How to Build Realistic Roadmaps as a Product Owner
Every now and then I get asked: “How do you create realistic roadmaps?”
Meaning: roadmaps that the team can actually deliver in the time available.
In my environment, budget is allocated on a yearly basis. That means my roadmap must realistically cover at least one year. You can’t rely on wishful thinking, oversized ambitions, or inflated capacity assumptions. You need something grounded, data-driven, and operationally realistic.
Over the years, I’ve refined a workflow that reliably gets me to a roadmap the team can commit to. It’s a mix of probabilistic forecasting, lean decision-making, and practical collaboration with the people who will actually deliver the work.
If you struggle with unrealistic roadmaps, slipping commitments, or annual budget pressures, I hope this workflow helps bring clarity, predictability, and sanity back into your planning process.
1. Start With a Prioritized List of Epics
Before thinking about time or capacity, start with outcomes.
What do we want to achieve this year? What matters most for our customers and for the business?
This results in a prioritised list of epics, ranked by value and impact.
The roadmap will only ever be as good as this list.
2. Establish a Realistic User Story Capacity
Next, I need to know how much work the team can realistically deliver in one year.
I use Monte Carlo simulation to answer a simple question: “How many user stories can the team complete in a year with 85% confidence?”
Example: The simulation tells us the team should be able to complete 230 user stories or more with 85% confidence.
That number is now my upper bound for planning.
3. Decide How Much Capacity Goes to Feature Development
Not all capacity goes into new features. The real world also includes:
Bugs
Technical debt
…
So I consciously decide how much of the yearly capacity I want to allocate to feature development.
Example: even if the team can do ~230 stories, I might allocate only 200 to planned features.
The rest is buffer — for reality.
This prevents overcommitting, protects the team, and keeps the roadmap sane.
4. Create a Quick High-Level Plan
At this point, as a team, we haven’t reviewed epics deeply yet. I don’t want to waste the team’s time on detailed estimations before I know which work is likely to make the cut.
So I use historical data to create a quick sizing rule of thumb: 85% of the epics we’ve delivered in the past required 30 user stories or less.
Therefore, as a placeholder, I temporarily assume 30 stories per epic.
Using our example:
Capacity for features = 200 stories
Average epic placeholder size = 30 stories
High-level capacity = ~6 epics
Those 6 become the initial high-level plan.
This step is extremely lightweight — and that’s intentional.
5. Review Only the Selected Epics With the Core Team
Now that I know which epics might fit, it’s time to review them together with key players: architect, lead developers, lead tester, cybersecurity expert, …
This review takes time, so we make sure to apply it only to the most important items, those likely to make the cut!
This is where depth meets focus.
6. T-Shirt Sizing and Risk Assessment
In the review, the team assigns:
A T-shirt size (XS/S/M/L/XL)
A risk level (low / medium / high)
T-shirt sizes are then translated into the number of expected user stories, but with a twist. Instead of arbitrary numbers, k-means clustering algorithm on historical epic sizes is used to to determine how many user stories should be used for each T-shirt size. E.g. T-shirt size M typically means 18 stories
This keeps estimates consistent with our actual delivery patterns.
7. Replace the Placeholder Epic Sizes With Human Estimates
Once the review is done, the high-level plan becomes more accurate: instead of “every epic is 30 stories”, we now have epic-specific estimates grounded in historical data and expert judgment.
This hybrid approach keeps estimation cost low while ensuring quality where it matters.
8. Refine the Plan Based on Updated Estimates
We can now re-check the plan against the capacity.
Two scenarios:
The epics do not fit the “200 user story capacity”: I remove the lowest-priority items until the scope fits.
The epics fit, with room left over: review few more items (step 5).
This is the stage where realism strengthens.
9. Replace T-Shirt Estimates With Actual User Stories
As we break epics down into user stories (just-in-time refinement):
the T-shirt estimates are replaced with the actual story counts.
The forecast updates automatically (point 10)
This makes the roadmap both adaptive and transparent.
10. Continuous Forecasting
At any point in time, the Monte Carlo simulation provides a continuously updated, data-driven answer to a simple question: “When will we finish the planned scope?”
That planned scope is not a single, fixed thing. It is composed of two parts:
Epics that have already been analysed, where we have a reasonable understanding of how many user stories are required.
Epics that have not yet been analysed, where the work is still represented by forecasted user stories derived from historical data.
At any moment, the roadmap can be understood as a mix of actual user stories and forecasted user stories.
Early in the journey, uncertainty dominates. Most of the scope exists as forecast rather than concrete work: classic fog of war. But as execution progresses, epics are refined just in time, forecasted user stories are replaced by real ones, and uncertainty steadily decreases.
What starts as a range of possibilities gradually collapses into reality.
The forecast evolves with the work, not despite it, allowing the roadmap to remain both realistic and responsive throughout execution.
Why should you try this approach?
1. Fast initial planning
You can produce an initial plan in hours, not weeks.
2. Just-in-time work
The team invests effort only into the epics that really matter. Waste minimised. Lean, for real.
3. Human input + Data synergy
The final plan is:
based on team judgment
backed by historical performance
reinforced by statistical forecasting
Teams commit much more easily to plans they helped shape.
4. Avoiding the trap of estimating everything
Estimating everything is waste. Because half of them will never happen. Or they’ll mutate by the time we get to them.
In Conclusion
There are many ways to plan and track a team’s work.
This one is mine, but only until I find a better one.
There are also many tools that can support this way of working.
The one I use is Lighthouse.