244. Лучше разговаривать с тем, кого не знаешь

Для customer interview лучше подходят респонденты, с которыми интервьюер не знаком совсем или знаком очень мало.

Когда интервьюер разговаривает с друзьями или хорошими знакомыми, знания о них будут искажать всю информацию: как вопросы, которые будут задачать, так и интерпретировать ответы при обработке результатов.

Например: респондент говорит в интервью, что первый и один из важных критериев переключения на новую модель поведения (привычки питания) — высокая стоимость доставки продуктов.

Интервьюер/исследователь в итоге говорит, что это не важный фактор и вообще не главное при смене модели поведения. Почему? Потому что «я давно знаю этого человека, это не так»...

Читаем стенограмму интервью — видим другую историю. В отчете подобного вывода, конечно нет. А фактор смены модели (событие перехода) это очень важный фактор для продукта!

В сухом остатке: не следует проводить интервью со знакомыми и друзьями; знания и прошлый опыт о них сильно влияют на выводы.

#customerinterview@custdevlab #interview@custdevlab #полезное@custdevlab

P.S. Кстати, это было выявлено благодяря аудиту качества проведенного исследования. Если вам нужен аудит по уже проведенному исследованию — пишите в сообщения сообщества.

245. Когда аудитория это продукт

В некоторых ситуациях продукт — это аудитория. Например, блогер с 1 млн подписчиков. Источник дохода это монетизация через охват аудитории, а также через продажу товаров этой аудитории.

Бывают два подхода:

1. Набрать аудиторию и придумывать товары для нее. Или продукты для конвертации аудитории в деньги

2. Придумать продукт и набирать аудиторию под продукт

Первый подход предпочтительнее, главное, дешево (или бесплатно) набрать аудиторию. Еще лучше, если частотность пользования продуктом высокая.

С точки зрения продуктового подхода это не очень прозрачная история. Как зарабатывать? Где деньги? Что продавать? Где unit для масштабирования?

Пример: приложение с расписанием Кампус. Продуктом пользуются сотни тысяч студентов. Ценность для них — удобный способ смотреть расписание. Частотность у активных пользователей зашкаливает (по несколько раз в день заходят в приложение).

Получается, есть много аудитории с высокой частотностью посещения приложения.

Как ее монетизировать?

В сухом остатке: иногда мы бесплатно накапливаем аудиторию, чтобы потом придумать, какой продукт ей предложить за деньги.

#кейс@custdevlab

246. Парадокс «рынок обуви в Африке»

Если в некоторой Африканской стране бОльшая часть населения не носит обувь, то это означает:

1️⃣ Рынок огромный и мы сможем продавать им много обуви
2️⃣ Рынка нет, и обувь там не продать, возможно она не нужна

Вопрос очень хороший. Он близок к парадоксу «Чесалка для спины», но более глубокий.

Скорее всего, ответ 2️⃣. Поэтому смотреть на рынок «со стороны» недостаточно, нужно проводить custdev-процедуры.

В сухом остатке: если продукта на определенном рынке нет, это не означает, что его все будут покупать, скорее всего, его покупать не станут; узнать причину можно именно на основе custdev-процедур.

#интересное@custdevlab

247. Модель «знания как айсберг»

Знания в предметной области можно представить как айсберг: вершина над водой — это малая часть айсберга, видимая со стороны. На основании верхушки можно оценивать айсберг.

То, что под водой — знания скрытые от внешнего взгляда, но именно в них состоит истинная ценность (масса, объем).

Знания в любой области похожи на модель айсберга. Есть что-то «над водой». По этим знаниям оценивается компетенции специалиста, например.

Для полной оценки важно не столько, что над водой, сколько то, что под водой. Для этого потребуется дополнительный инструментарий (как нырнуть в воду, чтобы рассмотреть подводную часть айсберга).

Например, custdev-специалист. На поверхности будут знания вроде «проблемные и решенческие вопросы», «правило пяти почему» и прочие.

