Part 4 · 1 chapters · ~8 min
Writing PRDs and Specs
What a product requirements document is for, a structure engineers want to read (problem, evidence, goals and non-goals, users and stories, requirements with priorities, success metrics, risks, open questions), one-pagers versus full PRDs, and keeping specs alive.
9
A PRD engineers want to read
code
PRD: Self-serve clearance letter owner: PM · design · tech lead status: review
1 problem 249 manual support issues a month for clearance letters; customers wait 2-5 days
2 evidence support tags (last 6 months), 14 interviews, bank feedback on rejected letters
3 goals cut manual issues 50% in a quarter; letter in < 60 s; accepted by partner banks
4 non-goals letters for loans not yet repaid; letters in languages other than English (v1)
5 users borrowers who repaid; receiving banks and embassies (verifiers); support agents
6 stories as a borrower who repaid, I can download a signed letter so I can open an account elsewhere
7 requirements must: eligibility on settled balance · signed PDF + QR · audit log
should: email copy · share sheet could: letter history
8 metrics manual issues/month (primary) · time to letter · verification page views (guardrail: wrong letters = 0)
9 risks stale balances, partner acceptance, signing service capacity (see risk register)
10 open retention period for letters? who can revoke a letter?Specs are conversations: the PRD is reviewed with engineering and design while it is still a draft, and engineering's design doc (the how) is linked from it. A one-pager is enough for small bets; a full PRD earns its length for money flows and regulated features.