Real customers display these common characteristics:
- They have a problem or need
- They understand they have a problem
- They pay you money to make the pain go away
- They’re actively searching for a solution and have a timetable for finding it
- The problem is painful or costly
- An Interim solution is better then no solution
- They’ve committed, or can quickly acquire, budget dollars to purchase
Real customers are perfect candidates for our customer discovery process. They can be relied on for feedback and initial sales; they’ll tell others about the product and spread the word that the vision is real. Moreover, they can be potential advisory board candidates. At its core, the essence of customer discovery is to answer these questions: have we found a problem lots of people want us to solve (or a need they want us to fill)” and “does our solution (a product, a website, or an app) solve the problem in a compelling way?”
Vision or a hallucination
A startup begins with the vision of its founders: a vision of a new product or service that solves a customer’s “expected” problems or needs. So on the day the company starts, there is very limited customer input. All the startup has is a vision of what the problem, product and solution seem to be. Unfortunately, it’s either a vision or a hallucination. The company doesn’t know who its initial customers are or what features they’ll want. So the No. 1 goal of all startup’s must be this: turning the founders’ initial hypotheses about their market and customers needs into real data driven facts.
The goal of customer discovery is to test your understanding of the customer’s problem and see if your proposed solution will prompt users to buy the product based on its current features alone.
Goal of customer discovery
The goal of customer discovery is to validate your understanding of the customer’s problem and see if your proposed solution will prompt buying of the product based on its most important features alone. If no one thinks your MVP solution is interesting or sufficient, iterate or pivot until an adequate number say “yes.”
This shift in thinking to an incremental and iterative MVP as opposed to a fully featured first product release is important. Engineers tend to make a product bigger and more perfect. The MVP helps them focus the most important and indispensable features. Your goal in having an MVP is not to gather feature requests to change the product or to make the feature set larger. Instead, the goal is to put the MVP in front of customers to find out whether you understood the customer problem well enough to define key elements of your solution.
In the Customer Development model, feature requests to an MVP are by exception and iteration rather than by rule. This eliminates the endless list of feature requests that often delay first customer ship and drive product development teams crazy