Кастдев (custdev): что это и как проводить интервью

Коротко

Кастдев (custdev, customer development) — способ проверять гипотезы о клиенте и его проблеме через разговоры с настоящими пользователями до того, как потрачены месяцы разработки.

• Подход описал Стив Бланк: это четыре шага развития клиентов, а не только интервью. В русскоязычной практике «кастдевом» чаще называют именно серию интервью.
• Проблемное интервью выясняет, есть ли проблема и как её решают сейчас. Решенческое проверяет, подходит ли ваше решение.
• Спрашивают о прошлом поведении: что человек делал в последний раз, а не что он сделал бы.
• Респондентов выбирают по данным: сегмент, в котором проседает метрика, и случайная выборка из него.
• Число интервью не задают заранее: разговоры идут, пока в сегменте появляются новые ответы.
• Вывод интервью — гипотеза. Её проверяют числом и экспериментом.

Что такое кастдев простыми словами

Customer development дословно — «развитие клиентов». Подход описал предприниматель Стив Бланк в книге «The Four Steps to the Epiphany». Его исходная мысль: стартапы чаще гибнут не оттого, что не смогли сделать продукт, а оттого, что сделали продукт, который никому не нужен. Поэтому рядом с разработкой продукта должен идти второй процесс — поиск и проверка клиентов.

У Бланка четыре шага. Выявление клиентов (customer discovery): предположения основателей о проблеме, клиенте и решении превращаются в гипотезы, и их проверяют в разговорах. Проверка клиентов (customer validation): выясняют, можно ли продавать повторяемо. Если нет, команда возвращается к первому шагу. Затем привлечение клиентов (customer creation) — создание спроса, и построение компании (company building) — переход от поиска к исполнению.

Главный принцип Бланк сформулировал коротко: «There are no facts inside your building, so get outside» — фактов внутри офиса нет, за ними надо выходить к людям. В русскоязычной среде слово «кастдев» сузилось до первого шага и до его основного инструмента: «провести кастдев» значит провести серию интервью с пользователями. В этой статье речь о таком, узком значении.

Кастдев не опрос и не продажа. Опрос считает доли ответов на заранее заданные вопросы, а интервью ищет то, о чём вы не догадались спросить. Продажа убеждает, а на интервью вы молчите и слушаете.

Чем проблемное интервью отличается от решенческого

Деление пришло из книги Эша Маурьи «Running Lean», где problem interview и solution interview разнесены по разным этапам. Сначала вы убеждаетесь, что проблема существует и человек уже что-то делает, чтобы её решить. Только потом показываете своё решение.

Частая ошибка — смешать оба в одном разговоре: десять минут расспросить о проблеме, а потом открыть макет и спросить «как вам?». После макета собеседник перестаёт рассказывать о своей жизни и начинает оценивать вашу работу, причём вежливо. Что именно искать на проблемном интервью — какую «работу» человек пытается выполнить и чем пользуется сейчас, — разобрано в статье о Jobs To Be Done.

Какие вопросы задавать на кастдев-интервью

Лучше всего правила вопросов описал Роб Фитцпатрик в книге «The Mom Test». Название — от мысленной проверки: даже мама, которая вас любит и хочет поддержать, не сможет соврать, если вопрос задан правильно. Правил три: говорить о жизни собеседника, а не о своей идее; спрашивать о конкретных случаях в прошлом, а не о мнениях и будущем; меньше говорить и больше слушать.

Причина проста. Ответ на вопрос «вы бы пользовались?» ничего не стоит человеку: согласиться приятнее, чем огорчить. Рассказ о прошлом проверяем: человек либо искал решение, либо нет, либо платил, либо обходился таблицей.

Вторая ловушка — наводящие вопросы. «Вам ведь было неудобно импортировать данные?» содержит ответ, и собеседник его вернёт. Нейтральная форма: «Расскажите, что происходило после того, как вы создали рабочее пространство». Если человек сам не вспомнил про импорт, это тоже результат.

Сценарий интервью — это не анкета, а список тем: 5–7 открытых вопросов и уточнения «почему», «что было дальше», «как вы решили это в тот раз». Запись по минутам чаще всего показывает, что интервьюер говорил слишком много.

Как выбрать респондентов для кастдева по данным

