Особенности B2B-custdev в SaaS

Мы с коллегой (@SKoloskov и @SLystsev) консультируем В2В-продукты уже более 5 лет, в том числе, помогаем наладить процессы дискаверинга и проверки гипотез. И у нас родилась статья с чек-листом, обобщающим опыт.

Как происходит дискаверинг? 

Всё как обычно:

• Аналитика - собирается из кликов и воронок, в результате получается понимание, кто чем и как пользуется, где есть проблемные места в воронке
• Обращения в техподдержку - все та же “Жалоба - это подарок”. Все, кто обращается в в2в, в отличие от в2с, чаще имеет в виду что-то конкретное и продуктивное, а не просто негатив и слезы. Но (!) часто  склонны подменять проблему самостоятельно придуманным решением, поэтому вся входящая информация по-прежнему требует творческого переосмысления
• Подсмотрели у конкурентов/сообщили друзья - фичи, которые дают сделаны и имеют хороший отклик у пользователей конкурентов.

Всё не как обычно:

• Фичи “под ключ” как сигнал, что функционал нужен. Каждый заказчик готов доплатить за улучшение. Если совпадений более 1 и выше, а фича тиражируемая и сводит экономику, делать надо.
• Интервью - глубинное интервью с получением обратной связи по текущим возможностям в продукте, получение инсайтов  и проверкой инсайтов и аналитики. Всегда важно добиваться не ответа на вопрос “готовы прямо сейчас купить?”, а хотя бы “готовы прямо сейчас инвестировать рабочий день на это?”
• Первая продажа - в процессе первой продажи возникает пакет предложений и замечаний к продукту. Там всегда будут как те, что конвертнутся в фичи под ключ, так и будут те, кому не хватило для продажи.
• Новые тарифы пользования - не быстрый дискаверинг, связанный с формированием и продажей нового предложения. Как правило, дискаверинг происходит на новых пользователях и проверяет продаваемость новых тарифов с валидацией гипотез о новых, улучшающих матмодель предложениях.

Как происходит валидация? 

• Рынок - расчеты объема рынка предполагаемой гипотезы в формате “в мире около 10 тыс крупных франшизовых сетей ресторанов азиатской кухни. Общий объем закупки продуктов в них достигает 6 млрд долларов в год, среди которых, потенциальные пользователи доработки - рестораны с кооперацией с другими кухнями (итальянской, мексиканской, и проч), для кого нужна разветвленная система приема продуктов, составляет 17%”.
• Глубинные проблемно - решенческие интервью: с построением сегментации пользователей и частотностью повторения инсайтов. Если сегменты и частотность сходятся по unit-экономике, значит валидация прошла. Мегаважно, что инсайты могут повторяться не просто в сегментах, а отраслях. Правила повторов инсайтов - повторения в правилах деятельности. Например, что закупщики выбирают подрядчика прежде всего по величине скидки.
• Проверка деньгами - предложить заплатить за доработки, новый тариф. Самая надежная валидация гипотезы. Важно, что заплатить за доработки и тариф должны столько раз, чтобы unit-экономика фичи сводилась в быстрый плюс. 

Проверка гипотез

• Приемлемый формат теста гипотез в B2B диктуется числом обслуживаемых “2B”
• При большом числе “2B” (сотни, тысячи и более) становятся доступны практики “2C” - потенциально можно проводить эксперименты:

1. A/B тесты; Включить функционал только части клиентов.  
2. mock функционала для замера заинтересованности (лендинги и подобное)

“Потенциально” - потому что в каких-то средах и культурах эксперименты могут оказаться неприемлемой бизнес-практикой. 

• Разумеется, мало кто готов делать эксперименты над самыми “толстыми” ВИП-клиентами. Эксперименты делаются над так называемым long tail - множеством мелких клиентов.
• Для “толстых” клиентов и при общем малом числе 2B-клиентов применяются другие практики, основанные на плотном контакте и общении:

1. Вместо mock’а в продукте делается классическое демо с опросом “надо / не надо”. здесь возникает классическая сложность, что собеседник может соглашаться неискренне
2. Вместо A/B теста на разных клиентах делается наблюдение за одним клиентом до/после внедрения
3. Здесь возникают сложности со скрытым влиянием каких-то других временных факторов:

• При демо и обсуждении, чтобы исключить ложное соглашательство, удобно рассматривать новую функцию как требующую отдельного коммитмента от клиента, что требует согласованной работы с командой продаж:
• оплата за сделанную работу (однако, это не самый лучший результат для бизнеса)
• отдельная оплата за использование именно этой функции
• согласие на повышение общей оплаты
• Однако, явный комминтмент не всегда возможен, и результаты могут оказаться в “серой зоне”
• согласие сохранить прежнюю оплату
• согласие на продление контракта

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

• Можно в дальнейшем попытаться совместно с командой продаж еще раз проверить ценность этого функционала - если клиент будет просить скидку, то предложить отключить такие функции за скидку. Согласие будет означать, что функционал не ценен. 
• Дальнейшее тестирование уже приходится вести с какой-то реализацией гипотезы (например, MVP). Если есть возможность отслеживать поведение клиента (в B2B это не всегда приемлемо), то можно делать выводы из наблюдаемого использования добавленного функционала.

Подписывайтесь на наши телеграм-каналы:
https://t.me/FreshProductGo
https://t.me/program_man