Don’t fix MVPs that fail
As explained via a weird bridge metaphor!
Ever found yourself in this chain of events?
- You did exhaustive discovery research.
- You found a real user pain point.
- You iterated through dozens of sketches and prototypes to find a solution.
- You cleverly identified a cheap way to build an MVP.
- You launched it.
- … And it flopped.
Where does one go from here?
Do you say to yourself — “thank god we only built an MVP and not the whole thing.”
Or do you say — “of course it flopped, it was too stripped down, let’s fix it!”
My hunch is that lots of teams say the latter and that is almost always a mistake.
Building products means dealing with uncertainty. Thankfully, we’ve developed ways of minimizing uncertainty — cheap prototypes, user research, and iterative development. 👊
This holy trinity of product development often results in creating a so-called minimum viable product.
Despite all that you can learn through research and prototyping, there is still a knowledge gap. Confidence has increased and risk has been mitigated. This is all well and good.
But you still need to cross the chasm and see what happens once it is real. You’re at Point A and you have learned about Point B. But you still need to actually get there.
“In theory, there is no difference between theory and practice. But, in practice, there is.”
Jan L. A. van de Snepscheut
👆This is precisely why not all MVPs work. If we had successfully mitigated all risk in earlier steps, why not jump right to building the full solution?
So we agree there is still some risk and we want to start small. A minimum product. But it also has to be viable. 🤔
How exactly do you define “viable”?
This part is really hard. I think it is one of the hardest things a Product Manager does. You need to thread the needle between two opposing forces.
- Build it quickly and cheaply
- Solve your users’ problem in a real and compelling way
The first item is a little easier. Cutting scope and reducing functionality is pretty straightforward. It’s not always fun but most folks are pretty good at it.
It is the second wrinkle that makes this challenging because…
How will you know if the thing you decided to cut is the reason why users didn’t adopt the solution?
This what-if-anxiety can be haunting. This happens because the feedback you receive on MVPs is asymmetric.
MVP is successful… you do not get a lot of “this would have still worked without [blah]” from internal or external stakeholders. It is mostly time for 👏 and 🙌.
MVP is unsuccessful… you’re left with a lot of “what ifs.” You know, stuff like—“maybe if we had invested in performance more so this wasn’t so slow we would have seen better adoption!”
I like to call this “the bridge is out trap.”
I’ll try to explain. We’ve learned users would like to get to Point B across the river. Unfortunately, there is a gap in the middle of the old bridge that crosses it. As an MVP, we’ve decided to build a small ramp and let people jump the gap for now.
In this world, you don’t ask a lot of questions after users careen towards the ramp and make it to the other side. You just take a deep breath after watching them catch some sick air.
But if they come up short? 😬 (Note: no users were killed or injured in this hypothetical example.)
- “What if we made the ramp larger?”
- “What if we installed a radar gun with a sign to encourage users to speed up?”
- “What if we required cars to weigh in before they can use the ramp?”
This exercise is kind of fun. (Again, the users are not dead so it isn’t morbid, relax.) It is satisfying to trial-and-error your way to a fix.
Plus, let’s be real — product managers love ideating on solutions. And because this MVP-ramp was so stripped down in the first place there is lots you could conceivably improve about it. All the low hanging fruit.
And, there is kind of a sunk cost fallacy at play here too. We already built the ramp! Let’s fix it and try again!
Do you see where this is going yet?
Don’t fall for it. In this example, you didn’t just randomly build a ramp and cross your fingers. 🤞
You measured the gap. You asked users about the type of cars they drive. You knew the user’s average speed. You did some fancy physics calculations. AKA all of the earlier validation steps. You did these important steps first… right??
So if it didn’t work? Sure, you could try again. But this wasn’t some fluke failure. It failed despite a good amount of upfront diligence. Odds are it is going to require a significant investment to make it not fail.
Your MVP failed. Oh well. Big deal. It is part of the process. It is why you use this process.
Move on. Let it go. Don’t fix the MVP.
Maybe it is time to pilot a ferry service across the river? Don’t worry—if your users really miss the ramp, they’ll let you know and then you have permission to try again.
