es
Feedback
CustDev Laboratory

CustDev Laboratory

Ir al canal en Telegram

Канал про продукт и потребителей: - Customer Development - Jobs-to-be-done - Модели потребительского поведения http://custdevlab.ru Практические советы, полезные ресурсы. Контент на 100% оригинальный. Стенограммы: @pasportichka @pnevostruev

Mostrar más
2 100
Suscriptores
Sin datos24 horas
-47 días
-1230 días
Atraer Suscriptores
agosto '26
agosto '26
+13
en 0 canales
julio '26
+20
en 0 canales
Get PRO
junio '26
+24
en 0 canales
Get PRO
mayo '26
+24
en 0 canales
Get PRO
abril '26
+70
en 1 canales
Get PRO
marzo '26
+56
en 1 canales
Get PRO
febrero '26
+42
en 0 canales
Get PRO
enero '26
+46
en 2 canales
Get PRO
diciembre '25
+51
en 2 canales
Get PRO
noviembre '25
+160
en 2 canales
Get PRO
octubre '25
+75
en 2 canales
Get PRO
septiembre '25
+117
en 3 canales
Get PRO
agosto '25
+45
en 4 canales
Get PRO
julio '25
+94
en 2 canales
Get PRO
junio '25
+41
en 2 canales
Get PRO
mayo '25
+71
en 2 canales
Get PRO
abril '25
+70
en 2 canales
Get PRO
marzo '25
+120
en 0 canales
Get PRO
febrero '25
+49
en 0 canales
Get PRO
enero '25
+83
en 0 canales
Get PRO
diciembre '24
+67
en 0 canales
Get PRO
noviembre '24
+102
en 0 canales
Get PRO
octubre '24
+74
en 0 canales
Get PRO
septiembre '24
+83
en 0 canales
Get PRO
agosto '24
+41
en 0 canales
Get PRO
julio '24
+47
en 0 canales
Get PRO
junio '24
+35
en 0 canales
Get PRO
mayo '24
+51
en 0 canales
Get PRO
abril '24
+89
en 1 canales
Get PRO
marzo '24
+77
en 0 canales
Get PRO
febrero '24
+75
en 1 canales
Get PRO
enero '24
+53
en 0 canales
Get PRO
diciembre '23
+67
en 1 canales
Get PRO
noviembre '23
+132
en 0 canales
Get PRO
octubre '23
+200
en 0 canales
Get PRO
septiembre '23
+587
en 0 canales
Fecha
Crecimiento de Suscriptores
Menciones
Canales
28 agosto0
27 agosto+1
26 agosto0
25 agosto0
24 agosto+1
23 agosto0
22 agosto0
21 agosto+1
20 agosto+1
19 agosto0
18 agosto+1
17 agosto+1
16 agosto0
15 agosto+1
14 agosto0
13 agosto+1
12 agosto+3
11 agosto0
10 agosto+1
09 agosto0
08 agosto0
07 agosto0
06 agosto0
05 agosto0
04 agosto0
03 agosto+1
02 agosto0
01 agosto0
Publicaciones del Canal
297. Модель Фогга: Линия действия (часть 2/2) На графике модели по одной оси — способность (от сложного к простому), по друго
297. Модель Фогга: Линия действия (часть 2/2) На графике модели по одной оси — способность (от сложного к простому), по другой — мотивация. Кривая «линия действия» отделяет зону, где подсказка сработает, от зоны, где нет. Мотивация и способность компенсируют друг друга: если мотивация очень высокая, человек потянет и сложное действие; если действие тривиально простое — хватит и слабой мотивации. Зачем это продукту и custdev Модель универсальна — от действия «оставить отзыв» до «оформить подписку». Когда целевое действие не случается, полезно не гадать, а пройти по модели MAP: — Был ли prompt в нужный момент и в нужном контексте? — Достаточно ли было способности — не только «мало кнопок», но и деньги, время, привычка, социальная норма? — Хватало ли мотивации именно в этот момент — или мы просим действие, когда человек «ниже линии действия»? В интервью это часто звучит иначе, чем в метриках воронки: «не понял, зачем сейчас», «страшно ошибиться», «у конкурента привычнее», «не было времени разбираться». Это не абстрактный «отвал», а конкретный провал одного из элементов MAP. Практический вывод Фогга и его школы behavior design: надёжнее поднимать способность, чем бесконечно наращивать мотивацию скидками и давлением. Упростить шаг, встроить подсказку в существующую рутину, снять когнитивную нагрузку — часто эффективнее, чем «ещё одна акция». В сухом остатке: для продукта используйте чек-лист: не только «мало мотивации», но и «слишком сложно» или «не было сигнала сейчас»; мотивация и способность взаимодополняют друг друга. #модельповедения@custdevlab #методика@custdevlab #продукт@custdevlab #полезное@custdevlab

