Pengantar Validasi Problem

Pra-syarat sebelum mulai

Sebelum buka modul ini, siapkan:

• Ide bisnis kasar yang ingin Anda kerjakan selama program. Tidak perlu sempurna. Cukup 1 sampai 2 paragraf tentang siapa pengguna dan masalah apa yang ingin Anda selesaikan.
• Akses ke folder Drive kohort untuk submit worksheet.
• Microsoft Excel atau Google Sheets untuk membuka file .xlsx.
• Waktu fokus 90 sampai 120 menit tanpa gangguan.

Topik

Banyak founder muda mulai dengan ide solusi. Mereka langsung membayangkan aplikasi, fitur, dan logo. Padahal urutan yang benar dimulai dari masalah, bukan dari solusi. Pekan ini kita meletakkan dasar pola pikir yang akan dipakai selama 4 bulan ke depan: kemampuan melihat masalah dengan jujur sebelum jatuh cinta dengan solusi sendiri.

Apa yang Akan Dipelajari

• Definisi problem, pain, dan jobs to be done dalam konteks bisnis
• Skala intensitas pain yang menentukan kapan masalah layak jadi bisnis
• Cara menulis problem statement yang spesifik dan bisa diuji
• Pemetaan asumsi dengan teknik risk-based prioritization
• Cara skoring risiko 1 sampai 5 yang konsisten antar peserta
• Simulasi lengkap dari ide kasar sampai peta hipotesis siap uji

Glossary singkat

• Problem: gangguan yang dialami pengguna saat menyelesaikan sesuatu
• Pain: seberapa parah problem itu dirasakan secara emosional dan finansial
• Jobs to be done (JTBD): pekerjaan atau tujuan yang ingin diselesaikan pengguna ketika memakai sebuah produk
• Asumsi: keyakinan yang belum diuji dengan data
• Hipotesis: asumsi yang sudah diformulasikan jadi pernyataan yang bisa terbukti benar atau salah dengan bukti
• Indikator valid: ambang angka yang membuat Anda yakin hipotesis benar
• Indikator gugur: ambang angka yang membuat Anda berani mencoret hipotesis
• Riskiest Assumption Testing (RAT): prinsip untuk menguji asumsi paling berisiko duluan
• Segmen: kelompok pengguna spesifik dengan karakteristik yang serupa

Estimasi waktu pengerjaan modul

Uraian Pembelajaran

Mulai dari masalah, bukan solusi

Riset Tom Eisenmann dari Harvard Business School yang dipublikasikan di HBR (“Why Start-ups Fail”, 2021) menunjukkan, alasan paling umum kegagalan startup bukan kurangnya skill teknis. Penyebab utamanya adalah membangun produk yang tidak benar-benar dibutuhkan pasar. CB Insights dalam laporan “Top Reasons Startups Fail” mencatat bahwa “no market need” konsisten jadi penyebab nomor 1 selama bertahun-tahun, dengan persentase di kisaran 35 sampai 42 persen.

Sebelum bicara tentang aplikasi, fitur, atau model bisnis, kita harus pegang dulu satu hal: pemahaman jujur tentang masalah yang dihadapi orang lain.

Masalah yang layak dikejar punya tiga ciri. Pertama, terasa menyakitkan oleh sekelompok orang spesifik. Kedua, sering muncul, bukan hanya sesekali. Ketiga, orang sudah berusaha mengatasinya dengan cara yang kurang ideal. Bila satu dari tiga ciri ini hilang, kemungkinan besar Anda sedang mengejar masalah yang lemah.

Bedakan problem, pain, dan jobs to be done

Problem adalah gangguan yang dialami pengguna. Pain adalah seberapa parah gangguan itu dirasakan. Jobs to be done adalah pekerjaan yang ingin diselesaikan pengguna ketika mereka memakai sebuah produk. Pendekatan jobs to be done dari Clayton Christensen membantu kita melihat motif sebenarnya, bukan permukaan keluhan.

