An opportunity describes a need or outcome that exists independent of any implementation; a solution names the mechanism used to meet it. The tell is simple: if you can ask "why do you want that?" and get a deeper, still-valid answer, you were looking at a solution. If the answer is just a restatement, you've found the real opportunity.
Quick Answer: A genuine opportunity survives having its proposed solution deleted — the need is still there, still true, still worth solving. "Add a dashboard" fails that test instantly; "I can't tell if my team is on track without checking four tools" passes it.
Why Backlogs Fill Up With Solutions Instead of Opportunities
Backlogs skew toward solutions because solutions are what stakeholders and customers can picture, name, and ask for by label — needs require one more step of abstraction nobody's incentivized to take. A sales call ends with "they want SSO," a support ticket says "add bulk export," and both get logged as if they were opportunities. They aren't; they're candidate answers to a question nobody wrote down.
This matters because the solution-shaped ticket looks actionable, which is exactly what makes it dangerous. It skips discovery, heads straight to a scoping conversation, and by the time anyone asks "what problem does this solve," three engineers have already estimated it. Teresa Torres, who popularized the opportunity solution tree, frames this as the core discipline gap: most product teams jump from a stated want directly to a build decision, never mapping the space of alternative solutions that a clearly stated need would have opened up.
The fix isn't more scrutiny at sprint planning — it's catching the disguise earlier, at the point of capture. A weekly discovery habit of running structured interviews, rather than logging whatever a single loud stakeholder said last, is what actually surfaces needs before they've calcified into feature names.
The Test: Does It Survive Without Its Mechanism?
An opportunity is a statement about a need, pain, or desired outcome that would still be true if you deleted every possible way of addressing it. A solution is a statement that names a specific mechanism — a feature, a UI pattern, an integration — as the fix. The test is mechanical: strip out the "how," and see what's left.
Run it in three steps:
- Read the request literally. Does it contain a noun that is a feature (dashboard, button, API, toggle, report)? That's a signal you're holding a solution.
- Ask "why do you want that?" three times if needed — this is the classic Five Whys technique, borrowed from Toyota's production system, applied to product requests instead of defects.
- Stop when the answer stabilizes. You've hit an opportunity when the next "why" just restates the same underlying pain in different words rather than revealing a new layer.
| Signal | Solution | Opportunity |
|---|---|---|
| Grammar | Names a noun/feature ("a dashboard," "a filter") | Names a state or gap ("I can't tell," "I don't know") |
| Survives deletion? | No — remove the feature and the request disappears | Yes — the need persists with the feature gone |
| Number of ways to solve it | Implicitly one (the one named) | Many, still unexplored |
| Origin | Often a stakeholder's or customer's own proposed fix | Requires one extra "why" to surface |
A request that survives step 3 with the same phrasing each time is your opportunity statement. Write it down verbatim — resist the urge to "productize" it into a feature name immediately, which is exactly the collapse this whole exercise exists to prevent.
Three Disguised Solutions and Their Reframes
Solutions hide inside requests that sound specific and reasonable, which is precisely what makes them convincing. Below are three common patterns pulled from typical B2B SaaS backlogs, each with the mechanism stripped out to reveal the actual need underneath.
"Add a dashboard"
The stated ask names a UI artifact — a dashboard — before anyone has asked what decision it's meant to support. Ask "why do you need a dashboard," and the honest answer is usually "I can't tell if my team is on track without pinging four different people."
- Solution as stated: Build a dashboard.
- Reframe (opportunity): Team leads currently have no reliable way to check project status without manual follow-up.
- What this unlocks: a Slack digest, a weekly automated summary, a status field synced from existing tools, or yes, possibly a dashboard — now competing fairly against alternatives instead of winning by default.
"We need bulk export to CSV"
This one is seductive because it sounds like an engineering estimate away from being solved. Push on "why CSV, why bulk" and you typically get: "I need to get this data into our finance team's reporting tool, and right now I do it row by row."
- Solution as stated: Add a bulk CSV export button.
- Reframe (opportunity): Users need data to move from our system into a downstream reporting tool without manual re-entry.
- What this unlocks: a direct integration, a scheduled sync, a shared API, or a CSV export — but now you know the destination matters more than the file format, which changes the entire solution shortlist.
"Can you add an approval toggle?"
Buried inside "toggle" is an assumption about exactly how control should be exercised. The underlying need is almost always: "Someone made a change without the right person knowing, and it caused a problem."
- Solution as stated: Add an on/off approval toggle before publishing.
- Reframe (opportunity): Changes are going live without the accountable stakeholder being aware, creating downstream risk.
- What this unlocks: a notification-and-undo window, a role-based permission model, an audit log with alerts, or an approval gate — now chosen based on how much friction the team can tolerate, not assumed by the first person who asked.
Notice the pattern across all three: the reframe never mentions a feature. It names who is affected, what they can't currently do or see, and why it matters to them. That's the shape a real opportunity takes, and it's exactly the shape the opportunity solution tree format is built to hold at the top of the tree, above any branch of candidate solutions.
Why Premature Solutions Collapse the Option Space
Naming a solution too early acts like a filter that removes every alternative before anyone's had a chance to compare them. Once a ticket says "add a dashboard," the team's cognitive frame narrows to dashboard variants — bigger widgets, more charts, better filters — and the far cheaper or more effective non-dashboard fix never gets considered.
This is a known failure mode with a name. Herbert Simon's research on bounded rationality describes decision-makers as "satisficing" — settling for the first option that clears a minimum bar rather than exhaustively comparing alternatives, especially under time pressure. A solution-shaped ticket hands teams exactly that shortcut: a plausible-looking answer that lets everyone stop searching.
The cost compounds in three ways:
- Estimation happens against the wrong thing. Engineering estimates the named feature, not the cheapest way to close the gap — so a two-day fix gets skipped in favor of a two-week build nobody compared it against.
- Validation gets skipped. A solution ticket reads as "already decided," so the team moves straight to build, skipping the customer discovery step that would have tested whether the mechanism actually addresses the need.
- Success gets measured wrong. Shipping "a dashboard" gets marked done when the dashboard ships — regardless of whether the team lead can now actually tell if their team is on track, which was the entire point.
Jobs-to-be-done thinking, formalized by Clayton Christensen and popularized further by Tony Ulwick's outcome-driven innovation work, exists partly to counter this collapse: it insists teams describe the job the customer is "hiring" a product to do, in outcome terms, before any solution enters the conversation. A team fluent in Jobs to Be Done framing has a built-in habit of asking "what job is this actually for" before writing the ticket title.
How to Catch Solutions Before They Reach the Backlog
The best point to catch a disguised solution is the conversation where it's first said out loud — not three sprints later during grooming. Interview technique matters more here than backlog hygiene, because by the time something is written as a ticket, the reframing work is much harder to do and much easier to skip.
The practical move is to treat any feature-named request as an interview prompt, not an answer. When a customer or stakeholder says "I want X," the immediate next move is a clarifying, non-leading follow-up — not "when do you need X by."
| Interview move | Example follow-up | Why it works |
|---|---|---|
| Ask for the underlying scenario | "Walk me through the last time this came up." | Surfaces the real trigger event, not the abstracted request |
| Ask "why" without judgment | "What made you land on that specific fix?" | Reveals whether the person already considered and rejected alternatives |
| Ask about the cost of not having it | "What happens today when you don't have that?" | Confirms the need is real and current, not hypothetical |
| Avoid leading, closed questions | Not: "Would a dashboard help?" | Leading questions confirm your own bias instead of testing it |
This is exactly the distinction covered in open, leading, and closed interview questions: a closed or leading question about the proposed solution just gets you a nodding "yes," while an open question about the underlying scenario gets you the actual need. Mapping where in a customer's day this pain shows up also benefits from a customer journey lens — a request that surfaces mid-task looks different from one that surfaces during onboarding, even if the stated ask is identical.
Interviewees jump to a feature name constantly — it's the natural, low-effort way to answer "what do you need." Prodinja's Customer Interview practice is built as a space to rehearse that specific follow-up moment: when a simulated interviewee names a mechanism, the practice walks you through asking the "why" that gets back to the underlying need, so the muscle is built before a real, time-pressured customer conversation puts it to the test.
Key Takeaways
- An opportunity survives deleting its solution; a feature request doesn't. Strip out the mechanism and see if a real need remains — that's the whole test.
- Grammar is a tell. Requests naming a UI artifact, button, or toggle are solutions in disguise; requests naming a state, gap, or inability are likely genuine opportunities.
- Three "whys" usually surfaces the real need, borrowed from the Five Whys technique — stop when the answer stabilizes into a restated pain rather than a new layer.
- Premature solutions collapse the option space, letting teams satisfice on the first plausible fix (per Herbert Simon's bounded rationality) instead of comparing real alternatives.
- Catch it in the interview, not the backlog. Open, non-leading follow-up questions at the moment a solution is first named are far cheaper than reframing a ticket three sprints later.
- Reframing changes what gets built, not just how it's described — a dashboard-shaped ticket and a "can't tell if we're on track" opportunity can lead to entirely different, cheaper solutions.
Frequently Asked Questions
What's the difference between an opportunity and a solution in product management?
An opportunity is a customer need or desired outcome stated independent of any fix — it survives even if you remove every possible feature that could address it. A solution names the specific mechanism (a button, dashboard, toggle) proposed to meet that need, and collapses the moment the mechanism is removed.
How do I know if a customer request is really an opportunity or just a feature wearing a disguise?
Ask "why do you want that" and see if the answer restates the same underlying pain in different words, or reveals a genuinely new layer. If the request names a UI element or specific mechanism and the "why" just circles back to the same feature, it's a solution; if it reveals a state, gap, or inability, it's an opportunity.
Why is it bad to write feature requests directly into the backlog?
Because a feature-named ticket looks pre-decided, teams skip the discovery and validation work that would have surfaced cheaper or more effective alternatives, and estimation happens against the named feature rather than the actual need — narrowing the option space before anyone compares it.
What's a practical technique for reframing a solution into an opportunity?
Use a version of the Five Whys: ask "why do you need that" repeatedly until the answer stops revealing new information and starts restating the same core pain — write that stabilized statement down as the opportunity, before any feature name re-enters the conversation.
Does every stated feature request contain a hidden opportunity?
Almost always, yes — even oddly specific requests ("add a red banner") usually trace back to a real underlying need (urgent alerts get missed). The rare exception is a request driven purely by a stakeholder's personal preference with no downstream user impact, which is worth naming honestly rather than manufacturing a fake need to justify it.