Ошибка приоритизации гипотез - Решение и исправление самых разных ошибок на TopOshibok.ru

Как приоритизировать продуктовые гипотезы на основе юнит-экономики: разбираем примеры

Время на прочтение
6 мин

Количество просмотров 13K

Дел у менеджеров по продукту всегда больше, чем ресурсов. Новые задачи приходят со всех сторон — от дизайнеров до маркетологов и CEO. Но если брать в работу все подряд, есть риск получить на выходе не то, что нужно для развития проекта, а то, что было «по фану» кому-то из коллег. Так, сооснователь KISSmetrics Хитен Ша признался, что его компания потеряла позиции на рынке именно из-за ошибок приоритизации. Как только у него появлялись новые идеи, подчиненные должны были бросить все и начать работу над ними. О вдумчивом распределении сил речь тогда не шла. Пока команда пыталась успеть за руководителем, конкуренты захватывали рынок и выпускали новые продукты.

Расскажем, как не допустить такого развития событий с помощью простых методик для приоритизации гипотез. Вообще говоря, эту тему часто поднимают на профильных конференциях и семинарах. Так, Мэтт Билотти, менеджер продукта в Drift, интерактивной маркетинговой платформы, которая заняла шестое место в рейтинге самых быстрорастущих компаний по версии Deloitte, поделился на Epic Growth SEASONS своим взглядом на то, как можно приоритизировать гипотезы на основе юнит-экономики. Он объяснил, в чем преимущества подхода и как его можно использовать в работе.

Источник: unsplash.com

Метод оценки задач ICE и его соседи

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

Такой метод оценки называется ICE — влияние (Impact), уверенность (Confidence), усилия (Effort). Он был придуман Шоном Эллисом, автором термина «Growth Hacking». Преимущество подхода — в его простоте: чтобы оценить задачу, достаточно присвоить значения от одного до десяти для каждого из факторов и вычислить ICE Score:

ICE Score = Impact*Confidence*Effort.

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

В отличие от него, так называемый RICE — охват (Reach), влияние (Impact), уверенность в оценке (Confidence), трудозатраты (Effort) — более сбалансирован.

RICE Score = (Reach*Impact*Confidence) / Effort.

Чтобы оценить фактор охвата, нужно рассчитать количество пользователей, которому придется столкнуться с изменениями в продукте. Фактор влияния обычно отражает ценность, которую фича приносит продукту. Для количественного выражения влияния используют шкалу множественного выбора (это такая модель выбора, когда нужно принять одно решение, но выбрать между тремя и более вариантами):

3 — массовое влияние;
2 — высокое;
1 — среднее;
0,5 — низкое;
0,25 — минимальное.

Оценка фактора уверенности всегда вызывает много вопросов. Если остальные показатели можно оценить достаточно точно, то как оценить уверенность? И как снизить субъективное влияние в процессе утверждения приоритетов? Можно использовать диаграмму Итамара Гилада, бывшего продакта в Google и Microsoft. На ней можно увидеть описание типичных фактов, на основе которых обычно рассчитывают значения параметра Confidence (личное мнение, экспертная оценка, идея коллеги, фича конкурента, результаты UX исследований, данные на основе интервью и др.). Предположим, ваша уверенность в успехе фичи основана на мнении кого-то из членов команды или личном мнении. Оценка этого фактора в таком случае будет около нуля.

Гипотезы, основанные на данных маркетинговых исследований, запросах пользователей, результатах юзабилити тестов получат низкий уровень уверенности (от 1 до 3). Если же вы, расставляя приоритеты задачам, делаете выводы на основе длительных исследований поведения пользователей, результатов запуска MVP, A/B-тестов и других достоверных данных, уровень уверенности может быть средним (от 3 до 7).

Источник: unsplash.com

Вообще говоря, есть много разных подходов для приоритизации задач, все зависит запросов и целей команды. Какие-то компании даже придумывают свои методы. Так, в Netflix используют DHM-подход, в котором гипотезы оценивают по трем критериям:

D — delight;
H — hard to copy;
M — margin.

На практике это означает, что нужно задать ряд вопросов относительно каждой гипотезы. Например, принесет ли прибыль ввод этой фичи? Будут ли пользователи удовлетворены изменениями? Насколько сложно будет конкурентам скопировать этот функционал? Для того, чтобы Netflix начали тестировать гипотезу, она должна соответствовать как минимум двум критериям DHM-модели, а лучше — всем трем.

Источник: unsplash.com

В блоге Ducalis.io мы нашли классную схему, в которой можно выбрать фреймворк для приоритизации исходя из запросов конкретно вашей команды. Помимо уже известных ICE, RICE, DHM, есть и другие подходы: REAN метод (Reach, Engage, Activate, Nurture), приоритизация на основе North Star метрики, матрица усилий (Effort Matrix), AARRR скоринг и др.