Contoh: orang membeli bor bukan karena ingin bor, tapi karena ingin membuat lubang. Lebih dalam lagi, mereka ingin memasang lukisan. Lebih dalam lagi, ingin rumah terasa hangat. Lapisan motivasi ini yang akan kita gali di pekan 2 lewat customer interview.

Cara cepat menggali sampai motivasi paling dalam: tanya “kenapa” sampai 5 kali. Teknik 5 Whys dari Toyota. Setiap kali pengguna menyebut keluhan, tanya kenapa itu masalah. Lakukan 5 lapis. Lapisan ke-5 biasanya jadi job yang sebenarnya.

Beda jobs to be done dengan feature request: feature request berisi solusi yang dipikirkan pengguna (“saya butuh tombol export PDF”), sedangkan job to be done berisi tujuan yang ingin dicapai (“saya butuh laporan bulanan untuk dipresentasikan ke direksi”). Tugas Anda adalah menggali job, bukan menjadi tukang implementasi feature request.

Skala intensitas pain: vitamin, painkiller, morphine

Tidak semua masalah layak jadi bisnis. Kategorikan dulu intensitasnya.

• Vitamin: enak kalau ada, tapi pengguna bisa hidup tanpa itu. Contoh: aplikasi untuk filter foto pre-wedding. Orang ngerti gunanya, tapi tidak akan bayar mahal. Adopsi lambat, churn tinggi.
• Painkiller: ada masalah riil yang mengganggu rutinitas. Pengguna mau bayar untuk hilangkan rasa sakit. Contoh: aplikasi absen karyawan untuk HRD yang tiap akhir bulan begadang rekap manual. Adopsi cepat ketika ditunjukkan ROI.
• Morphine: masalah krusial yang kalau tidak diselesaikan, ada konsekuensi besar (kehilangan uang, klien, atau nyawa). Contoh: sistem antrean rumah sakit untuk pasien BPJS. Salah hitung, pasien telantar. Pengguna rela bayar tinggi karena alternatifnya berisiko fatal.

Aturan praktis: bisnis early stage paling cepat tumbuh ketika menjual painkiller atau morphine. Kalau ide Anda cuma vitamin, cari urgency-nya sebelum lanjut. Atau, bundling vitamin Anda dengan painkiller yang relevan supaya lebih dipakai berulang.

Asumsi vs bukti

Setiap ide bisnis berdiri di atas tumpukan asumsi. Beberapa contoh asumsi yang berisiko tinggi: “mahasiswa rela bayar 50 ribu per bulan untuk aplikasi belajar”, “UMKM kuliner butuh dashboard analytics”, atau “alumni butuh platform mentorship khusus”. Tugas pekan ini adalah menemukan asumsi paling berbahaya dan mengubahnya menjadi hipotesis yang bisa diuji.

Cara mudah memetakan: tulis semua keyakinan Anda tentang pengguna, masalah, dan solusi. Beri skor risiko 1 sampai 5. Mulai pengujian dari skor tertinggi. Inilah yang disebut Riskiest Assumption Testing (RAT).

Cara skoring risiko 1 sampai 5

Banyak peserta bingung memberi skor. Pakai patokan ini:

• Skor 5: bila salah, seluruh bisnis tidak punya alasan eksis. Contoh: “Pengguna mau bayar.”
• Skor 4: bila salah, harus pivot besar (segmen, model bisnis, atau channel). Contoh: “Pengguna mau bayar lewat transfer bank, bukan COD.”
• Skor 3: bila salah, harus ubah fitur utama. Contoh: “Pengguna butuh dashboard real-time.”
• Skor 2: bila salah, ubah fitur pendukung. Contoh: “Pengguna prefer push notification dibanding email.”
• Skor 1: bila salah, hanya ubah copywriting atau warna tombol.

