What to Do When Your Roadmap Gets Thrown Out Mid-Quarter
If you’ve been a product manager for more than a year, this has probably happened to you already. You spent weeks building a quarterly roadmap. You got it signed off. You presented it to the team, maybe even to the wider company. And then, six weeks in, leadership comes back and says priorities have changed — and half of what you planned needs to go.
It stings. There’s no way around that. But a roadmap thrown out mid-quarter isn’t actually rare, and the PMs who handle it well aren’t the ones who avoid it — they’re the ones who’ve built a process for dealing with it when it happens.
Why roadmaps get scrapped mid-quarter
Roadmaps get thrown out for reasons that are rarely about the roadmap itself. A competitor ships something that changes the market conversation. A big customer threatens to churn unless a specific feature gets fast-tracked. The company misses a revenue target, and leadership decides the whole portfolio needs to shift toward monetization. Sometimes it’s even simpler — a new VP joins and wants to put their stamp on the direction.
None of these things are predictable when you’re building the roadmap in the first place, and that’s the point. A roadmap is a snapshot of the best plan given what you knew at the time. The world doesn’t hold still just because you published a quarterly plan.
It’s common for PMs early in their career to take a scrapped roadmap personally — to read it as evidence of bad planning. Mostly, it means the business changed faster than the planning cycle did. Once that distinction is internalized, the whole situation gets a lot less stressful.
There’s also a pattern worth noticing: the closer a company is to a major milestone — a funding round, a renewal-heavy quarter, a board meeting — the more likely the roadmap is to move. Not because those events cause problems, but because they create moments where leadership is forced to look hard at the numbers and ask, “Is what we’re building actually going to move this?” If the honest answer is “not fast enough,” something gets reshuffled. Mapping a company’s calendar of these moments tends to reveal that “surprise” resets often aren’t all that surprising in hindsight — they cluster around predictable points.
First moves when your roadmap is thrown out mid-quarter happen to you
The instinct a lot of PMs have is to immediately start reshuffling tickets in Jira. Resist that for at least a day. The first thing you actually need is clarity on why the roadmap is changing, because that shapes everything else.
Get time with whoever delivered the news — your manager, a VP, whoever it was — and ask direct questions. What’s driving this? Is it a hard deadline or a soft preference? Does the new priority replace everything, or just reorder it? Is there a number attached (a specific deal size, a specific competitor feature, a specific date)?
You’re looking for the actual constraint, not the headline. “We need to focus on enterprise” is a headline. “We’re at risk of losing a $400K renewal unless we ship SSO by August” is a constraint you can plan around.
It also helps to ask what triggered the urgency now, specifically. Sometimes a “new” priority has actually been a slow-building concern for weeks, and the roadmap reset is just the moment it finally got loud enough to act on. Knowing that changes how you plan — if this has been simmering for a while, there might be more flexibility on exact timing than the framing suggests, because the urgency is more about finally addressing something than about a hard external deadline. On the other hand, if something genuinely changed this week — a deal, an outage, a competitor announcement — the timeline is probably as tight as it sounds.
Once you have that, do a quick gut-check on your current roadmap. What’s already in flight that can’t be stopped without wasting sunk cost? What hasn’t started yet and can be cut cleanly? What’s halfway done and would need a decision either way?
How to reprioritize without losing team trust
Here’s where a lot of roadmap resets go wrong — not in the planning, but in how the team finds out. If engineers hear about the change secondhand, or if it feels like the third reset this year, trust erodes fast, and that’s much harder to rebuild than a roadmap — the same dynamic that shows up in using OKRs without losing your team’s trust: the mechanism matters less than whether people feel like they were leveled with.
Be upfront about what changed and why, even if the “why” is a little uncomfortable. Teams can handle “the business needs changed and here’s the new priority” much better than they can handle silence followed by a sudden pivot. If you don’t know all the details yet, say that too — “here’s what I know, here’s what I’m still finding out” is a perfectly fine thing to tell a team.
Then get specific fast. Vague statements like “we’re shifting focus to enterprise this quarter” leave engineers guessing about what happens to the three things they were already half done with. Walk through the in-flight work item by item. Some things you’ll keep, some you’ll pause, some you’ll outright cut. Naming each one explicitly — even if the answer is just “we’re parking this” — removes a lot of the anxiety that builds up around a reset.
Don’t pretend the new roadmap is “even better” than the old one if it isn’t. Sometimes a reprioritization really is a downgrade in terms of what the team gets to ship this quarter, and pretending otherwise just reads as spin. It’s fine to acknowledge that this isn’t the quarter anyone planned for.
It’s worth saying something about morale here, too, because resets hit people differently depending on how attached they were to what got cut. If a designer spent three weeks on mockups for Feature B and it just got axed, “we’re pivoting to a great new opportunity” isn’t going to land — not because the new opportunity isn’t great, but because it doesn’t acknowledge that their work just got shelved. A short, direct acknowledgment — “I know this means the work you did on B isn’t shipping this quarter, and that’s a real loss, even if the decision makes sense” — tends to go further than any amount of reframing. People can handle disappointing news. What’s harder to handle is feeling like the disappointment wasn’t even noticed.
Talking to stakeholders about the roadmap thrown out mid-quarter
While you’re managing the internal side, you also need to manage outward — the stakeholders who were promised things on the old roadmap. Sales might have told a prospect a feature was “coming this quarter.” Customer success might have set expectations with an account based on the old plan. Marketing might have a launch planned around something that’s now been cut. This is the same dynamic covered in the hidden cost of saying yes to every stakeholder request — commitments made under the old roadmap don’t disappear just because the roadmap changed.
This is where being proactive saves a lot of pain later. Don’t wait for these stakeholders to notice the roadmap changed on their own — that’s how you end up with an angry account exec finding out a promised feature got cut three days before a renewal call.
A short, direct message works better than a long explanation. Something like: “Quick heads up — due to [reason], we’ve had to reprioritize this quarter’s roadmap. [Feature X] is now planned for [new timeframe / TBD]. Let me know if this affects any active conversations so we can figure out next steps together.” That last part matters — you’re not just delivering bad news, you’re offering to help solve the problem it creates. Lenny’s Newsletter has covered this exact pattern in practitioner write-ups on communicating a strategy shift: the messages that land well name the change plainly and immediately pivot to what happens next, rather than spending three paragraphs justifying the decision.
It’s worth thinking about timing here too. If a renewal call is coming up in two weeks and the feature that call depended on just got cut, that conversation needs to happen now, not whenever it’s convenient. The cost of an awkward “this isn’t happening anymore” conversation goes up the closer it gets to the moment someone was counting on it — both because there’s less time to adjust the plan on their end, and because it starts to look like the change was known about and not communicated, even when that’s not what happened.
Rebuilding a leaner roadmap for the rest of the quarter
Once the dust settles, you’re left with whatever time remains in the quarter and a new set of priorities. Don’t try to cram the old roadmap and the new priority into the same timeframe — that’s how teams end up overcommitted and burned out, and it usually ends with both the old and new priorities slipping. The same instinct that helps with prioritizing when everything feels urgent applies here: a full quarter’s worth of scope can’t be protected after losing real weeks to a pivot, so don’t plan as if it can.
Be realistic about capacity. If three weeks of the quarter just got eaten by a pivot — the planning meetings, the re-scoping, the context switching — there isn’t actually a full quarter of work time left. Adjust the scope of the new priority accordingly, even if that means delivering a smaller version of it than leadership originally asked for.
This is also a good moment to write down what happened, briefly, somewhere a future self (or the next PM) can find it. Not a blame document — just a record of “here’s what changed, here’s why, here’s what we deprioritized and when we plan to revisit it.” Six months from now, when someone asks, “Wait, what happened to that feature we were supposed to get in Q2?” that record turns into an actual answer instead of a shrug.
Mid-Quarter Reset Triage
| Workstream | Status Before Reset | Decision (Keep / Cut / Defer) | Owner Notified |
|---|---|---|---|
| Feature A (in progress, 60% done) | On track for original deadline | Keep — too costly to abandon | Eng lead, design |
| Feature B (not started) | Planned for next sprint | Cut — replaced by new priority | Eng lead |
| Feature C (in progress, 20% done) | Early stage | Defer — revisit next quarter | Eng lead, marketing |
| New priority (SSO) | Not on original roadmap | Add — scoped to MVP only | Eng lead, sales, CS |
Protecting yourself from the next reset
You can’t prevent the next mid-quarter reset — that’s not really the goal, and chasing it usually means over-engineering the planning process in ways that slow everyone down without actually making the roadmap more stable. Atlassian’s Agile Coach material on roadmap thrashing makes a similar point: a roadmap that’s updated too rarely goes stale, but one micromanaged into constant flux stops giving the team any real context at all. The goal is a roadmap resilient enough to absorb a reset without everyone losing the plot. But there are a few habits that make the next one less disruptive, even if they don’t stop it from happening.
One is keeping roadmap commitments slightly looser than they feel like they should be. If a quarterly roadmap reads as a list of guaranteed deliverables with hard dates, every item on it is a promise that a reset breaks. If it reads more like “here’s what we’re focused on and roughly when we expect to get there, based on what we know now,” a reset becomes an update to an existing plan rather than the breaking of a commitment. This isn’t about being vague to avoid accountability — it’s about setting expectations that match how planning actually works.
Another is keeping a running list, informally, of what’s “almost ready to go” versus “still needs significant work.” When a reset happens, and leadership wants something new prioritized fast, having a sense of what could realistically be picked up versus what would need weeks of groundwork first makes for a much more useful answer than “let me get back to you.” That same instinct — knowing your numbers cold before you’re asked — is exactly what makes a strong pitch to leadership land instead of stall. It also means that pushing back on an unrealistic timeline happens with specifics rather than a general sense that things feel rushed.
A roadmap thrown out mid-quarter feels like a crisis in the moment, but it’s also just… part of the job. The plan was never the point — it was always a tool for aligning a team around the best available information. When the information changes, the plan should too. The PMs who handle this well aren’t the ones with roadmaps that never change. They’re the ones who can change the roadmap without the team falling apart around them.
References
- Reforge — resources on planning and roadmapping under uncertainty
- Atlassian Agile Coach — reprioritization and roadmap-thrashing guidance for product teams
- Lenny’s Newsletter — practitioner writing on communicating a strategy shift to your team
