Sebagian besar riset pengguna sebelum peluncuran adalah sandiwara, dan yang terburuk, kedua belah pihak tahu naskahnya. Kamu bertanya "apakah kamu akan menggunakan sesuatu seperti ini," dan orang di seberang panggilan — yang bersikap baik, yang tidak punya kepentingan apa pun, yang membayangkan produk yang belum ada — menjawab ya. Kamu mencatatnya sebagai validasi. Padahal bukan. Itu hanya orang asing yang bersikap sopan terhadap sebuah hipotesis.
Dulu saya rutin melakukan wawancara semacam ini, karena setiap buku strategi produk menyuruhnya. Bicara dengan lima puluh pengguna sebelum menulis satu baris kode. Temukan titik masalahnya. Validasi masalah sebelum solusi. Terdengar disiplin, dan terlihat bagus di papan tulis. Tapi hasil sebenarnya dari sepuluh panggilan discovery adalah sepuluh orang memberitahumu apa yang mereka kira ingin kamu dengar, disaring melalui ingatan samar mereka sendiri tentang masalah yang tidak pernah mereka pikirkan sejak panggilan dimulai. Tidak ada yang sengaja berbohong padamu. Mereka hanya belum punya informasinya — karena informasi itu tidak ada sampai produknya benar-benar ada.
Hal yang tidak bisa dihasilkan wawancara
Yang sebenarnya perlu kamu ketahui sebelum membangun bersifat perilaku, bukan sikap: apakah seseorang akan membuka aplikasi ini lagi, apakah mereka akan membayarnya, apakah mereka akan tersendat di layar ketiga lalu berhenti. Tidak ada satu pun dari itu yang muncul dalam percakapan. Itu muncul dalam rekaman sesi, grafik drop-off, tiket dukungan. Pengguna bisa mengatakan dengan sangat tulus bahwa onboarding "masuk akal," lalu meninggalkannya empat puluh detik kemudian, karena laporan-diri dan perilaku adalah dua alat ukur berbeda yang mengukur dua hal berbeda.
Dulu, faktor ekonomi memang memaksa urutan wawancara-dulu. Jika membangun sesuatu memakan waktu delapan minggu dan tiga engineer, kamu tidak mampu menanggung risiko baru menyadari itu salah setelah dirilis — jadi kamu memindahkan risiko ke percakapan murah dan berharap itu menangkap kesalahan mahal. Trade-off itu masuk akal ketika proses membangun adalah bottleneck-nya. Sekarang tidak lagi. Prototipe yang benar-benar berfungsi — dengan autentikasi asli, basis data asli, UI yang bisa benar-benar diklik orang — kini bisa kamu bangun dalam satu sore dengan alat yang tepat, termasuk milik saya. Setelah biaya membuat versi pertama turun sedrastis itu, wawancara berhenti menjadi cara murah mengurangi risiko dan justru menjadi langkah yang mahal. Kamu membayar dengan berminggu-minggu waktu kalender hanya untuk menghindari pembangunan yang sebenarnya cuma butuh satu akhir pekan.
Yang saya lakukan sebagai gantinya
Bangun versi terkecil yang nyata dari ide tersebut, tunjukkan ke tiga sampai lima orang sungguhan yang mengalami masalah itu, lalu amati, jangan bertanya. Bukan "apa pendapatmu" — tapi di mana kursor mereka ragu-ragu, apa yang mereka klik yang ternyata tidak melakukan apa-apa, apa yang mereka coba lakukan tapi sama sekali tidak didukung produk. Yang terakhir itulah emas sesungguhnya: hal yang mereka coba lakukan tanpa diminta adalah sinyal yang lebih jujur daripada apa pun yang akan mereka katakan dalam wawancara hipotetis, karena itu preferensi yang terungkap, bukan preferensi yang dinyatakan.
Ini membalikkan corong riset tradisional, dan penting untuk menjelaskan secara eksplisit apa yang berubah:
| Wawancara-dulu | Bangun-dulu | |
|---|---|---|
| Apa yang kamu ukur | Niat yang dinyatakan ("Sepertinya saya akan pakai ini") | Perilaku yang terungkap (mereka membukanya tiga kali minggu ini, atau tidak sama sekali) |
| Biaya jika salah | Rendah per siklus, tapi kamu bisa salah selama berbulan-bulan lewat puluhan wawancara | Satu siklus pembangunan, lalu data segera mengoreksimu |
| Pertanyaan terbaik untuk diajukan | "Apa yang membuatmu frustrasi dengan cara kamu melakukan ini sekarang?" | "Tunjukkan padaku terakhir kali kamu mencoba melakukan X di sini" |
| Hal yang paling bisa ditemukannya | Apakah suatu masalah benar-benar ada | Apakah solusi spesifik Anda untuk masalah itu berhasil |
| Mode kegagalan | Semua orang bersikap sopan, tidak ada yang jujur, dan Anda membangun hal yang salah dengan penuh percaya diri | Anda merilis sesuatu yang masih kasar sebelum berhasil mendapatkan kepercayaan, dan itu meninggalkan kesan pertama yang buruk |
Perhatikan bahwa kedua baris ini tidak saling meniadakan — keduanya menjawab pertanyaan yang berbeda. Wawancara cukup baik untuk memastikan sebuah masalah itu nyata. Namun wawancara buruk dalam memberi tahu Anda apakah solusi spesifik Anda sudah tepat, karena solusi spesifik Anda belum ada untuk ditanggapi secara jujur oleh siapa pun. Itulah perbedaan yang sering dilewatkan oleh sebagian besar saran "ngobrol dengan pengguna": saran itu biasanya bagus untuk menemukan masalah, tapi buruk untuk memvalidasi solusi, dan orang-orang menerapkannya untuk keduanya sekaligus.
Seorang founder yang saya kenal melakukan empat belas wawancara untuk alat penjadwalan yang ditujukan untuk salon rambut. Tiga belas orang mengatakan masalah double-booking itu nyata dan menyusahkan. Dia pun membangunnya. Adopsinya datar. Ternyata pemilik salon memang benci double-booking secara konsep, tapi mereka sudah punya cara mengatasinya sendiri yang rapuh dan tidak ingin mereka tinggalkan — sesuatu yang tidak disebutkan siapa pun, karena tidak ada yang terpikir untuk menceritakan mekanisme penanganannya sendiri kecuali Anda menunjukkan penggantinya dan melihat mereka menolaknya.
Di mana para pengkritik benar
Ini tidak berlaku di semua kondisi, dan saya akan melebih-lebihkan kalau berpura-pura sebaliknya. Jika pembangunan produk benar-benar mahal untuk dibalik — perangkat keras, alur kerja medis yang diregulasi, apa pun yang setiap perubahannya memerlukan tinjauan kepatuhan — maka perhitungan wawancara-dulu kembali berlaku, karena asimetri biaya yang membuat bangun-dulu murah sama sekali tidak berlaku di situ. Prototipe yang bisa dibuang begitu saja dalam semalam adalah hal yang sangat berbeda dari perangkat yang cetakannya sudah dibuat khusus.
Tempat lain di mana riset benar-benar berguna adalah penjualan enterprise dengan siklus panjang. Jika pembeli Anda adalah komite pengadaan dan siklus penjualan Anda empat bulan, Anda tidak bisa "sekadar merilis dan mengamati" untuk mendapatkan kontrak yang ditandatangani — Anda perlu tahu sebelum membangun apakah produk itu bahkan lolos tinjauan keamanan, karena kesepakatan yang ditolak setelah enam bulan jauh lebih mahal daripada wawancara mana pun. Dan penemuan masalah murni, yang dilakukan sejak awal dan murah — duduk bersama seseorang saat mereka menjalankan pekerjaan sehari-hari mereka, bukan meminta mereka membayangkan produk masa depan — sungguh kurang dimanfaatkan dan sungguh berguna. Saya tidak menentang ngobrol dengan orang. Saya menentang memperlakukan percakapan hipotetis yang sopan sebagai bukti, padahal sebuah build kasar yang nyata di depan orang yang sama selama sepuluh menit akan memberi tahu Anda kebenarannya.
