A stakeholder keeps changing their mind and I can't lock the scope.

What to do when the scope keeps moving and you cannot lock it

Reston, Virginia, two thousand and six. Inside Backfence — an early hyper-local citizen-journalism platform — the founders are running the conversation that will, over the next year, decide the company's fate.

The product is good. The concept makes sense. Neighbourhoods can publish their own news. Residents contribute stories about local events, schools, zoning disputes, the things that never make it into regional papers. The early communities are vibrant. The press is warm.

The problem is scope.

The founders and their stakeholders keep expanding the geographical coverage. More neighbourhoods. More cities. More regions. Each expansion adds dilution to the team's capacity. Each new city is a new community that has to be seeded, populated, and supported through the cold-start phase before it can sustain itself.

The resources get spread thin across dozens of places, none of which reach the critical mass required for the platform to sustain itself. The hyper-local thesis — the value lives in being deeply present in a small number of communities — keeps getting violated by a scope decision that flattens the depth across more and more places.

By the time the founders realise that the only way to make hyper-local work is to actually go hyper-local — to dominate a small number of communities first rather than spread thin across many — the capital is gone. The company shuts down in two thousand and seven.

It is a case where the thing that killed the business wasn't any single bad decision. It was the absence of a decision to stop adding places. Each individual expansion looked reasonable in isolation. The accumulation broke the company.

When a stakeholder keeps changing their mind and you can't lock the scope, the question is rarely whether each individual change is justified. Most are. The question is whether the accumulation of justified changes is destroying the thesis the project is supposed to test.

So let's go to the office and work through it.

Start by asking whether the stakeholder is learning or avoiding

"A stakeholder keeps changing their mind and I can't lock the scope."

The feeling is exhausted.

Each individual change is small. Each is defensible. Each, on its own, would be absorbed without much difficulty. The aggregate is a project whose shape has shifted four times since you started, and the team's capacity to hold the thesis steady against the changes has been fully consumed by holding the thesis steady against the changes.

Two choices. They look like the same scope problem. The first move is different.

When the changes track real new information

Choice one: the stakeholder is genuinely learning things that justify the changes. The market is moving. They are getting real information from real sources. The changes are responses to something that has actually happened, and the changes are intelligent.

If that's the read, stop treating the changes as disruption and start treating them as expected work. Explicitly budget twenty per cent of every sprint for learning-driven variations, and tell the stakeholder that's what you've done.

Mary and Tom Poppendieck, working on lean software development through the two-thousands, are clear that the change isn't the problem. Pretending the plan is stable when it isn't is the problem. Because the pretence forces every change to arrive as an emergency rather than as planned absorption. Once the variance is budgeted, the relationship with the stakeholder shifts from adversarial — why are you disrupting us? — to collaborative — which of these variations do we run this sprint? The change still happens. The disruption stops.

When new ideas dodge the hard choice

Choice two: the stakeholder can't commit. The new ideas are a substitute for making the hard choice. Every new idea costs the team a day of rework. The stakeholder isn't learning; they're avoiding the discipline of choosing.

If that's the read, force them to rip up one requested feature before they're allowed to add a new one. Physically, if you can. Print the backlog on cards and make them pull one out of the board before they're allowed to put a new one in.

Jim Benson, working on Personal Kanban and work-in-progress limits, has been clear about this. The inability to commit is almost always a failure to feel the cost of not committing. Making the cost visible and tactile is usually all it takes to restore the commitment. They still change their mind. They just have to trade something each time they do.

Genuinely-learning, or can't-commit. Same scope drift. Two different first moves.

How to make the cost of scope drift visible

Three tools. The discipline is to make the scope problem visible to the stakeholder, not just to the team.

Show every pivot as unvalidated risk

The first is

Assumption Mapping.

