Minimum Viable Hypothesis

Or, why it’s good to have a hypothesis at all

I was reminded today of the idea of the Minimum Viable Hypothesis. I think I first saw this on the blog of James Shore, an early practitioner and proponent of Agile Development (he wrote the book back in 2007, after all).

On his blog, James talks about devising a test that you’ll trust if it comes back negative, as a way to see whether your product idea is viable for a certain market segment. Then figure out the cheapest and fastest way of performing this test. This is your MVH. There’s slightly more to it than that, but not much.

Essentially, he’s just asking you to find a way to validate your riskiest assumptions about a market before you start building product. It’s surprising how often people fail to undertake anything like this. Instead, they go for low-hanging fruit and figure we’ll burn that bridge when we come to it. I am of the opinion that low-hanging fruit is more or less poisonous. (More on that in another post.)

Devising a MVH helps derisk whatever you’re working on, by helping you to either locate a market that needs your product, or better understand what a particular market’s needs. It puts the hard questions first, and lets you start out with a couple of big strides, rather than baby steps (at least as far as market validation is concerned).

And it’s good to extend this idea to whatever development you’re doing. Even having specific hypotheses in mind as you’re planning each sprint or release can bring a lot more insight to your process. I think this is pretty basic stuff for a lot of agile practitioners, but it’s surprising how often teams (even those that consider themselves agile) neglect to do this.