Bab 2: Memahami Masalah yang Layak Dipecahkan

Startup yang kuat jarang dimulai dari pertanyaan, “Aplikasi apa yang bisa saya buat?” atau “Teknologi apa yang sedang ramai?” Pertanyaan yang lebih mendasar adalah:

“Masalah apa yang cukup nyata, cukup menyakitkan, dan cukup bernilai sehingga orang mau mengubah perilakunya untuk menyelesaikannya?”

Bab sebelumnya membahas cara berpikir founder: bergerak di tengah ketidakpastian, belajar cepat, dan tidak terlalu jatuh cinta pada ide sendiri. Di bab ini, kita mulai memakai cara berpikir itu untuk mencari fondasi pertama startup: masalah yang layak dipecahkan.

Sebuah ide bisa terdengar menarik, modern, bahkan indah secara teknis. Namun ide belum tentu berhubungan dengan masalah yang benar-benar dirasakan pasar. Banyak founder pemula terlalu cepat melompat dari “saya punya ide” ke “saya harus membuat produk”. Padahal, dalam pendekatan customer development, Steve Blank menekankan bahwa startup perlu keluar dari gedung—berbicara dengan calon pelanggan dan menguji asumsi—karena fakta tentang pasar biasanya tidak ditemukan hanya dari diskusi internal tim (Blank, 2013).

Bab ini akan membantu Anda membedakan antara ide menarik dan masalah penting. Kita akan membahas cara mengenali siapa yang benar-benar merasakan masalah, bagaimana menilai urgensi, frekuensi, nilai ekonomi, serta bagaimana membaca tanda bahwa suatu masalah mungkin cukup kuat untuk menjadi dasar startup.

Ide Bukan Masalah

Mari mulai dari perbedaan paling dasar.

Ide adalah bayangan tentang solusi, fitur, produk, atau bisnis yang mungkin dibuat.

Masalah adalah kesulitan, hambatan, risiko, biaya, rasa frustrasi, atau kebutuhan yang dialami seseorang dalam situasi nyata.

Contoh ide:

“Saya ingin membuat aplikasi manajemen tugas untuk mahasiswa.”

Contoh masalah:

“Mahasiswa tingkat akhir sering gagal mengatur jadwal skripsi, kerja paruh waktu, dan kegiatan kampus sehingga terlambat lulus atau stres karena pekerjaan menumpuk.”

Keduanya terdengar berhubungan, tetapi tidak sama. Ide langsung menunjuk pada solusi: aplikasi. Masalah menjelaskan situasi manusia: siapa yang kesulitan, dalam konteks apa, dan akibatnya apa.

Perbedaan ini penting karena founder sering terjebak membela solusi sebelum memahami masalah. Rob Fitzpatrick dalam The Mom Test menjelaskan bahwa percakapan pelanggan yang buruk sering membuat founder mendapatkan pujian palsu terhadap ide, bukan fakta tentang perilaku nyata pelanggan (Fitzpatrick, 2013). Misalnya, ketika Anda bertanya, “Apakah Anda akan memakai aplikasi pengatur skripsi saya?” banyak orang mungkin menjawab, “Wah, menarik!” Namun jawaban itu belum membuktikan mereka benar-benar membutuhkan, menggunakan, atau membayar produk tersebut.

Pertanyaan yang lebih baik adalah:

• “Bagaimana Anda mengatur jadwal skripsi sekarang?”
• “Kapan terakhir kali jadwal Anda berantakan?”
• “Apa akibatnya?”
• “Apa yang sudah Anda coba untuk mengatasinya?”
• “Apakah Anda pernah membayar alat, jasa, atau orang lain untuk membantu?”

Pertanyaan seperti ini memindahkan fokus dari opini tentang ide ke bukti tentang kehidupan nyata.

Masalah yang Layak Dipecahkan Selalu Punya Pemilik

Masalah tidak hidup di udara. Masalah selalu melekat pada seseorang atau sekelompok orang.

Kalimat “orang sulit mengatur keuangan” terlalu luas. Siapa orangnya? Mahasiswa? Karyawan baru? Pemilik warung? Freelancer? Keluarga muda? Masing-masing punya situasi, bahasa, sumber stres, dan kemampuan bayar yang berbeda.

Bandingkan dua pernyataan berikut:

1. “Banyak orang sulit mengatur keuangan.”
2. “Freelancer desain grafis berusia 22–35 tahun sering kesulitan memisahkan uang pribadi dan uang proyek karena penghasilan mereka tidak tetap, sehingga mereka bingung menentukan berapa uang yang boleh dipakai setiap bulan.”

Pernyataan kedua lebih berguna bagi founder karena lebih konkret. Kita bisa membayangkan siapa yang perlu diwawancarai, situasi apa yang harus diamati, dan solusi seperti apa yang mungkin relevan.

Dalam teori Jobs to Be Done, pelanggan tidak hanya “membeli produk”; mereka menggunakan produk untuk menyelesaikan suatu pekerjaan atau kemajuan tertentu dalam hidup mereka. Clayton Christensen dan rekan-rekannya menjelaskan bahwa memahami “pekerjaan” yang ingin diselesaikan pelanggan membantu perusahaan melihat kebutuhan dari sudut pandang pelanggan, bukan dari kategori produk yang sudah ada (Christensen et al., 2016).

