Product Requirements Documents

Specs that engineers
actually want to build from.

A PRD is not a documentation exercise. It's a product decision record — a proof that the PM made the tradeoffs visible before the engineers started. Here are four of mine.

Principle 01

Non-goals are documented as carefully as goals. What we're not building is a decision too.

Principle 02

Acceptance criteria include compliance annotations — not just what to build, but why that constraint exists.

Principle 03

Every PRD ends with open questions. A spec with no open questions is a spec that hasn't been read carefully.

The best PRDs I've written don't just specify what to build. They document why we chose this over that, what we're explicitly not building in this version, and how we'll know it worked. If you're hiring a PM to write specs, these show how I think before engineering starts.

All PRDs here are sanitized where necessary to protect client-specific information. The structure, decision logic, and acceptance criteria represent real specification work.

Full PRDs
PRD 01 AI · Data Product · B2C Multi-persona API

JobSignals — Labor Market Intelligence Platform

Full PRD for a zero-to-one AI data product that extracts structured hiring signals from unstructured job posting text. Six distinct user personas, REST + GraphQL API, and a prompt engineering specification that I wrote as acceptance criteria. The insight: writing precise prompts for consistent AI output taught me more about writing good feature specs than any methodology.

6
User personas
3
API surfaces
Signature Decision in This PRD
Chose coverage over accuracy. The salary signal extraction trades precision for breadth — extracting probabilistic salary ranges from implicit language ("competitive compensation" + seniority signals) rather than explicit numbers. Documented with explicit confidence interval design so users can calibrate their own trust. This tradeoff decision is the center of the PRD, not a footnote.
PRD Structure
Problem Statement User Personas (6) Non-Goals API Specification Prompt Engineering Spec Acceptance Criteria Success Metrics Open Questions
Zero-to-one Claude API Data product REST/GraphQL
Read PRD →
PRD 02 B2B Fintech · KYC RBI Compliance

KYC Guided Capture — Feature PRD

Feature spec for the guided document capture experience that moved KYC first-attempt success rate by 28% in the first month at Signzy — before touching the AI model. Every acceptance criterion has a compliance annotation explaining why the constraint exists (not just what it is). Designed for two users simultaneously: the bank customer completing KYC, and the bank ops team reviewing the results.

2
User types
+28%
First-attempt rate
Signature Decision in This PRD
Real-time quality feedback specified at the component level, not the feature level. Rather than "add document quality check," the spec defines the exact feedback states (lighting_low, edge_cropped, blur_detected, quality_ok), the latency threshold (feedback must appear within 200ms of frame stability), and the fallback when the quality check fails to load. Compliance annotation: "No quality score or image data may be retained on device after capture session ends — RBI data minimization requirement." Engineering never needs to ask whether to retain data.
PRD Structure
Problem Statement North Star Metric Users (End Customer + Ops Team) Non-Goals Feature Specification Acceptance Criteria + Compliance Annotations Edge Cases Success Metrics Open Questions
RBI compliance Mobile-first AI-assisted UX B2B Fintech
Read PRD →
PRD 03 GenAI Feature Healthcare · HIPAA

AI Email Drafting — TruServe Feature PRD

Feature spec for smart email drafting — the Phase 1 P0 feature from the HCSC $10M program that achieved 78% agent acceptance rate in Sprint 4. The most interesting section: the AI confidence score UX specification, designed explicitly for skeptical agents who need to feel in control of AI output, not replaced by it. Also includes the override design and how override data feeds back into model improvement.

78%
AI acceptance rate
8–12min
Saved per email
Signature Decision in This PRD
The override UX is specified as carefully as the generation UX. Most AI feature PRDs specify what happens when the AI works. This one specifies what happens when agents don't like the output: one-click override, pre-populated edit mode (not blank slate), and an implicit feedback signal captured from every override (which phrases were edited, what replacements were made). The override isn't a failure state — it's a data collection mechanism that improves the model over time. This design decision is why adoption was 30% higher than our baseline assumption.
PRD Structure
Problem Statement Risk Assessment (Quadrant D classification) Users (Agent + Supervisor + IT) Non-Goals Generation Spec Confidence Score UX Override Design + Feedback Loop HIPAA Compliance Notes Acceptance Criteria Adoption Metrics
GenAI Adoption design Healthcare SaaS Enterprise
Read PRD →
PRD 04 Zero-to-One B2B SaaS

Founder OS — Operating Layer PRD

Full PRD for a zero-to-one product with no brief, no existing product, and no validated demand. The challenge: there are 20 existing tools for different parts of what founders need. The PM question at the center of this PRD: what is the minimum slice of functionality that creates irreversible founder habit — the thing that makes a founder open this product every morning instead of switching between the six tools they already have?

6
Tools displaced
Zero
to one
Signature Decision in This PRD
Chose OKR tracking as the wedge feature — not investor CRM, not burn rate dashboard, not roadmap. The hypothesis: founders open their OKR tool at the start of every week. If we own the Monday morning review, we own the context that makes every other feature (investor updates, hiring decisions, sprint planning) naturally want to connect to us. The PRD documents this reasoning explicitly in the "why this feature is the wedge" section — because zero-to-one PRDs need to explain the sequencing logic, not just the feature list.
PRD Structure
Problem Statement Market Context User Research Synthesis The Wedge Feature + Rationale Module Specifications (6 modules) Integration Architecture Pricing Model Non-Goals Success Metrics
Zero-to-one B2B SaaS Founder tools Pricing strategy
Read PRD →