Your quarterly roadmap. It was beautiful.
You spent weeks on it. You had prioritization discussions with stakeholders, collected estimates from the team, drew a cut line and packaged everything up in a VP-ready Gantt chart that was surely destined for the halls of management Valhalla.
But then, you got nailed with a roadmap torpedo. BOOM! Something blew up your roadmap. Roadmap torpedoes have many forms. Roll 1d4 for an example:
-
Priority torpedo: an urgent p0 appeared. MAUs are dropping! Pull Johnny off of whatever he’s in the middle of right now — oh it’s a p0 too? Well…he can do that later. This p0 is more important than that p0. Get him on this p0 now and tell him to go find us some more MAUs, preferably yesterday!
-
Requirements torpedo: your PM had a ‘great idea’ for turning the new onboarding flow into an AI powered chatbot with full-duplex voice mode. Scope increases 500%. Your PM thinks scope only increased 1%.
-
Resourcing torpedo: your tech-lead rage-quit and gave 24-hour notice. Your boss never read the copy of The Mythical Man Month you sent them for Christmas, and so they tried to help by hiring a contractor for you. You find out they start ‘tomorrow’.
-
Tech-debt torpedo: Oops! Turns out you actually can’t do that project until you upgrade 25 app dependencies. They’re all several major versions behind the ‘latest’.
Your beautiful roadmap is now a worthless pile of scrap that depicts a glorious future that will never come to pass.
What do you do now?
When you get hit with a roadmap torpedo, you usually need to: a) notify stakeholders (who often have no idea your roadmap just imploded) and b) clearly answer the following questions:
- Which projects are now off track, and by how much?
- What are you doing about it?
- What are the updated ETAs given #1 and #2?
- How confident are you in the new timeline?
A typical response
Which initiatives are off track, and by how much?
Something is now definitely off-track. But by how much — are you ‘yellow’ or ‘red’? What’s the difference? Who knows! ‘Yellow’ probably means ‘bad’ and red probably means ‘really bad’. You ask Johnny (your tech-lead). He asks his gut. His gut says ‘real bad’. You go with ‘red’.
What are you doing about it?
You need to come up with a ‘path back to green’. You have four levers to pull:
- Cut work from scope
- Re-prioritize work (change sequencing)
- Re-assign work
- (Maybe) add a new team member.
You ask your team a ton of questions in an attempt to build your ‘path’ — can we cut X? can we re-prioritize Y? can we re-assign Z? These are all valid questions.
But, answering them burns a ton of time.
Your team runs around trying to figure out how all the various combinations of changes would render certain projects on-track or off-track. This distracts them from actually shipping. But, you manage to find your path.
The next morning, your PM has another ‘great idea’. This time it’s game-ifying the profile screen with unlockable NFT achievements for ‘virality’. This is your team’s new p0. It now supersedes all other p0’s.
And so, the cycle repeats.
What are the updated ETAs given #1 and #2?
You take a look at the remaining Jira tickets and ask the team to conjure new estimates. They do so via vibes or velocity. You redraw your Gantt chart whilst frantically trying to grab those pesky drag handles.
Your chart is probably wrong. You know it. But you have to give stakeholders something. So you pad the timelines.
How confident are you in the new timeline?
You have no idea.
So, you ask Johnny (your most senior engineer). Johnny asks his gut. It says 85%. Great! You roll with the pseudorandom number that came out of Johnny’s gut. You send an email to stakeholders claiming you’re 85% confident in the new dates.
This is insanity
Roadmap torpedoes are a fact of life, especially in startups. The problem isn’t torpedoes, it’s that your roadmapping process can’t handle them.
Likely, this is because your business thinks it’s using ‘Agile’. But it’s not. It’s using a weird amalgamation of ‘mostly Waterfall’ + bolted on ‘Scrum meetings’. Let’s call this WetScrum.
WetScrum isn’t Agile. WetScrum roadmaps implode when hit by a torpedo because they’re static artifacts that require manual rebuilds on every significant change.
That’s insanity! Change happens all the time.
Roadmapping shouldn’t be a discrete process. It needs to be continuous. And it needs to be ‘fast’ and ‘cheap’ so your team can focus on what actually matters — shipping stuff.
So, what’s the solution?
You need to actually be Agile.
More specifically, you need to find a way to uphold the following two principles from the Agile manifesto:
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
And
Business people and developers must work together daily throughout the project.
Modern tools can help you do this via embedding these principles directly into their workflows.
But we still need roadmaps!
Yes, the business still needs roadmaps. But, what you need is an agile roadmap.
An agile roadmap:
-
Builds itself automatically — e.g. via simulating your team working through what’s currently in your backlog
-
Updates instantly when you cut, re-prioritize or re-reassign work — e.g. via re-forecasting in real-time.
-
Computes accurate confidence levels for your timelines and clearly visualizes them, so your stakeholders can make informed decisions — e.g. via a probabilistic forecast using Monte Carlo methods.
This isn’t fantasy. Empirical makes agile roadmaps a reality:
Ok, but what do I do about torpedoes?
When a torpedo is headed for your team, use this principle:
Business people and developers must work together daily throughout the project.
Sit down with your stakeholders. And work with them to deploy evasive maneuvers.
Empirical makes this easy via probabilistic forecasts that update instantly when things change. This enables you to work collaboratively with stakeholders in real-time to decide on the best path forward:
-
Priority torpedo: Drag that new P0 to the top of your sprint or backlog — watch the forecast update instantly to show you quantitatively how the timelines of your other projects are impacted.
-
Requirements torpedo: Grab your PM. Sit down with them. Show them just how far adding that ‘AI onboarding chatbot’ is going to push the timeline out for their other favorite project. Work with them in real time to reshuffle the backlog to best support customer needs.
-
Resourcing torpedo: Re-assign tickets and instantly see timelines update using historical per-developer cycle times. Brooks’ law still applies, but you might simulate adding a new team member if you’ve got a project that hasn’t started yet.
-
Tech-debt torpedo Add the new tickets to the backlog and prioritize them. Watch the forecasts update instantly. Got a staff engineer that’s really good at resolving dependency hell issues? Assign them and see how much it might help.
What about those stakeholder questions?
Empirical makes it easy to answer these too:
Which initiatives are off track? And by how much?
Empirical bakes the answer to this directly into its forecast visualizations:
What are you doing about it?
Pull the ‘management levers’ you have available — e.g. cut, re-prioritize or re-assign work in your task management tool. And watch your forecasts update instantly.
What are the updated ETAs given #1 and #2?
How confident are you about the new timeline?
To answer these questions, just look at the updated forecast:
Transform your roadmap from a static artifact to a dynamic decision-making tool
Roadmaps don’t have to be brittle artifacts you create once a quarter. With data-driven forecasting, your roadmap transforms into a dynamic command center that adapts to the inevitable chaos of software development.
When roadmap torpedoes hit, you need the ability to assess impact, simulate options, and communicate with confidence—all without burning valuable engineering time on manual recalculations and endless meetings.
Empirical gives engineering leaders like you the power to:
- Update forecasts instantly when priorities or resources change
- Provide stakeholders with accurate, confidence-based delivery timelines
- Turn roadmap chaos into a competitive advantage through rapid adaptation
Stop the painful cycle of guess-react-apologize. Start making data-driven decisions that keep your team shipping and your stakeholders informed.