Prioritisasi Roadmap: RICE vs Kano vs Opportunity Solution Tree

Saya pernah menyaksikan sebuah tim memberi skor RICE pada diri mereka sendiri hingga menghasilkan setahun penuh fitur yang tidak berguna. Lima belas item, semua diberi peringkat dengan cermat, semua dikirimkan tepat waktu. Aktivasi tidak bergerak. Retensi tidak bergerak. Pendapatan per akun tetap datar. CEO akhirnya mengajukan pertanyaan yang paling ditakuti setiap PM: "Apa yang benar-benar kita pelajari?" Tidak ada yang punya jawaban yang baik, karena framework itu tidak pernah dirancang untuk belajar. Framework itu dirancang untuk membela urutan sebuah daftar.

Itulah masalah framework prioritisasi. Sebagian besar PM menggunakan RICE karena Intercom menulis blognya pada 2017 dan menyebar seperti wabah di setiap organisasi produk yang berlangganan Notion. Kelihatannya ketat. Menghasilkan sebuah angka. Para pemangku kepentingan mengangguk ketika melihat spreadsheet. Tapi framework bukan jawaban untuk masalah roadmap Anda. Framework adalah mekanisme pemaksa untuk percakapan yang dihindari tim Anda. Pilih yang memaksa percakapan yang tepat, dan Anda akan mengirimkan sesuatu yang lebih baik. Pilih yang salah, dan Anda akan mengirimkan banyak hal.

Jadi mari kita bahas tiga framework yang benar-benar akan diminta Anda bela, apa keunggulan masing-masing, di mana masing-masing gagal, dan kapan harus mengombinasikannya.

Matematika RICE dengan angka nyata

RICE adalah singkatan dari Reach, Impact, Confidence, Effort. Formulanya mudah dipahami:

Skor = (Reach x Impact x Confidence) / Effort

• Reach: berapa banyak pengguna yang terdampak dalam periode tertentu. Biasanya per bulan. Jujurlah tentang apa artinya "terdampak."
• Impact: seberapa besar dampaknya terhadap metrik target per pengguna yang terdampak. Rubrik Intercom asli menggunakan 3 / 2 / 1 / 0,5 / 0,25 untuk masif / tinggi / sedang / rendah / minimal. Sengaja dibuat kasar.
• Confidence: dalam persentase. 100% berarti Anda memiliki data. 80% berarti Anda memiliki bukti. 50% berarti Anda menebak.
• Effort: orang-bulan yang dibutuhkan oleh produk, desain, dan teknik secara gabungan.

Sebuah contoh nyata. Bayangkan B2B SaaS dengan 4.000 akun aktif bulanan dan Anda memberi skor tiga kandidat roadmap untuk kuartal berikutnya:

Impor massal menang dengan selisih besar. Dan sejujurnya, dengan skor ini, memang seharusnya begitu. Anda memiliki confidence tinggi, reach yang layak, dan effort rendah. RICE melakukan persis apa yang dirancangnya: memunculkan taruhan murah-dan-efektif yang jelas.

Kapan RICE benar-benar bekerja:

• Produk matang dengan KPI yang jelas. Anda tahu seperti apa aktivasi, retensi, dan konversi. Anda bisa memprediksi dampak dalam kisaran yang wajar.
• Tim besar yang mengirimkan secara paralel. Ketika lima squad perlu mengoordinasikan urutan pengerjaan, rubrik penilaian bersama lebih cepat dari sepuluh rapat.
• Membela pengorbanan kepada eksekutif berorientasi keuangan. CFO bisa membaca tabel RICE. Mereka tidak bisa membaca peta perjalanan pelanggan.

Di mana RICE gagal:

• Produk tahap awal. Reach hanyalah tebakan karena Anda belum tahu audiens sebenarnya. Impact adalah harapan karena Anda belum tahu seperti apa kesuksesan itu.
• Taruhan tahap discovery. RICE menghukum ketidakpastian melalui pengali Confidence, yang berarti hal-hal yang benar-benar baru selalu kalah dari hal-hal yang inkremental. Roadmap Anda penuh dengan fitur impor massal dan tidak pernah berisi taruhan yang benar-benar bisa mengubah arah.
• Taruhan strategis. "Haruskah kita ekspansi ke mid-market?" tidak cocok dalam tabel RICE. Jangan mencoba.

Kritik yang jujur: RICE mengoptimalkan untuk apa yang bisa diukur, bukan untuk apa yang penting. Gunakan di mana pengukuran mudah, abaikan di mana tidak.

Model Kano dengan pertanyaan survei yang benar-benar efektif

