Keutamaan Roadmap: RICE vs Kano vs Opportunity Solution Tree

Saya pernah menyaksikan pasukan yang menjatuhkan markah RICE kepada diri mereka sendiri selama setahun penuh dengan ciri-ciri yang tidak berkesan. Lima belas item, semuanya disusun dengan teliti, semuanya dihantar tepat pada jadual. Pengaktifan tidak bergerak. Pengekalan tidak bergerak. Hasil per akaun kekal datar. CEO akhirnya bertanya soalan yang ditakuti setiap PM: "Apa yang kita pelajari sebenarnya?" Tiada siapa yang mempunyai jawapan yang baik, kerana rangka kerja itu tidak pernah tentang pembelajaran. Ia tentang mempertahankan urutan sebuah senarai.

Itulah hakikat tentang rangka kerja keutamaan. Kebanyakan PM menggunakan RICE kerana Intercom menulis mengenainya pada 2017 dan ia tersebar seperti virus melalui setiap organisasi produk yang mempunyai langganan Notion. Ia kelihatan teliti. Ia menghasilkan nombor. Pihak berkepentingan mengangguk apabila melihat hamparan. Tetapi rangka kerja itu bukan jawapan kepada masalah roadmap anda. Rangka kerja itu adalah fungsi memaksa untuk perbualan yang pasukan anda elakkan. Pilih yang memaksa perbualan yang betul, dan anda akan menghantar yang lebih baik. Pilih yang salah, dan anda akan menghantar banyak.

Jadi mari kita bincangkan tiga yang sebenarnya akan anda diminta pertahankan, apa yang setiap satu mahir, di mana setiap satu gagal, dan bila anda harus menggabungkannya.

Matematik RICE, dengan angka sebenar

RICE bermaksud Reach (Jangkauan), Impact (Impak), Confidence (Keyakinan), Effort (Usaha). Formulanya mudah:

Markah = (Jangkauan x Impak x Keyakinan) / Usaha

• Jangkauan: berapa ramai pengguna yang terjejas dalam tempoh tertentu. Biasanya bulanan. Jujurlah tentang maksud "terjejas."
• Impak: seberapa besar ia menggerakkan metrik sasaran anda per pengguna yang terjejas. Rubrik Intercom asal menggunakan 3 / 2 / 1 / 0.5 / 0.25 untuk besar / tinggi / sederhana / rendah / minimum. Ia kasar dengan sengaja.
• Keyakinan: peratusan. 100% bermakna anda mempunyai data. 80% bermakna anda mempunyai bukti. 50% bermakna anda meneka.
• Usaha: orang-bulan merentasi produk, reka bentuk, dan kejuruteraan digabungkan.

Contoh sebenar. Bayangkan SaaS B2B dengan 4,000 akaun aktif bulanan dan anda mencetak tiga calon roadmap untuk suku tahun hadapan:

Import pukal menang dengan margin yang besar. Dan sejujurnya, pada pemarkahan ini, ia patut menang. Anda mempunyai keyakinan tinggi, jangkauan yang baik, dan usaha yang rendah. RICE melakukan tepat apa yang ia dibina untuk lakukan: memunculkan pertaruhan murah-dan-berkesan yang jelas.

Bila RICE benar-benar berfungsi:

• Produk matang dengan KPI yang jelas. Anda tahu seperti apa pengaktifan, pengekalan, dan penukaran. Anda boleh meramalkan impak dalam julat yang munasabah.
• Pasukan besar yang menghantar secara selari. Apabila lima pasukan perlu menyelaraskan urutan, rubrik pemarkahan bersama lebih pantas daripada sepuluh mesyuarat.
• Mempertahankan pertukaran kepada eksekutif yang berorientasikan kewangan. CFO boleh membaca jadual RICE. Mereka tidak boleh membaca peta perjalanan pelanggan.

Di mana RICE gagal:

• Produk awal. Jangkauan adalah tekaan kerana anda belum tahu audiens sebenar anda lagi. Impak adalah angan-angan kerana anda tidak tahu seperti apa kejayaan.
• Pertaruhan peringkat penerokaan. RICE menghukum ketidakpastian melalui pengganda Keyakinan, yang bermakna apa sahaja yang benar-benar baru dihancurkan oleh apa sahaja yang bertambah baik. Roadmap anda dipenuhi dengan ciri import pukal dan tidak pernah dengan pertaruhan yang boleh mengubah trajektori.
• Pertaruhan strategik. "Adakah kita patut berkembang ke pertengahan pasaran?" tidak sesuai pada jadual RICE. Jangan cuba.

Kritikan yang jujur: RICE mengoptimumkan untuk apa yang boleh anda ukur, bukan untuk apa yang penting. Gunakannya di mana pengukuran mudah, abaikannya di mana ia tidak.

