Three Problems With Product Roadmaps

A product roadmap is an important strategic framework that provides direction and guidance to internal and external stakeholders. It provides a plan for how the product’s vision will be realized and reflects strategic priorities including specific market segments and customer needs.

However, while there’s general agreement that preparing a roadmap is important, the reality is that often roadmaps are not as effective in practice. The problems generally fall into one of three categories:

  1. Confusing short-term plans with a roadmap. Ask a product manager what the roadmap is for his or her product, and you might hear a rundown of what’s in the next release or what’s in the product backlog (for those using an Agile/SCRUM process). These short-term priorities are the most near-term execution step in a roadmap, but not a roadmap in and of themselves. In fact, without the broader context that a roadmap provides, it may not be evident when immediate project work is not aligned with longer-term strategic priorities. These feature lists provide no insight into the bigger picture. By focusing on impending tactical activities, companies don’t position their products for the future state of the market, become ignorant of pressing competitive threats, and may focus on short-term fixes at the expense of long-term success.
  2. Executives confuse a roadmap with the roadmapping process. A roadmap is the deliverable; a roadmapping process is the way that it’s created. Many executives see the end result and want a roadmap for their products, missing the point that you can’t just wave a magic wand to create one. By focusing on the output instead of the process, product managers/teams miss out on the collaborative input that comes with creating and updating a roadmap. The focus on data, analysis and context goes by the wayside as product managers throw together something that simply matches the defined corporate presentation format. What’s lost is the realization that the process of putting together a roadmap is often more beneficial than the final deliverable.
  3. Product managers have an ad hoc process for roadmap creation. You need a good process to bake a delicious apple pie. What ingredients are needed? When do you add them to the mix? What tradeoffs must be made (flavor vs. nutrition)? How long should it bake? Different recipes will yield different results. Similarly, if you want to have a good product roadmap, you need an effective process to create one. Just as you can’t bake a pie by just randomly throwing ingredients into a pan, you can’t create a good roadmap by randomly adding features to a PowerPoint slide. If your process is flawed and your ingredients are subpar, you will not be pleased with the final outcome.

So, how can you address these problems in your organization?

  • Product managers must have the know-how to create effective roadmaps. Product managers may have never received the support needed to create effective roadmaps. This goes well beyond simply providing a template or offering one-time training; it’s an expertise and experience gap that must be addressed as part of a broader upskilling of the product management team.
  • Make sure product managers prioritize roadmap creation. This starts with clear job descriptions and well-defined roles and responsibilities, and must be reinforced by product management leaders requiring their teams to create and update roadmaps. Simply put, leaders need to show roadmapping the respect it deserves and make it a priority.
  • Product managers must do a better job balancing the tactical with the strategic. Too many product managers get caught up in tactical details, like monitoring the daily progress of the product development team or debating minute details of product design; they also spend too much time on day-to-day “firefighting” (e.g. responding to requests from sales reps). They need to stop making excuses for not having enough hours in the day and prioritize their time better to ensure enough focus on strategic areas like roadmapping.

In the SiriusDecisions Product Marketing and Management Model, we stress the importance of a consistent roadmapping process, resulting in a product roadmap that covers not only near-term plans but the future roadmap. Best-in-class organizations implement standard roadmapping approaches and consistent formats for roadmaps. Not only do they have roadmaps for all individual products and services, but also for product portfolios and broader solutions.

By making sure that product managers are trained on the roadmapping process and templates, and receive appropriate support through the roadmapping process, companies can ensure that their product and solution plans are aligned with longer-term strategic objectives.

 

About the Author

Jeff Lash is Research Director, Product Management, at SiriusDecisions. A recognized thought leader in product management, he has over 10 years of experience in product management, portfolio management, product development, and user/customer experience design. Follow Jeff on Twitter at @jefflash.


