I started out in a waterfall world (the development process, not the Costner movie). When agile began to gather steam, I earned the nickname McWatterfall because I favored a more linear product development path. I rebelled against the rat’s nest that was being pawned off as agile, even as I knew we weren’t actually doing agile. I saw teams unable to enact the kind of rigorous research, strategy, execution, and design required by waterfall, and instead just flubbering about like squids in a bucket. Like others, I half-jokingly called their approach fragile.
Even in my waterfall days, though, I knew the initial product or feature wasn’t a static artifact encased in amber like some prehistoric bed bug. Our teams always had plans for how we’d iterate and improve things in the days, weeks, and months after launch. We weren’t manufacturing cars or building skyscrapers. Digital tech in general, and the web in specific, birthed a kind of never done mindset that was intoxicating and liberating. Agile and, later, Lean UX provided more rigorous frameworks for this never doneness in product design.
Why we iterate
User contexts and expectations are dynamic: markets mature, hardware and software evolve, and—occasionally—legislation upends the entire game. Then there’s the plain fact that we’re forever refining our craft, our tools, and our heuristics. And these factors don’t include more mundane forcing mechanisms like budgets, deadlines, and resource constraints (oh my!), each of which dashes our hopes of launching the Perfect Product™ or Ideal Feature® on day one.
“A work is never completed, but merely abandoned.” — Paul Valéry¹
These forcing mechanisms are often cast as exciting enablers of innovation. You know, move fast and break things—even though breaking things is rarely a realistic or responsible thing to do. Truth is, you’d probably get fired by the most ardent proponent of this pablum propaganda if you actually broke something important.² Still, the underlying concept has an allure: We should be experimental! Throw the spaghetti at the wall and see what sticks! FAFO, but in a good way!
Seems reasonable. Despite how vigorously we stomp our feet toddler-style, we’re regularly handed timelines that all but guarantee a launch that’s more Swiss cheese than fully cooked Reuben. Accepting our fate, we try to prioritize the features and functions that will make our initial market foray meaningful, where meaningful means we’re learning what works and what doesn’t, and developing something of a vision for future iterations. Invoking a sports metaphor, we call this an MVP because it sounds cooler than HBL (Half-Baked Launch).³
“An MVP is the smallest version of a product you can use to start the process of learning from customers. Think of it as the first experiment or in-market test of our ideas. It needn’t be the full product; often it’s a version with elements removed or one made using a simpler production process. It can be as simple as marketing materials or a brochure.” — Eric Ries
It sounds great! Dream big, start small, and iterate your way to fame and fortune!
And yet…
Meet the dissenters
There’s one group of people who don’t believe in the MVP process. They don’t care about our desire to continually innovate after launch. They haven’t bought into agile frameworks or similar design and development strategies, mostly because they think agile means “good at yoga.” Nonetheless, these folks are fantastically important; they have the ability to make or break us.⁴
These dissenters are the customers, viewers, readers, subscribers, posters and contributors who, if the stars align (and the marketing team has done their job) will use the products or features we’re designing for them.
Put simply, the customer is the true MVP.
We may not think of our pixelated products the same way we think about a coffee table, donut, or airplane, but our MVPs do. Just as they would never buy a table missing a leg, order an uncooked donut, or knowingly board an airplane whose engineers are still “working out kinks in the landing gear,” these true MVPs expect our products to be fully formed, to work as promised, with no known defects or omissions. Sure, savvy users understand that digital products improve over time, but they want—expect—the shipped product to be fully formed, not a work in progress.⁷
They’re humans, not guinea pigs.
And yet product teams of every size in every industry treat their MVPs—the people, not the process—just that way. At this very moment, in fact, the titans of tech are tinkering with our shared epistemology in a mad rush to win the natural language search war, all while arguing this is really just one big MVP for the future of…of…well, everything.⁵ The arts, media, science, education, commerce, love. The results so far are mixed, sometimes frightening, and definitely coming at us faster than anyone expected. So, as MVPs ourselves, we’re smart to ask what damage may be done in this proving ground.
Okay, that was a little dramatic 😰. (Still…)
Viable, but inaccurate
In addition to treating people like lab rats, another critique of the MVP model is that it results in launch products that are so bare bones they’re not very good at gauging a product’s true potential. In trying to get to market quickly and cheaply, the product is hobbled by corner-cutting and defects that reduce adoption and increase frustration such that the launch version will lead to skewed and misleading customer and market insights. In this way, the MVP process often undermines one of its central goals: rapid learning.
“A delayed game is eventually good, but a rushed game is forever bad.” — Shigeru Miyamoto
MVP proponents will say this risk can be mitigated if you do just enough research, but since a prototype thrown into a user research lab can only tell you so much, you gotta ship, right? But this rush introduces another risk: the initial foray, the MVP, may be flawed such that it stymies adoption now and into the future. One particularly negative high-profile review or news story could do irreparable damage to the product’s chances of gaining traction. Again, the MVP, despite everone’s best intentions, may do the opposite of what it promised—not because the underlying idea was bad, but because the execution, the MVP-ness of it all, was too leaky to sail.
Oh, and teams stuck in a seemingly never-ending loop of MVP development may start to shut down. Smart people like to do smart things smartly, if you’ll pardon the poorly constructed tautology, and MVPs—if we’re being honest—can feel kind of…not smart. Like a cheat code that unlocks a portal to janitorial closets rather than some magnificent new world.
A tale of two (photo) apps
A couple years ago, a new photo-sharing app called Glass entered a saturated market. It promised an elegant, minimalist way for photographers to share their work, with none of the noise or cruft found in established, consumer-centric photo sharing apps like Instagram. For Glass, it made sense to start small, focus on core features, and only introduce more bells in a thoughtful, measured way over time.
“At this early stage in (Glass’s) existence, it’s evident that a lot of work and care has gone into its creation. The app’s design is at a high level, and features are well thought out, especially regarding security and privacy.” — Malcolm Owen on the Glass launch, Apple Insider, August 2021
What if instead of a photo sharing app, Glass launched a photo editing app for the same group of avid photographers? That minimalist mindset would have to be balanced against user expectations. People who take photo editing seriously expect powerful tools that work every time. Omitting or downscaling key features in order to get to MVP could do permanent damage to the app’s reputation and long-term viability. Moreover, it would be hard to chart a path forward—one key promise of the MVP development process—when that path is blocked by a forest of feature, design, and tech debt.
Actually, we don’t need to hypothesize about this. A few years ago, Darkroomlaunched a minimalist photo editing app that did many or most of the things serious photographers expect from a photo editor, and did them so well that Darkroom quickly gained a loyal following. Darkroom was sprinting off the starting blocks rather than gasping for air, trying to prove its worth. Today, Darkroom is a robust but lightweight photo editing app that started out strong and has only gotten better with small tweaks and the occasional addition of substantive new features like color grading.
Both Glass and Darkroom are studies in launch minimalism done right: each focused on the things that mattered most to their MVPs; they did those things incredibly well; and both fast-followed with improvements and limited additions shaped by feedback from their now-loyal MVPs. Again, the MVPs for each app (serious amateur and pro-level photographers) were essentially the same, but those same people have very different expectations for each product. For photo sharing, they want less, and Glass capitalized on that; for photo editing, they want more (but done right), and Darkroom capitalized on that, as well.
Both Glass and Darkroom delivered a promise fulfilled rather than an IOU. Each launched products that were more than viable. They were lovable.
It must be love
If the MVP development model was, well, the MVP for this type of product development, the MLP, or Minimum Lovable Product, is its first major product update. Like its v1 release, the MLP embraces constraints as necessities to kickstart the launch-learn-iterate cycle, but sprinkles in enough magical Kano Dust so that viability becomes lovability.⁶
The MLP approach reminds me of that quote by Aaron Walter: “Designers shooting for usable is like a chef shooting for edible.” What we accept in the world of pixels would never be acceptable in meat space.
Okay, so, we just gotta MLP, right? Constraints with benefits. We’re good?
On the surface, yeah, sure. But what happens if your product team says they’re doing MLP when they’re actually doing MVP? They’ve been handed a ton of constraints and so they’ve convinced themselves (or simply embraced the myth) that the MVP is going to be lovable. That barely enough is more than enough. As I write this, there’s a Product Manager somewhere doing a find-and-replace in their product brief, swapping MVP for MLP. Guaranteed.
If you’re curious as to whether you’re about to ship a lovable product, share it with some potential users. If it’s met with approval but not excitement — if your potential users spot the plot holes and see them as potential blockers — you’re shipping an MVP, not an MLP. If the prototype is met with indifference or suggestions for fundamental improvements, it’s a weak MVP, not an MLP. Your users are telling you you’re about to hobble your ability to learn anything meaningful, and you might be inviting failure as well. Listen to them.
What’s a perfectionist to do?
Research. And not just research on a polished prototype or, worse, an alpha or beta version. Rough, organic research from the earliest stages all the way through to that wondrously terrifying initial launch. Heck, research might tell you to stop the MVP / MLP train altogether, and it’s a lot cheaper than launching even the most minimal version of your proposed product.
Research can be the User Ego to the Business Id, the voice of reason encouraging us to avoid skimping, to try to buckle down and deliver the stuff we might not think we need to deliver right now—the stuff we think we can fast follow after launch, but which inevitably gets ignored because there’s a new shiny toy to play with. Or, as noted above, research might sober us up, draw us away from our stumble-drunk dreams of an MVP that opens the door to profitability and promotions. A caffeinated dose of reality, if you will.
History repeats itself
Pixels changed everything. Instead of carving characters into a slab of stone or machining aluminum into landing gear, we can shoot a specific configuration of electrons anywhere we like, to anyone who wants them. We learn how those electrons are being used (or not), what’s working and what isn’t working, then blast an updated configuration of electrons into the ether as an app update.
But this ethereal malleability and impermanence can lead us to think we don’t need to do all the hard work we should. It can lead us to launch products that frustrate, alienate, and otherwise fail to gain any kind of traction with our customers.
Sometimes it’s better to do all the things—or most of the things—now. Because now is when users—the true MVPs—want them, and want them to be done right. Or, if appropriate, to do a few things, but to do them really well. Well enough that the product’s promise is evident and compelling enough to drive adoption.
When I find myself avidly sipping the MVP Kool-Aid—when I start to think it’s just peachy to knowingly ship borked products—I like to remind myself that a cake without frosting is just bread.⁸
Utter hypocrisy
If you’ve read this far, it’s possible you’ve catalogued several objections to the way I’ve characterized MVPs and MLPs. Maybe you’re reflecting on all the times you’ve seen MVPs do what they promised. Maybe you noticed that I didn’t include alpha or beta programs, which are kinda / sorta MVP-ish, and which can be highly effective for learning and evolving before a bigger release.
Guess what? I’m with you. Sometimes you gotta MVP (or, preferably, MLP). Sometimes it’s the best way forward, or the only practical way forward. I can admit my hypocrisy here: I’ve been an avid participant in many an MVP.⁹
I’d only reiterate, though, that not everything should start out as an MVP, and that before accepting MVP (or even MLP) as the best path forward, all the associated risks and challenges should be weighed against the benefits of perceived speed and efficiency. And I stand by my claim that most MLPs are really just MVPs with a letter swap to rationalize the shortcomings. At least that’s been in my experience. YMMV.
And, finally, I stand by my assertion that the real MVP is the user, not the process—and that MVP should be the central focus of any design and development process.
¹ Attributed to Paul Valéry, but may find its roots in a quote by da Vinci, who was supposed to have said, “Art is never finished, only abandoned.”
² Good news: tech’s love affair with MFABT seems to be waning. Bad news: it’s still a siren song for companies eager to launch products quickly and cheaply.
³ Not an industry term. 😜
⁴ Your job is to protect management from bad decisions, and bad decisions are the ones that hurt your customers. Never get this backward.
⁵ Legit question: has Marc Andreesen lost his marbles?
⁶ Some teams use the term MCP (Minimal Compelling Product) instead of MLP. I have the same reservations as above, but I think compelling is a more realistic and measurable metric than lovable.
⁷ I’m excluding alpha and beta releases for the (hopefully) obvious reason that test participants understand they’re not getting the full enchilada.
⁸ In fairness, cake without frosting is still pretty delicious, but if your goal was to capture the cake market, delicious bread isn’t going to cut it.
⁹ I still maintain that most Agile is really just Waterfall set to Repeat or, worse, Shuffle.