Apa Itu PRD (Product Requirements Document) dan Kenapa Makin Penting di Era AI Coding Agent

Kasih satu paragraf ide ke Cursor, terus kasih ide yang persis sama ke Claude Code. Buka dua hasilnya berdampingan. Struktur folder beda, nama field beda, format response API beda. Dua-duanya jalan, tapi nggak ada yang nyambung kalau mau digabung.

Yang hilang bukan skill si agent. Yang hilang kontraknya. Dan kontrak itu namanya PRD.

PRD adalah, tanpa jargon

Kepanjangan PRD itu Product Requirements Document. Sederhananya: dokumen yang jelasin apa yang mau dibangun dan aturan mainnya, sebelum ada kode ditulis. Bukan lebih dari itu.

Orang sering salah bayangin PRD sebagai spesifikasi teknis 80 halaman yang ditulis product manager pakai jas. Bukan. PRD juga bukan sekadar satu baris ide di notes yang isinya "bikin app reminder servis". Dia ada di tengah: cukup jelas biar orang lain, atau agent, ngerti maksudmu tanpa harus nebak.

Intinya PRD jawab tiga hal: apa yang dibangun, buat siapa, dan aturan apa yang nggak boleh dilanggar. Kalau tiga itu jelas, sisanya urusan implementasi.

Kenapa PRD justru makin penting pas AI yang ngoding

Dulu alasan orang skip PRD masuk akal. "Yang ngoding aku sendiri, aku udah tahu maunya apa." Konteksnya ada di kepala, jadi ngapain ditulis.

Sekarang yang ngetik kode itu agent, bukan kamu. Dan agent nggak bisa baca isi kepalamu. Setiap celah yang kamu biarkan kosong, dia isi sendiri pakai tebakan. Tebakannya sering masuk akal secara umum, tapi jarang persis yang kamu bayangin. Kamu minta "form pendaftaran", dia kasih 12 field padahal kamu cuma butuh 3. Kamu bilang "simpan tanggal", dia pilih format yang beda dari sisa datamu.

Makin pinter agent-nya, makin cepat dia ngebangun asumsi yang salah. PRD nutup celah itu di depan. Ini juga inti alasan kenapa banyak orang pindah dari ngasal ke mulai dari spec dulu: bukan biar terlihat rapi, tapi biar output-nya bisa ditebak.

Anatomi PRD yang beneran kepakai

Lupakan template korporat. PRD yang berguna buat diserahkan ke agent cukup punya empat bagian:

• Tujuan — satu-dua kalimat: fitur ini buat apa dan buat siapa. Ini yang bikin agent nolak nambah hal yang nggak diminta.
• Entitas data — objek utama dan field-nya. Di sinilah nama tabel, tipe data, dan relasi dikunci. Bagian yang paling sering dilewat, dan paling sering bikin berantakan.
• Alur — langkah dari aksi user sampai hasil. Bukan cerita panjang, cukup urutan yang jelas.
• Aturan & edge case — kondisi yang gampang kelupaan: input kosong, data ganda, hari libur, kuota habis. Bagian ini yang misahin PRD beneran dari daftar keinginan.

Bagian yang paling nentuin bukan tujuan atau alur, tapi aturan dan edge case. Agent hampir selalu bisa nebak alur bahagia. Yang dia nggak bisa tebak: apa yang harus terjadi pas ada yang meleset. Begini kira-kira potongan PRD yang cukup ketat buat langsung diserahkan:

# PRD ringkas — Fitur: Reminder Servis Kendaraan

## Entitas
Reminder {
  id
  customer_id      -> Customer.id
  kendaraan_id     -> Kendaraan.id
  jenis_servis     enum: rutin | berat | garansi
  jatuh_tempo      date
  status           enum: pending | terkirim | selesai | batal
  channel          enum: wa | email
}

## Aturan
- Reminder dibuat H-7 dari jatuh_tempo, sekali per kendaraan per siklus.
- Kirim jam 09:00 waktu lokal customer. Di luar jam itu, masuk antrean.
- Status "selesai" hanya boleh transisi dari "terkirim".

## Edge case
- Nomor WA tidak valid       -> fallback ke email, set channel = email.
- 2 kendaraan customer jatuh tempo di hari sama -> gabung jadi 1 pesan.
- Jatuh tempo pas libur nasional -> geser kirim ke hari kerja berikutnya.

