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
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