Q: What are the key hypotheses you need to address first getting your startup off the ground? What is the difference between a hypothesis and an assumption?
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 who 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 who to speak to (or who will speak with you) are not sampling from the full spectrum of possibilities.
“Creative leaps are discontinuities, qualitative changes. They involve three steps: identification of self-imposed constraints (assumptions); removing them; exploring the consequences of their removal. That is why there is always an element of surprise when we are exposed to creative work–it always embodies the denial of something we have taken for granted, usually unconsciously.”
Russell Ackoff in “The Democratic Corporation” (page 99)
- Hypothesis Not Hype
- Early Markets Offer Fluid Opportunities
- Spend Some Time On How To Disprove Your Hypotheses
Update Wed-Jan-29-2014: Tim Allan left a great comment that elaborated on the need to focus on value first even if your methods don’t scale:
There was a bit of a light-bulb moment for me what I read the line:
“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.”
I feel this is so often forgotten, especially in the situation of legacy systems and trying to execute lean product design within larger organizations. One example that I have been involved in, and which I regret not pushing back harder, was a requirement to use some legacy data services.
This meant that we couldn’t initially execute a hand-cranked, non-scalable solution to data storage and retrieval that our product required, which would have been better as it would have enabled us to get to customer quicker and get real learnings about how they are using our product.
At the time it didn’t seem like a big deal, but in the end it was, and continues to be an issue and an impediment in getting to the customer quicker. Likewise, any real growth hypothesis, results will most likely be skewed by the performance of systems that are not in your control.
I want to thank Tim for offering a practical story that elaborates on the principle of confirm the value before worrying about scaling. When I was at Cisco the focus was always on “will it scale,” as in we shouldn’t do something because “it won’t scale.” This sometimes led to us releasing a product that could have been more valuable if we had proceeded a little more thoughtfully and incorporated early feedback before rushing to launch. Techniques that work “in the small” to gather insight have their place even inside of large firms.
Trackback from your site.