Альтернативный подход

Если возвращаться к команде Drift, то Мэтт Билотти говорит, что отказ от ICE стал возможным благодаря поиску альтернатив. В этом ему помог Дариус Контрактор, который в течение четырех лет развивал Dropbox, руководил отделом роста в Facebook Messenger, а теперь работает Head of Growth в Airtable. Он рассказал Мэтту про подход EVELYN.

Шаблон EVELYN bit.ly/evelyn-airtable

Drift вдохновились EVELYN и создали свою систему приоритизации. Суть в том, чтобы оценивать продуктовые гипотезы исходя из того, какую прибыль они могут принести компании. Для этого команда должна определить, что включает в себя весь путь пользователя и рассчитать юнит-экономику на каждом шаге воронки.

Когда вы построили весь путь пользователя и рассчитали экономику продукта, у вас появится перечень метрик. Это может выглядеть следующим образом:

UA — число привлеченных пользователей

Marketing costs — затраты на маркетинг

C1 — конверсия в первую покупку

Buyers — количество покупателей

AvP — средний чек

ARPC — средний доход на клиента (без учета маркетинговых затрат)

ARPU — средний доход на одного пользователя без учета маркетинговых затрат

ARPPU — доход с платящего пользователя за вычетом издержек

CAC — стоимость привлечения клиента.

CPA — стоимость одного привлеченного пользователя в начало воронки и др.

Более подробно о юнит-экономике можно почитать в блоге Даниила Ханина. В этой статье автор дает объяснение метрикам, которые упоминаются выше, можете начать с нее.

Специалисты Drift предлагают выбрать десять-двадцать метрик в денежном выражении, на которые вы можете влиять, внося изменения в продукт или маркетинг.

Затем сформулируйте гипотезы — благодаря каким действиям вы хотите увеличить или уменьшить выбранную метрику. Чтобы рассчитать, сколько гипотеза может принести компании, нужны следующие показатели:

— метрика, на которую вы хотите повлиять (в денежном выражении) (a);

— во сколько раз эксперимент может увеличить эту метрику (b);

— вероятность, что гипотеза сработает, в процентном выражении (c);

— количество дней, которое необходимо для реализации гипотезы (d).

Вот так выглядит формула:

Value per Day = (a * b * c) / d.

Из презентации Мэтта Билотти на Epic Growth SEASONS

Например, метрика влияния — ARPU, или средний доход с пользователя, составляет $1. Вы должны определить, во сколько раз эксперимент увеличит вашу метрику. Например, вы предполагаете, что ARPU станет не $1, а $20. Значит, opportunity size будет равен двадцати.

Предположим, вы уверены в успехе на 70%. Значит умножайте на 0,7. Если на реализацию идеи вам понадобится два дня, то полученное произведение цифр нужно разделить на два. Итого получаем: Value per Day = ($1*20*0,7)/2 = $7.

Таким образом, Value per Day метрика отражает, сколько дохода фича может сгенерировать за N потраченных на ее реализацию рабочих дней. Так как в нашем примере Value per Day составил семь долларов, а эксперимент занял два дня, ежемесячно фича будет генерировать доход в четырнадцать долларов ($7*2) до тех пор, пока метрика влияния не изменятся (в ходе новых экспериментов, например).

Источник: unsplash.com

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

Полезные источники по теме

Выступление Мэтта на Epic Growth SEASONS

Фреймворки по приоритизации задачЕще один список фреймворков для управления продуктами

Первоисточник RICE фреймворка в блоге Intercom

DHM подход к приоритизации гипотез от Netflix

Блог Даниила Ханина о юнит-экономике

Источник

Маркетинг

Подготовка к тестированию гипотез: от инсайта и идеи к созданию, сортировке и приоритизации гипотез

Сооснователь ecommerce-агентства KISLOROD

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

Содержание

Что такое инсайт, идея, гипотеза
Шаблон формирования гипотезы
Работа с идеями
Чек-лист формирования гипотезы
Приоритизация гипотез
Вывод

Что такое инсайт, идея, гипотеза

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

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

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

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

Шаблон формирования гипотезы

Мы разработали единый шаблон, по которому формулируем все гипотезы:

«Согласно данным из [Источника 1] (Скриншот подтверждения) и [Источника 2] (Скриншот подтверждения), если [Идея] для [Группы пользователей], то это приведет к росту следующих показателей: [KPI 1], [KPI 2], …».

