219. Граф конкуренции: способ решения проблемы, альтернативные решения в рамках одного способа
Конкуренты есть всегда, продукта без конкурентов не бывает. Существует классический подход классификации конкурентов: прямые, косвенные и много других. Для стартапа это условности, которые часто только мешают.
Игнорировать тот факт, что конкуренция неоднородная, нельзя: например, согласно jtbd-подходу, для одного и того же продукта в разное время суток, конкуренты могут кардинально отличаться, потому что работа, на которую нанимается продукт, очень разная (пример с молочным коктейлем в McDonalds).
Есть конкуренция на уровне мышления: способ решения проблемы потребителя. Если мне скучно, я могу пойти в кино, а могу посмотреть кино дома, а могу вообще почитать книгу, например. Для того, чтобы продукт с определенным способом решения проблемы попал в набор выбора потребителя, нужно сначала рассказать и научить потребителя этому способу решения, а потом уже рассказывать о самом продукте.
Если альтернативы в рамках одного способа.
Сходить в кинотеатр: разные кинотеатры. Выбираю нужные по определенному алгоритму (ближе, удобнее расписание, парковка и пр.)
Посмотреть кино онлайн: разные онлайн-кинотеатры и контент в них. Критерии выбора будут сильно отличаться от простых кинотеатров, даже продукт по функционалу другой (система рекомендаций, удобство интерфейса и пр.)
Конкуренты на уровне мышления потребителя (способ решения проблемы) при решении проблемы и разные альтернативы в рамках одного способа, представляют собой граф (как в теории AJTBD Вани Замесина).
В сухом остатке: осознаваемые и неосознаваемые модели поведения потребителя это альтернативные верхнеуровневые способы решения одной проблемы; граф конкурентного выбора для потребителя включает как выбор способа решения проблемы, так и выбор конкретного продукта в рамках способа; продукты из разных способов решения проблемы отлично конкурируют при выборе конкретного решения.
#конкуренция@custdevlab #jtbd@custdevlab
Конкуренты есть всегда, продукта без конкурентов не бывает. Существует классический подход классификации конкурентов: прямые, косвенные и много других. Для стартапа это условности, которые часто только мешают.
Игнорировать тот факт, что конкуренция неоднородная, нельзя: например, согласно jtbd-подходу, для одного и того же продукта в разное время суток, конкуренты могут кардинально отличаться, потому что работа, на которую нанимается продукт, очень разная (пример с молочным коктейлем в McDonalds).
Есть конкуренция на уровне мышления: способ решения проблемы потребителя. Если мне скучно, я могу пойти в кино, а могу посмотреть кино дома, а могу вообще почитать книгу, например. Для того, чтобы продукт с определенным способом решения проблемы попал в набор выбора потребителя, нужно сначала рассказать и научить потребителя этому способу решения, а потом уже рассказывать о самом продукте.
Если альтернативы в рамках одного способа.
Сходить в кинотеатр: разные кинотеатры. Выбираю нужные по определенному алгоритму (ближе, удобнее расписание, парковка и пр.)
Посмотреть кино онлайн: разные онлайн-кинотеатры и контент в них. Критерии выбора будут сильно отличаться от простых кинотеатров, даже продукт по функционалу другой (система рекомендаций, удобство интерфейса и пр.)
Конкуренты на уровне мышления потребителя (способ решения проблемы) при решении проблемы и разные альтернативы в рамках одного способа, представляют собой граф (как в теории AJTBD Вани Замесина).
В сухом остатке: осознаваемые и неосознаваемые модели поведения потребителя это альтернативные верхнеуровневые способы решения одной проблемы; граф конкурентного выбора для потребителя включает как выбор способа решения проблемы, так и выбор конкретного продукта в рамках способа; продукты из разных способов решения проблемы отлично конкурируют при выборе конкретного решения.
#конкуренция@custdevlab #jtbd@custdevlab
2👍3🌭3🤔2🔥1🤩1🤮1💩1👾1
220. Первая часть процесса использования: онбординг (Боб Моэста)
После покупки начинается процесс использования продукта. Он состоит из минимум трех этапов: онбординг (on-boarding), непосредственное использование (ongoing use) и оффбординг (off-boarding).
Onboarding — первый опыт использования продукта. Пользователь первый раз самостоятельно взаимодействует с продуктом и делает выводы о том, насколько он соответствует ожиданиям. Получает первый пользовательский опыт через процесс научения.
Если первый опыт оказался неудачным, пользователь скорее всего попробует вернуть продукт или просто откажется от него: в таком случае, с высокой вероятностью, он уже больше не вернется к этому продукту. Существует даже специальная метрика на этот случай: TTV (Time-To-Value).
Важно также учитывать процент возвратов в бизнес-модели стартапа (продукта). Для некоторых сервисов это критично для юнит-экономики.
При проведении custdev следует учитывать, что онбординг настолько важный процесс для любого продукта, что по сути это отдельный продукт внутри вашего продукта и требует особых метрик и подходов к изучению.
В сухом остатке: после покупки пользователь тестирует/пробует купленный товар, этот процесс называется онбординг; он настолько важен для будущего успеха продукта, что требует особого подхода к изучению.
#онбординг@custdevlab #jtbd@custdevlab #jtbdэтапы@custdevlab
После покупки начинается процесс использования продукта. Он состоит из минимум трех этапов: онбординг (on-boarding), непосредственное использование (ongoing use) и оффбординг (off-boarding).
Onboarding — первый опыт использования продукта. Пользователь первый раз самостоятельно взаимодействует с продуктом и делает выводы о том, насколько он соответствует ожиданиям. Получает первый пользовательский опыт через процесс научения.
Если первый опыт оказался неудачным, пользователь скорее всего попробует вернуть продукт или просто откажется от него: в таком случае, с высокой вероятностью, он уже больше не вернется к этому продукту. Существует даже специальная метрика на этот случай: TTV (Time-To-Value).
Важно также учитывать процент возвратов в бизнес-модели стартапа (продукта). Для некоторых сервисов это критично для юнит-экономики.
При проведении custdev следует учитывать, что онбординг настолько важный процесс для любого продукта, что по сути это отдельный продукт внутри вашего продукта и требует особых метрик и подходов к изучению.
В сухом остатке: после покупки пользователь тестирует/пробует купленный товар, этот процесс называется онбординг; он настолько важен для будущего успеха продукта, что требует особого подхода к изучению.
#онбординг@custdevlab #jtbd@custdevlab #jtbdэтапы@custdevlab
7🔥5✍3🌭2👍1🤔1🤩1👾1
221. Life experience map
LXM (life experience map) — карта жизненного пути потенциальных клиентов. Она помогает понять, как живёт целевая аудитория продукта, чем увлекаются эти люди, какие у них проблемы и потребности. Это нужно, чтобы улучшить продукт и каждый этап взаимодействия с ним для тех, кто ещё о нём не знает.
По сравнению с CJM подход LXM помогает изучить именно поведение потребителя вне зависимости от использования конкретного продукта.
Так CJM строится с позиции того, что клиент уже выбрал определенный продукт. А LXM учитывает возможность вариативного выбора.
Например, самокат (средство индивидуальной мобильности). У компаний разные приложения, а значит и задачи (работы) с помощью них могут быть решены разные. Но если строить CJM для Яндекса, то она не учитывает как именно клиент делал выбор между разными продуктами. LXM учитывает.
Единого подхода к построению LXM не существует. Процесс ее построения похож на процесс построения CJM: множество исследований по сбору первичных, вторичных данных, а также данных zero-side.
В сухом остатке: LXM нужен для понимания того, как пользователь взаимодействует с разными продуктами, а не с одним (как в CJM).
#lxm@custdevlab #cjm@custdevlab
LXM (life experience map) — карта жизненного пути потенциальных клиентов. Она помогает понять, как живёт целевая аудитория продукта, чем увлекаются эти люди, какие у них проблемы и потребности. Это нужно, чтобы улучшить продукт и каждый этап взаимодействия с ним для тех, кто ещё о нём не знает.
По сравнению с CJM подход LXM помогает изучить именно поведение потребителя вне зависимости от использования конкретного продукта.
Так CJM строится с позиции того, что клиент уже выбрал определенный продукт. А LXM учитывает возможность вариативного выбора.
Например, самокат (средство индивидуальной мобильности). У компаний разные приложения, а значит и задачи (работы) с помощью них могут быть решены разные. Но если строить CJM для Яндекса, то она не учитывает как именно клиент делал выбор между разными продуктами. LXM учитывает.
Единого подхода к построению LXM не существует. Процесс ее построения похож на процесс построения CJM: множество исследований по сбору первичных, вторичных данных, а также данных zero-side.
В сухом остатке: LXM нужен для понимания того, как пользователь взаимодействует с разными продуктами, а не с одним (как в CJM).
#lxm@custdevlab #cjm@custdevlab
5👍5🤔2🌭2😁1😱1
222. Последняя часть процесса использования продукта: офбординг
Офбординг такая же важная часть, как и онбординг. Только если онбординг это первое знакомство с продуктом и тем, как им пользоваться, то офбординг — это плавный выход из продукта.
Многие сервисы усложняют процесс офбординга, делают его запутанным, лишь бы пользователю было сложнее прекратить использование. Связывают это с экономическими показателями продукта, забывая о том, что LXM и CJM не зацикливаются на продуктах компании.
Для клиента уйти без осложнений и проблем может быть одним из факторов выбора продукта в текущий момент, даже если он не планирует прекращать использование в ближайшее время.
Например, в онлайн-кинотеатре вышел сериал, который хочется посмотреть. Чтобы это сделать, нужно оформить подписку на месяц с последующей автоматической пролонгацией. Чем проще отказаться от этой пролонгации, тем скорее пользователь выберет покупку сервиса, по сравнению, например, с пиратским сервисом.
Зачем:
1. Сохранение положительного пользавательского опыта. Хорошие окончания отношений не стимулируют написать гневный отзыв, которые другие пользователи прочитаю во время этапа активного поиска информации
2. Репутация бренда. Особенно для экосистемных продуктов
3. Будущие положительные решения в пользу этого же продукта или других продуктов этой компании. Положительный опыт останется в памяти и в следующий раз будет играть в плюс при сравнении вариантов.
В сухом остатке: выход из продукта также важно, как и вход в него; это влияет на пользовательский опыт, правда может понижать экономические показатели продукта.
#jtbd@custdevlab #этапыjtbd@custdevlab
Офбординг такая же важная часть, как и онбординг. Только если онбординг это первое знакомство с продуктом и тем, как им пользоваться, то офбординг — это плавный выход из продукта.
Многие сервисы усложняют процесс офбординга, делают его запутанным, лишь бы пользователю было сложнее прекратить использование. Связывают это с экономическими показателями продукта, забывая о том, что LXM и CJM не зацикливаются на продуктах компании.
Для клиента уйти без осложнений и проблем может быть одним из факторов выбора продукта в текущий момент, даже если он не планирует прекращать использование в ближайшее время.
Например, в онлайн-кинотеатре вышел сериал, который хочется посмотреть. Чтобы это сделать, нужно оформить подписку на месяц с последующей автоматической пролонгацией. Чем проще отказаться от этой пролонгации, тем скорее пользователь выберет покупку сервиса, по сравнению, например, с пиратским сервисом.
Зачем:
1. Сохранение положительного пользавательского опыта. Хорошие окончания отношений не стимулируют написать гневный отзыв, которые другие пользователи прочитаю во время этапа активного поиска информации
2. Репутация бренда. Особенно для экосистемных продуктов
3. Будущие положительные решения в пользу этого же продукта или других продуктов этой компании. Положительный опыт останется в памяти и в следующий раз будет играть в плюс при сравнении вариантов.
В сухом остатке: выход из продукта также важно, как и вход в него; это влияет на пользовательский опыт, правда может понижать экономические показатели продукта.
#jtbd@custdevlab #этапыjtbd@custdevlab
7👍5🔥3🤔2🌭2👾1
223. Процесс использования продукта (между онбордингом и оффбордингом)
Ongoing Use — продолжительное использование продукта. Если продукт прошел первоначальный онбординг, пользователь начинает обращаться к нему, т.е. нанимать его на работу, каждый раз, когда у него возникает соответствующая необходимость.
Работа, для которой продукт был куплен, должна выполняться на постоянной основе, и желаемый прогресс (путь от точки «А» к точке «Б») должен достигаться.
На этом этапе фокус продуктолога может быть на том, чтобы продукт приносил ценность со временем, помогая клиенту преодолевать барьеры и поддерживать лояльность. В процессе использования каждое касание с продуктом может влиять на улучшение его восприятия и осознание его ценности, а может наоборот — работать отрицательно.
Если начинаются проблемы с продуктом, это повод переключиться на другие продукты для выполнения той же работы. Пользователь начнет смотреть на другие решения в товарной категории или на другие способы выполнения работы.
Если пользователю предлагают новый продукт для выполнения такой же работы, важно, чтобы метрики продукта, ценность от перехода на новый продукт была выше, чем барьеры переключения.
В сухом остатке: ingoing use этап, ради которого продукт создается.
#jtbd@custdevlab #этапыjtbd@custdevlab
Ongoing Use — продолжительное использование продукта. Если продукт прошел первоначальный онбординг, пользователь начинает обращаться к нему, т.е. нанимать его на работу, каждый раз, когда у него возникает соответствующая необходимость.
Работа, для которой продукт был куплен, должна выполняться на постоянной основе, и желаемый прогресс (путь от точки «А» к точке «Б») должен достигаться.
На этом этапе фокус продуктолога может быть на том, чтобы продукт приносил ценность со временем, помогая клиенту преодолевать барьеры и поддерживать лояльность. В процессе использования каждое касание с продуктом может влиять на улучшение его восприятия и осознание его ценности, а может наоборот — работать отрицательно.
Если начинаются проблемы с продуктом, это повод переключиться на другие продукты для выполнения той же работы. Пользователь начнет смотреть на другие решения в товарной категории или на другие способы выполнения работы.
Если пользователю предлагают новый продукт для выполнения такой же работы, важно, чтобы метрики продукта, ценность от перехода на новый продукт была выше, чем барьеры переключения.
В сухом остатке: ingoing use этап, ради которого продукт создается.
#jtbd@custdevlab #этапыjtbd@custdevlab
35👍4🔥2🌭2✍1🤩1👾1
224. Этапы jtbd-методологии: итог
Собрали в один пост все этапы jtbd-методологии:
1. Первая мысль о продукте (First thought)
2. Пассивный поиск (Passive looking)
3. Активный поиск (Active looking)
4. Принятие решения о покупке (Deciding)
5. Онбординг (Onboarding)
6. Использования в процессе (Ongoing Use)
7. Офбординг (Offboarding)
Между этими процессами происходят события перехода. Что-то стимулирует осознанный или неосознанный переход от одного этапа на другой. Задачей custdev-процедур является выявление этого события для более эффективного использования в стратегии продвижения.
В сухом остатке: этапы jtbd и переход между ними помогают понять процесс мышления пользователя.
#jtbd@custdevlab #этапыjtbd@custdevlab
Собрали в один пост все этапы jtbd-методологии:
1. Первая мысль о продукте (First thought)
2. Пассивный поиск (Passive looking)
3. Активный поиск (Active looking)
4. Принятие решения о покупке (Deciding)
5. Онбординг (Onboarding)
6. Использования в процессе (Ongoing Use)
7. Офбординг (Offboarding)
Между этими процессами происходят события перехода. Что-то стимулирует осознанный или неосознанный переход от одного этапа на другой. Задачей custdev-процедур является выявление этого события для более эффективного использования в стратегии продвижения.
В сухом остатке: этапы jtbd и переход между ними помогают понять процесс мышления пользователя.
#jtbd@custdevlab #этапыjtbd@custdevlab
6👍8🔥5🌭2🤔1🤩1👾1
225. MVP не всегда проще самого продукта
MVP — это версия продукта, обладающая минимально ощутимой ценностью для потребителя. Создание MVP является целью этапа Customer Discovery и перехода на этап Customer Validation.
Крайне важно создать MVP таким, чтобы можно было протестировать гипотезу, которая чаще всего является сложносоставной. Для этого мы создали CDDC-канвас.
Считается, что MVP должен быть дешевым, простым и не всегда удобным. На самом деле существует еще одно очень важное требование к MVP: он должен давать возможность собирать метрики, необходимые как для HADI-циклов, так и для CDDC.
Но главное — возможность проверять гипотезы!
Предположим, нам нужно MVP для тестирвоания такрифной сетки. По сути, мы можем сделать лендтинг с описанием тарифов. Но стоит понимать, что сами по себе тарифы — это проверка гипотезы о том, за члю пользователи готовы платить, а за что не готовы.
Нужно ли делать бесплатный период? Или сразу платный, но дешевый?
Сколько дней/недель/месяцев этот период должен быть?
Нужно ли делать часть функций бесплатной, а другую — платной?
Какую часть сделать бесплатной?
Это все гипотезы. И для их тестирования (проверки) нужно... MVP.
Поэтому, по сути, для тестирования этих гипотез можно делать много разных MVP, по сути один или даже несколько. Но можно проверять это через конструктор MVP — тарифы должны быть гибкими, чтобы быстро изменять тарифную сетку, перенастриавать условия и получать метрики для принятия решений.
Получается, что MVP может быть сложнее обычного продукта. Особенно, если главная цель проверки гипотез — скорость, а не стоимость.
В сухом остатке: MVP может быть сложнее самого продукта; главное — скорость, данные и гибкость.
#mvp@custdevlab #гипотезы@custdevlab
P.S. Если есть прототип продукта, но он не позволяет собирать нужные для дальнейшего развития данные, то это не MVP.
MVP — это версия продукта, обладающая минимально ощутимой ценностью для потребителя. Создание MVP является целью этапа Customer Discovery и перехода на этап Customer Validation.
Крайне важно создать MVP таким, чтобы можно было протестировать гипотезу, которая чаще всего является сложносоставной. Для этого мы создали CDDC-канвас.
Считается, что MVP должен быть дешевым, простым и не всегда удобным. На самом деле существует еще одно очень важное требование к MVP: он должен давать возможность собирать метрики, необходимые как для HADI-циклов, так и для CDDC.
Но главное — возможность проверять гипотезы!
Предположим, нам нужно MVP для тестирвоания такрифной сетки. По сути, мы можем сделать лендтинг с описанием тарифов. Но стоит понимать, что сами по себе тарифы — это проверка гипотезы о том, за члю пользователи готовы платить, а за что не готовы.
Нужно ли делать бесплатный период? Или сразу платный, но дешевый?
Сколько дней/недель/месяцев этот период должен быть?
Нужно ли делать часть функций бесплатной, а другую — платной?
Какую часть сделать бесплатной?
Это все гипотезы. И для их тестирования (проверки) нужно... MVP.
Поэтому, по сути, для тестирования этих гипотез можно делать много разных MVP, по сути один или даже несколько. Но можно проверять это через конструктор MVP — тарифы должны быть гибкими, чтобы быстро изменять тарифную сетку, перенастриавать условия и получать метрики для принятия решений.
Получается, что MVP может быть сложнее обычного продукта. Особенно, если главная цель проверки гипотез — скорость, а не стоимость.
В сухом остатке: MVP может быть сложнее самого продукта; главное — скорость, данные и гибкость.
#mvp@custdevlab #гипотезы@custdevlab
6✍3👍2🤔2