CustDev Laboratory

293. Как понять, что онбродинг работает хорошо: основные метрики

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

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

Коллеги из “Антипуш” собрали несколько метрик и типовых проблем онбординга, которые чаще всего анализируют команды продукта.

1️⃣ Activation rate
Процент пользователей, которые совершили целевое действие после onboarding: заполнили профиль, сделали первый заказ, подключили функцию и т.д.
Смысл метрики — понять, дошёл ли пользователь до первого осмысленного действия, где продукт начинает восприниматься как полезный.
Низкая активация — сигнал, что пользователь либо не понял ценность, либо столкнулся с трением в процессе.

2️⃣ Time to First Value (TTFV)
Время до первого полезного результата.
Чем быстрее человек получает ощущение «это мне помогает», тем выше вероятность, что он вернётся. Поэтому многие продукты стараются сокращать путь до первой ценности: упрощают сценарии, убирают лишние шаги, показывают результат раньше.

3️⃣ Retention после онбординг
Сам факт прохождения онбординг ещё мало что значит. Важно, возвращается ли пользователь позже.
Иногда онбординг формально «успешный» — пользователь всё прошёл — но удержание (retention) остаётся низким, потому что человек так и не встроил продукт в свой сценарий жизни.

4️⃣ Обратная связь
Количественные метрики показывают, где проблема. Но не всегда объясняют почему.
Поэтому полезно собирать и качественную обратную связь:
— что было непонятно
— где возникла перегрузка
— в какой момент пользователь потерял интерес
— чего не хватило для уверенного старта

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

#метрики@custdevlab #онбординг@custdevlab

292. «Нужный» параметр товара: противоударный телефон

Противоударный телефон — продукт с понятным параметром. Но продажи у таких устройств часто небольшие. Потому что противоударность важна не всем. Для большинства покупателей это совершенно не главный критерий выбора продукта.

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

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

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

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

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

#продукт@custdevlab #ценностноепредложение@custdevlab #методика@custdevlab

291. Мини-шпаргалка: методы исследований — что к чему

Коллеги из 'https://t.me/dtcenter_global/4137?utm_source=partner&utm_medium=custdevlab&utm_campaign=metod-research' rel='nofollow'>Центра дизайн-мышления собрали интересный контент: какой тип метода исследований для какой задачи и на каком этапе продукта обычно уместен. Это не жёсткие правила, а скорее ориентир, с чего начать выбор нужного метода и спроектировать дизайн исследования.

1️⃣ Качественные методы
Глубокое погружение в мотивы, ожидания и контекст: ответы на «почему так?» и «как человек это переживает?», а не на «сколько процентов».

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

Инструменты
Глубинные интервью, фокус-группы, контекстное наблюдение, карты сортировки (card sorting).

2️⃣ Количественные методы
Сбор цифр и проверка гипотез в масштабе: «сколько?», «как часто?», «насколько сильно сдвинулась метрика после изменения?».

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

Инструменты
Опросы и анкеты, веб-аналитика (Яндекс.Метрика и аналоги), A/B-тесты, коридорки (короткие тесты первого впечатления — например, пятисекундный тест).

3️⃣ Смешанные методы
Сочетание «качества» и «количества»: и цифры, и объяснение, почему цифры такие — удобно перед крупными решениями.

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

Инструменты
Удалённые немодерируемые юзабилити-тесты (без ведущего), бета-тесты и пилотные запуски, опрос по модели Кано (базовые / ожидаемые / «вау»-характеристики).

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

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

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

Про стадии разработки продукта
Названия «Проблема → Концепция → Разработка → Оптимизация» — это упрощённая воронка жизненного цикла продукта, к которой часто относят исследования в курсах и статьях.

По смыслу она близка к связке discovery / delivery: сначала понять проблему и проверить идею решения, потом строить рабочую версию и измерять, затем улучшать то, что уже в поле.

Пересекается с логикой Lean Startup (поиск проблемы и решения → продукт с пользователями → итерации по данным) и с фазами в stage-gate и дорожных картах, но названия у разных авторов могут отличаться (например, «дизайн-спринт / прототип» вместо «концепция»). Если у вас в компании свои названия этапов — просто подставьте свои: важнее тип вопроса («почему» vs «сколько»), чем этикетка на слайде.

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

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

