19 Mei 2026 5 menit baca Product Management
Mutation-Driven Framing untuk PM
Stakeholder request datang, PM tanya kenapa, langsung shaping. Enam minggu kemudian baru sadar yang dibangun bukan jawaban. Ada cara lebih murah ketauan salahnya.
Kemarin di meeting roadmap, sales lead saya bilang satu kalimat yang sudah saya dengar puluhan kali: “User butuh dashboard analytics.”
Saya tanya, “Kenapa?”
Dia jawab, “Biar mereka bisa lihat data sendiri, gak nanya ke admin terus.”
Sebelum saya sempat lompat ke shaping mode—mikirin layout, chart library, query plan—saya nahan diri. Saya tau pola ini ujungnya ke mana: enam minggu kemudian dashboard live, kita rayain di Slack, tiga bulan kemudian engagement-nya 4%. Bukan karena dashboard-nya jelek. Karena yang user butuhin bukan dashboard.
Masalahnya bukan PM malas bertanya. Masalahnya gak ada toolkit sistematis untuk mengeksplorasi ruang masalah. “Kenapa” doang gak cukup—itu satu sumbu dari banyak sumbu yang bisa dipakai.
Framing yang Terlalu Cepat Konvergen
Ryan Singer di Shape Up ngajarin satu hal yang sering di-skip orang: Framing harus selesai sebelum Shaping. Kamu harus jelas dulu “sisi sini” dan “sisi sana” dari sungai sebelum mulai mikirin jembatan.
Tapi di lapangan, kebanyakan PM langsung konvergen ke definisi pertama yang masuk:
Stakeholder: "User butuh dashboard analytics"
PM: "Oke, masalahnya user gak bisa lihat data?"
Stakeholder: "Ya"
PM: *langsung shaping dashboard*Yang barusan kejadian itu bukan framing. Itu transkripsi. PM jadi notulen solusi yang sudah dibawa stakeholder, bukan partner yang bantu jelasin masalahnya.
Akibatnya predictable: build the wrong thing dengan eksekusi rapi. Yang mahal bukan kesalahan teknisnya—itu gampang di-revert. Yang mahal: enam minggu engineer time, dua siklus QA, satu Slack thread berdebat warna chart, ujung-ujungnya fitur gak dipake.
Pinjem 9 Pola Mutasi dari Tachikawa
Eisuke Tachikawa dari NOSIGNER nge-catalog 9 pola mutasi yang bisa menjelaskan hampir semua inovasi: Disappear, Reverse, Substitute, Separate, Integrate, Transit, Assimilate, Variate, Proliferate. Pola ini biasanya dipakai untuk generate solusi.
Yang menarik: pola yang sama jalan juga buat eksplorasi masalah.
Daripada nanya “kenapa” berulang-ulang sampai stakeholder bête, paksa diri ngeliat request dari 9 sudut berbeda dulu. Gak semua harus dipake—tapi minimal kamu udah ngecek apakah definisi pertama itu paling fundamental, atau cuma yang paling cepat keluar dari mulut.
Saya gak akan bikin listicle dari 9-nya. Mendingan saya tunjukin 3 yang paling sering nyelametin saya di Founderplus.
Disappear — “Kalau Fitur Ini Dihilangin, Apa yang Tetap Rusak?”
Kembali ke request dashboard tadi. Kalau saya jawab pakai Disappear:
“Kalau dashboard ini gak pernah dibangun, apa yang gagal di hidup sales lead?”
Jawabannya bukan “dia gak bisa lihat angka”. Jawabannya: “keputusan rebooking pelanggan jadi lambat karena dia harus ping admin tiap pagi, dan admin baru balas siang.”
Definisi masalahnya berubah total. Bukan akses ke data, tapi information latency dalam decision making. Solusinya bisa jadi bukan dashboard—bisa jadi push notification ke WhatsApp tiap jam 8 pagi dengan 3 angka kritis. Dua hari coding, bukan enam minggu.
Disappear berguna ketika request terasa “nice to have”. Kalau dihilangin dan gak ada yang bener-bener rusak, mungkin masalahnya gak ada—stakeholder cuma lagi excited sama tool yang dia lihat di LinkedIn.
Separate — “Kalau Ini Dipisahin, Akan Lebih Jelas Gak?”
Ini favorit saya. Baru-baru ini nyelametin satu proyek yang kalau di-rewrite total bisa nelan dua quarter.
Request awal: “Landing page kita loading lambat, harus dirombak.”
Kalau saya nurut, hasilnya: rewrite SPA jadi SSR, delapan minggu, satu engineer full-time. Tapi saya jalanin Separate dulu:
“Sebentar—landing page (public, anonymous, SEO-critical) dan app (authenticated, transactional) selama ini satu codebase. Kalau dipisah, masalahnya beda gak?”
Ternyata beda jauh. Landing page butuh First Contentful Paint cepat, SEO crawlability, bundle kecil. App butuh state management, real-time sync, interactivity. Satu arsitektur, dua use case yang requirements-nya bertolak belakang.
Solusinya bukan rewrite—pisahin domain. Landing page pindah ke Astro static, app tetap React. Tiga minggu, bukan delapan.
Separate jago kalau kamu curiga satu sistem lagi melayani dua master sekaligus. Biasanya iya, dan biasanya nobody noticed karena udah lama begitu.
Integrate — “Kalau Dua Hal Ini Digabungin, Tool-nya Hilang?”
Pernah ada request: “Tim sales butuh CRM yang lebih bagus, fitur-fiturnya kurang.”
Tipikal PM bakal mulai benchmarking—Hubspot vs Pipedrive vs custom build. Saya lempar Integrate dulu:
“Sales selama ini kerja pakai apa? Oh, WhatsApp 90% waktunya. CRM cuma dibuka pas weekly review. Kalau CRM overlay di atas WhatsApp—context-nya nyatu—gimana?”
Itu yang jadi project Sales Overlay. Masalahnya bukan CRM yang fiturnya kurang. Masalahnya context switching—tim sales pindah aplikasi puluhan kali sehari, dan setiap pindah, separuh konteks hilang.
Integrate berguna kalau user workflow melibatkan terlalu banyak tool. Yang user pengen sebenernya bukan tool yang lebih bagus—mereka pengen tool-nya hilang, kerjaannya tetep beres.
Cara Pake-nya: Mutation-Driven Framing Session
Kalau kamu mau coba, ini alurnya yang udah saya rapihin jadi reps mingguan:
| Step | Yang dilakuin | Output |
|---|---|---|
| 1 | Tulis request mentah dari stakeholder. Apa adanya, no filter. | Initial Frame (1 kalimat) |
| 2 | Pilih 3-5 mutation pattern yang paling relevan. Paksa diri generate minimal 1 reframe per pola. | 3-5 alternative frames |
| 3 | Cluster reframe yang muncul. Mana yang paling fundamental? Mana yang ekor dari yang lain? | Ranked list |
| 4 | Balik ke stakeholder: “Saya lihat ini bisa di-frame jadi A, B, atau C. Mana yang paling kena?” | Locked frame |
| 5 | Baru masuk Shaping. Solution space terbuka. | Pitch |
Penting di step 4: bawa definisi masalah alternatif, bukan solusi alternatif. Beda banget. Stakeholder yang dikasih 3 solusi bakal pilih yang paling kelihatan keren. Stakeholder yang dikasih 3 definisi masalah mikir lebih dalam tentang apa yang sebenernya mereka cari.
Kenapa Reps Ini Worth It
Ada empat alasan saya invest waktu di pola ini, tiga di antaranya baru jelas setelah setahun pake.
Defensible. Pas stakeholder push back—“kenapa gak langsung build aja”—ada paper trail. “Saya udah explore dari tujuh sudut, yang paling kena adalah ini.” Bukan opini, ada jejak.
Cross-functional. Pola mutasi itu bahasa universal. Engineer, designer, business semua bisa ikut session. Gak ada yang merasa “ini bukan domain gue”. Beda kalau pake framework PM-specific—engineer langsung zone out.
Murah ketauannya kalau salah. Iterasi di level frame harganya satu meeting. Iterasi di level build harganya satu cycle. Saya prefer salah di meeting.
Junior bisa outperform senior yang andalin feeling. Framework sistematis menutup kesenjangan pengalaman. Junior PM dengan toolkit ini bisa kasih reframe yang senior dengan 10 tahun jam terbang gak kepikiran—karena senior-nya udah terlalu lama autopilot.
Meta: Ini Latticework, Bukan Single Framework
Yang sebenernya jalan di sini bukan Shape Up sendirian, bukan 9 Mutation sendirian. Yang jalan adalah kombinasi. Shape Up bilang “frame dulu sebelum shaping”, tapi gak ngajarin cara framing yang baik. 9 Mutation Patterns dari design thinking ngisi gap itu. Latticework-nya Munger kalau dipraktekin di product.
Setiap framework punya blind spot. Yang nutupin blind spot framework satu, biasanya framework dari domain lain. Itu kenapa orang yang cuma baca buku PM bakal selalu kalah sama orang yang baca buku PM plus desain plus filsafat sains—lebih banyak sudut untuk lihat masalah yang sama.
Framing yang baik bukan nanya kenapa lebih banyak. Framing yang baik nanya yang beda.