Представьте, вы 2 или 3 месяца работали над фичей и продуктом, релиз прошел гладко, багов нет, пользователь идет по нужному сценарию. И тут бизнес говорит: «Вот выкатили вы релиз — а что дальше, где деньги?» Обидно, правда? Поэтому я рекомендую всем менеджерам продуктов, которые хотя вырасти быстро, ставить цели не в фичах, а в метриках.
Фичи против метрик — наиболее болезненная тема у многих в последнее время, так что давайте разбираться. Как перестать измерять свои результаты в фичах? Как отказывать бизнесу, когда вас просят «сделать красную кнопку вон там»?
Расскажу на примере Маши. Она junior product и пришла на испытательный срок, ей поставили задачу — сделать онбординг не хуже, чем у конкурентов A, B и C. Это абстрактная и эфемерная цель: как мы поймем, что онбординг стал «не хуже»?
На месте Маши надо сразу задать три вопроса — о цели, метриках и критериях оценки:
- Какая цель?
- Как мы поймем, что достигли цели?
- Как будем измерять?
Мы пишем о менеджменте продуктов и развитии в телеграм-каналах make sense и Продуктовое мышление.
Откуда приходят цели для менеджера продуктов
Мы поговорили, как ставить и оценивать таргеты (цели) в работе менеджера продуктов, теперь посмотрим, откуда эти цели могут приходить. Существует четыре основных метода.
Первый метод. Таргеты, которые выставляют сверху (идем от потребности). Это особенно удобно для менеджеров продуктов уровня junior — им не надо принимать решения и делать какие-то сложные пассы. Дали цель и лопату — копай. Хорошо, если в компании есть декомпозиция по метрикам, понятные причины, почему надо достигать конкретной планки. Бывает и хуже — когда таргеты спускаются сверху просто наугад. Если у вас такой случай, перепроверяйте таргет на выполнимость (об этом чуть ниже) и обязательно говорите с бизнесом о смысле самой метрики. Если мы понимаем, что хотим измерить, то нам проще выставить таргет.
Пример: менеджеру продуктов ставят таргет на разработку и интеграцию FAQ, чтобы снизить нагрузку на службу поддержки — а значит, снизить и затраты на них. Бизнес четко понимает, что если нужны деньги на развитие, то их можно взять из операционного процесса. Но чтобы при этом не сломалось качество, придется автоматизировать. Тогда таргет будет понятный и обоснованный. Нужно X денег, значит, оптимизируем поддержку на этот Х. Следовательно, с учетом уровня нагрузки количество обращений должно сократиться на Y. Но даже в этом примере есть нюансы — все равно придется проверять таргет на реалистичность.
Второй метод. Идем от возможности. Например, мы определили ключевые цели, выбрали метрики, по которым будем определять движение к целям. Далее мы смотрим, почему эти метрики сейчас находятся на таком уровне? Тут пригодятся все варианты исследований (исследований количественных, потому что качественные скорее дадут вам гипотезы, чем расскажут об истинных причинах). Мы собираем и группируем причины, выясняем, что мешает людям достигать целевого действия. Потом смотрим, какие из этих причин мы можем исправить в ближайший период планирования и, в идеале, прикидывам, на сколько процентов мы можем исправить эти причины. Лучше всего провести А/B-тесты, но к сожалению, для этого не всегда есть условия. Поэтому надо провести хотя экспертную оценку — причем желательно опросить нескольких экспертов и оценить, какую долю проблем мы можем закрыть, а значит — на сколько сдвинуть метрику.
Третий метод. Смотрим на тренд, соотносим с сезонностью и дополняем пунктами из второго метода. Но тут есть нюанс — для этого необходимы ретроспективные замеры метрик минимум за 2 года. Например, в этом году пандемия внесла серьезные коррективы и в линии трендов, и в сезонность.
Четвертый метод. Интегральный. Вы вместе с бизнесом сначала определяете цели и метрики, потом бизнес смотрит, что ему надо от вас, а вы оцениваете, насколько это реалистично и достижимо.
Итак, что нужно помнить, выбирая источник таргетов:
- Важно договориться про цели и метрики;
- Если вам приносят готовые таргеты, то их надо проверять на реалистичность, чтобы вы в конце периода не сказали: “Это было невозможно”;
- Если вам нужно самостоятельно выставить таргеты, то оцените, какие нерешенные проблемы существуют и какую их часть вы сможете закрыть в нужном для вас горизонте планирования (в идеале — исследования + тесты).
Чем отличаются цели (таргеты) и метрики
Эти понятия так часто путают, что пора расставить все по полочкам.
Представьте, что ваша цель — научиться стрелять из лука. Но как вы поймете, что уже научились? Например, измерите, сколько стрел из 10 попадают в мишень. Это и есть метрика, способ измерения.
То есть ваша цель — это определенное количество стрел, которые должны попадать в мишень. Если вы только учитесь, то 2 стрелы из 10 — это уже победа, определенный таргет, то значение метрики, к которому вы стремитесь.
Когда надо менять метрики, а когда таргеты?
Таргеты могут меняться от следующих факторов:
- Вы серьезно улучшаете процесс (например, перешли с лука на арбалет) — и теперь 2 из 10 стрел вы отправите в цель даже с закрытыми глазами.
- Изменились внешние условия (например, таргет надо менять, когда дует сильный ветер).
- Изменился доступный ресурс и т.д.
Когда надо менять метрику?
Если у вас существенно изменится сам процесс — например, вы сменили стрельбу из лука в мишень на стрельбу по тарелочкам. Тогда вашей метрикой станет количество разбитых тарелочек.
Но вернемся к Маше — она уже сходила к руководителю и вернулась с ответами на три вопроса. Что у нее получилось?
- Цель — быстро конвертировать посетителей в пользователей.
- Критерии — пользователь быстро выходит в первую оплату.
- Метрика — среднее время оплаты.
Важно, чтобы метрики соответствовали критериям — это надо продумать еще на старте, а не во время релиза. Теперь, чтобы оценить свою работу или работу Маши, надо собрать данные по этой метрике и понять, что у нас происходит сейчас. Ведь мы должны понимать, с чем сравнивать результат.
Как выставить цели?
Шаг 1
- Разбираем и группируем причины. Сравниваем успешные и неуспешные пользовательские сценарии.
- Исследуем пользователей. Сначала качественно, потом количественно. В идеале надо провести A/B-тесты, но не всегда хватает времени.
- Выясняем, какие группы причин закрыть продуктом. Какие задачи отдать в операционную и маркетинговую команду.
Шаг 2
- Формируем список фичей, которые закрывают ключевые группы негативных сценариев.
- Прогнозируем сдвиг метрики. На сколько мы сможем подвинуть метрику релизом (даже не очень точная экспертная оценка лучше, чем ее отсутствие).
- Проводим скоринг затрат по ресурсам. Сколько часов уйдет на разработку — с учетом времени после релиза.
На выходе получаем заполненную табличку.
Если просто просуммировать или вычитать таргет, то можно получить проблемы: мы не успеем реализовать все фичи, сценарий пойдет не так, на проде возникнут неожиданные затруднения и т.п. Поэтому надо делать поправку на степень уверенности. Лучше ее немного занижать: бизнес будет рассчитывать на ваши прогнозы, на них будут ориентироваться сотрудники, которые выставляют задачи другим отделам. Такое планирование позволяет говорить бизнесу, что поместится в разработку, а что нет.
Что делать, если у вас мало ресурса
В такой ситуации лучше сделать много мелких фич и с большей вероятностью сдвинуть метрики, чем заниматься парой больших задач, вероятность выстрелить у которых ниже (чисто статистически). При такой тактике, если вдруг мелкие фичи не сработают, в конце периода у вас останется свободное время в разработке, а если вы поставите «на одну жирную лошадь», то она вообще может не добежать до финиша.
Даже если вы все сделали прекрасно с точки зрения работы с бэклогом, а таргет так и не достигнут, у вас останется свободное время внутри запланированного периода времени — вы сможете переделать бэклог, чтобы все-таки выполнить квартальные показатели по таргету.
Важный момент: ваш график релизов обязательно должен привязываться к сдвигу по таргету. И если в середине месяца таргет не изменился, надо срочно поднимать всю команду и думать, что еще сделать, чтобы все-таки стать ближе к цели.
И здесь часто задают вопрос — а что, если метрика достигнута не за счет продуктовой команды? Что, если это постарался маркетинг или сейлзы? Для этого надо еще на старте определить, какие части сдвига таргета могут появиться за счет вашей работы, а какие — благодаря другим отделам, и разделить их. Если разделить показатели не получится и остается одна общая метрика, которая влияет на KPI обеих команд, надо просто связать командные KPI и работать вместе.
Если запланированных показателей удалось достичь почти сразу, нужно пересогласовать бэклог, добавить другие метрики, передать свой ресурс другой команде или помочь им с достижением их таргета.
Как работать с большими инфраструктурными проектами
Я рекомендую оставлять 20% на инфраструктуру и рефакторинг. Если у вас есть супербольшие и амбициозные долгосрочные цели, закладывайте на их реализацию определенный процент времени. Например, 20 — инфраструктура, 20 — долгосрочные цели и 60 — операционка.
Ксения ведет телеграм-канал «Мат, скотч и google-doc» — о цифрах, продуктах и рабочих лайфхаках.
