CustDev Laboratory

294. Верификация custdev: когда исследование нужно не «для галочки» На отборе в акселератор, перед питчем или перед разговором со стейкхолдерами стртап часто рассказывает о проведенных custdev-процедурах. Однако на деле у экспертов возникает вопрос: а какой custdev вообще был — и можно ли доверять выводам? Отчёт с цитатами о проведенных процедурах сам по себе не отвечает на этот вопрос. Важна связка: гипотеза → метод → первичные данные → выводы → что вы решили по продукту. Для таких случаев в CustDev Laboratory запустили услугу верификации custdev-исследований. Кому это нужно Команды на отборе в программы, стартапы перед питчем, продакты — когда нужно показать, что customer development сделан осознанно, а не формально. Что на выходе верификации Сертификат CustDev Laboratory с оценкой по трём блокам — методология, гипотеза, выводы — в формате, который можно приложить к заявке, питч-деку или внутреннему отчёту. Если есть зоны роста, в документе будут краткие рекомендации. Сертификат не заменяет due diligence, но даёт внешнюю экспертную оценку: видно, что исследование проведено по корректной для целей методике, а выводы опираются на данные и сам исследователь не галлюцинирует. У каждого документа — уникальный номер; подлинность можно проверить по запросу в лабораторию. Как это работает Отправляете материалы через форму на сайте: первичные данные, гипотезу, которую проверяли, и выводы, к которым пришли. Эксперты лаборатории разбирают исследование — гайд и вопросы, рекрутинг и выборку, глубину интервью, связь выводов с фактами из первички. Оценка опирается на практику лаборатории и методики, в том числе канвас CDDC. Получаете сертификат и при необходимости используете его в заявке, на питче или в отчёте для команды. Материалы, отправленные на верификацию, нигде и никогда не публикуются и не передаются третьим лицам — конфиденциальность по умолчанию. Стоимость Сейчас услуга бесплатна: мы на этапе запуска и верифицируем исследования без оплаты. Заявка: custdevlab.ru/verification.html В сухом остатке: верификация custdev — внешняя экспертная оценка вашего исследования (методология, гипотеза, выводы) с сертификатом для приложения к документам; подходит командам на отборе, перед питчем и когда нужно показать стейкхолдерам, что custdev сделан осознанно. #верификация@custdevlab #методика@custdevlab #услугилаборатории@custdevlab

293. Как понять, что онбродинг работает хорошо: основные метрики Онбординг — самый важный процесс клиентского пути. Потому что за клиента мы уже заплатили, он прошел все рекламные этапы, и если онбординг будет сделан плохо, деньги потрачены, а результата нет. Как понять, когда онбординг сделан хорошо? В мобильных приложениях (онбординг пришел в первую очередь оттуда) обычно смотрят на следующее: — получил ли человек первую ценность от продукта — вернулся ли позже — насколько быстро вообще понял, зачем ему приложение Коллеги из “Антипуш” собрали несколько метрик и типовых проблем онбординга, которые чаще всего анализируют команды продукта. 1️⃣ Activation rate Процент пользователей, которые совершили целевое действие после onboarding: заполнили профиль, сделали первый заказ, подключили функцию и т.д. Смысл метрики — понять, дошёл ли пользователь до первого осмысленного действия, где продукт начинает восприниматься как полезный. Низкая активация — сигнал, что пользователь либо не понял ценность, либо столкнулся с трением в процессе. 2️⃣ Time to First Value (TTFV) Время до первого полезного результата. Чем быстрее человек получает ощущение «это мне помогает», тем выше вероятность, что он вернётся. Поэтому многие продукты стараются сокращать путь до первой ценности: упрощают сценарии, убирают лишние шаги, показывают результат раньше. 3️⃣ Retention после онбординг Сам факт прохождения онбординг ещё мало что значит. Важно, возвращается ли пользователь позже. Иногда онбординг формально «успешный» — пользователь всё прошёл — но удержание (retention) остаётся низким, потому что человек так и не встроил продукт в свой сценарий жизни. 4️⃣ Обратная связь Количественные метрики показывают, где проблема. Но не всегда объясняют почему. Поэтому полезно собирать и качественную обратную связь: — что было непонятно — где возникла перегрузка — в какой момент пользователь потерял интерес — чего не хватило для уверенного старта В сухом остатке: онбординг — это процесс, в котором пользователь пытается ответить на вопрос «зачем мне этот продукт и насколько легко встроить его в свою жизнь»; чем быстрее и понятнее продукт помогает получить этот ответ, тем выше шанс на удержание. #метрики@custdevlab #онбординг@custdevlab

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

291. Мини-шпаргалка: методы исследований — что к чему Коллеги из Центра дизайн-мышления собрали интересный контент: какой тип метода исследований для какой задачи и на каком этапе продукта обычно уместен. Это не жёсткие правила, а скорее ориентир, с чего начать выбор нужного метода и спроектировать дизайн исследования. 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

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