CustDev Laboratory

307. Три уровня воркараундов (workaround)

Пользовательский (User Workaround)
Клиент сам находит способ решить свою задачу, потому что в продукте нет нужной кнопки.

Пример: В приложении для заметок нельзя форматировать текст жирным. Пользователь начинает писать слова КАПСЛОКОМ или выделять их звездочками *вот так*.

Это явный сигнал для продакта: функция востребована.

Операционный / Ручной (Operational Workaround)
Команда стартапа имитирует автоматическую работу продукта вручную («эффект Волшебника Изумрудного города»). Это классический подход в Customer Development и Lean Startup.

Пример: Стартап запустил сайт по подбору витаминов. Робот на сайте обещает «умный алгоритм анализа». На самом деле, когда пользователь отправляет анкету, данные приходят на почту основателю стартапа, и он вручную за 20 минут собирает PDF-отчет.

Технический (Technical Workaround / «Костыль»)
Разработчики пишут быстрый код, который временно решает критическую проблему (баг), чтобы приложение не падало, пока они ищут фундаментальное решение.

Пример: Упала интеграция с платежной системой. Вместо долгой починки кода разработчики за 5 минут выводят на экран плашку: «Извините, мы временно принимаем переводы по СБП на этот номер».

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

#полезное@custdevlab

306. Lead users: пример и custdev

Примеры из практики и литературы

— Горные велосипеды. В 1970-х энтузиасты сами модифицировали рамы и тормоза под спуск с гор — за годы до того, как индустрия оформила категорию MTB. Классический кейс фон Хиппеля: инновация шла от пользователей, не от R&D отдела.

— Медицина и 3M. В методике Lead User Method (развита совместно с 3M) команда намеренно ищет врачей и специалистов с «опережающими» проблемами — так, например, появлялись новые материалы и решения для хирургии, которых рынок ещё не формулировал.

— B2B и «свои костыли». Бухгалтер, который уже собрал макросы в Excel, логист, который ведёт учёт в Notion, инженер с самописным скриптом — часто lead users в зародыше: потребность уже есть, выгода от решения высокая, рынок догонит позже.

Зачем это custdev

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

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

В сухом остатке: Это не early adopters и не фанаты продукта — скорее «завтрашний рынок сегодня». В custdev их ищут ради прорывных инсайтов, но проверяют, когда потребность станет массовой.

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

305. Lead users: кто такие «лидирующие пользователи» по Эрику фон Хиппелю

Если искать инсайты только у «среднего» клиента, можно опоздать с продуктом на годы. Эрик фон Хиппель (Eric von Hippel), исследователь из MIT, описал другую точку опоры — lead users, лидирующих пользователей. Идея изложена в работах по user innovation и в книге Democratizing Innovation (2005).

Lead users — те, кто обладает двумя ключевыми характеристиками:
1. Они сталкиваются с потребностями, которые впоследствии станут общими на рынке, — но сталкиваются с ними за месяцы или годы до того, как большинство участников этого рынка их испытает.
2. Они получают значительную выгоду, находя решение для удовлетворения своих потребностей — часто сами, до появления готового продукта на рынке.

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

Чем lead users не являются
— Не просто early adopters по Роджерсу. Инноватор пробует новое ради новизны; lead user может вообще не пользоваться вашей категорией — он уже решил задачу иначе.
— Не «самый лояльный клиент». Фанат текущего продукта расскажет, как улучшить фичи. Lead user часто живёт за пределами вашего продукта — с самодельным workaround (собственным способом решить проблему).
— Не эксперт «вообще». Нужна связка «опережающая потребность + личная выгода от решения», а не должность в CV.

Ограничение
Lead users хороши для поиска нового, но плохи как единственный голос рынка: их потребности могут опережать массу слишком сильно. Поэтому после интервью с lead users проверяют, когда и для кого эта потребность станет общей — custdev, метрики, пилот.

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

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

304. Переход от Discovery к Validation в CDDC: критерии готовности и «красные флаги»

CDDC разделяет два этапа: Customer Discovery и Customer Validation. Переход между ними — критический момент. Перейдем слишком рано и рискуем тестировать решение для несуществующей проблемы. Слишком поздно — теряем время и деньги на лишние custdev-процедуры.

Критерии готовности к Validation: 
✅Есть формулировка «боли» словами потребителя.
✅ Есть гипотеза о сегменте, проверенная на интервью.
✅ Понимаем, какие характеристики продукта важны и как пользователь оценивает ценность.
✅ Можем сделать MVP (или его минимальную версию), который можно предложить за деньги или в обмен на обязательство.

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

Что делать, если перешли рано. Вернуться к Discovery. Уточнить формулировку проблемы, провести дополнительные интервью, скорректировать сегмент. Лучший критерий проверки — деньги, но только когда до этого есть понимание проблемы и контекста.

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

#cddc@custdevlab #discovery@custdevlab #validation@custdevlab

303. Последовательные vs параллельные шаги в CDDC: когда параллельно, когда строго по очереди

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

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

Бессмысленно тестировать цену, если не подтвердили проблему. То же с каналами продаж: сначала проверяем product-market fit и только потом — масштабирования трафика. 

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

Смешанная логика. Часто внутри этапа Discovery — несколько параллельных направлений (сегмент А и сегмент Б), а между этапами Discovery и Validation — строгая последовательность. Поэтому сначала понимаем проблему и сегмент, потом проверяем решение деньгами.

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

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

302. Приглашение на интервью: что повышает отклик и типичные ошибки

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

