Are You Iterating Toward the Right Destination?
Inside the Classroom (Episode 1)
When MVP meets an undefined concern — and why speed without prior diagnosis is not agility, but expensive guessing.
During a recent session with my students, we explored two concepts that sit at the heart of modern work: the Minimum Viable Product (MVP) and Fit-for-Purpose thinking.
I did not plan the lesson the way it unfolded. It grew out of something I was already watching: student groups grinding toward their Term Project deadlines. Every group started at the same time, with the same prompt. But by the final week, their projects had diverged sharply. One group was clearly on the right path. Another was "lost in the woods" — moving just as fast as everyone else, but increasingly uncertain about where they were headed.
That divergence is what I want to talk about. Because I have seen the same pattern in organizations far more often than I have seen it in classrooms.
THE TRAP MOST TEAMS DO NOT SEE COMING - The common trap is this: most teams reach for output before they have done the harder work of defining purpose. When we build fast toward an unclear goal, we are not practicing agility. We are moving efficiently toward the wrong destination. At its best, "move fast, refine later" thinking is an honest discipline. Build the smallest thing that tests a real assumption. Let reality correct your model before you invest further. That is genuinely useful — when the purpose is clear. But when purpose is still vague, the MVP loses its fixed point. Every iteration gets measured against the previous one. We see velocity in the data. We lose sight of value in any meaningful sense.
Speed is not the problem. The missing question is: speed toward what, exactly?
THE COST THAT ACCUMULATES QUIETLY - A failure in sequence rarely announces itself immediately. In the short term, a team looks healthy — shipping, adapting, staying active. But the cost builds in the background: Rework cycles appear when the output finally meets a stakeholder who needed something else entirely. Technical debt embeds itself into a product shaped by the wrong assumptions. And organizational energy drains away defending iterations that were never anchored to a justified outcome.
Real-world evidence makes this concrete. The MIT "State of AI in Business 2025" report found that 95% of Generative AI pilots failed to deliver any measurable financial impact. These were not technical failures — the models worked. They were disconnected pilots. Organizations raced to build capabilities without first diagnosing the specific business concern those capabilities were meant to solve.
Apple Vision Pro tells a similar story at a different scale. A technical marvel that struggled to find its footing because the market could not identify its essential daily value. It was a remarkable solution still searching for a clear, high-frequency problem.
The pattern is the same in both cases. The build preceded the diagnosis.
FROM REACTIVE TO DELIBERATE - The danger in misusing MVP is treating it as a substitute for defining the problem. If you are iterating to discover what the problem is, rather than to test a solution to a problem already defined, you are learning — but at a much higher cost than necessary. The cheapest form of learning is almost always available before the first line of code is written.
To move from reactive to deliberate, I ask my students — and myself — to work through these questions before the build begins:
- Which specific concern are we addressing? Name the stakeholders. Name the decision or pain point. Be precise enough that you would know when it had been resolved.
- What is the minimum that would address it? Not the fastest route — the one that resolves the concern without leaving ambiguity for the people who need to act on it.
- Is the investment proportionate to the value? Time, energy, opportunity cost. If the answer is unclear, the scope is not yet defined well enough to begin.
- Then, and only then: what is the smallest thing we can build to test whether we have addressed it? And as we build — did we resolve the original concern, or did we ship a polished version of a tool nobody needed?
CLOSING - An output that is technically excellent but disconnected from the concern it was meant to address is not a partial success. It is a complete miss, produced at full cost.
Raschada Nootjarat is an Enterprise Architect with a focus on AI strategy, architecture governance, and the intersection of human and machine systems in organizational transformation. She starts this website together with her "Fit-for-Purpose Enterprise Architecture" book in April, 2026.