What Even Is an MVP
Eric Ries, defined it as:
— “The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”
Sounds straightforward, right? Except in practice, the term “MVP” has been twisted, bloated, and stretched so far out of shape that it barely resembles this original intent
Every single project I’ve worked on in the past five years has aimed to deliver an MVP.
But here’s the thing—what is an MVP, really? Is it the smallest thing you can build that solves a problem? Is it a barely-functional prototype you’ll fix later (spoiler: you won’t)? Or is it just a vague buzzword someone threw into the roadmap to make it look like they know what they’re doing?
And let’s talk about “viable.” Viable for whom? The users? The stakeholders? The team? If the MVP is “viable” for everyone, then it’s no longer an MVP—it’s a full-blown product that somehow skipped the learning phase entirely. And that defeats the whole purpose.
The Misuse of MVPs in the Real World
Ah, the classic: “Deliver the MVP, but make sure it’s perfect.”
Excuse me? That’s not an MVP—that’s a contradiction wrapped in buzzwords, sprinkled with unrealistic expectations.
Here’s how it usually plays out:
- Management wants something that ticks all the boxes but insists it’s “just an MVP.”
- Security says it’s not viable because it doesn’t meet every possible standard.
- The team spends weeks aligning with everyone on what “viable” means instead of building anything.
By the time it’s finally delivered, it’s either:
- A bloated monstrosity that tries to be everything to everyone, or
- A half-baked prototype that gets abandoned because “we’ll improve it later” (spoiler: you won’t).
The result? Nothing gets learned. The product doesn’t deliver value. And everyone involved leaves the project thinking MVP stands for Mediocre, Vague, and Painful.
The Ideal MVP Mindset
Here’s what MVP should mean:
- Build something that works.
- When it’s viable for you, it’s viable.
- Ship it.
- Treat it like a product: improve it based on real-world feedback and data, you know.. learn something and make it attractive to more and more customers
Whether it’s a SaaS app, internal tool, or platform engineering service, MVP is just the beginning. An MVP isn’t just about building—it’s about learning. You’re not delivering a finished masterpiece; you’re setting the stage for continuous improvement.
But here’s the reality: MVPs often get shipped and immediately abandoned. Why? Because by the time it’s done, everyone’s already been sucked into “the next big thing.” Maintenance? Iteration? Next version? Nah, let’s just slap an “Operations” budget on it and move on. See you in five years when everything’s broken!
Platform Engineering and the Rise of the TVP
In Platform Engineering, we’ve started using a new term: TVP—Thinnest Viable Platform.
As Team Topologies puts it:
— “We’re aiming to build what we call a thinnest viable platform (TVP). This TVP could be just a wiki page if that’s all you need for your platform.”
Or, as the Platforms whitepaper by the CNCF describes:
— “A TVP is a careful balance between keeping the platform small and ensuring that the platform is helping to accelerate and simplify software delivery for teams building on the platform.”
It’s a brilliant concept. Protect it with your life.
Because let’s be honest: it’s only a matter of time before the buzzword brigade gets their hands on it. Can’t you already hear it?
- “Let’s deliver the TVP, but make it scalable for the next decade and compliant with all regulations.”
Sure. And while we’re at it, let’s make it “future-proof”, powered by AI and somehow “zero trust” in the first iteration…
The truth is, a TVP—like an MVP—requires focus. Start small, solve real problems, and iterate. Let the value-add be small increments and let the complixity develop organically. If you don’t know what your users need, you’re just building another API monster no one asked for.
Conclusion: Redefine MVP
An MVP isn’t the end—it’s the beginning. It’s not about perfection; it’s about learning and improving.
Before you throw the term around, take a moment to ask:
- What problem are we solving?
- Who defines “viable”?
- How will we iterate and improve it?
If you can answer those questions, you’re off to a great start. If not, well… good luck with your “perfect MVP”, you’ll probably end up in more than one “alignment meeting.” before you’re finished.