Что повышает отклик
Чёткий следующий шаг: «напишите «да» в ответ» или «перейдите по ссылке и выберите время». Размытое «если интересно, дайте знать» хуже — человек не понимает, что делать. Персонализация: упомянуть, откуда взяли контакт или почему обратились именно к нему. Короткая тема письма с конкретикой: «20 минут о выборе доставки — 500 ₽» сработает лучше, чем «Предложение» или «Важное сообщение». Follow-up через 2–3 дня — многие отвечают на напоминание, а не на первое письмо.

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

В сухом остатке: чёткий следующий шаг, персонализация и конкретная тема письма повышают отклик; follow-up через 2–3 дня тоже помогает. Избегать: длинных текстов, скрытой рекламы, расплывчатых формулировок, рассылки без сегментации.

#рекрутингреспондентов@custdevlab #методика@custdevlab #интервью@custdevlab

300. Правила Mom Test: как не получать «вежливое да»

Книга «Спроси маму» Роба Фитцпатрика у нас упоминается, но три правила Mom Test на канале не разобраны отдельно.

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

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

Правило 3: искать конкретику и готовность к действию. Конкретика — детали, цифры, примеры. Готовность к действию: записаться на демо, дать контакт коллеги, потратить время. «Вежливое да» — не готовность к действию.

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

В сухом остатке: Mom Test (тест "Спроси маму") — говорить о жизни респондента, не верить на слово, искать конкретику и готовность к действию.

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

299. Структура приглашения на интервью

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

Человек должен быстро понять:
— что от него хотят
— сколько времени это займёт
— в чём ЕГО выгода.

Короткое приглашение лучше длинного. Минимум: тема разговора (общая — «как вы выбираете сервисы доставки»), длительность (15–20 минут), формат (звонок, Zoom, очно). Этого достаточно, чтобы оценить, подходит ли запрос конкретному потенциальному респонденту.

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

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

#рекрутингреспондентов@custdevlab #методика@custdevlab #интервью@custdevlab

298. Модель Hook (Hooked): привычки и переменная награда

Модель Hook — фреймворк Нира Эяля (Nir Eyal) из книги «Hooked: How to Build Habit-Forming Products» (2014). Описывает, как продукты формируют привычки у пользователей. Цикл из четырёх фаз повторяется и усиливает возвращение к продукту.

1. Триггер (Trigger) — сигнал к действию. Внешние: push-уведомление, email, иконка приложения. Внутренние: эмоция или мысль («скучно» → открыть ленту, «хочу узнать новости» → соцсеть). Цель — перейти от внешних триггеров к внутренним: пользователь сам запускает действие без напоминаний. Привычка сформирована, когда продукт «первым приходит в голову» в определённой ситуации.

2. Действие (Action) — простое поведение в ожидании награды. Чем проще действие и выше мотивация, тем чаще оно совершается. Эяль опирается на модель Фогга: поведение = мотивация × способность. Снизить трение, упростить шаги — ключ к этой фазе.

3. Переменная награда (Variable Reward) — главное отличие Hook от обычной обратной связи. Предсказуемая награда (холодильник включается при открытии двери) не создаёт «хочу ещё». Непредсказуемая — да. Изменчивость усиливает выброс дофамина и поддерживает интерес.

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

Лента соцсети, лента рекомендаций, уведомления «у вас новый лайк» — примеры переменной награды.

4. Инвестиция (Investment) — пользователь вкладывает время, данные, усилия, социальный капитал. Подписки, сохранённые настройки, загруженный контент, приглашённые друзья. Инвестиция улучшает следующий цикл: триггер становится сильнее, действие — проще, награда — релевантнее. Получается не разовая «конверсия», а то, что повышает ценность продукта при следующем заходе.

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

В сухом остатке: модель Hook — Trigger → Action → Variable Reward → Investment. Переменная награда (непредсказуемость) создаёт желание возвращаться и поддерживает привычку. Связь с retention и управлением усталостью — через разнообразие и переменность подкрепления.

#retention@custdevlab #метрики@custdevlab #опыт@custdevlab

296. Модель поведения Фогга: B = MAP (часть 1/2)

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

Модель поведения Фогга (Fogg Behavior Model, FBM) — один из самых практичных способов это разложить. Её автор — BJ Fogg, основатель Behavior Design Lab в Стэнфорде; модель описана в работах с 2009 года и подробно в книге Tiny Habits.

Формула короткая: B = MAP

Поведение (Behavior) происходит, когда в один момент сходятся мотивация (Motivation), способность (Ability) и подсказка (Prompt). Если действия нет — не хватает чего-то одного. Это не «слабая воля пользователя», а диагностика: что именно отсутствует.

Мотивация. Насколько человек хочет сделать действие именно сейчас. Фогг выделяет базовые мотиваторы — удовольствие и боль, надежда и страх, принятие и отвержение. Мотивация нестабильна: утром одна, вечером другая, в стрессе падает. На неё опираться как на единственный рычаг рискованно. Теория JTBD в особенности рассматривает изменчивость мотивации.

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

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

Подсказка (prompt). Сигнал «сделай это сейчас». Раньше в модели это называли trigger; Фогг переименовал в prompt, чтобы не путать с негативным «триггерным» маркетингом (см. LXM-модель). Без подсказки поведения не будет — даже при высокой мотивации и простом действии. Пуш в три ночи, баннер без контекста, шаг онбординга без привязки к ситуации пользователя — слабые или несвоевременные подсказки.

В сухом остатке: модель Фогга B = MAP — поведение случается, когда в один момент сходятся мотивация, способность и подсказка; если действия нет, не хватает одного из трёх.

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

295. Сбор обратной связи: нужно платить пользователю

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

Если мотивация только эмоциональная

Срабатывают, как правило, пиковые эмоции — очень хорошие или очень плохие.

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

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

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

Если мотивация денежная (или иная явная)

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

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

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

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

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

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