Blog · Product management

How to Write a PRD Engineers Can Build (and You Can Measure)

VektorForgeAI

A product requirements document has one job: get a team to build the right thing, and know when it’s done. Most PRDs fail at one or both. They read like a wish list, they skip the “why,” and they define “done” as “shipped.”

This guide walks through a PRD structure that fixes those problems. It starts with the outcome, turns it into requirements an engineer can build, and ends with acceptance criteria someone can actually test. There’s a free template at the end.

Why most PRDs don’t get used

PRDs usually go wrong in three predictable ways:

  • They start with the solution. “Add a dashboard” is a feature, not a problem. Without the problem, engineers can’t make good trade-offs when the plan meets reality.
  • They don’t define success. If the document never says what should change for users or the business, nobody can tell whether the work paid off.
  • Their requirements can’t be tested. “The page should be fast” and “the export should be easy to use” mean different things to every reader.

A good PRD is short where it can be and precise where it has to be.

Start with the outcome, not the feature

Before writing a single requirement, answer three questions at the top of the document:

  1. What problem are we solving, and for whom? Name the user and the situation, in one or two sentences.
  2. Why now? What makes this worth doing this quarter instead of next year?
  3. How will we know it worked? One outcome metric, with a baseline and a target. For example: “Reduce the time to produce a monthly report from about 3 hours to under 30 minutes.”

That third question does the most work. It turns the PRD from a list of features into a bet you can check. It also gives engineers a tiebreaker: when two approaches compete, pick the one more likely to move the number.

The sections every PRD needs

Keep the structure consistent so readers know where to look:

  1. Summary: the problem, the user and the outcome metric, in a short paragraph.
  2. Background and evidence: what you know and how you know it. Link to research, support tickets, interviews or data, and mark anything that’s still an assumption.
  3. Goals and non-goals: what this release will do, and just as important, what it won’t.
  4. Users and scenarios: the main jobs the user is trying to get done.
  5. Requirements: numbered, each one testable (more below).
  6. Acceptance criteria: how each requirement will be verified.
  7. Dependencies and risks: other teams, systems, vendors and open questions, each with an owner.
  8. Release plan: what ships first, and what waits.
  9. Open questions and decisions: a running log, with the date and who decided.

Writing requirements engineers can build

A good requirement is specific, necessary and testable. A useful pattern:

REQ-07. When a user exports a report, the system shall produce a CSV file containing every row matching the current filters, within 5 seconds for up to 50,000 rows.

Notice what makes it work:

  • One requirement per line, with an ID, so it can be referenced, tracked and traced to tests.
  • “Shall” for what’s mandatory. Use “should” only for real preferences, and say so.
  • Measurable terms: “within 5 seconds for up to 50,000 rows” instead of “fast.”
  • No hidden design. It says what the system must do, not which library or screen layout to use, unless that’s truly a constraint.

Standards such as ISO/IEC/IEEE 29148 describe the qualities of well-formed requirements in more detail: necessary, unambiguous, complete, feasible and verifiable, among others. You don’t need to adopt the whole standard to borrow its checklist.

Acceptance criteria that actually test something

Acceptance criteria turn a requirement into a pass/fail check. The Given/When/Then format keeps them concrete:

Given a report filtered to 12,000 rows, When the user selects Export to CSV, Then a CSV with exactly 12,000 data rows and the same column headers as the on-screen table downloads within 5 seconds.

A few rules of thumb:

  • Each criterion should be checkable by someone who didn’t write it.
  • Include the unhappy paths: empty results, permission errors, very large inputs.
  • Tie at least one criterion back to the outcome metric, so “done” includes “measurably better,” not just “it works.”

Keep it on the record

Requirements change, and that’s fine. What hurts is losing track of what changed, when and why. Keep named versions of the PRD, set a baseline when the team commits to a release, and log decisions with a date and an owner. When someone asks six weeks later why the scope moved, the answer is in the document instead of in someone’s memory.

Free PRD template

Copy this outline into your own document:

PRD: <name>                         Version: <v1.0>   Baseline date: <date>
Owner: <name>                       Status: Draft / In review / Baselined

1. Summary
   Problem, user, outcome metric (baseline -> target)
2. Background and evidence
   Sources; assumptions marked as assumptions
3. Goals / Non-goals
4. Users and scenarios
5. Requirements
   REQ-01 The system shall ...
6. Acceptance criteria
   REQ-01  Given ... When ... Then ...
7. Dependencies and risks (owner for each)
8. Release plan
9. Decisions log (date, decision, who)

Doing this faster

If you’d rather not assemble this by hand, Product Architect, our AI-guided product management workspace, follows the same order. You start with research and an outcome metric, then Arc, its AI coach, drafts requirements with acceptance criteria for you to edit and approve. Drafts are labeled as drafts, assumptions are marked, and approved requirements can be pushed to Jira. Plans are kept as named versions and baselines.

Product Architect is free to start on one product: see the plans. Prefer a hand from a person? We also offer product management consulting.

← All articles