The first two lines describe symptoms. The third line is the diagnosis. And it is the hardest of the three — not because it is complicated, but because genuine clarity of purpose requires something that most planning processes are not designed to produce: an honest answer to the question of what you are choosing not to do.

Defining value means making trade-offs. It means naming the stakeholders you are serving and, implicitly, the ones you are not prioritizing in this particular effort. It means committing to an outcome specific enough that you would know, without ambiguity, when you had achieved it — and when you had not.

That level of specificity is uncomfortable. It closes options. It makes the work easier to evaluate, which means it makes the work easier to criticize. It transforms "we are pursuing digital transformation" into "we are solving this specific problem for these specific people, and here is what resolution looks like." The second version is accountable in a way the first is not.

WHAT CLARITY ACTUALLY REQUIRES - In my classroom, I watch students struggle with this more than with anything else in the project cycle. The technical work is hard, but it is learnable. The process discipline is unfamiliar, but it is teachable. The willingness to commit to a specific, bounded, testable purpose — and to hold that purpose steady when the work gets complicated — is the capability that separates the groups that finish well from the ones that finish lost.

I do not think this is a student problem. I think it is a human problem, and organizations reflect it at scale.

It shows up in AI investments that begin with "we need to leverage AI" rather than "we need to make this specific decision better." It shows up in architecture engagements that produce comprehensive models because nobody agreed on which three concerns actually needed resolving. It shows up in workforce restructuring decisions made on anticipated returns rather than diagnosed constraints — because naming the constraint would require admitting uncertainty about the strategy.

In each case, the vagueness is not accidental. It is protective. Vague purpose is harder to hold accountable. Broad mandates feel safer than specific commitments. And the cost of that protection accumulates quietly, in exactly the same way I described in Episode 1 — until the rework cycle arrives, or the pilot is quietly wound down, or the project is redesigned after consuming the resources that were meant to deliver it.

CLARITY IS NOT A PLANNING STEP - This is the point I want to land on, because I think it is frequently misunderstood in practice.

Clarity of purpose is not something you achieve during the planning phase and then carry into execution. It is not a box to check before the project begins. It is an ongoing discipline — the willingness to return, at each stage of the work, to the original concern and ask honestly: are we still addressing it, or have we drifted?

The Fit-for-Purpose concept frames this through the Stakeholder Value Test: does this output provide clarity for a strategic decision, or does it simplify a workflow for an operational stakeholder? If the answer to both questions is no, the output is overhead — regardless of how much effort went into it.

MVP frames it through the measurement question: are we measuring against the original concern, or against the previous iteration? Progress relative to yesterday is not the same as progress toward the goal.

Both tests require the same prior condition: a purpose that is specific enough to test against. Not a direction. Not a vision statement. A named concern, a named stakeholder, and a named resolution.

That is the work that most teams skip. Not because they do not understand its value, but because it is genuinely difficult — and because the pressure to begin building is always easier to feel than the pressure to be clear before you do.