skills/skills/discovery-framing/SKILL.md

---

name: discovery-framing description: Run the discovery / framing phase of product innovation — define and quantify a focused customer problem BEFORE any solution exists. Four movements: understand the problem space, learn about customers, identify and size problems, decide pursue/table/kill. Produces a problem brief per prioritized opportunity. Use when an idea is still vague, when someone is jumping to solutions before the problem is validated, when scoping early research, or when deciding which problems are worth pursuing. Trigger phrases include "frame the problem", "discovery", "problem statement", "is this worth building", "early research", "opportunity sizing", "we have an idea for", "how might we", "what problem are we solving".

Discovery / Framing

The phase before solutioning. Goal: define and quantify a focused customer problem, tied to a specific target segment, validated with external evidence — so that later investment rides on a real problem, not a pet idea. Products built on a validated problem have a materially higher success rate; solving an unvalidated problem builds something that solves nothing.

This is the de-identified pattern. When run for a named client, the wrapper (their phase names, internal tools, region structure, named teams) stays in the client boundary.

Pairs with stage-gate-review (this is the Frame→Concept gate's content) and the brain principle on solutions-looking-for-problems. Killing a bad problem here is the cheapest kill you will ever make.

---

The four movements

1. Understand the problem space   →  2. Learn about customers
         ↓                                      ↓
4. Decide: pursue / table / kill  ←   3. Identify & size problems

Typical envelope: weeks, not months; cheap. The whole point is to de-risk before spend.

1. Understand the problem space (the ecosystem)

Map the field before judging any idea. You are not validating a solution — you are learning the terrain.

• Ecosystem analysis — top trends, market size (the whole pie, not your slice), key players (end users, customers, intermediaries), competitors and their gaps.
• Value-exchange map — list every player; for each, the qualitative + quantitative value flowing to/from them; score it. A scalable ecosystem has roughly equal value per player — lopsided value = it won't scale across the chain. This is the single most overlooked check.
• External-forces scan (PESTL + localization) — Political, Economic, Social, Technological, Legal, plus local/regulatory constraints that break the business model in a given market.

2. Learn about customers and end-customers

• Personas / design targets — behaviours, needs & values, pain points, gains. Keep them universal where possible (cut across segments), specific where it matters.
• Journey maps — steps & touchpoints, emotional valence per step, pain points and opportunity areas. Separate the customer journey from the end-customer journey.
• Assumptions → hypotheses — dump everything you believe true about the target (quantity over quality), then prioritize on a risk × certainty grid: attack the assumptions that are high risk AND low certainty first. Sort each into Desirability (do they want it?), Feasibility (can we build it?), Viability (can we make money?). Convert each prioritized assumption into a testable hypothesis: "If we do X, then Y will happen" — falsifiable, specific outcome.
• Validate externally — research with real customers/end-customers (interviews, focus groups, surveys, diaries). Record per persona: assumption → learning → validated/invalidated. External validation is non-negotiable — a problem confirmed only internally is not confirmed.

3. Identify and size the problems

• Problem statement — one tight form: "[who] needs a way to [need], but [compelling insight from research]." The insight cites where/how the opportunity actually manifests, not a guess.
• Total Addressable Problem (TAP) — not market size. Market size is the pie-in-the-sky figure. TAP = (what would they pay to solve this specific problem) × (how many have it), summed across use cases. A subset of the market, honestly bounded. Sizing the problem — not the market — is what makes prioritization real.

4. Determine next steps

• Prioritize by TAP × strategic fit.
• Pursue / table / kill — every problem gets one verdict. Kill is a first-class output, not a failure; a tabled problem is parked with its reason.
• How-Might-We — reframe each pursued pain point as an open question to spark solution ideation. Use verbs, not nouns — never pre-pack a solution into the HMW. ("HMW increase awareness…" not "HMW build an app that…").
• Problem brief — one per pursued opportunity (see below). This is the deliverable that carries into the solutioning gate.

---

The Problem Brief (required deliverable)

A problem brief, not a solution brief. Fields:

1. Problem — "We believe [user/customer/market] needs a way to [need], because/but/ surprisingly [insight]." Quantitative proof where possible.
2. Customer — who has it; segment specifics; their pain points / desired gains.
3. End-customer (if different) — who you're ultimately innovating for.
4. Why it matters — to them and to you; what you observed that makes this a priority.
5. Ecosystem — relevant signals, localization needs, competitive/comparative landscape.
6. Total Addressable Problem — the bounded value of the problem.
7. Thought-starters / HMW — reframed questions, no solutions.
8. Desired value & outcomes — impact if the problem were solved.
9. Strategic benefit — how success is measured for the business; strategy fit.

If a brief drifts into describing a solution, it has failed — send it back to the problem.

---

Anti-patterns

• Solution smuggling — an HMW or brief that already names the answer. The discovery is over before it began.
• Internal-only validation — "we all agree it's a problem." That is conviction, not evidence. See stage-gate-gate-killers.
• Market size as problem size — quoting a $XXbn TAM to justify a narrow bet.
• Skipping the kill — every idea "has potential." A discovery phase that never kills a problem is theatre.
• Lopsided value exchange — a solution that enriches one player and starves another; it will not scale no matter how good the UX.

---

Operator judgment (hard-won)

Compressing discovery by stakes

• High-stakes bet: run all four movements hard — especially external customer research and the riskiest-assumption tests. Don't thin the validation.
• Low-stakes bet: keep movement 1 (ecosystem) + movement 3 (problem statement + a rough size). Size with TAM / SAM / SOM instead of a full Total Addressable Problem build.
• Customer research can be skipped or AI-simulated for low stakes — a well-framed agent, prompted as the target persona, can give a directional read fast. Treat this as a cheap directional signal only — it is not external validation and never clears a high-stakes desirability assumption. Use it to decide whether real research is worth doing.

The bar for "externally validated"

No fixed floor — case by case. The invariant is the posture, not the count: go looking for disproving evidence, not reinforcing evidence. A problem survives discovery when you tried to kill it with real external input and couldn't — not when N people nodded along. (Same disease as a faked gate — see stage-gate-gate-killers.)

Tell for solution smuggling

The solution is described crisply and confidently, but the moment you ask whose problem and how do you know, the answer goes fuzzy — the need is vague, the validation is hand-wavy. Crisp solution + fuzzy problem = reverse-engineered justification. Stop and reframe.

War-story patterns (de-identified)

• Sized big, fizzled in reality. A problem that scored a large TAP/TAM but never converted to sustained real-world usage. Lesson: problem size ≠ adoption. A big addressable problem measures willingness to care, not willingness to change behavior. Add a "would they actually switch/use it repeatedly?" test before trusting a large size.
• Tabled/iceboxed a valid problem others then won. A real problem killed or parked on weak conviction or bad timing, which competitors later executed well. Lesson: the kill is not free. Killing protects against sunk cost, but a wrong table is also a cost — record why you tabled and a signal that would reopen it, so a right problem killed for the wrong reason can come back.

Named instances of both war stories are client-tagged and held out of this public skill pending client-store decision. The transferable lesson lives here; the wrapper stays out.