Потоп функцій: Як пріоритезувати функції продукту, не потонувши в морі можливостей

Парадокс достатку

Ваш продуктовий беклог — це, ймовірно, кладовище хороших ідей.

Там є інтеграція, яку ваш найбільший клієнт просить уже кілька місяців. Редизайн, за який агітує команда дизайнерів. Покращення продуктивності, на які постійно вказують інженери. Нова функція, яку щойно запустив конкурент. Аналітична панель, яка, за словами відділу продажів, допоможе закривати більше угод.

Усе це обґрунтовано. Усе це потенційно цінне. І спроба реалізувати все одночасно знищить ваш продукт.

Це і є потоп функцій — постійний тиск можливостей, що накопичуються і загрожують потопити ясність вашого продукту та ефективність команди. Більшість продуктових команд реагують на це, хапаючись за фреймворки пріоритезації: RICE-оцінки, матриці MoSCoW, моделі зваженого скорингу. Ці інструменти мають своє місце, але всі вони мають фатальну ваду.

Вони припускають, що найважча робота — це ранжування функцій. Але це не так. Найважча робота — це вирішити, який саме продукт ви взагалі створюєте.

Чому фреймворки пріоритезації не працюють

Розповім про один стартап, який я консультував минулого року. Вони впровадили суворий RICE-фреймворк — Reach, Impact, Confidence, Effort. Кожен запит на функцію отримував оцінку. Найвищі бали піднімалися на вершину. Демократія в дії.

Через шість місяців їхній продукт перетворився на монстра Франкенштейна. Функції з високими оцінками накопичилися в заплутаний хаос. Користувачі скаржилися, що продукт намагається робити занадто багато. Команда була виснажена від постійного перемикання між непов'язаними ініціативами.

Що пішло не так? RICE-оцінки були точними. Кожна окрема функція справді мала високий вплив. Але фреймворк не міг відповісти на більш фундаментальне питання: Вплив на що?

Фреймворки пріоритезації оптимізують у межах стратегії. Вони не можуть її створити. А без стратегічної ясності навіть ідеальна пріоритезація породжує хаос.

Фокусуюче питання

Перш ніж пріоритезувати функції, потрібно відповісти на те, що я називаю Фокусуючим питанням:

«Яку одну річ наш продукт має робити краще за все інше на ринку?»

Не три речі. Не п'ять. Одну.

Це не про обмеження можливостей вашого продукту. Це про встановлення центру тяжіння, який надає узгодженості всьому, що ви створюєте. Кожен успішний продукт має таке гравітаційне ядро:

Ядро Slack — не функції, а те, щоб робоча комунікація відчувалася менш схожою на роботу
Ядро Notion — не гнучкість, а те, щоб складна інформація здавалася простою
Ядро Linear — не управління проєктами, а те, щоб розробка програмного забезпечення відчувалася швидкою

Зверніть увагу: це не описи функцій. Це обіцянки досвіду. І коли ви визначите свою, пріоритезація стане майже автоматичною. Функції, що підсилюють ваше ядро, створюються. Функції, що його розмивають, відкидаються — незалежно від того, як високо вони оцінені за традиційними фреймворками.

Тест трьох лінз

Коли ви визначили своє фокусуюче питання, пропускайте кожну потенційну функцію через три лінзи:

Лінза 1: Підсилення ядра

Чи робить ця функція нашу ключову обіцянку сильнішою чи слабшою?

Це здається очевидним, але дивовижно, як часто команди це пропускають. Функція може бути цінною, запитуваною клієнтами і технічно вражаючою — і все одно послаблювати ваш продукт, відволікаючи увагу від того, що робить вас незамінними.

Запитайте: «Якщо ми це створимо, чи скажуть користувачі, що ми стали ще кращими в нашій ключовій справі? Чи вони почнуть описувати нас інакше?»

У той момент, коли користувачам стає важко пояснити, для чого призначений ваш продукт, ви втратили фокус.

Лінза 2: Стратегічна послідовність

Чи має ця функція існувати, перш ніж інші функції зможуть розкрити свій потенціал?

Деякі функції — це несучі стіни. Інші — декоративне оздоблення. Будувати оздоблення до стін — найпоширеніший спосіб, яким продукти втрачають імпульс.

Я працював з командою, що створювала інструмент для співпраці. Вони постійно пріоритезували нові функції співпраці, тоді як їхній базовий редактор документів залишався незграбним. Користувачі не могли ефективно співпрацювати, бо фундамент був слабким. Кожна нова функція співпраці не виправдовувала очікувань, бо стояла на нестабільній основі.

Побудуйте карту залежностей ваших функцій. Що має існувати, щоб інші речі мали значення? Будуйте це першим.

Лінза 3: Реальність альтернативних витрат

Що ви не створите, якщо створите це?

Ось де пріоритезація стає чесною. Кожна функція, яку ви створюєте — це три функції, які ви не створюєте. Кожен спринт, витрачений на одну ініціативу — це спринт, не витрачений на іншу.

Більшість команд ставляться до свого беклогу як до черги — все буде створено з часом. Це втішна ілюзія. Насправді більшість пунктів беклогу ніколи не буде реалізовано. Питання не в тому, чи відкидати функції. Питання в тому, чи робити це усвідомлено.

Підхід ради до рішень щодо функцій

Ось де багато продуктових команд роблять критичну помилку: вони намагаються приймати ці рішення на самоті.

