Memahami PRD: Dari BRD ke Fitur yang Bisa Dikoding

Mei 29, 2026 · 7 min read

Series: Memahami SDLC — Post 2 dari 10

---

Kemarin kita udah bahas BRD — dokumen yang bikin bos ngerti masalah bisnis.

Hari ini kita naik satu level: PRD (Product Requirements Document).

Kalau BRD itu “kenapa kita bangun ini”, PRD itu “apa yang akan kita bangun”.

---

PRD Itu Apa Sih?

PRD = Terjemahan BRD ke bahasa produk.

BRD bilang: “Lead hilang 15%, perlu automasi”

PRD bilang: “User klik ‘Import Lead’, sistem baca WhatsApp API, simpan ke database, tampil di dashboard”

PRD dibaca oleh:

• Product Manager — pemilik dokumen
• Designer — bikin UI/UX berdasarkan ini
• Developer — estimasi effort & mulai coding
• QA — bikin test case dari ini

Stakeholder & bos? Mereka udah approve BRD. PRD udah bukan urusan mereka lagi (kecuali ada perubahan scope besar).

---

Kapan PRD Dibuat?

Flow-nya gini:

BRD (approved stakeholder)
    ↓
PRD (tim produk kerja)
    ↓
SRS (developer coding)

PRD dibuat setelah BRD approved, tapi sebelum developer mulai coding.

Kenapa gak langsung coding? Karena:

1. Designer butuh PRD buat bikin mockup
2. Developer butuh PRD buat estimasi waktu
3. QA butuh PRD buat bikin test case
4. Kalau ada perubahan, lebih murah ubah dokumen daripada ubah kode

---

Struktur PRD yang Baik

PRD lebih detail dari BRD. Biasanya 5-15 halaman. Ini struktur minimal:

1. Document Info

# Product Requirements Document

**Product Name:** Automasi Lead Import  
**Version:** 1.0  
**Date:** 29 Mei 2026  
**Author:** [Nama PM]  
**Status:** Draft / In Review / Approved  
**BRD Reference:** [Link ke BRD]

2. Product Overview

Jelasin produk dalam 1-2 paragraf:

“Sistem automasi import lead dari WhatsApp, email, dan web form ke CRM. User bisa lihat semua lead dalam 1 dashboard, filter berdasarkan source, dan export ke Excel.”

3. Goals & Success Metrics

Dari BRD, tapi lebih spesifik:

Metric	Target	Cara Ukur
Lead masuk CRM	<1 menit dari pesan masuk	Timestamp comparison
Data accuracy	100% match dengan pesan asli	Manual sampling 100 lead
User adoption	80% tim sales pakai dalam minggu pertama	Login analytics

4. User Personas

Siapa yang bakal pake produk ini:

Persona	Role	Goal	Pain Point
Sales Rep	Frontline sales	Cepat follow-up lead	Ribet rekap manual dari WA
Sales Manager	Team lead	Monitor performa tim	Gak tau lead mana yang belum dihandle
Admin	Operations	Export data untuk report	Harus copy-paste dari 3 sumber

5. User Stories

Format: “As a [persona], I want to [action], so that [benefit]”

## User Stories

### US-01: Import Lead dari WhatsApp
**As a** Sales Rep  
**I want to** otomatis import pesan WhatsApp ke CRM  
**So that** saya gak perlu rekap manual

**Acceptance Criteria:**
- [ ] Pesan WhatsApp masuk CRM dalam <1 menit
- [ ] Nama kontak tersimpan otomatis
- [ ] Pesan lengkap dengan timestamp
- [ ] Lead status = "New" saat pertama masuk

### US-02: Filter Lead by Source
**As a** Sales Manager  
**I want to** filter lead berdasarkan source (WA, email, web)  
**So that** saya bisa analisa channel mana yang paling efektif

**Acceptance Criteria:**
- [ ] Filter dropdown: All, WhatsApp, Email, Web Form
- [ ] Counter show jumlah lead per source
- [ ] Filter bisa dikombinasi dengan date range

### US-03: Export Lead to Excel
**As a** Admin  
**I want to** export lead ke Excel  
**So that** saya bisa bikin report mingguan

**Acceptance Criteria:**
- [ ] Export button di dashboard
- [ ] Format .xlsx dengan kolom lengkap
- [ ] Max 10.000 rows per export
- [ ] Download link valid 24 jam

6. Functional Requirements

Detail fitur yang harus ada:

## FR-01: WhatsApp Integration
- Connect ke WhatsApp Business API
- Read incoming messages (text only, v1)
- Extract: sender number, message content, timestamp
- Store ke table `leads` dengan source = "whatsapp"

## FR-02: Dashboard Lead List
- Table view dengan kolom: Nama, Nomor, Source, Timestamp, Status
- Pagination 20 items per page
- Sort by timestamp (default: newest first)
- Search by nama atau nomor

