If you’ve worked in Agile for more than five minutes, you’ve probably said it, built it, or been burned by it.
It’s supposed to help us move fast and learn faster.
But in practice? Most MVPs either flop, get ignored, or turn into awkward, half-baked features that no one asked for.
As a product guy who's worked closely with Agile teams, I’ve seen many MVP traps. So here’s my take on why they often fail—and what I’ve learned to do differently.
We try to make it small enough to fit into a sprint... but forget to make it actually useful.
Just shipping something isn’t the goal.
An MVP should test something specific—a behavior, a need, a risky assumption.
But too often, it’s just a trimmed-down version of a feature we were already planning to build.
We launch it. We move on. It quietly dies in Jira.
No follow-up. No learning. And definitely no iteration.
Agile isn’t just “go fast”—it’s supposed to be learn fast.
Sound familiar? Been there? Yeah, same.
Some of our best sprint outcomes aren’t features—they’re answers.
We run:
Clickable prototypes
20-min customer chats
All of that is Agile—just not always in Jira.
If we’re building something, I want it to feel real.
Not perfect—but polished enough that users “get it” and care enough to react.
MAP = Minimum Awesome Product (yep, stealing that one proudly)
If we ship something to test a hunch, we talk about it.
What did we learn? What did we miss? Do we still believe in this idea?
If MVPs aren’t part of the feedback loop, they’re just another ticket.
I’m not against MVPs—I’m just tired of seeing them misused.
When we treat them as a learning tool instead of a shipping hack, they work beautifully in Agile.
Speed is good—but speed without insight is just motion.
Would love to hear your take.
How do you approach MVPs on your team? Have you moved past them—or found a better way?
Let’s chat 👇
Rishabh Jhawar
Senior Product Manager
Beyond Key
India
16 accepted answers
0 comments