Product Roadmaps Relaunched: How to Set Direction while Embracing Uncertainty

by C. Todd Lombardo

internal and customer-focused objectives should be mutually reinforcing

This framework also makes room for things not often included on product roadmaps, such as bug fixes and infrastructure enhancements, by providing the business justification for that work.

A roadmap based primarily on internal business objectives would not, of course, be appropriate for sharing with customers or channel partners.

One of the most important things a product pro must do before releasing a product is define how the success of that product will be measured, or its key performance indicators (KPIs).

For the new product person, we have one key piece of advice here: find a balance with the amount of data you analyze. Three to five objectives are usually sufficient, and the metrics to measure them shouldn’t be exponential.

you also have to make sure to define enough success metrics to actually be able to capture valuable insights.

The risk of an output-focused roadmap often equates to a product team that releases feature after feature, and no tie back to the reason for those features. A feature factory is the term often used to describe such teams.

Many stakeholders are looking to the roadmap to tell them exactly what they can expect and when. However, that type of artifact is not a roadmap—it’s a project plan or a release plan.

Guiding principles forming a vision of the future for your customer and your organization, and a strategy for achieving them, are essential ingredients of a compelling roadmap.

Identifying customer needs is the most important aspect of your roadmapping process. Roadmaps should be about expressing those customer needs. Therefore, most items on your roadmap will derive from a job the customer needs to accomplish or a problem the customer must solve.

you have identified a “job to be done” that is frustrating and inconvenient enough for a customer to seek out and “hire” a solution to address that discomfort.

if your guiding principles are properly set, then you also have a clear vision for a desired end state and the goals that will get you there.

draw a clear distinction between the product roadmap and the release plan

Your roadmap should be a high-level view of what needs and problems your product should solve, while also helping you confirm why.

your release plan should detail how you w...

Themes are an organizational construct for defining what’s important to your customers at the present time.

A theme is a high-level customer need. A subtheme is a more specific need.

themes and subthemes represent the needs and problems your product will solve for. A need is generally something the customer doesn’t have yet, whereas a problem is something that’s not working right

“Themes help teams stay focused without prematurely committing to a solution that may not be the best idea later on.”

“the viability of a feature may shift dramatically, while the nature of an important customer problem will likely remain the same.”

Focusing on customer needs helps the team say “no” to unnecessary solutions.

Focusing on customer needs helps the team shift away from playing competitive catch-up

Focusing on customer needs creates a better and more intuitive narrative for sales and marketing.

A clearly defined need makes solution development easier.

Starting with customer needs provides development teams with more freedom and flexibility ...

Customer needs are generally smaller in number than a laundry list of features, making the roa...

“so many features in today’s products are solutions without a clear problem to solve.”

themes are so important is because they force you to focus on the need before you even start to consider solutions—and

The journey map is a tool that helps you understand every step a user takes when solving a problem.

James Kalbach’s book Mapping Experiences: A Complete Guide to Creating Value Through Journeys, Blueprints, and Diagrams (O’Reilly).

the key is to focus on understanding “why” a need or problem is worth solving (or not).

Themes Are About Outcomes, Not Outputs

By asking yourself (or whomever is requesting a particular feature) why, you are attempting to discern the difference between the output requested and the result or outcome desired.

you are attempting to distinguish the end from the means.

you must tie the themes on your roadmap back to your strategic objectives.

I. Product vision The problem you’re solving, or the change you want to see in the world II. Objectives The high-level goals you want to accomplish in this next version of the product III. Themes and subthemes The customer needs or problems that you are addressing

every step in the roadmapping process is incremental and builds on the one before it.

If any theme on your roadmap does not map back to an objective, this should be a warning sign.

every theme on your roadmap should relate to at least one of your strategic objectives!

Linking themes to objectives will then ensure you’re moving in the right direction and will increase the chances of your product adding real value—to your business, your customers, your technology, or all of the above.

Figure 5-6.

Error: should be figure 5-8.

the roadmap “describes our platform development plans for the benefit of developers creating tools that interact with Slack.”

Sarela Bliman-Cohen explains, “In order to have a good roadmap, you need to look at the markets you’re after. You need to identify the ones where you can succeed. Once you understand the markets you’re after, then you can have a thematic roadmap.”

Opportunity Solution Tree see Teresa Torres’ blog: https://www.producttalk.org/opportunity-solution-tree

Probable solutions First, some teams decide to include “probable” solutions on the roadmap.

Infrastructure solutions Second, infrastructure solutions often appear on a roadmap.

Carryover solutions A third common scenario relates to carryover.

Buffer’s public roadmap on Trello

When considering whether to add features to your roadmap, ask yourself these questions: Do we have enough understanding of the need and possible solutions to feel confident in a particular solution? Do we have any validated solutions from previous release plans that did not get completed and need to be carried over? Do we have any validated infrastructure needs? Do we have any mandates from decision-making stakeholders that must be addressed? What is the likelihood that this solution will be changed, postponed, or dropped form the schedule (i.e., what is your confidence)?

Using Stage of Development