171. Миф о размере выборки для количественного исследования
В литературе про исследования часто фигурирует цифра 384. Считается, что в количественных исследованиях это максимально необхомое количество человек, которых нужно опросить для получения 95% вероятности попасть в интервал +/-5%. И не важно, целевая аудитория составляет 10 тыс. человек или 100 млн. Всему причина — теория вероятности.
Например, мы опросили 384 человека и узнали, что уровень знания бренда составляет 34%, значит если бы мы опросили всех представителей целевой аудитории, то с вероятностью 95% уровень знания бренда был бы в диапазоне 29-39%.
Для маркетинговых исследований этой точности обычно хватает. Потому что если захотим увеличить точность, скажем, до 99% (вместо 95%), а разброс значений до +/-1%, то размер выборки нужно было бы увеличить в 43 раза!
Небольшой прирост точности будет связан со значительн увеличением бюджета исследования.
В теории оно так и работает. Но лишь в случае простой случайной выборки. Однако в исследовании потребителей простая случайная выборка попросту невозможна.
Простая случайная выборка может быть только тогда, когда для каждого представителя нашей целевой аудитории существует одинаковая вероятность попасть в выборку. Одинаковая вероятность означает, что мы должны иметь равный доступ к каждому представителю нашей ЦА.
Однако, даже поименный список часто составить невозможно, не говоря о других методах идентификации потребителей. Представим, что наша ЦА — женщины 25-34 года. Сколько их в Москве? Сколько их в России? Пока мы будем составлять список, кто-то уедет, кто-то поменяет имя. Получается, что для таких представителей нашей ЦА вероятность попасть в нашу выборку уже отличается. А значит простой случайный отбор невозможен.
В подобных исследованиях мы используем принципы здравого смысла при определении размера выборки, и квотирование при определении ее структуры. Для качественных исследований размеры выборки еще меньше.
В сухом остатке: размер выборки в 384 респондента в исследовании потребителей и обоснование этого размера через формулу недостаточны.
#выборка@custdevlab
В литературе про исследования часто фигурирует цифра 384. Считается, что в количественных исследованиях это максимально необхомое количество человек, которых нужно опросить для получения 95% вероятности попасть в интервал +/-5%. И не важно, целевая аудитория составляет 10 тыс. человек или 100 млн. Всему причина — теория вероятности.
Например, мы опросили 384 человека и узнали, что уровень знания бренда составляет 34%, значит если бы мы опросили всех представителей целевой аудитории, то с вероятностью 95% уровень знания бренда был бы в диапазоне 29-39%.
Для маркетинговых исследований этой точности обычно хватает. Потому что если захотим увеличить точность, скажем, до 99% (вместо 95%), а разброс значений до +/-1%, то размер выборки нужно было бы увеличить в 43 раза!
Небольшой прирост точности будет связан со значительн увеличением бюджета исследования.
В теории оно так и работает. Но лишь в случае простой случайной выборки. Однако в исследовании потребителей простая случайная выборка попросту невозможна.
Простая случайная выборка может быть только тогда, когда для каждого представителя нашей целевой аудитории существует одинаковая вероятность попасть в выборку. Одинаковая вероятность означает, что мы должны иметь равный доступ к каждому представителю нашей ЦА.
Однако, даже поименный список часто составить невозможно, не говоря о других методах идентификации потребителей. Представим, что наша ЦА — женщины 25-34 года. Сколько их в Москве? Сколько их в России? Пока мы будем составлять список, кто-то уедет, кто-то поменяет имя. Получается, что для таких представителей нашей ЦА вероятность попасть в нашу выборку уже отличается. А значит простой случайный отбор невозможен.
В подобных исследованиях мы используем принципы здравого смысла при определении размера выборки, и квотирование при определении ее структуры. Для качественных исследований размеры выборки еще меньше.
В сухом остатке: размер выборки в 384 респондента в исследовании потребителей и обоснование этого размера через формулу недостаточны.
#выборка@custdevlab
5❤6👍3🐳2🔥1🌭1
172. Как обойти модель поведения потребителя, если продукт не может ее изменить
Стартап «Битком 24», о котором мы много писали тут, тут и даже тут, предлагал сервис по бронированию столика в ресторане. По идее, пользователь заходил в приложение, изучал варианты ресторанов, выбирал тот, который нравился, жал на кнопку «Забронировать», выбирал день, время (иногда и место).
К сожалению, большинство пользователей предпочитало по привычке звонить, нажатие кнопки для них не было удобным решением. Мы ввели функцию звонка в ресторан. Только вот звонок был не в ресторан, а в наш колл-центр, но пользователь об этом не знал. Мы даже придумали сложную систему номеров, чтобы в случае, если пользователь звонил в несколько ресторанов из нашего приложения, номера разных ресторанов не повторялись.
Однако даже система звонков не позволяла получить жизнеспособную конверсию в бронирование: пользователи заходили в приложение, смотрели много ресторанов, выбирали, куда пойти... и просто шли туда, без звонка, без кнопки.
Низкая конверсия делала сервис не только убыточным, он был и инвестиционно непривлекательным. Обратившись к крупному игроку — потенциальному инвестору, мы получили предложение научиться монетизировать сервис не через гостя ресторана, а через сам ресторан. Нужно было придумать способ, чтобы ресторан нам платил не процент от каждой брони, а какую-то фиксированную, пусть даже небольшую сумму.
Мы не придумали. В итоге — закрылись.
Прошло 10 лет и вот другой стартап придумал. Они предлагают ресторану заменить функцию приема звонков сотрудниками заведения на прием звонков голосовым ботом с AI-функционалом. Бот работает быстрее человека, понимает любой язык (что важно, если ресторан работает с иностранными туристами), а также мгновенно проверяет наличие или отсутствие возможных слотов для бронированаия. Стоит это от 200 долларов в месяц. Платит ресторан.
Показательно в этих историях то, что модель поведения потребителей осталась нетронутой. Потребитель как привык звонить в ресторан, так и продолжает это делать. Если нельзя изменить модель поведения (что очень долго и очень дорого), лучше «обойти» ее.
В сухом остатке: если нельзя научить людей не звонить, то можно заменить сотрудника в ресторане, принимающего звонок — поведение ресторана изменить будет проще.
#кейсы@custdevlab #модельповедения@custdevlab
Стартап «Битком 24», о котором мы много писали тут, тут и даже тут, предлагал сервис по бронированию столика в ресторане. По идее, пользователь заходил в приложение, изучал варианты ресторанов, выбирал тот, который нравился, жал на кнопку «Забронировать», выбирал день, время (иногда и место).
К сожалению, большинство пользователей предпочитало по привычке звонить, нажатие кнопки для них не было удобным решением. Мы ввели функцию звонка в ресторан. Только вот звонок был не в ресторан, а в наш колл-центр, но пользователь об этом не знал. Мы даже придумали сложную систему номеров, чтобы в случае, если пользователь звонил в несколько ресторанов из нашего приложения, номера разных ресторанов не повторялись.
Однако даже система звонков не позволяла получить жизнеспособную конверсию в бронирование: пользователи заходили в приложение, смотрели много ресторанов, выбирали, куда пойти... и просто шли туда, без звонка, без кнопки.
Низкая конверсия делала сервис не только убыточным, он был и инвестиционно непривлекательным. Обратившись к крупному игроку — потенциальному инвестору, мы получили предложение научиться монетизировать сервис не через гостя ресторана, а через сам ресторан. Нужно было придумать способ, чтобы ресторан нам платил не процент от каждой брони, а какую-то фиксированную, пусть даже небольшую сумму.
Мы не придумали. В итоге — закрылись.
Прошло 10 лет и вот другой стартап придумал. Они предлагают ресторану заменить функцию приема звонков сотрудниками заведения на прием звонков голосовым ботом с AI-функционалом. Бот работает быстрее человека, понимает любой язык (что важно, если ресторан работает с иностранными туристами), а также мгновенно проверяет наличие или отсутствие возможных слотов для бронированаия. Стоит это от 200 долларов в месяц. Платит ресторан.
Показательно в этих историях то, что модель поведения потребителей осталась нетронутой. Потребитель как привык звонить в ресторан, так и продолжает это делать. Если нельзя изменить модель поведения (что очень долго и очень дорого), лучше «обойти» ее.
В сухом остатке: если нельзя научить людей не звонить, то можно заменить сотрудника в ресторане, принимающего звонок — поведение ресторана изменить будет проще.
#кейсы@custdevlab #модельповедения@custdevlab
5🔥9❤4👍4🌭2🐳1🤝1
173. Первая мысль о продукте
В jtbd-артефактах Боба Моэсты есть последовательность этапов, через которые проходит пользователь, прежде чем купит и будет использовать товар, точнее «наймет его на работу».
Первый этап этого процесса — First Thought. То есть первая мысль о продукте или смене существующего продукта на новый. Триггером этой мысли может быть что угодно.
Если человек захотел купить игровую консоль, триггером (той самой первой мыслью) мог стать рилс с кадрами игры, рассказы друзей об этой игре.
Без этой первой мысли не возникает спроса.
С контентом все интереснее. Например, по результатам исследований выяснилось, что определенная часть целевой аудитории задумывается о просмотре конкретного фильма после того, как увидит отрывок из этого фильма в соцсетях. Это может быть кусочек видео, может быть несколько кадров с субтитрами. Важно, что это просто встречается в ленте и человек не прикладывал специальных усилий для поиска.
Чем больше таких триггеров мы сможем определить или придумать, тем больше шансов, что потребитель наймет наш продукт на работу.
В сухом остатке: первая мысль по jtbd (Моэста) запускает процесс, который в итоге приводит к найму нашего продукта.
#jtbd@custdevlab #jtbdэтапы@custdevlab
В jtbd-артефактах Боба Моэсты есть последовательность этапов, через которые проходит пользователь, прежде чем купит и будет использовать товар, точнее «наймет его на работу».
Первый этап этого процесса — First Thought. То есть первая мысль о продукте или смене существующего продукта на новый. Триггером этой мысли может быть что угодно.
Если человек захотел купить игровую консоль, триггером (той самой первой мыслью) мог стать рилс с кадрами игры, рассказы друзей об этой игре.
Без этой первой мысли не возникает спроса.
С контентом все интереснее. Например, по результатам исследований выяснилось, что определенная часть целевой аудитории задумывается о просмотре конкретного фильма после того, как увидит отрывок из этого фильма в соцсетях. Это может быть кусочек видео, может быть несколько кадров с субтитрами. Важно, что это просто встречается в ленте и человек не прикладывал специальных усилий для поиска.
Чем больше таких триггеров мы сможем определить или придумать, тем больше шансов, что потребитель наймет наш продукт на работу.
В сухом остатке: первая мысль по jtbd (Моэста) запускает процесс, который в итоге приводит к найму нашего продукта.
#jtbd@custdevlab #jtbdэтапы@custdevlab
5❤9👍3🔥3🌭2
174. Целевая аудитория и целевая аудитория
Целевая аудитория — это люди, на которых продукт ориентирован. Может быть несколько сегментов целевой аудитории у одного продукта. Выделять целевую аудиторию можно на основе разных параметров.
Условно, если представить всю численность населения региона как генеральную совокупность, то выделение целевой аудитории представляет процесс выбора именно тех людей, которым продукт нужен больше всего.
Например, продукт нацелен на женщин, значит «убираем» всех мужчин. Далее, определенный возраст — убираем все остальные возраста. Определенная модель поведения — убираем все другие. То, что останется — наша целевая аудитория.
В теории все просто. На практике нет.
Важно понимать, что при работе с целевыми аудиториями, мы работаем с двумя ее размерностями. Первая — количество аудитории, которое нам нужно (узкая размерность). Вторая — реально достижимая аудитория (широкая размерность).
Предположим, что мы выделили аудиторию по 1) полу, 2) возрасту, 3) интересам, а также 4) на основе работ, для выполнения которых продукт нанимают.
Наша ЦА: 1) женщины, 2) 25-29 лет, 3) интересующиеся финтесом, правильным питанием и заботой о здоровье; а с точки зрения jtbd-подхода 4) им нужна поддержка в случае, когда важно не сорваться с диеты или с ПП.
Мы можем работать с аудиторией 1) женщины, 2) 25-29 лет, 3) интересующиеся фитнесом и пр. Их можно «получить» через digital-каналы, так как существуют настройки таргетинга на эти параметры и другие хитрости. А вот определить ситуацию, в которой 4) «понадобится поддержка, когда пользователь вот-вот сорвется с диеты» определить практически невозможно. Самое главное ограничение, это как посчитать количество такой аудитории.
Скорее всего, таргетирование будет направлено на более высокий уровень описания (пол, возраст, интересы), а вот среди всей аудитории через коммуникационное сообщение придется таргетировать более точечно на ситуацию и триггер.
Это приведет к увеличению стоимости привлечения клиентов. И чем больше разрыв между размерностями, тем больший прирост стоиомсти привелчения будет.
В сухом остатке: при опредлении ЦА существуют две размерности — то, что мы реально можем посчитать, и то, что посчитать не можем, но для нашего продукта это важно.
#ца@custdevlab #таргетирование@custdevlab
P.S. Часто после применения jtbd-подхода описание сегмента выглядит таким образом, что невозможно понять, на какие характеристики таргетироваться, т.е. где и как искать таких людей остается загадкой.
Целевая аудитория — это люди, на которых продукт ориентирован. Может быть несколько сегментов целевой аудитории у одного продукта. Выделять целевую аудиторию можно на основе разных параметров.
Условно, если представить всю численность населения региона как генеральную совокупность, то выделение целевой аудитории представляет процесс выбора именно тех людей, которым продукт нужен больше всего.
Например, продукт нацелен на женщин, значит «убираем» всех мужчин. Далее, определенный возраст — убираем все остальные возраста. Определенная модель поведения — убираем все другие. То, что останется — наша целевая аудитория.
В теории все просто. На практике нет.
Важно понимать, что при работе с целевыми аудиториями, мы работаем с двумя ее размерностями. Первая — количество аудитории, которое нам нужно (узкая размерность). Вторая — реально достижимая аудитория (широкая размерность).
Предположим, что мы выделили аудиторию по 1) полу, 2) возрасту, 3) интересам, а также 4) на основе работ, для выполнения которых продукт нанимают.
Наша ЦА: 1) женщины, 2) 25-29 лет, 3) интересующиеся финтесом, правильным питанием и заботой о здоровье; а с точки зрения jtbd-подхода 4) им нужна поддержка в случае, когда важно не сорваться с диеты или с ПП.
Мы можем работать с аудиторией 1) женщины, 2) 25-29 лет, 3) интересующиеся фитнесом и пр. Их можно «получить» через digital-каналы, так как существуют настройки таргетинга на эти параметры и другие хитрости. А вот определить ситуацию, в которой 4) «понадобится поддержка, когда пользователь вот-вот сорвется с диеты» определить практически невозможно. Самое главное ограничение, это как посчитать количество такой аудитории.
Скорее всего, таргетирование будет направлено на более высокий уровень описания (пол, возраст, интересы), а вот среди всей аудитории через коммуникационное сообщение придется таргетировать более точечно на ситуацию и триггер.
Это приведет к увеличению стоимости привлечения клиентов. И чем больше разрыв между размерностями, тем больший прирост стоиомсти привелчения будет.
В сухом остатке: при опредлении ЦА существуют две размерности — то, что мы реально можем посчитать, и то, что посчитать не можем, но для нашего продукта это важно.
#ца@custdevlab #таргетирование@custdevlab
5❤7👍4🔥2🌭2🐳1
175. Экстремальное поведение потребителя
В продукте могут быть разные модели поведения потребителя. Одни применяются большим числом потребителей, другие малым.
Например, пользователь сервиса по бронированию столиков в ресторанах в одном из конкурентов «Битком 24» бронировала столик для бизнес-ланча в Гудмане. И делала это каждый будний день на протяжении долгих месяцев. Подробнее мы писали об этом.
Другой пример уже у пользователя Битком.
Женщина хотела забронировать конкретный столик в конкретном ресторане. Она сделала заявку на него, перезвонила и уточнила, тот ли самый столик закрепили за ней. После позвонила через день, чтобы уточнить, а точно ли именно этот столик забронирован для нее.
Через день она же позвонила с нового номера и попыталась на те же время и дату забронировать этот столик на другое имя. Успокоилась только тогда, когда услышала, что столик занят.
Такие модели поведения есть в каждом продукте. Обычно их называют экстремальными.
В процессе customer interview важно уметь такие модели не путать с более распространенными моделями поведения, иначе получится продукт для экстремальных пользователей, а таких обычно очень мало.
В сухом остатке: экстремальные модели могут быть, главное научиться отличать их от более распространенных.
#поведениепотребителей@custdevlab #модельповедения@custdevlab
P.S. При расчете метрик продукта экстремальное поведение лучше исключать, чтобы не было искажения в метриках.
В продукте могут быть разные модели поведения потребителя. Одни применяются большим числом потребителей, другие малым.
Например, пользователь сервиса по бронированию столиков в ресторанах в одном из конкурентов «Битком 24» бронировала столик для бизнес-ланча в Гудмане. И делала это каждый будний день на протяжении долгих месяцев. Подробнее мы писали об этом.
Другой пример уже у пользователя Битком.
Женщина хотела забронировать конкретный столик в конкретном ресторане. Она сделала заявку на него, перезвонила и уточнила, тот ли самый столик закрепили за ней. После позвонила через день, чтобы уточнить, а точно ли именно этот столик забронирован для нее.
Через день она же позвонила с нового номера и попыталась на те же время и дату забронировать этот столик на другое имя. Успокоилась только тогда, когда услышала, что столик занят.
Такие модели поведения есть в каждом продукте. Обычно их называют экстремальными.
В процессе customer interview важно уметь такие модели не путать с более распространенными моделями поведения, иначе получится продукт для экстремальных пользователей, а таких обычно очень мало.
В сухом остатке: экстремальные модели могут быть, главное научиться отличать их от более распространенных.
#поведениепотребителей@custdevlab #модельповедения@custdevlab
5👍9🌭5❤4🐳2
176. В продукте всегда есть проблемы
Сложный продукт/сервис всегда работает со сбоями, особенно если ключевые функции выполняет человек. Чтобы предсказывать такие болевые точки можно использовать концепцию сервис-дизайна.
Рассмотрим нетипичный продукт со значительной сервисной составляющей — вакцинация.
Предположим, соискателю в организации говорят, что его примут на работу только при наличии антител к Кори или при наличии прививки.
Антител нет (пришлось сдать анализ), надо делать прививку. Запись на прием к терапевту оказалась быстрой (день в день). Но терапевт уточняет в «прививочной» наличие вакцин от Кори. Оказывается, что их нет в наличии. Когда будет? Неизвестно. Почему нельзя сразу сообщить БЕЗ записи к терапевту — вопрос для обсуждения. Но главное, почему нельзя сообщить о примерной дате поступления?
Человек негодует, ему нужно срочно получить прививку, ведь работа может достаться другому. Поиск в интернете быстро навел на горячую линию по вакцинации.
Звонок на горячую линию выглядел примерно так:
— Мне нужна прививка от кори.
— Запишитесь к терапевту.
— Уже записывался, прививок нет.
— Прививки есть.
— Терапевт сказал, что прививок нет.
— Значит они зарезервированы на какой-то случай.
— А что мне делать?
— Записывайтесь к терапевту еще раз…
Как это выглядит со стороны владельца продукта: вакцины поставляются, вакцины реализуются, колл-центр звонки отрабатывает, процент вакцинированного населения растет. В продукте все хорошо.
Как это выглядит со стороны пользователя: полнейший хаос, абсолютное отсутствие ощущения контроля, много потраченного времени, паника из-за возможного срыва трудоустройства, негативное отношение к системе медицинского обслуживания.
Как исправить ситуацию: проанализировать продукт с позиции клиента, например, через CJM; внедрить инструменты обратной связи, новые метрики.
Например, FCRR (First Contact Resolution Rate) — метрика, которая показывает процент решеных проблем клиента при первом обращении. Если этот процент низкий, значит клиентам приходится звонить несколько раз, чтобы решить проблему. Показатель одновременно показывает и степень ненужной нагрузки на колл-центр. Но работать этот показатель сможет только при наличии обратной связи от звонившего. Как ни старайся, перекраивать сервис для продукта «вакцинация» нужно основательно.
В сухом остатке: у любого продукта есть проблемы всегда; важно принять это как базовый принцип управления продуктом и внедрять принципы сервис-дизайна.
#сервисдизайн@custdevlab #клиентскийопыт@custdevlab
Сложный продукт/сервис всегда работает со сбоями, особенно если ключевые функции выполняет человек. Чтобы предсказывать такие болевые точки можно использовать концепцию сервис-дизайна.
Рассмотрим нетипичный продукт со значительной сервисной составляющей — вакцинация.
Предположим, соискателю в организации говорят, что его примут на работу только при наличии антител к Кори или при наличии прививки.
Антител нет (пришлось сдать анализ), надо делать прививку. Запись на прием к терапевту оказалась быстрой (день в день). Но терапевт уточняет в «прививочной» наличие вакцин от Кори. Оказывается, что их нет в наличии. Когда будет? Неизвестно. Почему нельзя сразу сообщить БЕЗ записи к терапевту — вопрос для обсуждения. Но главное, почему нельзя сообщить о примерной дате поступления?
Человек негодует, ему нужно срочно получить прививку, ведь работа может достаться другому. Поиск в интернете быстро навел на горячую линию по вакцинации.
Звонок на горячую линию выглядел примерно так:
— Мне нужна прививка от кори.
— Запишитесь к терапевту.
— Уже записывался, прививок нет.
— Прививки есть.
— Терапевт сказал, что прививок нет.
— Значит они зарезервированы на какой-то случай.
— А что мне делать?
— Записывайтесь к терапевту еще раз…
Как это выглядит со стороны владельца продукта: вакцины поставляются, вакцины реализуются, колл-центр звонки отрабатывает, процент вакцинированного населения растет. В продукте все хорошо.
Как это выглядит со стороны пользователя: полнейший хаос, абсолютное отсутствие ощущения контроля, много потраченного времени, паника из-за возможного срыва трудоустройства, негативное отношение к системе медицинского обслуживания.
Как исправить ситуацию: проанализировать продукт с позиции клиента, например, через CJM; внедрить инструменты обратной связи, новые метрики.
Например, FCRR (First Contact Resolution Rate) — метрика, которая показывает процент решеных проблем клиента при первом обращении. Если этот процент низкий, значит клиентам приходится звонить несколько раз, чтобы решить проблему. Показатель одновременно показывает и степень ненужной нагрузки на колл-центр. Но работать этот показатель сможет только при наличии обратной связи от звонившего. Как ни старайся, перекраивать сервис для продукта «вакцинация» нужно основательно.
В сухом остатке: у любого продукта есть проблемы всегда; важно принять это как базовый принцип управления продуктом и внедрять принципы сервис-дизайна.
#сервисдизайн@custdevlab #клиентскийопыт@custdevlab
1👍8🔥6🌭5❤2🤝2🐳1
177. Как потребитель сравнивает
В исследовании краткосрочной аренды самокатов (кикшеринг) пользователи рассказывали, что при наличии выбора нескольких самокатов, на которых можно совершить поездку (например, Whoosh, Яндекс, Urent), выбор чаще всего основывается на цене.
То есть скорее выбор будет сделан в пользу самого дешевого решения, потому что у аренды самокатов другие параметры сравнения или одинаковые, или сложны для сравнения.
Но в реальности цены на аренду самокатов зависят от разных параметров. Например, у Whoosh динамическое ценообразование, которое зависит от спроса и предложения самокатов в конкретной локации.
Поэтому для сравнения цен пользователю нужно открыть несколько приложений. Посмотреть, какой уровень цен сейчас в конкретном месте. А это в целом представляется как очень муторная и сложная работа: подойти к самокату, открыть приложение, отсканировать QR-код на самокате, посмотреть на цену, попробовать другой тариф, например, фиксированную цену за поездку до нужной точки… и так 3 раза (если три разных самоката на месте).
Скорее всего, в интервью была озвучена социально-приемлемая модель поведения. И проводить интервью, чтобы выяснить реальную модель поведения, может оказаться ошибкой.
Для исправления ситуации отлично подходит метод наблюдения: берем пользователя за руку, приводим к парковсе с самокатами и просим показать в реальности, как он будет выбирать. Еще лучше, когда он не знает, что мы за ним наблюдаем в этой ситуации. Но это уже сложнее.
В сухом остатке: не все данные, собранные в ходе интервью, на практике могут оказаться реальными.
#модельповедения@custdevlab #какпотребительсравнивает@custdevlab
В исследовании краткосрочной аренды самокатов (кикшеринг) пользователи рассказывали, что при наличии выбора нескольких самокатов, на которых можно совершить поездку (например, Whoosh, Яндекс, Urent), выбор чаще всего основывается на цене.
То есть скорее выбор будет сделан в пользу самого дешевого решения, потому что у аренды самокатов другие параметры сравнения или одинаковые, или сложны для сравнения.
Но в реальности цены на аренду самокатов зависят от разных параметров. Например, у Whoosh динамическое ценообразование, которое зависит от спроса и предложения самокатов в конкретной локации.
Поэтому для сравнения цен пользователю нужно открыть несколько приложений. Посмотреть, какой уровень цен сейчас в конкретном месте. А это в целом представляется как очень муторная и сложная работа: подойти к самокату, открыть приложение, отсканировать QR-код на самокате, посмотреть на цену, попробовать другой тариф, например, фиксированную цену за поездку до нужной точки… и так 3 раза (если три разных самоката на месте).
Скорее всего, в интервью была озвучена социально-приемлемая модель поведения. И проводить интервью, чтобы выяснить реальную модель поведения, может оказаться ошибкой.
Для исправления ситуации отлично подходит метод наблюдения: берем пользователя за руку, приводим к парковсе с самокатами и просим показать в реальности, как он будет выбирать. Еще лучше, когда он не знает, что мы за ним наблюдаем в этой ситуации. Но это уже сложнее.
В сухом остатке: не все данные, собранные в ходе интервью, на практике могут оказаться реальными.
#модельповедения@custdevlab #какпотребительсравнивает@custdevlab
1👍8🌭5❤4🔥3🤔2🐳2
178. Не нужно сужать аудиторию при проблемном интервью
Довольно часто в ходе поиска респондентов для проблемного интервью (проблемных вопросов) владельцы продукта намеренно сужают поиск респондентов. Например, в одной из групп, где можно найти респондентов для исследований, появился запрос на респондентов, которые покупали солнцезащитные очки дороже 20 тыс. рублей и это были отечественные бренды (бренды перечислены).
Также сразу указан продукт (идея продукта), которые авторы запроса разрабатывают — маркетплейс handmade солнцезащитных очков.
Что тут нет так:
1. Когда мы проводим проблемную часть интервью, мы должны выявить проблемы и способы решения. Упоминание идеи продукта очень сильно сужает обсуждаемый проблемы. По сути, мы намеренно используем прайминг.
2. Проблемную часть исследования не нужно сужаьб только до отечественных брендов. В чем отличие покупки очков отечественного бренда и любого зарубежного? Возможно, исследователи заранее выявили разницу в моделях поведения при покупке этих “разных” категорий товара. Но зачем тогда проводить исследования в два этапа? Можно объединить проблемную часть интервью при выявлении модели поведения в целом, а также при выявлении модели поведения при покупке именно отечественных очков.
3. Скорее всего, нет разницы между покупателем солнцезащитных очков любого бренда и покупателем солнцезащитных очков отечественного бренда (это, безусловно, гипотеза, ее нужно проверить). Но заведомо сужая аудиторию мы лишаем себя возможности узнать о других проблемах при покупке очков.
В сухом остатке: не нужно сужать аудиторию при проблемной части интервью; старайтесь в этой части интервью охватывать сегменты, для которых разрабатываемое решение может не попадать в набор рассмотрения.
#ошибки@custdevlab #проблемныевопросы@custdevlab
Довольно часто в ходе поиска респондентов для проблемного интервью (проблемных вопросов) владельцы продукта намеренно сужают поиск респондентов. Например, в одной из групп, где можно найти респондентов для исследований, появился запрос на респондентов, которые покупали солнцезащитные очки дороже 20 тыс. рублей и это были отечественные бренды (бренды перечислены).
Также сразу указан продукт (идея продукта), которые авторы запроса разрабатывают — маркетплейс handmade солнцезащитных очков.
Что тут нет так:
1. Когда мы проводим проблемную часть интервью, мы должны выявить проблемы и способы решения. Упоминание идеи продукта очень сильно сужает обсуждаемый проблемы. По сути, мы намеренно используем прайминг.
2. Проблемную часть исследования не нужно сужаьб только до отечественных брендов. В чем отличие покупки очков отечественного бренда и любого зарубежного? Возможно, исследователи заранее выявили разницу в моделях поведения при покупке этих “разных” категорий товара. Но зачем тогда проводить исследования в два этапа? Можно объединить проблемную часть интервью при выявлении модели поведения в целом, а также при выявлении модели поведения при покупке именно отечественных очков.
3. Скорее всего, нет разницы между покупателем солнцезащитных очков любого бренда и покупателем солнцезащитных очков отечественного бренда (это, безусловно, гипотеза, ее нужно проверить). Но заведомо сужая аудиторию мы лишаем себя возможности узнать о других проблемах при покупке очков.
В сухом остатке: не нужно сужать аудиторию при проблемной части интервью; старайтесь в этой части интервью охватывать сегменты, для которых разрабатываемое решение может не попадать в набор рассмотрения.
#ошибки@custdevlab #проблемныевопросы@custdevlab
1🔥7❤3👍2👎1🌭1
179. Осознаваемая и неосознаваемая модели потребления продукта (решения проблемы)
Например, в деревне люди носят воду из колодца ведрами. Они не знают про водопровод, потому что никогда ничего подобного не видели, и ни о чем подобном не слышали. Получается, они не осознают наличие подобного способа решения их проблемы.
Если спросить их про водопровод — скорее всего, он им не нужен. Конечно, часть аудитории возможно захочет попробовать, например, по Роджерсу 2,5% людей являются инноваторами и просто пробуют все новое. Но большая часть аудитории не поддержит идею. Потому что в данном примере водопровод — неосознаваемая модель решения проблемы.
Когда водопровод появляется в соседних деревнях, и жители текущей деревни могут попробовать водопровод в деле, или услышать рассказы об этом продукте от тех, кто его использует, получается, что теперь такое решение проблемы осознано.
Важно, что речь именно об осознанности модели решения проблемы, а не об опыте. Таким образом, элемент обучения потребителя для формирования осознанности в моделях поведения, является одной из ключевых задач продукта.
Выделяя сегмент целевой аудитории также необходимо учитывать степень осознаваемости модели поведения и склонность целевой аудитории к формированию этой осознанности.
В сухом остатке: продвигать (проддавать) продукт потребителям, у которых практически отсутствуте осознанность предлагаемой модели поведения, очень долго и дорого; формирование осознанности модели поведения это многоэтапный процесс, требующий отдельной стратегии продвижения.
#моделиповедения@custdevlab #полезное@custdevlab
Например, в деревне люди носят воду из колодца ведрами. Они не знают про водопровод, потому что никогда ничего подобного не видели, и ни о чем подобном не слышали. Получается, они не осознают наличие подобного способа решения их проблемы.
Если спросить их про водопровод — скорее всего, он им не нужен. Конечно, часть аудитории возможно захочет попробовать, например, по Роджерсу 2,5% людей являются инноваторами и просто пробуют все новое. Но большая часть аудитории не поддержит идею. Потому что в данном примере водопровод — неосознаваемая модель решения проблемы.
Когда водопровод появляется в соседних деревнях, и жители текущей деревни могут попробовать водопровод в деле, или услышать рассказы об этом продукте от тех, кто его использует, получается, что теперь такое решение проблемы осознано.
Важно, что речь именно об осознанности модели решения проблемы, а не об опыте. Таким образом, элемент обучения потребителя для формирования осознанности в моделях поведения, является одной из ключевых задач продукта.
Выделяя сегмент целевой аудитории также необходимо учитывать степень осознаваемости модели поведения и склонность целевой аудитории к формированию этой осознанности.
В сухом остатке: продвигать (проддавать) продукт потребителям, у которых практически отсутствуте осознанность предлагаемой модели поведения, очень долго и дорого; формирование осознанности модели поведения это многоэтапный процесс, требующий отдельной стратегии продвижения.
#моделиповедения@custdevlab #полезное@custdevlab
4👍9❤5👏3🌭2🐳1🤝1
180. Особые категории товаров на маркетплейсах
Модель поведения потребителя на маркетплейсе отличается от обычного иинтернет-магазина. Причин множество: начиная от оплаты (не нужно каждый раз подтверждать платеж, деньги списываются сами), заканчивая стабильным качеством сервиса (сегодня заказал — завтра привезли).
По статистике бОльшая часть трафика на маркетплейсах идет с мобайла, т.е. потребители выбирают и оплачивают товары с мобильных устройств. Но существуют товарные категории, где до 80% покупок осуществляется не через мобайл, а через десктоп.
При первом приближении это категории крупногабаритных товаров: стиральные машинки, холодильники, телевизоры. Если изучить вопрос глубже, оказывается, что это товары, которые используют совместно несколько человек в семье (домохозяйстве), и вовсе не их размер определяет такую особенность поведения. Выбирают такие товары совместно, т.е. стараются учесть потребности всех участников процесса потребления.
Следовательно, выбирать такие товары удобнее на большом экране компьютера, чтобы было лучше видно товары и его характеристики было удобнее сравнивать.
В сухом остатке: анализируя статистику продукта не всегда можно узнать особенности модели поведения; первоначальная гипотеза о размерах товаров может оказаться ошибочной после изучения процесса выбора товара.
#модельповедения@custdevlab #маркетплейсы@custdevlab
Модель поведения потребителя на маркетплейсе отличается от обычного иинтернет-магазина. Причин множество: начиная от оплаты (не нужно каждый раз подтверждать платеж, деньги списываются сами), заканчивая стабильным качеством сервиса (сегодня заказал — завтра привезли).
По статистике бОльшая часть трафика на маркетплейсах идет с мобайла, т.е. потребители выбирают и оплачивают товары с мобильных устройств. Но существуют товарные категории, где до 80% покупок осуществляется не через мобайл, а через десктоп.
При первом приближении это категории крупногабаритных товаров: стиральные машинки, холодильники, телевизоры. Если изучить вопрос глубже, оказывается, что это товары, которые используют совместно несколько человек в семье (домохозяйстве), и вовсе не их размер определяет такую особенность поведения. Выбирают такие товары совместно, т.е. стараются учесть потребности всех участников процесса потребления.
Следовательно, выбирать такие товары удобнее на большом экране компьютера, чтобы было лучше видно товары и его характеристики было удобнее сравнивать.
В сухом остатке: анализируя статистику продукта не всегда можно узнать особенности модели поведения; первоначальная гипотеза о размерах товаров может оказаться ошибочной после изучения процесса выбора товара.
#модельповедения@custdevlab #маркетплейсы@custdevlab
1👍7🔥6🌭3💯3🐳2🏆1
181. Эволюция подходов от custdev к jtbd
Большинство специалистов по custdev со временем прииходят к концепциии jobs-to-be-done. Связано это с тем, что сначала исследователь старается понять, как выявлять у потребителей то, что им на самом деле нужно.
Когда становится понятно, как выявлять, возникает вопрос — а какие закономерности в поведении потребителей существуют. Начинается использование разных фреймворков в целях ответа на вопрос почему потребители ведут себя таким образом. В итоге приходит пониманиие, что сейчас наиболее полная теориия, описывающая поведение потребителей — jobs-to-be-done.
В сухом остатке: чаще всего эволюция исследователя просиходит от custedv к jobs-to-be-done, потому что от вопроса «как изучать» переходим к вопросу «почему ведет себя так».
#jtbd@custdevlab
Большинство специалистов по custdev со временем прииходят к концепциии jobs-to-be-done. Связано это с тем, что сначала исследователь старается понять, как выявлять у потребителей то, что им на самом деле нужно.
Когда становится понятно, как выявлять, возникает вопрос — а какие закономерности в поведении потребителей существуют. Начинается использование разных фреймворков в целях ответа на вопрос почему потребители ведут себя таким образом. В итоге приходит пониманиие, что сейчас наиболее полная теориия, описывающая поведение потребителей — jobs-to-be-done.
В сухом остатке: чаще всего эволюция исследователя просиходит от custedv к jobs-to-be-done, потому что от вопроса «как изучать» переходим к вопросу «почему ведет себя так».
#jtbd@custdevlab
2👍5❤2🔥2🌭2👎1🤮1💩1🐳1🤝1
182. CustDev через продажи — а если я не умею продавать?
CustDev — это не только интервью. Это целый рад методов, которые позволяют быстро понять востребованность продукта и, самое важное, желание платить за продукт.
Логично предположить, что хороший способ проводить customer development — сделать продукт и продать его. Правда, есть множество методов и процедур, которые помогают до начала продаж сделать продукт максимально ценным (valuable), что сильно повысит шансы совершить продажу.
Но сам факт продажи — обмен реального или предполагаемого товара на деньги — самый лучший факт, подтверждающий успешность custdev-процедур.
Однако, основатели стартапов часто сетуют, что не умеет продавать. Поэтому вместо того, чтобы скорее начать тестировать гипотезу продукта, они тратят время и ресурсы на поиск профессионального продавца, который уж точно будет успешно продать.
Продавец не нужен. Профессиональный как раз продаст, не потому, что продукт нужен, а потому что умеет продавать.
Основатель же наоборот, через такую «продажу» сможет выяснить и возражения, и слабые места своей идеи/продукта. Ну а если продажа состоится, значит потребность в продукте точно подтверждена.
В сухом остатке: чтобы проводить custdev через продажи не нужен специалист по продажам; наоборот, он будет влиять на результат custdev-процедуры худшим образом.
#custdevчерезпродажи@custdevlab
CustDev — это не только интервью. Это целый рад методов, которые позволяют быстро понять востребованность продукта и, самое важное, желание платить за продукт.
Логично предположить, что хороший способ проводить customer development — сделать продукт и продать его. Правда, есть множество методов и процедур, которые помогают до начала продаж сделать продукт максимально ценным (valuable), что сильно повысит шансы совершить продажу.
Но сам факт продажи — обмен реального или предполагаемого товара на деньги — самый лучший факт, подтверждающий успешность custdev-процедур.
Однако, основатели стартапов часто сетуют, что не умеет продавать. Поэтому вместо того, чтобы скорее начать тестировать гипотезу продукта, они тратят время и ресурсы на поиск профессионального продавца, который уж точно будет успешно продать.
Продавец не нужен. Профессиональный как раз продаст, не потому, что продукт нужен, а потому что умеет продавать.
Основатель же наоборот, через такую «продажу» сможет выяснить и возражения, и слабые места своей идеи/продукта. Ну а если продажа состоится, значит потребность в продукте точно подтверждена.
В сухом остатке: чтобы проводить custdev через продажи не нужен специалист по продажам; наоборот, он будет влиять на результат custdev-процедуры худшим образом.
#custdevчерезпродажи@custdevlab
5👍3🔥3🌭3🐳1💯1🤝1
183. Пассивный поиск в jtbd (Боб Моэста)
Passive Looking — пассивное изучение доступных на рынке решений, который пользователь может нанять на работу.
Этот этап начинается после первой мысли о продукте — первая мысль получает развитие, но пока человек целенаправленно не инвестирует силы в поиск решения.
Если что-то подвернется, хорошо, но специально человек пока еще ничего не ищет.
Как это можно использовать в custdev или jtbd-исследованиях?
Во время интервью выяснять этот этап подробнее: где, как, когда, в каких обстоятельствах случились контакты с продуктом или решением. Потому что скорее всего именно на этом этапе закладывается фундамент для последующих этапов. Факты, информация, полученные в ходе пассивного поиска, могут значительно ускорить процесс выбора конкретного решения. Или наоборот, замедлить его.
Следующим этапом будет активный поиск, то есть пользователь будет целенаправленно инвестировать ресурсы в поиск информации. Этот процесс осознать и описать куда проще.
В сухом остатке: пассивный поиск важный этап принятия решения о покупке конкретного продукта в теории jtbd (Боб Моэста); именно тут закладывается фундамент для последующего принятия решения, а точнее ускоряется весь процесс решения.
#jtbd@custdevlab #jtbdэтапы@custdevlab
Passive Looking — пассивное изучение доступных на рынке решений, который пользователь может нанять на работу.
Этот этап начинается после первой мысли о продукте — первая мысль получает развитие, но пока человек целенаправленно не инвестирует силы в поиск решения.
Если что-то подвернется, хорошо, но специально человек пока еще ничего не ищет.
Как это можно использовать в custdev или jtbd-исследованиях?
Во время интервью выяснять этот этап подробнее: где, как, когда, в каких обстоятельствах случились контакты с продуктом или решением. Потому что скорее всего именно на этом этапе закладывается фундамент для последующих этапов. Факты, информация, полученные в ходе пассивного поиска, могут значительно ускорить процесс выбора конкретного решения. Или наоборот, замедлить его.
Следующим этапом будет активный поиск, то есть пользователь будет целенаправленно инвестировать ресурсы в поиск информации. Этот процесс осознать и описать куда проще.
В сухом остатке: пассивный поиск важный этап принятия решения о покупке конкретного продукта в теории jtbd (Боб Моэста); именно тут закладывается фундамент для последующего принятия решения, а точнее ускоряется весь процесс решения.
#jtbd@custdevlab #jtbdэтапы@custdevlab
2✍5👍4🌭4🥰1👾1
Задумали и сделали новый канал
👨🏼💻 Паспортичка
Там размещаем реальные стенограммы реальных интервью. Тематики самые разные.
Можно просто читать вместо новостей, а можно использовать как интересный источник знаний о поведении потребителей. Ведь никто не расскажет о своем поведении лучше, чем сам потребитель.
Приятного чтения!
👨🏼💻 Паспортичка
Там размещаем реальные стенограммы реальных интервью. Тематики самые разные.
Можно просто читать вместо новостей, а можно использовать как интересный источник знаний о поведении потребителей. Ведь никто не расскажет о своем поведении лучше, чем сам потребитель.
Приятного чтения!
Telegram
Паспортичка
Интервью с респондентами. Настоящие стенограммы разговоров о том, как люди потребляют продукты.
Основной канал: @custdevlab
Сотрудничество: @pnevostruev
Основной канал: @custdevlab
Сотрудничество: @pnevostruev
7👍9🔥5🌭3✍2🥰2🤩1👾1
184. Идеального custdev не существует
Идеальный объект по ТРИЗ — это когда объект отсутствует, но его функция выполняется. Идеальный custdev — это когда custdev отсутствует, но его функция выполнена.
По сути, самый идеальный custdev — это получить за свой продукт деньги от потребителя. Т.е. для этого нужно сделать продукт, донести его до потребителя, получить деньги за продукт, просчитать unit-экономику, которая, в идеале, должна «сойтись». Вуа-ля! Мы молодцы.
Но на практике, создавать продукт в «лаборатории» без общения с реальными потребителями, без должной упаковки в коммуникациях и без работы с ценностью сулит очень много возможных ошибок. Ошибки как снежный ком: допущенные на первых этапах ошибки могут мультиплицироваться в итоге в колосальную проблему в итсутствии ценности созданного продукта. Поэтому такой подход, пожалуй, самый дорогой и высокорисковый.
Чтобы снизить напокленный риск неудачи, а точнее, риск отсутствия product/market fit, мы и используем иные custdev-процедуры (интервью, опросы, A/B-тесты и др.), и для начала оцениваем product/solution fit.
В сухом остатке: идеальный custdev, это когда мы не проводим custdev, но узнаем о потребностях потребителей; к сожалению, такой подход слишком высокорисковый, поэтому идеального custdev не существует.
#полезное@custdevlab
Идеальный объект по ТРИЗ — это когда объект отсутствует, но его функция выполняется. Идеальный custdev — это когда custdev отсутствует, но его функция выполнена.
По сути, самый идеальный custdev — это получить за свой продукт деньги от потребителя. Т.е. для этого нужно сделать продукт, донести его до потребителя, получить деньги за продукт, просчитать unit-экономику, которая, в идеале, должна «сойтись». Вуа-ля! Мы молодцы.
Но на практике, создавать продукт в «лаборатории» без общения с реальными потребителями, без должной упаковки в коммуникациях и без работы с ценностью сулит очень много возможных ошибок. Ошибки как снежный ком: допущенные на первых этапах ошибки могут мультиплицироваться в итоге в колосальную проблему в итсутствии ценности созданного продукта. Поэтому такой подход, пожалуй, самый дорогой и высокорисковый.
Чтобы снизить напокленный риск неудачи, а точнее, риск отсутствия product/market fit, мы и используем иные custdev-процедуры (интервью, опросы, A/B-тесты и др.), и для начала оцениваем product/solution fit.
В сухом остатке: идеальный custdev, это когда мы не проводим custdev, но узнаем о потребностях потребителей; к сожалению, такой подход слишком высокорисковый, поэтому идеального custdev не существует.
#полезное@custdevlab
3👍6🌭3🔥2🥰1🤩1👾1
185. Что значит «убить работу» в AJTBD
Работа по теории AJTBD по своей сути это задача, которую должен решить пользователь. Работы складываются в сложную систему, которую принято называть графом, потому что одна работа ниже уровнем может быть связана с несколькими работами как выше, так и ниже уровнем.
Одна из продуктовых стратегий — «убить работу».
Как это работает на практике: возьмем косметический продукт патчи под глаза. Работы, которые выполняет пользователь:
1. Выбрать пачти
2. Приобрести патчи
3. Открыть упаковку
4. Правильно наклеить патч на лицо
5. Изучить инструкцию
6. Засечь 15 минут (обычно столько патч нужно держать)
7. Снять патчи
8. Утилизровать упаковку и сами патчи
Многие из перечисленных работ содержат большое количество работ ниже уровнем. Например, 5. Изучить инструкцию включает следующие работы:
5.1. Взять упаковку в руки
5.2. Крутить ее, пока не найдешь инструкцию
5.3. Прочитать, что написано (а если мелко — найти очки, чтобы это сделать)
А работа 6. Засечь 15 минут также включает ряд работ ниже уровнем:
6.1. Взять телефон
6.2. Найти приложение «Секундомер»
6.3. Открыть приложение
6.4. Указать нужный отрезок времени
Получается сложная система, хотя вроде бы мы говорим о простейших патчах под глаза.
«Убить работу» означает, что часть работ из списка наш продукт делает не нужными. Например, наш патч будет менять цвет в процессе высыхания, т.е. когда он полностью отработает свою задачу, цвет сменится (например, на прозрачный). Таким образом всю работу №6 Засечь 15 минут мы «убиваем», ведь пользователю не нужно засекать время — продукт сам подскажет, когда его нужно снимать.
Меньше работ, которые нужно выполнить пользователю — продукт более привлекательный.
В сухом остатке: «убить работу» означает сократить количество работ, которые пользователю необходимо выполнить для достижения своего целевого состояния.
#jtbd@custdevlab #ajtbd@custdevlab
Работа по теории AJTBD по своей сути это задача, которую должен решить пользователь. Работы складываются в сложную систему, которую принято называть графом, потому что одна работа ниже уровнем может быть связана с несколькими работами как выше, так и ниже уровнем.
Одна из продуктовых стратегий — «убить работу».
Как это работает на практике: возьмем косметический продукт патчи под глаза. Работы, которые выполняет пользователь:
1. Выбрать пачти
2. Приобрести патчи
3. Открыть упаковку
4. Правильно наклеить патч на лицо
5. Изучить инструкцию
6. Засечь 15 минут (обычно столько патч нужно держать)
7. Снять патчи
8. Утилизровать упаковку и сами патчи
Многие из перечисленных работ содержат большое количество работ ниже уровнем. Например, 5. Изучить инструкцию включает следующие работы:
5.1. Взять упаковку в руки
5.2. Крутить ее, пока не найдешь инструкцию
5.3. Прочитать, что написано (а если мелко — найти очки, чтобы это сделать)
А работа 6. Засечь 15 минут также включает ряд работ ниже уровнем:
6.1. Взять телефон
6.2. Найти приложение «Секундомер»
6.3. Открыть приложение
6.4. Указать нужный отрезок времени
Получается сложная система, хотя вроде бы мы говорим о простейших патчах под глаза.
«Убить работу» означает, что часть работ из списка наш продукт делает не нужными. Например, наш патч будет менять цвет в процессе высыхания, т.е. когда он полностью отработает свою задачу, цвет сменится (например, на прозрачный). Таким образом всю работу №6 Засечь 15 минут мы «убиваем», ведь пользователю не нужно засекать время — продукт сам подскажет, когда его нужно снимать.
Меньше работ, которые нужно выполнить пользователю — продукт более привлекательный.
В сухом остатке: «убить работу» означает сократить количество работ, которые пользователю необходимо выполнить для достижения своего целевого состояния.
#jtbd@custdevlab #ajtbd@custdevlab
3🔥9🌭3✍2👍2👾2
186. Принятие решения — самая затратная для мозга работа
Принятие решений является одной из самых энергозатратных работ головного мозга. При выборе продукта пользователь вынужден совершать это действие. Поэтому лучшее, что можно сделать продуктологу — облегчить или даже убрать необходимость принимать решения. Это объяснет эффективность стратегии «убийства работы».
Данный эффект описан в работах Роя Баумейстера. В его статьях фигурирует термин «усталость от принятия решений» (англ. decisions fatigue). И несмотря на то, что эксперименты, на основе которых построена теория Баумейстера, периодически критикуют, нельзя отрицать наличие этого феномена.
Чем больше решений нужно принять пользователю при выборе продукта, тем больше он устанет. То же самое касается и использования продукта. Чем больше решений нужно принимать при достижении задачи (работы), тем скорее пользователь переключится на продукт, требующий меньше вложений умстенной работы.
Например, выбрать фильм на вечер. Сама по себе это непростая задача, а если в процессе участвует несколько человек, то и в принципе часто невыполнимая. Поэтому продукт по подбору фильма для просмотра будет востребован, если, конечно, отвечает требованиям пользователя (рекомендует адекватный запросам и интересный фильм).
В сухом остатке: принимать решения — самая затратная для головного мозга работа; чем меньше решений клиенту придется принимать в процессе выбора и/или использования продукта, тем выше будет удовлетворенность от продукта.
#интересное@custdevlab #принятиерешений@custdevlab
Принятие решений является одной из самых энергозатратных работ головного мозга. При выборе продукта пользователь вынужден совершать это действие. Поэтому лучшее, что можно сделать продуктологу — облегчить или даже убрать необходимость принимать решения. Это объяснет эффективность стратегии «убийства работы».
Данный эффект описан в работах Роя Баумейстера. В его статьях фигурирует термин «усталость от принятия решений» (англ. decisions fatigue). И несмотря на то, что эксперименты, на основе которых построена теория Баумейстера, периодически критикуют, нельзя отрицать наличие этого феномена.
Чем больше решений нужно принять пользователю при выборе продукта, тем больше он устанет. То же самое касается и использования продукта. Чем больше решений нужно принимать при достижении задачи (работы), тем скорее пользователь переключится на продукт, требующий меньше вложений умстенной работы.
Например, выбрать фильм на вечер. Сама по себе это непростая задача, а если в процессе участвует несколько человек, то и в принципе часто невыполнимая. Поэтому продукт по подбору фильма для просмотра будет востребован, если, конечно, отвечает требованиям пользователя (рекомендует адекватный запросам и интересный фильм).
В сухом остатке: принимать решения — самая затратная для головного мозга работа; чем меньше решений клиенту придется принимать в процессе выбора и/или использования продукта, тем выше будет удовлетворенность от продукта.
#интересное@custdevlab #принятиерешений@custdevlab
54👍11🔥5🌭3🤔1🤩1👾1