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

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

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

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

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

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

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

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

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

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

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

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

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

Однако зачастую это ой как непросто.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Расскажу, как делаем мы, а дальше вы решайте для себя, подходит ли такой формат. 

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

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

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

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

Название фичи. Название, которое будет транслироваться для клиента, а не для команды разработки. 

Краткое описание. Описание фичи и ее ЦА в паре предложений.

Ответственная команда. Кто будет заниматься разработкой фичи.

Задача. Ссылка на задачу в таск-менеджере. Статус. В процессе/завершено/на паузе.

• Контекст и предпосылки. Почему мы решили делать эту фичу? Если фича основана на исследовании, то дай ссылку на это исследование.
• Бизнес-эффект. Что мы предполагаем получить, внедрив эту фичу? Как будем измерять? Какие метрики использовать?
• Целевая аудитория фичи. Для кого эта фича? (описание как внешних пользователей, так и внутренних).
• Как работает фича. Верхнеуровневое описание взаимодействия пользователя с фичей.
• Преимущества фичи. Как мы можем позиционировать фичу клиентам?
• Особенности и ограничения. Известные ограничения и особенности работы фичи.
• Этапы и реализация. Описание этапов (если применимо) в формате:

1. Название этапа (что и где).
2. Краткое описание.
3. Что нам этот этап даст.
4. Ориентировочные сроки.
5. Ссылка на задачу в таск-менеджере.

• Артефакты. Каждая роль в команде может добавлять свои артефакты к фиче:

1. Продакт — описание бизнес-процесса, результаты исследования, бизнес-требования.
2. Продакт + UX — юзерфлоу, юзерстори, результаты исследования.
3. UX — макеты, требуемые изменения в интерфейсе.
4. Backend — техдизайн, описание логики работы на бэке, план работ.
5. Frontend — план работ.
6. QA — план тестирования.

• FAQ. Основные вопросы и ответы на них. Раздел должен обновляться по мере поступления вопросов. Если к вам пришли с вопросом больше одного раза, то добавьте вопрос в этот раздел.

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

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

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

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

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

Но, конечно же, на этом все не заканчивается.

Еще одна задача продакт-менеджера

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

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

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

Универсального решения не существует

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

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

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

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

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

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

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

И еще одна задача продакт-менеджера

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

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

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

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

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

Заключение

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

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