Скоринг фичей на основе метрик воронки. Funnel Scoring Model. Часть 1

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

Привет!

Меня зовут Юля Ранн, почти пять лет я была CPO в Level. travel, а до этого product owner’ом в Ведомостях и занималась аналитикой. А сейчас я помогаю разным компаниям развивать свои продукты и команды.

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

У нас были такие исходные данные:

1. Одной из важнейших стратегических целей компании был тюнинг основной продающей воронки.
2. Нам было важно говорить о задачах в деньгах и оперировать терминами трудозатрат и потенциальной прибыли, а не абстрактными поинтами.
3. Бэклог был огромен. Сотни гипотез об улучшениях, которые стекались от разных продуктовых команд в разных вертикалях.
4. У нас были ограниченны ресурсы для разработки, поэтому мы хотели, насколько это возможно, избежать ошибок планирования и минимизировать ущерб от неправильной приоритизации задач.
5. За эти ресурсы разработки конкурировали различные внутренние заказчики не только со стороны продукта, но и из других частей компании.
6. У нас было уже очень много качественных и количественных данных о том, что нужно клиентам, и так или иначе протестированных или проанализированных гипотез. Вопрос стоял в правильной приоритизации для передачи в разработку и создания MVP, а не о приоритизации идей ради их первичной проверки.

Из наших вводных растут определенные претензии к популярным эвристическим фреймворкам типа ICE.

• Опасно на этапе передачи в разработку.
  Быстрые методики вроде ICE хороши для первых прикидок, например о том, какие гипотезы проверять в первую очередь, особенно если проверка этих гипотез выполняется быстро и обходится дешево. Если же мы находимся на этапе, когда инициативы прошли первый этап проверки и надо принимать решения о том, какие задачи первыми пускать в разработку — здесь цена неверно принятых решений возрастает многократно.
• Субъективность скоринговых факторов.
  В ICE есть три фактора — Impact, Confidence, Effort — которые в классическом варианте оцениваются в баллах и процентах. Даже если решение о баллах принимается совместно группой людей на мозговом штурме, продакты или стейкхолдеры часто склонны переоценивать Impact тех фичей, в которые верят, и недооценивать те фичи, которые почему-то плохо понимают. Impact — слишком монолитный показатель.
• Сложность управления финмоделями фичей.
  Продвинутая версия ICE подразумевает оценку Impact и Effort в деньгах. Сама парадигма оценки в деньгах заставляет оценивающего глубже погружаться в аналитику, ответственнее относиться к цифрам и, фактически, рассчитывать мини-p&l для каждой из фичей. Однако уследить за тем, что все фичи были оценены в сравнимых моделях, и нигде никто не наделал расчетных косяков — бывает сложно, особенно, если в одном скоринге участвуют несколько продактов и несколько команд.
  Создавать эти универсальные правила игры и следить за их соблюдением — работа СРО. Но ему не позавидуешь, если чтобы разобраться, почему у одной фичи Impact составляет 100$, а у другой — 500$, придётся лезть в связанные документы с расчетами, отдельные для каждой фичи. Управлять этим нереально.
• Сложность презентации стейкхолдерам.
  Нельзя презентовать приоритизацию словами «Это классная методика, весь мир ей пользуется, просто доверьтесь мне и смотрите на баллы». Следующие вопросы от лиц, принимающих решение, будут про субъективность оценок и про то, как скоринговый балл соотносится с деньгами (cм. предыдущие пункты). Было бы отлично, если бы просто при взгляде на таблицу приоритизации все было понятно сразу.

В этой методике воронку мы представим как вот такую совокупность метрик:

На самом деле, всегда можно дотюнить модель до метрик, которые важны тому или иному конкретному бизнесу: например, от оборота перейти на маржинальность или прибыль, развить идею общей конверсии платформы до C1, C2…Cn и т. д.

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

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

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

Алгоритм работы с табличкой состоит всего из трех шагов:

1. Определяем группу переменных: На что влияет фича — на трафик, конверсию или чек?

2. Определяем конкретные переменные, на которые влияет фича: Если на трафик — на какие каналы? И насколько мотивированный трафик придет, с какой вероятностью он будет идти дальше по воронке? Если на конверсию — то на какой из шагов воронки? Или, возможно, фича влияет на чек?

3. Определяем силу влияния: каким в процентах будет изменение? Это изменение коснется всех пользователей или какой-то доли (нужно ли взвешивать этот показатель) ? На чем основан наш прогноз?

Пример того, как мы вводим фичу в скоринг:

Мы хотим добавить в поиск новый фильтр.

У нас есть гипотеза о том, что добавление нового фильтра в поиск поможет 15% людей, которые ищут именно этот фильтр и сейчас не находят его. Про 15% людей — это прикидка из обратной связи + данных о том, что люди вводят в поиск на сайте. Кроме того, нам известно, что люди, которые находят нужные себе фильтры типа такого (у нас есть фильтры в поиске, с которыми можно относительно без опаски сравнить новый) в среднем имеют конверсию в переход на карточку на 25% больше, чем те, кто не пользуется фильтрами.

Пройдем по алгоритму:

1. Мы здесь влияем на воронку, не на трафик.

2. Мы влияем на шаг из поиска в карточку товара (search2card)

3. Наше влияние оценивается в 15%*25%=3,75%. Это и пишем в соответствующую ячейку.

Это простой пример с одной переменной, поэтому здесь линейно получаем увеличение оборота на 3,75%. В реальной жизни чаще комбинируется влияние нескольких шагов воронки и участие фичи в привлечении нового трафика в разных каналах, например в SEO и эффективности контекста.

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

Вот так проходим все фичи — и в итоге можем отсортировать их по степени влияния на оборот (GMV) .

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

• Она дает единую систему координат для разных команд, которые могут заниматься абсолютно не связанными между собой вещами и иметь разный стек. Потому что имеет значение только влияние фичей на верхнеуровневые метрики изменения поведения пользователей.
• Фреймворк снижает уровень субъективности. Он помогает продактам думать об импакте фичей более предметно и копать глубже, задавать себе правильные бизнес-ориентированные вопросы. Когда требуется верхнеуровнево прикинуть рост прибыли или, тем более, оценить его баллом от 1 до 10, велик соблазн не основываться на каких-либо данных. Здесь же завести фичу в таблицу можно только задав себе вопросы о влиянии фичи на этапы пути пользователя в воронке и получив на них выраженные в цифрах ответы.
• Этот фреймворк прост в использовании и понятен бизнесу. Если один раз разобраться с тем, как работает табличка - дальше на добавление новой фичи тратятся буквально минуты, без дополнительной логики и большого количества расчетов. В ценности задач будет всегда легко ориентироваться, потому что весь расчет и логика основного влияния на воронку собрана на одном экране. Это значит, что даже очень большим бэклогом будет нетрудно управлять. И все стейкхолдеры обычно хорошо понимают что такое воронка, трафик и оборот, значит им тоже (при необходимости) будет просто сориентироваться в таблице.
• Он располагает к диалогу. Когда в одной таблице встречаются две фичи от разных заказчиков, которые претендуют на одни и те же ресурсы — эти заказчики видят ход рассуждений и могут почелленджить друг друга. Если дополнить табличку столбцами с ожидаемыми датами разработки, то диалоги получаются особенно жаркими и въедливыми по части доказательности гипотез и объективности метрик. Это я называю data-driven:)

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

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

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

#product #бэклог #скоринг #ice #воронка #productmanagement