Perhatikan nggak ada satu kata "mulus" atau "user-friendly" di situ. Semuanya bisa diverifikasi. Agent baca ini, dia tahu persis kapan status boleh pindah dan apa yang terjadi pas nomor WA-nya ngaco. Nggak ada ruang buat nebak.

PRD korporat tebal vs PRD ramping buat agent

PRD tradisional ditulis buat manusia yang bakal rapat dulu sebelum ngoding. Isinya ada latar belakang bisnis, analisis kompetitor, target metrik kuartal, persona lengkap dengan nama dan foto. Berguna di konteksnya. Berlebihan buat nyuruh agent bikin satu fitur.

PRD buat agent lebih pendek dan lebih padat aturan. Yang dipangkas: basa-basi naratif dan justifikasi. Yang justru dipertebal: entitas data, konvensi penamaan, dan edge case. Agent nggak butuh diyakinkan kenapa fitur ini penting. Dia butuh tahu field-nya apa aja dan apa yang haram dilakukan.

Satu hal yang tetap wajib di dua-duanya: konsistensi konvensi. Kalau PRD bilang pakai camelCase dan response API selalu dibungkus objek data, itu harus dipegang. Lebih bagus lagi kalau aturan konvensi ini juga kamu taruh di file rules seperti CLAUDE.md biar agent nggak lupa di tengah sesi panjang.

Salah kaprah: PRD itu ribet dan bikin lama

Ini keberatan paling umum, dan datang dari trauma PRD korporat. Orang ngebayangin harus nulis dokumen 30 halaman sebelum boleh ngetik satu baris kode. Padahal PRD ramping buat satu fitur bisa selesai dalam 15 menit, dan waktu itu balik berkali lipat begitu agent nggak salah bangun struktur.

1. "PRD harus lengkap dari awal." Nggak. PRD itu hidup. Mulai dari yang kamu tahu, tambahin edge case pas ketemu.
2. "Kalau proyek kecil nggak perlu PRD." Justru proyek kecil paling untung, karena kamu bisa selesai sekali jalan tanpa bolak-balik benerin tebakan agent.
3. "PRD cuma buat aplikasi besar." Bikin skrip Google Apps Script pun kepakai. Entitas sheet, kolom, dan aturan validasi itu tetap harus dikunci.

Cara paling cepat lihat bedanya: bandingin prompt "bikinin app absensi" sama PRD yang udah nyebut entitas Karyawan, aturan jam masuk, dan edge case telat. Prompt yang presisi selalu menang, dan itu berlaku juga buat cara nulis prompt ke agent di luar PRD.

Jadi fungsi PRD sebenarnya apa

Diringkas, PRD ngerjain beberapa hal sekaligus:

• Jadi kontrak: agent ngoding sesuai aturan, bukan default bawaannya.
• Bikin output bisa ditebak: ganti agent atau ulang sesi, polanya tetap sama.
• Mindahin keputusan ke depan: kamu mikirin edge case sekali, bukan pas produksi udah kebakar.
• Jadi memori bersama: kamu, timmu, dan agent baca sumber yang sama.
• Mempercepat, bukan memperlambat: sedikit waktu di depan nukar banyak waktu benerin di belakang.

Cara mulai bikin PRD tanpa mikir lama

Nggak usah nunggu sempurna. Ambil satu fitur, tulis empat bagian tadi: tujuan, entitas, alur, aturan dan edge case. Kalau macet, mulai dari entitas datanya dulu, biasanya sisanya ngikut.

Kalau mau kerangka yang lebih terarah, ada panduan bikin PRD langkah demi langkah dan kumpulan template plus contoh PRD siap pakai. Mau lihat wujud jadinya dulu? Buka contoh PRD yang udah jadi biar kebayang seberapa detail yang cukup.

Atau lewati ngoding dokumennya dari nol. Skematik nulis PRD terstruktur dari deskripsi idemu, lengkap dengan entitas dan aturan, tinggal kamu rapikan sebelum diserahkan ke agent.

Ide di kepala itu murah. Yang mahal itu benerin tebakan agent. PRD nutup jaraknya.