Why Most Roadmaps Make Poor Results Inevitable

Three common mistakes with roadmaps lead teams to?failure

Why do companies strive to have a flawless roadmap per quarter? Because they want predictability on future outputs. Then stakeholders will have clear expectations and can hold teams accountable for meeting roadmap plans. Wouldn’t it be ideal to deliver everything on time as we planned?

Planning upfront doesn’t work in a dynamic environment. The perfect plan creates an illusion that makes us forget how complex reality is. 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 in 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 an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.

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

Let me share a little story with you. We met right before Christmas 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. with 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 unrelated to each other. 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 features, and we couldn’t collaborate. Some teams manage to deliver all their promises. Yet, stakeholders were unhappy. The 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 time 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

Pleasing Everyone; Pleasing?No One

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. How 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 following quarter roadmap. It’s an easy way to strengthen the relationship in 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 it doesn’t work in practice.

“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

We are not ready to talk about solutions until we understand the underlying problems. Great Product Owners shift the conversation from features to goals. We should collaborate intensively with the stakeholders to uncover hidden needs.

Also, we should strive to prioritize goals that will set a single direction for the Scrum Team. When everything is a priority, nothing is. By saying yes to many stakeholders, we may be saying no to our chance to build meaningful solutions.

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 Scrum Team to pursue.

Involving Developers Too?Late

If developers get 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 developer. The Product Owners give their “educated guess” estimation of 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— Agile Manifesto

The roadmap shouldn’t be a surprise to developers. 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. Developers sometimes 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.

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 achieving our goals. We should accept that we don’t know what to build to reach the expected outcome. But we should understand why we go to work every day. We should see 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 of. But, it may surprise them with challenging goals to achieve.