Рутина продакта: путешествие из ХЗ в ТЗ11.08.2023 14:17

Привет, Хабр! Я Кристина — продакт-менеджер компании Selectel. В статье расскажу, как мы строим гипотезы и проверяем потенциальную полезность и выгоду от фичей до того, как на их реализацию будут потрачены долгие годы.

Статья будет наиболее интересна тем, кто только начинает свой путь в продакт-менеджменте или работает в продуктовой команде разработки и хочет узнать, чем занимаются вечно пропадающие на встречах продакты. Однако, даже если вы уже зрелый продакт, вы с большой вероятностью найдете для себя что-то полезное и применимое в работе.
Я рассчитываю, что предложенные мной инструменты позволят структурировать продуктовую рутину по проверке гипотез и принятию решений о реализации той или иной функциональности. А также поспособствуют росту взаимопонимания между продакт-менеджерами и командой разработки. Ведь нет ничего приятнее, чем в едином порыве пилить крутые фичи, ценность которых осознается всеми.

О ценности и задачах продакт-менеджеров

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

На мой взгляд, в этом и состоят основные задачи продакт-менеджера:

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

А теперь приземлимся на проблемы

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

Нащупать клиентскую боль

Так, а где же там надо пощупать, чтобы найти эту самую клиентскую боль? Если в вашей компании есть роль продакт-менеджера, то в ней наверняка настроен процесс получения обратной связи от клиентов. Существует множество каналов для коммуникации с клиентами: отзывы, feature requests, регулярные или периодические интервью/опросы, обращения в поддержку и так далее. Каждый из этих каналов может стать источником для того самого «нащупывания» клиентской боли.

Однако зачастую это ой как непросто. С какими препятствиями можно столкнуться:

Редко налажен четкий процесс работы с клиентскими обращениями через любой из каналов. Важно их правильно обрабатывать и систематизировать для последующего анализа — хотя бы тегировать. Банально высокая частота обращения по одной и той же теме/проблеме говорит о том, что там кроется что-то интересное. И продакт-менеджеру надо бы посмотреть повнимательнее, не залежалась ли там клиентская боль, которую можно вылечить.
Отсутствует процесс реагирования на обратную связь от клиентов. Если обращения клиента игнорируются или ответ провоцирует его отказаться от продукта, то большой пользы из анализа таких коммуникаций извлечь не удастся.

Обратная связь — один из самых понятных и «прямых» источников поиска боли, но не единственный.

Например, можно искать гипотезы о клиентской боли «на стороне». Например, у конкурентов, сравнив ваши и их возможности, прочитав их отзыв. Но мой вам совет — стройте процесс здорового общения с клиентами. Без него даже шикарная функциональность может не помочь развитию вашего продукта.

Другим источником для поиска клиентских болей и потребностей является аналитика — как поведенческая (как пользователь взаимодействует с вашим продуктом) и продуктовая, так и маркетинговая. Статистика способна:

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

Настроить корректный сбор аналитики и реализовать возможность удобной работы с данным — сложная задача. Даже в схожих по функциональности инструментах, например, Google Analytics и Яндекс Метрике, данные расходятся. Очень малому количеству компаний удается качественно организовать сбор и обработку статистических данных. Из-за необходимости использования аналитики в работе продакт-менеджера многие компании считают навык работы с данными обязательным для соискателей на эту позицию.

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

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

Проверить наличие боли/потребности. Измерить потенциальную ценность

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

Проверяем наличие боли

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

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

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

Бывает еще сложнее

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

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

Как тогда проверить наличие боли? Вариантов много, вот несколько из них:

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

Исследование потенциальной выгоды

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

Чтобы ответить на вопрос «А что нам принесет новая фича», и нужно проводить исследование. Один из методов понять — это эксперимент.

С экспериментами нужно быть осторожными, ведь нужно учитывать большое количество факторов, способных повлиять на его результат. Может оказаться, что спрос на ваше молоко вырос в момент, когда вы начали продавать его в бутылках, только потому что был день города. В районе, где вы торгуете, оказалось очень большое количество людей, что повлияло на рост продаж. Или время эксперимента совпало с запущенной по радио рекламой о продаже вашего молока и возросший спрос был обусловлен этим.
Работайте над дизайном вашего эксперимента тщательно, тогда вероятность получить репрезентативные и корректные результаты возрастет.