Model Kano lebih tua dan lebih tidak biasa dari RICE. Noriaki Kano membangunnya pada 1980-an untuk menjelaskan mengapa beberapa fitur dicintai pelanggan dan beberapa hampir tidak diperhatikan. Ada lima kategori, tapi Anda hanya perlu tiga untuk prioritisasi:

• Dasar (Wajib ada): pelanggan tidak memperhatikan saat fitur ada, mereka marah saat tidak ada. Autentikasi dua faktor. Ekspor ke CSV. Pencarian yang layak. Membangun ini tidak membuat mereka mencintai Anda. Melewatkannya membuat mereka pergi.
• Performa (Lebih banyak lebih baik): kepuasan yang linier. Pemuatan halaman lebih cepat, lebih banyak integrasi, uptime lebih baik. Layak diinvestasikan secara proporsional dengan biayanya.
• Kegembiraan (Pemberi kejutan menyenangkan): pelanggan tidak mengharapkannya, tidak bisa memintanya, tapi mencintainya saat mendapatkannya. Hal yang membuat demo berhasil ditutup. Thread Slack, pintasan keyboard Linear, kursor multiplayer Figma saat pertama kali diluncurkan.

Dua kategori lainnya (Tidak Peduli dan Sebaliknya) adalah tempat Anda memangkas fitur. Tidak Peduli berarti tidak ada yang peduli. Sebaliknya berarti sebagian orang secara aktif tidak menyukainya (bayangkan saran AI yang agresif dalam alat produktivitas yang tenang).

Inilah template pertanyaan survei yang benar-benar saya gunakan, dua pertanyaan per fitur:

1. Bagaimana perasaan Anda jika produk memiliki fitur ini?
2. Bagaimana perasaan Anda jika produk tidak memiliki fitur ini?

Keduanya dijawab pada skala 5 poin: Saya suka / Saya mengharapkannya / Saya netral / Saya bisa menerimanya / Saya tidak suka.

Tabulasi silangnya memberi tahu Anda kategorinya. "Suka / tidak suka kalau tidak ada" = Performa. "Netral / tidak suka kalau tidak ada" = Dasar. "Suka / netral kalau tidak ada" = Kegembiraan. Jalankan ini pada 50-100 pelanggan per segmen dan Anda memiliki sinyal yang layak untuk dibela.

Kapan Kano menang:

• Keputusan paritas fitur. "Pesaing X baru saja meluncurkan Y. Apakah kita perlu itu?" Kano memberi tahu Anda apakah Y adalah Dasar (ya, kirimkan sekarang), Performa (ya, tapi sesuai jadwal), atau Kegembiraan (hanya jika membedakan kita).
• Memangkas ruang lingkup. Ketika teknik memberi tahu Anda spesifikasi butuh enam minggu sementara Anda hanya punya empat, Kano memberi tahu Anda apa yang harus dihilangkan. Pangkas Kegembiraan terlebih dahulu jika Dasar belum selesai.
• Keputusan "haruskah kita membangun ini sama sekali?" Jika sebuah fitur mendapat skor Tidak Peduli, data memberi tahu Anda untuk tidak melanjutkan.

Jebakannya: Kano membutuhkan data pelanggan nyata, bukan intuisi PM. Saya pernah melihat roadmap penuh yang dibenarkan oleh analisis Kano yang sebenarnya hanya tiga orang dalam ruang konferensi yang berdebat tentang kolom mana untuk menempatkan penghapusan massal. Itu bukan Kano. Itu PM yang meminjam nama framework untuk melegitimasi pendapat pribadi.

Opportunity Solution Tree, kapan ia menang

Teresa Torres membangun Opportunity Solution Tree (OST) untuk tim yang melakukan discovery berkelanjutan. Strukturnya:

                  Hasil
                     |
       -----------------------------
       |             |             |
  Peluang       Peluang        Peluang
       |             |             |
   ---------     ---------     ---------
   |       |     |       |     |       |
 Solusi  Solusi Solusi  ...  Solusi
   |
Eksperimen

Anda mulai dengan satu Hasil (hasil bisnis yang terukur, seperti "tingkatkan konversi uji coba ke berbayar sebesar 15%"). Anda memetakan Peluang (titik nyeri pelanggan, kebutuhan yang belum terpenuhi, momen gesekan) yang dikumpulkan dari wawancara pelanggan mingguan. Di bawah setiap peluang Anda melakukan brainstorming beberapa Solusi. Di bawah setiap solusi yang menjanjikan, Anda merancang Eksperimen untuk memvalidasi sebelum membangun.

Keunggulannya adalah framework ini memaksa hierarki. Anda tidak bisa memprioritaskan solusi melawan solusi. Anda hanya bisa memprioritaskan peluang, lalu memilih solusi terbaik untuk peluang yang dipilih.