Вопрос «кого звать» решается до вопроса «что спрашивать». Интервью с десятью случайными пользователями дадут десять разных историй, и ни одна не объяснит провал на конкретном шаге. Нужен сегмент: люди, которые дошли до одного и того же места и повели себя одинаково. Такие сегменты видны в воронке и на карте пути клиента, а как резать базу на группы, разобрано в статье о сегментации пользователей.

Посчитаем на учебной базе «Маяк» — это сервис с рабочими пространствами и отчётами: 4613 регистраций с 1 июня по 29 августа 2026 года, события, платежи и подписки. Первый сегмент — те, кто создал рабочее пространство (workspace_created), но не создал отчёт (report_created). Создание отчёта здесь — первая ценность продукта, и человек остановился в шаге от неё.

Всего таких 975 из 2750 создавших пространство — 35,5%. Запрос сразу показывает две разные картины. Доля застрявших почти одинакова во всех каналах, от 34,0% до 37,3%. Значит, препятствие сидит в самом продукте, и звать на проблемное интервью нужно людей из всех каналов. А вот до рабочего пространства каналы доходят очень по-разному: 74,7% регистраций из referral и только 37,0% из paid_search. Это уже другой вопрос — чего ждали люди, пришедшие по рекламе, — и другая серия интервью.

Из сегмента берут случайную выборку, а не первых откликнувшихся: составьте список user_id, перемешайте, приглашайте по порядку. И записывайте, сколько человек отказалось. На разговор охотнее соглашаются вовлечённые, поэтому выборка всё равно смещена — об этом подробнее в статье о репрезентативности выборки.

WITH flags AS (
  SELECT
    u.user_id,
    u.channel,
    MAX(CASE WHEN e.event_name = 'workspace_created' THEN 1 ELSE 0 END) AS has_workspace,
    MAX(CASE WHEN e.event_name = 'report_created' THEN 1 ELSE 0 END) AS has_report
  FROM users AS u
  LEFT JOIN events AS e ON e.user_id = u.user_id
  GROUP BY u.user_id, u.channel
)
SELECT
  channel,
  COUNT(*) AS signups,
  SUM(has_workspace) AS with_workspace,
  ROUND(CAST(100.0 * SUM(has_workspace) / COUNT(*) AS numeric(18, 6)), 1) AS workspace_pct,
  SUM(has_workspace) - SUM(has_report) AS no_report,
  ROUND(CAST(100.0 * (SUM(has_workspace) - SUM(has_report)) / SUM(has_workspace) AS numeric(18, 6)), 1) AS no_report_pct
FROM flags
GROUP BY channel
ORDER BY no_report DESC;

Кого звать: заплатили один раз и ушли

Второй сегмент дороже первого: эти люди уже отдали деньги. В таблице payments у платежа есть тип — first или renewal, в subscriptions — статус подписки: active, churned или past_due. Сегмент для интервью — одна оплата и статус churned: человек попробовал платную версию и отказался сам.

Статус past_due — другая история. Это просроченный платёж: возможно, не прошла карта. Таких с одной оплатой 189, и звать их на интервью о ценности продукта рано — сначала проверяют биллинг и письма о неудачном списании. Данные здесь экономят время: без них оба статуса попали бы в одну кучу «не продлили».

Ушедших после первой оплаты — 149 из 912 подписчиков, 16,3%. Разбивка по каналам неровная: в paid_search так ушли 45,3% подписчиков, в referral — 7,9%. Это и есть подсказка, кого звать первым. 39 человек из paid_search — небольшой список, его можно обзвонить целиком. Для сравнения стоит поговорить и с несколькими из 22 ушедших referral: если причины разные, проблема в ожиданиях от рекламы, если одинаковые — в продукте.

WITH paid AS (
  SELECT user_id, COUNT(*) AS payments_cnt
  FROM payments
  GROUP BY user_id
)
SELECT
  u.channel,
  COUNT(*) AS subscribers,
  SUM(CASE WHEN s.status = 'churned' AND p.payments_cnt = 1 THEN 1 ELSE 0 END) AS churned_after_one,
  SUM(CASE WHEN s.status = 'past_due' AND p.payments_cnt = 1 THEN 1 ELSE 0 END) AS past_due_after_one,
  ROUND(CAST(100.0 * SUM(CASE WHEN s.status = 'churned' AND p.payments_cnt = 1 THEN 1 ELSE 0 END) / COUNT(*) AS numeric(18, 6)), 1) AS churned_pct
