Step Three: Gather Requirements

Before the document is drafted, the raw material of the document must be collected. Requirements do not emerge from a single person's thinking. They emerge from a structured process of gathering input from the right sources in the right sequence.

This step is where most of the real discovery happens. It is also the step most frequently rushed because teams are eager to start writing.

What this step requires you to do:

1. Talk to engineers early. Before writing a single requirement, understand the technical landscape. What constraints exist? What integrations are involved? What will take significantly longer than expected? Engineers will save you from writing requirements that are either technically impossible or technically trivial to improve upon.
2. Work with designers on user flows. Understand the user journey before specifying the requirements that must support it. Where do users currently drop off? What gaps exist in the current experience? What states and edge cases must the product handle?
3. Review existing data. Usage analytics, funnel metrics, support volumes, NPS verbatims. What does the data say about where users struggle? What does it confirm about the problem you defined in Step One?
4. Identify non-functional requirements proactively. Performance, accessibility, security, compliance. These must be gathered before drafting, not discovered during engineering review.
5. Document open questions explicitly. Requirements gathering will not answer every question. The ones that remain open should be listed, assigned an owner, and given a resolution deadline before drafting begins.

Requirements that are gathered thoroughly produce PRDs that are written quickly. Requirements that are gathered poorly produce PRDs that are rewritten repeatedly.