Recently I was with my friend Jeff Patton, one of the pioneers in applying Agile to product organizations, and he told that he has been advocating the term “Opportunity Backlog” as an alternative to the product roadmap.
I have written earlier about the problems with old-style product roadmaps, so I immediately liked this and wanted to do my part to try to spread this concept.
Remember that the purpose of product discovery is to discover and then describe the product backlog. The product backlog is the output of product discovery.
Normally, the input to product discovery is the product roadmap.
The reason that both Jeff and I struggle with the old style “product roadmap” is that most people assume that when something goes on the product roadmap, that the team has every intention of building and launching this.
The problem is that if the product discovery team is truly doing product discovery, especially when they are validating the ideas with real customers and users as well as stakeholders, then they’ll typically find that at least half of what is on the roadmap is simply not worth doing (usually because the customer doesn’t value it as much as we had hoped, but there are several other reasons that we may decide this is not worth building).
So if the product roadmap has this baggage that can lead to serious waste of time and effort, Jeff’s idea was to reposition the roadmap as the “opportunity backlog.”
Many of you already use the technique of an opportunity assessment to scope out an opportunity and frame the work of product discovery. What Jeff is advocating is that the product owner maintain a prioritized list of opportunities in the form of an opportunity backlog.
As a reminder, the three most important questions on an opportunity assessment are:
- What problem are we trying to solve? (why are we doing this)
- Who are we trying to solve this problem for? (target persona)
- How will we know if we succeed? (what is the outcome we are hoping for)
The other big advantage of an opportunity backlog over a product roadmap is that it is very common to list specific proposed solutions on the roadmap (typically they are specific features by name), and a key purpose of an opportunity assessment is to untangle your initial ideas or assumptions about the solution from the problem that this feature is intended to solve. The reason this is so important to do is that so often our initial attempts at solving the problem don’t pan out, but the problem still remains. We want to make sure we solve the problem, even though we may have to try several different features or approaches.
Opportunities on the opportunity backlog can of course come from anywhere (just as with the product roadmap), but the two most important inputs are the product vision (the bigger picture of what you are trying to achieve), and the product scorecard (the prioritized business objectives for this team).
So to summarize, the opportunity backlog is the prioritized set of opportunities for the product discovery team to explore in product discovery. The output of product discovery is the product backlog, which is the prioritized set of work (usually represented as user stories and prototypes) for the delivery team.
In the next article I’ll talk about another technique that Jeff is advocating around the concept of time-boxing product discovery.