редакции
Как не передраться в команде при выборе тестируемых гипотез
Опишем типичную команду.
- Вася — идейный вдохновитель и по совместительству ПМ. Вдохновляется деньгами и крутостью своих гениальных идей.
- Петя — дизайнер. Петя любит, чтобы было красиво и удобно пользователю.
- Стёпа — разработчик. Стёпе нравится, когда задачи интересные и чётко сформулированы.
- Григорий — еще один разработчик. Желаниями очень походит на Стёпу.
- Анатолий — инвестор. Толя тоже любит деньги и когда они окупаются.
К примеру, команда занимается созданием и развитием сайта для обмена видеоконтентом.
Обсуждение гипотез.
Наступает час Х — момент, когда все собираются, чтобы определить планы на будущее.
Что происходит:
- Вася говорит, что придумал классную фичу, которая должна подбирать релевантный контент на базе нейросетей.
- Петя говорит, что пока сервис некрасивый — никто им пользоваться не будет и нужно переделать все внутренние и внешние страницы в новом дизайне, который он отрисовал вчера.
- Стёпа и Григорий топят за архитектуру, припоминая, как в последний раз, когда договорились сделать “по-быстрому, а потом переделаем” так и не дали время на переделать.
- Анатолий настаивает сделать то, что можно сделать побыстрее, чтобы заработать денег.
Приоритизация гипотез.
Знакомая картина? Нам тоже приходилось присутствовать на таких встречах в разных командах и чтобы избежать “перетягивания одеяла”, есть универсальная методика приоритизации гипотез и задач - методика ICE Scoring. Только осмысленный подход к приоритетам позволит добиться результата в создании продукта. Автором методики ICE является Шонн Эллис, автор термина Growth Hacker.
Суть метода заключается в оценке каждой фичи, будь то редизайн, или внедрение сложного алгоритма, по трем параметрам по 10-бальной шкале:
(I) Impact — оценка влияния фичи на результат/целевую метрику;
(C) Confidence — вера в результат;
(E) Ease — простота реализации.
После оценки каждой фичи по этим трем параметрам, перемножаем их и получаем итоговую оценку фичи. Чем оценка больше, тем выше приоритет гипотезы. А как же быть с разными мнениями? Тут тоже есть выход — если все пять участников процесса приоритизации не могут договориться, создайте анонимный опрос, например, в гугл докс и итоговой оценкой для фичи укажите среднее значение, которое указали все участники процесса.
Ну а мы — всегда за высокоприоритетные фичи, которые мы можем помочь вам реализовать с furnas.ru :)
Пример расчетов.
Гипотезы.
- Переверстав все страницы сайта, мы упростим путь пользователя до оплаты и увеличим конверсию из трафика в покупки.
- Добавив алгоритм подбора релевантного контента, мы увеличим "липкость" продукта и как следствие - клиенты будут жить с нами дольше.
- Изменив посыл на главной странице сайта, увеличим конверсию из трафика в регистраты.
Оцениваем.
1 гипотеза:
- влияние на целевую метрику: 5
- вера в результат: 3
- простота реализации: 4
2 гипотеза:
- влияние на целевую метрику: 7
- вера в результат: 7
- простота реализации: 3
3 гипотеза:
- влияние на целевую метрику: 3
- вера в результат: 3
- простота реализации: 9
Перемножив все метрики получаем:
1 гипотеза: 60
2 гипотеза: 147
3 гипотеза: 81
В первую очередь стоит делать гипотезу №2
