Как CustDev превращается в самообман
Customer Development — это дисциплина не про то, чтобы «придумать продукт», а про то, чтобы понять реальную задачу человека, его контекст, барьеры, альтернативы и критерии успеха, а затем проверить, что выбранное решение действительно нужно и за него готовы платить или им пользоваться. Ошибки в этой работе почти всегда дают один и тот же результат: команда собирает псевдоинсайты, укрепляет собственные иллюзии и разгоняется — в неправильном направлении. Разберём, где именно исследование разваливается, по тому же порядку, в каком оно обычно и рушится: от постановки задачи до повторного цикла.
До первого интервью: задача поставлена неверно
Самый частый провал случается ещё до звонков, когда CustDev превращается в поиск подтверждений. Команда уже решила, что делать, и идёт «собрать доказательства»: в разговоре звучит «вам бы понравилась наша функция X?», интервьюер спорит, оправдывает решение и, по сути, продаёт, а после десяти интервью уверенность выросла, но фактов о реальных привычках и альтернативах почти нет. Это чистый confirmation bias: мозг ищет согласие, а не правду. Лечится это сменой цели: не «проверить решение», а «разобрать проблему, контекст и триггер». Заранее выпишите, что должно вас разубедить (какие ответы будут означать, что идея слабая (falsification criteria)), и держите интервью про проблему отдельно от интервью про реакцию на решение.
С этим связана и вторая ошибка — не разделять discovery и validation. Когда в одном разговоре пытаются вытащить боль, протестировать прототип и обсудить цену, человек путается, отвечает вежливо, а интервью расползается. Discovery — это про прошлое поведение, события, обходные пути, последствия, эмоции и альтернативы. Validation — про конкретный оффер и проверку готовности действовать (временем, деньгами, данными, интеграциями) и про барьеры внедрения. Это два разных разговора.
Третья ловушка — путать пользователя, покупателя и того, кто влияет на решение. Часто говорят с тем, кто кликает, а платит другой; или платит один, внедряет второй, а страдает третий. Симптом узнаваемый: «всем нравится», но сделки не идут, а внедрение буксует. Помогает карта ролей — User, Buyer, Champion, Approver, Blocker — со своими вопросами и критериями успеха под каждую. И четвёртая — отсутствие внятной гипотезы сегмента. «Поговорим со всеми, вдруг найдём» оборачивается тем, что после двадцати интервью нет ни одного повторяющегося паттерна. До старта стоит выбрать один-два сегмента по понятным признакам — контекст, частота проблемы, стоимость ошибки, бюджет, доступность — и фиксировать в табличке сегментации, где паттерн проявляется сильнее.
Карта ролей в сделке: кто есть кто
- User — тот, кто реально работает в продукте каждый день. Боль у него конкретная, но бюджета обычно нет. Вопрос к нему: что в текущем процессе отнимает больше всего времени.
- Buyer — у кого бюджет и право сказать «да» деньгам. Его волнует не удобство экрана, а возврат вложенного и риск. Вопрос: по каким цифрам вы поймёте, что покупка себя оправдала.
- Champion — внутренний сторонник, который проталкивает внедрение и продаёт его коллегам за вас. Без него сделка в крупной компании глохнет. Вопрос: что вам даст, если это заработает, и кого ещё нужно убедить.
- Approver — тот, кто согласует решение по бюджету, безопасности или юридической части, часто не пользуясь продуктом сам. Вопрос: какие требования должны быть закрыты, чтобы вы дали добро.
- Blocker — тот, кому изменение невыгодно или рискованно: перегруженный ИТ-отдел, смежник, теряющий контроль. Вопрос: что для вас меняется в худшую сторону.
Симптом «всем нравится, но сделки нет» почти всегда значит, что говорили с User, а Buyer, Approver и Blocker остались за кадром.
Рекрутинг: не те люди и не те стимулы
Интервью с друзьями, знакомыми и лояльными — это много поддержки и мало критики при минимуме деталей. Рекрутировать нужно через нейтральные каналы: сообщества, outbound, формы на сайте, списки клиентов, партнёров, а знакомых, если уж без них никак, держать отдельной группой и не смешивать с основными данными. Так же вредит и обратное — брать слишком широких людей без скрининга: объявляете, что ищете «предпринимателей, маркетологов, студентов», и половина разговоров оказывается не про вашу задачу, а ответы выходят теоретическими. Короткий скрининг из трёх-шести вопросов до созвона отсекает лишних: была ли проблема за последние 30–60 дней, как её решали в последний раз, сколько времени и денег ушло, кто ещё был вовлечён.
Отдельно скажем про деньги. Платить участникам можно, но не так, чтобы человек «отрабатывал ожидания» и говорил что угодно. Компенсация небольшая и одинаковая для всех; в приглашении не раскрывайте саму идею продукта, говорите о теме и опыте; вопросы стройте вокруг фактов, а не мнений. И не собирайте одних «идеальных» респондентов, пропуская крайние случаи, иначе продукт потом ломается о реальность интеграций, доступов и регламентов. Зовите тех, кто недавно ушёл к альтернативе, кто пытался и бросил, кто решает иначе: самописка, Excel, агентство или вообще ничего.
Сценарий: вопросы, дающие иллюзию знания
Главная ошибка сценария — спрашивать про будущее поведение. «Купили бы? Пользовались бы каждый день?» — люди не предсказывают себя точно, тем более в абстракции. Спрашивайте про прошлое: расскажите про последний раз, когда это случилось; что стало триггером; какие шаги сделали; сколько это заняло; что было самым неприятным. Туда же относятся наводящие вопросы вроде «вам же неудобно делать отчёты вручную?»; заменяйте их нейтральными («как вы делаете отчёты сейчас?») и подключайте шкалы только после того, как человек описал процесс: «насколько это больно по 10-балльной? почему?».
Ещё одна беда — перекос в сторону мнений, когда интервью скатывается в обсуждение вкусов «нравится/не нравится». Держите пропорцию: около 70% времени — факты (действия, инструменты, частота, потери, ограничения), 20% — причины (мотивация, риски, критерии выбора) и лишь 10% — реакция на концепт или оффер, если вы уже на стадии validation. И обязательно закладывайте блок про альтернативы и «конкурента по умолчанию»: люди сравнивают вас не с идеальным продуктом, а с тем, что делают сейчас, Excel, Notion, подрядчик, самописка, «потерпим». Спросите, чем пробовали решать, почему выбрали именно это, что не устраивает и что удерживает от смены.
Проведение: разговор превращается в питч
Если запись интервью — это монолог команды, а не человека, данных вы не получили. Правило простое: 70/30 в пользу респондента, вопросы короткие, паузы — это нормально. Рано показанный прототип или презентация тоже портят разговор: человек начинает реагировать на красивое, а не рассказывать реальность, поэтому первые 20–30 минут — только контекст и факты, и лишь потом, если нужно, короткий концепт. Спорить с респондентом или объяснять ему, «как правильно», нельзя: он закрывается и переходит на социально одобряемые ответы; любое непонимание оформляйте как уточнение: «правильно ли я понял, что…», «а что вы сделали дальше?», «что было самым сложным на этом шаге?».
Сильные инсайты часто прячутся в эмоциях (стыд, страх, раздражение, злость, тревога), поэтому спрашивайте, что больше всего бесит в этом процессе, что будет, если сделать ошибку, кто об этом узнает и какими будут последствия. Фиксируйте точные формулировки: если команда потом пересказывает своими словами, смысл теряется, особенно в описаниях боли и критериев выбора, поэтому запись с согласия плюс заметки, а цитаты выписывайте отдельно. И не ведите интервью в одиночку: минимальный сетап — интервьюер, ноттейкер и общий шаблон заметок (контекст → триггер → шаги → альтернативы → потери → критерии → цитаты), где один ведёт разговор, а второй ловит нюансы.
Синтез: данные собрали, смысл упустили
Свести интервью к «кажется, всем важно…» и «люди часто говорят…» без частот и сегментов — значит выбросить работу. Нужны кодирование и группировка: теги на фразы (боль, триггер, обходной путь, риск, критерий выбора, барьер) и частота по сегментам — у кого что повторяется чаще. Причём синтез всегда идёт в разрезе сегмента, потому что паттерны бывают противоположными: у стартапа и корпорации разные ограничения, и честнее звучит «в сегменте A чаще X, в сегменте B критично Y, в сегменте C проблема редкая, но дорогая», чем усреднённое «в целом по больнице».
Две частые подмены на этом этапе. Первая — взять самую яркую историю вместо самого частого сценария: один эмоциональный рассказ легко перебивает двенадцать спокойных сигналов, поэтому яркие кейсы помечайте как edge case, пока не подтвердите повторяемость. Вторая — не строить причинно-следственные цепочки. Оформляйте инсайт как связку: контекст → триггер → действие → барьер → последствия → почему текущая альтернатива удерживает. Именно из неё и появляются реальные рычаги продукта и маркетинга: что менять, чтобы поведение стало другим.
Решения: «мы всё поняли» не становится планом
Без формальных критериев «данных достаточно» интервью идут бесконечно и ни к чему не приводят. Stop-условия задают заранее: паттерн повторился N раз в целевом сегменте, нашлись 3–5 одинаковых барьеров, есть 2–3 сильные альтернативы с понятной причиной выбора. Дальше не стоит менять продукт, полагаясь на слова: люди соглашаются, но шагов не делают. Готовность проверяют делом: попросить доступ к данным или интеграции, поставить в очередь на пилот с конкретной датой, предложить pre-order, LOI или депозит там, где это уместно, подписку в waitlist с выбором плана или цены.
Особенно в B2B нельзя игнорировать барьеры внедрения: интерес есть, а внедрение не стартует. Под это нужен отдельный блок вопросов: кто принимает решение, какие требования по безопасности и юридической части, как устроена закупка, сколько внедрение занимает сейчас и почему, что убивает проект на согласованиях. И последнее на этом этапе — когда инсайтов много, а приоритета ни одного. Переводите инсайты в гипотезы и ранжируйте по влиянию на ключевую метрику, по уверенности (сколько повторений и насколько сильны доказательства) и по стоимости изменения.
Интерпретация: слова против реальных мотивов
Вежливость — не спрос. «Классно», «интересно», «прикольно» — это социальная реакция, а не подтверждение ценности; ищите сигналы реальной цены: что человек уберёт или заменит, чтобы этим пользоваться, какой бюджет и время уже тратит, что должно случиться, чтобы он переключился. Отделяйте «проблема есть» от «проблема важная»: проблема может быть, но люди её просто терпят; напряжение измеряют частотой ситуации, стоимостью ошибки, последствиями для KPI, денег и репутации, вопросом «сколько времени уходит в месяц?». И слушайте не только «что хотят», но и «как выбирают»: человек говорит «хочу быстро», а выбирает по доверию, риску, простоте внедрения и привычке, поэтому спрашивайте, почему выбрали этот инструмент, что было решающим фактором и что остановило от другого варианта.
Процесс: CustDev как разовая акция
Если CustDev — это двухнедельный проект, о котором потом забыли, продукт неизбежно уезжает от меняющегося рынка. Встраивайте его в рутину: 2–4 интервью в неделю (или раз в две недели), еженедельный синк «инсайты → гипотезы → решения», библиотека интервью с тегированием и доступом для всей команды. Когда интервью делает один человек, остальные получают пересказ и верят меньше, поэтому нужна ротация: PM или PO, дизайнер и инженер по очереди слушают одно-два интервью в неделю, а затем полчаса общего разбора — что услышали, что удивило, что проверяем дальше. И не забывайте про этику: короткий протокол с согласием на запись, названной целью разговора, обещанием не публиковать персональные данные и возможностью остановиться в любой момент.
Форматы: инструмент применили не туда
Интервью прекрасно раскрывают мотивацию и контекст, но плохо отвечают на вопрос «сколько таких людей», поэтому доказывать рынок одними интервью, без количественной части, нельзя. Сочетайте: качественно — паттерны и причины, количественно — опрос, анализ воронки, данные использования, трафик, спрос, конверсия. При этом на ранней стадии опрос не заменяет интервью: опрос — это ответы на ваши заранее заданные варианты, а интервью — реальность человека, так что сначала интервью, затем опрос для масштаба. И solution-интервью не проводят без реального концепта: на слишком сыром человек начнёт додумывать и соглашаться. Даже для ранней проверки лучше иметь один экран или одну страницу оффера, два-три конкретных сценария использования и чёткое «что вы делаете вместо этого сейчас».
Что особенно часто губит стартапы
Целиться во всех из страха потерять рынок — верный способ не собрать ни одного паттерна; выберите узкий сегмент, где боль острая, а путь к покупке короткий: расширяться потом проще, чем лепить фокус из хаоса. Не берите слова пользователей как ТЗ на фичи: человек эксперт в своей проблеме, но не обязан быть экспертом в дизайне решения, поэтому фиксируйте «что болит» и «почему», а не «как именно сделать». И не путайте «интересно» с «готов выделить ресурс»: сильный сигнал — это когда человек готов дать доступ и данные, назначить внедрение, подписать пилот, выделить бюджет или время команды.
Как переформулировать вопросы
Почти все слабые вопросы лечатся сдвигом от гипотетики к фактам. Вместо «вам нравится идея X?» спрашивайте «когда в последний раз вы столкнулись с ситуацией Y? что сделали?». Вместо «сколько бы вы заплатили?» спрашивайте «сколько стоит вам текущий способ в деньгах, времени и рисках? что было бы справедливым обменом?». Вместо «если бы была функция Z, вы бы пользовались?» спрашивайте «какой шаг в процессе самый неприятный? что вы уже пробовали, чтобы его убрать?». Вместо «какие функции вам нужны?» спрашивайте «каким должен быть результат, чтобы вы сказали: это сработало?».
Рабочий шаблон, чтобы не наступать на грабли
Подготовка занимает час-два: гипотеза сегмента (кто именно), сценарий ситуации (когда возникает боль), критерии, опровергающие идею, и скрининг-анкета. Само интервью — 45–60 минут по понятной структуре: контекст человека и роль, детальный разбор «последнего раза», альтернативы и сравнение, потери, риски и эмоции, критерии выбора и, опционально, реакция на концепт с тестом готовности. Синтез делают сразу после разговора, за 20–30 минут: 5–10 тегов на ключевые фразы, три дословные цитаты и одна гипотеза на проверку дальше. А раз в неделю проходит сессия решений на 30–60 минут: паттерны по сегментам, 3–5 гипотез на следующую неделю и явное решение, что строим, что проверяем и что прекращаем делать.
Перед тем как считать исследование качественным, прогоните его по короткому списку:
- Мы говорим с людьми, у которых проблема была недавно?
- Мы спрашиваем про прошлые действия, а не про предположения?
- Мы понимаем альтернативы и почему они выбраны?
- Мы различаем user, buyer, champion, approver?
- У нас есть признаки, которые могут нас разубедить?
- Мы синтезируем в разрезе сегментов, а не «в целом по больнице»?
- Мы переводим инсайты в проверяемые гипотезы и следующий шаг?
- Мы проверяем готовность выделить ресурс, а не собираем комплименты?
Если на один из пунктов ответ «нет», оцените, какое решение может исказить этот пробел, и начните с проверки самого рискованного предположения.