Contoh sederhana:

• Orang tidak hanya membeli bor listrik; mereka ingin membuat lubang di dinding.
• Orang tidak hanya memakai aplikasi transportasi; mereka ingin sampai ke tempat tujuan dengan lebih mudah, cepat, atau dapat diprediksi.
• Pemilik toko tidak hanya memakai software kasir; mereka ingin tahu penjualan, stok, dan keuntungan tanpa menghitung manual setiap malam.

Jadi, ketika Anda menemukan masalah, tanyakan:

“Siapa yang sedang mencoba menyelesaikan pekerjaan apa, dalam situasi apa, dan mengapa cara yang ada belum memuaskan?”

Masalah Penting Biasanya Terlihat dari Perilaku, Bukan Sekadar Ucapan

Orang bisa berkata bahwa suatu masalah penting. Namun dalam startup, ucapan saja belum cukup. Kita perlu melihat perilaku.

Perilaku adalah tindakan nyata yang dilakukan orang: waktu yang mereka habiskan, uang yang mereka keluarkan, cara mereka mengakali keadaan, atau kebiasaan yang mereka ulangi. Perilaku lebih kuat daripada opini karena menunjukkan prioritas nyata.

Misalnya, Anda bertanya kepada pemilik usaha kecil:

“Apakah pencatatan keuangan penting?”

Kemungkinan besar mereka menjawab, “Penting.”

Namun jawaban itu belum cukup. Pertanyaan berikutnya adalah:

• “Bagaimana Anda mencatat keuangan sekarang?”
• “Kapan terakhir kali pencatatan itu membuat Anda bingung?”
• “Berapa lama waktu yang habis setiap minggu?”
• “Apakah Anda pernah memakai aplikasi akuntansi?”
• “Mengapa berhenti?”
• “Apakah Anda membayar admin atau konsultan pajak?”
• “Apa dampaknya kalau catatan keuangan salah?”

Jika pemilik usaha berkata “penting” tetapi tidak pernah mencatat, tidak pernah mencari solusi, dan tidak mengalami konsekuensi yang terasa, masalah itu mungkin belum cukup kuat. Sebaliknya, jika mereka memakai spreadsheet rumit, mengirim foto nota ke admin, membayar jasa pembukuan, dan tetap sering panik menjelang laporan pajak, Anda sedang melihat masalah yang lebih nyata.

Dalam The Lean Startup, Eric Ries menekankan pentingnya pembelajaran tervalidasi: startup perlu menguji apakah asumsi bisnisnya benar melalui eksperimen dan bukti, bukan hanya rencana atau keyakinan internal (Ries, 2011). Dalam konteks bab ini, bukti awal yang kita cari adalah tanda-tanda bahwa pelanggan sudah merasakan masalah dan sudah melakukan sesuatu untuk mengatasinya.

Empat Ukuran Awal: Urgensi, Frekuensi, Nilai Ekonomi, dan Kepemilikan Masalah

Untuk menilai apakah suatu masalah layak dipecahkan, gunakan empat pertanyaan awal:

1. Seberapa mendesak masalah ini?
2. Seberapa sering masalah ini terjadi?
3. Seberapa besar nilai ekonomi dari penyelesaiannya?
4. Siapa yang benar-benar merasakan dan memiliki masalah ini?

Keempat pertanyaan ini tidak memberi jawaban sempurna. Namun ia membantu Anda berpikir lebih tajam sebelum membuat produk.

Urgensi: Apakah Masalah Ini Perlu Diselesaikan Sekarang?

Urgensi berarti tingkat kebutuhan untuk menyelesaikan masalah dalam waktu dekat. Masalah yang mendesak biasanya membuat orang aktif mencari solusi, bukan sekadar menganggapnya menarik.

Contoh masalah dengan urgensi tinggi:

Sebuah restoran sering kehabisan bahan baku utama saat jam ramai karena pencatatan stok buruk. Akibatnya, menu populer tidak bisa dijual dan pendapatan hari itu turun.

Masalah ini mendesak karena berdampak langsung pada penjualan. Pemilik restoran tidak bisa menunggu enam bulan untuk solusi sempurna. Ia perlu cara yang lebih baik segera.

Contoh masalah dengan urgensi rendah:

Banyak orang merasa “ingin lebih produktif” tetapi belum punya situasi spesifik yang membuat mereka harus berubah.

Keinginan produktif bisa nyata, tetapi terlalu umum. Jika tidak ada konsekuensi yang jelas, orang mungkin mengunduh aplikasi produktivitas, mencobanya dua hari, lalu melupakannya.

Cara menguji urgensi adalah dengan menanyakan kejadian terakhir, bukan opini umum.

Daripada bertanya:

“Apakah masalah ini mendesak?”

Tanyakan:

“Kapan terakhir kali masalah ini terjadi?”
“Apa yang terjadi setelah itu?”
“Siapa yang terkena dampaknya?”
“Apa yang Anda lakukan saat itu?”
“Kalau masalah ini tidak selesai, apa kerugiannya?”

Jika calon pelanggan bisa menceritakan kejadian konkret, nama orang yang terlibat, biaya, waktu, atau stres yang muncul, urgensinya lebih mungkin nyata.

Frekuensi: Apakah Masalah Ini Terjadi Cukup Sering?

