How to Write a Product Requirements Document With AI

Build an evidence spine before drafting

Start with five separate inputs: user evidence, business goal, constraints, candidate requirements, and success measures. Give every source a stable label such as U03 for an interview observation, S12 for a support ticket, or C02 for a security constraint. Ask the model to extract observations without converting them into features. This matters because a fluent draft can quietly turn one complaint into an invented universal need.

Use a table with columns for source ID, observation, affected user, frequency or sample context, confidence, and open question. The UK Government Service Manual recommends learning what users are trying to do, how they work now, and what problems they experience before planning a service. Its research-analysis guidance also separates observed behavior from interpretation. Those practices provide useful discipline for an AI-assisted evidence spine (research in discovery, analysis guidance).

Only after the evidence table is stable should AI propose problem statements. Require each proposal to cite source IDs and state what the evidence does not establish.

Sources: [1] [2]

Draft decisions, not decorative sections

A useful PRD answers a sequence of decisions: whose problem is in scope, what outcome matters, what constraints are fixed, what behavior the product must enable, what is deliberately excluded, and how the team will know whether the release worked. Ask AI to draft one section at a time from the evidence spine. Do not ask for a complete PRD from a vague prompt.

For every requirement, record its evidence basis, owner, acceptance condition, and unresolved dependency. Use requirement language that describes observable behavior. “The system should be intuitive” is not testable. “A participant can resume a saved draft after reconnecting without losing entered text” is testable, although its priority still needs evidence.

Worked example: source map to requirement

Imagine three synthetic observations. U03: two of six participants reopened a separate note because they feared losing form text. S12: four support tickets mention interrupted connections. C02: drafts may be retained for 24 hours. A defensible requirement is: “When a connection drops, preserve locally entered draft text and restore it after reconnection within the permitted retention window.”

The trace row links the requirement to U03, S12, and C02. Its acceptance check simulates a disconnect after text entry and verifies restoration. The PRD also records uncertainty: the small research sample does not establish prevalence, and the team still needs to test whether the recovery message is understandable.

A bad AI draft would say, “Users demand seamless autosave, which will increase completion.” Neither the universal demand nor the outcome is supported. Repair it by restoring the actual observations and separating the feature hypothesis from the evidence.

Verify the PRD before approval

Run a reverse trace. Starting from each requirement, can a reviewer reach a source, constraint, or explicitly owned assumption? Starting from each high-confidence problem, can the reviewer find a requirement or a reason it is out of scope? Then check that metrics correspond to the stated outcome rather than convenient activity.

Use this checklist:

AI can make the document faster to navigate, but approval remains a product decision. The PRD is a living decision record, not proof that a proposed solution will succeed.

• Every requirement has a source ID, constraint, or labelled assumption.
• Direct observations remain distinguishable from AI summaries and product interpretation.
• Acceptance conditions describe observable behavior.
• Exclusions and unresolved questions are visible.
• Metrics have a baseline, measurement window, and owner where those exist.
• A product, engineering, design, and risk reviewer can challenge the source map.