Как убедиться, что мы не расходуем зря время коллег и ресурсы компании, а занимаемся по-настоящему важными делами?

Представим себе, что мы организовали мозговой штурм, изобрели множество путей усовершенствования продукта и сбора обратной связи. Теперь мы в состоянии создать дорожную карту развития продукта. Но в какой последовательности всё это реализовывать? Нужно установить приоритеты.

Таких гипотез будет много. Будем определять приоритетность каждой из них, чтобы ранжировать их в том порядке, который будет определять последовательность разработки продукта.

1. Работать над своими идеями приятно, над чужими — не особенно.

2. Интереснее фокусироваться на идеях, чем думать в категориях глобальной целеполагания.

3. Увлекательно разрабатывать новые идеи, знакомый и продуманный проект — скучно.

4. Тяжело держать в уме детали различных частей большого проекта.

1. Как часто возникает проблема? (число обращений)

2. Сколько пользователей затронуто? (процент пользователей)

3. Насколько это важно для пользователя? (серьёзность проблемы)

4. Есть ли способ решить эту проблему вручную? (сложность решения)

5. Сколько ресурсов потребуется, чтобы решить проблему? (человеко-часы)

6. Можно ли применить решение к другим проблемам? (эффект от решения)

Скольким пользователям мы улучшим жизнь?

Измеряется количеством людей/событий за определённый период времени. Важно использовать реальные метрики.

Например, «функцией будет пользоваться 800 пользователей в месяц» или «1000 пользователей участвуют в онбординге, и 70% (700 пользователей) увидят эту функцию».

Насколько сильно мы улучшим жизнь нашим пользователям?

Например, в компании Hygger (B2B SaaS) для текущего квартала функции получают высокую оценку, если они:

1. Улучшают trial-to-paid конверсию. 2. Помогают привлечь новых пользователей. 3. Помогают сохранить текущих пользователей (например, не менее 15% удержания) 4. Добавляют ценности продукту и отличают нас от конкурентов (влияние сложно измерить; используются условные шкалы, например, пятибалльная).

Насколько мы убеждены в том, что действительно можем что-то улучшить? Если вы полагаете, что функция может оказать значительное влияние, но у вас нет подтверждающих данных, Confidence помогает урегулировать этот аспект. Измеряется в процентном соотношении.

Проект A: у руководителя продукта имеются количественные данные об эффекте функции и оценка затрат на труд. Следовательно, проект получает 100%-ную оценку уверенности.

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

Проект C: данные об охвате и влиянии могут оказаться ниже ожидаемых. Затраты на труд могут превысить расчёты. Проект получает оценку доверия в 50%.

● UX-исследования; ● опросы; ● интервью; ● наблюдения; ● MVP; ● A/B-тесты; ● внешние исследования; ● аналитика; ● личные убеждения; ● глобальные тренды; ● мнения команды, экспертов, руководителей; ● «все конкуренты это делают»; ● обращения в поддержку; ● запросы от менеджеров по продажам; ● запросы от клиентов.

Если гипотеза является лишь вашим собственным мнением, то её значимость минимальна. Поэтому, прежде чем отправлять что-либо на разработку, важно обдумать, как проверить реальную необходимость этой функции, и возможно ли её реализовать с минимальным участием программистов.

Как много времени потребуется нам для воплощения наших планов в жизнь? Затраты на труд измеряются в «человеко-часах».

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

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

Это степень лёгкости, с которой можно реализовать идею: сколько усилий и ресурсов требуется.

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

Влияние: насколько эффективной будет эта функция? Что она принесёт нашим пользователям и как повлияет на их цели и задачи?

Лёгкость реализации: насколько просто будет разработать, протестировать и запустить эту функцию?

Уверенность: как я могу быть уверен в том, что эта функция даст ожидаемое улучшение, как описано в Impact, и потребует указанное количество времени?