259. Два подхода к созданию гайда для customer interview

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

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

От вопроса к решению
Начинается с вопросов, которые помогают понять проблему, работу, контекст, сегмент. Например: «Как вы сегодня решаете эту проблему?» или «Расскажите про этапы вашего процесса».
Из ответов выясняется, как проблема решается сейчас, каким образом потребитель мыслит, где в JTBD-процессе может вписаться продукт, кто конкуренты решения.
И только после определяем, что делать с продуктом на основе собранной информации.
Такой подход подходит на ранних этапах, когда нужно понять проблему, работу клиента, контекст использования — то, что предшествует формулировке гипотез о продукте. Интервью становится инструментом исследования и открытия.

В первом случае мы движемся от известного решения к неизвестной информации.
Во втором — от открытых вопросов к неизвестному решению.

Первый подход фокусирован на валидации, второй — на исследовании.

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

В сухом остатке: два подхода к созданию гайда — от решения к вопросам (когда есть конкретная гипотеза или действие) и от вопроса к решению (когда нужно исследовать проблему и контекст); первый для валидации, второй для открытия.

#customerinterview@custdevlab #методика@custdevlab #гайд@custdevlab

260. Что такое MVP и как его использовать в CDDC

MVP — минимально жизнеспособный продукт. Часто MVP понимают неправильно, и это приводит к ошибкам.

Что не является MVP: последовательная сборка частей продукта. Сначала делаем колесо, потом шасси, потом кузов, и только в конце получается автомобиль. До финальной сборки ни одна часть не функциональна сама по себе — колесо не ездит, шасси не перевозит. Это не MVP, потому что на каждом этапе продукт не доставляет ценность пользователю. Пользователь не может использовать части продукта для решения своей задачи.

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

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

MVP должен быть функциональным и доставлять ценность с самого начала, а не собираться по частям или заменяться другими продуктами. Каждая итерация MVP — это минимальная, но полная версия продукта, которая решает задачу пользователя и позволяет собирать данные для следующих итераций. В CDDC MVP используется при переходе от Discovery к Validation.

В сухом остатке: MVP — это не части продукта и не разные продукты, а итерации одного функционального продукта, который доставляет ценность с первого этапа; каждая версия MVP должна быть полной и рабочей, просто минимальной.

#mvp@custdevlab #гипотезы@custdevlab #полезное@custdevlab

Оригинальное изображение: Fred Voorhorst

Собрали для удобства в одном посте всё про customer interview и как задавать вопросы:

С чего начать:
1. С чего начать custdev (решенческий custdev)
2. Главные вопросы проблемного интервью (проблемный custdev)
3. Самый полезный вопрос во время custdev
4. Custdev-интервью: проблемное и решенческое
5. С чего начать custdev: цель
6. Где взять гипотезу для первого custdev-интервью
7. Зачем нужны гипотезы для исследования и можно ли обойтись без них

Почему опрос не интервью:
8. Опросы и custdev. Часть 1 и Часть 2

Что спрашивать — перечень вопросов:
9. С чего начать, если нет продукта и клиентов. Проблемные вопросы для customer interview
10. С чего начать, если есть продукт и клиенты. Решенческие вопросы для customer interview
11. Custdev-интервью: спросите об идеальном продукте
12. Custdev-интервью: спросите о самом ужасном продукте
13. Вопросы про цену продукта
14. Проблема идеального продукта по мнению пользователей — важен образ мысли, а не сам ответ
15. Как узнать значимость проблемы для клиента — шкала для определения значимости
16. Привычное потребление и разные модели — частотность и формулировка вопросов

Как спрашивать:
17. Customer interview: открытые вопросы
18. Правило «Пять почему»
19. Спрашиваем про прошлое, а не про будущее
20. Два проверочных вопроса интервью: «получил ли я ответ?», «что я смогу сделать со своим продуктом?»
21. Прайминг: как получить нужный ответ респондента
22. Техника «отражение» в интервью
23. Факты, а не домыслы

Гайд для интервью:
24. Рекомендации по вопросам для customer interview — 10 принципов, чек-лист для гайда
25. Модель принятия решения о покупке как основа для гайда customer interview
26. Два подхода к созданию гайда для интервью
27. Ошибка: составить слишком большой и подробный гайд

Шкалы оценок в интервью:
28. Шкалы оценок в customer interview: часть 1 и часть 2