Frekuensi berarti seberapa sering masalah terjadi. Masalah yang sering terjadi biasanya lebih mudah diingat, lebih mudah diamati, dan lebih mungkin menjadi bagian dari kebiasaan pelanggan.

Contoh:

• Masalah parkir di kantor terjadi hampir setiap hari.
• Masalah memilih vendor acara mungkin terjadi setahun sekali.
• Masalah mencari dokter anak bisa terjadi beberapa kali dalam setahun, tetapi dalam situasi emosional yang penting.
• Masalah memperpanjang dokumen legal perusahaan mungkin jarang, tetapi bisa bernilai tinggi dan berisiko jika salah.

Frekuensi tinggi tidak selalu berarti peluang bisnis lebih baik, dan frekuensi rendah tidak selalu berarti buruk. Yang penting adalah hubungan antara frekuensi, urgensi, dan nilai ekonomi.

Mari bandingkan:

Jika masalah sering terjadi tetapi tidak terlalu penting, pelanggan mungkin enggan membayar. Jika masalah jarang terjadi tetapi kerugiannya besar, pelanggan mungkin tetap bersedia membayar mahal.

Nilai Ekonomi: Apakah Penyelesaian Masalah Ini Bernilai?

Nilai ekonomi adalah manfaat yang dapat diterjemahkan ke dalam uang, penghematan, peningkatan pendapatan, pengurangan risiko, atau efisiensi waktu. Nilai ekonomi tidak selalu sama dengan harga produk, tetapi membantu memperkirakan apakah pelanggan punya alasan rasional untuk membayar.

Ada beberapa bentuk nilai ekonomi:

1. Menghemat biaya
   Contoh: software yang mengurangi kebutuhan lembur admin.

2. Meningkatkan pendapatan
   Contoh: alat yang membantu toko online menaikkan konversi pembelian.

3. Menghemat waktu
   Contoh: sistem reservasi yang mengurangi waktu staf menjawab pesan manual.

4. Mengurangi risiko
   Contoh: layanan keamanan data yang menurunkan risiko kebocoran informasi pelanggan.

5. Mengurangi kesalahan
   Contoh: sistem stok yang mencegah salah kirim barang.

6. Meningkatkan kepastian
   Contoh: dashboard keuangan yang membantu founder melihat runway dan burn rate dengan jelas.

Contoh perhitungan sederhana:

Sebuah klinik kecil memiliki dua staf administrasi. Setiap staf menghabiskan 10 jam per minggu untuk mengatur jadwal pasien secara manual. Total waktu yang digunakan:

2 staf × 10 jam = 20 jam per minggu

Jika biaya tenaga kerja efektif per jam adalah Rp35.000, maka biaya waktu per minggu:

20 × Rp35.000 = Rp700.000

Dalam satu bulan kira-kira:

Rp700.000 × 4 = Rp2.800.000

Jika sebuah sistem penjadwalan dapat mengurangi separuh waktu tersebut, nilai penghematan kasar per bulan sekitar:

50% × Rp2.800.000 = Rp1.400.000

Artinya, jika solusi Anda dijual Rp300.000–Rp700.000 per bulan dan benar-benar menghemat waktu tersebut, pelanggan punya alasan ekonomi untuk mempertimbangkannya. Perhitungan ini belum sempurna karena masih perlu memperhitungkan biaya pelatihan, perubahan proses, risiko kesalahan, dan kenyamanan pengguna. Namun ini lebih baik daripada hanya berkata, “Produk saya akan membantu klinik.”

Nilai ekonomi memaksa founder menjawab pertanyaan penting:

“Jika masalah ini selesai, manfaat nyatanya apa?”

Kepemilikan Masalah: Siapa yang Sakit, Siapa yang Membayar, Siapa yang Memutuskan?

Dalam banyak bisnis, terutama B2B, orang yang merasakan masalah belum tentu orang yang membayar. Karena itu, founder perlu memahami tiga peran:

1. Pengguna: orang yang memakai solusi.
2. Pembeli: orang atau pihak yang membayar.
3. Pengambil keputusan: orang yang menyetujui pembelian.

Kadang ketiganya orang yang sama. Misalnya, seorang freelancer membeli aplikasi invoice untuk dirinya sendiri. Ia pengguna, pembeli, sekaligus pengambil keputusan.

Namun dalam perusahaan, ketiganya bisa berbeda.

Contoh:

Anda membuat software untuk membantu staf gudang menghitung stok.

• Pengguna: staf gudang.
• Pembeli: perusahaan.
• Pengambil keputusan: manajer operasional atau direktur keuangan.
• Pihak yang terdampak: tim penjualan, tim pembelian, pelanggan akhir.

Jika staf gudang suka produk Anda tetapi manajer tidak melihat manfaat ekonomi, penjualan bisa gagal. Sebaliknya, jika direktur membeli software yang sulit dipakai staf, implementasi bisa gagal.

Karena itu, masalah yang layak dipecahkan tidak cukup hanya “dirasakan seseorang”. Anda perlu tahu apakah masalah itu juga diakui oleh pihak yang punya anggaran dan wewenang.

Pertanyaan praktis:

• Siapa yang paling sering merasakan sakitnya?
• Siapa yang paling rugi jika masalah tidak selesai?
• Siapa yang punya anggaran?
• Siapa yang bisa mengatakan “ya”?
• Siapa yang bisa menghalangi keputusan?
• Apakah pengguna dan pembeli punya prioritas yang sama?