В нашем примере гипотеза будет звучать так: «Согласно данным из отчетов Google Analytics, больше транзакций совершают те, кто пользуется онлайн-примеркой мебели. Необходимость этого функционала в онлайне-опросе отметили 74% покупателей. Если мы добавим в СТА выгоду и переместим кнопку ближе к слайдеру, это приведет к росту конверсии в клик (с функционалом будет взаимодействовать больше пользователей) и ARPU».

Работа с идеями

Сортировка идей

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

Один из таких параметров — достаточность источников. Должно быть как минимум два источника данных, подтверждающих работоспособность идеи. Такими источниками могут быть системы веб-аналитики, карта кликов, немодерируемое и модерируемое тестирование, юзабилити-тестирование, опрос, глубинное интервью и так далее.

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

Еще один момент, который обязательно вносим в таблицу — категория Just Do It (просто сделай это). Иногда в процессе работы выявляются настолько очевидные вещи, что их нет смысла тестировать. Например, какие-то проблемы с версткой или функционалом. В этом случае фиксируем проблему в таблице, чтобы не забыть ее исправить и ставим задачу разработчикам.

Приоритизация идей

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

Существуют разные фреймворки (системы) для расстановки приоритетов, например Additive. Система предполагает составление таблицы с важными для проекта условиями — возможность отследить основной показатель, масштаб охвата, доля отказов, ценность страницы, частота возникновения, серьезность проблемы, влияние трафика, размер выборки, легкость, «линия сгиба» и так далее.

Затем для каждой идеи нужно проставить 1 балл за соответствие условиям каждого параметра и 0 баллов за несоответствие. В итоге идеи наберут определенное количество баллов. С той, у которой баллов больше, нужно работать в первую очередь.

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

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

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

Отправьте заявку на юзабилити-аудит сайта прямо сейчас! Мы найдём точки роста конверсии и выявим барьеры, c которыми сталкиваются пользователи

Чек-лист формирования гипотезы

Чтобы гипотеза была оформлена правильно и толковалась всеми одинаково, нужно учитывать 6 важных моментов:

Формулируйте гипотезу по шаблону.
Указывайте дополнительные метрики, за которыми будете следить, чтобы избежать улучшения одних метрик за счет других.
Определите необходимое время теста, используя калькулятор размера аудитории.
Расставьте приоритеты, указав дополнительные параметры для скоринга гипотез.

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

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

ICE расшифровывается как Impact, Confidence и Ease. То есть Влияние, Уверенность и Легкость. Показатель влияния демонстрирует, насколько реализация гипотезы улучшит ключевую метрику. Показатель уверенности отображает вашу убежденность в том, что идея значимая и ее будет легко реализовать. Показатель легкости говорит о необходимом количестве ресурсов для внедрения гипотезы.

Формула расчета приоритета: ICE Score = Impact х Confidence х Ease.

Каждый участник команды оценивает все показатели от 1 до 10. Потом оценки участника перемножаются и суммируются с итоговым баллом других участников. В итоге получается ICE Score по гипотезе.

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

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

длительность проведения теста,
трудозатраты (стоимость) разработки вариации и проведения теста,
и другие.

Вывод

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

Получайте полезный контент от KISLOROD в любой из мессенджеров

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

Спасибо, что дочитали до конца.

Если информация была полезна, поделитесь статьёй. Вам не сложно, нам приятно

Шаблон построения гипотезы и ее компоненты

Гипотеза — утверждение, которое требует доказательства и потенциально может быть проверено с помощью эксперимента.

Гипотеза формулируется в виде: «если мы <описание изменений>, то это улучшит пользовательский опыт <сегмент пользователей> и <метрика> увеличится на <Х>%».

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

Описание изменений — что конкретно мы хотим изменить?
Сегмент пользователей — для кого делаем?
Метрика — как будем измерять успех?
Масштаб изменения метрики — какое изменение будем считать успехом?

Давайте разберем стандартную гипотезу по компонентам.

Шаблон гипотезы. Описание изменений

Самый удачный вариант для описания изменений — небольшой мокап, на котором любой участник команды быстро поймет, что конкретно для пользователя будет меняться. Это можно сделать как в специальных инструментах вроде Figma (если меняется UI) или Miro (если изменения касаются логики серверной части), так и нарисовав скетч от руки.

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

Шаблон гипотезы. Сегмент пользователей

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

Благодаря сегментации аудитории всем участникам команды проще понимать пользователей продукта. Сегментацию вовсе не обязательно (скорее, даже нежелательно) делать при помощи продвинутых ML-методов.

Например, мы в Flo делим пользователей на сегменты в зависимости от цели использования приложения. Цель использования мы уточняем на онбординге. Список сегментов (целей) мы определяли и подтверждали качественными исследованиями исходя из того, какую основную цель могут ставить перед собой пользователи в приложении.

