Product Discovery

Distinguish what someone asked to build from the problem it should solve, and permission to build from evidence that it will help.

When useful

Use when the problem, useful scope, intended users, or expected benefit is materially uncertain. Reuse existing observations and accepted decisions. Skip discovery for a clear bounded request with a known problem; do not restart an interview or demand market research for an internal tool.

This method is advisory unless the current assignment gives it a governed home. It creates no execution permission, product authority, gate, required document, or new agent. Existing role and workflow contracts govern decisions, questions, mutations, and completion.

Method

1. Ground the problem. Name the affected person or integration, context, desired outcome, and present obstacle. Separate direct observations, user reports, external evidence, inference, and unknowns. Preserve source and limits; an imagined persona or walkthrough is not observed user behavior.
2. Separate need from proposed solution. Explain how the requested feature is expected to remove the obstacle. Where direction is genuinely open, compare a small number of meaningfully different same-goal approaches, including improving an existing path or doing less. Do not reopen fixed choices without material new evidence.
3. Find the smallest useful outcome. Describe an end-to-end improvement the intended user could actually use, not a collection of disconnected components. Preserve accepted scope and exclusions. A different goal, weakened guarantee, or material scope/risk change remains with its existing authority owner.
4. Expose the decisive assumptions. Identify what could make the approach unnecessary, infeasible, unusable, or too costly. Use risk-driven-planning to distinguish evidence needed now from uncertainty that can be carried. Get the cheapest authorized observation, comparison, prototype, or technical probe that could change the decision before elaborating dependent work. A probe involving writes still needs normal execution authority; calling it research does not grant it.
5. Define useful evidence. Separate delivery criteria (the feature works) from the expected benefit (the obstacle is reduced). Reuse an available baseline and name what observation would support or contradict the benefit, in which context, and at what useful checkpoint. Propose missing measures rather than silently making them accepted obligations. Do not require analytics, telemetry, exact numeric targets, or external users where a direct observation would suffice.
6. Return a decision-ready result. Explain the supported direction, smallest useful outcome, material uncertainty, and next evidence needed. A consciously authorized experiment may proceed with uncertain value; preserve that uncertainty. Do not claim an experiment, interview, probe, or benefit has been observed when it has only been proposed.