Kapan OST menang:

• Tim dengan discovery berkelanjutan. Tim yang menjalankan touchpoint pelanggan mingguan dan melakukan pengujian prototipe. Pohon diperbarui seiring discovery menemukan peluang baru.
• Organisasi berbasis hasil. Di mana kepemimpinan menetapkan tujuan sebagai hasil, bukan daftar fitur. OST menerjemahkan hasil ke dalam pipeline discovery-dan-bangun.
• Menghindari mode pabrik fitur. Gebrakan OST adalah membuat terlihat ketika solusi tidak terhubung ke peluang yang terhubung ke hasil. Jika tidak terhubung, jangan bangun.

Di mana OST gagal:

• Organisasi di mana "discovery" berarti satu wawancara pengguna per kuartal. OST adalah sistem operasi discovery berkelanjutan. Tanpa ritme discovery, pohonnya hanya dekorasi. Anda akan mengisinya dengan peluang yang Anda asumsikan, bukan yang Anda temukan.
• Tim tanpa akses riset. Jika PM Anda harus berjuang untuk mendapatkan lima panggilan pelanggan per bulan, OST adalah aspirasi, bukan operasional.
• Kuartal eksekusi penuh. Terkadang Anda harus mengirimkan hal yang memblokir pembaruan kontrak. OST tidak akan membantu Anda mengurutkan delapan fitur yang sudah diketahui.

"Sekarang, berikutnya, nanti" dan mengapa itu RICE berkedok

Sebagian besar roadmap "sekarang/berikutnya/nanti" hanyalah peringkat RICE dengan angka yang disembunyikan. PM memberi skor semuanya, bagian atas daftar masuk Sekarang, tengah ke Berikutnya, bawah ke Nanti. Formatnya berpura-pura fleksibel tapi prioritisasinya identik dengan spreadsheet yang sudah diurutkan.

Format ini benar-benar bermakna ketika setiap kategori memiliki standar epistemik yang berbeda:

• Sekarang: confidence tinggi, sudah dibatasi ruang lingkupnya, sudah berkomitmen. Anda akan mengirimkan ini. Tim memiliki hasilnya.
• Berikutnya: confidence sedang, masalah sudah divalidasi, solusi masih dalam discovery. Anda percaya ini penting. Anda belum membuktikan solusinya berhasil.
• Nanti: peluang, bukan solusi. Hal-hal yang Anda dengar dari pelanggan yang belum mendapat slot.

Jika kategori "Nanti" Anda berisi nama fitur dengan estimasi effort, Anda sedang melakukan RICE berkedok. Jika kategori "Nanti" berisi masalah pelanggan dengan pertanyaan terbuka, Anda melakukannya dengan benar.

Confidence, input yang tidak pernah dinilai dengan jujur

Setiap PM yang pernah saya temui menggelembungkan confidence untuk fitur favorit mereka. Orang yang membangun kolom confidence dalam framework berharap itu menjadi alat kalibrasi, menyaksikannya berubah menjadi kolom perasaan subjektif.

Solusinya: rubrik confidence yang terikat pada bukti, bukan perasaan.

Apa pun di bawah 60% tidak seharusnya berada di kolom Sekarang Anda dalam framework mana pun. Apa pun di bawah 40% seharusnya menjadi Peluang dalam OST Anda, bukan fitur dalam roadmap. Jika Anda tidak bisa mencapai confidence 60% pada sesuatu yang sudah ada di roadmap selama dua kuartal, hapuslah. Biaya meninggalkannya di sana adalah ilusi kemajuan tanpa kemajuan yang sebenarnya.

Mengapa pemangku kepentingan Anda membenci RICE

Inilah percakapan diagnostik yang selalu saya lakukan dengan setiap tim yang berkata "RICE tidak berhasil untuk kami." Hampir tidak pernah masalahnya pada frameworknya. Masalahnya pada lapisan terjemahan.

Penjualan membenci RICE karena permintaan pelanggan mendapat skor Reach yang rendah. Penjualan membawa kepada Anda permintaan yang memblokir kesepakatan dari prospek yang membayar $80K. Reach untuk pelanggan itu adalah satu. Skor RICE-nya pecahan. Penjualan membacanya sebagai "PM tidak peduli dengan pendapatan." Terjemahan: keluarkan permintaan pemblokir kesepakatan dari RICE sepenuhnya. Kelola jalur terpisah "pemblokir kesepakatan" yang disesuaikan dengan dampak tingkat kemenangan Anda. Beritahu penjualan bahwa jalur itu ada.