Pertanyaan ini akan menjadi sangat penting saat kita membahas penjualan B2B di bab berikutnya tentang sales. Namun sejak awal, founder perlu belajar melihat peta manusia di balik masalah.

Alternatif yang Ada: Pelanggan Tidak Pernah Hidup Tanpa Solusi

Founder sering berkata, “Belum ada solusi untuk masalah ini.” Pernyataan itu hampir selalu perlu diperiksa.

Mungkin belum ada aplikasi khusus. Mungkin belum ada produk modern. Namun pelanggan biasanya sudah memakai alternatif.

Alternatif adalah cara apa pun yang dipakai pelanggan saat ini untuk menghadapi masalah. Alternatif bisa berupa produk pesaing, spreadsheet, grup WhatsApp, catatan kertas, asisten pribadi, proses manual, atau bahkan keputusan untuk mengabaikan masalah.

Contoh:

Masalah: pemilik kos ingin mencatat pembayaran penghuni.

Alternatif yang mungkin:

• Buku tulis.
• Spreadsheet.
• Transfer bank dan cek mutasi manual.
• Grup WhatsApp penghuni.
• Mengingat sendiri.
• Meminta penjaga kos mencatat.
• Aplikasi keuangan umum.

Jika Anda tidak memahami alternatif, Anda tidak tahu standar pembanding produk Anda. Pelanggan tidak membandingkan produk baru dengan “tidak ada apa-apa”. Mereka membandingkannya dengan cara lama yang sudah mereka pahami.

Inilah mengapa pertanyaan “Apa kompetitor saya?” perlu diperluas. Kompetitor bukan hanya perusahaan lain dengan fitur serupa. Kompetitor juga kebiasaan lama pelanggan.

Dalam difusi inovasi, Everett Rogers menjelaskan bahwa adopsi inovasi dipengaruhi oleh beberapa karakteristik, termasuk keunggulan relatif, kesesuaian dengan kebutuhan atau nilai pengguna, kompleksitas, kemampuan dicoba, dan kemudahan diamati hasilnya (Rogers, 2003). Bagi founder, ini berarti solusi baru tidak cukup “lebih canggih”. Solusi baru harus terasa cukup lebih baik dibanding alternatif sehingga pelanggan mau belajar, mencoba, dan berpindah.

Masalah “Painkiller” dan Masalah “Vitamin”

Dalam dunia startup, ada istilah populer: painkiller dan vitamin.

• Painkiller adalah solusi untuk rasa sakit yang jelas dan mendesak.
• Vitamin adalah solusi yang terasa baik, tetapi tidak selalu mendesak.

Analogi ini tidak sempurna, tetapi berguna sebagai alat berpikir.

Contoh painkiller:

Sistem pembayaran online toko sering gagal sehingga pelanggan batal membeli. Solusi yang meningkatkan keberhasilan pembayaran bisa langsung berdampak pada pendapatan.

Contoh vitamin:

Aplikasi yang memberi kutipan motivasi harian untuk founder.

Aplikasi motivasi bisa bermanfaat bagi sebagian orang, tetapi banyak pengguna mungkin tidak merasa harus membayar atau memakainya setiap hari. Masalahnya lebih lemah kecuali ada konteks yang membuatnya sangat bernilai, misalnya program coaching berbayar dengan komunitas dan akuntabilitas.

Namun jangan menyimpulkan bahwa semua produk “vitamin” buruk. Banyak produk besar dimulai dari kebutuhan yang tidak tampak mendesak secara tradisional, seperti hiburan, komunitas, atau ekspresi diri. Yang perlu diperiksa adalah apakah pelanggan menunjukkan perilaku kuat: sering menggunakan, mengajak orang lain, membayar, atau merasa kehilangan jika produk hilang.

Jadi, pertanyaan yang lebih tepat bukan “ini painkiller atau vitamin?” melainkan:

“Apakah pelanggan menunjukkan bahwa masalah ini cukup penting dalam perilaku nyata mereka?”

Sinyal Masalah yang Kuat

Masalah yang layak dipecahkan biasanya meninggalkan jejak. Jejak ini bisa terlihat dari perilaku pelanggan, biaya yang sudah dikeluarkan, atau proses manual yang menyakitkan.

Beberapa sinyal kuat:

1. Pelanggan Sudah Membayar Solusi Lain

Jika pelanggan sudah membayar konsultan, software, alat manual, atau tenaga kerja tambahan untuk mengatasi masalah, berarti masalah tersebut punya nilai ekonomi.

Contoh:

Sebuah sekolah membayar staf khusus untuk mengelola administrasi pendaftaran siswa baru secara manual. Jika Anda membuat sistem yang mengurangi kekacauan pendaftaran, sekolah mungkin punya alasan anggaran yang jelas.

2. Pelanggan Membuat Solusi Sendiri

Jika pelanggan membuat spreadsheet rumit, formulir manual, template, atau proses darurat, itu tanda bahwa masalah cukup mengganggu.

Contoh:

Tim HR membuat 12 tab spreadsheet untuk melacak cuti, kontrak, absensi, dan reimbursement. Mereka mungkin belum memakai software HR bukan karena tidak butuh, tetapi karena software yang ada terlalu mahal, terlalu rumit, atau tidak cocok dengan proses mereka.