Как проводить: глубина, мессенджеры, запись:
29. Можно ли проводить custdev через мессенджеры
30. Нужно ли разбираться в тематике исследования, когда идешь на первые интервью
31. Customer Interview: насколько глубоко нужно копать
32. Customer Interview: форма для записи результатов
33. Как, сколько и кто — как проводили исследование

Ошибки при проведении customer interview:
34. «Впарить» проблему респонденту, если её нет
35. Слишком долго обсуждать социально-демографические вопросы
36. Составить слишком большой и подробный гайд
37. Лучше не проводить custdev, чем проводить его для галочки
38. Не нужно сужать аудиторию при проблемном интервью

С кем разговаривать и кого опрашивать:
39. С кем разговаривать в первую очередь
40. Где быстро найти людей для custdev
41. Анкета для отбора респондентов для customer interview
42. Мета-критерии сегментирования для интервью: способность рассказать о себе
43. Минимальное количество респондентов в customer interview
44. Разговариваем про человека, а не про продукт
45. Лучше разговаривать с тем, кого не знаешь

#подборка@custdevlab #интервью@custdevlab #методика@custdevlab #какзадаватьвопросы@custdevlab

261. Разные масштабы опыта

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

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

Опыт жизненных сценариев — чуть уже. В продукте по‑прежнему экосистема, но уже через сценарии: как человек решает типичные задачи, как выбирает между альтернативами в категории, что для него триггер, что — барьер. Именно этот масштаб описывает LXM (Life Experience Map): карта жизненного пути потенциальных клиентов, поведение в товарной категории, выбор между продуктами — без привязки к одному решению.

Клиентский опыт (CX) — масштаб, которому в продукте соответствует продукт как целое. Человек уже взаимодействует с решением: путь от первого контакта до использования, повторных покупок, ухода. CJM обычно строится на этом уровне.

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

Опыт в точке контакта (UI) — самый узкий масштаб. В продукте ему соответствует интерфейс: конкретный экран, кнопка, форма. Как человек с ними взаимодействует — что видит, куда нажимает, где ошибается.

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

Если улучшаем путь внутри уже выбранного продукта — работаем с продуктом, CX и CJM. Если оптимизируем сценарий или экран — работаем со сценарием и интерфейсом, UX и UI.

LXM как раз про верхние матрёшки: жизненный опыт и опыт жизненных сценариев. Остальные уровни вложены внутрь; им в продукте соответствуют продукт, сценарий, интерфейс.

В сухом остатке: опыт пользователя имеет разные масштабы, и каждому в продуктовом управлении соответствует свой объект работы — экосистема, продукт, сценарий, интерфейс. LXM работает на уровне жизненных сценариев (экосистема); понимание масштаба помогает выбирать инструменты и фокус в продукте.

#lxm@custdevlab #cjm@custdevlab #опыт@custdevlab #полезное@custdevlab

262. Фильтры и боязнь потерять содержание

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

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

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

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

Как быть с бесконечной полкой на маркетплейсах? Там априори невозможно увидеть всё: каталог огромен, ассортимент пополняется. «Показать всё» не сработает. В таком случае «всё» — это не каждый товар, а структура предложения: категории, типы, границы каталога. Задача — дать пользователю карту пространства выбора.

Он не просмотрим все позиции, но поймет, что есть, где искать, какие бывают варианты. Сначала — обзор структуры (категории, подкатегории, «что бывает»), потом сужение внутри уже понятного пространства. Фильтры тогда не отрезают неизвестный кусок, а помогают двигаться по карте, которую пользователь уже в общих чертах видел.

В сухом остатке: чем больше предварительных фильтров, тем сильнее боязнь потерять содержание. Лучше сначала показывать всё, что есть (или структуру каталога, если «всё» невозможно), затем давать сужать выбор — так пользователь опирается на обзор или на карту пространства, а не на неизвестный «отфильтрованный» кусок.

#ux@custdevlab #выбор@custdevlab #полезное@custdevlab

263. Зачем нужен элемент «информация» в гайде для customer interview

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

Промежуточный элемент — это явное указание: какую информацию собирают на этом участке гайда. Не только «о чём спрашивают», а «что в итоге должно оказаться среди записей». Например: «как человек сегодня решает задачу», «какие альтернативы рассматривает», «что для него триггер перехода к действию», «какие возражения останавливают». Это формулируют до интервью и держат в голове (или в гайде) во время разговора. Получается череда шагов: сначала собирается информация А, потом — Б, и только затем выходят к проблеме продукта или к решению, которое нужно валидировать.

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

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

