Anda merilis sesuatu, orang mulai menggunakannya, dan dalam seminggu pesan-pesan mulai berdatangan. Ulasan bintang satu yang berbunyi "membingungkan". DM yang berbunyi "bisakah ini juga melakukan X". Tiket dukungan yang sebenarnya hanya seseorang yang curhat soal tombol yang tidak bisa ditemukannya. Ini adalah masalah yang bagus — artinya orang cukup peduli untuk memberi tahu Anda ada yang salah. Tapi ini juga saat kebanyakan builder diam-diam mulai memperburuk keadaan, karena mengubah satu feedback menjadi prompt terasa seharusnya sederhana, padahal hampir tidak pernah begitu.
Saya telah menyaksikan banyak build yang justru memburuk setelah diluncurkan, bukan membaik, dan jarang karena feedback-nya buruk. Itu terjadi karena apa yang terjadi di antara membaca pesan dan mengetik prompt berikutnya. Tiga pola ini muncul berulang kali.
Kesalahan satu: membangun persis apa yang mereka ketik
Seorang pengguna berkata "saya berharap ada toggle mode gelap di header." Jadi Anda membuka chat build dan mengetik: "tambahkan toggle mode gelap di header." Builder melakukannya. Tiket selesai, kan?
Padahal pengguna itu sebenarnya tidak ingin toggle di header — mereka ingin aplikasi berhenti menyakiti mata mereka di malam hari. Mungkin mereka ingin itu mengikuti preferensi sistem secara otomatis dan tidak perlu memikirkannya lagi. Mungkin masalah sebenarnya adalah latar belakang Anda berwarna putih menyilaukan dan toggle itu adalah solusi sementara yang mereka ciptakan karena mereka tidak tahu apa lagi yang harus diminta. Pengguna sangat pandai menggambarkan gejala dan tidak bisa diandalkan dalam meresepkan solusi, karena mereka tidak tahu apa yang murah atau mahal untuk dibangun, dan mereka tidak memikirkan dua belas tempat lain di aplikasi yang juga harus menghormati toggle tersebut.
Kerusakannya di sini menumpuk. Anda mendapat lima permintaan fitur dalam seminggu, Anda menerapkan kelimanya secara literal, dan sekarang Anda punya panel pengaturan dengan toggle mode gelap, toggle "tampilan ringkas", toggle "sembunyikan sidebar", dan checkbox "mode sederhana" yang setengah bertentangan dengan tiga lainnya. Tidak ada yang meminta panel pengaturan. Anda tetap membangunnya, satu permintaan literal demi satu permintaan literal, dan sekarang setiap fitur baru harus diuji terhadap kombinasi kondisi toggle yang membingungkan yang tak seorang pun ingat pernah mengaktifkannya.
Permintaan itu adalah data. Bukan spesifikasi. Tugas Anda adalah langkah penerjemahan di antaranya, dan melewatkannya adalah cara paling umum feedback berubah menjadi fitur yang menggelembung tanpa guna.
Kesalahan dua: diam saja, lalu menumpahkan semuanya sekaligus
Kegagalan yang sebaliknya terlihat disiplin dari luar. Anda tidak bereaksi terhadap setiap pesan yang masuk — insting yang bagus, sebagian besar. Tapi kemudian Anda membiarkan tiket menumpuk selama dua minggu di spreadsheet, dan suatu hari Sabtu Anda duduk dan menulis satu prompt panjang yang mencakup semuanya: "perbaiki bug checkout, tambahkan fitur ekspor, rombak alur onboarding, perbaiki nav mobile, dan perbarui teks halaman harga."
Builder akan berusaha sebaik mungkin dengan itu, tapi Anda baru saja meminta lima perubahan tidak terkait untuk diterapkan dalam satu langkah, di codebase di mana kelima hal tersebut kemungkinan menyentuh file yang saling tumpang tindih. Ketika ada yang rusak — dan dengan perubahan sebesar itu, biasanya memang ada yang rusak — Anda tidak bisa tahu permintaan mana dari kelimanya yang menyebabkannya. Riwayat versi Anda menunjukkan satu diff raksasa, bukan lima yang bisa ditinjau satu per satu. Jika Anda perlu membatalkan perbaikan checkout karena menimbulkan regresi, Anda juga akan membatalkan rombakan onboarding yang sebenarnya berjalan baik. Catatan verifikasi untuk pengiriman itu adalah tembok perubahan yang tidak akan dibaca baris demi baris oleh siapa pun, termasuk Anda sendiri.
Menggabungkan permintaan terasa efisien. Padahal justru sebaliknya begitu ada satu saja dalam gabungan itu yang bermasalah, karena sekarang debugging berarti mengurai lima benang, bukan mengikuti satu.
Kesalahan tiga: membiarkan pesan paling keras yang menentukan roadmap
Ini yang paling sulit disadari saat sedang dilakukan. Seorang pengguna mengirim email yang marah, detail, dan runtut tentang fitur yang mereka inginkan. Tulisannya bagus, spesifik, jelas menghabiskan sepuluh menit untuk menyusunnya — dan sepuluh menit perhatian sungguhan dari seseorang terasa layak mendapat sepuluh menit dari Anda juga. Jadi Anda menghentikan apa pun yang sedang Anda kerjakan dan membangun fitur itu.
Sementara itu empat puluh pengguna lain yang lebih pendiam mengalami langkah pendaftaran yang membingungkan yang sama setiap minggu dan langsung pergi. Tak satu pun dari mereka menuliskan paragraf tentang itu untuk Anda. Mereka tidak mengirim apa pun sama sekali — mereka hanya tidak kembali lagi, dan keheningan itu tidak pernah muncul di kotak masuk Anda menuntut respons. Kebaruan dan banyaknya kata bukanlah hal yang sama dengan tingkat kepentingan, tapi terasa seperti itu, terutama pada jam 11 malam saat satu pesan ada di depan Anda dan empat puluh non-konversi ada di dashboard analitik yang belum Anda buka.
| Kesalahan | Seperti apa bentuknya | Kerusakan yang ditimbulkan |
|---|---|---|
| Implementasi literal | Menuliskan prompt persis dengan kata-kata pengguna, tanpa dikaji ulang | Fitur menggelembung, toggle yang saling bertentangan, pengaturan yang tersebar ke mana-mana |
| Menggabungkan lalu menumpahkan sekaligus | Diam, lalu satu prompt raksasa berisi banyak permintaan sekaligus | Diff yang tidak bisa ditinjau, rollback yang sulit, regresi misterius |
| Roadmap ditentukan suara paling keras | Bereaksi terhadap siapa pun yang mengirim email paling baru atau paling mendesak | Mengejar kasus tepi sementara titik gesekan sebenarnya tidak tersentuh |
Seperti apa sebenarnya prompt yang tepat
Perbaikannya bukan diagram proses, melainkan kebiasaan: baca pesannya, lalu tanyakan apa yang sebenarnya mendasarinya sebelum menyentuh build chat sama sekali. Ketika pengguna mode gelap itu muncul, kebutuhan sebenarnya biasanya "mengurangi kelelahan mata di malam hari", dan jawaban yang lebih murah dan lebih baik seringkali adalah "ikuti pengaturan skema warna tingkat OS" — satu baris, tanpa antarmuka baru, tanpa tombol yang harus dipelihara. Ketika lima tiket masuk dalam seminggu, cari polanya sebelum menulis apa pun: jika tiga di antaranya sebenarnya adalah kebingungan yang sama yang dijelaskan dengan tiga cara berbeda, itu satu prompt, bukan tiga.
Jaga agar perubahan tetap bertujuan tunggal meskipun Anda termotivasi untuk bergerak cepat. "Perbaiki error checkout di mana pengguna tamu kehilangan keranjangnya saat refresh" adalah prompt yang bisa Anda verifikasi dalam satu kali jalan dan dibatalkan dengan bersih jika salah. Ini juga memberi Anda kartu versi yang bermakna enam minggu kemudian, alih-alih entri changelog yang hanya bertuliskan "berbagai perbaikan".
Dan timbang masukan berdasarkan pola, bukan volume perasaan. Keluhan singkat dan blak-blakan yang juga dialami tiga pengguna lain lebih layak mendapatkan prompt berikutnya dibanding permintaan yang ditulis dengan indah dari seseorang yang menjelaskan alur kerja yang tidak dilakukan orang lain. Di sinilah benar-benar melihat penggunaan — di mana orang berhenti, apa yang mereka klik sebelum pergi — jadi berharga, karena itu memberi tahu Anda apa yang dilakukan mayoritas diam sementara minoritas yang vokal mengirim email kepada Anda.
Tidak satu pun dari ini berarti abaikan pengguna yang meluangkan waktu untuk menulis kepada Anda. Artinya jangan biarkan "siapa yang menulis kepada saya paling baru dan paling meyakinkan" menjadi algoritma yang menentukan apa yang dibangun selanjutnya. Pesan itu adalah awal percakapan, bukan tiketnya. Penerjemahan dari apa yang dikatakan seseorang menjadi apa yang sebenarnya Anda minta dari builder tetap menjadi tugas Anda, setiap saat.
