CustDev простыми словами: 15 интервью дешевле полугода разработки

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

Разница в цене наглядна. Возьмём команду из четырёх человек при 6 000 долларов на человека в месяц: полгода её работы стоят 144 000 долларов. Серия из 15 часовых интервью с анализом занимает у одного продакт-менеджера две-три недели. Метод простой: системный разговор с потенциальными и реальными клиентами, где гипотезы о проблемах, мотивациях и поведении людей проверяются фактами.

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

Провал начинается с неверных предположений о клиенте

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

Чем больше конкурентов, тем дороже такая ошибка. У пользователя есть выбор, и он не станет тратить время на продукт, польза которого непонятна. Ненужная функция, а тем более целый продукт, стоит денег, времени и веры команды в своё дело. CustDev и появился как ответ на это: вместо того чтобы гадать в офисе, команда идёт и смотрит, как живут клиенты.

Гибкие методы разработки сделали проблему острее, хотя должны были её решить. Команды научились быстро выпускать MVP. И оказалось, что быстрая разработка ничего не стоит, если команда так же быстро не узнаёт новое о клиентах. Можно за месяц выпустить три версии продукта, который никому не нужен. CustDev даёт понятный способ узнавать о клиентах и менять продукт до того, как ошибка превратится в код.

Что именно проверяет CustDev

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

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

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

На практике эти инструменты путают чаще, чем кажется, поэтому полезно разложить их по осям:

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

Кому и когда он нужен

CustDev нужен везде, где решение приходится принимать вслепую. Но в каждой ситуации он портится по-своему:

• на ранней стадии стартапа он помогает выжить. Пока неясно, кто клиент и какую проблему решает продукт, разговоры спасают от разработки "в вакууме" и быстрее приводят к модели, на которой можно зарабатывать. Портится он, когда исследуют ради самого процесса;
• в зрелой компании он помогает запускать новые продукты, выходить к новым клиентам и перестраивать старые решения. Он показывает, где представления о рынке расходятся с реальностью, и подсказывает, где ещё можно расти. Ломается он, когда команда думает: раз клиенты у нас есть, мы и так знаем, что им нужно;
• когда своей аналитики нет или её мало, он становится главным источником знаний для решений. Продакт-менеджеры, маркетологи, основатели и руководители начинают говорить о реальных проблемах клиента, а не о своих догадках. Смысл теряется, если этим занимается один человек и его выводы ни на что не влияют.

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

Как это выглядит в повседневной работе

Цикл проще показать на обобщённой истории, которая в разных вариациях случается постоянно. Команда SaaS-сервиса для малого бизнеса была уверена, что её ключевая ценность в автоматизации отчётности. Основатели сами сталкивались с этой проблемой и считали её универсальной. Продукт активно развивался и усложнялся, но пользователи росли слабо. Ровно та тишина, с которой начинался этот текст.

Формулирование гипотез

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

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

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

Общение с клиентами

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

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

Анализ и выводы

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

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

Инструменты и дисциплина записи

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

Чтобы знания о клиентах были у всей команды, включая тех, кто не сидел на интервью, их записывают: гипотезы, персоны, карты проблем, описания задач клиента (jobs-to-be-done). Рядом ведут таблицу, где выводы собраны по темам, и журнал решений: какой вывод к какому изменению в продукте привёл. Прототипы, лендинги и простые эксперименты дополняют картину, но живой разговор не заменяют. Всё решают вопросы, наблюдения и выводы, а шаблоны тут дело второе.

Как CustDev превращается в формальность

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

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

Третья группа касается работы с результатом, и её удобно держать перед глазами списком:

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

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

Есть и тихий вариант той же болезни: массовые опросы без контекста. Разослать анкету с закрытыми вопросами и назвать это CustDev значит потерять глубину: такие данные годятся для количественной проверки, но не для выявления реальных проблем. Окончательный диагноз ставится по результату. Если продукт и стратегия остались прежними вопреки новым данным, CustDev использовали как оправдание, а не как инструмент решений.

Ценность оказалась в другом месте

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

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

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

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

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

Готовы ли вы к первому интервью?

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

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

Вторая группа про то, что вы делаете с ответами:

• Умеете ли вы слушать, не подсказывая, и отделять факты от интерпретаций?
• Ищете ли повторяющиеся паттерны вместо единичных мнений?
• Документируете ли инсайты после каждого цикла и ведёте ли журнал гипотез и решений?
• Принимаете ли решения на основе данных, а не вопреки им, и готовы ли отказаться от идеи, если CustDev показал её несостоятельность?
• Вовлечена ли в обсуждение вся команда, а не один человек, и проводите ли вы исследование регулярно, а не только на старте?

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

Сколько интервью нужно, кто их ведёт и когда начинать

Когда начинать: до MVP или после

Логичнее до. CustDev нужен, чтобы проверить, существует ли проблема и насколько она значима, ещё до того как команда что-то построит. После MVP появляется риск, что команда начнёт защищать вложенные усилия и отмахиваться от неудобных инсайтов, как это было бы с основателями из первой истории, если бы они спрашивали клиентов уже про готовый модуль отчётности. На раннем этапе CustDev делает MVP сфокусированным, а не "для всех". При этом с выходом MVP он не заканчивается: после релизов он показывает, как продукт используют и какие проблемы возникают.

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

Магического числа нет: важны качество и повторяемость инсайтов, а не количество. Первые паттерны с правильно выбранной аудиторией обычно проступают уже после 5-7 интервью, но для уверенных выводов этого редко хватает. Чаще CustDev идёт сериями: 10-15 интервью, анализ, уточнение гипотез, при необходимости следующий раунд. Продолжать стоит, пока новые разговоры приносят новое; когда ответы начинают повторяться, гипотеза либо подтверждена, либо опровергнута, и дальнейшие интервью в этом сегменте дают убывающую ценность.

Кто в команде должен этим заниматься

В идеале ключевые продуктовые роли: основатель, продакт-менеджер, дизайнер. Они принимают решения о направлении продукта, и прямой контакт с клиентами помогает им понимать последствия своих выборов; полностью отдать CustDev стороннему исследователю значит получить отчёт, который не изменит ни одного решения. Обязанностью одного человека он тоже быть не должен. Даже если интервью проводит один, анализ инсайтов лучше делать вместе: так понимание рынка становится общим, а не личным. Считать это вспомогательной нагрузкой не стоит, CustDev входит в саму продуктовую работу.

Как избежать искажения ответов

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

Как это связано с Lean Startup и MVP

CustDev служит фундаментом Lean Startup: он проверяет проблемную часть гипотез, а MVP проверяет часть с решением. Без него MVP рискует стать просто урезанной версией ненужного продукта. В связке CustDev подсказывает, что именно проверять через MVP, и делает эксперименты точнее: вместо "посмотрим, что выйдет" команда понимает, какую гипотезу тестирует. Сначала проблема через интервью, затем решение через MVP, потом снова к клиентам: такой цикл ускоряет обучение и повышает шансы найти соответствие продукта рынку. Старая последовательность выглядела иначе: бизнес-план с прогнозом на пять лет, питч инвесторам, найм команды и запуск, а первый честный разговор с клиентом случался уже после релиза.

Можно ли масштабировать CustDev в большой компании

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

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