Mulai pengujian dari yang skor 5 dulu. Jangan habiskan energi menguji asumsi skor 2 di minggu pertama. Cara uji asumsi tanpa coding: wawancara, smoke test landing page, fake door, mockup interaktif, atau sales pre-order.

Format problem statement yang baik

Problem statement yang kuat punya 4 komponen. Siapa subjeknya, masalah spesifik apa, dalam konteks situasi apa, dan kenapa itu menyakitkan (konsekuensi terukur).

Contoh lemah: “mahasiswa kesulitan belajar.”

Contoh kuat: “Mahasiswa tahun akhir teknik di kota tier 2 kesulitan dapat akses bimbingan industri sebelum sidang TA, sehingga banyak yang lulus tanpa portfolio kerja nyata dan harus magang lagi setelah lulus selama 6 sampai 12 bulan.”

Statement kedua memberi kita target spesifik, konteks situasi, dan konsekuensi terukur. Dari sini hipotesis pengujian jadi jauh lebih mudah disusun.

Studi kasus singkat

Tokopedia (William Tanuwijaya, 2009-2010). William menghabiskan dua tahun bicara dengan pedagang dan pembeli online sebelum Tokopedia dibangun. Dari ratusan obrolan, dia menemukan bahwa transaksi online di forum Kaskus sering tertahan karena tidak ada pihak ketiga yang menjamin pembayaran. Ini bukan masalah teknologi, ini masalah trust. Dari situ lahir sistem rekening bersama yang jadi fitur inti Tokopedia.

Ruangguru (Adamas Belva Devara, 2014). Belva mendatangi puluhan rumah orang tua siswa di Jakarta dan Bandung sebelum mendesain Ruangguru. Yang ditemukan: orang tua menengah ke bawah ingin anaknya les privat tapi kesulitan cari guru yang dipercaya dan terjangkau. Format awal Ruangguru bukan video pelajaran, tapi marketplace guru les privat. Pivot ke video baru terjadi setelah pasar marketplace divalidasi.

Gojek (Nadiem Makarim, 2010-2015). Sebelum jadi aplikasi, Gojek dimulai sebagai call center 1 nomor telepon dengan 20 driver ojek. Selama 5 tahun, Nadiem dan tim memvalidasi bahwa pengguna mau bayar premium untuk ojek yang dijemput, bukan dicari di pangkalan. Aplikasi baru launch 2015 setelah model bisnis terbukti sustainable di skala manual.

Pola yang sama berulang: ada fase panjang validasi sebelum eksekusi. Founder yang menang adalah yang paling sabar mendengarkan, bukan yang paling cepat coding.

Simulasi: dari ide kasar ke peta hipotesis

Mari kita jalankan satu contoh utuh. Ide kasar: aplikasi untuk bantu UMKM kuliner kelola pesanan online.

Langkah 1. Tulis dulu daftar asumsi mentah

• UMKM kuliner kewalahan kelola pesanan dari banyak channel
• Pemilik UMKM mau bayar 99 ribu per bulan
• Solusi yang ada (notes di HP) sudah tidak cukup
• Pemilik UMKM bisa pakai aplikasi tanpa training
• Channel pesanan utama: GoFood, GrabFood, WhatsApp

Langkah 2. Skor risiko

Langkah 3. Susun problem statement

Pemilik UMKM kuliner di kota besar yang menerima pesanan dari 3 atau lebih channel (GoFood, GrabFood, WhatsApp) sering melewatkan pesanan saat jam ramai 11.00 sampai 13.00, sehingga rating turun dan kehilangan repeat order rata-rata 12 transaksi per minggu.

Langkah 4. Turunkan hipotesis yang akan diuji

Inilah output yang harus Anda hasilkan minggu ini. Bukan aplikasi, bukan logo, bukan nama brand. Cukup peta yang jelas tentang apa yang akan diuji.

Contoh problem statement dari domain lain