Model Kano, dengan soalan tinjauan yang benar-benar berfungsi

Model Kano lebih lama dan lebih luar biasa daripada RICE. Noriaki Kano membinanya pada 1980-an untuk menjelaskan mengapa pelanggan menyukai sesetengah ciri dan hampir tidak menyedari yang lain. Terdapat lima kategori, tetapi anda hanya memerlukan tiga untuk keutamaan:

• Asas (Mesti ada): pelanggan tidak menyedarinya apabila ia ada, mereka marah apabila ia hilang. Pengesahan dua faktor. Eksport ke CSV. Carian yang baik. Membina perkara ini tidak menjadikan mereka menyukai anda. Melangkaunya menjadikan mereka pergi.
• Prestasi (Lebih adalah lebih baik): kepuasan linear. Masa muatan halaman yang lebih pantas, lebih banyak integrasi, masa operasi yang lebih baik. Patut dilabur secara berkadar dengan kos.
• Keseronokan (Ciri yang menyeronokkan): pelanggan tidak menjangkanya, tidak boleh memintanya, tetapi menyukainya apabila mereka mendapatnya. Perkara yang membuat demo itu ditutup. Benang Slack, pintasan papan kekunci Linear, kursor berbilang pemain Figma apabila ia dilancarkan.

Dua kategori lain (Tidak peduli dan Terbalik) adalah tempat anda memotong ciri. Tidak peduli bermakna tiada siapa yang peduli. Terbalik bermakna sesetengah orang secara aktif tidak menyukainya (fikirkan cadangan AI yang agresif dalam alat produktiviti yang tenang).

Berikut adalah templat soalan tinjauan yang saya gunakan sebenarnya, dua soalan setiap ciri:

1. Bagaimana perasaan anda jika produk mempunyai ciri ini?
2. Bagaimana perasaan anda jika produk tidak mempunyai ciri ini?

Kedua-duanya dijawab pada skala 5 titik: Saya suka / Saya jangkakan / Saya neutral / Saya boleh terima / Saya tidak suka.

Jadual silang memberitahu anda kategorinya. "Suka / tidak suka tidak ada" = Prestasi. "Neutral / tidak suka tidak ada" = Asas. "Suka / neutral tentang tidak ada" = Keseronokan. Jalankan ini pada 50-100 pelanggan per segmen dan anda mempunyai isyarat yang patut dipertahankan.

Bila Kano menang:

• Keputusan pariti ciri. "Pesaing X baru sahaja menghantar Y. Adakah kita memerlukannya?" Kano memberitahu anda sama ada Y adalah Asas (ya, hantarkan sekarang), Prestasi (ya, tetapi mengikut jadual), atau Keseronokan (hanya jika ia membezakan).
• Memotong skop. Apabila eng memberitahu anda spesifikasi itu enam minggu dan anda mempunyai empat, Kano memberitahu anda apa yang perlu digugurkan. Potong Keseronokan dahulu jika Asas belum siap.
• Panggilan "Adakah kita perlu membinanya langsung?" Jika ciri itu mendapat markah Tidak peduli, data memberitahu anda untuk pergi.

Perangkap: Kano memerlukan data pelanggan yang sebenar, bukan andaian naluri PM. Saya pernah melihat keseluruhan roadmap dibenarkan oleh analisis Kano yang terdiri daripada tiga orang dalam bilik persidangan yang berdebat tentang lajur mana untuk meletakkan penghapusan pukal. Itu bukan Kano. Itu PM yang melaunder pendapat melalui nama rangka kerja.

Opportunity Solution Tree, bila ia menang

Teresa Torres membina Opportunity Solution Tree (OST) untuk pasukan yang melakukan penerokaan berterusan. Strukturnya:

                  Hasil
                     |
       -----------------------------
       |             |             |
  Peluang       Peluang       Peluang
       |             |             |
   ---------     ---------     ---------
   |       |     |       |     |       |
Penyelesaian  Penyelesaian  ... Penyelesaian
   |
Eksperimen

Anda bermula dengan satu Hasil (keputusan perniagaan yang boleh diukur, seperti "tingkatkan penukaran percubaan ke berbayar sebanyak 15%"). Anda memetakan Peluang (titik kesakitan pelanggan, keperluan yang tidak dipenuhi, momen geseran) yang dikumpulkan daripada temu bual pelanggan mingguan. Di bawah setiap peluang anda menjana beberapa Penyelesaian. Di bawah setiap penyelesaian yang menjanjikan, anda mereka bentuk Eksperimen untuk mengesahkan sebelum membina.

Kejeniusan dalam pendekatan ini ialah ia memaksa hierarki. Anda tidak boleh mengutamakan penyelesaian berbanding penyelesaian. Anda hanya boleh mengutamakan peluang, kemudian memilih penyelesaian terbaik untuk peluang yang dipilih.

