Семь раз протестируй, один — внедри: как генерировать и тестировать гипотезы для b2b-рынка

Можно ли создавать и внедрять инструменты, которые и бизнес-клиента привлекут, и продукту будут полезны – опыт b2b-продакта из СберМаркета.

Рынок b2b e-commerce огромен — в США в 2021 году его объем оценили в $7,72 трлн. Ожидается, что он будет расти каждый год примерно на 18% и через семь лет достигнет $25,65 тлрн.

• В 2023 году b2b-продажи составят 17% от всего объема торговли США.
• К 2025 году 80% всех b2b-сделок между поставщиками и бизнесом будут проходить только в онлайне.
  
• 73% клиентов в этом сегменте — миллениалы.

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

СберМаркет (экс-Instamart) начинался как b2b-сервис. Свои первые заказы мы доставляли именно корпоративным клиентам, и только потом переключились еще и на b2c.

В этом году мы усилили продукт для бизнеса: выделили на сайте отдельную витрину для компаний — и сделали для неё свои дизайн и функциональность. Также учли особенности проведения оплат и документооборот.

Все это – чтобы сделать традиционно «сложный» продукт для бизнеса как можно более приближенным к реальному пользователю: руководителю, менеджеру АХО, эйчару и так далее.

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

1. Команда. Сотрудники платформы, особенно Sales-менеджеры, ежедневно в контексте: видят метрики и аналитику. Им проще всего сформулировать гипотезу и предложить идею, что исправить или что добавить в продукт.
2. Анализ российского и зарубежного рынков. Смотрите, как другие компании в разных странах закрывают потребности и решают проблемы, похожие на ваши. И применяйте лучшие практики у себя.
   
3. Обратная связь. Это самое ценное. Слушайте, что говорит ваш клиент: он сам вам подскажет, какие функции работают, какие нет, что нужно добавить, а что вообще бесполезно.
   

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

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

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

Наш поход к продуктовой разработке – это Discovery to Delivery. То есть изучение и проверка гипотез, и только потом — разработка и «доставка» фичи до клиента. Все решения мы принимаем на основании данных и реальной ценности для пользователям.

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

Delivery – это все, что потом делает команда продукта: разработка, отладка, тестирование и запуск решения.

• Синхронизировать все функции в команде. А в первую очередь — понять требования к каждому. То есть какие у нас ожидания по каждой функции: кто готовит прототипы, дизайн коммуникаций, определяет целевые метрики и методы тестирования и так далее.
• Наметить набор возможных решений. Одну и ту же задачу можно решать по-разному за счет разных механик реализаций в продукте. Удобно распишите каждое возможное решение и составьте критерии для сравнения их между друг другом (ресурсоемкость, ожидаемый импакт на метрики и прочее).
  
• Исследовать каждое и найти оптимальное. Тут важен баланс времени, ресурсов команды, бюджета и ценности для бизнеса. К примеру, вы можете: Примеры: провести коридорные интервью с клиентами, количественный опрос или сравнительный анализ существующих решений на рынке.
  
• Составить план внедрения и определить критерии его успешности. Можно выбрать два типа метрик: те, на которые мы хотим положительно повлиять новым изменением, и те, на которые можем повлиять негативно. Их мониторинг поможет оценить успешность запуска.

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

Если ответы на все вопросы есть — можно делать MVP, а затем приступать к основной разработке.

Искать другие гипотезы.

Неудача на этапе идеи – шанс для компании сэкономить бюджет и ресурсы. Если идея провалилась на этапе discovery, значит, мы не потратили на внедрение фичи ни деньги, ни время.

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

Чтобы «выкристаллизовать» формулировку, можно задать себе контрольные вопросы:

• Для кого мы хотим внедрять решение?
• Какую «боль» мы закрываем? А она действительно есть?
  

• В какой момент эта «боль» возникает?

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

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

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