Точно ли нужен CustDev / Customer Development?

CustDev часто продают как универсальное лекарство: “сходи к пользователям — и всё станет ясно”. В реальности CustDev — это инструмент управления риском. Он нужен не “потому что так правильно”, а потому что есть ситуации, где без него вы почти гарантированно:

• строите не то,
• продаёте не тем,
• упираетесь в низкий retention,
• спорите внутри команды мнениями вместо фактов,
• тратите месяцы на то, что рынок не примет.

Но есть и обратная сторона: CustDev легко превращается в театр интервью (много разговоров, мало решений) или в тормоз (бесконечное “надо ещё узнать”). Поэтому вопрос “точно ли нужен CustDev?” правильный — особенно если вы хотите действовать быстро.

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

1) CustDev — это не “интервью”. Это проверка гипотез с минимальной стоимостью ошибки

Когда говорят “делать CustDev”, часто подразумевают “поговорить с пользователями”. Но разговор — лишь метод. Суть CustDev — в другом:

• у вас есть гипотеза о проблеме / сегменте / ценности / канале / цене;
• вы выбираете самый дешёвый способ проверить, что это правда;
• вы фиксируете критерий: что будет считаться подтверждением/опровержением;
• вы принимаете решение (продолжать, менять, прекращать).

Если после CustDev вы не меняете решение, значит вы:

• спрашивали не то,
• фиксировали не то,
• или подсознательно искали подтверждение.

2) Быстрый “тест необходимости”: 7 вопросов, после которых всё становится проще

Отвечайте честно “да/нет”. Если 3+ “да” — CustDev нужен почти наверняка.

1. Вы делаете продукт для аудитории, которую сами не представляете (другая профессия, другой доход, другой контекст).
2. Вы меняете сегмент (SMB → enterprise, B2C → B2B, локально → глобально).
3. Вы меняете ценностное предложение (новая категория, новая “работа пользователя”).
4. Есть риск, что проблема не болит (nice-to-have вместо must-have).
5. Есть риск, что решение не встроится в привычки (сложно, долго, требует перестройки процесса).
6. Есть риск неправильной монетизации (непонятно кто платит, за что, как проходит покупка).
7. Цена ошибки высокая (дорогая разработка, долгий цикл, брендовые риски, команда маленькая).

Если 0–1 “да”, можно идти минимальным форматом или даже сознательно пропустить (ниже — когда это разумно).

3) Сценарии, где CustDev почти обязателен

3.1. Новый продукт / новая категория

Если вы ещё не знаете:

• кто ваш “первый настоящий” сегмент,

• какая боль самая дорогая,

• какие альтернативы сейчас используют,

  то без CustDev вы часто строите продукт на фантазии.

3.2. Низкий retention при нормальном acquisition

Когда люди приходят, пробуют и уходят — проблема редко в “ещё одной фиче”. Обычно это:

• обещание не совпадает с реальностью,
• люди не доходят до ценности,
• ценность одноразовая,
• продукт не подходит сегменту.

Здесь CustDev нужен, потому что графики показывают “что”, а разговоры и наблюдения помогают понять “почему”.

3.3. B2B и сложная покупка

В B2B легко ошибиться в трёх точках:

• пользователь ≠ заказчик ≠ плательщик,
• решение принимается не логикой продукта, а политикой/рисками,
• внедрение важнее интерфейса.

Без CustDev вы можете сделать “идеальный UI” и проиграть из-за безопасности, процессов закупки, интеграций и ролей.

3.4. Сильные разногласия внутри команды

Если спор выглядит так:

• “пользователи хотят X”

• “нет, хотят Y”

• “нет, им вообще другое важно”

  — CustDev нужен как способ заменить спор мнениями на спор фактами.

3.5. Монетизация: цена, упаковка, paywall

Ошибки в монетизации часто не видны до поздней стадии. CustDev помогает понять:

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

4) Сценарии, где CustDev можно сократить до минимума (и это нормально)