290. Система метрик — как не потеряться в показателях

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

Три уровня метрик
Удобная схема — трехуровневая модель (она используется, в частности, при оценке эффективности customer development):

1. Метрики процесса — что и сколько мы делаем.
Количество интервью, опросов, респондентов; охват сегментов; регулярность исследований. Эти показатели отвечают на вопрос «достаточно ли мы вообще кастдевим?», но не говорят о качестве и отдаче. Без них непонятно, насколько систематична работа; зацикливаться только на них — ошибка.

2. Метрики результата — что мы узнали и проверили.
Количество и качество инсайтов, сформулированные и валидированные гипотезы, скорость валидации, глубина понимания ЦА. В CDDC у каждого шага есть блок «метод проверки» с метрикой и бенчмарком: с чем сравниваем результат, что считаем успехом. Выбор метрики и бенчмарка для проверки гипотез — одна из самых важных задач: неправильная метрика равна непроверенной гипотезе. В HADI данные (Data) — это в том числе метрики, по которым мы решаем, подтверждена гипотеза или нет.

3. Метрики бизнес-влияния — как изменились ключевые показатели продукта.
Влияние на трафик, конверсию, средний чек, частоту покупок, удержание; в итоге — на выручку. Выручка раскладывается на трафик × конверсия × средний чек × частота покупок; custdev и продукт в конечном счёте должны двигать именно эти метрики. Связь «интервью → инсайт → изменение продукта → рост конверсии» не всегда прямая, но без уровня бизнес-влияния мы не видим, окупается ли наша работа.

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

В сухом остатке: система метрик помогает не путать «сколько мы сделали» (процесс), «что узнали и проверили» (результат) и «как изменился бизнес» (влияние). Метрики процесса и результата нужны для управления custdev и гипотезами; метрики бизнес-влияния — чтобы понимать отдачу. Одна North Star задаёт фокус; остальные уровни — чтобы не потеряться в показателях.

#метрики@custdevlab #custdev@custdevlab #методика@custdevlab

289. North Star Metric — главная метрика продукта

В продукте и стартапе метрик много: выручка, трафик, конверсия, удержание, NPS и десятки других. Но на что смотреть в первую очередь? Концепция North Star Metric (NSM) — «метрика Полярной звезды» — предлагает выбрать одну метрику, которая лучше всего отражает ценность, которую продукт доставляет клиентам.

Идею популяризировали Шон Эллис (Sean Ellis) и Морган Браун: North Star — это не «что мы зарабатываем» и не «сколько нас посетило», а когда клиент реально получает главную ценность продукта. То есть NSM — это опережающий индикатор: растёт он — с высокой вероятностью потом подтянутся и выручка, и рост. Если гнаться только за выручкой или только за трафиком, можно оптимизировать не то: увеличение одной метрики нередко бьёт по другой (кейс доставки еды — время против охвата).

Как выбирают North Star Metric
Ключевой вопрос: какая одна метрика, если она вырастет сегодня, сильнее всего разгонит «маховик» вашего бизнеса?
Часто NSM относят к одному из типов:
— Ценность для пользователя — моменты использования, «аха-момент», глубина вовлечённости.
— Потребление — сообщения отправлены, ночи забронированы, поездки совершены (Airbnb, Uber).
— Рост пользователей — платящие пользователи, MAU/DAU.
— Эффективность роста — LTV/CAC и подобное.
— Выручка — ARR, GMV (часто как North Star у зрелых бизнесов).

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

Что важно для сильной North Star Metric
Хорошая NSM: отражает ценность для клиента; является опережающим индикатором дохода; измерима имеющимися данными; понятна команде и по ней можно принимать решения; её сложно «накрутить» в ущерб продукту. Маркетинговые метрики для стартапа часто и есть главные — умение привлекать и удерживать клиентов; North Star помогает сфокусировать именно на той одной метрике, которая лучше всего связана с долгосрочным успехом.

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

#метрики@custdevlab #управлениепродуктом@custdevlab #методика@custdevlab

288. AHA-момент и WOW-эффект в продуктах

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

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

