The trouble with roadmaps

One of the joys of my job at Belka is that I get to talk to a lot of product managers about their roles, pains and pleasures. One of the things that always comes up is roadmaps, and how much they suck. (I’m exaggerating, but only a little.) 

Roadmaps are supposed to make everything easier by helping us prioritize, align, organize and deliver. Sounds good, right?

But here's actually what many product managers keep telling me:

• They don’t work! The projects are too big, the time is too short, and we never manage to hit our deadlines.
• They’re never up to date! Already obsolete and useless by day one.
• They’re always changing!
• Nobody looks at them! The roadmap file is barely opened.
• Nobody’s happy with the feature estimates! For the team they’re too short, for the stakeholders, they’re too broad.

We need them but we also hate them. And a lot of the time they don’t seem to be working.
‍

The root of the problem

Clearly there are some serious problems with roadmaps. Tell me if any of the following sounds familiar:

You think of the roadmap as a list of features, visualized as a timeline made of feature titles in multicolored rectangles on a horizontal page. 

Your definition of success: delivering each feature on time, on budget, and within a fixed scope.

When you create a roadmap it begins with someone (usually you) asking the leadership and stakeholders which are the future projects for the product (yes, collecting requirements). Then you share these “feature titles”' with your product team and ask them to provide estimates. This leads to a big discussion involving story points, epics, deadlines, and milestones.

Once nobody is satisfied (I’m exaggerating again, but not much), the timeline is set in stone. As the project proceeds, there will be updates on how these projects are going — if you’re lucky.

More often than not, you end up delivering late. 

And last but not least, at no point is there a serious discussion of the actual problem to be solved, or the expected outcomes.

If this is how you’ve approached roadmaps, I don’t blame you for hating them and thinking they don’t work. 

So what’s the problem?
‍

What this approach gets wrong: Features vs Outcomes

This understanding of roadmaps is an example of what we can call a “feature mindset,” and it’s problematic for several reasons. 

What are some symptoms of a feature mindset?

Prioritizing features, not goals: When you prioritize features over goals you go into what we like to call the “what-to-build mode” — everything becomes about building. Once you’re focused on building your shiny new feature, it’s easy to get too excited about it and completely forget why you wanted to build it in the first place.

Thinking too big: When you’ve defined your goal as building the feature, you risk locking yourself into a big project with no intermediary steps, no space for early validation, small experiments, and iterations. This method may lead to over-delivery and a waste of resources that could have been invested in smaller, safer iterations.

Caring more about time spent than value added: The feature mindset means that most of the debate about the project will be spent estimating how much time is needed to complete it rather than the value it will generate for the company. Pressure mounts on teams to provide timelines for large, unclear projects, creating friction and detracting from the true purpose of the initiative.

Not knowing who’s responsible: When the solution is predetermined, who is accountable for the end product? Lack of clarity around responsibility, especially regarding the Product Manager’s role, further complicates the process.

This is a completely wrong way to think about roadmaps. Time for a fresh perspective.
‍

How a roadmap should actually work

Thinking about roadmaps as a collection of features or a timeline leads to misdirection, wasted resources, and missed opportunities. And while project plans and other documentation are essential to a good roadmaps, they are not themselves the roadmap.

So if that’s the wrong way to approach a roadmap, what’s the right way?

The most important thing to understand is that a roadmap is really a tool to make your strategy tangible, and to give everyone on the team an answer to the question: "Why are we working on this particular issue and not something else?"

This means two things have to be clear:

Agreement on product priorities: Leadership must define product priorities that remain consistent for at least three months at a time. A well-crafted roadmap ensures visibility, clarity, and commitment to these priorities (problems or goals) within a set timeframe.

Autonomy for the product team: Teams should be given goals, not feature titles, allowing them the freedom to devise various initiatives to reach the desired result. The solution doesn't have to be polished or complete — sometimes a simple email automation done in two hours can be more valuable than a fancy dashboard.

Now, based on these two principles, your roadmap should include:

• Goal: An overview of the desired outcome regardless of what actually gets built. How does this goal align with the company’s overall goals?
• Initiative: Why does it make sense for us to work on this now? Include a brief description of the initiative or intervention on the product. (Not a detailed project plan or requirements list.)
• Timeframe: Limit the scope to a quarter or semester, recognizing that circumstances may change, requiring validation and experimentation.
• Accountability: Clearly establish who is responsible for making things happen.

