The Opportunity Backlog: A Living List of Jobs Worth Solving

An opportunity backlog is a persistent, scored list of customer jobs and desired outcomes — not features — that a product team maintains across quarters and reorgs. Unlike a feature backlog, which tracks solutions and rots the moment priorities shift, an opportunity backlog tracks the underlying problems, so it stays useful no matter who ends up running the roadmap.

An opportunity backlog is a living inventory of customer jobs, desired outcomes, and opportunity scores — refreshed on a set cadence — that survives reorgs because it tracks problems, not solutions.

What Is an Opportunity Backlog, Really?

An opportunity backlog is a structured, continuously updated record of the jobs customers are trying to get done, the outcomes they use to judge success, and how well those outcomes are currently satisfied. It comes from the Jobs-to-be-Done framework, not from a running tally of feature requests dumped into a ticketing tool.

The distinction matters because the two artifacts answer different questions. A feature backlog answers "what should we build next?" An opportunity backlog answers "what is worth solving, for whom, and how do we know?" The second question changes far less often than the first.

Clayton Christensen and Bob Moesta formalized this in their JTBD work: customers don't buy products, they "hire" them to make progress on a job. If you want the full grounding in that theory before building your own backlog, read this complete guide to Jobs-to-be-Done — it covers the vocabulary an opportunity backlog depends on.

A row in a well-built opportunity backlog typically survives:

• A reorg that eliminates the team that captured it
• A pivot in go-to-market strategy
• A change of CEO, VP Product, or entire leadership layer
• Two or three failed attempts to solve it

Try that with a row on a feature backlog. Most don't survive the next sprint planning meeting, let alone a leadership change.

Feature Backlog vs. Opportunity Backlog: What Actually Changes

A feature backlog lists proposed solutions ranked by guesswork or the loudest stakeholder in the room; it decays within a quarter because the solutions it names go stale, get shipped, or get vetoed. An opportunity backlog lists customer jobs and outcomes ranked by evidence-based scores; it stays relevant for years because problems change far more slowly than solutions do.

Ask any engineering lead what happens to a backlog item once it crosses into a sprint, and you'll hear some version of the same story: the ticket gets re-litigated. Acceptance criteria drift. The original "why" gets lost between the PM who wrote it and the engineer who built it three sprints later.

Job statements are more resistant to that drift because they describe a stable want, not a stable implementation. Melissa Perri's "build trap" framing captures the failure mode well: teams that organize backlogs around outputs (features shipped) instead of outcomes (jobs satisfied) end up busy but not effective. If your job statements keep getting reinterpreted by the time they reach a sprint board, this piece on writing job statements that survive the engineering handoff is the fix.

There's also a volume problem with feature backlogs that an opportunity backlog avoids. Industry usage-tracking research popularized by the Standish Group has, for years, pointed to a majority of shipped features going rarely or never used by customers. That's not a knock on any one team — it's what happens when a backlog is stocked with guesses instead of scored, evidenced jobs.

The Six Fields Worth Tracking on Every Row

A usable opportunity backlog needs six fields per row: the job, the desired outcome, an opportunity score, a qualitative label, the customer segment, and the evidence backing all of it. Miss any one of these and the backlog quietly turns back into an opinion list dressed up as data.

A few notes on getting these right:

1. Job should follow a repeatable grammar so it can't be reinterpreted at the whim of whoever reads it later. If you haven't nailed that grammar yet, this guide on how to write a JTBD job statement format walks through the exact structure to use.
2. Outcome statements should be measurable and solution-free — "minimize," "reduce," "increase" plus a metric, never a feature name.
3. Segment matters because the same job can score completely differently across cohorts; a job that's underserved for enterprise buyers might already be overserved for solo users.
4. Evidence is the field most teams skip, and it's the one that turns the backlog from a list of opinions into something you can defend in a prioritization debate.

Skipping the evidence field is the single most common failure mode. Without it, an opportunity backlog is just a feature backlog wearing a JTBD costume — nicer vocabulary, same underlying guesswork.

How to Score and Prioritize Without Gaming the Numbers

Anthony Ulwick's Outcome-Driven Innovation model gives the opportunity backlog its scoring backbone: Opportunity = Importance + max(Importance − Satisfaction, 0). Ask customers to rate each outcome on importance and current satisfaction, run the formula, and the outcomes with the widest gap between "this matters" and "we're not solving it" rise to the top.

