Есть ли разница между созданием продукта для потребителя и для бизнеса? Очевидно, что есть, хотя продуктовый менеджмент в b2b очень похож на b2c, здесь также есть пользовательские проблемы и опыт, гипотезы и требования, цели и метрики. Но есть и важное отличие – в b2b принимать решения о покупке продукта и пользоваться им часто могут разные люди.
Поэтому c одной стороны время и затраты на начало пользования продуктом бизнесами значительно выше, чем на потребительском рынке. А с другой – компаниям гораздо тяжелее отказаться от уже используемого продукта, чем отдельным пользователям. Кроме этого, входящий трафик в b2b и b2c сегментах существенно отличается: у второго он обычно значительно выше.
Я Group Product Manager компании iDeals, которая создает b2b-продукт – виртуальные комнаты данных (VDR). В этой статье подробно расскажу о том, как мы выстроили продуктовый процесс и что делаем на каждом из этапов.
Для чего
Продуктовый процесс:
уменьшает субъективизм в принятии решений продуктовыми менеджерами,
упрощает понимание того, что и в какой момент времени необходимо делать,
добавляет прозрачности как внутри продуктовых команд, так и за их пределами для смежных подразделений.
Руководители и члены других команд (например, поддержки или продаж) могут в любой момент зайти и понять, на каком этапе находится та или иная идея, а также какой у нее приоритет.
Продуктовый процесс
Каждый шаг продуктового процесса называется в соответствии с тем, в каком состоянии находится или что происходит с идеей / гипотезой. Для простоты отслеживания всех существующих идей мы используем что-то похожее на Kanban доску, где имя каждой колонки – это одноименный этап.
Идея
Все начинается с идеи, которая может быть получена из абсолютно разных источников, например из:
анализа рынка и конкурентов;
качественных исследований пользователей и клиентов (интервью, опросы и т. д.);
количественных исследований пользователей и клиентов (Heap, Bigquery, Google analytics и т. д.);
обратной связи от потенциальных и нынешних клиентов и пользователей;
идей от стейкхолдеров или других команд;
внутренних запросов от других команд;
выводов после измерения показателей успеха.
Иными словами, идея может появиться откуда угодно. Что важно: каждую из них мы записываем вместе с информацией, откуда или от кого она появилась. Также ведем подсчет, сколько было запросов с одинаковыми или похожими идеями.
На каждую идею из внешних источников мы стараемся отвечать как можно быстрее, особенно, если она приходит от клиентов или пользователей. Тем не менее, у нас есть условный срок в 5 дней – его мы используем как максимальный для ответа. На следующем этапе каждый продуктовый менеджер берет наиболее приоритетную идею по количеству обращений и трансформирует в гипотезу.
Примеры идей:
Привет! А можно ли как-то увидеть все свои заметки из комнаты данных? Я бы хотел видеть их в одном месте, чтобы не ��ликать на разные файлы, для которых я их сделал.
Здравствуйте!
Я бы хотел проходить двухфакторную аутентификацию не каждый раз при попытке зайти в систему, а только когда есть угрозы безопасности моей учетной записи или при выполнении важных действий.
Гипотеза
Гипотеза отличается от идеи глубиной проработки. Обычно в ней 4 блока, которые по сути отвечают на следующие вопросы:
Какая проблема решается? Идея в формате гипотезы, которая содержит информацию об аудитории, проблеме и условиях, когда она возникает.
На кого повлияет? Более детальная информация об аудитории или персоне, которая испытывает проблему.
На что повлияет? Приблизительная оценка бизнес-показателей, на которые повлияет возможное решение проблемы, описанной в гипотезе. Например, удовлетворенность клиентов или уровень конверсии из пробного (триального) аккаунта в клиентский.
Как сейчас решается проблема? Информация об обходном пути внутри продукта или за его пределами, с помощью которого сейчас решается проблема.
Гипотеза может изменять, дополнять или расширять суть изначальной идеи и часто так и происходит. Идеи зачастую приходят из источников, которые не обладают всеми знаниями о продукте. Есть определенные ситуации, когда идея в своем первоначальном виде не будет работать или за ней кроются совершенно другие проблемы – по сравнению с теми, на которые указывает первоисточник.
На этом этапе в процесс вступает приоритизация, которая призвана бороться с субъективизмом и ориентировать продуктовый процесс на работу только с самыми влиятельными и важными идеями. Для этого в iDeals мы используем модифицированный подход RICE от Intercom (Reach * Impact * Confidence / Effort), который дополнили еще одним параметром – Strategy (S) и в итоге получили RICSE (Reach * Impact * Confidence * Strategy / Effort):
Reach (охват) определяет, на какое количество пользователей, транзакций или, в нашем случае, проектов (комнат) повлияет решение проблемы из гипотезы.
Impact (влияние) – условный коэффициент того, как сильно решение проблемы из гипотезы повлияет на пользовательский опыт аудитории. Мы используем шкалу от 0 до 3 с шагом 0.25, каждый из шагов значит силу влияния: от 0 – нет влияния, до 3 – влияние огромное.
Strategy (стратегия) показывает, на сколько это решение ложится в наши долгосрочные планы. Мы используем три значения стратегии: 0,3 – нет соответствия стратегии; 0,8 – частичное соответствие; 1 – полное соответствие.
Effort (трудозатраты) – это высокоуровневая оценка, для которой мы используем числа Фибоначчи, к которым привязаны календарные периоды: 1 – до 2 недель; 3 – до месяца; 5 – до квартала; 8 – до двух кварталов; 13 – два квартала и больше (или по факту, когда оценка крайне неточна, но понятно, что решение будет очень трудозатратным).
Confidence (уверенность) – условный коэффициент уверенности во всех других показателях и может принимать значение от 0,1 до 1. Обычно мы используем шаг –0,2 для каждого показателя, в котором есть сомнения. Например, если мы не очень уверены в охвате, то уверенность 0,8, а если еще и во влиянии – 0,6 и т.д.
На этом этапе, мы используем приблизительные показатели и не сильно углубляемся в правильную оценку. Например, для Reach (охват) достаточно понять, что если определенную функцию используют в неком количестве проектов, это число и будет использоваться как Reach. На следующем этапе эту цифру мы проверим более подробно и получим максимально близкое число.
Пример гипотезы:
Какая проблема решается?
Мы считаем, что пользователи с включенной двухфакторной аутентификацией недовольны необходимостью каждый раз при входе в систему вводить код подтверждения, когда они используют одно и тоже устройство из одного и того же м��ста.
На кого повлияет?
Пользователи с включенной двухфакторной аутентификацией, независимо от роли и прав доступа.
На что повлияет?
Уменьшение расходов на отправку кодов для двухфакторной аутентификации через СМС и звонки.
Уменьшение количества случаев, когда из-за невозможности доставить код пользователь не может войти в систему.
Повышение уровня удовлетворенности пользователей.
Как сейчас решается проблема?
Отключением двухфакторной аутентификации.
Валидация
При валидации мы пытаемся получить более правильную оценку всех показателей RICSE, а также максимально приблизить Confidence (уверенность) к 1. Таким образом, весь этап валидации – это попытка «оцифровать уверенность» и оценить неопределенность. На данном этапе мы подключаем продуктового аналитика, вместе собираем данные и строим первые прогнозы по гипотезе.
Этот этап имеет два возможных пути решения:
У нас есть все необходимые данные для подтверждения гипотезы и движения дальше.
У нас нет данных для подтверждения гипотезы.
В первом случае мы проверяем ретроспективно, исходя из разных данных, которые у нас уже есть. Для этого используем типичные инструменты: Google Analytics, Heap, BigQuery; опросы – для количественных данных, интервью, запросы и отзывы клиентов – для качественных.
Во втором случае для некоторых гипотез, в которые команда особенно верит, мы можем запустить эксперимент, тестирование или дополнительные опросы с интервью, чтобы собрать необходимые данные и понять, верна ли гипотеза или нет.
Окончание этапа – обновленные показатели RICSE и отчеты, Excel таблицы, записи интервью и другие данные, которые подтверждают эти показатели.
Гипотезы с наибольшей приоритизацией берутся в дальнейшую проработку.
Пример гипотезы и валидации:
Гипотеза
Мы верим, что пользователи, которые ответственны за загрузку документов в проект, смогут более успешно решать проблему безопасного и контролируемого обмена документами, если будут чаще использовать функцию разархивации для архивов при загрузке документов.
Данные для валидации:
По данным за 4-й квартал 2020-го года около 30% всех проектов имеют больше одного архива в формате ZIP, RAR или 7Z, но при этом только 1.7% из проектов с архивами хоть раз использовали функцию разархивации.
Решение (PRD)
Данный этап целиком и полностью посвящен самому решению и созданию «product requirements document» (PRD / документ с требованиями к продукту) и состоит из следующих шагов:
исследование рынка на предмет того, как лежащая в основе гипотезы проблема решается прямыми и непрямыми конкурентами, а также продуктами из других отраслей;
определение персон, которые являются покупателями и пользователями решения;
определение возможных флоу, которые являются характерными для разных персон;
создание пользовательских историй (user stories) для понимания полной картины и всех возможных нюансов;
обсуждение уже полученных наработок с технической командой на предмет того, является ли это все возможным, нужно ли проводить дополнительные технические исследования или создавать технические концепты (proof of concept);
детальная проработка пользовательского опыта и интерфейса (UX / UI);
проработки UX / UI и консультации с технической командой могут быть итеративными;
создание динамических прототипов для подтверждения жизнеспособности и удобства разработанного решения с реальными или максимально похожими по профилю пользователями;
определение необходимых маркетинговых активностей: коммуникация через имейл / продукт; материалы для маркетинг-сайтов, влияние на прайсинг и планы и т.д.;
определение индикаторов и показателей успеха, которые будут измеряться после выхода решения в свет, для понимания, что оно действительно решает первичную проблему, полезно для пользователей и ценно для бизнеса.
Обычно на этом этапе проводятся пользовательские интервью. С одной стороны, они помогают лучше понять проблему и решение, с другой – позволяют сделать демонстрацию клиентам, когда появляется прототип.
Продуктовый менеджер описывает только само решение и флоу. Затем подключается техническая команда – для того чтобы оценить, реально ли это реализовать. После чего с продуктовым дизайнером прорабатывается прототип решения и валидируется с клиентами.
Затем прототип и флоу еще раз показывается технической команде для получения верхнеуровневой оценки: спринт, два спринта, пол-квартала, квартал или два квартала. Так как решение еще не является полностью описанным, нельзя ожидать точной оценки на данном этапе. Оценка, полученная выше, нужна лишь для приблизительного пон��мания трудозатрат.
Таким образом получается, что формула RISCE: React * Impact * Strategy * Confidence / Effort получает подтверждения по всем элементам и гипотезы / решения вновь приоритизируются уже учитывая все переменные в формуле.
Дорожная карта (Roadmap)
В конце каждого квартала продуктовые менеджеры вместе с инженерными менеджерами и командами составляют дорожную карту (Roadmap) на ближайший квартал для каждой технической команды (их у нас 6). В нее попадают уже подготовленные решения. Иногда – и гипотезы для технической или продуктовой проработки, которые имеют наивысшие значения приоритета по RICSE.
Также мы оставляем часть инженерного времени (до 15-20%) на доработки, связанные с инструментами для внутренних потребителей (команды поддержки, продаж и тд.), техническим долгом и идеями, которые не имеют твердого подтверждения данными, но кажутся перспективными.
Для прозрачности и простоты отслеживания дорожной карты мы используем специальный шаблон в Notion. Каждые пару недель продуктовые или инженерные менеджеры обновляют прогресс и статус каждого пункта. К этому шаблону также имеют доступ руководители маркетинга, поддержки, продаж и других, чтобы иметь возможность в любой момент узнать статус интересующего решения.
Каждый месяц мы проводим встречи для обсуждения всех нюансов и вопросов по реализации дорожной карты, а также возможных перераспределений приоритетов или инженерных ресурсов.
Имплементация
В условиях iDeals команды работают по процессу, который очень близок к Scrum, со всеми соответствующими артефактами: итеративная разработка, ежедневные встречи по 5-10 минут для быстрой синхронизации, еженедельные встречи для обсуждений новых пользовательских историй, каждые две недели – планирование очередной итерации (Спринта) и проведение ретроспективы по прошлой.
Продуктовые менеджеры на постоянной основе прописывают детальные критерии приемки для каждой пользовательской истории в рамках конкретного решения, а потом обсуждают их с командой. Прежде всего, это дает бизнес-контекст команде, помогает определять возможные упущения и, конечно, же получать более точную оценку и делать прогнозирование.
При подходе очередного спринта, в первый день происходит планирование: распределяется, кто и чем займется в рамках следующих двух недель. Каждый второй спринт – выпуск на продуктовое окружение новых доработок.
В конце каждого месяца происходит внутреннее демо нового функционала, для того, чтобы синхронизироваться с другими командами (например, командой продаж) и признать заслуги всех участвующих в разработке.
Во время имплементации гипотезы также подключаются и другие команды, например, маркетинг, для подготовки всех коммуникаций по ней. Также, подготавливаются все необходимые отчеты для замеров эффективности разрабатываемых решений. После того как решение раскатывается на всю аудиторию и коммуникации запущены, продуктовый менеджер вместе с продуктовым аналитиком ведут наблюдение за метриками.
Верификация
На данном этапе собираем и сравниваем метрики, полученные в результате имплементации и выпуска решения, с теми, которые устанавливались на этапе подготовки.
Если все метрики успешно достигнуты, то в большинстве случаев задача закрывается и выводы записываются со ссылкой на изначальную гипотезу без каких-либо дополнительных шагов. Если же какие-то метрики не достигнуты или достигнуты не полностью, то мы пытаемся понять причины и сделать выводы в виде новых идей, гипотез или улучшений для текущего решения.
Вывод
Создаете ли вы продукт в b2b или b2c сфере, он должен быть понятным, простым в использовании и эффективным. В обоих случаях пользователи – такие же люди, как вы, поэтому для работы с продуктом также необходимо общение с ними, исследования и отслеживание различных метрик.
Да, в b2b покупатель и пользователь – часто не одно и то же лицо, но регулярный фидбек от тех, кто использует ваше решение поможет вам находить новые идеи и выдвигать гипотезы. Вы также тестируете свои предположения, выставляете приоритеты и фокусируетесь на том, что важно вашей аудитории.
Как устроен продуктовый процесс в вашей компании? Делитесь в комментариях!
P.S. Спасибо Дмитрию Ковалю за помощь в подготовке статьи.
