Чем занимаются вечно пропадающие на встречах продакты? Или путешествие из ХЗ в ТЗ

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

Используйте навигацию, если не планируете читать текст целиком:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

➡ Почему это нужно делать? Есть ли запрос от действующих клиентов? Что будет, если не сделаем?

➡ Кому это нужно?

➡ Какие кейсы использования этой фичи бывают?

➡ Какова цена ошибки? Какие риски?

➡ Это эксперимент или полноценная функциональность?

➡ Какие сроки?

➡ Кто-то уже делал такое? Как это выглядит?

➡ Как мы поймем полезность фичи?

➡ Какой приоритет у разработки фичи?

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

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

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

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

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

Задача. Ссылка на задачу в таск-менеджере.

Статус. В процессе/завершено/на паузе.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Читайте также:

#selectel #продактменеджмент #продукт