Inget banget waktu itu sprint 3 bulan buat fitur yang cuma dipake 2%. Rasanya kayak sia-sia banget. PM bilang ini bakal jadi game-changer, tapi ternyata... ya gitu deh. Feature itu sekarang cuma jadi dead code yang bikin codebase makin bloated.
Terus baca buku ini. Baru sadar kenapa itu bisa kejadian.
Build-Measure-Learn (atau sebenarnya Learn-Measure-Build)
Jadi yang menarik itu konsepnya dibalik sebenarnya. Mulainya dari learning goal, bukan dari "kita mau bikin apa".
Yang biasa terjadi:
- "Kita bikin payment multi-channel karena kompetitor punya"
- "Kita tambahin AI karena lagi tren"
Yang seharusnya:
- "Hipotesis: user drop karena payment option terbatas. Target: conversion naik 15% kalau tambah e-wallet"
- "Hipotesis: 70% user browsing tapi ga beli. Kalau ada recommendation, purchase rate naik ga?"
Bedanya subtle tapi penting. Jadi bukan sekadar "bikin fitur" tapi "validasi asumsi".
MVP ≠ Produk Setengah Jadi
Salah pemahaman paling sering nih. MVP bukan berarti boleh kode jelek, boleh UX ancur.
MVP itu: hal terkecil yang bisa validasi hipotesis.
Contoh favorite: Dropbox video demo. Cuma video 3 menit. Ga ada kode production sama sekali. Tapi validasi demand - 75k orang daftar waiting list overnight.
Atau Gojek early days - fokus ojek booking aja dulu. Baru ekspansi ke Go-Food dll setelah demand jelas.
Bayangin kalau Gojek dari awal bikin super app lengkap 20 services. Probably kehabisan dana sebelum nemuin product-market fit.
Vanity Metrics vs Actionable Metrics
Ini yang sering kelewat. Ada metrics yang cuma bikin kita merasa bagus, tapi sebenernya ga ngasih insight.
Vanity:
- "500k registered users!" (berapa yang aktif?)
- "Traffic naik 300%!" (conversion rate gimana?)
- "100k downloads!" (retention berapa?)
Actionable:
- DAU/MAU ratio
- Week 1 retention
- Time to first value
- LTV vs CAC
Inget ada startup yang obsessed sama total signup. CEO bangga banget show grafik exponential. Tapi pas diliat dalam:
- 90% user ga balik setelah first session
- Conversion <1%
- Churn rate > acquisition rate
Eventually collapse.
Karena ngukur hal yang salah.
Pivot or Persevere
Ini yang paling susah secara emosional.
Udah spend berbulan-bulan, passionate sama vision, team sacrifice banyak. Terus data bilang: not working.
Ego: "Gue udah bilang dari awal ini bakal work!"
Sunk cost: "Udah invest terlalu banyak!"
Fear: "Nanti orang mikir gue ga punya conviction"
Tapi yang lebih susah dari pivot: dying slowly karena ga mau pivot.
Red flags kapan harus consider pivot:
- Growth menurun meski effort naik
- Churn rate tinggi terus
- Low engagement - signup tapi ga pake
- Susah jelasin value prop
- Selalu bilang "if only..." - itu excuse, bukan alasan
Personal experience:
Pernah involved internal tool project. Vision: comprehensive platform handle everything - code review, deployment, monitoring, incident management.
Ambitious. Tapi unrealistic.
6 bulan kemudian usage 12%. Majority dev masih prefer existing tools. Feedback: "Too complicated".
Hard truth: we built wrong thing.
Decision: pivot. Zoom-in ke deployment automation aja, yang punya satisfaction score paling tinggi.
Result: usage jump ke 67% dalam 2 bulan.
Lesson: sometimes need to think smaller to win bigger.
Aplikasi di Indonesia
Not everything dari buku ini langsung applicable. Context matters.
Yang works well:
- MVP mindset crucial - kita resource terbatas, harus efficient
- Local validation non-negotiable - user behavior beda dari US
- Rapid iteration match sama market dynamics yang cepat berubah
Yang challenging:
- "Move fast break things" vs risk-averse culture
- Data infrastructure - banyak company belum punya analytics proper
- "Failure is learning" vs "failure is shameful" - cultural barrier
Dark side: when Lean becomes excuse
Harus jujur - Lean Startup bisa disalahgunakan.
"We're being lean!" jadi excuse untuk:
- Poor code quality - "ini cuma MVP kok!"
- Bad UX - "testing value prop dulu!"
- Lack of vision - "pivot every 2 weeks based on data!"
- Ignoring fundamentals - "fokus growth dulu, unit economics belakangan!"
Ini salah semua.
Technical debt dari "lean MVP" will haunt you. UX IS PART OF value prop. Data should inform, not dictate. Growth tanpa fundamentals = unsustainable.
How to actually do this
Before writing code, tanya:
- Hipotesis apa yang mau di-test?
- Smallest version yang bisa test ini?
- Metrics apa yang prove/disprove?
- Success criteria?
Build with feature flags
Deploy production tapi control siapa yang liat. Test sama subset dulu.
Instrument everything
Add tracking dari day one. Ga bisa measure kalau ga track.
Make rollback easy
Kalau fail, harus bisa rollback cepat. Invest in CI/CD.
Beyond building products
Konsep ini applicable beyond work:
Waktu mau belajar new tech stack - build small project dulu (MVP) sebelum commit to complete course. Validasi apakah actually interested.
Consider career move - do small experiment (freelance, side gig) dulu sebelum full jump. Test fit.
Start new habit - test dengan smallest commitment (5 min daily) sebelum scale up.
Build-Measure-Learn bukan cuma framework untuk produk. It's a framework for decision making under uncertainty.
Bottom line
Buku ini changed how I think about building products.
Core insight: Don't assume. Test. Learn. Iterate.
Simple tapi powerful.
Wish I read this sebelum spend 3 bulan untuk feature 2% adoption rate. But better late than never.
Stop assuming. Start validating.