When the Roadmap Changes Mid-Quarter

Every quarter starts with a plan that felt solid. Six weeks in, something changes. A competitor ships the thing you were building. A large customer churns over a problem you hadn’t prioritised. Engineering surfaces a constraint that makes the next item on the list twice as expensive as estimated.

The decision to reprioritise is usually straightforward. What’s hard is everything after it.

The cascade you can’t see

When your roadmap lives as a ranked list, reprioritisation looks clean. You move something up, you move something down. Simple.

What you can’t see is that the thing you moved up depends on something that now gets pushed. And that dependency has two things downstream of it. And one of those things was promised to a stakeholder last month.

In a flat list, every item looks independent. Dependencies are invisible until they’re already broken — usually discovered in a planning meeting when someone points out that the new top priority can’t actually start until something else is finished.

The cascade isn’t a planning failure. It’s a visibility failure. You made a reasonable decision with incomplete information because the list didn’t show you what was connected to what.

Re-planning when you can see the graph

On a canvas, the dependencies are edges. When you move a card, you can see what’s attached to it. The decision becomes concrete instead of abstract: pulling this forward means these three things get displaced. You’re not reconstructing the dependency graph in your head — it’s visible.

This changes the nature of the conversation. Instead of “we’re reprioritising feature X,” the discussion becomes “here’s what moves if we pull feature X forward, and here’s what we’re choosing to defer.” Those are different conversations. The second one is harder, but it’s the one that actually needs to happen.

The other thing a canvas shows: what’s already in progress. Partially-built work has a different cost to defer than work that hasn’t started. When status is visible on the canvas — not buried in a filter somewhere — you can see the in-flight work before you make the call.

The conversation that has to happen

Re-planning isn’t just a canvas operation. Someone committed to the old plan. Stakeholders expected specific things. Engineers may have started work on something that’s about to shift.

The instinct is to update the plan quietly and move on. This almost always creates more problems than it solves. The people who were working from the old plan don’t know it’s changed. The stakeholders who expected a delivery find out in a review meeting instead of a conversation.

A shared canvas helps here because the change is visible to everyone who has access, not just the PM who made the edit. The card moved. The edge to the dependent task is now pulling on something different. Anyone looking at the project can see the current state of the plan — not the version from the kickoff deck.

That visibility doesn’t replace the conversation. But it means the conversation starts from a shared picture of reality instead of competing interpretations of what the plan said.

What to do with the docs that are now wrong

When a priority shifts, the specs attached to affected cards are often no longer accurate. A feature that’s been descoped needs a note on why. A card that’s been pushed to next quarter shouldn’t carry a due date that passed. A document that described an approach you’ve now abandoned shouldn’t look identical to a document that’s still current.

The version history does part of this automatically — every time you publish a revision, a snapshot is saved. The decision to cut or defer something can live in the document as a published update, not in someone’s memory of a Slack conversation. Six months later, when the feature comes back up, the reasoning for why it was deferred is there.

Partially-built work is the harder case. The card exists, some of the spec is still valid, but the scope changed mid-build. A short note in the document — what was done, what was cut, what assumption changed — takes five minutes and saves hours of archaeology later.

The quarter doesn’t care about your plan

Mid-quarter reprioritisation isn’t a sign that the planning process failed. It’s a sign that the team is responding to reality instead of defending a document.

The question is whether you can do it without losing the thread. Who knows what changed? What’s still valid? What moved, and why?

A plan that’s still legible after a pivot — where the canvas reflects the current state, the docs travel with the cards, and the reasoning for the change is recorded somewhere — is a plan you can actually work from. The alternative is spending the back half of the quarter explaining what happened to the front half.

That conversation is worse than the pivot itself.