Сегодня поговорим про Customer Development, или «КасДев». Только не про красивую схему из учебника, а про главную проблему этого инструмента: предприниматель часто использует его, чтобы подтвердить собственную правоту.
Основатель созванивается с потенциальным клиентом, двадцать минут рассказывает про продукт, показывает презентацию и в конце спрашивает: «Вам нравится?»
Клиент вежливо отвечает: «Да, интересно».
Команда записывает в отчёт: гипотеза подтверждена.
Через три месяца продукт выходит на рынок, и никто не покупает.
Я видел такой сценарий много раз. И проблема здесь не в Customer Development. Проблема в том, что интервью превратили в продажу собственной идеи самому себе.
Если после десяти разговоров все вас похвалили, но никто не сделал следующий шаг, гипотеза не подтверждена. Вы просто хорошо провели десять приятных разговоров.
Что мы пытаемся узнать
Customer Development — подход, связанный с работами Стива Бланка. Его смысл не в количестве интервью и не в заполнении очередного шаблона. Вам нужно выйти из офиса и проверить бизнес-гипотезы на реальном поведении клиентов.
Это важное различие: не спросить мнение, а найти факты.
В рамках программы NSF I-Corps исследовательские команды проходят интенсивный процесс интервью с потенциальными клиентами, партнёрами и участниками рынка. Цель — понять, может ли технология стать основой устойчивой бизнес-модели. Не доказать, что разработка хорошая, а проверить коммерческую реальность.
Для обычного стартапа задача та же. Не доказать, что вы придумали хороший продукт, а как можно раньше найти причину, по которой он не взлетит.
Кого приглашать на интервью
Плохой респондент — человек, которому тема просто интересна. Друг, коллега или знакомый предприниматель может дать умный совет и при этом вообще не быть вашим клиентом.
Хороший респондент недавно сталкивался с проблемой, пытался её решить и может восстановить конкретную ситуацию.
Если вы делаете продукт для логистов, недостаточно поговорить с человеком, который «работает в логистике». Один пользователь оформляет заявки, второй управляет автопарком, третий отвечает за бюджет, четвёртый согласует закупку. У них разные задачи и разная цена ошибки.
Перед интервью зафиксируйте роль человека. Я обычно раскладываю это так:
- Кто испытывает проблему?
- Кто использует решение?
- Кто принимает решение?
- Кто платит?
- Кто способен заблокировать покупку?
В B2B это редко один человек. Если вы поговорили только с пользователем, а бюджет утверждает финансовый директор, вы узнали лишь часть истории.
Не начинайте с рассказа о продукте
Чем раньше вы покажете решение, тем сильнее исказите разговор. Клиент начнёт помогать вам улучшать интерфейс вместо того, чтобы рассказывать о своей работе. А вам пока нужен не бесплатный дизайнер, а правда о проблеме.
Начните с прошлого:
- Когда эта проблема возникла в последний раз?
- Что именно произошло?
- Как вы её решили?
- Сколько людей участвовало?
- Сколько времени занял процесс?
- Что случилось, если проблему не решить?
- За какое решение вы уже платите?
Запомните простое правило: прошлое поведение полезнее будущих обещаний. Человек может искренне сказать, что купит продукт, а потом не согласовать бюджет. Это не ложь. Между желанием и покупкой находится реальный процесс компании, который вы пока не увидели.
Вопросы, которые почти ничего не дают
«Нравится ли вам идея?» — собеседник оценивает вашу презентацию, а не собственную потребность.
«Купили бы вы такой продукт?» — слишком легко ответить «да», когда платить не нужно.
«Какие функции добавить?» — клиент проектирует решение вместо вас.
«Сколько вы готовы платить?» — без контекста закупки цифра будет случайной.
Полезнее спросить, сколько компания уже тратит на текущий процесс: зарплаты, подрядчиков, простои, ошибки, возвраты и потерянную выручку.
Как фиксировать результат
После каждого интервью я бы разделил записи на четыре группы:
- Факт: что реально произошло.
- Интерпретация: почему, по мнению клиента, это произошло.
- Гипотеза команды: что мы теперь предполагаем.
- Следующий тест: каким действием это проверить.
Например:
Факт: менеджер три часа собирает еженедельный отчёт из пяти таблиц.
Интерпретация: данные находятся в разных системах.
Гипотеза: компания заплатит за автоматическую сборку отчёта.
Следующий тест: вручную собрать отчёт для трёх команд и предложить платный пилот.
Интервью не подтверждает последнюю строку. Оно только помогает сформулировать тест.
Сколько интервью достаточно
Мне часто задают вопрос: сколько интервью достаточно? Магического числа нет. Десять разговоров могут дать сильный сигнал в узком сегменте. Пятьдесят будут бесполезны, если вы разговариваете не с теми людьми или задаёте наводящие вопросы.
Остановиться можно, когда:
- истории начинают повторяться;
- понятен текущий процесс клиента;
- известна цена проблемы;
- определены участники решения;
- вы способны предсказать возражения следующего собеседника;
- несколько клиентов согласились на действие, а не только на разговор.
После этого нужен тест решения и цены.
Customer Development продолжается после запуска
Одна из ошибок — считать интервью подготовительным этапом, который закончился после MVP.
После запуска появляются более точные вопросы. Почему клиент не дошёл до оплаты? Почему перестал пользоваться? Почему один сегмент покупает быстро, а другой требует шесть месяцев согласований? Какая функция действительно удерживает пользователя?
Хорошая продуктовая команда соединяет разговоры с поведением в продукте, продажами и экономикой. Если интервью говорит одно, а оплаты показывают другое, я всегда доверяю оплатам.
Простой сценарий первого интервью
- Попросите человека описать его роль и последний реальный случай.
- Восстановите процесс по шагам.
- Найдите самый дорогой или неприятный участок.
- Уточните последствия и текущую стоимость.
- Узнайте, кто ещё участвует в решении.
- В конце коротко опишите гипотезу и предложите следующий шаг.
Следующим шагом может быть доступ к обезличенным данным, встреча с руководителем, пилот или предоплата. Чем дороже действие для клиента, тем сильнее доказательство.
Главный результат Customer Development — не таблица с цитатами и не двадцать галочек в отчёте. Это решение: что строить, для кого, почему за это заплатят и какую гипотезу нужно убить до дорогой разработки.
КасДев не делает идею хорошей. Он помогает вам дешевле узнать, что в ней плохо. И это, на мой взгляд, намного ценнее очередного комплимента потенциального клиента.
Связанные материалы
- GTM-стратегия для стартапа
- Юнит-экономика для стартапа
- Как не потерять деньги при запуске IT-стартапа