262. Фильтры и боязнь потерять содержание
Чем больше фильтров, позволяющих отсортировать продукт заранее, тем выше опасение пользователя, что что‑то важное упущено.
Человек не видит полной картины: он сужает выбор до того, как успел понять полный набор вариантов. Вопрос «А что я отфильтровал?» остаётся в голове. Получается парадокс: фильтры должны упрощать выбор, а вместо этого усиливают тревогу — вдруг нужное как раз за бортом.
Помогает разворот логики: сначала показываем всё, что есть, например в каталоге, а уже потом даём возможность выбрать нужное. Пользователь видит объём выбора, понимает, с чем имеет дело, и только после этого сужает — фильтрами, сортировкой, поиском. У него есть опора: «я видел всё», а не «я отрезал кусок, не зная целого». Страх что‑то упустить снижается.
Это не значит, что фильтры не нужны. Нужны — но как второй шаг. Сначала «всё, что есть», потом «отсечь лишнее и выбрать своё». Порядок меняет переживание: не «боюсь пропустить», а «я уже видел, теперь отбираю».
Как быть с бесконечной полкой на маркетплейсах? Там априори невозможно увидеть всё: каталог огромен, ассортимент пополняется. «Показать всё» не сработает. В таком случае «всё» — это не каждый товар, а структура предложения: категории, типы, границы каталога. Задача — дать пользователю карту пространства выбора.
Он не просмотрим все позиции, но поймет, что есть, где искать, какие бывают варианты. Сначала — обзор структуры (категории, подкатегории, «что бывает»), потом сужение внутри уже понятного пространства. Фильтры тогда не отрезают неизвестный кусок, а помогают двигаться по карте, которую пользователь уже в общих чертах видел.
В сухом остатке: чем больше предварительных фильтров, тем сильнее боязнь потерять содержание. Лучше сначала показывать всё, что есть (или структуру каталога, если «всё» невозможно), затем давать сужать выбор — так пользователь опирается на обзор или на карту пространства, а не на неизвестный «отфильтрованный» кусок.
#ux@custdevlab #выбор@custdevlab #полезное@custdevlab
Чем больше фильтров, позволяющих отсортировать продукт заранее, тем выше опасение пользователя, что что‑то важное упущено.
Человек не видит полной картины: он сужает выбор до того, как успел понять полный набор вариантов. Вопрос «А что я отфильтровал?» остаётся в голове. Получается парадокс: фильтры должны упрощать выбор, а вместо этого усиливают тревогу — вдруг нужное как раз за бортом.
Помогает разворот логики: сначала показываем всё, что есть, например в каталоге, а уже потом даём возможность выбрать нужное. Пользователь видит объём выбора, понимает, с чем имеет дело, и только после этого сужает — фильтрами, сортировкой, поиском. У него есть опора: «я видел всё», а не «я отрезал кусок, не зная целого». Страх что‑то упустить снижается.
Это не значит, что фильтры не нужны. Нужны — но как второй шаг. Сначала «всё, что есть», потом «отсечь лишнее и выбрать своё». Порядок меняет переживание: не «боюсь пропустить», а «я уже видел, теперь отбираю».
Как быть с бесконечной полкой на маркетплейсах? Там априори невозможно увидеть всё: каталог огромен, ассортимент пополняется. «Показать всё» не сработает. В таком случае «всё» — это не каждый товар, а структура предложения: категории, типы, границы каталога. Задача — дать пользователю карту пространства выбора.
Он не просмотрим все позиции, но поймет, что есть, где искать, какие бывают варианты. Сначала — обзор структуры (категории, подкатегории, «что бывает»), потом сужение внутри уже понятного пространства. Фильтры тогда не отрезают неизвестный кусок, а помогают двигаться по карте, которую пользователь уже в общих чертах видел.
В сухом остатке: чем больше предварительных фильтров, тем сильнее боязнь потерять содержание. Лучше сначала показывать всё, что есть (или структуру каталога, если «всё» невозможно), затем давать сужать выбор — так пользователь опирается на обзор или на карту пространства, а не на неизвестный «отфильтрованный» кусок.
#ux@custdevlab #выбор@custdevlab #полезное@custdevlab
2👍3🌭3✍2
263. Зачем нужен элемент «информация» в гайде для customer interview
В посте про два подхода к гайду мы писали: можно двигаться от решения к вопросам или от вопросов к решению. В обоих случаях в гайде есть точка назначения — та проблема продукта, которую нужно решить, или то решение, которое нужно обосновать. Но от начала интервью до этой точки путь не прямой. Задаются вопросы, слушается, уточняется. Легко уйти в сторону: респондент увлёкся темой, интересная мысль подхватывается — и вот уже собирается то, что не ведёт к цели. Промежуточный элемент в гайде помогает не сбиться с пути.
Промежуточный элемент — это явное указание: какую информацию собирают на этом участке гайда. Не только «о чём спрашивают», а «что в итоге должно оказаться среди записей». Например: «как человек сегодня решает задачу», «какие альтернативы рассматривает», «что для него триггер перехода к действию», «какие возражения останавливают». Это формулируют до интервью и держат в голове (или в гайде) во время разговора. Получается череда шагов: сначала собирается информация А, потом — Б, и только затем выходят к проблеме продукта или к решению, которое нужно валидировать.
Можно вести интервью по списку вопросов без явных «информационных» блоков — и всё равно добраться до цели, если есть опыт. Но если ещё нет привычки уверенно вести разговор и не сбиваться, промежуточный элемент в гайде работает как ориентир. Сверяются: сейчас собирают то, что задумали, или уже ушли в сторону? Если ушли в сторону — разговор возвращают к нужным темам. Так не теряется время на красивый, но бесполезный для продуктовой задачи разговор и не забывается, ради чего вообще вышли на интервью.
В сухом остатке: промежуточный элемент в гайде — явное «информацию, которую собирают» на каждом участке. Он не обязателен, но помогает не сбиться с пути, пока не дошли до проблемы продукта или решения, которые нужно проверить.
#customerinterview@custdevlab #методика@custdevlab #гайд@custdevlab
В посте про два подхода к гайду мы писали: можно двигаться от решения к вопросам или от вопросов к решению. В обоих случаях в гайде есть точка назначения — та проблема продукта, которую нужно решить, или то решение, которое нужно обосновать. Но от начала интервью до этой точки путь не прямой. Задаются вопросы, слушается, уточняется. Легко уйти в сторону: респондент увлёкся темой, интересная мысль подхватывается — и вот уже собирается то, что не ведёт к цели. Промежуточный элемент в гайде помогает не сбиться с пути.
Промежуточный элемент — это явное указание: какую информацию собирают на этом участке гайда. Не только «о чём спрашивают», а «что в итоге должно оказаться среди записей». Например: «как человек сегодня решает задачу», «какие альтернативы рассматривает», «что для него триггер перехода к действию», «какие возражения останавливают». Это формулируют до интервью и держат в голове (или в гайде) во время разговора. Получается череда шагов: сначала собирается информация А, потом — Б, и только затем выходят к проблеме продукта или к решению, которое нужно валидировать.
Можно вести интервью по списку вопросов без явных «информационных» блоков — и всё равно добраться до цели, если есть опыт. Но если ещё нет привычки уверенно вести разговор и не сбиваться, промежуточный элемент в гайде работает как ориентир. Сверяются: сейчас собирают то, что задумали, или уже ушли в сторону? Если ушли в сторону — разговор возвращают к нужным темам. Так не теряется время на красивый, но бесполезный для продуктовой задачи разговор и не забывается, ради чего вообще вышли на интервью.
В сухом остатке: промежуточный элемент в гайде — явное «информацию, которую собирают» на каждом участке. Он не обязателен, но помогает не сбиться с пути, пока не дошли до проблемы продукта или решения, которые нужно проверить.
#customerinterview@custdevlab #методика@custdevlab #гайд@custdevlab
4🔥4🌭3✍2👍1
264. Офбординг — наиболее недооцененный этап LXM
В LXM офбординг — последний этап: плавный выход из продукта. Но после него путь не обрывается. Человек переходит к началу LXM для товарной категории — снова триггер, пассивный и активный поиск, выбор альтернативы, решение, покупка, онбординг, использование, офбординг. Цикл замыкается на уровне опыта жизненных сценариев: поведение в категории, выбор между продуктами, без привязки к одному решению.
Офбординг одного продукта — точка, после которой человек оказывается «на рынке» снова и может в следующий раз выбрать другой продукт или вернуться к тому же. Иногда товарами-конкурентами пользуются параллельно: использование одного продукта не исключает использование другого (как в случае онлайн-кинотеатров — выбор контента в одном сервисе, просмотр в другом). В этом случае удобный офбординг одного продукта может в долгосрочной перспективе быть конкурентным преимуществом (если причина была не в низкой удовлетворенности).
Поэтому важная задача офбординга — не только корректно завершить использование, но и оставить возможность и желание вернуться. Если выход был простым и без неприятных сюрпризов, последнее впечатление остаётся позитивным; если выход усложняли ради метрик, запоминается именно это.
Здесь возникает trade-off. Более простой офбординг — лёгкий выход из продукта — приводит к тому, что людям проще отказаться от продукта. Удержание и LTV могут снизиться: часть пользователей уйдёт быстрее, чем при запутанном процессе отписки или отмены. Многие сервисы делают наоборот: усложняют офбординг именно ради экономических показателей. Но если офбординг упростить, опыт пользователя в конце пути становится более положительным. Человек запоминает, что продуктом было просто пользоваться и просто из него выйти — низкие усилия, низкий CES.
По правилу последнего впечатления именно финальный опыт сильно влияет на общую оценку: продукт остаётся в памяти как простой и предсказуемый, а не как ловушка. Это влияет на метрики с другой стороны — репутация, возвраты, рекомендации.
В сухом остатке: офбординг — последний этап LXM, после него человек возвращается к началу цикла в товарной категории; более простой офбординг может снизить LTV и удержание, но улучшает последнее впечатление и запоминание продукта как простого (связь с CES и правилом последнего впечатления).
#lxm@custdevlab #офбординг@custdevlab #опыт@custdevlab #полезное@custdevlab
В LXM офбординг — последний этап: плавный выход из продукта. Но после него путь не обрывается. Человек переходит к началу LXM для товарной категории — снова триггер, пассивный и активный поиск, выбор альтернативы, решение, покупка, онбординг, использование, офбординг. Цикл замыкается на уровне опыта жизненных сценариев: поведение в категории, выбор между продуктами, без привязки к одному решению.
Офбординг одного продукта — точка, после которой человек оказывается «на рынке» снова и может в следующий раз выбрать другой продукт или вернуться к тому же. Иногда товарами-конкурентами пользуются параллельно: использование одного продукта не исключает использование другого (как в случае онлайн-кинотеатров — выбор контента в одном сервисе, просмотр в другом). В этом случае удобный офбординг одного продукта может в долгосрочной перспективе быть конкурентным преимуществом (если причина была не в низкой удовлетворенности).
Поэтому важная задача офбординга — не только корректно завершить использование, но и оставить возможность и желание вернуться. Если выход был простым и без неприятных сюрпризов, последнее впечатление остаётся позитивным; если выход усложняли ради метрик, запоминается именно это.
Здесь возникает trade-off. Более простой офбординг — лёгкий выход из продукта — приводит к тому, что людям проще отказаться от продукта. Удержание и LTV могут снизиться: часть пользователей уйдёт быстрее, чем при запутанном процессе отписки или отмены. Многие сервисы делают наоборот: усложняют офбординг именно ради экономических показателей. Но если офбординг упростить, опыт пользователя в конце пути становится более положительным. Человек запоминает, что продуктом было просто пользоваться и просто из него выйти — низкие усилия, низкий CES.
По правилу последнего впечатления именно финальный опыт сильно влияет на общую оценку: продукт остаётся в памяти как простой и предсказуемый, а не как ловушка. Это влияет на метрики с другой стороны — репутация, возвраты, рекомендации.
В сухом остатке: офбординг — последний этап LXM, после него человек возвращается к началу цикла в товарной категории; более простой офбординг может снизить LTV и удержание, но улучшает последнее впечатление и запоминание продукта как простого (связь с CES и правилом последнего впечатления).
#lxm@custdevlab #офбординг@custdevlab #опыт@custdevlab #полезное@custdevlab
5👍4✍3🌭3👾1
265. Офбординг: скидка как последняя попытка удержать клиента
В посте про офбординг мы писали: простой выход улучшает последнее впечатление. Частая практика — обратная. Пользователь нажимает «отписаться» или «отменить подписку», и вместо простого выхода ему показывают предложение остаться — со скидкой. Иногда скидка достигает 80%. Логика сервиса понятна: удержать пользователя, снизить отток, поддержать LTV. Но на пользовательский опыт это влияет иначе.
Человек пришёл завершить использование. Его решение не приняли как данность — ему предложили сделку. Вместо простого офбординга последний контакт с продуктом превращается в переговоры: «оставайся, вот тебе 80%». Если пользователь всё равно уходит, последнее впечатление — не «мне помогли выйти без лишнего», а «мне пытались продать продление со скидкой».
По правилу последнего впечатления именно этот опыт сильно влияет на общую оценку: продукт запоминается как тот, из которого сложно уйти без уговоров и спецпредложений. Доверие к «честной» цене падает: раз при отписке дают 80%, значит обычная цена завышена, а раньше переплачивал.
Если пользователь остаётся из-за скидки, он остаётся не потому, что продукт для него ценен по полной цене, а потому, что его «купили» скидкой. Лояльность к продукту не растёт, растёт привычка: в следующий раз снова нажмёт «отписаться», ожидая новое предложение. Офбординг не завершился — он отложился, и цикл «попытка уйти → скидка → остался» может повторяться. Для метрик это временный выигрыш по удержанию; для опыта — последнее взаимодействие было не про уважение к решению пользователя, а про удержание любой ценой.
В сухом остатке: скидка при попытке отписаться (вплоть до 80%) может поддержать удержание и LTV, но последний контакт с продуктом становится переговорами, а не простым выходом; пользователь запоминает не лёгкий офбординг, а уговоры и сомнения в честности цены; если остаётся — из-за скидки, а не из-за ценности продукта.
#офбординг@custdevlab #опыт@custdevlab #полезное@custdevlab #lxm@custdevlab
В посте про офбординг мы писали: простой выход улучшает последнее впечатление. Частая практика — обратная. Пользователь нажимает «отписаться» или «отменить подписку», и вместо простого выхода ему показывают предложение остаться — со скидкой. Иногда скидка достигает 80%. Логика сервиса понятна: удержать пользователя, снизить отток, поддержать LTV. Но на пользовательский опыт это влияет иначе.
Человек пришёл завершить использование. Его решение не приняли как данность — ему предложили сделку. Вместо простого офбординга последний контакт с продуктом превращается в переговоры: «оставайся, вот тебе 80%». Если пользователь всё равно уходит, последнее впечатление — не «мне помогли выйти без лишнего», а «мне пытались продать продление со скидкой».
По правилу последнего впечатления именно этот опыт сильно влияет на общую оценку: продукт запоминается как тот, из которого сложно уйти без уговоров и спецпредложений. Доверие к «честной» цене падает: раз при отписке дают 80%, значит обычная цена завышена, а раньше переплачивал.
Если пользователь остаётся из-за скидки, он остаётся не потому, что продукт для него ценен по полной цене, а потому, что его «купили» скидкой. Лояльность к продукту не растёт, растёт привычка: в следующий раз снова нажмёт «отписаться», ожидая новое предложение. Офбординг не завершился — он отложился, и цикл «попытка уйти → скидка → остался» может повторяться. Для метрик это временный выигрыш по удержанию; для опыта — последнее взаимодействие было не про уважение к решению пользователя, а про удержание любой ценой.
В сухом остатке: скидка при попытке отписаться (вплоть до 80%) может поддержать удержание и LTV, но последний контакт с продуктом становится переговорами, а не простым выходом; пользователь запоминает не лёгкий офбординг, а уговоры и сомнения в честности цены; если остаётся — из-за скидки, а не из-за ценности продукта.
#офбординг@custdevlab #опыт@custdevlab #полезное@custdevlab #lxm@custdevlab
3👍8🌭3✍2🔥2👾1
266. Продакт-менеджмент в 2025: 4 инсайта для custdev
Команда ProductSense совместно с X5 провела ежегодное исследование продактов: выборка составила 1 220 респондентов, период сбора данных — октябрь-ноябрь 2025. В этом посте — четыре основных вывода, которые важны с точки зрения custdev и понимания пользователя в 2026 году.
1. Классика никуда не делась — её адаптируют
В блоке про перспективы профессии явно сказано: традиционные подходы — Jobs to Be Done, customer development, North Star Metric, RICE, user stories и др. — по-прежнему остаются рабочими инструментами. Их чаще не отбрасывают, а адаптируют под контекст и современные условия. На фоне хайпа вокруг ИИ это важный сигнал: базовые методологии про понимание пользователя остаются в ядре практики.
2. Разрыв между «важно» и «во что реально вкладываются»
Навыки исследований, управленческие и коммуникативные навыки, мета-навыки (критическое мышление, решение проблем) стабильно входят в топ того, что считают важным при найме. Но в 2025 их заметно реже выбирали фокусом развития. Custdev и пользовательские исследования попадают в эту зону: все подтверждают, что это критично, но в планах обучения совсем другие задачи — ИИ, аналитика, проектное управление.
3. ИИ экономит время, но не заменяет понимание пользователя
ИИ в работе используют почти все; 72% говорят об экономии времени (до двух часов в день и больше), но лишь около 20% видят заметный эффект на результаты продукта или бизнеса. Личная эффективность выросла — продуктовый эффект не автоматически. Без целенаправленной работы по пониманию пользователя (custdev, исследования, проверка гипотез) LLM сам по себе не даёт роста retention или выручки.
4. Глубокие инсайты — не из Google и не из LLM
В разделе «Главный урок года» один из частых мотивов: «Сколько ни исследуй рынок удалённо/через гугл/AI, пока ты в него не погрузишься сам с головой, глубокие инсайты ты не найдешь». Это почти дословная формулировка смысла custdev: данные и ИИ сужают поле, но «мясо» понимания контекста появляется только когда продакт выходит из дашбордов к живому опыту пользователей.
В сухом остатке: исследование ProductSense показывает, что сообщество по-прежнему опирается на JTBD и customer development, но мало инвестирует время в развитие исследовательских и коммуникативных навыков, а ИИ чаще даёт личную скорость, чем продуктовый результат; если цель — не просто «делать больше задач», а лучше решать работы пользователя, ставка по-прежнему на custdev, глубинные интервью и осознанное погружение в контекст.
#custdev@custdevlab #исследования@custdevlab #методика@custdevlab #полезное@custdevlab
Команда ProductSense совместно с X5 провела ежегодное исследование продактов: выборка составила 1 220 респондентов, период сбора данных — октябрь-ноябрь 2025. В этом посте — четыре основных вывода, которые важны с точки зрения custdev и понимания пользователя в 2026 году.
1. Классика никуда не делась — её адаптируют
В блоке про перспективы профессии явно сказано: традиционные подходы — Jobs to Be Done, customer development, North Star Metric, RICE, user stories и др. — по-прежнему остаются рабочими инструментами. Их чаще не отбрасывают, а адаптируют под контекст и современные условия. На фоне хайпа вокруг ИИ это важный сигнал: базовые методологии про понимание пользователя остаются в ядре практики.
2. Разрыв между «важно» и «во что реально вкладываются»
Навыки исследований, управленческие и коммуникативные навыки, мета-навыки (критическое мышление, решение проблем) стабильно входят в топ того, что считают важным при найме. Но в 2025 их заметно реже выбирали фокусом развития. Custdev и пользовательские исследования попадают в эту зону: все подтверждают, что это критично, но в планах обучения совсем другие задачи — ИИ, аналитика, проектное управление.
3. ИИ экономит время, но не заменяет понимание пользователя
ИИ в работе используют почти все; 72% говорят об экономии времени (до двух часов в день и больше), но лишь около 20% видят заметный эффект на результаты продукта или бизнеса. Личная эффективность выросла — продуктовый эффект не автоматически. Без целенаправленной работы по пониманию пользователя (custdev, исследования, проверка гипотез) LLM сам по себе не даёт роста retention или выручки.
4. Глубокие инсайты — не из Google и не из LLM
В разделе «Главный урок года» один из частых мотивов: «Сколько ни исследуй рынок удалённо/через гугл/AI, пока ты в него не погрузишься сам с головой, глубокие инсайты ты не найдешь». Это почти дословная формулировка смысла custdev: данные и ИИ сужают поле, но «мясо» понимания контекста появляется только когда продакт выходит из дашбордов к живому опыту пользователей.
В сухом остатке: исследование ProductSense показывает, что сообщество по-прежнему опирается на JTBD и customer development, но мало инвестирует время в развитие исследовательских и коммуникативных навыков, а ИИ чаще даёт личную скорость, чем продуктовый результат; если цель — не просто «делать больше задач», а лучше решать работы пользователя, ставка по-прежнему на custdev, глубинные интервью и осознанное погружение в контекст.
#custdev@custdevlab #исследования@custdevlab #методика@custdevlab #полезное@custdevlab
2👍4🔥2🤩2🌭2
267. Гипотезы и уточняющие вопросы
Есть гипотеза, которую нужно проверить в интервью: например, что для сегмента важен атрибут X — цена, скорость доставки, возможность отменить подписку.
Ошибка — спрашивать про гипотезу в лоб: «Для Вас важна цена?» или «Влияет ли на выбор возможность простой оплаты?». Респондент получает подсказку: исследователь уже назвал атрибут. Ответ «да» не значит, что человек сам бы это назвал; он мог согласиться, потому что вопрос навёл на мысль. Получаются не факты с рынка, а отражение гипотезы исследователя.
Правильный порядок в интервью в этом случае, это начать издалека (а еще лучше с самого начала, в соответствии с LXM-моделью).
Задаем открытые вопросы:
«Что для вас важно при выборе продукта...»
«Как вы обычно принимаете решение о покупке...»
«Расскажите про последний раз, когда выбирали продукт»
Респондент рассказывает сам, без подсказок. Если атрибут X для него действительно значим, он назовёт его своими словами — тогда гипотеза подтверждается фактом из его опыта, а не согласием с формулировкой исследователя.
Если респондент не упомянул нужный атрибут — только тогда задаем уточняющий вопрос:
«Вы не назвали [цену / возможность отписаться / что-то ещё]. В вашей ситуации цена играет роль?»
Так проверяется принцип забыл упомянуть или атрибут для не важен. Ответ «да, важно» при уточнении слабее, чем самостоятельное упоминание в открытом ответе, но хотя бы не навязываем атрибут первым. Ответ «нет, не задумывался» или «не принципиально» — сигнал, что гипотеза для этого респондента не подтверждается.
В сухом остатке: гипотезу не проверяют вопросом в лоб; сначала задают открытые вопросы и слушают, что респондент называет сам; уточняющий вопрос про нужный атрибут задают только если он не был упомянут.
#customerinterview@custdevlab #методика@custdevlab #гипотезы@custdevlab #полезное@custdevlab
Есть гипотеза, которую нужно проверить в интервью: например, что для сегмента важен атрибут X — цена, скорость доставки, возможность отменить подписку.
Ошибка — спрашивать про гипотезу в лоб: «Для Вас важна цена?» или «Влияет ли на выбор возможность простой оплаты?». Респондент получает подсказку: исследователь уже назвал атрибут. Ответ «да» не значит, что человек сам бы это назвал; он мог согласиться, потому что вопрос навёл на мысль. Получаются не факты с рынка, а отражение гипотезы исследователя.
Правильный порядок в интервью в этом случае, это начать издалека (а еще лучше с самого начала, в соответствии с LXM-моделью).
Задаем открытые вопросы:
«Что для вас важно при выборе продукта...»
«Как вы обычно принимаете решение о покупке...»
«Расскажите про последний раз, когда выбирали продукт»
Респондент рассказывает сам, без подсказок. Если атрибут X для него действительно значим, он назовёт его своими словами — тогда гипотеза подтверждается фактом из его опыта, а не согласием с формулировкой исследователя.
Если респондент не упомянул нужный атрибут — только тогда задаем уточняющий вопрос:
«Вы не назвали [цену / возможность отписаться / что-то ещё]. В вашей ситуации цена играет роль?»
Так проверяется принцип забыл упомянуть или атрибут для не важен. Ответ «да, важно» при уточнении слабее, чем самостоятельное упоминание в открытом ответе, но хотя бы не навязываем атрибут первым. Ответ «нет, не задумывался» или «не принципиально» — сигнал, что гипотеза для этого респондента не подтверждается.
В сухом остатке: гипотезу не проверяют вопросом в лоб; сначала задают открытые вопросы и слушают, что респондент называет сам; уточняющий вопрос про нужный атрибут задают только если он не был упомянут.
#customerinterview@custdevlab #методика@custdevlab #гипотезы@custdevlab #полезное@custdevlab
3👍3🔥3🌭3🤔2🤩1👾1
268. Усталость пользователя от продукта и управление усталостью
Даже если продукт хороший и полностью соответствует требованиям потребителя — или, по Бобу Моэсте, пользователь выбрал его как наименее худший из доступных вариантов, — это не гарантирует долгую лояльность. Без изменений в продукте пользователи со временем начинают от него уставать.
Предельная полезность повторного использования падает: то, что в начале радовало или хотя бы устраивало, со временем воспринимается слабее. В итоге растёт желание переключиться на продукт-конкурент — не потому, что тот объективно лучше, а потому, что текущий продукт «приелся».
В исследованиях потребительского поведения это описывают несколько механизмов.
Гедоническая адаптация (hedonic adaptation): повторный контакт с одним и тем же продуктом или опытом снижает интенсивность удовольствия — люди привыкают к хорошему.
Стремление к разнообразию (variety-seeking): потребители намеренно меняют продукты, бренды или атрибуты выбора, чтобы избежать «насыщения» от одного варианта и сохранить ощущение новизны.
Насыщение атрибутами (attribute satiation): повторное потребление одних и тех же характеристик продукта создаёт пресыщение; хочется другого сочетания свойств, другого опыта. В сумме даже «наименее худший» продукт без обновлений проигрывает не столько по качеству, сколько по ощущению однообразия.
Управление усталостью от продукта — это работа над тем, чтобы продукт не воспринимался как «всё время одно и то же». Варианты: обновление контента или функционала, персонализация, переменная награда (как в модели Hook: непредсказуемость подкрепления поддерживает интерес), добавление новых сценариев использования, периодическое обновление интерфейса или формата взаимодействия. Цель — не только повысить или удержать метрики retention, но и снизить гедонический спад: чтобы пользователь не уставал от продукта быстрее, чем от альтернатив.
Если конкуренты при этом тоже не меняются, относительная позиция продукта сохраняется; если конкуренты обновляются, а наш продукт — нет, накопленная усталость подталкивает к переключению.
В сухом остатке: даже хороший или «наименее худший» продукт со временем вызывает усталость; без изменений растёт желание переключиться на конкурента; управление усталостью — обновления, разнообразие, переменная награда, новые сценарии — помогает замедлить гедонический спад и удержание.
#jtbd@custdevlab #опыт@custdevlab #retention@custdevlab #полезное@custdevlab
Даже если продукт хороший и полностью соответствует требованиям потребителя — или, по Бобу Моэсте, пользователь выбрал его как наименее худший из доступных вариантов, — это не гарантирует долгую лояльность. Без изменений в продукте пользователи со временем начинают от него уставать.
Предельная полезность повторного использования падает: то, что в начале радовало или хотя бы устраивало, со временем воспринимается слабее. В итоге растёт желание переключиться на продукт-конкурент — не потому, что тот объективно лучше, а потому, что текущий продукт «приелся».
В исследованиях потребительского поведения это описывают несколько механизмов.
Гедоническая адаптация (hedonic adaptation): повторный контакт с одним и тем же продуктом или опытом снижает интенсивность удовольствия — люди привыкают к хорошему.
Стремление к разнообразию (variety-seeking): потребители намеренно меняют продукты, бренды или атрибуты выбора, чтобы избежать «насыщения» от одного варианта и сохранить ощущение новизны.
Насыщение атрибутами (attribute satiation): повторное потребление одних и тех же характеристик продукта создаёт пресыщение; хочется другого сочетания свойств, другого опыта. В сумме даже «наименее худший» продукт без обновлений проигрывает не столько по качеству, сколько по ощущению однообразия.
Управление усталостью от продукта — это работа над тем, чтобы продукт не воспринимался как «всё время одно и то же». Варианты: обновление контента или функционала, персонализация, переменная награда (как в модели Hook: непредсказуемость подкрепления поддерживает интерес), добавление новых сценариев использования, периодическое обновление интерфейса или формата взаимодействия. Цель — не только повысить или удержать метрики retention, но и снизить гедонический спад: чтобы пользователь не уставал от продукта быстрее, чем от альтернатив.
Если конкуренты при этом тоже не меняются, относительная позиция продукта сохраняется; если конкуренты обновляются, а наш продукт — нет, накопленная усталость подталкивает к переключению.
В сухом остатке: даже хороший или «наименее худший» продукт со временем вызывает усталость; без изменений растёт желание переключиться на конкурента; управление усталостью — обновления, разнообразие, переменная награда, новые сценарии — помогает замедлить гедонический спад и удержание.
#jtbd@custdevlab #опыт@custdevlab #retention@custdevlab #полезное@custdevlab
5👍6🔥4🌭4🤩2👾1
269. B2B: руководитель не признает некомпетентность — как выяснить настоящее отношение респондента
На рынках B2B руководитель редко признается в своей некомпетентности. Если продукт направлен на устранение недостатков руководителя — например, на слабые навыки планирования, делегирования, контроля — руководитель не скажет: «да, у меня с этим проблемы». Признать это значит поставить под удар свой статус и образ эксперта.
В интервью или при продаже он будет говорить о других причинах отказа: «не подходит по формату», «дорого», «пока рано». Поэтому нет смысла спрашивать про человека — спрашиваем про процесс и прошлое.
Вместо «Вам сложно с планированием?» — «Как у вас сейчас устроено планирование? Кто за это отвечает? Что происходит, когда сроки срываются?»
Вместо «Вы достаточно делегируете?» — «Расскажите про последний проект, где нужно было распределить задачи. Как вы это делали? Что пошло не так?»
Респондент описывает факты и конкретные ситуации, а не свою самооценку, что позволит понять, есть ли проблема в компетентностью руководителя и насколько она им осознаётся. Руководитель может описать типичные провалы, узкие места, затраты времени, не говоря «это я плохо делаю». Настоящее отношение и реальные барьеры проявляются через описание ситуации.
Если продукт как раз закрывает такой барьер — не следует продавать его как «решение вашей некомпетентности», а как решение типичной задачи или типичной проблемы процесса. Так снижается защитная реакция, и легче услышать, как человек на самом деле относится к задаче и к продукту.
В сухом остатке: на B2B руководители не признают собственные недостатки; чтобы выяснить настоящее отношение, спрашиваем не про них самих, а про процесс, прошлые ситуации и «как обычно»; если одного ракурса недостаточно — усиление аргументации.
#b2b@custdevlab #customerinterview@custdevlab #методика@custdevlab
На рынках B2B руководитель редко признается в своей некомпетентности. Если продукт направлен на устранение недостатков руководителя — например, на слабые навыки планирования, делегирования, контроля — руководитель не скажет: «да, у меня с этим проблемы». Признать это значит поставить под удар свой статус и образ эксперта.
В интервью или при продаже он будет говорить о других причинах отказа: «не подходит по формату», «дорого», «пока рано». Поэтому нет смысла спрашивать про человека — спрашиваем про процесс и прошлое.
Вместо «Вам сложно с планированием?» — «Как у вас сейчас устроено планирование? Кто за это отвечает? Что происходит, когда сроки срываются?»
Вместо «Вы достаточно делегируете?» — «Расскажите про последний проект, где нужно было распределить задачи. Как вы это делали? Что пошло не так?»
Респондент описывает факты и конкретные ситуации, а не свою самооценку, что позволит понять, есть ли проблема в компетентностью руководителя и насколько она им осознаётся. Руководитель может описать типичные провалы, узкие места, затраты времени, не говоря «это я плохо делаю». Настоящее отношение и реальные барьеры проявляются через описание ситуации.
Если продукт как раз закрывает такой барьер — не следует продавать его как «решение вашей некомпетентности», а как решение типичной задачи или типичной проблемы процесса. Так снижается защитная реакция, и легче услышать, как человек на самом деле относится к задаче и к продукту.
В сухом остатке: на B2B руководители не признают собственные недостатки; чтобы выяснить настоящее отношение, спрашиваем не про них самих, а про процесс, прошлые ситуации и «как обычно»; если одного ракурса недостаточно — усиление аргументации.
#b2b@custdevlab #customerinterview@custdevlab #методика@custdevlab
2👍6🌭3🤔2✍1👾1
270. B2B: усиление аргументации при некомпетентности
В посте про то, как выяснять настоящее отношение на B2B. Респондент может не описывать процесс честно: если он некомпетентен и из‑за него всё пошло не так, он будет приукрашивать, минимизировать свою роль или перекладывать вину на других. Вопросы про процесс сами по себе не гарантируют правду.
Несколько источников. Разговаривать не только с руководителем, но с теми, кто участвует в процессе — подчинёнными, коллегами, при необходимости с его руководством. Далее сравниваем версии: как он описывает процесс и результат и как описывают другие. Расхождения — сигнал о том, что что-то не так.
Результаты и проверяемые факты. Спрашивать не только «как вы делали», а «что в итоге получилось: сроки, объём, обратная связь от заказчика или руководства». Исходы сложнее исказить, чем самоотчёт о собственной роли.
Артефакты. Что было произведено — документы, отчёты, выводы. Описание «как было» сверять с тем, что реально есть на выходе.
Детализация конкретного кейса. Просить разобрать один случай по шагам — кто что делал, когда, что произошло дальше. В подробностях неискренность или пустоты чаще заметны.
В сумме один источник и один ракурс недостаточны; нужна триангуляция и опора на факты, которые труднее подогнать под желаемую картину.
В сухом остатке: при вопросах о процессе некомпетентный респондент может искажать описание. Усиление аргументации — несколько источников (триангуляция), результаты и проверяемые факты, артефакты, детализация конкретного кейса.
#b2b@custdevlab #customerinterview@custdevlab #методика@custdevlab #полезное@custdevlab
В посте про то, как выяснять настоящее отношение на B2B. Респондент может не описывать процесс честно: если он некомпетентен и из‑за него всё пошло не так, он будет приукрашивать, минимизировать свою роль или перекладывать вину на других. Вопросы про процесс сами по себе не гарантируют правду.
Несколько источников. Разговаривать не только с руководителем, но с теми, кто участвует в процессе — подчинёнными, коллегами, при необходимости с его руководством. Далее сравниваем версии: как он описывает процесс и результат и как описывают другие. Расхождения — сигнал о том, что что-то не так.
Результаты и проверяемые факты. Спрашивать не только «как вы делали», а «что в итоге получилось: сроки, объём, обратная связь от заказчика или руководства». Исходы сложнее исказить, чем самоотчёт о собственной роли.
Артефакты. Что было произведено — документы, отчёты, выводы. Описание «как было» сверять с тем, что реально есть на выходе.
Детализация конкретного кейса. Просить разобрать один случай по шагам — кто что делал, когда, что произошло дальше. В подробностях неискренность или пустоты чаще заметны.
В сумме один источник и один ракурс недостаточны; нужна триангуляция и опора на факты, которые труднее подогнать под желаемую картину.
В сухом остатке: при вопросах о процессе некомпетентный респондент может искажать описание. Усиление аргументации — несколько источников (триангуляция), результаты и проверяемые факты, артефакты, детализация конкретного кейса.
#b2b@custdevlab #customerinterview@custdevlab #методика@custdevlab #полезное@custdevlab
1🌭3✍2👍2👾2
271. Если респондент не сказал — значит не нужно?
Если во время интервью пользователь не сказал об ожидании от продукта, значит ли это, что ему это не нужно? Не обязательно. Часть ожиданий настолько базовые, что их не называют — они воспринимаются как само собой разумеющееся и обязательное условие. Отсутствие в ответе не равно отсутствию важности.
Пример: никто не просит авиакомпанию подтвердить, что «самолёт не упадёт и полёт будет безопасным». Это не значит, что безопасность не важна — значит, что она входит в базовый набор требований, без которого продукт в категории вообще не рассматривается. Респондент может не упомянуть такой атрибут, потому что для него он очевиден: «это же должно быть по умолчанию». Если исследователь сделает вывод «раз не сказал — не нужно» и продукт не обеспечит этот базовый уровень, пользователь откажется или уйдёт — не потому что требовал чего-то лишнего, а потому что не получил того, что считал обязательным.
Поэтому при уточняющих вопросах про атрибуты, которые респондент не назвал сам, важно различать: забыл упомянуть, не считает важным или считает настолько очевидным, что не стал говорить. Вопрос «вы не назвали [X]. В вашей ситуации это играет роль?» может дать ответ «да, конечно, я просто не подумал, что это надо озвучивать» — тогда атрибут не «неважный», а «табличные ставки» (table stakes): без него продукт не принимают в расчёт. Вывод «не сказал — не нужно» в таком случае ошибочен.
Дополнительно помогают вопросы про идеальный продукт и про самый отвратительный (ужасный) продукт. «Опишите идеальный для вас продукт в этой категории» — респондент называет важные для себя функции и комбинирует ожидания; то, что он включит в «идеал», может быть и базовым требованием, которое в открытых вопросах не озвучил. «Опишите самый ужасный продукт» — респондент называет болевые точки и то, чего ни в коем случае быть не должно; это тоже ожидания, часто как раз «обязательные по умолчанию» (например, «чтобы не обманывали», «чтобы не падало»). Оба вопроса помогают вытащить ожидания, которые в свободном ответе не прозвучали.
В сухом остатке: если пользователь не сказал об ожидании от продукта, это не значит, что ему это не нужно; часть ожиданий — базовые, их не называют, потому что считают обязательными по умолчанию; такие атрибуты стоит выявлять уточняющими вопросами, а не списывать как неважные.
#customerinterview@custdevlab #методика@custdevlab #полезное@custdevlab
Если во время интервью пользователь не сказал об ожидании от продукта, значит ли это, что ему это не нужно? Не обязательно. Часть ожиданий настолько базовые, что их не называют — они воспринимаются как само собой разумеющееся и обязательное условие. Отсутствие в ответе не равно отсутствию важности.
Пример: никто не просит авиакомпанию подтвердить, что «самолёт не упадёт и полёт будет безопасным». Это не значит, что безопасность не важна — значит, что она входит в базовый набор требований, без которого продукт в категории вообще не рассматривается. Респондент может не упомянуть такой атрибут, потому что для него он очевиден: «это же должно быть по умолчанию». Если исследователь сделает вывод «раз не сказал — не нужно» и продукт не обеспечит этот базовый уровень, пользователь откажется или уйдёт — не потому что требовал чего-то лишнего, а потому что не получил того, что считал обязательным.
Поэтому при уточняющих вопросах про атрибуты, которые респондент не назвал сам, важно различать: забыл упомянуть, не считает важным или считает настолько очевидным, что не стал говорить. Вопрос «вы не назвали [X]. В вашей ситуации это играет роль?» может дать ответ «да, конечно, я просто не подумал, что это надо озвучивать» — тогда атрибут не «неважный», а «табличные ставки» (table stakes): без него продукт не принимают в расчёт. Вывод «не сказал — не нужно» в таком случае ошибочен.
Дополнительно помогают вопросы про идеальный продукт и про самый отвратительный (ужасный) продукт. «Опишите идеальный для вас продукт в этой категории» — респондент называет важные для себя функции и комбинирует ожидания; то, что он включит в «идеал», может быть и базовым требованием, которое в открытых вопросах не озвучил. «Опишите самый ужасный продукт» — респондент называет болевые точки и то, чего ни в коем случае быть не должно; это тоже ожидания, часто как раз «обязательные по умолчанию» (например, «чтобы не обманывали», «чтобы не падало»). Оба вопроса помогают вытащить ожидания, которые в свободном ответе не прозвучали.
В сухом остатке: если пользователь не сказал об ожидании от продукта, это не значит, что ему это не нужно; часть ожиданий — базовые, их не называют, потому что считают обязательными по умолчанию; такие атрибуты стоит выявлять уточняющими вопросами, а не списывать как неважные.
#customerinterview@custdevlab #методика@custdevlab #полезное@custdevlab
2👍3🌭3✍2👾1
272. Кейс ABBYY: технология против AI
В 1989 году студент четвертого курса МФТИ Давид Ян готовился к зачёту по французскому и подумал: нужен удобный электронный словарь. Вместе с другом-программистом Александром Москалёвым за лето написали словарь и начали продавать по 100 рублей за копию (план 100 копий). Потом объединили сканер и переводчик — вставил лист с текстом, получил распознанный и переведённый результат — продажи выросли в разы. Так появилась компания BIT Software (а с 1997 года — ABBYY), и неё основные продукты — FineReader (распознавание текста) и Lingvo (словари). Миллионы людей годами сканировали документы и смотрели перевод в Lingvo; ABBYY была лидером на рынках OCR (технология распознания текста) и электронных словарей, её технологии лицензировали Fujitsu, Samsung, Xerox.
Со временем, уже в 2020-ых, те же задачи — распознать текст, перевести, извлечь данные из документа — стали решать технологии на базе ИИ и нейросетей: быстрее, дешевле, часто точнее, прямо в облаке и в каждом телефоне.
Один и тот же результат пользователь получал разными технологиями: через OCR от ABBYY или аналогичными от AI-продуктов. Для него не так важно, как именно это сделано технологически, важны критерии получения результата: скорость, цена, удобство. Если другой способ даёт тот же или лучший результат при меньших затратах времени и денег, выбор смещается. Людям для достижения своих целей чаще всего не хватает времени и денег; продукт, который экономит и то и другое при том же результате, выигрывает, а что под капотом — не так важно.
Рынок, на котором работала ABBYY, изменился глобально. Нейронный машинный перевод и бесплатные облачные переводчики отчасти заменили словарные продукты вроде Lingvo. Задачи OCR стали решать облачные сервисы, сейчас они встроены в экосистемы крупных AI-продуктов, относительно дёшевы, а развитие deep learning резко повысило точность.
В сухом остатке: Один и тот же результат можно получить разными технологиями; для пользователя технология не так важна, как критерии результата: скорость, цена и т.п.; технология внутри продукта должна развиваться — иначе лидерство уходит.
#кейс@custdevlab #технологии@custdevlab #полезное@custdevlab
В 1989 году студент четвертого курса МФТИ Давид Ян готовился к зачёту по французскому и подумал: нужен удобный электронный словарь. Вместе с другом-программистом Александром Москалёвым за лето написали словарь и начали продавать по 100 рублей за копию (план 100 копий). Потом объединили сканер и переводчик — вставил лист с текстом, получил распознанный и переведённый результат — продажи выросли в разы. Так появилась компания BIT Software (а с 1997 года — ABBYY), и неё основные продукты — FineReader (распознавание текста) и Lingvo (словари). Миллионы людей годами сканировали документы и смотрели перевод в Lingvo; ABBYY была лидером на рынках OCR (технология распознания текста) и электронных словарей, её технологии лицензировали Fujitsu, Samsung, Xerox.
Со временем, уже в 2020-ых, те же задачи — распознать текст, перевести, извлечь данные из документа — стали решать технологии на базе ИИ и нейросетей: быстрее, дешевле, часто точнее, прямо в облаке и в каждом телефоне.
Один и тот же результат пользователь получал разными технологиями: через OCR от ABBYY или аналогичными от AI-продуктов. Для него не так важно, как именно это сделано технологически, важны критерии получения результата: скорость, цена, удобство. Если другой способ даёт тот же или лучший результат при меньших затратах времени и денег, выбор смещается. Людям для достижения своих целей чаще всего не хватает времени и денег; продукт, который экономит и то и другое при том же результате, выигрывает, а что под капотом — не так важно.
Рынок, на котором работала ABBYY, изменился глобально. Нейронный машинный перевод и бесплатные облачные переводчики отчасти заменили словарные продукты вроде Lingvo. Задачи OCR стали решать облачные сервисы, сейчас они встроены в экосистемы крупных AI-продуктов, относительно дёшевы, а развитие deep learning резко повысило точность.
В сухом остатке: Один и тот же результат можно получить разными технологиями; для пользователя технология не так важна, как критерии результата: скорость, цена и т.п.; технология внутри продукта должна развиваться — иначе лидерство уходит.
#кейс@custdevlab #технологии@custdevlab #полезное@custdevlab
3👍5✍3🌭3👾1
273. Товарные категории изменяются со временем: как будили раньше
Товарные категории и способы решения одних и тех же «работ» меняются вместе с технологиями и образом жизни. Хороший пример — задача «проснуться в нужное время». Как её решали в разное время, показывает, как сдвигается целая категория продуктов и услуг.
До электричества режим сна жёстко зависел от светового дня. Стемнело — пора спать, рассвело — пора вставать. Время измеряли по солнцу, поэтому изначально использовали неравные часы (temporal hours) — день и ночь делили на 12 интервалов каждый, но длина часа летом была длиннее, а зимой — короче. Распорядок жизни был привязан к свету, а не к абстрактным 60 минутам.
Электрическое освещение изменило правила. Появилась возможность продлевать световой день — можно было работать, читать, делать любые дела после заката. Режим сна усложнился: люди стали ложиться позже, спать меньше (исследования показывают, что при доступе к электрическому свету сон сокращается на 40–50 минут в сутки). Возникла потребность просыпаться в строго заданное время — не «когда рассветёт», а «когда начинается смена».
Решение работы «проснуться в определенное время» претерпевала сильные изменения:
1. Церковные колокола. В Средневековье колокола звонили несколько раз в день — по каноническим часам (от утрени на рассвете до повечерия ночью). Утренний звон (Matins) на рассвете по сути будил тех, кто жил рядом. Прямая цель — призвать к молитве, а не разбудить, но эффект был тот же.
2. Будильщики (knocker-uppers). В XIX веке в Великобритании и ряде других стран появилась такая профессия: человек за плату обходил дома и будил клиентов. Стучал длинной палкой в окна, использовал рогатки с горохом, постукивал в двери.
3. Механические будильники. Первый механический будильник изготовил американец Леви Хатчинс в 1787 году — он звонил только в 4 утра, время изменить было нельзя. Со временем будильники становились дешевле. Это и вытеснило будильщиков.
4. Радиобудильники. В 1940‑х годах появились устройства, совмещающие радиоприёмник и будильник. В 1968 году Sony выпустила Dream Machine. Радио к тому времени уже вещало круглосуточно: можно было проснуться под музыку или новости, а не только под звонок.
5. Смартфоны и умные колонки. Сегодня ту же «работу» часто выполняет телефон или умная колонка — будильник, подкасты, музыка, голосовой помощник включаются в определенное время. Категория «будильник» слилась с категорией «устройство для воспроизведения контента и управления умным домом».
Одна и та же задача — проснуться в нужное время — решалась по-разному: природный ритм, церковные колокола, будильщик, механический будильник, радиобудильник, смартфон. Каждый сдвиг связан с технологиями, доступностью и изменением образа жизни. Понимание того, как менялись способы решения «работы», помогает видеть, на каком рынке мы на самом деле работаем и как развиваются рынки — сегодняшняя категория завтра может выглядеть иначе.
В сухом остатке: товарные категории меняются со временем; задача «проснуться в нужное время» решалась разными способами; технологии и доступность продуктов меняют и саму категорию, и способ её «закрыть».
#рынок@custdevlab #интересное@custdevlab #модельповедения@custdevlab
Товарные категории и способы решения одних и тех же «работ» меняются вместе с технологиями и образом жизни. Хороший пример — задача «проснуться в нужное время». Как её решали в разное время, показывает, как сдвигается целая категория продуктов и услуг.
До электричества режим сна жёстко зависел от светового дня. Стемнело — пора спать, рассвело — пора вставать. Время измеряли по солнцу, поэтому изначально использовали неравные часы (temporal hours) — день и ночь делили на 12 интервалов каждый, но длина часа летом была длиннее, а зимой — короче. Распорядок жизни был привязан к свету, а не к абстрактным 60 минутам.
Электрическое освещение изменило правила. Появилась возможность продлевать световой день — можно было работать, читать, делать любые дела после заката. Режим сна усложнился: люди стали ложиться позже, спать меньше (исследования показывают, что при доступе к электрическому свету сон сокращается на 40–50 минут в сутки). Возникла потребность просыпаться в строго заданное время — не «когда рассветёт», а «когда начинается смена».
Решение работы «проснуться в определенное время» претерпевала сильные изменения:
1. Церковные колокола. В Средневековье колокола звонили несколько раз в день — по каноническим часам (от утрени на рассвете до повечерия ночью). Утренний звон (Matins) на рассвете по сути будил тех, кто жил рядом. Прямая цель — призвать к молитве, а не разбудить, но эффект был тот же.
2. Будильщики (knocker-uppers). В XIX веке в Великобритании и ряде других стран появилась такая профессия: человек за плату обходил дома и будил клиентов. Стучал длинной палкой в окна, использовал рогатки с горохом, постукивал в двери.
3. Механические будильники. Первый механический будильник изготовил американец Леви Хатчинс в 1787 году — он звонил только в 4 утра, время изменить было нельзя. Со временем будильники становились дешевле. Это и вытеснило будильщиков.
4. Радиобудильники. В 1940‑х годах появились устройства, совмещающие радиоприёмник и будильник. В 1968 году Sony выпустила Dream Machine. Радио к тому времени уже вещало круглосуточно: можно было проснуться под музыку или новости, а не только под звонок.
5. Смартфоны и умные колонки. Сегодня ту же «работу» часто выполняет телефон или умная колонка — будильник, подкасты, музыка, голосовой помощник включаются в определенное время. Категория «будильник» слилась с категорией «устройство для воспроизведения контента и управления умным домом».
Одна и та же задача — проснуться в нужное время — решалась по-разному: природный ритм, церковные колокола, будильщик, механический будильник, радиобудильник, смартфон. Каждый сдвиг связан с технологиями, доступностью и изменением образа жизни. Понимание того, как менялись способы решения «работы», помогает видеть, на каком рынке мы на самом деле работаем и как развиваются рынки — сегодняшняя категория завтра может выглядеть иначе.
В сухом остатке: товарные категории меняются со временем; задача «проснуться в нужное время» решалась разными способами; технологии и доступность продуктов меняют и саму категорию, и способ её «закрыть».
#рынок@custdevlab #интересное@custdevlab #модельповедения@custdevlab
👍6✍3🌭3👎1👾1
274. На каком рынке я работаю. Дополнения спустя 4 года
В посте про главный вопрос стартапа мы писали: спросить покупателя «Между чем еще Вы выбирали, прежде чем остановить выбор на нашем товаре?» — способ определить рынок и конкурентное окружение.
Но формулировка «между чем и чем ты выбираешь, прежде чем купить у меня» — не единственный и не всегда достаточный вопрос. Ответ зависит от ситуации. В одном контексте человек сравнивает конкретные продукты. В другом — способы решения проблемы (пойти в кино vs смотреть дома vs почитать книгу). В третьем — вообще не осознаёт альтернатив или выбирает «ничего не делать».
По сути мы разделяем пользователей по отношению к альтернативам при решении проблемы. У кого-то узкий набор выбора (consideration set): несколько брендов или решений, между которыми он реально выбирает. У кого-то продукт вообще не попадает в набор рассмотрения — человек решает задачу иначе или не решает её вовсе. Отсюда — разные сегменты: те, для кого мы конкурируем с X, те, для кого — с Y, и те, для кого мы «не в наборе рассмотрения».
Поэтому вопрос про рынок может раскрываться через несколько в зависимости от контекста, типа продукта и этапа пути клиента:
— «Как вы обычно решаете эту задачу?»
— «Что ещё рассматривали в этот раз?»
— «Были ли другие варианты, от которых отказались?»
— «Почему выбрали именно это?»
Граф конкуренции и разные уровни конкуренции помогают увидеть, что набор альтернатив у разных людей разный, а значит и «рынок» для каждого сегмента свой.
В сухом остатке: вопрос «между чем выбираете» — отправная точка; рынок определяется набором альтернатив в голове потребителя; этот набор зависит от ситуации и сегмента; иногда нужна цепочка вопросов, чтобы понять, с чем мы конкурируем и для кого вообще попадаем в набор рассмотрения (consideration set).
#рынок@custdevlab #сегментация@custdevlab
В посте про главный вопрос стартапа мы писали: спросить покупателя «Между чем еще Вы выбирали, прежде чем остановить выбор на нашем товаре?» — способ определить рынок и конкурентное окружение.
Но формулировка «между чем и чем ты выбираешь, прежде чем купить у меня» — не единственный и не всегда достаточный вопрос. Ответ зависит от ситуации. В одном контексте человек сравнивает конкретные продукты. В другом — способы решения проблемы (пойти в кино vs смотреть дома vs почитать книгу). В третьем — вообще не осознаёт альтернатив или выбирает «ничего не делать».
По сути мы разделяем пользователей по отношению к альтернативам при решении проблемы. У кого-то узкий набор выбора (consideration set): несколько брендов или решений, между которыми он реально выбирает. У кого-то продукт вообще не попадает в набор рассмотрения — человек решает задачу иначе или не решает её вовсе. Отсюда — разные сегменты: те, для кого мы конкурируем с X, те, для кого — с Y, и те, для кого мы «не в наборе рассмотрения».
Поэтому вопрос про рынок может раскрываться через несколько в зависимости от контекста, типа продукта и этапа пути клиента:
— «Как вы обычно решаете эту задачу?»
— «Что ещё рассматривали в этот раз?»
— «Были ли другие варианты, от которых отказались?»
— «Почему выбрали именно это?»
Граф конкуренции и разные уровни конкуренции помогают увидеть, что набор альтернатив у разных людей разный, а значит и «рынок» для каждого сегмента свой.
В сухом остатке: вопрос «между чем выбираете» — отправная точка; рынок определяется набором альтернатив в голове потребителя; этот набор зависит от ситуации и сегмента; иногда нужна цепочка вопросов, чтобы понять, с чем мы конкурируем и для кого вообще попадаем в набор рассмотрения (consideration set).
#рынок@custdevlab #сегментация@custdevlab
5👍6🔥3🤔2🌭2✍1👎1
Собрали для удобства в одном посте всё про целевую аудиторию и сегментацию:
Основа: не бывает ЦА «все»:
1. Ловушка основателя «Чесалка для спины» — не бывает целевой аудитории «все»; все — значит никто
2. Онлайн-школа математики: валидация сегментов — продукт «все для всех» на деле означает «ни для кого»
Целевая аудитория: две размерности:
3. Целевая аудитория и целевая аудитория — та, которую хотим (JTBD, ситуация, триггер), и та, до которой можем дотянуться через рекламу (пол, возраст, интересы); разрыв увеличивает CAC
Валидация и выбор сегментов:
4. Custdev и проверка целевых аудиторий
5. Ситуация — проблема — решение — сегментация в отрыве от этой схемы не работает
6. Сервис florm.io: выбор ниши и значимость решаемой проблемы — узкий сегмент для старта и customer validation
7. Битком 24: ошибка в определении ЦА — ЦА по данным vs фактическое ядро; customer validation неотъемлема
8. Custdev-чатбот: автоматизируем валидацию клиентских сегментов
9. Подписка на цветы: ищем новую целевую аудиторию
С кем проводить custdev и где искать:
10. С кем разговаривать в первую очередь
11. Три основных сегмента, с кем следует проводить custdev
12. Где найти представителей трёх основных сегментов
13. Где быстро найти людей для custdev
14. Мета-критерии сегментирования для интервью: способность рассказать о себе
15. Минимальное количество респондентов в customer interview
Оценка потенциала и доступности:
16. Правильный бенчмарк в custdev — ориентироваться на потребности целевых сегментов
17. Три главных критерия экспресс-оценки потенциала продукта — размер сегмента, сложность доступа, трансформация модели потребления
18. Affinity — насколько признак представлен в изучаемом сегменте
19. Когда у продукта один большой конкурент — учитывать целевые сегменты и потенциальных конкурентов
Масштаб и паттерны:
20. Масштаб custdev — от отдельных интервью к паттернам поведения и сегментам
Связанные темы:
21. Основной источник проблемы стартапа — не покупают — custdev раньше, чем проблема с ЦА
#подборка@custdevlab #целеваяаудитория #сегментация@custdevlab #методика@custdevlab
Основа: не бывает ЦА «все»:
1. Ловушка основателя «Чесалка для спины» — не бывает целевой аудитории «все»; все — значит никто
2. Онлайн-школа математики: валидация сегментов — продукт «все для всех» на деле означает «ни для кого»
Целевая аудитория: две размерности:
3. Целевая аудитория и целевая аудитория — та, которую хотим (JTBD, ситуация, триггер), и та, до которой можем дотянуться через рекламу (пол, возраст, интересы); разрыв увеличивает CAC
Валидация и выбор сегментов:
4. Custdev и проверка целевых аудиторий
5. Ситуация — проблема — решение — сегментация в отрыве от этой схемы не работает
6. Сервис florm.io: выбор ниши и значимость решаемой проблемы — узкий сегмент для старта и customer validation
7. Битком 24: ошибка в определении ЦА — ЦА по данным vs фактическое ядро; customer validation неотъемлема
8. Custdev-чатбот: автоматизируем валидацию клиентских сегментов
9. Подписка на цветы: ищем новую целевую аудиторию
С кем проводить custdev и где искать:
10. С кем разговаривать в первую очередь
11. Три основных сегмента, с кем следует проводить custdev
12. Где найти представителей трёх основных сегментов
13. Где быстро найти людей для custdev
14. Мета-критерии сегментирования для интервью: способность рассказать о себе
15. Минимальное количество респондентов в customer interview
Оценка потенциала и доступности:
16. Правильный бенчмарк в custdev — ориентироваться на потребности целевых сегментов
17. Три главных критерия экспресс-оценки потенциала продукта — размер сегмента, сложность доступа, трансформация модели потребления
18. Affinity — насколько признак представлен в изучаемом сегменте
19. Когда у продукта один большой конкурент — учитывать целевые сегменты и потенциальных конкурентов
Масштаб и паттерны:
20. Масштаб custdev — от отдельных интервью к паттернам поведения и сегментам
Связанные темы:
21. Основной источник проблемы стартапа — не покупают — custdev раньше, чем проблема с ЦА
#подборка@custdevlab #целеваяаудитория #сегментация@custdevlab #методика@custdevlab
4👍4🌭3🔥2✍1👎1
275. Как определить ситуацию
Ситуация — это контекст, в котором возникает потребность и за который «нанимается» продукт. Без неё работа размыта, ценность неопределима, сегменты сливаются. Разные подходы задают ситуацию по-разному.
1. Схема «ситуация — проблема — решение»
Базовый вариант: ситуация задает, когда и при каких обстоятельствах появляется проблема. Пример: «найти ресторан» — разная работа, если человек один, с романтическим партнёром или с деловым спутником. Критерии выбора, конкуренты и решение будут разными. Ситуация — проблема — решение — отправная точка: сегментация и валидация сегментов не имеют смысла в отрыве от неё.
2. JTBD: Job Story и триггер
В формате Job Story ситуация — это первый элемент фреймаворка. Ситуация — это триггерное событие, т.е. условия, при которых возникает потребность что-то сделать. Например для B2B: «Когда важный новый клиент регистрируется, я хочу получить уведомление, чтобы начать с ним диалог». Ситуация — «важный новый клиент регистрируется», а не «менеджер по продажам».
3. JTBD Боба Моэста: этапы и контекст
В модели Моэсты ситуация проявляется на этапе первой мысли о продукте: где, когда, при каких обстоятельствах возникла идея. Вопросы: «Где вы были? В каком месте? В какой ситуации/контексте? Кто/что способствовало возникновению этой мысли?» На этапе пассивного поиска — где, как, когда происходили контакты с продуктом. На переходе к активному поиску — «Что изменилось в ситуации?» Контекст фиксируется через конкретные обстоятельства, а не абстрактные сценарии. Один и тот же продукт в разное время суток может выполнять разные работы (молочный коктейль утром — завтрак, днём — перекус). LXM-based интервью помогает пройти этапы и собрать контекст.
4. AJTBD: сценарии и граф работ
В Advanced JTBD ситуация встроена в сценарии разного уровня. Высокоуровневые сценарии — широкая «работа» и жизненный контекст («больше времени на значимое общение без рутины»). Низкоуровневые — более конкретные, зависящие от контекста сценарии («получить справку из любого места в продукте, чтобы не отвлекаться на типовые вопросы»). Ситуация — часть графа работ: одна низкоуровневая работа может вести к нескольким верхнеуровневым, и наоборот. «Решить кейс» само по себе не цель — это шаг к чему-то в контексте определённой ситуации. Важно, осознаёт ли пользователь альтернативные способы решения — осознаваемая и неосознаваемая модель влияют на то, как мы описываем ситуацию и доносим продукт.
Список вопросов для выявления ситуации:
— Когда, где, при каких обстоятельствах человек оказался в этой точке?
— Что изменилось — что сдвинуло его к действию (триггер перехода)?
— С кем, для кого — кто ещё участвует в ситуации?
— Как часто и в каких вариантах — одна и та же категория может иметь несколько ситуаций (вечер после работы vs голодный обеденный перерыв — разные работы при покупке продуктов).
При интервью по JTBD нельзя спрашивать про работу без контекста: ценность продукта и сама работа зависят от ситуации. Одна категория в разных ситуациях — разные jobs.
В сухом остатке: в разных фреймворках разные подходы к опеределению ситуации; в обобщенном виде определять ситуацию можно через «где, когда, при каких обстоятельствах, что изменилось» — иначе работа и ценность остаются размытыми.
#jtbd@custdevlab #ajtbd@custdevlab #методика@custdevlab
Ситуация — это контекст, в котором возникает потребность и за который «нанимается» продукт. Без неё работа размыта, ценность неопределима, сегменты сливаются. Разные подходы задают ситуацию по-разному.
1. Схема «ситуация — проблема — решение»
Базовый вариант: ситуация задает, когда и при каких обстоятельствах появляется проблема. Пример: «найти ресторан» — разная работа, если человек один, с романтическим партнёром или с деловым спутником. Критерии выбора, конкуренты и решение будут разными. Ситуация — проблема — решение — отправная точка: сегментация и валидация сегментов не имеют смысла в отрыве от неё.
2. JTBD: Job Story и триггер
В формате Job Story ситуация — это первый элемент фреймаворка. Ситуация — это триггерное событие, т.е. условия, при которых возникает потребность что-то сделать. Например для B2B: «Когда важный новый клиент регистрируется, я хочу получить уведомление, чтобы начать с ним диалог». Ситуация — «важный новый клиент регистрируется», а не «менеджер по продажам».
3. JTBD Боба Моэста: этапы и контекст
В модели Моэсты ситуация проявляется на этапе первой мысли о продукте: где, когда, при каких обстоятельствах возникла идея. Вопросы: «Где вы были? В каком месте? В какой ситуации/контексте? Кто/что способствовало возникновению этой мысли?» На этапе пассивного поиска — где, как, когда происходили контакты с продуктом. На переходе к активному поиску — «Что изменилось в ситуации?» Контекст фиксируется через конкретные обстоятельства, а не абстрактные сценарии. Один и тот же продукт в разное время суток может выполнять разные работы (молочный коктейль утром — завтрак, днём — перекус). LXM-based интервью помогает пройти этапы и собрать контекст.
4. AJTBD: сценарии и граф работ
В Advanced JTBD ситуация встроена в сценарии разного уровня. Высокоуровневые сценарии — широкая «работа» и жизненный контекст («больше времени на значимое общение без рутины»). Низкоуровневые — более конкретные, зависящие от контекста сценарии («получить справку из любого места в продукте, чтобы не отвлекаться на типовые вопросы»). Ситуация — часть графа работ: одна низкоуровневая работа может вести к нескольким верхнеуровневым, и наоборот. «Решить кейс» само по себе не цель — это шаг к чему-то в контексте определённой ситуации. Важно, осознаёт ли пользователь альтернативные способы решения — осознаваемая и неосознаваемая модель влияют на то, как мы описываем ситуацию и доносим продукт.
Список вопросов для выявления ситуации:
— Когда, где, при каких обстоятельствах человек оказался в этой точке?
— Что изменилось — что сдвинуло его к действию (триггер перехода)?
— С кем, для кого — кто ещё участвует в ситуации?
— Как часто и в каких вариантах — одна и та же категория может иметь несколько ситуаций (вечер после работы vs голодный обеденный перерыв — разные работы при покупке продуктов).
При интервью по JTBD нельзя спрашивать про работу без контекста: ценность продукта и сама работа зависят от ситуации. Одна категория в разных ситуациях — разные jobs.
В сухом остатке: в разных фреймворках разные подходы к опеределению ситуации; в обобщенном виде определять ситуацию можно через «где, когда, при каких обстоятельствах, что изменилось» — иначе работа и ценность остаются размытыми.
#jtbd@custdevlab #ajtbd@custdevlab #методика@custdevlab
4👍3✍2👎2🤔2🌭1
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