Скоринг фичей на основе метрик воронки. Funnel Scoring Model. Часть 1
Хочу рассказать о том, как однажды мы оценивали приоритетность задач для бизнеса при планировании загрузки разработки. Казалось бы, готовых фреймворков много, и зачем ещё один, тем более самодельный. Но не всё так просто, расскажу по-порядку.
Привет!
Меня зовут Юля Ранн, почти пять лет я была CPO в Level. travel, а до этого product owner’ом в Ведомостях и занималась аналитикой. А сейчас я помогаю разным компаниям развивать свои продукты и команды.
Зачем ещё один фреймворк скоринга?
На рынке есть много фреймворков для скоринга бэклога, например, ICE/RICE или WSJF. Но у каждого из них есть свои ограничения. В одном из проектов мы столкнулись с ситуацией, которой оценка с помощью популярных фреймворков подходила плохо, поэтому решили создать свою скоринговую модель.
У нас были такие исходные данные:
- Одной из важнейших стратегических целей компании был тюнинг основной продающей воронки.
- Нам было важно говорить о задачах в деньгах и оперировать терминами трудозатрат и потенциальной прибыли, а не абстрактными поинтами.
- Бэклог был огромен. Сотни гипотез об улучшениях, которые стекались от разных продуктовых команд в разных вертикалях.
- У нас были ограниченны ресурсы для разработки, поэтому мы хотели, насколько это возможно, избежать ошибок планирования и минимизировать ущерб от неправильной приоритизации задач.
- За эти ресурсы разработки конкурировали различные внутренние заказчики не только со стороны продукта, но и из других частей компании.
- У нас было уже очень много качественных и количественных данных о том, что нужно клиентам, и так или иначе протестированных или проанализированных гипотез. Вопрос стоял в правильной приоритизации для передачи в разработку и создания MVP, а не о приоритизации идей ради их первичной проверки.
Почему решили не выбирать ICE или другой существующий фреймворк?
Из наших вводных растут определенные претензии к популярным эвристическим фреймворкам типа 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.
Кастомизированные модели – 🔥❤️
7/10
8/11