Но настоящая (подводная) ценность этого специалиста в том, как он адаптируется к ответам респондента, как сводит цепочки ответов вместе и в процессе интервью понимает какое влияние на продукт оказывают ответы респондента.

В сухом остатке: знания похожи на айсберг; основная ценность знаний в предметной области в его подводной части, а не надводной, то, что не видно без специальных инструментов и экспертного мнения.

#интересное@custdevlab

248. Научите пользователя: пример как основа обучения

Для пользования продуктом есть барьеры. Некоторые барьеры можно преодолеть через онбординг. Другие — через обучение (курсы или что-то подобное). Онбординг по сути — частный случай обучения.

Как преодолевали барьеры раньше.

В 1937 году владелец сети супермаркетов Силван Голдман году заметил, что люди покупают столько товаров, сколько могут унести в руках. Гипотеза нового продукта была в том, чтобы сделать тележку на колесах. Чем больше покупатель сможет «носить» (возить), тем больше будет средний чек.

Покупатели не торопились использовать новую фичу: женщины не хотели катать еще и по магазину нечто, напоминающее детскую коляску, а мужчинам «коляска» казалась слишком женской.

Как решить проблему
Наняли подставных покупателей, чтобы они ходили по магазину и клали продукты с полок в тележку. Таким образом демонстрировался механизм работы «фичи» в действии.

Не всегда можно демонстрировать как это работает таким простым способом — через подставных пользователей.

Например, когда ВкусВилл открывал свои первый магазины, со временем стало понятно, что не все посетители разбираются в концепции и сути формата. ВкусВилл поставил корзинки двух цветов. Один означал, что не нужно подходить к покупателю и тревожить его вопросами. Второй цвет напротив, был призывом для сотрудников подойти и объяснить как все устроено.

В сухом остатке: обучение — основа знакомства с продуктом; обучение может быть показано через пример другого пользователя.

#интересное@custdevlab #онбординг@custdevlab #обучениепотребителя@custdevlab

249. Реальная и воспринимаемая метрики: Яндекс.Лавка

Мы уже писали про восприятие метрик и их реальные значения. Мы уже писали про управление ожиданием (тут и тут).

На практике с помощью управления ожиданиями можно исправлять негативное отношение к компании или продукту.

Например, Яндекс в службах доставки (Лавка, Еда) иногда намерено завышает время ожидания. При заказе говорит: доставим за 30 минут. Далее говорит: извините, доставим за 50 минут. А по итогу привозит за 35 (все цифры условные).

Зачем так делать?
Если привезти просто за 35 минут, если обещали за 30, то будет разочарование и, возможно, негативные эмоции.

Если привезти за 35, когда обещали 50, да еще и подсветить это: Привезли на 15 минут раньше! Эмоции скорее будут положительные. Не так важно, что сначала они были отрицательными, ведь в соответствии с правилом последнего впечатления важнее последние эмоции.

Тем самым формируется иллюзия быстрой доставки, даже когда она такой не является.

В сухом остатке: даже если заявленную метрику продукта продукта не получается выполнить, можно искусственно управлять ожиданием через намеренное завышение параметра с последующим перевыполнением (привезли быстрее на 15 минут!)

#управлениеожиданием@custdevlab

250. Недостаток продукта как его особенность

Некоторые параметры продукта не сразу получается сделать такими, какими их ожидают клиенты. Например, у нас сервис доставки пельменей по подписке. Пельмени «лепят» бабушки и мамы в декрете. Это вызывает много вопросов: санитарные нормы при производстве; что за сырье используют, где гарантии качества...

Например, персонаж Йода во вселенной «Звездные войны» говорит нарочито странно. Это сделано, чтобы к нему прислушивались, ведь он главный философ фильма. «Недостаток» (или особенность) персонажа — это его главная фишка. Если бы Йода говорил грамматически правильно, то так внимательно его не слушали и на цитаты не разбирали.

Недостаток продукта может быть максимально гипертрофирован.

