Q: We have already implemented the first prototype of our product, but we need to know that we are either on a good course or need to change.
A: If you long for certainty you should not be doing a startup, pick a regulated utility or government bureaucracy as a career. Lean Startup and Customer Development techniques can help you to reduce risks by identifying them and developing mitigation strategies but it’s not a guarantee. Any real market attracts competitors and you don’t get to write their plans so it’s not just a question of understanding the prospect’s status quo but being able to identify and react to competitive threats. The view that product-market fit is a ratchet that you cannot fall back from neglects the impact of competitive response, new entrants, and continued changes in technology and customer preference.
Q: Perhaps I overemphasized our desire for certainty; we understand a startup is uncertain. Should we use our current prototype as an MVP?
Yes. I would start with what you have and use it as a probe to refine your understanding of the market and customer needs.
Make a distinction between the product, your message, and your target customer. You can talk about your product in different ways, adjusting your message to highlight and test key hypotheses. You do not have to make any changes to your product to this. Any product by definition–or at least any short enough for a prospect for prospect to listen to willingly–of necessity highlights some aspects omits others. You can also use different messages on different target customers or present different message to different prospects of the same type as a way of refining your understanding of what they view as important.
It’s critical that you have conversations with prospects and not simply present messages and see what they react to. It’s only in conversation that you can truly be surprised (you have to be listening, it’s not a monolog) and often the most surprising and useful thing a prospect can do in a conversation is to ask you a question you have not considered before (that’s why it’s called a conversation not an interrogation). When you are looking for early customers the value hypothesis is critical. You may reach them using non-scalable methods that don’t address your first real growth hypothesis.
My take on the distinction between hypothesis and assumption, your mileage may vary: A hypothesis is what is being tested explicitly by an experiment. An assumption is tested implicitly. By making your assumptions as well as your hypotheses explicit you increase the clarity of your approach and the chance for learning. The two things that can trip you up most often is an unconscious assumption that masks a problem with your hypothesis or an unconscious bias in whom you are testing the value hypothesis on. In particular you may have defined your target customer by certain selection criteria but your actual choices for whom to speak to (or who will speak with you) are not sampling from the full spectrum of possibilities.
Q: Or should we build another or several other smaller MVPs to test only the most important assumptions? Should we build various tests in parallel to test the needs of different types of customers?
I have come around to the approach of testing several hypotheses in parallel, I think you learn faster and are more likely to identify a good opportunity more quickly. After you take your current prototype and use it to have conversations, I would explore a few different potential customer types in parallel. One good article on this is by David Aycan, “Don’t Let the Minimum Win Over the Viable,” where he offers a comparison between three approaches:
Traditional linear approach:
I am also a huge fan of Discovery Kanban as a way to manage a set of options and experiments in parallel with managing commitments to customers and other execution targets. It actually gets harder as you start to gain some early customers and need to continue to explore the market and refine your understanding in parallel with keeping your current customers satisfied.
Trackback from your site.