Core Thesis
”Start from the problem, not the solution” adalah advice yang valid di era teknologi statis. Tapi di era di mana teknologi berubah lebih cepat dari problem space, pendekatan solution-first jadi equally — kadang lebih — valid. Kamu nggak selalu tahu problem worth solving sampai kamu lihat solusinya.
Kenapa Solution-First Dianggap “Haram”
Design process klasik (design thinking, double diamond, dll.) mengajarkan flow linear:
- Discover problems → 2. Define problem statement → 3. Develop solutions → 4. Deliver
Mulai dari solusi dianggap:
- Ego-driven (“saya sudah tahu jawabannya”)
- Skip user empathy
- Bias confirmation
- ”Bad design practice”
Dan di era sebelumnya, ini mostly benar. Teknologi relatif statis — mobile, web, database — jadi competitive advantage ada di siapa yang paling paham user problems.
Apa yang Berubah: Tech Moves Faster Than Problems
Di era AI, dinamikanya kebalik:
| Era Sebelumnya | Era AI |
|---|---|
| Tech statis, problem space luas | Tech berubah cepat, problem space sama |
| Cari masalah → bikin solusi dengan tech yang ada | Lihat capability baru → mapping ke masalah existing |
| Competitive advantage: deep user understanding | Competitive advantage: speed to recognize + apply new capability |
| Problem-first natural | Solution-first sering lebih efektif |
Contoh nyata dari Anthropic (Jenny Wen):
- Setiap kali model Claude improve (larger context, better tool use, multi-step reasoning), tim harus figure out: “capability baru ini bisa solve masalah apa?”
- Claude Artifacts: researcher bikin prototype kasar — code yang di-generate jadi interactive panel. Nggak ada problem statement. Tapi saat tim lihat prototype itu, semua langsung ngerti ini powerful. Saat launch, ini fundamentally mengubah cara orang perceive AI.
- Research feature: gabungan capability baru (sub-agents, slow thinking, large context) → memungkinkan Claude bikin full research report dalam 10-20 menit. Solusi ini exist karena tech-nya sampai duluan.
Bukan Berarti Problem Nggak Penting
Solution-first bukan berarti ignore problems. Ini soal urutan:
Problem-first flow: Problem → Research → Solution → Validate
Solution-first flow: Capability/Prototype → “Oh shit, ini bisa solve X!” → Validate → Ship
Di solution-first, problem tetap di-address — cuma ditemukan setelah lihat solusi, bukan sebelumnya. Dan kadang problem yang ditemukan lewat cara ini justru yang nggak pernah muncul dari user research tradisional, karena user nggak bisa articulate need yang mereka belum pernah lihat.
Kapan Pakai Mana
| Situasi | Approach |
|---|---|
| Tech stabil, problem space well-understood | Problem-first |
| New technology/capability muncul | Solution-first |
| Iterasi produk existing | Problem-first (feedback-driven) |
| Explorasi 0→1 di domain baru | Solution-first (prototype-driven) |
| User bisa articulate pain | Problem-first |
| User belum tahu apa yang possible | Solution-first |
Implikasi untuk PM
- Jangan alergi sama “solutioning duluan.” Kalau ada capability baru (AI, API, framework), explore dulu apa yang bisa dibikin. Baru tanya: ini solve masalah siapa?
- Prototype > Problem statement di fase explorasi. Working prototype bikin orang bilang “wow” — problem statement nggak pernah bikin orang bilang wow.
- Setiap model upgrade = opportunity untuk solution-first thinking. Lihat apa yang baru bisa dilakukan, mapping ke customer problems.
- Ini bukan excuse untuk skip validation. Solution-first tetap butuh “does anyone actually need this?” — cuma timing-nya beda.
Key Takeaway
Di era di mana teknologi shift faster than user needs evolve, kemampuan untuk recognize apa yang baru possible dan connect ke real problems jadi lebih valuable dari kemampuan untuk articulate problems dan cari solusi dari toolkit yang sama.