Шаблон гипотезы. Ключевая метрика и иерархия метрик

В Flo мы опираемся на OKR компании при выборе метрик. KR на уровне компании представляют собой микс бизнесовых (монетизационных) и UX-метрик. Так мы изначально понимаем, какие именно показатели хотим улучшить. Это позволяет ограничить набор гипотез и выбирать только релевантные идеи.

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

Поэтому мы много инвестируем в единую иерархию метрик в компании, которая поможет:

разложить составные бизнес-метрики (например, LTV) на компоненты;
связать компоненты бизнес-метрик с продуктовыми;
выстроить несколько уровней продуктовых метрик в зависимости от их чувствительности.

уровни продуктовых метрик в зависимости от их чувствительности

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

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

Шаблон гипотезы. Прокси-метрики для оценки экспериментов

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

Сходство бинарных метрик можно оценивать с помощью коэффициента Жаккара. На иллюстрации видим, что метрика retained М1 (возврат во второй месяц после установки, отсчет с нуля) на 60% сходна с метрикой retained up to D7 (возврат между вторым и восьмым днем после установки). В первом случае нам надо ждать два месяца для того, чтобы получить оценку эффекта, во втором — восемь дней.

Не всегда очевидно, как работать с трейд-оффом между точностью и скоростью расчета. Принимать решение будет проще, если установить внутренний KPI по точности (сходству).

Шаблон гипотезы. Business vs. UX

В некоторых случаях оптимизация бизнес-метрик может вступать в противоречие с User Experience и общей ценностью продукта для пользователей. Например, если делать более агрессивную монетизацию.

Такие кейсы можно контролировать с помощью health-метрик, которые как раз отвечают за UX. Health-метрика, как правило, разнонаправлена с основной метрикой эксперимента (если это бизнес метрика), и главное — ее не «уронить».

Самый популярный пример health-метрики — Retention, но мы используем и другие метрики на разных уровнях иерархии. Например, часто смотрим «активацию» конкретной фичи приложения, чтобы быть уверенными, что изменения ее не обвалили.

Шаблон гипотезы. Масштаб изменения метрики

Мы пришли к одному из самых сложных вопросов — как определить потенциал изменения метрики.

На этапе приоритизации гипотез, как правило, сложно получить супер-достоверную оценку, поэтому надо стараться получить оценку примерную, которая может также быть подтверждена интуицией (об этом чуть позже).

Мы знаем сегмент аудитории, на которую должны повлиять изменения. Но откуда получить информацию об эффекте?

1. «Холодный расчет»
В некоторых случаях масштаб изменений можно просчитать. Например, перед запуском новой фичи можно опросить своих пользователей, насколько они заинтересованы в запуске новой Feature X. Исходя из этого, можно оценить интервал потенциальных конверсий и планируемый эффект.

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

3. Рыночное исследование
Иногда оценить эффект от изменения можно по косвенным признакам из рыночного исследования. Как правило, это касается гипотез с рынка, подсмотренных в каком-то виде у конкурентов или просто у других продуктов. В известных сервисах вроде AppAnnie мы можем посмотреть, какой эффект оказало обновление на верхнеуровневые метрики конкурентов. Желательно, чтобы это работало в обе стороны: берете гипотезу/фичу с рынка — обязательно посмотрите на ее влияние в том продукте, где она реализована.

4. Just Noticeable Difference (JND)
Мы можем предлагать что-то суперпрорывное и вообще ничего не понимать с точки зрения эффекта. Рекомендуем определить Just Noticeable Difference на каждом уровне иерархии метрик — масштаб изменений, который точно будет заметен на необходимом уровне. Тогда в случае запуска эксперимента вы всегда будете понимать, насколько он успешен.

Приоритизация гипотез для тестирования с помощью ICE

Мы научились формулировать гипотезы, но у нас их много, и нам надо понимать, как находить наиболее перспективные.

Мы пользуемся чек-листом из пяти пунктов, которые позволяют упростить выбор и найти хорошие гипотезы.

Итак, гипотеза хорошая, если:

потенциально решает реальные проблемы/задачи пользователей;
имеет обоснования из анализа данных, UX-исследования или исследования рынка;
связана с долгосрочной продуктовой стратегией;
приводит к заметному увеличению важных продуктовых метрик в иерархии;
сложность реализации адекватна потенциальному выигрышу.

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

На помощь нам приходит методика приоритизации ICE, которая поможет выстроить бэклог из гипотез.

Чек-лист легко превращается в элементы ICE:

решает реальные проблемы/задачи пользователей (I);
имеет подтверждение либо из анализа данных, либо из UX-исследования, либо из исследования рынка (C);
связана с долгосрочной продуктовой стратегией (I);
приводит к заметному увеличению метрик (I);
реализуется достаточно просто (E).

