“The #1 failure mode of Shape Up adoption is undershaped work.”
— Ryan Singer, 2025
Buku Shape Up (2019) itu legendaris. Tapi, realitanya? Banyak tim produk yang coba menerapkannya lalu gagal total. Mereka mengikuti buku “mentah-mentah” tanpa tahu bahwa Ryan Singer sendiri sudah mengubah cara mainnya setelah keluar dari Basecamp.
Tulisan ini bukan review buku, melainkan catatan pribadi (dan pengingat buat diri sendiri) tentang evolusi metodologi ini. Poin-poin inilah yang menyelamatkan tim dari jebakan “teori bagus, eksekusi nol”.
Masalah Klasik: “The Sticky Note Problem”
Di buku, alurnya terlihat linear dan indah:
Ide → Shaping → Betting → Build
Tapi di lapangan? Seringkali PM datang dengan ide (hasil coretan sticky note saat rapat), lalu langsung “bertapa” selama 3 hari melakukan Shaping—bikin sketsa UI, mikirin teknis, dsb.
Pas dipresentasikan ke stakeholder, jawabannya menyakitkan:
Lho, sebentar. Masalah itu bukan prioritas kita sekarang.
Dampaknya fatal:
-
Waktu 3 hari terbuang sia-sia.
-
PM stres dan burnout.
-
Tim kehilangan kepercayaan pada proses ini.
Akar masalahnya: Kita sibuk “jualan solusi” sebelum sepakat tentang apa masalah sebenarnya.
Evolusi #1: Gerbang “FRAMING”
Stop Menggambar Solusi Dulu!
Sebelum tangan gatal memegang spidol untuk menggambar UI, ada gerbang baru bernama FRAMING.
Fokus di sini murni Masalah (Problem), bukan Solusi. Lupakan dulu fiturnya. Tanyakan ini:
-
Apa yang sebenarnya rusak?
-
Siapa yang menderita karena ini?
-
Berapa “uang/waktu” (Appetite) yang rela kita bakar untuk membereskan ini?
Output: Cukup 1 halaman dokumen “Frame”.
Goal: Mendapat stempel “Frame Go”.
Artinya: “Oke, masalah ini valid. Silakan cari solusinya (Shaping).” Kalau belum dapat stempel ini, haram hukumnya masuk ke teknis.
Perubahan Flow:
-
❌ 2019: Pitch → Betting Table → Build
-
✅ 2025: Candidate → Frame Go → Shape Go (Package) → Build
Evolusi #2: Mental Model “Menyeberang Sungai”
Ini cara paling ampuh untuk menulis Framing yang tajam. Bayangkan User ada di Tepi A dan ingin ke Tepi B.
1. Sisi Sini (Current Context)
Apa realita pahit yang dialami user sekarang?
-
❌ Salah: “User butuh fitur export PDF.” (Ini solusi, bukan masalah).
-
✅ Benar: “Setiap akhir bulan, Finance Manager harus screenshot 50 halaman manual buat laporan pajak. Butuh 4 jam kerja dan sering human error.”
2. Sisi Sana (Desired Outcome)
Kalau sukses, dunia mereka berubah jadi apa?
- ✅ Benar: “Laporan pajak selesai dalam 5 menit, akurat, tanpa kerja manual.”
3. Jembatan (The Solution)
Di fase Framing, jangan bahas jembatannya dulu.
Pastikan semua stakeholder setuju bahwa “menyeberangkan Finance Manager” itu penting. Kalau mereka bilang “Gak penting, biarin aja dia lembur”, ya sudah. Project batal. Kita hemat waktu shaping.
Evolusi #3: Technical Shaping
Jangan Jadi “Lone Wolf”
Di buku aslinya (2019), Shaping sering digambarkan sebagai aktivitas solo. Kenapa? Karena di Basecamp, orang yang melakukan shaping biasanya punya skill desain sekaligus coding (Unicorn). Mereka bisa validasi teknis di kepala sendiri.
Realita di Tim Lain: Banyak PM non-teknis meniru “kerja sendiri”-nya, tapi melewatkan validasi teknisnya. Akibatnya? Fitur yang terlihat masuk akal di atas kertas, ternyata mustahil dieksekusi di kodingan.
Kita kembali ke buku 2019, Shaping Didefinisikan Sebagai “Private & Creative”. Di buku, Ryan menulis bahwa Shaping adalah antitesis dari “Design by Committee”. Dia menekankan perlunya bekerja dalam isolasi agar ide tidak mentah.
”Shaping is a creative process… It’s primarily design work. The shaped concept is an interaction design. It requires a combination of interface design, technical knowledge, and business strategy.”
Perhatikan syaratnya: Satu orang (Shaper) diharapkan punya 3 skill sekaligus (Desain + Teknis + Bisnis).
Di Basecamp, Ryan Singer punya ketiga skill itu. Di perusahaan lain? Jarang ada PM yang bisa coding sekaligus desain UI.
Aturan Baru: Kecuali kamu menguasai codebase 100% (seperti senior dev), Shaping adalah olahraga tim. Jangan menebak-nebak. Tarik satu Senior Engineer selama 30-60 menit untuk memvalidasi ide liarmu sebelum dibungkus jadi Package.
Fokus Sesi Shaping:
-
Konsep Solusi: Pikirkan blueprint rumah (tembok & kabel listrik), bukan rendering interior 3D.
-
Breadboarding: Visual kasar interaksi. Cuma kotak, teks, dan garis sambungan.
-
Rabbit Holes: Ini bom waktu. Kalau ada ketidakjelasan teknis, selesaikan SEKARANG. Atau putuskan fitur itu Out of Scope (No-Go).
Istilah Baru: “Package”, Bukan “Pitch”
Ini perubahan mindset terbesar.
-
Pitch (Istilah Lama): Kesannya kita sedang membujuk/jualan ide ke atasan.
-
Package (Istilah Baru): Ini adalah instruksi kerja.
Sebuah Package adalah dokumen matang yang siap diserahkan ke tim. Isinya bukan janji manis marketing, tapi batasan teknis, desain kasar, dan solusi masalah. Tim dev tinggal buka “paket” ini dan langsung kerja tanpa bingung.
Demand Side vs. Supply Side
Ryan Singer mengajarkan kita untuk memisahkan mode otak:
| Demand Side (Framing) | Supply Side (Shaping) |
|---|---|
| Fokus: Masalah (Kenapa?) | Fokus: Solusi (Bagaimana?) |
| Aktor: PM & Bisnis | Aktor: PM & Tech Lead |
| Bahasa: Frustrasi user, value | Bahasa: Database, API, UI flow |
Kesalahan Fatal: Mencampur keduanya.
”Kita mau bikin fitur Report (Supply) karena user butuh (Demand).” -> SALAH.
Cara Benar:
-
Kunci Demand-nya dulu: “User butuh data rekap bulanan biar nggak lembur.” -> Deal? Deal.
-
Baru masuk Supply: “Oke, solusinya bisa PDF, Dashboard, atau Email. Mana yang paling efisien?”
Key Takeaways (Catatan Pinggir)
-
Framing First: Jangan buang waktu memikirkan solusi untuk masalah yang belum divalidasi.
-
Technical Shaping: PM bukan dukun. Ajak engineer ngobrol saat merancang solusi.
-
Solve Rabbit Holes: Ketidakjelasan di awal = Kekacauan di akhir.
-
Build Ugly: Di fase building, kejar fungsi dulu, baru estetika (style last).
Shape Up 2025 ini terasa lebih matang, lebih defensif terhadap risiko, dan jauh lebih realistis untuk tim yang bukan “Basecamp”. Intinya: Validasi masalahnya (Framing), baru Paketkan solusinya (Shaping).
Referensi: Ryan Singer, “Framing and Hard Conversations” (BoS Europe 2025) & Shape Up Book.
Spesial shoutout buat Pak Topan dan Bang Jay sudah jadi mentor dan rekan kerja yang sudah banyak membantu saya membedah logika Demand Framing ini. Terima kasih sudah sabar menghadapi saya yang dulu sering buru-buru loncat ke solusi. Tulisan ini adalah bukti bahwa pelajaran kalian nempel!
