Продуктовое управление. Часть 2

Обновлено: 4 июл.

Это 2-й пост про продуктовое управление. 1-я часть доступна по этой ссылке

Содержание:

RICE & ICE

RICE

RICE — это метод приоритезации идей и особенностей, возможностей продукта. Аббревиатура включает 4 фактора, которые можно использовать для оценки установления приоритетов

  • Reach — это охват

  • Impact — влияние

  • Confidence — уверенность в вашей оценке охвата, влияния и трудозатрат

  • Effort — трудозатраты / усилия

  • Охват (Reach)

Чтобы избежать предвзятости, ответьте на вопрос: сколько пользователей затронут изменения за период?

По возможности, берите цифры из метрик, а не с потолка.

Пример

Сайт в среднем посещает 5000 человек в месяц, 50% посетителей заходят с мобильных устройств. Если мы хотим сделать адаптивную версию, то охват составит 5000 х 0,5 = 2500 человек в месяц

  • Влияние (Impact)

Фокусируйтесь на проектах, которые действительно приближают вас к цели, оказывая влияние на ваших пользователей или клиентов.

Компания Intercom разработала пятиуровневую систему оценки для оценки воздействия проекта:

  • 3 = массивное воздействие;

  • 2 = сильное воздействие;

  • 1 = среднее воздействие;

  • 0,5 = слабое воздействие;

  • 0,25 = минимальное воздействие.

Да, оценка субъективна, но такой подход всё же лучше невысказанных ощущений.

Именно поэтому важно регулярно проводить обзоры и учиться.

Ценность понимается по-разному в каждом продукте или проекте. Оценивать влияние можно по следующим критериям:

  1. Улучшают конверсию из "пробной" версии, в платную

  2. Помогают привлечь новых пользователей

  3. Помогают сохранить текущих пользователей

  4. Добавляют ценности продукту и отстраивают нас от конкурентов. Ищем возможности, которые могут дать нам конкурентное преимущество, создадут причину, по которой клиенты конкурентов перейдут к нам. Это конкурентное преимущество должно быть уникальным, трудно повторяемым и, в идеале, не воспроизводимым.

  • Достоверность (Confidence)

Насколько вы уверены в своих оценках? Оценки, не основанные на метриках, могут ввести вас в заблуждение. Таких заблуждений лучше избегать, оценивая достоверность полученных оценок, где 100% = высокая достоверность, 80% = средняя достоверность, 50% = низкая достоверность. Достоверность ниже 50% — тревожный сигнал. Не принимайтесь за этот проект, если не хотите сыграть в рулетку. Примеры: Проект A: У менеджера продукта есть количественные показатели для влияния фичи, и оценка трудозатрат. Таким образом, проект получает 100% -ную оценку уверенности.

Проект B: У менеджера продукта есть данные по охвату и трудозатратам, но он не уверен в отношении фактора влияния. Проект получает коэффициент доверия в 80%.

Проект C: Данные охвата и влияния могут быть ниже, чем предполагалось. Трудозатраты могут быть выше. Проект получает 50%-ную оценку доверия.

  • Effort (Трудозатраты)

Трудозатраты оцениваются как количество «человеко-месяцев», недель или часов, в зависимости от потребностей.

Например:

Проект A займет около недели планирования, 2 недели дизайна и 3 недели для разработки, поэтому трудозатраты составят 2 человеко-месяца.

Для проекта B потребуется только 1 неделя планирования, 1-2 недели для разработки и не потребует дизайна. Трудозатраты будут равны 1 человеко-месяцу.


Ниже файл для проведения расчета от разработчика методики Intercom.com

RICE scoring example spreadsheet
.xlsx
Download XLSX • 100KB

Метод оценки ICE

Первоначально ICE был предназначен для приоритtзации экспериментов по росту. Позже ICE стали использовать и для приоритезации дополнений

Рассчитайте оценку для каждой фичи или идеи, согласно формуле:

  • Impact / Влияние показывает, насколько ваша идея положительно повлияет на ключевой показатель, который вы пытаетесь улучшить.

  • Easy / Легкость реализации — это о простоте реализации. Это оценка того, сколько усилий и ресурсов требуется для реализации этой идеи.

  • Confidence / Уверенность показывает, насколько вы уверены в оценках влияния и легкости реализации.

В ICE используется шкала от 1 до 10 чтобы все факторы сбалансированно влияли на итоговый бал. Вы можете подразумевать под 1-10 то что вам нужно, лишь бы значения были согласованы между собой.

ICE Scoring подвергается критике за его субъективность:

  • одна и та же доработка может оцениваться по-разному одним и тем же лицом в разное время. Это может повлиять на окончательный список приоритетов.

  • если дополнения оценивают разные люди — все они будут оценивать ее по-разному.

  • члены команды, которые хотят, чтобы их идеи были приоритетными, могут манипулировать результатами, чтобы получить одобрение

Ссылки:

  1. Фреймворк RICE для приоритезации

  2. RICE и ICE Scoring: простые техники приоритезации для продвинутых менеджеров продукта

  3. 12 методов приоритезации продуктовых целей: RICE, WSJF, KANO и прочие

Видео:

WSJF - Weighted Shortest Job First

Более Ценная и Короткая Работа Сначала — Weighted Shortest Job First - метод приоритезации последовательности работ в потоке, обеспечивающий максимальную экономическую выгоду.

В итоге получаем ранжированный список задач, где первая — самая простая в реализации, но при этом и самая ценная с точки зрения бизнеса.

https://onagile.ru/trends/lean-startup/backlog-prioritization-technique-weighted-shortest-job-first

Метод расчета

Шаг 1: Посчитать Cost of Delay

Чтобы подсчитать общий балл Cost of Delay, каждый компонент нужно оценить по шкале. Можно применять шкалу или от 1 до 10, или последовательность Фибоначчи - каждая следующая величина равна сумме двух предыдущих: 1, 2, 3, 5, 8...

Ценность для клиента/бизнеса (User-Business Value) — показывает, насколько выполнение конкретной задачи будет полезно клиентам и бизнесу.

Фактор времени (Time Criticality) — насколько критично выполнить задачу прямо сейчас? Чтобы опередить конкурентов, успеть к установленному сроку или открыть возможность для работы над связанными задачами.

Снижение рисков или реализация возможностей (Risk Reduction or Opportunity Enablement) — фактор, отражающий, как выполнение конкретной задачи снизит риски или какие возможности откроет.

Шаг 2: Посчитать Job Size

Затем потребуется определить шкалу для оценки объёма работы, которую надо выполнить для каждой Вашей идеи или инициативы. Шкала может отличаться от шкалы Cost of Delay, главное чтобы она была единой для всех инициатив.

Определить этот параметр может быть непросто. Он будет различаться в зависимости от тех ресурсов, которые у вас есть прямо сейчас, наборов скиллов в команде, зависимостей и внешних факторов. Но ваша команда должна договориться и прийти к единой методологии, по которой можно оценить каждую инициативу. Те из них, что получат наименьшую оценку по job size, станут для вас приоритетными.

Шаг 3: Разделить Cost of Delay на Job Size

Поделить 1-й параметр на 2-й и ранжировать инициативы по баллам от большого к меньшему

Например, если оценили для одной инициативы Cost of Delay в 9, а Job Size в 1, балл будет 9

Если у другой инициативы при этом Cost of Delay = 7, Job Size = 4, ее балл — всего 1.75

Плюсы метода WSJF:

  • Позволяет задать правильные вопросы для определения приоритетов в разработке ПО для крупных компаний.

  • Исключает когнитивные искажения в процессе расстановки приоритетов.

  • Его легко выстроить в соответствии с потребностями вашего бизнеса, так как вы можете создать шкалу, соответствующую вашим целям.

Минусы метода WSJF:

  • Потребуется время и много переговоров со стейкхолдерами, экспериментов и опытов, чтобы добиться оптимальной шкалы для вашего бизнеса.

  • Придётся постараться, чтобы получить все числа и использовать формулу.

  • Задачи с неясными и масштабными требованиями будут откладываться в пользу задач с понятной оценкой, что не всегда хорошо для бизнеса

Ссылки:

  1. Более Ценная и Короткая Работа Сначала — Weighted Shortest Job First, WSJF

  2. WSJF или приоритезация, когда все вокруг — «сложно»

  3. Модель приоритизации бэклога WSJF

Видео:

Модель Кано

Разработанная в 1980-х годах профессором Норияки Кано (Noriaki Kano), эта модель позволяет компаниям классифицировать функции своих продуктов на основании их ценности для целевой аудитории

Идея, которая лежит в основной модели Кано состоит в том, что чем больше времени, денег и усилий вы тратите на то чтобы создать, внедрить и улучшить функции из каждой категории, тем выше будет уровень удовлетворенности пользователей.

На горизонтальной оси слева размещаются потребности, которые вообще не удовлетворены, справа те, которые удовлетворены полностью.

Вертикальная ось отражает уровень удовлетворенности пользователя. Шкала функциональности показывает, насколько хорошо реализована функция, от «не реализована вообще» до «полностью реализована».

Как это выглядит в сборе:

Есть 2 вида модели:

  • Калифорнийская, "упрощенная", для молодых компаний

  • Японская, полная, для стабильных компаний

Калифорнийская разделяет функции на 3 категории:

  • Обязательные или базовые функции. Если у вас нет их - клиент не станет рассматривать Ваш продукт.

  • Функции производительности: чем больше Вы инвестируете в их развитие, тем выше будет уровень пользовательской удовлетворенности.

  • Восхищающие функции: пользователь их не ожидает, но они вызывают у него восторг

Японская немного точнее, там 5 категорий

  • линейные, одномерные функции (Satisfiers, One-Dimensional, O) – как правило, нефункциональные характеристики, например, скорость работы, процент отказов и проч.; тут все просто – чем выше характеристики, тем выше удовлетворенность, зависимость линейная;

  • обязательные, базовые функции (Basic, Must-be, M) – правый нижний угол графика, те функции, без которых продукт в принципе не будет иметь смысла для пользователя;

  • привлекательные функции, вызывающие восторг (Delighters, Attractive, A) – правый верхний уровень графика, те функции, которые вызывают “вау эффект” и желание купить или использовать продукт, которые отличают его от конкурентов;

  • неважные функции (Indifferent, I) – левый верхний угол графика, те функции, которые большинству пользователей совершенно безразличны, будут – хорошо, нет – никто не заметит;

  • нежелательные функции (Reverse, R) – левый нижний угол графика, те функции, которые вызывают у пользователя раздражение или неприятие (даже если продакту они сильно нравятся).

Пример из ресторанного бизнеса:

  • Обязательная (или базовая) потребность — чтобы ресторан был чистым, а блюда подавались вовремя. Без этого пользователи не смогут быть удовлетворены.

  • Нормальная (или производительная) потребность: в ресторане вкусно кормят.

  • Восхищающая (или привлекательная) потребность: в ресторане предлагают бесплатные угощения с заказом.

  • Безразличная потребность: в ресторане есть терминал самообслуживания.

Модель Кано полезна, если Вам надо приоритезировать функции продукта, основываясь на пользовательском восприятии ценности. Восприятие — ключевое здесь слово. Если пользователь живет в пустыне, его не вдохновит дождевик. Если вы хотите использовать модель Кано, нужно хорошо знать своего клиента.

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

Опросник должен включать вопросы:

  • Если бы у вас был доступ к такой функции, что бы вы чувствовали?

  • Если бы у вас не было доступа к такой функции, что бы вы чувствовали?

И такие варианты ответов:

  • Мне это нравится

  • Я ожидаю этого

  • Мне все равно

  • Я смог бы с этим мириться

  • Мне это не нравится

Затем собираем все функции (присутствующие или отсутствующие) в таблицу оценки:

  • Привлекательная – эта фича не ожидается, но нравится клиентам

  • Обязательная – обязательная функция, клиенты недовольны когда ее нет

  • Результативная – пользователям нравится наличие и не нравится отсутствие этой функции

  • Безразличная – клиентам безразличны к данной функциональности или готовы потерпеть ее отсутствие/наличие

  • Спорная – противоречивый и конфликтующий фидбек от клиентов

  • Неодобряемая – клиентам нравится отсутствие функциональности и не нравится когда она присутствует

Плюсы приоритезации по модели Кано:

  • Помогает команде перестать переоценивать фичи восхищения и недооценивать обязательные функции.

  • Помогает команде принимать лучшие продуктовые решения и строить прогнозы по рынку в соответствии с ожиданиями аудитории.

Минусы приоритезации по модели Кано:

  • Возня с опросником может занимать много времени. Чтобы охватить достаточно клиентов, нужно провести количество исследований, пропорциональное числу ваших пользователей.

  • Клиенты могут не до конца понимать функции, о которых вы их спрашиваете.

Ссылки:

  1. Объяснение модели Кано: анализ и примеры

  2. Японская и Калифорнийская модели Кано

  3. Модель Кано и анализ Кано – почему это круто и как использовать

Видео:

HEART

Фреймворк HEART (Happiness, Engagement, Adoption, Retention и Task Success) был создан в Google и используется чаще всего в digital-сфере. Позволяет отслеживать опыт пользователя (для него часто используется обозначение UX, User Experience) по определенным категориям: счастье, вовлечённость, принятие, удержание, успех (выполнения задач).

Он является частью Data Informed подхода

В него не входят конкретные метрики, поэтому их придётся продумывать индивидуально. Это неслучайно, потому что для различных продуктов важны разные показатели.

HEART разделяет все метрики на 5 категорий

1. Happiness (Счастье)

К метрикам счастья относятся, к примеру:

  • пользовательское удовлетворение;

  • ощущение, что продуктом легко пользоваться

2. Engagement (Вовлечение)

К примеру:

  • количество визитов пользователя в неделю;

  • количество фото, загружаемых юзером в день;

  • количество лайков и отправления ссылок (шэров)

3. Adoption (Принятие)

К принятию можно отнести:

  • обновления до новой версии;

  • созданные пользователем подписки;

  • покупки сделанные новыми пользователями в приложении.

4. Retention (Возвращаемость)

Конкретными метриками здесь могут быть:

  • количество пользователей, остающихся активными с течением времени

  • повторные покупки

5. Task Success (Успех ключевых задач)

Ключевыми задачами могут, к примеру быть:

  • успешные поиски;

  • время загрузки фотографии;

  • полностью заполненный пользователем профиль.

Необязательно пытаться придумать важные для вашего продукта метрики во всех этих категориях. HEART — о том, чтобы выбрать 1 или 2 по настоящему важных и на какой-то период сконцентрировать внимание именно на них.

Цели

Для каждой категории команда генерирует цели, из которых в работу берут 1-2 ключевые. Приоритеты определяют, опираясь на общую стратегию и актуальные бизнес-цели в текущей период: год, квартал, месяц.

Когда есть цель, можно сформулировать задачу: что конкретно нужно изменить в продукте, чтобы её достичь. После — выдвинуть гипотезы и выбрать наиболее подходящие для реализации.

Сигналы

Сигнал — это то, что в поведении пользователей укажет на успех или неудачу в достижении цели

Метрики

Метрика — это численное измерение сигнала во времени

Пример использования фреймворка