The Opportunity Backlog Framework: A User-Focused Alternative To The Product Roadmap
Most of us are familiar with product roadmaps: documents that depict the release cadence of a series of features & functions in order to eventually arrive at an overall product vision. These documents often map out release schedules several months—sometimes years—in advance, and can be helpful for teams who need to fill & prioritize their product backlogs (prioritized lists of tasks to be completed by a scrum team). Logically, these roadmaps make a lot of sense; write down a list of things that need to get done, include deadlines, and complete the items on the list one-by-one. But, as Marty Cagan, product management guru, wrote back in 2012, one of the problems with product roadmaps “is that most people assume that when something goes on the product roadmap, that the team has every intention of building and launching this.” Cagan also stated that when teams actually take the time to validate items on a roadmap with users, they “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…).” Fortunately, there’s an alternative.
The more we experiment & collect feedback, the more we learn about our users, their needs, and what they value.
Product Roadmaps vs. The Opportunity Backlog Framework: An Analogy
🎻 Classical music is performed by professionals who are trained to sight-read pre-written musical arrangements and use their instruments to bring expression & feeling to that musical score. Lead by a conductor who helps the orchestra work together by moderating their dynamics and maintaining a uniform tempo, the written composition (often composed decades—even hundreds of years ago) is performed note-for-note by the musicians. There is no freedom to deviate from the written score. Ask almost any classically trained musician to improvise something on their instrument, and they’ll likely stare are you uncomfortably.
🎷 Jazz musicians’ approach to playing music focuses much less on written compositions. While elements of jazz tunes are often prearranged and rehearsed, jazz musicians play within an agreed upon framework consisting of tempo, time signature, and key/mode which allows each member of the group the freedom to improvise & explore. While playing, musical artists who specialize in jazz can respond to feedback from the audience and other musicians within the group, collaborating in real time and creating new compositions on the fly.
“There is no better example of democracy than a jazz ensemble — individual freedom but with responsibility to the group; in other words, individual musicians have the freedom to express themselves on their instrument as long as they maintain their responsibility to the other musicians by adhering to the overall framework and structure of the tune.” [Source]
Rather than adhering to a roadmap document written months ago that outlines exactly what someone decided the product team needs to build, team members using the opportunity backlog framework have “Individual freedom… to express themselves… by adhering to the overall framework.” Not only is this freedom of expression more empowering to members of the product team, it provides the opportunity to change course and innovate based on user needs and is more effective at delivering products that your users will value. As opposed to product roadmaps which are about implementing pre-determined features, opportunity backlogs focus on identifying & solving problems via a constant feedback loop among makers & users.
Elements Of The Opportunity Backlog Framework
Anyone familiar with Design Thinking, Google Design Sprints, Lean UX, Hypothesis Driven Design, and comparable approaches will recognize similar elements throughout the steps of the opportunity backlog. Broadly, the framework is about understanding problems, developing testable hypotheses, and gathering actionable feedback. I’ve included specific syntaxes in this article to make it easier for teams to standardize how they articulate problem statements, hypotheses, etc. If your team already has a standard way to define these things, feel free to continue using what works. The steps of the framework are more important than how you format problems and hypotheses. I’ve included examples throughout to help clarify how to use the syntaxes. On to the steps…
Step 1: Identify & Define Problems
This is by far the most critical element of the opportunity backlog framework and where teams should spend the most time when reviewing the backlog. In fact, I’d argue that it’s the most important part of product design period. After all, you can’t deliver products that matter until you understand the problems & needs of your target audience. To dig deeper on this topic check out my post on how to define & use problem statements:
How do teams identify user problems? There are several signals to pay attention to, starting with (and most importantly) feedback from your target audience a.k.a. voice of the customer. You can get this feedback from user surveys, usability tests, and interviews. You can get it second-hand from customer service and sales representatives whose jobs consist of talking to customers and listening to their problems & needs every day. Assuming you already have a live product on the market, you can also review analytics to identify potential issues, e.g. bounce rates, time spent, fall off in conversion funnels, etc.
Once a problem has been identified it needs to be articulated. As I outlined in my post on writing problem statements, there are a couple syntaxes that I’ve had success with. For documenting problems within the opportunity backlog I’d suggest using the simpler Syntax B:
Here’s a specific example using the syntax: When I’m about to run out of dog food, I want to place an order for another bag so I can get it before my current supply runs out, but my order probably won’t arrive in time.
Problem statements should be written out and refined among the members of the product team. Don’t spend too much time wordsmithing, but make sure the team agrees that the statement effectively describes the problem, and that it’s a problem worth solving; then add it to the first column of the opportunity backlog, and prioritize its relative importance among the other problems. Repeat this process anytime and every time a new problem is identified.
Step 2: Describe The Opportunity
After defining a problem, reframe it via at least one “How might we…” statement to convert the problem into an opportunity for which the team can begin to conceive solutions.
Here’s an example based on the previous problem statement: How might we help customers make sure their orders arrive before they run out of their current supply?
Note: the example above could have been written as “How might we ship our products faster?” but that includes a specific solution (faster shipping) within the statement. Just like when writing problem statements, avoid using the How might we… format to incorporate or define solutions. More open ended statements can and will lead to more innovative solutions. The How might we… statements get placed in column 2, to the right of their respective problems.
Step 3: Define Your Hypothesis
You’ve articulated a problem, and presented it as an opportunity with at least one How might we… statement. Now it’s time to start conceiving potential solutions, but we’re going to use a bit more rigor than immediately jumping into sketching, prototyping, or coding. We’re going to write out one or more hypothesis.
The hypothesis syntax that I use includes the proposed solution that we will be testing, for whom the solution is intended, and how we’ll know whether or not we were successful. Again, if you already have a hypothesis syntax that works for your team, feel free to continue using it. The most important part of this step is defining what the team plans to do to fix the problem and what success looks like.
Hypothesis example based on the late dog food problem/opportunity: We believe a monthly auto-shipped pet food subscription for our customers who forget to re-order their supply will achieve a consistent and reliable supply of food, ensuring pet owners don’t run out.
Teams can and should come up with multiple hypotheses based on the problems/opportunities. Instead of a pet food subscription, maybe the solution could be a scale or container that weighs the amount of food and alerts the pet owner or auto-orders more when the supply gets low. Maybe it’s building more local warehouses across the country to store and deliver food faster. There’s very little cost to writing hypothesis statements.
Teams can post the hypotheses statements to column 3 of the backlog and decide which ones they actually want to build out and test. It’s probably much more costly to build pet food warehouses and distribution centers all over the country, so the team may decide to test the subscription model and see how well it solves the problem first.
Step 4: Create Concepts
Via Step 3, hypothesis definition, the team has decided what should be tested and knows what success looks like. Now it’s time to create a stimulus that we will use to get actionable feedback from the users whose problem we’re trying to solve. The goal for the team at this point is to deliver a Minimum Viable Experiment (MVE); i.e. something users can react to that most effectively tests the hypothesis with the least amount of effort for the product team to create.
There is no single way to produce an MVE. They can (and should) take many different forms depending on what the product team is trying to learn: hand-drawn sketches, lo-fi prototypes, fully-functioning code, user interviews, surveys, etc. Images or descriptions of your MVE can be added to column 4 of the backlog.
A potential MVE example for our pet food subscription hypothesis: A marketing email promoting a new monthly pet food subscription sent to customers who are often placing last minute food orders.
Step 5: Test & Validate
Once the MVE has been created it’s time to get it in front of the target audience that was defined originally in the problem statement and again in the hypothesis to collect user feedback. Using our MVE pet food subscription email example, the team could track open and click-through rates on the email, or track sign ups for the subscription service on a “Coming Soon” landing page. Take aggregate and verbatim user feedback about the concept and add it to the final column of the backlog.
After receiving user feedback we can determine whether or not the concept described in the hypothesis passed muster. Did it help solve the user problem? If yes, great — graduate to the product backlog! If no, great — now the team knows what doesn’t work! And don’t forget to share and celebrate what you’ve learned either way.
The more we experiment & collect feedback, the more we learn about our users, their needs, and what they value. New problems can be discovered along the way. New hypotheses & potential solutions can be developed and validated. It’s practice—a continuous cycle—always focused on identifying and solving user problems.
“Individual freedom… to express themselves… by adhering to the overall framework.”
This is the core difference between the product roadmap and the opportunity backlog. When we aim to solve problems, there will be many possible hypotheses and design solutions. Rather than simply building & delivering features listed on a roadmap, teams are free and empowered to understand user problems, validate hypotheses, and deliver design solutions. Maybe, through experimentation, the user experience improves, but the core user problem persists. Product teams can always look for new and innovative ways to solve the users’ problems more effectively, more satisfyingly via the opportunity backlog framework.
Working The Opportunity Backlog
Your opportunity backlog should be visible to your entire team as well as senior stakeholders and other product teams within your organization. It’s especially helpful to socialize user problems and hypotheses because there’s often overlap within organizations. Sharing the opportunity backlogs helps break down silos. For co-located teams it can be easily displayed on a wall or whiteboard with some tape, notecards, or post-it notes. Distributed teams can use digital collaboration products like Mural (my fav), JIRA, or Trello to post and share their opportunity backlogs.
Rather than a static product roadmap that’s created once and rarely revised, the point of the opportunity backlog is to consistently revisit (I recommend at least once/week) and revise it as a team—starting with identifying & prioritizing problems and working them through the steps of the framework. Just like accomplished jazz musicians who are comfortable playing and improvising within the jazz framework, working in an opportunity backlog framework takes practice and trust. Work regularly and collaboratively with your team to hone your skills identifying and defining problems, describing opportunities, and writing hypotheses. Make a goal to regularly produce and get feedback on design solutions. The more you work the backlog, the better the team will get at creating innovative solutions and delivering products that matter.
This Medium article is adapted from a workshop that I conduct with product & design teams interested in adopting the opportunity backlog framework to deliver products that matter. For questions, more information, or if you’re interested in having me conduct the workshop for your business or event, please feel free to contact me via LinkedIn.
