Opportunity Scoring

Most prioritization frameworks assume the list of candidates already exists. You can't multiply and divide until there are rows in the table. But look at where those rows came from and the answer is almost always inside the building: something sales heard while losing a deal, something an engineer found annoying, a feature the CEO saw in a competitor's product.

So no matter how carefully the scoring is done, anything missing from the list never gets built. A team can spend three days arguing over twenty candidates in a quarterly planning session and never once mention the thing users struggle with every day. Not because nobody knew about it — because there was no slot for putting it on the list.

Opportunity scoring moves the question one step earlier, to where the list gets made. Before asking what to do first, it asks users two things: how much does this matter to you, and how well does it go today? The outcomes where "it matters a lot" overlaps with "it goes badly" are the ones nobody has touched yet.

You collect two numbers per item through a user survey and put them into a fixed formula. There are five steps.

1. Write each item as an outcome, not a feature. "Know in time who left what on a document I shared" rather than "comment notifications." Ask about a feature and the answers split according to how each person pictures that feature working.
2. Pick who to ask. They have to be people who actually do the work, and you need dozens of them. Ask five people and a single respondent moves the average.
3. Ask twice per item. How important is this outcome, 1 to 10. How well does it go today, 1 to 10.
4. Run the formula. The score is importance plus the gap between importance and satisfaction, with a negative gap treated as zero. An item at 8.7 importance and 4.2 satisfaction scores 8.7 plus 4.5, or 13.2. An item at 5.1 importance and 6.8 satisfaction has a negative gap and stays at 5.1.
5. Sort by score and keep the top five or six. The list points at where to dig, not at what to build.

Negative gaps collapse to zero because investing further in something already going well doesn't register with users. An item whose satisfaction runs above its importance is a place that's been overbuilt rather than underbuilt.

The list from step 5 isn't a build order. For each place on it you generate several candidate solutions, then rank those through a framework like RICE that also weighs reach and effort. Opportunity scoring decides where to dig. The other frameworks decide which shovel to use.

The method pays off when you already have plenty of users and it's the candidate list that's thin. A product past its first year, with a growing user base and a roadmap discussion that never leaves the team's own heads, is the right situation. A product with no users yet is the wrong one — there is nobody to ask about satisfaction. User research with a handful of people in depth fits better there.

Asking users about satisfaction makes this look like the Kano model, but Kano asks how people react to a specific feature while this asks whether an outcome is going well.

Small samples flip the rankings. Below about thirty respondents, a gap of half a point between two items can't be separated from noise. The same holds when respondents don't match the actual user base. Survey thirty power users and the friction a brand-new user hits never shows up in the numbers at all.

There are three limits worth knowing.

1. It ignores cost. The highest-scoring item can be six months of work, and the formula has no slot for that fact.
2. It doesn't say whether the problem is solvable by you. When low satisfaction has a cause outside the product, the score comes out just as high.
3. The outcome statements are the ceiling. An outcome users have never considered isn't on the survey, and what isn't on the survey has no score. The method exists to widen the list, and it still only widens within sentences somebody wrote in advance.

"This one scores 13 and that one scores 5. Let's work from the top this quarter."

Start with the places users called important and rated as going badly.

"Drop the high-satisfaction items. Building more there won't register."

Don't spend capacity where things already work well enough.

"We only got 28 responses, so treat the ranking as directional."

The sample is too small for the gaps between scores to be trusted.

At Pagedeck, Mia runs this survey about three weeks before quarterly planning. She writes twelve outcome statements, sends them to roughly 400 active users, calculates the scores from what comes back, and pulls the top five. The planning meeting then puts those five on the wall and generates three or four candidate solutions for each.

Running it in that order changes the character of the meeting. Instead of everyone arriving with a feature they want to build and competing for it, people propose different solutions to the same problem. When Theo's approach turns out cheaper than Mia's, that gets settled on the spot.

The frequent mistake is reading the high-scoring items as the build list. The numbers arrive sorted, so they look like tasks. But the score attaches to an outcome, not to a solution. There are usually four or five ways to address a place scoring 13, and they range from a day of work to half a year. Convert score order into build order and you end up picking the most expensive option and then explaining why the plan slipped.

The other mistake is reading low satisfaction as a missing feature. Satisfaction is a sense that the outcome isn't going well, and it doesn't name a cause. The feature may be absent, but it may also exist and be hard to find, or exist and be slow. Ship something new without checking which one it is and the menu grows by one item while the score comes back unchanged next quarter.