4.1. Улучшение понятных частей продукта

Если вы делаете:

• ускорение,

• исправление ошибок,

• улучшение UX в явном узком месте,

• упрощение известного сценария,

  то часто достаточно:

• продуктовой аналитики,

• записей сессий,

• саппорт-тикетов,

• 2–3 быстрых юзабилити-проверок.

Полный цикл CustDev тут избыточен.

4.2. Рынок зрелый, а ваш продукт — “ещё один”

Когда категория стандартизирована, а дифференциация небольшая (например, типовой инструмент с понятными ожиданиями), можно:

• быстрее запускаться,
• больше полагаться на бенчмарки и конкурентный анализ,
• проверять через A/B и метрики.

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

4.3. Внутренний продукт для своей компании

Если вы делаете внутренний инструмент и у вас:

• доступ к пользователям постоянный,

• быстрый цикл обратной связи,

• чёткие бизнес-процессы,

  то CustDev превращается в “постоянные уточнения” и наблюдения. Формально это тоже CustDev, но без сложных ритуалов.

5) Когда CustDev может навредить (да, такое бывает)

5.1. CustDev становится оправданием бездействия

Симптом: “нужно ещё 20 интервью”, но:

• гипотезы не формулируются,
• критерии успеха не записаны,
• решения не принимаются.

В таком режиме CustDev — не исследование, а отсрочка ответственности.

5.2. Вы разговариваете не с теми людьми

Классика: интервьюируют “всех понемногу” и получают среднюю кашу.

CustDev работает, когда вы осознанно выбираете:

• самый болючий сегмент,
• самых активных/платящих,
• людей с недавним опытом проблемы.

5.3. Интервью превращаются в питч

Люди говорят “классно”, потому что вы подсознательно просите одобрения.

Тогда CustDev даёт ложную уверенность, которая хуже неопределённости.

5.4. Команда собирает “хотелки” вместо понимания проблемы

Список “добавьте кнопку” почти никогда не равен истине. Пользователь предлагает вам свою “внутреннюю заплатку”, а ваша задача — понять:

• что он пытался сделать,
• почему это важно,
• почему текущие способы не подходят,
• что будет считаться успехом.

6) Альтернативы CustDev, когда нужно быстро, а данных мало

CustDev — не единственная форма узнавания правды. Иногда быстрее и точнее работают другие каналы:

6.1. Аналитика поведения (если продукт уже живой)

• воронки,
• когорты,
• “путь до ценности”,
• сегментация по удержанию.

Это часто быстрее, чем разговоры, но хуже отвечает на “почему”.

6.2. Саппорт и продажи как источник сигналов

• тикеты показывают повторяющиеся боли,
• продажи слышат возражения и критерии покупки,
• customer success видит, где продукт “не доезжает”.

Важно: превращать это в гипотезы, а не в “кто громче пожаловался”.

6.3. Fake door и прототип-тесты

Если вопрос: “нужно ли это вообще?”, часто быстрее:

• показать кнопку/экран,
• измерить клики и конверсию,
• собрать причины “почему да/почему нет”.

6.4. Concierge / ручной сервис

Для B2B или сложных сценариев иногда самый честный тест:

• “мы делаем ценность руками/полуруками”,
• смотрим, готовы ли платить/возвращаться,
• только потом автоматизируем.

7) “Мини-CustDev”: формат, который почти всегда оправдан

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

7.1. 5 интервью за 5 дней

Цель — не “узнать всё”, а снять один ключевой риск:

• боль реальная?
• она частая?
• сейчас как решают?
• сколько стоит проблема?
• что мешает переключиться?

7.2. Одностраничник гипотез

Заполняется до интервью:

• Сегмент:
• Ситуация/триггер:
• Текущий способ:
• Цена проблемы:
• Что должно быть правдой, чтобы купили/пользовались:
• Самая рискованная часть:
• Как поймём, что подтвердили:

7.3. Решение в конце недели

В конце недели обязателен один из вариантов:

