So here’s the thing: The Lean movement has jumped on the phrase ‘Minimum Viable Product’, devoured it whole and absorbed it utterly. Unfortunately, the term does not mean what most lean types think it means, and this can actually be quite damaging.
The official, canonical definition comes from SyncDev, the company run by Frank Robinson, who coined the term. According to them, the MVP is:
that unique product that maximizes return on risk for both the vendor and the customer
And that seems like quite a good thing. I think we’d all like to maximise our return on risk. The “minimal” bit suggests a cleansing, cathartic process of scraping away anything that’s high-risk or low-return, and exposing the bare essence of the product. This is, we believe, the bit that straightforwardly offers something desirable for the customer – and profitable for the vendor.
This idea works quite well when applied in the context of incrementally novel products in a well-understood market. If you’re a TV manufacturer, and you’ve been making TVs for decades, you can use the MVP maxim when designing this year’s line of TVs. Do we need to add a cup-holder? No, because we don’t know much about the value add of cup-holders to TVs. It bumps up the risk more than it bumps up the return. But do we need Blu-ray? Yes, because without it our feature set doesn’t compete with our competitors at our target price point. So the product isn’t viable without Blu-ray, but cup-holders go beyond the minimum. Lovely.
But there’s a problem. When developing new products, especially when one is developing a new category of product, it’s really, really hard to know what the MVP looks like. For any given feature, if you’re being honest, the answer to questions like “How much risk will this add?” or “How much might this increase our return?” is going to be “I have no idea”, at least at the start of the process. In fact, that’s sort of the point of using Agile processes like Scrum in the first place: the start of the development of any product is when you know the least about your product. That ignorance very definitely extends to what will affect return on risk in what ways.
Which is fine, of course. You don’t need to know what your MVP is when you first start building. You’ll figure it out as you go along. In fact, you’ll probably only figure it out when you get there – you’ll wake up one day, look at the numbers, and say to yourself, “Golly gosh, I think this product is finally viable!” And if you’ve been disciplined in your approach, starting small and building only what you need, at the point of viability what you’ll have will probably be pretty minimal too.
Here, by the way, is where I diverge from the Lean Startup crowd. They say that you just build an MVP and then tune it. To me, that’s glossing over the hard/interesting bit, which is working out what the MVP is. Furthermore, when they say ‘MVP’, they don’t really mean MVP as defined by Robinson – if what you’ve built really “maximises return on risk for both the vendor and consumer” then frankly it doesn’t need tuning.
But if the MVP is the end result of your development process, and you won’t know what it looks like until you’ve built it, well, it’s not a very helpful target to aim for. “I’ll know it when I see it” does not instill confidence in the first planning session. You need something more tangible to work towards. What should that first target be, then? Well, let’s think about what you’re trying to achieve in the early stages of product development. You have an idea of what you want to build, but you acknowledge that you don’t know what’ll really work (at least, I hope you acknowledge it – if the past 20 years have taught us anything it’s that in the world of the web, no one knows what’ll be popular a priori). So what do you do? You gather data. And you do it through the classic cycle of build/measure/learn. Now, some people describe the product of each build phase as an MVP, but again, taking its definition from the original source, we see that the term just doesn’t apply here. We’re not thinking about the return for the customer at all, and the only return the vendor values at this stage is knowledge. The term just doesn’t fit very well.
So I propose a new term. What you should be aiming for, when lining up for each circuit of the build-measure-learn loop, isn’t an MVP at all. It’s an MVE – the Minimal Valuable Experiment. What you want is to do the least amount of work you have to to perform an experiment that gives you valuable information back. That experiment might involve A/B testing a new feature on some users. It might involve showing a barely functional prototype to a focus group. It might even involve building a website advertising parrot cages that doesn’t actually sell parrot cages. It’s whatever you need to do to learn a little bit more, to get you that one step closer to viability.
Am I just being finickety? Does it really matter that you say MVP and I say MVE? After all, just because you use MVP to mean something different to what Frank Robinson meant doesn’t mean that you’re wrong. In the context of Lean the term has taken on a specialist meaning, and that’s just fine. Right?
Well, no. Because regardless of the original definition, talking in terms of ‘viability’ and ‘products’ puts the emphasis in the wrong places. ‘Viable’ makes you think about things like revenue, customer bases and margins at a time when you should be focussed exclusively on knowledge acquisition. ‘Product’ makes you lean towards building working software and working prototypes, and polishing them to look like finished products, when you might be able to learn something useful from knocking up a survey on Google Forms and posting it on Twitter. It takes a lot of guts to hold off on building your product until you know enough to build the right thing, and focussing on learning in the first instance. Aiming for a minimum viable product from the get-go undermines that good intention. But working on a series of minimal valuable experiments, on the other hand, reminds you constantly that you’re an explorer, a researcher, an empirical scientist, and in the moderm world of digital businesses, that’s how great product decisions are made.