2
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
142
3
295. Сбор обратной связи: нужно платить пользователю Через обратную связь пользователь по сути становится соавтором продукта: называет боли, проверяет гипотезы, подсказывает, что улучшить. Это работа — пусть и короткая, но очень важная. Рассчитывать, что её будут делать «просто так» и регулярно, не стоит. Если мотивация только эмоциональная Срабатывают, как правило, пиковые эмоции — очень хорошие или очень плохие. Когда всё отлично, человек может один-два раза написать восторженный отзыв или порекомендовать продукт. Но постоянно быть на супер-позитиве нельзя: эмоция сходит на нет, и поток обратной связи быстро высыхает. Когда всё плохо, человек тоже может написать — злой, развёрнутый комментарий. Но такой клиент часто быстро перестаёт быть клиентом: он уходит, а вы теряете и продажу, и возможность дальше с ним разговаривать. В ящике обратной связи из «Теда Лассо» как раз много шлака и ругани — среди этого есть дельное, но это не система сбора знаний о продукте. То есть «бесплатная» обратная связь чаще приходит в крайних точках и не даёт ровного, управляемого потока — особенно если нужны не эмоции, а разбор ситуации, контекста и причин. Если мотивация денежная (или иная явная) Другая история. Человек понимает, за что тратит время: интервью, опрос, тест прототипа, развёрнутый отзыв по заданию. Мотивация может быть разной — деньги, подарок, бонус, доступ к функции, ведро курицы в обмен на отзыв у KFC — но суть одна: есть обмен, а не просьба «сделайте нам одолжение». Для custdev это особенно заметно: глубинное интервью, разбор кейса, участие в исследовании — это уже не «оставьте звёздочку в приложении», а отдельная задача. Без вознаграждения или другой ясной выгоды рекрутинг усложняется, выборка смещается в сторону самых мотивированных или самых недовольных — не всегда тех, кого вы хотели слышать. Это не значит, что каждый отзыв в поддержке нужно оплачивать. Речь про осознанный сбор обратной связи как часть исследования и развития продукта: когда вы просите у человека время и внимание сверх обычного пользования — закладывайте в это ресурс. В сухом остатке: развёрнутая обратная связь — это работа пользователя как соавтора продукта; на одних эмоциях (восторг или злость) она приходит рывками и быстро иссякает. Когда нужен регулярный и содержательный поток — особенно в custdev — нужен явный обмен: деньги, бонус или другая понятная выгода; иначе вы получаете не картину рынка, а пики и случайную выборку. #custdev@custdevlab #методика@custdevlab #customerinterview@custdevlab #полезное@custdevlab
229
4
Sin texto...
1
5
Раньше такси заказывалось самое ближайшее к точке подаче. Но потом из-за внутренних KPI таксисты стали сами себя возить для получения бонусов. Теперь такси не заказывается самое близкое Кто пострадал? Пользователь? Таксист? Теперь владелец сервиса получает нужное поведение, а клиент страдает
80
6
294. Верификация custdev: когда исследование нужно не «для галочки» На отборе в акселератор, перед питчем или перед разговором со стейкхолдерами стртап часто рассказывает о проведенных custdev-процедурах. Однако на деле у экспертов возникает вопрос: а какой custdev вообще был — и можно ли доверять выводам? Отчёт с цитатами о проведенных процедурах сам по себе не отвечает на этот вопрос. Важна связка: гипотеза → метод → первичные данные → выводы → что вы решили по продукту. Для таких случаев в CustDev Laboratory запустили услугу верификации custdev-исследований. Кому это нужно Команды на отборе в программы, стартапы перед питчем, продакты — когда нужно показать, что customer development сделан осознанно, а не формально. Что на выходе верификации Сертификат CustDev Laboratory с оценкой по трём блокам — методология, гипотеза, выводы — в формате, который можно приложить к заявке, питч-деку или внутреннему отчёту. Если есть зоны роста, в документе будут краткие рекомендации. Сертификат не заменяет due diligence, но даёт внешнюю экспертную оценку: видно, что исследование проведено по корректной для целей методике, а выводы опираются на данные и сам исследователь не галлюцинирует. У каждого документа — уникальный номер; подлинность можно проверить по запросу в лабораторию. Как это работает Отправляете материалы через форму на сайте: первичные данные, гипотезу, которую проверяли, и выводы, к которым пришли. Эксперты лаборатории разбирают исследование — гайд и вопросы, рекрутинг и выборку, глубину интервью, связь выводов с фактами из первички. Оценка опирается на практику лаборатории и методики, в том числе канвас CDDC. Получаете сертификат и при необходимости используете его в заявке, на питче или в отчёте для команды. Материалы, отправленные на верификацию, нигде и никогда не публикуются и не передаются третьим лицам — конфиденциальность по умолчанию. Стоимость Сейчас услуга бесплатна: мы на этапе запуска и верифицируем исследования без оплаты. Заявка: custdevlab.ru/verification.html В сухом остатке: верификация custdev — внешняя экспертная оценка вашего исследования (методология, гипотеза, выводы) с сертификатом для приложения к документам; подходит командам на отборе, перед питчем и когда нужно показать стейкхолдерам, что custdev сделан осознанно. #верификация@custdevlab #методика@custdevlab #услугилаборатории@custdevlab
364
7
293. Как понять, что онбродинг работает хорошо: основные метрики Онбординг — самый важный процесс клиентского пути. Потому что за клиента мы уже заплатили, он прошел все рекламные этапы, и если онбординг будет сделан плохо, деньги потрачены, а результата нет. Как понять, когда онбординг сделан хорошо? В мобильных приложениях (онбординг пришел в первую очередь оттуда) обычно смотрят на следующее: — получил ли человек первую ценность от продукта — вернулся ли позже — насколько быстро вообще понял, зачем ему приложение Коллеги из “Антипуш” собрали несколько метрик и типовых проблем онбординга, которые чаще всего анализируют команды продукта. 1️⃣ Activation rate Процент пользователей, которые совершили целевое действие после onboarding: заполнили профиль, сделали первый заказ, подключили функцию и т.д. Смысл метрики — понять, дошёл ли пользователь до первого осмысленного действия, где продукт начинает восприниматься как полезный. Низкая активация — сигнал, что пользователь либо не понял ценность, либо столкнулся с трением в процессе. 2️⃣ Time to First Value (TTFV) Время до первого полезного результата. Чем быстрее человек получает ощущение «это мне помогает», тем выше вероятность, что он вернётся. Поэтому многие продукты стараются сокращать путь до первой ценности: упрощают сценарии, убирают лишние шаги, показывают результат раньше. 3️⃣ Retention после онбординг Сам факт прохождения онбординг ещё мало что значит. Важно, возвращается ли пользователь позже. Иногда онбординг формально «успешный» — пользователь всё прошёл — но удержание (retention) остаётся низким, потому что человек так и не встроил продукт в свой сценарий жизни. 4️⃣ Обратная связь Количественные метрики показывают, где проблема. Но не всегда объясняют почему. Поэтому полезно собирать и качественную обратную связь: — что было непонятно — где возникла перегрузка — в какой момент пользователь потерял интерес — чего не хватило для уверенного старта В сухом остатке: онбординг — это процесс, в котором пользователь пытается ответить на вопрос «зачем мне этот продукт и насколько легко встроить его в свою жизнь»; чем быстрее и понятнее продукт помогает получить этот ответ, тем выше шанс на удержание. #метрики@custdevlab #онбординг@custdevlab
353
8
Собрали для удобства в одном посте посты про LXM и разные масштабы опыта: Что такое LXM и зачем он нужен: 1. Life experience map — карта жизненного пути, поведение пользователя с разными продуктами в категории, а не с одним (как в CJM) Как проводить интервью по LXM: 2. LXM-based customer interview — вопросы по каждому этапу, построение LXM по результатам интервью LXM и CJM — в чём разница: 3. CJM и LXM: в чем отличие — CJM как карта сокровищ, LXM как карта местности Разные масштабы опыта (матрёшки): 4. Разные масштабы опыта — *вставить ссылку как пост выйдет* Офбординг в LXM и цикл в категории: 5. Офбординг — *вставить ссылку как пост выйдет* #подборка@custdevlab #lxm@custdevlab #cjm@custdevlab #методика@custdevlab
84
9
2**. «Нужный» параметр товара: противоударный телефон Противоударный телефон — продукт с понятным параметром. Но продажи у таких устройств часто небольшие. Потому что противоударность важна не всем. Для большинства покупателей это совершенно не главный критерий выбора продукта. При покупке телефона люди в первую очередь смотрят на базовые вещи: экран, камера, производительность, автономность, цена. Эти параметры важны почти для всех в категории. Противоударность же — специфическая потребность: строители, спортсмены, работники в сложных условиях, родители активных детей. Этот сегмент уже, чем «все, кто покупает телефон». Если продукт позиционируется только как противоударный, он обращается к узкой аудитории, тем сложнее масштабировать продажи. Успешный продукт в этой нише работает иначе: он решает основные задачи категории для большинства и при этом обладает противоударностью. То есть сначала продукт должен быть хорошим телефоном — с теми функциями, которые ждут в категории, а противоударность становится дополнительным преимуществом для тех, кому это важно, и не мешает остальным. Потребитель не жертвует «обычным» функционалом ради одной особенности. Тот же принцип применим к другим параметрам: влагозащита, расширенная батарея, особо прочный экран. Если характеристика важна только части аудитории, она не может быть единственным основанием для позиционирования продукта. Ценностное предложение строится на том, что нужно потребителю и чего нет у конкурентов — но базовый набор ожиданий категории должен выполняться. В сухом остатке: параметр, важный не для всех, не должен быть основой позиционирования, если не закрывает основные потребности большинства потребителей. #продукт@custdevlab #ценностноепредложение@custdevlab #методика@custdevlab
377
10
Главное конкурентное пеимущество стартапа — скорость проверки гипотез Некоторые гипотезы можно протестриовать быстро. Некоторые гипотезы тестируются чуть дольше. Но главное — размытая гипотеза ведёт у осознанию, что продукт вообще не стоило делать. Чтобы избежать ошибок (учиться же лучше на чужих ошибках, верно?) проведу вебинар для МФТИ 23 апреля в 19:00. Участие бесплатное — нужно только пройти регистрацию. На онлайн-вебинаре расскажу, как правильно формулировать продуктовые гипотезы, подбирать инструменты для тестирования и быстро отсекать слабые идеи и находить слабые места. А главное, у нас будет 30 минут на три гипотезы — то есть мы протестируем 3 гипотезы продуктов за полчаса. Это сильно быстрее, чем мы могли бы... Бонус: после вебинара каждый участник получит гайд по проверке гипотез в подарок (гайда на этом канале нет).
262
11
291. Мини-шпаргалка: методы исследований — что к чему Коллеги из Центра дизайн-мышления собрали интересный контент: какой тип метода исследований для какой задачи и на каком этапе продукта обычно уместен. Это не жёсткие правила, а скорее ориентир, с чего начать выбор нужного метода и спроектировать дизайн исследования. 1️⃣ Качественные методы Глубокое погружение в мотивы, ожидания и контекст: ответы на «почему так?» и «как человек это переживает?», а не на «сколько процентов». Когда чаще всего применяют — Стадия «Проблема» — искать реальные боли, барьеры и язык пользователя до того, как вы жёстко зафиксировали решение. — Стадия «Концепция» — проверять идеи, сценарии, прототипы: достаточно ли они резонируют с тем, как люди живут задачу. Инструменты Глубинные интервью, фокус-группы, контекстное наблюдение, карты сортировки (card sorting). 2️⃣ Количественные методы Сбор цифр и проверка гипотез в масштабе: «сколько?», «как часто?», «насколько сильно сдвинулась метрика после изменения?». Когда чаще всего применяют — Стадия «Разработка» — зафиксировать базовые показатели, когда продукт уже в руках у пользователей. — Стадия «Оптимизация» — сравнивать варианты и понимать, что реально двигает метрики, а что шум. Инструменты Опросы и анкеты, веб-аналитика (Яндекс.Метрика и аналоги), A/B-тесты, коридорки (короткие тесты первого впечатления — например, пятисекундный тест). 3️⃣ Смешанные методы Сочетание «качества» и «количества»: и цифры, и объяснение, почему цифры такие — удобно перед крупными решениями. Когда чаще всего применяют — Финальное тестирование прототипа или пилота перед широким релизом. — Приоритизация фич и дорожной карты, когда нужны и приоритеты по данным, и понимание «зачем это пользователю». Инструменты Удалённые немодерируемые юзабилити-тесты (без ведущего), бета-тесты и пилотные запуски, опрос по модели Кано (базовые / ожидаемые / «вау»-характеристики). Как выбрать метод Сформулируйте вопрос исследования: что нужно узнать — смысл и контекст («почему?»), масштаб и измеримость («сколько?») или все сразу. Оцените ресурсы: время, бюджет, доступ к респондентам и возможность дотянуться до «живых» пользователей. На сложных вопросах не бойтесь комбинировать: качество подсказывает направление, количество — проверяет масштаб. Про стадии разработки продукта Названия «Проблема → Концепция → Разработка → Оптимизация» — это упрощённая воронка жизненного цикла продукта, к которой часто относят исследования в курсах и статьях. По смыслу она близка к связке discovery / delivery: сначала понять проблему и проверить идею решения, потом строить рабочую версию и измерять, затем улучшать то, что уже в поле. Пересекается с логикой Lean Startup (поиск проблемы и решения → продукт с пользователями → итерации по данным) и с фазами в stage-gate и дорожных картах, но названия у разных авторов могут отличаться (например, «дизайн-спринт / прототип» вместо «концепция»). Если у вас в компании свои названия этапов — просто подставьте свои: важнее тип вопроса («почему» vs «сколько»), чем этикетка на слайде. В сухом остатке: на ранних этапах (проблема, концепция) применяют качественные методы, которые отвечают на вопрос «почему» и «как думает пользователь»; когда продукт уже в поле и нужны метрики и сравнение вариантов — количественные отвечают на вопросы «сколько» и «что изменилось»; смешанные методы нужны, когда перед крупным решением нужны и глубина, и цифры. #методика@custdevlab #исследования@custdevlab #полезное@custdevlab #цдм@custdevlab
532
12
290. Система метрик — как не потеряться в показателях В продукте и в custdev метрик много: одни описывают процесс, другие — результат, третьи — влияние на бизнес. Если мерить всё подряд, легко утонуть в цифрах и не понять, что именно улучшать. Поэтому имеет смысл выстраивать систему метрик: разделять уровни и связывать их с решениями. Три уровня метрик Удобная схема — трехуровневая модель (она используется, в частности, при оценке эффективности customer development): 1. Метрики процесса — что и сколько мы делаем. Количество интервью, опросов, респондентов; охват сегментов; регулярность исследований. Эти показатели отвечают на вопрос «достаточно ли мы вообще кастдевим?», но не говорят о качестве и отдаче. Без них непонятно, насколько систематична работа; зацикливаться только на них — ошибка. 2. Метрики результата — что мы узнали и проверили. Количество и качество инсайтов, сформулированные и валидированные гипотезы, скорость валидации, глубина понимания ЦА. В CDDC у каждого шага есть блок «метод проверки» с метрикой и бенчмарком: с чем сравниваем результат, что считаем успехом. Выбор метрики и бенчмарка для проверки гипотез — одна из самых важных задач: неправильная метрика равна непроверенной гипотезе. В HADI данные (Data) — это в том числе метрики, по которым мы решаем, подтверждена гипотеза или нет. 3. Метрики бизнес-влияния — как изменились ключевые показатели продукта. Влияние на трафик, конверсию, средний чек, частоту покупок, удержание; в итоге — на выручку. Выручка раскладывается на трафик × конверсия × средний чек × частота покупок; custdev и продукт в конечном счёте должны двигать именно эти метрики. Связь «интервью → инсайт → изменение продукта → рост конверсии» не всегда прямая, но без уровня бизнес-влияния мы не видим, окупается ли наша работа. Одна главная vs множество метрик North Star Metric — одна метрика, которая лучше всего отражает ценность для клиента и разгон бизнеса. Она не отменяет остальные: система метрик описывает процесс и результат на разных уровнях, а North Star задаёт фокус, чтобы не оптимизировать второстепенное в ущерб главному. При этом у продукта всегда есть целевые и побочные метрики: запуская фичу, мы ждём целевой эффект, но учитываем и побочные — и со временем доля «шума» может снижаться. В сухом остатке: система метрик помогает не путать «сколько мы сделали» (процесс), «что узнали и проверили» (результат) и «как изменился бизнес» (влияние). Метрики процесса и результата нужны для управления custdev и гипотезами; метрики бизнес-влияния — чтобы понимать отдачу. Одна North Star задаёт фокус; остальные уровни — чтобы не потеряться в показателях. #метрики@custdevlab #custdev@custdevlab #методика@custdevlab
424
13
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
335
14
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
368
15
Собрали для удобства в одном посте все посты про 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
366
16
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
329
17
286. NPS и CSI: на опросы отвечает 10–30% клиентов — почему важна статистическая значимость На вопросы NPS и CSI после покупки или взаимодействия отвечает малая часть базы. По разным исследованиям, большинство компаний получает 5–15% ответов на рассылки по электронной почте, а эффективные программы достигают 30–40% отклика. В B2B средний коэффициент ответа (по данным CustomerGauge) — 12,4%, а общий диапазон — от 4,5% до 39,3%. Через электронную почту обычно отвечают 15–25%, через in-app — 20–30%. То есть типичный диапазон для опросов среди покупателей (post-purchased) — примерно 10–30%. При низком проценте ответов результат легко искажается. Отвечают чаще всего те, кто уже доволен или, наоборот, очень недоволен. Нейтральные и «тепло-прохладные» клиенты реже открывают опросы. Получается смещение выборки: NPS или CSI могут выглядеть лучше или хуже, чем реальная картина по всей базе. Не менее важно — проверка статистической значимости. NPS строится на трёх группах (промоутеры, пассивные пользователи, детракторы), и это триномиальная метрика. Если сравнивать два NPS между собой или во времени, нельзя считать доли групп независимыми — иначе занижается стандартное отклонение и разницы могут казаться значимыми, когда ими не являются. Нужен расчет доверительных интервалов и методы, учитывающие структуру NPS. Для надёжных выводов важны и объём выборки, и доля ответивших: при коэффициенте ответов 10% и 1000 отправленных опросов — 100 ответов; при 100 отправленных — всего 10, что явно недостаточно для устойчивых выводов. В сухом остатке: на опросы NPS и CSI после покупки отвечает 10–30% клиентов; при таком проценте ответов важно проверять статистическую значимость и учитывать смещение выборки #nps@custdevlab #csi@custdevlab #метрики@custdevlab
335
18
285. Блок «Действия» в CDDC: как формулировать шаги, чек-лист и типичные упущения Четвёртый блок CDDC — «Действия». Что именно нужно сделать, чтобы получить результат проверки гипотезы. Часто его заполняют в последнюю очередь и общими фразами: «провести интервью», «запустить трафик». В итоге шаг висит в воздухе — непонятно, кто, когда и как его выполняет. Как формулировать действия Каждое действие должно быть конкретным и выполнимым. Вместо «провести 10 интервью» — «составить гайд на основе гипотезы; отобрать 15 респондентов по анкете; провести 10 интервью по 45–60 минут; зафиксировать выводы в таблице». Чем детальнее, тем меньше вопросов при выполнении. Действия стоит привязывать к метрике: что мы делаем, чтобы её получить. Чек-лист для блока «Действия»:  — Подготовка: гайд, анкета отбора, скрипт (если нужен) — Рекрутинг: каналы, объявление, критерии отбора — Проведение: сроки, ответственные, формат (онлайн/офлайн) — Обработка: фиксация результатов, сравнение с бенчмарком — Решение: критерий «подтверждено / не подтверждено» и следующие шаги Что часто упускают Не прописывают подготовку — и выходят на интервью без гайда. Не закладывают время на рекрутинг — он всегда дольше, чем кажется. Забывают про обработку — интервью проведены, а выводы не сформулированы. Не определяют критерий успеха заранее — потом трудно понять, подтвердилась гипотеза или нет. В сухом остатке: блок «Действия» превращает гипотезу в выполнимый план; конкретные шаги, чек-лист и учёт типичных упущений снижают риск «провели, но ничего не получили». #cddc@custdevlab #действия@custdevlab #методика@custdevlab
362
19
284. Блок «Респонденты» в CDDC: как описывать, кого искать и где Третий блок канваса CDDC — «Респонденты». Он отвечает на два вопроса: кого мы исследуем и где их ищем. На практике здесь одна из самых частых ошибок: размытое описание, неверный сегмент, нереалистичные источники. Как описывать респондентов Не «потенциальные клиенты» или «все, кому интересно», а конкретные критерии: кто по поведению, демографии, ситуации. Чем точнее описание, тем понятнее, куда идти за респондентами. Например: «владельцы малого бизнеса в сфере услуг, которые за последние 3 месяца выбирали CRM» — это хорошее описание. «Предприниматели» — плохое. Связь с сегментацией Блок «Респонденты» — это применение критериев сегментирования: социально-демографических, поведенческих, психографических. На этапе Discovery сегмент часто размыт — и это нормально. Но уже на втором шаге мы уточняем гипотезу о сегменте и проверяем её. Валидация сегментов — часть CDDC: каждый шаг может подтвердить или скорректировать, с кем мы работаем. Где искать Зависит от сегмента и этапа. Существующие клиенты — для понимания удержания и опыта. Те, кто в процессе выбора, — самый ценный сегмент для привлечения новых клиентов. Три основных сегмента: наши клиенты, клиенты конкурентов, те, кто выбирает. Для каждого — свои каналы: база, входящий трафик, группы и сообщества, холодный рекрутинг. Анкета для отбора помогает фильтровать респондентов до интервью. В сухом остатке: чёткие критерии «кого» и «где» связывают гипотезу с реальными людьми и повышают ценность каждого шага проверки. #cddc@custdevlab #респонденты@custdevlab #сегментация@custdevlab
344
20
283. Как формулировать гипотезы для CDDC: структура, примеры удачных и неудачных формулировок Первый блок CDDC — «Гипотеза». От неё зависят метод проверки, респонденты и действия. Размытая гипотеза ведёт к размытым результатам: непонятно, что именно мы проверили и что делать дальше. От этого весь метод CDDC может показаться бесполезным. Структура хорошей гипотезы Гипотеза для CDDC должна быть проверяемой и конкретной. Удобный каркас: «Мы предполагаем, что [сегмент] [поведение/потребность/реакция] при [условиях]». Чем яснее сегмент, поведение и условия — тем проще подобрать метод, метрику и респондентов. Примеры неудачных формулировок:  — «Людям нужен наш продукт» — нет сегмента, нет поведения, не проверить — «Рынок большой» — что значит «большой», для кого, как измерить? — «Клиенты готовы платить больше» — кто именно, за что, при каких условиях? Примеры удачных формулировок:  «Владельцы малого бизнеса в сфере услуг, которые искали CRM за последний квартал, готовы платить от X рублей в месяц за автоматизацию напоминаний клиентам» «Родители детей 5–8 лет, которые водят ребёнка на доп. занятия, считают английский приоритетом и готовы тратить на него не менее Y рублей в месяц» «Пользователи, установившие приложение по рекламе в соцсетях, при стоимости привлечения до 60 руб. конвертируются в платящих не менее чем в 5% случаев» Связь CDDC с узловыми тестами: большую гипотезу разбиваем на «узлы», каждый узел — отдельная проверяемая гипотеза. Сначала проверяем «есть ли боль», потом «готовы ли платить», потом «какой канал работает». Метрика и бенчмарк для каждой гипотезы — в блоке «Метод проверки». В сухом остатке: хорошая гипотеза для CDDC — конкретная, проверяемая, с ясным сегментом и условиями; плохая — размытая и не измеряемая. Время на формулировку окупается качеством всего канваса. #cddc@custdevlab #гипотезы@custdevlab #методика@custdevlab
356