Мы в Flo используем Data Informed ICE: аналитики информируют команду о прогнозном Impact (влиянии изменения), но каждый принимает решение об оценке для ICE лично. Это позволяет привнести элемент продуктовой интуиции в процесс приоритизации и снижает разброс оценок, который бывает при отсутствии бейзлайна.

Получив бэклог из гипотез, мы идем далее по процессу:

Запускаем эксперименты. О том, как технически у нас реализован эксперимент-сервис, вы можете прочитать в статье продуктового менеджера нашей дата-платформы Кости Грабара.
Собираем необходимые данные и анализируем результаты.
Делаем выводы и принимаем решение о раскатке. Принять решение раскатывать ли тестовую группу на 100% не всегда так просто, как может показаться. Это может быть темой для отдельной статьи. От себя могу только рекомендовать еще до запуска эксперимента определять критерии его успеха — это снимет большую часть сомнений в результатах.

Именно так работают продуктовые команды Flo. Внутри два взаимосвязанных, никогда не заканчивающихся процесса: работа с гипотезами и экспериментирование.

Документирование — важный этап процесса приоритизации и тестирования гипотез

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

Сейчас приоритизацию мы храним и делаем в Google Sheets. Там же мы храним связь гипотез — сводную таблицу планируемых гипотез, которые влияют на одну Objective. Это не очень удобно. И мы в процессе поиска более удобного инструмента, который позволяет эффективно миксовать OKR, работу с гипотезами и результаты экспериментов.

С похожими проблемами столкнулись ребята из соседней статьи и разработали свой инструмент.

Результаты внедрения процесса работы с гипотезами

Мы работаем по описанному процессу уже несколько кварталов и можем отметить:

большую вовлеченность и заинтересованность членов команд в процесс планирования, разработки и анализа;
на 30% больше успешных экспериментов;
ускорение экспериментов, которые влияют на долгосрочные метрики, за счет использования прокси-метрик.

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

Об авторе

Дима Золотухин, Head of Analytics в компании Flo. Занимается дата-аналитикой 8 лет, с 2017 года — в продуктовых компаниях.

Контакты: Facebook, Telegram.

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

→ «Симулятор управления продуктом на основе данных» поможет научиться принимать решения с помощью данных и исследований при создании продукта (путь от 0 к 1).

→ «Симулятор управления ростом продукта» поможет найти пути управляемого роста и масштабирования продукта. Вы построите модель роста и составите стратегию развития продукта (путь от 1 к N).

→ «Симулятор SQL для продуктовой аналитики» поможет освоить SQL и применять его для решения продуктовых и маркетинговых задач.

→ «Симулятор управления ML/AI-проектами» научит применять технологии машинного обучения с пользой для бизнеса.

Не знаете с чего начать? Пройдите бесплатный тест для оценки навыков управления продуктом. Вы определите свои сильные стороны и слепые зоны, получите план профессионального развития.

Еще больше ценных материалов и инсайтов — в телеграм-канале GoPractice.

Источник

Дописал гипотезы для своего продукта (SaaS b2c) и настало время приоритезации.

1.8K
показов

373
открытия

Обычно приоритизирую гипотезы и задачи по методологии ICE. Она простая и можно быстро посчитать score. Но мне нужно учитывать охваты и трудозатраты. Поэтому перешел на RICE.

RICE — акроним, обозначающий:

Reach (Охват). Оценивает, сколько пользователей или клиентов затронет данная задача или гипотеза. Чем больше людей она затронет, тем выше оценка.

Например, новой функцией будет пользоваться 30%, от вашей аудитории, за месяц (1000 человек). Reach = 300. А другой функцией будут пользоваться 5% клиентов. Reach = 50.

Impact (Влияние). Оценивает, насколько сильно данная задача или гипотеза повлияет на пользователей. Это может быть выражено в улучшении метрик, повышении удовлетворенности или улучшении пользовательского опыта.

Для оценки, используют параметры:

3 — массовое влияние;
2 — высокое;
1 — среднее;
0.5 — низкое;
0.25 — минимальное.

Confidence (Уверенность). Оценивает степень уверенности в ожидаемых результатах. Оценка может быть основана на данных, исследованиях или экспертном мнении:

1 — высокая уверенность;
0.8 — средняя;
0.5 — низкая.

Если оцениваете ниже 0.5 — то это ваша «галлюцинация», которая в реальности не даст положительных результатов.

Effort (Усилие). Оценивает затраты, необходимые для выполнения. Измеряется в человека-месяцах. Если на реализацию нужна 1 неделя — пишем 0.25 (1/4 месяца). Нужно делать 6 месяцев — пишем 6.

