Три года назад я написал статью про то, как мы тогда приоритизировали продуктовые решения.
Если хотите, можете её найти в архиве — там всё честно: RICE, AAARRR, матрица Эйзенхауэра, квартальные исследования. На тот момент это был рабочий набор. Мы им пользовались, он давал результат, и я искренне считал его оптимальным.
С тех пор прошло много времени, десятки продуктовых запусков и сотни разговоров с командами. И вот что я понял: почти все те инструменты за это время либо потеряли актуальность, либо уступили место более живым и гибким подходам.
Поэтому я решил сделать то, что давно откладывал: вернуться к старой статье, перечитать её — и переписать так, чтобы она отражала реальность 2025 года.
Ниже — мой апдейт. Всё те же темы, но другие решения. Если хотите сравнить с оригиналом, начните с него, а потом вернитесь сюда — разница будет очевидна.
By Teresa Torres
Почему критично: В 2025 году это стандарт для команд, которые реально разговаривают с пользователями, а не просто делают вид. Больше 16 тысяч продактов уже освоили этот подход.
В чем суть: Вместо того чтобы приоритизировать функции, вы приоритизируете проблемы пользователей. Рисуете дерево: наверху — цель бизнеса, посередине — проблемы пользователей (возможности), внизу — способы их решить (решения).
Как это работает:
— Каждую неделю разговариваете с 2-3 пользователями
— Обновляете дерево на основе того, что узнали
— Приоритизируете не «какую кнопку добавить», а «какую проблему решать первой»
Пример: Команда Zoom думала приоритизировать новые фильтры для видео. После интервью поняли — главная проблема не в том, как я выгляжу, а в том, что не слышно коллег. Переключились на улучшение аудио и получили больший эффект.
Разница с RICE: RICE помогает выбрать лучшее решение из готового списка. Деревья возможностей и решений помогают понять, правильный ли у вас список.
Что изменилось: Раньше ставили цели и ключевые результаты в январе, а приоритизировали функции каждую неделю. Связь между ними была на уровне «ну, вроде бы влияет». Сейчас каждая задача в бэклоге привязана к конкретному ключевому результату.
Как это выглядит: Открываете список задач — у каждой написано, на какой ключевой результат она влияет и насколько. Если задача не двигает ни один ключевой результат этого квартала — она не попадает в спринт. Точка.
Пример: У команды Notion есть ключевой результат «увеличить количество еженедельно активных команд на 20%».
Две функции в бэклоге:
1) новые шаблоны для личного планирования,
2) улучшенное комментирование в общих страницах.
По RICE обе получают похожие баллы. По подходу с целями и ключевыми результатами выбираете комментирование — оно напрямую влияет на командную работу.
Инструменты: Dragonboat показывает, как изменится ваш ключевой результат, если сделать конкретную функцию. ProductPlan рисует дорожную карту, где видно, какие функции к какому результату привязаны.
ProductPlan рисует дорожную карту как интеллект-карту: в центре ваши цели и ключевые результаты, от них идут ветки к функциям, которые на них влияют. Получается дерево зависимостей, где сразу видно, какие части дорожной карты работают на какие цели.
Если у вас есть функция, которая ни к чему не привязана — она висит в воздухе, и становится очевидно, что либо ее нужно убрать, либо пересмотреть цели и ключевые результаты. Особенно полезно для больших команд: когда фронтенд-разработчик спрашивает, зачем делать эту кнопку, вы показываете дорожную карту и объясняете, как кнопка влияет на квартальный ключевой результат по удержанию.
Главное: Квартальные циклы вместо годовых. Долгосрочные проекты разбиваете на части так, чтобы каждый квартал видеть прогресс.
Идея: Вместо балансирования десятка метрик выбираете одну главную. Все решения о приоритетах принимаете через призму этой метрики. Метрика полярной звезды — это одна главная метрика, которая отражает ценность вашего продукта для пользователей. Если эта метрика растет, значит, продукт становится полезнее. Если падает — что-то идет не так, несмотря на рост других показателей.
Метрика полярной звезды отличается от обычных бизнес-метрик тем, что она одновременно отражает пользу для клиента и пользу для бизнеса. Когда пользователи получают больше ценности от продукта, компания зарабатывает больше денег.
Есть три типа продуктов, и для каждого подходят разные метрики:
Модель внимания (медиа, соцсети, развлечения):
— Метрика: время, проведенное в продукте
— Примеры: Netflix — часы просмотра на подписчика, TikTok — ежедневное время использования, Medium — время чтения
— Логика: чем больше времени проводят пользователи, тем больше рекламы можно показать или подписок продать
Транзакционная модель (электронная торговля, маркетплейсы, финтех):
— Метрика: количество транзакций или их объем
— Примеры: Airbnb — забронированные ночи, Uber — завершенные поездки, PayPal — объем платежей
— Логика: каждая транзакция приносит комиссию
Модель продуктивности (рабочие инструменты, корпоративные программы):
— Метрика: завершенные результаты или активные пользователи
— Примеры: Asana — завершенные проекты, GitHub — активные репозитории, Slack — отправленные сообщения в команде
— Логика: чем продуктивнее пользователи, тем больше готовы платить за инструмент
Вместо многофакторного анализа все решения принимаете через одну призму: как это повлияет на главную метрику?
Пример 1: Airbnb и забронированные ночи
Команда хотела сделать два улучшения: новые фильтры поиска (найти жилье по конкретным критериям) и улучшенную систему отзывов (больше доверия к хозяевам). Фильтры помогают найти подходящее жилье быстрее, но не увеличивают количество забронированных ночей — люди и так бронировали что-то. Система отзывов повышает доверие → больше людей решаются забронировать → количество забронированных ночей растет. Решение: приоритет получили отзывы.
Пример 2: Spotify и время прослушивания
Две идеи на столе: социальные функции (делиться плейлистами с друзьями) и улучшенные рекомендации (более точный алгоритм подбора музыки). Социальные функции увеличивают вовлеченность, но не обязательно время прослушивания — можно весь день листать ленту друзей, не слушая музыку. Улучшенные рекомендации помогают найти музыку, которую хочется слушать дольше. Решение: приоритет получили рекомендации.
Полярная звезда не заменяет RICE или другие методы приоритизации. Она работает как окончательный арбитр и стратегический фильтр:
Как стратегический фильтр: Если функция не влияет на полярную звезду, она не попадает в разработку. Неважно, насколько она красивая или сколько людей ее просят.
Как окончательный арбитр: Когда у вас две функции с одинаковым показателем RICE, выбираете ту, которая сильнее влияет на главную метрику.
Пример интеграции: Команда электронной торговли использует «ежемесячные покупающие пользователи» как полярную звезду. Применяют RICE для оценки функций, но в параметр влияния подставляют прогноз воздействия на количество покупающих пользователей. Функции, которые увеличивают удовлетворенность, но не влияют на покупки, получают низкий показатель влияния.
Полярная звезда, как и любая другая метрика, может толкать в неправильную сторону.
Пример: Если ваша метрика — ежедневно активные пользователи, команда начнет делать спам-уведомления для роста активности. Пользователи вернутся в продукт, но возненавидят его.
Краткосрочная оптимизация: Полярная звезда может толкать к решениям, которые работают сейчас, но вредят в долгосрочной перспективе.
Пример: Если ваша метрика — ежедневно активные пользователи, команда может начать делать спам-уведомления. Пользователи возвращаются в приложение → ежедневно активные пользователи растут → все довольны. Через полгода пользователи устают от спама и удаляют приложение.
Решение: Добавляете балансирующую метрику. К ежедневно активным пользователям добавляете показатель удержания или индекс потребительской лояльности. Если основная метрика растет, а балансирующая падает — что-то не так со стратегией.
Локальная оптимизация: Фокус на одной метрике может сломать другие части продукта.
Пример: Команда YouTube оптимизирует время просмотра. Алгоритм начинает продвигать очень длинные видео, потому что они дают больше времени просмотра. Результат: создатели начинают делать искусственно растянутый контент, качество падает.
Решение: Учитываете не только количественные, но и качественные показатели. YouTube добавил метрики типа «лайки за минуту просмотра» и «вовлеченность в комментарии».
Неправильный выбор метрики: Иногда то, что кажется важным для бизнеса, не отражает ценность для пользователей.
Пример: Команда мобильного банка выбрала «количество открытий приложения в месяц» как полярную звезду. Оптимизируют под эту метрику: добавляют push-уведомления, геймификацию, программы лояльности. Количество открытий приложения растет, но удовлетворенность клиентов падает — люди заходят в банк, когда у них проблемы, а не для развлечения. Правильная метрика была бы «успешно завершенные транзакции» — отражает, насколько хорошо банк помогает решать финансовые задачи.
Шаг 1: Быстрый шаблон: Определите, к какому типу продуктов вы относитесь (Внимание/Транзакции/Продуктивность) и выберите соответствующую категорию метрик. Этот набор не универсальный, но можно начать размышления с него.
Шаг 2: Проверьте связь с бизнесом. Полярная звезда должна коррелировать с доходом. Если пользователи получают больше ценности (метрика растет), компания должна зарабатывать больше денег.
Шаг 3: Сделайте метрику выполнимой. Команда должна понимать, какими действиями можно на нее повлиять. «Счастье пользователей» — плохая полярная звезда, потому что неясно, что конкретно делать. «Время от регистрации до первой завершенной задачи» — хорошая, потому что ясно, где искать проблемы.
Шаг 4: Внедрите в процесс приоритизации. Каждая новая функция должна иметь гипотезу: «Если мы сделаем X, полярная звезда изменится на Y% потому что Z».
Шаг 5: Добавьте балансирующие метрики, чтобы избежать локальной оптимизации.
Полярная звезда работает лучше всего в продуктовых командах, которые имеют свободу действий и несут ответственность за результат. В компаниях с жесткой вертикальной структурой, где решения принимает топ-менеджмент, этот подход может не прижиться.
Проблема с воронкой: AAARRR заставляет думать о пользователях как о воде, которая течет через трубу. Прошел привлечение → попал в активацию → дошел до дохода. Но в программах как услуге и цифровых продуктах пользователь не «проходит» через продукт — он живет в нем, получает ценность, становится адвокатом бренда. Вороночное мышление пропускает самое главное: моменты, когда продукт реально помогает решить проблему.
Что такое метрики продуктово-ориентированного роста: Вместо этапов пути клиента измеряете моменты ценности внутри продукта. Фокус не на том, сколько людей что-то сделали, а на том, насколько глубоко они интегрировали продукт в свою жизнь или работу.
Идея: Измеряете, как быстро новый пользователь получает реальную пользу от продукта. Не «зарегистрировался» или «заполнил профиль», а именно решил свою проблему.
Примеры:
— Slack: время до отправки первого сообщения в команде (не время до регистрации)
— Figma: время до создания первого общего дизайна (не время до первого входа)
— Notion: время до создания первой базы данных с реальными данными (не время до завершения знакомства с продуктом)
Как это меняет приоритизацию: Если ваше время до получения ценности 3 дня, а у конкурента 30 минут, никакие улучшения в удержании не помогут. Приоритет получают функции, которые помогают пользователю быстрее достичь «ага-момента», а не красивое знакомство с продуктом.
Пример: Команда Dropbox обнаружила, что пользователи, которые установили приложение на втором устройстве в первые 7 дней, имеют удержание в 10 раз выше. Время до получения ценности = время до синхронизации первого файла между устройствами. Вся продуктовая стратегия переключилась на сокращение этого времени.
Идея: Какой процент пользователей использует ключевые функции, которые отличают ваш продукт от конкурентов. Не просто «сколько пользователей активны», а «сколько пользователей используют то, за что они реально платят».
Примеры:
— Asana: процент команд, которые используют пользовательские поля (не просто создают задачи)
— Zoom: процент пользователей, которые запланировали повторяющиеся встречи (не просто созвонились один раз)
— GitHub: процент разработчиков, которые используют запросы на слияние (не просто хранят код)
Как определить ключевые функции: Берете пользователей с самым высоким удержанием и смотрите, какими функциями они пользуются чаще других. Это и есть ваши «волшебные функции».
Влияние на приоритизацию: Если только 15% пользователей используют вашу убойную функцию, проблема не в том, что нужны новые функции. Проблема в том, что 85% пользователей не понимают ценность того, что уже есть. Приоритет получают улучшения в обнаружении и знакомстве с существующими функциями.
Пример: Spotify обнаружил, что пользователи, которые создали свой первый плейлист, слушают музыку в 3 раза дольше. Принятие функций = процент пользователей, создавших плейлист в первые 30 дней. Вместо добавления новых музыкальных функций сфокусировались на том, чтобы больше людей создавали плейлисты.
Идея: Пользователи, которые достигли определенного уровня активности в продукте и готовы к покупке/обновлению. В отличие от квалифицированных лидов маркетинга (скачал техническую документацию, посетил вебинар), квалифицированные лиды продукта показывают готовность платить через реальное поведение в продукте.
Как определить пороговое значение: Анализируете поведение пользователей, которые уже платят, и находите закономерности.
Например: «Пользователи, которые создали больше 10 проектов, обновляются в 70% случаев».
Примеры критериев квалифицированных лидов продукта:
— Calendly: запланировал больше 8 встреч в месяц
— Canva: скачал больше 5 дизайнов за неделю
— Loom: записал больше 3 видео с командным доступом
Влияние на приоритизацию: Вместо улучшений в коэффициенте конверсии целевой страницы фокусируетесь на том, чтобы больше пользователей достигали статуса квалифицированного лида продукта. Приоритет получают функции, которые подталкивают к более глубокому взаимодействию.
Пример: HubSpot определил, что пользователи, которые подключили интеграцию с электронной почтой и отправили больше 100 писем через платформу, покупают платный план в 90% случаев. Вся продуктовая дорожная карта переориентировалась на то, чтобы помочь пользователям быстрее достичь этого рубежа.
Как интегрировать оба подхода: Используете AAARRR для макро-обзора (общий путь клиента), метрики продуктово-ориентированного роста для микро-обзора (что происходит внутри продукта). AAARRR показывает, сколько людей дошло до регистрации, метрики продуктово-ориентированного роста показывают, что они делают после регистрации и почему остаются или уходят.
Главное отличие в мышлении: AAARRR думает «как привести больше людей в воронку», продуктово-ориентированный рост думает «как сделать продукт настолько полезным, чтобы люди не могли без него жить». Первое требует больше маркетинга, второе — больше разработки продукта.
Проблема квартальных исследований: Большинство продуктовых команд проводят пользовательские исследования циклами: два месяца строим функции по старым пониманиям, потом месяц проводим исследования, делаем выводы и планируем еще на квартал вперед. К моменту релиза половина предположений устарела, но менять уже поздно — дорожная карта утверждена, ресурсы распределены.
Что такое непрерывное исследование: Вместо больших исследовательских проектов раз в квартал — маленькие еженедельные точки контакта с пользователями. Не драматические повороты на основе всеобъемлющих исследований, а постоянные микрокорректировки направления на основе свежих доказательств. Как навигатор в машине: не перепланирует весь маршрут каждые 100 км, а подсказывает повороты каждые 100 метров.
Автор и философия: Teresa Torres развила этот подход в 2021-2023 годах, работая с сотнями продуктовых команд. Основная идея: понимания клиентов, как молоко — быстро портятся. Трехмесячное исследование так же полезно для принятия решений сегодня, как трехмесячная газета для понимания текущих событий.
Минимальная доза: 2 часа контакта с клиентами в неделю на команду. Не 2 часа интервью — 2 часа любого контакта: интервью, наблюдения за использованием продукта, анализ обращений в поддержку, чтение отзывов.
Структура недели:
— Понедельник: планируете спринт с учетом пониманий прошлой недели
— Среда: интервью с 1-2 пользователями (20-30 минут каждое)
— Пятница: анализируете то, что узнали, обновляете предположения
Кто участвует: Не только исследователь пользовательского опыта. Разработчики, дизайнеры, продакт — все по очереди говорят с пользователями. Как в методологии разработки и эксплуатации каждый отвечает за развертывание, в непрерывном исследовании каждый отвечает за понимание клиентов.
Пример: Команда BBC Maestro делала онлайн-курсы кулинарии. Квартальное исследование показало: «Пользователи хотят видео высокого качества в высоком разрешении.» Потратили 3 месяца на улучшение качества видео. Непрерывное исследование через еженедельные интервью показало другое: «Пользователям нужна возможность поставить урок на паузу и вернуться к конкретному шагу рецепта.» Переключились на улучшение навигации внутри уроков. Принятие функций выросло с 23% до 67%.
Старый подход: Продакт-менеджер думает: «Пользователям точно нужна темная тема, это же тренд.» Ставит высокое влияние в RICE без обоснований. Функция получает приоритет на основе внутренних убеждений команды.
Подход непрерывного исследования: Каждая оценка в любом фреймворке приоритизации опирается на доказательства последних 1-2 недель. «Влияние = 8, потому что в 4 из 5 интервью на этой неделе люди упомянули эту проблему как основную болевую точку.»
Что считается доказательствами:
— Прямые цитаты от пользователей (не пересказ, а буквальные слова)
— Поведенческие данные (что люди реально делают против того, что говорят)
— Закономерности поддержки (какие вопросы задают чаще всего)
— Аналитика использования (где пользователи застревают или уходят)
Пример: Команда Superhuman хотела добавить календарную интеграцию. Традиционный подход: «Электронная почта + календарь = очевидная синергия, делаем.» Непрерывное исследование: 20 еженедельных интервью показали — люди хотят не календарь в почте, а напоминания по почте для событий календаря. Совсем другая функция, которую никто не планировал, но которая решала реальную боль.
Непрерывное исследование не заменяет RICE/OKR/ICE — она питает их актуальными данными. Как хороший бензин не заменяет двигатель, но позволяет ему работать эффективнее.
Как это работает с RICE:
— Охват: не интуитивное ощущение, а данные о том, сколько людей в интервью упоминали проблему
— Влияние: не предположения, а цитаты пользователей о том, насколько это критично
— Уверенность: основана на количестве доказательств за последние недели
— Усилие: дополняется пониманием того, какие части решения наиболее важны для пользователей
Как это работает с целями и ключевыми результатами: Еженедельное исследование показывает, какие инициативы реально движут ключевые результаты, а какие только кажутся важными. Можете корректировать тактику каждую неделю, не меняя стратегические цели.
Пример интеграции: Команда использует RICE для приоритизации. В понедельник RICE показал, что функция А важнее функции Б. В среду интервью показали новую проблему пользователей — функция В. В пятницу добавили функцию В в RICE, пересчитали приоритеты. Функция В оказалась важнее А и Б. Скорректировали план следующего спринта. Не революция, а эволюция.
Асинхронные интервью: Не все интервью должны быть в реальном времени. Можете отправить пользователям 3-4 вопроса в видео и попросить записать ответы. Экономит время, но дает глубокое понимание.
Микро-исследования: 10-минутные разговоры лучше, чем отсутствие разговоров. Позвонили пользователю, задали один вопрос, получили ответ — это тоже исследование.
Консультативные звонки с клиентами: Раз в две недели созвон с 3-5 постоянными клиентами, которые готовы давать обратную связь. Обсуждаете новые идеи и получаете быструю валидацию или отклонение.
Собачий корм: Команда сама пользуется продуктом в реальных сценариях.
Продакт-менеджер заказывает еду через свое приложение доставки, дизайнер создает реальный проект в своем инструменте дизайна.
Результаты непрерывного исследования:
— Меньше провальных функций (потому что проверено до разработки)
— Выше принятие функций (потому что решают реальные проблемы)
— Короче время до соответствия продукта рынку (потому что итерируют на основе доказательств)
— Лучше согласованность команды (все видят одни и те же понимания клиентов)
Как измерить успех подхода:
— Уровень принятия функций: процент пользователей, которые используют новые функции через месяц после релиза
— Время до валидации: сколько времени нужно, чтобы понять, работает функция или нет
— Скорость получения понимания клиентов: сколько новых пониманий команда получает в неделю
— Уверенность в решениях: насколько команда уверена в продуктовых решениях (субъективный опрос)
Кейсы внедрения: BBC Maestro сократил время выхода на рынок на 40%, TextHelp увеличил принятие функций с 23% до 67%, команда JetBrains уменьшила количество неиспользуемых функций с 60% до 20%.
Не подходит, когда:
— Корпоративный сегмент с длинными циклами продаж: клиенты недоступны для еженедельных чатов
— Высоко регулируемые отрасли: каждое изменение требует юридического одобрения
— Инфраструктурные продукты: конечные пользователи не имеют прямого контакта с продуктом
— Очень ранняя стадия: еще нет пользователей для интервью
Альтернативы для сложных случаев:
— Представители пользователей (команда успеха клиентов, отдел продаж как источник пониманий)
— Интервью с заинтересованными сторонами вместо интервью с конечными пользователями
— Поведенческая аналитика как замена прямого контакта
— Отраслевые исследования и анализ конкурентов
Главный принцип: Лучше иметь какой-то контакт с клиентами, чем никакого контакта с клиентами. Если не можете говорить с пользователями каждую неделю, говорите раз в две недели. Если не можете делать 30-минутные интервью, делайте 10-минутные. Идеальное — враг хорошего, а хорошие понимания клиентов лучше, чем идеальные предположения.
Культурный сдвиг: Команды перестают спорить о том, что «пользователи хотят», и начинают спрашивать: «А что говорили пользователи на этой неделе?» Обсуждения на основе доказательств, не на мнениях. Это меняет не только приоритизацию, но и весь способ принятия продуктовых решений.
Проблема мышления, ориентированного на выпуск: Большинство продуктовых команд измеряют успех количеством сделанного: «В этом квартале запустили 12 функций, закрыли 80% задач из бэклога, отличный результат!» При этом ни одна функция не улучшила ключевые метрики продукта, пользователи не стали активнее, доход не вырос. Но бэклог очищен, дорожная карта выполнена — все довольны. До момента, когда босс спрашивает: «А зачем мы это все делали?»
Что такое подход, основанный на результатах: Приоритизируете не функции, а изменения в поведении пользователей или бизнес-показателях. Успех измеряете не количеством выпущенных функций, а достижением конкретных результатов. «В этом квартале увеличили еженедельное удержание с 65% до 72%» — неважно, потребовалась одна функция или двенадцать.
Разница в постановке вопросов:
— Подход, ориентированный на выпуск: «Какие функции сделать в этом спринте?»
— Подход, основанный на результатах: «Какого изменения в поведении пользователей мы хотим достичь? Что поможет этого добиться?»
Пример переключения: Команда музыкального стриминга хотела увеличить время прослушивания. Подход, ориентированный на выпуск: составили список из 15 функций (плейлисты, социальные функции, тексты песен, интеграция подкастов, улучшенный поиск), разделили на 3 спринта, начали делать по порядку. Подход, основанный на результатах: проанализировали, в какие моменты люди перестают слушать музыку. Оказалось — когда заканчивается любимый плейлист и начинается случайная подборка. Сделали одну функцию: умное продолжение плейлистов на основе предпочтений. Время прослушивания выросло на 23%. Остальные 14 функций оказались не нужны.
Шаг 1: Привязка каждой функции к гипотезе
Каждую задачу в бэклоге связываете с конкретным предположением об изменении поведения:
— Плохо: «Добавить темную тему»
— Хорошо: «Если добавим темную тему, пользователи будут проводить в приложении больше времени вечером, потому что меньше устают глаза. Ожидаем рост продолжительности вечерних сессий на 15%»
Шаг 2: Определение измеримых результатов
Для каждой гипотезы выбираете метрику, которая покажет успех или провал:
— Конкретная: «Увеличить вовлеченность» → «Увеличить ежедневное время использования на 10%»
— Измеримая: «Улучшить пользовательский опыт» → «Увеличить индекс потребительской лояльности с 7.2 до 8.0»
— Временная: «Когда-нибудь повысить удержание» → «Повысить 7-дневное удержание на 5% к концу квартала»
Шаг 3: Измерение после запуска
После релиза измеряете результаты, не выпуски. Если результат не достигнут, функция считается провальной, даже если технически идеальна и пользователи ее используют.
Пример: Команда электронной торговли добавила рекомендации товаров на главную страницу. Успех выпуска: функция работает без ошибок, 60% пользователей кликают на рекомендации. Провал результата: коэффициент конверсии не изменился, потому что рекомендации показывали товары, которые люди и так собирались купить. Функция технически успешна, но бизнесу бесполезна.
RICE, ориентированный на результаты: В параметр влияния подставляете не «сколько пользователей затронет», а «насколько изменится целевое поведение». Если функция не меняет поведение — влияние = 0, независимо от охвата.
Пример RICE с результатами:
— Обычный RICE: Охват = 10,000 пользователей, Влияние = 3 (средний), Уверенность = 80%, Усилие = 2. Оценка = 12.
— RICE с результатами: Охват = 10,000 пользователей, Влияние = 0 (не изменит ключевое поведение), Уверенность = 80%, Усилие = 2. Оценка = 0.
Цели и ключевые результаты, ориентированные на результаты: Ключевые результаты формулируете в терминах изменения поведения, не завершения задач:
— Плохой ключевой результат: «Запустить 5 новых функций»
— Хороший ключевой результат: «Увеличить принятие функций новыми пользователями с 40% до 60%»
ICE с результатами: Влияние оцениваете по воздействию на метрики результатов, не по субъективному ощущению важности.
Поведенческие результаты (изменения в действиях пользователей):
— Примеры: больше времени в продукте, чаще используют ключевые функции, приглашают коллег
— Как приоритизировать: функции, которые делают желаемое поведение проще/быстрее/приятнее, получают приоритет
Бизнес-результаты (изменения в бизнес-метриках):
— Примеры: выше конверсия, больше дохода на пользователя, ниже показатель оттока
— Как приоритизировать: прямая связь с отчетом о прибылях и убытках — чем больше влияние на прибыль, тем выше приоритет
Результаты удовлетворенности клиентов (изменения в восприятии продукта):
— Примеры: выше индекс потребительской лояльности, меньше обращений в поддержку, лучшие отзывы в магазине приложений
— Как приоритизировать: опережающие индикаторы для бизнес-результатов — довольные пользователи позже приносят больше денег
Пример иерархии: Финтех-приложение.
Результат удовлетворенности клиентов: снизить количество обращений в поддержку о непонятных транзакциях.
Поведенческий результат: пользователи чаще читают описания транзакций.
Бизнес-результат: меньше возвратных платежей и споров.
Приоритет получают функции, которые делают описания транзакций понятнее.
Ловушка 1: Оптимизация неправильных результатов
Можете оптимизировать метрику, которая не коррелирует с долгосрочным успехом продукта.
Пример: Команда новостного приложения оптимизировала время чтения. Алгоритм начал показывать статьи-приманки, потому что они держат внимание дольше. Время чтения выросло, но удовлетворенность пользователей упала — люди чувствовали, что тратят время впустую.
Решение: Балансирующие метрики. К времени чтения добавили индекс потребительской лояльности и коэффициент возврата. Если основная метрика растет, а балансирующие падают — стратегия неправильная.
Ловушка 2: Краткосрочные против долгосрочных результатов
Фокус на квартальных результатах может навредить долгосрочному здоровью продукта.
Пример: Приложение социальных медиа хотело увеличить количество ежедневных постов на пользователя. Добавили агрессивные подсказки и уведомления. Посты на пользователя выросли, но через полгода пользователи стали жаловаться на спам, удержание упало.
Решение: Портфель результатов. 70% фокуса на краткосрочных метриках, 30% на долгосрочных индикаторах здоровья.
Ловушка 3: Корреляция против причинности
Можете приоритизировать функции, которые коррелируют с результатами, но не являются их причиной.
Пример: Анализ показал, что пользователи с загруженной фотографией профиля имеют удержание в 2 раза выше. Команда сделала загрузку фото обязательной при знакомстве с продуктом. Удержание не изменилось — фото было следствием вовлеченности, а не причиной.
Решение: А/Б тестирование гипотез о причинности, не только анализ корреляций.
От фабрики функций к фабрике результатов: Команды перестают праздновать завершение задач и начинают праздновать достижение результатов. «Мы увеличили конверсию на 15%» вместо «Мы закрыли все задачи в спринте».
От «сделаем и посмотрим» к «проверим и сделаем»: Прежде чем строить функцию, формулируете измеримую гипотезу. Если после релиза гипотеза не подтвердилась — это не провал команды, а ценное обучение.
От квартального планирования к непрерывной корректировке: Результаты можете измерять еженедельно, поэтому можете корректировать тактику, не дожидаясь конца квартала. Стратегические цели остаются, тактические подходы эволюционируют.
Пример культурного сдвига: В ретроспективе обсуждаете не «сколько очков истории закрыли», а «на сколько приблизились к целевому результату». Вопросы меняются: вместо «Почему задача заняла больше времени?» спрашиваете «Почему результат не достигнут и что можем изменить?»
Подходит, когда:
— Есть четкие измеримые метрики для успеха
— Можете проводить А/Б тесты для валидации причинности
— Бизнес-заинтересованные стороны понимают разницу между активностью и результатами
— Команда готова принять ответственность за бизнес-результаты
Не подходит, когда:
— Результаты очень отложены (корпоративный сегмент с длинными циклами продаж)
— Слишком много внешних факторов влияют на метрики
— Регулятивные требования определяют дорожную карту
— Команда не контролирует факторы, влияющие на результаты
Альтернатива для сложных случаев: Промежуточные результаты. Если нельзя измерить финальный бизнес-результат, измеряете промежуточные поведенческие изменения, которые исторически приводят к успеху.
Приоритизация, основанная на результатах, превращает продуктовую команду из исполнителей дорожной карты в достигателей целей. Это требует больше аналитического мышления и подотчетности, но дает гораздо лучшие бизнес-результаты и более высокую удовлетворенность команды.