Sebagai referensi tambahan, berikut bentuk problem statement dari berbagai domain:

• B2B SaaS HR: Manajer HR perusahaan 50 sampai 200 karyawan kesulitan menyusun laporan kinerja bulanan karena data tersebar di Excel, absensi, dan email, menghabiskan 8 sampai 12 jam per bulan.
• Marketplace jasa: Pemilik rumah tangga di Jabodetabek kesulitan menemukan jasa AC service yang transparan harga dan kualitas, sehingga 40 persen merasa ditipu setelah panggil teknisi.
• Consumer health: Ibu menyusui usia 25 sampai 35 di kota besar bingung apakah ASI cukup karena tidak ada cara objektif mengukur, menyebabkan banyak yang beralih ke sufor lebih cepat dari rekomendasi WHO.
• Edtech vokasi: Lulusan SMK jurusan multimedia di kota tier 2 punya skill dasar tapi tidak punya portfolio profesional, menyebabkan tingkat reject di screening kerja mencapai 70 persen.
• Fintech retail: Karyawan kontrak swasta usia 25 sampai 40 di kota besar tidak punya akses kredit konsumtif murah karena tidak masuk kriteria bank, sehingga terjebak pinjol bunga 30 persen per bulan saat darurat.

Semua statement di atas mengikuti pola yang sama: siapa, masalah, konteks, konsekuensi terukur.

Anti-pattern: kesalahan yang harus dihindari

Empat jebakan yang paling sering bikin peserta tersangkut.

1. Mengubah pertanyaan wawancara jadi pitch produk. Anda mendatangi calon pengguna bukan untuk meyakinkan, tapi untuk belajar. Kalau Anda lebih banyak bicara dari mendengar, wawancara Anda gagal.
2. Mengisi worksheet berdasarkan asumsi sendiri tanpa data primer. Worksheet pekan ini sengaja minta cara uji konkret. Bila Anda tidak bisa keluar dari kepala sendiri, hipotesis Anda hanya rasionalisasi.
3. Memberi skor risiko rendah ke asumsi favorit. Bias konfirmasi otomatis. Kalau Anda jatuh cinta dengan ide, Anda akan menganggap asumsi pendukungnya rendah risiko. Lakukan check silang dengan teman se-kohort.
4. Membuat indikator yang tidak bisa salah. Hindari indikator seperti “pengguna setuju” atau “ada minat”. Itu indikator yang akan selalu valid karena orang sopan. Pakai angka yang kalau tidak tercapai, Anda berani mencoret asumsi.

Tugas Worksheet

Buka file pekan-01.xlsx dari sidebar. Total waktu pengerjaan sekitar 80 menit. Kerjakan berurutan: Sheet 1 → Sheet 2 → Sheet 3 → Sheet 4.

Sheet 1: Pemetaan Asumsi (estimasi 25 menit)

Cara mengisi:

1. Tulis 5 sampai 8 asumsi paling berani tentang pengguna, masalah, dan willingness to pay.
2. Kolom Sumber asumsi: dari mana keyakinan ini datang? Pengalaman pribadi, ngobrol dengan 1 teman, baca riset, atau cuma tebakan.
3. Kolom Tingkat risiko: pakai skala 1 sampai 5 di subbab “Cara skoring risiko” di atas.
4. Kolom Cara mengujinya: tulis kata kerja konkret. Contoh: “Wawancara 10 ibu rumah tangga di komplek X”. Hindari “lakukan riset pasar”.

Sheet ini di Excel sudah punya baris contoh isian (italic abu-abu). Itu cuma referensi, jangan diubah. Tulis isian Anda di baris kosong di bawahnya.

Kualitas minimum: minimal 1 asumsi skor 5 dan 1 asumsi skor 4. Kalau semua asumsi Anda skor 1 sampai 2, berarti Anda belum berani berpendapat.

Sheet 2: Problem Statement (estimasi 20 menit)