CS membenci RICE karena taruhan retensi mendapat skor Impact yang rendah. Fitur retensi jarang menunjukkan pergerakan metrik jangka pendek. Mereka mencegah churn yang akan terjadi enam bulan ke depan. RICE Impact bersifat ke depan, tapi kebanyakan PM menilainya sebagai pergerakan kuartal-ke-kuartal. Terjemahan: pisahkan taruhan retensi dan nilai Impact sebagai pergerakan tingkat churn tahunan, bukan aktivasi kuartalan.

Teknik membenci RICE karena Effort adalah tebakan Anda, bukan mereka. PM memperkirakan effort berdasarkan fitur serupa di masa lalu. Teknik tahu bahwa codebase memiliki tiga hambatan tersembunyi. Terjemahan: jangan pernah mempublikasikan skor RICE dengan angka effort milik Anda sendiri. Gunakan rentang (1-2 PM-bulan, 3-5 PM-bulan, 6+) dan biarkan teknik mempersempitnya setelah proses pembatasan ruang lingkup singkat. PM memiliki Reach, Impact, Confidence. Teknik memiliki Effort.

Polanya: RICE menghasilkan satu angka, tapi empat input berasal dari empat pemangku kepentingan yang berbeda. Ketika Anda mempublikasikan satu skor tanpa menunjukkan cara Anda menghitungnya, setiap pemangku kepentingan membaca input yang mereka pedulikan dan tidak setuju dengannya. Tunjukkan inputnya. Diskusikan Reach dengan marketing, Impact dengan tim data, Confidence dengan riset, Effort dengan teknik. Skor adalah keluaran dari empat percakapan itu, bukan pengganti bagi mereka.

Kapan mengombinasikan ketiganya

Inilah tumpukan yang benar-benar saya jalankan:

1. Gunakan OST untuk menemukan peluang yang tepat. Petakan hasil ke peluang pelanggan melalui discovery berkelanjutan. Pilih peluang yang memiliki bukti paling kuat dan potensi dampak hasil tertinggi. Lewati lapisan ini jika Anda sudah tahu masalahnya dengan sangat baik (fitur matang, domain yang sudah dipahami dengan baik). Jangan lewati jika tim Anda mengirimkan fitur yang tidak diminta siapa pun.

2. Gunakan Kano untuk mengklasifikasikan solusi. Setelah Anda memilih peluang dan memiliki dua atau tiga kandidat solusi, jalankan Kano pada kandidat tersebut dengan data pelanggan nyata. Lewati lapisan ini jika solusinya jelas bersifat Dasar (autentikasi, ekspor, aksesibilitas). Jangan lewati jika Anda memilih antara "membuat fitur yang ada lebih cepat" dan "menambahkan momen kegembiraan" dan Anda tidak bisa memutuskan mana yang benar-benar dihargai pelanggan.

3. Gunakan RICE untuk mengurutkan pembangunan. Setelah Anda memilih peluang dan solusi yang akan dibangun, RICE mengurutkannya dalam kuartal. Effort, ketergantungan, kapasitas. RICE adalah alat pengurutan, bukan alat discovery. Di situlah ia membuktikan nilainya.

Tumpukan penuh ini berlebihan untuk sebagian besar tim di sebagian besar waktu. Tim yang mengirimkan peningkatan inkremental ke CRM yang matang tidak memerlukan OST setiap kuartal, mereka memerlukan RICE pada backlog yang bersih. Startup sebelum kecocokan produk-pasar tidak memerlukan RICE, mereka memerlukan OST dan kesediaan untuk membuang setengah roadmap. Sesuaikan kedalaman framework dengan situasi epistemik yang sebenarnya. Memaksakan OST pada tim tanpa akses riset adalah pertunjukan belaka. Memaksakan RICE pada tim yang tidak tahu KPI-nya adalah presisi tanpa akurasi.

Framework bukan jawabannya. Pilih yang memaksa percakapan yang dihindari tim Anda. Jika tim Anda menghindari kontak pelanggan, jalankan OST. Jika tim Anda menghindari pemangkasan ruang lingkup, jalankan Kano. Jika tim Anda menghindari pengorbanan pengurutan, jalankan RICE. Dan jika tim Anda menghindari ketiganya, masalahnya bukan pada frameworknya. Masalahnya adalah tidak ada yang ingin membuat keputusan nyata, dan tidak ada spreadsheet yang akan memperbaiki itu.

Pelajari Lebih Lanjut

• Deskripsi Jabatan PM (pendamping)
• Kebiasaan Discovery Berkelanjutan untuk PM
• Menulis PRD yang Tidak Dibenci Insinyur
• Perencanaan Kuartalan dengan Teknik dan Desain