179. Осознаваемая и неосознаваемая модели потребления продукта (решения проблемы)
Например, в деревне люди носят воду из колодца ведрами. Они не знают про водопровод, потому что никогда ничего подобного не видели, и ни о чем подобном не слышали. Получается, они не осознают наличие подобного способа решения их проблемы.
Если спросить их про водопровод — скорее всего, он им не нужен. Конечно, часть аудитории возможно захочет попробовать, например, по Роджерсу 2,5% людей являются инноваторами и просто пробуют все новое. Но большая часть аудитории не поддержит идею. Потому что в данном примере водопровод — неосознаваемая модель решения проблемы.
Когда водопровод появляется в соседних деревнях, и жители текущей деревни могут попробовать водопровод в деле, или услышать рассказы об этом продукте от тех, кто его использует, получается, что теперь такое решение проблемы осознано.
Важно, что речь именно об осознанности модели решения проблемы, а не об опыте. Таким образом, элемент обучения потребителя для формирования осознанности в моделях поведения, является одной из ключевых задач продукта.
Выделяя сегмент целевой аудитории также необходимо учитывать степень осознаваемости модели поведения и склонность целевой аудитории к формированию этой осознанности.
В сухом остатке: продвигать (проддавать) продукт потребителям, у которых практически отсутствуте осознанность предлагаемой модели поведения, очень долго и дорого; формирование осознанности модели поведения это многоэтапный процесс, требующий отдельной стратегии продвижения.
#моделиповедения@custdevlab #полезное@custdevlab
Например, в деревне люди носят воду из колодца ведрами. Они не знают про водопровод, потому что никогда ничего подобного не видели, и ни о чем подобном не слышали. Получается, они не осознают наличие подобного способа решения их проблемы.
Если спросить их про водопровод — скорее всего, он им не нужен. Конечно, часть аудитории возможно захочет попробовать, например, по Роджерсу 2,5% людей являются инноваторами и просто пробуют все новое. Но большая часть аудитории не поддержит идею. Потому что в данном примере водопровод — неосознаваемая модель решения проблемы.
Когда водопровод появляется в соседних деревнях, и жители текущей деревни могут попробовать водопровод в деле, или услышать рассказы об этом продукте от тех, кто его использует, получается, что теперь такое решение проблемы осознано.
Важно, что речь именно об осознанности модели решения проблемы, а не об опыте. Таким образом, элемент обучения потребителя для формирования осознанности в моделях поведения, является одной из ключевых задач продукта.
Выделяя сегмент целевой аудитории также необходимо учитывать степень осознаваемости модели поведения и склонность целевой аудитории к формированию этой осознанности.
В сухом остатке: продвигать (проддавать) продукт потребителям, у которых практически отсутствуте осознанность предлагаемой модели поведения, очень долго и дорого; формирование осознанности модели поведения это многоэтапный процесс, требующий отдельной стратегии продвижения.
#моделиповедения@custdevlab #полезное@custdevlab
180. Особые категории товаров на маркетплейсах
Модель поведения потребителя на маркетплейсе отличается от обычного иинтернет-магазина. Причин множество: начиная от оплаты (не нужно каждый раз подтверждать платеж, деньги списываются сами), заканчивая стабильным качеством сервиса (сегодня заказал — завтра привезли).
По статистике бОльшая часть трафика на маркетплейсах идет с мобайла, т.е. потребители выбирают и оплачивают товары с мобильных устройств. Но существуют товарные категории, где до 80% покупок осуществляется не через мобайл, а через десктоп.
При первом приближении это категории крупногабаритных товаров: стиральные машинки, холодильники, телевизоры. Если изучить вопрос глубже, оказывается, что это товары, которые используют совместно несколько человек в семье (домохозяйстве), и вовсе не их размер определяет такую особенность поведения. Выбирают такие товары совместно, т.е. стараются учесть потребности всех участников процесса потребления.
Следовательно, выбирать такие товары удобнее на большом экране компьютера, чтобы было лучше видно товары и его характеристики было удобнее сравнивать.
В сухом остатке: анализируя статистику продукта не всегда можно узнать особенности модели поведения; первоначальная гипотеза о размерах товаров может оказаться ошибочной после изучения процесса выбора товара.
#модельповедения@custdevlab #маркетплейсы@custdevlab
Модель поведения потребителя на маркетплейсе отличается от обычного иинтернет-магазина. Причин множество: начиная от оплаты (не нужно каждый раз подтверждать платеж, деньги списываются сами), заканчивая стабильным качеством сервиса (сегодня заказал — завтра привезли).
По статистике бОльшая часть трафика на маркетплейсах идет с мобайла, т.е. потребители выбирают и оплачивают товары с мобильных устройств. Но существуют товарные категории, где до 80% покупок осуществляется не через мобайл, а через десктоп.
При первом приближении это категории крупногабаритных товаров: стиральные машинки, холодильники, телевизоры. Если изучить вопрос глубже, оказывается, что это товары, которые используют совместно несколько человек в семье (домохозяйстве), и вовсе не их размер определяет такую особенность поведения. Выбирают такие товары совместно, т.е. стараются учесть потребности всех участников процесса потребления.
Следовательно, выбирать такие товары удобнее на большом экране компьютера, чтобы было лучше видно товары и его характеристики было удобнее сравнивать.
В сухом остатке: анализируя статистику продукта не всегда можно узнать особенности модели поведения; первоначальная гипотеза о размерах товаров может оказаться ошибочной после изучения процесса выбора товара.
#модельповедения@custdevlab #маркетплейсы@custdevlab
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
182. CustDev через продажи — а если я не умею продавать?
CustDev — это не только интервью. Это целый рад методов, которые позволяют быстро понять востребованность продукта и, самое важное, желание платить за продукт.
Логично предположить, что хороший способ проводить customer development — сделать продукт и продать его. Правда, есть множество методов и процедур, которые помогают до начала продаж сделать продукт максимально ценным (valuable), что сильно повысит шансы совершить продажу.
Но сам факт продажи — обмен реального или предполагаемого товара на деньги — самый лучший факт, подтверждающий успешность custdev-процедур.
Однако, основатели стартапов часто сетуют, что не умеет продавать. Поэтому вместо того, чтобы скорее начать тестировать гипотезу продукта, они тратят время и ресурсы на поиск профессионального продавца, который уж точно будет успешно продать.
Продавец не нужен. Профессиональный как раз продаст, не потому, что продукт нужен, а потому что умеет продавать.
Основатель же наоборот, через такую «продажу» сможет выяснить и возражения, и слабые места своей идеи/продукта. Ну а если продажа состоится, значит потребность в продукте точно подтверждена.
В сухом остатке: чтобы проводить custdev через продажи не нужен специалист по продажам; наоборот, он будет влиять на результат custdev-процедуры худшим образом.
#custdevчерезпродажи@custdevlab
CustDev — это не только интервью. Это целый рад методов, которые позволяют быстро понять востребованность продукта и, самое важное, желание платить за продукт.
Логично предположить, что хороший способ проводить customer development — сделать продукт и продать его. Правда, есть множество методов и процедур, которые помогают до начала продаж сделать продукт максимально ценным (valuable), что сильно повысит шансы совершить продажу.
Но сам факт продажи — обмен реального или предполагаемого товара на деньги — самый лучший факт, подтверждающий успешность custdev-процедур.
Однако, основатели стартапов часто сетуют, что не умеет продавать. Поэтому вместо того, чтобы скорее начать тестировать гипотезу продукта, они тратят время и ресурсы на поиск профессионального продавца, который уж точно будет успешно продать.
Продавец не нужен. Профессиональный как раз продаст, не потому, что продукт нужен, а потому что умеет продавать.
Основатель же наоборот, через такую «продажу» сможет выяснить и возражения, и слабые места своей идеи/продукта. Ну а если продажа состоится, значит потребность в продукте точно подтверждена.
В сухом остатке: чтобы проводить custdev через продажи не нужен специалист по продажам; наоборот, он будет влиять на результат custdev-процедуры худшим образом.
#custdevчерезпродажи@custdevlab
183. Пассивный поиск в jtbd (Боб Моэста)
Passive Looking — пассивное изучение доступных на рынке решений, который пользователь может нанять на работу.
Этот этап начинается после первой мысли о продукте — первая мысль получает развитие, но пока человек целенаправленно не инвестирует силы в поиск решения.
Если что-то подвернется, хорошо, но специально человек пока еще ничего не ищет.
Как это можно использовать в custdev или jtbd-исследованиях?
Во время интервью выяснять этот этап подробнее: где, как, когда, в каких обстоятельствах случились контакты с продуктом или решением. Потому что скорее всего именно на этом этапе закладывается фундамент для последующих этапов. Факты, информация, полученные в ходе пассивного поиска, могут значительно ускорить процесс выбора конкретного решения. Или наоборот, замедлить его.
Следующим этапом будет активный поиск, то есть пользователь будет целенаправленно инвестировать ресурсы в поиск информации. Этот процесс осознать и описать куда проще.
В сухом остатке: пассивный поиск важный этап принятия решения о покупке конкретного продукта в теории jtbd (Боб Моэста); именно тут закладывается фундамент для последующего принятия решения, а точнее ускоряется весь процесс решения.
#jtbd@custdevlab #jtbdэтапы@custdevlab
Passive Looking — пассивное изучение доступных на рынке решений, который пользователь может нанять на работу.
Этот этап начинается после первой мысли о продукте — первая мысль получает развитие, но пока человек целенаправленно не инвестирует силы в поиск решения.
Если что-то подвернется, хорошо, но специально человек пока еще ничего не ищет.
Как это можно использовать в custdev или jtbd-исследованиях?
Во время интервью выяснять этот этап подробнее: где, как, когда, в каких обстоятельствах случились контакты с продуктом или решением. Потому что скорее всего именно на этом этапе закладывается фундамент для последующих этапов. Факты, информация, полученные в ходе пассивного поиска, могут значительно ускорить процесс выбора конкретного решения. Или наоборот, замедлить его.
Следующим этапом будет активный поиск, то есть пользователь будет целенаправленно инвестировать ресурсы в поиск информации. Этот процесс осознать и описать куда проще.
В сухом остатке: пассивный поиск важный этап принятия решения о покупке конкретного продукта в теории jtbd (Боб Моэста); именно тут закладывается фундамент для последующего принятия решения, а точнее ускоряется весь процесс решения.
#jtbd@custdevlab #jtbdэтапы@custdevlab
Задумали и сделали новый канал
👨🏼💻 Паспортичка
Там размещаем реальные стенограммы реальных интервью. Тематики самые разные.
Можно просто читать вместо новостей, а можно использовать как интересный источник знаний о поведении потребителей. Ведь никто не расскажет о своем поведении лучше, чем сам потребитель.
Приятного чтения!
👨🏼💻 Паспортичка
Там размещаем реальные стенограммы реальных интервью. Тематики самые разные.
Можно просто читать вместо новостей, а можно использовать как интересный источник знаний о поведении потребителей. Ведь никто не расскажет о своем поведении лучше, чем сам потребитель.
Приятного чтения!
Telegram
Паспортичка
Интервью с респондентами. Настоящие стенограммы разговоров о том, как люди потребляют продукты.
Основной канал: @custdevlab
Сотрудничество: @pnevostruev
Основной канал: @custdevlab
Сотрудничество: @pnevostruev
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
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
186. Принятие решения — самая затратная для мозга работа
Принятие решений является одной из самых энергозатратных работ головного мозга. При выборе продукта пользователь вынужден совершать это действие. Поэтому лучшее, что можно сделать продуктологу — облегчить или даже убрать необходимость принимать решения. Это объяснет эффективность стратегии «убийства работы».
Данный эффект описан в работах Роя Баумейстера. В его статьях фигурирует термин «усталость от принятия решений» (англ. decisions fatigue). И несмотря на то, что эксперименты, на основе которых построена теория Баумейстера, периодически критикуют, нельзя отрицать наличие этого феномена.
Чем больше решений нужно принять пользователю при выборе продукта, тем больше он устанет. То же самое касается и использования продукта. Чем больше решений нужно принимать при достижении задачи (работы), тем скорее пользователь переключится на продукт, требующий меньше вложений умстенной работы.
Например, выбрать фильм на вечер. Сама по себе это непростая задача, а если в процессе участвует несколько человек, то и в принципе часто невыполнимая. Поэтому продукт по подбору фильма для просмотра будет востребован, если, конечно, отвечает требованиям пользователя (рекомендует адекватный запросам и интересный фильм).
В сухом остатке: принимать решения — самая затратная для головного мозга работа; чем меньше решений клиенту придется принимать в процессе выбора и/или использования продукта, тем выше будет удовлетворенность от продукта.
#интересное@custdevlab #принятиерешений@custdevlab
Принятие решений является одной из самых энергозатратных работ головного мозга. При выборе продукта пользователь вынужден совершать это действие. Поэтому лучшее, что можно сделать продуктологу — облегчить или даже убрать необходимость принимать решения. Это объяснет эффективность стратегии «убийства работы».
Данный эффект описан в работах Роя Баумейстера. В его статьях фигурирует термин «усталость от принятия решений» (англ. decisions fatigue). И несмотря на то, что эксперименты, на основе которых построена теория Баумейстера, периодически критикуют, нельзя отрицать наличие этого феномена.
Чем больше решений нужно принять пользователю при выборе продукта, тем больше он устанет. То же самое касается и использования продукта. Чем больше решений нужно принимать при достижении задачи (работы), тем скорее пользователь переключится на продукт, требующий меньше вложений умстенной работы.
Например, выбрать фильм на вечер. Сама по себе это непростая задача, а если в процессе участвует несколько человек, то и в принципе часто невыполнимая. Поэтому продукт по подбору фильма для просмотра будет востребован, если, конечно, отвечает требованиям пользователя (рекомендует адекватный запросам и интересный фильм).
В сухом остатке: принимать решения — самая затратная для головного мозга работа; чем меньше решений клиенту придется принимать в процессе выбора и/или использования продукта, тем выше будет удовлетворенность от продукта.
#интересное@custdevlab #принятиерешений@custdevlab
187. Восприятие или реальная метрика: что важнее
Многие метрики продукта двоякие: есть реальная метрика, измеренная на основе объективных методов, а есть восприяние этой метрики потребителем.
Например, среднее время, в течение которого человек ожидает в очереди, и восприятие времени ожидания в очереди человеком.
Управлять нужно как реальной, так и воспринимаемой метрикой. Например, открыть дополнительную кассу, чтобы очередь двигалась быстрее, а также занять клиента во время ожидания в очереди, например, предоставить ему интерактивную игру или информацию для изучения.
Реальная и воспринимаемая метрики могут сильно отличаться. Например, время ожидания не превышает 2-3 минут, а вот воспринимаемое оценвиается как «очень долго (около 10 минут)».
Какая метрика важнее? Обе. Но реальной управлять проще, так как есть объективные инструменты измерения. Воспринимаемой сложнее, так как часто это связано с управлением ожиданием, а ее измерение всегда довольно субъективно и зависит в том числе от внешних факторов.
В цифровых продуктах реальную метрику не всегда можно измерить. Например, сложность при решении задачи в мобильном приложении это всегда воспринимаемая метрика. Для ее измерения применяется CES. Объективной сложности выполнения не бывает.
В сухом остатке: в первую очередь нужно управлять воспринимаемой метрикой, но ее управление может быть связано с реальной метрикой.
#метрики@custdevlab
Многие метрики продукта двоякие: есть реальная метрика, измеренная на основе объективных методов, а есть восприяние этой метрики потребителем.
Например, среднее время, в течение которого человек ожидает в очереди, и восприятие времени ожидания в очереди человеком.
Управлять нужно как реальной, так и воспринимаемой метрикой. Например, открыть дополнительную кассу, чтобы очередь двигалась быстрее, а также занять клиента во время ожидания в очереди, например, предоставить ему интерактивную игру или информацию для изучения.
Реальная и воспринимаемая метрики могут сильно отличаться. Например, время ожидания не превышает 2-3 минут, а вот воспринимаемое оценвиается как «очень долго (около 10 минут)».
Какая метрика важнее? Обе. Но реальной управлять проще, так как есть объективные инструменты измерения. Воспринимаемой сложнее, так как часто это связано с управлением ожиданием, а ее измерение всегда довольно субъективно и зависит в том числе от внешних факторов.
В цифровых продуктах реальную метрику не всегда можно измерить. Например, сложность при решении задачи в мобильном приложении это всегда воспринимаемая метрика. Для ее измерения применяется CES. Объективной сложности выполнения не бывает.
В сухом остатке: в первую очередь нужно управлять воспринимаемой метрикой, но ее управление может быть связано с реальной метрикой.
#метрики@custdevlab
188. Метрика NPS и ее неправильное применение
Знаменитая метрика NPS — это запатентованная формулировка вопроса, разработанная Фредериком Райхельдом, которую он опубликовал в 2003 году.
Вопрос в методике NPS звучит следующим образом: «С какой вероятностью Вы порекомендуете наш продукт близкому другу или родственнику?» Оценивается он по специальной шкале от 0 до 10.
В оригинальном методе есть два важных момента:
1. Рекомендация должна быть не абы кому, а именно близкому другу или родственнику. Так важность сделать правильную рекомендацию сильно выше, чем, например, просто знакомому или коллеге по работе, которого видишь пару раз в неделю.
2. Ответ оценивается по шкале от нуля, а не от единицы. Потому что 0 в данном случае характеризует абсолютное нежелание рекомендовать продукт кому-либо, тогда как 1 это все маловероятная, но возможность.
Вопрос стал настолько популярным и приобрел такое количество разных формулировок, что суть часто просто теряется. Клиента спрашивают о намерении порекомендовать продкут, но не уточняется, а зачем его рекомендовать?
С точки зрения JTBD-подхода и тем более AJTBD-подхода рекомендация может иметь несколько целей, а от этого будет зависеть и вероятность порекомендовать. Например, если речь о контенте, скажем, пользователь посмотрел интересный фильм, порекомендовать его можно хотя бы для того, чтобы было о чем разговаривать за обедом с коллегой. А вот если пользователь использовал какой-то хороший промо-код, получил значительную скидку при покупке, какая цель рекомендовать этот продукт другому?
Если изучать модели поведения глубже, то становится понятно, что в некоторых сферах NPS-вопрос уместен, а в некоторых он скорее вводит в заблуждение. Существуют категории, в которых его спрашивать не этично или недопустимо.
В сухом остатке: NPS нужно применять для тех товаров, где понятна цель рекомендации; есть категории, в которых рекомендации неуместны или не отражают суть вопроса о намерении рекомендовать.
#метрики@custdevlab #nps@custdevlab
P.S. Еще в рамках школьной программы нас учат, что вероятность оцениватеся от 0 до 1. Ну или от 0 до 100%, если в процентах. Почему же NPS мы оцениваем от 0 до 10?
Знаменитая метрика NPS — это запатентованная формулировка вопроса, разработанная Фредериком Райхельдом, которую он опубликовал в 2003 году.
Вопрос в методике NPS звучит следующим образом: «С какой вероятностью Вы порекомендуете наш продукт близкому другу или родственнику?» Оценивается он по специальной шкале от 0 до 10.
В оригинальном методе есть два важных момента:
1. Рекомендация должна быть не абы кому, а именно близкому другу или родственнику. Так важность сделать правильную рекомендацию сильно выше, чем, например, просто знакомому или коллеге по работе, которого видишь пару раз в неделю.
2. Ответ оценивается по шкале от нуля, а не от единицы. Потому что 0 в данном случае характеризует абсолютное нежелание рекомендовать продукт кому-либо, тогда как 1 это все маловероятная, но возможность.
Вопрос стал настолько популярным и приобрел такое количество разных формулировок, что суть часто просто теряется. Клиента спрашивают о намерении порекомендовать продкут, но не уточняется, а зачем его рекомендовать?
С точки зрения JTBD-подхода и тем более AJTBD-подхода рекомендация может иметь несколько целей, а от этого будет зависеть и вероятность порекомендовать. Например, если речь о контенте, скажем, пользователь посмотрел интересный фильм, порекомендовать его можно хотя бы для того, чтобы было о чем разговаривать за обедом с коллегой. А вот если пользователь использовал какой-то хороший промо-код, получил значительную скидку при покупке, какая цель рекомендовать этот продукт другому?
Если изучать модели поведения глубже, то становится понятно, что в некоторых сферах NPS-вопрос уместен, а в некоторых он скорее вводит в заблуждение. Существуют категории, в которых его спрашивать не этично или недопустимо.
В сухом остатке: NPS нужно применять для тех товаров, где понятна цель рекомендации; есть категории, в которых рекомендации неуместны или не отражают суть вопроса о намерении рекомендовать.
#метрики@custdevlab #nps@custdevlab
189. Метрика NPS или CSI — почему они не работают как надо
Как только метрика, основанная на обратной связи, влияет на результат работы сотрудника, это превращается в манипулятивный инструмент.
Например, сотрудник сам просит клиента оценить его работу по шкале NPS, но если клиент на его глазах выставляет метрику ниже 10, сотрудник начнает просить изменить оценку, ведь это влияет на финансовый результат сотрудника.
Если клиент ставит оценку без прямого присуствия сотрудника, но осознает, что эта оценка окажет влияние, то стимул ставить реально ощущаемую оценку становится ниже. Подсознательно это практически невозможно контролировать.
Обратная ситуация с низкой оценкой. Желание «наказать» сотрудника, если он не выполнил требования клиента, может привести к минимальной оценке. По сути, это полностью «убивает» идею подобной метрики для принятия решения о продукте.
Другой пример связан с дополнительными работами, которые возникают, если клиент поставит не 9 или 10 для NPS (аналог 4 или 5 для CSI). Ведь в этом случае компания будет изучать вопрос, выявлять причины низкой оценки. Будут звонки или сообщения с просьбой дать развернутый ответ о приничнах невысокой оценки. И в следующий раз клиент может подумать, что не стоит ставить низкую оценку даже в том случае, если он остался недоволен.
А вот если компания не будет уточнять причины, это также может оказать негативное влияние на восприятие работы компании в целом и на общую оценку. Особенно с учетом обраного мнения относительно правильности выбора продукта.
В этой связи разумным кажется предоставить возможность клиенту выбрать вариант и потребность связаться с ним. Если он недоволен, поставил низкую оценку, то может указать это в анкете обратной связи: Свяжитесь со мной.
В сухом остатке: метрики, основанные на сборе обратной связи, не должны влиять на финансовый результат сотрудника; клиенту нужно давать возможность выбора, хочет ли он, чтобы с ним связались для уточнения деталей по оценке.
#метрики@custdevlab #nps@custdevlab #csi@custdevlab
Как только метрика, основанная на обратной связи, влияет на результат работы сотрудника, это превращается в манипулятивный инструмент.
Например, сотрудник сам просит клиента оценить его работу по шкале NPS, но если клиент на его глазах выставляет метрику ниже 10, сотрудник начнает просить изменить оценку, ведь это влияет на финансовый результат сотрудника.
Если клиент ставит оценку без прямого присуствия сотрудника, но осознает, что эта оценка окажет влияние, то стимул ставить реально ощущаемую оценку становится ниже. Подсознательно это практически невозможно контролировать.
Обратная ситуация с низкой оценкой. Желание «наказать» сотрудника, если он не выполнил требования клиента, может привести к минимальной оценке. По сути, это полностью «убивает» идею подобной метрики для принятия решения о продукте.
Другой пример связан с дополнительными работами, которые возникают, если клиент поставит не 9 или 10 для NPS (аналог 4 или 5 для CSI). Ведь в этом случае компания будет изучать вопрос, выявлять причины низкой оценки. Будут звонки или сообщения с просьбой дать развернутый ответ о приничнах невысокой оценки. И в следующий раз клиент может подумать, что не стоит ставить низкую оценку даже в том случае, если он остался недоволен.
А вот если компания не будет уточнять причины, это также может оказать негативное влияние на восприятие работы компании в целом и на общую оценку. Особенно с учетом обраного мнения относительно правильности выбора продукта.
В этой связи разумным кажется предоставить возможность клиенту выбрать вариант и потребность связаться с ним. Если он недоволен, поставил низкую оценку, то может указать это в анкете обратной связи: Свяжитесь со мной.
В сухом остатке: метрики, основанные на сборе обратной связи, не должны влиять на финансовый результат сотрудника; клиенту нужно давать возможность выбора, хочет ли он, чтобы с ним связались для уточнения деталей по оценке.
#метрики@custdevlab #nps@custdevlab #csi@custdevlab
190. Три главных критерия экспресс-оценки потенциала продукта
Маркетинговый потенциал любого продукта или идеи стартап-проекта можно оценить быстро, используя три критерия:
1. Размер целевого сегмента. Чем больше людей будут пользовать продуктом, тем выше потенциал продукта. Например, можно создавать продукт для сегмента в 10 тыс. человек, а можно -- 1,5 млн. Разница ощутимая.
2. Сложность доступа к сегменту (доступность сегмента). Чем выше сложность, тем дороже будет привлечение клиентов. А именно эта составляющая является важнейшей при построении бизнес-модели.
3. Трансформация существующей модели потребления. Чем значительнее предполагается трансформация привычной модели потребления, тем сложнее будет добиться успеха продукта. Пересадить людей с автомобиля на каршеринг можно, но это долго, а значит очень дорого.
Важно понимать, что без оценки этих критериев невозможно осуществить расчеты для построения бизнес-модели, не получится оценивать другие параметры продукта. Это отправная точка анализа.
В сухом остатке: для оценки маркетингового потенциала используются три критерия: размер целевого сегмента, сложность доступа к сегменту, трансформация модели потребления; без оценки маркетингового потенциала невозможно оценивать перспективу продукта на рынке.
#интересное@custdevlab #оценкапотенциала@custdevlab
Маркетинговый потенциал любого продукта или идеи стартап-проекта можно оценить быстро, используя три критерия:
1. Размер целевого сегмента. Чем больше людей будут пользовать продуктом, тем выше потенциал продукта. Например, можно создавать продукт для сегмента в 10 тыс. человек, а можно -- 1,5 млн. Разница ощутимая.
2. Сложность доступа к сегменту (доступность сегмента). Чем выше сложность, тем дороже будет привлечение клиентов. А именно эта составляющая является важнейшей при построении бизнес-модели.
3. Трансформация существующей модели потребления. Чем значительнее предполагается трансформация привычной модели потребления, тем сложнее будет добиться успеха продукта. Пересадить людей с автомобиля на каршеринг можно, но это долго, а значит очень дорого.
Важно понимать, что без оценки этих критериев невозможно осуществить расчеты для построения бизнес-модели, не получится оценивать другие параметры продукта. Это отправная точка анализа.
В сухом остатке: для оценки маркетингового потенциала используются три критерия: размер целевого сегмента, сложность доступа к сегменту, трансформация модели потребления; без оценки маркетингового потенциала невозможно оценивать перспективу продукта на рынке.
#интересное@custdevlab #оценкапотенциала@custdevlab
191. Человек верит себе меньше, чем окружающим
Человек себе верит меньше, чем окружающим… Собственный опыт потребления важен, но его восприятие может быть таким, что он ощущается как ошибочный. То есть да, я сам попробовал, но могло же быть так, что я ошибся. Или что мое поведение было экстремальным.
Отзывы, советы, рекомендации оказывают сильное влияние на принятие решение о покупке. И модель поведения на этом этапе очень сложная. Например, у пользователей есть понимание, что отзывы накручивают и покупают, но все равно их продолжают читать и опираться на них при выборе продукта из товарной категории.
Так, воспринимаемое повышение ценности продукта может быть создано через очередь. Чем больше людей в очереди, тем ценнее то, что ожидает по ее окончанию. Ведь не будут же люди стоять в очереди просто так?
Другой пример. 10-20 лет назад в пригородных электричках процветала торговля «с рук». И обычно в вагоне поезда или никто не совершал покупку, или совершали сразу несколько — 2-3 раза. Это могло быть связано с социальным доказательством — первый «смельчак» купил, и остальные видят, что это «не страшно», а значит тоже можно купить.
Управление ожиданиями — важная функция сервиса или продукта. Через создание «социального доказательства» можно повышаеть воспринимаемую ценность продукта.
В сухом остатке: социальное доказательство неотъемлемая часть этапа выбора продукта; чем весомее будет особновано, что пордукт пользуется спросом у других, чем выше вероятность его покупки.
#социальноедоказательство@custdevlab #управлениеожиданиями@custdevlab
Человек себе верит меньше, чем окружающим… Собственный опыт потребления важен, но его восприятие может быть таким, что он ощущается как ошибочный. То есть да, я сам попробовал, но могло же быть так, что я ошибся. Или что мое поведение было экстремальным.
Отзывы, советы, рекомендации оказывают сильное влияние на принятие решение о покупке. И модель поведения на этом этапе очень сложная. Например, у пользователей есть понимание, что отзывы накручивают и покупают, но все равно их продолжают читать и опираться на них при выборе продукта из товарной категории.
Так, воспринимаемое повышение ценности продукта может быть создано через очередь. Чем больше людей в очереди, тем ценнее то, что ожидает по ее окончанию. Ведь не будут же люди стоять в очереди просто так?
Другой пример. 10-20 лет назад в пригородных электричках процветала торговля «с рук». И обычно в вагоне поезда или никто не совершал покупку, или совершали сразу несколько — 2-3 раза. Это могло быть связано с социальным доказательством — первый «смельчак» купил, и остальные видят, что это «не страшно», а значит тоже можно купить.
Управление ожиданиями — важная функция сервиса или продукта. Через создание «социального доказательства» можно повышаеть воспринимаемую ценность продукта.
В сухом остатке: социальное доказательство неотъемлемая часть этапа выбора продукта; чем весомее будет особновано, что пордукт пользуется спросом у других, чем выше вероятность его покупки.
#социальноедоказательство@custdevlab #управлениеожиданиями@custdevlab
192. Активный поиск в jtbd (Боб Моэста)
Active Looking — активное изучение доступных решений, которые клиент может нанять для решения своей проблемы («боли»). Потребность в покупке становится более явной, и человек может начать специально искать информацию, например, обзоры на те или иные решения и конкретные продукты.
Важный итог этого шага — человек отметает для себя ряд решений, которые точно ему не подойдут. В итоге, формируется шорт-лист подходящих для него продуктов. Может быть использована иерархия:
— Набор осведомленности. Те решения, о которых человек знает, в первую очередь то, что он узнал во время пассивного поиска
— Набор НЕ рассмотрения. Те решения, которые человеку не подходят
— Набор рассмотрения. Те решения, которые подходят
Эта иерархия двухуровневая: сначала выбирается тип решения (концепция продукта), а затем — сам продукт внутри конкретного решения. Эти уровни могут быть четко разделены, а могут рассматриваться одновременно.
Важно, что на данном этапе происходит «инвестирование» времени и внимания в поиск решения. Это то, что человек будет обязательно учитывать при последующей оценке эффективности выбранного решения (проекта), что может повлиять, например, на TTV-метрику. Обычно между фазами пассивного и активного поиска происходит какое-то событие.
Как это можно использовать в custdev или jtbd-исследованиях?
Во время интервью выяснять этот этап подробнее: где, как, когда, в каких обстоятельствах случились событие, которое привело к переходу от пассивного поиска к активному.
Сам этап активного поиска, то есть когда человек целенаправленно инвестирует ресурсы в поиск информации, осознать и описать проще, чем пассивный поиск.
В сухом остатке: активный поиск важный этап принятия решения о покупке конкретного продукта в теории jtbd (Боб Моэста); именно на этом этапе человек инвестирует время в выбор решения и продукта.
#jtbd@custdevlab #jtbdэтапы@custdevlab
Active Looking — активное изучение доступных решений, которые клиент может нанять для решения своей проблемы («боли»). Потребность в покупке становится более явной, и человек может начать специально искать информацию, например, обзоры на те или иные решения и конкретные продукты.
Важный итог этого шага — человек отметает для себя ряд решений, которые точно ему не подойдут. В итоге, формируется шорт-лист подходящих для него продуктов. Может быть использована иерархия:
— Набор осведомленности. Те решения, о которых человек знает, в первую очередь то, что он узнал во время пассивного поиска
— Набор НЕ рассмотрения. Те решения, которые человеку не подходят
— Набор рассмотрения. Те решения, которые подходят
Эта иерархия двухуровневая: сначала выбирается тип решения (концепция продукта), а затем — сам продукт внутри конкретного решения. Эти уровни могут быть четко разделены, а могут рассматриваться одновременно.
Важно, что на данном этапе происходит «инвестирование» времени и внимания в поиск решения. Это то, что человек будет обязательно учитывать при последующей оценке эффективности выбранного решения (проекта), что может повлиять, например, на TTV-метрику. Обычно между фазами пассивного и активного поиска происходит какое-то событие.
Как это можно использовать в custdev или jtbd-исследованиях?
Во время интервью выяснять этот этап подробнее: где, как, когда, в каких обстоятельствах случились событие, которое привело к переходу от пассивного поиска к активному.
Сам этап активного поиска, то есть когда человек целенаправленно инвестирует ресурсы в поиск информации, осознать и описать проще, чем пассивный поиск.
В сухом остатке: активный поиск важный этап принятия решения о покупке конкретного продукта в теории jtbd (Боб Моэста); именно на этом этапе человек инвестирует время в выбор решения и продукта.
#jtbd@custdevlab #jtbdэтапы@custdevlab
193. Факты, а не домыслы
В ходе Customer Interview мы спрашиваем не о домыслах и намерениях потребителя (это все неправда), а о фактах. Т.е. мы фиксируем то, что реально было (случалось с пользователем), а не то, чего не было.
Также мы спрашиваем о прошлом, а не о будущем. Чем более детализированный опыт каждого отдельного случая решения проблемы клиента мы изучим, тем нам станут понятнее реальные, а не фантомные «боли» клиента.
Нам важнее не обобщенный опыт, который пользвоатель сам обобщил на основе своего субъективного мнения, а конкретные события и конкретный опыт потребителя.
То есть спрашивать про «обычное поведение» менее предпочтительно, чем о конкретных реальных историях поведения в конкрентых реальных ситуациях.
В сухом остатке: факты в customer interview важнее обобщенного опыта; а информацию о домыслах и намерениях лучше избегать полностью.
#customerinterview@custdevlab #какзадаватьвопросы@custdevlab
В ходе Customer Interview мы спрашиваем не о домыслах и намерениях потребителя (это все неправда), а о фактах. Т.е. мы фиксируем то, что реально было (случалось с пользователем), а не то, чего не было.
Также мы спрашиваем о прошлом, а не о будущем. Чем более детализированный опыт каждого отдельного случая решения проблемы клиента мы изучим, тем нам станут понятнее реальные, а не фантомные «боли» клиента.
Нам важнее не обобщенный опыт, который пользвоатель сам обобщил на основе своего субъективного мнения, а конкретные события и конкретный опыт потребителя.
То есть спрашивать про «обычное поведение» менее предпочтительно, чем о конкретных реальных историях поведения в конкрентых реальных ситуациях.
В сухом остатке: факты в customer interview важнее обобщенного опыта; а информацию о домыслах и намерениях лучше избегать полностью.
#customerinterview@custdevlab #какзадаватьвопросы@custdevlab
194. Реальные и фантомные «боли» клиентов
Реальные боли — это то, с чем клиенты на самом деле сталкиваются при решени своих задач.
Фантомные боли — это боли, которые кажутся клиентам существующими, но таковыми могут не являться.
Например, при оплате через мобильное приложение банка на кассе у клиента на разных карточках может быть достаточная сумма, только в раздробленном виде. Нужно оплатить 500 рублей, но 200 на одной карте, а 300 на второй. Реальная боль — это необходимость сначала перевести деньги с одной карты на другую, а если карт больше трех, то можно еще и перепутать, что приведет к веренице переводов. От этого возрастает тревожность, особенно, если за спиной скопилась очередь: контекст задачи нельзя не принимать в рассчет.
Решением могло бы стать просто снимать деньги сразу с двух карт, если клиент дал банку на это разрешение.
Фантомная боль в данном случае, может быть связана с тем, что подобное решение клиентом не осознается. А следовательно, клиент в ходе интервью скажет, что именно процесс перевода денег с одной карты на другую является значимой проблемой, потому что он связывает тревожность с этими действиями. Решением с точки зрения клиента, могло бы стать, например, ранжирование карт и счетов в приложении сильно облегчило бы решение. Но это фантомная боль, которая не решает реальную проблему оплаты.
В сухом остатке: исследователь должен научиться определять реальные и фантомные боли потребителей; преодоление фантомных болей не решает изначальную проблему клиента.
#боли@custdevlab
Реальные боли — это то, с чем клиенты на самом деле сталкиваются при решени своих задач.
Фантомные боли — это боли, которые кажутся клиентам существующими, но таковыми могут не являться.
Например, при оплате через мобильное приложение банка на кассе у клиента на разных карточках может быть достаточная сумма, только в раздробленном виде. Нужно оплатить 500 рублей, но 200 на одной карте, а 300 на второй. Реальная боль — это необходимость сначала перевести деньги с одной карты на другую, а если карт больше трех, то можно еще и перепутать, что приведет к веренице переводов. От этого возрастает тревожность, особенно, если за спиной скопилась очередь: контекст задачи нельзя не принимать в рассчет.
Решением могло бы стать просто снимать деньги сразу с двух карт, если клиент дал банку на это разрешение.
Фантомная боль в данном случае, может быть связана с тем, что подобное решение клиентом не осознается. А следовательно, клиент в ходе интервью скажет, что именно процесс перевода денег с одной карты на другую является значимой проблемой, потому что он связывает тревожность с этими действиями. Решением с точки зрения клиента, могло бы стать, например, ранжирование карт и счетов в приложении сильно облегчило бы решение. Но это фантомная боль, которая не решает реальную проблему оплаты.
В сухом остатке: исследователь должен научиться определять реальные и фантомные боли потребителей; преодоление фантомных болей не решает изначальную проблему клиента.
#боли@custdevlab
195. Чем стартап отличается от «не стартапа»
Не каждый бизнес является стартапом. Следовательно, не каждый бизнес должен развиваться по правилам развития стартап-проекта. Некоторым бизнесам это будет только вредить.
Предположим, нужно приготовить яичницу. Можно взять уже готовый рецепт, которых в открытом доступе несколько десятков. Повторить несколько рецептов. Может получиться не сразу, но в итоге получится яичница.
Яичницу готовили миллиарды раз, тонкостей ее приготовления, конечно, много, но в целом это известный процесс. В конечном итоге можно попросить знакомого повара научить готовить яичницу (поделиться опытом). А если нет знакомого повара — найти его.
А вот если нужно приготовить новое блюдо, например, новый соус, на основе куриных яиц. Никто до вас этот новый соус не готовил. Вы не знаете, как его приготовить, потому что никто не знает. Также не знаете, понравится ли это вам или вашим клиентам. Спросить, как готовить этот соус, не у кого, ведь никто его не готовил. Вы, конечно, слышали, что кто-то где-то когда-то далеко такой соус сделал, но в целом, это для всех неизвестный процесс. И непонятный результат.
Пример с рецептом яичницы — это не стартап. Процессы известны, бери и делай. Например, маркетинговое агентство, студия дизайна, HR-агентство, ларек с шаурмой — это примеры таких проектов. Действовать по принципу развития стартапа не нужно, достаточно посмотреть на успешные практики и повторить, адаптируя под себя и под целевую аудиторию.
Пример с новым соусом — стартап. Новый сервис заказа одежды через AR-технологии, новый способ подбора персонала в компанию, автомат-робот, приготавливающий шаурму на заказ, но без повара — это примеры таких проектов. Тут сложно обойтись без custdev-процедур.
В сухом остатке: не каждый бизнес — это стартап; применение методик развития стартапов для таких проектов может приносить больше вреда, чем пользы.
#интересное@custdevlab #стартап@custdevlab
Не каждый бизнес является стартапом. Следовательно, не каждый бизнес должен развиваться по правилам развития стартап-проекта. Некоторым бизнесам это будет только вредить.
Предположим, нужно приготовить яичницу. Можно взять уже готовый рецепт, которых в открытом доступе несколько десятков. Повторить несколько рецептов. Может получиться не сразу, но в итоге получится яичница.
Яичницу готовили миллиарды раз, тонкостей ее приготовления, конечно, много, но в целом это известный процесс. В конечном итоге можно попросить знакомого повара научить готовить яичницу (поделиться опытом). А если нет знакомого повара — найти его.
А вот если нужно приготовить новое блюдо, например, новый соус, на основе куриных яиц. Никто до вас этот новый соус не готовил. Вы не знаете, как его приготовить, потому что никто не знает. Также не знаете, понравится ли это вам или вашим клиентам. Спросить, как готовить этот соус, не у кого, ведь никто его не готовил. Вы, конечно, слышали, что кто-то где-то когда-то далеко такой соус сделал, но в целом, это для всех неизвестный процесс. И непонятный результат.
Пример с рецептом яичницы — это не стартап. Процессы известны, бери и делай. Например, маркетинговое агентство, студия дизайна, HR-агентство, ларек с шаурмой — это примеры таких проектов. Действовать по принципу развития стартапа не нужно, достаточно посмотреть на успешные практики и повторить, адаптируя под себя и под целевую аудиторию.
Пример с новым соусом — стартап. Новый сервис заказа одежды через AR-технологии, новый способ подбора персонала в компанию, автомат-робот, приготавливающий шаурму на заказ, но без повара — это примеры таких проектов. Тут сложно обойтись без custdev-процедур.
В сухом остатке: не каждый бизнес — это стартап; применение методик развития стартапов для таких проектов может приносить больше вреда, чем пользы.
#интересное@custdevlab #стартап@custdevlab
196. Искажение PAM-TAM-SAM-SOM
В большинстве презентаций на демо-днях размеры рынка показывают через PAM-TAM-SAM, а доля рынка конкретного продукта через SOM.
В последние годы показывать PAM (потенциальный рынок) не принято. Причин несколько, но главная, в этом параметре нет большого смысла, так как потенциал может быть как глобальный, так и региональный. Какой считать — не очень понятно.
TAM-SAM-SOM почти всегда показан через круги (см. изображение). И это плохо.
1. Непонятно, как были посчитаны эти параметры (нет прозрачности).
2. Не соблюдается масштаб, так как круги не пропорциональны расчетным параметрам. При оценке перспектив продукта важно понимать разницу между TAM и SAM, ведь это определяет и стоимость конкуренции, в том числе стоимость привлечения клиента, а также потенциал роста.
Почему это происходит, объяснить просто. В Power Point есть стандартная Smart-фигура с подобными кругами. Создание слайда очень быстрое и простое. К тому же, «так делают все», то есть исторически сложилось представлять параметры рынка таким образом.
Как исправить ситуацию:
1. Показывать круги пропорционально цифрам. Если TAM в 5 раз больше, чем SAM, значит нужно площадь (!), а не радиус, показывать в 5 раз больше.
2. Добавлять расчеты. Расчеты лучше показывать через таблицу, в основе которой лежат ключевые метрики стартапа. Если не помещается на слайде — добавляем QR и ссылку на нее на слайде.
В сухом остатке: не надо делать что-то потому, что «все так делают»; если решили показывать TAM-SAM-SOM через «круги», учитывайте их пропорциональность.
#рынок@custdevlab #метрики@custdevlab
В большинстве презентаций на демо-днях размеры рынка показывают через PAM-TAM-SAM, а доля рынка конкретного продукта через SOM.
В последние годы показывать PAM (потенциальный рынок) не принято. Причин несколько, но главная, в этом параметре нет большого смысла, так как потенциал может быть как глобальный, так и региональный. Какой считать — не очень понятно.
TAM-SAM-SOM почти всегда показан через круги (см. изображение). И это плохо.
1. Непонятно, как были посчитаны эти параметры (нет прозрачности).
2. Не соблюдается масштаб, так как круги не пропорциональны расчетным параметрам. При оценке перспектив продукта важно понимать разницу между TAM и SAM, ведь это определяет и стоимость конкуренции, в том числе стоимость привлечения клиента, а также потенциал роста.
Почему это происходит, объяснить просто. В Power Point есть стандартная Smart-фигура с подобными кругами. Создание слайда очень быстрое и простое. К тому же, «так делают все», то есть исторически сложилось представлять параметры рынка таким образом.
Как исправить ситуацию:
1. Показывать круги пропорционально цифрам. Если TAM в 5 раз больше, чем SAM, значит нужно площадь (!), а не радиус, показывать в 5 раз больше.
2. Добавлять расчеты. Расчеты лучше показывать через таблицу, в основе которой лежат ключевые метрики стартапа. Если не помещается на слайде — добавляем QR и ссылку на нее на слайде.
В сухом остатке: не надо делать что-то потому, что «все так делают»; если решили показывать TAM-SAM-SOM через «круги», учитывайте их пропорциональность.
#рынок@custdevlab #метрики@custdevlab