FROM subscriptions AS s
JOIN paid AS p ON p.user_id = s.user_id
JOIN users AS u ON u.user_id = s.user_id
GROUP BY u.channel
ORDER BY churned_after_one DESC;

Кого звать: активные, но не платят

Третий сегмент — люди, которые пользуются продуктом и не покупают. С ними интересно говорить о том, какую задачу они решают бесплатной частью и чего им не хватило для оплаты. Определение придётся собрать самому, и от него зависит размер сегмента, поэтому условия лучше записать явно.

Здесь условия такие. Регистрация не позже 8 августа: первая оплата в базе приходит на 3–20-й день, и у более свежих пользователей срок ещё не вышел. Активность — события минимум в пять разных дней за последние четыре полные недели, со 2 по 29 августа. 30 августа в окно не входит: выгрузка закрыта в 13:00, день неполный. И третье условие — человек хотя бы раз создал отчёт, то есть знает, что продукт умеет.

Активных по этому определению 637, ни разу не платили 493, из них 217 создавали отчёт. Последняя цифра — кандидаты на интервью. Остальные 276 ходят в приложение без отчётов, и это отдельная загадка: что они там делают? Порог в пять дней — рабочее допущение. С порогом в четыре дня сегмент вырастет до 312 человек, с шестью — сожмётся до 133: проверьте, что вывод не держится на одном значении порога.

WITH recent AS (
  SELECT user_id, COUNT(DISTINCT CAST(event_time AS date)) AS active_days
  FROM events
  WHERE event_time >= TIMESTAMP '2026-08-02 00:00:00'
    AND event_time < TIMESTAMP '2026-08-30 00:00:00'
  GROUP BY user_id
),
reporters AS (
  SELECT DISTINCT user_id FROM events WHERE event_name = 'report_created'
),
payers AS (
  SELECT DISTINCT user_id FROM payments
)
SELECT
  u.channel,
  COUNT(*) AS active_users,
  SUM(CASE WHEN p.user_id IS NULL THEN 1 ELSE 0 END) AS never_paid,
  SUM(CASE WHEN p.user_id IS NULL AND r.user_id IS NOT NULL THEN 1 ELSE 0 END) AS never_paid_with_report
FROM users AS u
JOIN recent AS a ON a.user_id = u.user_id
LEFT JOIN reporters AS r ON r.user_id = u.user_id
LEFT JOIN payers AS p ON p.user_id = u.user_id
WHERE u.signup_date <= DATE '2026-08-08'
  AND a.active_days >= 5
GROUP BY u.channel
ORDER BY never_paid_with_report DESC;

Сколько интервью нужно провести

Честный ответ — пока в сегменте не перестанут появляться новые ответы. В качественных исследованиях это называют насыщением: очередной разговор повторяет уже услышанные причины и не добавляет новых. Заранее это число неизвестно, потому что зависит от того, насколько однородна группа.

Ориентир из литературы есть, но он узкий. Грег Гест с коллегами в 2006 году разобрали 60 глубинных интервью и проверили, когда перестают появляться новые темы: насыщение наступило в первых двенадцати разговорах, а основа крупных тем была видна уже к шести. Группа у них была однородной, а вопросы — одинаковыми для всех. Перенести «12» на любой кастдев нельзя: если в одной серии смешаны ушедшие после оплаты и застрявшие до первого отчёта, насыщение не наступит и к тридцати.

Практическое правило отсюда такое: считайте интервью по сегментам, а не всего. После каждого разговора отмечайте, появилась ли причина, которой не было раньше. Три-четыре разговора подряд без новых причин — повод остановиться в этом сегменте и перейти к следующему. А если после пяти интервью каждый рассказывает своё, сегмент слишком широкий и его надо делить.

Как фиксировать результаты интервью

Записывайте разговор с разрешения собеседника и переносите в таблицу в тот же день: через неделю от интервью остаётся общее впечатление, и оно подозрительно похоже на то, что вы думали до разговора. Одна строка — одно интервью. Главное правило таблицы — держать отдельно то, что человек сделал, то, что он сказал, и то, как вы это поняли.

