Whether you are building a product from scratch or revamping an existing one, one piece of advice I have is to never build for perfection.
It took me a while to change my attitude towards building the best products and building successful products. We often assume they mean the same thing. But a product can meet every expectation you had for it and still do very little for the people using it.
Perfection is a never-ending process. There’s always another screen to improve, another feature to add, another version of the onboarding flow that someone wants to try. So when you intend to build for perfection, what you end up doing is build forever.
There’s nothing wrong with aiming high. The problem is having no way to decide when you’ve done enough to put something in front of users.
The other problem with perfection is that it is different for everyone. What is perfect for you may not be perfect for someone else. Your designer wants a simpler experience. Your sales team wants more features. Your engineering team wants to rebuild the thing properly this time.
All of them may have valid reasons. How do you decide?
You have got to define what you’re trying to achieve before you build.
So what do you build? MVP? Lean startup sort of something?
Sure. You can call it an MVP or Lean or something along those lines. But best of all you can build for success.
Now, what on Earth does building for success mean?
It means building to achieve certain goals. Let’s assume you are planning a massive revamp of your existing product. Good for you. But why are you revamping it?
Are users struggling to finish something? Are they signing up and never coming back? Or has everyone internally become bored of looking at the same screens?
Those are very different reasons to do the same expensive thing.
Find out why you are building that revamped version. Define a few key metrics and build to improve them. Keep the list short enough that your team can actually use it to make decisions.
Here’s an example.
Goal: Improve the signup completion rate by 20%.
Be clear about what that means. If 50 out of every 100 people who start signing up currently finish, a 20% relative improvement would mean getting that number to 60. Decide when you’ll review the result, too.
Now you have something to work with.
Do we need users to create a profile during signup?
Maybe. But do they need to upload a photo, write a bio, and tell us where they work before they can use the product? Some of that could wait until it becomes useful.
Do we need a progress bar?
It could help people understand how much is left. But if the process is unnecessarily long, a progress bar won’t fix that. First ask whether all those steps need to exist.
Do we need both an email address and a phone number?
Maybe not. Depending on the product, one verified contact method might be enough. Where unnecessary verification can wait, introduce it at a more relevant stage.
The point is that you now have a reason to question each requirement. You also have a way to find out whether your answers were right.
And you do need to check. A sensible explanation for a feature doesn’t guarantee that it will help.
There’s a catch here, though. You can get too attached to the metric as well. Researchers at Microsoft documented how teams running thousands of experiments repeatedly drew wrong conclusions from changes in their metrics. Seeing a number move doesn’t automatically mean the product has improved. Their research is worth a read.
In our signup example, more people completing registration is encouraging. But do those people go on to use the product? If they all leave five minutes later, there’s still a problem.
And it goes without saying that you should be wary of hygiene issues. Broken flows, poor accessibility, or careless handling of user data don’t become acceptable because they weren’t part of your target metric.
For everything else, give your team room to make decisions. You don’t need to settle every small design debate yourself. Agree on the outcome, make sure the basics work, and see what happens when people use what you’ve built.
You’ll probably find something you hadn’t thought of. Leave room to work on that, too.
So, what are you building today? And how will you know it worked?
