opportunity-solution-tree

Start with one measurable business outcome, then map user opportunities (framed as needs, not solutions) that could drive it. Generate at least three solutions per opportunity, list the assumptions behind each, and prioritize small experiments to test the riskiest assumptions first.

An opportunity is a user need or pain point, such as 'PMs struggle to see who is overloaded.' A solution is something you might build to address it, like a workload dashboard. Keeping them separate prevents premature commitment to one idea.

Yes, but the tree will be hypothesis-based. The Skill asks what you know about why users are not achieving the outcome and helps generate opportunities to validate, though grounding each opportunity in interview or data evidence is strongly recommended.

A good outcome is measurable, achievable by the team, and specific, such as 'increase trial-to-paid conversion from 12% to 18%.' Vague goals like 'improve the product' are rejected and refined into a metric that would move if the initiative succeeds.

Avoid it when you have multiple outcomes at once, since each tree supports only one outcome, or when the solution is already committed and validated. In those cases, execution planning or PRD writing is a better fit than discovery mapping.