Проект приостановлен. Менторские проверки, группы и активности недоступны. Предлагаем только самостоятельное обучение на платформе.
Українська
Українська
Русский
Українська
Українська
Русский

Сообщение об ошибке

Вы собираетесь отправить сообщение о следующей ошибке:

Пожалуйста, опишите суть ошибки

Как не стать продактом-официантом: подход Lean Startup

Эту статью мы написали вместе с Владимиром Меркушевым, продакт-менеджером в OLX. Вот ссылка на его телеграм-канал.

Запросы на новые фичи сыпятся на продакта как заказы на официанта: “Нужен другой онбординг и отзывы к товарам”, “Мне, пожалуйста, смс-уведомления”,  “А мне — всплывающее окно с подпиской”.


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

Как фильтровать идеи

Представьте ситуацию: Элис устроилась продакт-менеджером в автомобильный маркетплейс. От коллег постоянно идут запросы на фичи. Элис пытается никому не отказать, в итоге команда ничего не успевает, и приходится действовать по принципу — главным стейкхолдерам “да”, а остальным “нет”.


В один день Элис пошла на обед со своим другом Джеком, который тоже работает продактом. 

Во время обеда пришло сообщение от маркетолога — очередное предложение фичи. Элис не выдержала.

Джек, как ты справляешься со всем этим потоком идей и запросов от других людей? Я ничего не успеваю 😥

Поток идей — это круто, иногда там есть что-то полезное. Мне это нравится. А что случилось?

Да вот опять маркетолог кидает идеи.

А что в этом такого?

Я чувствую себя как официант, который просто реализует чужие запросы. Не ощущаю своего влияния на продукт.

А что ты обычно делаешь, когда тебе приходит запрос?

Смотря от кого запрос. Но чаще всего беру его в работу.

Поэтому ты и не успеваешь. Надо как-то фильтровать запросы.

Ты читала Lean Startup?

Да, а что?

Там основная идея как раз в том, чтобы сначала изучить возможности, а потом строить. То есть, сначала мы запускаем MVP, смотрим метрики и учимся на них. И с помощью полученных знаний уже совершенствуем продукт.

Но на деле часто выходит по-другому. У всех много идей, и команда постоянно что-то строит. И потом уже продакт вспоминает про метрики.

процессы в Lean Management и реальной жизни

Да, вот у нас как раз так и выходит. Мы постоянно что-то строим. Как думаешь, что я могу сделать, чтобы это поменять?

На мой взгляд, продакт-менеджер — это фильтр идей. Стань им. Проверяй все идеи перед тем, как брать их в работу. Так ты снизишь риск принятия неправильного решения и получишь более высокий результат. 

Звучит конечно круто, но знаешь, иногда приходит стейкхолдер со своей очень важной идеей, и я не могу сказать нет.

Тебе и не обязательно говорить нет. Ты можешь предложить проверить идею.

Хм, а как мне ее проверять?

Сначала проверяешь проблему — а стоит ли она того, чтобы ее решать. Многих ли пользователей она затрагивает, насколько критична, насколько соответствует целям. Затем смотришь возможные решения, приоритизируешь их и выбираешь одно. Дальше проводишь эксперимент. Если все ок, масштабируешь решение.

Звучит логично, попробую. Только мне все равно не очень понятно, как говорить об этом. Вот представь, что к тебе пришел СЕО с запросом. Что ты ему скажешь?

Если СЕО что-то предлагает, значит он подумал и понял, что это важно для бизнеса. С ним нужно говорить про бизнес-ценность — почему он хочет решить эту проблему, зачем ему нужна в продукте эта фича. 

Я бы узнал у него всю информацию, а потом сказал бы так: “Давай я проверю сторону, связанную с пользователем. Оценю, скольких пользователей затрагивает эта проблема, и узнаю, что им нужно”.

Изучил бы проблему, нагенерировал с командой идей, приоритизировал их и пришел к СЕО с конкретикой. Сказал бы: “Решение этой проблемы будет стоить 1,5 месяца разработки. Как думаешь, стоит того?”.

Звучит реалистично, надо мне тоже попробовать твой подход.

Спасибо тебе!
Гайд по лучшим статьям skillsetter
В нашем блоге уже больше 150 статей про рост продуктов и карьеру в IT. Для удобной навигации мы объединили их в тематические подборки.
Выбрать подборку

Вернувшись с обеда, Элис решила, что теперь будет проверять все запросы по подходу Джека. Она разложила его на три этапа:


  1. Проверка проблемы.

  2. Поиск и выбор решения.

  3. Проверка решения.


этапы фильтрации идей и запросов в продакт-менеджменте