Bila OST menang:

• Pasukan penerokaan berterusan. Pasukan yang menjalankan temu bual pelanggan mingguan dan melakukan ujian prototaip. Pokok dikemas kini apabila penerokaan memunculkan peluang baru.
• Organisasi yang didorong oleh hasil. Di mana kepimpinan menetapkan matlamat sebagai hasil, bukan senarai ciri. OST menterjemah hasil ke dalam saluran paip penerokaan-dan-bina.
• Mengelakkan mod kilang ciri. Gerakan pembunuh OST adalah menjadikannya jelas apabila penyelesaian tidak berkait dengan peluang yang berkait dengan hasil. Jika ia tidak bersambung, jangan bina.

Di mana OST gagal:

• Organisasi di mana "penerokaan" bermakna satu temu bual pengguna suku tahunan. OST adalah sistem operasi penerokaan berterusan. Tanpa irama penerokaan, pokok itu hiasan semata-mata. Anda akan mengisinya dengan peluang yang anda andaikan dan bukannya yang anda temui.
• Pasukan tanpa akses penyelidikan. Jika PM anda terpaksa berjuang untuk mendapatkan lima panggilan pelanggan sebulan, OST adalah aspirasi, bukan operasi.
• Suku tahun pelaksanaan semata-mata. Kadangkala anda perlu menghantar perkara yang menyekat pembaharuan. OST tidak akan membantu anda mengurut lapan ciri yang diketahui.

"Sekarang, seterusnya, kemudian" dan mengapa ia adalah RICE berkedok

Kebanyakan roadmap "sekarang / seterusnya / kemudian" adalah penarafan RICE dengan angka yang disembunyikan. PM mencetak segala-galanya, bahagian atas senarai masuk ke Sekarang, tengah ke Seterusnya, bawah ke Kemudian. Format itu berpura-pura fleksibel tetapi keutamaannya sama dengan hamparan yang diisih.

Format itu benar-benar bermakna sesuatu apabila setiap baldi mempunyai piawaian epistemik yang berbeza:

• Sekarang: keyakinan tinggi, berskop, komited. Anda akan menghantar ini. Pasukan memiliki hasil.
• Seterusnya: keyakinan sederhana, masalah disahkan, penyelesaian masih dalam penerokaan. Anda percaya ini penting. Anda belum membuktikan penyelesaian itu berfungsi.
• Kemudian: peluang, bukan penyelesaian. Perkara yang anda dengar daripada pelanggan yang belum mendapat slot lagi.

Jika baldi "Kemudian" anda mempunyai nama ciri dengan anggaran usaha, anda sedang melakukan RICE berkedok. Jika baldi "Kemudian" anda mempunyai masalah pelanggan dengan soalan terbuka, anda melakukannya dengan betul.

Keyakinan, input yang tidak pernah dicetak dengan jujur oleh sesiapa

Setiap PM yang pernah saya temui mengelembungkan keyakinan pada ciri kegemaran mereka. Orang yang membina lajur keyakinan rangka kerja mengharapkannya menjadi alat kalibrasi menyaksikannya menjadi lajur perasaan.

Penyelesaiannya: rubrik keyakinan yang dikaitkan dengan bukti, bukan perasaan.

Apa sahaja di bawah 60% tidak sepatutnya berada dalam lajur Sekarang anda di bawah mana-mana rangka kerja. Apa sahaja di bawah 40% sepatutnya menjadi Peluang dalam OST anda, bukan ciri pada roadmap anda. Jika anda tidak dapat mencapai keyakinan 60% pada sesuatu yang telah ada pada roadmap selama dua suku tahun, bunuhnya. Kos meninggalkannya di sana adalah penampilan kemajuan tanpa kemajuan sebenar.

Mengapa pihak berkepentingan anda membenci RICE

Inilah perbualan diagnostik yang saya lakukan dengan setiap pasukan yang berkata "RICE tidak berfungsi untuk kami." Ia hampir tidak pernah tentang rangka kerja. Ia tentang lapisan terjemahan.

Jualan membenci RICE kerana permintaan pelanggan mendapat markah rendah pada Jangkauan. Jualan membawa kepada anda permintaan yang menyekat tawaran daripada prospek yang membayar $80K. Jangkauan untuk pelanggan itu adalah satu. Markah RICE adalah pecahan. Jualan membaca ini sebagai "PM tidak peduli tentang hasil." Terjemahan: tarik keluar permintaan yang menyekat tawaran dari RICE sepenuhnya. Kekalkan "lorong penyekat tawaran" yang berasingan yang bersaiz mengikut impak kadar menang anda. Beritahu jualan lorong itu wujud.

