In today's Portland Entrepreneurs' Salon, we were talking about Lean Startups. As we talked, I had a realization.

In Lean Startup, there's a lot of focus on creating a Minimum Viable Product (MVP). Like Sprints in Scrum, it's an easy concept that people latch onto right away. But perhaps that's the wrong focus. Maybe it's not MVP we should focus on, but MVH: Minimum Viable Hypothesis.

The Minimum Viable Hypothesis

In working on Rabu, Diana and I ran into a common problem. We were in love with our product. We loved designing it, thinking about it, creating it. We focused on creating an MVP, and when our target market didn't respond, we said, "Well, that must have been too minimal. Let's make it more robust." And we dived back into product development. We ended up with a nice product that hardly anyone uses. Then we ran out of money.

We were following the build-measure-learn cycle, but falling into an easy trap: persevering when we should have pivoted. I think it's because we were focusing on MVP at the expense of MVH.

With MVH, the first step after figuring out the problem to solve isn't to create a minimum viable product. Instead, the first step is to brainstorm market hypotheses. Which groups have the desire and funds for a solution? One way to brainstorm would be to put a big graph on a flipchart with "Desire" on the X-axis and "Funds" on the Y-axis. Potential markets would be brainstormed onto sticky notes and placed onto the chart. The guess in the upper right--the one with the most desire for a solution and the most collective funds to pay for it--is the first market to test. It's your best guess market.

It's still a guess, though. So rather than going out and creating an MVP, test the market. That's what an MVP is for, too, but I'm shifting the emphasis. For me, and I think for most people, it's way more tempting and fun to work on product than it is to work on marketing. But in the early stages of a startup, when you're discovering product-market fit, "market" is just as important as "product," and much less tempting to work on.

At the end of the build-measure-learn cycle, you have a decision to make: Pivot? Or persevere? Our mistake with Rabu was that we persevered when we should have pivoted. Our measurements showed us, over and over again, that people weren't using what we had built. We assumed that the problem was in our product, but I think it was much bigger than that: the market we had chosen didn't actually care that much about the problem we were solving. But because we were focused on our product, we kept investing in improving the product rather than pivoting to a new market.

Instead, I wish we had tested our market assumptions. We had made two implicit assumptions: that programmers on Agile teams wanted a tool to help them collaborate with their sponsors (desire), and that enough of them would pay us to customize such a tool to their situation (funds). We did test those assumptions once, with a successful landing page, but then we shifted gears to creating an MVP. We should have stayed focused on our assumptions.

The minimum viable hypothesis provides that focus. Product is built as a last resort. Each MVH is focused on providing an un-ignorable answer to the pivot or persevere question. To define an MVH, look at your market assumptions. Consider which are the riskiest, and ask yourself, "What unambiguous test would I trust so much that I would abandon this market and pivot if the test failed? What's the smallest test that I could perform that would give me that confidence?" The important part is to create this MVH in advance, with a clear and unambiguous pass/fail criteria, so you can overcome the temptation to simply press on when you're in the throes of development.

The MVH doesn't validate your market; instead, it helps you fail fast. Once you have your MVH, you go through the build-measure-learn loop: build the test, measure the results, and learn from them. Using your pre-established criteria, if the test failed, you abandon the market and choose a different one. If the test passed, you've validated one assumption, but more will remain. Choose the next riskiest, define another MVH, and build-measure-learn again.

Conclusion

I'm not changing any of the fundamental Lean Startup ideas. Testing hypotheses is what MVPs are for, after all. But by focusing on product rather than creating an explicit hypothesis, I found it was human nature to spend way more time on the fun product stuff than I should have. I'm hoping the MVH approach will help prevent that mistake next time.

In summary:

1. Don't start with a product.
2. Instead, start by brainstorming potential markets. Choose the one that looks most promising.
3. Consider your riskiest assumptions about the market. Pick one to test.
4. Define a test that you'll trust if it comes back negative. Figure out the cheapest/fastest way to perform the test. This is your MVH: minimum viable hypothesis.
5. Build-measure-learn. Build the MVH, measure the results, and take action:
6. If the test failed, discard that market and pivot. Start over with step 2.
7. If the test passed, persevere. Continue with step 3.

Thanks to Willem Larsen of Language Hunters fame for providing the case study we used to catalyze our discussion on this issue.