AHA-момент обычно случается в онбординге или при первом использовании. Пользователь регистрируется, пробует, и в какой-то момент — понимает. Facebook обнаружил: пользователи, добавившие 7 друзей в первые 10 дней, почти всегда оставались надолго; те, кто не достиг этого порога, чаще уходили. Добавление друзей — proxy для AHA: человек понял, зачем ему соцсеть. Каждый продукт имеет свой «триггер»: для банкинга — первая успешная операция, для трекера привычек — первая завершённая цепочка, для мессенджера — первый осмысленный диалог.

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

Связь с TTV (Time to Value): чем быстрее пользователь достигает AHA-момента, тем выше вероятность, что он останется. Долгий онбординг, множество шагов до первой ценности — ресурсы пользователя (время, внимание, усилия) заканчиваются раньше, чем он «доберётся». Метрика TTV измеряет время до AHA или WOW; её оптимизация — ключ к активации и снижению churn.

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

В сухом остатке: AHA-момент — осознание ценности продукта; WOW-эффект — эмоциональное удивление. Оба решают, останется пользователь или уйдёт. Чем короче путь к ним (TTV), тем выше активация. В custdev — спрашивать, когда и при каком действии пользователь впервые почувствовал ценность.

#онбординг@custdevlab #метрики@custdevlab #ttv@custdevlab

Собрали для удобства в одном посте все посты про JTBD и AJTBD:

Custdev и JTBD — основы:
1. Custdev и JTBD — понимание потребителя и мотивов его поведения
2. Эволюция подходов от custdev к jtbd — от вопроса «что нужно?» к «какую работу нанимают?»
3. Подходы к проведению продуктовых исследований — custdev, JTBD, дизайн-мышление, сервис-дизайн
4. Создание прорывных продуктов через CustDev — боль и потребности клиентов как основа

JTBD и другие инструменты:
5. Custdev для CJM: зачем нужно и нужно ли? — custdev и JTBD при построении CJM
6. Как объединить в одну систему потребности + жизненные ситуации + точки контакта + клиентский путь — Custdev + JTBD + CJM
7. CJM или почему они не работают — AJTBD и динамический CJM
8. Данные нулевой стороны — типы данных в JTBD и custdev

Этапы JTBD-методологии (Боб Моэста):
9. Этапы jtbd-методологии: итог — сводка всех этапов LXM-модели в одном посте
10. Первая мысль о продукте (First thought)
11. Пассивный поиск в jtbd (Боб Моэста) (Passive looking)
12. Активный поиск в jtbd (Боб Моэста) (Active looking)
13. Принятие решения о покупке (Боб Моэста) (Deciding)
14. Первая часть процесса использования: онбординг (Боб Моэста) (Onboarding)
15. Процесс использования продукта (между онбордингом и офбордингом) (Ongoing use)
16. Последняя часть процесса использования продукта: офбординг (Offboarding)

AJTBD — работы и сценарии:
17. Что значит «убить работу» в AJTBD — сократить количество работ для пользователя
18. AJTBD-сценарии и верхнеуровневая работа — работы более высокого уровня

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

Связанные темы:
22. Отличие покупки в первый раз и в каждый последующий — разный дизайн исследования
23. Привычное потребление и разные модели — частотность потребления и формулировка вопросов

#подборка@custdevlab #jtbd@custdevlab #ajtbd@custdevlab #методика@custdevlab

287. Рекламная бизнес-модель продукта: unit-экономика и пороги по числу пользователей

Рекламная модель живёт за счёт большого числа пользователей. Unit здесь — показ рекламы:

Выручка = количество показов × CPM (стоимость за 1000 показов)

Чем больше аудитория и её вовлечённость, тем больше показов и дохода.

Unit-экономика рекламной модели
CPM в РФ (по данным click.ru на окт. 2024): для соцсетей и медийки — порядка 65–250 рублей за 1000 показов (myTarget ~66 ₽, VK Ads ~97 ₽, Яндекс.Сети ~110 ₽, маркетплейсы в среднем ~237 ₽). Для выручки 100 млн рублей в год нужно порядка 400 млн – 1 млрд показов, а это означает сотни тысяч или около миллиона активных пользователей в месяц при высокой вовлечённости.

