You’re two weeks from finishing a milestone. The team has a rhythm. The next milestone is scoped, the tickets exist, and the order is settled: Feature A first, then Feature B. Everyone knows what’s coming.
Then someone demos the product to a customer, and the order turns out to be wrong.
What the feedback looks like
It’s rarely dramatic. It’s a comment on a sales call, a question from a prospect that nobody has a good answer to, or a demo where the audience spends the whole time on a screen you considered secondary.
Say you planned to build the reporting module next and the self-service portal after it. Internally that order made sense: reporting was already in motion, the designs were ready, the team had momentum. But in demo after demo the prospects kept asking about the self-service side. They wanted to see what their own users would touch, not the admin views. Reporting mattered, but the portal was the thing that would close deals.
So the neat sequential plan needs to become parallel, or B needs to jump ahead of A entirely.
Why it’s harder than it looks
Changing priorities on a whiteboard takes a minute. Changing them in the team channel is a different thing.
Engineers don’t push back on this because they’re inflexible. They push back because they’ve already invested in the current plan. They’ve thought through the implementation, argued about tradeoffs, maybe started some groundwork. When you say “we’re reprioritizing”, what lands is “the thing you were preparing for matters less than we told you it did”.
Handle that badly and you lose something more expensive than a week of velocity. The next time you share a roadmap, people will mentally add “until the next demo” to every line on it.
Making the change without losing the team
A few things that have worked for me.
Share the signal, not just the decision. Don’t open with “we’re reprioritizing”. Open with what you learned. What did the prospect say? Which question couldn’t sales answer? When the team can see the input, the decision stops looking arbitrary and starts looking like the obvious response to new information, which is what it is.
Say plainly that it’s disruptive. The worst option is to pretend it’s a small change. If there was a plan and you’re changing it mid-stride, say that. “I know this shifts what we agreed, and I’m not going to pretend it doesn’t.” People deal with change fine. What they don’t deal with is a manager acting like nothing happened.
Be specific about what gives. “We’ll do both in parallel” sounds like a decision, and usually it’s the absence of one. If you’re pulling something forward, something else moves back, shrinks, or gets cut. Parallel work with the same people and the same deadline is a polite way of announcing crunch. Name the thing that gives.
Protect the work that just shipped. The milestone the team finished still matters, and if you don’t say so out loud, the change can feel like it retroactively devalued it. Connect the two: “The reporting work is why these prospects are talking to us at all. Now we need to finish the picture.”
The underlying problem is the feedback loop
A demo that reshuffles the roadmap isn’t planning failing. It’s the feedback loop working, just late. The real issue is when the only time you hear about customer priorities is a quarterly demo or a late-stage sales call, because then you’re planning in the dark for months at a stretch.
What helps:
Show rough work to sales before it’s polished. The instinct is to wait until something is demo-ready. But the go-to-market team talks to customers every week, and a five-minute walkthrough of a half-done screen can surface a mismatch before it costs you a sprint.
Get an engineering gut check before a concept reaches a customer. If product or design shows a prospect something without asking whether it’s realistic, you risk selling a six-month feature as a six-week one. Sales promises, engineering scrambles, and trust erodes in both directions. A quick “is this doable on our timeline” before the demo saves a lot of pain after it.
Limit the number of active threads. If you respond to every piece of feedback by opening another workstream, you end up with a team spread across four things, none of them moving. One primary focus, one secondary, and an honest “not now” for the rest.
The test
A healthy roadmap isn’t one that never changes. It’s one where, when it does change, the team understands why, agrees the new order makes sense, and believes the work they already did wasn’t wasted.
If you’re reshuffling every few weeks, the demos aren’t the problem. The distance between your planning and your customers is. Close that, and the shuffles get smaller, earlier, and less painful.