Вернемся к подписке на пельмени. Мы не станем (пока) заказывать пельмени на производстве, ведь это изменит изначальную идею продукта и повлияет на бизнес-модель. Поэтому нарочно позиционируем продукт как пельмени, которые лепят бабушки. И каждый раз вам будут привозить разные пельмени, потому что бабушек много и они лепят по настроению, а не на заказ. Отсюда идея именно с подпиской: каждый раз сюрприз от какой бабушки пельмени привезут сегодня.

В сухом остатке: недостаток продукта может быть основой его позиционирования.

#позиционирование@custdevlab

251. Product/Market Fit: Ловушка «Дырявое ведро» (Leaky Bucket)

Используя разные методики анализа PMF можно получить противоречащие друг другу результаты. Например, при высоком показателе по тесту Эллиса (>40% ответили, что будут очень разочарованы), но при низком удержании клиентов (Retention) появляется ситуация «Дырявое ведро».

Продукт несет высокую ценность, но имеет критические дефекты в реализации или пользовательском опыте (UX).

Получается, что мы привлекаем пользователей, а они уходят быстрее, чем окупается стоимость их привлечения (CPUser и CAC).

Три признака «дырявого ведра»:

1. Retention падает
Пользователи приходят, но быстро уходят. Растет количество регистраций, а платящих пользователей больше не становится.

2. LTV меньше CAC
Деньги в привлечение одного пользователя вкладываются, а обратно возвращается меньше, чем было потрачено. Юнит-экономика на пользователе не сходится, т.е. уходит в минус.

3. Онбординг не рассказывает о ценности
Пользователь регистрируется, но не понимает, зачем ему продукт. Нет момента осознания ценности в первые минуты использования (TTV слишком большой). Онбординг показывает основные функции, но не показывает ценность, которую получит пользователь.

В сухом остатке: Ситуация «Дырявое ведро» возникает, когда тест Эллиса показал высокий уровень, но удержание пользователей низкое на долгой дистанции и LTV < CAC.

#retention@custdevlab #метрики@custdevlab

252. Product/Market Fit: Ловушка «Золотые наручники»

В прошлом посте мы писали про «Дырявое ведро» — ситуацию, когда по опросам пользователи будут переживать, если продукт исчезнет, но удержание при этом низкое.

Можно получить другие противоречащие друг другу результаты: при высоком удержании клиентов (Retention) — низкая удовлетворенность. Такая ситуаия назыается «Золотые наручники».

Люди пользуются продуктом, удержание есть, но продукт им не нравится. Они продолжают использовать его не потому, что он хороший, а потому что альтернатив нет, или их обязали использовать его (B2B-продукт или государственный сервис без альтернативы).

Получается, что продукт прикован к пользователям, которые недовольны, но вынуждены оставаться из-за отсутствия других вариантов. Как только появится возможность переключиться на альтернативу с лучшим пользовательским опытом, это скорее всего произойдет.

Три признака «золотых наручников»:

1. Удержание высокое, но удовлетворенность низкая
Пользователи остаются, retention хороший, но при этом они недовольны продуктом. Они используют его не по желанию, а по необходимости. Нет альтернативных решений на рынке, которые могли бы заменить продукт.

2. Низкие оценки продукта
Метрики удовлетворенности (NPS, CSAT, CES) низкие или отрицательные. Пользователи жалуются на продукт, критикуют его, но продолжают использовать. Они вынуждены мириться с недостатками, потому что других вариантов нет.

3. Отсутствие альтернатив на рынке или неконкурентное доминирование решения
На рынке нет конкурентов или альтернативных решений, которые могли бы выполнить ту же работу на тех же условиях. Пользователи заперты в продукте не из-за его качества, а из-за монопольного положения или отсутствия выбора.

В сухом остатке: cитуация «Золотые наручники» возникает, когда удержание высокое, но пользователям не нравится продукт; они остаются только потому, что альтернатив нет, как только они появятся — пользователи переключатся на другой продукт (при отсутствии барьеров).

#retention@custdevlab #nps@custdevlab #pmf@custdevlab

