Why and how to challenge your MVPs

Ah, MVPs, or Minimum Viable Products. I haven’t seen many projects without them in the last few years. Yet still, I haven’t seen project success rates going up significantly either, despite what MVPs promise: building the smallest thing that will bring success. What are we doing wrong? What can we improve?

Of course, project success and failure can have many reasons, especially in an innovation context. Focusing on MVPs, let’s look at this iconic image “How to build a Minimum Viable Product” by Henrik Kniberg from Spotify:

Both approaches divide the product scope into smaller steps. This is good: you get a better grip on how your project moves forward (or not).

However, while the first approach delivers something useful only at the very end, the second approach delivers something useful at every step. This allows you to get valuable customer feedback from the very beginning.

• In approach one, the customer does not know what he would need to do with a tire or wheel, as it does not solve his problem. The customer does not care, and cannot provide useful feedback.
• In approach two, the skateboard will potentially help the customer solve his problem to some extent, albeit in a quite rudimentary way. After trying out the skateboard, the customer will tell us about its advantages and disadvantages. We will learn about the customer problem and the required solution features from real-life use. This helps us adjust our scope with small fine-tunings or big changes.

So far, so good. But there’s a catch: many people think both approaches imply we’ll be building a car. This would mean that the final scope is known from the very beginning. Regrettably, this is still a fact in many projects: we set out to build a fairly large, mostly pre-defined scope. Yes, we chunk it up in so-called “MVPs”, but in reality, we have the entire scope in mind from day 1. And

• we find it very hard to let go of it;
• we forget to build in moments to really challenge our problem and solution understanding, and validate whether customers or users find our solution valuable.

The truth is, most of the time we do not know if the initial solution we have in mind is the right one. We don’t even know for sure if we are solving the right problem. Customer feedback at every step will help us find out whether we should be building a car, a train, a boat, an airplane, a teleportation system, or maybe something else entirely. Maybe even nothing at all, because people just don’t care. We definitely want to discover that early on! In an uncertain world, it’s impossible to know everything up front, and we need a development approach that enables us to learn and change course easily.

How to go about this in practice? We’ll need to consider each of our “MVPs” and ask ourselves a few questions:

• Is this MVP a small enough increment over our previous version? Asking this question will allow us to keep the learning loop short and to limit the potential waste of time and money. So let’s challenge ourselves each time: how can we make our next MVP even smaller? (Note the word “how” in the previous sentence. Don’t remove it. ;-))
• Is it clear what we are trying to learn with this MVP? What feedback do we want to capture that will help us get to the best solution more quickly or more efficiently?
• Are we building only what is needed to get that feedback? What can we remove that, while part of our future vision, is not essential for our current learning?

What do you want to learn next, and how small can you get your corresponding MVP?

What’s next?

Interested to learn more about MVPs? Check out my e-course on The Master Channel.

References

• Making sense of MVP

Acknowledgements

• Photo by Janik Lipke from Pixabay