Apa Itu Masalah? (Dan Kenapa Kebanyakan Orang Salah Define)

Sebelum kamu build apapun, kamu harus bisa jawab satu pertanyaan: masalah apa yang kamu selesaikan?

Kedengarannya gampang. Tapi kebanyakan orang salah dari sini.

Masalah Bukan “Sesuatu yang Salah”

Coba pikir. Macet itu masalah? Tergantung. Kalau kamu lagi rebahan di rumah, macet bukan masalah kamu. Kalau kamu harus sampai di kantor jam 9 dan sekarang jam 8:45, macet jadi masalah.

Hujan itu masalah? Buat petani yang butuh air, hujan itu berkah. Buat orang yang mau nikahan outdoor, hujan itu bencana.

Jadi apa dong definisi masalah?

Masalah = apapun yang menghalangi kamu mencapai tujuan.

Simpel. Tapi implikasinya besar:

Tanpa tujuan, nggak ada masalah. Yang ada cuma fakta. “Banjir tiap tahun” itu fakta. Baru jadi masalah kalau tujuan kamu adalah “tinggal di tempat kering.”
Masalah itu kontekstual. Hal yang sama bisa jadi masalah buat orang A dan bukan masalah buat orang B. Tergantung tujuan masing-masing.
Kalau nggak bisa tunjuk tujuannya, kamu belum punya masalah. Kamu cuma punya keluhan.

Langkah Pertama: Define Tujuan Dulu

Sebelum bilang “X itu masalah”, tanya dulu:

1. Tujuan siapa?
2. Tujuannya apa, spesifik?
3. Apa yang menghalangi tujuan itu tercapai?
4. Bisa dibuktikan nggak hambatannya?

Contoh:

“Saya mau bikin app keuangan” — Ini bukan masalah. Ini solusi. Mundur satu langkah.

“Freelancer susah track pemasukan dari 5 client berbeda karena semuanya lewat channel yang beda-beda (transfer, e-wallet, cash). Akibatnya tiap akhir bulan mereka nggak tahu untung atau rugi.” — Ini masalah. Ada tujuan (tahu kondisi keuangan), ada hambatan (data tersebar), ada orang yang merasakan (freelancer).

Jebakan Umum: Loncat ke Solusi

Ini pola yang paling sering terjadi:

"Saya mau bikin app untuk X"
"Butuh fitur Y"
"Bagus kalau ada Z"

Semua itu bukan masalah. Semua itu solusi. Dan solusi tanpa masalah yang jelas = kamu nggak tahu lagi ngapain.

Kenapa ini berbahaya? Karena kamu bisa habiskan berminggu-minggu build sesuatu yang nggak ada yang butuh. Bukan karena app-nya jelek — tapi karena masalahnya nggak pernah ada dari awal.

Framework: River Crossing

Cara paling gampang untuk framing masalah: bayangin kamu mau nyeberangin sungai.

Sisi Sini — Realita Sekarang	Sisi Sana — Keadaan Ideal
Sakitnya user sekarang, tanpa app kamu	Dunia user setelah masalah selesai
Bukan fitur. Bukan solusi. Tapi rasa sakit yang nyata.	Bukan fitur. Tapi perubahan hidup yang terjadi.

Contoh:

Sisi Sini	Sisi Sana
Freelancer nggak tahu berapa total pemasukan bulan ini karena datanya ada di 5 tempat berbeda	Freelancer bisa lihat total pemasukan real-time di satu tempat, tanpa input manual
UMKM ngira untung padahal ternyata rugi karena nggak pisah uang pribadi dan bisnis	UMKM tahu persis profit margin tiap bulan dan bisa ambil keputusan berdasarkan data

Aturan penting: Jangan bahas jembatan (solusi/fitur) sebelum kedua sisi sungai jelas dan disepakati. Kalau kamu langsung ngomong “kita bikin dashboard”, kamu sudah skip bagian terpenting.

Buktikan Masalahnya Ada

Setelah kamu define masalah, ada satu langkah lagi yang sering di-skip: buktiin.

Banyak orang bikin app berdasarkan asumsi:

“Pasti banyak yang butuh ini”
“Temen gue bilang ini bagus”
“Di luar negeri ada app kayak gini”

Itu semua bukan bukti. Itu opini.

Yang perlu kamu buktikan:

Yang diklaim	Yang harus dibuktikan
”X adalah masalah”	X benar-benar menghambat tujuan seseorang
”Banyak orang punya masalah ini”	Kamu bisa tunjuk siapa dan berapa banyak
”Solusi saya akan menyelesaikan ini”	Solusi kamu mengubah hambatan sehingga tujuan tercapai

Cara paling simpel buat buktiin: tanya orangnya langsung. Bukan tanya “kamu mau app ini nggak?” (semua orang bilang mau). Tapi tanya “ceritain terakhir kali kamu ngalamin masalah ini. Apa yang kamu lakuin?”

Kalau mereka nggak bisa cerita pengalaman nyata — masalahnya mungkin nggak ada.

Latihan: Coba Sekarang

Tulis 1 ide app yang mau kamu build.
Mundur. Tulis masalah apa yang coba kamu selesaikan — tanpa menyebut fitur atau solusi.
Pakai River Crossing: tulis Sisi Sini dan Sisi Sana.
Tanya diri sendiri: “Bisa nggak aku buktiin masalah ini ada? Siapa yang ngalamin? Kapan terakhir?”

Kalau kamu bisa jawab semua itu — selamat, kamu punya masalah yang worth solving. Kalau belum bisa? Bagus juga. Sekarang kamu tahu apa yang harus dicari sebelum mulai build.

TL;DR

Masalah = tujuan + hambatan. Tanpa tujuan, nggak ada masalah.
Jangan mulai dari solusi. Mulai dari rasa sakit yang nyata.
Pakai River Crossing: Sisi Sini (pain) → Sisi Sana (outcome). Jangan bahas jembatan dulu.
Buktikan masalahnya ada sebelum build apapun.

Bawa jawaban latihan ini ke live session minggu pertama. Kita framing bareng.