Product discovery

A feature request is an answer. Discovery is recovering the question it answers, and finding out whether the question is real. Most of the evidence you need already exists and nobody has read it.

When this fires

A request names a solution and not a problem; a plan rests on a belief about users that has never been checked; someone asks whether a thing is worth building. It does not fire when the problem and its evidence are already established and the job is to write the scope — that is prd-and-stories.

Procedure

1. Split the request into solution and problem. Write the request verbatim, then write the sentence under it: who is trying to do what, and what happens today instead. If you cannot write that second sentence from what you were given, that gap is the finding — say so before going further.
2. Name the person and the job. A named role doing a specific task on a specific occasion ("a support agent closing a ticket after a refund"), not a segment. Ask who is not affected too — a problem everyone allegedly has usually belongs to nobody in particular.
3. Read what the product already does. Find the current path through the code, the existing screens, the config, the feature flags. Half of all requests are for something that exists, is disabled, or is two clicks away from where the user looked. Report that outcome as a result, not as a failure to find work.
4. Harvest evidence already in reach before asking for any. Issue tracker and its duplicates, support tickets, changelog and past attempts at this, analytics and logs already collected, prior docs and decision records. Quote what you found with its source; a claim you cannot attribute is an assumption.
5. Grade every piece of evidence. Three grades, and keep them apart: observed (behaviour in logs, tickets, recordings, a failing workflow you traced), reported (a person says so — including the requester and the loudest stakeholder), assumed (nobody has checked). Say the grade next to the claim. Most "user needs" collapse a grade when written down honestly.
6. Write the load-bearing assumption as one falsifiable sentence. The one that, if wrong, makes the whole idea pointless. Phrase it so it can fail: "agents abandon refunds because the audit log is on another screen" — not "agents want a better experience".
7. Say what would falsify it, and what it would cost to look. Name the cheapest honest check that could return "no": a query against data you already have, a count of tickets matching a pattern, tracing five real cases end to end, watching the current workflow being used. Prefer a check you can run over one that needs someone else's calendar.
8. Run the checks you are permitted to run. Reading existing data and code is yours to do. Anything that reaches a person — a survey, an interview request, a message to a customer, a posted question, an experiment served to live traffic — is outward-facing: draft it, then stop and ask. Discovery never sends on its own initiative.
9. Report the decision the evidence supports, not the one that was hoped for. Three honest endings: the problem is real and here is what we know; the problem is real but different from the request; there is no evidence yet and here is the cheapest way to get some. "Proceed anyway" is a legitimate call for someone else to make — say what is being bet on.

Checklist

• The request is written down separately from the problem it claims to solve
• A specific person and a specific occasion are named, not a segment
• Current product behaviour was actually inspected, not assumed absent
• Existing evidence was searched before any new research was proposed
• Every claim carries a grade: observed, reported, or assumed
• One load-bearing assumption is written so that it could fail
• A named check that could falsify it, with its cost
• Anything that would contact a user was drafted and paused for approval, not sent
• What is still unknown is listed, not smoothed over

Failure handling

• No evidence exists anywhere. That is a finding, and a common one. Say the belief is unvalidated, give the cheapest check, and do not launder the requester's confidence into "user research shows".
• The only evidence is one loud stakeholder. Record it as reported, with the name. It may still be right; it is not yet observed.
• Analytics disagree with what people say. Report both and say which question each answers. Logs show what happened; people explain why. Neither overrides the other by default.
• The problem is real but the requested solution does not address it. Say so plainly, keep the problem, and hand the solution question on. Do not quietly redesign the request.
• Discovery would need to contact users and you have no approval. Stop. Prepare the questions and say what you would learn. An unapproved outreach is worse than an unanswered question.
• The pressure is to confirm. If every check you propose can only return "yes", you have designed a formality. Rewrite one that can return "no".

Evidence to report

The request as received and the problem statement derived from it; the person and job named; what the product does today, with file or screen references; every source you read, quoted, with its grade; the load-bearing assumption in falsifiable form; the checks run and what they returned, distinguished from the checks proposed but not run; and the list of open unknowns. "We validated the need" with no quoted source, no grade and no check is not evidence.