Помимо эксперимента, существует множество других методов исследования, способных помочь вам оценить потенциальную выгоду от новой функциональности / пользовательской возможности. В этом тексте не буду перечислять все, остановлюсь на любимом — финансовом или математическом моделировании. Оно может быть невероятно сложным, с громоздкими формулами, миллионом переменных, но не всегда такой уровень требуется. Зачастую простейшая модель в Excel может вам помочь найти ответ на вопрос — стоит делать фичу или нет.

Математическое моделирование. Пример

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

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

Вы используете эту информацию для своей модели, закладываете плановую конверсию в заказ больше на 7 п.п., чем есть сейчас. Теперь вы можете посчитать выручку и видите, насколько она возросла. Сравниваете это с потенциальными расходами на разработку. Прирост в выручке покрывает расходы на разработку? Да! Отлично, надо делать!

Суровая реальность

Нооо… мы же тут о проблемах, помните? Реальность такова, что сейчас вы получили позитивный сценарий, потому что основывались на амбициозных прикидках по времени на разработку и чужой статистике по росту конверсии. Теперь-то и начинается настоящее моделирование.

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

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

Подготовить материалы для разработки. Запилить Фичу

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

Казалось бы, чего сложного, возьми да расскажи команде, что нужно делать. Но как же на самом деле непросто сделать так, чтобы команда четко понимала, какой результат ожидается получить. А насколько сложно родить этот ожидаемый результат продакт-менеджеру, я и говорить не буду. Но тут есть лайфхак: подключать поддержку на этапе генерации ожидаемого результата, а не приходить с готовым ТЗ (которое в любом случае придется бить об реальность и править).

Расскажу, как мы это делаем в Selectel.

До того, как прийти с задачами к команде, продакт-менеджер отвечает на несколько вопросов. Список базовый, но подойдет, чтобы разобраться в логике и последовательности шагов:

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

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

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

Карточка фичи

Название фичи. Название, которое будет транслироваться для клиента, а не для команды разработки.
Краткое описание. Описание фичи и ее ЦА в паре предложений.
Ответственная команда. Кто будет заниматься разработкой фичи.
Задача. Ссылка на задачу в таск-менеджере.
Статус. В процессе/завершено/на паузе.

Контекст и предпосылки. Почему мы решили делать эту фичу? Если фича основана на исследовании, то дай ссылку на это исследование.
Бизнес-эффект. Что мы предполагаем получить, внедрив эту фичу? Как будем измерять? Какие метрики использовать?
Целевая аудитория фичи. Для кого эта фича? (описание как внешних пользователей, так и внутренних)
Как работает фича. Верхнеуровневое описание взаимодействия пользователя с фичей.
Преимущества фичи. Как мы можем позиционировать фичу клиентам?
Особенности и ограничения. Известные ограничения и особенности работы фичи.
Этапы и реализация. Описание этапов (если применимо) в формате:
- Название этапа (что и где).
- Краткое описание.
- Что нам этот этап даст.
- Ориентировочные сроки.
- Ссылка на задачу в таск-менеджере.
Артефакты. Каждая роль в команде может добавлять свои артефакты к фиче:
- Продакт — описание бизнес-процесса, результаты исследования, бизнес-требования.
- Продакт + UX — юзерфлоу, юзерстори, результаты исследования.
- UX — макеты, требуемые изменения в интерфейсе.
- Backend — техдизайн, описание логики работы на бэке, план работ.
- Frontend — план работ.
- QA — план тестирования.
FAQ. Основные вопросы и ответы на них. Раздел должен обновляться по мере поступления вопросов. Если к вам пришли с вопросом больше одного раза, то добавьте вопрос в этот раздел.

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

Конечно, все зависит от конкретной команды и инициативности ее членов. В Selectel процесс заполнения шаблона выглядит следующим образом:

