Claude
В первой части мы договорились, что продукт начинается с проблемы, а не с решения, и что любую идею стоит воспринимать как гипотезу. Теперь два следующих вопроса, с которыми продакт сталкивается каждый день. Как понять, что продукт работает? И как выбрать, что делать дальше, если идей в десять раз больше, чем времени?
Зачем вообще нужны метрики
Метрика — это число, которое помогает принять решение. Если число нельзя использовать для решения, это не метрика, а украшение дашборда. Хороший тест: спросите себя, что вы сделаете иначе, если цифра вырастет вдвое или упадёт вдвое. Если ответ «ничего», можно перестать на неё смотреть.
Самая распространённая ловушка — метрики тщеславия. Это числа, которые всегда растут и приятно выглядят на слайдах: общее количество регистраций за всё время, суммарные просмотры, число скачиваний. Они растут даже у умирающего продукта, потому что накопленная сумма не может уменьшиться. Если у нашего сервиса за год набралось десять тысяч посетителей, это звучит гордо. Но если девять тысяч девятьсот из них открыли одну страницу и ушли навсегда, продукта на самом деле нет.
Противоположность метрикам тщеславия — метрики, которые отражают реальную ценность и могут ухудшиться. Сколько людей вернулось на этой неделе? Какая доля начавших историю дочитала её до конца? Сколько человек прошли весь алфавит хотя бы один раз? Эти цифры неприятно показывать, когда они плохие, и именно поэтому за ними стоит следить.
Путь пользователя: модель пиратских метрик
Удобная рамка для размышлений о метриках — модель AARRR, которую за звучание прозвали пиратской. Она описывает путь пользователя через пять этапов.
Привлечение. Откуда люди узнают о продукте и сколько их приходит. Для нашего сервиса — переходы из поиска, из ссылок в чатах, от друзей.
Активация. Испытал ли человек ценность продукта при первом знакомстве. Здесь важно честно определить, что значит «испытал ценность». Открыть главную страницу — не активация. Выбрать алфавит и прочитать хотя бы один раздел с новыми буквами — пожалуй, да. Этот момент иногда называют «ага-моментом»: человек вдруг понимает, зачем ему продукт.
Удержание. Возвращаются ли люди. Для большинства продуктов это главный этап, потому что без удержания всё остальное бессмысленно. Можно лить сколько угодно трафика в дырявое ведро, и оно всё равно будет пустым.
Доход. Платят ли люди и сколько. Для некоммерческого проекта сюда можно подставить любую форму отдачи — например, присылают ли пользователи свои тексты.
Рекомендации. Приводят ли пользователи других пользователей. Это самый дешёвый и самый честный канал привлечения: люди рекомендуют только то, за что им не стыдно.
Ценность модели не в аббревиатуре, а в том, что она заставляет искать узкое место. Если на каком-то этапе теряется девяносто процентов людей, улучшать соседние этапы почти бесполезно. Нет смысла вкладываться в привлечение, если активация нулевая: вы просто быстрее сожжёте аудиторию.
Удержание и когорты
Об удержании стоит поговорить отдельно, потому что его очень легко посчитать неправильно.
Наивный способ — смотреть на общее количество активных пользователей за неделю. Проблема в том, что эта цифра смешивает старых и новых. Если вы активно привлекаете трафик, число активных может расти, даже когда каждый отдельный пользователь уходит через два дня. Вы видите рост и радуетесь, а на самом деле ведро всё так же протекает, просто вы наливаете быстрее.
Правильный способ — когортный анализ. Пользователей группируют по неделе первого визита и смотрят, какая доля каждой группы возвращается через неделю, две, месяц. Получается таблица, в которой каждая строка — когорта, а каждый столбец — время с момента прихода. Если кривые удержания со временем выходят на плато — например, через месяц стабильно возвращается пятнадцать процентов, — у продукта есть ядро людей, для которых он ценен. Если кривые неуклонно стремятся к нулю, продукт пока никому по-настоящему не нужен, и маркетинг этого не исправит.
Сравнение когорт между собой показывает, становится ли продукт лучше. Если когорта, пришедшая после запуска новой функции, удерживается заметно лучше предыдущих, функция, скорее всего, сработала. Это гораздо надёжнее, чем смотреть на общие цифры до и после.
Северная звезда
Когда метрик становится много, команда начинает тянуть в разные стороны. Маркетинг гонит трафик, дизайнеры улучшают конверсию на одном экране, разработчики ускоряют загрузку. Всё это полезно, но неясно, складывается ли в общий результат.
Для этого придумали метрику Северной звезды — одно число, которое лучше всего отражает ценность, получаемую пользователями, и при этом связано с долгосрочным успехом бизнеса. У сервиса бронирования жилья это может быть количество забронированных ночей. У мессенджера — количество отправленных сообщений. Хорошая Северная звезда растёт, только когда пользователи действительно получают пользу, и её трудно накрутить.
Какой она могла бы быть для нашего сервиса? Количество посетителей не подходит: это привлечение, а не ценность. Время на сайте — спорно: человек может открыть вкладку и уйти пить чай. Кажется, неплохой вариант — количество разделов с новыми буквами, прочитанных за неделю. Каждый такой раздел — это реальный шаг в изучении алфавита. Но и у этой метрики есть недостаток: она не различает, запомнил ли человек буквы или просто пролистал. Идеальных метрик не бывает, бывают достаточно хорошие и честно описанные ограничения.
Как не обмануть себя экспериментом
Самый надёжный способ узнать, работает ли изменение, — эксперимент, или A/B-тест. Пользователей случайно делят на две группы: одна видит старую версию, другая новую. Если между группами возникает разница, её можно приписать изменению, потому что всё остальное в среднем одинаково.
У экспериментов есть подвохи, о которых стоит знать даже без глубокой статистики.
Первый подвох — маленькие выборки. Если в каждой группе по двадцать человек, разница в десять процентов может оказаться чистой случайностью. Как подбрасывание монеты: десять бросков вполне могут дать семь орлов, но это не значит, что монета кривая. Чем меньше ожидаемый эффект, тем больше людей нужно для уверенного вывода.
Второй подвох — подглядывание. Если смотреть на результаты каждый день и остановить тест в момент, когда разница выглядит значимой, вы почти гарантированно найдёте эффект, которого нет. Случайные колебания рано или поздно пересекут любую черту. Срок и размер теста нужно определять заранее и не останавливать его досрочно из-за красивой цифры.
Третий подвох — слишком много метрик. Если сравнить группы по двадцати показателям, один из них почти наверняка покажет «значимую» разницу по чистой случайности. Поэтому главная метрика эксперимента выбирается одна и заранее, а остальные считаются вспомогательными.
Для маленьких продуктов вроде нашего A/B-тесты часто вообще не работают: просто не хватает людей. Это нормально. Тогда опираются на качественные методы — интервью, наблюдение за пользователями, анализ отдельных сессий — и на здравый смысл. Плохой эксперимент хуже, чем его отсутствие, потому что создаёт иллюзию уверенности.
Приоритизация: идей всегда слишком много
Теперь о второй большой задаче. У любого живого продукта список идей растёт быстрее, чем команда успевает их реализовывать. Бэклог в сотни задач — нормальное состояние. Вопрос в том, как выбрать несколько, которые стоит делать сейчас.
Самый популярный инструмент — оценочные модели. Модель RICE предлагает оценить каждую идею по четырём параметрам. Охват: сколько людей затронет изменение за определённый период. Влияние: насколько сильно оно изменит поведение каждого из них, по условной шкале. Уверенность: насколько мы уверены в первых двух оценках, в процентах. Усилия: сколько человеко-недель уйдёт на реализацию. Итоговая оценка — произведение охвата, влияния и уверенности, делённое на усилия.
Например, для нашего сервиса есть три идеи. Первая — показывать прогресс изучения алфавита. Её увидят все читатели, влияние среднее, уверенность умеренная, сделать можно за пару дней. Вторая — мобильное приложение. Охват потенциально больше, влияние неясное, уверенность низкая, а усилия огромные. Третья — озвучка новых букв при наведении. Охват средний, влияние, возможно, высокое для тех, кто учит японский, усилия умеренные. Даже грубый подсчёт сразу показывает, что приложение проигрывает: огромные усилия в знаменателе при низкой уверенности в числителе.
Важно понимать, чем на самом деле полезны такие модели. Они не выдают истину. Цифры в них почти всегда взяты с потолка, и подогнать их под желаемый ответ ничего не стоит. Их ценность в другом: они заставляют проговорить допущения вслух. Когда кто-то ставит влияние «три» новой функции, а коллега ставит «единицу», возникает разговор о том, почему вы по-разному видите пользователя. Этот разговор и есть настоящий результат приоритизации.
Ещё одна полезная модель — модель Кано. Она делит функции на три типа. Базовые — те, отсутствие которых раздражает, а наличие не радует: никто не хвалит сайт за то, что он открывается, но все ругают, если нет. Линейные — чем больше, тем лучше: скорость, количество историй в библиотеке. Восхищающие — те, которых никто не ждёт, но они вызывают восторг: например, если бы сервис вдруг показал, что вы уже можете прочитать настоящую вывеску на грузинском. Хорошая стратегия сначала закрывает базовые потребности, затем держит конкурентный уровень по линейным и добавляет немного восхищения, чтобы о продукте хотелось рассказать.
Фабрика фич
Напоследок — о самом распространённом анти-паттерне в продуктовых командах. Он называется фабрикой фич. Команда измеряет свою работу количеством выпущенных функций. Квартальные цели звучат как «запустить пять новых возможностей». После запуска никто не проверяет, изменилось ли что-нибудь для пользователей: на это нет времени, впереди следующие пять.
Снаружи фабрика фич выглядит продуктивной. Изнутри она выматывает: люди много работают, а продукт почему-то не становится лучше. Признаки легко узнать. Никто не может сказать, какие из прошлогодних функций реально используются. Роадмап — это список фич с датами, а не список проблем, которые нужно решить. Успех празднуют в день релиза, а не в день, когда метрика выросла.
Лекарство — переключиться с результатов работы на последствия работы. Не «запустить прогресс-бар», а «увеличить долю дочитавших историю с тридцати до сорока процентов». Прогресс-бар — одна из гипотез, как этого достичь. Если она не сработает, команда попробует другую, и это будет не провал, а нормальный ход работы.
Что попробовать прямо сейчас
Выберите одну метрику своего продукта, на которую вы регулярно смотрите. Задайте себе вопрос из начала этого текста: что я сделаю иначе, если она вырастет вдвое? А если упадёт вдвое? Если ответа нет — возможно, это метрика тщеславия.
Затем возьмите три верхние задачи из своего бэклога и попробуйте грубо оценить их по RICE. Не ради точных цифр, а чтобы заметить, где ваша уверенность на самом деле ниже, чем казалось. В третьей части мы поговорим о том, как превратить всё это в план, который понимают и команда, и руководство, и как запускать продукты, не теряя связь с реальностью.