The concept of minimum viable product (MVP) has been popularized in the past decade thanks to the success of the wonderful book, The Lean Startup. It’s thrown around so casually, and you hear it so often, that sometimes you wonder how — or even if — people define it.
In this post, I’ll describe how I think about MVPs, first using one real-life example and then using my favorite MVP analogy.
The concept of a minimum viable product is simple:
- Every startup is basically a hypothesis (e.g., we think people will buy an X).
- Instead of doing a big build-up during a lengthy stealth phase concluding in a triumphant (if often ill-fated) product unveiling, let’s build and ship something basic quickly — and start iterating.
- By taking this lean approach we can test our hypothesis, learn, and iterate more quickly — and avoid tons of work and waste in the process.
The trick is, of course, those two pesky words, minimum and viable. In my worldview:
- Minimum means the least you can do to test your hypothesis.
- Viable means the product actually does the thing it’s supposed to do, even in some very basic way.
I’ll use an old, but concrete, example of an MVP from my career at Business Objects. It’s the late 1990s. The Internet is transforming computing. We sell a high-functionality query & reporting tool, capable of everything from ad hoc query to complex, highly-formatted reports to interactive multidimensional analysis. That tool is a client/server Windows application and we need to figure out our web strategy. We are highly constrained technologically, because it’s still the early days of the web browser (e.g., browsers had no print functionality) [1].
After much controversy, John Ball and the WebIntelligence team agreed on (what we’d now call) the following MVP:
- A catalog of reports that users can open/browse
- End-user ad hoc query
- Production of very basic tabular reports
- Semi-compatibility with our existing product [2]
But it would work in a browser without any plug-ins, web native. No multi-block reports. No pages. No printing. No interactive analysis. No multidimensional analysis. No charting. No cross-tabs. No headers, no footers. Effectively, the world’s most basic reporting tool — but it let users run an ad hoc query over the web and produce a simple report. That was the MVP. That was the hypothesis — that people would want to buy that and evolve with us over time.
Because of that tightly focused MVP we were able to build the product quickly, position it clearly within the product line [3], and eventually use it as the basis for an entirely new line of business [4].
Now, let’s do the analogy. Pretend for a moment we’re in a world where there are no four-wheel drive cars. We have invented the four-wheel drive car. We imagine numerous use-cases [5] and a big total available market (TAM).
What should be our MVP? Meet the 1947 Jeep Willys [6] [7].
No roof. No back seat. In some cases, no windscreen. No doors. No air conditioning. No entertainment system. No navigation. No cup holders. No leather. No cruise control. No rearview camera. No ABS. No seatbelts. No airbags.
No <all that shit that too many product managers say are requirements because they don’t understand what MVP means>.
Just the core: a seat, a steering wheel, an engine, a transmission, a clutch, and four traction tires.
- Is it missing all kinds of functionality? Yes
- In this case, would it even be legal to sell? No. Well, maybe off-road, but we’re in analogy-mode here.
- But can it get you across a muddy field or down a muddy road? YES.
And that’s the point. It’s minimum because it’s missing all kinds of things we can easily imagine people wanting, later. It’s viable because it does the one thing that no other car does. So if you need to cross a muddy field or go down a muddy road, you’ll buy one.
As Steve Blank says: “You’re selling the vision and delivering the minimum feature set to visionaries, not everyone” [8].
So next time you think someone is focused on jamming common but non-core attributes into an MVP, tell them they’re counting cupholders in a Willys and point them here.
# # #
Notes
[1] And printing is a pretty core requirement for a reporting application!
[2] This was key. WebIntelligence could not even open a BusinessObjects report. Instead, we opted for compatibility one layer deeper, at the semantic layer (that defined data objects and security) not the reporting layer.
[3] If you want all that power, use BusinessObjects. If you want web native, use WebIntelligence. And you can share semantic layer definitions and security.
[4] BI extranets.
[5] From military off-road applications to emergency off-road and/or slippery conditions to sand recreational to family vehicles on snow and many more.
[6] Which in some ways literally was the MVP for Jeeps.
[7] Popularized by the Grateful Dead in Sugar Magnolia (“… jump like a Willys in four-wheel drive.”)
[8] Where I’ll define visionary as someone who has the problem we’re trying to solve and willing to use a new technology to solve it. It’s a little easier to think of someone trying a next-generation database system as a “technology visionary” than the Army buying a Jeep, but it’s the same characteristic. They need a currently unsolvable problem solved, and are willing to try unconventional solutions to do it.
