Есть ли разница между созданием продукта для потребителя и для бизнеса? Очевидно, что есть, хотя продуктовый менеджмент в 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. Спасибо Дмитрию Ковалю за помощь в подготовке статьи.
