Keeping the Roadmap Alive
A review rhythm, honest triggers for change, the urgent request, and what this skill means for your career
Six weeks after the roadmap was published, a request arrives from the chief executive: add a new store-pickup option before the promotional peak. The analyst does not panic and does not refuse. She opens the roadmap, finds where the request would go, and brings the executive a one-page answer showing what it would cost and what it would move. The conversation takes ten minutes. Without the roadmap it would have taken a month. If you are joining us on day five, here is where we are. This week is five days on turning a long list of requirements into a roadmap, following one analyst at a regional online grocery retailer who started with 60 requirements for the customer app and the delivery operation and had to plan the next two quarters. Day one showed that a list is not a roadmap, because it cannot explain its order or its boundaries. Day two grouped 52 distinct requirements into five themes, each tied to a goal. Day three sequenced them by dependency, risk, learning, capacity and fixed dates. Day four turned the sequence into a Now, Next, Later page with a confidence level on each horizon and a stated way of saying no. Today we look at what keeps the roadmap honest once it is out in the world.
A review rhythm and agreed triggers
A roadmap that is never reviewed becomes fiction, and one that is rewritten every time someone sends an email becomes noise. The answer is a rhythm. Review Now weekly, because it is where delivery reality shows up first. Review Next and Later monthly, because that is how often the facts behind them usually change. At each review, ask three things: what has moved, what have we learned, and does the order still make sense? Put the last-updated date on the page, keep the previous version and note what changed and why. Even a single line per change is enough. That small change log is what lets you answer "when did that move, and what did we decide?" without a debate.
The second half of the discipline is agreeing in advance what counts as a reason to change the plan. Without that, every change request is a negotiation from scratch. With it, a change is a response to a known trigger and the decision is quicker. The table below lists triggers worth agreeing with your sponsors.
TRIGGERS FOR CHANGING THE ROADMAP, AND THE RESPONSE
| Trigger | Response |
|---|---|
| A fixed date moves, such as a supplier delay or a regulatory change. | Re-run sequencing for the affected themes. Tell everyone who depends on them. |
| Evidence contradicts an assumption, for instance the first theme's results. | Review the themes that rest on it. Change the plan openly and say why. |
| Team capacity changes materially. | Reduce what is in Now, not the quality of it. Move the rest, and show where it went. |
| A new request arrives from a senior stakeholder. | Show where it would go and what it displaces. Let the sponsor decide the trade. |
| A goal changes at leadership level. | Revisit the theme-to-goal links first, then the sequence. |
Illustrative. The point is to agree the list before the first change request, not after.
The urgent request, handled as a trade
The hardest test of a roadmap is the request that cannot wait. Most organisations produce one every few weeks, and the usual response is to squeeze it in, on top of everything else, with a quiet understanding that quality will absorb the cost. The roadmap offers a better response: treat the request as a trade, not a squeeze. If it comes in, something moves, and the roadmap shows what and when. The decision then belongs to the person with the authority to make it, with the consequences in front of them.
Keep a short decision log of these exchanges: what was asked, who decided, what moved and the reasoning. It takes a couple of lines each time. Months later, when someone wonders why a theme slipped, the answer is already written down, and it was agreed by the people who now question it. The log also protects the analyst. A plan that changed because senior people chose a trade looks very different from one that slipped because nobody was managing it.
A final safeguard is to protect the roadmap from becoming a political document. When a theme is added because of who asked, and not because of a goal or a dependency, the reasoning on the page stops matching reality, and readers notice. Keep the rule that every item on the roadmap traces to a goal and has a reason for its place. If a senior stakeholder insists on an item that does not, record it honestly as a decision made by that person, with the trade it caused. Honesty about how a plan was shaped is what keeps it credible when the next hard conversation arrives, and it keeps the analyst clear of accusations of favouritism.
Did it work, and what it means for your career
The best test of a roadmap is not whether the dates were hit. It is whether stakeholders can say, in their own words, what is coming, in what order, and why. Ask a handful of them. Count how many surprise requests arrive late in a quarter, and whether they get smaller over time. Watch whether the goal measures the themes were tied to are moving: fewer late deliveries, more repeat orders, lower checkout abandonment. If people can explain the plan, surprises are fewer and the goals are moving, the roadmap has done its job, even if some items slipped.
Look also at what the delivery team says. If engineers describe the roadmap as a fair picture of what they are doing, and if their questions have moved from "what are we building?" to "how should we build it?", the plan is doing its work at the level where it matters most. Ask your sponsors and your delivery lead the same short question after each quarter: what would you change about how we plan? Their answers become the agenda for the next version, and the habit of asking is itself a mark of the product mindset.
For a business analyst who is looking at product roles, this is the bridge. Everything in this week uses skills analysts already have: reading requirements closely, finding hidden dependencies, tracing decisions and explaining trade-offs. What it adds is the willingness to commit to an order and defend it in public. Start small. Take the next list you are handed and group it into themes, tie each to a goal and draw the dependencies before you hand it over. That alone moves you from the person who records what was asked to the person who helps decide what happens first. Next week the series moves to cloud and infrastructure basics, a different subject with the same underlying habit of understanding what everything rests on.
Go out and be successful.
Oluwatosin Ogunkoya · Flotog BA Insights · 1:1 mentoring and coaching for BAs at every career stage · www.flotogbainsights.com
NEXT WEEK
Cloud and Infrastructure Basics - What a business analyst needs to understand about where systems run, and the questions worth asking about it.