253. Побочные метрики продукта

Когда продукт запускается на рынок, не стоит ожидать, что все будет идеально. Говоря языком продуктового управления: если есть целевые метрики, не нужно убирать из ожидания (и результата) «побочные» метрики.

Для иллюстрации этого эффекта обратимся к сериалу «Тед Лассо». В одной из серий Тед Лассо и его помощник-тренер сделали ящик для сбора обратной связи от команды (речь про футбол).

Большая часть собранной информции — шлак и ругань в адрес нового руководства клуба. Среди 80-90% шлака будет 20-10% дельного. Это и есть нормально. Особенно для метрик обратной связи.

Важно не упустить это дельное, а 80-90% шлака это базовый минимум того, как продукт работает.

В классических продуктах это работает похожим образом. Если ввести определенную функцию и ожидать от нее определенного эффекта (результата), то этот целевой результат будет «скрыт» среди множества других «побочных» результатов. Со временем, процент побочного будет уменьшаться, а, возможно, совсем сведется к нулю. Это тоже нормально.

В сухом остатке: если мы планируем продукт или функцию продукта, помимо целевого результата от него нужно ожидать и побочные.

#интересное@custdevlab #результативность@custdevlab

254. Когда возражения не ведут к core job: кейс конструктора приложений Inflow Business

Продукт Inflow Business — конструктор, в котором пользователь сам собирает мобильное приложение и выгружает его в стор. Создание приложения с нуля это сложно, дорого и требует специальных знаний. Делать сайты через конструкор пользователи привыкли, а вот делать приложения через конструктор пока непривычное поведение.

Продажи подобного продукта, как и аналогичных, не происходят гладко и быстро. Изучение возражений обычно приводит к подобным ответам:
— Пришлите демо или примеры
— А вы можете собрать за нас?
— Позже разберёмся, сейчас не до этого

После доработок продукта, и добавления новых «фич» возражения менялись, но проблема оставалась прежней: интерес есть, а до целевых действия не доходит.

С точки зрения LXM модели проблема возникала на этапе активного поиска и принятия решения. На B2B рынке люди склонны увиливать, говоря о причинах, почему им не подходит продукт, вместо того чтобы говорить о реальных барьерах. Иногда это связано с боязнью показать свою некомпетентность как профессионала.

Продукт в итоге перешел к гарантиям результата. У пользователя есть страх, что не получится самостоятельно собрать нужное приложение. Этот страх нужно гарантированно преодолеть: «мы обещаем, что у тебя точно получится».

В итоге, вместо «отправим демо» стали давать демо-доступ, где человек собирает приложение сам. Добавили сценарий «первый каркас приложения за один заход», а для преодоления всех контекстных запросов подключили личного менеджера в боте. В итоге у пользователя появилась понятная точка опоры: он не «смотрит сервис», а пробует и получает результат, после чего решение о продолжении принимается гораздо проще.

В сухом остатке: когда возражения не ведут к core job, нужно переходить к гарантиям результата; на B2B рынке важно обеспечивать преодоление страха «не получится» через конкретные решения, которые показывают: точно получится, вот как.

#кейс@custdevlab #jtbd@custdevlab #b2b@custdevlab

255. Четыре критерия экспресс-оценки стартапа

При оценке стартапа на ранней можно опираться на четыре критерия. Они позволяют быстро оценить перспективы стартапа без глубокого погружения в детали продукта или технологии. Когда-то мы уже писали про три критерия, но переосмысление действительности позволяет добавить еще один, критически важный.

1. Размер целевой аудитории
Размер той части рынка, которая реально может стать клиентами. Большая аудитория сама по себе не гарантирует успех, но она создает пространство для роста. Если целевая аудитория слишком узкая, стартап может столкнуться с ограничениями масштабирования уже на ранних этапах.
Важно понимать разницу между общей аудиторией рынка и той ее частью, которая соответствует целевому сегменту. Например, рынок всех людей, которые пользуются смартфонами, и рынок людей, которые готовы платить за конкретное приложение для управления финансами — это разные по размеру аудитории.

