Есть ли разница между созданием продукта для потребителя и для бизнеса? Очевидно, что есть, хотя управление продуктом в b2b очень похоже на b2c, здесь также есть проблемы и опыт пользователей, гипотезы и требования, цели и метрики.
Но есть важное отличие – в b2b решения о покупке продукта и использовании его зачастую могут принимать разные люди.
Поэтому, с одной стороны, время и затраты бизнеса на начало использования продукта значительно выше, чем на потребительском рынке.
С другой стороны, компаниям гораздо сложнее отказаться от продукта, который они уже используют, чем отдельным пользователям.
Кроме того, входящий трафик в сегментах b2b и b2c существенно различается: во втором он обычно значительно выше.
Я являюсь менеджером группы продуктов компании iDeals, которая создает продукт b2b — виртуальные комнаты данных (VDR).
В этой статье я подробно расскажу о том, как мы построили процесс создания продукта и что мы делаем на каждом этапе.
За что
Процесс продукта:- снижает субъективизм в принятии решений продакт-менеджерами,
- облегчает понимание того, что и когда нужно сделать,
- добавляет прозрачности как внутри продуктовых команд, так и за ее пределами для смежных отделов.
Процесс продукта
Каждый шаг процесса создания продукта назван в соответствии с тем, в каком состоянии он находится или что происходит с идеей/гипотезой.Чтобы было легко отслеживать все существующие идеи, мы используем что-то похожее на Канбан-доска , где имя каждого столбца — это одноименный этап.
Идея
Все начинается с идеи, которую можно получить из совершенно разных источников, например из:- анализ рынка и конкурентов;
- качественные исследования пользователей и клиентов (интервью, опросы и т. д.);
- количественные исследования пользователей и клиентов (Heap, Bigquery, Google Analytics и т. д.);
- отзывы потенциальных и текущих клиентов и пользователей;
- идеи заинтересованных сторон или других команд;
- внутренние запросы от других команд;
- выводы после измерения показателей успеха.
Что важно: записываем каждое из них вместе с информацией о том, откуда и от кого оно пришло.
Также мы считаем, сколько было запросов с такими же или похожими идеями.
Мы стараемся как можно быстрее реагировать на каждую идею из внешних источников, особенно если она исходит от клиентов или пользователей.
Однако у нас есть условный срок 5 дней — мы используем его как максимум для ответа.
На следующем этапе каждый продакт-менеджер берет идею с наивысшим приоритетом исходя из количества запросов и трансформирует ее в гипотезу.
Примеры идей:
Привет! Можно ли как-то посмотреть все мои записи из комнаты данных? Я хотел бы видеть их в одном месте, чтобы мне не приходилось нажимать на разные файлы, для которых я их создал.
Привет! Я хотел бы проходить двухфакторную аутентификацию не каждый раз при попытке входа в систему, а только при наличии угроз безопасности моего аккаунта или при выполнении важных действий..
Гипотеза
Гипотеза отличается от идеи глубиной своей разработки.Обычно он содержит 4 блока, которые по сути отвечают на следующие вопросы:
- Какая проблема решается? Идея в формате гипотезы, содержащая информацию об аудитории, проблеме и условиях, при которых она возникает.
- Кто пострадает? Более подробная информация об аудитории или человеке, испытывающем проблему.
- На что это повлияет? Грубая оценка бизнес-показателей, на которые повлияет возможное решение проблемы, описанной в гипотезе.
Например, удовлетворенность клиентов или уровень конверсии из пробного аккаунта в клиентский аккаунт.
- Как сейчас решается проблема? Информация о внутреннем или внешнем обходном пути, который в настоящее время решает проблему.
Бывают определенные ситуации, когда идея в исходном виде не работает или за ней стоят совсем другие проблемы – по сравнению с теми, которые указаны первоисточником.
На этом этапе в процесс вступает расстановка приоритетов, призванная бороться с субъективизмом и ориентировать продуктовый процесс на работу только с наиболее влиятельными и важными идеями.
Для этого в iDeals мы используем модифицированный подход РИС от Интеркома (Охват*Воздействие*Уверенность/Усилие), который был дополнен еще одним параметром - Стратегия (S) и в итоге получил RICSE (Охват*Воздействие*Уверенность*Стратегия/Усилие):
- Охват определяет, сколько пользователей, транзакций или, в нашем случае, проектов (комнат) будет затронуто решением проблемы из гипотезы.
- Влияние — это условный коэффициент того, насколько решение проблемы из гипотезы повлияет на пользовательский опыт аудитории.
Мы используем шкалу от 0 до 3 с шагом 0,25, каждый шаг означает силу влияния: от 0 – нет влияния, до 3 – огромное влияние.
- Стратегия показывает, насколько это решение вписывается в наши долгосрочные планы.
Мы используем три значения стратегии: 0,3 – не соответствует стратегии; 0,8 – частичное соответствие; 1 – полное соответствие.
- Усилие (усилие) — это оценка высокого уровня, для которой мы используем Числа Фибоначчи , к которым привязаны календарные периоды: 1 – до 2 недель; 3 – до месяца; 5 – до блока; 8 – до двух блоков; 13 – два квартала и более (или фактически, когда оценка крайне неточна, но понятно, что решение будет очень трудоемким).
- Доверие является условным коэффициентом доверия ко всем остальным показателям и может принимать значение от 0,1 до 1. Обычно мы используем шаг -0,2 для каждого показателя, в котором есть сомнение.
Например, если мы не очень уверены в освещении, то уверенность равна 0,8, а если мы еще и уверены во влиянии – 0,6 и т. д.
Например, для Reach (охвата) достаточно понимать, что если определенная функция используется в определенном количестве проектов, то это число и будет использоваться как Reach. На следующем этапе мы проверим эту цифру более детально и получим максимально близкое число.
Пример гипотезы: Какая проблема решается? Мы считаем, что пользователи с включенной двухфакторной аутентификацией недовольны тем, что им приходится вводить код подтверждения каждый раз, когда они входят в систему, когда они используют одно и то же устройство из одного и того же места.
Кто пострадает? Пользователи с включенной двухфакторной аутентификацией независимо от роли и прав доступа.
На что это повлияет?
- Сократите затраты на отправку кодов двухфакторной аутентификации по SMS и звонкам.
- Уменьшение количества случаев, когда из-за невозможности доставки кода пользователь не может авторизоваться в системе.
- Повышение удовлетворенности пользователей.
Проверка
В ходе валидации мы пытаемся получить более правильную оценку всех показателей RICSE, а также максимально приблизить Confidence (доверие) к 1. Таким образом, весь этап валидации — это попытка «оцифровать доверие» и оценить неопределенность..
На этом этапе мы привлекаем продуктового аналитика, вместе собираем данные и делаем первые прогнозы на основе гипотезы.
На этом этапе есть два возможных решения:
- У нас есть все необходимые данные, чтобы подтвердить гипотезу и двигаться дальше.
- У нас нет данных, подтверждающих гипотезу.
Для этого используем типовые инструменты: Google Analytics, Heap, BigQuery; опросы – для количественных данных, интервью, запросы и отзывы клиентов – для качественных данных.
Во втором случае для некоторых гипотез, в которые особенно верит команда, мы можем провести эксперимент, тестирование или дополнительные опросы с интервью, чтобы собрать необходимые данные и понять, верна гипотеза или нет. Завершение этапа – обновленные показатели и отчеты RICSE, таблицы Excel, записи интервью и другие данные, подтверждающие эти показатели.
Гипотезы, имеющие наивысший приоритет, принимаются в дальнейшее развитие.
Пример гипотезы и проверки: Гипотеза
Мы считаем, что пользователи, отвечающие за загрузку документов в проект, смогут лучше решить проблему безопасного и контролируемого обмена документами, если будут чаще использовать функцию разархивирования архива при загрузке документов.Данные проверки:
По данным на 4 квартал 2020 года, около 30% всех проектов имеют более одного архива в формате ZIP, RAR или 7Z, но только 1,7% проектов с архивами когда-либо использовали функцию разархивирования.
Решение (ПРД)
Этот этап целиком посвящен самому решению и созданию «документа требований к продукту» (PRD/productquirements document) и состоит из следующих шагов:- исследование рынка того, как проблема, лежащая в основе гипотезы, решается прямыми и косвенными конкурентами, а также продукцией других отраслей;
- идентификация лиц, являющихся покупателями и пользователями решения;
- выявление возможных потоков, характерных для разных людей;
- создание пользовательских историй, чтобы понять полную картину и все возможные нюансы;
- обсуждение уже полученных разработок с технической командой для определения того, возможно ли все это, нужны ли дополнительные технические исследования или необходимо создание технических концепций (proof of Concept);
- детальная разработка пользовательского опыта и интерфейса (UX/UI);
- Разработка UX/UI и консультации с технической командой могут быть итеративными;
- создание динамических прототипов для подтверждения жизнеспособности и удобства разработанного решения реальными или максимально похожими пользователями;
- определение необходимых маркетинговых мероприятий: общение по электронной почте/продукту; материалы для маркетинговых сайтов, влияние на цены и планы и т.д.;
- Определение показателей и показателей успеха, которые будут измеряться после выпуска решения, чтобы гарантировать, что оно действительно решает основную проблему, полезно для пользователей и ценно для бизнеса.
С одной стороны, они помогают лучше понять проблему и решение, с другой — позволяют продемонстрировать клиентам, когда появится прототип.
Менеджер продукта описывает только само решение и поток.
Затем подключается техническая команда, чтобы оценить, реалистично ли это реализовать.
После этого прототип решения разрабатывается совместно с дизайнером продукта и утверждается с клиентами.
Затем прототип и поток снова показывают технической команде, чтобы получить оценку высшего уровня: спринт, два спринта, полчетверти, четверть или две четверти.
Поскольку решение еще не полностью описано, точную оценку на данном этапе ожидать нельзя.
Полученная выше смета нужна лишь для приблизительного понимания трудозатрат. Таким образом, получается, что формула RISCE: Реакция * Воздействие * Стратегия * Уверенность/Усилия получает подтверждение по всем элементам и гипотезам/решениям снова присваивается приоритет с учетом всех переменных в формуле.
Дорожная карта
В конце каждого квартала продакт-менеджеры совместно с инженерными менеджерами и командами составляют Дорожную карту на предстоящий квартал для каждой технической команды (у нас их 6).В него входят уже готовые решения.
Иногда встречаются также гипотезы технической или продуктовой разработки, имеющие высшие приоритетные значения по данным RICSE. Также мы оставляем часть инженерного времени (до 15-20%) для доработок, связанных с инструментами для внутренних заказчиков (поддержка, отделы продаж и т. д.), технического долга и идей, не имеющих надежной информационной поддержки, но кажущихся многообещающими.
Для прозрачности и удобства отслеживания дорожной карты мы используем специальный шаблон в Notion .
Каждые пару недель менеджеры по продуктам или инженерам обновляют информацию о ходе и статусе каждого элемента.
Менеджеры по маркетингу, поддержке, продажам и другие также имеют доступ к этому шаблону, чтобы иметь возможность в любой момент узнать статус интересующего их решения.
Ежемесячно мы проводим встречи для обсуждения всех нюансов и вопросов, связанных с реализацией дорожной карты, а также возможного перераспределения приоритетов или инженерных ресурсов.
Выполнение
В среде iDeals команды работают по процессу, очень близкому к Скрам , со всеми соответствующими артефактами: итеративная разработка, ежедневные встречи по 5-10 минут для быстрой синхронизации, еженедельные встречи для обсуждения новых пользовательских историй, каждые две недели — планирование следующей итерации (Спринт) и проведение ретроспективы по последней.Менеджеры по продуктам обычно пишут подробные критерии приемки для каждой пользовательской истории в рамках конкретного решения, а затем обсуждают их с командой.
Прежде всего, это дает команде бизнес-контекст, помогает выявить возможные упущения и, конечно же, получить более точные оценки и прогнозы.
Когда приближается следующий спринт, планирование происходит в первый день: распределяется, кто что будет делать в течение следующих двух недель.
Каждый второй спринт — это выпуск новых улучшений продуктовой среды.
В конце каждого месяца происходит внутренняя демонстрация нового функционала для синхронизации с другими командами (например, отделом продаж) и признания достижений всех, кто участвует в разработке.
Во время реализации гипотезы для подготовки всех коммуникаций по ней привлекаются и другие команды, например, маркетинг.
Также подготавливаются все необходимые отчеты для измерения эффективности разрабатываемых решений.
После того, как решение развернуто на всю аудиторию и запущены коммуникации, продакт-менеджер совместно с продуктовым аналитиком отслеживают метрики.
Проверка
На этом этапе мы собираем и сравниваем метрики, полученные в результате внедрения и выпуска решения, с теми, которые были установлены на этапе подготовки.Если все метрики успешно достигнуты, то в большинстве случаев задача закрывается и выводы фиксируются со ссылкой на исходную гипотезу без каких-либо дополнительных шагов.
Если какие-то метрики не достигнуты или достигнуты не полностью, то мы пытаемся понять причины и сделать выводы в виде новых идей, гипотез или улучшений текущего решения.
Заключение
Независимо от того, создаете ли вы продукт в сфере b2b или b2c, он должен быть понятным, простым в использовании и эффективным.В обоих случаях пользователи — такие же люди, как и вы, поэтому работа с продуктом также требует общения с ними, исследования и отслеживания различных метрик.
Да, в B2B покупатель и пользователь зачастую не один и тот же человек, но регулярная обратная связь от тех, кто использует ваше решение, поможет вам найти новые идеи и выдвинуть гипотезы.
Вы также проверяете свои предположения, расставляете приоритеты и сосредотачиваетесь на том, что важно для вашей аудитории.
Как в вашей компании организован продуктовый процесс? Поделитесь в комментариях! P.S. Спасибо Дмитрию Ковалю за помощь в подготовке статьи.
Теги: #Управление продуктом #разработка продукта #разработка продукта #менеджмент продукта #SaaS / S+S #продукт #менеджмент продукта
-
Как Удалить Всплывающую Рекламу
19 Oct, 24 -
Поговорим О Градиентах В Unity
19 Oct, 24 -
История Игровой Рекламы
19 Oct, 24 -
#4 Джокаст
19 Oct, 24
