Product Discovery and Framing
Turn an ambiguous request into an evidence-backed decision frame. Do not use this skill to design screens, run evaluative usability testing, or justify a predetermined feature.
Required inputs
Collect what exists without blocking on perfect research:
- decision, deadline, and decision owner;
- affected users and current behavior;
- business outcome and constraints;
- existing research, product data, support evidence, and technical facts;
- assumptions already being treated as facts.
Label missing evidence instead of inventing it.
Workflow
- State the decision. Write one sentence describing what must be decided and by when.
- Build an evidence ledger. Separate observed evidence, stakeholder claims, assumptions, and unknowns. Attach a source and freshness date where possible.
- Model the current situation. Describe the actor, context, goal, present workaround, friction, and consequence. Avoid demographic personas without behavioral evidence.
- Frame the problem. Use:
[Actor] struggles to [goal] when [context], causing [consequence]. Evidence: [sources].
- Identify opportunities. Group needs by underlying outcome. Keep solution ideas separate until the opportunity set is visible.
- Prioritize. Score opportunities using user impact, strategic value, evidence strength, urgency, effort uncertainty, and reversibility. Show the reasoning, not just a number.
- Define hypotheses. Express the expected behavior change, who experiences it, why it should occur, and what evidence would disconfirm it.
- Set success criteria. Choose one primary outcome, supporting indicators, guardrails, and a time horizon. Do not use output volume as the outcome.
- Choose the next evidence step. Prefer the smallest study, prototype, data query, or technical spike that resolves the highest-risk uncertainty.
Output contract
Return:
- decision statement;
- evidence and assumptions table;
- current-state problem frame;
- prioritized opportunity list;
- hypothesis and success measures;
- constraints and non-goals;
- unresolved risks;
- recommended next evidence step.
Verification
Confirm that every major claim is sourced or marked as an assumption, the frame does not prescribe a solution, success measures describe user or business change, and the next step could invalidate the preferred direction. If stakeholders disagree, preserve the competing frames and name the evidence needed to choose between them.
Use information-architecture after the problem is framed around findability or structure. Use interaction-design after a workflow opportunity is selected. Use design-measurement-and-experimentation to operationalize success criteria.
1---2name: product-discovery-and-framing3description: Frame product opportunities from user, business, technical, and market evidence into testable problem statements, priorities, risks, and success criteria. Use before solution design when the team is unsure what problem to solve or why it matters.4---56# Product Discovery and Framing78Turn an ambiguous request into an evidence-backed decision frame. Do not use this skill to design screens, run evaluative usability testing, or justify a predetermined feature.910## Required inputs1112Collect what exists without blocking on perfect research:1314- decision, deadline, and decision owner;15- affected users and current behavior;16- business outcome and constraints;17- existing research, product data, support evidence, and technical facts;18- assumptions already being treated as facts.1920Label missing evidence instead of inventing it.2122## Workflow23241. **State the decision.** Write one sentence describing what must be decided and by when.252. **Build an evidence ledger.** Separate observed evidence, stakeholder claims, assumptions, and unknowns. Attach a source and freshness date where possible.263. **Model the current situation.** Describe the actor, context, goal, present workaround, friction, and consequence. Avoid demographic personas without behavioral evidence.274. **Frame the problem.** Use: `[Actor] struggles to [goal] when [context], causing [consequence]. Evidence: [sources].`285. **Identify opportunities.** Group needs by underlying outcome. Keep solution ideas separate until the opportunity set is visible.296. **Prioritize.** Score opportunities using user impact, strategic value, evidence strength, urgency, effort uncertainty, and reversibility. Show the reasoning, not just a number.307. **Define hypotheses.** Express the expected behavior change, who experiences it, why it should occur, and what evidence would disconfirm it.318. **Set success criteria.** Choose one primary outcome, supporting indicators, guardrails, and a time horizon. Do not use output volume as the outcome.329. **Choose the next evidence step.** Prefer the smallest study, prototype, data query, or technical spike that resolves the highest-risk uncertainty.3334## Output contract3536Return:37381. decision statement;392. evidence and assumptions table;403. current-state problem frame;414. prioritized opportunity list;425. hypothesis and success measures;436. constraints and non-goals;447. unresolved risks;458. recommended next evidence step.4647## Verification4849Confirm that every major claim is sourced or marked as an assumption, the frame does not prescribe a solution, success measures describe user or business change, and the next step could invalidate the preferred direction. If stakeholders disagree, preserve the competing frames and name the evidence needed to choose between them.5051Use `information-architecture` after the problem is framed around findability or structure. Use `interaction-design` after a workflow opportunity is selected. Use `design-measurement-and-experimentation` to operationalize success criteria.
memi-design