CB Insights menerbitkan rincian tahunan tentang mengapa startup gagal. Selama bertahun-tahun, alasan pertama selalu sama: "tidak ada kebutuhan pasar." Bukan eksekusi yang buruk. Bukan kehabisan uang. Bukan tim yang buruk. Produk itu cukup tidak menyelesaikan masalah yang cukup diinginkan orang untuk mengubah perilaku mereka.
Statistik itu menakjubkan ketika Anda menganggap berapa banyak usaha yang masuk ke dalam membangun produk. Tim menghabiskan berbulan-bulan — kadang bertahun-tahun — merancang sistem, menulis kode, berdebat tentang arsitektur, dan menyempurnakan aliran. Dan alasan paling umum mereka gagal adalah bahwa tidak ada orang yang menanyakan apakah ada dari itu benar-benar menyelesaikan masalah nyata.
Membangun produk yang benar-benar diinginkan orang bukan bakat. Ini adalah disiplin. Ini memiliki metode, dan metode itu dapat dipelajari.
Kesalahan produk paling umum adalah jatuh cinta dengan solusi sebelum Anda benar-benar memahami masalahnya. Ini hampir universal di kalangan pendiri pertama kali dan mengejutkan sering di kalangan yang berpengalaman. Polanya selalu sama: seseorang memiliki ide, mereka menganggapnya menarik, dan mereka mulai membangun. Pelanggan adalah pikiran belakangan — seseorang untuk diyakinkan, bukan dipahami.
Penawar adalah tidak rumit tetapi membutuhkan disiplin: menghabiskan lebih banyak waktu pada masalah daripada yang menurut Anda diperlukan, sebelum Anda mempertimbangkan solusi sama sekali. Bicarakan dengan orang-orang yang memiliki masalah. Saksikan mereka bekerja. Pahami workaround yang mereka gunakan hari ini dan mengapa workaround itu tidak sempurna. Hanya kemudian Anda memiliki konteks yang cukup untuk merancang sesuatu yang benar-benar cocok.
Pengembangan produk yang baik bukan garis lurus — itu adalah loop. Setiap iterasi di sekitar loop adalah kesempatan untuk mengganti asumsi dengan bukti. Tim yang membangun produk yang diinginkan orang adalah yang menyelesaikan loop ini dengan cepat dan sering.
Loop bukan formalitas. Setiap tahap memiliki keluaran spesifik yang menjadi masukan untuk tahap berikutnya. Melompat tahap — paling umum melompat langsung dari Masalah ke Bangun — adalah apa yang menghasilkan produk yang melewatkan titik.
Tidak semua masalah layak diselesaikan. Masalah produk yang baik memiliki tiga kualitas: itu sering (mempengaruhi orang sering, bukan jarang), itu intens (orang merasakannya cukup untuk menginginkan bantuan), dan solusi yang ada benar-benar tidak memadai (tidak hanya sedikit berbeda dari apa yang akan Anda bangun).
Kesalahannya adalah mengoptimalkan untuk kualitas pertama dan mengabaikan dua lainnya. "Orang membuang waktu di pertemuan" sering. Tetapi jika rasa sakitnya rendah — jika orang telah menemukan workaround yang cukup baik — masalahnya mungkin tidak layak diselesaikan secara komersial. Dan jika sudah ada dua belas alat yang melakukan apa yang ingin Anda lakukan, Anda membutuhkan alasan yang sangat spesifik mengapa milik Anda akan dipilih.
Penelitian memiliki reputasi buruk di lingkaran produk — ini dikaitkan dengan konsultan lambat, laporan tebal, dan temuan yang tidak ada orang membaca. Itu adalah kegagalan eksekusi, bukan praktik. Penelitian produk yang baik cepat, spesifik, dan mengubah apa yang Anda bangun.
Tujuan penelitian bukan untuk memastikan bahwa masalahnya nyata. Anda harus sudah percaya bahwa sebelum Anda banyak berinvestasi dalam penelitian. Tujuannya adalah memahami masalah cukup dalam untuk mengetahui seperti apa solusi yang baik: siapa secara spesifik yang memiliki masalah, dalam konteks apa, apa yang sudah mereka coba, kata-kata apa yang mereka gunakan untuk mendeskripsikannya, dan apa "diselesaikan" akan terlihat bagi mereka.
Hipotesis adalah prediksi spesifik, dapat dipalsukan tentang apa yang Anda percaya benar. Ini memaksa kejelasan. Jika Anda tidak dapat menulis hipotesis yang jelas, Anda belum cukup memahami masalahnya untuk membangun solusi.
Hipotesis produk yang berguna memiliki tiga bagian:
Sinyal adalah bagian paling penting — dan yang paling sering dihilangkan. Tanpa kondisi pemalsuan yang telah ditetapkan sebelumnya, setiap eksperimen "agak berhasil." Tim menemukan cara untuk menafsirkan data yang ambigu secara menguntungkan. Hipotesis tanpa kondisi pemalsuan hanya berupa keinginan.
Fase bangun adalah di mana sebagian besar tim menghabiskan terlalu banyak waktu. Tujuannya bukan untuk membangun produk — itu untuk membangun hal minimum yang akan memberi Anda sinyal pada hipotesis Anda. Ini adalah tujuan yang berbeda dan mereka menghasilkan output yang sangat berbeda.
Untuk sebagian besar hipotesis tahap awal, minimum jauh lebih kecil daripada yang dipikirkan tim. Bisakah Anda secara manual melakukan apa yang akan dilakukan perangkat lunak, untuk sepuluh orang, untuk menguji apakah mereka menghargai hasilnya? Bisakah Anda mengurangi alat yang ada dan menguji alur kerja sebelum Anda membangun infrastruktur baru? Bisakah Anda membuat sketsa prototipe dan menjalannya melalui lima pengguna sebelum menulis kode apa pun?
Disiplin di sini adalah bertanya, sebelum membangun apa pun: "Apa yang saya coba pelajari?" dan "Apa hal terkecil yang akan membiarkan saya mempelajarinya?" Jawabannya hampir selalu lebih kecil dari yang ingin dibangun tim.
Setelah peluncuran — baik itu prototipe, pilot manual, atau fitur yang diterapkan — fase pengukuran adalah di mana tim paling sering menipu diri sendiri. Mereka menanyakan kepada pengguna apakah mereka menyukainya. Pengguna mengatakan ya. Tim menandai eksperimen sebagai divalidasi.
Sentimen bukan sinyal. Satu-satunya sinyal yang dapat diandalkan adalah perilaku: apakah orang melakukan hal itu? Apakah mereka kembali? Apakah mereka bayar? Apakah mereka memberitahu orang lain?
Untuk pengukuran kuantitatif, instrumen sebelum Anda meluncurkan. Tahu tindakan spesifik mana yang Anda lacak. Tetapkan ambang batas sebelumnya — "kami akan mempertimbangkan ini divalidasi jika X% pengguna menyelesaikan Y dalam Z hari." Untuk pengukuran kualitatif, lakukan wawancara tindak lanjut terstruktur, bukan survei kepuasan terbuka.
Fase pembelajaran adalah tentang memperbarui model mental Anda tentang pengguna dan masalahnya, bukan hanya memutuskan apa yang akan dibangun selanjutnya. Tim yang melompati langkah ini mengumpulkan data tetapi tidak mengumpulkan pemahaman. Mereka menjalankan dengan cepat tetapi tidak meningkatkan penilaian mereka seiring waktu.
Sesi pembelajaran yang baik menanyakan: Apa yang kami prediksi? Apa yang sebenarnya terjadi? Apa kesenjangan itu katakan kepada kami tentang asumsi kami? Apa sekarang hal paling penting yang tidak kami tahu?
Keluaran dari fase pembelajaran adalah definisi masalah yang lebih tajam, hipotesis yang direvisi, atau — jika eksperimen jelas gagal — keputusan untuk mengejar arah yang berbeda sepenuhnya. Semua hasil ini berharga. Hasil terburuk adalah keambiguan: "kami belajar beberapa hal tetapi tidak yakin apa yang harus dilakukan selanjutnya." Itu adalah tanda bahwa eksperimen tidak cukup spesifik.
Pengembangan produk tidak pernah mencapai tahap di mana Anda berhenti menjalankan loop ini. Pertanyaan berubah — awal Anda memvalidasi apakah masalahnya nyata; kemudian Anda memvalidasi apakah elemen solusi tertentu bekerja — tetapi strukturnya selalu sama. Amati, buat hipotesis, uji, pelajari.
Tim yang membangun produk yang diinginkan orang bukan yang dengan wawasan awal paling cerdas. Mereka adalah yang menyelesaikan loop paling cepat dan paling jujur. Kecepatan pembelajaran, bukan kecepatan pengiriman, adalah keunggulan kompetitif.