#customerinterview@custdevlab #методика@custdevlab #гайд@custdevlab

264. Офбординг — наиболее недооцененный этап LXM

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

Офбординг одного продукта — точка, после которой человек оказывается «на рынке» снова и может в следующий раз выбрать другой продукт или вернуться к тому же. Иногда товарами-конкурентами пользуются параллельно: использование одного продукта не исключает использование другого (как в случае онлайн-кинотеатров — выбор контента в одном сервисе, просмотр в другом). В этом случае удобный офбординг одного продукта может в долгосрочной перспективе быть конкурентным преимуществом (если причина была не в низкой удовлетворенности).

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

Здесь возникает trade-off. Более простой офбординг — лёгкий выход из продукта — приводит к тому, что людям проще отказаться от продукта. Удержание и LTV могут снизиться: часть пользователей уйдёт быстрее, чем при запутанном процессе отписки или отмены. Многие сервисы делают наоборот: усложняют офбординг именно ради экономических показателей. Но если офбординг упростить, опыт пользователя в конце пути становится более положительным. Человек запоминает, что продуктом было просто пользоваться и просто из него выйти — низкие усилия, низкий CES.

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

В сухом остатке: офбординг — последний этап LXM, после него человек возвращается к началу цикла в товарной категории; более простой офбординг может снизить LTV и удержание, но улучшает последнее впечатление и запоминание продукта как простого (связь с CES и правилом последнего впечатления).

#lxm@custdevlab #офбординг@custdevlab #опыт@custdevlab #полезное@custdevlab

#юмор@custdevlab #мем@custdevlab

265. Офбординг: скидка как последняя попытка удержать клиента

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

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

По правилу последнего впечатления именно этот опыт сильно влияет на общую оценку: продукт запоминается как тот, из которого сложно уйти без уговоров и спецпредложений. Доверие к «честной» цене падает: раз при отписке дают 80%, значит обычная цена завышена, а раньше переплачивал.

Если пользователь остаётся из-за скидки, он остаётся не потому, что продукт для него ценен по полной цене, а потому, что его «купили» скидкой. Лояльность к продукту не растёт, растёт привычка: в следующий раз снова нажмёт «отписаться», ожидая новое предложение. Офбординг не завершился — он отложился, и цикл «попытка уйти → скидка → остался» может повторяться. Для метрик это временный выигрыш по удержанию; для опыта — последнее взаимодействие было не про уважение к решению пользователя, а про удержание любой ценой.

В сухом остатке: скидка при попытке отписаться (вплоть до 80%) может поддержать удержание и LTV, но последний контакт с продуктом становится переговорами, а не простым выходом; пользователь запоминает не лёгкий офбординг, а уговоры и сомнения в честности цены; если остаётся — из-за скидки, а не из-за ценности продукта.

#офбординг@custdevlab #опыт@custdevlab #полезное@custdevlab #lxm@custdevlab

266. Продакт-менеджмент в 2025: 4 инсайта для custdev

Команда ProductSense совместно с X5 провела ежегодное исследование продактов: выборка составила 1 220 респондентов, период сбора данных — октябрь-ноябрь 2025. В этом посте — четыре основных вывода, которые важны с точки зрения custdev и понимания пользователя в 2026 году.

1. Классика никуда не делась — её адаптируют
В блоке про перспективы профессии явно сказано: традиционные подходы — Jobs to Be Done, customer development, North Star Metric, RICE, user stories и др. — по-прежнему остаются рабочими инструментами. Их чаще не отбрасывают, а адаптируют под контекст и современные условия. На фоне хайпа вокруг ИИ это важный сигнал: базовые методологии про понимание пользователя остаются в ядре практики.

2. Разрыв между «важно» и «во что реально вкладываются»
Навыки исследований, управленческие и коммуникативные навыки, мета-навыки (критическое мышление, решение проблем) стабильно входят в топ того, что считают важным при найме. Но в 2025 их заметно реже выбирали фокусом развития. Custdev и пользовательские исследования попадают в эту зону: все подтверждают, что это критично, но в планах обучения совсем другие задачи — ИИ, аналитика, проектное управление.

