Почему я вообще это подчёркиваю
Я вижу одну и ту же картину снова и снова, когда фаундер говорит “я делаю кастдев”, но по факту он собирает вежливые подтверждения, вдохновляется на неделю и… продолжает строить продукт в вакууме. Потом приходит момент “почему никто не покупает?” — и начинается поиск виноватых: рынок не готов, маркетинг слабый, “люди ничего не понимают”.
Я опираюсь на классическую рамку Customer Development Стива Бланка (книги The Four Steps to the Epiphany и The Startup Owner’s Manual). У нас их часто знают по названиям «Четыре шага к озарению» и «Стартап: настольная книга основателя», соответственно. Я работаю по этой логике больше 10 лет и вижу большую разницу между тем, что написано в методологии, и тем, как “кастдев” понимают в обиходе. В этом материале, который вы сейчас держите перед глазами, я структурирую объяснение для ясности, включая сравнение в таблице, и приведу реальные примеры стартапов, чтобы показать, почему это различие критично.
Неправильный CustDev опаснее, чем отсутствие CustDev. Потому что он даёт ложную уверенность в том, что «мы проверили», «нам подтвердили», «рынок есть». А дальше — месяцы разработки и дорогой урок.
Customer Development - это научный процесс, а не случайный разговор
CustDev — это не просто общение; это систематический, итеративный метод тестирования гипотез о рынке, клиентах
и прочих гипотез бизнес-модели,
чтобы минимизировать риски провала стартапа. В ходе одной итерации вы формулируете гипотезы (о проблеме, клиенте, решении, модели доходов),
выходите "из здания" (get out of the building, как говорит Стив Бланк - атор методологии CustDev),
собираете данные через структурированные интервью (интервью - это не единственный способ сбора данных,
но в рамках данного материала мы говорим именно об интеревью), анализируете их и решаете:
изменить курс (pivot) или продолжить (persevere) проводить интервью.
Customer Development это ни что иное, как научный эксперимент в предпринимательстве, цель которого — найти product-market fit (соответствие продукта и рынка)
на основе доказательств (evidence), а не предположений (assumptions).
Важно понимать, что CustDev — это вообще не про “поговорить”, как считают многие.
CustDev — это системная проверка гипотез бизнес-модели: про проблему, сегмент, каналы,
оплату, модель бизнеса и так далее.
Подробнее об этом, о том, что такое Customer Development на самом деле и о том,
чем он не явяется я рассказываю в другой
статье "Что такое CustDev на самом деле" (и чем он не является).
Процесс настоящего CustDev показан на рисунке ниже.
Самый простой «тест на настоящий Кастдев». CustDev - это когда после серии интервью вы меняете гипотезы. Если нет — это были не проверки, а беседы. CustDev - это итеративный процесс генерации и проверки гипотез. В CustDev не бывает так, что все г потезы с первого раза подтвердились. Они итеративно меняются.
А "Поговорить с клиентами" — это, напротив, неструктурированный, субъективный подход. Если воспринимать Кастдев,
как поговорить с клиентами, то это может, ничем не отличаться обычной беседы о вашем продукте на конференции,
опроса в соцсетях или фидбека от друзей,
где вы бессознательно ищете подтверждение своих идей. Нет системы, нет объективности — только мнения,
которые часто вводят в заблуждение. В результате 90% стартапов с хорошими идеями проваливаются не из-за технологий или технических навыков,
а из-за отсутствия навыков поиска реального спроса. Если вопринимать такие "разговоры" как CustDev и проверку спроса, то они
только усугубляют проблему, демотивируя основателя, и, создавая лишний шум в его голове.
"Говорить с клиентами" — это тоже нужно, обязательно нужно, но позже, когда клиенты уже есть и пользуются продуктом.
Обычно это про ощущения, про мнения. Про то, что может быть лучше, про "руку на пульсе".
"Поговорить с клиентами" - это для общего кругозора, но не для проверки спроса.
Таблица: CustDev vs «поговорить»
| Аспект | CustDev (Customer Development) | «Поговорить с клиентами» |
|---|---|---|
| Цель | Проверять и опровергать гипотезы. Ищете не “подтверждение”, а правду (включая неприятную). | Получить фидбек, одобрение, “поддержку”. Часто — бессознательно искать подтверждение идеи. |
| Структура | Интервью по сценарию, привязанному к гипотезам. Разные типы интервью на разных этапах (проблема / решение). | Созвоны без плана. Вопросы “как получится”. Часто — наводящие формулировки. |
| Данные | Фиксируете факты поведения, паттерны, метрики. На выходе — решение (pivot/persevere). | Субъективные впечатления: “людям понравилось”, “было интересно”, “вроде больно”. |
| Риск искажений | Снижается: вы не “продаёте” в проблемном интервью, больше слушаете, проверяете факты из прошлого. | Высокий: вы слышите то, что хотите, а люди отвечают “социально правильно”. |
| Результат | Понимание сегмента, силы проблемы, готовности платить, и следующий шаг. | Ложные положительные сигналы. После них обычно строят продукт и удивляются отсутствию продаж. |
| Когда уместно | Когда есть неопределённость и нужно принять решение, куда двигаться и что проверять. | Как “разогрев” или сбор мнений — но не как основа решения начать разработку продукта. |
CustDev — это дисциплина, которая заставляет вас не мечтать, а проверять и фиксировать решения.
Два примера на одном кейсе, но с разными результатами
Допустим, есть идея - создать услугу консультации по проверке идей с помощью в Custdev интервью. Сравним подходы.
Пример 1 — "покастдевить" или «поговорить с клиентами» (как не правильно и как делаете вы, скорее всего)
Как правило, в этом случае нет заранее подготовленных гипотез, которые вы проверяете. Вопросы берутся из списков из интернета по запросу "Вопросы для CustDev" либо из нашумевшей книги "Спроси маму", либо из лекций популярных "гуру кастдева":
- «Что для вас самое сложное в проведении интервью?»
- Вопросы из серии «5 почему»
- «Чего вам стоит наличие этих проблем?»
- «Как вы сейчас решаете эти проблемы»?
- «Нравится ли вам, как сейчас решаются эти проблемы на рынке?»
- «Вы хотите воспользоваться услугой консультаций для помощи в подготовке к кастдев интервью?»
- «Сколько готовы заплатить за это?» и т.д.
На базе этих вопросов проводятся все интервью. В этих интервью люди говорят о своих проблемах. Казалось бы - и проблемы у них есть, и решение им нужно. Что может пойти не так?
- Во-первых, в ответах на вопрос из серии "что у вас болит" - будет очень много разной информации, и она меняется от респондента к респонденту. Один скажет, что его проблема в сложности поиска респондентов, другой - в сложности знакомиться с незнакомыми людьми, третий - ещё в чём-то. И, соответственно, ещё более разнообразными будут и ответы на вопросы из серии «5 почему». И, вроде бы, и вопросы как в книге "Спроси маму", и все говорят правду, но эта правда - такая разная и её так много.
- Во-вторых, люди хотят разное: кто-то сервис для поиска респондентов, кто-то AI-агента для проведения интервью и т.д.
- В третьих, когда вы что-то предлагаете купить в будущем, то люди могут только готоворть, что купят, а купят ли - далеко не факт.
- В четвёртых, на вопросы из серии "использовали бы решение" часто можно услышать “да”. Но это - наводящие вопросы, они не проверяют ни реальность боли, ни попытки решения, ни готовность платить.
В результате после серии интервью вы понимаете, что "вроде проблемы есть" и даже есть фразы, которыми респонденты говорят о проблемах.
И на базе этого создаётся продукт. Но такой продукт будет переполнен фичами, и у него будеи сложный запутанный нтерфейс.
Маркетинг будет дорогим, поскольку будет опираться на недопроверенные гипотезы. Юнит-экономика не сходится, даже при наличии
высокого потенциала идеи.
И что самое интересное, в основном, вопросы сами по себе - правильные, но они используются не правильно, без структуры.
Это как рецепт торта, когда ингредиенты хорошие и дорогие, но если смешать наугад, выйдет каша.
Это классический кейс провала, 90% стартапов проваливаются именно так - "поговорили" с 20 людьми, услышали "круто",
построили app, а потом никто не платит.
Пример 2 — проблемное и решенческое CustDev интервью (как правильно)
Для проведения правильных CustDev интервью используется интервью двух видов, соответствующих первым двум шагам "процесса Customer Development" (рисунок выше). А именно на шаге "Выявление потребителей" применяются проблемные интервью, а на шаге Верификация потребителей - решенческие интервью. На каждом из этих шагов применя цикл тестирования гипотез (рисунок ниже), где каждый из четырёх этапов - это отдельное мероприятие.
Проблемные интервью
Этап 1 - гипотезы
Для начала нужно сузить ареал поиска до одного целевого сегмента (который на ваш взгляд самый удобный для пилотного). Пусть в нашем примере это будет гипотезы о неком вайб-кодере. Далее генерируем гипотезы проблем, которые планируется проверить в ходе интервью. А так же гипотезы о том, на какой ступени пирамиды осознания проблемы находится потребитель (вспоминаем рисунок "Пирамида осознания проблемы" из предыдущей статьи). Гипотезы формируем в формате утверждения, чтобы в результате интервью по каждой гипотезе можно было слелать вывод: истина это или ложь. Примеры гипотез:
- Гипотеза целевого сегмента - «вайб кодеры»
- Гипотеза проблемы №1 - «они часто быстро, за 1-2 дня теряют мотивацию к начатому проекту и переключаются на другую идею»
- Причина проблемы - «мотивация к начатым проектам теряется потому, что пропадает вера в то, что "продукт будут покупать"»
- Гипотеза о силе боли - "они осознают проблему и ищут решение"
- Гипотеза о потребительском опыте - "они уже платили за какое-либо решение этой проблемы"
- Гипотеза об опыте самостоятельного решения - "они пытались решить проблему с помощью AI (ChatGPT, например), но это не решило проблему"
Далее на этом же этапе составляем вопросы через призму цели - проверить эти гипотезы на предмет истинности или ложности.
- «Скажите, сколько у вас проектов в папке, в которой хранятся проекты?»
- «Раскажите о ТОП3 своих недоделанных проектах, которые длились меньше всего?»
- «Почему вы их бросили?»
- «Что вам мешает доделывать проекты и не переключаться на другие идеи?»
- Прямые закрытые вопросы о проблеме: «Бывает так, что вы начинаете проект, но не доделываете и на другой день переключаетесь на другую идею?»
- Иногда я пользуюсь следующим приёмом чтобы скорее "нащупать" гипотезы: «Давайте я буду перечислять возможные проблемы, а вашей задачей будет оценить от 1 до 5, насколько каждая проблема имееи место быть и почему».
Вопросы отличаются, не правда ли? Отличаются тем, что в них есть узкий ситуативный контекст, который направляет разшговор в сторону проблемы, которую мы проверяем". При этом, они - не наводящие. Вопреки расхожему мнению, главная цель проблемных CustDev интервью - проверить гипотезы о конкретных, изначально сформулированных проблемах. А понимать спектр проблем - это второстепенная цель, знание разнообразия проблем может пригодиться для поиска другой, более сильной гипотезы о проблеме, если текущая гипотеза не сработает или не устроит.
Этап 2 - Тест
Далее делаем прямое обращение (outreach) в тех местах, в которых вероятнее всего могут находиться представители,
выбранного нами, целевого сегмента (отмечу, outreach - это не единственный способ поиска респондентов, просто подходит к выбранному кейсу).
В приглашении указываем проблему, которую планируем решить - она то и должна стать крючком,
который побуждает респондентов уделить своё время. Это приглашение само по себе является экспериментом.
Если откликов на приглашение нет - меняем формуллировку проблемы. Если есть отклики - поздравляем, проблема
цепляет целевой сегмент и на интервью будет, о чём поговорить (об этой проблеме).
На интервью говорим подробно об этой проблеме с целью получить подтверждение или опровержение гипотез.
Часто в ходе интервью возникают инсайты, например, о других проблемах - фиксируем их, чтобы рассмотреть в качестве
гипотез для проверки в следующих итерациях.
Этап 3 - Анализ
Анализ делается как после каждого интервью, так и после серии интервью.
После каждого интервью отмечаем напротив каждой гипотезы "Подтверждилась" или "Опроверглась"
После серии интервью - делаем качественный внализ, выделяя и сводя формуллировки в паттерны, и
количественный анализ, измеряя процентное соотношение подтверждений и опровержений гипотез.
В итоге накаптиваем статистику и отвечаем на вопросы: "У какого сегмента боль повторяется?",
"Где действительно есть цена бездействия?", "Платили ли они уже за попытки решить проблему?" "Пытались ли сами решить проблему?"
Этап 4 - Принятие решения
И только после всего этого — решение: менять сегмент, менять формулировку проблемы, либо переходить к проверке решения (MVP/прототип).
Решенческие интервью
После успешных проблемных интервью (когда гипотезы о проблеме подтверждены) мы переходим к решенческим интервью.
Здесь мы показываем минимально жизнеспособный продукт (MVP) — это может быть простой прототип,
landing page или даже описание на бумаге, — и задаём вопросы вроде: "Готовы ли вы заплатить предоплату прямо сейчас?".
Если в проблемных интервью мы слушаем и не продаём, то в решенческих — тестируем на реальные действия,
чтобы избежать ложных надежд. Это помогает перейти от "проблема есть" к "клиенты купят".
Для проведения решенческих интервью также применяется "Цикл тестирования гипотез", где каждый из четырёх этапов -
это отдельное мероприятие. Только здесь мы приходим к клиентам и показываем им MVP и задаём вопросы с целью понять,
готовы ли они действовать.
- На первом этапе "Гипотезы" - делаем MVP
- На втором этапе "Тестирование" - показываем MVP и изучаем реакцию
- На третьем этапе "Анализ" - оцениваем готовность клиентов платить на основе текущего MVP (соотношение готовы/не готовы)
- На четвёртом этапе "Приняие решения" - принимаем решение: переделываем MVP или переходим к следующему шагу, или возвращаемся к первому шагу "Выявление потребителей", к проблемным интервью.
Метрики и итерации: что делает разговор “данными”
Одно из ключевых отличий CustDev, которое часто упускают, состоит в том, что здесь важны измеримые результаты. Не “мне показалось”, а цифры и признаки поведения.
Доля респондентов с подтверждённой проблемой
Какой % респондентов реально сталкивались с проблемой в жизни (не “в теории”), и как часто.
Попытки решить и цена бездействия
Что уже пробовали. Сколько времени/денег потеряли и сейчас теряют.
Готовность на “следующий шаг”
Не “классно”, а конкретика: пилот, предоплата, интро ЛПР, выделение бюджета, слот в календаре.
Обязательства в решенческих инервью
Готовность подтвердить ценность действием: предзаказ, тест, депозит, согласование пилота.
Разговор становится CustDev, когда вы превращаете его в проверку гипотез с измеримым итогом и итерацией с ответом на вопров “что меняем после этой серии интервью”. Изменяемость - это прзнак правилного CustDev. Если не было итератвных изменений - это был не CustDev.
Объективность и роль команды
Ещё один ключевой момент для правильного CustDev состоит в том, что анализ лучше проводить в команде, а не в одиночку.
Если интервью ведёт один человек (особенно энтузиаст идеи), он может безсознательно фильтровать ответы под свои ожидания —
это распространённое когнитивное искажение, доказанное научным сообществом, которое носит название "Влюблённость в идею".
Идеально, если один проводит интервью, другой записывает сигналы и анализирует данные и сообща они принимают решения.
В команде проще увидеть паттерны объективно. Это снижает риски и делает выводы надёжнее.
В практике Стива Бланка в Стэндфордском университете с тысячами стартапов именно командный анализ спасал от строительства "воздушных замков".
О том, как предпринимателю вовлечь в процесс CustDev команду или продакт-менеджеру вовлечь руководство
(если стартап внутри крупной компании), я готовлю очередную статью (скоро).
Если после анализа ничего не меняется в вашей бизнес-модели — это сигнал, что CustDev был неполным.
Помните, что цель интервью, как проблемных, так и решенческих — не собрать мнения, а принять обоснованное решение:
pivot (изменить курс) или persevere (продолжить).
Не упускайте это из виду. Я часто вижу тревожную картину, когда “Поговорить” обычно делает один человек.
И чаще всего — тот, кто сильнее всего влюблён в идею.
Он бессознательно фильтрует ответы под свои ожидания. Это нормально, это по-человечески — и смертельно для проверки.
А разрыв и непонимание между ним и участниками команды/инвесторами/партнёрами - усиливаются.
Идея CustDev в том, что вы ищете не “похвалу”, а то, почему большинство гипотез не выдерживает реальности. Чем раньше вы это поймёте и освоите поиск самых сильных гипотез экспериментальным путём — тем дешевле вам обойдётся обучение и успех.
Реальные провалы без нормального CustDev
Ниже — несколько историй, которые хорошо показывают одну мысль: “разговоры” не заменяют Customer Development. Я даю ссылки на разборы. Суть их в том, чтобы увидеть шаблон ошибки, когда настоящий CustDev подменяется "поговорить с клиентами".
Quibi (привлекли $1.75 миллиарда и закрылись в 2020)
Это стриминговый сервис для коротких видео, основанный голливудскими магнатами. Они "поговорили" с потенциальными пользователями, но не провели CustDev интервью — не проверили, нужна ли людям "мобильная Netflix" в эпоху TikTok. Как результат - недостаток понимания рынка и переоценка спроса. Основатели позже публично признали: "Мы не слушали людей, а полагались на личные амбиции". Это был громкий показательный кейс. Если бы они сделали 50+ структурированных интервью с метриками (e.g., "Сколько времени вы тратите на видео в день? Готовы ли платить $5/мес?"), то pivot был бы раньше и не потерялись бы миллиарды. Источник: gapscout.com
Shyp (привлекли $62 миллиона, закрылись в 2018)
Это сервис доставки. Основатели "поговорили" с клиентами об удобстве, но без структуры: не тестировали сегменты, проблемы, готовность платить и т.д.. Переоценили market fit, тратя огромные бюджеты на маркетинг без ваидации. CEO позже сказал: "Мы не корректировали стратигию своевременно". Настоящий CustDev требует минимум 10–20 интервью на сегмент с данными, а не "клиенты сказали 'да'. "Частая ошибка сервисов в том, что они собрают позитив про удобство, но не проверяют “готовность платить” и экономику сегментов, но потом масштабировали рост так, будто проверка уже пройдена. Источник: about.crunchbase.com
Dinnr (доставка ингредиентов)
Сервис доставки ингредиентов для рецептов. Основатели строили продукт не проверив, что клиенты предпочитают, супермаркеты или готовую еду. Они "поговорили" с друзьями, но без скрипта и метрик. Вместо этого стоило начать с гипотез проблем и вопросов: "Как вы готовите ужин? Сколько времени тратите на покупки?" — это показало бы им отсутствие потребности. Это классика - продукт сделали “по ощущениям” и подтверждениям от близкого круга, без системной проверки спроса. Источник: gapscout.com
Ещё хочу поделиться одной полезной подборкой стартапов, которые “не попали в рынок” из-за отсутствия ранней валидации полезности. failory.com
Общий вывод простой: без Customer Development вы строите "замок на песке". Проблема не в том, что вы мало общались, общаться вы можете много, даже слишком. Проблема в том, что вы не проверяли гипотезы и не принимали решения.
Как проверить, что вы делаете CustDev, а не “общаетесь”
Есть гипотезы до интервью
Кто сегмент, в какой ситуации болит, как решает сейчас, что будет сигналом “да/нет”.
Вопросы про прошлое поведение
Факты, попытки, цена, последствия — а не “а если бы было…”.
Вы не продаёте в проблемном интервью
80% времени слушаете. Решение появляется позже, когда проблема подтверждена.
После серии интервью есть решение
Что меняем: сегмент, формулировку проблемы, канал, оффер, шаг процесса.
Если хотите — на консультации мы собираем это “в комплект” под ваш проект: сценарий интервью, приглашение, план поиска респондентов и критерии “делаем/не делаем”. Это экономит недели хаоса.
Другие статьи, которые могут быть полезными
- Что такое CustDev на самом деле (и чем он не является) — базовая рамка и 4 шага.
- Как строить сценарий интервью, а не список вопросов — чтобы интервью перестали быть “болтовнёй”.
- Как писать приглашения, которые не игнорируют — если интервью “не набираются”.
- Как анализировать интервью и принимать решения — чтобы CustDev не превращался в отчёт ради отчёта.
- Где искать респондентов для B2B CustDev — если “всем некогда”.
