# Product Discovery & Scoping

Turns a request into a scope that can be estimated, staffed and shipped — with everything still unknown named rather than filled in.

## Deliverable

One Markdown document, `scope-definition.md`, in the structure set out under **Output** below. It is the input to **Roadmapping & Prioritisation**.

## Required inputs

- **The request, in the requester's own words** — a brief, an email, a ticket or a meeting transcript. One is enough; more is better.
- **A named approver** — the person who can sign off the outcome statement. Without one the result is a proposal, not a scope.

If either is absent, stop and report it. Never infer a request from a codebase: code shows what was built, not what was wanted.

## Optional inputs

- Repository access, system documentation, schemas, API contracts
- Workflow descriptions, support tickets, user interviews, analytics
- Budget, deadline, regulatory or contractual constraints
- Earlier attempts at the same problem, and why they stopped

Every optional input that is absent becomes an entry under **Open questions**. It never becomes a guess.

## Execution

**1 — Separate the request from the problem.** Record the request verbatim with its source and date. State the problem it implies: who has it, how often, and what it costs them now. If the problem cannot be stated without naming a feature, the problem is not yet known — write that down and continue.

**2 — Inventory the current state.** From the supplied material only, list the systems, data stores, integrations and manual work-arounds on the path being changed. Tag each one `observed` if it was found in a file or system you were given, or `reported` if a person stated it. An element that is neither does not go on the list.

**3 — Draft the outcome and its measure.** One sentence of what must be observably different after launch; one metric; its current value; its target. A current value that was not supplied is written `unknown — required before approval`, never estimated.

**4 — Record the constraints.** Budget, dates, regulation, systems that may not change, integrations that must keep working. Each with the source that stated it. A constraint with no source is an assumption and is filed as one.

**5 — Cut the scope three ways.** `Ships first`, `Deferred`, `Out of scope`. A `Ships first` item must be useful on its own and must trace to the outcome in step 3. An item that traces to nothing moves to `Deferred` or `Out of scope`, with the reason written down.

**6 — Tag every statement.** `fact` with its source, `assumption` with what would confirm it, or `decision` with who made it and when. An untagged statement is a defect in the document, not a shortcut.

**7 — Collect what is missing.** Every question the steps above could not answer, each with what it blocks and who can answer it.

## Output

`scope-definition.md`, in this order:

- **1. Request as received** — verbatim, with source and date
- **2. Problem statement** — who, how often, what it costs, tagged
- **3. Outcome and measure** — outcome, metric, current value, target, approver
- **4. Current state** — one line per element: name, type, `observed` or `reported`, and the evidence
- **5. Constraints** — one line each: constraint, value, source
- **6. Scope** — the three lists; each `Ships first` item names the outcome it serves, each `Deferred` item the condition that would bring it forward, each `Out of scope` item why it is out
- **7. Assumptions and risks** — the statement, what would confirm it, and what changes if it is wrong
- **8. Decisions** — the decision, who made it, when, and the alternatives rejected
- **9. Open questions** — the question, what it blocks, who can answer it

## Validation

The document is ready when all of these hold:

- Section 3 names an approver and a metric; a target may read `to be set by <name>`
- Every `Ships first` item traces to the outcome in section 3
- Every statement in sections 2 to 6 is tagged `fact`, `assumption` or `decision`
- No figure appears without a source; `unknown` is a valid and expected entry
- Section 9 is either non-empty or states explicitly that nothing is outstanding

Fail the run if a `Ships first` item traces to nothing, or if any number in the document has no source.

## Failure handling

- **No request supplied** — stop. Report that discovery has no input and cannot infer one.
- **No approver** — produce all nine sections and mark section 3 `UNAPPROVED`. A scope in that state may not be estimated.
- **No access to the existing system** — section 4 is `reported` only. State plainly that nothing was verified, and that every downstream estimate inherits that uncertainty.
- **Contradictory inputs** — record both, name both sources, and raise the contradiction in section 9 as blocking. Do not resolve it by choosing.
- **Partial material** — produce every section the material supports, mark the rest `INCOMPLETE — pending <question>`, and deliver. A partial scope that is honest about its gaps is usable; a complete-looking one that filled them is not.