276. Источники поиска респондентов для custdev
Выбор источника поиска респондентов зависит от того, есть ли продукт и клиенты, насколько детализировано определена ЦА и какой бюджет на это есть.
1. Предварительный отбор через онлайн-опрос. Анкета с соцдемом, вопросами о поведении и контактами рассылается куда угодно; отбираете подходящих и приглашаете на интервью. Не тратим время интервью на «допрос». Учитываем 152-ФЗ. Анкета — это фильтр для последующих интервью, источник респондентов для неё — все пункты ниже.
2. Собственные клиенты и входящий трафик. Если продукт есть — начинаем с имеющихся клиентов: CRM, звонки, сообщения. Дополняем входящим трафиком (звонки, письма, сообщения, заявки). Мы уже писали про три сегмента респондентов: клиенты (CRM), клиенты конкурентов (их соцсети) и те, кто только выбирает товарную категорию (входящий трафик, сообщества).
3. Специальные группы в Telegram. Telegram-чаты позволяют оставить запрос на участие в исследовании. Кто подходит и имеет желание — согласится. Единственное, нужно учитывать мета-критерии таких респондентов. Для особых ниш ЦА подходят тематические группы ВК, Telegram, Тенчат (B2B).
4. Соцсети и сервисы. Youdo.com и аналоги — заявка «нужен человек с характеристиками X для разговора 15–20 минут» позволяет получить респондентов достаточно быстро, правда платно.
5. Платные панели и агентства. Онлайн-панели (OMI и др.) созданы для быстрого рекрутинга по нужным критериям. Оплата осуществляется за каждого респондента. Существуют агентства, специализирующиеся на рекрутинг нужных респондентов (например, ADS), что подходит для сложных B2B и редких сегментов. Плюс: скорость, минус — мотивация панелистов может отличаться от «настоящих» клиентов.
Выбор: есть продукт — с клиентов. Нет — анкета + группы/таргет. Нужна скорость и квоты — панели или агентства. Минимум ~15 интервью на сегмент; важна релевантность, не количество.
В сухом остатке: пять источников респондентов — предварительный отбор, клиенты и трафик, группы, соцсети/сервисы, панели и агентства; выбор зависит от продукта, ЦА и бюджета.
#методика@custdevlab #рекрутингреспондентов@custdevlab
Выбор источника поиска респондентов зависит от того, есть ли продукт и клиенты, насколько детализировано определена ЦА и какой бюджет на это есть.
1. Предварительный отбор через онлайн-опрос. Анкета с соцдемом, вопросами о поведении и контактами рассылается куда угодно; отбираете подходящих и приглашаете на интервью. Не тратим время интервью на «допрос». Учитываем 152-ФЗ. Анкета — это фильтр для последующих интервью, источник респондентов для неё — все пункты ниже.
2. Собственные клиенты и входящий трафик. Если продукт есть — начинаем с имеющихся клиентов: CRM, звонки, сообщения. Дополняем входящим трафиком (звонки, письма, сообщения, заявки). Мы уже писали про три сегмента респондентов: клиенты (CRM), клиенты конкурентов (их соцсети) и те, кто только выбирает товарную категорию (входящий трафик, сообщества).
3. Специальные группы в Telegram. Telegram-чаты позволяют оставить запрос на участие в исследовании. Кто подходит и имеет желание — согласится. Единственное, нужно учитывать мета-критерии таких респондентов. Для особых ниш ЦА подходят тематические группы ВК, Telegram, Тенчат (B2B).
4. Соцсети и сервисы. Youdo.com и аналоги — заявка «нужен человек с характеристиками X для разговора 15–20 минут» позволяет получить респондентов достаточно быстро, правда платно.
5. Платные панели и агентства. Онлайн-панели (OMI и др.) созданы для быстрого рекрутинга по нужным критериям. Оплата осуществляется за каждого респондента. Существуют агентства, специализирующиеся на рекрутинг нужных респондентов (например, ADS), что подходит для сложных B2B и редких сегментов. Плюс: скорость, минус — мотивация панелистов может отличаться от «настоящих» клиентов.
Выбор: есть продукт — с клиентов. Нет — анкета + группы/таргет. Нужна скорость и квоты — панели или агентства. Минимум ~15 интервью на сегмент; важна релевантность, не количество.
В сухом остатке: пять источников респондентов — предварительный отбор, клиенты и трафик, группы, соцсети/сервисы, панели и агентства; выбор зависит от продукта, ЦА и бюджета.
#методика@custdevlab #рекрутингреспондентов@custdevlab
5👍5✍3🔥3🌭2🤩1
277. Универсальность VS экспертность продукта
Маркетплейс — это много товаров в одном месте. Один каталог, одна корзина, единая логистика. Но выбрать специфичный товар на маркетплейсе часто сложнее, чем на специализированном сайте.
Причина — не учитываются особенности категории. У каждой категории свои критерии выбора: для техники — характеристики, комплектация, совместимость; для строительной техники — мощность, тип питания, вес; для спортинвентаря — размер, материал, назначение. Специализированный магазин или сайт знает это и даёт соответствующие фильтры: десятки параметров, подсказки, сравнение. На маркетплейсе — универсальный набор: цена, бренд, рейтинг, может быть ещё пара общих фильтров. Один интерфейс для всего каталога, значит — компромисс по глубине для каждой категории.
Получается дилемма выбора, где купить: универсальность даёт широту выбора, экспертность даёт качество выбора. Чем шире ассортимент, тем сложнее обеспечить «умный» подбор внутри каждой ниши. Пользователь, который точно знает, что ищет (например, беговую обувь по типу покрытия), на маркетплейсе вынужден листать и отсеивать вручную то, что специализированный спортивный магазин отфильтровывет за один клик.
В модели жизненного опыта ключевые этапы — активный поиск и принятие решения. Именно там человек собирает информацию, сравнивает альтернативы, сужает выбор по критериям. Для каждой категории эти критерии свои: техника, спорт, инструменты — разные «карты» выбора.
Маркетплейс предлагает одну универсальную карту; специализированный сайт выстроен под LXM своей категории — знает типичные триггеры, этапы поиска и критерии решения. Там, где путь выбора в категории требует экспертизы (много параметров, сложное сравнение), универсальный интерфейс «сплющивает» этот путь — этап активного поиска растягивается, формирование набора рассмотрения усложняется.
Для многих покупок «универсальный» набор фильтров достаточен. Но для категорий с высокой экспертизой выбора специализированные решения остаются сильнее — и это объясняет, почему в нишах (техника, инструменты, спорт, профессиональное оборудование) продолжают жить отраслевые площадки и магазины.
В сухом остатке: универсальность продукта (много категорий) и экспертность (глубокие фильтры и помощь в выборе внутри категории) — разные преимущества; универсальный продукт даёт первое, специализированный продукт — второе.
#lxm@custdevlab #полезное@custdevlab #ux@custdevlab
Маркетплейс — это много товаров в одном месте. Один каталог, одна корзина, единая логистика. Но выбрать специфичный товар на маркетплейсе часто сложнее, чем на специализированном сайте.
Причина — не учитываются особенности категории. У каждой категории свои критерии выбора: для техники — характеристики, комплектация, совместимость; для строительной техники — мощность, тип питания, вес; для спортинвентаря — размер, материал, назначение. Специализированный магазин или сайт знает это и даёт соответствующие фильтры: десятки параметров, подсказки, сравнение. На маркетплейсе — универсальный набор: цена, бренд, рейтинг, может быть ещё пара общих фильтров. Один интерфейс для всего каталога, значит — компромисс по глубине для каждой категории.
Получается дилемма выбора, где купить: универсальность даёт широту выбора, экспертность даёт качество выбора. Чем шире ассортимент, тем сложнее обеспечить «умный» подбор внутри каждой ниши. Пользователь, который точно знает, что ищет (например, беговую обувь по типу покрытия), на маркетплейсе вынужден листать и отсеивать вручную то, что специализированный спортивный магазин отфильтровывет за один клик.
В модели жизненного опыта ключевые этапы — активный поиск и принятие решения. Именно там человек собирает информацию, сравнивает альтернативы, сужает выбор по критериям. Для каждой категории эти критерии свои: техника, спорт, инструменты — разные «карты» выбора.
Маркетплейс предлагает одну универсальную карту; специализированный сайт выстроен под LXM своей категории — знает типичные триггеры, этапы поиска и критерии решения. Там, где путь выбора в категории требует экспертизы (много параметров, сложное сравнение), универсальный интерфейс «сплющивает» этот путь — этап активного поиска растягивается, формирование набора рассмотрения усложняется.
Для многих покупок «универсальный» набор фильтров достаточен. Но для категорий с высокой экспертизой выбора специализированные решения остаются сильнее — и это объясняет, почему в нишах (техника, инструменты, спорт, профессиональное оборудование) продолжают жить отраслевые площадки и магазины.
В сухом остатке: универсальность продукта (много категорий) и экспертность (глубокие фильтры и помощь в выборе внутри категории) — разные преимущества; универсальный продукт даёт первое, специализированный продукт — второе.
#lxm@custdevlab #полезное@custdevlab #ux@custdevlab
4🌭3✍2👍2🤔2
278. Пивот должен быть настоящим пивотом
Не каждая смена идеи продукта — пивот. Пивот в Lean Startup — это структурное изменение элемента бизнес-модели на основе обучения от рынка. То есть решение поменять направление должно опираться на данные, собранные через взаимодействие с пользователями, а не на «подумали и решили».
Если проект просто захотел делать что-то новое — не связанное с тем, что выяснили в интервью, из метрик, из обратной связи — это не пивот. Это смена идеи «из головы». Команда могла устать от прежнего продукта, увидеть тренд, скопировать чужую идею. Но без опоры на информацию от рынка новая идея оказывается такой же непроверенной гипотезой, как и первая.
Интервью с пользователями — ключевой источник данных для решения о пивоте. Они показывают: проблема не подтвердилась, сегмент другой, способ решения не подходит, ценность в другом. На основе этого можно менять целевой сегмент, саму проблему, решение, каналы. Custdev «для галочки» не даёт такой информации — получаете формальное «подтверждение», но не понимание, куда двигаться. Готовность менять идею важна, но меняют не «просто так», а когда данные говорят: текущее направление не работает.
Настоящий пивот — это смена направления, обоснованная тем, что узнали от пользователей и рынка. Изменения в продукте «потому что решили попробовать другое» — это новый старт без валидации.
В сухом остатке: пивот — изменение на основе обучения от рынка; если решение поменять продукт не связано с собранной информацией от пользователей (интервью, метрики, обратная связь), это не пивот, а смена идеи «из головы»; интервью — ключ к обоснованному пивоту.
#пивот@custdevlab #методика@custdevlab #custdev@custdevlab
Не каждая смена идеи продукта — пивот. Пивот в Lean Startup — это структурное изменение элемента бизнес-модели на основе обучения от рынка. То есть решение поменять направление должно опираться на данные, собранные через взаимодействие с пользователями, а не на «подумали и решили».
Если проект просто захотел делать что-то новое — не связанное с тем, что выяснили в интервью, из метрик, из обратной связи — это не пивот. Это смена идеи «из головы». Команда могла устать от прежнего продукта, увидеть тренд, скопировать чужую идею. Но без опоры на информацию от рынка новая идея оказывается такой же непроверенной гипотезой, как и первая.
Интервью с пользователями — ключевой источник данных для решения о пивоте. Они показывают: проблема не подтвердилась, сегмент другой, способ решения не подходит, ценность в другом. На основе этого можно менять целевой сегмент, саму проблему, решение, каналы. Custdev «для галочки» не даёт такой информации — получаете формальное «подтверждение», но не понимание, куда двигаться. Готовность менять идею важна, но меняют не «просто так», а когда данные говорят: текущее направление не работает.
Настоящий пивот — это смена направления, обоснованная тем, что узнали от пользователей и рынка. Изменения в продукте «потому что решили попробовать другое» — это новый старт без валидации.
В сухом остатке: пивот — изменение на основе обучения от рынка; если решение поменять продукт не связано с собранной информацией от пользователей (интервью, метрики, обратная связь), это не пивот, а смена идеи «из головы»; интервью — ключ к обоснованному пивоту.
#пивот@custdevlab #методика@custdevlab #custdev@custdevlab
3👍4🌭4✍3🔥2🤩1
279. Дебрифинг после интервью: зачем он нужен и как его проводить
Интервью закончилось — и часто следующий шаг «отложить на потом»: разберём/обсудим, когда будет время, соберём все другие интервью и проанализируем разом.
Опасность в том, что к моменту «когда будет время» уже поздно, потому что многие детали стёрлись, цитаты забылись, контекст смешался с другими разговорами. Дебрифинг — краткий разбор сразу после интервью — снимает эту проблему.
Важно делать дебрифинг сразу, пока проще зафиксировать:
— что запомнилось сильнее всего
— какие формулировки респондента показались важными
— что не сходится с ожиданиями
15–20 минут сразу после разговора дают больше, чем час разбора через неделю. Лучше всего дебрифить после каждого интервью, а не копить на один большой синтез.
Что делать во время дебрифинга. Минимум: записать цитаты, ключевые факты, гипотезы и инсайты — по сути то, что описано в форме для записи результатов: суть ответа, быстрые факты о респонденте, возможности для продукта. Если интервью ведёт один человек — достаточно личных заметок. Если команда — короткий обмен:
«Что особо выделяем?»
«Какие паттерны напоминают прошлые сессии?»
«Что добавить или убрать в гайде?»
Обновлять гайд между сессиями. Дебрифинг — не только фиксация, но и коррекция процесса. После 2–3 интервью часто видно: какие вопросы дают пустые ответы, какие — новые направления, чего не хватает. Обновлять гайд между интервью, а не после всех, — значит каждое следующее интервью становится точнее. Иначе к концу серии накапливается «мусор» от неудачных вопросов.
Не копить на один разбор. Одна длинная синтез-сессия в конце — выше риск потери деталей и упрощения выводов. Дебрифинг после каждого интервью создаёт цепочку: интервью — фиксация — обновление гайда — следующее интервью.
Выводы формируются постепенно; паттерны поведения видны лучше, когда каждый разговор разобран отдельно.
В сухом остатке: дебрифинг после каждого интервью — 15–20 минут сразу после разговора — сохраняет детали и цитаты, помогает обновлять гайд между сессиями и не копить всё на один разбор.
#customerinterview@custdevlab #методика@custdevlab #интервью@custdevlab
Интервью закончилось — и часто следующий шаг «отложить на потом»: разберём/обсудим, когда будет время, соберём все другие интервью и проанализируем разом.
Опасность в том, что к моменту «когда будет время» уже поздно, потому что многие детали стёрлись, цитаты забылись, контекст смешался с другими разговорами. Дебрифинг — краткий разбор сразу после интервью — снимает эту проблему.
Важно делать дебрифинг сразу, пока проще зафиксировать:
— что запомнилось сильнее всего
— какие формулировки респондента показались важными
— что не сходится с ожиданиями
15–20 минут сразу после разговора дают больше, чем час разбора через неделю. Лучше всего дебрифить после каждого интервью, а не копить на один большой синтез.
Что делать во время дебрифинга. Минимум: записать цитаты, ключевые факты, гипотезы и инсайты — по сути то, что описано в форме для записи результатов: суть ответа, быстрые факты о респонденте, возможности для продукта. Если интервью ведёт один человек — достаточно личных заметок. Если команда — короткий обмен:
«Что особо выделяем?»
«Какие паттерны напоминают прошлые сессии?»
«Что добавить или убрать в гайде?»
Обновлять гайд между сессиями. Дебрифинг — не только фиксация, но и коррекция процесса. После 2–3 интервью часто видно: какие вопросы дают пустые ответы, какие — новые направления, чего не хватает. Обновлять гайд между интервью, а не после всех, — значит каждое следующее интервью становится точнее. Иначе к концу серии накапливается «мусор» от неудачных вопросов.
Не копить на один разбор. Одна длинная синтез-сессия в конце — выше риск потери деталей и упрощения выводов. Дебрифинг после каждого интервью создаёт цепочку: интервью — фиксация — обновление гайда — следующее интервью.
Выводы формируются постепенно; паттерны поведения видны лучше, когда каждый разговор разобран отдельно.
В сухом остатке: дебрифинг после каждого интервью — 15–20 минут сразу после разговора — сохраняет детали и цитаты, помогает обновлять гайд между сессиями и не копить всё на один разбор.
#customerinterview@custdevlab #методика@custdevlab #интервью@custdevlab
2👍5🔥3🌭3✍2🤩1
280. Когда достаточно интервью: насыщение vs минимальное число
Вопрос «сколько интервью проводить» не имеет единственного ответа. Минимальные ориентиры : около 15 на один сегмент целевой аудитории. Но кроме фиксированного числа есть второй критерий — насыщение: новые интервью перестают давать новую информацию.
Два этих подхода не противоречат друг другу.
Фиксированное число — ориентир на старте — сколько сегментов, сколько интервью на каждый. Это помогает планировать рекрут, бюджет, сроки. Числа (4–5, 8–12, 15) это отправные точки.
1. Для быстрой проверки «есть ли проблема вообще» иногда достаточно 4–5 интервью: если за это время не нашлось никого, кому проблема по-настоящему важна, гипотеза, скорее всего, слабая.
2. Для выявления паттернов поведения в сегменте — 8–12
3. Для более глубокого анализа — 15 и больше.
Ориентиры зависят от задачи и сложности гипотезы.
Насыщение — критерий для остановки. В качественных исследованиях достаточно интервью, когда новые респонденты перестают давать новое знание о поведении: те же темы, те же формулировки, те же паттерны.
Признаки насыщения: исследователь перестает слышать новое, т.е. складывается картина того, как люди решают проблему сейчас, готовы ли платить, что важно при выборе продукта. Также важно — получил ли исследователь ответы на ключевые вопросы и понимает ли, что включать в MVP.
Насыщение может наступить раньше «плановых» 15 или позже — зависит от однородности сегмента и согласованности ответов.
Фиксированное число — для планирования и отчётности: «проведём 12 интервью в каждом из двух сегментов». Насыщение — для решения «достаточно ли уже»: если после 10 интервью два последних ничего нового не добавили, можно останавливаться; если после 15 по-прежнему слышите противоречия и новые темы — продолжать.
Дебрифинг после каждого интервью помогает отслеживать появляется ли новое или повторяется уже услышанное. Поэтому дебрифинг является обязательной частью custdev-процедур, основанных на интервью.
Ранняя остановка «по насыщению» рискованна, если интервью всего 2–3 — там ещё нет паттернов, только отдельные случаи. И наоборот: если после 15–20 интервью ответы сильно расходятся, насыщение не достигнуто — отбор респондентов или гайд требуют корректировки. Насыщение предполагает согласованность данных; при большом разбросе нужно разбираться в причинах, а не просто добавлять интервью.
В сухом остатке: количество интервью задаётся ориентирами (4–5 для проверки проблемы, 8–15 на сегмент для паттернов), останавливаться можно по критерию насыщения — когда новые интервью не добавляют нового.
#customerinterview@custdevlab #методика@custdevlab #интервью@custdevlab
Вопрос «сколько интервью проводить» не имеет единственного ответа. Минимальные ориентиры : около 15 на один сегмент целевой аудитории. Но кроме фиксированного числа есть второй критерий — насыщение: новые интервью перестают давать новую информацию.
Два этих подхода не противоречат друг другу.
Фиксированное число — ориентир на старте — сколько сегментов, сколько интервью на каждый. Это помогает планировать рекрут, бюджет, сроки. Числа (4–5, 8–12, 15) это отправные точки.
1. Для быстрой проверки «есть ли проблема вообще» иногда достаточно 4–5 интервью: если за это время не нашлось никого, кому проблема по-настоящему важна, гипотеза, скорее всего, слабая.
2. Для выявления паттернов поведения в сегменте — 8–12
3. Для более глубокого анализа — 15 и больше.
Ориентиры зависят от задачи и сложности гипотезы.
Насыщение — критерий для остановки. В качественных исследованиях достаточно интервью, когда новые респонденты перестают давать новое знание о поведении: те же темы, те же формулировки, те же паттерны.
Признаки насыщения: исследователь перестает слышать новое, т.е. складывается картина того, как люди решают проблему сейчас, готовы ли платить, что важно при выборе продукта. Также важно — получил ли исследователь ответы на ключевые вопросы и понимает ли, что включать в MVP.
Насыщение может наступить раньше «плановых» 15 или позже — зависит от однородности сегмента и согласованности ответов.
Фиксированное число — для планирования и отчётности: «проведём 12 интервью в каждом из двух сегментов». Насыщение — для решения «достаточно ли уже»: если после 10 интервью два последних ничего нового не добавили, можно останавливаться; если после 15 по-прежнему слышите противоречия и новые темы — продолжать.
Дебрифинг после каждого интервью помогает отслеживать появляется ли новое или повторяется уже услышанное. Поэтому дебрифинг является обязательной частью custdev-процедур, основанных на интервью.
Ранняя остановка «по насыщению» рискованна, если интервью всего 2–3 — там ещё нет паттернов, только отдельные случаи. И наоборот: если после 15–20 интервью ответы сильно расходятся, насыщение не достигнуто — отбор респондентов или гайд требуют корректировки. Насыщение предполагает согласованность данных; при большом разбросе нужно разбираться в причинах, а не просто добавлять интервью.
В сухом остатке: количество интервью задаётся ориентирами (4–5 для проверки проблемы, 8–15 на сегмент для паттернов), останавливаться можно по критерию насыщения — когда новые интервью не добавляют нового.
#customerinterview@custdevlab #методика@custdevlab #интервью@custdevlab
2✍4👍4🌭3
281. MECE: структурность мышления
MECE (Mutually Exclusive, Collectively Exhaustive) — принцип структурирования в исследованиях: факторы или категории должны быть взаимно исключающими и совместно исчерпывающими. Не пересекаться и не оставлять «дыр».
Взаимно исключающие (ME)
Означает, что каждый элемент, изучаемый в опросе или в интервью, попадает только в одну категорию — пересечений быть не должно. Если делим респондентов по возрасту, то используем следующие интервалы: 18–25, 26–35, 36–45. Если респонденту 30 лет, он относится к одному конкретному сегменту. Если бы варианты ответа пересекались (например, «молодые» и «до 35»), один и тот же человек мог бы оказаться в двух местах — а это путаница в выводах.
То же с причинами отказа от продукта: «дорого» и «не уложился в бюджет» по сути одно и то же; при анализе лучше объединить или разделить чётко.
Совместно исчерпывающие (CE)
Все категории в исследовании вместе покрывают всё исследуемое пространство. Нет «остального» или «прочего», куда попадает непонятно что. Сегментация «клиенты» и «не клиенты» — исчерпывает, если мы говорим о статусе покупки.
«Клиенты», «потенциальные» и «конкуренты» — три основных сегмента для custdev — тоже MECE: любой человек в одной из трёх групп. Если добавлен «прочие» без определения — это разрыв; что в «прочих», непонятно.
Применение MECE в custdev-процедурах
При сегментировании — чёткие критерии без наложения. При разбиении гайда на блоки — вопросы не дублируют друг друга и вместе покрывают нужные темы. При анализе инсайтов после интервью — группировка по MECE помогает не терять важное и не считать одно дважды.
Структура «проблема — как решают сейчас — критерии выбора — готовность платить» — пример: блоки не пересекаются, вместе дают полную картину.
MECE — ориентир, не строгое правило. В реальности границы часто размыты, поэтому важно стремиться к непересекающимся и исчерпывающим категориям там, где от структуры зависят выводы. Где структура условна — допустимы компромиссы.
В сухом остатке: MECE — факторы взаимно исключающие (без пересечений) и совместно исчерпывающие (без пробелов); применяются при сегментации, структуре гайда и анализе результатов интервью — чтобы не дублировать и не терять важное.
#методика@custdevlab #сегментация@custdevlab #mece@custdevlab
MECE (Mutually Exclusive, Collectively Exhaustive) — принцип структурирования в исследованиях: факторы или категории должны быть взаимно исключающими и совместно исчерпывающими. Не пересекаться и не оставлять «дыр».
Взаимно исключающие (ME)
Означает, что каждый элемент, изучаемый в опросе или в интервью, попадает только в одну категорию — пересечений быть не должно. Если делим респондентов по возрасту, то используем следующие интервалы: 18–25, 26–35, 36–45. Если респонденту 30 лет, он относится к одному конкретному сегменту. Если бы варианты ответа пересекались (например, «молодые» и «до 35»), один и тот же человек мог бы оказаться в двух местах — а это путаница в выводах.
То же с причинами отказа от продукта: «дорого» и «не уложился в бюджет» по сути одно и то же; при анализе лучше объединить или разделить чётко.
Совместно исчерпывающие (CE)
Все категории в исследовании вместе покрывают всё исследуемое пространство. Нет «остального» или «прочего», куда попадает непонятно что. Сегментация «клиенты» и «не клиенты» — исчерпывает, если мы говорим о статусе покупки.
«Клиенты», «потенциальные» и «конкуренты» — три основных сегмента для custdev — тоже MECE: любой человек в одной из трёх групп. Если добавлен «прочие» без определения — это разрыв; что в «прочих», непонятно.
Применение MECE в custdev-процедурах
При сегментировании — чёткие критерии без наложения. При разбиении гайда на блоки — вопросы не дублируют друг друга и вместе покрывают нужные темы. При анализе инсайтов после интервью — группировка по MECE помогает не терять важное и не считать одно дважды.
Структура «проблема — как решают сейчас — критерии выбора — готовность платить» — пример: блоки не пересекаются, вместе дают полную картину.
MECE — ориентир, не строгое правило. В реальности границы часто размыты, поэтому важно стремиться к непересекающимся и исчерпывающим категориям там, где от структуры зависят выводы. Где структура условна — допустимы компромиссы.
В сухом остатке: MECE — факторы взаимно исключающие (без пересечений) и совместно исчерпывающие (без пробелов); применяются при сегментации, структуре гайда и анализе результатов интервью — чтобы не дублировать и не терять важное.
#методика@custdevlab #сегментация@custdevlab #mece@custdevlab
2✍2👍2🔥2🌭2
282. Две стратегии продуктовых идей: своё решение vs требования клиента
На этапе Customer Discovery выявляем боли клиента через проблемное интервью. Дальше встаёт вопрос о том, как формулировать решение — и здесь можно выделить два подхода в зависимости от источника идеи. В реальности часто встречаются смешанные варианты.
1. Идея решения от команды. Команда на основе выявленных болей предлагает продукт самостоятельно, не спрашивая клиента о том, каким он видит идеальное решение. Подобное решение часто предполагает значительное изменение модели поведения пользователя: новый способ заказа такси, другая модель подписки, принципиально иной интерфейс. В четырех критериях экспресс-оценки потенциала трансформация модели потребления выделена как отдельный фактор — чем она существеннее, тем сложнее и дороже запуск, но при успехе выше и потенциал отличия от конкурентов. Риск и возможность растут вместе.
2. Идея решения от клиента. Спрашиваем потенциального клиента:
— «Какое решение вы считаете оптимальным?»
— «Что должно быть в продукте?»
В этом случае клиент формулирует требования, и важно понимать ценность такого подхода: клиент указывает на то, что для него важно. Он описывает желаемое, опираясь на то, что уже знает и использует — это осознаваемая модель поведения. «Удобнее», «быстрее», «дешевле» в рамках привычного способа решения проблемы. Оригинальность такого решения может быть невысокой, поскольку клиент мыслит в категориях уже знакомого, а конкуренты слышат от своих клиентов похожие запросы. На уровне идеи конкурентное преимущество может оказаться скромным.
Критерий разделения — источник идеи: команда или клиент. Это разные полюса; на практике чаще используется комбинация (спросили требования, доработали сами). При сочетании обеих стратегий в интервью важно соблюдать порядок вопросов: сначала спрашивать мнение респондента о желаемом решении, о том, что для него важно, и лишь потом расспрашивать об отношении к идеям команды. Иначе получится эффект прайминга — первые вопросы наведут респондента на нужные ответы, и вы услышите не его собственное мнение, а отражение ваших же формулировок.
В сухом остатке: после выявления болей можно опираться на идею от команды (часто меняет модель поведения, выше риск и потенциал отличия) или на требования клиента (клиент указывает, что для него важно; главное — сначала мнение респондента, потом оценка решения команды.
#customerdiscovery@custdevlab #методика@custdevlab #модельповедения@custdevlab
На этапе Customer Discovery выявляем боли клиента через проблемное интервью. Дальше встаёт вопрос о том, как формулировать решение — и здесь можно выделить два подхода в зависимости от источника идеи. В реальности часто встречаются смешанные варианты.
1. Идея решения от команды. Команда на основе выявленных болей предлагает продукт самостоятельно, не спрашивая клиента о том, каким он видит идеальное решение. Подобное решение часто предполагает значительное изменение модели поведения пользователя: новый способ заказа такси, другая модель подписки, принципиально иной интерфейс. В четырех критериях экспресс-оценки потенциала трансформация модели потребления выделена как отдельный фактор — чем она существеннее, тем сложнее и дороже запуск, но при успехе выше и потенциал отличия от конкурентов. Риск и возможность растут вместе.
2. Идея решения от клиента. Спрашиваем потенциального клиента:
— «Какое решение вы считаете оптимальным?»
— «Что должно быть в продукте?»
В этом случае клиент формулирует требования, и важно понимать ценность такого подхода: клиент указывает на то, что для него важно. Он описывает желаемое, опираясь на то, что уже знает и использует — это осознаваемая модель поведения. «Удобнее», «быстрее», «дешевле» в рамках привычного способа решения проблемы. Оригинальность такого решения может быть невысокой, поскольку клиент мыслит в категориях уже знакомого, а конкуренты слышат от своих клиентов похожие запросы. На уровне идеи конкурентное преимущество может оказаться скромным.
Критерий разделения — источник идеи: команда или клиент. Это разные полюса; на практике чаще используется комбинация (спросили требования, доработали сами). При сочетании обеих стратегий в интервью важно соблюдать порядок вопросов: сначала спрашивать мнение респондента о желаемом решении, о том, что для него важно, и лишь потом расспрашивать об отношении к идеям команды. Иначе получится эффект прайминга — первые вопросы наведут респондента на нужные ответы, и вы услышите не его собственное мнение, а отражение ваших же формулировок.
В сухом остатке: после выявления болей можно опираться на идею от команды (часто меняет модель поведения, выше риск и потенциал отличия) или на требования клиента (клиент указывает, что для него важно; главное — сначала мнение респондента, потом оценка решения команды.
#customerdiscovery@custdevlab #методика@custdevlab #модельповедения@custdevlab
4👍2🔥2✍1🌭1
283. «Буду ли я рекомендовать продукт? А зачем мне рекомендовать?»
Вопрос «С какой вероятностью вы порекомендуете продукт?» — основа метрики NPS. Но за ним не следует уточнение: а зачем его рекомендовать? Между тем цель рекомендации определяет и вероятность, и контекст, и то, как этим процессом можно управлять. В B2C и B2B истории разные.
B2C: для чего человек рекомендует
Потребитель рекомендует фильм — чтобы было о чём поговорить за обедом с коллегой, чтобы разделить впечатление, чтобы выглядеть «в теме». Рекомендует ресторан — чтобы друг получил хороший опыт, чтобы подтвердить свой вкус. Рекомендует скидку или промо-код — чтобы помочь сэкономить или продемонстрировать свою осведомлённость.
В каждом случае «работа» рекомендации разная: JTBD-подход предполагает, что рекомендация — это действие, за которым стоит своя цель. Если продукт не даёт пользователю причины рекомендовать (нет выгоды, статуса, эмоции, которой хочется поделиться), вопрос «порекомендуете ли?» повиснет в воздухе. В некоторых категориях рекомендация вообще неуместна или не этична — и тогда NPS вводит в заблуждение.
B2B: ставки другие
В бизнес-контексте рекомендация влияет на профессиональную репутацию. Порекомендовал поставщика коллеге — если всё сложится хорошо, укрепляется доверие; если провалится, страдает репутация. Поэтому в B2B рекомендация осторожнее: её дают, когда уверены в результате или когда выгода от помощи коллеге перевешивает риски.
С другой стороны, успешная рекомендация — способ укрепить отношения, поделиться экспертизой, получить благодарность. В B2B custdev важно понимать: кто в организации может рекомендовать, кому и при каких условиях.
Как управлять процессом рекомендации
В интервью спрашивать не только «порекомендуете ли», но и:
— «Кому бы порекомендовали»
— «В какой ситуации»
— «Что вы при этом получите»
То есть выявлять цель и контекст рекомендации.
Но более важно проектировать продукт и пользовательский опыт так, чтобы у пользователя появлялась естественная причина рекомендовать:
— момент, которым хочется поделиться; выгода от рекомендации (реферальная программа);
— снижение риска для рекомендующего (в B2B — кейсы, гарантии, прозрачность).
Не стоит полагаться на NPS там, где цель рекомендации неочевидна или рекомендация не вписывается в модель поведения категории. Социальное доказательство и рекомендации сильно влияют на выбор — но только когда они уместны и когда у рекомендующего есть мотив.
В сухом остатке: вопрос «буду ли рекомендовать» имеет меньше смысла без «зачем»; чтобы управлять рекомендациями, нужно понимать их цель в интервью и проектировать продукт с учётом мотива рекомендующего.
#nps@custdevlab #b2b@custdevlab #b2c@custdevlab #методика@custdevlab
Вопрос «С какой вероятностью вы порекомендуете продукт?» — основа метрики NPS. Но за ним не следует уточнение: а зачем его рекомендовать? Между тем цель рекомендации определяет и вероятность, и контекст, и то, как этим процессом можно управлять. В B2C и B2B истории разные.
B2C: для чего человек рекомендует
Потребитель рекомендует фильм — чтобы было о чём поговорить за обедом с коллегой, чтобы разделить впечатление, чтобы выглядеть «в теме». Рекомендует ресторан — чтобы друг получил хороший опыт, чтобы подтвердить свой вкус. Рекомендует скидку или промо-код — чтобы помочь сэкономить или продемонстрировать свою осведомлённость.
В каждом случае «работа» рекомендации разная: JTBD-подход предполагает, что рекомендация — это действие, за которым стоит своя цель. Если продукт не даёт пользователю причины рекомендовать (нет выгоды, статуса, эмоции, которой хочется поделиться), вопрос «порекомендуете ли?» повиснет в воздухе. В некоторых категориях рекомендация вообще неуместна или не этична — и тогда NPS вводит в заблуждение.
B2B: ставки другие
В бизнес-контексте рекомендация влияет на профессиональную репутацию. Порекомендовал поставщика коллеге — если всё сложится хорошо, укрепляется доверие; если провалится, страдает репутация. Поэтому в B2B рекомендация осторожнее: её дают, когда уверены в результате или когда выгода от помощи коллеге перевешивает риски.
С другой стороны, успешная рекомендация — способ укрепить отношения, поделиться экспертизой, получить благодарность. В B2B custdev важно понимать: кто в организации может рекомендовать, кому и при каких условиях.
Как управлять процессом рекомендации
В интервью спрашивать не только «порекомендуете ли», но и:
— «Кому бы порекомендовали»
— «В какой ситуации»
— «Что вы при этом получите»
То есть выявлять цель и контекст рекомендации.
Но более важно проектировать продукт и пользовательский опыт так, чтобы у пользователя появлялась естественная причина рекомендовать:
— момент, которым хочется поделиться; выгода от рекомендации (реферальная программа);
— снижение риска для рекомендующего (в B2B — кейсы, гарантии, прозрачность).
Не стоит полагаться на NPS там, где цель рекомендации неочевидна или рекомендация не вписывается в модель поведения категории. Социальное доказательство и рекомендации сильно влияют на выбор — но только когда они уместны и когда у рекомендующего есть мотив.
В сухом остатке: вопрос «буду ли рекомендовать» имеет меньше смысла без «зачем»; чтобы управлять рекомендациями, нужно понимать их цель в интервью и проектировать продукт с учётом мотива рекомендующего.
#nps@custdevlab #b2b@custdevlab #b2c@custdevlab #методика@custdevlab
8👍2🔥2🤔2🌭2
283. Как формулировать гипотезы для CDDC: структура, примеры удачных и неудачных формулировок
Первый блок CDDC — «Гипотеза». От неё зависят метод проверки, респонденты и действия. Размытая гипотеза ведёт к размытым результатам: непонятно, что именно мы проверили и что делать дальше. От этого весь метод CDDC может показаться бесполезным.
Структура хорошей гипотезы
Гипотеза для CDDC должна быть проверяемой и конкретной. Удобный каркас:
Чем яснее сегмент, поведение и условия — тем проще подобрать метод, метрику и респондентов.
Примеры неудачных формулировок:
— «Людям нужен наш продукт» — нет сегмента, нет поведения, не проверить
— «Рынок большой» — что значит «большой», для кого, как измерить?
— «Клиенты готовы платить больше» — кто именно, за что, при каких условиях?
Примеры удачных формулировок:
Связь CDDC с узловыми тестами: большую гипотезу разбиваем на «узлы», каждый узел — отдельная проверяемая гипотеза. Сначала проверяем «есть ли боль», потом «готовы ли платить», потом «какой канал работает». Метрика и бенчмарк для каждой гипотезы — в блоке «Метод проверки».
В сухом остатке: хорошая гипотеза для CDDC — конкретная, проверяемая, с ясным сегментом и условиями; плохая — размытая и не измеряемая. Время на формулировку окупается качеством всего канваса.
#cddc@custdevlab #гипотезы@custdevlab #методика@custdevlab
Первый блок CDDC — «Гипотеза». От неё зависят метод проверки, респонденты и действия. Размытая гипотеза ведёт к размытым результатам: непонятно, что именно мы проверили и что делать дальше. От этого весь метод CDDC может показаться бесполезным.
Структура хорошей гипотезы
Гипотеза для CDDC должна быть проверяемой и конкретной. Удобный каркас:
«Мы предполагаем, что [сегмент] [поведение/потребность/реакция] при [условиях]».
Чем яснее сегмент, поведение и условия — тем проще подобрать метод, метрику и респондентов.
Примеры неудачных формулировок:
— «Людям нужен наш продукт» — нет сегмента, нет поведения, не проверить
— «Рынок большой» — что значит «большой», для кого, как измерить?
— «Клиенты готовы платить больше» — кто именно, за что, при каких условиях?
Примеры удачных формулировок:
«Владельцы малого бизнеса в сфере услуг, которые искали CRM за последний квартал, готовы платить от X рублей в месяц за автоматизацию напоминаний клиентам»
«Родители детей 5–8 лет, которые водят ребёнка на доп. занятия, считают английский приоритетом и готовы тратить на него не менее Y рублей в месяц»
«Пользователи, установившие приложение по рекламе в соцсетях, при стоимости привлечения до 60 руб. конвертируются в платящих не менее чем в 5% случаев»
Связь CDDC с узловыми тестами: большую гипотезу разбиваем на «узлы», каждый узел — отдельная проверяемая гипотеза. Сначала проверяем «есть ли боль», потом «готовы ли платить», потом «какой канал работает». Метрика и бенчмарк для каждой гипотезы — в блоке «Метод проверки».
В сухом остатке: хорошая гипотеза для CDDC — конкретная, проверяемая, с ясным сегментом и условиями; плохая — размытая и не измеряемая. Время на формулировку окупается качеством всего канваса.
#cddc@custdevlab #гипотезы@custdevlab #методика@custdevlab
7👍3✍2🌭2
284. Блок «Респонденты» в CDDC: как описывать, кого искать и где
Третий блок канваса CDDC — «Респонденты». Он отвечает на два вопроса: кого мы исследуем и где их ищем. На практике здесь одна из самых частых ошибок: размытое описание, неверный сегмент, нереалистичные источники.
Как описывать респондентов
Не «потенциальные клиенты» или «все, кому интересно», а конкретные критерии: кто по поведению, демографии, ситуации. Чем точнее описание, тем понятнее, куда идти за респондентами. Например: «владельцы малого бизнеса в сфере услуг, которые за последние 3 месяца выбирали CRM» — это хорошее описание. «Предприниматели» — плохое.
Связь с сегментацией
Блок «Респонденты» — это применение критериев сегментирования: социально-демографических, поведенческих, психографических. На этапе Discovery сегмент часто размыт — и это нормально. Но уже на втором шаге мы уточняем гипотезу о сегменте и проверяем её. Валидация сегментов — часть CDDC: каждый шаг может подтвердить или скорректировать, с кем мы работаем.
Где искать
Зависит от сегмента и этапа. Существующие клиенты — для понимания удержания и опыта. Те, кто в процессе выбора, — самый ценный сегмент для привлечения новых клиентов. Три основных сегмента: наши клиенты, клиенты конкурентов, те, кто выбирает. Для каждого — свои каналы: база, входящий трафик, группы и сообщества, холодный рекрутинг. Анкета для отбора помогает фильтровать респондентов до интервью.
В сухом остатке: чёткие критерии «кого» и «где» связывают гипотезу с реальными людьми и повышают ценность каждого шага проверки.
#cddc@custdevlab #респонденты@custdevlab #сегментация@custdevlab
Третий блок канваса CDDC — «Респонденты». Он отвечает на два вопроса: кого мы исследуем и где их ищем. На практике здесь одна из самых частых ошибок: размытое описание, неверный сегмент, нереалистичные источники.
Как описывать респондентов
Не «потенциальные клиенты» или «все, кому интересно», а конкретные критерии: кто по поведению, демографии, ситуации. Чем точнее описание, тем понятнее, куда идти за респондентами. Например: «владельцы малого бизнеса в сфере услуг, которые за последние 3 месяца выбирали CRM» — это хорошее описание. «Предприниматели» — плохое.
Связь с сегментацией
Блок «Респонденты» — это применение критериев сегментирования: социально-демографических, поведенческих, психографических. На этапе Discovery сегмент часто размыт — и это нормально. Но уже на втором шаге мы уточняем гипотезу о сегменте и проверяем её. Валидация сегментов — часть CDDC: каждый шаг может подтвердить или скорректировать, с кем мы работаем.
Где искать
Зависит от сегмента и этапа. Существующие клиенты — для понимания удержания и опыта. Те, кто в процессе выбора, — самый ценный сегмент для привлечения новых клиентов. Три основных сегмента: наши клиенты, клиенты конкурентов, те, кто выбирает. Для каждого — свои каналы: база, входящий трафик, группы и сообщества, холодный рекрутинг. Анкета для отбора помогает фильтровать респондентов до интервью.
В сухом остатке: чёткие критерии «кого» и «где» связывают гипотезу с реальными людьми и повышают ценность каждого шага проверки.
#cddc@custdevlab #респонденты@custdevlab #сегментация@custdevlab
4✍3👍3🌭2
285. Блок «Действия» в CDDC: как формулировать шаги, чек-лист и типичные упущения
Четвёртый блок CDDC — «Действия». Что именно нужно сделать, чтобы получить результат проверки гипотезы. Часто его заполняют в последнюю очередь и общими фразами: «провести интервью», «запустить трафик». В итоге шаг висит в воздухе — непонятно, кто, когда и как его выполняет.
Как формулировать действия
Каждое действие должно быть конкретным и выполнимым. Вместо «провести 10 интервью» — «составить гайд на основе гипотезы; отобрать 15 респондентов по анкете; провести 10 интервью по 45–60 минут; зафиксировать выводы в таблице». Чем детальнее, тем меньше вопросов при выполнении. Действия стоит привязывать к метрике: что мы делаем, чтобы её получить.
Чек-лист для блока «Действия»:
— Подготовка: гайд, анкета отбора, скрипт (если нужен)
— Рекрутинг: каналы, объявление, критерии отбора
— Проведение: сроки, ответственные, формат (онлайн/офлайн) — Обработка: фиксация результатов, сравнение с бенчмарком
— Решение: критерий «подтверждено / не подтверждено» и следующие шаги
Что часто упускают
Не прописывают подготовку — и выходят на интервью без гайда. Не закладывают время на рекрутинг — он всегда дольше, чем кажется. Забывают про обработку — интервью проведены, а выводы не сформулированы. Не определяют критерий успеха заранее — потом трудно понять, подтвердилась гипотеза или нет.
В сухом остатке: блок «Действия» превращает гипотезу в выполнимый план; конкретные шаги, чек-лист и учёт типичных упущений снижают риск «провели, но ничего не получили».
#cddc@custdevlab #действия@custdevlab #методика@custdevlab
Четвёртый блок CDDC — «Действия». Что именно нужно сделать, чтобы получить результат проверки гипотезы. Часто его заполняют в последнюю очередь и общими фразами: «провести интервью», «запустить трафик». В итоге шаг висит в воздухе — непонятно, кто, когда и как его выполняет.
Как формулировать действия
Каждое действие должно быть конкретным и выполнимым. Вместо «провести 10 интервью» — «составить гайд на основе гипотезы; отобрать 15 респондентов по анкете; провести 10 интервью по 45–60 минут; зафиксировать выводы в таблице». Чем детальнее, тем меньше вопросов при выполнении. Действия стоит привязывать к метрике: что мы делаем, чтобы её получить.
Чек-лист для блока «Действия»:
— Подготовка: гайд, анкета отбора, скрипт (если нужен)
— Рекрутинг: каналы, объявление, критерии отбора
— Проведение: сроки, ответственные, формат (онлайн/офлайн) — Обработка: фиксация результатов, сравнение с бенчмарком
— Решение: критерий «подтверждено / не подтверждено» и следующие шаги
Что часто упускают
Не прописывают подготовку — и выходят на интервью без гайда. Не закладывают время на рекрутинг — он всегда дольше, чем кажется. Забывают про обработку — интервью проведены, а выводы не сформулированы. Не определяют критерий успеха заранее — потом трудно понять, подтвердилась гипотеза или нет.
В сухом остатке: блок «Действия» превращает гипотезу в выполнимый план; конкретные шаги, чек-лист и учёт типичных упущений снижают риск «провели, но ничего не получили».
#cddc@custdevlab #действия@custdevlab #методика@custdevlab
4✍3👍2🌭2
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
На вопросы 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
4✍4👍4🌭3
287. Рекламная бизнес-модель продукта: unit-экономика и пороги по числу пользователей
Рекламная модель живёт за счёт большого числа пользователей. Unit здесь — показ рекламы:
Чем больше аудитория и её вовлечённость, тем больше показов и дохода.
Unit-экономика рекламной модели
CPM в РФ (по данным click.ru на окт. 2024): для соцсетей и медийки — порядка 65–250 рублей за 1000 показов (myTarget ~66 ₽, VK Ads ~97 ₽, Яндекс.Сети ~110 ₽, маркетплейсы в среднем ~237 ₽). Для выручки 100 млн рублей в год нужно порядка 400 млн – 1 млрд показов, а это означает сотни тысяч или около миллиона активных пользователей в месяц при высокой вовлечённости.
Пороги по аудитории
В аналитике и практике часто говорят о порогах для venture-scale рекламного продукта: 10+ млн MAU как минимальный уровень для серьёзной монетизации.
Freemium/рекламные модели в массовом потребительском интернете обычно требуют 50+ млн активных пользователей для устойчивой экономики.
Меньшие рынки и ниши
На более узких рынках порог ниже. При высоком CPM (таргет, B2B, специализированная аудитория) или локальном рынке 1 млн MAU уже может давать осмысленную выручку — при условии, что вовлечённость и ценность аудитории для рекламодателей высоки. Масштаб компенсируется ценой показа.
В сухом остатке: рекламная модель строится на большом числе пользователей и показах; массовый продукт — десятки миллионов MAU; ниша с высоким CPM — от ~1 млн MAU при сильной вовлечённости и ценности аудитории.
#бизнесмодель@custdevlab #реклама@custdevlab #unitэкономика@custdevlab #метрики@custdevlab
Рекламная модель живёт за счёт большого числа пользователей. 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
4✍4👍3🌭2
Собрали для удобства в одном посте все посты про 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
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
4🔥5🌭3✍2👍1👎1
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
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
1👍6✍3🌭3🔥1
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
В продукте и стартапе метрик много: выручка, трафик, конверсия, удержание, 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
6👍6✍4🌭2🔥1
290. Система метрик — как не потеряться в показателях
В продукте и в custdev метрик много: одни описывают процесс, другие — результат, третьи — влияние на бизнес. Если мерить всё подряд, легко утонуть в цифрах и не понять, что именно улучшать. Поэтому имеет смысл выстраивать систему метрик: разделять уровни и связывать их с решениями.
Три уровня метрик
Удобная схема — трехуровневая модель (она используется, в частности, при оценке эффективности customer development):
1. Метрики процесса — что и сколько мы делаем.
Количество интервью, опросов, респондентов; охват сегментов; регулярность исследований. Эти показатели отвечают на вопрос «достаточно ли мы вообще кастдевим?», но не говорят о качестве и отдаче. Без них непонятно, насколько систематична работа; зацикливаться только на них — ошибка.
2. Метрики результата — что мы узнали и проверили.
Количество и качество инсайтов, сформулированные и валидированные гипотезы, скорость валидации, глубина понимания ЦА. В CDDC у каждого шага есть блок «метод проверки» с метрикой и бенчмарком: с чем сравниваем результат, что считаем успехом. Выбор метрики и бенчмарка для проверки гипотез — одна из самых важных задач: неправильная метрика равна непроверенной гипотезе. В HADI данные (Data) — это в том числе метрики, по которым мы решаем, подтверждена гипотеза или нет.
3. Метрики бизнес-влияния — как изменились ключевые показатели продукта.
Влияние на трафик, конверсию, средний чек, частоту покупок, удержание; в итоге — на выручку. Выручка раскладывается на трафик × конверсия × средний чек × частота покупок; custdev и продукт в конечном счёте должны двигать именно эти метрики. Связь «интервью → инсайт → изменение продукта → рост конверсии» не всегда прямая, но без уровня бизнес-влияния мы не видим, окупается ли наша работа.
Одна главная vs множество метрик
North Star Metric — одна метрика, которая лучше всего отражает ценность для клиента и разгон бизнеса. Она не отменяет остальные: система метрик описывает процесс и результат на разных уровнях, а North Star задаёт фокус, чтобы не оптимизировать второстепенное в ущерб главному. При этом у продукта всегда есть целевые и побочные метрики: запуская фичу, мы ждём целевой эффект, но учитываем и побочные — и со временем доля «шума» может снижаться.
В сухом остатке: система метрик помогает не путать «сколько мы сделали» (процесс), «что узнали и проверили» (результат) и «как изменился бизнес» (влияние). Метрики процесса и результата нужны для управления custdev и гипотезами; метрики бизнес-влияния — чтобы понимать отдачу. Одна North Star задаёт фокус; остальные уровни — чтобы не потеряться в показателях.
#метрики@custdevlab #custdev@custdevlab #методика@custdevlab
В продукте и в custdev метрик много: одни описывают процесс, другие — результат, третьи — влияние на бизнес. Если мерить всё подряд, легко утонуть в цифрах и не понять, что именно улучшать. Поэтому имеет смысл выстраивать систему метрик: разделять уровни и связывать их с решениями.
Три уровня метрик
Удобная схема — трехуровневая модель (она используется, в частности, при оценке эффективности customer development):
1. Метрики процесса — что и сколько мы делаем.
Количество интервью, опросов, респондентов; охват сегментов; регулярность исследований. Эти показатели отвечают на вопрос «достаточно ли мы вообще кастдевим?», но не говорят о качестве и отдаче. Без них непонятно, насколько систематична работа; зацикливаться только на них — ошибка.
2. Метрики результата — что мы узнали и проверили.
Количество и качество инсайтов, сформулированные и валидированные гипотезы, скорость валидации, глубина понимания ЦА. В CDDC у каждого шага есть блок «метод проверки» с метрикой и бенчмарком: с чем сравниваем результат, что считаем успехом. Выбор метрики и бенчмарка для проверки гипотез — одна из самых важных задач: неправильная метрика равна непроверенной гипотезе. В HADI данные (Data) — это в том числе метрики, по которым мы решаем, подтверждена гипотеза или нет.
3. Метрики бизнес-влияния — как изменились ключевые показатели продукта.
Влияние на трафик, конверсию, средний чек, частоту покупок, удержание; в итоге — на выручку. Выручка раскладывается на трафик × конверсия × средний чек × частота покупок; custdev и продукт в конечном счёте должны двигать именно эти метрики. Связь «интервью → инсайт → изменение продукта → рост конверсии» не всегда прямая, но без уровня бизнес-влияния мы не видим, окупается ли наша работа.
Одна главная vs множество метрик
North Star Metric — одна метрика, которая лучше всего отражает ценность для клиента и разгон бизнеса. Она не отменяет остальные: система метрик описывает процесс и результат на разных уровнях, а North Star задаёт фокус, чтобы не оптимизировать второстепенное в ущерб главному. При этом у продукта всегда есть целевые и побочные метрики: запуская фичу, мы ждём целевой эффект, но учитываем и побочные — и со временем доля «шума» может снижаться.
В сухом остатке: система метрик помогает не путать «сколько мы сделали» (процесс), «что узнали и проверили» (результат) и «как изменился бизнес» (влияние). Метрики процесса и результата нужны для управления custdev и гипотезами; метрики бизнес-влияния — чтобы понимать отдачу. Одна North Star задаёт фокус; остальные уровни — чтобы не потеряться в показателях.
#метрики@custdevlab #custdev@custdevlab #методика@custdevlab
2✍3👍3🤔1
291. Мини-шпаргалка: методы исследований — что к чему
Коллеги из Центра дизайн-мышления собрали интересный контент: какой тип метода исследований для какой задачи и на каком этапе продукта обычно уместен. Это не жёсткие правила, а скорее ориентир, с чего начать выбор нужного метода и спроектировать дизайн исследования.
1️⃣ Качественные методы
Глубокое погружение в мотивы, ожидания и контекст: ответы на «почему так?» и «как человек это переживает?», а не на «сколько процентов».
Когда чаще всего применяют
— Стадия «Проблема» — искать реальные боли, барьеры и язык пользователя до того, как вы жёстко зафиксировали решение.
— Стадия «Концепция» — проверять идеи, сценарии, прототипы: достаточно ли они резонируют с тем, как люди живут задачу.
Инструменты
Глубинные интервью, фокус-группы, контекстное наблюдение, карты сортировки (card sorting).
2️⃣ Количественные методы
Сбор цифр и проверка гипотез в масштабе: «сколько?», «как часто?», «насколько сильно сдвинулась метрика после изменения?».
Когда чаще всего применяют
— Стадия «Разработка» — зафиксировать базовые показатели, когда продукт уже в руках у пользователей.
— Стадия «Оптимизация» — сравнивать варианты и понимать, что реально двигает метрики, а что шум.
Инструменты
Опросы и анкеты, веб-аналитика (Яндекс.Метрика и аналоги), A/B-тесты, коридорки (короткие тесты первого впечатления — например, пятисекундный тест).
3️⃣ Смешанные методы
Сочетание «качества» и «количества»: и цифры, и объяснение, почему цифры такие — удобно перед крупными решениями.
Когда чаще всего применяют
— Финальное тестирование прототипа или пилота перед широким релизом.
— Приоритизация фич и дорожной карты, когда нужны и приоритеты по данным, и понимание «зачем это пользователю».
Инструменты
Удалённые немодерируемые юзабилити-тесты (без ведущего), бета-тесты и пилотные запуски, опрос по модели Кано (базовые / ожидаемые / «вау»-характеристики).
Как выбрать метод
Сформулируйте вопрос исследования: что нужно узнать — смысл и контекст («почему?»), масштаб и измеримость («сколько?») или все сразу.
Оцените ресурсы: время, бюджет, доступ к респондентам и возможность дотянуться до «живых» пользователей.
На сложных вопросах не бойтесь комбинировать: качество подсказывает направление, количество — проверяет масштаб.
Про стадии разработки продукта
Названия «Проблема → Концепция → Разработка → Оптимизация» — это упрощённая воронка жизненного цикла продукта, к которой часто относят исследования в курсах и статьях.
По смыслу она близка к связке discovery / delivery: сначала понять проблему и проверить идею решения, потом строить рабочую версию и измерять, затем улучшать то, что уже в поле.
Пересекается с логикой Lean Startup (поиск проблемы и решения → продукт с пользователями → итерации по данным) и с фазами в stage-gate и дорожных картах, но названия у разных авторов могут отличаться (например, «дизайн-спринт / прототип» вместо «концепция»). Если у вас в компании свои названия этапов — просто подставьте свои: важнее тип вопроса («почему» vs «сколько»), чем этикетка на слайде.
В сухом остатке: на ранних этапах (проблема, концепция) применяют качественные методы, которые отвечают на вопрос «почему» и «как думает пользователь»; когда продукт уже в поле и нужны метрики и сравнение вариантов — количественные отвечают на вопросы «сколько» и «что изменилось»; смешанные методы нужны, когда перед крупным решением нужны и глубина, и цифры.
#методика@custdevlab #исследования@custdevlab #полезное@custdevlab #цдм@custdevlab
Коллеги из Центра дизайн-мышления собрали интересный контент: какой тип метода исследований для какой задачи и на каком этапе продукта обычно уместен. Это не жёсткие правила, а скорее ориентир, с чего начать выбор нужного метода и спроектировать дизайн исследования.
1️⃣ Качественные методы
Глубокое погружение в мотивы, ожидания и контекст: ответы на «почему так?» и «как человек это переживает?», а не на «сколько процентов».
Когда чаще всего применяют
— Стадия «Проблема» — искать реальные боли, барьеры и язык пользователя до того, как вы жёстко зафиксировали решение.
— Стадия «Концепция» — проверять идеи, сценарии, прототипы: достаточно ли они резонируют с тем, как люди живут задачу.
Инструменты
Глубинные интервью, фокус-группы, контекстное наблюдение, карты сортировки (card sorting).
2️⃣ Количественные методы
Сбор цифр и проверка гипотез в масштабе: «сколько?», «как часто?», «насколько сильно сдвинулась метрика после изменения?».
Когда чаще всего применяют
— Стадия «Разработка» — зафиксировать базовые показатели, когда продукт уже в руках у пользователей.
— Стадия «Оптимизация» — сравнивать варианты и понимать, что реально двигает метрики, а что шум.
Инструменты
Опросы и анкеты, веб-аналитика (Яндекс.Метрика и аналоги), A/B-тесты, коридорки (короткие тесты первого впечатления — например, пятисекундный тест).
3️⃣ Смешанные методы
Сочетание «качества» и «количества»: и цифры, и объяснение, почему цифры такие — удобно перед крупными решениями.
Когда чаще всего применяют
— Финальное тестирование прототипа или пилота перед широким релизом.
— Приоритизация фич и дорожной карты, когда нужны и приоритеты по данным, и понимание «зачем это пользователю».
Инструменты
Удалённые немодерируемые юзабилити-тесты (без ведущего), бета-тесты и пилотные запуски, опрос по модели Кано (базовые / ожидаемые / «вау»-характеристики).
Как выбрать метод
Сформулируйте вопрос исследования: что нужно узнать — смысл и контекст («почему?»), масштаб и измеримость («сколько?») или все сразу.
Оцените ресурсы: время, бюджет, доступ к респондентам и возможность дотянуться до «живых» пользователей.
На сложных вопросах не бойтесь комбинировать: качество подсказывает направление, количество — проверяет масштаб.
Про стадии разработки продукта
Названия «Проблема → Концепция → Разработка → Оптимизация» — это упрощённая воронка жизненного цикла продукта, к которой часто относят исследования в курсах и статьях.
По смыслу она близка к связке discovery / delivery: сначала понять проблему и проверить идею решения, потом строить рабочую версию и измерять, затем улучшать то, что уже в поле.
Пересекается с логикой Lean Startup (поиск проблемы и решения → продукт с пользователями → итерации по данным) и с фазами в stage-gate и дорожных картах, но названия у разных авторов могут отличаться (например, «дизайн-спринт / прототип» вместо «концепция»). Если у вас в компании свои названия этапов — просто подставьте свои: важнее тип вопроса («почему» vs «сколько»), чем этикетка на слайде.
В сухом остатке: на ранних этапах (проблема, концепция) применяют качественные методы, которые отвечают на вопрос «почему» и «как думает пользователь»; когда продукт уже в поле и нужны метрики и сравнение вариантов — количественные отвечают на вопросы «сколько» и «что изменилось»; смешанные методы нужны, когда перед крупным решением нужны и глубина, и цифры.
#методика@custdevlab #исследования@custdevlab #полезное@custdevlab #цдм@custdevlab
3👍9✍7🌭4
292. «Нужный» параметр товара: противоударный телефон
Противоударный телефон — продукт с понятным параметром. Но продажи у таких устройств часто небольшие. Потому что противоударность важна не всем. Для большинства покупателей это совершенно не главный критерий выбора продукта.
При покупке телефона люди в первую очередь смотрят на базовые вещи: экран, камера, производительность, автономность, цена. Эти параметры важны почти для всех в категории. Противоударность же — специфическая потребность: строители, спортсмены, работники в сложных условиях, родители активных детей. Этот сегмент уже, чем «все, кто покупает телефон».
Если продукт позиционируется только как противоударный, он обращается к узкой аудитории, тем сложнее масштабировать продажи.
Успешный продукт в этой нише работает иначе: он решает основные задачи категории для большинства и при этом обладает противоударностью. То есть сначала продукт должен быть хорошим телефоном — с теми функциями, которые ждут в категории, а противоударность становится дополнительным преимуществом для тех, кому это важно, и не мешает остальным. Потребитель не жертвует «обычным» функционалом ради одной особенности.
Тот же принцип применим к другим параметрам: влагозащита, расширенная батарея, особо прочный экран. Если характеристика важна только части аудитории, она не может быть единственным основанием для позиционирования продукта. Ценностное предложение строится на том, что нужно потребителю и чего нет у конкурентов — но базовый набор ожиданий категории должен выполняться.
В сухом остатке: параметр, важный не для всех, не должен быть основой позиционирования, если не закрывает основные потребности большинства потребителей.
#продукт@custdevlab #ценностноепредложение@custdevlab #методика@custdevlab
Противоударный телефон — продукт с понятным параметром. Но продажи у таких устройств часто небольшие. Потому что противоударность важна не всем. Для большинства покупателей это совершенно не главный критерий выбора продукта.
При покупке телефона люди в первую очередь смотрят на базовые вещи: экран, камера, производительность, автономность, цена. Эти параметры важны почти для всех в категории. Противоударность же — специфическая потребность: строители, спортсмены, работники в сложных условиях, родители активных детей. Этот сегмент уже, чем «все, кто покупает телефон».
Если продукт позиционируется только как противоударный, он обращается к узкой аудитории, тем сложнее масштабировать продажи.
Успешный продукт в этой нише работает иначе: он решает основные задачи категории для большинства и при этом обладает противоударностью. То есть сначала продукт должен быть хорошим телефоном — с теми функциями, которые ждут в категории, а противоударность становится дополнительным преимуществом для тех, кому это важно, и не мешает остальным. Потребитель не жертвует «обычным» функционалом ради одной особенности.
Тот же принцип применим к другим параметрам: влагозащита, расширенная батарея, особо прочный экран. Если характеристика важна только части аудитории, она не может быть единственным основанием для позиционирования продукта. Ценностное предложение строится на том, что нужно потребителю и чего нет у конкурентов — но базовый набор ожиданий категории должен выполняться.
В сухом остатке: параметр, важный не для всех, не должен быть основой позиционирования, если не закрывает основные потребности большинства потребителей.
#продукт@custdevlab #ценностноепредложение@custdevlab #методика@custdevlab
🔥2👍1🤔1