Продакт-менеджер сидить наодинці з таблицею, зважує фактори, присвоює оцінки і виходить з пріоритезованим списком. Це здається ефективним. Насправді це небезпечно.

Пріоритезація функцій — це саме той тип рішень, який виграє від різноманітних порад. Вам потрібні перспективи, що кидають виклик вашим припущенням і бачать кути, які ви пропускаєте:

Адвокат клієнта, який знає, які больові точки справді блокують впровадження
Технічний реаліст, який розуміє, які функції — це айсберги (малі на поверхні, величезні під водою)
Бізнес-стратег, який бачить, як функції пов'язані з доходом і зростанням
Дизайн-мислитель, який може помітити, коли функції створять плутанину замість ясності
Контраріан, який запитує, чи взагалі варто створювати цю функцію

Інструменти на кшталт thonk можуть допомогти зібрати ці різноманітні перспективи в структурований процес прийняття рішень. Мета — не консенсус, а всебічне розуміння. Ви хочете знати, чим жертвуєте, перш ніж взяти на себе зобов'язання.

Квартальне очищення

Навіть з чітким фокусом і хорошим процесом, повзуче розростання функцій невпинне. Ідеї накопичуються. Стейкхолдери лобіюють. Беклог росте.

Запровадьте квартальне очищення. Кожні три місяці переглядайте весь беклог свіжим поглядом і з єдиним питанням: «Якби ми починали з нуля сьогодні, чи додали б ми це?»

Будь-яка функція, що не отримує чіткого «так», архівується. Не видаляється — ці ідеї можуть знадобитися пізніше. Але прибирається з активного розгляду, щоб перестати споживати ментальну енергію.

Це здається марнотратством. Ви інвестували час в обговорення цих функцій, їх опис, можливо, навіть дизайн. Але нести мертвий вантаж — більше марнотратство, ніж його відкинути. Кожна функція у вашому беклозі — це рішення, яке ви не прийняли, а неприйняті рішення виснажують.

Анти-роадмап

Більшість продуктових команд ведуть роадмап того, що вони створюють. Подумайте також про ведення анти-роадмапу: публічного документа функцій, які ви свідомо вирішили не створювати.

Це служить трьом цілям:

По-перше, це комунікує фокус. Коли стейкхолдери бачать, що ви вдумливо розглянули і відхилили певні напрямки, вони розуміють, що ваші пріоритети не довільні.

По-друге, це запобігає повторним дискусіям. На функції, які постійно пропонуються, можна вказати в анти-роадмапі. «Ми це розглядали. Ось чому вирішили відмовитися. Ось що має змінитися, щоб ми переглянули рішення.»

По-третє, це створює відповідальність. Якщо функції з вашого анти-роадмапу продовжують приносити успіх конкурентам, у вас є чіткий сигнал, що вашу стратегію потрібно переглянути.

Сміливість розчаровувати

Зрештою, пріоритезація — це про розчарування. Кожна функція, яку ви не створюєте, когось розчаровує — клієнта, який її просив, стейкхолдера, який за неї агітував, інженера, який хотів над нею працювати.

Ось чому фреймворки пріоритезації такі спокусливі. Вони дозволяють звинувачувати математику. «RICE-оцінка була нижчою.» «Не досягла порогу.» Фреймворк прийняв рішення, не ви.

Але справжня пріоритезація вимагає брати на себе відповідальність за розчарування. Це означає дивитися клієнту в очі і говорити: «Я розумію, що це важливо для вас, і ми вирішили це не створювати.» Це означає казати своїй команді: «Це чудова ідея, і це не те, на чому ми зараз фокусуємося.»

Це вимагає сміливості. Це також будує довіру. Команди і клієнти поважають лідерів, які приймають чіткі рішення, навіть непопулярні, більше, ніж лідерів, які ховаються за процесами.

Практика на цей тиждень

Візьміть свій поточний беклог і спробуйте цю вправу:

Напишіть своє Фокусуюче питання вгорі сторінки — одну річ, яку ваш продукт має робити краще за все інше
Перелічіть топ-10 пунктів беклогу
Для кожного пункту оцініть від 1 до 5 за Підсиленням ядра (чи підсилює він ваш фокус?)
Будь-який пункт з оцінкою нижче 4 перенесіть у список «переглянути»
Для пунктів, що залишилися, визначте залежності — що має існувати першим?
Поділіться своїми міркуваннями принаймні з двома людьми, які поставлять під сумнів ваші припущення

Ви, ймовірно, виявите, що половина ваших «топ-пріоритетів» насправді не підсилює ваше ядро. Це не провал минулої пріоритезації — це ясність щодо того, що робити далі.

Спокійний беклог

Існує особливий спокій, що приходить від сфокусованого беклогу. Коли ваша команда точно знає, що вона створює і чому, рішення стають легшими на кожному рівні. Інженери не витрачають час на крайні випадки для функцій, які можуть бути відкинуті. Дизайнери не полірують інтерфейси для можливостей, що не мають значення. Стейкхолдери перестають лобіювати, бо критерії зрозумілі.

Як ми досліджуємо на thonk, найкращі рішення часто приходять не від кращого аналізу, а від ясності мети. Пріоритезація функцій не виняток. Команди, що випускають чудові продукти — це не ті, хто має найкращі фреймворки. Це ті, хто точно знає, яким має стати їхній продукт — і має дисципліну не будувати нічого іншого.