Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-03-10

1 <p>Теги: продакт-менеджер, product manager, b2b-custdev, дискаверинг</p>

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

3 <h2>Как происходит дискаверинг?</h2>

4 <h4>Всё, как обычно:</h4>

5 <ul><li><strong>Аналитика</strong>- собирается из кликов и воронок, в результате получается понимание, кто чем и как пользуется, где есть проблемные места в воронке.</li>

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

7 <li>Подсмотрели у конкурентов/сообщили друзья -<strong>фичи</strong>, которые сделаны и имеют хороший отклик у пользователей конкурентов.</li>

8 </ul><h4>Всё, не как обычно:</h4>

9 <ul><li><strong>Фичи “под ключ”</strong>как сигнал, что функционал нужен. Каждый заказчик готов доплатить за улучшение. Если совпадений более 1 и выше, а фича тиражируемая и сводит экономику, делать надо.</li>

10 <li><strong>Интервью</strong>- глубинное интервью с получением обратной связи по текущим возможностям в продукте, получением инсайтов и проверкой инсайтов и аналитики. Всегда важно добиваться не ответа на вопрос “готовы прямо сейчас купить?”, а хотя бы “готовы прямо сейчас инвестировать рабочий день на это?”</li>

11 <li><strong>Первая продажа</strong>- в процессе первой продажи возникает пакет предложений и замечаний к продукту. Там всегда будут как те, кто конвертнутся в фичи под ключ, так и те, кому не хватило для продажи.</li>

12 <li><strong>Новые тарифы пользования</strong>- не быстрый дискаверинг, связанный с формированием и продажей нового предложения. Как правило, дискаверинг происходит на новых пользователях и проверяет продаваемость новых тарифов с валидацией гипотез о новых, улучшающих матмодель предложениях.</li>

13 </ul><h2>Как происходит валидация?</h2>

14 <ul><li>Рынок - расчеты объема рынка предполагаемой гипотезы в формате “в мире около 10 тыс крупных франшизовых сетей ресторанов азиатской кухни. Общий объем закупки продуктов в них достигает 6 млрд долларов в год, среди которых, потенциальные пользователи доработки - рестораны с кооперацией с другими кухнями (итальянской, мексиканской, и проч), для кого нужна разветвленная система приема продуктов, составляет 17 %”.</li>

15 <li>Глубинные проблемно-решенческие интервью с построением сегментации пользователей и частотностью повторения инсайтов. Если сегменты и частотность сходятся по unit-экономике, значит валидация прошла. Мегаважно, что инсайты могут повторяться не просто в сегментах, а отраслях. Правила повторов инсайтов - повторения в правилах деятельности. Например, что закупщики выбирают подрядчика прежде всего по величине скидки.</li>

16 <li>Проверка деньгами - предложить заплатить за доработки, новый тариф. Самая надежная валидация гипотезы. Важно, что заплатить за доработки и тариф должны столько раз, чтобы unit-экономика фичи сводилась в быстрый плюс.</li>

17 </ul><h2>Проверка гипотез</h2>

18 <p>Приемлемый формат теста гипотез в B2B диктуется числом обслуживаемых “2B”.</p>

19 <p>При большом числе “2B” (сотни, тысячи и более) становятся доступны практики “2C” - потенциально можно проводить эксперименты: - A/B тесты; включить функционал только части клиентов; - mock-функционала для замера заинтересованности (лендинги и подобное);</p>

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

21 <p>Разумеется, мало кто готов делать эксперименты над самыми “толстыми” ВИП-клиентами. Эксперименты делаются над так называемым long tail - множеством мелких клиентов.</p>

22 <p>Для “толстых” клиентов и при общем малом числе 2B-клиентов применяются<strong>другие практики</strong>, основанные на плотном контакте и общении:</p>

23 <ul><li>Вместо mock’а в продукте делается классическое демо с опросом “надо/не надо”. Здесь возникает классическая сложность, что собеседник может соглашаться неискренне.</li>

24 <li>Вместо A/B-теста на разных клиентах делается наблюдение за одним клиентом до/после внедрения. Здесь возникают сложности со скрытым влиянием каких-то других временных факторов. При демо и обсуждении, чтобы исключить ложное соглашательство, удобно рассматривать новую функцию как требующую отдельного коммитмента от клиента, что требует согласованной работы с командой продаж:</li>

25 </ul><p>- оплата за сделанную работу (однако, это не самый лучший результат для бизнеса); - отдельная оплата за использование именно этой функции; - согласие на повышение общей оплаты; - однако, явный комминтмент не всегда возможен, и результаты могут оказаться в “серой зоне”; - согласие сохранить прежнюю оплату; - согласие на продление контракта.</p>

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

27 <p>Можно в дальнейшем попытаться совместно с командой продаж еще раз проверить ценность этого функционала - если клиент будет просить скидку, то предложить отключить такие функции за скидку. Согласие будет означать, что функционал не ценен.</p>

28 <p>Дальнейшее тестирование уже приходится вести с какой-то реализацией гипотезы (например, MVP). Если есть возможность отслеживать поведение клиента (в B2B это не всегда приемлемо), то можно делать выводы из наблюдаемого использования добавленного функционала.</p>

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