2. «Стоимость» и легкость доступа к аудитории
Это не только финансовые затраты на привлечение клиента (CAC), но и сложность самого процесса поиска ЦА. Если аудиторию сложно найти, если нет понятных каналов коммуникации, если требуется много времени и ресурсов на установление контакта, то даже при большом размере аудитории стартап столкнется с проблемами роста.
Легкость доступа означает, что есть понятные способы донести продукт до целевой аудитории, и эти способы не требуют экстремальных затрат. Если аудитория — это узкоспециализированные эксперты, которых сложно найти и с которыми сложно установить контакт, то стоимость привлечения будет высокой, даже если размер аудитории достаточен.

3. Частота потребления и средний чек
Это определяет unit-экономику стартапа. Если продукт используется редко, а средний чек низкий, то даже при успешном привлечении клиентов стартап может не достичь прибыльности. Высокая частота потребления компенсирует низкий средний чек, а высокий средний чек может компенсировать низкую частоту. Но если оба показателя низкие, бизнес-модель становится неустойчивой.
Важно понимать, что частота потребления связана не только с типом продукта, но и с тем, насколько продукт встраивается в привычную модель поведения пользователя. Продукт, который используется ежедневно, но стоит 100 рублей, может быть более выгодным, чем продукт, который используется раз в год, но стоит 10 000 рублей, если учитывать затраты на привлечение и удержание клиента.

4. Изменение привычной модели поведения
Это самый сложный для оценки критерий, но он критически важен. Если продукт требует от пользователя кардинального изменения привычек, вероятность его принятия резко снижается. Пользователи сопротивляются изменениям, особенно если они затрагивают устоявшиеся паттерны поведения. Чем меньше изменений требуется, тем выше шанс на успешное внедрение продукта.
Но если изменения необходимы, важно понимать, есть ли у пользователей достаточная мотивация для их принятия. Например, переход с наличных на бесконтактную оплату требовал изменения привычки доставать кошелек, но мотивация была высокой — скорость и удобство. А вот переход на новый мессенджер, когда все контакты уже в другом, требует больших изменений и часто встречает сопротивление.

Четыре критерия взаимосвязаны. Например, если продукт требует значительного изменения поведения, но при этом частота потребления высокая, а средний чек достаточный, то стартап может преодолеть барьер принятия. Или если доступ к аудитории сложный и дорогой, но размер аудитории огромный, а частота потребления высокая, то инвестиции в привлечение могут окупиться. Слабость по одному критерию может быть компенсирована силой по другим, но критическая слабость по нескольким критериям одновременно делает стартап высокорискованным.

В сухом остатке: четыре критерия взаимосвязаны, и слабость по одному может быть компенсирована силой по другим, но критическая слабость по нескольким критериям одновременно делает стартап высокорискованным.

#стартап@custdevlab #оценка@custdevlab #unitэкономика@custdevlab

256. Ценность в зависимости от ситуации: важное ограничение JTBD и AJTBD

При проведении интервью по JTBD очень часто допускают ошибку: спрашивают про работу без контекста. «Что ты делаешь, когда покупаешь продукты?» — вопрос слишком общий.

Ценность продукта и сама работа зависят от ситуации. Покупать продукты вечером после работы и покупать продукты, когда голоден и очень хочешь есть, — это разные работы. В первом случае человек может спокойно сравнивать цены, выбирать новое, планировать меню на неделю. Во втором — нужно быстро утолить голод, критерии выбора другие, конкуренты другие (доставка, кафе, снек из автомата). Одна и та же категория «продукты», но разные ситуации, разные работы.

Если в интервью не уточнять контекст — когда, где, при каких обстоятельствах человек оказался в этой ситуации, — мы получаем размытую «работу» и теряем то, ради чего вообще нужен JTBD: понимание, какую конкретную прогрессию клиент пытается достичь и что его толкает к действию именно сейчас. Без ситуации ценность продукта не определишь.