Поле user_id нужно обязательно. Через него интервью соединяется с событиями и платежами: видно, совпадает ли рассказ с поведением, и можно проверить, чем ответившие отличаются от остального сегмента.

Как вернуть вывод интервью в данные

Интервью заканчивается гипотезой, а не решением. Дальше три шага: сформулировать её так, чтобы можно было опровергнуть, найти число, в котором она должна проявиться, и поставить эксперимент.

Условный пример. Вы поговорили с шестью застрявшими между рабочим пространством и отчётом, и четверо рассказали одно и то же: открыли пустой экран и не поняли, что делать первым. Гипотеза: «людям не хватает подсказки о первых шагах; если показать список шагов, больше новичков дойдёт до целевого действия». Проверка числом до эксперимента: если причина в пустом экране, застрявшие должны быть во всех каналах примерно в равной доле — и первый запрос это показал. Будь провал только в paid_search, гипотеза про экран объясняла бы его плохо.

Затем эксперимент. В базе «Маяк» как раз есть тест onboarding_checklist: части новичков показывали чек-лист первых шагов. В контрольной группе целевого действия достигли 306 из 1527 (20,0%), в группе с чек-листом — 467 из 1541 (30,3%). Разница в 10,3 процентного пункта — уже количественный результат, его можно проверять на значимость и считать в деньгах. Как довести гипотезу от наблюдения до критерия решения, разобрано в статье о гипотезах для A/B-тестов.

Обратите внимание на порядок. Данные показали место и сегмент, интервью дало причину, данные её проверили. Если пропустить первое, разговаривать придётся с кем попало. Если пропустить последнее, компания будет строить функцию по рассказу четырёх человек.

SELECT
  variant,
  COUNT(*) AS users,
  SUM(CASE WHEN converted THEN 1 ELSE 0 END) AS converted_users,
  ROUND(CAST(100.0 * SUM(CASE WHEN converted THEN 1 ELSE 0 END) / COUNT(*) AS numeric(18, 6)), 1) AS conversion_pct
FROM experiment_exposures
WHERE experiment_name = 'onboarding_checklist'
GROUP BY variant
ORDER BY variant;

Типичные ошибки кастдева

Почти все они сводятся к одному: разговор устроен так, что услышать неприятное невозможно.

• Спрашивать «купили бы вы?». Ответ о будущем ни к чему не обязывает. Спрашивайте, что человек уже делал и за что уже платил.
• Говорить только с лояльными. Те, кто остался и охотно отвечает, расскажут, почему продукт хорош. Причины ухода знают ушедшие — это ошибка выжившего в чистом виде.
• Читать три разговора как статистику. Интервью дают список причин, а не их доли. «Большинству не хватает интеграций» по итогам трёх звонков — не вывод.
• Подтверждать собственную идею. Наводящие вопросы, рассказ о решении в начале, запись только удобных цитат. Проверка простая: что в этой серии интервью могло бы вас переубедить?
• Звать тех, кто под рукой. Знакомые, подписчики канала, клиенты одного менеджера — это не сегмент.
• Смешивать сегменты в одной серии. Причины ушедших после оплаты и не дошедших до первого отчёта разные, а в общей таблице они сольются в шум.
• Показывать решение на проблемном интервью. После макета человек обсуждает макет.
• Оставлять вывод без проверки. Гипотеза из интервью, не дошедшая до числа и эксперимента, остаётся мнением — только теперь с цитатами.

Частые вопросы о кастдеве

Итог

Кастдев — это не «поговорить с пользователями», а короткий цикл: данные находят сегмент, где что-то идёт не так, интервью объясняют причину, данные и эксперимент её проверяют. На учебной базе три запроса дали три списка для разговоров: 975 застрявших до первого отчёта, 149 ушедших после первой оплаты и 217 активных, которые не платят. В каждом — свои вопросы и своя серия интервью.

Если проблема подтвердилась, следующий шаг — проверить решение на минимальной версии; об этом статья про MVP. А считать сегменты на базе продукта самому можно в Симуляторе SQL-аналитика: там та же база «Маяк» и задачи на воронку, активацию и эксперимент.