mastermind-product-intake

Mastermind product intake

A PRD is written to decide whether to build something. A task contract is written to check whether it was built. They are different documents, and pasting the first into the second produces acceptance criteria that no gate can fail.

This is a planning step. It converts; it does not implement, and it does not judge whether the work is worth doing.

Name the source

Record the PRD, ticket, or document with a stable reference — an ID or a URL, not a title. "Per the spec" is unauditable: a product doc that moved on cannot be told apart from an implementation that drifted.

Sort every statement into three piles

This is the whole job, and most of the value is in refusing to blur them.

Behaviour — what the system does, observable at merge time. "An archived invoice is excluded from the export." This becomes acceptance criteria.

Constraint — a bound the behaviour must respect. "The export completes within 30 seconds for 10,000 invoices." This becomes a criterion only if you also name how it is measured. Unmeasured, it is decoration that reads like rigour.

Outcome — why the work exists. "Reduce support tickets about missing invoices." This is never acceptance criteria. It cannot fail at merge time, it resolves weeks later in production if anyone looks, and putting it in the contract means a mechanical gate marks it satisfied while nobody has measured anything.

A criterion that cannot fail on the day the change lands belongs in the outcome section, no matter how central it is to the PRD.

Resolve the nouns

Product writing names things: invoice, export, workspace, role, plan. Search each one before assuming it is new.

mmcg_search Invoice
mmcg_search exportInvoices
mmcg_api_surface src/billing/

A feature that reads as new is usually mostly existing surface with a gap in the middle. Say which nouns already exist as symbols, which exist under a different name, and which are genuinely new — that distinction changes the scope, the risk, and often the mode.