3. Masalah Menimbulkan Konsekuensi Nyata

Konsekuensi bisa berupa kehilangan uang, kehilangan waktu, risiko hukum, reputasi buruk, stres berat, atau pelanggan pergi.

Contoh:

Toko online yang lambat membalas chat kehilangan calon pembeli. Jika ada bukti bahwa keterlambatan respons menurunkan penjualan, masalah ini lebih kuat daripada sekadar “ingin customer service lebih rapi”.

4. Pelanggan Aktif Mencari Solusi

Pelanggan yang mencari di Google, bertanya di komunitas, mengikuti webinar, atau mencoba banyak alat menunjukkan adanya kebutuhan aktif.

Contoh:

Pemilik bisnis kecil yang bergabung di grup pajak dan sering bertanya tentang pembukuan mungkin sedang mengalami masalah yang jelas.

5. Masalah Memburuk Seiring Pertumbuhan

Beberapa masalah kecil pada awalnya, tetapi menjadi besar ketika volume naik.

Contoh:

Saat toko hanya menerima 10 pesanan per hari, pencatatan manual masih bisa dilakukan. Saat pesanan menjadi 300 per hari, proses lama mulai pecah. Ini peluang karena pertumbuhan pelanggan menciptakan kebutuhan baru.

Sinyal Masalah yang Lemah

Sebaliknya, ada juga tanda bahwa masalah belum cukup kuat.

1. Orang Hanya Berkata “Menarik”

Kata “menarik” sering berbahaya. Ia terdengar positif, tetapi tidak menunjukkan komitmen.

Jika calon pelanggan berkata, “Menarik, kabari saya kalau sudah jadi,” tanyakan:

“Kalau kami buka akses uji coba minggu depan, apakah Anda bersedia memakai data nyata?”
“Apakah Anda bersedia menjadwalkan sesi implementasi?”
“Apakah Anda bersedia membayar harga awal?”

Bukan untuk memaksa, tetapi untuk menguji apakah minat itu nyata.

2. Tidak Ada Kejadian Terakhir

Jika calon pelanggan tidak bisa mengingat kapan terakhir kali masalah terjadi, mungkin masalah itu jarang, tidak penting, atau terlalu abstrak.

Contoh:

Founder: “Kapan terakhir kali Anda kesulitan mengatur dokumen kerja?”
Calon pelanggan: “Hmm, saya tidak ingat. Tapi sepertinya itu masalah umum.”

Jawaban seperti ini belum cukup kuat.

3. Tidak Ada Alternatif yang Dicoba

Jika masalah sangat penting, biasanya orang sudah mencoba sesuatu. Jika mereka tidak pernah mencoba apa pun, cari tahu mengapa. Bisa jadi karena masalah tidak penting, solusinya terlalu sulit ditemukan, atau mereka tidak punya anggaran.

4. Pengguna Tidak Punya Wewenang atau Anggaran

Seorang karyawan bisa sangat menyukai ide Anda, tetapi jika ia tidak punya pengaruh pada pembelian, Anda belum menemukan jalur bisnis yang jelas.

5. Masalah Terlalu Umum

“UMKM butuh digitalisasi” adalah pernyataan terlalu luas. UMKM jenis apa? Warung makan? Distributor bahan bangunan? Klinik kecantikan? Penjual frozen food? Masalah digitalisasi mereka berbeda.

Pernyataan yang terlalu umum membuat riset kabur dan produk menjadi terlalu lebar sejak awal.

Menghindari Bias Konfirmasi

Ketika kita menyukai sebuah ide, otak kita cenderung mencari bukti yang mendukung ide tersebut dan mengabaikan bukti yang bertentangan. Kecenderungan ini disebut bias konfirmasi. Raymond Nickerson mendeskripsikan bias konfirmasi sebagai kecenderungan untuk mencari, menafsirkan, atau mengingat informasi dengan cara yang mendukung keyakinan yang sudah ada (Nickerson, 1998).

Dalam startup, bias konfirmasi sangat berbahaya karena founder bisa merasa sudah melakukan riset padahal hanya mengumpulkan pujian.

Contoh:

Anda ingin membuat aplikasi belajar bahasa untuk pekerja kantoran. Anda bertanya kepada 20 teman:

“Kalau ada aplikasi belajar bahasa Inggris yang fleksibel untuk pekerja, kamu tertarik?”

Banyak yang menjawab:

“Iya, menarik.”

Lalu Anda menyimpulkan pasar siap. Padahal mungkin mereka hanya sopan. Mereka belum tentu pernah belajar konsisten, belum tentu mau membayar, dan belum tentu menjadikan bahasa Inggris sebagai prioritas.

Untuk mengurangi bias konfirmasi, ubah cara bertanya.

Jangan bertanya:

“Apakah Anda suka ide ini?”

Tanyakan:

“Kapan terakhir kali Anda mencoba belajar bahasa Inggris?”
“Berapa lama bertahan?”
“Apa yang membuat berhenti?”
“Apakah pernah membayar kursus atau aplikasi?”
“Apa yang terjadi jika kemampuan bahasa Inggris Anda tidak meningkat?”
“Apakah ada target kerja yang bergantung pada kemampuan ini?”

