An opportunity is an unmet outcome, not a solution already chosen

What it is

An outcome-defined opportunity names a kind of ending that some people have not stably reached, not a feature already picked. If you can say who, in what situation, is trying to get what done and currently cannot—without naming a widget—it is an opportunity. “Add a chatbot” and “make the button bigger” are solutions. Once a solution is the list item, later discussion can only back or kill that object; the problem itself drops out of inspection.

Why it happens

Outcomes outlast solutions. The same gap—confirming that an application is moving without waiting on a human—can be filled by notifications, a status page, an outbound call, or a policy change, means that are not equivalent. If the list item is already one of those means, the others never enter the comparison. Teams also find it easier to defend a solution: it has effort, an owner, a visual. An unmet outcome sounds empty, yet it is what the research actually observed. Writing the outcome as the item rescues the observation from an implementation fight.

Studying it

Rewrite every candidate as person—situation—desired outcome—evidence of current failure. Strip widget names, technology names, and brand names from the sentence; if they will not come off, go back to the observation and rewrite. Test with a counterfactual: would the item still hold under a completely different implementation? If not, it was a solution. Check the raw material that the outcome is what participants were pursuing, not a product attribute the researcher wished for.

Where it stops holding

Sometimes the research question is itself a comparison of two existing solutions; items may then be solutions—that is a bake-off, not opportunity identification. A regulator-mandated implementation (two-factor must exist) is not an opportunity, though it may reveal a real outcome gap such as “prove identity without dropping the work in hand.” Writing the outcome so empty that it says “a better experience” is equally unusable.

Applying it

• Ban control, platform, and algorithm names from opportunity cards; rewrite or demote them to a solution draft stored elsewhere.
• Give each card one observable failure as evidence: in which sessions this outcome was not reached.
• In review ask only “is this an ending we are willing to let someone reach,” not “will we build this feature.”
• Print the outcome list before ideation; every new idea must declare which card it targets.

Related

• Same group: Q4.15.2 Check that identification covers the key research evidence · Q4.15.3 One opportunity can map to mutually exclusive directions; do not narrow early · Q4.15.4 Record the tradeoff when business priority and user-value ranking conflict
• Adjacent: Q4.09 Ranking opportunities · Q4.08 Jobs to be done
• Search terms: outcome-defined opportunity · jobs to be done · problem-solution conflation