217. Сколько стоит custdev для крупной компании
KFC теряют позиции на рынке США. Речь даже не про фаст-фуд в целом, а именно про рынок фаст-фуда жаренной курицы. Сайт Food Republic опубликовал рейтинг «12 сетей жареной курицы» и KFC занял последнее место, что для компании с 30 тыс. точек и 75 лет истории, мягко говоря, плохой показатель.
KFC решила собрать обратную связь от потребителей. Конечно, они это делают на постоянной основе, как и любая другая компания. Но инструмент, почему-то, не работал как нужно.
Во-первых, потребителей стало меньше, так как компания теряла позции уже не первый год. Соответственно, многие уже не покупают продукт компании, поэтому и оставлять отзыв сымла нет.
Во-вторых, почему люди должны давать подробный и развернутый отзыв, по сути, делая за компанию ее же работу.
Компания стала предлагать бесплатное ведро курицы в обмен на развернутую обратную связь. Если посмотреть на этот инструмент, это классический custdev через сбор отзывов.
Конечно, стоимость ведра курицы для компании ниже, чем сумма денег, которую компания просит у посетителя за это же ведро. Т.е. нельзя считать стоимость исследования по рыночной цене ведерка. Однако и качество собранной информации будет под вопросом: не получится контролировать качество обратной связи, разве что количество (количество символов, например).
На самом деле, судя по информции в СМИ, компания в первую очередь хочет привлечь к себе внимание и вернуть ушедших клиентов, иначе зачем нужно было модифицировать логотип (Полковник на лого больше не улыбается).
Также без контракта с исследовательским агентством или колсантиговой компанией тоже не обойтись, скорее всего бесплатное ведро за отзыв часть большой и дорогой программы.
В сухом остатке: custdev помогает бизнесу любого размера; особенно, когда в продукте фундаментальные и серьтезные проблемы, которые напрямую влияют на объем продаж и, как следствие, долю рынка.
#интересное@custdevlab #сколькостоит@custdevlab
KFC теряют позиции на рынке США. Речь даже не про фаст-фуд в целом, а именно про рынок фаст-фуда жаренной курицы. Сайт Food Republic опубликовал рейтинг «12 сетей жареной курицы» и KFC занял последнее место, что для компании с 30 тыс. точек и 75 лет истории, мягко говоря, плохой показатель.
KFC решила собрать обратную связь от потребителей. Конечно, они это делают на постоянной основе, как и любая другая компания. Но инструмент, почему-то, не работал как нужно.
Во-первых, потребителей стало меньше, так как компания теряла позции уже не первый год. Соответственно, многие уже не покупают продукт компании, поэтому и оставлять отзыв сымла нет.
Во-вторых, почему люди должны давать подробный и развернутый отзыв, по сути, делая за компанию ее же работу.
Компания стала предлагать бесплатное ведро курицы в обмен на развернутую обратную связь. Если посмотреть на этот инструмент, это классический custdev через сбор отзывов.
Конечно, стоимость ведра курицы для компании ниже, чем сумма денег, которую компания просит у посетителя за это же ведро. Т.е. нельзя считать стоимость исследования по рыночной цене ведерка. Однако и качество собранной информации будет под вопросом: не получится контролировать качество обратной связи, разве что количество (количество символов, например).
На самом деле, судя по информции в СМИ, компания в первую очередь хочет привлечь к себе внимание и вернуть ушедших клиентов, иначе зачем нужно было модифицировать логотип (Полковник на лого больше не улыбается).
Также без контракта с исследовательским агентством или колсантиговой компанией тоже не обойтись, скорее всего бесплатное ведро за отзыв часть большой и дорогой программы.
В сухом остатке: custdev помогает бизнесу любого размера; особенно, когда в продукте фундаментальные и серьтезные проблемы, которые напрямую влияют на объем продаж и, как следствие, долю рынка.
#интересное@custdevlab #сколькостоит@custdevlab
15👍11🤔5🌭5🔥1🤩1👾1
218. Квалификация продукта и квалификация продуктолога
Про навыки и квалификацию продуктолога написано много на других каналах, тут мы обычно не трогаем этот вопрос. Но вот два навыка, которые оказываются важными для сложных продуктов: навык исследователя и навык преподавателя.
Для очень сложного продукта (например, сервис Movista) его сложность пропорциональна степени изменения поведения человека. То есть чем больше нужно изменить привычную и осознаваемую модель поведения пользователя, тем более сложным для пользователя продукт является. Тем дольше и дороже будет запуск и развитие нового продукта на рынке.
Продуктолог в данном продукте нужен не только с исследовательскими функциями (это must have для продуктолога), но и с функциями преподавателя.
В первую очередь нужно обучить (научить) пользователей новой, пока неосознаваемой модели поведения, при решения его проблемы.
Опыт продуктолога важен, но чем более нетипичное и сильное изменение привычной пользователю модели поведения, тем важнее навыки преподавателя (обучения и научения).
В сухом остатке: иметь большой опыт работы на одном рынке больше недостаточно, иногда опыт скорее может мешать. Продуктологу нужны навыки исследования и обучения потребителей.
#навыки@custdevlab #модельповедения@custdevlab
Про навыки и квалификацию продуктолога написано много на других каналах, тут мы обычно не трогаем этот вопрос. Но вот два навыка, которые оказываются важными для сложных продуктов: навык исследователя и навык преподавателя.
Для очень сложного продукта (например, сервис Movista) его сложность пропорциональна степени изменения поведения человека. То есть чем больше нужно изменить привычную и осознаваемую модель поведения пользователя, тем более сложным для пользователя продукт является. Тем дольше и дороже будет запуск и развитие нового продукта на рынке.
Продуктолог в данном продукте нужен не только с исследовательскими функциями (это must have для продуктолога), но и с функциями преподавателя.
В первую очередь нужно обучить (научить) пользователей новой, пока неосознаваемой модели поведения, при решения его проблемы.
Опыт продуктолога важен, но чем более нетипичное и сильное изменение привычной пользователю модели поведения, тем важнее навыки преподавателя (обучения и научения).
В сухом остатке: иметь большой опыт работы на одном рынке больше недостаточно, иногда опыт скорее может мешать. Продуктологу нужны навыки исследования и обучения потребителей.
#навыки@custdevlab #модельповедения@custdevlab
16🌭4🔥3🤩3👍2🥰1🤔1👾1
219. Граф конкуренции: способ решения проблемы, альтернативные решения в рамках одного способа
Конкуренты есть всегда, продукта без конкурентов не бывает. Существует классический подход классификации конкурентов: прямые, косвенные и много других. Для стартапа это условности, которые часто только мешают.
Игнорировать тот факт, что конкуренция неоднородная, нельзя: например, согласно jtbd-подходу, для одного и того же продукта в разное время суток, конкуренты могут кардинально отличаться, потому что работа, на которую нанимается продукт, очень разная (пример с молочным коктейлем в McDonalds).
Есть конкуренция на уровне мышления: способ решения проблемы потребителя. Если мне скучно, я могу пойти в кино, а могу посмотреть кино дома, а могу вообще почитать книгу, например. Для того, чтобы продукт с определенным способом решения проблемы попал в набор выбора потребителя, нужно сначала рассказать и научить потребителя этому способу решения, а потом уже рассказывать о самом продукте.
Если альтернативы в рамках одного способа.
Сходить в кинотеатр: разные кинотеатры. Выбираю нужные по определенному алгоритму (ближе, удобнее расписание, парковка и пр.)
Посмотреть кино онлайн: разные онлайн-кинотеатры и контент в них. Критерии выбора будут сильно отличаться от простых кинотеатров, даже продукт по функционалу другой (система рекомендаций, удобство интерфейса и пр.)
Конкуренты на уровне мышления потребителя (способ решения проблемы) при решении проблемы и разные альтернативы в рамках одного способа, представляют собой граф (как в теории AJTBD Вани Замесина).
В сухом остатке: осознаваемые и неосознаваемые модели поведения потребителя это альтернативные верхнеуровневые способы решения одной проблемы; граф конкурентного выбора для потребителя включает как выбор способа решения проблемы, так и выбор конкретного продукта в рамках способа; продукты из разных способов решения проблемы отлично конкурируют при выборе конкретного решения.
#конкуренция@custdevlab #jtbd@custdevlab
Конкуренты есть всегда, продукта без конкурентов не бывает. Существует классический подход классификации конкурентов: прямые, косвенные и много других. Для стартапа это условности, которые часто только мешают.
Игнорировать тот факт, что конкуренция неоднородная, нельзя: например, согласно jtbd-подходу, для одного и того же продукта в разное время суток, конкуренты могут кардинально отличаться, потому что работа, на которую нанимается продукт, очень разная (пример с молочным коктейлем в McDonalds).
Есть конкуренция на уровне мышления: способ решения проблемы потребителя. Если мне скучно, я могу пойти в кино, а могу посмотреть кино дома, а могу вообще почитать книгу, например. Для того, чтобы продукт с определенным способом решения проблемы попал в набор выбора потребителя, нужно сначала рассказать и научить потребителя этому способу решения, а потом уже рассказывать о самом продукте.
Если альтернативы в рамках одного способа.
Сходить в кинотеатр: разные кинотеатры. Выбираю нужные по определенному алгоритму (ближе, удобнее расписание, парковка и пр.)
Посмотреть кино онлайн: разные онлайн-кинотеатры и контент в них. Критерии выбора будут сильно отличаться от простых кинотеатров, даже продукт по функционалу другой (система рекомендаций, удобство интерфейса и пр.)
Конкуренты на уровне мышления потребителя (способ решения проблемы) при решении проблемы и разные альтернативы в рамках одного способа, представляют собой граф (как в теории AJTBD Вани Замесина).
В сухом остатке: осознаваемые и неосознаваемые модели поведения потребителя это альтернативные верхнеуровневые способы решения одной проблемы; граф конкурентного выбора для потребителя включает как выбор способа решения проблемы, так и выбор конкретного продукта в рамках способа; продукты из разных способов решения проблемы отлично конкурируют при выборе конкретного решения.
#конкуренция@custdevlab #jtbd@custdevlab
9👍4🌭4🤔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
13🔥5✍3🌭3👍2🤔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
11👍7🌭3🤔2😁1😱1
222. Последняя часть процесса использования продукта: офбординг
Офбординг такая же важная часть, как и онбординг. Только если онбординг это первое знакомство с продуктом и тем, как им пользоваться, то офбординг — это плавный выход из продукта.
Многие сервисы усложняют процесс офбординга, делают его запутанным, лишь бы пользователю было сложнее прекратить использование. Связывают это с экономическими показателями продукта, забывая о том, что LXM и CJM не зацикливаются на продуктах компании.
Для клиента уйти без осложнений и проблем может быть одним из факторов выбора продукта в текущий момент, даже если он не планирует прекращать использование в ближайшее время.
Например, в онлайн-кинотеатре вышел сериал, который хочется посмотреть. Чтобы это сделать, нужно оформить подписку на месяц с последующей автоматической пролонгацией. Чем проще отказаться от этой пролонгации, тем скорее пользователь выберет покупку сервиса, по сравнению, например, с пиратским сервисом.
Зачем:
1. Сохранение положительного пользавательского опыта. Хорошие окончания отношений не стимулируют написать гневный отзыв, которые другие пользователи прочитаю во время этапа активного поиска информации
2. Репутация бренда. Особенно для экосистемных продуктов
3. Будущие положительные решения в пользу этого же продукта или других продуктов этой компании. Положительный опыт останется в памяти и в следующий раз будет играть в плюс при сравнении вариантов.
В сухом остатке: выход из продукта также важно, как и вход в него; это влияет на пользовательский опыт, правда может понижать экономические показатели продукта.
#jtbd@custdevlab #этапыjtbd@custdevlab
Офбординг такая же важная часть, как и онбординг. Только если онбординг это первое знакомство с продуктом и тем, как им пользоваться, то офбординг — это плавный выход из продукта.
Многие сервисы усложняют процесс офбординга, делают его запутанным, лишь бы пользователю было сложнее прекратить использование. Связывают это с экономическими показателями продукта, забывая о том, что LXM и CJM не зацикливаются на продуктах компании.
Для клиента уйти без осложнений и проблем может быть одним из факторов выбора продукта в текущий момент, даже если он не планирует прекращать использование в ближайшее время.
Например, в онлайн-кинотеатре вышел сериал, который хочется посмотреть. Чтобы это сделать, нужно оформить подписку на месяц с последующей автоматической пролонгацией. Чем проще отказаться от этой пролонгации, тем скорее пользователь выберет покупку сервиса, по сравнению, например, с пиратским сервисом.
Зачем:
1. Сохранение положительного пользавательского опыта. Хорошие окончания отношений не стимулируют написать гневный отзыв, которые другие пользователи прочитаю во время этапа активного поиска информации
2. Репутация бренда. Особенно для экосистемных продуктов
3. Будущие положительные решения в пользу этого же продукта или других продуктов этой компании. Положительный опыт останется в памяти и в следующий раз будет играть в плюс при сравнении вариантов.
В сухом остатке: выход из продукта также важно, как и вход в него; это влияет на пользовательский опыт, правда может понижать экономические показатели продукта.
#jtbd@custdevlab #этапыjtbd@custdevlab
10👍6🔥3🌭3🤔2👾1
223. Процесс использования продукта (между онбордингом и оффбордингом)
Ongoing Use — продолжительное использование продукта. Если продукт прошел первоначальный онбординг, пользователь начинает обращаться к нему, т.е. нанимать его на работу, каждый раз, когда у него возникает соответствующая необходимость.
Работа, для которой продукт был куплен, должна выполняться на постоянной основе, и желаемый прогресс (путь от точки «А» к точке «Б») должен достигаться.
На этом этапе фокус продуктолога может быть на том, чтобы продукт приносил ценность со временем, помогая клиенту преодолевать барьеры и поддерживать лояльность. В процессе использования каждое касание с продуктом может влиять на улучшение его восприятия и осознание его ценности, а может наоборот — работать отрицательно.
Если начинаются проблемы с продуктом, это повод переключиться на другие продукты для выполнения той же работы. Пользователь начнет смотреть на другие решения в товарной категории или на другие способы выполнения работы.
Если пользователю предлагают новый продукт для выполнения такой же работы, важно, чтобы метрики продукта, ценность от перехода на новый продукт была выше, чем барьеры переключения.
В сухом остатке: ingoing use этап, ради которого продукт создается.
#jtbd@custdevlab #этапыjtbd@custdevlab
Ongoing Use — продолжительное использование продукта. Если продукт прошел первоначальный онбординг, пользователь начинает обращаться к нему, т.е. нанимать его на работу, каждый раз, когда у него возникает соответствующая необходимость.
Работа, для которой продукт был куплен, должна выполняться на постоянной основе, и желаемый прогресс (путь от точки «А» к точке «Б») должен достигаться.
На этом этапе фокус продуктолога может быть на том, чтобы продукт приносил ценность со временем, помогая клиенту преодолевать барьеры и поддерживать лояльность. В процессе использования каждое касание с продуктом может влиять на улучшение его восприятия и осознание его ценности, а может наоборот — работать отрицательно.
Если начинаются проблемы с продуктом, это повод переключиться на другие продукты для выполнения той же работы. Пользователь начнет смотреть на другие решения в товарной категории или на другие способы выполнения работы.
Если пользователю предлагают новый продукт для выполнения такой же работы, важно, чтобы метрики продукта, ценность от перехода на новый продукт была выше, чем барьеры переключения.
В сухом остатке: ingoing use этап, ради которого продукт создается.
#jtbd@custdevlab #этапыjtbd@custdevlab
35👍5🌭3🔥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
24👍10🔥7🌭3🤔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
12👍4✍3🤔2🌭1
226. Управление ожиданием: правило последнего впечатления (peak-end rule)
Правило последнего впечатления было изучено Даниелем Канеманом и коллегами в 1990-ых. Проведя несколько экспериментов исследователи сформулировали ряд правил, назвав их "peak-end rule". На основе этих правил может быть построено управление ожиданиями для продукта.
Суть эксперимента пересказывать не будем, но вывод следующий: среди вереницы последовательных событий, которые включает определенный опыт пользователя, запоминается не усредненное значение пережитых эмоций, а пиковое и последнее.
Например, опыт использования продукта. Он состоит из множества «работ» и может быть визуализирован в CJM или LXM. В обеих моделях принято спрашивать про эмоции, потому что пользователь будет судить обо всем опыте использования продукта по пиковому значению опыта (как положительному, так и отрицательному), и по итоговому опыту на этом пути.
Это еще раз подтверждает важность офбординга, так как скорее всего он запомнится в качестве итогового опыта взаимодействия с продуктом.
Как это можно использовать в продуктовом управлении. Если мы по результатам анализа понимаем, что у нас есть пиковый негативный опыт, следует добавить что-то в продукт, чтобы после пикового негативного опыта был опыт с бОльшим позитивным эффектом, пусть и не таким сильным. Подобный подход «сгладит» общее впечатление о продукте. А, возможно, и позволит избежать сильно негативного отзыва.
Правило универсальное. Работает в кино, медицине, отношениях: если последнее событие было очень сильным и негативным, оно исказит общие воспоминания о всем процессе.
В сухом остатке: правило "peak-end rule" нужно использовать для управления ожиданиями и управления пользовательским опытом.
#управлениеожиданиями@custdevlab
Правило последнего впечатления было изучено Даниелем Канеманом и коллегами в 1990-ых. Проведя несколько экспериментов исследователи сформулировали ряд правил, назвав их "peak-end rule". На основе этих правил может быть построено управление ожиданиями для продукта.
Суть эксперимента пересказывать не будем, но вывод следующий: среди вереницы последовательных событий, которые включает определенный опыт пользователя, запоминается не усредненное значение пережитых эмоций, а пиковое и последнее.
Например, опыт использования продукта. Он состоит из множества «работ» и может быть визуализирован в CJM или LXM. В обеих моделях принято спрашивать про эмоции, потому что пользователь будет судить обо всем опыте использования продукта по пиковому значению опыта (как положительному, так и отрицательному), и по итоговому опыту на этом пути.
Это еще раз подтверждает важность офбординга, так как скорее всего он запомнится в качестве итогового опыта взаимодействия с продуктом.
Как это можно использовать в продуктовом управлении. Если мы по результатам анализа понимаем, что у нас есть пиковый негативный опыт, следует добавить что-то в продукт, чтобы после пикового негативного опыта был опыт с бОльшим позитивным эффектом, пусть и не таким сильным. Подобный подход «сгладит» общее впечатление о продукте. А, возможно, и позволит избежать сильно негативного отзыва.
Правило универсальное. Работает в кино, медицине, отношениях: если последнее событие было очень сильным и негативным, оно исказит общие воспоминания о всем процессе.
В сухом остатке: правило "peak-end rule" нужно использовать для управления ожиданиями и управления пользовательским опытом.
#управлениеожиданиями@custdevlab
11👍7🔥4🌭3✍2🤔1
227. Информирование не равно обучению
Функция обучения для продукта очень важна. Если пользователь не умеет его использовать, то продукт вряд ли будет успешным.
Роль онбординга в этом процессе возрастает многократно. Второй попытки произвести первое впечатление может и не случиться.
Но просто рассказать о функциях продукта — это еще не научить. Нельзя заменять обучение информированием.
Также важно понимать, что научить пользователя невозможно. Он может только научиться сам. Важно создать для него условия для этого обучения/научения.
Допустим, в продукте есть кнопка, которая позволяет отфильтровать товары в каталоге. Просто рассказать об этом, означает просто проинформировать. Дать человеку возможность нажать на эту кнопку и увидеть результат уже лучше, но еще не обучение.
Дать задание отфильтровать товары определенным образом, дать возможность пользователю это задание выполнить, проверить его и вознаградить за правильно выполненное задание — это уже ближе к обучению.
Ошибки это тоже неотъемлемая часть обучения. Если пользователь что-то сделал неправильно, нужно ему об этом рассказать, объяснить и показать правильный путь решения.
Зачем так сложно? Иногда это действительно слишком. Но, как говорил Суворов: «Тяжело в учении, легко в бою!»
К тому же, приведенный пример фильтрации товаров в каталоге, скорее всего, будет похож на какие-то аналоги, то есть модель поведения достаточно осознаваемая. Например, на фильтрацию на маркетплейсах. То есть так «заморачиваться» с обучением не нужно, если процесс в целом пользователю знаком.
Подобный подход скорее нужен для продуктов, функции которых меняют привычное поведение. Как Фудфокс на рынке доставки еды или Мовиста на рынке мультимодальных перевозок.
В сухом остатке: обучение не равно информирование; мало просто рассказать, нужно сформировать петлю научения, иначе результата не будет
#обучение@custdevlab
Функция обучения для продукта очень важна. Если пользователь не умеет его использовать, то продукт вряд ли будет успешным.
Роль онбординга в этом процессе возрастает многократно. Второй попытки произвести первое впечатление может и не случиться.
Но просто рассказать о функциях продукта — это еще не научить. Нельзя заменять обучение информированием.
Также важно понимать, что научить пользователя невозможно. Он может только научиться сам. Важно создать для него условия для этого обучения/научения.
Допустим, в продукте есть кнопка, которая позволяет отфильтровать товары в каталоге. Просто рассказать об этом, означает просто проинформировать. Дать человеку возможность нажать на эту кнопку и увидеть результат уже лучше, но еще не обучение.
Дать задание отфильтровать товары определенным образом, дать возможность пользователю это задание выполнить, проверить его и вознаградить за правильно выполненное задание — это уже ближе к обучению.
Ошибки это тоже неотъемлемая часть обучения. Если пользователь что-то сделал неправильно, нужно ему об этом рассказать, объяснить и показать правильный путь решения.
Зачем так сложно? Иногда это действительно слишком. Но, как говорил Суворов: «Тяжело в учении, легко в бою!»
К тому же, приведенный пример фильтрации товаров в каталоге, скорее всего, будет похож на какие-то аналоги, то есть модель поведения достаточно осознаваемая. Например, на фильтрацию на маркетплейсах. То есть так «заморачиваться» с обучением не нужно, если процесс в целом пользователю знаком.
Подобный подход скорее нужен для продуктов, функции которых меняют привычное поведение. Как Фудфокс на рынке доставки еды или Мовиста на рынке мультимодальных перевозок.
В сухом остатке: обучение не равно информирование; мало просто рассказать, нужно сформировать петлю научения, иначе результата не будет
#обучение@custdevlab
13👍4✍3🌭3👾2
228. Синдром «создателя чат-бота» (chat-bot creation syndrome)
Синдром создателя чат-ботов это псевдо-навык, дающий ощущение тестирования продукта через создание чат-бота.
Надо протестировать потребительскую гипотезу? Делаем чат-бот.
По сравнению с мобильным приложением, например, это гораздо быстрее, дешевле и проще. С учетом современного развития ИИ, даже не особо понимая программирование можно сделать чат-бот (да-да, можно, проверено).
Но вот в чем проблема, продукт, сделанный через чат-бот, тестирует гипотезу поведения потребителя в чат-боте в том мессенджере, где он располагается. То есть он не проверяет гипотезу в целом, он именно проверяет возможность решения ее через чат-бот. Ни больше, ни меньше.
В CDDC чат-боты позволяют тестировать ранние (левые) части гипотезы. Но не гипотезу в целом.
Пилить чат-боты еще не значит стать серийным предпринимателем. Пилить чат-боты это значит пилить чат-боты. А синдром создателя чат-ботов для предпринимателя скорее минус, чем плюс.
В сухом остатке: создавать чат-боты это не полноценный custdev; это часто вовсе не Custdev.
#интересное@custdevlab
Синдром создателя чат-ботов это псевдо-навык, дающий ощущение тестирования продукта через создание чат-бота.
Надо протестировать потребительскую гипотезу? Делаем чат-бот.
По сравнению с мобильным приложением, например, это гораздо быстрее, дешевле и проще. С учетом современного развития ИИ, даже не особо понимая программирование можно сделать чат-бот (да-да, можно, проверено).
Но вот в чем проблема, продукт, сделанный через чат-бот, тестирует гипотезу поведения потребителя в чат-боте в том мессенджере, где он располагается. То есть он не проверяет гипотезу в целом, он именно проверяет возможность решения ее через чат-бот. Ни больше, ни меньше.
В CDDC чат-боты позволяют тестировать ранние (левые) части гипотезы. Но не гипотезу в целом.
Пилить чат-боты еще не значит стать серийным предпринимателем. Пилить чат-боты это значит пилить чат-боты. А синдром создателя чат-ботов для предпринимателя скорее минус, чем плюс.
В сухом остатке: создавать чат-боты это не полноценный custdev; это часто вовсе не Custdev.
#интересное@custdevlab
11👍8✍2🌭2👾1
229. Custdev это не про методику, это про mindset
Custdev по своей сути это не столько набор методов и методик, сколько способ мыслить, т.е. подход к решению задачи.
Можно изучить customer interview досканально, но без сформированного образа мышления сам по себе инструмент мало эффективен. Можно понимать другие custdev-процедуры, но если нет понимания о целях применения, пользы для продукта будет мало.
То же самое можно сказать про JTBD и AJTBD. Это больше про мышление, чем про инструменты.
В сухом остатке: важнее сформировать mindset (образ мышления), чем научиться применять инструменты.
#полезное@custdevlab
Custdev по своей сути это не столько набор методов и методик, сколько способ мыслить, т.е. подход к решению задачи.
Можно изучить customer interview досканально, но без сформированного образа мышления сам по себе инструмент мало эффективен. Можно понимать другие custdev-процедуры, но если нет понимания о целях применения, пользы для продукта будет мало.
То же самое можно сказать про JTBD и AJTBD. Это больше про мышление, чем про инструменты.
В сухом остатке: важнее сформировать mindset (образ мышления), чем научиться применять инструменты.
#полезное@custdevlab
10👍3🌭3✍2👾1
LXM-model.pdf
51.8 KB
230. LXM-based customer interview
Этапы принятия решения о покупке в соотстветствии с JTBD-подходом мы недавно описывали. Если узнать у потребителя про каждый этап подробно, получится отличная база для построения LXM.
Остается только составить список вопросов для каждого этапа. А также понимать, что между этапами происходит триггерное событие, о котором также нужно узнать во время интервью.
Поэтому мы подготовили еще один канвас, который позволяет максимально подробно построить LXM. В модели указаны основные вопросы, а также уточняющите. Присутствуют теги, опираясь на которые можно понять, раскрыт этап полностью, или что-то еще нужно уточнить. Даны примеры уточняющих вопросов.
Правда, про правило «Пяти почему» забывать не стоит.
В сухом остатке: интервью, основанное на модели LXM позволит максимально подробно описать процесс принятия решения о покупке в товарной категории.
#lxm@custdevlab #customerinterview@custdevlab
Этапы принятия решения о покупке в соотстветствии с JTBD-подходом мы недавно описывали. Если узнать у потребителя про каждый этап подробно, получится отличная база для построения LXM.
Остается только составить список вопросов для каждого этапа. А также понимать, что между этапами происходит триггерное событие, о котором также нужно узнать во время интервью.
Поэтому мы подготовили еще один канвас, который позволяет максимально подробно построить LXM. В модели указаны основные вопросы, а также уточняющите. Присутствуют теги, опираясь на которые можно понять, раскрыт этап полностью, или что-то еще нужно уточнить. Даны примеры уточняющих вопросов.
Правда, про правило «Пяти почему» забывать не стоит.
В сухом остатке: интервью, основанное на модели LXM позволит максимально подробно описать процесс принятия решения о покупке в товарной категории.
#lxm@custdevlab #customerinterview@custdevlab
10👍6✍3🌭3🔥2👾1
Напоминаем, что мы уже давно задумали и сделали новый канал
👨🏼💻 Паспортичка
Там размещаем реальные стенограммы реальных интервью. Тематики самые разные.
Можно просто читать вместо новостей, а можно использовать как интересный источник знаний о поведении потребителей. Ведь никто не расскажет о своем поведении лучше, чем сам потребитель.
Приятного чтения!
👨🏼💻 Паспортичка
Там размещаем реальные стенограммы реальных интервью. Тематики самые разные.
Можно просто читать вместо новостей, а можно использовать как интересный источник знаний о поведении потребителей. Ведь никто не расскажет о своем поведении лучше, чем сам потребитель.
Приятного чтения!
Telegram
Паспортичка
Интервью №15
Про подбор участников в команду для решения заданий во время обучения в вузе
https://telegra.ph/Intervyu-15-09-06
#образование@pasportichka #команднаяработа@pasportichka #межгрупповоевзаимодействие@pasportichka
Про подбор участников в команду для решения заданий во время обучения в вузе
https://telegra.ph/Intervyu-15-09-06
#образование@pasportichka #команднаяработа@pasportichka #межгрупповоевзаимодействие@pasportichka
11👍7✍4🌭3
231. Почему на рынке выигрывают продукты, которые выполняют больше работ
В конкурентной борьбе на рынке чаще выигрывают продукты, которые могут выполнять больше работ, чем их конкуренты. Говоря иначе, продукты, которые являются более универсальными решениями, по сравнению с узко специализированными.
Например, в нулевые были популярны навигаторы — целая товарная категория, которая в итоге была вытеснена смартфонами. Навигатор — это специальное устройство со своими характеристиками (размер экрана, способ загрузки карт, способ крепления и пр.), которая была наряду с видеорегистратором желанным девайсом любого водителя. Мобильный интернет тогда был редкостью, а пробки не учитывались вовсе, или учитывались, но не в режиме реального времени, а как динамическая модель, основанная на статистических данных.
Шли годы, смартфоны стали доступнее и функциональнее. И навигаторы превратились из отдельного устройства в приложение на смартфоне.
Смартфон «убил» товарную категорию «навигаторов». То же самое смартфон сделал и с MP3-плеерами. И фотоаппаратами. И много с чем еще. Потому что смартфон может выполнять много разных работ: от позвонить, записать заметку, сделать фотографию до послушать музыку, посмотреть кино и так далее.
ChatGPT является более универсальным продуктом, чем поисковик (правда, пока это скорее вопрос времени). Но, например, работу репетиторов по иностранным языкам он, скорее всего, тоже убъет. Как уже убивает работу Фотошопа и других фото- и видео-редакторов.
Суть в том, что чем больше работ можно выполнить одним продуктом, тем он более конкурентоспособен.
В дополнение вопрос обучения, т.е. если нужно переучиваться или изучать новый продукт для решения отдельной работы, текущий продукт + имеющиеся о нем знания дадут сильное конкурентное преимущество.
В сухом остатке: на рынке выживает продукт, который решает больше работ, чем его конкуренты; еще лучше, если переобучение продукту не требуется.
#jtbd@custdevlab #конкуренция@custdevlab
В конкурентной борьбе на рынке чаще выигрывают продукты, которые могут выполнять больше работ, чем их конкуренты. Говоря иначе, продукты, которые являются более универсальными решениями, по сравнению с узко специализированными.
Например, в нулевые были популярны навигаторы — целая товарная категория, которая в итоге была вытеснена смартфонами. Навигатор — это специальное устройство со своими характеристиками (размер экрана, способ загрузки карт, способ крепления и пр.), которая была наряду с видеорегистратором желанным девайсом любого водителя. Мобильный интернет тогда был редкостью, а пробки не учитывались вовсе, или учитывались, но не в режиме реального времени, а как динамическая модель, основанная на статистических данных.
Шли годы, смартфоны стали доступнее и функциональнее. И навигаторы превратились из отдельного устройства в приложение на смартфоне.
Смартфон «убил» товарную категорию «навигаторов». То же самое смартфон сделал и с MP3-плеерами. И фотоаппаратами. И много с чем еще. Потому что смартфон может выполнять много разных работ: от позвонить, записать заметку, сделать фотографию до послушать музыку, посмотреть кино и так далее.
ChatGPT является более универсальным продуктом, чем поисковик (правда, пока это скорее вопрос времени). Но, например, работу репетиторов по иностранным языкам он, скорее всего, тоже убъет. Как уже убивает работу Фотошопа и других фото- и видео-редакторов.
Суть в том, что чем больше работ можно выполнить одним продуктом, тем он более конкурентоспособен.
В дополнение вопрос обучения, т.е. если нужно переучиваться или изучать новый продукт для решения отдельной работы, текущий продукт + имеющиеся о нем знания дадут сильное конкурентное преимущество.
В сухом остатке: на рынке выживает продукт, который решает больше работ, чем его конкуренты; еще лучше, если переобучение продукту не требуется.
#jtbd@custdevlab #конкуренция@custdevlab
13👍5🤔4🌭3✍1🔥1🤩1👾1
232. Опыт исполнителя и новый подход к определению ценности опыта
Считается, что опыт измеряется временем. Обычно в резюме или при рассказе о себе человек говорит: опыт работы 10 лет. Этот подход устарел и не отвечает современным требованиям.
Не так важен срок (время) опыта. Как важен прогресс, который был получен человеком за этот период.
Можно 10 лет работать над продуктом, выполнять совершенно обычные функции, которые не приводят к прогрессу (росту) личностного и профессионального роста.
Можно за год сделать что-то с продуктом, что позволит человеку трансформировать собственный mindset на совершенно другой уровень, недоступный человеку с опытом в 10 лет.
Поэтому оценивать опыт нужно не временем, и даже не количеством проведенных работ, а прогрессом, который получил человек за период этого опыта.
Например, вы ищите агентство для проведения custdev-процедур для вашего продукта. Один претендент рассказывает, что проводит исследования более 15 лет. Второй, что провел уже более 2000 глубинных интервью. А третий говорит, что проводит исследования полгода, но за это время смог переупаковать 5 продуктов и помочь им выйти на новый уровень продаж за счет изменения методики проведения интервью.
В сухом остатке: опыт должен измеряться не временем, а прогрессом профессионального и личностного роста.
#интересное@custdevlab
Считается, что опыт измеряется временем. Обычно в резюме или при рассказе о себе человек говорит: опыт работы 10 лет. Этот подход устарел и не отвечает современным требованиям.
Не так важен срок (время) опыта. Как важен прогресс, который был получен человеком за этот период.
Можно 10 лет работать над продуктом, выполнять совершенно обычные функции, которые не приводят к прогрессу (росту) личностного и профессионального роста.
Можно за год сделать что-то с продуктом, что позволит человеку трансформировать собственный mindset на совершенно другой уровень, недоступный человеку с опытом в 10 лет.
Поэтому оценивать опыт нужно не временем, и даже не количеством проведенных работ, а прогрессом, который получил человек за период этого опыта.
Например, вы ищите агентство для проведения custdev-процедур для вашего продукта. Один претендент рассказывает, что проводит исследования более 15 лет. Второй, что провел уже более 2000 глубинных интервью. А третий говорит, что проводит исследования полгода, но за это время смог переупаковать 5 продуктов и помочь им выйти на новый уровень продаж за счет изменения методики проведения интервью.
В сухом остатке: опыт должен измеряться не временем, а прогрессом профессионального и личностного роста.
#интересное@custdevlab
7👍6✍4🌭4🔥1🤩1👾1
233. Unit в unit-экономике: смещаем фокус для роста. Кейс Стажер.online
Unit-экономика — база для роста стартапа и понимания его бизнеса. Именно этот подход позволяет понять перспективы стартапа.
Если на начальном этапе развити стартапа важно проводить custdev-процедуры для создания полезного MVP (т.е. MVP который позволит получить нужные данные о продукте и пользователях в том числе, для расчета unit-экономики). То после запуска MVP, его корректировок и сбора достаточной информации именно анализ unit-экономики — ключ к взрывному (или хотя бы какому-нибудь) росту продукта.
Unit в unit-экономике — это единица, которая приносит нам деньги. Например, пользователь, который пользуется нашим продуктом и приносит нам деньги. Для ныне несуществующего QIWI юнитом являлись QIWI-терминалы: чем больше терминалов, тем больше будет поток денег. Для отелей unit — это номер (и ночь). Чем больше номеров, тем больше будет поток денег.
Unit — это, что мы хотим масштабировать. Это источник нашего дохода.
Проект Стажер.online — это платформа по размещению кейсовых заданий от работодателей для решения студентами в целях поиска талантливых стажеров. Проект межвузовский, что является преимуществом для работодателя — не нужно общаться с каждым отдельным вузом, чтобы сообщить о стажировках.
Получается аналог традиционной модели отбора стажеров, где: много студентов изъявляют желание пройти стажировку, HR в компании проводит предварительный отбор на основе резюме, проводится большая работа по последующему отбору через решение задания и в итоге стажер получает место в компании.
Стажер.online меняет привычное поведение компаний — на платформе размещается задание, заинтересованные студенты его решают, далее HR (или представитель компании) производит отбор из меньшего числа студентов, решивших кейс. В теории — экономия времени, а главное, ресурсов HR в дополнение к более подробной оценке реальных навыков студентов, ведь мы не оцениваем их по резюме, которое скорее всего пустое, а оцениваем сразу по результатам выполненного задания.
Платформа получает доход от размещения заданий. Тарифы разные, но основным юнитом является компания (ее представитель), который приносит деньги за каждое размещение. Первое изучение ситуации сразу подсказывает — компаний меньше, чем студентов, да и привлекать на платформу студентов гораздо дешевле. Что, если попробовать юнитом сделать студентов?
Что нужно сделать для этого?
Нужно перенести фокус внимания с компании на студента, а именно подробно изучить ценность от решения подобных заданий для него и постараться «докрутить» ценность продукта до уровня, за который студент готов платить. Вот тут как раз нужен custdev. Также важно понять, что привычное поведение студентов меняется в меньшей степени — они умеют решать кейсы и для них это привычно.
Прекращаем работать с компаниями?
Нет. Именно компании являются источником заданий, но размещают их неохотно, так как существует множество барьеров — начиная от банального отсутствия времени на разработку задания, заканчивая тем, что размещенное публично задание может стать достоянием конкурентов. И конечно, просто отсутствием компетенций для этого (не умею и даже не знаю, как это сделать).
Как будет выглядеть новая модель unit-экономики
Мотивируем компании бесплатно размещать задания на платформе, помогаем с заданиями (внедряем AI, например), помогаем с размещением (максимально смещаем акцент на то, чтобы задание было размещено, а все барьеры появились позже -- например, разместил, а регистрация уже в самом конце).
Тут нам поможет CJM или LXM, что ближе. А для студентов ценность еще предстоит сформировать через custdev-процедуры, чтобы узнать за что они действительно готовы платить после решения.
Но главное — если сложно и дорого привлекать компании, нужно сместить фокус на студентов и начать масштабировать продукт за счет них.
В сухом остатке: unit-экономика это подход для понимания источника масштабирвоания продукта; если один unit нам не приносит дохода, ищем другой unit и тестируем гипотезы получения дохода от него.
#кейс@custdevlab #стажеронлайн@custdevlab
Unit-экономика — база для роста стартапа и понимания его бизнеса. Именно этот подход позволяет понять перспективы стартапа.
Если на начальном этапе развити стартапа важно проводить custdev-процедуры для создания полезного MVP (т.е. MVP который позволит получить нужные данные о продукте и пользователях в том числе, для расчета unit-экономики). То после запуска MVP, его корректировок и сбора достаточной информации именно анализ unit-экономики — ключ к взрывному (или хотя бы какому-нибудь) росту продукта.
Unit в unit-экономике — это единица, которая приносит нам деньги. Например, пользователь, который пользуется нашим продуктом и приносит нам деньги. Для ныне несуществующего QIWI юнитом являлись QIWI-терминалы: чем больше терминалов, тем больше будет поток денег. Для отелей unit — это номер (и ночь). Чем больше номеров, тем больше будет поток денег.
Unit — это, что мы хотим масштабировать. Это источник нашего дохода.
Проект Стажер.online — это платформа по размещению кейсовых заданий от работодателей для решения студентами в целях поиска талантливых стажеров. Проект межвузовский, что является преимуществом для работодателя — не нужно общаться с каждым отдельным вузом, чтобы сообщить о стажировках.
Получается аналог традиционной модели отбора стажеров, где: много студентов изъявляют желание пройти стажировку, HR в компании проводит предварительный отбор на основе резюме, проводится большая работа по последующему отбору через решение задания и в итоге стажер получает место в компании.
Стажер.online меняет привычное поведение компаний — на платформе размещается задание, заинтересованные студенты его решают, далее HR (или представитель компании) производит отбор из меньшего числа студентов, решивших кейс. В теории — экономия времени, а главное, ресурсов HR в дополнение к более подробной оценке реальных навыков студентов, ведь мы не оцениваем их по резюме, которое скорее всего пустое, а оцениваем сразу по результатам выполненного задания.
Платформа получает доход от размещения заданий. Тарифы разные, но основным юнитом является компания (ее представитель), который приносит деньги за каждое размещение. Первое изучение ситуации сразу подсказывает — компаний меньше, чем студентов, да и привлекать на платформу студентов гораздо дешевле. Что, если попробовать юнитом сделать студентов?
Что нужно сделать для этого?
Нужно перенести фокус внимания с компании на студента, а именно подробно изучить ценность от решения подобных заданий для него и постараться «докрутить» ценность продукта до уровня, за который студент готов платить. Вот тут как раз нужен custdev. Также важно понять, что привычное поведение студентов меняется в меньшей степени — они умеют решать кейсы и для них это привычно.
Прекращаем работать с компаниями?
Нет. Именно компании являются источником заданий, но размещают их неохотно, так как существует множество барьеров — начиная от банального отсутствия времени на разработку задания, заканчивая тем, что размещенное публично задание может стать достоянием конкурентов. И конечно, просто отсутствием компетенций для этого (не умею и даже не знаю, как это сделать).
Как будет выглядеть новая модель unit-экономики
Мотивируем компании бесплатно размещать задания на платформе, помогаем с заданиями (внедряем AI, например), помогаем с размещением (максимально смещаем акцент на то, чтобы задание было размещено, а все барьеры появились позже -- например, разместил, а регистрация уже в самом конце).
Тут нам поможет CJM или LXM, что ближе. А для студентов ценность еще предстоит сформировать через custdev-процедуры, чтобы узнать за что они действительно готовы платить после решения.
Но главное — если сложно и дорого привлекать компании, нужно сместить фокус на студентов и начать масштабировать продукт за счет них.
В сухом остатке: unit-экономика это подход для понимания источника масштабирвоания продукта; если один unit нам не приносит дохода, ищем другой unit и тестируем гипотезы получения дохода от него.
#кейс@custdevlab #стажеронлайн@custdevlab
11👍6🌭3🔥2🤩1👾1
234. Стоимость привлечения пользователя (CPUser)
CPUser = стоимость привлечения одного пользователя. Формул для расчета много, но самый правильный — сложить все стоимости платного привлечения для каждого пользователя (сложить CPC, cost per click).
Первые тесты каналов продвижения, особенно исчерпаемые (канал в ТГ, блогер и пр.) обычно приносят пользователей не по самой высокой стоимости.
Попытки закрепить успех приводят к росту этой метрики. Далее стартап пробует другие каналы привлечения пользователей, оставляя те, которые обходятся дешевле.
Многие каналы привлечения пользователей, особенно в digital, аукционные. Это значит, что стоимость размещения рекламы не фиксированная, а зависит от конкретных условий конкретного аукциона. Можно выбирать разные стратегии участия в аукционе, но по сути мы выбираем между балансом от «каждый пользователь дороже, больше пользователей» и «каждый пользователь дешевле, меньше пользователей».
Получается, что сначала пользователи обходятся нам недорого, потом дорожают. И будут дорожать каждый день, потому что при росте масштабов мы вынуждены подключать все более дорогие каналы привлечения пользователей, а более дешевые редко получается масштабировать.
В сухом остатке: стоимость привлечения пользователя (CPUser) это метрика, которая в долгосрочной перспективе всегда будет расти в цене.
#метрики@custdevlab #cpuser@custdevlab
CPUser = стоимость привлечения одного пользователя. Формул для расчета много, но самый правильный — сложить все стоимости платного привлечения для каждого пользователя (сложить CPC, cost per click).
Первые тесты каналов продвижения, особенно исчерпаемые (канал в ТГ, блогер и пр.) обычно приносят пользователей не по самой высокой стоимости.
Попытки закрепить успех приводят к росту этой метрики. Далее стартап пробует другие каналы привлечения пользователей, оставляя те, которые обходятся дешевле.
Многие каналы привлечения пользователей, особенно в digital, аукционные. Это значит, что стоимость размещения рекламы не фиксированная, а зависит от конкретных условий конкретного аукциона. Можно выбирать разные стратегии участия в аукционе, но по сути мы выбираем между балансом от «каждый пользователь дороже, больше пользователей» и «каждый пользователь дешевле, меньше пользователей».
Получается, что сначала пользователи обходятся нам недорого, потом дорожают. И будут дорожать каждый день, потому что при росте масштабов мы вынуждены подключать все более дорогие каналы привлечения пользователей, а более дешевые редко получается масштабировать.
В сухом остатке: стоимость привлечения пользователя (CPUser) это метрика, которая в долгосрочной перспективе всегда будет расти в цене.
#метрики@custdevlab #cpuser@custdevlab
15👍4🌭3✍2👾1