Pertanyaan ini mungkin menghasilkan jawaban yang tidak nyaman. Tetapi jawaban tidak nyaman sering lebih berguna daripada pujian kosong.

Cara Menulis Pernyataan Masalah

Setelah melakukan pengamatan awal, tulis masalah dalam bentuk yang jelas. Gunakan struktur sederhana:

[Kelompok pelanggan] mengalami [masalah spesifik] ketika [situasi/konteks], sehingga [konsekuensi nyata]. Saat ini mereka mengatasinya dengan [alternatif], tetapi alternatif itu kurang memuaskan karena [kekurangan].

Contoh buruk:

“Orang butuh aplikasi keuangan yang mudah.”

Masalahnya terlalu luas. “Orang” siapa? Keuangan bagian apa? Mudah dibanding apa?

Contoh lebih baik:

“Freelancer kreatif yang menerima proyek tidak tetap mengalami kesulitan memisahkan uang pribadi, uang pajak, dan uang operasional ketika pembayaran klien datang tidak teratur, sehingga mereka sering merasa punya uang lebih banyak daripada kenyataannya. Saat ini mereka memakai rekening pribadi dan spreadsheet sederhana, tetapi cara itu mudah lupa diperbarui dan tidak memberi peringatan saat uang pajak terpakai.”

Pernyataan ini belum membuktikan bisnis pasti berhasil. Namun ia cukup jelas untuk diuji.

Contoh lain:

“Pemilik klinik kecil mengalami kesulitan mengatur jadwal pasien ketika pasien sering membatalkan atau mengubah janji lewat WhatsApp, sehingga staf administrasi menghabiskan banyak waktu membalas pesan dan risiko jadwal bentrok meningkat. Saat ini mereka memakai buku jadwal dan chat manual, tetapi cara itu sulit dilacak saat jumlah pasien bertambah.”

Pernyataan masalah yang baik membantu Anda menentukan siapa yang harus diwawancarai, data apa yang dicari, dan solusi minimum apa yang bisa diuji.

Menilai Masalah dengan Skor Sederhana

Untuk membantu berpikir, Anda dapat memberi skor awal pada masalah. Skor ini bukan kebenaran mutlak. Ia hanya alat diskusi agar founder tidak menilai masalah berdasarkan perasaan saja.

Gunakan skala 1 sampai 5:

• 1 = sangat lemah
• 2 = lemah
• 3 = sedang
• 4 = kuat
• 5 = sangat kuat

Nilai lima aspek:

Contoh penilaian:

Masalah: pemilik restoran kecil sering kehabisan stok bahan utama saat jam ramai.

Total: 20 dari 25.

Masalah ini terlihat cukup kuat untuk diteliti lebih lanjut.

Bandingkan dengan:

Masalah: mahasiswa ingin kutipan motivasi otomatis setiap pagi.

Total: 12 dari 25.

Bukan berarti ide ini pasti buruk, tetapi fondasi masalahnya lebih lemah. Jika tetap ingin dikejar, founder perlu menemukan konteks yang lebih kuat, misalnya mahasiswa yang sedang persiapan ujian penting dan membutuhkan sistem akuntabilitas, bukan sekadar kutipan.

Jangan Terlalu Cepat Memilih Pasar yang Terlalu Luas

Pasar yang luas terdengar menggoda. Founder sering berkata:

“Target kami semua UMKM.”

Atau:

“Produk ini bisa dipakai semua orang.”

Masalahnya, “semua orang” sulit dijangkau, sulit diajak bicara, dan sulit dibuatkan produk yang benar-benar tajam. Startup awal biasanya lebih efektif jika mulai dari segmen sempit yang punya masalah jelas. Geoffrey Moore dalam Crossing the Chasm menekankan pentingnya fokus pada pasar awal yang spesifik ketika membawa produk teknologi ke pelanggan utama, terutama karena kelompok pelanggan berbeda memiliki tingkat kesiapan dan kebutuhan yang berbeda (Moore, 2014).

Contoh:

Daripada:

“Software kasir untuk semua UMKM.”

Lebih tajam:

“Software kasir sederhana untuk kedai kopi kecil dengan 1–3 cabang yang masih mencatat stok bahan secara manual.”

Daripada:

“Aplikasi kesehatan mental untuk semua orang.”

Lebih tajam:

“Program dukungan stres untuk karyawan remote usia 25–35 tahun yang mengalami burnout ringan dan sulit memisahkan jam kerja dari waktu pribadi.”

Segmen sempit bukan berarti mimpi kecil. Segmen sempit adalah tempat belajar awal. Jika Anda tidak bisa memahami satu kelompok kecil dengan baik, biasanya Anda akan lebih sulit memahami pasar luas.

Masalah Layak Dipecahkan Tidak Selalu Masalah yang Anda Alami Sendiri

Banyak startup dimulai dari masalah pribadi founder. Ini bisa menjadi kekuatan karena founder punya empati awal dan pengalaman langsung. Namun pengalaman pribadi juga bisa menipu jika founder menganggap semua orang mengalami masalah yang sama dengan cara yang sama.

Contoh:

Seorang founder pernah kesulitan mencari mentor karier. Ia lalu ingin membuat platform mentor untuk semua fresh graduate. Pengalaman pribadinya nyata, tetapi ia tetap harus memeriksa:

