Belajar Product Manager - PRD & Requirement Writing
Menulis Product Requirement Document yang jelas dan actionable, mendefinisikan acceptance criteria, serta menyusun user stories yang menghubungkan kebutuhan user dengan eksekusi engineering
#Pendahuluan
Setelah di episode 8 kita memahami experimentation dan A/B testing, pada episode ini kita belajar mendokumentasikan keputusan produk ke dalam bentuk yang bisa dieksekusi. PRD (Product Requirement Document) adalah jembatan antara "apa yang ingin kita capai" dan "apa yang engineering harus bangun." PRD yang buruk menghasilkan build yang salah — waktu terbuang, frustrasi meningkat, dan produk tetap tidak selesai.
Banyak PM menulis PRD yang terlalu panjang (50+ halaman) atau terlalu pendek (hanya judul fitur). Keduanya bermasalah. PRD yang baik cukup detail untuk dieksekusi tetapi cukup fleksibel untuk adaptasi.
#Struktur PRD
#Komponen Utama
| Bagian | Isi | Kapan Ditulis |
|---|---|---|
| Context | Problem statement, user, data pendukung | Awal discovery |
| Goals & success metrics | Apa yang ingin dicapai, bagaimana mengukurnya | Setelah problem definition |
| User stories | Cerita user yang menggambarkan kebutuhan | Saat requirement gathering |
| Acceptance criteria | Kondisi yang harus terpenuhi untuk "done" | Bersamaan dengan user stories |
| Non-functional requirements | Performance, security, scalability | Saat technical discussion |
| Out of scope | Apa yang TIDAK masuk sprint ini | Untuk menghindari scope creep |
| Open questions | Pertanyaan yang belum terjawab | Dokumen hidup |
#User Stories
User stories menghubungkan kebutuhan user dengan action yang terukur:
Sebagai [persona], saya ingin [aksi], sehingga [hasil yang diinginkan].
Contoh:
Sebagai developer merchant, saya ingin SDK pembayaran tersedia di npm,
sehingga saya bisa mengintegrasikan pembayaran dalam satu perintah install.User story yang baik harus Independent (tidak bergantung story lain), Negotiable (bisa didiskusikan solusinya), Valuable (ada value untuk user), Estimable (bisa diestimasi effort), Small (bisa selesai dalam satu sprint), dan Testable (ada acceptance criteria).
#Acceptance Criteria
Acceptance criteria mendefinisikan "kapan ini selesai" secara eksplisit:
User Story: Sebagai developer merchant, saya ingin SDK tersedia di npm
Acceptance Criteria:
1. Package "nusapay-sdk" tersedia di npm registry
2. Perintah "npm install nusapay-sdk" berhasil tanpa error
3. Import module mengembalikan object dengan method: createPayment, checkStatus, refund
4. Documentasi API tersedia di README package
5. Unit test coverage ≥ 80%#Tips Menulis PRD yang Efektif
- Satu PRD = satu inisiatif: jangan menggabungkan banyak fitur dalam satu dokumen.
- Gunakan visual: diagram alur, wireframe, atau mockup lebih mudah dipahami dari teks panjang.
- Dokumen hidup: PRD harus diupdate seiring belajar baru — ini bukan dokumen statis.
- Libatkan engineering sejak awal: PRD yang ditulis sendiri tanpa input engineering sering kali tidak realistis.
Tip
Review PRD dengan engineer sebelum sprint dimulai. Tanyakan: "Apakah ada yang tidak jelas? Apakah ada asumsi yang salah? Apakah estimasi realistis?" 30 menit review bisa menghemat berminggu-minggu revisi.
#Penutup
Inti yang harus dibawa pulang:
- PRD adalah jembatan antara strategi dan eksekusi — harus cukup detail tetapi cukup fleksibel.
- User stories menghubungkan kebutuhan user dengan action engineering.
- Acceptance criteria mendefinisikan "kapan selesai" secara eksplisit — tanpa ini, "done" selalu ambigu.
- PRD adalah dokumen hidup yang diupdate seiring belajar baru.
Di episode 10 selanjutnya kita akan membahas collaboration dengan engineering — working agreements, backlog management, sprint planning, dan estimasi. Topik ini menghubungkan PRD dengan cara tim bekerja bersama. Tetap semangat!