Shortest path to value is Meaghan Waters’ name for a legacy-replacement roadmap that delivers useful portions of capability while limiting disruption to the work already being done. It is a sequencing proposal introduced in a pair of 2021 articles, not an optimisation method and not an established industry category.
Spell the term out. In financial services the abbreviation already means special purpose vehicle, which is the dominant reading in exactly the sectors where legacy replacement gets discussed.
What it sequences
The approach starts from the work rather than the software. Establish the current workflow, the recipient group or process boundary being addressed, what continuity that group requires, and what evidence would count as acceptance. Then select a slice that can carry real work end to end, including the tasks that leave the new system and come back later.
The slicing itself has three named patterns — segmenting by end user, segmenting by process step, and running a competitive system alongside the incumbent. Each cuts the problem on a different axis, and each leaves a different set of dependencies dangling.
What must not be assumed is that approval to replace validates every proposed change. A decision to retire a system authorises the retirement. It does not establish that any particular new capability attached to the replacement is wanted.
The question it answers, and the one it does not
An MVP framing and a shortest-path framing inform different decisions, and this is the whole of the distinction.
An MVP framing asks whether or how to pursue a product or feature hypothesis. What it needs made explicit is the hypothesis, the audience, the observations that would settle it, and the decision that follows. What invalidates the framing is discovering that no result could change the decision — at which point the release is not an experiment, whatever its size.
A shortest-path framing asks how to deliver a useful replacement slice. What it needs made explicit is the existing work, the selected scope, the continuity requirement, and the acceptance evidence. What invalidates it is a slice that cannot support the work assigned to it.
The two coexist. One programme can hold a settled requirement and an open hypothesis at the same time: a loan-origination replacement can have an established need to preserve intake, sequenced as a slice, while separately testing whether automated summarisation helps anyone. Treating those as the same question produces either an experiment nobody can opt out of or a rollout nobody validated.
The evidence already in the building
The incumbent system and the workarounds around it are evidence about requirements. Waters’ argument is to learn from them: the exceptions people handle by hand, the spreadsheet beside the terminal, the steps everyone skips. That record answers questions a discovery exercise would otherwise pay to re-answer.
Prior operation does not validate the replacement. Four things stay separate: workflow evidence that is known, behaviour that is undocumented, requirements that have changed, and capabilities that have never been tested. The first shortens the work. The last three do not, and using the first as cover for the last three is where the sequencing argument gets abused. An existing mortgage workflow demonstrates that staff review documents. It establishes nothing about whether a generated summary improves that review.
The rule
What stays fixed is that sequencing and hypothesis-testing answer different questions. What changes is which parts of a given programme fall under each, and that allocation has to be made explicitly, scope by scope, rather than inherited from whichever word the project charter used.
Where it fails
Reduced disruption is the goal, not a property of the name. The label states an intention. Whether the chosen slice actually held continuity is an observation, and it requires the incumbent to be watched on representative work before pass criteria are set. A slice can be selected for minimal disruption and still strand the downstream team that receives its output.
A slice that is useful to the builder and not to the user. Intake looks independently releasable from the delivery side. Whether it is depends on what downstream staff need from it, which is a question about the next desk along, not about the module boundary.
Not to be confused with
A guarantee of continuous value. No claim about uninterrupted delivery follows from the framing.
A rule that all incumbent behaviour must survive. Broken and unwanted behaviour is recorded separately from necessary outcomes. Retiring an unused screen is judged by its consequences, not counted automatically as lost ground.