Battling Roadmap Inconsistency

If you’ve been in a product for a while, you’ve almost certainly run into the problem of inconsistent documentation. This problem rears its ugly head in lots of places:

  • Requirements spread across product briefs, PRDs, Jira or other workflow management tool tickets, and wireframes
  • Web-based and in-app user guides
  • Sales collateral, especially in B2B situations in which sales execs like to put their spin on the pitch
  • Product roadmaps

Inconsistent documentation is, of course, only one example of a lack of standardization within a product team. This post will focus on the last example, product roadmaps. Furthermore, the post will offer some suggestions on how you can get this issue under control.

Why does roadmap inconsistency matter?

What are the problems that arise from having inconsistent roadmaps, starting with the most consequential?

Your story lacks coherence

The worst result of roadmap inconsistency is that the story doesn’t make sense. The details at the drill-down level don’t support the big-picture vision. This inconsistency is the most insidious sign of a poor product strategy. It has the consequence of individual teams failing to align. In either case, the outcome is the same – a failure (or at least an obstacle to overcome) to achieve your goals.

Your audiences get the wrong message

If you only have one roadmap for the entire company that you show to everyone who needs to see it, inconsistency is not an issue for you. The effectiveness of communication might be, but that’s a different topic. Or you may work at a very small company. Smaller companies may not need to target views of their roadmap for different groups – internal/external, executives/product team/sales team, etc.

If you have reached that point, however, a set of roadmaps describe a different picture of the future. When it comes to expectation management, those different understandings make a big difference. One group may celebrate the evolution of the product, while the other experiences confusion.

For example, you could find yourself in a situation where the customer support team is thrilled about a fix. The fix addresses a big source of support tickets. However, the sales team is incensed that the valuable feature they have been promising customers is still in development. Or worse, depending on how large, decentralized, and empowered your product team is, you could have teams working on problems that have been deprioritized based on a change in corporate strategy.

The roadmap user experience makes the reader “work for it”

If your product team is of sufficient size to include multiple product managers, all with responsibility for a different aspect of the product, then you likely have multiple individuals creating and contributing to views of your roadmap at different levels. With each person applying their spin on how to visualize the plan for their area of responsibility, even if each team’s plan is aligned with the overall vision, you can end up with a document that is difficult to decipher. Inconsistency of formatting and what drill-down details to include can create an increased cognitive load on the reader or viewer that requires unwanted work to understand. At worst, these issues can make what is otherwise a well-aligned team and story come across as disconnected and disjointed.

Download the Product Planning Workbook➜

Types of inconsistency and how to fix them

Roadmap inconsistency falls into three categories:

  • Structure
  • Content
  • Style

You need to address all three to avoid the issues we reviewed above.

Structural inconsistency

Structural consistency requires the product team to choose a standardized roadmap the collective can use. Will you adopt a feature-based roadmap or an outcome-driven roadmap? If you select an outcome-driven, feature-less roadmap approach, will you build your story around themes or a north star?

The second aspect of structural consistency to consider is the time horizon. Whereas traditional roadmaps orient around a calendar-based timeline, typically divided into quarters or even years in some cases, more and more teams are adopting a Now, Next, and Later approach. This type of structure, used primarily with outcome-driven roadmaps, acknowledges the uncertainty around strategic outcome achievement. Calendar-oriented timelines have more common with feature-based roadmaps, which usually aim to communicate specifics about when a new feature will be delivered.

Another element of structural consistency that can be overlooked is decisions about what to include in different roadmap views. For example, sometimes it’s appropriate to include an item on the view that the sales team shows to customers, and sometimes it’s not. Having a way to manage information disclosure can go a long way toward avoiding uncomfortable conversations when a customer gets excited about an early-stage idea on the roadmap that was ultimately deprioritized.

Templates and tags

ProductPlan helps product leaders manage structural roadmap consistency through templates and tags. There are a variety of template types that teams can use as-is or customize as needed. Or if none of the pre-existing templates are quite right, product leaders can create templates from scratch. In either case, product managers can save preferred templates for team members to use as they build the roadmap for their specific area of responsibility.

ProductPlan also allows for custom tags and a way to manage tags to avoid redundancy and error. Once in place, tags can filter roadmap items to create the right view for your audience and situation.

Inconsistent content

When you have a team of product managers contributing individual areas to a larger roadmap owned by a Portfolio Product Manager, you run the risk that each person will make decisions about what information is important to include and what isn’t. The old saying, “The devil is in the details,” applies here. A consistent set of details for every item on the roadmap goes a long way toward instilling confidence in the decisions.

For example, at the most basic level, information like what you are building, why you are building it, and who you are building it for are a good start at establishing a common set of details for each item. In many cases, companies will want to go further to include information like the responsible product owner, the allocated budget, and the values assigned to each item that contributed to its prioritization.

ProductPlan has two features that are particularly helpful in maintaining consistent content in your roadmap. Custom fields give you a way to specify exactly what content you want product managers to include, assuring that when a stakeholder drills down, they get the same set of supporting details for each item. The Prioritization Board provides a customizable set of scoring criteria that allow your team to make objective decisions about the importance and anticipated value of each item on the roadmap. This objective prioritization helps you avoid the dreaded HiPPO approach to product strategy and communicate the “why” behind an item’s placement in the plan.

Stylistic inconsistency

Sometimes designs are objectively bad or at least worse than others when comparing the outcomes achieved by alternatives. The practice of A/B testing allows product teams to make design decisions out of subjective opinions about whether the orange or blue call-to-action button is better by looking at the conversion data achieved by each.

Often, however, decisions about design alternatives are purely subjective. Should we use a serif or sans-serif font for labels? Will the items on the roadmap related to this theme be green or purple? Should we use a light orange or dark orange to denote initiatives that are at risk? Or should we use yellow? Product managers, left to their own devices, will make different decisions when creating their roadmap. Even if the rest of the content and structure of the roadmap is completely consistent, a stylistic hodge-podge is the first thing stakeholders will see, and the rest of the content will immediately be suspect.

Shared legends and templates

With Shared Legends and templates, ProductPlan users can easily maintain a consistent look and feel for their roadmaps. Shared Legends allows admins to create and lock down roadmap legends. Individual users will have to use predetermined colors and labels. Just as templates allow product leaders to implement structural consistency, they also support stylistic consistency. Templates provide a way for product leaders to provide an officially-styled display format that product managers can not change.

With ProductPlan’s roadmap software, product teams have a rich set of tools available to battle roadmap inconsistency. By ensuring that roadmaps are consistent structurally, in content, and stylistically, product leaders can better communicate the information, stakeholders need with a product roadmap.

Learn how to transform your product launches from chaos to success➜

Read next

New ProductPlan Features Will Elevate Your Product Strategy

New ProductPlan Features Will Elevate Your Product Strategy

The seasons are changing, and ProductPlan is too! Our team is actively committed to continuous innovation and improvement, and this fall is no exception. The ProductPlan Fall Release celebrates powerful new features within our Strategy Module that will elevate your...

read more
ProductPlan Platform Recap: Q2 2024 & Q3 Sneak Peek

ProductPlan Platform Recap: Q2 2024 & Q3 Sneak Peek

Our product team has been keeping busy, and we’re excited to review recent changes and share what’s next on the horizon with you! Looking ahead, we’re planning quarterly releases packed with new features and improvements that will elevate your experience with...

read more