product-frame
Product Frame
Two motions, one skill: establish what we actually know, then be ruthless about what it means. Fictional personas launder assumptions into confident-sounding facts; feature requests are solutions wearing a problem's clothes. This phase converts both into something falsifiable — tagged evidence, a pressure-tested assumption ledger, a problem statement traceable to it, non-goals, and success signals. The most valuable outputs are often the Unknowns list, the challenged assumptions, and the non-goals.
Part of the product-define suite. Read design/context.md first; write design/evidence.md and design/problem.md from assets/problem-brief.md; update context.md's User / Job / Problem / Desire / Sandbox / Aging / Evidence / Unknowns / Success signals. Gate 1 runs against this skill's output. On low-evidence-need engagements, run frame-only against existing evidence. When evidence is thin, escalate per assets/research-depth.md — deepen frame, do not skip to concept.
Quick Reference
| Topic | File | Read when |
|---|---|---|
| Desire, sandbox, aging templates | assets/sandbox-card.md | Before writing problem.md / before concepting |
| Cold-readable problem.md skeleton | assets/problem-brief.md | Framing deliverable |
| Current-state Mermaid recipes | assets/diagram-recipes.md | Workflow / artifact diagrams |
| Deep research + assumption ledger | assets/research-depth.md | Thin evidence or pressure-test |
Core Principles
- Inspect what exists before asking for anything. In order of availability: the codebase and current product behavior, existing PRDs/briefs/strategy docs and past experiment readouts, support complaints, issue tracker, analytics/telemetry, past research, customer quotes in docs/CRM, sales and field feedback, workflow artifacts (the spreadsheets people actually use), adjacent screens solving cousin problems.