Семь раз протестируй, один — внедри: как генерировать и тестировать гипотезы для b2b-рынка
Можно ли создавать и внедрять инструменты, которые и бизнес-клиента привлекут, и продукту будут полезны – опыт b2b-продакта из СберМаркета.
Рынок b2b e-commerce огромен — в США в 2021 году его объем оценили в $7,72 трлн. Ожидается, что он будет расти каждый год примерно на 18% и через семь лет достигнет $25,65 тлрн.
- В 2023 году b2b-продажи составят 17% от всего объема торговли США.
- К 2025 году 80% всех b2b-сделок между поставщиками и бизнесом будут проходить только в онлайне.
- 73% клиентов в этом сегменте — миллениалы.
Это очень емкий и надежный для платформ сектор: здесь можно получить больше выручки и надолго удержать крупного клиента.
Где брать идеи для b2b-продукта
СберМаркет (экс-Instamart) начинался как b2b-сервис. Свои первые заказы мы доставляли именно корпоративным клиентам, и только потом переключились еще и на b2c.
В этом году мы усилили продукт для бизнеса: выделили на сайте отдельную витрину для компаний — и сделали для неё свои дизайн и функциональность. Также учли особенности проведения оплат и документооборот.
Все это – чтобы сделать традиционно «сложный» продукт для бизнеса как можно более приближенным к реальному пользователю: руководителю, менеджеру АХО, эйчару и так далее.
Оптимизация продукта под потребности клиента – бесконечный процесс. Помогают три главных источника идей:
- Команда. Сотрудники платформы, особенно Sales-менеджеры, ежедневно в контексте: видят метрики и аналитику. Им проще всего сформулировать гипотезу и предложить идею, что исправить или что добавить в продукт.
- Анализ российского и зарубежного рынков. Смотрите, как другие компании в разных странах закрывают потребности и решают проблемы, похожие на ваши. И применяйте лучшие практики у себя.
- Обратная связь. Это самое ценное. Слушайте, что говорит ваш клиент: он сам вам подскажет, какие функции работают, какие нет, что нужно добавить, а что вообще бесполезно.
Пример с обратной связью: у нас есть опция работы по предоплате. Пользователи вносят часть своего бюджета и получают моментальную передачу заказов в сборку, упрощенные взаимозачеты и контроль расходов.
Подключение даже к такой схеме расчетов занимает от недели, внесение средств возможно только с помощью клиентского менеджера и установлены лимиты на минимальный остаток на балансе. Оказалось, что клиентам нужно быстрей. Проблема была в сложном процессе согласования договора и лимитах на минимальную сумму на балансе.
Мы пошли в сторону клиента и упразднили эти ограничения. Теперь заключение отдельного договора не требуется, достаточно согласиться с офертой при регистрации компании.
Как приступить к реализации
Наш поход к продуктовой разработке – это Discovery to Delivery. То есть изучение и проверка гипотез, и только потом — разработка и «доставка» фичи до клиента. Все решения мы принимаем на основании данных и реальной ценности для пользователям.
Процесс discovery начинается тогда, когда у вас уже есть первый пул идей: после работы с командой, сбора аналитики, обратной связи от клиентам. Его цель — определить целевое решение перед внедрением.
Delivery – это все, что потом делает команда продукта: разработка, отладка, тестирование и запуск решения.
Чтобы начать этап discovery, надо:
- Синхронизировать все функции в команде. А в первую очередь — понять требования к каждому. То есть какие у нас ожидания по каждой функции: кто готовит прототипы, дизайн коммуникаций, определяет целевые метрики и методы тестирования и так далее.
- Наметить набор возможных решений. Одну и ту же задачу можно решать по-разному за счет разных механик реализаций в продукте. Удобно распишите каждое возможное решение и составьте критерии для сравнения их между друг другом (ресурсоемкость, ожидаемый импакт на метрики и прочее).
- Исследовать каждое и найти оптимальное. Тут важен баланс времени, ресурсов команды, бюджета и ценности для бизнеса. К примеру, вы можете: Примеры: провести коридорные интервью с клиентами, количественный опрос или сравнительный анализ существующих решений на рынке.
- Составить план внедрения и определить критерии его успешности. Можно выбрать два типа метрик: те, на которые мы хотим положительно повлиять новым изменением, и те, на которые можем повлиять негативно. Их мониторинг поможет оценить успешность запуска.
В дискавери-процессе команда учитывает все направления бизнеса. Как обновление будет выглядеть в дизайне, сколько времени уйдет на разработку и как пользователь узнает об изменениях? Какие риски возникнут и какой эффект она ожидает от внедрения?
Если ответы на все вопросы есть — можно делать MVP, а затем приступать к основной разработке.
Что делать, если дискавери-процесс провалился
Искать другие гипотезы.
Неудача на этапе идеи – шанс для компании сэкономить бюджет и ресурсы. Если идея провалилась на этапе discovery, значит, мы не потратили на внедрение фичи ни деньги, ни время.
Чтобы проверка гипотезы оказалась успешной, нужно правильно ее сформулировать. В противном случае может возникнуть расхождение между изначальной идеей и тем, что мы в итоге проверяем.
Чтобы «выкристаллизовать» формулировку, можно задать себе контрольные вопросы:
- Для кого мы хотим внедрять решение?
- Какую «боль» мы закрываем? А она действительно есть?
В какой момент эта «боль» возникает?
- Как ее решают сейчас? Почему будут пользоваться новым решением?
- На какую ключевую метрику в нашем продукте мы хотим повлиять и какое наше прогнозируемое изменение?
- Когда мы должны увидеть результат, чтобы убедиться в правильности гипотезы?
Гипотеза должна быть предметной, а также соответствовать стратегии компании. Иначе ее невозможно проверить.
Если формулировка вышла размытой — стоит декомпозировать гипотезу на несколько, приоритизировать и проработать каждую из них по порядку.
Не, ну вы хотя бы не так палитесь)
Ну с чего-то начинать надо))))
Поясните, не понял)