Пороги по аудитории
В аналитике и практике часто говорят о порогах для venture-scale рекламного продукта: 10+ млн MAU как минимальный уровень для серьёзной монетизации.

Tubi вышла в прибыль при 64 млн MAU

BeReal запустила рекламу при 40 млн

Freemium/рекламные модели в массовом потребительском интернете обычно требуют 50+ млн активных пользователей для устойчивой экономики.

Меньшие рынки и ниши
На более узких рынках порог ниже. При высоком CPM (таргет, B2B, специализированная аудитория) или локальном рынке 1 млн MAU уже может давать осмысленную выручку — при условии, что вовлечённость и ценность аудитории для рекламодателей высоки. Масштаб компенсируется ценой показа.

В сухом остатке: рекламная модель строится на большом числе пользователей и показах; массовый продукт — десятки миллионов MAU; ниша с высоким CPM — от ~1 млн MAU при сильной вовлечённости и ценности аудитории.

#бизнесмодель@custdevlab #реклама@custdevlab #unitэкономика@custdevlab #метрики@custdevlab

284. Блок «Респонденты» в CDDC: как описывать, кого искать и где

Третий блок канваса CDDC — «Респонденты». Он отвечает на два вопроса: кого мы исследуем и где их ищем. На практике здесь одна из самых частых ошибок: размытое описание, неверный сегмент, нереалистичные источники.

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

Связь с сегментацией
Блок «Респонденты» — это применение критериев сегментирования: социально-демографических, поведенческих, психографических. На этапе Discovery сегмент часто размыт — и это нормально. Но уже на втором шаге мы уточняем гипотезу о сегменте и проверяем её. Валидация сегментов — часть CDDC: каждый шаг может подтвердить или скорректировать, с кем мы работаем.

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

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

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

283. Как формулировать гипотезы для CDDC: структура, примеры удачных и неудачных формулировок

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

Структура хорошей гипотезы
Гипотеза для CDDC должна быть проверяемой и конкретной. Удобный каркас:

«Мы предполагаем, что [сегмент] [поведение/потребность/реакция] при [условиях]».

Чем яснее сегмент, поведение и условия — тем проще подобрать метод, метрику и респондентов.

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

Примеры удачных формулировок: 

«Владельцы малого бизнеса в сфере услуг, которые искали CRM за последний квартал, готовы платить от X рублей в месяц за автоматизацию напоминаний клиентам»

«Родители детей 5–8 лет, которые водят ребёнка на доп. занятия, считают английский приоритетом и готовы тратить на него не менее Y рублей в месяц»

«Пользователи, установившие приложение по рекламе в соцсетях, при стоимости привлечения до 60 руб. конвертируются в платящих не менее чем в 5% случаев»

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

В сухом остатке: хорошая гипотеза для CDDC — конкретная, проверяемая, с ясным сегментом и условиями; плохая — размытая и не измеряемая. Время на формулировку окупается качеством всего канваса.

#cddc@custdevlab #гипотезы@custdevlab #методика@custdevlab

282. Две стратегии продуктовых идей: своё решение vs требования клиента

На этапе Customer Discovery выявляем боли клиента через проблемное интервью. Дальше встаёт вопрос о том, как формулировать решение — и здесь можно выделить два подхода в зависимости от источника идеи. В реальности часто встречаются смешанные варианты.

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

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

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

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

#customerdiscovery@custdevlab #методика@custdevlab #модельповедения@custdevlab

281. MECE: структурность мышления

MECE (Mutually Exclusive, Collectively Exhaustive) — принцип структурирования в исследованиях: факторы или категории должны быть взаимно исключающими и совместно исчерпывающими. Не пересекаться и не оставлять «дыр».

Взаимно исключающие (ME) 
Означает, что каждый элемент, изучаемый в опросе или в интервью, попадает только в одну категорию — пересечений быть не должно. Если делим респондентов по возрасту, то используем следующие интервалы: 18–25, 26–35, 36–45. Если респонденту 30 лет, он относится к одному конкретному сегменту. Если бы варианты ответа пересекались (например, «молодые» и «до 35»), один и тот же человек мог бы оказаться в двух местах — а это путаница в выводах.

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

