Join the DZone community and get the full member experience.Join For Free
How to Simplify Apache Kafka. Get eBook.
You’ve also got a ton of unknowns and uncertainty. You know you can’t just go build it and hope they will come. You have to do it iteratively. Put a little bit out there, see how people react, figure out what to do next.
But where do you start? How much is enough to start getting feedback?
Josh Seiden gave this awesome talk at Boston’s Lean Startup Circle on replacing requirements with hypotheses. And it occurred to me that what he’s really talking about is hypothesis-driven development, which I love.
In Agile, we drive our development with tests. We say, “okay, I know what the product needs to do, so let me write the test first.” It’s an automatic check. If I accidentally develop the feature incorrectly, the test will fail and I’ll get immediate feedback that the feature isn’t ready yet.
But what about in a startup where we’ve only got guesses for what the product should do? Then the tests should not be whether features are implemented correctly. Who cares if nobody wants them?
What we do care about is creating a successful business. So those tests aren’t for if the product works, they’re for whether it’s the right product. Now we’ve got an automated check. We don’t waste our time & money building something until we’ve validated it’s the right thing to build.
How it Works
Start from your business model canvas (I like Ash Maurya’s Lean Canvas). This documents the assumptions you’re making about how your vision will become a successful business – who your customers will be, why they’ll want this particular solution, how you’ll reach them, etc.
Now, pick your riskiest assumption and use Josh’s template to document it:
We believe that ____________________
We’ll know we have succeeded when we see: ____________________
Your signal needs to be clearly measurable. And it should be measurable within a short period of time (hours, not weeks).
Ash has a great blog post on running experiments to measure hypotheses. In it, he talks about how we tend to start with “Leaps of Faith” such as this:
Being known as an “expert” will drive early adopters.
But how do you measure that? You need to break it down into quickly testable parts. For example:
We believe that if we write a blog post on our new product, people will want to buy it
We’ll know we have succeeded when XXX people sign up within 24 hours.
Then, use the results to determine your next steps. If the expected number of people signed up, maybe you want to reach out to them and learn more about what they’re looking for so you can focus on building what’s most important to them. If nobody signed up, you know you’ve got more work to do at finding the right audience and appealing to them.
Don’t be afraid that your hypotheses will be wrong. Your goal isn’t proving to anyone that you’re right. Your goal is creating a successful business. Those hypotheses are just your tool to drive you there.
Here are some great resources to learn more:
» Replacing Requirements with Hypotheses by Josh Seiden
» Lean Startup is a Rigorous Process by Ash Maurya
» How to Evaluate and Implement Startup Ideas Using Hypothesis Driven Development by Daniel Tenner
Published at DZone with permission of Abby Fichtner , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.