Many of these critiques are valid. In fact, product leaders like Marty Cagan and Jeff Patton have even advocated for a roadmap alternative which they call an “Opportunity Backlog.” Before we take time to consider this option, though, let us first review the best way to use a roadmap.

Roadmaps Communicate Strategy

A roadmap reflects a product manager’s current thoughts on what business objectives are the most important to the enterprise. For instance, maybe the business wants to take the product into a new international market. Perhaps there is a need to support mobile devices. Or maybe the focus for the future is to address usability issues. The best product roadmaps are simply communication tools which describe how the enterprise goes from where they are today to realizing the product vision. 

In our experience, roadmaps are most effective when they provide a simple, high-level description of how to operationalize the product strategy. We have found when roadmaps are created collaboratively, they help product managers synchronize the focus of executive leaders, marketing, sales, architects and engineers on the objectives that really matter. When the goals described in the roadmap do not align to the product strategy — or when there is no product strategy — the roadmap has no context, and that is a serious problem. If you lack a clear understanding of your product strategy, then an opportunity backlog is not going to help you.

What is an Opportunity Backlog?

An opportunity backlog is a prioritized set of customer problems for the product development team to explore. It is a placeholder for ideas that have not been fully vetted by the product team BEFORE they are placed in a typical roadmap. When product ideas are placed in a buffer dedicated to experimentation and discovery, this enables product managers to untangle their initial ideas and assumptions about the customer’s needs and keep them separate from tasks already planned for execution. 

Ideas for the opportunity backlog can come from anywhere, just as with the product roadmap, but the most important inputs are customer feedback, market research, the product vision, the product strategy, and the list of business goals and objectives for the product. The owner of the opportunity backlog is the product manager or Product Owner. 

What Problems does an Opportunity Backlog Solve?

Opportunity backlogs address an unhealthy dynamic many product managers and Product Owners have observed with roadmaps — the assumption that if an item or request is present in the roadmap, the product team has committed to building and launching the item. When taken to its logical conclusion, this assumption transforms a roadmap from a high-level strategy document to a detailed list of features associated with delivery dates, which is a project plan and not a roadmap. This inaccurate understanding is why most product managers and development teams dislike roadmaps.  

 

In my experience, when product teams are engaged in product discovery — speaking and listening to customers, end users and stakeholders to validate their ideas and assumptions about the product — they often discover much of what is found in a traditional roadmap provides little or no value. In fact, the business should not pursue these ideas at all. And since “maximizing the amount of work not done” is one of the twelve principles of Agile Software Development this should be considered a win.

However, because the item in question is “on the roadmap” it sets off a chain of obligations. Product managers feel obligated to deliver the item because it was approved by the stakeholders. If not, they will have to explain — yet again — why they are missing delivery dates or why some promised feature was canceled, so they ask development teams to begin working on the item rather than pulling it off the roadmap. The engineers, who know more about the product than most people in the organization, feel frustrated and constrained by the roadmap because they know the work provides little or no value. 

Identifying Your Opportunities

With an opportunity backlog, product managers have the means to prevent the chain of obligations from starting. By recognizing everything in the opportunity backlog is speculative, the product manager, development team and stakeholders can delay committing to a capability until the last responsible moment. One-by-one, each idea in the opportunity backlog is evaluated against the three questions listed below. 

  1. What problem are we trying to solve?: how the product manager answers this question will be their response when development team members and stakeholders ask, “Why are we doing this?”
  2. Who are we trying to solve this problem for?: the answer to this question will provide sales and marketing the key information they need when they ask, “Who is our target persona?”
  3. How will we know if we succeed?: this last question helps the product manager define success. If they cannot come up with an answer to the question “What is the outcome we are hoping for?” they really do not understand the problem.

When these requests, or ideas, are embedded into a roadmap, arriving at clear answers to these questions is difficult because of the implicit assumption that something has to be delivered. Since no one considers the option of not doing the work, the development team and product manager thrash about trying to “make it work” rather than eliminating the idea. In those situations, what we see are development teams and product managers trying to solve the problem with more features and more functionality. This results in wasted effort on features and capabilities no one wants, missed delivery dates and uneven product quality.

With an opportunity backlog, though, product teams have a greater likelihood of remaining focused on solving the customer’s problems, even though they may have to try several different approaches. Unlike the roadmap, once an insight has been generated, the product manager has three choices: 1) promote the idea from the opportunity backlog to a low-level work queue (like a Product Backlog) or a high-level work queue (like a roadmap); 2) stop working on the idea; or 3) formulate another experiment.

Building an Opportunity Backlog

When collecting opportunities to put into an opportunity backlog there are three crucial elements one must have: description, order and value. Without these elements, which should be familiar to those who have worked with a Product Backlog, the product manager cannot properly capture the idea. This expanded list (see below) describes our preferred approach to documenting an opportunity backlog. However, feel free to extend this list for opportunities related to your product or service under development.  

  1. Description: A short phrase, or sentence, that serves as the placeholder for the broader opportunity. If you recall the three questions introduced earlier, this placeholder is very likely a hypothesis. 
  2. Order: Represents a forced ranking of the opportunities from 1 to n. Remember, no two items can have the same ranking at the same time.
  3. Value: Measured as typical “high,” “medium,” or “low” that nearly all product managers are familiar with. Value is based on the professional judgement of the product manager.
  4. Source: This element clarifies the origin of the opportunity. We recommend using a categorization provided by Alpha’s 2020 Product Management Insights Report, which ranks the quality of different sources of ideas: direct customer feedback (best), team brainstorming, market research, competitor, sales team, executives, crowdsourcing (worst). 
  5. Expiration date: Not all opportunities are equal and some opportunities are time sensitive. Capture this information with this factor or mark it as “not applicable.”

 

We provide a downloadable framework to help you start creating an Opportunity Backlog of your own. 

Or if you would like more help creating an Opportunity Backlog, or working on other solutions for your company, contact one of our experts to see how we can help.  

The Product Playbook: More to Come…

This is Part 4 in our series on Product Playbooks.

  1. Our first article was Product Playbooks: Why You Need One.
  2. The second was How to Build a Product Roadmap.
  3. Number three was How to Build a Customer Journey Map.

We will continue to share more step-by-step instructions on how to use some common frameworks to inspire you to create your own winning Product Playbook, so be sure to follow us on Linkedin, Twitter and/or Facebook to get notice of when new blogs are posted, and when you can come back and learn more!