framing-the-opportunitylisted

# Framing the Opportunity ## Overview Good discovery keeps the **problem space** (understand the problem) separate from the **solution space** (generate solutions). Fully exploring the problem first yields more creative, better-targeted solutions. The single most common failure is **solution-jumping** — starting in the solution space before the problem is understood. This skill produces a tight **opportunity brief**: the outcome being pursued, the framed problem, and ideation-ready "How Might We" questions. ## When to use - Kicking off a discovery effort or a new initiative. - A request arrives pre-loaded with a solution ("build a dashboard") and the underlying problem is unstated. - Translating research findings into a framing the team can ideate against. ## Workflow **Guard:** If asked to "write requirements/specs" for a named solution, stop — produce the opportunity brief here and hand requirements to `writing-requirements` only *after* the outcome is agreed. Do not spec the named solution in this pass. Create a task for each and complete in order: 1. **State the desired outcome.** An outcome is *a change in customer behavior that drives business results* — not a feature. Write it measurably — but take the **metric and target from a stakeholder or product data**; if none is supplied, leave the number `[TBD]` (or propose-and-confirm), **never invent it** (a made-up target anchors downstream assumption/impact maps to a fake goal). If the goal is phrased as an output