Practical guide
A roadmap should explain what can wait
Explain why this work comes next, what it depends on and what would change the order.
The useful part is the choice
I want a roadmap to explain why the team is doing this work now. If every request looks equally important, the person who starts building ends up making the priority call. A row of dates can look convincing while leaving that decision unresolved.
Begin with what needs to change. Fewer customers abandoning setup? Less time spent correcting orders? The ability to serve a customer you cannot support today? Choose a specific outcome and write down the evidence that it deserves attention.
Follow the dependencies
For each proposed piece of work, ask what has to be true before it can succeed. That might mean access to data, a partner's decision, a migration or agreement on who handles exceptions. Put a name against each unanswered question. An estimate does not remove a dependency.
Then ask what the team will stop or delay to take this on. Capacity already spent on support and maintenance counts. I would rather see a small plan that acknowledges that work than an ambitious one that depends on everyone having uninterrupted weeks.
What waiting could look like
Consider a hypothetical team choosing between a reporting dashboard and a fix to customer setup. They find that new customers cannot complete setup without staff intervention. Improving that journey becomes the next priority because it blocks the product's basic use.
The dashboard can wait while a weekly export covers the reporting need. The team records the compromise and agrees to revisit it if preparing the export takes too much time or a customer needs information it cannot provide. Everyone knows why the work is waiting and what would bring it forward.
Run a short planning exercise
Take the five requests receiving the most attention. For each, write one sentence about the customer or business change it supports. Add the evidence, dependencies and consequence of waiting. If the team cannot explain an item without naming a feature, spend more time on the problem.
Choose the next outcome and list the work needed to reach it. Mark the remaining requests as later or unresolved, with an owner for each open question. Write down what new information would change the order, then set a date to review it.
Some dates are commitments
An incident, a contractual deadline or a required migration can set the order for you. Name that constraint and show what it displaces. Keep committed dates distinct from tentative sequencing. When a deadline is fixed, the useful discussion is about scope, dependencies and the consequences of missing it. Calling everything flexible is no more honest than pretending every estimate is a promise.
Written for this site, 4 October 2026.