• продолжаем и сужаем сегмент,
• меняем ценность/сценарий,
• закрываем гипотезу,
• делаем прототип-проверку.

Если решения нет — это был не CustDev, а разговоры.

8) Что именно стоит проверять через CustDev (и что не стоит)

Через CustDev отлично проверяются:

• “болит ли проблема и как именно”
• как выглядит текущий процесс (workflow)
• альтернативы и “конкуренты привычки”
• контекст принятия решения (особенно B2B)
• причины отказа, риски, барьеры внедрения
• язык пользователя (как он описывает задачу)

Через CustDev плохо проверяются:

• “понравится ли ваша фича”
• точная цена “сколько заплатите” в вакууме
• прогнозы поведения без контекста (“будете пользоваться каждый день?”)

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

9) Как понять, что CustDev приносит пользу (признаки “работает”)

Сильный CustDev меняет решения. Прямые маркеры:

1. Вы начали резать инициативы, которые раньше казались “очевидными”.
2. Roadmap стал короче, но эффект сильнее.
3. Появились чёткие сегменты: “для кого сейчас”, “для кого позже”, “не для нас”.
4. Появился язык пользователя в лендингах, онбординге, скриптах продаж.
5. Улучшилась связка acquisition → activation → retention, потому что вы оптимизируете не клики, а реальную ценность.
6. Команда меньше спорит мнениями, больше опирается на наблюдения и данные.

Если после CustDev стало больше “вариантов всего на свете”, но не стало больше ясности — процесс настроен плохо.

10) Проблема времени: “у нас нет ресурсов на CustDev”

Часто это правда — но обычно не в том смысле, что “нет времени поговорить”. Обычно проблема в том, что:

• нет стабильного рекрутинга,
• нет привычки записывать гипотезы,
• нет дисциплины принимать решение,
• нет владельца процесса.

Практичный способ встроить CustDev без расширения штата

• 2 интервью в неделю как норма (это 2–3 часа)
• 15 минут синтеза после каждого интервью (3 факта + 1 гипотеза)
• еженедельный слот “решение по гипотезам” (30 минут)

Так вы получаете постоянную связь с рынком без “исследовательского проекта на квартал”.

11) CustDev и скорость: как не потерять темп разработки

У многих страх: “если делать CustDev, мы станем медленными”. Это происходит, когда CustDev поставлен как “фаза до разработки”. Рабочая модель — другая:

• часть команды ведёт discovery параллельно delivery,
• гипотезы формулируются на 1–2 шага вперёд,
• часть проверок делается прототипами, fake door, ручными сценариями.

Тогда CustDev не замедляет, а ускоряет: вы реже строите лишнее.

12) Готовые структуры, которые снимают 80% типовых ошибок

12.1. Структура разговора (30–40 минут)

1. Последний реальный случай: “когда в последний раз вы делали X?”
2. Процесс: “какие шаги, какие инструменты, где сложно?”
3. Цена: “во что это обходится — время/деньги/риск?”
4. Альтернативы: “почему так, что пробовали раньше?”
5. Решение: “что должно быть правдой, чтобы вы сменили способ?”
6. Следующий шаг: “можно вернуться с прототипом/вариантом?”

12.2. Таблица синтеза (после 5–10 интервью)

Колонки:

• сегмент / роль
• триггер ситуации
• текущий способ
• барьер
• цена проблемы
• цитата “их словами”
• сигнал готовности (готов ли на следующий шаг)

13) Самый честный ответ на “точно ли нужен CustDev?”

CustDev нужен не всем и не всегда, но он почти всегда оправдан, когда:

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

Если ситуация простая, изменения маленькие, есть хорошая аналитика и быстрый цикл обратной связи — можно ограничиться мини-форматом и инструментами поведения (воронки, когорты, A/B).

Чтобы не спорить “нужен / не нужен”, полезнее спрашивать иначе:

какой самый дорогой риск сейчас у продукта — и какой самый дешёвый способ его проверить?