Pagi ini Anda membuka halaman Notion berjudul "PRD: [nama fitur]." Tiga jam kemudian, judulnya masih "PRD: [nama fitur]."
Anda tahu masalahnya. Anda tahu solusinya. Anda sudah menjelaskannya dua kali kepada lead engineering kemarin. Tapi begitu Anda duduk untuk menuliskannya, Anda macet.
Ini bukan masalah berpikir. Ini masalah mengetik.
PM tidak dibayar untuk mengetik. Anda dibayar untuk membuat keputusan tentang apa yang harus dibangun dan mengapa. PRD hanyalah artefak yang mendokumentasikan keputusan itu agar engineering, design, dan leadership bisa bertindak. Di antara tahu apa yang ingin ditulis dan menyelesaikan dokumennya, berjam-jam menghilang begitu saja.
Ada jalan yang lebih cepat. PRD adalah salah satu dokumen yang paling cocok untuk suara di antara semua yang ditulis seorang PM. Pada dasarnya ini sama dengan yang akan Anda ucapkan sambil berdiri di depan whiteboard menjelaskan fiturnya. Begitu Anda berhenti mengetik PRD dan mulai mendiktekannya, waktu draf Anda langsung turun.
Pajak menulis yang dibayar PM dan jarang dibicarakan
Setiap PRD yang Anda tulis bersaing dengan meeting, roadmap review, dan thread Slack dari stakeholder. Penulisan yang sesungguhnya hanya terjadi di sela-sela waktu setengah jam yang Anda curi atau setelah makan malam.
Matematikanya kejam. Rata-rata orang mengetik sekitar 40 kata per menit. Rata-rata orang berbicara sekitar 150. Selisih sekitar 3,5x sebelum Anda menghitung semua friksi yang membuat menulis jadi lebih berat: menghapus, mengulang kalimat, ragu-ragu tiga kali sebelum melanjutkan.
PRD 1.500 kata yang butuh 90 menit untuk diketik hanya butuh sekitar 25 menit untuk diucapkan. Pikirannya sama. Hasilnya sama. Yang berubah hanya cara menuangkannya.
Kenapa PRD sangat cocok untuk suara
Sebagian besar dokumen menghukum dikte karena menuntut presisi: kode, tabel, model finansial. PRD justru sebaliknya. PRD adalah dokumen naratif.
Coba ingat PRD terakhir yang Anda tulis. Bagian "Problem" adalah dua paragraf yang menjelaskan kenapa sesuatu itu penting. Bagian "Solution" adalah deskripsi cara kerja fiturnya. "User Stories" adalah kalimat-kalimat berformat "Sebagai X, saya ingin Y, supaya Z." Bagian "Edge Cases" adalah daftar skenario "apa yang terjadi kalau...".
Tidak ada satu pun dari itu yang menuntut akurasi keyboard. Semuanya adalah hal yang akan Anda ucapkan di sebuah meeting. Formatnya sudah sesuai dengan cara seorang PM benar-benar mengomunikasikan pekerjaan.
Alur kerja draf PRD 30 menit
Berikut struktur yang berhasil: 1. Buka dokumen kosong dengan header bagian yang sudah disiapkan: problem, solution, user stories, acceptance criteria, edge cases, out of scope, open questions. 2. Kerjakan bagian per bagian. Diktekan tiap bagian seolah-olah Anda menjelaskannya ke engineer baru yang baru bergabung di tim. 3. Jangan mengedit sambil berbicara. Pergeseran mental antara "pembicara" dan "editor" itulah yang paling memperlambat Anda. 4. Setelah mendiktekan semua bagian, baca draf lengkap sekali dari atas ke bawah. Rapikan bahasanya. Perbaiki yang benar-benar salah. 5. Kirim untuk review.
Disiplinnya ada di langkah ketiga. Kalau Anda terus berhenti untuk memperbaiki kalimat, Anda tidak mendapatkan keuntungan kecepatannya. Anda kembali ke kecepatan mengetik, hanya dengan kostum yang berbeda.
Bagian per bagian: cara mendiktekan tiap bagian PRD
Beberapa bagian lebih mudah didiktekan daripada yang lain. Berikut cara menanganinya satu per satu.
Pernyataan masalah
Ini bagian paling mudah untuk didiktekan. Murni naratif. Anda sedang menjelaskan apa yang rusak, untuk siapa, dan kenapa hal itu penting sekarang.
Ucapkan seperti Anda sedang memberi briefing ke rekan tim baru saat stand-up. Sebutkan segmen pengguna, friksi yang mereka rasakan, metrik yang terdampak. Jangan pusingkan keanggunan prosa. Itu urusan saat mengedit.
Gambaran solusi
Jelaskan solusi yang Anda usulkan seperti Anda sedang menggambarnya di whiteboard. "User klik di sini, lihat ini, lalu..." Suara menangani ini dengan mulus karena sesuai dengan cara Anda menjelaskannya secara lisan.
User story
User story terdengar mekanis karena polanya "Sebagai X, saya ingin Y, supaya Z", tapi cukup nyaman didiktekan kalau Anda konsisten dengan formatnya. Ucapkan tiap story sebagai satu kalimat, lalu lanjut ke berikutnya.
Kalau Anda punya sepuluh story, diktekan semuanya dalam satu sapuan. Jangan menomori sambil bicara. Biarkan editor dokumen atau pass pembersihan AI yang mengurus formatnya.
Acceptance criteria
List adalah bagian tersulit dalam dikte suara, tapi tetap bisa dikerjakan. Ada dua pendekatan:
Yang pertama, diktekan kriteria sebagai kalimat utuh dan biarkan AI yang merapikannya menjadi list. Ucapkan misalnya: "User harus bisa memfilter hasil berdasarkan tanggal, berdasarkan user, dan berdasarkan status. State filter harus bertahan antar sesi. Empty state harus menampilkan tip."
Yang kedua, ucapkan struktur bullet-nya secara eksplisit: "Bullet satu, filter berdasarkan tanggal. Bullet dua, filter berdasarkan user. Bullet tiga, bertahan antar sesi." Pilih mana yang paling tidak janggal di mulut Anda.
Edge case
Di sinilah suara benar-benar bersinar. Edge case adalah jenis konten "berpikir keras" yang keluar mulus saat diucapkan dan kaku saat diketik. Pertanyaan seperti "apa yang terjadi kalau user offline" atau "bagaimana kalau datanya sudah basi" mengalir lebih alami dalam bentuk lisan ketimbang tulisan.
Diktekan setiap edge case yang terlintas, bahkan yang terlihat jelas. Anda bisa memangkasnya saat mengedit.
Out of scope
Tiga kalimat. Mungkin empat. Suara menyelesaikannya dalam waktu kurang dari satu menit.
Open question
Bagian ini sering diremehkan. Kebanyakan PM melewatkannya karena tidak ingin terlihat ragu. Jangan dilewatkan. Bagian open question justru tempat engineering, design, dan skip-level Anda menangkap hal-hal yang belum sempat Anda pikirkan.
Suara adalah alat yang tepat untuk ini. Open question persis seperti pikiran setengah jadi yang keluar bagus saat diucapkan dan terasa anehnya berat saat dicoba ketik. Diktekan setiap ketidakpastian, bahkan yang Anda duga sudah ada jawaban jelasnya. Setengahnya akan tuntas di standup berikutnya. Setengah lainnya bisa menyelamatkan launch Anda.
Menyesuaikan nada dengan tiap bagian
PRD tidak ditulis dengan satu suara. Exec summary di bagian atas seharusnya padat dan strategis. Spesifikasi teknis harus presisi. Bagian "open question" boleh lebih santai.
Saat mendiktekan, Anda secara alami berganti register. Nada Anda lebih formal saat membicarakan strategi dan lebih cair saat menjelaskan edge case. Masalahnya, kebanyakan alat dikte mengeluarkan transkripsi datar yang sama, tidak peduli konteksnya.
Di sinilah Smart Rules Voicr berperan. Anda bisa menyetel gaya "clean professional spec" untuk editor dokumen, gaya "casual brainstorming" untuk thread Slack, dan gaya "technical clarity" untuk wiki engineering. Voicr mendeteksi aplikasi yang sedang aktif dan menerapkan gaya yang tepat secara otomatis, jadi satu pikiran yang sama bisa mendarat dengan nada berbeda tergantung tujuannya.
Khusus untuk PRD, buat aturan yang meminta prosa profesional yang rapi, menghapus filler word, dan menyusun bullet list di tempat yang Anda tandai. Anda bicara sekali. Dokumennya terbaca seolah Anda menulisnya dengan teliti.
Di mana suara tidak banyak membantu
Jujur saja: tidak semua bagian PRD diuntungkan oleh suara.
Tabel dan matriks masih lebih cepat diketik. Kalau PRD Anda berisi grid perbandingan fitur, matriks permission, atau tabel estimasi ukuran, ketik saja.
String teknis yang persis juga lebih cepat diketik. Nama endpoint API, nama kolom database, nomor versi — Anda memang bisa mendiktekannya ("endpoint-nya garis miring users garis miring ID") tapi rasanya janggal. Ketik yang seperti itu.
Diagram jelas tidak bisa didiktekan. Sketsa di tool pilihan Anda, lalu sematkan.
Untuk semua sisanya — narasi, user story, edge case, keputusan, rasional — suara unggul dalam kecepatan, dan dalam fakta bahwa Anda tidak macet di tengah kalimat hanya karena ingin merangkai sesuatu dengan sempurna.
Pergeseran cara berpikir: berpikir keras dulu, mengedit belakangan
Keuntungan terbesar dari mendiktekan PRD bukanlah hitungan WPM. Tapi bahwa Anda berhenti memoles sambil menulis.
Saat mengetik, Anda menghapus. Anda menulis ulang satu kalimat dua kali. Anda menatap satu paragraf yang "hampir benar" selama sepuluh menit. Di situlah PRD biasa mati: di celah antara membuat draf dan mengedit, di mana tidak ada yang benar-benar terjadi.
Saat mendiktekan, Anda berkomitmen. Anda ucapkan satu kalimat, ia mendarat di halaman, dan Anda lanjut. Sapuan pertama memang lebih berantakan daripada yang akan Anda ketik. Tapi Anda menyelesaikan drafnya. Dan draf berantakan yang selesai jauh lebih berguna daripada draf rapi yang setengah jadi.
Begitu draf-nya ada, mengedit menjadi aktivitas yang berbeda dan jauh lebih cepat. Anda sering kali akan menghabiskan lebih banyak waktu untuk merapikan ketimbang mendiktekan, dan itu tidak masalah. Merapikan dokumen yang utuh adalah pekerjaan yang jelas. Menatap dokumen kosong tidak.
Coba di PRD berikutnya
Pilih PRD yang sudah lama Anda tunda. Buka dokumennya, letakkan header tiap bagian, lalu diktekan dari atas ke bawah tanpa mengedit. Setel timer 25 menit. Lihat hasilnya.
Pertama kali mencoba, rasanya akan canggung. Anda akan khawatir hasilnya kurang bagus. Tahan dorongan untuk memperbaiki di tengah jalan. Selesaikan saja.
Kalau Anda ingin hasil dikte yang langsung cukup rapi sampai nyaris tidak perlu diedit, Voicr menangani pemolesannya secara otomatis. Tahan FN dari mana saja di Mac, ucapkan satu bagian, lepas, lalu tempel teks yang sudah dirapikan ke dokumen Anda. Voicr menghapus filler word, memperbaiki tata bahasa, dan menata pikiran Anda sebelum sampai ke clipboard. PRD yang dulu butuh seharian, sekarang bisa selesai dalam sekali duduk.
PRD Anda tidak akan menulis dirinya sendiri. Tapi juga tidak harus diketik.