Разбор провала обычно пишут после релиза, когда деньги уже потрачены. Пре-мортем делает ту же работу заранее: команда представляет, что продукт провалился через полгода, и ищет причину. В трёх историях ниже причина одна: предположение о клиенте, которое никто не проверил разговором. Двенадцать интервью по 45 минут вместе с разбором занимают около 16 часов, а два месяца работы трёх разработчиков над фичей, которой никто не пользуется, стоят около тысячи часов.
Стив Бланк ввёл метод в первой своей книге, «The Four Steps to the Epiphany». Эрик Рис позже сделал его частью «The Lean Startup» (2011), а сам Бланк подвёл итог в статье Harvard Business Review «Why the Lean Start-Up Changes Everything» (май 2013). Мысль за всем этим простая и неудобная: команда почти всегда знает о клиентах меньше, чем ей кажется. Даже если продукт делается «для себя» или для знакомой аудитории, догадки редко совпадают с жизнью. CustDev помогает проверять эти догадки по порядку. Работает он одинаково в стартапе, корпорации, digital-команде и во внутреннем продукте.
Откуда у команды ложная уверенность
Откуда команда берёт уверенность, что клиента уже поняли? Обычно из отчётов о рынке, чужих исследований или своего опыта похожих задач. Всё это знание из вторых рук. Оно описывает рынок в среднем и почти ничего не говорит о том, как конкретный человек решает, пробовать продукт или нет.
Опасно оно тем, что его никто не проверяет. Гипотезы не испытывают на реальных людях, решения принимаются по мнению самого громкого участника, по ожиданиям руководства или по образцу конкурента. Продукт выглядит логичным внутри компании и не вызывает интереса у рынка.
Цена ошибки растёт вместе с неопределённостью. Когда нет исторических данных, метрик и устойчивого спроса, единственным источником правды остаются люди. Если их не слушать, дело кончается затяжной разработкой, болезненным пивотом и потерей доверия внутри команды.
Поэтому острее всего CustDev нужен стартапу, который ещё не нашёл соответствие продукта рынку: любой месяц разработки без понимания клиента здесь ставка вслепую. Зрелые компании ошибаются, считая этот риск пройденным. Миллионы пользователей не гарантируют понимания мотивации нового сегмента, и при запуске нового направления CustDev обновляет картину так же, как в стартапе. Внутри команды выигрывают продакт-менеджеры, дизайнеры, маркетологи и основатели: спор «мне кажется» против «а мне кажется иначе» заменяется вопросом, что говорили клиенты.
Что CustDev проверяет и где его границы
CustDev (Customer Development) помогает проверить догадки о клиентах в прямом разговоре с ними: какие у них проблемы, чего они хотят и как себя ведут. Задача в том, чтобы понять, есть ли проблема и насколько она серьёзна. Одобрение идеи здесь не нужно.
Отсюда и отличие от смежных практик. UX-исследования фокусируются на удобстве интерфейса, то есть на решении, которое уже существует. Аналитика работает с поведением, которое уже случилось. Продажа добивается согласия, даже если в разговоре обсуждаются те же деньги и готовность платить. CustDev ищет правду, в том числе неприятную.
Граница проходит там, где заканчивается исследование проблемы и начинается проектирование решения. CustDev отвечает на вопросы «кто», «почему» и «зачем», но не на вопрос «как это должно выглядеть». Команда, которая ждёт от интервью готового дизайна, разочаруется в методе по ошибке.
Значимость проблемы проверяют отдельно от её наличия. Признак значимости: человек уже тратит на проблему деньги или время, собрал обходной путь из таблиц и чатов, может назвать последний случай. Если проблему «иногда замечают», но никто ничего с ней не делает, это слабый сигнал, сколько бы людей её ни упомянули.
Как выглядит процесс CustDev в реальной работе
Цикл состоит из трёх этапов, и пропуск любого из них обесценивает два остальных.
Этап формулирования гипотез
Любой CustDev начинается с гипотез: кто клиент, какую проблему он испытывает, как решает её сейчас и почему это решение его не устраивает. Без них интервью превращаются в разговоры без фокуса.
Гипотеза должна быть проверяемой. Формулировка «пользователям это будет полезно» не годится, потому что её невозможно опровергнуть: любой ответ можно истолковать в её пользу. Рабочая формулировка заранее называет критерий отказа. Например (условные цифры): «Если меньше 6 из 12 фрилансеров сами, без подсказки, назовут поиск клиентов одной из двух главных проблем за последние три месяца, гипотеза отклонена». Такой порог записывают до первого интервью, иначе после него команда незаметно сдвинет планку.
Этап общения с клиентами
Когда гипотезы записаны, команда идёт к потенциальным или текущим клиентам. Чаще всего это глубинные интервью вокруг прошлого опыта человека: реальных ситуаций, действий и решений. Абстрактные рассуждения о будущем почти ничего не дают.
Главное правило этапа: слушать и не убеждать. Интервьюер не продаёт идею, не защищает продукт и не подсказывает ответы. Каждая такая попытка сужает пространство, в котором клиент может сказать неожиданное, а неожиданное здесь самое ценное. Пауза после ответа часто приносит больше, чем следующий заготовленный вопрос: человек сам добавляет подробности, о которых вы бы не догадались спросить.
Сколько интервью нужно? Твёрдого числа нет, но есть рабочий признак насыщения: если четыре разговора подряд внутри одного сегмента не принесли ни одной новой проблемы, этот сегмент можно закрывать. На практике это часто 8-15 разговоров на сегмент. Смешивать сегменты в одной выборке опасно: пять бухгалтеров и пять дизайнеров дают десять интервью, но два недоисследованных сегмента по пять человек.
Этап анализа и принятия решений
Анализ после интервью недооценивают чаще всего. Команда структурирует ответы, ищет повторяющиеся паттерны и сопоставляет их с гипотезами. Здесь проще всего обмануть себя: перепутать факт с интерпретацией или подогнать данные под желаемый результат.
Помогает простая таблица. В строках респонденты, в столбцах гипотезы, в ячейке цитата с фактом, без выводов. «В марте клиент не заплатил 1 200 евро, я два месяца писал ему» описывает факт. «Ему важна безопасность оплаты» уже ваше толкование.
Итогом CustDev должны стать решения: изменить целевую аудиторию, пересобрать ценностное предложение или отказаться от идеи. После цикла понятно, что поддерживают данные: сменить направление, проверить оставшийся риск или сохранить курс.
Инструменты и артефакты CustDev
Основной инструмент: глубинное интервью по заранее подготовленному сценарию с вопросами о контексте, проблемах, триггерах и существующих решениях. Ответы фиксируют дословно, потому что вывод, записанный на ходу, уже содержит интерпретацию интервьюера. Лучше всего работает запись с согласия респондента и второй человек, который ведёт заметки.
Из интервью вырастают артефакты: журнал гипотез, карты проблем, описания сегментов и jobs-to-be-done. Они фиксируют знание так, что им может пользоваться вся команда, и CustDev перестаёт быть личным опытом одного исследователя.
Прототипы, лендинги и эксперименты тоже идут в дело, но как дополнение к разговору: они показывают, что человек сделал, а интервью объясняет почему. Для уже работающего продукта мостом служит короткий опрос активных пользователей: насколько они расстроятся, если продукт завтра исчезнет. Интервью с теми, кто ответил «очень», затем объясняют, за что именно они держатся.
Сбои, после которых CustDev становится ритуалом
Самый частый сбой выглядит безобидно: CustDev проводят для галочки. Интервью есть, а гипотез нет, выводы нигде не записаны, решения после разговоров не меняются. Формально процесс идёт, по сути он давно стал ритуалом.
Не меньше вредит неудачный выбор респондентов. Друзья, коллеги и случайные знакомые охотно соглашаются поговорить, но к целевой аудитории обычно не относятся, и картина, собранная по их ответам, ведёт к ложным выводам.
Отдельная ловушка возникает, когда просят оценить идею или обсуждают будущие фичи. Люди плохо предсказывают собственное поведение и из вежливости соглашаются. Полезная проверка для каждого вопроса: может ли собеседник ответить на него вежливой неправдой. Если может, вопрос нужно переписать. Опирайтесь на то, что человек уже делал, а обещания почти ничего не стоят.
Похожий эффект даёт защита идеи во время интервью. Интервьюер спорит с клиентом или объясняет, «почему он неправ», и самая ценная информация так и не прозвучит. CustDev требует нейтральной позиции и готовности услышать отказ.
Даже честно собранные данные можно похоронить при анализе. Если результаты противоречат ожиданиям, их пытаются обесценить: «не та аудитория», «мало интервью», «они не поняли идею». Часто так начинается весь неработающий CustDev: с заранее принятого решения, которое нужно подтвердить. Вопросы составляют под положительный ответ, негативные сигналы списывают, и команда уверенно идёт в неверном направлении с ощущением, что всё проверила.
Другая маскировка: массовые опросы вместо интервью. Анкета с закрытыми вопросами даёт поверхностные данные, ведь варианты ответа придумала сама команда. Опрос полезен позже, когда нужно оценить масштаб уже найденной проблемы. Искать саму проблему анкетой бесполезно.
Самый надёжный индикатор лежит в последствиях. Если после двадцати интервью продукт не изменился ни в одной строке roadmap, процесс не встроен в принятие решений.
Провал первый: витрина услуг, которая не была нужна фрилансерам
Компании в трёх историях вымышлены, ситуации типичны. Команда онлайн-сервиса для фрилансеров была уверена, что главная боль аудитории связана с поиском клиентов. Продукт строился вокруг фич продвижения и витрин услуг, но рост пользователей оставался слабым.
Команда записала гипотезу с тем самым порогом: не меньше 6 из 12 респондентов должны сами назвать поиск клиентов одной из двух главных проблем. После двенадцати интервью счёт выглядел так: поиск клиентов назвали трое. Девять человек говорили о переговорах, согласовании условий и контроле оплат, семеро за последний год хотя бы раз не получили деньги за сданную работу. Гипотеза не прошла собственный порог, а соседняя проблема набрала втрое больше упоминаний.
Фрилансеры рассказывали о потерянных деньгах, неоплаченных счетах и тяжёлой переписке с заказчиками, и эти темы повторялись из интервью в интервью. Фичи продвижения на этом фоне воспринимались как второстепенные.
Команда пересобрала продукт вокруг договоров и оплат. Часть фич убрали, фокус стал уже и понятнее. Продукт начал решать реальную боль аудитории, выросли вовлечение и готовность платить. Арифметика итога проста: около 16 часов интервью сэкономили месяцы разработки витрин, которые и так не росли.
Провал второй: аналитический модуль, который никто бы не открыл
Во второй истории продукт зрелый, а уверенность шла сверху. В крупной B2B-компании планировали новый модуль для корпоративных клиентов. Руководство считало, что пользователям не хватает расширенной аналитики и отчётности, и команда получила задачу сделать сложный аналитический блок с множеством настроек и дашбордов.
До начала разработки продуктовая команда настояла на CustDev. Гипотезу сформулировали так: пользователям не хватает прозрачности данных и возможности глубже анализировать процессы. Затем провели серию интервью с представителями разных ролей в компаниях-клиентах. Разные роли здесь обязательны: боль человека, который читает отчёт, редко совпадает с болью того, кто подписывает на него бюджет.
Аналитика как таковая проблемой не оказалась. Пользователи признавали, что отчёты полезны, но жаловались на перегруженный интерфейс и сложность текущих инструментов. Главной болью был недостаток времени на интерпретацию данных, которых и так хватало.
Многие рассказывали, что отчёты делаются «для галочки» и редко влияют на решения. Им нужны были простые сигналы и рекомендации вместо ручной сборки сложных отчётов. Этот вывод сильно расходился с ожиданиями руководства.
Команда пересобрала модуль. Вместо сложных отчётов он стал давать готовые подсказки, оповещения о важных изменениях и сценарии действий. Интерфейс упростили, настроек стало меньше. Модуль приняли гораздо лучше прежних обновлений. А компания не стала строить дорогую функцию, которую никто бы не открыл.
Провал третий: подписка, на которую соглашались все
Третья команда придумала доставку готовых обедов в офисы и провела пятнадцать интервью. Почти все собеседники хвалили идею и говорили, что подписались бы. Команда приняла это за подтверждение и запустила подписку с оплатой на месяц вперёд. Через два месяца платили единицы.
Ошибка сидела в вопросах. Команда спрашивала о будущем («Стали бы вы заказывать?»), а такой вопрос почти бесплатно получает «да». Вопросы о прошлом дали бы другую картину: где человек обедал на прошлой неделе, сколько заплатил, почему в последний раз не заказал доставку. Из ответов стало бы видно, что большинство носит еду из дома или ходит в столовую через дорогу, а доставку берёт раз в месяц, когда задерживается. Месячная подписка для такой привычки слишком тяжёлая.
Порог отказа и здесь можно было записать заранее: скажем, «не меньше половины собеседников за последние две недели хотя бы трижды заказывали обед в офис». Пятнадцать честных ответов о прошлой неделе заняли бы два-три дня и закрыли бы гипотезу до запуска. Ещё быстрее работает просьба о маленьком обязательстве, например оплатить пробную неделю заранее. Похвала собеседнику ничего не стоит, предоплата стоит, и разница видна в первый же день.
Когда интервью проигрывают данным
Критика CustDev звучит убедительно. Интервью дают малую выборку, люди говорят одно, а делают другое, интервьюер неизбежно влияет на ответы. Зачем разговаривать с двенадцатью людьми, если аналитика видит поведение ста тысяч, а A/B-тест показывает причинный эффект?
Для существующего продукта с трафиком критики часто правы. Если вы меняете текст кнопки или порядок шагов в онбординге, эксперимент ответит точнее любого интервью. Но эксперимент требует, чтобы вариант уже был построен. Каждый проигравший вариант к моменту теста уже оплачен разработкой, а проигрывает в тестах заметная часть идей. CustDev работает раньше и дешевле: он отсекает идеи, которые не стоит даже прототипировать.
Правило выбора получается такое. Если решение дешёвое, обратимое и трафика хватает на тест, тестируйте. Если решение дорогое (месяц разработки и больше), необратимое или касается нового сегмента, начинайте с интервью. CustDev почти не нужен там, где проблема и решение хорошо известны: мелкие улучшения существующего функционала, обязательные требования регулятора, перенос паттерна, который уже работает у вас в соседнем продукте.
Проверка: работает ли CustDev у вас
Проходите список строго: «да» засчитывается, только если за ответом стоит артефакт или принятое решение.
- Есть ли у вас зафиксированные гипотезы о клиентах и их проблемах?
- Понимаете ли вы, какую именно неопределённость хотите снизить с помощью CustDev?
- Записан ли для каждой гипотезы порог, при котором вы её отклоните?
- Общаетесь ли вы с реальными представителями целевой аудитории?
- Задаёте ли вы вопросы о прошлом опыте, а не о будущем?
- Избегаете ли вы обсуждения своего решения в интервью?
- Фиксируете ли вы ответы клиентов дословно?
- Отделяете ли вы факты от интерпретаций при анализе?
- Изменилась ли за последний квартал хотя бы одна строка roadmap после интервью?
- Готовы ли вы отказаться от идеи при отсутствии подтверждений?
- Знаете ли вы текущие альтернативы клиентов и сколько денег и времени они на них тратят?
- Есть ли у вас журнал гипотез и решений?
Что спрашивают про CustDev до разработки
Почему CustDev не равен просто разговорам с пользователями?
Разговоры с пользователями бывают полезны, но без структуры редко дают системную ценность. CustDev начинается с гипотез и заканчивается решениями, поэтому остаётся управляемым процессом. Вопросы в нём составляют так, чтобы проверить конкретные предположения и выявить факты и паттерны.
Без подготовки и навыков анализа разговоры превращаются в субъективные впечатления, которые каждый участник команды пересказывает по-своему. Проверка простая: если после разговора нельзя сказать, какая гипотеза подтвердилась или упала, это был разговор, а не CustDev.
Можно ли проводить CustDev в одиночку?
Технически один человек может провести интервью, но замыкать процесс на одном человеке вредно. Совместный анализ помогает избежать искажений, а инсайты, которые живут только в голове исследователя, не становятся частью общего понимания.
Лучше всего работает схема, при которой интервью ведут один или два человека, а выводы и решения команда принимает вместе. Хорошее правило: разработчик или дизайнер слушает хотя бы одно интервью из пяти вживую. Тогда знание не уходит вместе с одним сотрудником.
Как часто нужно проводить CustDev?
CustDev сопровождает продукт на протяжении всего жизненного цикла, и частота зависит от уровня неопределённости. На ранних этапах гипотезы меняются быстро, и интервью могут идти почти непрерывно. Тереза Торрес в книге «Continuous Discovery Habits» (2021) предлагает зрелым командам ритм в одно-два интервью каждую неделю вместо больших исследований раз в полгода.
В зрелых продуктах CustDev проверяет новые инициативы, гипотезы роста и изменения в поведении клиентов. Даже при развитой аналитике он остаётся источником объяснений: аналитика фиксирует, что случилось, интервью объясняет почему.
Что делать, если клиенты сами не знают, чего хотят?
Это нормальная ситуация. CustDev и не ждёт, что клиенты сформулируют решения: его задача понять проблемы, контекст и ограничения. Решения всегда остаются за командой.
Ответ «не знаю» в интервью служит сигналом копать глубже. Лучше работают вопросы о прошлом опыте, сложных ситуациях и эмоциях: человек может не знать, чего хочет, но хорошо помнит, что вывело его из себя на прошлой неделе.
Можно ли доверять результатам CustDev?
Результатам CustDev можно доверять больше, чем интуиции, и меньше, чем поведению клиентов после запуска. Их ценность зависит от качества гипотез, вопросов и анализа. Неопределённость метод снижает, но не устраняет, поэтому успеха он не гарантирует.
Доверие к инструменту растёт со временем. Когда команда регулярно сравнивает выводы интервью с реальным поведением клиентов после запуска, становится видно, где интервью предсказали верно, а где команда слышала то, что хотела услышать.
Сколько стоит один цикл CustDev?
Двенадцать интервью по 45 минут дают 9 часов разговоров. Ещё около часа уходит на сценарий и по 30 минут на разбор каждого интервью, итого примерно 16 часов одного исследователя. Если респондентам платят за время, скажем по 50 евро, бюджет на вознаграждения составит 600 евро. Медленнее всего обычно идёт рекрутинг: в B2B найти двенадцать человек из нужного сегмента может занять две-три недели.
Теперь сравните это с ценой ошибки. Месяц работы трёх разработчиков и дизайнера составляет порядка 640 часов. Если хотя бы один цикл из пяти останавливает неверную инициативу такого масштаба, метод окупается многократно. Если же за год CustDev ни разу не поменял решения, деньги уходят впустую, и вопрос уже к тому, как вы формулируете гипотезы.
Как встроить CustDev в текущие процессы?
Проще всего сделать его обязательным шагом перед запуском инициатив дороже заранее оговорённого порога, например месяца работы команды. Для этого нужны поддержка руководства, обучение и выделенное время, иначе CustDev будет постоянно откладываться «на потом». Руководителю он даёт аргументы для приоритизации: видно, какие инициативы опираются на услышанное, а какие только на предположения.
Платить за эту дисциплину приходится дискомфортом: самые полезные интервью обычно неприятны. Разговор о гипотезе, которую страшнее всего проверять, чаще приносит причины отказа, чем согласие, и команда, привыкшая к одобрительным ответам, легко сворачивает его раньше времени. Если за последний месяц ни одно решение не изменилось из-за услышанного, интервью шли ради подтверждения уже принятой идеи. Порог отказа, записанный до первого звонка, отличает проверку от ритуала.