CS membenci RICE kerana pertaruhan pengekalan mendapat markah rendah pada Impak. Ciri pengekalan jarang menunjukkan pergerakan metrik jangka pendek. Mereka mencegah kadar peralihan pelanggan yang akan berlaku enam bulan kemudian. Impak RICE bersifat ke hadapan, tetapi kebanyakan PM mencetak markah berdasarkan suku ke suku. Terjemahan: pisahkan pertaruhan pengekalan dan cetak Impak sebagai pergerakan kadar peralihan pelanggan tahunan, bukan pengaktifan suku tahunan.

Eng membenci RICE kerana Usaha adalah tekaan anda, bukan mereka. PM menganggar usaha berdasarkan ciri yang sama pada masa lalu. Eng tahu pangkalan kod mempunyai tiga perangkap. Terjemahan: jangan pernah menerbitkan markah RICE dengan nombor usaha anda sendiri. Gunakan julat (1-2 PM-bulan, 3-5 PM-bulan, 6+) dan biarkan eng memperketatkannya selepas laluan skop ringkas. PM memiliki Jangkauan, Impak, Keyakinan. Eng memiliki Usaha.

Coraknya: RICE memberikan satu nombor, tetapi empat input datang daripada empat pihak berkepentingan yang berbeza. Apabila anda menerbitkan skor tunggal dan tidak menunjukkan kerja anda, setiap pihak berkepentingan membaca input yang mereka peduli dan tidak bersetuju dengannya. Tunjukkan inputnya. Berdebat tentang Jangkauan dengan pemasaran, Impak dengan pasukan data, Keyakinan dengan penyelidikan, Usaha dengan eng. Skor adalah hasil daripada empat perbualan tersebut, bukan pengganti kepada mereka.

Bila menggabungkan ketiga-tiga

Berikut adalah gabungan yang saya gunakan sebenarnya:

1. Gunakan OST untuk mencari peluang yang betul. Petakan hasil kepada peluang pelanggan melalui penerokaan berterusan. Pilih peluang yang mempunyai bukti paling kukuh dan potensi impak hasil tertinggi. Langkaui lapisan ini jika anda sudah mengetahui masalah dengan baik (ciri matang, domain yang difahami dengan baik). Jangan langkaui jika pasukan anda menghantar ciri yang tidak diminta oleh sesiapa.

2. Gunakan Kano untuk mengklasifikasikan penyelesaian. Setelah anda memilih peluang dan mempunyai dua atau tiga penyelesaian calon, jalankan Kano pada calon tersebut dengan data pelanggan sebenar. Langkaui lapisan ini jika penyelesaian itu jelas Asas (pengesahan, eksport, kebolehaksesan). Jangan langkaui jika anda memilih antara "jadikan ciri sedia ada lebih pantas" dan "tambah momen keseronokan" dan anda tidak dapat memberitahu mana yang benar-benar pelanggan hargai.

3. Gunakan RICE untuk mengurut pembinaan. Setelah anda memilih peluang dan penyelesaian yang hendak dibina, RICE mengurut mereka merentasi suku tahun. Usaha, kebergantungan, kapasiti. RICE adalah alat pengurutan, bukan alat penerokaan. Di situlah ia mendapat tempatnya.

Gabungan penuh adalah berlebihan untuk kebanyakan pasukan pada kebanyakan masa. Pasukan yang menghantar penambahbaikan bertambah kepada CRM yang matang tidak memerlukan OST setiap suku tahun. Mereka memerlukan RICE pada backlog yang bersih. Syarikat permulaan pra-kesesuaian produk-pasaran tidak memerlukan RICE. Mereka memerlukan OST dan kesanggupan untuk membuang separuh roadmap. Padankan kedalaman rangka kerja dengan situasi epistemik sebenar. Memaksa OST pada pasukan tanpa akses penyelidikan adalah teater. Memaksa RICE pada pasukan yang tidak tahu KPI-nya adalah ketepatan tanpa kejituan.

Rangka kerja itu bukan jawapannya. Pilih yang memaksa perbualan yang dielakkan oleh pasukan anda. Jika pasukan anda mengelakkan hubungan pelanggan, jalankan OST. Jika pasukan anda mengelakkan pemotongan skop, jalankan Kano. Jika pasukan anda mengelakkan pertukaran pengurutan, jalankan RICE. Dan jika pasukan anda mengelakkan ketiga-tiga, masalahnya bukan rangka kerjanya. Masalahnya ialah tiada siapa yang mahu membuat keputusan yang sebenar, dan tiada hamparan yang akan membetulkan perkara itu.

Baca Lagi

• JD Pengurus Produk (rakan)
• Tabiat Penerokaan Berterusan untuk PM
• Menulis PRD yang Tidak Dibenci Jurutera
• Perancangan Suku Tahunan dengan Eng + Reka Bentuk