Are you ever ready to launch a new product or service, or to set a new update free into the wild? After all the time and effort in brainstorming, planning, designing, and building, you have to decide to go live. But is it good enough to go ahead?
The painful MVP
This is where we inevitably talk about the MVP: the minimum viable product, which is an incredibly useful way to discuss what is “good enough” to begin with. And which has therefore, paradoxically, become one of the biggest problems in agile.
Of course, volumes have been written about defining an MVP. But since I’m currently busy writing on how to improve the time to market of digital experience projects, it was one of the things that jarred me. If there’s such a good understanding of what an MVP is, and how it fits into an agile project; if you can read up on what Frank Robinson meant by it, and how Eric Ries defined it; and if you can find a plethora of simple illustrations of the core idea (often involving bicycles and cars). Then how come when I ask people, “what was your most recent experience with defining and building an MVP?”, many will start by rolling their eyes. Or sighing deeply? I might as well have asked “what’s the biggest argument you’ve had at work”.
Paralyzing perfectionism
The reason for that is perfectly understandable: ambition and perfectionism. It’s another paradox; some of the most capable and experienced teams can struggle with it the most. What makes them good at it, also means “good enough” to them is rarely, well, good enough. A new product has to eclipse previous accomplishments. And updates and relaunches are worse: existing reputation is at stake. A new version has to be better; not a step back. All of this, of course, within constraints of deadlines and resources.
So let’s take a step back to Eric Ries’ definition of an MVP. “That version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.” That’s not about being lazy, it’s about speed. An MVP is not supposed to be launched, it’s supposed to be what you test. If you ambitiously bloat your MVP and then try to polish it to perfection before getting it in front of people, it takes too much time. Worse, it turns the MVP into a moving target, and every bug and every pixel keeps teams from getting there.
Are you as agile as Achilles?
That’s the third paradox, which I’m borrowing from Zeno, the Greek philosopher. “Achilles and the tortoise” is why I sometimes call MVPs “turtles”. You will never reach a turtle, no matter how fast you go. Because by the time you reach it, the turtle has already moved on. And you then, again, have to move to where the turtle is. Ad infinitum. Zeno concluded that all motion is an illusion; I call it product launch paralysis.
It took about two millennia for math to defeat that paradox. If you look at a graphical representation of it, you could much more easily defeat my analogy and note that unlike Achilles, development sprints have a fixed length. Passing the turtle would be easy, two weeks at a time! And that, of course, is exactly the point. Because the MVP isn’t a goal in itself. You have to get past it.
In the pressure chamber of launching products and updates against deadlines, it’s one of the things most easily forgotten. The MVP is not what you launch. It just helps you determine what to launch and what direction to take to get there. Step out of the paralysis and test fast, and test often. Bring it in front of your stakeholders and users as early as you can, and keep going.
Does that guarantee your actual launch will be a success? Well, don’t ask what Zeno said about arrows hitting their target… that’s a story for another day.