В сухом остатке: при интервью по JTBD нельзя спрашивать про работу без контекста; одна и та же категория в разных ситуациях — разные работы; контекст (когда, где, при каких обстоятельствах) нужно выяснять каждый раз.

#jtbd@custdevlab #customerinterview@custdevlab #контекст@custdevlab

257. Когда custdev-интервью не нужно

Интервью — не универсальный инструмент. Есть ситуации, когда оно почти ничего не даёт: продукт уже есть, гипотеза «каким он должен быть» сформулирована, и нужно её валидировать.

В таком случае интервью лишь трата сил, времени и денег. Люди плохо предсказывают своё поведение, зато хорошо реагируют на реальное предложение. Лучше просто пробовать продавать: запустить трафик, выставить цену, показать оффер и посмотреть, кто платит, кто отказывается, на каком шаге.

Интервью нужно, когда важно понять проблему, работу, контекст, сегмент — то, что предшествует «каким должен быть продукт». Когда же продукт уже есть и вопрос именно «каким он должен быть», ответ даёт рынок: конверсия, отказы, возражения при продаже, поведение после покупки.

Это не значит, что разговоры с людьми бесполезны в этой ситуации — но их роль в другом. Опрашивать «что бы ты хотел в продукте?» при готовом решении чаще всего слабее, чем проверять гипотезу продажей и трафиком.

В CDDC (Customer Development Design Canvas) как раз заложено разделение опросной части и MVP: на этапе Customer Discovery — интервью, опросы, понимание проблемы и формулировка требований к решению; на этапе Customer Validation — MVP, трафик, продажи, проверка готовности платить.

Вопрос «каким должен быть продукт» при уже существующем продукте относится к Validation: проверять нужно через оффер и рынок, а не через опросы.

В сухом остатке: если продукт уже есть и ты проверяешь, каким он должен быть, — не начинай с интервью. Пробуй продавать, запускай трафик; интервью оставляй для понимания проблемы, работы и контекста, а не для голосования по фичам.

#custdev@custdevlab #customerinterview@custdevlab #cddc@custdevlab #полезное@custdevlab

Собрали посты про то, когда 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

258. Видение предпринимателя как необходимый навык

Крайне важно развивать широту видения (насмотренность). Это помогает иначе смотреть на свой продукт. Предприниматель, который долго работает над одной идеей, застревает в одном ракурсе: видит продукт через призму собственных предположений, привычных решений, ограничений, которые сам же и создал. Широта видения позволяет выйти за эти рамки и увидеть продукт с другой стороны.

В CustDev-школе мы придумали одно упражнение для развития видения: идеи одного продукта даем на разбор другим предпринимателям. Когда человек смотрит на чужой продукт, он не знает истории его создания, не знает, почему были приняты те или иные решения, не знает ограничений, которые заложил автор. Он видит только саму идею и начинает разбирать её с чистого листа: какую проблему решает, для кого, какими способами, какие есть альтернативы, что можно улучшить. Получается интересный взгляд на продукт — свежий, без предрассудков.

Например, идею проекта Чек-Чирик (ИИ-ассистент по выбору техники) дали на разбор студентам МФТИ. Предприниматели, которые не были знакомы с продуктом, должны были протестировать идею за 3 часа. Т.е. придумать способы в рамках CDDC как быстро понять востребованность идеи.

Их подходы к тестирвоанию не были лучше или хуже, чем в оригинальном проекте — просто они были другими, потому что видение каждого предпринимателя отличается. Такое упражнение помогает расширить собственное видение продукта и увидеть возможности, которые раньше не замечал.

В сухом остатке: широта видения помогает иначе смотреть на продукт и находить новые возможности. Разбирать идеи своего продукта с другими предпринимателями — способ выйти за рамки собственных предположений и увидеть продукт свежим взглядом.

#видение@custdevlab #мышление@custdevlab #полезное@custdevlab

259. Два подхода к созданию гайда для customer interview

