How to Write a PRD That Engineers Actually Read

A PRD that opens with "We will build X" has already failed. Open with the problem statement: who is hurting, what they're doing today, and what it costs them (time, money, errors, churn).

If you can't write the problem in three sentences without using the word "solution," you're not ready to write the PRD yet — go do five more customer interviews.

Template

# Problem
<Who> is trying to <job-to-be-done>, but <current friction>.
This costs us <measurable impact> per <period>.
Evidence: <tickets, interviews, analytics>.

List the primary user, secondary users, and the operator (the person who supports them when things break). Each gets one paragraph: who they are, what device/channel they're on, what they know, what they don't.

For FinTech: always name the compliance/ops user. They're who you'll be debugging with at 2am.

Three columns, not two. The "explicitly not" column is what saves your sprint. Examples:

• In scope: P2P send between two wallets, same currency.
• Out of scope (this release): Bulk send, scheduled send.
• Explicitly not: Cross-border send. Will require a separate PRD with treasury sign-off.

One story per behavior, Gherkin-style acceptance criteria. Keep them testable.

Story: As a sender, I can send money to another wallet using their phone number.

AC1: Given a valid recipient phone, when I confirm, the transfer completes in <5s.
AC2: Given an invalid recipient, the UI shows "Number not registered" within 1s.
AC3: Given insufficient balance, the confirm button is disabled with reason shown.
AC4: Every successful send writes one ledger entry per leg (debit + credit).

Pick one headline metric and 2–3 supporting metrics. Define them with the SQL you'd run on day 30.

• Headline: % of new wallets that complete a P2P send within 7 days of activation. Target: 35%.
• Supporting: Send success rate, median time-to-confirm, support tickets per 1000 sends.

Three lists. Each item has an owner and a due date. "Open questions" is where you put the things you don't know — be honest, it builds trust with engineering.

Wireframes go in Figma. API contracts go in the design doc. Sprint plans go in Jira. Marketing copy goes in the launch doc. The PRD answers what and why, not how.