‍

How the pros do it: Immobiliare.it

If you’re wondering how great product teams use roadmaps you’re in luck, because I’ve talked to some of them too.

All of them have four things in common: a mature product, a clear vision, a meaningful strategy, and valid product goals aligned with overall business objectives.

These four elements promote a product-centric culture within the company and serve as the foundation for an effective roadmap.

Immobiliare.it is Italy's leading real estate platform and one of the most thriving and experienced tech companies in the country. Here’s how their team uses roadmaps:

Yearly Product Goals: Defined by product leadership, these are the big objectives that are communicated across all product teams. They translate into epic goals, such as “increase the number of users logged onto the platform.”

Team-Specific Goals: Each product team or squad is assigned specific goals that align with the broader product objectives. The team then comes up with the initiatives needed to reach these goals within a given quarter, such as, for example “add another social login”

This way of working gives us two roadmaps that are in alignment:

• A Team Roadmap focuses on a single goal, detailing the initiatives undertaken by the team to approach that goal within a specific timeframe.
• A Strategic Roadmap, which contains all the squad goals and anticipated outcomes agreed upon by the stakeholders.

In this way, Immobiliare.it has succeeded in turning roadmaps into dynamic tools that not only guide product development but also support collaboration and strategic alignment within their organizations.

‍

A solution to all your problems?

Thinking of roadmaps as strategic tools, rather than mere feature lists, will change how you approach product development. It can help you focus on what you want to achieve, not just what you plan to build. It aligns your efforts with broader company goals, transforming your product from a collection of features into an evolving experiment to realize your product vision.

In theory this sounds great. But what about practice? Let’s do a quick reality check: 

I’m not saying we should throw away traditional tools like estimates, t-shirt sizing techniques, or cost considerations. These elements still have their place, just not in the roadmap. 

Also, business requests will inevitably guide some features. But if 80% of your roadmap consists only of feature titles without clear goals, it's time for a rethink.

Finally, we need to be aware that conflicts between product managers and teams are natural. Teams often focus on completing features, while product managers must think strategically. Asking, "How can I deliver this value quickly?" rather than seeking completeness keeps everyone aligned on what truly matters, which is delivering value.
‍

How to get from here to here

Done correctly, this approach to roadmaps empowers product managers to focus on real value, goal alignment, and collaboration. But how do you implement it? You are basically trying to switch from feature-mindset to product-mindset. It’s not easy!

So here are three pieces of practical advice to help you with the transition:

Acknowledge that roadmaps are a collective responsibility. Roadmaps aren't only a product manager’s responsibility. This isn’t a solo task you can master from reading a book and tweaking templates. You have to engage the team and the stakeholders in understanding and implementing the change. 

Set realistic goals, with one step at a time. If you don’t currently have yearly goals or a clear product vision, it’s unrealistic for you to switch to an OKR model in one quarter. So start small:

• The next time you start a project, along with the feature title, also sneak in a question about the expected business results of the change. Let the leadership team tell you their expected results and then show them what actually happened.
• Identify just one product priority or KPI that needs improvement in the current quarter. Align your current initiatives towards it and measure improvements.

Finally, recognize your limitations. If your stakeholders are far removed from a product mindset, understand that you alone might not change the company culture. But that doesn't mean you can't make a positive impact!

‍

What happens now?

This roadmap transformation is not a magical, instant fix. It requires patience, collaboration, and realistic goal-setting. But with these strategies in hand, you are now better equipped for the exciting journey towards a more effective and goal-oriented roadmap.

It’s a bumpy road but the destination is worth it.

‍

∗ ∗ ∗

‍

Sara Fazzini leads Belka’s UX Research Team. She is currently driving around Italy on vacation, without a roadmap. Want advice from Sara on roadmaps? Feel free to reach out to her at sara@belkadigital.com!

‍

Want more good advice from Belka? 

• Giulio wrote an article about how to build terrible digital products and make everyone miserable.
• Doctor Belka offered his insights about digital product development: when it slows down and how to fix it!
• Again, doctor Belka advised on why and when use a design system. Or not.

‍

Want a safe pair of hands to help with your own design system?
Learn about Design System Audit, our service to make sure your design system brings you results.