7 Comments

  • Geoff Anderson, 21st November 2012 at 9:44 am

    Reply

    Very good advice. Alas, much of it is lost on senior executives.

    At my last job, I tried to create a comprehensive roadmap, using all the skills and tools that I have developed over 14 years, only to have our corner office sitter tell me to just put his vision in a slide and call it done. I wish I could say that this was an isolated experience, but it has happened before.

    Thanks for the post!

  • Bruce McCarthy, 21st November 2012 at 3:05 pm

    Reply

    Thanks, Jeff. Clear and concise. I’ve been witness to all of these mistakes – and made them as well!

    I think it’s important that whoever heads up product management – whether it’s a VP of Product, the CEO or a functional leader from Marketing or Development – establish and support a process. Buy-in is needed up, down and horizontally that a solid process is needed and that it will be led by product management with participation from all groups.

    I presented on roadmapping at ProductCamp in Boston this year (slides here: http://www.slideshare.net/bmmccarthy/prioritization-301) and one of the key points I made is that you need buy-in on the priorities that go into the roadmap or it won’t stick. And the only way to get that buy-in is by having key people from different departments as part of the process.

  • Jeff Lash, 23rd November 2012 at 9:34 am

    Reply

    Geoff — You’re right, and unfortunately product managers aren’t “truly” in charge of their roadmaps. That’s not as much a roadmapping problem, though, and goes beyond that to the overall role and responsibility of the product manager.

    And, this gets to Bruce’s point too — if the roadmapping process isn’t agreed to, or the right people aren’t involved, then then you won’t get buy-in on the results.

  • Mark A Hart, 26th November 2012 at 8:05 pm

    Reply

    Geoff stated “product managers aren’t ‘truly’ in charge of their roadmaps. That’s not as much a roadmapping problem, though, and goes beyond that to the overall role and responsibility of the product manager.”

    What if Product Managers realized that a product roadmap is just a typical artifact of a product development process?

    Product Managers know that Product Roadmaps are deliverables that include:
    - Guesses about an uncertain future marketplace.
    - Framing errors of those engaged in the roadmapping process.
    - Guesses and assumptions about the availability of resources in the future.
    - Guesses and assumptions about the quality, adaptability, and commitment of individual contributors that can be recruited to develop the concepts into viable products.

    Forecasts about the viability of future product concepts are always subject to errors because of problems that include the lack of awareness (also known as unknown unknowns).

    Product Roadmaps may be ONE FACTOR to deliver a successful portfolio of projects within an organization. There are many more.

    What if Product Managers embraced evolving roles and responsibilities that resulted in an abundant number of customer purchasing products that provide value by solving problems better than competing solutions?

  • John Peltier, 18th December 2012 at 8:00 pm

    Reply

    Another one to add: Related to your second bucket of confusing the output with the process, is the common mistake of confusing a roadmap with a project plan. Stakeholders mistake the roadmap with commitment. Ever have someone tell you in one conversation that they understand a roadmap is a guideline, but then later the same week ask you why something “slipped”?

    This problem is exacerbated when features are listed by time period on a chart, which implies more certainty than is intended. While trying to stay at the “theme” level, some stakeholders aren’t comfortable without the extra feature level of detail. I haven’t ever solved this one to a reasonable level of comfort.

  • Jeff Lash, 19th December 2012 at 9:32 am

    Reply

    There have been a bunch of great comments, which I think highlights how important this topic is and how much people still struggle with it. A lot of the comments relate back to one fundamental issue — a common definition of a roadmap. There needs to be a consistent understanding of it among the stakeholders, an agreement about what it is/isn’t, a sense of how it fits in with other deliverables, and, most importantly, a purpose behind creating one.

    The challenges Geoff and John mention are direct results of not having that shared understanding and agreement about not just the roadmap itself but the roadmapping process. This isn’t something that can happen in one meeting; it requires clear definitions of roles/responsibilities, a defined go-to-market process, and alignment and interlock between the different stakeholders in the process.

  • Desi Product Manager, 3rd February 2013 at 1:26 am

    Reply

    A very good post, highlights the problems with the roadmap and the suggested solutions. In my experience, I have come across 2 related issues. 1) Senior management does not want a roadmap, they simply want the list of deliverables for every quarter (this is remarkably common in offshore R&D centers in India) 2) Senior management does not understand different types of roadmaps and sub-roadmaps (technology support roadmap, feature delivery roadmap, geography support roadmap, vertical support roadmap etc). IMHO, every project plan to add features or enhancements is a roadmap in some sense. And they should not be merged into a single “global” roadmap just to get executive management approval.


Leave a Comment