You’ve just thought of an amazing idea, an app to solve ‘X’. This is huge! Within the next few minutes, you’ve planned 17 awesome features, planned mental wireframes and page designs for those features and a tech. stack to boot. Sound familiar? You’re not alone. We’ve all started building a product for ourselves, assuming others will want the same. After countless hours of development, long nights and gallons of coffee, it’s finally launched, except nothing happens1, people aren’t interested it seems. Why not?
The problem was, it was built for you, not for them.
Recognise the Problem and Change Perspectives
Recognising the problem is vital in order to avoid wasting time.
When starting a new product (or project), be on the lookout for thoughts or ideas that have no business case behind them. This might not be as exciting, but if you’re building it for someone else, then this is how it needs to be.
Don’t waste time building a feature that will never be used.
You’re building it for them, so what do they want?
The solution is to ignore ‘me’ and switch into customer mode. To see it from their perspective. These are people that will be parting with their hard-earned cash. There has to be a good reason for them to do so. So, it all starts with one question:
As a customer, what do I want?
You’ll notice that we’re not offering anything here, nor are we determining if a problem can be solved. There aren’t restrictions either. Just a simple question with an open-ended answer.
This is TDD
At this point, a developer reading this will see the crossover with test-driven development (TDD). TDD is where you write tests (questions), then write code (features) to pass those tests (answer the questions). No code is written until the tests are. With this new perspective, no features are created until they are requested; no solutions are created without first having a problem.
Asking The Question
Here’s an example. You’re thinking about building a web analytics product for the modern web. What does the customer want?
As a website owner, I want to know:
- How many visitors do I have?
- Is it increasing?
- What’s the trend?
- Which websites do they come from?
- Should I put more effort into promotion on Twitter or Facebook?
- Did they read my blog?
- Which articles do people like?
- Which articles suck?
- How much of an article does someone read?
These are questions that customers will be willing to trade cash in return for answers. Looking at it like this reinforces that it isn’t about what features can be provided, but what problems people want solving.
The secret to success: 😠 + 💰 = 💡 + 🤑
Questions, into Answers, into Products
Now that we have the questions our future customers are asking, we need to work on producing answers and placing those answers inside a product.
Problems become solutions, and solutions become products.
In the beginning (MVP stage), take a core set of questions and answers, choose the most valued ones and convert them into features. You will then validate this by charging for the product, aka charging for the answer. You’ll realise soon enough if people are willing to pay for your solution.
A mature product is driven by
featureuser requests, often with a large backlog to choose from. We can apply the same principle to new product development in order to be smart about where our limited efforts are focused.
BONUS: While people pay for solutions not features, a beautiful UI with a fantastic user experience can (in some select cases) trump features. The trick is to know the target market.
You might be one of the lucky few who get it right the first time, but don’t count on it. ↩