Почему я вообще это подчёркиваю
Я вижу одну и ту же картину снова и снова: фаундер говорит “я делаю кастдев”, но по факту он собирает вежливые подтверждения, вдохновляется на неделю и… продолжает строить продукт в вакууме. Потом приходит момент “почему никто не покупает?” — и начинается поиск виноватых: рынок не готов, маркетинг слабый, “люди ничего не понимают”.
Я опираюсь на классическую рамку Customer Development Стива Бланка (книги The Four Steps to the Epiphany и The Startup Owner’s Manual). У нас её часто знают по «Стартап: настольная книга основателя». Я работаю по этой логике больше 10 лет и вижу большую разницу между тем, что написано в методологии, и тем, как “кастдев” понимают в обиходе.
Неправильный CustDev опаснее, чем отсутствие CustDev. Потому что он даёт ложную уверенность: «мы проверили», «нам подтвердили», «рынок есть». А дальше — месяцы разработки и дорогой урок.
Главная причина: CustDev — процесс, а не разговор
CustDev — это не “поговорить”. CustDev — это системная проверка гипотез: про проблему, сегмент, каналы, оплату, модель бизнеса. То есть про то, что именно вы строите и почему это вообще должно существовать.
Если говорить по-честному: CustDev — это предпринимательство как эксперимент. Есть гипотеза → есть тест → есть данные → есть решение. В конце каждого цикла вы обязаны выбрать: pivot (разворот) или persevere (продолжаем).
Самый простой тест: после серии интервью вы приняли решение, которое меняет действия? Если нет — это были не проверки, а беседы.
“Поговорить с клиентами” — это обычно про ощущения. Про мнения. Про “кажется”. Это может быть полезно для общего кругозора, но это не проверка спроса.
Таблица: CustDev vs «поговорить»
| Аспект | CustDev (Customer Development) | «Поговорить с клиентами» |
|---|---|---|
| Цель | Проверять и опровергать гипотезы. Ищете не “подтверждение”, а правду (включая неприятную). | Получить фидбек, одобрение, “поддержку”. Часто — бессознательно искать подтверждение идеи. |
| Структура | Интервью по сценарию, привязанному к гипотезам. Разные типы интервью на разных этапах (проблема / решение). | Созвоны без плана. Вопросы “как получится”. Часто — наводящие формулировки. |
| Данные | Фиксируете факты поведения, паттерны, метрики. На выходе — решение (pivot/persevere). | Субъективные впечатления: “людям понравилось”, “было интересно”, “вроде больно”. |
| Риск искажений | Снижается: вы не “продаёте” в проблемном интервью, больше слушаете, проверяете факты из прошлого. | Высокий: вы слышите то, что хотите, а люди отвечают “социально правильно”. |
| Результат | Понимание сегмента, силы проблемы, готовности платить, и следующий шаг. | Ложные положительные сигналы. После них обычно строят продукт и удивляются отсутствию продаж. |
| Когда уместно | Когда есть неопределённость и нужно принять решение, куда двигаться и что проверять. | Как “разогрев” или сбор мнений — но не как основа решений про продукт и деньги. |
Важно: CustDev — это не “таблица ради таблицы”. Это дисциплина, которая заставляет вас не мечтать, а проверять и фиксировать решения.
Два примера на одном кейсе
Допустим, вы считаете, что фрилансеры теряют много времени на поиск проектов. Это гипотеза проблемы. Сравним подходы.
Пример 1 — CustDev (нормально)
- «Расскажите про последний раз, когда вы искали проект. Где искали? Сколько времени ушло?»
- «Что было самым раздражающим и почему?»
- «Что вы делали, чтобы улучшить ситуацию? Какие варианты пробовали?»
- «Вы платили деньгами или временем за решение? Какие сервисы использовали?»
Дальше — анализ паттернов: у какого сегмента боль повторяется, где действительно есть цена бездействия, где люди уже пытались решить задачу. И только после этого — решение: менять сегмент, менять формулировку проблемы, либо переходить к проверке решения (MVP/прототип).
Пример 2 — «поговорить» (как обычно делают)
- «Тебе бы было удобно приложение для поиска проектов?»
- «Если бы было — пользовался?»
- «Сколько бы заплатил?»
Это почти гарантированно даст “да”. Из вежливости. Из желания поддержать. Но это не проверяет ни реальность боли, ни попытки решения, ни готовность платить.
Метрики и итерации: что делает разговор “данными”
Одно из ключевых отличий CustDev, которое часто упускают: здесь важны измеримые результаты. Не “мне показалось”, а цифры и признаки поведения.
Доля респондентов с подтверждённой проблемой
Сколько людей реально сталкивались с проблемой в жизни (не “в теории”), и как часто.
Попытки решить и цена бездействия
Что уже пробовали. Сколько времени/денег потеряли, если не решить.
Готовность на “следующий шаг”
Не “классно”, а конкретика: пилот, предоплата, интро ЛПР, выделение бюджета, слот в календаре.
Commitment на этапе Validation
Готовность подтвердить ценность действием: предзаказ, тест, депозит, согласование пилота.
Разговор становится CustDev, когда вы превращаете его в проверку гипотез с измеримым итогом и итерацией: “что меняем после этой серии интервью”.
Объективность и роль команды
“Поговорить” обычно делает один человек. И чаще всего — тот, кто сильнее всего влюблён в идею. Он бессознательно фильтрует ответы под свои ожидания. Это нормально по-человечески — и смертельно для проверки.
В CustDev правильнее работать как команда (даже если команда маленькая): один ведёт интервью, второй фиксирует дословные цитаты, третий потом сводит паттерны и выводы. Это резко снижает искажения и повышает шанс увидеть правду.
Идея CustDev в том, что вы ищете не “похвалу”, а места, где гипотеза не выдерживает реальности. Чем раньше вы это увидите — тем дешевле это вам обойдётся.
Реальные провалы без нормального CustDev
Ниже — несколько историй, которые хорошо показывают одну мысль: “разговоры” не заменяют Customer Development. Я даю ссылки на разборы. Суть не в том, чтобы “пинать” компании, а в том, чтобы увидеть шаблон ошибки.
Quibi (закрылся в 2020)
По разбору в источнике, команда переоценила спрос на “мобильный Netflix” и недооценила реальное поведение аудитории. Это классический кейс: идея звучит логично, но поведение и готовность платить не подтверждены дисциплиной проверки. Источник: gapscout.com
Jawbone (фитнес-трекеры)
В разборе подчёркивается, что “обратная связь” существовала, но она не была встроена как системная проверка гипотез: больше напоминало поддержку/жалобы, чем CustDev-цикл с выводами и разворотами. Источник: simpleclosure.com
Shyp (логистика)
Частая ошибка сервисов: собрали позитив про удобство, но не проверили “готовность платить” и экономику сегментов, а потом масштабировали рост как будто проверка уже пройдена. Источник: about.crunchbase.com
Dinnr (доставка ингредиентов)
Классика: продукт сделали “по ощущениям” и подтверждениям от близкого круга, без системного теста поведения и спроса. Источник: gapscout.com
Ещё одна полезная подборка: стартапы, которые “не попали в рынок” из-за отсутствия ранней валидации полезности. Источник: failory.com
Общий вывод простой: без Customer Development вы строите на песке. Проблема не в том, что вы “мало общались”. Проблема в том, что вы не проверяли гипотезы и не принимали решения.
Как проверить, что вы делаете CustDev, а не “созвоны”
Есть гипотезы до интервью
Кто сегмент, в какой ситуации болит, как решает сейчас, что будет сигналом “да/нет”.
Вопросы про прошлое поведение
Факты, попытки, цена, последствия — а не “а если бы было…”.
Вы не продаёте в проблемном интервью
80% времени слушаете. Решение появляется позже, когда проблема подтверждена.
После серии интервью есть решение
Что меняем: сегмент, формулировку проблемы, канал, оффер, шаг процесса.
Если хотите — на консультации мы собираем это “в комплект” под ваш проект: сценарий интервью, приглашение, план респондентов и критерии “делаем/не делаем”. Это экономит недели хаоса.
Куда дальше: внутренняя перелинковка
- Что такое CustDev на самом деле (и чем он не является) — базовая рамка и 4 шага.
- Как строить сценарий интервью, а не список вопросов — чтобы интервью перестали быть “болтовнёй”.
- Как писать приглашения, которые не игнорируют — если интервью “не набираются”.
- Как анализировать интервью и принимать решения — чтобы CustDev не превращался в отчёт ради отчёта.
- Где искать респондентов для B2B CustDev — если “всем некогда”.
Хотите перестать гадать и начать проверять?
Напишите в Telegram — я уточню 2–3 вопроса по контексту и предложу ближайшие слоты. На консультации мы соберём рабочий комплект: сценарий интервью, приглашение, план респондентов и следующие шаги.
Написать в Telegram