For years, the IT world had a simple mantra: Move fast and break things. Today, we’ve replaced it with another one that sounds much more responsible: Just build an MVP. Somewhere along the way, “start small” stopped being one useful tool among many and became almost a moral principle. Suggest spending six months building something before showing it to users, and someone will inevitably remind you that “this isn’t very Lean.” It’s an interesting shift. The same people who insist that every product should be an MVP would probably think twice before boarding an aircraft whose navigation system was developed the same way.
The problem is not the idea of an MVP itself. Quite the opposite. Some of the best products I’ve worked on started exactly that way. We had a hypothesis, we knew we didn’t have all the answers, and the fastest way to learn was to put something useful in front of real users. They surprised us, challenged our assumptions, and often took the product in directions we hadn’t anticipated. That is exactly what an MVP is supposed to do.
But over time, many organizations quietly stopped asking why they were building an MVP. It became the default answer rather than a conscious decision. Every project, regardless of its nature, was expected to follow the same playbook. New recommendation engine? MVP. Internal workflow? MVP. Authentication platform? MVP. Core publishing infrastructure? Also MVP. At that point, we’ve stopped applying a methodology and started following an ideology.
The mistake is subtle but important. We tend to think that every project carries the same kind of uncertainty, when in reality they don’t. Sometimes the biggest unknown is whether users actually want what we’re building. Sometimes the real challenge is whether the technology will work reliably under real conditions, whether it can scale, whether it can survive failures, or whether it can be trusted at all. Those are fundamentally different problems, yet we often reach for exactly the same delivery approach.
Take something as simple as a new dashboard. If users don’t understand it or don’t find it useful, the consequences are relatively small. You learn something, improve it, and release another version. The cost of being wrong is low, while the value of learning quickly is extremely high. That is exactly the environment where iterative development shines. The product becomes better because people use it before it’s finished.
Now compare that with replacing your authentication system, your payment platform, or the infrastructure that allows journalists to publish safely in heavily censored countries. Here, a partially working solution doesn’t create partial value. It creates partial trust. And trust is remarkably difficult to recover once you’ve lost it. A bridge that reaches halfway across the river isn’t an MVP. It’s simply an unfinished bridge. Some systems become valuable only when they work as a complete system.
I think this is why experienced product leaders often sound more cautious than people early in their careers. It’s not because they’ve become less Agile or less innovative. They’ve simply learned that not every uncertainty should be exposed to customers. Sometimes the smartest iteration happens long before the first public release. Technical prototypes, architecture experiments, internal pilots, migration rehearsals, dark launches, and parallel systems. These are all forms of iteration as well. Users may not see them, but the organization is constantly learning.
There is also an irony that doesn’t get discussed often enough. The companies we admire for moving incredibly fast are frequently the same companies that spend years investing in things nobody outside the organization will ever notice. We see the new feature appear overnight and assume it was built overnight. What we don’t see are the years spent building internal platforms, deployment pipelines, observability, testing frameworks, migration tools, and engineering practices that make those rapid releases possible. To outsiders, it looks like speed. Inside the company, it often looks like patience.
Over the years, I’ve found that one question has become much more useful than asking whether something deserves an MVP. Instead, I ask what we’re actually trying to learn. If the biggest uncertainty is about people — their needs, habits, priorities, or willingness to adopt something — then expose the product early and learn from reality. But if the biggest uncertainty lies in technology, resilience, security, compliance, or trust, then exposing customers to that uncertainty may be exactly the wrong thing to do. Learn internally first.
Perhaps that’s the distinction we should be making more often. The goal is not to release everything as quickly as possible, nor is it to hide in development for years chasing perfection. The goal is to expose uncertainty to the right audience at the right moment. Users should help us discover whether we’re solving the right problem. Engineers should help us discover whether we’ve built the solution correctly. Mixing those two kinds of learning is where many expensive mistakes begin.
Maybe the real lesson is that there is no universally “Agile” way to build products. There is only a disciplined way to manage uncertainty. The best product organizations aren’t the ones that always ship first or always polish everything before launch. They’re the ones that know which risks can safely be explored in public. And which ones absolutely should not.