Product requirements: how to write a PRD from interviews

A request for a button leaves the task unclear

A customer says, “Add an export button.” This does not tell you who needs the file, what it should contain, or what they will do with it. A product requirements document, or PRD, gives the team a shared understanding of the task and the scope of its result.

This article covers a short working document for one feature. Architecture, contracts, and organizational technical requirements still have their own place. The PRD makes the user problem testable before the team chooses an implementation.

From a user request to requirements

1. Return to the last real case

   Ask when the person needed the export, what they did instead, what they copied, and where they struggled. Mark the example and consequence in the transcript. A broad “it’s inconvenient” needs specifics before you can test improvement.

2. Describe the scenario before choosing an interface

   Record who starts the action, what inputs they have, and what outcome they expect. A button, email, or automatic report are possible solutions. Review the need and constraints before making the first suggestion a requirement.

3. Define the release scope

   Write what belongs in the current task and what is deliberately excluded. List access rights, data fields, and empty-result cases separately. Agree on measurement conditions before specifying performance or volume.

4. Write the verification criteria

   For each requirement, describe an observable result and example inputs. Connect the check to the original problem. If the requester has not confirmed a disputed item, record it as an open question with an owner and the date a decision is needed.

Exporting a list of closed inquiries

This fictional example uses names, conditions, and outcomes solely to explain the method.

The need is to share specific fields for a period. The interview does not call for an export of the whole database, attachments, or full conversation text.

Example criterion: after selecting a period, the export includes closed inquiries from that period and only the agreed fields. Clarify how the date boundaries are handled separately.

PRD template for one feature

Link each requirement to an observation. One source can support several items, but agreement still needs to be confirmed.

Feature name and version:
User problem:
Specific interview case:
User and context:
Main scenario:
Expected outcome:
Data and constraints:
In and out of scope:
Verification criteria:
Assumptions and open questions:
Sources and timecodes:
Who approved it and when:

Can someone verify the requirements without the author?

• Each requirement explains the problem it addresses.
• The verifiable result is distinct from the chosen implementation.
• The release scope is explicit.
• Open questions are marked as such.