• Apakah fresh graduate lain punya masalah yang sama?
• Apakah mereka cukup peduli untuk membayar?
• Apakah mentor berkualitas mau bergabung?
• Apakah masalahnya kurang akses mentor, kurang motivasi, kurang informasi, atau kurang jaringan?
• Apakah solusi platform benar-benar lebih baik daripada komunitas, LinkedIn, alumni kampus, atau program perusahaan?

Masalah pribadi adalah titik awal yang baik, bukan bukti pasar.

Sebaliknya, Anda juga bisa membangun startup dari masalah yang tidak Anda alami sendiri, asalkan Anda mau belajar langsung dari pelanggan. Di sinilah empati, observasi, dan wawancara menjadi penting.

Dari Masalah ke Hipotesis

Pada tahap awal, hampir semua yang Anda yakini adalah hipotesis.

Hipotesis adalah dugaan sementara yang bisa diuji. Dalam startup, hipotesis bukan sekadar pendapat; ia harus cukup jelas sehingga bisa dibuktikan lebih benar atau lebih salah melalui data atau perilaku pelanggan.

Contoh hipotesis buruk:

“Orang akan suka aplikasi kami.”

Terlalu kabur. Orang siapa? Suka berarti apa?

Contoh hipotesis lebih baik:

“Pemilik klinik kecil dengan 2–5 dokter bersedia membayar minimal Rp500.000 per bulan untuk sistem penjadwalan yang mengurangi waktu admin membalas WhatsApp setidaknya 30%.”

Hipotesis ini lebih baik karena menyebut:

• segmen pelanggan,
• masalah,
• hasil yang diharapkan,
• nilai ekonomi,
• indikasi kemauan membayar.

Bab 5 akan membahas validasi hipotesis bisnis lebih dalam. Untuk sekarang, cukup pahami bahwa masalah yang layak dipecahkan perlu diubah menjadi dugaan yang bisa diuji, bukan dibiarkan sebagai inspirasi umum.

Contoh Lengkap: Dari Ide Mentah ke Masalah yang Lebih Tajam

Bayangkan Anda punya ide:

“Saya ingin membuat aplikasi untuk membantu restoran kecil.”

Ini terlalu luas. Kita perlu menggali.

Langkah 1: Cari Situasi Nyata

Anda berbicara dengan 10 pemilik restoran kecil. Anda tidak mempresentasikan aplikasi. Anda bertanya tentang kegiatan harian mereka.

Beberapa cerita muncul:

• Mereka sering tidak tahu stok bahan secara akurat.
• Kasir dan dapur kadang salah komunikasi.
• Pemilik tidak selalu berada di lokasi.
• Laporan penjualan dari staf sering terlambat.
• Banyak pesanan masuk dari aplikasi delivery, WhatsApp, dan pelanggan langsung.

Langkah 2: Temukan Pola Masalah

Dari 10 wawancara, 6 pemilik menyebut stok sebagai sumber stres. Mereka tidak hanya berkata “stok penting”; mereka bercerita tentang kejadian nyata: menu habis, bahan busuk, pembelian mendadak, dan staf saling menyalahkan.

Langkah 3: Periksa Alternatif

Saat ini mereka memakai:

• buku catatan,
• grup WhatsApp,
• ingatan kepala dapur,
• spreadsheet sederhana,
• pengecekan manual setiap malam.

Alternatif ini murah, tetapi mudah salah saat restoran ramai.

Langkah 4: Ukur Dampak

Anda bertanya:

• “Berapa kali menu habis minggu lalu?”
• “Menu apa yang paling sering habis?”
• “Kalau menu itu habis, kira-kira berapa penjualan hilang?”
• “Berapa jam staf menghitung stok?”
• “Apa yang terjadi kalau bahan terlalu banyak dibeli?”

Dari sini Anda mulai melihat nilai ekonomi.

Langkah 5: Rumuskan Pernyataan Masalah

“Pemilik restoran kecil dengan 1–3 cabang mengalami kesulitan memantau stok bahan utama secara akurat ketika pesanan datang dari banyak channel dan pemilik tidak selalu berada di lokasi, sehingga menu populer bisa habis saat jam ramai atau bahan terbuang karena pembelian berlebih. Saat ini mereka memakai catatan manual, WhatsApp, dan ingatan staf, tetapi cara itu sering terlambat dan mudah salah.”

Pernyataan ini jauh lebih kuat daripada “aplikasi untuk restoran”. Sekarang Anda punya masalah yang bisa diuji.

Latihan: Peta Masalah Startup Anda

Gunakan latihan ini sebelum membuat produk.

Tulis satu ide yang Anda punya:

Ide saya: …

Lalu jawab pertanyaan berikut dengan jujur.

1. Siapa pelanggan yang mengalami masalah?

Jangan tulis “semua orang”. Buat lebih spesifik.

Kelompok pelanggan: …

Contoh:

Pemilik laundry kiloan dengan 1–2 cabang di kota besar.

2. Apa masalah spesifiknya?

Masalah spesifik: …

Contoh:

Mereka sering salah melacak status cucian pelanggan saat pesanan meningkat.

3. Kapan masalah terjadi?

Situasi: …

Contoh:

Saat akhir pekan atau musim hujan ketika volume cucian naik.

4. Apa konsekuensinya?

Konsekuensi: …

