Step Four: Draft the PRD

This is where the writing begins. Not before. Every step that preceded this one was preparation, and the quality of this draft is a direct reflection of how thoroughly that preparation was done.

The first draft of a PRD is not meant to be perfect. It is meant to be complete. Its job is to get everything onto the page in the right structure so that the review process has something real to react to.

What this step requires you to do:

1. Follow the structure from Module Two. Header, overview, problem statement, goals and metrics, user stories, functional requirements, non-functional requirements, out of scope, dependencies, risks, open questions. In that order, because each section contextualises the one that follows it.
2. Write the problem statement first, even if you already wrote it in Step One. It anchors everything. The rest of the document should flow from it directly.
3. Write requirements in plain, testable language. Apply the principles from Module Four at every sentence. Specific, not approximate. Outcome-focused, not output-focused. User-grounded, not feature-driven.
4. Fill in the out-of-scope section deliberately. Do not leave it empty or treat it as optional. Naming what is explicitly excluded is as important as naming what is included.
5. Mark every unresolved question clearly. Do not paper over uncertainty with confident-sounding language. If something is not yet decided, say so. The review process is where it gets resolved.
6. Do not aim for perfection on the first pass. Aim for honesty and completeness. Clarity can be improved. Missing sections cannot be reviewed.

A draft that says the right things imperfectly is always more useful than a polished document that says the wrong things precisely.