12 Pertanyaan Discovery yang Harus Ditanyakan Setiap Founder Sebelum Building

Setiap founder yang bekerja sama dengan kami punya keyakinan. Mereka sudah menemukan masalah. Mereka punya solusi. Mereka siap build.

Keyakinan itu perlu. Tapi keyakinan tanpa validasi cuma optimisme yang mahal.

Founder terbaik menyeimbangkan keyakinan dengan rasa ingin tahu. Mereka mengajukan pertanyaan sulit sebelum commit resource. Mereka lebih memilih membunuh ide buruk di minggu pertama daripada menemukan itu buruk di bulan keenam.

Ini 12 pertanyaan yang kami tanyakan di setiap engagement discovery. Jawab dengan jujur sebelum kamu menulis satu baris kode pun.

TL;DR — seluruh panduan dalam lima baris:

Deskripsikan masalah tanpa menyebut solusi kamu — kalau nggak bisa, kamu jatuh cinta pada solusinya, bukan masalahnya.
Kebanyakan masalah itu vitamin, bukan painkiller — cuma rasa sakit parah yang bikin rugi uang atau peluang yang memotivasi orang untuk bayar.
MVP sejati kamu 3–5x lebih kecil dari yang kamu kira — potong setiap fitur yang tanpa itu user tetap dapat value.
Verifikasi matematika bisnisnya, bukan cuma rasa sukanya — produk yang dicintai user tetap bisa gagal di biaya akuisisi dan churn.
Founder-market fit dan pengorbanan nyata menentukan eksekusi — ide itu murah; fokus yang berkelanjutan itu yang langka.

Founder dalam cat air grayscale memeriksa hamparan kartu ide dengan kaca pembesar — hanya beberapa kartu tervalidasi yang menyala magenta dan ungu

12 pertanyaan ini terbagi dalam empat kelompok. Ini petanya sebelum kita bahas satu per satu:

Kelompok pertanyaan	Yang diuji	Red flag-nya
Masalah (Q1–4)	Apakah rasa sakitnya nyata, spesifik, dan parah?	Kamu nggak bisa mendeskripsikan masalah tanpa solusi kamu
Solusi (Q5–7)	Apakah solusimu lebih baik, kecil, dan bisa diuji?	”Berbeda” bukan lebih baik dalam hal yang dipedulikan user
Bisnis (Q8–10)	Apakah channel, harga, dan timing benar-benar jalan?	”Kita akan melakukan marketing”
Tim (Q11–12)	Apakah kamu spesifik bisa mengeksekusi ini?	Kamu baca soal masalahnya di blog

Pertanyaan Masalah

Sebelum menyelesaikan apapun, pastikan kamu paham apa yang sedang kamu selesaikan. Kalau masalahnya nggak spesifik, nggak menyakitkan, dan nggak dimiliki kelompok orang yang bisa ditemukan, solusi apa pun nggak akan menyelamatkannya.

1. Bisakah Kamu Mendeskripsikan Masalahnya dalam Satu Kalimat—Tanpa Menyebut Solusi Kamu?

Ini kedengarannya simpel. Ternyata nggak.

Buruk: “Usaha kecil butuh cara yang lebih baik untuk mengelola invoice dengan otomasi bertenaga AI.”

Bagus: “Pemilik usaha kecil menghabiskan 5+ jam per minggu mengejar pembayaran telat.”

Versi buruk menyelundupkan solusi (otomasi bertenaga AI). Versi bagus menyatakan masalah secara netral. Kamu bisa menyelesaikan “mengejar pembayaran telat” dengan banyak cara—reminder otomatis, desain invoice yang lebih baik, konsultasi terms pembayaran, layanan factoring.

Kalau kamu nggak bisa mendeskripsikan masalah tanpa solusi kamu, mungkin kamu jatuh cinta pada solusi, bukan pada masalahnya.

Memisahkan cara berpikir masalah dari solusi

2. Bagaimana Orang Menyelesaikan Masalah Ini Sekarang?

Setiap masalah punya solusi saat ini—bahkan kalau itu “abaikan saja” atau “pakai spreadsheet.”

Memahami solusi yang ada mengungkap:

Switching cost: Apa yang kamu tarik orang-orang darinya?
Kompetisi: Siapa lagi yang coba menyelesaikan ini?
Baseline: Apa minimum yang harus kamu kalahkan?

Kalau orang nggak punya solusi saat ini, tanyakan kenapa. Kadang jawabannya adalah “masalahnya nggak cukup menyakitkan untuk diselesaikan.” Itu penting untuk diketahui.

3. Siapa yang Paling Punya Masalah Ini?

“Semua orang” bukan target market. Begitu juga “usaha kecil” atau “milenial.”

Lebih spesifik:

Demografi: Usia, lokasi, penghasilan, industri
Psikografi: Sikap, perilaku, prioritas
Situasi: Apa yang memicu kebutuhannya?

Lebih baik: “Pemilik toko e-commerce dengan revenue $50K-500K/tahun, tanpa orang finance full-time, yang jualan di banyak platform.”

Spesifisitas membantu kamu menemukan user, menulis messaging, dan memprioritaskan fitur. Kamu bisa expand nanti. Mulai sempit dulu.

4. Seberapa Menyakitkan Masalah Ini—Beneran?

Rasa sakit itu ada spektrumnya:

Level	Deskripsi	Perilaku User
Ringan	Menjengkelkan tapi bisa ditolerir	Mengeluh tapi nggak bertindak
Sedang	Frustrasi, buang waktu	Cari solusi sesekali
Parah	Bikin rugi uang atau peluang	Aktif mencari, mau bayar
Kritis	Krisis bisnis atau personal	Mau bayar berapapun

Kebanyakan masalah itu ringan atau sedang. Produk yang dibangun untuk masalah ringan susah dapat traction karena rasa sakitnya nggak memotivasi aksi.

Cara menilai rasa sakit:

Apakah orang menghabiskan uang untuk workaround?
Apakah mereka mengeluh tentang ini tanpa diminta?
Apakah mereka sudah coba solusi lain?
Apa yang terjadi kalau mereka nggak menyelesaikannya?

Spektrum rasa sakit dari ringan sampai kritis

Validasi dalam 2 minggu. Sesi Blueprint mengubah pemikiran ini jadi prototype yang diuji ke user nyata — lihat cara kerja Blueprint & Prototype.

Pertanyaan Solusi

Setelah kamu memahami masalahnya, interogasi solusi kamu. Solusi layak dibangun hanya kalau lebih baik dalam hal yang dipedulikan user, cukup kecil untuk diuji, dan dibangun di atas asumsi yang sudah kamu buat eksplisit.

5. Kenapa Solusi Kamu Akan Bekerja Lebih Baik dari Alternatif?

Bukan “berbeda.” Lebih baik.

Diferensiasi penting hanya kalau meningkatkan hasil. Aplikasi invoice berwarna ungu itu berbeda. Aplikasi invoice yang bikin kamu dibayar 10 hari lebih cepat itu lebih baik.

Kategori “lebih baik”:

Lebih cepat: Hemat waktu, hasil lebih cepat
Lebih murah: Biaya lebih rendah, value lebih baik
Lebih mudah: Lebih simpel, learning curve lebih rendah
Lebih lengkap: Selesaikan masalah adjacent juga
Lebih accessible: Tersedia untuk segmen yang underserved

Kalau kamu nggak bisa mengartikulasikan kenapa kamu lebih baik dalam hal yang dipedulikan user, kamu punya masalah diferensiasi.

6. Apa Versi Terkecil yang Memberikan Value?

Versi pertama kamu harus membuktikan satu hal: bahwa user menginginkan apa yang kamu bangun.

Itu saja. Bukan “pamerkan visi kamu.” Bukan “impress investor.” Buktikan demand.

Latihan minimisasi:

List semua fitur yang direncanakan
Untuk masing-masing, tanya: “Bisa nggak user dapat value tanpa ini?”
Hapus semua yang jawabannya “ya”
Yang tersisa adalah MVP sejati kamu

Kebanyakan MVP yang kami lihat itu 3-5x lebih besar dari yang diperlukan. Potong tanpa ampun. Dan sebelum kamu commit ke MVP sama sekali, cek dulu apakah pilot atau prototype bisa menjawab pertanyaan kamu lebih cepat.