Совместно исчерпывающие (CE)
Все категории в исследовании вместе покрывают всё исследуемое пространство. Нет «остального» или «прочего», куда попадает непонятно что. Сегментация «клиенты» и «не клиенты» — исчерпывает, если мы говорим о статусе покупки.

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

Применение MECE в custdev-процедурах
При сегментировании — чёткие критерии без наложения. При разбиении гайда на блоки — вопросы не дублируют друг друга и вместе покрывают нужные темы. При анализе инсайтов после интервью — группировка по MECE помогает не терять важное и не считать одно дважды.

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

MECE — ориентир, не строгое правило. В реальности границы часто размыты, поэтому важно стремиться к непересекающимся и исчерпывающим категориям там, где от структуры зависят выводы. Где структура условна — допустимы компромиссы.

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

#методика@custdevlab #сегментация@custdevlab #mece@custdevlab

280. Когда достаточно интервью: насыщение vs минимальное число

Вопрос «сколько интервью проводить» не имеет единственного ответа. Минимальные ориентиры : около 15 на один сегмент целевой аудитории. Но кроме фиксированного числа есть второй критерий — насыщение: новые интервью перестают давать новую информацию.

Два этих подхода не противоречат друг другу.

Фиксированное число — ориентир на старте — сколько сегментов, сколько интервью на каждый. Это помогает планировать рекрут, бюджет, сроки. Числа (4–5, 8–12, 15) это отправные точки.

1. Для быстрой проверки «есть ли проблема вообще» иногда достаточно 4–5 интервью: если за это время не нашлось никого, кому проблема по-настоящему важна, гипотеза, скорее всего, слабая.
2. Для выявления паттернов поведения в сегменте — 8–12
3. Для более глубокого анализа — 15 и больше.

Ориентиры зависят от задачи и сложности гипотезы.

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

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

Насыщение может наступить раньше «плановых» 15 или позже — зависит от однородности сегмента и согласованности ответов.

Фиксированное число — для планирования и отчётности: «проведём 12 интервью в каждом из двух сегментов». Насыщение — для решения «достаточно ли уже»: если после 10 интервью два последних ничего нового не добавили, можно останавливаться; если после 15 по-прежнему слышите противоречия и новые темы — продолжать.

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

Ранняя остановка «по насыщению» рискованна, если интервью всего 2–3 — там ещё нет паттернов, только отдельные случаи. И наоборот: если после 15–20 интервью ответы сильно расходятся, насыщение не достигнуто — отбор респондентов или гайд требуют корректировки. Насыщение предполагает согласованность данных; при большом разбросе нужно разбираться в причинах, а не просто добавлять интервью.

В сухом остатке: количество интервью задаётся ориентирами (4–5 для проверки проблемы, 8–15 на сегмент для паттернов), останавливаться можно по критерию насыщения — когда новые интервью не добавляют нового.

#customerinterview@custdevlab #методика@custdevlab #интервью@custdevlab

279. Дебрифинг после интервью: зачем он нужен и как его проводить

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

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

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

15–20 минут сразу после разговора дают больше, чем час разбора через неделю. Лучше всего дебрифить после каждого интервью, а не копить на один большой синтез.

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

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

Не копить на один разбор. Одна длинная синтез-сессия в конце — выше риск потери деталей и упрощения выводов. Дебрифинг после каждого интервью создаёт цепочку: интервью — фиксация — обновление гайда — следующее интервью.

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

В сухом остатке: дебрифинг после каждого интервью — 15–20 минут сразу после разговора — сохраняет детали и цитаты, помогает обновлять гайд между сессиями и не копить всё на один разбор.

#customerinterview@custdevlab #методика@custdevlab #интервью@custdevlab

278. Пивот должен быть настоящим пивотом

Не каждая смена идеи продукта — пивот. Пивот в Lean Startup — это структурное изменение элемента бизнес-модели на основе обучения от рынка. То есть решение поменять направление должно опираться на данные, собранные через взаимодействие с пользователями, а не на «подумали и решили».

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

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

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

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

#пивот@custdevlab #методика@custdevlab #custdev@custdevlab