Статьи

    Точно ли нужен CustDev, или это лишний ритуал, который мешает делать продукт?

    2 марта 2026 г.
    10 мин чтения
    Автор: Callan Whitmore
    Обновлено 26 октября 2026 г.
    Поделиться этой статьей

    CustDev окупается тогда, когда у команды есть неопределённость, которую разговор с клиентом способен снять. Если за квартал набралась дюжина интервью и сорок страниц заметок, а ни одно решение не сдвинулось, виноват обычно не метод. Скорее всего, вопроса просто не было, и команда честно спрашивает себя, нужен ли ей CustDev вообще.

    Сомнения появляются после ритуала без вопроса

    О Customer Development пишут в вакансиях, программах курсов и презентациях для инвесторов. Со стороны кажется, что без CustDev продукт не имеет права на существование. На практике он часто раздражает: интервью не дают ответов, пользователи говорят очевидное, время уходит на разговоры, а решения всё равно принимают по ощущениям.

    Скепсис обычно приходит после серии разочарований, когда интервью не приводят к понятным решениям, а продукт всё равно не растёт. Первая причина: CustDev внедряют как процесс. Появляются планы интервью, квоты и шаблоны вопросов, а главный смысл, снижение неопределённости, теряется.

    Вторая причина в ожиданиях. От CustDev ждут ответа «какую фичу сделать, чтобы всё заработало». Он даёт материал для размышлений, который ещё нужно уметь интерпретировать. Поэтому вопрос «нужен ли нам CustDev» на деле звучит иначе: какую задачу он должен решить именно у нас.

    CustDev сужает варианты, но не выбирает за команду

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

    Термин и дисциплину ввёл Стив Бланк в книге «The Four Steps to the Epiphany» (2005). Его мысль: стартап ищет работающую бизнес-модель и поэтому не может быть уменьшенной копией большой компании. Гипотезы об этой модели проверяют, выйдя к клиентам (get out of the building). Переговорная для этого не годится. В мае 2013 года Бланк вынес этот подход на широкую аудиторию в статье для HBR «Why the Lean Start-Up Changes Everything».

    Решать, что строить, CustDev не берётся. Он показывает, какие варианты вообще имеет смысл рассматривать. Аналитику, эксперименты и продуктовые решения он не заменяет и работает до них и вместе с ними.

    Высокая неопределённость оправдывает интервью, низкая нет

    CustDev ценнее всего там, где команда не понимает контекст пользователя:

    • старт нового продукта;
    • выход на новый рынок;
    • смена целевой аудитории;
    • разворот стратегии.

    Он нужен и тогда, когда данные не объясняют поведение. Метрики покажут падение конверсии, но не скажут почему. Интервью помогает восстановить причинную цепочку, которую потом проверяют на данных.

    В зрелом продукте CustDev работает иначе. Больших открытий там ждать не стоит. Регулярные разговоры сверяют представления команды с жизнью пользователей и не дают от неё оторваться.

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

    Момент остановки лучше знать заранее. Когда новые интервью повторяют услышанное и перестают менять картину, неопределённость, скорее всего, снята. Дальше команда платит временем за уверенность, которая у неё уже есть.

    Это время легко посчитать. Час разговора, полчаса подготовки и час на запись выводов дают 2,5 часа на одно интервью. Двенадцать интервью съедают 30 часов, почти неделю работы одного человека. Если они не изменили ни одного решения, неделя ушла на ощущение исследования.

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

    Рабочий CustDev начинается с записанного вопроса

    Рабочий CustDev устроен как последовательная работа с гипотезами. Хаотичные разговоры его не заменят.

    Видео: Точно ли нужен CustDev, или это лишний ритуал, который мешает делать продукт?

    Первый шаг: сформулировать неопределённость. Что именно команда не понимает: проблему, мотивацию, контекст использования или процесс принятия решения? Без этого шага интервью превращаются в разговоры обо всём, где много слов и мало смысла. Хороший признак: после формулировки становится ясно, какие решения пока рано принимать.

    Вопрос удобно записывать в одну строку:

    Мы не знаем [что], поэтому не можем решить [какое решение]. Поговорим с [кем]. Если услышим [сигнал], то [изменим что].

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

    Дальше команда собирает качественный материал. Подтверждать гипотезу на этом этапе рано, поэтому никаких наводящих вопросов и продажи идеи. Рекламировать идею или проверять готовую фичу на интервью не нужно, это уже не CustDev. Этой ловушке целиком посвящена книга Роба Фитцпатрика «The Mom Test» (2013).

    Количество интервью вторично. Важнее глубина, разнообразие контекстов и умение слушать.

    Выборка из 80 довольных клиентов молчит о 920 ушедших

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

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

    Допустим, из 1 000 человек, начавших пробный период, платить стали 80. Команда проводит 12 интервью с платящими, и все 12 рассказывают о сценариях, где продукт работает. О 920 ушедших команда не узнаёт ничего, хотя ответ на вопрос о росте лежит именно там.

    Строка-вопрос из предыдущего раздела для этого случая могла бы выглядеть так: «Мы не знаем, почему 920 из 1 000 человек не платят после пробного периода, поэтому не можем решить, менять онбординг или цену. Поговорим с 8-10 ушедшими за последний месяц. Если большинство не дошло до первого отчёта, переделаем онбординг. Если дошли и ушли на цене, проверим тарифы». В такой формулировке видно, с кем говорить и что изменится от ответа.

    Прежде чем назначать интервью, стоит честно ответить, чей опыт снимет неопределённость, и готова ли команда потратить силы, чтобы до этих людей дотянуться. Удобная выборка и правильная совпадают редко.

    Одно яркое интервью весит больше десяти спокойных

    Труднее всего даётся интерпретация. Готовых ответов CustDev не даёт, поэтому команде приходится думать, спорить и делать выводы.

    Частая ошибка: трактовать интервью буквально. Пользователь сказал «мне нужна кнопка», команда сделала кнопку, и решение вышло поверхностным. Гарвардский маркетолог Теодор Левитт напоминал об этом формулой про дрель: люди покупают не четвертьдюймовое сверло, а четвертьдюймовое отверстие. Просьба про кнопку обычно рассказывает о нужном отверстии. Работа интервьюера в том, чтобы докопаться до него, прежде чем точить сверло по первому описанию.

    Ценно то, что повторяется у разных людей, а также противоречия и ограничения. Список пожеланий сам по себе почти ничего не даёт. Зрелые команды записывают рядом с цитатами свои интерпретации и связывают выводы с решениями. Если выводы не влияют на приоритеты, формат или стратегию, работа была лишней или плохо встроенной. Самый недооценённый результат хорошего CustDev: осознанное «нет».

    Сложность ещё и в психологии. Команда запоминает эмоциональную историю с деталями и строит решения вокруг единичного случая, принимая громкость за распространённость.

    Защита простая по формулировке и трудная на практике. Закономерностью считается то, что повторяется у разных людей в разных контекстах. Наблюдение, встреченное один раз, остаётся гипотезой, и переписывать продукт из-за него рано.

    CustDev вредит, когда становится алиби

    Провалы повторяются. CustDev делают без чёткого вопроса и используют интервью как подтверждение своих идей. Задают наводящие вопросы, путают желания с проблемами, ждут от пользователей готовых решений. Игнорируют контекст, проводят интервью ради отчёта и продолжают их, когда неопределённость уже снята.

    Бывает и прямой вред. Если команда боится взять ответственность, интервью становятся способом отложить выбор. Фраза «мы же поговорили с пользователями» превращается в алиби для слабого решения. А если команда заранее знает, что не изменит решение при любом результате, CustDev становится просто тратой времени.

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

    Аргумент рассыпается там, где тестировать нечего или не на ком. Новый сегмент, где ещё нет пользователей, решение о том, что вообще строить, B2B с двадцатью клиентами в год: A/B-тест здесь не наберёт выборку, а поддержка слышит только тех, кто уже купил.

    Одинаковое старание, разный вопрос

    Сравните две истории. Компании в них выдуманы, ситуации же реальны: обе встречаются в продуктовой практике постоянно.

    В первой команда делала B2B-продукт для автоматизации отчётности. Рост замедлился, и решили «усилить CustDev»: провели десятки интервью с текущими клиентами. Пользователи подробно рассказывали, каких отчётов и функций им не хватает. Команда сделала несколько улучшений, но рост не вернулся.

    При повторном анализе выяснилось, что интервью не касались ключевой неопределённости. Говорили с теми, кто уже купил продукт, и ни разу с теми, кто отказался. Когда фокус сменили на потенциальных клиентов, не выбравших продукт, появились совсем другие выводы о барьерах и ожиданиях. Команда пересобрала онбординг и позиционирование, и рост вернулся, хотя ни одной «запрошенной фичи» не добавили.

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

    Сигналы пошли противоречивые, пользователи хотели взаимоисключающего, команда пыталась учесть всё, и дорожная карта расползалась. После ретроспективы регулярный CustDev остановили и переключились на данные, технические метрики и эксперименты. Позже его вернули точечно, для проверки конкретных неопределённостей нового сегмента. Шум снизился, решения ускорились.

    Старались в обеих историях одинаково. Разница в том, что никто вовремя не спросил, какую неопределённость снимают интервью. Отсюда проверки до старта:

    • понимаем ли мы, какую неопределённость хотим снизить, и есть ли вопрос, на который нельзя ответить одними данными;
    • знаем ли, с кем именно говорить, включая тех, кто отказался или ушёл;
    • готовы ли изменить направление по результатам;
    • не используем ли CustDev, чтобы затянуть решение;
    • хватит ли времени не только собрать материал, но и интерпретировать его;
    • связаны ли выводы с дорожной картой и понятно ли, когда остановиться.

    Ответственность за выводы несёт продуктовая роль (PM, основатель или исследователь), и тот, кто принимает решение, участвует в интерпретации.

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

    Похожие статьи

    Статьи
    7 мин чтения

    Плохой Product Manager: это не тот, кто ошибается

    Плохого продакт-менеджера выдаёт отношение к ошибкам, а не их количество. Как работать с неполными данными, фиксировать предположения до решения и разбирать результат, чтобы ошибка не стала системной.

    1 марта 2026 г.
    Статьи
    7 мин чтения

    Книга «Спроси маму» как первый шаг в CustDev

    Вежливое «звучит здорово» от знакомых ничего не говорит о спросе. Как построить цикл интервью от гипотезы к паттернам, где разговор ломается чаще всего и как внедрить метод за один цикл исследований.

    1 марта 2026 г.
    Статьи
    26 мин чтения

    North Star Metric, или метрика полярной звезды: одна цифра, которая меняет решения

    Как выбрать North Star Metric, которая отражает ценность для пользователя: требования к метрике, входные метрики, встраивание в Agile-ритм, связь с KPI и OKR, когда метрику пора менять и в какие ловушки попадают команды.

    27 декабря 2025 г.