That formula only works if the inputs are honest. A few disciplines keep it that way:

• Collect importance and satisfaction from the same respondents, in the same session, so you're not comparing two different populations' opinions.
• Re-run the survey on a fixed cadence rather than only when a debate needs settling — cherry-picked timing produces cherry-picked scores.
• Pair the numeric score with a qualitative label (underserved, overserved, table stakes) so a stakeholder skimming the backlog gets the story, not just a decimal.
• Segment the score. A single blended average across all customer types flattens exactly the signal you're trying to surface.

If you want the full derivation and worked examples behind that formula, the opportunity score formula explained breaks down each term and shows how the gap calculation behaves at the extremes.

A practical scoring workshop tends to run in five steps:

1. Pull the top 15-20 candidate jobs from recent interviews and support themes.
2. Draft an outcome statement for each job with a product coach or research lead reviewing for solution-free wording.
3. Field a short outcome survey (importance + satisfaction, 1-10 scale) to a segmented sample.
4. Compute the opportunity score for every outcome and sort descending.
5. Assign labels and evidence links, then freeze the backlog until the next scheduled re-survey.

Note that an opportunity score answers a different question than a RICE or Kano score. RICE estimates the value of a specific initiative you're already considering; the opportunity score identifies which underlying job deserves an initiative in the first place. They're complementary, not competing — score the opportunity first, then RICE-score the candidate solutions once you've picked a job to attack.

The Re-Survey Cadence: Keeping the Backlog Alive as the Market Shifts

A backlog only stays "living" if satisfaction scores get refreshed on a schedule, not just when someone remembers to ask. The right cadence mixes a light quarterly pulse, a full annual re-survey, and event-triggered updates whenever something in the market changes the calculus — a new competitor, a pricing shift, or a regulatory change.

A backlog stocked with solutions ages like fruit. A backlog stocked with scored jobs ages like wine — but only if someone keeps tasting it.

Market shifts don't just change satisfaction; they can change which jobs matter at all. A new entrant can make a previously "table stakes" outcome suddenly underserved across the whole category, because customers now have a working alternative to compare you against. That's a systems-level effect, not a single-metric one, which is why it helps to view backlog drift through a systems-thinking lens on market and product dynamics — reinforcing loops in a market rarely show up in a single survey question.

Emotional context matters too. Satisfaction with an outcome often tracks closely with where that outcome sits on the customer's broader experience. Re-surveying alongside a refreshed customer journey map tends to surface why a score moved, not just that it moved — a job's satisfaction can drop because a competitor improved, or because your own product introduced friction somewhere upstream in the journey.

A simple discipline keeps this from becoming busywork:

1. Calendar the quarterly pulse and annual refresh before the quarter starts, not after a debate makes it urgent.
2. Maintain a standing list of "market shock" triggers (named competitors, pricing changes, regulatory dates) that automatically queue a re-score.
3. Log every re-survey result against the same row rather than creating a new one — the history of a score moving is itself useful evidence.
4. Retire a job only when satisfaction is consistently high and importance has genuinely declined, not just because it's been open for a while.

Where Prodinja Fits: From Spreadsheet to Persistent System of Record

That persistence is the whole point of an opportunity backlog: it's only durable if it's actually durable, technically and organizationally. A spreadsheet can do the math. It can't stop someone from overwriting a tab, losing the file in a reorg, or forgetting the evidence links lived in a separate folder. A tool built around the job-and-outcome model is designed to keep those pieces attached to each other by default.

Key Takeaways

• An opportunity backlog tracks customer jobs and outcomes; a feature backlog tracks solutions — and solutions decay far faster than problems.
• Every row needs six fields: job, outcome, opportunity score, label, segment, and evidence — skip evidence and the backlog is just opinions with better formatting.
• Ulwick's formula, Opportunity = Importance + max(Importance − Satisfaction, 0), only produces trustworthy scores when importance and satisfaction come from the same respondents in the same session.
• A living backlog needs a cadence: quarterly pulse checks, an annual full re-survey, and event-triggered re-scores when the market shifts.
• Job statements written in a stable, solution-free format survive engineering handoff and reorgs in a way that feature tickets never do.
• Opportunity scores and RICE scores answer different questions — score the opportunity to find the job, then RICE-score the candidate solutions.
• Tooling matters as much as the model: a backlog that autosaves and keeps evidence attached to each row is more likely to actually stay alive than one living in a spreadsheet.