The metamorphosis of the MVP (and how to save it)
The MVP awoke one morning from uneasy dreams and found itself transformed into a giant insect. It had devolved so far that it bore no resemblance to its former self. However, the fault was not in The Lean Startup but in a pervasive culture of overpromising and underdelivering.
Mutant Locusts
Warning: bugs (I don’t like them any more than you do. Skip this paragraph if you’re squeamish).
I worked at a bar for a year after college. We had a pest problem — cockroaches. I wasted no time in calling the exterminators. FDA guidelines must require that the poison doesn’t pose a risk to people: It wasn’t strong enough to get rid of the cockroaches immediately. In fact, they would live on for about seven more generations (not human generations, thankfully, but their little bug lifecycles). Each generation would be more sickly than the last, smaller and deformed, hobbling around on five mismatched legs, until they could no longer reproduce and would die out.
This memory is etched onto my retina screens when I think about the state of “MVPs.” Maybe once upon a time there were eager project managers who understood the true concept but just wanted to build, baby! They skipped the whole “Learn” thing and were rewarded for moving on to the next project. Then others learned from the misinformed and added some clumsy Agile practices. It’s the misunderstandings of MVP that have spread like locusts. I can only hope we’re finally at the seventh generation of degradation and this mistake can be mercifully put to rest.
A Life in the Day of the Mayfly
Things do move fast in the tech industry — Moore, Christensen, and the funds rate always nipping at our heels. With a quick lifecycle comes the possibility of rapid change. This can take the form of progress, or it can be an overnight loss of institutional knowledge. The MVP concept was also a product of the dot com mania and bust.
- The term “Minimum Viable Product” was coined and TM’d by Frank Robinson in 2001 at his process consulting company, Product & Market Development, Inc. The MVP was a “right-sized product, big enough to cause adoption, satisfaction, and sales.” [my emphasis]. I get a kick out of this: the tagline for their product was “Sell, Design, Build.”
- Steve Blank, “the father of modern entrepreneurship,” and Shawn Carolan, Partner at Menlo Ventures, met on a mountain top and landed on “customer development” rather than market development. “Translate company ideas into business model hypotheses, test assumptions about customers’ needs, and then create a ‘minimum viable product.’” — Steve Blank, HBR
- Shawn Carolan developed the MVP Tree framework to help startups find product-market fit. The MVP goal is “To be the best tool for one job, for one customer group, such that they stick around.”
- Circa 2009, Eric Ries started to formalize his variation on the MVP concept. What gets lost in the sauce here is that he encapsulates all of the above — the customer research, discovery, selling, design, and testing — into the “MVP” phrase.
There has been much said about the pros and cons of taking an “MVP” approach. I share the countertrend view — don’t blame Eric Ries. While the concept predates The Lean Startup, it certainly got a big boost from that publication. Let’s take a look back at its examples and lessons in the book so I can stop putting quotation marks around MVP.
Crickets in our Conscience
The book offered four examples of MVPs, including:
- Dropbox — a video prototype leading to a waitlist signup. (Note, a prototype doesn’t need to be “working;” in Dropbox’s case it was composed of static stick figure drawings).
- Food on the Table — an in-person, concierge proof-of-concept for recipes and grocery delivery that would theoretically someday be automated.
- Aardvark — (a product that hoped to be Google for subjective search) tried the “wizard behind the curtain” proof-of-concept. Humans secretly answered the questions (restaurant recommendations, etc.), that were submitted by users.
None of these MVP examples was a built product. They were prototypes, “pretotypes,” practice-runs, or proofs-of-concept. (Incidentally, these companies were still plagued by wasted development efforts. Two of three no longer exist for reasons we’ll explore below). But we can’t blame The Lean Startup for their mistakes. The MVP concept is introduced in the Test chapter; e.g. test your idea before you build it.
“A Minimum Viable Product helps entrepreneurs start the process of learning as quickly as possible. It is not necessarily the smallest product imaginable, though; it is simply the fastest way to get through the Build-Measure-Learn feedback loop with the minimum amount of effort.”
Let’s tell the truth. The book’s argument is that you need to validate — or more likely, invalidate and iterate — quick and cheap. It emphasized a feedback loop, it did not advocate to launch a fraction of a feature and then move on to the next.
Lucky for us, we now have tools to gather feedback faster and more accurately than ever before.
Along Came a Spider
Ideas, no matter how good, are outputs of their time and place. As the world around them changes, they lose their luster. Copernicus was fresh when he introduced a heliocentric model of the solar system. When the data didn’t match the model, he added as many complexities as a Swiss watch — maybe the planets orbited little invisible nodes in perfect circles that themselves orbited the sun in perfect circles. Then Kepler was like, “nope, ovals!,” rendering the Copernican model laughable.
We have to remember that The Lean Startup was written 12 years ago. On the one hand, the world hasn’t changed much. The interwebs changed everything (arguably the smartphone, too), but since then, there haven’t been any life-altering technological inventions (crypto bros, come at me). On the other hand, the power of our existing technologies continues to grow exponentially. One of them has indirectly changed the landscape for product development: bandwidth.
Bandwidth has led to harder, better, faster, stronger spiders (2001 version) crawling across the web. Most important to our discussion are Figma and UserTesting. Figma, leveraging cloud computing, has allowed us to design and host prototypes that can be indistinguishable from a live app. UserTesting, leveraging both the cloud and a bandwidth-supercharged gig economy, records, analyzes, and returns user experiences nearly instantly.
The current strength of these tools wasn’t even feasible in 2011. We no longer need to build a product in order to measure and learn from a product. The startups of tomorrow will spin up a Dropbox-esque video and waitlist website with AI, respectively drumming up and validating market demand in minutes, not months. They will iterate and optimize the UI and UX of the “product” before there’s a product organization.
The Many Permutations of MVP
MVPs, while misinterpreted and misapplied to tragic consequences, don’t need to go away. It’s just a question of semantics. P is for… Product? Not anymore. Here’s how to ensure your survival.
Minimum Viable Proof-of-Concept
The Zappos example is canon. The Zappos founder used existing products — physical shoe stores, a camera, Flickr, and the USPS — to validate a proof of concept. Our term “productize” suggests that we’re not really inventing something new, we’re just “-izing” something old. We’re stringing together existing products and services into a cohesive whole with the goal of automating and integrating the data and efficiencies as much as possible.
It’s vital to understand that most of the cool ideas we have are amalgamations and remixes of other existing things. Break your idea down into its existing product components and see how you can manually perform them.
Minimum Viable Prototype
This is now so easy (and cheap) with Figma and UserTesting. It’s astonishing how few startups prototype and validate, both at the concept and usability stages. So you’ve done a proof of concept and confirmed that a few people are into your idea. Now a design team of one can make it a virtual reality. Are you not a designer? Get one. There are also enough publicly available design systems and UI kits for free or next-to-nothing that anyone can cobble together a decent app screen.
And AI, sure, but from what I’ve seen, so far the output is uber generic. For non-designers, a word of caution: design is not the interface, it’s the problem-solving. What you’re hoping to do with a prototype is see if a user can successfully, enjoyably complete a task. UserTesting is best utilized to iterate toward a successful solution. AI may be some years away from being able to solve this (but I hope UserTesting is working on it!).
Minimum (Un)Viable Problem
Most successful startups are not creating some cool new thing with Jobsian certitude that “people don’t know what they want until I give it to them.” Mostly it’s about identifying a problem, understanding the underlying causes of the problem, and then coming up with a solution. The bigger the problem — the more annoying, costly, or time-consuming — the better. How can you determine if the problem is truly unviable? A little bit of research goes a long way. Talk to your target market and find out if it’s as big an issue for others as you’ve deemed it to be. Along the way, dig in and find out why it’s a problem. You may discover the secret sauce for your solution.
Food on the Table, the MVP example above (along with Blue Apron and everyone else who has tried) failed on so many different vectors that it’s hard to pick the worst. My vote is that there isn’t a problem. The target market doesn’t hate grocery shopping — it kind of appeals to the gatherers in us. People love cookbooks and picking recipes. People like to select the produce that looks just right (good luck with the avocados). And we like the unpredictability of it, picking what we’re in the mood for in the moment.
Minimum Viable Probability
It’s fair to say that there’s nothing new under the sun… but there are varying shades of newness. Nothing is truly original, but some things are more original than others. Ideas are cheap, but some are worthless, and some are worth pursuing. It’s very hard to be sure a market will want a new, original product. People are tuned in to what bothers them, but it’s much harder to know whether a novel idea will catch on. Often the most original of ideas will make people balk. This is where we can turn to some quantitative analysis to gauge the probability.
Go broad to your network with surveys. I also like to add some quant survey questions to the end of a UserTesting prototype. “Do you like this?” won’t do; try an NPS-style “rate how desirable this is for you 1–10.” Try pricing sensitivity or drop a mention of a waitlist signup to see if the tester actually puts their money where their mouth is. What’s the percentage of follow through we’re looking for? There’s no right answer, but it’s much, much closer to 100 than 0.
Aardvark found some initial engagement but it was a false positive. The app would receive a user question and then (manually) relay it to their network. What was the probability of success here? A survey would have revealed a lot. Will you consent to an app asking you questions on behalf of your acquaintances? Would you prefer to simply text a friend or post a question on social media? When friends aren’t available we’d sooner turn to a stranger whose opinion has credibility. It wasn’t just between the lines but on the lines of Ries’s passage: the value of the information “depends on the person answering.” While Aardvark turned into a $50m Google write-off, Eater, Michelin, and Instagram influencers flourished.
Minimum Viable Profitability
There are innumerable good and useful ideas out there that just don’t have a prayer of making money. First and foremost, is it something that people or businesses will pay for? If you plan to traffic in eyeballs, are they lucrative and high-intent enough for you to monetize through commission, paid (and curated) partnerships, or ads (probably not)? You must at least do some back-of-the-envelope calculations of your unit economics.
Consider the Minimum Viable Predictability of recurring revenue or non-seasonal retention and LTV. Estimate the Minimum Viable Promotability of your product by looking up average customer acquisition costs for your industry of choice. Try a Minimum Viable Painted-door to see how many people will click to buy, even if you don’t have something to sell yet.
Minimum Viable Protection
I wrote an article a couple weeks ago about the dying unicorn, Bird, and why it was never fit to live. That was an issue of both profitability and protection — or moats, as we like to call them. There are a handful of different defensive strategies for businesses, but imho there are only two worth a damn. A close third is network effects, but in practice these can engender as much distrust, animosity, and litigation as any temporary benefits. The two that matter are IP and Brand; without them the invisible hand will smack you around and commoditize the sh*t out of you. The first is highly specific, regulated, and lasts 20–70 years; the latter is nebulous, ever-changing, and requires constant effort.
Minimum Viable Proliferation
This last one wraps up all of the above. The death cry of most “viable” startups is a CAC > LTV. It costs more to get a customer than the total profit they generate during your beautiful but impermanent relationship. Anything you spend money on to acquire users — from your Sales team to SEM — will intrinsically have limited economies of scale. You’ll need to grow for free, too. It starts with your network, but from there, it requires that customers come to you and then tell their friends. It has to be something that people want; it has to be something usable — or better, fun; it has to solve a problem or be something new that excites people; it needs solid unit economics and a margin that you can maintain without a race to the bottom.
And that, my friends, precludes a Minimum Viable Product — at least the current sad version of its former self. The MVP has reached the end of its life, poisoned as much by mismanagement as the superficial misreading. In the 10-year Fed firehouse of quantitative easing, the money had to go somewhere. Sadly, the best place many startups could find was the toilet bowl.
“Because startups often accidentally build something nobody wants, it doesn’t matter much if they do it on time and on budget. The goal of a startup is to figure out the right thing to build — the thing customers want and will pay for — as quickly as possible.”
— Eric Ries
One of the more damaging internal metrics has been “hitting dates.” It’s a relentless race to skip all valuable effort and hack away at a product concept because someone put it on a spreadsheet with a made up date to the left and a made up revenue estimate to the right. No time to waste? Take a look at the laundry list of product duds and write-offs.
“We need to show investors and the market that we can commit to new feature deliveries and hit our target dates.”
Have you heard this before? Looking through my last decade of work, smushed against the glass ceiling of Design, reporting to the Chief of Something, I can’t recall hearing anything else.
Long Live the MVP
Don’t be discouraged! Start your startup, just don’t build the product… yet.
Work on your MVPs until you pass the P-test on all, or at least most, of the above. Then, and only then, should you write your first line of code. If you’ve already got engineers, PMs, designers, or marketers on payroll and you’re worried about them sitting on their hands or, god forbid, enjoying their job through self-directed motivation, have them work on foundational efforts of flexible and scalable components that can be put to use towards your future product, whatever shape it takes. Have them file for patents or trademarks or copyrights, have them build inbound content marketing that actually says something. Have the whole team participate in user research.
The MVP is the way.
