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:

## 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:

  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

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).

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”.

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.

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