From BRD to Code: Writing a PRD That Developers Actually Want to Use
May 29, 2026 · 7 min read
Series: Memahami SDLC — Part 2 dari 10
Yesterday we covered the BRD — the document that gets stakeholders aligned on the business problem.
Today we level up: PRD (Product Requirements Document).
If the BRD is “why we’re building this”, the PRD is “what we’re actually building”.
What’s a PRD, Really?
PRD = Translation of BRD into product language.
BRD says: “We’re losing 15% of leads, need automation”
PRD says: “User clicks ‘Import Lead’, system reads WhatsApp API, saves to database, displays in dashboard”
Who reads the PRD:
- Product Manager — owns the document
- Designers — create UI/UX based on this
- Developers — estimate effort & start coding
- QA — write test cases from this
Stakeholders and bosses? They already approved the BRD. PRD is no longer their concern (unless there’s a major scope change).
When Do You Write a PRD?
The flow goes like this:
BRD (stakeholder approved)
↓
PRD (product team works)
↓
SRS (developers code)
PRD is written after BRD approval, but before developers start coding.
Why not code directly? Because:
- Designers need PRD to create mockups
- Developers need PRD to estimate time
- QA needs PRD to write test cases
- If changes are needed, it’s cheaper to change docs than code
Structure of a Good PRD
PRD is more detailed than BRD. Usually 5-15 pages. Here’s the minimum structure:
1. Document Info
# Product Requirements Document
**Product Name:** Lead Import Automation
**Version:** 1.0
**Date:** May 29, 2026
**Author:** [Your Name]
**Status:** Draft / In Review / Approved
**BRD Reference:** [Link to BRD]
2. Product Overview
Explain the product in 1-2 paragraphs:
“Lead automation system that imports from WhatsApp, email, and web forms into CRM. Users can view all leads in one dashboard, filter by source, and export to Excel.”
3. Goals & Success Metrics
From the BRD, but more specific:
| Metric | Target | How to Measure |
|---|---|---|
| Lead to CRM time | <1 minute from message received | Timestamp comparison |
| Data accuracy | 100% match with original message | Manual sampling of 100 leads |
| User adoption | 80% of sales team uses in week 1 | Login analytics |
4. User Personas
Who will use this product:
| Persona | Role | Goal | Pain Point |
|---|---|---|---|
| Sales Rep | Frontline sales | Quick lead follow-up | Manual recap from WA is tedious |
| Sales Manager | Team lead | Monitor team performance | Doesn’t know which leads are unhandled |
| Admin | Operations | Export data for reports | Has to copy-paste from 3 sources |
5. User Stories
Format: “As a [persona], I want to [action], so that [benefit]”
## User Stories
### US-01: Import Leads from WhatsApp
**As a** Sales Rep
**I want to** automatically import WhatsApp messages to CRM
**So that** I don't need to manually recap
**Acceptance Criteria:**
- [ ] WhatsApp messages enter CRM within <1 minute
- [ ] Contact name saved automatically
- [ ] Full message with timestamp saved
- [ ] Lead status = "New" on first import
### US-02: Filter Leads by Source
**As a** Sales Manager
**I want to** filter leads by source (WA, email, web)
**So that** I can analyze which channel is most effective
**Acceptance Criteria:**
- [ ] Filter dropdown: All, WhatsApp, Email, Web Form
- [ ] Counter shows lead count per source
- [ ] Filter can combine with date range
### US-03: Export Leads to Excel
**As a** Admin
**I want to** export leads to Excel
**So that** I can create weekly reports
**Acceptance Criteria:**
- [ ] Export button on dashboard
- [ ] .xlsx format with full columns
- [ ] Max 10,000 rows per export
- [ ] Download link valid for 24 hours
6. Functional Requirements
Detailed features that must exist:
## FR-01: WhatsApp Integration
- Connect to WhatsApp Business API
- Read incoming messages (text only, v1)
- Extract: sender number, message content, timestamp
- Store to `leads` table with source = "whatsapp"
## FR-02: Dashboard Lead List
- Table view with columns: Name, Number, Source, Timestamp, Status
- Pagination 20 items per page
- Sort by timestamp (default: newest first)
- Search by name or number
## FR-03: Lead Detail View
- Click row → detail modal
- Show full conversation thread
- Buttons: "Mark as Contacted", "Add Note"
7. Non-Functional Requirements
The invisible but important stuff:
| Category | Requirement |
|---|---|
| Performance | Dashboard loads <2 seconds with 10,000 leads |
| Security | Role-based access (sales only see their own data) |
| Availability | 99% uptime (business hours: 08:00-20:00 WIB) |
| Scalability | Support 100,000 leads within 1 year |
| Compliance | Data retention 2 years, then auto-archive |
8. UI Mockups / Wireframes
Link to Figma/Adobe XD, or simple sketches:
┌─────────────────────────────────────────┐
│ Lead Dashboard │
├─────────────────────────────────────────┤
│ [Search...] [Filter: All ▼] [Export]│
├─────────────────────────────────────────┤
│ Name │ Number │ Source │ Time │ Status│
│ Budi │ 0812.. │ WA │ 5m │ New │
│ Sari │ 0813.. │ Email │ 10m │ New │
│ ... │ ... │ ... │ ... │ ... │
├─────────────────────────────────────────┤
│ < 1 2 3 ... 10 > │
└─────────────────────────────────────────┘
9. Out of Scope (Reminder)
From the BRD, repeated to prevent scope creep:
Not in v1:
- Automated follow-up email
- Chatbot for lead qualification
- Mobile app
- SMS integration
10. Timeline & Milestones
Week 1-2: Design finalization + API setup
Week 3-5: Development (WhatsApp + Dashboard)
Week 6: QA + UAT
Week 7: Go-live
Common PRD Mistakes
Wrong: PRD Too Technical
Wrong:
“The system will use PostgreSQL 15 with B-tree indexing on the
phone_numbercolumn for faster queries.”
Right:
“Search lead by number must return results in <500ms even with 100,000 records."
The first one is SRS (technical spec). The second is PRD (user requirement).
Wrong: User Stories Without Acceptance Criteria
Wrong:
“As a user, I want to export data”
Right:
“As a user, I want to export data to Excel, so that I can create weekly reports.
AC: .xlsx format, max 10,000 rows, download link valid 24 hours”
Without AC, developers and QA don’t know when the feature is “done”.
Wrong: Mockups Inconsistent with Requirements
PRD says “filter by source”, but mockup has no filter dropdown.
Fix: Cross-check that every user story appears in the mockup, and every element in the mockup has a corresponding user story.
Wrong: Changing PRD Mid-Development
Developers are halfway through coding, PM shows up: “Hey, let’s add notification features!”
This is a disaster.
An approved PRD = contract. If you want to add something:
- Document as “change request”
- Re-estimate timeline & cost
- Get stakeholder approval
- Then developers continue
Ready-to-Use PRD Template
# Product Requirements Document
## Document Info
- **Product:** [Name]
- **Version:** 1.0
- **Date:** [Date]
- **Author:** [Name]
- **Status:** Draft / In Review / Approved
## Product Overview
[1-2 paragraphs]
## Goals & Success Metrics
| Metric | Target | Measurement |
|--------|--------|-------------|
| [Metric] | [X] | [How to measure] |
## User Personas
| Persona | Role | Goal | Pain Point |
|---------|------|------|------------|
| [Name] | [Role] | [Goal] | [Pain] |
## User Stories
### US-01: [Story Name]
**As a** [persona]
**I want to** [action]
**So that** [benefit]
**Acceptance Criteria:**
- [ ] [Criterion 1]
- [ ] [Criterion 2]
## Functional Requirements
### FR-01: [Feature Name]
- [Requirement detail]
## Non-Functional Requirements
| Category | Requirement |
|----------|-------------|
| Performance | [Req] |
| Security | [Req] |
| Availability | [Req] |
## UI Mockups
[Link to Figma or sketch]
## Out of Scope
- [What's not included]
## Timeline
[Week-by-week breakdown]
BRD vs PRD — Side by Side
| Aspect | BRD | PRD |
|---|---|---|
| Author | Business Analyst / PM | Product Manager |
| Audience | Stakeholders, Boss | Designer, Developer, QA |
| Focus | Business problem, ROI | Features, user journey |
| Detail | High-level (3-5 pages) | Detailed (5-15 pages) |
| Metric | Business KPI (revenue, leads) | Product metric (load time, adoption) |
| Approval | Before project starts | Before design & dev starts |
When You Don’t Need a PRD
PRD is overkill for:
- Small bug fixes — direct ticket to developer
- Minor feature tweaks — 1-pager spec is enough
- Startup early stage — 1-pager + mockup is sufficient
- Agile sprints — user stories in Jira/Linear can replace formal PRD
But if:
- Budget >$10,000
- Timeline >1 month
- Team >5 people (designer + multiple devs + QA)
- Impact on revenue or user experience is significant
PRD is mandatory.
Closing
PRD is the bridge between business (BRD) and technical (SRS).
A good PRD:
- Right: Clearly defines who the user is and what they need
- Right: Has measurable acceptance criteria
- Right: Mockups are consistent with requirements
- Right: Out of scope is clearly stated (no scope creep)
- Right: Approved before coding starts
Next post: SRS (Software Requirements Specification) — how developers translate PRD into technical specs that can be coded.
Series: “Memahami SDLC” — Part 2 of 10. Follow at susiloharjo.web.id
Related: SRS: The Technical Spec That Keeps Developers Honest.
Related: Design Thinking Is 80% Theater. Here’s the 20% That Works..
Discover more from Susiloharjo
Subscribe to get the latest posts sent to your email.