Cara mengisi:

Kolom Komponen sudah pre-filled dengan: Siapa, Mengalami apa, Konteks, Konsekuensi, Statement utuh. Anda hanya isi kolom Isi.

Kualitas minimum: statement utuh harus mengandung minimal 1 angka spesifik (frekuensi, durasi, persentase, atau nominal). Kalau tidak ada angka, Anda belum cukup spesifik untuk diuji di pekan 2.

Sheet 3: Hipotesis Awal (estimasi 25 menit)

Cara mengisi:

1. Pilih 3 asumsi skor tertinggi dari Sheet 1.
2. Reformulasi jadi hipotesis (kalimat pernyataan yang bisa benar atau salah).
3. Tentukan Indikator valid: angka konkret yang membuat Anda yakin hipotesis benar.
4. Tentukan Indikator gugur: angka konkret yang membuat Anda berani mencoret asumsi ini.

Kualitas minimum: indikator harus berupa angka, bukan kata sifat. Hindari “banyak”, “sering”, “cukup”. Tulis “minimal 7 dari 10” atau “rata-rata di atas 60 menit”.

Sheet 4: Refleksi Pribadi (estimasi 10 menit)

Tiga pertanyaan singkat di akhir worksheet. Jawab dengan jujur. Sheet ini hanya dilihat oleh mentor Anda, tidak dipublikasikan ke kohort.

Cara mengumpulkan

Simpan file dengan nama pekan-01-[nama-Anda].xlsx. Upload ke folder Drive kohort sebelum Sabtu pukul 21.00. Mentor akan review dan beri komentar sebelum sesi pekan 2.

20 Persen Terpenting dari Pekan Ini

Kalau Anda hanya bisa mengingat 5 hal dari modul ini, ingat ini:

1. Mulai dari masalah, jangan dari solusi. Sebelum memikirkan aplikasi atau fitur, pastikan ada manusia yang benar-benar mengalami masalah ini sampai bersedia bayar untuk hilangkan.
2. Tidak semua masalah layak dikejar. Cari yang painkiller atau morphine. Vitamin tidak menggerakkan bisnis di tahap awal.
3. Asumsi paling berbahaya diuji duluan. Skor 5 dulu, skor 1 belakangan. Jangan kebalik.
4. Problem statement tanpa angka spesifik berarti belum jadi. Siapa, masalah apa, konteks mana, konsekuensi terukur. Empat-empatnya wajib.
5. Hipotesis butuh indikator yang bisa membuktikan salah. Kalau tidak ada angka yang membuat Anda berani mencoret asumsi, Anda hanya akan terus bias mendukung ide sendiri.

Checklist Peserta Sebelum Lanjut ke Pekan 2

Beri tanda centang. Lanjut ke pekan 2 hanya bila minimal 8 dari 10 sudah tercentang.

• Saya bisa menjelaskan beda problem, pain, dan jobs to be done dalam 1 menit
• Saya sudah menulis minimal 5 asumsi tentang ide saya
• Minimal 1 asumsi saya skor 5 dan 1 asumsi skor 4
• Setiap asumsi punya cara uji konkret berbentuk kata kerja (bukan “riset pasar”)
• Problem statement saya mengandung minimal 1 angka spesifik
• Problem statement menyebut konteks (kapan, di mana, dalam situasi apa)
• Saya menulis 3 hipotesis dengan indikator valid berupa angka
• Saya menulis indikator gugur untuk setiap hipotesis (ambang batas mencoret asumsi)
• Saya sudah punya daftar minimal 10 calon orang yang akan diwawancarai pekan 2
• Saya tidak terlanjur membuat aplikasi, mockup, atau logo sebelum validasi

Centang yang jujur. Kalau belum 8 dari 10, ulang bagian yang masih lemah sebelum lanjut. Lebih baik sedikit lambat tapi solid daripada cepat tapi fondasinya goyah.