3. ИИ экономит время, но не заменяет понимание пользователя
ИИ в работе используют почти все; 72% говорят об экономии времени (до двух часов в день и больше), но лишь около 20% видят заметный эффект на результаты продукта или бизнеса. Личная эффективность выросла — продуктовый эффект не автоматически. Без целенаправленной работы по пониманию пользователя (custdev, исследования, проверка гипотез) LLM сам по себе не даёт роста retention или выручки.

4. Глубокие инсайты — не из Google и не из LLM
В разделе «Главный урок года» один из частых мотивов: «Сколько ни исследуй рынок удалённо/через гугл/AI, пока ты в него не погрузишься сам с головой, глубокие инсайты ты не найдешь». Это почти дословная формулировка смысла custdev: данные и ИИ сужают поле, но «мясо» понимания контекста появляется только когда продакт выходит из дашбордов к живому опыту пользователей.

В сухом остатке: исследование ProductSense показывает, что сообщество по-прежнему опирается на JTBD и customer development, но мало инвестирует время в развитие исследовательских и коммуникативных навыков, а ИИ чаще даёт личную скорость, чем продуктовый результат; если цель — не просто «делать больше задач», а лучше решать работы пользователя, ставка по-прежнему на custdev, глубинные интервью и осознанное погружение в контекст.

#custdev@custdevlab #исследования@custdevlab #методика@custdevlab #полезное@custdevlab

267. Гипотезы и уточняющие вопросы

Есть гипотеза, которую нужно проверить в интервью: например, что для сегмента важен атрибут X — цена, скорость доставки, возможность отменить подписку.

Ошибка — спрашивать про гипотезу в лоб: «Для Вас важна цена?» или «Влияет ли на выбор возможность простой оплаты?». Респондент получает подсказку: исследователь уже назвал атрибут. Ответ «да» не значит, что человек сам бы это назвал; он мог согласиться, потому что вопрос навёл на мысль. Получаются не факты с рынка, а отражение гипотезы исследователя.

Правильный порядок в интервью в этом случае, это начать издалека (а еще лучше с самого начала, в соответствии с LXM-моделью).

Задаем открытые вопросы:
«Что для вас важно при выборе продукта...»
«Как вы обычно принимаете решение о покупке...»
«Расскажите про последний раз, когда выбирали продукт»

Респондент рассказывает сам, без подсказок. Если атрибут X для него действительно значим, он назовёт его своими словами — тогда гипотеза подтверждается фактом из его опыта, а не согласием с формулировкой исследователя.

Если респондент не упомянул нужный атрибут — только тогда задаем уточняющий вопрос:
«Вы не назвали [цену / возможность отписаться / что-то ещё]. В вашей ситуации цена играет роль?»

Так проверяется принцип забыл упомянуть или атрибут для не важен. Ответ «да, важно» при уточнении слабее, чем самостоятельное упоминание в открытом ответе, но хотя бы не навязываем атрибут первым. Ответ «нет, не задумывался» или «не принципиально» — сигнал, что гипотеза для этого респондента не подтверждается.

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

#customerinterview@custdevlab #методика@custdevlab #гипотезы@custdevlab #полезное@custdevlab

268. Усталость пользователя от продукта и управление усталостью

Даже если продукт хороший и полностью соответствует требованиям потребителя — или, по Бобу Моэсте, пользователь выбрал его как наименее худший из доступных вариантов, — это не гарантирует долгую лояльность. Без изменений в продукте пользователи со временем начинают от него уставать.

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

В исследованиях потребительского поведения это описывают несколько механизмов.

Гедоническая адаптация (hedonic adaptation): повторный контакт с одним и тем же продуктом или опытом снижает интенсивность удовольствия — люди привыкают к хорошему.

Стремление к разнообразию (variety-seeking): потребители намеренно меняют продукты, бренды или атрибуты выбора, чтобы избежать «насыщения» от одного варианта и сохранить ощущение новизны.

Насыщение атрибутами (attribute satiation): повторное потребление одних и тех же характеристик продукта создаёт пресыщение; хочется другого сочетания свойств, другого опыта. В сумме даже «наименее худший» продукт без обновлений проигрывает не столько по качеству, сколько по ощущению однообразия.

