Jangan Cuma Ngeluh, Build Sesuatu

Semua orang bisa nunjuk masalah. “App ini jelek.” “Prosesnya ribet.” “Harusnya ada yang bikin solusi buat ini.”

Tapi berapa banyak yang benar-benar build solusinya?

Di bootcamp ini, kamu belajar jadi orang yang kedua — yang nggak cuma ngeluh, tapi build sesuatu sebagai respons.

Dua Jenis Orang

Tipe 1: Penunjuk Masalah	Tipe 2: Builder
”App kompetitor jelek banget UX-nya"	"Aku bikin prototype yang lebih baik, ini demo-nya"
"Proses di kantor terlalu manual"	"Aku bikin automation sederhana, ini hasilnya"
"Nggak ada tools yang cocok buat kebutuhan ini"	"Aku bikin tools-nya sendiri, ini MVP-nya”

Tipe 1 banyak. Tipe 2 langka. Bootcamp ini bikin kamu jadi Tipe 2.

Dan kamu nggak perlu jadi programmer untuk jadi Tipe 2. Kamu cuma perlu:

Berani tunjuk masalahnya
Berani bikin versi kasar dari solusinya
Berani minta feedback — dan terima dengan lapang

Berani Tunjuk Masalah

Menunjuk masalah itu bukan ngeluh. Ngeluh itu bilang “ini jelek” tanpa konteks. Menunjuk masalah itu bilang:

“Tujuannya adalah X. Yang menghambat tercapainya tujuan itu adalah Y. Ini buktinya.”

Bedanya ada di 3 hal:

Ada tujuan yang jelas. Bukan “ini jelek” tapi “ini nggak achieve tujuan spesifik.”
Ada hambatan yang bisa ditunjuk. Bukan “semuanya salah” tapi “bagian ini yang bermasalah.”
Ada bukti. Bukan “kayaknya” tapi “ini datanya / ini pengalaman nyata.”

Contoh:

Jelek: “Proses invoice di kantor gue ribet banget.”

Bagus: “Tim sales harus copy-paste data dari 3 sistem berbeda untuk bikin 1 invoice. Rata-rata butuh 25 menit per invoice. Bulan lalu ada 3 invoice salah karena typo saat copy-paste. Ini bikin revenue delay 2 minggu.”

Yang kedua bukan cuma keluhan — itu diagnosis. Dan diagnosis yang baik adalah langkah pertama menuju solusi.

Prototype Sebagai Argumen

Presentasi paling powerful di dunia bukan slide deck 50 halaman. Tapi sesuatu yang bisa diklik.

Seribu kata nggak bisa ngalahin satu working prototype.

Ini bukan soal bikin app yang sempurna. Ini soal bikin sesuatu yang cukup nyata untuk membuktikan bahwa ide kamu punya potensi.

Prototype bisa berupa:

Landing page sederhana yang jelasin masalah dan solusi
Mockup yang bisa diklik (bahkan pakai Google Slides)
Bot WhatsApp sederhana
Spreadsheet yang di-automate
Website 1 halaman yang live di internet

Kunci-nya: sesuatu yang orang lain bisa lihat dan coba, bukan cuma denger cerita kamu tentang itu.

Kenapa Prototype Lebih Kuat dari Presentasi?

Menghilangkan ambiguitas. “App yang bisa track keuangan” bisa berarti 100 hal berbeda di kepala 100 orang. Prototype menunjukkan persis apa yang kamu maksud.
Mengundang feedback yang konkret. Orang sulit kasih feedback ke ide abstrak. Tapi begitu lihat sesuatu yang nyata: “tombol ini harusnya di sini”, “ini kurang info X”, “ini gue bakal pakai tiap hari.”
Membuktikan kamu serius. Siapapun bisa ngomong. Sedikit yang build. Prototype membuktikan kamu bukan cuma ngomong.

Solution-First Juga Valid

Di bootcamp ini kamu belajar framing masalah dulu sebelum build. Dan itu penting.

Tapi ada situasi di mana mulai dari solusi juga valid:

Mulai dari Masalah	Mulai dari Solusi
Kamu jelas tahu ada orang yang suffer	Kamu lihat teknologi baru dan pikir “ini bisa solve apa ya?”
User bisa ceritakan pain mereka	User belum tahu apa yang possible
Improvement dari sesuatu yang sudah ada	Sesuatu yang belum pernah ada sebelumnya

Contoh solution-first yang berhasil:

Claude Artifacts di Anthropic: seorang researcher bikin prototype kasar — code yang di-generate AI jadi panel interaktif. Nggak ada problem statement. Tapi saat tim lihat, semua langsung paham ini powerful. Ini mengubah cara jutaan orang pakai AI.

Jadi kalau kamu punya ide “random” yang kamu excited sama itu — jangan langsung dismiss karena “belum ada problem statement.” Build prototype-nya dulu. Problem statement bisa ditemukan setelah kamu lihat apa yang possible.

Yang penting: tetap validasi. Solution-first bukan excuse buat skip validasi. Bikin prototype → tunjukkan ke orang → tanya: “ini solve masalah kamu nggak?”

Budaya Feedback

Di bootcamp ini, kamu akan sering kasih dan terima feedback. Ini skill yang perlu dilatih.

Cara Kasih Feedback yang Konstruktif

Bukan: “Ini jelek.” / “Ini bagus.”

Tapi: Observasi + Impact + Saran

Komponen	Contoh
Observasi	”Di halaman utama, user harus scroll 3x sebelum lihat fitur utama”
Impact	”Ini bikin banyak orang nggak tahu app ini bisa apa, dan langsung close”
Saran	”Gimana kalau fitur utama ditaruh di atas, sebelum fold?”

Cara Terima Feedback

Dengerin dulu, jangan langsung defend. Feedback bukan serangan personal. Ini informasi.
Tanya “kenapa”. “Kamu bilang ini confusing — bagian mana spesifik-nya? Apa yang kamu expect terjadi?”
Nggak semua feedback harus diikuti. Kamu yang decide mana yang relevan. Tapi semua feedback harus di-dengerin.
Tulis. Jangan cuma dengerin di udara. Catat di Obsidian. Feedback hari ini bisa jadi insight paling valuable bulan depan.

Peer Review di Bootcamp

Setiap minggu, kamu akan review pekerjaan teman dan teman review pekerjaanmu. Format simpel:

1. Apa yang sudah bagus? (spesifik, bukan cuma "bagus")
2. Apa yang bisa di-improve? (observasi + impact + saran)
3. Satu pertanyaan yang bikin mereka mikir

Jadi Builder, Bukan Cuma Consumer

Selama ini kamu pakai app yang orang lain bikin. Mulai sekarang, kamu yang bikin.

Dan kamu nggak perlu bikin sesuatu yang sempurna. Kamu perlu bikin sesuatu yang nyata. Sesuatu yang bisa ditunjuk: “ini gue yang bikin.” Ugly? Boleh. Belum lengkap? Boleh. Yang penting exist — bisa diakses, bisa dicoba, bisa dikritik.

Karena sesuatu yang exist — se-ugly apapun — selalu lebih valuable dari ide sempurna yang cuma ada di kepala.

“Kamu tidak perlu jadi programmer. Kamu perlu jadi BUILDER.”

Latihan: Mulai dari Sini

Pikirin satu masalah yang sering kamu keluhkan (di kerjaan, di kehidupan sehari-hari, di komunitas).
Tulis diagnosis-nya: Tujuannya apa? Hambatannya apa? Buktinya apa?
Pikirin: kalau kamu bikin solusi paling sederhana buat masalah ini — bentuknya apa? (Nggak harus app. Bisa spreadsheet, bot, website 1 halaman.)
Tanya 1 orang yang punya masalah yang sama: “Kalau ada solusi ini, kamu bakal pakai nggak? Kenapa?”

TL;DR

Ngeluh ≠ menunjuk masalah. Menunjuk masalah butuh tujuan + hambatan + bukti.
Prototype > presentasi. Sesuatu yang bisa diklik lebih powerful dari 50 slide.
Solution-first juga valid — tapi tetap harus validasi.
Feedback itu skill: kasih dengan Observasi + Impact + Saran, terima dengan telinga terbuka.
Jadi builder. Bikin sesuatu yang exist.