The Opportunity Backlog

You've seen this movie. A roadmap full of features, dated and committed, marching quarter by quarter. It slips, the way big roadmaps always do. Dates move, scope gets cut. And the missed dates aren't even the problem. The features that do ship don't move the business.

No customer asked for half of it. Nobody validated the other half. By the time it shipped, the only thing you knew for sure was that you'd built it. Not that anyone would use it.

That's the build trap. A roadmap is how most teams walk right into it.

The opportunity backlog is the way out. A backlog of problems beats a roadmap of features. And that's not a slogan. It comes down to the one thing most teams get backwards: what you can actually measure.

Be obsessed with the problem

In my design thinking classes I teach one rule above the rest: be obsessed with the problem, not the solution. The reason is simple. You can measure a problem. You can't measure a solution that doesn't exist yet.

Take a process that eats 15 hours a week because someone is hand-keying data across 3 systems, hitting errors, and re-keying to fix them. You can hypothesize a solution that saves 8 of those hours. What you can't do is promise it. Too many variables sit between you and that number: technical, process, regulatory, company politics, and whether people actually change how they work. The improvement is a guess until you've run it.

The size of the problem, though, you can pin down. 15 hours, times the number of people doing it, times how often. That's a real number, and you can go get it.

I lived in San Francisco when Uber launched. Before that, I could never get a cab. I'd call one, and when it pulled up, whoever was closest climbed in and took it. So to get anywhere, I had to stay within a walk of public transit, or hike to a hotel where the cabs lined up. Nothing like Chicago, where they're everywhere and you just put a hand up.

There was no way to know, in advance, that Uber would work. None. You can't quantify the success of an app that doesn't exist. But the problem? That you could measure. How many people need a ride, and when. What rides cost. How big the market already was. Every bit of that is research you can do before you build anything.

So a roadmap full of solutions is a list of guesses dressed up as numbers. A backlog of problems is a list of numbers you can go get. And those numbers are your signal. Size the problem, count who it affects, and you can decide with something real: what to solve first, what to let sit, what to defend in the room. That's prioritizing by evidence, not by opinion.

What it is

The opportunity backlog is a prioritized list of customer problems for your product team to explore. Not features. Problems. You work them in priority order, and the output of that work is a validated solution you hand to engineering to build.

Read that again, because the sequence is the whole point. You validate the solution before engineering builds it. By the time anyone writes production code, you already have reasonable confidence the thing will get used. You're not hoping. You checked.

One credit while we're here, because I didn't invent this. Most of what follows builds on Marty Cagan's work, plus Teresa Torres on continuous discovery. Melissa Perri named the trap it gets you out of. What I'm adding is how it actually runs once it meets a real organization.

It doesn't float on its own. Vision sets the destination (that's Part 02). Strategy sets the route. The opportunity backlog is where strategy stops being a document and turns into real, validated work. Jim Carroll has an old innovation line for this: think big, start small, scale fast. The vision is the big part. The opportunity backlog is how you start small, then earn the right to scale.

The list gets fed company-wide. Everyone has input: sales, support, engineering, customers themselves. The product team owns ranking it and working it. And anything you're thinking about building should pass through here first. Not just to build the solution right. To find out if it's worth building at all.

The bet

Every opportunity is a bet, and the stake is engineering time. The whole loop exists to help you pick the right bets, keep the stakes small, and score them honestly.

You pick the bet with one question, and the order matters: should we solve this problem, and only then, can we. Should-we is worth far more than can-we. Plenty of things you're able to build aren't worth building.

You keep the stake small with speed. Speed to knowing whether a problem is worth solving, then speed to a solution that actually works. Your first attempt rarely does: it solves the problem badly, or in a way nobody wants to use. So the number of cheap iterations you can run before you commit engineering is the real lever. Protecting that is most of what this process does.

And you score the bet on outcomes, not output. You're measuring how well you solve the customer's problem, not how much you shipped.