Теперь считаем RICE Score, по формуле (R x I x C)/E

Чем выше RICE Score, тем больше шансов гипотезы/задачи, на успех. Например:

Гипотеза 1: (50 * 0.25 * 0.5 ) / 1 = 6.25
Гипотеза 2: (300 * 2 * 0.8 ) / 1.25 = 384
Гипотеза 3: (1000 * 1 * 0.5) / 0.25 = 2000

В итоге, проверяем гипотезы в порядке 3, 2, 1.

Где применять RICE?

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

Как итог приоритизации — экономия денег, времени, нервов.

RICE можно применить и для бытовых вопросов, например, выбор страны/места для переезда:

Рассмотрите параметры RICE. Оцените, какой охват у каждого потенциального места (Reach), доступности работы, образовательных учреждений, культурных объектов, природы, климата и т.д.
Оцените, какие позитивные изменения (Impact) оно может принести для вашей жизни и семьи.
Сделайте оценку своей уверенности (Confidence) в преимуществах места, основываясь на исследованиях и отзывах.
Наконец, учтите усилия (Effort) в виде финансовых затрат, подготовки документов и переезда.

Ваша субъективная оценка становится детализирование, вы задумываетесь о большем количестве параметров.

Источник

#Руководства

6 дек 2021
0

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

Разбираем методы поиска и приоритизации идей — матрицу Кано, RICE и другие. Присматриваемся к интересным гипотезам в «Яндексе», Netflix и «МегаФоне».

Кадр: мультфильм «Рик и Морти»

Редактор Skillbox Media. Пишет о бизнесе и маркетинге вместе с экспертами.

Руководитель проектов в «Сбере». Возглавлял направление по работе с партнёрами в «Яндексе», а также отдел консалтинга в компании QED. Работал в Microsoft. Эксперт курса «Customer Development» в Skillbox.

Без постоянного тестирования гипотез идеи маркетолога останутся непроверенными домыслами. Как искать сильные идеи и при чём здесь Customer Journey? Если гипотез много, то как выбрать самые важные? Разбираем в этом материале.

Что такое гипотеза и зачем её проверять
Как оценивать идеи и найти самые важные
«МегаФон» и Dota: интересные гипотезы от крупных компаний.

Маркетолог всегда «на острие»: он знает рынок, конкурентов, технологии, новые механики привлечения клиентов и продаж. При этом умеет адаптировать эти знания под нужды бизнеса. Чтобы это сделать максимально быстро и дешёво, подойдёт механизм проверки гипотез.

Гипотеза — это предположение о бизнесе, продажах или клиентах, которое можно подтвердить или опровергнуть в ходе исследования.

Разберём на примере: это будет маркетплейс фитнес-услуг, его название мы указывать не будем. Сервис соединяет клиентов, которые хотят заниматься спортом, и тех, кто эту возможность даёт: индивидуальных тренеров, фитнес-клубы и спортивные площадки.

Маркетолог компании решил пройти клиентский путь конкурента и притворился его покупателем. В результате маркетолог нашёл уязвимость в системе: клиент может найти услугу на маркетплейсе, а заказать её в обход сервиса. Тогда посредник становится не нужен ни продавцу, ни покупателю.

Чтобы избежать повторения ситуации у себя, маркетолог решил поменять процедуру подтверждения, что клиент пришёл на тренировку. Раньше для этой цели использовали QR-код — спортсмен наводил на него телефон и подтверждал посещение нажатием кнопки. Для пилотной группы из двух клубов эту механику отменили: теперь подтверждать посещение должен был тренер вручную.

Эксперимент увеличил показатели «доходимость» и «удовлетворённость», но сильно снизил количество регистраций на тренировки. Тренеры не хотели подтверждать их вручную и перестали приглашать спортсменов на новые. Гипотеза была признана провалившейся, и в компании стали искать другую схему валидации.

На каких стадиях развития бизнеса или продукта нужно тестировать гипотезы? Современный бизнес развивается быстро, поэтому лучше находить и проверять гипотезы на всех этапах: идея, анализ рынка, MVP, запуск, масштабирование, выход на новые рынки и так далее.

Так вы решите весь спектр маркетинговых задач: сможете исследовать рынок, сформировать ценностное предложение, привлекать и удерживать пользователей, сформулируете PR-стратегию. В методологии CustDev для этого используют HADI-циклы:

формулируем гипотезу;
проверяем;
собираем данные;
получаем выводы;
возвращаемся на первый этап.

В HADI-циклах процесс тестирования гипотез непрерывен.

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

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

Чтобы найти гипотезы, нужно проанализировать клиентский путь в нашей компании и пути у конкурентов, тип рынка и каналы продаж. В этом поможет инструмент Customer Journey Map.