Есть два способа составить гайд для интервью, и выбор зависит от того, что уже известно о продукте и что необходимо выяснить. Не важно, речь про проблемное или решенческое интервью.

От решения к вопросам
Известно, что нужно сделать с продуктом: поднять цену, повысить конверсию из регистрации в накопление баллов, изменить тарифную сетку.
После необходимо определить информацию, которая нужна для этого решения: как потребитель относится к цене сейчас, почему пользователи не накапливают баллы, что влияет на выбор тарифа.
И только потом формулируются вопросы, которые эту информацию позволят выявить. Такой подход подходит, когда есть конкретная гипотеза о продукте или конкретное действие, которое нужно проверить или обосновать. Интервью становится инструментом валидации или сбора данных для принятия решения.

От вопроса к решению
Начинается с вопросов, которые помогают понять проблему, работу, контекст, сегмент. Например: «Как вы сегодня решаете эту проблему?» или «Расскажите про этапы вашего процесса».
Из ответов выясняется, как проблема решается сейчас, каким образом потребитель мыслит, где в JTBD-процессе может вписаться продукт, кто конкуренты решения.
И только после определяем, что делать с продуктом на основе собранной информации.
Такой подход подходит на ранних этапах, когда нужно понять проблему, работу клиента, контекст использования — то, что предшествует формулировке гипотез о продукте. Интервью становится инструментом исследования и открытия.

В первом случае мы движемся от известного решения к неизвестной информации.
Во втором — от открытых вопросов к неизвестному решению.

Первый подход фокусирован на валидации, второй — на исследовании.

Выбор зависит от стадии работы с продуктом и от того, что именно нужно выяснить.

В сухом остатке: два подхода к созданию гайда — от решения к вопросам (когда есть конкретная гипотеза или действие) и от вопроса к решению (когда нужно исследовать проблему и контекст); первый для валидации, второй для открытия.

#customerinterview@custdevlab #методика@custdevlab #гайд@custdevlab

260. Что такое MVP и как его использовать в CDDC

MVP — минимально жизнеспособный продукт. Часто MVP понимают неправильно, и это приводит к ошибкам.

Что не является MVP: последовательная сборка частей продукта. Сначала делаем колесо, потом шасси, потом кузов, и только в конце получается автомобиль. До финальной сборки ни одна часть не функциональна сама по себе — колесо не ездит, шасси не перевозит. Это не MVP, потому что на каждом этапе продукт не доставляет ценность пользователю. Пользователь не может использовать части продукта для решения своей задачи.

Также не является MVP: создание разных функциональных продуктов вместо итераций одного. Сначала делаем самокат, потом велосипед, потом мотоцикл, и только потом — автомобиль. Каждый продукт функционален, но это не итерации одного решения. Самокат, велосипед и мотоцикл — это не версии автомобиля, это разные продукты. MVP должен быть итерацией одного продукта, а не последовательностью разных решений.

Что является MVP: итерации одного функционального продукта, который доставляет ценность с первого этапа. Сначала делаем примитивную тележку — она простая, но функциональна: перевозит людей и грузы. Потом пикап — более развитая версия, но та же суть: перевозка. Потом простой автомобиль — еще более развитая версия. И наконец финальная версия — автомобиль. На каждом этапе продукт функционален и доставляет ценность, просто в разной степени. Каждая итерация — это полный, работающий продукт, который можно использовать.

MVP должен быть функциональным и доставлять ценность с самого начала, а не собираться по частям или заменяться другими продуктами. Каждая итерация MVP — это минимальная, но полная версия продукта, которая решает задачу пользователя и позволяет собирать данные для следующих итераций. В CDDC MVP используется при переходе от Discovery к Validation.

В сухом остатке: MVP — это не части продукта и не разные продукты, а итерации одного функционального продукта, который доставляет ценность с первого этапа; каждая версия MVP должна быть полной и рабочей, просто минимальной.

#mvp@custdevlab #гипотезы@custdevlab #полезное@custdevlab

Оригинальное изображение: Fred Voorhorst

Собрали для удобства в одном посте всё про 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