Управление усталостью от продукта — это работа над тем, чтобы продукт не воспринимался как «всё время одно и то же». Варианты: обновление контента или функционала, персонализация, переменная награда (как в модели Hook: непредсказуемость подкрепления поддерживает интерес), добавление новых сценариев использования, периодическое обновление интерфейса или формата взаимодействия. Цель — не только повысить или удержать метрики retention, но и снизить гедонический спад: чтобы пользователь не уставал от продукта быстрее, чем от альтернатив.

Если конкуренты при этом тоже не меняются, относительная позиция продукта сохраняется; если конкуренты обновляются, а наш продукт — нет, накопленная усталость подталкивает к переключению.

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

#jtbd@custdevlab #опыт@custdevlab #retention@custdevlab #полезное@custdevlab

269. B2B: руководитель не признает некомпетентность — как выяснить настоящее отношение респондента

На рынках B2B руководитель редко признается в своей некомпетентности. Если продукт направлен на устранение недостатков руководителя — например, на слабые навыки планирования, делегирования, контроля — руководитель не скажет: «да, у меня с этим проблемы». Признать это значит поставить под удар свой статус и образ эксперта.

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

Вместо «Вам сложно с планированием?» — «Как у вас сейчас устроено планирование? Кто за это отвечает? Что происходит, когда сроки срываются?»

Вместо «Вы достаточно делегируете?» — «Расскажите про последний проект, где нужно было распределить задачи. Как вы это делали? Что пошло не так?»

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

Если продукт как раз закрывает такой барьер — не следует продавать его как «решение вашей некомпетентности», а как решение типичной задачи или типичной проблемы процесса. Так снижается защитная реакция, и легче услышать, как человек на самом деле относится к задаче и к продукту.

В сухом остатке: на B2B руководители не признают собственные недостатки; чтобы выяснить настоящее отношение, спрашиваем не про них самих, а про процесс, прошлые ситуации и «как обычно»; если одного ракурса недостаточно — усиление аргументации.

#b2b@custdevlab #customerinterview@custdevlab #методика@custdevlab

270. B2B: усиление аргументации при некомпетентности

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

Несколько источников. Разговаривать не только с руководителем, но с теми, кто участвует в процессе — подчинёнными, коллегами, при необходимости с его руководством. Далее сравниваем версии: как он описывает процесс и результат и как описывают другие. Расхождения — сигнал о том, что что-то не так.

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

Артефакты. Что было произведено — документы, отчёты, выводы. Описание «как было» сверять с тем, что реально есть на выходе.

Детализация конкретного кейса. Просить разобрать один случай по шагам — кто что делал, когда, что произошло дальше. В подробностях неискренность или пустоты чаще заметны.

В сумме один источник и один ракурс недостаточны; нужна триангуляция и опора на факты, которые труднее подогнать под желаемую картину.

В сухом остатке: при вопросах о процессе некомпетентный респондент может искажать описание. Усиление аргументации — несколько источников (триангуляция), результаты и проверяемые факты, артефакты, детализация конкретного кейса.

#b2b@custdevlab #customerinterview@custdevlab #методика@custdevlab #полезное@custdevlab

271. Если респондент не сказал — значит не нужно?

Если во время интервью пользователь не сказал об ожидании от продукта, значит ли это, что ему это не нужно? Не обязательно. Часть ожиданий настолько базовые, что их не называют — они воспринимаются как само собой разумеющееся и обязательное условие. Отсутствие в ответе не равно отсутствию важности.

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

Поэтому при уточняющих вопросах про атрибуты, которые респондент не назвал сам, важно различать: забыл упомянуть, не считает важным или считает настолько очевидным, что не стал говорить. Вопрос «вы не назвали [X]. В вашей ситуации это играет роль?» может дать ответ «да, конечно, я просто не подумал, что это надо озвучивать» — тогда атрибут не «неважный», а «табличные ставки» (table stakes): без него продукт не принимают в расчёт. Вывод «не сказал — не нужно» в таком случае ошибочен.

Дополнительно помогают вопросы про идеальный продукт и про самый отвратительный (ужасный) продукт. «Опишите идеальный для вас продукт в этой категории» — респондент называет важные для себя функции и комбинирует ожидания; то, что он включит в «идеал», может быть и базовым требованием, которое в открытых вопросах не озвучил. «Опишите самый ужасный продукт» — респондент называет болевые точки и то, чего ни в коем случае быть не должно; это тоже ожидания, часто как раз «обязательные по умолчанию» (например, «чтобы не обманывали», «чтобы не падало»). Оба вопроса помогают вытащить ожидания, которые в свободном ответе не прозвучали.

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