На этом этапе мы можем предложить тезисы, которые проверим в ходе дальнейших интервью и экспериментов.

Вот что включает правильно сформулированная гипотеза:

Утверждение о нашем пользователе, продукте, рынке, бизнес-функциях компании или несколько из этих пунктов.
Точки или схемы для возможных улучшений («быстрее», «дешевле», «качественнее»).

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

Давайте разберём несколько популярных моделей.

Метод предполагает, что каждую фичу или инициативу нужно оценить по трём параметрам:

«влияние» (impact) — насколько сильно фича может изменить целевую метрику;
«достоверность» (confidence) — насколько сильно мы уверены в результате;
«усилия» (effort) — насколько просто внедрить инициативу.

Иногда модель ICE расширяют до RICE, добавляя ещё один индикатор — «охват» (reach). Он показывает, какое число пользователей или клиентов будут затронуты изменением.

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

Методы ICE/RICE хорошо работают, когда нужно запустить новый продукт на существующем рынке. Если вы хотите внедрить дополнительный канал обслуживания клиентов и собираетесь проверить гипотезы о том, как клиенты привыкли получать сервис в данный момент, — ICE-/RICE-методы также подойдут. Степень их субъективности и сложности для этого достаточна.

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

В основе метода — матрица 2×2, изображённая на рисунке ниже. Она помогает принимать решения и определять что важно, что рискованно и в каком направлении нужно сосредоточить свои усилия. Предприниматели в стартапах часто используют эту матрицу для расстановки приоритетов при разработке продукта. Метод Lean также используют для оценки бизнес-моделей.

Инфографика: Майя Мальгина для Skillbox Media

Lean Prioritization используют и в концепции «новый продукт на новом рынке». Если рынок вам незнаком, метод поможет запланировать цепочку действий, направленных на то, чтобы понять, какие проблемы в целом на нём есть и у каких групп клиентов они возникают.

Цель метода — понять эмоциональную реакцию потребителей на разные характеристики продукта. Методологию применяют для совершенствования товаров и услуг и повышения удовлетворённости клиентов.

Матрица представляет собой график с двумя осями: «функциональность» и «удовлетворённость». Используя эти оси, нужно разбить функции продукта на пять категорий:

Обязательные: без них продукт работать не будет. Пример — руль автомобиля. Но если обязательные функции работают хорошо, это не приводит к высокому уровню удовлетворённости клиентов — они рассматривают такое положение вещей как должное.
Одномерные: уровень удовлетворённости атрибутом прямо зависит от его функциональности. Пример — производительность процессора.
Привлекательные. Они не обязательны для продукта, но добавляют ценность для потребителя. Пример — бесплатная доставка.
Неважные. Это функции, наличие которых никак не влияет на удовлетворённость пользователя.
Нежелательные. Характеристики продукта, для которых справедливо следующее правило: чем больше мы их развиваем, тем больше они снижают удовлетворённость пользователя. Например, дополнительные функции программы делают её сложнее, а покупателей они не интересуют.

Инфографика: Майя Мальгина для Skillbox Media

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

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

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

Как это выглядит на практике? Банк возьмёт за основу оценки гипотезы две группы показателей. Первая — это ключевые финансовые показатели: сколько денег будет заработано после внедрения гипотезы. Вторая — объём трудозатрат: сколько времени нужно потратить на разработку. К этим критериям он добавит риски: насколько велика вероятность что-то сломать в уже существующем бизнес-процессе.

Обратимся к примерам известных российских компаний. Пару лет назад компания «МегаФон» зашла на территорию киберспорта. Тема довольно сложная: если ты не геймер, то вряд ли станешь своим. Если ты их не понимаешь, будешь выглядеть нелепо. Аудитория со своей спецификой, закрытая, с ней сложно работать. Но в то же время, в другом пространстве её не достанешь.

«МегаФон» выбрал стратегию RedBull — «если приходишь на новую сцену, зайди изнутри и сделай так, чтобы тебя приняли». Для этого компания начала сотрудничать с ESforce — одним из крупнейших киберспортивных холдингов России. В итоге они сделали крупную совместную интеграцию, которая задействовала всю киберспортивную вселенную ESforce.

В коллаборации приняли участие блогеры и звёзды кибермира, под проект запустили онлайн-студию для освещения матчей в соцсетях и собственный кибертурнир «МегаФона». В итоге мультиканальное спонсорство охватило более 70% целевой аудитории.

Конкурс в рамках интеграции. Изображение: официальный сайт «МегаФона»

Гипотеза оправдалась, результат был виден на цифрах. По итогам исследования Ipsos Comcon, «МегаФон» стал самым заметным оператором в кибериндустрии. Компания победила с огромным отрывом — 24% против 5% у ближайшего конкурента.