Contoh:

Pelanggan marah karena cucian tertukar atau terlambat, staf harus mencari manual, dan reputasi laundry turun.

5. Bagaimana mereka mengatasinya sekarang?

Alternatif saat ini: …

Contoh:

Nota kertas, catatan WhatsApp, dan ingatan staf.

6. Mengapa alternatif itu belum cukup?

Kekurangan alternatif: …

Contoh:

Nota mudah hilang, status cucian tidak real-time, dan pemilik sulit memantau dari jauh.

7. Apa bukti bahwa masalah ini nyata?

Bukti awal: …

Contoh:

Tiga pemilik laundry menceritakan kejadian cucian tertukar dalam satu bulan terakhir dan dua di antaranya memberi kompensasi kepada pelanggan.

Jika Anda belum punya bukti, tulis:

“Belum ada bukti. Perlu wawancara dan observasi.”

Jawaban seperti itu bukan kegagalan. Itu kejujuran yang baik. Founder yang baik tahu perbedaan antara yang sudah diketahui dan yang masih dugaan.

Kesalahan Umum Saat Mencari Masalah

Ada beberapa kesalahan yang sering terjadi pada tahap ini.

Kesalahan 1: Memulai dari Teknologi

Misalnya:

“Kami ingin memakai AI untuk pendidikan.”

Teknologi bisa menjadi alat yang kuat, tetapi pelanggan biasanya tidak membeli teknologi karena teknologinya. Mereka membeli hasil: lebih cepat belajar, lebih mudah mengajar, lebih hemat biaya, lebih akurat menilai, atau lebih nyaman menjalankan tugas.

Pertanyaan yang lebih baik:

“Masalah pendidikan apa yang cukup menyakitkan, dan apakah AI benar-benar cara terbaik untuk menyelesaikannya?”

Kesalahan 2: Menganggap Keluhan Sama dengan Kemauan Membayar

Orang sering mengeluh tentang sesuatu, tetapi tidak semua keluhan menjadi peluang bisnis.

Contoh:

Banyak orang mengeluh macet. Namun tidak semua orang bersedia membayar layanan premium untuk menghindari macet. Sebagian memilih berangkat lebih pagi, naik motor, mendengarkan podcast, atau menerima macet sebagai bagian hidup.

Keluhan perlu diuji dengan perilaku dan komitmen.

Kesalahan 3: Mengabaikan Biaya Berpindah

Biaya berpindah adalah semua usaha, waktu, uang, risiko, dan ketidaknyamanan yang harus ditanggung pelanggan untuk pindah dari cara lama ke solusi baru.

Contoh:

Sebuah perusahaan sudah memakai spreadsheet untuk operasional. Produk Anda lebih rapi. Namun untuk pindah, mereka harus memindahkan data, melatih staf, mengubah SOP, dan mengambil risiko gangguan kerja. Jika manfaat produk tidak jauh lebih besar daripada biaya berpindah, mereka mungkin tetap memakai cara lama.

Kesalahan 4: Terlalu Cepat Percaya pada Survei

Survei berguna, tetapi pada tahap awal sering kurang dalam. Jika Anda belum memahami bahasa pelanggan dan konteks masalah, survei mudah menghasilkan jawaban dangkal.

Wawancara dan observasi biasanya lebih baik untuk eksplorasi awal. Survei lebih berguna setelah Anda punya dugaan yang lebih jelas dan ingin melihat pola pada jumlah responden lebih besar.

Kesalahan 5: Mencari Masalah yang “Keren”, Bukan yang Penting

Masalah yang terlihat keren di pitch deck belum tentu penting bagi pelanggan. Sebaliknya, masalah yang tampak membosankan—stok gudang, invoice, pajak, jadwal, kepatuhan, administrasi—bisa sangat bernilai jika menyakitkan dan sering terjadi.

Startup tidak dibayar karena idenya keren. Startup dibayar karena membantu pelanggan membuat kemajuan yang mereka anggap penting.

Ringkasan Bab

Masalah yang layak dipecahkan adalah masalah yang nyata, dialami oleh kelompok pelanggan tertentu, memiliki konsekuensi, dan cukup penting sehingga pelanggan mau mencari solusi, mengubah perilaku, atau membayar.

Untuk menilai masalah, periksa empat hal utama:

• Urgensi: apakah perlu diselesaikan segera?
• Frekuensi: apakah terjadi cukup sering atau pada momen yang penting?
• Nilai ekonomi: apakah penyelesaiannya menghemat uang, waktu, risiko, atau meningkatkan pendapatan?
• Kepemilikan masalah: siapa yang merasakan, siapa yang membayar, dan siapa yang memutuskan?

Jangan berhenti pada ide. Turunlah ke situasi nyata. Dengarkan cerita kejadian terakhir. Cari alternatif yang sudah digunakan pelanggan. Waspadai pujian kosong. Hindari bias konfirmasi. Tulis pernyataan masalah dengan jelas sebelum membangun produk.

Bab berikutnya akan melanjutkan dari sini: setelah memahami masalah, kita perlu menentukan pelanggan pertama. Sebab startup awal tidak membutuhkan semua orang. Startup awal membutuhkan kelompok kecil yang masalahnya cukup kuat, cukup jelas, dan cukup siap untuk mencoba solusi baru.

References

Blank, S. (2013