## FR-03: Lead Detail View
- Klik row → modal detail
- Show full conversation thread
- Button: "Mark as Contacted", "Add Note"

7. Non-Functional Requirements

Yang gak keliatan tapi penting:

Category	Requirement
Performance	Dashboard load <2 detik dengan 10.000 lead
Security	Role-based access (sales cuma lihat data sendiri)
Availability	99% uptime (jam kerja: 08:00-20:00 WIB)
Scalability	Support 100.000 lead dalam 1 tahun
Compliance	Data retention 2 tahun, lalu auto-archive

8. UI Mockups / Wireframes

Link ke Figma/Adobe XD, atau sketsa sederhana:

┌─────────────────────────────────────────┐
│  Dashboard Leads                        │
├─────────────────────────────────────────┤
│  [Search...]  [Filter: All ▼]  [Export]│
├─────────────────────────────────────────┤
│  Nama  │ Nomor  │ Source │ Time │ Status│
│  Budi  │ 0812.. │ WA     │ 5m   │ New   │
│  Sari  │ 0813.. │ Email  │ 10m  │ New   │
│  ...   │ ...    │ ...    │ ...  │ ...   │
├─────────────────────────────────────────┤
│  <  1  2  3  ... 10  >                  │
└─────────────────────────────────────────┘

9. Out of Scope (Reminder)

Dari BRD, diulang biar gak scope creep:

Not in v1:

• Automasi follow-up email
• Chatbot qualify lead
• 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

---

Kesalahan Umum di PRD

Wrong: PRD Kebanyakan Teknis

Salah:

“Sistem akan pakai PostgreSQL 15 dengan indexing B-tree pada kolom phone_number untuk query yang lebih cepat.”

Bener:

“Search lead by nomor harus return result dalam <500ms bahkan dengan 100.000 data."

Yang pertama itu SRS (technical spec). Yang kedua itu PRD (user requirement).

Wrong: User Story Gak Ada Acceptance Criteria

Salah:

“As a user, I want to export data”

Bener:

“As a user, I want to export data to Excel, so that I can create weekly reports.

AC: Format .xlsx, max 10.000 rows, download link valid 24 jam”

Tanpa AC, developer dan QA gak tau kapan fitur “done”.

Wrong: Mockup Gak Konsisten dengan Requirement

PRD bilang “filter by source”, tapi mockup gak ada dropdown filter.

Fix: Cross-check setiap user story ada di mockup, dan setiap elemen di mockup ada di user story.

Wrong: PRD Diubah Tengah Development

Developer udah coding setengah, PM datang: “Eh, kita tambah fitur notifikasi aja!”

Ini disaster.

PRD yang approved = kontrak. Kalau mau nambah:

1. Catat sebagai “change request”
2. Estimasi ulang timeline & cost
3. Approve dari stakeholder
4. Baru developer lanjut

---

Template PRD Siap Pakai

# Product Requirements Document

## Document Info
- **Product:** [Nama]
- **Version:** 1.0
- **Date:** [Tanggal]
- **Author:** [Nama]
- **Status:** Draft / In Review / Approved

## Product Overview
[1-2 paragraf]

## 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 atau sketsa]

## Out of Scope
- [Yang gak termasuk]

## Timeline
[Week-by-week breakdown]

---

BRD vs PRD — Side by Side

Aspect	BRD	PRD
Author	Business Analyst / PM	Product Manager
Audience	Stakeholder, Bos	Designer, Developer, QA
Focus	Masalah bisnis, ROI	Fitur, user journey
Detail	High-level (3-5 halaman)	Detailed (5-15 halaman)
Metric	Business KPI (revenue, lead)	Product metric (load time, adoption)
Approval	Sebelum project dimulai	Sebelum design & dev dimulai

---

Kapan PRD Gak Perlu?

PRD overkill kalau:

• Bug fix kecil — langsung tiket ke developer
• Feature tweak minor — 1 halaman spec cukup
• Startup early stage — 1-pager + mockup udah cukup
• Agile sprint — user story di Jira/Linear bisa replace PRD formal

Tapi kalau:

• Budget >Rp 100 juta
• Timeline >1 bulan
• Tim >5 orang (designer + multiple devs + QA)
• Impact ke revenue atau user experience besar

PRD wajib.

---

Penutup

PRD itu jembatan antara bisnis (BRD) dan teknis (SRS).

PRD yang bagus:

• Right: Jelas user-nya siapa dan apa yang mereka butuh
• Right: Acceptance criteria terukur
• Right: Mockup konsisten dengan requirement
• Right: Out of scope ditegasin (no scope creep)
• Right: Approved sebelum coding dimulai

Next post: SRS (Software Requirements Specification) — gimana developer nerjemahin PRD jadi spesifikasi teknis yang bisa dikoding.

---

Series: “Memahami SDLC” — Part 2 dari 10. Follow di teknologinow.com