Конечно, есть и неудачные примеры. Они встречаются даже в известных компаниях. Например, у «Яндекса» было огромное количество проектов, которые со временем пришлось закрыть. Один из них — «Антивирус», совместный проект с «Лабораторией Касперского».

Казалось, у проекта была хорошая идея — бесплатная «Яндекс-версия» «Антивируса Касперского». Срок действия бесплатной версии — шесть месяцев. Затем пользователи могли перейти на полную версию Kaspersky Internet Security или «Антивируса Касперского». Был и хороший бонус — при оплате «Яндекс.Деньгами» давали скидку 20%. Но в итоге проект закрылся. Как бывший сотрудник «Яндекса», не могу говорить много, но обозначу, что причина неудачи — в несостоятельной гипотезе о целевой аудитории.

А бывает и так, что гипотеза кажется провальной, но спустя время подтверждается и даёт бизнесу хороший рост. Так было у Netflix. Компания столкнулась с проблемой — крупные игроки вроде Disney и NBC перекрыли ей возможность показывать популярные фильмы и сериалы, авторскими правами на которые они владели.

Тогда Netflix в корне поменял стратегию. В сервисе решили инвестировать большие деньги в создание собственного оригинального контента.

В 2019 году Netflix потратил на контент 15 млрд долларов. Более 80% из них — на создание собственных сериалов и фильмов.

Расходы Netflix на собственный контент выросли с 6,88 млрд долларов в 2016 году до 17 млрд долларов в 2021. Инфографика: Statista

Сначала зрители не восприняли альтернативу, начались отписки. В июле 2019 года компания сообщила о самом низком квартальном росте подписчиков и о потере абонентов внутри США — впервые с 2011 года. После этого акции компании упали на 11%.

«Акции упадут ещё ниже, ведь всё больше инвесторов понимают, что у компании нет шансов приблизиться к cash flow, который приведёт к росту акций до 325 долларов», — вот что писал тогда Forbes.

Чтобы бороться с отписками и эффективно привлекать новых зрителей, в Netflix пошли на хитрость. Сделали бесплатный доступ к первым эпизодам оригинальных сериалов. Люди увлекались и оформляли платную подписку, чтобы досмотреть их до конца.

Сегодня акции Netflix стоят по 650 долларов — ровно в два раза больше суммы, в которую не верили в Forbes. Инвестиции в оригинальный контент оправдались. Только за первые два месяца оригинальный сериал «Ход королевы» посмотрело 62 млн человек, а сериал «Игра в кальмара» и вовсе побил абсолютный рекорд платформы — 111 млн просмотров за 27 дней с момента выхода.

Без проверки гипотез выводы маркетолога останутся домыслами.
Нужно искать и тестировать гипотезы на всех этапах развития бизнеса или продукта.
В поиске идей вам поможет анализ клиентского пути в вашей компании и в компаниях-конкурентах.
Нужно присваивать гипотезам приоритеты и проверять их по очереди.
Для экспертной оценки идей используйте ICE Score, Lean Prioritization или матрицу Кано.
Если у вас много данных, то можно использовать количественные методы.
Даже у лидеров рынка есть длинный список провалившихся гипотез.

Как зарабатывать больше с помощью нейросетей?
Бесплатный вебинар: 15 экспертов, 7 топ-нейросетей. Научитесь использовать ИИ в своей работе и увеличьте доход.
Узнать больше

Источник

Как приоритизировать продуктовые гипотезы на основе юнит-экономики: разбираем примеры

Метод оценки задач ICE и его соседи

Альтернативный подход

Полезные источники по теме

Подготовка к тестированию гипотез: от инсайта и идеи к созданию, сортировке и приоритизации гипотез

Что такое инсайт, идея, гипотеза

Шаблон формирования гипотезы

Работа с идеями

Сортировка идей

Приоритизация идей

Чек-лист формирования гипотезы

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

Вывод

Рекомендованные статьи

Шаблон построения гипотезы и ее компоненты

Шаблон гипотезы. Описание изменений

Шаблон гипотезы. Сегмент пользователей

Шаблон гипотезы. Ключевая метрика и иерархия метрик

Шаблон гипотезы. Прокси-метрики для оценки экспериментов

Шаблон гипотезы. Business vs. UX

Шаблон гипотезы. Масштаб изменения метрики

Приоритизация гипотез для тестирования с помощью ICE

Документирование — важный этап процесса приоритизации и тестирования гипотез

Результаты внедрения процесса работы с гипотезами

RICE — акроним, обозначающий:

Теперь считаем RICE Score, по формуле (R x I x C)/E

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