Assumption Mapping was popularised by David Bland and the Strategyzer practice through the late twenty-tens, formalised in the Testing Business Ideas book — Bland and Osterwalder, two thousand and nineteen. The deeper lineage runs through the lean-startup tradition's value hypothesis and growth hypothesis writing of Steve Blank and Eric Ries, and earlier through the strategic-planning literature on critical assumptions that emerged from Royal Dutch Shell's scenario-planning practice we covered in scenario twenty-five.

The reason Assumption Mapping matters when a stakeholder keeps changing their mind is that each casual pivot is carrying substantial unvalidated risk that the stakeholder rarely sees. The map plots each new idea against two axes: how risky the underlying assumption is, and how certain you are about it. The chart shows, without argument, that the stakeholder's casual ideas sit in the high-risk-low-certainty quadrant — the place where the cost of being wrong is highest.

The unique insight is the visualisation forces the conversation. The stakeholder isn't being told their ideas are bad. The stakeholder is being shown, on a single page, that their ideas all sit in the same quadrant of the assumption-risk grid — and that the team has been absorbing the cost of high-risk assumptions without anyone validating them first.

What you get is a structural way to push back on the next change. Not we don't have time, which is opinion. This idea sits in the top-right quadrant alongside the last three changes that haven't been validated, which is structural.

So. How to run it.

List. Each pivot rests on assumptions about users, market, technology, or business model. List them out, one assumption per sticky note.

Plot. Two axes — risk on one, certainty on the other. Each assumption goes onto the grid.

Identify. High-risk assumptions you are not yet certain about. These are the ones that need testing before they get built.

Test. For each top-right assumption, design the cheapest test that would falsify it. The test runs before the next pivot is committed to engineering.

Re-plot. Tested assumptions move down the certainty axis. Untested ones stay where they are. The grid is a living artefact, not a one-off slide.

Set each change against the whole user journey

The second is

User Story Mapping.

User Story Mapping was developed by Jeff Patton through the late two-thousands and codified in his two thousand and fourteen book User Story Mapping: Discover the Whole Story, Build the Right Product. The framework draws on the user-journey tradition from service design and the backbone-and-walking-skeleton discipline from agile architecture, which we covered in scenario seventeen. The method is structural — a single horizontal map of the user's journey across the wall, with vertical slices showing the depth of work behind each step.

The reason User Story Mapping matters when a stakeholder keeps changing their mind is that changes that look small on a list look very different against a journey. A new feature on a backlog list is a row. The same new feature on a story map is a vertical line through the user's journey, and the line either fits cleanly or breaks the journey. Breaking a user journey is harder to approve when you can see what breaking it looks like.

The unique insight is the visualisation of the whole user journey. The stakeholder, presented with the wall-sized map, can see exactly where the proposed change would sit and what it would displace. The map turns abstract feature requests into concrete impact on a sequence the user has to be able to complete.

What you get is a structural conversation about scope. Not should we add this feature?, which is binary. Where in the user's journey does this sit, and which existing capability does it move?, which is structural.

So. How to draw it.

Backbone. The major steps of the user's journey, left to right. Sign up. Onboard. First action. Repeat. Invite teammate. Each step is a column.

Stories. Below each backbone step, the specific user stories that make that step work, ordered by priority top to bottom.

Release. Horizontal lines across the map indicating which stories ship in each release. The lines define what done means at each release point.

Test. When the stakeholder proposes a new feature, the question becomes: which column does it sit under, and what does it displace? If it adds a new column, what does the user do at that step today, and is the new column even the right place for the work?

The map is doing the conversation; the manager isn't.

Let a concrete example filter vague requests

The third is

Specification by Example.

Specification by Example was formalised by Gojko Adzic in his two thousand and eleven book Specification by Example: How Successful Teams Deliver the Right Software. The deeper lineage runs through Behaviour-Driven Development — Dan North, two thousand and six — and Test-Driven Development — Kent Beck, late nineteen-nineties. The discipline is structural — every requirement is written as a concrete, testable example of the desired behaviour, not as an abstract description.

