Why Most Roadmaps Make Poor Results Inevitable
Three common mistakes with roadmaps lead teams to failure
Three common mistakes with roadmaps lead teams to failure
Why do we strive to have a perfect roadmap per quarter? Because we want to commit to the future outputs. Then we can set clear expectations with our stakeholders. Wouldn’t it be ideal for delivering everything on time as we planned?
The perfect plan creates an illusion that makes us forget how complex reality is. Planning upfront doesn’t work in a dynamic environment. Once we insist on an ideal plan upfront, we might not be able to react fast to the inevitable changes. In this case, we will fail to use Scrum to our best interests.
The Scrum Guide doesn’t have a single mention of the word roadmap. But it does say what the Product Backlog is:
The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful.
— The Scrum Guide, November 2017
When we don’t accept changes, we fail. Our results will be, at best, mediocre. I believe we can do better than that.

Planning Features Instead of Goals
It was right before Christmas, when we met to plan our roadmap for the next quarter. All Product Owners were excited about it. The meeting was supposed to last three hours. We started at 09:00 a.m., we had post-its and a large whiteboard to draw our roadmap. Everything was set for a significant interaction. But that’s not exactly what happened.
Each Product Owner wrote their ideas for the roadmap on the post-its. Then, one by one went to the whiteboard and explained each item. I was shocked after the first Product Owner. She presented fifteen issues as part of the Roadmap plan; all of them were features to implement. The other Product Owners had a similar approach. I wondered what was happening. I could see little or no chance for us to collaborate as a Product team during the next quarter.
Needless to say, the next quarter was a complete failure for us as a Product team. Every team was fighting for the features, and we couldn’t collaborate. Some teams manage to deliver all promises. Yet, stakeholders were unhappy. Output doesn’t matter. The outcome is what counts. Unfortunately, we ignore it.
A traditional Roadmap plan is focused on features to deliver in a given time. But I can’t remember a single time that producing features set any team on a successful track. To succeed, we should define goals to achieve, instead of features to implement.
“Finally, it’s all about solving problems, not implementing features. Conventional product roadmaps are all about output. Strong teams know it’s not only about implementing a solution. They must ensure that solution solves the underlying problem. It’s about business results.”
― Marty Cagan, INSPIRED: How to Create Tech Products Customers Love
Pleasing Everyone; Pleasing Nobody
The life of a Product Owner is complex. We have to manage the expectations of many stakeholders. Everyone wants to have a say on the product. The way we handle the stakeholders’ wishes will set our path to success or mediocrity.
A common pitfall is to use the roadmap as an opportunity to please many stakeholders. Product Owners decide to put requests from multiple stakeholders as part of the next quarter Roadmap. It’s indeed an easy way of strengthening the relationship for the short-term. The Product Owner promises to deliver some features for each of them during the next quarter. Thus, everyone will be pleased with the results. In theory, it sounds great, but in practice, it doesn’t work.
“Winning products come from the deep understanding of the user’s needs combined with an equally deep understanding of what’s just now possible.”
― Marty Cagan, Inspired: How To Create Products Customers Love
Until we don’t understand the underlying problems, we are not ready to talk about solutions. Great Product Owners shift the conversation from features to goals. We should collaborate intensively with the stakeholders to uncover the hidden needs.
Also, we should strive to prioritize goals that will set a single direction for the Development Team. By saying yes to many stakeholders, we may be saying no to our chance to build meaningful solutions. When everything is a priority, nothing is.
Excellent Product Owners are bold. They go into conflicts by saying no to many stakeholders. Thus, they can set goals that will be the north star for the Development Team to pursue.
Involving the Development Team Too Late
If the Development Team gets to know the new challenges during the Sprint Plan. You failed as a Product Owner.

Many organizations claim to be agile. Yet, they plan everything upfront. Product Managers define what to build. Designer work on the interaction of it. Sometimes, some tests with real users will happen. But Developers are left out of this phase. Using Scrum only during the execution phase minimizes the chances for the company to thrive.
Unfortunately, I’ve seen many Roadmaps planned without involving any Development Team members. The Product Owners give their “educated guess” estimation to the topics. Then, a Roadmap is defined based on the capacity of the team. This approach does not resemble Agile or Scrum in any way.
Responding to change over following a plan
The roadmap shouldn’t be a surprise to the Development Teams. Instead, the items should be discussed during refinements. That’s the moment the Scrum Team evaluates the future possibilities.
Successful Scrum Teams continually refine the Product Backlog items. Sometimes, the Development Team will ask for a spike to clarify open points. This approach will help the team to gain confidence that it fits in a Sprint.
To thrive, we should work as a team, instead of in silos. Remember that the Scrum Team has all the required skills to build successful products. Leaving Designers out of the Scrum Team, will eventually lead to failure.
The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint.
— The Scrum Guide, November 2017
Endnote
I am not against Roadmap planning. On the contrary, I am in favor of that. However, I believe we can only succeed once we focus on the goals to achieve. We should accept we don’t know what to build to reach the outcome we expect. But we should know why we go to work every day. We should know the result we want to deliver.
“If you tell people where to go, but not how to get there, you’ll be amazed at the results” — George S. Patton.
Successful Roadmap planning has the following characteristics:
The roadmap contains only goals to achieve. The focus is on the outcome.
The Product Owners prioritize what is best for the product, instead of trying to please the stakeholders.
The Roadmap plan will not surprise the Scrum Team with features they have never heard. But, it may surprise them with challenging goals to achieve.
Do you want to write for Serious Scrum or seriously discuss Scrum?