Sebelum membangun produk, tim startup perlu tahu ke mana mereka hendak bergerak. Tim yang solid memang penting, tetapi tenaga, waktu, dan modal bisa habis jika semuanya diarahkan untuk menyelesaikan masalah yang sebenarnya tidak dianggap penting oleh siapa pun.
Di sinilah ide perlu diperlakukan bukan sebagai hasil inspirasi sesaat, melainkan sebagai dugaan yang harus diperiksa. Ide yang layak biasanya berangkat dari masalah nyata, dialami oleh orang tertentu, muncul berulang, dan cukup mengganggu sampai pengguna bersedia mengubah kebiasaan, mengalokasikan waktu, atau membayar untuk memperoleh solusi.
Jangan Mulai dari Produk yang Ingin Dibuat
Banyak calon founder memulai dengan kalimat, “Saya ingin membuat aplikasi tentang ini.” Kalimat tersebut belum menjelaskan siapa yang membutuhkan aplikasi itu, situasi apa yang hendak diperbaiki, dan mengapa solusi yang sudah ada belum cukup membantu.
Pendekatan Problem First Thinking membalik urutan tersebut. Problem First Thinking adalah cara berpikir yang menempatkan masalah pengguna sebagai titik awal, bukan fitur atau teknologi. Pertanyaan pertamanya bukan “Apa yang ingin kita bangun?”, melainkan “Masalah siapa yang ingin kita selesaikan, kapan masalah itu muncul, dan apa akibatnya jika dibiarkan?”
Bayangkan kamu sedang mengantre di kasir minimarket. Pelanggan di depan sibuk mencari uang pas, kasir harus menghitung kembalian, dan antrean bergerak lambat. Orang lain mungkin hanya merasa kesal, tetapi seorang founder dapat mencatat situasinya sebagai sinyal: proses pembayaran tertentu mungkin masih merepotkan dan layak dipahami lebih jauh.
Namun, satu kejadian belum otomatis menjadi peluang bisnis. Kamu perlu mencari tahu apakah hambatan itu dialami banyak orang, seberapa sering terjadi, siapa yang paling dirugikan, serta apakah mereka telah mencoba solusi lain. Tanpa pemeriksaan ini, kamu berisiko mengubah rasa jengkel sesaat menjadi produk mahal yang tidak memiliki pengguna cukup.
Menggali Pain, Bukan Sekadar Mengumpulkan Keluhan
Pengamatan awal sebaiknya dilanjutkan dengan penggalian penyebab. Misalnya, seorang guru melihat murid-murid sulit fokus saat belajar daring. Masalahnya mungkin bukan sekadar materi yang membosankan; bisa jadi navigasi platform membingungkan, koneksi tidak stabil, jadwal terlalu panjang, atau murid tidak mendapat umpan balik yang memadai.
Karena itu, founder perlu membedakan gejala dari akar masalah. Wawancara pengguna bukan kesempatan untuk mempromosikan ide, melainkan ruang untuk memahami perilaku yang benar-benar terjadi: apa yang dilakukan pengguna sekarang, bagian mana yang paling menyita waktu, solusi apa yang pernah dicoba, dan mengapa solusi itu belum memuaskan.
Dua ukuran penting dalam tahap ini adalah frekuensi dan tingkat keparahan. Masalah yang muncul setiap hari tetapi hanya menimbulkan ketidaknyamanan kecil belum tentu lebih menarik daripada masalah yang terjadi mingguan namun menyebabkan kehilangan pendapatan, keterlambatan, atau risiko besar. Keduanya perlu dilihat bersama, termasuk siapa yang memiliki kewenangan dan kemampuan untuk membayar penyelesaiannya.
Keluhan juga perlu dibaca dengan hati-hati. Orang bisa mengeluhkan sesuatu tanpa benar-benar mau mengubah perilaku, apalagi membayar. Sinyal yang lebih kuat muncul ketika mereka sudah mengeluarkan waktu, tenaga, atau uang untuk mengatasi masalah tersebut, meski cara yang dipakai masih manual dan tidak efisien.
Validasi Cepat Mengurangi Risiko Membangun Terlalu Banyak
Lean Thinking adalah pendekatan untuk belajar dari kenyataan dengan eksperimen kecil sebelum membuat produk besar. Dalam konteks pencarian ide, tujuannya bukan menghasilkan versi pertama yang tampak lengkap, melainkan menguji apakah pemahaman kita tentang masalah, pengguna, dan solusi memiliki dasar yang cukup.
Salah satu bentuknya adalah Minimum Viable Validation, yaitu validasi minimum yang dirancang untuk menguji asumsi paling berisiko dengan sumber daya terbatas. Bentuknya bisa berupa survei yang terarah, wawancara mendalam, halaman pendaftaran sederhana, prototipe yang belum lengkap, atau simulasi manual di balik layar.
Misalnya, jika kamu menduga pemilik kedai kesulitan mengatur pemesanan meja dan colokan, jangan langsung membuat platform lengkap. Kamu bisa lebih dulu menawarkan pengaturan reservasi secara manual kepada beberapa kedai, mencatat permintaan yang masuk, waktu yang dibutuhkan, kesalahan yang berulang, dan apakah pemilik kedai merasa bantuan itu cukup bernilai untuk dilanjutkan.
Eksperimen seperti ini bukan tanda bahwa tim belum serius. Justru, cara tersebut membantu memisahkan hal yang benar-benar dibutuhkan dari fitur yang hanya terlihat menarik di presentasi. Jika hasilnya lemah, tim dapat mengganti segmen pengguna, mempersempit masalah, atau menghentikan arah itu sebelum biaya membesar.
Kecepatan dalam Lean bukan berarti tergesa-gesa mengambil kesimpulan. Kecepatan berarti memperpendek jarak antara dugaan dan bukti, lalu bersedia mengubah keputusan ketika temuan lapangan tidak mendukung asumsi awal. Produk awal boleh sederhana, tetapi pertanyaan yang diuji harus jelas.
Mindset Menentukan Arah Ide
Dalam ilustrasi hipotetis, Budi dan Tono sama-sama ingin membangun startup sejak muda. Tono terpesona oleh teknologi kecerdasan artifisial dan langsung membayangkan aplikasi yang dapat menebak perasaan seseorang dari wajahnya. Ia mulai merancang fitur dan materi presentasi, tetapi belum menemukan pengguna yang punya kebutuhan mendesak terhadap solusi tersebut.
Budi mengambil jalur berbeda. Saat bekerja paruh waktu di kafe, ia berulang kali melihat pelanggan kebingungan mencari tempat duduk dan colokan listrik untuk bekerja. Ia belum memiliki jawaban, tetapi mulai mencatat situasi, berbicara dengan pelanggan dan pemilik kafe, lalu mencari tahu apakah persoalannya cukup sering terjadi dan apakah ada cara yang lebih baik untuk mengaturnya.
Perbedaan keduanya bukan semata-mata soal siapa yang lebih kreatif. Tono memulai dari teknologi lalu mencari pembenaran, sedangkan Budi memulai dari pengamatan lalu menyusun hipotesis. Hipotesis adalah dugaan yang dapat diuji, misalnya: pekerja jarak jauh bersedia memesan tempat jika kepastian meja dan akses listrik menghemat waktu mereka.
Budi tetap bisa salah. Pelanggan mungkin tidak menganggap masalah itu serius, pemilik kafe mungkin tidak mau mengubah operasional, atau solusi manualnya ternyata tidak menghasilkan nilai yang cukup. Namun setiap hasil memberi informasi yang dapat dipakai untuk memperbaiki arah, sementara tim Tono berisiko terus menambah fitur tanpa pernah mengetahui apakah kebutuhan dasarnya ada.
Ide besar tidak harus ditemukan oleh orang yang merasa paling jenius. Ide yang layak lebih sering muncul dari kebiasaan memperhatikan pekerjaan yang berulang, proses yang membuat frustrasi, dan kompromi yang terpaksa diterima orang setiap hari. Setelah itu, tugas founder adalah menguji apakah masalah tersebut nyata, spesifik, cukup penting, dan bisa dilayani dengan cara yang masuk akal.
Dalam tujuh hari ke depan, catat sepuluh masalah yang kamu lihat langsung dari pekerjaan atau kehidupan sehari-hari. Pilih satu, lalu wawancarai sedikitnya lima orang yang benar-benar mengalaminya tanpa menawarkan produk; tulis frekuensi masalah, dampaknya, solusi yang mereka gunakan sekarang, dan tindakan yang sudah mereka ambil. Akhiri dengan satu hipotesis yang bisa diuji melalui eksperimen manual kecil sebelum kamu membangun produk.