Идеи, рожденные из обратной связи от клиентов, из исследований, из аналитики и т.д., проходят процесс приоритезации на уровне менеджмента. После того, как одна из них названа приоритетной и выбрана для реализации, продакт-менеджер собирает первичную информацию для заполнения карточки фичи и смысловых блоков с 1 по 4 включительно.
Если в процессе заполнения нет оснований для пересмотра приоритета функциональности, продакт-менеджер организует встречу с командой. Исходя из ожидаемых сроков и прогнозируемых результатов, в формате брейн-шторма накидываются варианты реализации. Могут быть выбраны экспериментальные варианты — например, MVP, Proof of Concept, Fake door. Эти подходы используются, если нет уверенности в том, что функциональность будет востребована, или нет представления, как она должна работать, чтобы решить задачу пользователей.
Далее продакт-менеджер анализирует предложенные варианты реализации. Пытается оценить возможные затраты по времени и ресурсам (aka фин/матмоделирование на более низком уровне). Соотносит это с ожидаемой ценностью (желательно в деньгах) от функциональности и выбирает один (или несколько) наиболее подходящих вариантов. Если определиться сложно, он может обсудить это с менеджментом и совместно прийти к решению.
На основе выбранного решения он корректирует четвертый блок «Как работает фича». Описывает процесс реализации, возможные ограничения и начинает формировать FAQ. В процессе продакт-менеджер общается по необходимому спектру задач с тим-лидом и другими членами команды разработки.
Теперь задача переходит UX-проектировщику, который в процессе разработки макетов дополняет шаблон необходимой для разработчиков информацией, а далее передает макеты и шаблон в работу.
В процессе разработки в шаблон еще могут вноситься изменения. Помните, что это совсем не страшно и даже правильно. Иметь план — это здорово, но гораздо важнее уметь адаптировать его к реальности.

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

Подробнее о работе с исследованиям с точки зрения организации процесса вы можете узнать в статье Discovery-процесс в продукте: из подземелья незнания — к лучшим решениям.

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

Отслеживаем результат внедрения фичи

Фичу запилили. Команда выдохнула, а продакт уже тащит новые задачи для разработки. На этом работа с фичей, которая уже в релизе, не останавливается. Надо же отслеживать результаты своих трудов. Сверять их с нашими ожиданиями, удивляться, радоваться или расстраиваться.

Какие проблемы могут поджидать нас тут?

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

Поэтому важно отслеживать эффективность функциональности не сразу после релиза, а в течение определенного времени после него. Реализованную фичу нельзя забрасывать, хотя чаще всего так и получается. Команда переключается на новые задачи, увлекается ими и не тратит время на анализ своих предыдущих действий. И даже мои слова о том, что отслеживать эффективность нужно какое-то время после релиза фичи, содержит проблему:, а сколько по времени это нужно делать? Сколько ресурсов на это нужно тратить? Как организовать такой процесс?

Универсального решения не существует. Моя рекомендация: пытаться на этапе работы над фичей (исследования, оценки потенциала) ставить сроки, в которые вы считаете необходимым отслеживать результат. Бывают фичи, эффект от которых продукт получит только через длительное время, есть моментально срабатывающие — все индивидуально.

От гипотезы к реализации

В практике Selectel был такой пример: в какой-то момент мы придумали решение, которое позволяло закрыть несколько внутренних и клиентских потребностей одновременно. Нам нужно было:

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

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

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

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

И еще одна задача продакт-менеджера: принять решение об избавлении от функциональности

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

Фича не показывает никакого результата, но при этом на ее поддержку приходится тратить силы и время. В данном случае решение о «выпиле» принять довольно просто. Если эта фича не затерялась среди множества таких же, и продакт, и команда просто не замечают ее.
Фича не взлетела, результат незначительный или отсутствует вообще, но фича живет сама по себе, «денег и сил не просит». Здесь подступиться к ней уже гораздо сложнее. Да и стоит ли? Иногда явно не стоит, потому что ресурсы на ее выпил могут потребоваться значительные. Обычно фича живет до тех пор, пока не приходит господин Большой Рефакторинг, в процессе которого она выкидывается. Но иногда она остается в продукте навсегда.

Есть мысли и о других вариантах? Буду рада, если поделитесь ими в комментариях.

Фичи — это не всегда хорошо. Часто бывает ощущение: новое, что мы делаем для клиентов, обязательно принесет им пользу, ведь мы так старались. Но стоит вспомнить «Дуров, верни стену», и так уже не кажется. Поэтому не стоит бояться ситуации, когда вам кажется, что функциональность должна быть выпилена. Это нормально.

Конец?

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

Миром правит информация, и в случае с продакт-менеджментом это актуально на 100%. Информация поможет продакт менеджеру и его команде найти клиентские боли, понять, что их нужно лечить, выяснить, какую ценность и полезность (идеально, если измеримые) может принести это лечение, отследить, как накладывается реальность на ожидания, и при необходимости, отказаться от «чемодана без ручки», какими могут становиться неудачные фичи.

В заголовке стоит знак вопроса, потому что мне интересно узнать, какие проблемы, на ваш взгляд, я еще не подсветила, а вы хотели бы узнать о них. Жду в комментариях. С любовью, из Selectel.