Product discovery and framing

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

1. State the decision. Write one sentence describing what must be decided and by when.
2. Build an evidence ledger. Separate observed evidence, stakeholder claims, assumptions, and unknowns. Attach a source and freshness date where possible.
3. Model the current situation. Describe the actor, context, goal, present workaround, friction, and consequence. Avoid demographic personas without behavioral evidence.
4. Frame the problem. Use: [Actor] struggles to [goal] when [context], causing [consequence]. Evidence: [sources].
5. Identify opportunities. Group needs by underlying outcome. Keep solution ideas separate until the opportunity set is visible.
6. Prioritize. Score opportunities using user impact, strategic value, evidence strength, urgency, effort uncertainty, and reversibility. Show the reasoning, not just a number.
7. Define hypotheses. Express the expected behavior change, who experiences it, why it should occur, and what evidence would disconfirm it.
8. Set success criteria. Choose one primary outcome, supporting indicators, guardrails, and a time horizon. Do not use output volume as the outcome.
9. Choose the next evidence step. Prefer the smallest study, prototype, data query, or technical spike that resolves the highest-risk uncertainty.

Output contract

Return:

1. decision statement;
2. evidence and assumptions table;
3. current-state problem frame;
4. prioritized opportunity list;
5. hypothesis and success measures;
6. constraints and non-goals;
7. unresolved risks;
8. 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.