The reason Specification by Example matters when a stakeholder keeps changing their mind is that vague ideas die at the specification stage; good ideas get sharper. Most stakeholder changes are casual until they have to be specified. When the team demands a concrete, testable example for each new request, half the requests are withdrawn because the stakeholder cannot produce one. The other half become genuinely useful work.

The unique insight is the concrete example as filter. I think we should add personalisation is not a specification. When user X with property Y arrives at page Z, they see content variant W instead of variant V is a specification. The first costs nothing to propose; the second forces the stakeholder to think through the change.

What you get is a structural defence against vague requests. The stakeholder either provides a specification, or the request waits. The team isn't refusing — the framework is.

So. How to use it.

Demand. For each new request, ask the stakeholder to describe a specific scenario in which the feature would behave. Given a user with X attributes, when they do Y, the system should respond with Z.

Refuse. We should add intelligence is not a specification. We should add a feature like Spotify is not a specification. Make it more flexible is not a specification.

Run. Engineering, design, and product all read the example. Disagreements about what the feature does surface immediately, not three sprints in.

Build. The acceptance criterion for the feature is that the example runs and produces the specified behaviour. The example is now part of the test suite, not documented elsewhere.

Reject. If the stakeholder cannot produce a concrete example, the change isn't a change yet. It is an idea, and the team is not committed to building ideas.

That's the toolkit. One more story before we close.

A precedent: reading scope changes as a signal, not an attack

The Backfence story we opened with showed a team that absorbed a stakeholder who couldn't stop adding places — until the absorption killed the company. The story we close with shows the inverse — an executive whose stakeholder kept changing the mandate, and who learned to read the changes as diagnostic rather than as disruption.

Mountain View, February two thousand and fourteen. Susan Wojcicki becomes CEO of YouTube. The platform's governing principle has been set at the Google acquisition in two thousand and six: YouTube is a distribution layer, and content decisions are creator decisions.

Over the following six years, the stakeholder Wojcicki reports to — Sundar Pichai, who becomes CEO of Google in August two thousand and fifteen and of Alphabet in December two thousand and nineteen — keeps reshaping what that principle is supposed to mean in practice.

Between two thousand and sixteen and two thousand and twenty, the regulatory, advertiser, and political environments around YouTube shift substantially. Alphabet's exposure to each shift runs through YouTube. The scope Wojcicki has been operating against keeps failing to hold.

The sharpest episode is the first week of June two thousand and nineteen. Conservative commentator Steven Crowder has posted repeated videos targeting Vox journalist Carlos Maza. YouTube's initial position — articulated publicly by Wojcicki and her communications team — is that the videos do not violate YouTube's harassment policies and that the platform's standards are being applied consistently. Inside the week, the position reverses. Pichai sends an internal email to Alphabet employees effectively apologising for the decision and signalling that the platform-neutrality posture Wojcicki has just defended is no longer what the stakeholder wants.

The Adpocalypse has produced the same pattern in two thousand and seventeen — advertiser boycotts forcing a rewrite of the Partner Program monetization thresholds, changing the scope under Wojcicki's feet. YouTube Shorts launches in September two thousand and twenty as Alphabet's short-form-video answer to TikTok, a competitive threat that had not been part of the two thousand and fourteen strategic plan at all.

When a stakeholder keeps changing their mind and you can't lock the scope, the default frustration is that the stakeholder is being inconsistent. Sometimes they are. More often, the stakeholder is responding to a changing environment that is visible to them but not yet to you — and the scope they gave you last quarter was the best they could lock when they gave it.

Wojcicki's response, across six years of shifting priorities, was to treat scope changes as diagnostic rather than adversarial. Each reshaping of the mandate told her something about what the environment had done to Alphabet's position. Fighting the change would have been fighting the environment, which is a different fight. The useful stance wasn't to hold her boss to his previous frame. It was to run YouTube inside the current scope, accept that the scope itself would keep moving, and let the fact of the change tell her what Alphabet was becoming.

So. Your Next Move from this playbook.

Does the next release you're shipping actually let a user complete a whole journey — or are you proudly delivering half a bridge?