254. Когда возражения не ведут к core job: кейс конструктора приложений Inflow Business
Продукт Inflow Business — конструктор, в котором пользователь сам собирает мобильное приложение и выгружает его в стор. Создание приложения с нуля это сложно, дорого и требует специальных знаний. Делать сайты через конструкор пользователи привыкли, а вот делать приложения через конструктор пока непривычное поведение.
Продажи подобного продукта, как и аналогичных, не происходят гладко и быстро. Изучение возражений обычно приводит к подобным ответам:
— Пришлите демо или примеры
— А вы можете собрать за нас?
— Позже разберёмся, сейчас не до этого
После доработок продукта, и добавления новых «фич» возражения менялись, но проблема оставалась прежней: интерес есть, а до целевых действия не доходит.
С точки зрения LXM модели проблема возникала на этапе активного поиска и принятия решения. На B2B рынке люди склонны увиливать, говоря о причинах, почему им не подходит продукт, вместо того чтобы говорить о реальных барьерах. Иногда это связано с боязнью показать свою некомпетентность как профессионала.
Продукт в итоге перешел к гарантиям результата. У пользователя есть страх, что не получится самостоятельно собрать нужное приложение. Этот страх нужно гарантированно преодолеть: «мы обещаем, что у тебя точно получится».
В итоге, вместо «отправим демо» стали давать демо-доступ, где человек собирает приложение сам. Добавили сценарий «первый каркас приложения за один заход», а для преодоления всех контекстных запросов подключили личного менеджера в боте. В итоге у пользователя появилась понятная точка опоры: он не «смотрит сервис», а пробует и получает результат, после чего решение о продолжении принимается гораздо проще.
В сухом остатке: когда возражения не ведут к core job, нужно переходить к гарантиям результата; на B2B рынке важно обеспечивать преодоление страха «не получится» через конкретные решения, которые показывают: точно получится, вот как.
#кейс@custdevlab #jtbd@custdevlab #b2b@custdevlab
Продукт Inflow Business — конструктор, в котором пользователь сам собирает мобильное приложение и выгружает его в стор. Создание приложения с нуля это сложно, дорого и требует специальных знаний. Делать сайты через конструкор пользователи привыкли, а вот делать приложения через конструктор пока непривычное поведение.
Продажи подобного продукта, как и аналогичных, не происходят гладко и быстро. Изучение возражений обычно приводит к подобным ответам:
— Пришлите демо или примеры
— А вы можете собрать за нас?
— Позже разберёмся, сейчас не до этого
После доработок продукта, и добавления новых «фич» возражения менялись, но проблема оставалась прежней: интерес есть, а до целевых действия не доходит.
С точки зрения LXM модели проблема возникала на этапе активного поиска и принятия решения. На B2B рынке люди склонны увиливать, говоря о причинах, почему им не подходит продукт, вместо того чтобы говорить о реальных барьерах. Иногда это связано с боязнью показать свою некомпетентность как профессионала.
Продукт в итоге перешел к гарантиям результата. У пользователя есть страх, что не получится самостоятельно собрать нужное приложение. Этот страх нужно гарантированно преодолеть: «мы обещаем, что у тебя точно получится».
В итоге, вместо «отправим демо» стали давать демо-доступ, где человек собирает приложение сам. Добавили сценарий «первый каркас приложения за один заход», а для преодоления всех контекстных запросов подключили личного менеджера в боте. В итоге у пользователя появилась понятная точка опоры: он не «смотрит сервис», а пробует и получает результат, после чего решение о продолжении принимается гораздо проще.
В сухом остатке: когда возражения не ведут к core job, нужно переходить к гарантиям результата; на B2B рынке важно обеспечивать преодоление страха «не получится» через конкретные решения, которые показывают: точно получится, вот как.
#кейс@custdevlab #jtbd@custdevlab #b2b@custdevlab
4👍4🌭3🤩2✍1🔥1
255. Четыре критерия экспресс-оценки стартапа
При оценке стартапа на ранней можно опираться на четыре критерия. Они позволяют быстро оценить перспективы стартапа без глубокого погружения в детали продукта или технологии. Когда-то мы уже писали про три критерия, но переосмысление действительности позволяет добавить еще один, критически важный.
1. Размер целевой аудитории
Размер той части рынка, которая реально может стать клиентами. Большая аудитория сама по себе не гарантирует успех, но она создает пространство для роста. Если целевая аудитория слишком узкая, стартап может столкнуться с ограничениями масштабирования уже на ранних этапах.
Важно понимать разницу между общей аудиторией рынка и той ее частью, которая соответствует целевому сегменту. Например, рынок всех людей, которые пользуются смартфонами, и рынок людей, которые готовы платить за конкретное приложение для управления финансами — это разные по размеру аудитории.
2. «Стоимость» и легкость доступа к аудитории
Это не только финансовые затраты на привлечение клиента (CAC), но и сложность самого процесса поиска ЦА. Если аудиторию сложно найти, если нет понятных каналов коммуникации, если требуется много времени и ресурсов на установление контакта, то даже при большом размере аудитории стартап столкнется с проблемами роста.
Легкость доступа означает, что есть понятные способы донести продукт до целевой аудитории, и эти способы не требуют экстремальных затрат. Если аудитория — это узкоспециализированные эксперты, которых сложно найти и с которыми сложно установить контакт, то стоимость привлечения будет высокой, даже если размер аудитории достаточен.
3. Частота потребления и средний чек
Это определяет unit-экономику стартапа. Если продукт используется редко, а средний чек низкий, то даже при успешном привлечении клиентов стартап может не достичь прибыльности. Высокая частота потребления компенсирует низкий средний чек, а высокий средний чек может компенсировать низкую частоту. Но если оба показателя низкие, бизнес-модель становится неустойчивой.
Важно понимать, что частота потребления связана не только с типом продукта, но и с тем, насколько продукт встраивается в привычную модель поведения пользователя. Продукт, который используется ежедневно, но стоит 100 рублей, может быть более выгодным, чем продукт, который используется раз в год, но стоит 10 000 рублей, если учитывать затраты на привлечение и удержание клиента.
4. Изменение привычной модели поведения
Это самый сложный для оценки критерий, но он критически важен. Если продукт требует от пользователя кардинального изменения привычек, вероятность его принятия резко снижается. Пользователи сопротивляются изменениям, особенно если они затрагивают устоявшиеся паттерны поведения. Чем меньше изменений требуется, тем выше шанс на успешное внедрение продукта.
Но если изменения необходимы, важно понимать, есть ли у пользователей достаточная мотивация для их принятия. Например, переход с наличных на бесконтактную оплату требовал изменения привычки доставать кошелек, но мотивация была высокой — скорость и удобство. А вот переход на новый мессенджер, когда все контакты уже в другом, требует больших изменений и часто встречает сопротивление.
Четыре критерия взаимосвязаны. Например, если продукт требует значительного изменения поведения, но при этом частота потребления высокая, а средний чек достаточный, то стартап может преодолеть барьер принятия. Или если доступ к аудитории сложный и дорогой, но размер аудитории огромный, а частота потребления высокая, то инвестиции в привлечение могут окупиться. Слабость по одному критерию может быть компенсирована силой по другим, но критическая слабость по нескольким критериям одновременно делает стартап высокорискованным.
В сухом остатке: четыре критерия взаимосвязаны, и слабость по одному может быть компенсирована силой по другим, но критическая слабость по нескольким критериям одновременно делает стартап высокорискованным.
#стартап@custdevlab #оценка@custdevlab #unitэкономика@custdevlab
При оценке стартапа на ранней можно опираться на четыре критерия. Они позволяют быстро оценить перспективы стартапа без глубокого погружения в детали продукта или технологии. Когда-то мы уже писали про три критерия, но переосмысление действительности позволяет добавить еще один, критически важный.
1. Размер целевой аудитории
Размер той части рынка, которая реально может стать клиентами. Большая аудитория сама по себе не гарантирует успех, но она создает пространство для роста. Если целевая аудитория слишком узкая, стартап может столкнуться с ограничениями масштабирования уже на ранних этапах.
Важно понимать разницу между общей аудиторией рынка и той ее частью, которая соответствует целевому сегменту. Например, рынок всех людей, которые пользуются смартфонами, и рынок людей, которые готовы платить за конкретное приложение для управления финансами — это разные по размеру аудитории.
2. «Стоимость» и легкость доступа к аудитории
Это не только финансовые затраты на привлечение клиента (CAC), но и сложность самого процесса поиска ЦА. Если аудиторию сложно найти, если нет понятных каналов коммуникации, если требуется много времени и ресурсов на установление контакта, то даже при большом размере аудитории стартап столкнется с проблемами роста.
Легкость доступа означает, что есть понятные способы донести продукт до целевой аудитории, и эти способы не требуют экстремальных затрат. Если аудитория — это узкоспециализированные эксперты, которых сложно найти и с которыми сложно установить контакт, то стоимость привлечения будет высокой, даже если размер аудитории достаточен.
3. Частота потребления и средний чек
Это определяет unit-экономику стартапа. Если продукт используется редко, а средний чек низкий, то даже при успешном привлечении клиентов стартап может не достичь прибыльности. Высокая частота потребления компенсирует низкий средний чек, а высокий средний чек может компенсировать низкую частоту. Но если оба показателя низкие, бизнес-модель становится неустойчивой.
Важно понимать, что частота потребления связана не только с типом продукта, но и с тем, насколько продукт встраивается в привычную модель поведения пользователя. Продукт, который используется ежедневно, но стоит 100 рублей, может быть более выгодным, чем продукт, который используется раз в год, но стоит 10 000 рублей, если учитывать затраты на привлечение и удержание клиента.
4. Изменение привычной модели поведения
Это самый сложный для оценки критерий, но он критически важен. Если продукт требует от пользователя кардинального изменения привычек, вероятность его принятия резко снижается. Пользователи сопротивляются изменениям, особенно если они затрагивают устоявшиеся паттерны поведения. Чем меньше изменений требуется, тем выше шанс на успешное внедрение продукта.
Но если изменения необходимы, важно понимать, есть ли у пользователей достаточная мотивация для их принятия. Например, переход с наличных на бесконтактную оплату требовал изменения привычки доставать кошелек, но мотивация была высокой — скорость и удобство. А вот переход на новый мессенджер, когда все контакты уже в другом, требует больших изменений и часто встречает сопротивление.
Четыре критерия взаимосвязаны. Например, если продукт требует значительного изменения поведения, но при этом частота потребления высокая, а средний чек достаточный, то стартап может преодолеть барьер принятия. Или если доступ к аудитории сложный и дорогой, но размер аудитории огромный, а частота потребления высокая, то инвестиции в привлечение могут окупиться. Слабость по одному критерию может быть компенсирована силой по другим, но критическая слабость по нескольким критериям одновременно делает стартап высокорискованным.
В сухом остатке: четыре критерия взаимосвязаны, и слабость по одному может быть компенсирована силой по другим, но критическая слабость по нескольким критериям одновременно делает стартап высокорискованным.
#стартап@custdevlab #оценка@custdevlab #unitэкономика@custdevlab
9👍8🌭4✍1🔥1👾1
256. Ценность в зависимости от ситуации: важное ограничение JTBD и AJTBD
При проведении интервью по JTBD очень часто допускают ошибку: спрашивают про работу без контекста. «Что ты делаешь, когда покупаешь продукты?» — вопрос слишком общий.
Ценность продукта и сама работа зависят от ситуации. Покупать продукты вечером после работы и покупать продукты, когда голоден и очень хочешь есть, — это разные работы. В первом случае человек может спокойно сравнивать цены, выбирать новое, планировать меню на неделю. Во втором — нужно быстро утолить голод, критерии выбора другие, конкуренты другие (доставка, кафе, снек из автомата). Одна и та же категория «продукты», но разные ситуации, разные работы.
Если в интервью не уточнять контекст — когда, где, при каких обстоятельствах человек оказался в этой ситуации, — мы получаем размытую «работу» и теряем то, ради чего вообще нужен JTBD: понимание, какую конкретную прогрессию клиент пытается достичь и что его толкает к действию именно сейчас. Без ситуации ценность продукта не определишь.
В сухом остатке: при интервью по JTBD нельзя спрашивать про работу без контекста; одна и та же категория в разных ситуациях — разные работы; контекст (когда, где, при каких обстоятельствах) нужно выяснять каждый раз.
#jtbd@custdevlab #customerinterview@custdevlab #контекст@custdevlab
При проведении интервью по JTBD очень часто допускают ошибку: спрашивают про работу без контекста. «Что ты делаешь, когда покупаешь продукты?» — вопрос слишком общий.
Ценность продукта и сама работа зависят от ситуации. Покупать продукты вечером после работы и покупать продукты, когда голоден и очень хочешь есть, — это разные работы. В первом случае человек может спокойно сравнивать цены, выбирать новое, планировать меню на неделю. Во втором — нужно быстро утолить голод, критерии выбора другие, конкуренты другие (доставка, кафе, снек из автомата). Одна и та же категория «продукты», но разные ситуации, разные работы.
Если в интервью не уточнять контекст — когда, где, при каких обстоятельствах человек оказался в этой ситуации, — мы получаем размытую «работу» и теряем то, ради чего вообще нужен JTBD: понимание, какую конкретную прогрессию клиент пытается достичь и что его толкает к действию именно сейчас. Без ситуации ценность продукта не определишь.
В сухом остатке: при интервью по JTBD нельзя спрашивать про работу без контекста; одна и та же категория в разных ситуациях — разные работы; контекст (когда, где, при каких обстоятельствах) нужно выяснять каждый раз.
#jtbd@custdevlab #customerinterview@custdevlab #контекст@custdevlab
5🔥5👍3🌭3✍1👾1
257. Когда custdev-интервью не нужно
Интервью — не универсальный инструмент. Есть ситуации, когда оно почти ничего не даёт: продукт уже есть, гипотеза «каким он должен быть» сформулирована, и нужно её валидировать.
В таком случае интервью лишь трата сил, времени и денег. Люди плохо предсказывают своё поведение, зато хорошо реагируют на реальное предложение. Лучше просто пробовать продавать: запустить трафик, выставить цену, показать оффер и посмотреть, кто платит, кто отказывается, на каком шаге.
Интервью нужно, когда важно понять проблему, работу, контекст, сегмент — то, что предшествует «каким должен быть продукт». Когда же продукт уже есть и вопрос именно «каким он должен быть», ответ даёт рынок: конверсия, отказы, возражения при продаже, поведение после покупки.
Это не значит, что разговоры с людьми бесполезны в этой ситуации — но их роль в другом. Опрашивать «что бы ты хотел в продукте?» при готовом решении чаще всего слабее, чем проверять гипотезу продажей и трафиком.
В CDDC (Customer Development Design Canvas) как раз заложено разделение опросной части и MVP: на этапе Customer Discovery — интервью, опросы, понимание проблемы и формулировка требований к решению; на этапе Customer Validation — MVP, трафик, продажи, проверка готовности платить.
Вопрос «каким должен быть продукт» при уже существующем продукте относится к Validation: проверять нужно через оффер и рынок, а не через опросы.
В сухом остатке: если продукт уже есть и ты проверяешь, каким он должен быть, — не начинай с интервью. Пробуй продавать, запускай трафик; интервью оставляй для понимания проблемы, работы и контекста, а не для голосования по фичам.
#custdev@custdevlab #customerinterview@custdevlab #cddc@custdevlab #полезное@custdevlab
Интервью — не универсальный инструмент. Есть ситуации, когда оно почти ничего не даёт: продукт уже есть, гипотеза «каким он должен быть» сформулирована, и нужно её валидировать.
В таком случае интервью лишь трата сил, времени и денег. Люди плохо предсказывают своё поведение, зато хорошо реагируют на реальное предложение. Лучше просто пробовать продавать: запустить трафик, выставить цену, показать оффер и посмотреть, кто платит, кто отказывается, на каком шаге.
Интервью нужно, когда важно понять проблему, работу, контекст, сегмент — то, что предшествует «каким должен быть продукт». Когда же продукт уже есть и вопрос именно «каким он должен быть», ответ даёт рынок: конверсия, отказы, возражения при продаже, поведение после покупки.
Это не значит, что разговоры с людьми бесполезны в этой ситуации — но их роль в другом. Опрашивать «что бы ты хотел в продукте?» при готовом решении чаще всего слабее, чем проверять гипотезу продажей и трафиком.
В CDDC (Customer Development Design Canvas) как раз заложено разделение опросной части и MVP: на этапе Customer Discovery — интервью, опросы, понимание проблемы и формулировка требований к решению; на этапе Customer Validation — MVP, трафик, продажи, проверка готовности платить.
Вопрос «каким должен быть продукт» при уже существующем продукте относится к Validation: проверять нужно через оффер и рынок, а не через опросы.
В сухом остатке: если продукт уже есть и ты проверяешь, каким он должен быть, — не начинай с интервью. Пробуй продавать, запускай трафик; интервью оставляй для понимания проблемы, работы и контекста, а не для голосования по фичам.
#custdev@custdevlab #customerinterview@custdevlab #cddc@custdevlab #полезное@custdevlab
5👍4🌭3✍2👾1
Собрали посты про то, когда custdev обманул:
Кейсы: ложные выводы и провалы
1. Кейс «Гладильный уголок» — как нельзя тестировать гипотезу — опрос вместо интервью: «было бы здорово» → никто не пользовался; опросы как единственный инструмент сильно повышают риск ошибки
2. Онлайн-детство: проблема потребителя, о которой он не скажет — интервью «подтвердили» гипотезу про «время для себя», но решенческие вопросы выявили сомнения; потребитель не всегда озвучивает настоящую причину отказа
3. Битком 24: ошибка в определении ЦА — опора на тех, кто чаще ходит в рестораны; фактическое ядро оказалось другим
4. Битком 24: что такое «инсайт» — 50 интервью + опрос на 980 человек + факторная модель, но ЦА определили неверно; упущен фактор «идеальность результата»
5. Битком 24: прогнозируем выручку — неверный бенчмарк: средний чек по рынку 890 ₽ vs 6500 ₽ в приложении; источник данных и среднерыночные метрики критичны
Социально желаемые ответы и «говорят — делают»
6. Как потребитель сравнивает — самокаты: в интервью «выбираю по цене», в реальности сравнение цен слишком сложно; социально приемлемая модель поведения
7. Социально приемлемое поведение — респондент отвечает «как принято», а не как действует; ограничение опросов
8. Спрашиваем про прошлое, а не про будущее — догадки и намерения = социально желаемый образ; нужен реальный опыт
9. Факты, а не домыслы — фиксировать то, что было, а не намерения; связь с реальными vs фантомными болями
Выборка, бенчмарки, нетипичное поведение
10. Нетипичная модель поведения потребителя — клиент Гудмана vs типичный клиент Битком; построение модели на нетипичном поведении вводит в заблуждение
11. Реальные и фантомные «боли» клиентов — различать то, с чем сталкиваются на деле, и то, что кажется проблемой
12. Опрос — это не выявление модели поведения — опрос проверяет представление исследователя, а не выявляет модель; использовать после интервью
Когда custdev не сработал или проведён неверно
13. Неправильный custdev как фундаментальная причина провала продукта — формальный custdev «для галочки» подрывает продукт
14. Лучше не проводить custdev, чем проводить его для галочки — неправильный custdev усиливает ошибочные представления
#подборка@custdevlab #ошибки@custdevlab #кейс@custdevlab
Кейсы: ложные выводы и провалы
1. Кейс «Гладильный уголок» — как нельзя тестировать гипотезу — опрос вместо интервью: «было бы здорово» → никто не пользовался; опросы как единственный инструмент сильно повышают риск ошибки
2. Онлайн-детство: проблема потребителя, о которой он не скажет — интервью «подтвердили» гипотезу про «время для себя», но решенческие вопросы выявили сомнения; потребитель не всегда озвучивает настоящую причину отказа
3. Битком 24: ошибка в определении ЦА — опора на тех, кто чаще ходит в рестораны; фактическое ядро оказалось другим
4. Битком 24: что такое «инсайт» — 50 интервью + опрос на 980 человек + факторная модель, но ЦА определили неверно; упущен фактор «идеальность результата»
5. Битком 24: прогнозируем выручку — неверный бенчмарк: средний чек по рынку 890 ₽ vs 6500 ₽ в приложении; источник данных и среднерыночные метрики критичны
Социально желаемые ответы и «говорят — делают»
6. Как потребитель сравнивает — самокаты: в интервью «выбираю по цене», в реальности сравнение цен слишком сложно; социально приемлемая модель поведения
7. Социально приемлемое поведение — респондент отвечает «как принято», а не как действует; ограничение опросов
8. Спрашиваем про прошлое, а не про будущее — догадки и намерения = социально желаемый образ; нужен реальный опыт
9. Факты, а не домыслы — фиксировать то, что было, а не намерения; связь с реальными vs фантомными болями
Выборка, бенчмарки, нетипичное поведение
10. Нетипичная модель поведения потребителя — клиент Гудмана vs типичный клиент Битком; построение модели на нетипичном поведении вводит в заблуждение
11. Реальные и фантомные «боли» клиентов — различать то, с чем сталкиваются на деле, и то, что кажется проблемой
12. Опрос — это не выявление модели поведения — опрос проверяет представление исследователя, а не выявляет модель; использовать после интервью
Когда custdev не сработал или проведён неверно
13. Неправильный custdev как фундаментальная причина провала продукта — формальный custdev «для галочки» подрывает продукт
14. Лучше не проводить custdev, чем проводить его для галочки — неправильный custdev усиливает ошибочные представления
#подборка@custdevlab #ошибки@custdevlab #кейс@custdevlab
4🔥5🌭3✍2👍1
258. Видение предпринимателя как необходимый навык
Крайне важно развивать широту видения (насмотренность). Это помогает иначе смотреть на свой продукт. Предприниматель, который долго работает над одной идеей, застревает в одном ракурсе: видит продукт через призму собственных предположений, привычных решений, ограничений, которые сам же и создал. Широта видения позволяет выйти за эти рамки и увидеть продукт с другой стороны.
В CustDev-школе мы придумали одно упражнение для развития видения: идеи одного продукта даем на разбор другим предпринимателям. Когда человек смотрит на чужой продукт, он не знает истории его создания, не знает, почему были приняты те или иные решения, не знает ограничений, которые заложил автор. Он видит только саму идею и начинает разбирать её с чистого листа: какую проблему решает, для кого, какими способами, какие есть альтернативы, что можно улучшить. Получается интересный взгляд на продукт — свежий, без предрассудков.
Например, идею проекта Чек-Чирик (ИИ-ассистент по выбору техники) дали на разбор студентам МФТИ. Предприниматели, которые не были знакомы с продуктом, должны были протестировать идею за 3 часа. Т.е. придумать способы в рамках CDDC как быстро понять востребованность идеи.
Их подходы к тестирвоанию не были лучше или хуже, чем в оригинальном проекте — просто они были другими, потому что видение каждого предпринимателя отличается. Такое упражнение помогает расширить собственное видение продукта и увидеть возможности, которые раньше не замечал.
В сухом остатке: широта видения помогает иначе смотреть на продукт и находить новые возможности. Разбирать идеи своего продукта с другими предпринимателями — способ выйти за рамки собственных предположений и увидеть продукт свежим взглядом.
#видение@custdevlab #мышление@custdevlab #полезное@custdevlab
Крайне важно развивать широту видения (насмотренность). Это помогает иначе смотреть на свой продукт. Предприниматель, который долго работает над одной идеей, застревает в одном ракурсе: видит продукт через призму собственных предположений, привычных решений, ограничений, которые сам же и создал. Широта видения позволяет выйти за эти рамки и увидеть продукт с другой стороны.
В CustDev-школе мы придумали одно упражнение для развития видения: идеи одного продукта даем на разбор другим предпринимателям. Когда человек смотрит на чужой продукт, он не знает истории его создания, не знает, почему были приняты те или иные решения, не знает ограничений, которые заложил автор. Он видит только саму идею и начинает разбирать её с чистого листа: какую проблему решает, для кого, какими способами, какие есть альтернативы, что можно улучшить. Получается интересный взгляд на продукт — свежий, без предрассудков.
Например, идею проекта Чек-Чирик (ИИ-ассистент по выбору техники) дали на разбор студентам МФТИ. Предприниматели, которые не были знакомы с продуктом, должны были протестировать идею за 3 часа. Т.е. придумать способы в рамках CDDC как быстро понять востребованность идеи.
Их подходы к тестирвоанию не были лучше или хуже, чем в оригинальном проекте — просто они были другими, потому что видение каждого предпринимателя отличается. Такое упражнение помогает расширить собственное видение продукта и увидеть возможности, которые раньше не замечал.
В сухом остатке: широта видения помогает иначе смотреть на продукт и находить новые возможности. Разбирать идеи своего продукта с другими предпринимателями — способ выйти за рамки собственных предположений и увидеть продукт свежим взглядом.
#видение@custdevlab #мышление@custdevlab #полезное@custdevlab
2👍6🔥3🌭3✍1👾1
259. Два подхода к созданию гайда для customer interview
Есть два способа составить гайд для интервью, и выбор зависит от того, что уже известно о продукте и что необходимо выяснить. Не важно, речь про проблемное или решенческое интервью.
От решения к вопросам
Известно, что нужно сделать с продуктом: поднять цену, повысить конверсию из регистрации в накопление баллов, изменить тарифную сетку.
После необходимо определить информацию, которая нужна для этого решения: как потребитель относится к цене сейчас, почему пользователи не накапливают баллы, что влияет на выбор тарифа.
И только потом формулируются вопросы, которые эту информацию позволят выявить. Такой подход подходит, когда есть конкретная гипотеза о продукте или конкретное действие, которое нужно проверить или обосновать. Интервью становится инструментом валидации или сбора данных для принятия решения.
От вопроса к решению
Начинается с вопросов, которые помогают понять проблему, работу, контекст, сегмент. Например: «Как вы сегодня решаете эту проблему?» или «Расскажите про этапы вашего процесса».
Из ответов выясняется, как проблема решается сейчас, каким образом потребитель мыслит, где в JTBD-процессе может вписаться продукт, кто конкуренты решения.
И только после определяем, что делать с продуктом на основе собранной информации.
Такой подход подходит на ранних этапах, когда нужно понять проблему, работу клиента, контекст использования — то, что предшествует формулировке гипотез о продукте. Интервью становится инструментом исследования и открытия.
В первом случае мы движемся от известного решения к неизвестной информации.
Во втором — от открытых вопросов к неизвестному решению.
Первый подход фокусирован на валидации, второй — на исследовании.
Выбор зависит от стадии работы с продуктом и от того, что именно нужно выяснить.
В сухом остатке: два подхода к созданию гайда — от решения к вопросам (когда есть конкретная гипотеза или действие) и от вопроса к решению (когда нужно исследовать проблему и контекст); первый для валидации, второй для открытия.
#customerinterview@custdevlab #методика@custdevlab #гайд@custdevlab
Есть два способа составить гайд для интервью, и выбор зависит от того, что уже известно о продукте и что необходимо выяснить. Не важно, речь про проблемное или решенческое интервью.
От решения к вопросам
Известно, что нужно сделать с продуктом: поднять цену, повысить конверсию из регистрации в накопление баллов, изменить тарифную сетку.
После необходимо определить информацию, которая нужна для этого решения: как потребитель относится к цене сейчас, почему пользователи не накапливают баллы, что влияет на выбор тарифа.
И только потом формулируются вопросы, которые эту информацию позволят выявить. Такой подход подходит, когда есть конкретная гипотеза о продукте или конкретное действие, которое нужно проверить или обосновать. Интервью становится инструментом валидации или сбора данных для принятия решения.
От вопроса к решению
Начинается с вопросов, которые помогают понять проблему, работу, контекст, сегмент. Например: «Как вы сегодня решаете эту проблему?» или «Расскажите про этапы вашего процесса».
Из ответов выясняется, как проблема решается сейчас, каким образом потребитель мыслит, где в JTBD-процессе может вписаться продукт, кто конкуренты решения.
И только после определяем, что делать с продуктом на основе собранной информации.
Такой подход подходит на ранних этапах, когда нужно понять проблему, работу клиента, контекст использования — то, что предшествует формулировке гипотез о продукте. Интервью становится инструментом исследования и открытия.
В первом случае мы движемся от известного решения к неизвестной информации.
Во втором — от открытых вопросов к неизвестному решению.
Первый подход фокусирован на валидации, второй — на исследовании.
Выбор зависит от стадии работы с продуктом и от того, что именно нужно выяснить.
В сухом остатке: два подхода к созданию гайда — от решения к вопросам (когда есть конкретная гипотеза или действие) и от вопроса к решению (когда нужно исследовать проблему и контекст); первый для валидации, второй для открытия.
#customerinterview@custdevlab #методика@custdevlab #гайд@custdevlab
5🔥3🌭3✍2👍2👾1
260. Что такое MVP и как его использовать в CDDC
MVP — минимально жизнеспособный продукт. Часто MVP понимают неправильно, и это приводит к ошибкам.
Что не является MVP: последовательная сборка частей продукта. Сначала делаем колесо, потом шасси, потом кузов, и только в конце получается автомобиль. До финальной сборки ни одна часть не функциональна сама по себе — колесо не ездит, шасси не перевозит. Это не MVP, потому что на каждом этапе продукт не доставляет ценность пользователю. Пользователь не может использовать части продукта для решения своей задачи.
Также не является MVP: создание разных функциональных продуктов вместо итераций одного. Сначала делаем самокат, потом велосипед, потом мотоцикл, и только потом — автомобиль. Каждый продукт функционален, но это не итерации одного решения. Самокат, велосипед и мотоцикл — это не версии автомобиля, это разные продукты. MVP должен быть итерацией одного продукта, а не последовательностью разных решений.
Что является MVP: итерации одного функционального продукта, который доставляет ценность с первого этапа. Сначала делаем примитивную тележку — она простая, но функциональна: перевозит людей и грузы. Потом пикап — более развитая версия, но та же суть: перевозка. Потом простой автомобиль — еще более развитая версия. И наконец финальная версия — автомобиль. На каждом этапе продукт функционален и доставляет ценность, просто в разной степени. Каждая итерация — это полный, работающий продукт, который можно использовать.
MVP должен быть функциональным и доставлять ценность с самого начала, а не собираться по частям или заменяться другими продуктами. Каждая итерация MVP — это минимальная, но полная версия продукта, которая решает задачу пользователя и позволяет собирать данные для следующих итераций. В CDDC MVP используется при переходе от Discovery к Validation.
В сухом остатке: MVP — это не части продукта и не разные продукты, а итерации одного функционального продукта, который доставляет ценность с первого этапа; каждая версия MVP должна быть полной и рабочей, просто минимальной.
#mvp@custdevlab #гипотезы@custdevlab #полезное@custdevlab
Оригинальное изображение: Fred Voorhorst
MVP — минимально жизнеспособный продукт. Часто MVP понимают неправильно, и это приводит к ошибкам.
Что не является MVP: последовательная сборка частей продукта. Сначала делаем колесо, потом шасси, потом кузов, и только в конце получается автомобиль. До финальной сборки ни одна часть не функциональна сама по себе — колесо не ездит, шасси не перевозит. Это не MVP, потому что на каждом этапе продукт не доставляет ценность пользователю. Пользователь не может использовать части продукта для решения своей задачи.
Также не является MVP: создание разных функциональных продуктов вместо итераций одного. Сначала делаем самокат, потом велосипед, потом мотоцикл, и только потом — автомобиль. Каждый продукт функционален, но это не итерации одного решения. Самокат, велосипед и мотоцикл — это не версии автомобиля, это разные продукты. MVP должен быть итерацией одного продукта, а не последовательностью разных решений.
Что является MVP: итерации одного функционального продукта, который доставляет ценность с первого этапа. Сначала делаем примитивную тележку — она простая, но функциональна: перевозит людей и грузы. Потом пикап — более развитая версия, но та же суть: перевозка. Потом простой автомобиль — еще более развитая версия. И наконец финальная версия — автомобиль. На каждом этапе продукт функционален и доставляет ценность, просто в разной степени. Каждая итерация — это полный, работающий продукт, который можно использовать.
MVP должен быть функциональным и доставлять ценность с самого начала, а не собираться по частям или заменяться другими продуктами. Каждая итерация MVP — это минимальная, но полная версия продукта, которая решает задачу пользователя и позволяет собирать данные для следующих итераций. В CDDC MVP используется при переходе от Discovery к Validation.
В сухом остатке: MVP — это не части продукта и не разные продукты, а итерации одного функционального продукта, который доставляет ценность с первого этапа; каждая версия MVP должна быть полной и рабочей, просто минимальной.
#mvp@custdevlab #гипотезы@custdevlab #полезное@custdevlab
Оригинальное изображение: Fred Voorhorst
2🔥7👍5🌭2✍1🫡1👾1
Собрали для удобства в одном посте всё про customer interview и как задавать вопросы:
С чего начать:
1. С чего начать custdev (решенческий custdev)
2. Главные вопросы проблемного интервью (проблемный custdev)
3. Самый полезный вопрос во время custdev
4. Custdev-интервью: проблемное и решенческое
5. С чего начать custdev: цель
6. Где взять гипотезу для первого custdev-интервью
7. Зачем нужны гипотезы для исследования и можно ли обойтись без них
Почему опрос не интервью:
8. Опросы и custdev. Часть 1 и Часть 2
Что спрашивать — перечень вопросов:
9. С чего начать, если нет продукта и клиентов. Проблемные вопросы для customer interview
10. С чего начать, если есть продукт и клиенты. Решенческие вопросы для customer interview
11. Custdev-интервью: спросите об идеальном продукте
12. Custdev-интервью: спросите о самом ужасном продукте
13. Вопросы про цену продукта
14. Проблема идеального продукта по мнению пользователей — важен образ мысли, а не сам ответ
15. Как узнать значимость проблемы для клиента — шкала для определения значимости
16. Привычное потребление и разные модели — частотность и формулировка вопросов
Как спрашивать:
17. Customer interview: открытые вопросы
18. Правило «Пять почему»
19. Спрашиваем про прошлое, а не про будущее
20. Два проверочных вопроса интервью: «получил ли я ответ?», «что я смогу сделать со своим продуктом?»
21. Прайминг: как получить нужный ответ респондента
22. Техника «отражение» в интервью
23. Факты, а не домыслы
Гайд для интервью:
24. Рекомендации по вопросам для customer interview — 10 принципов, чек-лист для гайда
25. Модель принятия решения о покупке как основа для гайда customer interview
26. Два подхода к созданию гайда для интервью
27. Ошибка: составить слишком большой и подробный гайд
Шкалы оценок в интервью:
28. Шкалы оценок в customer interview: часть 1 и часть 2
Как проводить: глубина, мессенджеры, запись:
29. Можно ли проводить custdev через мессенджеры
30. Нужно ли разбираться в тематике исследования, когда идешь на первые интервью
31. Customer Interview: насколько глубоко нужно копать
32. Customer Interview: форма для записи результатов
33. Как, сколько и кто — как проводили исследование
Ошибки при проведении customer interview:
34. «Впарить» проблему респонденту, если её нет
35. Слишком долго обсуждать социально-демографические вопросы
36. Составить слишком большой и подробный гайд
37. Лучше не проводить custdev, чем проводить его для галочки
38. Не нужно сужать аудиторию при проблемном интервью
С кем разговаривать и кого опрашивать:
39. С кем разговаривать в первую очередь
40. Где быстро найти людей для custdev
41. Анкета для отбора респондентов для customer interview
42. Мета-критерии сегментирования для интервью: способность рассказать о себе
43. Минимальное количество респондентов в customer interview
44. Разговариваем про человека, а не про продукт
45. Лучше разговаривать с тем, кого не знаешь
#подборка@custdevlab #интервью@custdevlab #методика@custdevlab #какзадаватьвопросы@custdevlab
С чего начать:
1. С чего начать custdev (решенческий custdev)
2. Главные вопросы проблемного интервью (проблемный custdev)
3. Самый полезный вопрос во время custdev
4. Custdev-интервью: проблемное и решенческое
5. С чего начать custdev: цель
6. Где взять гипотезу для первого custdev-интервью
7. Зачем нужны гипотезы для исследования и можно ли обойтись без них
Почему опрос не интервью:
8. Опросы и custdev. Часть 1 и Часть 2
Что спрашивать — перечень вопросов:
9. С чего начать, если нет продукта и клиентов. Проблемные вопросы для customer interview
10. С чего начать, если есть продукт и клиенты. Решенческие вопросы для customer interview
11. Custdev-интервью: спросите об идеальном продукте
12. Custdev-интервью: спросите о самом ужасном продукте
13. Вопросы про цену продукта
14. Проблема идеального продукта по мнению пользователей — важен образ мысли, а не сам ответ
15. Как узнать значимость проблемы для клиента — шкала для определения значимости
16. Привычное потребление и разные модели — частотность и формулировка вопросов
Как спрашивать:
17. Customer interview: открытые вопросы
18. Правило «Пять почему»
19. Спрашиваем про прошлое, а не про будущее
20. Два проверочных вопроса интервью: «получил ли я ответ?», «что я смогу сделать со своим продуктом?»
21. Прайминг: как получить нужный ответ респондента
22. Техника «отражение» в интервью
23. Факты, а не домыслы
Гайд для интервью:
24. Рекомендации по вопросам для customer interview — 10 принципов, чек-лист для гайда
25. Модель принятия решения о покупке как основа для гайда customer interview
26. Два подхода к созданию гайда для интервью
27. Ошибка: составить слишком большой и подробный гайд
Шкалы оценок в интервью:
28. Шкалы оценок в customer interview: часть 1 и часть 2
Как проводить: глубина, мессенджеры, запись:
29. Можно ли проводить custdev через мессенджеры
30. Нужно ли разбираться в тематике исследования, когда идешь на первые интервью
31. Customer Interview: насколько глубоко нужно копать
32. Customer Interview: форма для записи результатов
33. Как, сколько и кто — как проводили исследование
Ошибки при проведении customer interview:
34. «Впарить» проблему респонденту, если её нет
35. Слишком долго обсуждать социально-демографические вопросы
36. Составить слишком большой и подробный гайд
37. Лучше не проводить custdev, чем проводить его для галочки
38. Не нужно сужать аудиторию при проблемном интервью
С кем разговаривать и кого опрашивать:
39. С кем разговаривать в первую очередь
40. Где быстро найти людей для custdev
41. Анкета для отбора респондентов для customer interview
42. Мета-критерии сегментирования для интервью: способность рассказать о себе
43. Минимальное количество респондентов в customer interview
44. Разговариваем про человека, а не про продукт
45. Лучше разговаривать с тем, кого не знаешь
#подборка@custdevlab #интервью@custdevlab #методика@custdevlab #какзадаватьвопросы@custdevlab
1🔥14👍5🥰4🤩2🌭2👾1
CustDev Laboratory pinned «Собрали для удобства в одном посте всё про customer interview и как задавать вопросы: С чего начать: 1. С чего начать custdev (решенческий custdev) 2. Главные вопросы проблемного интервью (проблемный custdev) 3. Самый полезный вопрос во время custdev 4. Custdev…»
261. Разные масштабы опыта
Опыт пользователя можно рассматривать на разных масштабах — от самого широкого до самого узкого. Удобна аналогия матрёшки. Внешняя матрёшка — самый широкий масштаб, внутренняя — самый узкий. Каждому масштабу опыта в продуктовом управлении соответствует свой объект работы: то, с чем мы фактически работаем на этом уровне в продукте.
Жизненный опыт — самый широкий масштаб. В продукте ему соответствует экосистема: как человек живёт, чем увлекается, какие у него ценности, привычки, окружение. Вне продукта и даже вне товарной категории.
Опыт жизненных сценариев — чуть уже. В продукте по‑прежнему экосистема, но уже через сценарии: как человек решает типичные задачи, как выбирает между альтернативами в категории, что для него триггер, что — барьер. Именно этот масштаб описывает LXM (Life Experience Map): карта жизненного пути потенциальных клиентов, поведение в товарной категории, выбор между продуктами — без привязки к одному решению.
Клиентский опыт (CX) — масштаб, которому в продукте соответствует продукт как целое. Человек уже взаимодействует с решением: путь от первого контакта до использования, повторных покупок, ухода. CJM обычно строится на этом уровне.
Пользовательский опыт (UX) — масштаб, которому в продукте соответствует конкретный сценарий использования: как человек выполняет задачу внутри продукта, на каких шагах возникают проблемы, где теряется ценность.
Опыт в точке контакта (UI) — самый узкий масштаб. В продукте ему соответствует интерфейс: конкретный экран, кнопка, форма. Как человек с ними взаимодействует — что видит, куда нажимает, где ошибается.
Зачем различать масштабы
От масштаба зависят и объект работы в продукте, и инструменты. Если нужно понять, где в жизни пользователя может появиться продукт, как он выбирает между альтернативами — работаем с экосистемой, уровень жизненных сценариев, LXM.
Если улучшаем путь внутри уже выбранного продукта — работаем с продуктом, CX и CJM. Если оптимизируем сценарий или экран — работаем со сценарием и интерфейсом, UX и UI.
LXM как раз про верхние матрёшки: жизненный опыт и опыт жизненных сценариев. Остальные уровни вложены внутрь; им в продукте соответствуют продукт, сценарий, интерфейс.
В сухом остатке: опыт пользователя имеет разные масштабы, и каждому в продуктовом управлении соответствует свой объект работы — экосистема, продукт, сценарий, интерфейс. LXM работает на уровне жизненных сценариев (экосистема); понимание масштаба помогает выбирать инструменты и фокус в продукте.
#lxm@custdevlab #cjm@custdevlab #опыт@custdevlab #полезное@custdevlab
Опыт пользователя можно рассматривать на разных масштабах — от самого широкого до самого узкого. Удобна аналогия матрёшки. Внешняя матрёшка — самый широкий масштаб, внутренняя — самый узкий. Каждому масштабу опыта в продуктовом управлении соответствует свой объект работы: то, с чем мы фактически работаем на этом уровне в продукте.
Жизненный опыт — самый широкий масштаб. В продукте ему соответствует экосистема: как человек живёт, чем увлекается, какие у него ценности, привычки, окружение. Вне продукта и даже вне товарной категории.
Опыт жизненных сценариев — чуть уже. В продукте по‑прежнему экосистема, но уже через сценарии: как человек решает типичные задачи, как выбирает между альтернативами в категории, что для него триггер, что — барьер. Именно этот масштаб описывает LXM (Life Experience Map): карта жизненного пути потенциальных клиентов, поведение в товарной категории, выбор между продуктами — без привязки к одному решению.
Клиентский опыт (CX) — масштаб, которому в продукте соответствует продукт как целое. Человек уже взаимодействует с решением: путь от первого контакта до использования, повторных покупок, ухода. CJM обычно строится на этом уровне.
Пользовательский опыт (UX) — масштаб, которому в продукте соответствует конкретный сценарий использования: как человек выполняет задачу внутри продукта, на каких шагах возникают проблемы, где теряется ценность.
Опыт в точке контакта (UI) — самый узкий масштаб. В продукте ему соответствует интерфейс: конкретный экран, кнопка, форма. Как человек с ними взаимодействует — что видит, куда нажимает, где ошибается.
Зачем различать масштабы
От масштаба зависят и объект работы в продукте, и инструменты. Если нужно понять, где в жизни пользователя может появиться продукт, как он выбирает между альтернативами — работаем с экосистемой, уровень жизненных сценариев, LXM.
Если улучшаем путь внутри уже выбранного продукта — работаем с продуктом, CX и CJM. Если оптимизируем сценарий или экран — работаем со сценарием и интерфейсом, UX и UI.
LXM как раз про верхние матрёшки: жизненный опыт и опыт жизненных сценариев. Остальные уровни вложены внутрь; им в продукте соответствуют продукт, сценарий, интерфейс.
В сухом остатке: опыт пользователя имеет разные масштабы, и каждому в продуктовом управлении соответствует свой объект работы — экосистема, продукт, сценарий, интерфейс. LXM работает на уровне жизненных сценариев (экосистема); понимание масштаба помогает выбирать инструменты и фокус в продукте.
#lxm@custdevlab #cjm@custdevlab #опыт@custdevlab #полезное@custdevlab
5👍5🌭3🔥2✍1🤩1👾1
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