Элис открывает рабочий чат и снова видит сообщение от маркетолога с предложением новой фичи. Разберем, как лучше ответить, на примере задания из нашего курса по продакт-менеджменту.

Задание

Маркетолог увидел статью с кейсом, где всплывающее окно повысило конверсию в регистрацию на 38%. Поэтому маркетолог предлагает сделать также. Что лучше ему ответить?

Выберите несколько вариантов

Элис ответила маркетологу и вернулась к работе. Через какое-то время ей пишет Майк, продакт из команды поиска.

Привет, Элис. Мы тут общались с пользователями и получили инсайт о том, что частные покупатели не понимают, сколько должна стоить машина. Поэтому они смотрят похожие объявления и прикидывают среднюю цену. У них есть потребность в том, чтобы понимать, соответствует ли товар средней цене по рынку. 

Думаю, эту потребность можно закрыть на странице объявления. За это как раз отвечает твоя команда. 

Привет, Майк. Спасибо за информацию. Проверю эту проблему. А можешь скинуть результаты исследований?

Да, конечно.

Спасибо!

Просить Майка помочь в проверке проблемы нет смысла. Он просто передал информацию, которую получил во время исследования. Поэтому Элис пошла проверять идею сама.

Проверка проблемы

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


вопросы для проверки проблемы


Какую проблему решаем? 

Чаще всего это потребность пользователя или возможность для продукта. В случае Элис пользователи не понимают, сколько должна стоить машина. 


Насколько велика проблема? 

Надо понять, каких пользователей затрагивает проблема, сколько их, чего они хотят. Это можно сделать, посмотрев аналитику и пообщавшись с пользователями.


В продукте Элис есть несколько сегментов пользователей: бизнес-пользователи, частные продавцы и частные покупатели. Проблема затрагивает частных покупателей, но оказывает влияние и на другие сегменты. Например, если продавец выставляет высокую цену на авто, то новая фича ему невыгодна — покупатели увидят, что цена завышена.


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


Какие доказательства у нас есть?

Доказательствами могут быть исследования и аналитика. Майк скинул Элис результаты анализа аудитории.


Как это совпадает с нашими целями (OKR)?

Если проблема не попадает в цели, то можно запланировать ее решение на следующий квартал. Также можно передать задачу команде, у которой цели соотносятся с проблемой.


Цель команды Элис — облегчить покупателям процесс выбора машины. Решение проблемы помогает приблизиться к цели.


Как мы оценим успех?

Метрики успеха помогут понять, справляется ли конкретное решение с проблемой. 


Чтобы решить проблему пользователей, команде Элис нужно будет сделать модель оценки стоимости машины. У Элис есть гипотеза, как это повлияет на метрики. Если показывать пользователям, соответствует ли цена товара рыночной, это приведет к увеличению количества просмотров и звонков по объявлениям с рыночной ценой. 


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


При выборе метрик нужно думать не только о решении проблемы, но и о возможных рисках. Нужно добавить health-метрики — показатели, которые могут поменяться в негативную сторону при добавлении фичи.


Есть риск, что модель будет неправильно работать. Если у большинства объявлений будет отметка, что цена завышена, то количество просмотров объявлений упадет.

Вот метрики, которые Элис выбрала для отслеживания:


  • Покрытие базы объявлений оценкой цены.

  • Количество контактов по объявлению.

  • Количество просмотров.

  • Доля объявлений, которые попадают в группы «ниже рыночной», «выше рыночной». 

  • Взаимодействия с блоком, доля посетителей с кликом по блоку.

  • Обратная связь, количество тикетов в поддержку с тегом «ошибка в оценке».


Элис понимает, что проблему необходимо решать. Нужно только понять как. Она переходит к следующему этапу — поиску решения.

Задание


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

Выберите несколько вариантов

Читайте лучшие статьи по продакт-менеджменту

Раз в неделю будем отправлять свежий дайджест вам на почту. Наc читает 25000 человек 🚀

Поиск решения

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


В основном решения ищут двумя способами: бенчмаркингом и брейнштормом с командой. 


Бенчмаркинг. Вам нужно посмотреть, что делают конкуренты, что делают компании на другом рынке с похожей моделью. 


Элис понравилось решение, которое использует Carvago. Компания сравнивает цены на похожие машины за последние несколько месяцев и делает сегментирование.


Carvago сравнение цен на похожие машины


Брейншторм. Когда вы вдохновились решениями конкурентов, нужно собрать команду на брейншторм. Так вы сможете найти неочевидные решения, которые могут оказаться лучше первоначальных идей.


