Imagining the best possible thing
How “minimum” became the goal, and what it’s costing us
The MVP, or minimum viable product, has become a default move in product development. It’s taught as a best practice in Agile and praised for speed. It’s often treated as the safest way to find product market fit.
Conceptually, it makes sense. From dorm room startups to global companies, everyone feels the same pressure. Move fast. Learn quickly. Reduce risk.
But there’s a harder question underneath all of this.
Do customers actually want a minimally viable product?
And if every team follows the same MVP playbook, how does anything stand out?
How “minimum” became the goal
There’s a common misunderstanding about what MVP really means. Eric Ries originally described it as a way to collect the maximum amount of validated learning with the least effort. The goal was insight, not austerity.
An MVP was meant to be a learning loop, not a single release defined by how little could be done.
That distinction often gets lost.
Many teams say they’re Agile, but still operate with waterfall expectations. Executives want roadmaps. Stakeholders want firm timelines. Designs need approval. Specifications need to be finalized. Under those conditions, MVPs often turn into rigid, one-time releases. Something ships, learning is shallow, and the product struggles to earn attention.
Speed alone does not create differentiation. In fact, when speed becomes the primary goal, it often produces sameness.
I’ve written before about pitching yourself as a designer, and one of the most reliable ways to stand out is to over-deliver. The same principle applies to product and design teams. Strong products do not aim for the minimum. They show care, craft, and intent. They imagine the best possible thing they could make, not just the fastest thing they can ship.
This does not mean ignoring constraints. Time, budget, and scope still matter. Most teams cannot afford perfection, and they should not try. But within the same constraints, there is still a choice. You can ask, “What’s the minimum we can release?” or you can ask, “What could we make right now that customers would love ten times more than the alternatives?”
Not bigger in scope. Not slower. Just more intentional.
This idea shows up clearly in companies where design is treated as a strategic function, not a service layer. In fintech especially, teams that embed design deeply tend to build more resilient products. Ben Blumenrose, co-founder of Designer Fund, describes this in his essay on embedding design into the fiber of fintech. When design is valued, outcomes change.
What it’s costing us
The cost of getting this wrong is rising.
AI is making it easier to ship functional products. Funding tightening is making it harder to justify weak ones. When building gets cheaper and capital gets scarcer, expectations rise. “Good enough” stops being good enough.
In that environment, “viable” is not a differentiator. If many teams can ship quickly, the question shifts from “does it work?” to “why should anyone care?”
This tension is especially visible inside large organizations. Maria Guidice has spoken about how often teams only realize something is wrong when it’s already too late. Culture does not correct itself. Without leadership support, teams optimize for safety instead of impact.
Constraints still matter. Speed still matters. The difference is how those constraints are used. Teams can optimize only for learning, or they can use the same limits to create something customers actually care about.
When everyone can build faster, what you choose to care about matters more.
Imagining the best possible thing does not mean chasing perfection. It means being deliberate about focus, taste, and impact. It means using constraints to sharpen the work, not lower the bar.
That mindset is not indulgent. It’s strategic. And in a world full of fast, forgettable products, it may be the only real advantage left.
If this resonates, I’m curious how you’re navigating these tradeoffs on your team? Let’s compare notes.