Where are you going?
It started well. You built a great product. You got some early adopters and they loved the product. You built it further, and got paid customers. They loved it, too.
You talked to your customers. Understood their problems better. Worked on making your product better. Fixed bugs. Added features. Added some more features. Created that mobile app. Created another mobile app for another platform.
An year has passed and your product is now a mess. You worked relentlessly to create that mess. How? You didn’t know where you were going.
Wait before you build
What’s the easiest part of creating a product? Adding things. You get feedback from every place you can think of. Paid customers, free customers, customers who use it daily, customers who don’t use it at all, friends-who-tried-it-once, everyone. It’s difficult not to find some really attractive ideas in that deluge of feedback.
That’s the problem. There are two things you are doing wrong:
a) You aren’t qualifying feedback. For a small team, ruthless focus and prioritization is important. You cannot and must not build a product for everyone.
b) You don’t have a product roadmap. You’re building upon everyone’s feedback and that is usually a signal you don’t have a strong enough roadmap. That makes it easy for you to miss the larger picture and inevitably create a product that nobody will love.
Start by understanding your users and usage better. Who are the people using your product the most? What are the things that they are using the most? Do they have problems with those? Can you improve their experience? Usually, that gives you the most value for your time.
That doesn’t mean you ignore paid customers who aren’t using your product at all. That usually is a sign your product isn’t critical for them or they don’t extract enough value out of it. Maybe they don’t know how to do that.
Once you know what their expectations are, you can nudge them in the right direction.
You know whose feedback matters. What next? The most common mistake is to take a customer’s words and build exactly what they want.
A better strategy is to move away from the details and understand the broader problem. How? A customer tells you that they want a certain feature. Take a step back and try to understand what they are trying to accomplish.
Take the case of a calendar. Usually, when you have the ability to schedule events (tasks, reminders, to-dos, whatever you call them), a good percentage your customers will inevitably want a calendar. Should you build one?
No. Not without a very good reason. Building it without thinking about the problem will waste invaluable time, add another complex feature to support, and it’ll be another feature you will have to ensure gets used.
There are better ways to solve the problem. Do your customers just want to see all their events in one place? You can sync your events to their calendar. Or, you can avoid a calendar altogether and allow them to see all their tasks on a simple page that’s not a calendar.
There are a number of ways to solve that exact problem, but the customer usually doesn’t have the insight. Customers usually indulge in a lot of guesswork. It sounds like validation, but it isn’t. You have to take the problem, think about it, understand it, and experiment with different ideas to solve it.
Don’t confirm your biases
Often, we have very rigid ideas about about what we want to build. We go around asking customers what they think about it. We think it’s validation, but it’s just a confirmation of our biases. And it’s not helpful.
“No one has ever failed to find the facts he is looking for” — Peter Drucker
Your customer interviews should be to understand a customer’s problems in depth, not confirm what you think is their problem.
Take the example of a mobile app. You know mobile apps are important. Everyone has a smartphone, and having a mobile app will increase your product’s usage. It will get you more users in the long run.
You ask your customers, and sure enough, everyone loves the idea. They all need a mobile app, because why not? It’ll be great. You spend three months building an app. Then another. Do you see where you’re going with this?
When you don’t think through it, your features will often meet the same fate: no usage. And no amount of growth hacking and onboarding tweaks will solve that problem.
Don’t build it all at once
Lastly, the most important piece of advice: don’t build it all at once. Even if you make the wrong decisions, this gives you the opportunity to save some time and money.
You’re dead-set on building that mobile app. You have an intuition it will be a great success. Sometimes intuition is a great thing. Go ahead and build it. However, don’t cram it with all things imaginable. Build a lean version of it, launch it quickly, monitor its usage, get feedback, qualify feedback, and iterate.
Small improvements, great results
We learned one of the greatest lessons of our lives very early in our lives. Slow and steady often wins the race. A product that you improve a little everyday will be a much better product in an year than one that added a big bang feature every month and got no usage.
Go slow, learn quickly, and you win.