Four usual traps with roadmaps that make teams helpless and how to escape from them.

What’s your common reaction when you see your product roadmap?

I’d summarize my feelings as anxiety and fear. As we got closer to the end of the quarter, I often got anxious. The reason has always been the same: top management would present the roadmap, and I would get nervous as I didn’t know what to expect.

Most times, the roadmap made me panic because I had no idea how to deliver on the expectations. I felt powerless and even feared losing my job.

Once during a roadmap presentation, the CEO said, “I count on all of you to make it possible. We may all go to the job market if we cannot get this done.” The roadmap had an extensive list of features for each team. I wondered, “How can this be agile? Where’s the learning part?”

This story may not surprise you. You’ve probably been in a similar situation already. If not, it’s just a matter of time. I learned that roadmaps aren’t evil by design—they are accidentally miscreated because some people simply lack the experience to do things differently.

Let me walk you through four common reasons roadmaps trap teams and how you could improve them. I hope you get some actionable insights by the end of this read.

1.  The Top Secret Roadmap

Please, have a look at the following image. How do you interpret it?

Throwing roadmaps over the fence — Author’s courtesy — d-pereira.com

This image represents a significant part of my experience with roadmaps. It goes more or less like this:

1. Top management gets together to evaluate what matters most
2. They assess possibilities for the short, medium, and long term
3. They exchange ideas and potential solutions
4. They agree on what will go into the following roadmap
5. They define who does what by when
6. After crafting a shiny plan, they throw it to Scrum teams
7. Scrum teams get overwhelmed by the roadmap as they weren’t part of its conception
8. Top management expects Scrum teams to deliver on what they defined
9. Scrum teams feel confused because they are unaware of the problems they have to solve

What’s the result of that? Frustration on all layers. Top management will be mad when teams cannot meet deadlines, and Scrum teams will feel powerless as they cannot make any decision beyond the solution they have to deliver.

When roadmaps are thrown over the fence, everyone suffers. Nothing valuable comes out of that.

2.  More Features Is All That Matters

What’s a typical roadmap for you? For me, it used to be a list of features to deliver. Let me give you an example from an online shop:

• Referral program
• Product recommendation at cart & checkout
• Rating & review

That’s the high-level roadmap I got for a quarter with one of my teams some years ago. You may look at this and say, “What’s the problem with that? You can still make decisions on how to implement a solution for each one of the items.”

The problem with a feature roadmap is assuming impact. Take the referral program as an example. That’s an output, not an outcome. The goal behind this was to reduce customer acquisition costs, and it could be achieved in different ways.

When roadmaps focus on output, teams can only work on the solution space. But when roadmaps define outcomes, teams have room to discover better solutions that can drive the desired outcomes.

Outcome orientation increases the chance of creating value, while output orientation maximizes the odds of delivering crap.

Let me make a comparison between an output and outcome roadmap.

• Output: Implement product recommendations on the product detail page and cart.
• Outcome: Increase average basket size by 10% by the end of Q1.

The output roadmap forces teams to implement a solution, while an outcome roadmap empowers the team to solve a problem.

3.  No Room for Collaboration

In the perfect world, teams are self-organizing and can autonomously deliver value. In the real world, teams depend on other teams to create value. I encourage organizations to give teams end-to-end responsibilities, but this journey may take a while due to legacy and other aspects.

No matter the reality you’re in, collaboration is mandatory for success. Unfortunately, most roadmaps are too extensive and leave no room for collaboration. This situation is horrible because teams need one another and know if they help each other, they won’t conclude their roadmap.

You may wonder, why not design roadmaps without dependencies? Or at least reduce them to a realistic number? You’ve got it right. Generally, too many dependencies are part of the roadmap because those who crafted it were unaware of dependencies.

Roadmaps will have better chances of fostering collaboration when Scrum teams and top management craft them together.

4.  Unrelated to Strategy

It’s unbelievable how many roadmaps have no relation whatsoever with strategy. When roadmaps become a wishlist from influential stakeholders, you can only expect teams to deliver pointless results.

Let me give you a clear example. I joined a scale-up, and our strategy was to expand our reach, even if that would mean buying revenue for a year. When I first looked at the roadmap, here’s what I saw:

• Redesign product detail page
• Redesign the search experience
• Redesign the cart & check-out

What’s the relation of such a massive redesign with the strategy? In our case: none. Why did that happen? The Chief Product Officer (CPO) was recently promoted from UX Lead to CPO. She cared more about user experience than product strategy.

What’s the problem with a roadmap unrelated to product strategy? Scrum teams cannot connect their actions to what matters most for the company. Taking my example, you may say that user experience is also important, and I agree. But as John Wick wisely said, “Choices. Consequences.”

Strategy isn’t something to ignore, but it’s something to help product teams make decisions on their daily activities.

Moving From Trap Maps to Meaningful Roadmaps

You have a trap map when your roadmaps have any of the four elements I mentioned above. Your only certainty is trouble ahead of you. It doesn’t have to be that way.

I used to perceive the status quo as ultimate. I thought I couldn’t influence top management to change how they work. In time, I learned I was wrong. When you genuinely intend to do something better, people will listen to you.

Here are four golden tips on how to change roadmaps for the better:

1. Ask Questions: When you receive an output roadmap, don’t be shy about asking questions no one asks. Don’t bother about deadlines; care about understanding the desired outcome. Strive to comprehend what the solution aims to create. As you learn that, you can offer different ways of driving the outcome.
2. Take Responsibility: As you uncover undesired outcomes, be brave and offer to guide the team on delivering the result instead of implementing the solution. You will face resistance, that’s for sure, but you can get buy-in if you aim for a small experiment. It’s key to show confidence.
3. Talk About the Elephant in the Room: Almost all teams know that an output-oriented roadmap will create pointless results, but they don’t speak up. You can play the consultant role, share the potential results with the current approach and offer a better alternative. Make it clear that you want to achieve valuable results and recommend outcome orientation, but let top management decide which direction to take.
4. Collaboration: Ask to be part of the roadmap creation. Don’t hold yourself back from it. Most leadership teams I got to know created roadmaps alone because they thought it was their job. When I asked to be part of it, they welcomed me and were open to change.

Most roadmaps are the way they are because companies lack the expertise to do it in a better way. Don’t let the status quo limit you. You’ve got a chance to change it.