Latihan minimisasi MVP

7. Apa yang Harus Benar Supaya Ini Berhasil?

Setiap produk bergantung pada asumsi. Buat eksplisit:

User mau bayar $X/bulan
Kita bisa acquire customer kurang dari $Y
User akan cek app setiap hari
Integrasi dengan Z itu memungkinkan
Target market kita sedang tumbuh

Ini adalah killer assumptions kamu—hal-hal yang harus benar supaya bisnisnya sukses. Kalau salah satunya salah, produknya gagal.

Langkah selanjutnya: Ranking asumsi berdasarkan ketidakpastian. Test yang paling berisiko duluan.

Pertanyaan Bisnis

Produk hebat tetap bisa jadi bisnis yang buruk — channel, harga, dan timing juga pertanyaan validasi.

8. Bagaimana User Akan Menemukan Kamu?

“Kita akan melakukan marketing” bukan strategi.

Identifikasi channel spesifik:

Content/SEO: Kamu akan ranking untuk apa? Berapa lama sampai ada traffic?
Paid acquisition: Berapa ekspektasi CAC? Apakah unit economics-nya works?
Partnership: Siapa yang akan mempromosikan kamu? Apa untungnya buat mereka?
Komunitas: Di mana user kamu berkumpul? Bisa nggak kamu berpartisipasi secara autentik?
Word of mouth: Apa yang bikin ini cukup remarkable untuk di-share?

Test sebelum building: Bisa nggak kamu dapat 100 orang yang tertarik di landing page kamu? Kalau nggak, gimana kamu mau dapat 10.000 orang yang pakai produk kamu?

9. Berapa User Mau Bayar—dan Apakah Itu Cukup?

Dua pertanyaan di sini:

Willingness to pay:

Berapa yang mereka bayar untuk solusi serupa?
Berapa nilai dalam rupiah dari menyelesaikan masalah ini?
Berapa harga yang mereka ekspektasi saat kamu deskripsikan produknya?

Unit economics:

Revenue per user vs. biaya acquire
Lifetime value vs. ekspektasi churn
Margin setelah biaya infrastructure dan support

Produk bisa dicintai user dan tetap gagal sebagai bisnis. Verifikasi matematikanya.

10. Kenapa Sekarang?

Kenapa ini waktu yang tepat untuk produk ini?

Jawaban bagus:

Teknologi baru memungkinkan apa yang sebelumnya nggak mungkin
Regulasi berubah, menciptakan peluang
Perilaku pasar bergeser (remote work, mobile-first, dll.)
Incumbent rentan (ketinggalan zaman, mahal, dibenci)

Jawaban buruk:

“Aku baru kepikiran”
“Belum ada yang bikin” (mungkin ada alasannya)
“Aku lagi ada waktu”

Timing itu lebih penting dari yang disadari kebanyakan founder. Terlalu awal sama mematikannya dengan terlalu terlambat.

Pertanyaan Tim

Ide itu murah. Eksekusi adalah segalanya — dan eksekusi ditentukan oleh founder-market fit serta apa yang rela kamu korbankan.

11. Kenapa Kamu Tim yang Tepat untuk Membangun Ini?

Investor menyebut ini “founder-market fit.”

Founder-market fit yang kuat:

Kamu pernah mengalami masalah ini secara personal
Kamu pernah kerja di industri ini
Kamu punya expertise teknis yang relevan
Kamu punya akses unfair ke customer
Kamu irrationally committed di space ini

Founder-market fit yang lemah:

Kamu baca tentang masalah ini di blog
Kamu pikir pasarnya besar (tapi nggak punya koneksi ke sana)
Kamu excited soal teknologinya lebih dari masalahnya

Kamu nggak perlu semua sinyal kuat, tapi butuh beberapa. Membangun produk itu susah. Membangun produk di domain yang nggak kamu pahami itu lebih susah.

12. Apa yang Akan Kamu Hentikan untuk Melakukan Ini?

Waktu itu terbatas. Membangun sesuatu yang baru berarti nggak melakukan sesuatu yang lain.

