The MVP Death Spiral

Prioritising features is a micro version of the "if we build it they will come" mistake

Jun 02, 2024

Howdy!

Of course it makes business sense to only build what your customers want to pay for.

That’s why the idea of the Minimum Viable Product (MVP) is so alluring.

There’s just one tiny problem. You can’t know for sure what the MVP is beforehand. Reality has too much detail. You can only know after you’ve already found it.

Prioritising features for your MVP is guessing. Using a fancy prioritisation framework? Then it’s fancy guessing.

That’s why every feature you dream up, debate and prioritise is the famous “if we build it they will come” fallacy – just broken into smaller pieces.

Today, I’m going to explain how the concept of features leads teams into the MVP Death Spiral, give you some clues so you can tell if you’re already spiralling, and suggest an escape hatch.

First, some very quick updates:

I was on Product Quest Podcast this week talking about complexity. The trio running the interview asked great questions that helped to clarify the power of Cynefin Dynamics (more on that here soon), and we also talked about Estuarine Mapping. If you like strategy for operating in uncertainty, you’ll enjoy this one: https://overcast.fm/+4kzW1lvUU
Speaking of podcasts, OMG we’ve now published 50 episodes of Trigger Strategy Podcast! The latest one was about rumination, instinct and the fundamental attribution error. And the next one (coming Tuesday) is going to be about the MVP Death Spiral, with more thoughts and stories than I can fit in this article. We’d love to have you join us on our walk-and-talks. Let us know what you think!
OK now let’s unpack the dreaded MVP Death Spiral …

Here’s how the MVP Death Spiral goes:

You pick a set of features that you’re confident will make for a successful product. “We’ve cracked it! This is clearly a unicorn idea!”
You race to build those – you’ve got to get the MVP done! “Ship v1, then we can start learning and improving using data.”
Racing to build it takes ages. You grow frustrated, and you’re already thinking of new ideas you want to try. “This is taking too long! What features can we cut?”
As the MVP takes shape, your confidence starts to waver ... “the product wasn’t like this when we imagined it.”
You list additional feature ideas that you hadn’t thought of earlier. But you’re also afraid of scope creep delaying things further. You waste a bit of time estimating how long it’ll take to add the new features. Too long. “Come on! We’ve gotta ship!”
As you get closer to launching, your confidence plummets. Early conversations with prospects have given you a bad feeling: customers just aren’t that into it. “Perhaps this winning idea doesn’t have product-market fit after all?”
Rationalise that it must be because there are key features missing. Grab those lists of additional features you’ve been making and push to prioritise them. Decide on a new MVP. “YES! This time we’ve cracked it!”
Increase your level of panicked desperation by 50% and loop back to step 2.

Does that sound familiar?

If you’ve ever been shackled to an MVP initiative, you’ve probably been nodding your head as you read the above. Maybe you were weeping quietly. It’s OK, feel free to take a moment.

You’re not alone. This death spiral is incredibly common.

How to sense when you’re in the MVP Death Spiral

ever-increasing pressure to prioritise ever-longer lists of features, to meet ever more urgent deadlines.
grasping for a better prioritisation framework. Classics include the Impact/Effort matrix, MoSCoW prioritisation, many sub-variants of ICE, or there’s always good old fashioned horse-trading among the stakeholders.
you’re talking about being data-driven but you don’t know how to get data until you’ve got customers using the software. This is the “data-driven” chicken and egg trap.

How we end up in the Death Spiral

Like many of these complex and vicious cycles, there’s no root cause. There are lots of conditions at play, including but not limited to:

The need to feel in control (when grasping for more control is a reliable way to lose control)
Optimism bias
Prematurely rushing to scale things
Grasping for predictability using requirements and estimates
Competing industry, company and discipline narratives about “how digital product teams are supposed to work”
Competing narratives about what customers want and what our organisation should become
Competing (and fuzzy) goals inside your organisation – even when there are official goals, they can be at odds with various implicit and individual goals

But today I’m going to point a finger at something that runs through many of these like a streak of raspberry ripple runs through a tub of ice cream. The very concept of features.

“Features” – an attractive concept but a bad strategy

I’ve noticed that to many folks working in tech companies, it’s self-evident that a digital product is a thing made up of features. Then it follows that building a product is about figuring out the right set of features to bolt together. Q E motherfudging D.

Features are an attractive way of thinking about building digital products because they feel tangible and under our control. We can imagine each one, label it, and put it into a neat ordered list.

Compare that with thinking about customers and their behaviours. They’re messy and ambiguous. They’re confusing, and constantly changing, sometimes scarily so. They’re outside your control. You can’t easily put them in a list.

One takes a supply-side perspective on what we do, the other a demand-side perspective.

In an ambiguous, uncertain situation — like trying building a valuable new product — humans naturally “solutionise”. We scan the situation, perceive about 3% of what’s going on, and then do a first-fit pattern-match. We leap to the first solution that feels like a decent match to the story we’re telling ourself about what’s going on in the world. What pops into our mind is an idea. And it feels right and good and complete.

And it’s convenient to label that idea in some way. That’s where we reach for the concept of a “feature” or a “product”. As we talk with others in our organisation, our idea often mutates and turns into an expanding list of features.

So far, so good. Labelling ideas and breaking them into smaller chunks so that you can hold each one in your head and talk about it is natural and helpful. Humans use lots of abstractions when we have conversations. I’m not saying don’t do that.

I’m saying that features become a problem when you treat them as if they’re a real thing.

When you think of features as real things, you stumble into an additive approach to product development: “if we can just put all the desired features into the product bucket, then we'll win!”

That’s the moment you’ve tipped over the edge and started slipping down that hellish helter-skelter I call the MVP Death Spiral.

Many companies talk about how we have to avoid the “if we build it they will come” fallacy, but every single feature ever considered is a micro version of this fallacy.

“You are not one feature away from success and you never will be.” - Teresa Torres

What to do instead of working with features

Remember that features aren’t real. Behaviours are real. Take the demand-side perspective and work with behaviours instead.

People have pushed back on this. Surely you need to build features to be successful?

Maybe. But your success depends on the behaviours of people and systems that are outside your control. You’re going to have to grapple with that at some point, and I recommend that point being astonishingly early. Before you worry about features. Before you set the launch date for another MVP that’s simultaneously half-arsed and bloated.

Stop trying to pick the right features to make your product awesome. Start trying to enable the right behaviours to make your customer awesome.

This is a shift from supply-side tactics to demand-side strategy.

One reliable method I’ve found that’s helped lots of teams figure this out is to start with a Multiverse Map. This is a very fast way to collaboratively map your shared narratives about existing and desired customer behaviours. It’s an easy portal to the wonderful world of demand-side strategy.

Have you tried one yet? To help you, the steps are laid out for you in this article.

And if you’d like more detail, I walk you through the whole process with examples, tips and structure in my Master Multiverse Mapping course. One customer described it as “so easy it feels like cheating”, and another said, “the energy that followed of wanting to take action within the different groups was really nice to see.”

I invite you to step away from the MVP Death Spiral and through the portal with me.

Until next time,

Tom x

with thanks to

Corissa Nunn

for editing and support

P.S. If you’d like hands-on help from me personally, reply to this and let’s chat.