Hypothesis-Driven Development

Hacker News LinkedIn Facebook Twitter by Abby Fichtner

I'm always wrong about everything. What can I do to fix that?You’ve got your vision of what you want to build.

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.

Learn More

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

  • Pingback: buy backlinks()

  • Pingback: Homepage()

  • Pingback: steingarten()

  • Pingback: Focus in Chaos: Why I Like Kanban for Startups « The Hacker Chick Blog()

  • Pingback: smash bros. online()

  • Pingback: Agen Judi Terpercaya()

  • Pingback: Agen Bola Terpercaya()

  • Pingback: Agen Judi Casino()

  • Pingback: free porn videos()

  • Pingback: cinema lausanne()

  • Pingback: แทงบอลออนไลน์()

  • Who says you can’t just build it and they will come? Answer: Investors (this may include your spouse/partner/landlord or others with a monetary interest in rapid success.)

  • So this is all about a definition of success. The trick is you can’t predict it. What you can do is to define a minimal acceptable success like “We need at least 100 paid subscribers in the first month”. What if you have 50? Is it bad? Yes, it is. It is below a minimal success scenario. How you can fix it? You know nothing about that. 

    I don’t think this technique is terribly helpful. Maybe slightly, but I don’t buy it. My internal definition of success works pretty good to me. I don’t need any formalization. 

  • With apologies to anyone who just commented – I just learned that Echo (who I was using for comments) is no more, so am importing everything into Disqus… it should all return soon, i hope

  • RT @HackerChick: Just Blogged: Hypothesis-Driven Development http://t.co/DhYrBQ0O #leanstartup #agile @jseiden @ashmaurya @swombat

  • Trevor Lohrbeer

    I’m a bit torn on this. I don’t think converting all requirements to hypothesis is practical. There’s an overhead to generating hypothesis, success conditions and running tests.

    I think it can be useful, but I would add one additional question in the hypothesis: Why?

    Or rather:

    1. We believe that: _____________________
    2. Because: ___________________________
    3. We’ll know we have succeeded when we see: ____________________

    Without a reason for the hypothesis, all that’s being tested is a correlation. And that doesn’t let you extrapolate to other situations. Testing the “Why?” gives you two things: a) different assumptions can be tied to the same underlying reason, so that reason can be tested from multiple angles to make sure it’s correct, b) learning reasons allows you to extrapolate and create validated learning that can be used to generate more accurate hypothesis in the future, or to jump straight to implementation when the overhead of testing is too high.

    This can be taken further with the 5 Whys method, but as a start every hypothesis should define why the expected results are expected.

  • RT @HackerChick: Just Blogged: Hypothesis-Driven Development http://t.co/DhYrBQ0O #leanstartup #agile @jseiden @ashmaurya @swombat

  • RT @HackerChick: Just Blogged: Hypothesis-Driven Development http://t.co/DhYrBQ0O #leanstartup #agile @jseiden @ashmaurya @swombat

  • RT @HackerChick: Just Blogged: Hypothesis-Driven Development http://t.co/DhYrBQ0O #leanstartup #agile @jseiden @ashmaurya @swombat

  • Just Blogged: Hypothesis-Driven Development http://t.co/DhYrBQ0O #leanstartup #agile @jseiden @ashmaurya @swombat