Как не передраться в команде при выборе тестируемых гипотез

Опишем типичную команду.

• Вася — идейный вдохновитель и по совместительству ПМ. Вдохновляется деньгами и крутостью своих гениальных идей.
• Петя — дизайнер. Петя любит, чтобы было красиво и удобно пользователю.
• Стёпа — разработчик. Стёпе нравится, когда задачи интересные и чётко сформулированы.
• Григорий — еще один разработчик. Желаниями очень походит на Стёпу.
• Анатолий — инвестор. Толя тоже любит деньги и когда они окупаются.

К примеру, команда занимается созданием и развитием сайта для обмена видеоконтентом.

Обсуждение гипотез.

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

Что происходит:

• Вася говорит, что придумал классную фичу, которая должна подбирать релевантный контент на базе нейросетей.
• Петя говорит, что пока сервис некрасивый — никто им пользоваться не будет и нужно переделать все внутренние и внешние страницы в новом дизайне, который он отрисовал вчера.
• Стёпа и Григорий топят за архитектуру, припоминая, как в последний раз, когда договорились сделать “по-быстрому, а потом переделаем” так и не дали время на переделать.
• Анатолий настаивает сделать то, что можно сделать побыстрее, чтобы заработать денег.

Приоритизация гипотез.

Знакомая картина? Нам тоже приходилось присутствовать на таких встречах в разных командах и чтобы избежать “перетягивания одеяла”, есть универсальная методика приоритизации гипотез и задач - методика ICE Scoring. Только осмысленный подход к приоритетам позволит добиться результата в создании продукта. Автором методики ICE является Шонн Эллис, автор термина Growth Hacker.

Суть метода заключается в оценке каждой фичи, будь то редизайн, или внедрение сложного алгоритма, по трем параметрам по 10-бальной шкале:

(I) Impact — оценка влияния фичи на результат/целевую метрику;

(C) Confidence — вера в результат;

(E) Ease — простота реализации.

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

Ну а мы — всегда за высокоприоритетные фичи, которые мы можем помочь вам реализовать с furnas.ru :)

Пример расчетов.

Гипотезы.

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

Оцениваем.

1 гипотеза:

• влияние на целевую метрику: 5
• вера в результат: 3
• простота реализации: 4

2 гипотеза:

• влияние на целевую метрику: 7
• вера в результат: 7
• простота реализации: 3

3 гипотеза:

• влияние на целевую метрику: 3
• вера в результат: 3
• простота реализации: 9

Перемножив все метрики получаем:

1 гипотеза: 60

2 гипотеза: 147

3 гипотеза: 81

В первую очередь стоит делать гипотезу №2