Можно попробовать способ Crazy 8:

  • Взять лист А4 и сложить его, чтобы получилось 8 блоков (пополам, пополам и ещё раз пополам).

  • Заполнять по одному блоку в минуту. Можно не писать, а рисовать, как это будет выглядеть в интерфейсе.

  • Презентовать идеи и проголосовать за лучшие. 


Элис зовет на брейншторм всю команду — дизайнера, аналитика, инженеров, рисерчера. Сначала они генерируют идеи, затем оценивают их и оставляют лучшие. У команды осталось три варианта решения:

  • Экспертная оценка по марке и году. Дать коридор цен без оценки текущей карточки.

  • Оценка на основании похожих объявлений. Дать коридор цен без оценки текущей карточки.

  • Оценка на основании похожих объявлений. Сделать сегментацию цен, определить карточку в один из сегментов: “ниже рыночной цены”, “рыночная цена”, “выше рыночной цены”.


Каждый участник команды оценивает свои затраты на реализацию фичи по шкале от 1 до 5: дизайнер — на дизайн, инженеры — на разработку, аналитик — на эксперимент. 


Дальше нужно выбрать решение. Команда Элис делает это с помощью фреймворка Value-Effort. Можно воспользоваться и другими фреймворками. Например, ICE Score, RICE Score и Lean Prioritization Canvas. Мы написали об этом статью и дали в ней готовый шаблон для приоритизации.


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


Чтобы вам было легче оценивать и выбирать идеи, мы подготовили бесплатный шаблон для описания решения в Miro. Такой шаблон удобно заполнять вместе с командой прямо на брейншторме.


шаблон для описания решения в продакт-менеджменте


Проверка решения

На этапе проверки решения мы готовим и проводим эксперимент. Если после проведения эксперимента нет значимого влияния на метрики, решение нужно откатить и подумать над другим вариантом. 


Чтобы проверить гипотезу, нужно сделать MVP решения. Нужно максимально упростить решение — убрать из него части, которые отнимают много ресурсов. Например, вместо разработки опроса в приложении можно провести опрос с помощью колл-центра.

Задание


Потренируемся в выборе эксперимента. Представьте, что вы работаете в одной компании с Элис, только в другой команде. Вам нужно проверить, насколько покупателям интересно посмотреть отчет о техническом состоянии автомобиля в объявлении.


Как вы думаете, какой эксперимент лучше использовать, чтобы проверить эту гипотезу?

Выберите несколько вариантов

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


Аналитик подсчитал, что для статистически значимых результатов нужна выборка 5% пользователей. В течение двух недель пользователям из выборки будет показываться новая фича. После эксперимента сотрудники колл-центра проведут обзвон и соберут обратную связь. Также Элис будет отслеживать количество просмотров объявлений и количество контактов по ним.


Команда запустила эксперимент. Через две недели количество контактов по объявлениям, попадающим в рыночную цену, увеличилось на 3%. В отчете из колл-центра была в основном положительная обратная связь. Было несколько жалоб на то, что модель плохо работает и загоняет в категорию выше рынка недорогие машины. Элис проверила объявления и сделала вывод, что жалобы необъективны — цены на машину действительно завышены.


Элис решила масштабировать решение на весь продукт.

Элис решила написать Джеку и рассказать ему о своих успехах с проектом.

Привет, Джек! Как дела?

Привет, Элис! Все отлично. Как у тебя?

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

Это круто. Больше не чувствуешь себя продактом-официантом?

Нет. На самом деле, стало гораздо проще работать. Теперь не надо бояться кому-то отказать.

В этом и особенность такого подхода. Если начать фильтровать идеи и просто всем отказывать, люди будут чувствовать себя некомфортно и перестанут приходить с идеями. А это не очень.

Согласна. Вообще я боялась, что испорчу отношения с командой, если буду говорить им нет.

Возможно так и было бы. Управление командой вообще не простая штука. Многое еще зависит от подачи. Подача “я лучше знаю, как надо” и “твоя идея не очень” может испортить отношения, а подача “давай проверим твою идею” — наоборот.

Ага. Поэтому я тебе и пишу, хочу сказать спасибо. Ты мне очень помог, когда рассказал про этот подход.

Всегда пожалуйста 😉 

Резюмируем

Задача продакт-менеджера — следить за балансом между рисками и усилиями, потраченными на решение до разработки. 


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


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

Рекомендуем почитать

таблица выбора фреймворка: ICE, RICE и Lean Canvas

Как приоритизировать гипотезы на примере RPG игры: 3 проверенных фреймворка

юнит экономика — это что такое

Как за 6 шагов посчитать юнит-экономику идеи для стартапа

калькулятор Unit-экономики, Marketing Mix и шаблон UX-текстов

8 бесплатных шаблонов для запуска и роста продукта

← Читать другие статьи в блоге Получить реальные навыки