prd-templateMembuat Product Requirements Document (PRD) dengan struktur template PM yang sudah terbukti. Gunakan saat diminta menulis PRD, spesifikasi produk, spesifikasi fitur, atau dokumen kebutuhan untuk fitur atau produk baru. Menghasilkan PRD lengkap berisi problem statement, user story, kebutuhan fungsional, pertimbangan teknis, dan metrik keberhasilan.
Independent GitHub snapshot · Automated classification · Original documentation governs
Terjemahan bahasa Indonesia dari prd-template. Versi bahasa Inggris adalah versi kanonis.
Skill ini membantu membuat Product Requirements Document yang profesional sesuai praktik terbaik industri.
Urutan kedua dalam alur keputusan produk: /assumption-mapper → prd-template →
/rice-prioritisation → /roadmap-narrative. Skill ini menerima asumsi paling berisiko
dari /assumption-mapper (jika skill itu sudah dijalankan, baca peta asumsinya alih-alih menebak ulang risikonya)
dan menyerahkan ke /rice-prioritisation metrik keberhasilan PRD: satu angka dengan baseline
yang menjadi Impact dalam RICE. Istilah bersama (problem statement, hipotesis, metrik
keberhasilan, provenance) didefinisikan sekali di
docs/craft/product-decisions.md; gunakan istilah itu
persis seperti didefinisikan.
PRD ditulis dari luar ke dalam (masalah sebelum solusi, selalu) dalam empat fase. Fase 1 adalah fondasinya: PRD yang dibangun di atas masalah yang kabur akan rapi dari atas sampai bawah tetapi tetap salah.
/assumption-mapper di hulu ke sini sebagai Pertanyaan Terbuka, bukan taruhan diam-diam.
Selesai jika: metrik punya baseline (atau ditandai secara eksplisit belum punya baseline),
dan metrik itu mengukur masalahnya, bukan aktivitas./rice-prioritisation bisa menilai Impact dari metrik ini, bukan metrik yang dibuat ulang.
Selesai jika: PRD menyebutkan metrik dan cakupan yang dibutuhkan /rice-prioritisation
untuk menilainya tanpa perlu bertanya lagi.Tanyakan hal berikut kepada pengguna jika belum diberikan:
Jika ada professional-brain (brain/), gunakan alih-alih menanyakan konteks yang sudah Anda miliki:
context.md (produk, definisi metrik, gaya bahasa), knowledge/strategy.md
(arah produk), hypotheses/ yang terkait, dan file fitur entities/ yang sesuai.
Jalankan python3 ../professional-brain/scripts/brain_query.py ./brain "<feature>" untuk menarik
fakta yang berdasar, lalu bawa tag asal-usulnya ke dalam PRD (jangan sajikan [hunch] sebagai
kebutuhan yang sudah pasti).entities/<feature>.md, catat setiap keputusan cakupan ke
decisions/, dan tambahkan asumsi baru ke hypotheses/. Beri tag asal-usul pada masing-masing.Skill ini disertai dua file pendukung, gunakan jika tersedia:
templates/prd-skeleton.md: kerangka PRD yang tinggal diisi, dengan petunjuk "seperti apa yang baik" di setiap bagian. Mulai dari sini saat pengguna ingin dokumen yang mereka lengkapi sendiri alih-alih draf yang dibuatkan.references/success-metrics-guide.md: kalibrasi untuk bagian Metrik Keberhasilan: uji metrik empat bagian, set standar adopsi/hasil/bisnis/guardrail, dan jebakan yang umum. Rujuk setiap kali menulis atau mereview tabel metrik.Setiap PRD harus memuat bagian-bagian berikut secara berurutan:
Format: "Sebagai [jenis pengguna], saya ingin [tindakan] agar [manfaat]"
Kebutuhan Fungsional:
Kebutuhan Non-Fungsional:
Nada: Jelas, ringkas, bisa ditindaklanjuti Audiens: Engineer, desainer, stakeholder Panjang: Targetkan 3-6 halaman untuk fitur, 8-12 halaman untuk produk
Praktik Terbaik:
✅ Lakukan:
❌ Jangan:
Nilai setiap output skill ini sebelum diserahkan; skor 32+ berarti layak kirim.
| Dimensi | 0 | 5 | 10 |
|---|---|---|---|
| Landasan masalah | Masalah dinyatakan dari sudut pandang perusahaan, atau diklaim tanpa bukti | Masalah dibingkai dari sisi pengguna, tetapi data pendukungnya samar ("pengguna frustrasi") dan riset tidak dikutip | Masalahnya milik pengguna, dikuantifikasi dengan data kondisi saat ini, dan Mengapa Sekarang menjelaskan apa yang berubah; klaim tertelusur ke riset yang dikutip |
| Kebutuhan yang bisa diuji | Kebutuhan berupa kualitas samar ("cepat", "intuitif") yang tidak bisa diverifikasi reviewer | Sebagian besar kebutuhan konkret, tetapi acceptance criteria tipis dan kebutuhan non-fungsional hanya boilerplate | Setiap item P0/P1/P2 dan NFR bisa diverifikasi (ambang batas, persentil, standar), dan masing-masing tertelusur ke user story atau temuan riset |
| Ketelitian metrik | Metrik keberhasilan tidak ada, atau berupa persentase tanpa baseline | Baseline dan target ada, tetapi metrik hanya mengukur adopsi: tidak ada yang bisa mendeteksi fitur berhasil sementara bisnis merugi | Setiap metrik punya baseline → target, set metrik mencakup hasil sekaligus adopsi, dan minimal satu guardrail mencegah menang di metrik sambil merugikan pengguna |
| Kejujuran cakupan & risiko | MVP dan fase mendatang bercampur; tidak ada pertanyaan terbuka yang dicantumkan | Fase dipisahkan, tetapi alasan batas pemotongannya tidak ada dan perbedaan pendapat dihaluskan | Setiap batas fase punya alasan yang dinyatakan, permintaan di luar cakupan dicatat beserta syarat untuk masuk kembali, dan pertanyaan terbuka punya penanggung jawab, tenggat, dan biaya dari setiap jawaban |
# PRD: Dashboard Customer Support Multi-Channel
## Ikhtisar
**Problem Statement**: Tim support saat ini menangani pertanyaan pelanggan dari email, chat, dan media sosial menggunakan tiga tool terpisah, sehingga respons tertunda, pekerjaan terduplikasi, dan pengalaman pelanggan tidak konsisten. Rata-rata, agen support membuang 2,3 jam per hari untuk berpindah antar-tool dan melacak riwayat percakapan secara manual.
**Solusi yang Diusulkan**: Membangun dashboard terpadu yang menggabungkan pertanyaan pelanggan dari semua channel ke dalam satu antarmuka, menyimpan riwayat percakapan lintas channel, dan menyediakan routing cerdas berdasarkan keahlian dan ketersediaan agen.
**Metrik Keberhasilan**:
- Menurunkan rata-rata waktu respons dari 4 jam menjadi 1 jam
- Mengurangi waktu berpindah antar-tool sebesar 80% (dari 2,3 menjadi <0,5 jam)
- Meningkatkan skor kepuasan pelanggan dari 3,8 menjadi 4,5 (dari 5)
- Meningkatkan produktivitas agen support sebesar 35%
## Konteks & Latar Belakang
**Mengapa Sekarang**: Kepuasan pelanggan turun 15% dalam 6 bulan terakhir, terutama karena waktu respons yang lambat. Kompetitor utama kita meluncurkan dashboard support terpadu kuartal lalu, dan hal ini sering disebut dalam sales call. Turnover tim support mencapai 45% per tahun, dengan "kerumitan tool" disebut sebagai salah satu sumber frustrasi utama.
**Keselarasan Strategis**: Ini selaras dengan tujuan perusahaan Q1 untuk "Meningkatkan retensi pelanggan sebesar 10%" dan OKR tim support untuk "Menurunkan average handle time sebesar 25%."
**Ringkasan Riset Pengguna**: Kami mewawancarai 12 agen support dan mengamati 20 jam sesi support. Temuan utama:
- Agen menghabiskan 35% waktunya untuk mencari konteks dari interaksi sebelumnya
- 65% eskalasi terjadi karena tidak adanya riwayat percakapan
- Agen menilai berpindah antar-tool sebagai frustrasi harian #1 mereka (tingkat kesulitan 9,2/10)
- NPS saat ini untuk pengalaman support adalah -12
## User Story & Use Case
**US1: Inbox Terpadu**
Sebagai agen support, saya ingin melihat semua pertanyaan pelanggan di satu tempat agar tidak melewatkan permintaan mendesak dan bisa memprioritaskan dengan efektif.
Acceptance Criteria:
- Inbox menampilkan pertanyaan dari email, chat, dan media sosial
- Pertanyaan diurutkan berdasarkan prioritas (mendesak, tinggi, normal, rendah)
- Agen bisa memfilter berdasarkan channel, pelanggan, atau status
- Pembaruan real-time saat pertanyaan baru masuk
**US2: Konteks Lintas Channel**
Sebagai agen support, saya ingin melihat riwayat percakapan lengkap apa pun channel-nya agar bisa memberikan respons yang konsisten dan berbasis informasi tanpa meminta pelanggan mengulang cerita mereka.
Acceptance Criteria:
- Tampilan timeline menunjukkan semua interaksi secara kronologis
- Setiap interaksi menampilkan channel, waktu, dan isi
- Profil pelanggan menampilkan data demografis dan informasi akun
- Masalah dan penyelesaian sebelumnya bisa diakses
[Lanjutkan hingga total 5-7 user story...]