product-requirements-doclisted

# PRD Authoring ## Purpose Most PRDs describe a solution and omit the boundary, so scope grows silently during build and nobody can say whether it grew or was always intended. This skill fixes the sections that actually prevent that: an evidenced problem statement, non-goals written as commitments rather than caveats, decisions recorded with their reasoning, and open questions that carry an owner and a date. ## Prerequisites - **Inputs:** the problem or opportunity with at least one source of evidence; the affected users or segments; the accountable product owner; the engineering and design counterparts. - **Access:** whatever evidence exists — usage data, support or service records, research notes, sales or account feedback, incident history. - **Required decisions available:** whether the work is committed or exploratory, and who signs off. If the work is unfunded exploration, say so at the top; the document's job changes. If there is no evidence for the problem, write the PRD's first open question as "what evidence do we have that this problem exists?" with an owner, and do not fabricate usage figures, adoption estimates, or revenue impact to fill the section. An invented number in a PRD is quoted for years. ## Data classification **Internal** by default; **Confidential** where the document contains unreleased plans, pricing, or commercially sensitive customer detail. Cite customer evidence by segment and source, never by named individual, account number,