#customerinterview@custdevlab #методика@custdevlab #полезное@custdevlab

272. Кейс ABBYY: технология против AI

В 1989 году студент четвертого курса МФТИ Давид Ян готовился к зачёту по французскому и подумал: нужен удобный электронный словарь. Вместе с другом-программистом Александром Москалёвым за лето написали словарь и начали продавать по 100 рублей за копию (план 100 копий). Потом объединили сканер и переводчик — вставил лист с текстом, получил распознанный и переведённый результат — продажи выросли в разы. Так появилась компания BIT Software (а с 1997 года — ABBYY), и неё основные продукты — FineReader (распознавание текста) и Lingvo (словари). Миллионы людей годами сканировали документы и смотрели перевод в Lingvo; ABBYY была лидером на рынках OCR (технология распознания текста) и электронных словарей, её технологии лицензировали Fujitsu, Samsung, Xerox.

Со временем, уже в 2020-ых, те же задачи — распознать текст, перевести, извлечь данные из документа — стали решать технологии на базе ИИ и нейросетей: быстрее, дешевле, часто точнее, прямо в облаке и в каждом телефоне.

Один и тот же результат пользователь получал разными технологиями: через OCR от ABBYY или аналогичными от AI-продуктов. Для него не так важно, как именно это сделано технологически, важны критерии получения результата: скорость, цена, удобство. Если другой способ даёт тот же или лучший результат при меньших затратах времени и денег, выбор смещается. Людям для достижения своих целей чаще всего не хватает времени и денег; продукт, который экономит и то и другое при том же результате, выигрывает, а что под капотом — не так важно.

Рынок, на котором работала ABBYY, изменился глобально. Нейронный машинный перевод и бесплатные облачные переводчики отчасти заменили словарные продукты вроде Lingvo. Задачи OCR стали решать облачные сервисы, сейчас они встроены в экосистемы крупных AI-продуктов, относительно дёшевы, а развитие deep learning резко повысило точность.

В сухом остатке: Один и тот же результат можно получить разными технологиями; для пользователя технология не так важна, как критерии результата: скорость, цена и т.п.; технология внутри продукта должна развиваться — иначе лидерство уходит.

#кейс@custdevlab #технологии@custdevlab #полезное@custdevlab

273. Товарные категории изменяются со временем: как будили раньше

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

До электричества режим сна жёстко зависел от светового дня. Стемнело — пора спать, рассвело — пора вставать. Время измеряли по солнцу, поэтому изначально использовали неравные часы (temporal hours) — день и ночь делили на 12 интервалов каждый, но длина часа летом была длиннее, а зимой — короче. Распорядок жизни был привязан к свету, а не к абстрактным 60 минутам.

Электрическое освещение изменило правила. Появилась возможность продлевать световой день — можно было работать, читать, делать любые дела после заката. Режим сна усложнился: люди стали ложиться позже, спать меньше (исследования показывают, что при доступе к электрическому свету сон сокращается на 40–50 минут в сутки). Возникла потребность просыпаться в строго заданное время — не «когда рассветёт», а «когда начинается смена».

Решение работы «проснуться в определенное время» претерпевала сильные изменения:

1. Церковные колокола. В Средневековье колокола звонили несколько раз в день — по каноническим часам (от утрени на рассвете до повечерия ночью). Утренний звон (Matins) на рассвете по сути будил тех, кто жил рядом. Прямая цель — призвать к молитве, а не разбудить, но эффект был тот же.

2. Будильщики (knocker-uppers). В XIX веке в Великобритании и ряде других стран появилась такая профессия: человек за плату обходил дома и будил клиентов. Стучал длинной палкой в окна, использовал рогатки с горохом, постукивал в двери.

3. Механические будильники. Первый механический будильник изготовил американец Леви Хатчинс в 1787 году — он звонил только в 4 утра, время изменить было нельзя. Со временем будильники становились дешевле. Это и вытеснило будильщиков.

4. Радиобудильники. В 1940‑х годах появились устройства, совмещающие радиоприёмник и будильник. В 1968 году Sony выпустила Dream Machine. Радио к тому времени уже вещало круглосуточно: можно было проснуться под музыку или новости, а не только под звонок.

