RICE чи Kano: Який фреймворк допоможе не злити ресурси на непотрібні фічі?
Досліджуємо, де варто використовувати кожен із них
Під час планування продуктові команди часто витрачають ресурси неефективно. Навіть сильні ідеї та перспективні фічі не дають результату, якщо немає спільних критеріїв для пріоритизації. В підсумку команда фокусується на тому, що звучить важливо саме зараз, замість розвивати те, що реально просуває продукт уперед.
RICE і Kano з'явились як відповідь на цю проблему — такий собі набір правил, щоб домовитись про те, що взагалі означає «важливо». У цій статті говоримо про ці фреймворки в контексті продуктових гіпотез.
Чому пріоритизація взагалі болить
Будь-який продукт накопичує ідеї швидше, ніж здатен їх реалізувати. Фічі зʼявляються звідусіль: з фідбеку клієнтів, з аналізу конкурентів, з внутрішніх брейнштормів, з тікетів підтримки, з інтуїції команди. Так, через якийсь час беклог перетворюється на кладовище чудових ідей, до яких навряд чи хтось повернеться.
Тож якщо ідей вдосталь, у чому проблема? Виходить, що команда не знає, за яким критерієм вона обирає те, що робити наступним.
У цьому контексті фреймворки потрібні не для того, щоб думати замість команди, а щоб зробити процес вибору відтворюваним. Щоб наступного разу на плануванні розмова починалася з «ось дані, ось логіка, ось чому саме це», а не з «я вважаю».
RICE: коли потрібні цифри
Якщо по-простому, RICE — це спосіб перетворити суб'єктивне відчуття «ця фіча важлива» на число, яке можна порівняти з іншим числом.
Формула складається з чотирьох змінних:
- Reach — скільки користувачів зачепить фіча за конкретний період. Не абстрактно «багато», а конкретно: 2000 активних акаунтів на місяць або 400.
- Impact — який ефект це справить на метрику, що має значення: конверсію, утримання, середній чек. Тут команда зазвичай використовує шкалу від 0,25 до 3.
- Confidence — наскільки команда впевнена у своїх оцінках. Якщо reach та impact взяті зі стелі, а не з даних, — confidence має бути низьким, і це зменшить підсумковий score.
- Effort — кількість людино-тижнів, яку фіча з'їсть.
Підсумкова оцінка рахується просто:
Reach × Impact × Confidence, поділити на Effort. Чим більше результат — тим вище пріоритет.
RICE добре працює там, де є метрики й де рішення потрібно пояснювати. Тому його люблять B2B та SaaS-команди. У них є чіткі воронки, є дані за сегментами, є стейкхолдери, яким потрібна логіка, а не інтуїція. Коли продакт каже, що команда бере певну фічу в розробку, бо її RICE score 48 проти 12 в альтернативи, — це закриває половину суперечок ще до того, як вони починаються.
Але у RICE є важливий нюанс, який потрібно враховувати. Цей фреймворк не валідує гіпотези — він їх масштабує. Якщо команда переоцінила reach або виставила confidence 80% там, де насправді є лише відчуття, — формула видасть красиве число на основі хибних припущень. Score виглядає об'єктивно, але всередині — ті самі суб'єктивні судження, просто упаковані з цифрами.
Тому RICE працює лише тоді, коли дані, на яких він будується, пройшли хоча б мінімальну перевірку реальністю.
Kano: коли важливо, що відчуває користувач
Якщо RICE відповідає на питання «що вигідніше збудувати», то Kano допомагає зрозуміти, що користувач взагалі відчує, коли це отримає.
Різниця між цими двома фреймворками колосальна. Бо можна збудувати фічу з ідеальним RICE score і почути у відповідь повну тишу. Жодного захоплення, жодного приросту лояльності. Користувач просто прийняв це як належне і пішов далі.
Модель Kano ділить функції на три категорії:
- Базові очікування — це те, без чого продукт не розглядатиметься взагалі (наприклад, пуш-сповіщення в мобільному банкінгу). Відсутність базових фіч одразу вбиває довіру, але їхня наявність не викликає жодної реакції, адже це норма. Інвестувати в базові очікування потрібно, але зростання задоволеності від них не буде.
- Лінійні функції працюють інакше: чим більше — тим краще, чим менше — тим гірше. Це стосується швидкості завантаження, точності пошуку, кількості інтеграцій тощо. Тут кожне покращення прямо конвертується в задоволення користувача. Це найпередбачуваніша категорія — і тому найзручніша для RICE.
- Делайтери — функції, яких користувач не очікував, але які викликають реальне захоплення (наприклад, Spotify Wrapped). Відсутність таких фіч не розчаровує, але їхня поява змінює ставлення до продукту.
А ще варто мати на увазі, що делайтери мають термін придатності. Те, що викликало «вау» три роки тому, сьогодні стало базовим очікуванням. Раніше так було з темною темою в додатках. Де б її не додавали — всі були щасливі. А зараз її відсутність дратує.
Kano найкорисніший на етапі discovery: коли команда ще не вирішила, що будувати, і хоче зрозуміти, як різні функції сприймаються конкретним сегментом користувачів. Так, Kano навряд чи напряму скаже, що робити першим, але підкреслить, чого точно очікують і що може здивувати.
Де вони конфліктують (і чому це важливо)
Можна уявити гіпотетичну ситуацію, де команда рахує RICE для десяти фіч. Одна отримує score 64 — найвищий у списку. Широке охоплення, прямий вплив на конверсію, команда впевнена в оцінках, а зусилля для реалізації помірні. За будь-якою бізнес-логікою, таку фічу потрібно брати в роботу першою.
Але паралельно хтось провів Kano-опитування з користувачами. І ця сама фіча потрапила в категорію базових очікувань. Користувачі сприймають її як «ну звісно, це має бути». Її поява не підвищить лояльність, не запустить сарафанне радіо, не стане причиною, чому хтось обере саме ваш продукт, а не конкурента.
Так, команда збудує правильну річ — і не отримає нічого з того, на що очікувала.
Працює і зворотна ситуація. Kano-дослідження виявляє делайтер — функцію, яка викликає живу реакцію під час інтерв'ю, яку користувачі описують словами «ось це було б круто». Але RICE score мізерний: охоплення вузьке, effort великий, confidence низький. За цифрами — не варто чіпати.
Команда, яка дивиться тільки в таблицю зі scores, ніколи не збудує цю фічу. Але, можливо, саме вона могла б стати точкою диференціації від конкурентів.
Це порівняння підкреслює проблему монофреймворкового мислення.
- RICE без Kano оптимізує під метрики, але не запитує, чи справді це важливо для людини по той бік екрана.
- Kano без RICE розуміє користувача, але не має механізму сказати, що з цього розуміння робити першим і за які ресурси.
Як використовувати обидва разом
Спочатку Kano — щоб зрозуміти контекст цінності
До того як рахувати будь-які scores, варто мати відповідь на базове запитання: як користувач взагалі сприймає цю область продукту? Що для нього вже є нормою, а що може здивувати? Це робиться через якісні інтерв'ю або Kano-опитування. Фічі, які вийшли з цього етапу з розумінням своєї категорії, йдуть далі.
Потім RICE — щоб розставити пріоритети всередині того, що має сенс
Тепер у команди є не просто список ідей, а список ідей з контекстом. Делайтер з вузьким охопленням і великим effort може свідомо отримати нижчий пріоритет, але команда розуміє, чому вона його відкладає, а не просто ігнорує. Базове очікування з високим RICE score береться в роботу.
Але є умова, без якої все це не працює. Обидва фреймворки залежать від якості вхідних даних і чесності команди в оцінках. Kano-опитування на вибірці з 20 лояльних користувачів не репрезентує ринок. RICE із confidence 90% на гіпотезі, яку ніхто не перевіряв, — це самообман з формулою.
Тому фреймворк не замінює валідацію. Він структурує те, що команда вже знає або чесно визнає, що не знає. Найкорисніше, що може зробити RICE, — це змусити команду явно виставити низький confidence і побачити, як це обвалює score фічі, в яку всі «вірили».
Висновок напрошується сам: і Kano, і RICE цінні не через числа, а тому, що вчать дисципліни, дають простір думати вголос і перевіряти припущення до того, як почався спринт.
