The Myth of the Perfect MVP

MVP. Minimum viable product. An acronym everyone agrees on in theory and defines completely differently in practice. Ask engineers and viable usually means functional. Ask stakeholders and viable starts to stretch into something bigger, shinier, and more marketable. And in regulated spaces, the definition shifts again, because viability isn’t just about function. It’s about safety and risk.

Working in regulated industries I come across lots of different scenarios. I’ve worked in environments where a system could technically process drug transactions, but edge cases exposed weaknesses that weren’t acceptable in the real world. On paper, it was viable. In practice, it wasn’t ready to survive scale or scrutiny.But when you’re facing deadlines and pressure from the business, what do you do? You can release and hope an edge case doesn’t surface, or you keep working until you’re confident you’ve reduced the risk. Neither option is comfortable. That’s where the real definition of “viable” starts to matter.

To be honest, as I write this I struggle to come to terms on what a viable definition actually means. In a regulated industry it's pretty simple, viable does not jeopardize patient safety so when drug transactions don't meet safety requirements, you pull back. However in non regulated industries what does that mean? If you have a sports app that tracks workouts, heart rate and other variables when do you cut?

For a sports app, viability isn’t about having every feature. It’s about quality, which leads to trust. If the core tracking is off, nothing else matters. As someone who walks often, if I walk three miles and the app says one, there’s instant frustration. Most users don’t care how polished the interface is if the data feels unreliable. A viable version might be smaller, but the parts that exist have to work well enough that people believe what they’re seeing. The moment users start doubting the numbers, the product stops being useful. At that point it isn’t minimal. It’s broken.

And that’s where the myth of the perfect MVP falls apart. The goal is to ship something strong enough that you can keep building on it while maintaining the users trust at all times. Sometimes that line is clear and most times it's not and difficult decisions have to be made. Deadlines will always exist. Stakeholders will always push for more. There is always pressure to remove, add or fix one more thing. But viable isn’t about pleasing the room. It’s about protecting the relationship between the product and the people using it. If that relationship breaks, no roadmap can fix it.

But who am I? Just a product owner arguing with the definition of MVP like the rest of the industry.

Thanks for reading (: