Epic Growth — рост продуктов
27.7K subscribers
1.37K photos
139 videos
5 files
1.91K links
Канал про рост IT-продуктов и карьеру в продуктовой команде

Оформить подписку Epic+: https://bit.ly/subscription_epicplus

Платной рекламы НЕТ 🙅‍♂️

Техподдержка: @egconf_bot
Download Telegram
#оценка_гипотез #ICEscore
Денис Осипов, продакт менеджер ABBYY рассказал, как в их отделе Mobile App оценивали гипотезы на базе методологии ICE Score.
Вот стандартная формула подсчета ICE Score: Impact (влияние на продукт) * Confidence (уверенность, что это произойдет) * Ease (простота внедрения фичи).

Что пытались решить?

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

В компании начали не со скоринга, а с поиска проблем продуктов с помощью качественных исследований (интервью, опросы, отзывы) и поиска узких мест воронки (аналитика, Usability-исследования). Обычно оказывалось около пяти пользовательских проблем. И несколько «личных» проблем, вроде нехватки экономии, воронок в продуктах.
После этого формировалось не менее 10 гипотез решений на одну проблему.

Как вводили ICE Score?

Вот формула, которой пользовались в компании: аудитория продукта * сколько % увидят * сколько % воспользуется * сколько заплатит.
Здесь цель ICE Score — определить самые денежные фичи.

В чем смысл?

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

Но формула ICE Score делит твою гипотезу на 100 — и в итоге ставит на место. Эта методология заставляет тестировать гипотезы и выходить на более высокий уровень confidence.

С какими проблемами столкнулись?

У продуктов ABBYY не одна цель, а несколько, поэтому пришлось на каждую выстраивать свою ICE Score. Это оказался длительный и сложный процесс. В компании решили пользоваться оценкой гипотез только, если разработчик тратит больше трех дней на создание продукта. Также одной из проблем стали условия, влияющие на приоритеты разработки, но не вписывающиеся в модель.

Вдобавок ко всему, — сниженная объективность. Поэтому любая оценка проходит защиту перед всей командой, чтобы снять фильтр восприятия одного человека, который выстраивал ICE Score.

Итоги:

1) Поиск основных проблем
— Выделение самых срочных задач
— Формирование видения продукта

2) Оценка решений/гипотез
— Приоритезация
— Подтверждение

3) Груминг
— Избавления от фильтров восприятия
— Прозрачность

Подробности на видео митапа (с 47 мин): https://www.youtube.com/watch?v=B76mDTx2xnY&feature=youtu.be&fbclid=IwAR1kwC8_qsUexmJUHMVJiFhVYwFzqvpH2vJD7YInVWdTDH-HRVZZjIV_-xo