Как не стать продактом-официантом: подход Lean Startup
Эту статью мы написали вместе с Владимиром Меркушевым, продакт-менеджером в OLX. Вот ссылка на его телеграм-канал.
Запросы на новые фичи сыпятся на продакта как заказы на официанта: “Нужен другой онбординг и отзывы к товарам”, “Мне, пожалуйста, смс-уведомления”, “А мне — всплывающее окно с подпиской”.
Если вы не хотите постоянно обслуживать команду и внешних стейкхолдеров, нужно фильтровать идеи. В этой статье мы расскажем, как это делать, чтобы никого не обидеть. В конце дадим шаблон для оценки решений.
Как фильтровать идеи
Представьте ситуацию: Элис устроилась продакт-менеджером в автомобильный маркетплейс. От коллег постоянно идут запросы на фичи. Элис пытается никому не отказать, в итоге команда ничего не успевает, и приходится действовать по принципу — главным стейкхолдерам “да”, а остальным “нет”.
В один день Элис пошла на обед со своим другом Джеком, который тоже работает продактом.
Во время обеда пришло сообщение от маркетолога — очередное предложение фичи. Элис не выдержала.
Вернувшись с обеда, Элис решила, что теперь будет проверять все запросы по подходу Джека. Она разложила его на три этапа:
Проверка проблемы.
Поиск и выбор решения.
Проверка решения.
Элис открывает рабочий чат и снова видит сообщение от маркетолога с предложением новой фичи. Разберем, как лучше ответить, на примере задания из нашего курса по продакт-менеджменту.
Задание
Маркетолог увидел статью с кейсом, где всплывающее окно повысило конверсию в регистрацию на 38%. Поэтому маркетолог предлагает сделать также. Что лучше ему ответить?
Элис ответила маркетологу и вернулась к работе. Через какое-то время ей пишет Майк, продакт из команды поиска.
Просить Майка помочь в проверке проблемы нет смысла. Он просто передал информацию, которую получил во время исследования. Поэтому Элис пошла проверять идею сама.
Проверка проблемы
Проблем и идей обычно больше, чем ресурсов на их реализацию. Поэтому на начальном этапе нужно убедиться, что проблема стоит того, чтобы ее решать. Нужно ответить на несколько вопросов.
Какую проблему решаем?
Чаще всего это потребность пользователя или возможность для продукта. В случае Элис пользователи не понимают, сколько должна стоить машина.
Насколько велика проблема?
Надо понять, каких пользователей затрагивает проблема, сколько их, чего они хотят. Это можно сделать, посмотрев аналитику и пообщавшись с пользователями.
В продукте Элис есть несколько сегментов пользователей: бизнес-пользователи, частные продавцы и частные покупатели. Проблема затрагивает частных покупателей, но оказывает влияние и на другие сегменты. Например, если продавец выставляет высокую цену на авто, то новая фича ему невыгодна — покупатели увидят, что цена завышена.
Также у продукта есть подсегменты, в зависимости от категории товара: легковые авто, грузовые авто, лодки, байки. Нужно изначально делать фичу для того подсегмента, который больше других. В случае Элис это легковые авто.
Какие доказательства у нас есть?
Доказательствами могут быть исследования и аналитика. Майк скинул Элис результаты анализа аудитории.
Как это совпадает с нашими целями (OKR)?
Если проблема не попадает в цели, то можно запланировать ее решение на следующий квартал. Также можно передать задачу команде, у которой цели соотносятся с проблемой.
Цель команды Элис — облегчить покупателям процесс выбора машины. Решение проблемы помогает приблизиться к цели.
Как мы оценим успех?
Метрики успеха помогут понять, справляется ли конкретное решение с проблемой.
Чтобы решить проблему пользователей, команде Элис нужно будет сделать модель оценки стоимости машины. У Элис есть гипотеза, как это повлияет на метрики. Если показывать пользователям, соответствует ли цена товара рыночной, это приведет к увеличению количества просмотров и звонков по объявлениям с рыночной ценой.
О том, как формулировать гипотезы, можно почитать подробнее в другой нашей статье. Там мы даем шаблон для систематизации гипотез.
При выборе метрик нужно думать не только о решении проблемы, но и о возможных рисках. Нужно добавить health-метрики — показатели, которые могут поменяться в негативную сторону при добавлении фичи.
Есть риск, что модель будет неправильно работать. Если у большинства объявлений будет отметка, что цена завышена, то количество просмотров объявлений упадет.
Вот метрики, которые Элис выбрала для отслеживания:
Покрытие базы объявлений оценкой цены.
Количество контактов по объявлению.
Количество просмотров.
Доля объявлений, которые попадают в группы «ниже рыночной», «выше рыночной».
Взаимодействия с блоком, доля посетителей с кликом по блоку.
Обратная связь, количество тикетов в поддержку с тегом «ошибка в оценке».
Элис понимает, что проблему необходимо решать. Нужно только понять как. Она переходит к следующему этапу — поиску решения.
Задание
Перед тем, как переходить к следующему этапу, Элис решила добавить метрики успеха для других фичей. Как думаете, какие метрики нужно отслеживать для фичи — проверки машины? Фича подразумевает, что водитель привозит машину в центр проверки, после чего в объявлении появляется галочка и отчет о проверке.
Читайте лучшие статьи по продакт-менеджменту
Раз в неделю будем отправлять свежий дайджест вам на почту. Наc читает 25000 человек 🚀
Поиск решения
На этапе поиска решения не стоит брать первое решение, которое приходит в голову. Надо подумать, какие есть еще, и выбрать тот вариант, который даст больше ценности при меньших затратах.
В основном решения ищут двумя способами: бенчмаркингом и брейнштормом с командой.
Бенчмаркинг. Вам нужно посмотреть, что делают конкуренты, что делают компании на другом рынке с похожей моделью.
Элис понравилось решение, которое использует Carvago. Компания сравнивает цены на похожие машины за последние несколько месяцев и делает сегментирование.
Брейншторм. Когда вы вдохновились решениями конкурентов, нужно собрать команду на брейншторм. Так вы сможете найти неочевидные решения, которые могут оказаться лучше первоначальных идей.
Можно попробовать способ Crazy 8:
Взять лист А4 и сложить его, чтобы получилось 8 блоков (пополам, пополам и ещё раз пополам).
Заполнять по одному блоку в минуту. Можно не писать, а рисовать, как это будет выглядеть в интерфейсе.
Презентовать идеи и проголосовать за лучшие.
Элис зовет на брейншторм всю команду — дизайнера, аналитика, инженеров, рисерчера. Сначала они генерируют идеи, затем оценивают их и оставляют лучшие. У команды осталось три варианта решения:
Экспертная оценка по марке и году. Дать коридор цен без оценки текущей карточки.
Оценка на основании похожих объявлений. Дать коридор цен без оценки текущей карточки.
Оценка на основании похожих объявлений. Сделать сегментацию цен, определить карточку в один из сегментов: “ниже рыночной цены”, “рыночная цена”, “выше рыночной цены”.
Каждый участник команды оценивает свои затраты на реализацию фичи по шкале от 1 до 5: дизайнер — на дизайн, инженеры — на разработку, аналитик — на эксперимент.
Дальше нужно выбрать решение. Команда Элис делает это с помощью фреймворка Value-Effort. Можно воспользоваться и другими фреймворками. Например, ICE Score, RICE Score и Lean Prioritization Canvas. Мы написали об этом статью и дали в ней готовый шаблон для приоритизации.
Команда оценила затраты и ценность для каждого решения и выбрала третий вариант — сделать сегментацию цен на основании похожих объявлений. Осталось составить документ с описанием решения. В таком документе прописываются все важные моменты: что планируется делать, кто в этом будет участвовать, как это соотносится с целями, какие проблемы решаем, какие есть риски и как их минимизировать.
Чтобы вам было легче оценивать и выбирать идеи, мы подготовили бесплатный шаблон для описания решения в Miro. Такой шаблон удобно заполнять вместе с командой прямо на брейншторме.
Проверка решения
На этапе проверки решения мы готовим и проводим эксперимент. Если после проведения эксперимента нет значимого влияния на метрики, решение нужно откатить и подумать над другим вариантом.
Чтобы проверить гипотезу, нужно сделать MVP решения. Нужно максимально упростить решение — убрать из него части, которые отнимают много ресурсов. Например, вместо разработки опроса в приложении можно провести опрос с помощью колл-центра.
Задание
Потренируемся в выборе эксперимента. Представьте, что вы работаете в одной компании с Элис, только в другой команде. Вам нужно проверить, насколько покупателям интересно посмотреть отчет о техническом состоянии автомобиля в объявлении.
Как вы думаете, какой эксперимент лучше использовать, чтобы проверить эту гипотезу?
Не всегда получится упростить эксперимент. Тогда можно запустить фичу на небольшую выборку пользователей, а потом масштабировать решение. Так и сделала Элис.
Аналитик подсчитал, что для статистически значимых результатов нужна выборка 5% пользователей. В течение двух недель пользователям из выборки будет показываться новая фича. После эксперимента сотрудники колл-центра проведут обзвон и соберут обратную связь. Также Элис будет отслеживать количество просмотров объявлений и количество контактов по ним.
Команда запустила эксперимент. Через две недели количество контактов по объявлениям, попадающим в рыночную цену, увеличилось на 3%. В отчете из колл-центра была в основном положительная обратная связь. Было несколько жалоб на то, что модель плохо работает и загоняет в категорию выше рынка недорогие машины. Элис проверила объявления и сделала вывод, что жалобы необъективны — цены на машину действительно завышены.
Элис решила масштабировать решение на весь продукт.
Элис решила написать Джеку и рассказать ему о своих успехах с проектом.
Резюмируем
Задача продакт-менеджера — следить за балансом между рисками и усилиями, потраченными на решение до разработки.
Если не проверить идею, появляется большая вероятность потратить время на разработку ненужной фичи и ухудшить опыт пользователя. Если же слишком долго проверять каждую идею, разработка будет обходиться дорого.
Поэтому проверяйте запросы, но не делайте этот процесс жестким. Не всегда будет вся информация для принятия решения. Какой-то риск остается, и это нормально.