5. Смартфоны и умные колонки. Сегодня ту же «работу» часто выполняет телефон или умная колонка — будильник, подкасты, музыка, голосовой помощник включаются в определенное время. Категория «будильник» слилась с категорией «устройство для воспроизведения контента и управления умным домом».

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

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

#рынок@custdevlab #интересное@custdevlab #модельповедения@custdevlab

274. На каком рынке я работаю. Дополнения спустя 4 года

В посте про главный вопрос стартапа мы писали: спросить покупателя «Между чем еще Вы выбирали, прежде чем остановить выбор на нашем товаре?» — способ определить рынок и конкурентное окружение.

Но формулировка «между чем и чем ты выбираешь, прежде чем купить у меня» — не единственный и не всегда достаточный вопрос. Ответ зависит от ситуации. В одном контексте человек сравнивает конкретные продукты. В другом — способы решения проблемы (пойти в кино vs смотреть дома vs почитать книгу). В третьем — вообще не осознаёт альтернатив или выбирает «ничего не делать».

По сути мы разделяем пользователей по отношению к альтернативам при решении проблемы. У кого-то узкий набор выбора (consideration set): несколько брендов или решений, между которыми он реально выбирает. У кого-то продукт вообще не попадает в набор рассмотрения — человек решает задачу иначе или не решает её вовсе. Отсюда — разные сегменты: те, для кого мы конкурируем с X, те, для кого — с Y, и те, для кого мы «не в наборе рассмотрения».

Поэтому вопрос про рынок может раскрываться через несколько в зависимости от контекста, типа продукта и этапа пути клиента:
— «Как вы обычно решаете эту задачу?»
— «Что ещё рассматривали в этот раз?»
— «Были ли другие варианты, от которых отказались?»
— «Почему выбрали именно это?» 

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

В сухом остатке: вопрос «между чем выбираете» — отправная точка; рынок определяется набором альтернатив в голове потребителя; этот набор зависит от ситуации и сегмента; иногда нужна цепочка вопросов, чтобы понять, с чем мы конкурируем и для кого вообще попадаем в набор рассмотрения (consideration set).

#рынок@custdevlab #сегментация@custdevlab

Собрали для удобства в одном посте всё про целевую аудиторию и сегментацию:

Основа: не бывает ЦА «все»:
1. Ловушка основателя «Чесалка для спины» — не бывает целевой аудитории «все»; все — значит никто
2. Онлайн-школа математики: валидация сегментов — продукт «все для всех» на деле означает «ни для кого»

Целевая аудитория: две размерности: 
3. Целевая аудитория и целевая аудитория — та, которую хотим (JTBD, ситуация, триггер), и та, до которой можем дотянуться через рекламу (пол, возраст, интересы); разрыв увеличивает CAC

Валидация и выбор сегментов: 
4. Custdev и проверка целевых аудиторий 
5. Ситуация — проблема — решение — сегментация в отрыве от этой схемы не работает
6. Сервис florm.io: выбор ниши и значимость решаемой проблемы — узкий сегмент для старта и customer validation
7. Битком 24: ошибка в определении ЦА — ЦА по данным vs фактическое ядро; customer validation неотъемлема
8. Custdev-чатбот: автоматизируем валидацию клиентских сегментов 
9. Подписка на цветы: ищем новую целевую аудиторию

С кем проводить custdev и где искать: 
10. С кем разговаривать в первую очередь 
11. Три основных сегмента, с кем следует проводить custdev 
12. Где найти представителей трёх основных сегментов 
13. Где быстро найти людей для custdev 
14. Мета-критерии сегментирования для интервью: способность рассказать о себе 
15. Минимальное количество респондентов в customer interview

Оценка потенциала и доступности: 
16. Правильный бенчмарк в custdev — ориентироваться на потребности целевых сегментов
17. Три главных критерия экспресс-оценки потенциала продукта — размер сегмента, сложность доступа, трансформация модели потребления
18. Affinity — насколько признак представлен в изучаемом сегменте
19. Когда у продукта один большой конкурент — учитывать целевые сегменты и потенциальных конкурентов

Масштаб и паттерны: 
20. Масштаб custdev — от отдельных интервью к паттернам поведения и сегментам

Связанные темы: 
21. Основной источник проблемы стартапа — не покупают — custdev раньше, чем проблема с ЦА

#подборка@custdevlab #целеваяаудитория #сегментация@custdevlab #методика@custdevlab