Prioritize product opportunities before solutions

A roadmap often looks prioritized while hiding the decision that matters. It ranks solutions—add saved filters, rebuild onboarding, launch an AI assistant—before the team has agreed which user struggle deserves attention. Once an idea has a name, mock-up and executive sponsor, scoring frameworks can create precise arithmetic around an untested premise.

The stronger sequence is outcome, opportunity, risk, evidence and only then solution commitment. An outcome describes the change the product must create. An opportunity is an observed need, pain or desire that could influence that outcome. Risk identifies what must be true. Evidence tells the team whether the next investment is justified.

This article covers the upstream decision: choosing where to invest discovery. It complements, rather than repeats, a decision contract for an individual experiment.

Start with a product outcome, not a delivery target

A useful outcome describes a change in user or business behavior within a defined population and period. “Ship bulk actions in Q4” is an output. “Reduce the share of new operations managers who abandon their first reconciliation from 42% to 28% within eight weeks” is an outcome. It gives the team a direction without pre-selecting the interface.

Choose one primary outcome for the decision cycle and add guardrails. The outcome should be close enough to the team’s work to move, but meaningful enough to matter. Revenue may be too distant for a settings team; button clicks may be too local to represent value. A leading indicator such as successful first reconciliation can connect the user’s progress to retention while support contacts and error corrections act as guardrails.

Write the baseline, target, population, time window and source of truth. If the baseline is unknown, instrument it before promising an uplift. Do not turn an aspirational number into a fact. The metric is a decision boundary: it tells the team which opportunities are relevant and how later evidence will be judged.

Convert research into opportunities, not feature requests

The GOV.UK discovery guidance recommends reframing a proposed solution as a problem and understanding users, their wider context and the constraints around the service. Its user-needs guidance asks teams to learn what people are trying to do, how they do it now and where they struggle. That produces better inputs than a list of requested features.

An opportunity should describe the user’s situation and desired progress without prescribing the interface. “CSV importer” is a solution. “I need to correct hundreds of mismatched rows without losing the work I already reviewed” is an opportunity. Keep the actor, context, struggle and consequence. Attach direct evidence: interview clips, support cases, funnel events, session observations or sales-loss notes.

Separate an observation from its interpretation. “Seven of ten observed admins opened the same order in another tab before approval” is an observation. “They do not trust the summary” is a hypothesis. Store both, but label them correctly. Also record the segment and frequency; three enterprise administrators with a regulated workflow do not automatically represent every customer.

Merge duplicate wording only when the underlying progress is genuinely the same. Similar feature requests can hide different jobs. An export request may mean audit evidence for one segment, offline collaboration for another and performance escape for a third. Collapsing them too early destroys the context needed for a good decision.

Map the opportunity space before comparing solutions

An Opportunity Solution Tree connects a desired outcome to customer opportunities, possible solutions and assumption tests. Its value is not the diagram itself; it prevents a team from treating the first idea as the only route to the outcome.

Build the top two levels first. Under the outcome, group opportunities by meaningful user progress, not by screen or department. For the reconciliation example, branches might include “understand why a row failed,” “fix many errors safely,” “resume after interruption” and “prove who approved the correction.” These branches can be compared before a solution wins political momentum.

Give each important opportunity at least two materially different solution approaches before estimating delivery. A guided correction flow, downloadable error workbook and rule-based auto-fix can address the same opportunity with different risks. If the team can imagine only one solution, it may still be discussing a disguised feature request.

Keep the map bounded. It is not a warehouse for every customer request. Archive branches that do not plausibly affect the current outcome, and link them to the evidence repository so they can be revisited. A small tree with explicit exclusions is more useful than a beautiful map no one can review.

Score uncertainty separately from importance

A high-impact opportunity can still be poorly understood. A well-evidenced opportunity can be too small to matter. One blended score hides that difference, so use separate lenses. Rate outcome relevance, reach or frequency, severity, strategic fit and confidence in the evidence. Then list the assumptions that make the opportunity valuable.

Use ranges and evidence labels rather than false precision. “Seen in 18 of 73 failed first reconciliations last month” is stronger than “high reach.” “Mentioned by two strategic accounts” is important context but not population frequency. Mark whether each input comes from measured behavior, direct observation, reported preference, internal judgment or analogy.

The team should also test product risk. SVPG describes four major risks: value, usability, feasibility and business viability. An opportunity may be real while a chosen solution fails one of these. For example, users may need bulk correction, yet an automatic fix could be unacceptable to compliance, difficult to explain or too risky to reverse.

A simple decision record can remain small:

outcome: successful_first_reconciliation
opportunity: fix_many_rows_without_losing_reviewed_work
evidence: 18/73 failures + 5 observed sessions
importance: high
confidence: medium
riskiest_assumption: users will trust a reversible auto-fix preview
next_evidence: prototype task with 6 target admins
review_on: 2026-10-09
owner: product_trio

Do not calculate a final score to avoid judgment. Use the record to make judgment inspectable: everyone should see which evidence supports the choice and which uncertainty remains.

Test the assumption most likely to reverse the decision

Ask, “What must be true for us to keep funding this path?” Then choose the assumption that is both important and weakly evidenced. Strategyzer’s assumptions-mapping guidance similarly separates importance from evidence so teams can focus experiments on what matters most.

Select the cheapest evidence that can change the decision. A five-minute comprehension check can reject confusing language. A clickable prototype can test whether users understand a reversible preview. A concierge workflow can test whether the promised outcome is valuable before automation. A production A/B test is appropriate only after the proposition and interaction are stable enough to justify exposure.

Define the decision before collecting evidence: continue, narrow the segment, change the opportunity, test a different solution or stop. Set a time and participant bound. Discovery without a decision date can become an endless search for certainty, while a deadline without a quality bar becomes theater.

Treat stated enthusiasm as weak evidence for future behavior. Prefer observed attempts, commitments, repeated usage, willingness to change a workflow or a measurable reduction in the target struggle. One evidence type rarely proves everything; combine qualitative explanation with behavioral scale where the investment warrants it.

Run a weekly decision review, not a backlog ceremony

Review the outcome, new evidence, changed confidence and next decision—not the number of interviews completed or prototypes produced. Every active opportunity should have an owner, a riskiest assumption, a next evidence step and a review date. If none exists, the item is not active discovery.

Limit work in progress. Three well-framed opportunities with rapid evidence loops are more useful than twenty simultaneous research threads. Keep a decision log with the date, evidence snapshot, choice and reason. When later data contradicts a choice, the team can learn whether the original evidence was weak, the segment changed or the execution failed.

Kill zombie opportunities. If an item survives repeated reviews without new evidence or a credible route to the outcome, archive it explicitly. If leadership chooses it for strategic reasons, record that as a constraint rather than retrofitting customer evidence to justify it. Transparency is more valuable than pretending every commitment emerged from discovery.

Connect selected opportunities to delivery with a clear handoff: target user, expected progress, known constraints, unresolved risks, success signal and guardrails. The solution can evolve while these decision boundaries remain visible. Product managers should preserve this chain when the roadmap changes.

The practical decision

Prioritization is not the act of sorting a feature list. It is the act of deciding which uncertainty deserves the next unit of time and evidence. Start with one measurable outcome, describe opportunities in the user’s language, preserve multiple solution paths, separate importance from confidence and test the assumption most likely to reverse the investment.

A defensible roadmap is therefore a consequence of discovery, not its starting point. It shows not only what the team intends to build, but why this opportunity matters now, what evidence supports it, what remains risky and when the decision will be reviewed.

Prepared by: Noor Yasser