The loop

Every opportunity runs the same six steps:

1. Define the Problem. Get close to the customer and state the real problem, in a way you can actually solve.
2. Opportunity Assessment. Decide whether it's worth solving: the value, the market, the competition, and whether you even should.
3. Hypothesis. Turn the opportunity into a testable belief, with the measures that tell you if you're right.
4. Design Concepts. Bring diverse people in, generate ideas, narrow to the best few, and prototype what you'll test.
5. Test & Validate. Run lean experiments to build confidence. Cheap, fast, in front of real customers.
6. Build / Pivot / Archive. Read the data and decide: build it, rework it, or kill it.

It's a loop, not a conveyor belt. You'll go from Step 2 to Step 3 and back to Step 2 when you find you're missing what you need to decide. That's the process working, not failing.

How it gets prioritized

Not everything gets worked at once. Items get sorted on a few things:

• Source. Where did it come from? Direct customer feedback carries more weight. An executive request, on its own, carries less.
• Value. High, medium, or low, set by the people closest to the problem.
• Time sensitivity. Some problems are only worth solving by a certain date. Most aren't, but when the window is real, it moves the item up.
• Order. The final rank. No ties, one item per slot, based on everything above plus judgment.

You don't work this alone

Sourcing problems company-wide is the easy part. The part most teams miss is that every step of the loop has people who should be in it. These are just a few examples to tell the story, not absolutes.

• Support and sales when you're defining the problem, because they hear it raw, every day.
• Finance and leadership when you're sizing the opportunity, because they hold numbers you don't.
• Engineering when you're shaping concepts, because feasibility input at the sketch stage is cheap and the same input after you've committed is expensive.
• Customers when you test. The right people, at the right step, when their input changes the decision.

Notice the qualifier: when their input changes the decision. Not everyone needs to be involved, and nobody needs to be involved in everything. The fastest way to stall a backlog is to let it turn into a committee, where people feel like they have to be in every item and the loudest voice starts steering.

The product team owns this work.

Ranking it, running the steps, making the calls. Bringing someone in is an invitation to contribute, not an open seat at the wheel.

So set the boundaries early and out loud: who owns the decision, what input you need, from whom, and at which step. People respect a clear lane more than an open door. And the opposite failure is just as real. A product team that works the whole loop in a silo surprises everyone with the result, and surprised people push back. You can't do this alone, and you shouldn't let everyone do it with you. Both are true at the same time.

Kill it at any step

Step 6 ends in "kill it," but don't read that as the only exit. You can kill an opportunity at any step of this loop, and the earlier you do it, the cheaper the lesson. Nothing says you have to carry a weak problem through all six steps just to make the process feel complete. The steps exist to build confidence, and the moment the evidence says there's nothing here, you're done. Archive it and move on to the next item.

It happens at the early steps all the time. You sit down to define the problem, talk to customers, and find out it barely registers: a mild annoyance, not a 15-hours-a-week bleed. Killed at Step 1. Or the problem is real, but the assessment shows the market's too small to matter, or a competitor already solves it well enough that winning would cost more than it returns. Killed at Step 2. Or you try to write the hypothesis and can't name a single measure that would tell you whether you're right. That's a sign the opportunity was never concrete enough to act on. Killed at Step 3. None of those are failures. Every one of them is engineering time you didn't spend on something nobody needed.

From backlog to build

When a solution earns enough confidence, it leaves the opportunity backlog and lands on the product backlog: a just-in-time list of validated solutions for engineering to build. That handoff isn't a wall you throw work over. It's a partnership that runs through the build and into measuring whether the thing actually worked once customers have it.

"But leadership wants a roadmap." I know. It's the most common objection, and it has a real answer, big enough that it gets its own page below.

Start with Step 1. We'll run a single problem through the whole loop at the end, so by the time you finish, the process isn't theory. It's something you've watched work.