An MVP against a working baseline is a replacement released with less capability than the system it replaces, justified by minimum-viable-product framing, where the users required to adopt it can no longer complete work they previously completed. The diagnosis is the removed work. Small scope is not the fault, and a low feature count is not the symptom.
The mechanism
MVP framing selects the smallest build that will resolve an open question. It presumes the question is open and that participants can decline. A replacement inverts both conditions: the value hypothesis was settled by the decision to replace, and the users have no alternative once the incumbent is switched off.
What breaks is the disposal of work rather than the disposal of code. Every task the replacement does not carry has to go somewhere, and there are only three destinations. It stays on the legacy system, which means the legacy system is still running and still being paid for. It moves to a manual workaround, which transfers the cost to the people who were promised an improvement. Or it stops being done, which is a decision nobody recorded.
The diagnostic
Three questions separate this failure from a sound staged replacement, and all three are about arrangements rather than scope.
Has required work been removed? Not features — work. Identify the tasks the affected group performed before the release and check which of them still complete.
Is the parallel operation deliberate and funded? Running the incumbent alongside the replacement is the standard structure for a staged transition. Government beta guidance describes exactly that combination: limited initial use, feedback, and continuing legacy operation during replacement. Parallel running is a counterexample to the diagnosis when it is planned and paid for, and a symptom when it is discovered.
Does the release answer a stated question? If no result could change what happens next, the release is a rollout with an experimental label attached.
A bounded release that passes all three is not this failure, whatever its size. Inferring failure from the word MVP gets the diagnosis backwards.
Why the adoption numbers lie
Under mandate, usage counts measure compliance. Research on voluntary and mandatory workplace implementations found that social influence relates differently to usage intention depending on whether use is required, and the same work explicitly left the link between technology use and positive individual or organisational outcomes to further research. Logins are not outcomes, and under a mandate they are not even preferences.
The practical consequence is that a service desk can show complete adoption of a new tool while every member of the team maintains a separate queue to track the cases the tool drops. Both facts are true. Only one of them is in the report.
So successful work has to be defined independently of transaction counts: include failed attempts, work completed elsewhere, and assistance required. Recruit beyond the people who volunteered to pilot, and record who is missing from the sample relative to who is affected by deployment.
The rule
What stays fixed is that a captive user population converts every gap into someone’s unpaid workaround. What changes is the size of the gap and who absorbs it — and both are observable before release, from the incumbent, on representative work.
The remedy is acceptance defined around necessary outcomes and an explicit improvement, rather than feature-count equality. Government service guidance asks for a coherent whole user journey while explicitly permitting incremental delivery, which is the same position: the slice must be complete for the work it claims, not complete relative to the old system’s screen count.
Where the diagnosis is wrong
A retired capability that nobody used. Removing an unused legacy screen is evaluated by its consequences. Counting it as lost parity manufactures an objection out of an improvement.
A cohort that still has the old route. Where only a suitable group moves and other work remains supported, the same reduced feature set is not this failure. The measure is what happened to the users who were moved, not what the release contained.
Not to be confused with
Scope discipline. Deciding to build less is the correct instinct. This failure is about where the remainder went, and whether anyone agreed to carry it.
A rule that baselines forbid MVPs. A working incumbent does not mechanically invalidate MVP framing. It removes the assumption that participants can walk away, which changes what the release must preserve, not whether learning is permitted.