Untuk founder yang masih kerja:

Kapan kamu akan kerja ini? Sebelum kerja? Malam? Weekend?
Berapa lama kamu bisa sustain itu? Berbulan-bulan? Setahun?
Di titik mana kamu full-time?

Untuk founder full-time:

Proyek atau komitmen lain apa yang kamu drop?
Bagian mana dari rutinitas kamu yang berubah?
Siapa yang cover hal-hal yang kamu tinggalkan?

Memulai sesuatu itu mudah. Mempertahankannya butuh pengorbanan. Ketahui apa yang kamu tukarkan.

Cara Menggunakan Pertanyaan Ini

Jawab semua 12 pertanyaan secara tertulis sebelum build, kunjungi ulang seiring kamu belajar, dan jangan commit uang serius sampai jawabannya menajam.

Sebelum Kamu Mulai Building

Kerjakan semua 12 pertanyaan. Tulis jawabannya. Jujur—kamu cuma membohongi diri sendiri kalau kamu mengarangnya.

Red flag yang menunjukkan butuh validasi lebih:

Kamu nggak bisa mengartikulasikan masalah tanpa solusi kamu
Kamu menebak-nebak soal siapa yang punya masalah
Level rasa sakit terlihat ringan atau sedang
Nggak ada channel yang jelas untuk menjangkau user
Founder-market fit lemah

Selama Discovery

Kunjungi ulang pertanyaan ini seiring kamu belajar lebih banyak. Jawaban kamu harusnya semakin tajam dan makin confident.

Kalau jawaban malah makin kabur—kalau riset mengungkap asumsi kamu salah—itu justru berharga. Pivot sebelum kamu investasi lebih banyak.

Sebelum Investasi Besar

Sebelum pendanaan signifikan, hiring, atau komitmen development, verifikasi:

Pertanyaan masalah punya jawaban yang didukung bukti
Pertanyaan solusi punya validasi user
Pertanyaan bisnis punya data (bahkan yang kasar)
Pertanyaan tim dinilai dengan jujur

Apa Selanjutnya

Pertanyaan-pertanyaan ini mengungkap apakah kamu siap build. Kalau jawabannya kuat, maju dengan percaya diri. Kalau lemah, butuh discovery lebih lanjut.

Proses Blueprint kami secara sistematis menjawab pertanyaan-pertanyaan ini melalui user research dan eksperimen validasi — lihat cara kerja metodologinya atau apa saja isi engagement Blueprint & Prototype. Dalam dua minggu, kamu akan tahu apakah harus build, pivot, atau berhenti—berdasarkan bukti, bukan harapan.

Butuh bantuan menjawab pertanyaan ini? Book discovery call dan mari kita bicara soal situasi spesifik kamu.

FAQ

Apa itu pertanyaan product discovery? Pertanyaan terstruktur yang dijawab tim sebelum building — mencakup masalah, solusi, model bisnis, dan tim — untuk memastikan produknya layak dibangun. 12 pertanyaan di atas adalah set yang kami pakai di setiap engagement discovery.

Gimana cara validasi ide startup sebelum building? Deskripsikan masalahnya tanpa solusi kamu, pastikan rasa sakitnya cukup parah sampai orang sudah bayar untuk workaround, lalu taruh versi terkecil yang bisa diuji — prototype, pilot, atau MVP yang dipilih berdasarkan risiko terbesar kamu — di depan user nyata.

Berapa lama product discovery seharusnya? Untuk kebanyakan produk, dua minggu yang fokus cukup untuk menjawab pertanyaan paling berisiko dengan bukti. Engagement Blueprint kami memadatkan discovery jadi persis itu: riset, blueprint yang siap diputuskan, dan prototype yang sudah diuji.

Apa yang terjadi kalau aku skip discovery? Kamu mewarisi statistik dasarnya: 42% startup yang gagal menyebut “no market need” sebagai alasan utama mereka mati. Discovery adalah cara kamu tahu itu di minggu pertama, bukan bulan keenam.

LAYANAN UTAMA

PROGRAM KHUSUS

PRODUK KAMI

RINGKASAN

STUDI KASUS

TENTANG

SUMBER DAYA