These 4 steps will minimise wasting your time, money and the risk of failure by developing your product, together with your customers from day one. The model is built on top of:
-
Customer Development, which is helpful when you don’t know the problem. It’s a simple methodology and a process for getting out of the building and talking to potential customers, the market — before you start building anything.
-
[Agile development][agile], which is helpful when you don’t know the solution.
While none of the ideas presented below are new, the model brings them together in an effective way to give entrepreneurs a framework to work from.
Why
The most common pitfall related with customer development is that teams do not use it. Instead they fall in love with their product (the solution) without understanding which, if any, needs it satisfies. The result is a product without a market, or with a smaller market than anticipated and potential business issues.
1) Discovery
Discover something people want! The goal here is to reduce uncertainty by documenting assumptions and validating them by getting out of the building and talking to potential customers. Customer discovery and business case development starts at the same time and the two should inform one another. Learning should start at this stage - what can be tested without building anything? And how does this inform the assumptions in the business case?
Discovery of opportunities based on e.g. customer needs. Assessing opportunity potential for Emerging Business offer.
Identify the need
- Do they have the problem or need?
- Do they know that they have the problem or need?
- Have they been actively seeking for a solution to the problem or need today or in the past?
If the answers are yes to all three questions, you might have found the right customer segment for you to address — your early adopters.
Identify assumptions
“What must be true for the solution to be effective?” Business environment, Dependencies, Minimum requirements for a solution, Change management required
Once you have an understanding of the true need, hypothesize a potential solution. If you were initially handed a solution to deliver, you can include that as a candidate, but you may find that the need you’re satisfying requires a completely different solution.
Validate assumptions
And no, we don’t test for the viability of our proposed solution by selling it to them. We are not trying to convince them why they should use it in the solution interviews. This is not the time. And no, we don’t start building elaborate solutions before we first go out to test our hypothetical solution. Sketches and mockups are what we start testing with. Click Dummies and PowerPoints are more than enough at this stage.
Objective: Finding Problem-Solution fit
Tools
- Business Model Canvas or similar such as Offering Vision Board
- Assumption backlog
- Interview guide based on assumption backlog
Potential outcome scenarios
- Find significant signal, say e.g. that 40% of a 100 interviews actually confirms there is a felt need or problem
- No significant signal
- Another problem or need is found during the interview process that is more interesting to pursue
2) Finding proof
Make something people want! The goal here is to build just enough to start learning with customers. This applies not just to the service itself but also the broader operation. Premature scaling distracts and slows things down. More important is to get into learning loops and using the learnings to prioritise what’s next.
If, and only if, we can find significant signal we start to build it. This is when we start with building an MVP — Our first Minimum Viable Product.
3) Constantly re-evaluate your solution
Continuous Discovery and Delivery Cadance! The goal here is to find “Product Market Fit”. Too often people slavishly deliver a roadmap of features. Instead the business needs to be prepared to change anything required to prove enough customers want the new service and can’t do without it.
Many of us experience “falling in love” with our product where we fight to push through the execution, ignoring early warning signs that the original assumptions are wrong. - Dr Rita McGrath
Pro tip: Focus on a small subset of the market. Having few, paying customers forces [you] to focus 100% on what those customers need,” instead of being overwhelmed by a mass of data-points and free-signups. By showering a small segment of paying customers with time and attention, you gain valuable, actionable lessons on how to build a product that future customers need, rather than one they’d like.
Converting customers to paying customers
Talk about pricing with your customers. Before you ask how much they might be willing to pay, try to learn the value of your solution. It is important to remember that value is not the same as cost. Does your product save time? Money? Increase market share? Increase (their) customers’ satisfaction? The price your customer is willing to pay is somewhere between what they tell you and what the real value of your product is to them.
Pro tip: You will get a better idea by asking them, as market experts, how much another company would be willing to pay for the solution or by submitting a range of prices and seeing how they react.
It’s never too early to charge money for your product. Always put a price tag on everything you do to validate the signals and feedback you get from customer development.
4) Growth
Can we replicate our early sales model? The goal here is to establish a highly iterative and data-led approach to growth. One that’s tightly interwoven with ongoing product development. Quite simply the traditional approach to marketing doesn’t work for early stage ventures so a rapid, iterative approach is required instead to find the messaging, channels and journeys that stick.
You are at Product-Market fit, if you have built a product that customers need and this has been validated by high user adoption or through a significant number of paid users, and to some degree adoption and retention are “running themselves.”
P-M fit is an esoteric concept you only know you’ve achieved after you’ve achieved it. It’s like declaring the “turning-point” in a game: only once you’ve won or lost, can you reasonably hypothesize the actual turning point.
Tools
- Pirate metrics - AAARRR
Resources
-
Steve Blank’s Customer Development terminology from his book the “4 Steps to the Epiphany”
-
[Agile development][agile]