← Kembali ke Insight

Strategi

12 Pertanyaan Discovery yang Harus Ditanyakan Setiap Founder Sebelum Building

10 Desember 2025 7 menit baca

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.


Pertanyaan Masalah

Sebelum menyelesaikan apapun, pastikan kamu paham apa yang sedang kamu selesaikan.

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.

Separate problem from solution thinking

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:

LevelDeskripsiPerilaku User
RinganMenjengkelkan tapi bisa ditolerirMengeluh tapi nggak bertindak
SedangFrustrasi, buang waktuCari solusi sesekali
ParahBikin rugi uang atau peluangAktif mencari, mau bayar
KritisKrisis bisnis atau personalMau 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?

The pain spectrum from mild to critical


Pertanyaan Solusi

Setelah kamu memahami masalahnya, interogasi solusi kamu.

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:

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

Kebanyakan MVP yang kami lihat itu 3-5x lebih besar dari yang diperlukan. Potong tanpa ampun.

The MVP minimization exercise

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. Verifikasi ekonominya.

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.

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

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. Dalam dua minggu, kamu akan tahu apakah harus build, pivot, atau berhenti—berdasarkan bukti, bukan harapan.

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


Artikel Terkait

Butuh bantuan menerapkan ini?

Pesan sesi Blueprint dan kami akan ubah ide di artikel ini jadi rilis tervalidasi berikutnya.

Jadwalkan Discovery Call