35. MVP продукта: как узнать, что «отсечь» от куска мрамора
MVP (от англ. minimum viable product) — продукт, обладающий минимальными, но достаточными для удовлетворения первых потребителей функциями. Представьте, что «идеальный» продукт для потребителя — это идеальное утро.
⏰Можно спать столько, сколько хочется, не глядя на будильник.
☕️Выпить чашечку свежесваренного кофе.
🛀Провести в душе столько времени, сколько хочется.
🍳Вкусно позавтракать.
📰Прочитать все те каналы в телеграмме, которые хочется.
👔Примерить несколько разных вариантов одежды, выбрать самый приятный и удобный.
MVP — это утро, когда вы проспали будильник и через 30 минут будет важная встреча.
— Кофе? Не нужен.
— Душ? Примем завтра.
— Разнообразный завтрак? Что получится съесть на бегу, то и будет завтраком.
— Читать каналы в Телеграме? Если успем по пути на работу.
— Одежда? Надеваем то, что успеем, выбор не на основе удобства, а на основе быстроты.
В сухом остатке: MVP — это отсекание всего лишнего от функций продукта, чтобы протестировать главную гипотезу.
#mvp
MVP (от англ. minimum viable product) — продукт, обладающий минимальными, но достаточными для удовлетворения первых потребителей функциями. Представьте, что «идеальный» продукт для потребителя — это идеальное утро.
⏰Можно спать столько, сколько хочется, не глядя на будильник.
☕️Выпить чашечку свежесваренного кофе.
🛀Провести в душе столько времени, сколько хочется.
🍳Вкусно позавтракать.
📰Прочитать все те каналы в телеграмме, которые хочется.
👔Примерить несколько разных вариантов одежды, выбрать самый приятный и удобный.
MVP — это утро, когда вы проспали будильник и через 30 минут будет важная встреча.
— Кофе? Не нужен.
— Душ? Примем завтра.
— Разнообразный завтрак? Что получится съесть на бегу, то и будет завтраком.
— Читать каналы в Телеграме? Если успем по пути на работу.
— Одежда? Надеваем то, что успеем, выбор не на основе удобства, а на основе быстроты.
В сухом остатке: MVP — это отсекание всего лишнего от функций продукта, чтобы протестировать главную гипотезу.
#mvp
👍7❤5🌭2
36. Мобильное приложение OneScore: проверка сложной гипотезы по шагам
Про мобильное приложение, которое позволяет зарабатывать водителю, стоя в пробке, мы писали в самом первом посте.
Напомним, как это работало. Пользователь зарабатывает каждой минуте в пробке, получая условный балл приложения. Баллы можно тратить на предложения партнеров (скидки, купоны). За каждый «погашенный» купон, т.е. за каждого приведенного пользователя, партнер платил нам живые деньги, именно на этом мы и зарабатывали.
Основателей проекта заботила гипотеза о заработке, т.е. сколько денег стоит брать у партнеров за каждого клиента. Стоит ли привязываться к фиксированной стоимости или брать процент от чека. Если процент от чека, как контролировать размер этого чека. Но на самом деле перед проверкой этой гипотезы следует проверить много других, потребительских.
Воронка взаимодействия с приложением для пользователя:
1. Пользователь устанавливает приложение.
2. Пользователь начинает копить баллы.
3. Пользователь продолжает копить баллы.
4. Пользователь тратит накопленные баллы у партнеров.
5. Партнер переводит нам деньги за приведенного пользователя.
Тестирование бизнес-модели нужно начинать с первого, а не с последнего этапа.
Как считать гипотезы протестированными:
1. Стоимость установки приложения (CPI).
2. Конверсия из установившего приложение в первое накопление (в процентах).
3. Конверсия из тех, кто накопил хотя бы один балл, в тех, кто накопил 120 баллов (в процентах). Можно изменить критерий на этом этапе, например, Конверсия в тех, кто накопил баллы за две и более сессии.
4. Конверсия из тех, у кого есть на счету хотя бы 120 баллов (стоимость минимального купона) в тех, кто потратил накопленные баллы хотя бы один раз (в процентах).
5. Конверсия из партнеров, купоны которых были куплены пользователями и погашены, в тех, которые произвели оплату за привлеченного клиента (процент).
Вроде несложно. Но как вы думаете, на каком из этапов были самые плачевные показатели и почему? Ответ пишите в комментариях.
#кейс@custdevlab #гипотезы@custdeavlab #onescore@custdevlab
Про мобильное приложение, которое позволяет зарабатывать водителю, стоя в пробке, мы писали в самом первом посте.
Напомним, как это работало. Пользователь зарабатывает каждой минуте в пробке, получая условный балл приложения. Баллы можно тратить на предложения партнеров (скидки, купоны). За каждый «погашенный» купон, т.е. за каждого приведенного пользователя, партнер платил нам живые деньги, именно на этом мы и зарабатывали.
Основателей проекта заботила гипотеза о заработке, т.е. сколько денег стоит брать у партнеров за каждого клиента. Стоит ли привязываться к фиксированной стоимости или брать процент от чека. Если процент от чека, как контролировать размер этого чека. Но на самом деле перед проверкой этой гипотезы следует проверить много других, потребительских.
Воронка взаимодействия с приложением для пользователя:
1. Пользователь устанавливает приложение.
2. Пользователь начинает копить баллы.
3. Пользователь продолжает копить баллы.
4. Пользователь тратит накопленные баллы у партнеров.
5. Партнер переводит нам деньги за приведенного пользователя.
Тестирование бизнес-модели нужно начинать с первого, а не с последнего этапа.
Как считать гипотезы протестированными:
1. Стоимость установки приложения (CPI).
2. Конверсия из установившего приложение в первое накопление (в процентах).
3. Конверсия из тех, кто накопил хотя бы один балл, в тех, кто накопил 120 баллов (в процентах). Можно изменить критерий на этом этапе, например, Конверсия в тех, кто накопил баллы за две и более сессии.
4. Конверсия из тех, у кого есть на счету хотя бы 120 баллов (стоимость минимального купона) в тех, кто потратил накопленные баллы хотя бы один раз (в процентах).
5. Конверсия из партнеров, купоны которых были куплены пользователями и погашены, в тех, которые произвели оплату за привлеченного клиента (процент).
Вроде несложно. Но как вы думаете, на каком из этапов были самые плачевные показатели и почему? Ответ пишите в комментариях.
#кейс@custdevlab #гипотезы@custdeavlab #onescore@custdevlab
👍5🤔3🌭3❤1
37. Мобильное приложение OneScore: проблемы с метриками
В продолжение предыдущего поста расскажем о метриках приложения.
Важны не только сами по себе показатели, но и выбранный эталон для сравнения. Иначе как понять, хороший у нас результат или нет.
1. Стоимость установки (CLI — Cost-per-Install).
Рассчитывается как бюджет, потраченный на привлечение пользователей, установивших приложение, разделенный на количество этих пользователей.
На удивление, для приложения она получилась всего 16 рублей в среднем, а по некоторым каналам даже 12 рублей. При среднерыночной цене CLI в 60 рублей это нельзя считать неуспешным.
2. Конверсия из установившего приложение в первое накопление (в процентах).
Конверсия тоже оказалась удовлетворительной. 80% установивших запускали приложение и даже регистрировались в нем (оставляли номер телефона), и 60% от всех установивших начинали копить баллы.
3. Конверсия из тех, кто накопил хотя бы один балл, в тех, кто накопил 120 баллов (в процентах).
Этот процент был не очень высоким, но все же, не провальным. Около 35% пользователей копили регулярно. Удержание пользователей к 21 дню после установки снижалось до 20%.
4. Конверсия из тех, у кого есть на счету хотя бы 120 баллов (стоимость минимального купона) в тех, кто тратит накопленные баллы хотя бы один раз (в процентах).
Вот тут был самый большой провал. Из всех, кто копил баллы, только 1,6% пользователей их тратили на купоны, которые имели тоже низкий уровень конверсии в погашение. Т.е. купить в приложении купон и показать его партнеру не одно и то же. Даже если купон был куплен, более 50% из них не использовались.
5. Гипотеза о транзакциях от партнеров вообще не была протестирована, так как часть партнеров работала с нами бесплатно, а платные партнеры и купоны у них в воронку не попадали.
В сухом остатке: если бы мы тестировали только последнюю гипотезу про транзакции от партнеров, не проверяя предшествующие ей, найти причину провала практически невозможно.
#кейс@custdevlab #гипотезы@custdeavlab #метрики@custdevlab #onescore@custdevlab
В продолжение предыдущего поста расскажем о метриках приложения.
Важны не только сами по себе показатели, но и выбранный эталон для сравнения. Иначе как понять, хороший у нас результат или нет.
1. Стоимость установки (CLI — Cost-per-Install).
Рассчитывается как бюджет, потраченный на привлечение пользователей, установивших приложение, разделенный на количество этих пользователей.
На удивление, для приложения она получилась всего 16 рублей в среднем, а по некоторым каналам даже 12 рублей. При среднерыночной цене CLI в 60 рублей это нельзя считать неуспешным.
2. Конверсия из установившего приложение в первое накопление (в процентах).
Конверсия тоже оказалась удовлетворительной. 80% установивших запускали приложение и даже регистрировались в нем (оставляли номер телефона), и 60% от всех установивших начинали копить баллы.
3. Конверсия из тех, кто накопил хотя бы один балл, в тех, кто накопил 120 баллов (в процентах).
Этот процент был не очень высоким, но все же, не провальным. Около 35% пользователей копили регулярно. Удержание пользователей к 21 дню после установки снижалось до 20%.
4. Конверсия из тех, у кого есть на счету хотя бы 120 баллов (стоимость минимального купона) в тех, кто тратит накопленные баллы хотя бы один раз (в процентах).
Вот тут был самый большой провал. Из всех, кто копил баллы, только 1,6% пользователей их тратили на купоны, которые имели тоже низкий уровень конверсии в погашение. Т.е. купить в приложении купон и показать его партнеру не одно и то же. Даже если купон был куплен, более 50% из них не использовались.
5. Гипотеза о транзакциях от партнеров вообще не была протестирована, так как часть партнеров работала с нами бесплатно, а платные партнеры и купоны у них в воронку не попадали.
В сухом остатке: если бы мы тестировали только последнюю гипотезу про транзакции от партнеров, не проверяя предшествующие ей, найти причину провала практически невозможно.
#кейс@custdevlab #гипотезы@custdeavlab #метрики@custdevlab #onescore@custdevlab
👍7🌭2🔥1🤔1
38. Контролируем задачи по принципу 1/0 или процент плана
Работая с HADI-циклами проекты часто непонимают, как понять успешность цикла и какой вывод после него сделать. То же касается задач, гипотез и других процессов в стартапе, которые можно измерить по какой-нибудь метрике.
⛳️Принцип 1/0
Предполагает, что цель или достигнута, или нет.
Например: мобильное приложение прошло модерацию в сторе. Эту задачу можно выполнить, тогда модерация будет положительная и приложение станет доступно для скачивания, или можно не выполнить, тогда приложение нельзя будет скачать.
Другой пример: мы найдем маркетолога в проект к 1 числу следующего месяца. Цель ориентирована на результат, т.е. не так важен процесс поиска маркетолога, сколько важно, чтобы маркетолог был нанят.
🎯Процент от плана
Предполагает, что цель может быть частично достигнута и ее контроль осуществляется на основе процента, который был достигнут.
Например: провести 10 собеседований с соискателями маркетологами к 1 числу следующего месяца. Если было проведено 7 собеседований, значит эта задача выполнена на 70%.
Пример с приложением тут не подходит, так как нельзя пройти модерацию на 70%.
Почувствуйте разницу: если в проект нужен маркетолог, вы можете поставить себе задачу его найти, тогда измеряете достижение результата по принципу 1/0, а можете расписать достижение этой задачи на процесс и контролировать сам процесс по проценту от плана.
Если задача 1/0 была достигнута, это не то же самое, что 100% от плана при количестве собеседований — 10 проведенных собеседований не дают гарантию найти маркетолога в проект. И наоборот, если маркетолог найдет после 3 собеседований, получается что задача, оцениваемая по принципу «процент от плана» выполнена только лишь на 30%.
В сухом остатке: формулируйте задачи и оценивайте их эффективность таким образом, чтобы лучше можно было управлять результатом. Не стоит увлекаться процессом, забывая про результат.
#методика #hadi
Работая с HADI-циклами проекты часто непонимают, как понять успешность цикла и какой вывод после него сделать. То же касается задач, гипотез и других процессов в стартапе, которые можно измерить по какой-нибудь метрике.
⛳️Принцип 1/0
Предполагает, что цель или достигнута, или нет.
Например: мобильное приложение прошло модерацию в сторе. Эту задачу можно выполнить, тогда модерация будет положительная и приложение станет доступно для скачивания, или можно не выполнить, тогда приложение нельзя будет скачать.
Другой пример: мы найдем маркетолога в проект к 1 числу следующего месяца. Цель ориентирована на результат, т.е. не так важен процесс поиска маркетолога, сколько важно, чтобы маркетолог был нанят.
🎯Процент от плана
Предполагает, что цель может быть частично достигнута и ее контроль осуществляется на основе процента, который был достигнут.
Например: провести 10 собеседований с соискателями маркетологами к 1 числу следующего месяца. Если было проведено 7 собеседований, значит эта задача выполнена на 70%.
Пример с приложением тут не подходит, так как нельзя пройти модерацию на 70%.
Почувствуйте разницу: если в проект нужен маркетолог, вы можете поставить себе задачу его найти, тогда измеряете достижение результата по принципу 1/0, а можете расписать достижение этой задачи на процесс и контролировать сам процесс по проценту от плана.
Если задача 1/0 была достигнута, это не то же самое, что 100% от плана при количестве собеседований — 10 проведенных собеседований не дают гарантию найти маркетолога в проект. И наоборот, если маркетолог найдет после 3 собеседований, получается что задача, оцениваемая по принципу «процент от плана» выполнена только лишь на 30%.
В сухом остатке: формулируйте задачи и оценивайте их эффективность таким образом, чтобы лучше можно было управлять результатом. Не стоит увлекаться процессом, забывая про результат.
#методика #hadi
👍4🌭4❤2🤔2👏1
[CDL] Customer Interview Form.pptx
898.9 KB
39. Customer Interview: форма для записи результатов
Мы уже писали, что customer development не синоним интервьюирования пользователей. Среди методов custdev интервюирование занимает важное место, но не является единственным методом. Даже само интервью можно разделять на проблемное и решенческое, хотя часто получается что-то общее, без разделения на типы.
Сводить результаты интервью пользователя можно разными способами, а сам процесс лучше записывать на аудио или видео, чтобы можно было детально обработать собранную информацию. Но для оперативной записи результатов каждого интервью рекомендуем использовать предлагаемую форму.
Форма включает:
1. Информацию о респонденте: имя, фотографию (по желанию).
2. Техническую информацию об интервью: дата, место.
3. Суть ответа респондента: самая запомнившаяся цитата, быстрые факты о респонденте, инсайты и возможности для продукта.
Быстрые факты о респонденте — это фразы, которые помогают понять его опыт пользования товарной категорией, его привычки, предпочтения. Иными словами, краткий портрет потребителя.
Инсайт — это краткая фраза о потребителе, раскрывающая причины, мотивы поведения респондента. Найти инсайты — задача интервьюирования (опрос не позволит найти инсайты вовсе).
Возможности для продукта/проекта: это те фразы респондента, которые в последствии помогут сформулировать идеи по улучшению продукта, которые появились по ходу или после проведения интервью. Это могут быть гипотезы для HADI-циклов или просто список идей. Например: «Я каждый день делаю...» или «Мне важно, чтобы была возможность...»
В сухом остатке: используйте такую форму для записи результатов интервью, чтобы связывать слова респондента и улучшение продукта.
#методика #HADI #полезныефайлы
Мы уже писали, что customer development не синоним интервьюирования пользователей. Среди методов custdev интервюирование занимает важное место, но не является единственным методом. Даже само интервью можно разделять на проблемное и решенческое, хотя часто получается что-то общее, без разделения на типы.
Сводить результаты интервью пользователя можно разными способами, а сам процесс лучше записывать на аудио или видео, чтобы можно было детально обработать собранную информацию. Но для оперативной записи результатов каждого интервью рекомендуем использовать предлагаемую форму.
Форма включает:
1. Информацию о респонденте: имя, фотографию (по желанию).
2. Техническую информацию об интервью: дата, место.
3. Суть ответа респондента: самая запомнившаяся цитата, быстрые факты о респонденте, инсайты и возможности для продукта.
Быстрые факты о респонденте — это фразы, которые помогают понять его опыт пользования товарной категорией, его привычки, предпочтения. Иными словами, краткий портрет потребителя.
Инсайт — это краткая фраза о потребителе, раскрывающая причины, мотивы поведения респондента. Найти инсайты — задача интервьюирования (опрос не позволит найти инсайты вовсе).
Возможности для продукта/проекта: это те фразы респондента, которые в последствии помогут сформулировать идеи по улучшению продукта, которые появились по ходу или после проведения интервью. Это могут быть гипотезы для HADI-циклов или просто список идей. Например: «Я каждый день делаю...» или «Мне важно, чтобы была возможность...»
В сухом остатке: используйте такую форму для записи результатов интервью, чтобы связывать слова респондента и улучшение продукта.
#методика #HADI #полезныефайлы
👍7🌭6❤2🔥1🤩1
40. Конкуренты есть всегда!
В посте про ценность продукта мы писали о том, что важно сравнивать функции, которые нужны потребителю, с теми, которые предлагают ваши конкуренты. Цель — найти отличия, которых у конкурентов нет, но для потребителей они значимы.
Часто проект думает, что конкурентов у него нет. Иногда добавляя «прямых».
Конкуренты – это любые другие способы решить проблему («боль») потребителя, кроме того, который предлагает ваш продукт.
Иногда это не конкретные товары и услуги, а бесплатные альтернативные способы.
Ничего не делать – тоже альтернатива.
Конкуренты есть всегда! Не важно, прямые они, косвенные или какие-либо еще. Потребитель не думает такими категориями.
Важно понимать, что деньги у потребителя ограничены, поэтому выбирая между разными способами решения своей проблемы ему нужно решить не только на что он потратит деньги, но и на что он из-за этого не потратит.
В сухом остатке: конкуренты есть всегда, а прямые они или косвенные не важно (терминология вторична); решение купить один товар связано с решением не купить другой.
#полезное
В посте про ценность продукта мы писали о том, что важно сравнивать функции, которые нужны потребителю, с теми, которые предлагают ваши конкуренты. Цель — найти отличия, которых у конкурентов нет, но для потребителей они значимы.
Часто проект думает, что конкурентов у него нет. Иногда добавляя «прямых».
Конкуренты – это любые другие способы решить проблему («боль») потребителя, кроме того, который предлагает ваш продукт.
Иногда это не конкретные товары и услуги, а бесплатные альтернативные способы.
Ничего не делать – тоже альтернатива.
Конкуренты есть всегда! Не важно, прямые они, косвенные или какие-либо еще. Потребитель не думает такими категориями.
Важно понимать, что деньги у потребителя ограничены, поэтому выбирая между разными способами решения своей проблемы ему нужно решить не только на что он потратит деньги, но и на что он из-за этого не потратит.
В сухом остатке: конкуренты есть всегда, а прямые они или косвенные не важно (терминология вторична); решение купить один товар связано с решением не купить другой.
#полезное
👍10🔥3🌭3🤔1
41. HADI: зачем нужны и как с ними работать
HADI — циклический метод, состоящий из 4 последовательный шагов:
1. Выдвижение гипотезы (Hypothesis)
2. Способ проверки гипотезы (Action)
3. Сбор данных (метрик) (Data)
4. Выводы или инсайты (Insight)
Про гипотезы мы уже неоднократно писали, например: как формулировать первичные гипотезы и пример про приложение OneScore с составной гипотезой
Когда гипотеза сформулирована, нужно придумать, как ее проверить. Чем более конкретная гипотеза, с большим количеством уточнений, тем проще ее проверять. Однако при планировании проверки стоит сразу заложить метрики, которые помогут понять подтверждена гипотеза или опровергнута.
Рекомендуется сразу закладывать пороховые значения метрик, чтобы понять подверженность гипотезы. Такой подход называется Action Standarts, т.е. определение пороговых значений метрик для принятия решения о гипотезе.
Например, гипотеза «Цена для существующих клиентов является самым главным фактором выбора нашего продукта» может быть проверена через повышение цены на продукт. Мы уже рассматривали подобную ситуацию. Метрика в этом случае — доля (процент) клиентов, которые откажутся покупать по новой цене. Если доля будет 25%, мы считаем, что гипотеза подтверждена. Повышаем цену, замеряем долю. Делаем вывод.
Далее можно перейти к следующему HADI-циклу, сформулировав новую гипотезу: «Отказавшиеся клиенты могут покупать новый облегченный продукт за прежнюю цену». Для этого нужно разработать новую версию продукта, разместить ее на сайте (или где ее продаем), известить тех клиентов, кто отказался от покупки после повышения цены, и рассчитать долю клиентов, которые купить облегченный продукт.
HADI — очень эффективный и простой метод, который позволяет принимать правильные решения о продукте. По своей сути, каждый стартап борется за выживаемость на рынке, которую обеспечивает быстрая проверка гипотез. Иными словами, чем больше гипотез будет проверено, тем быстрее будет найден эффективный способ зарабатывать, тем выше вероятность у стартапа выжить.
В сухом остатке: применение метода HADI-циклов позволяет быстро и обоснованно проверять гипотезы одну за другой.
#hadi@custdevlab #гипотезы@custdeavlab #методика@custdevlab
HADI — циклический метод, состоящий из 4 последовательный шагов:
1. Выдвижение гипотезы (Hypothesis)
2. Способ проверки гипотезы (Action)
3. Сбор данных (метрик) (Data)
4. Выводы или инсайты (Insight)
Про гипотезы мы уже неоднократно писали, например: как формулировать первичные гипотезы и пример про приложение OneScore с составной гипотезой
Когда гипотеза сформулирована, нужно придумать, как ее проверить. Чем более конкретная гипотеза, с большим количеством уточнений, тем проще ее проверять. Однако при планировании проверки стоит сразу заложить метрики, которые помогут понять подтверждена гипотеза или опровергнута.
Рекомендуется сразу закладывать пороховые значения метрик, чтобы понять подверженность гипотезы. Такой подход называется Action Standarts, т.е. определение пороговых значений метрик для принятия решения о гипотезе.
Например, гипотеза «Цена для существующих клиентов является самым главным фактором выбора нашего продукта» может быть проверена через повышение цены на продукт. Мы уже рассматривали подобную ситуацию. Метрика в этом случае — доля (процент) клиентов, которые откажутся покупать по новой цене. Если доля будет 25%, мы считаем, что гипотеза подтверждена. Повышаем цену, замеряем долю. Делаем вывод.
Далее можно перейти к следующему HADI-циклу, сформулировав новую гипотезу: «Отказавшиеся клиенты могут покупать новый облегченный продукт за прежнюю цену». Для этого нужно разработать новую версию продукта, разместить ее на сайте (или где ее продаем), известить тех клиентов, кто отказался от покупки после повышения цены, и рассчитать долю клиентов, которые купить облегченный продукт.
HADI — очень эффективный и простой метод, который позволяет принимать правильные решения о продукте. По своей сути, каждый стартап борется за выживаемость на рынке, которую обеспечивает быстрая проверка гипотез. Иными словами, чем больше гипотез будет проверено, тем быстрее будет найден эффективный способ зарабатывать, тем выше вероятность у стартапа выжить.
В сухом остатке: применение метода HADI-циклов позволяет быстро и обоснованно проверять гипотезы одну за другой.
#hadi@custdevlab #гипотезы@custdeavlab #методика@custdevlab
👍10💯3🌭2
42. Правильный бенчмарк в custdev
Почему приложение Яндекс.Такси для таксистов для iOS появилось только в 2020 году, через 9 лет после основания самой компании? Скорее всего, потому что большинство таксистов имеют Android, а не iOS-устройство.
Приложение OneScore было сделано только для iOS. Основная причина, почему не сделали сразу для двух платформ, конечно, в отсутствии денег. Но можно было сделать изначально для Android. Почему не сделали? Очень просто: у всех основателей (5 человек) были Айфоны.
Custdev это не только интервью. Можно анализировать статистику или исследования рынков, проводить A/B-тесты, пробные продажи и др. Например, в случае с OneScore можно было провести бенчмаркинг: достаточно было посмотреть на Яндекс.Такси для таксистов, чтобы понять, что наша ЦА тоже использует Android, а не iOS.
Ошибка с выбором платформы автоматически изменила целевую аудиторию не только по важным параметрам, но и по важному параметру — мотивация для накопления баллов.
В сухом остатке: ориентируйтесь на потребности целевых сегментов, а не на свои собственные. Для этого и нужен custdev в любых его проявлениях.
#методика@custdevlab #бенчмарк@custdevlab
Почему приложение Яндекс.Такси для таксистов для iOS появилось только в 2020 году, через 9 лет после основания самой компании? Скорее всего, потому что большинство таксистов имеют Android, а не iOS-устройство.
Приложение OneScore было сделано только для iOS. Основная причина, почему не сделали сразу для двух платформ, конечно, в отсутствии денег. Но можно было сделать изначально для Android. Почему не сделали? Очень просто: у всех основателей (5 человек) были Айфоны.
Custdev это не только интервью. Можно анализировать статистику или исследования рынков, проводить A/B-тесты, пробные продажи и др. Например, в случае с OneScore можно было провести бенчмаркинг: достаточно было посмотреть на Яндекс.Такси для таксистов, чтобы понять, что наша ЦА тоже использует Android, а не iOS.
Ошибка с выбором платформы автоматически изменила целевую аудиторию не только по важным параметрам, но и по важному параметру — мотивация для накопления баллов.
В сухом остатке: ориентируйтесь на потребности целевых сегментов, а не на свои собственные. Для этого и нужен custdev в любых его проявлениях.
#методика@custdevlab #бенчмарк@custdevlab
👍10🌭4👏2
Собрали для удобства в одном посте методику customer interview (интревью клиентов):
Почему опрос не интервью:
1. Опросы и custdev. Часть 1
2. Опросы и custdev. Часть 2
Перечень вопросов:
3. С чего начать, если нет продукта и клиентов. Проблемные вопросы для customer interview
4. С чего начать, если есть продукт и клиенты. Решенческие вопросы для customer interview
5. Вопросы для интервью: идеальный продукт
6. Вопросы для интервью: отвратительный продукт
7. Вопросы про цену продукта
Как спрашивать:
8. Customer interview: открытые вопросы
9. Правило «Пять почему»
10. Можно ли проводить custdev через мессенджеры
Как записывать результат:
11. Customer Interview: форма для записи результатов
#подборка #интервью #методика
Почему опрос не интервью:
1. Опросы и custdev. Часть 1
2. Опросы и custdev. Часть 2
Перечень вопросов:
3. С чего начать, если нет продукта и клиентов. Проблемные вопросы для customer interview
4. С чего начать, если есть продукт и клиенты. Решенческие вопросы для customer interview
5. Вопросы для интервью: идеальный продукт
6. Вопросы для интервью: отвратительный продукт
7. Вопросы про цену продукта
Как спрашивать:
8. Customer interview: открытые вопросы
9. Правило «Пять почему»
10. Можно ли проводить custdev через мессенджеры
Как записывать результат:
11. Customer Interview: форма для записи результатов
#подборка #интервью #методика
👏8👍4🌭3❤2
43. Рост и масштабирование бизнеса: что посеешь, то и пожнешь
Или зачем нужен оценка рынка и проработка бизнес-модели.
Основатель стартапа как садовник: от того, семечку какого растения он посадит, будет зависеть размер взрослого растения, а также скорость роста, способность к масштабированию и пр.
🪴Некоторые бизнес-идеи — газон. Вырастают быстро, но не высоко. Зато и масштабировать можно быстро и недорого.
🪻Другие идеи — кусты. Растут дольше, но выше, сложнее масштабировать.
🌳Третьи идеи — деревья. Вырастают крайне долго, но зато очень высоко.
Оценка идеи стартапа — это ответ на вопрос, какое именно растение собирается выращивать садовник. Представьте, что идея стартапа — это непонятное семечко и только взгляд знающего специалиста подскажет, газон, куст или дерево у основателя в руке.
И в процессе ответа на этот вопрос custdev поможет рассчитать скорость роста и потенциальную высоту растения.
В сухом остатке: идея бизнеса — очень важный фактор успеха стартапа, но далеко не единственный. От идеи зависит потенциал бизнес-модели (высота растения) и скорость роста и масштабирования.
P.S. Газон — это тоже хороший бизнес. На этом тоже можно сделать большую выручку.
#полезное #масштабирование
Или зачем нужен оценка рынка и проработка бизнес-модели.
Основатель стартапа как садовник: от того, семечку какого растения он посадит, будет зависеть размер взрослого растения, а также скорость роста, способность к масштабированию и пр.
🪴Некоторые бизнес-идеи — газон. Вырастают быстро, но не высоко. Зато и масштабировать можно быстро и недорого.
🪻Другие идеи — кусты. Растут дольше, но выше, сложнее масштабировать.
🌳Третьи идеи — деревья. Вырастают крайне долго, но зато очень высоко.
Оценка идеи стартапа — это ответ на вопрос, какое именно растение собирается выращивать садовник. Представьте, что идея стартапа — это непонятное семечко и только взгляд знающего специалиста подскажет, газон, куст или дерево у основателя в руке.
И в процессе ответа на этот вопрос custdev поможет рассчитать скорость роста и потенциальную высоту растения.
В сухом остатке: идея бизнеса — очень важный фактор успеха стартапа, но далеко не единственный. От идеи зависит потенциал бизнес-модели (высота растения) и скорость роста и масштабирования.
P.S. Газон — это тоже хороший бизнес. На этом тоже можно сделать большую выручку.
#полезное #масштабирование
👍9👏2🌭2
Media is too big
VIEW IN TELEGRAM
Когда не проводил кастдев до запуска продукта.
Илипочему представления стартапа о пользователях отличаются от реальности.
@custdevlab #humor
Или
@custdevlab #humor
👍11😁8🌭2
44. Почему учиться на неудачных примерах лучше, чем на удачных
Удачные примеры в стартапах обычно звучат так: предприниматель сделал так-то и так-то, это сработало и он разбогател. Сторонний слушатель это послушает и… ничего не сделает со своим продуктом, потому что:
📊Рынок и игроки на нем изменились
⏱️Время изменилось
🛍️Модель поведения потребителя изменилась
Слушая успешную историю основателя бургерной новую сеть бургерных не построить.
Неудачи, провалы, фейлы дают больше полезной информации. Становится понятно, что не сработало, а в идеальном примере еще и почему это произошло. И вывод может быть разный: как делать не нужно, значит сделаем по-другому; как можно попробовать сделать, если ситуация на рынке изменилась (очень рискованно, но кто же нас остановит).
Если основатель бургерной расскажет про свои неудачи, это даст больше пользы для построения даже не бургерной, а подобного бизнеса.
Поэтому кейсы в нашем канале сопровождаются причинами неудач. Например, OneScore: проблема с метриками или как хоть и кастдевили, не получили хорошего результата.
В сухом остатке: учитесь кастдевить на неудачных примерах других предпринимателей ил исвоих неудачных примерах. Неудачный кастдев часто дает больше пользы, чем удачный.
#полезное@custdevlab
Удачные примеры в стартапах обычно звучат так: предприниматель сделал так-то и так-то, это сработало и он разбогател. Сторонний слушатель это послушает и… ничего не сделает со своим продуктом, потому что:
📊Рынок и игроки на нем изменились
⏱️Время изменилось
🛍️Модель поведения потребителя изменилась
Слушая успешную историю основателя бургерной новую сеть бургерных не построить.
Неудачи, провалы, фейлы дают больше полезной информации. Становится понятно, что не сработало, а в идеальном примере еще и почему это произошло. И вывод может быть разный: как делать не нужно, значит сделаем по-другому; как можно попробовать сделать, если ситуация на рынке изменилась (очень рискованно, но кто же нас остановит).
Если основатель бургерной расскажет про свои неудачи, это даст больше пользы для построения даже не бургерной, а подобного бизнеса.
Поэтому кейсы в нашем канале сопровождаются причинами неудач. Например, OneScore: проблема с метриками или как хоть и кастдевили, не получили хорошего результата.
В сухом остатке: учитесь кастдевить на неудачных примерах других предпринимателей ил исвоих неудачных примерах. Неудачный кастдев часто дает больше пользы, чем удачный.
#полезное@custdevlab
👍9🔥3❤2🌭2🤔1
45. Зачем нужны гипотезы для исследования и можно ли обойтись без них
Мы уже писали, где брать гипотезу для первого интервью. Но все чаще спрашивают, можно ли обойтись без гипотез? Зачем они нужны? О чем их формулировать?
Да, можно обойтись без гипотез. Гипотезы нужны, чтобы легче формулировать вопросы для интервью. Понимая гипотезу мы формулируем вопросы для ее проверки или опровержения.
Например, гипотеза: люди не бронируют рестораны, потому что идут спонтанно, и считают, что бронировать нужно минимум за день.
Вопросы для проверки этой гипотезы:
1. Вы бронируете рестораны?
Слушаем ответ.
2. Почему Вы так поступаете? (Зависит от ответа)
Слушаем ответ.
3. При необходимости применяем правило “5 почему”
Слушаем ответ. Если не было сказано про спонтанный поход, то задаем вопрос:
4. Расскажите, как Вы спонтанно ходили в ресторан? Были ли такой опыт?
Слушаем ответ. Если не было сказано про бронирование, говорим об этом. Если не было сказано про бронирование за день, то задаем следующий вопрос:
5. За какой срок, по вашему мнению, нужно бронировать ресторан?
Слушаем ответ.
В зависимости от сказанного мы понимаем, гипотеза подтвердилась или опровергнута.
Если же гипотезы нет, то разговор может пойти совсем в ином ключе. Если не знаешь, для чего спрашивать, то непонятно, что спрашивать. Так, интервью может растянуться на более длительное время, а результаты не помогут улучшить продукт.
Гипотезы помогают. Но плохая или некорректная гипотеза хуже, чем ее отсутствие.
В сухом остатке: модель проведения исследований “проблема-гипотеза-вопросы” помогает проводить интервью быстрее и получать результаты, которые можно применять сразу же.
#методика #гипотезы
Мы уже писали, где брать гипотезу для первого интервью. Но все чаще спрашивают, можно ли обойтись без гипотез? Зачем они нужны? О чем их формулировать?
Да, можно обойтись без гипотез. Гипотезы нужны, чтобы легче формулировать вопросы для интервью. Понимая гипотезу мы формулируем вопросы для ее проверки или опровержения.
Например, гипотеза: люди не бронируют рестораны, потому что идут спонтанно, и считают, что бронировать нужно минимум за день.
Вопросы для проверки этой гипотезы:
1. Вы бронируете рестораны?
Слушаем ответ.
2. Почему Вы так поступаете? (Зависит от ответа)
Слушаем ответ.
3. При необходимости применяем правило “5 почему”
Слушаем ответ. Если не было сказано про спонтанный поход, то задаем вопрос:
4. Расскажите, как Вы спонтанно ходили в ресторан? Были ли такой опыт?
Слушаем ответ. Если не было сказано про бронирование, говорим об этом. Если не было сказано про бронирование за день, то задаем следующий вопрос:
5. За какой срок, по вашему мнению, нужно бронировать ресторан?
Слушаем ответ.
В зависимости от сказанного мы понимаем, гипотеза подтвердилась или опровергнута.
Если же гипотезы нет, то разговор может пойти совсем в ином ключе. Если не знаешь, для чего спрашивать, то непонятно, что спрашивать. Так, интервью может растянуться на более длительное время, а результаты не помогут улучшить продукт.
Гипотезы помогают. Но плохая или некорректная гипотеза хуже, чем ее отсутствие.
В сухом остатке: модель проведения исследований “проблема-гипотеза-вопросы” помогает проводить интервью быстрее и получать результаты, которые можно применять сразу же.
#методика #гипотезы
👍6❤5🌭2
46. Почему стартап не проводит custdev
Существуют 4 причины:
1. Он думает, что знает лучше, чем его клиенты, что им на самом деле нужно
2. Он не умеет проводить custdev в любом виде, кроме как пробными продажами
3. Он проводит custdev для галочки, формально и без глубокого анализа
4. Он не хочет тратить драгоценное время на эту ерунду
1️⃣Сложнее всего предпринимателям с большим опытом. Они убеждены, что все знают лучше самих покупателей. Еще есть знаменитая фраза Генри Форда: “Если бы я спросил людей, чего они хотят, они бы сказали, что хотят более быстрых лошадей”. Кстати, нет никаких подтверждений, что Форд действительно это говорил.
2️⃣Custdev — это концепция проверки соответствия идеи стартапа рынку. Самый интуитивно понятный способ — пробные продажи. Сделать продукт и продать его. Купили, все хорошо. Нет — изменим продукт, и снова попробуем продать. Будем изменять продукт, пока не купят. Сам по себе подход не противоречит концепции custdev, но он очень дорогой.
3️⃣Очень часто слышу: Ну мы пообщались, ничего интересного и нового не узнали… Отвечают поверхностно, пользы ноль. Тут все просто: не так общались. Чаще всего интервью подменяют опросом, а точнее даже просто анкетой с открытыми вопросами (это даже не опрос, друзья).
4️⃣Все вышеперечисленное аккумулирует в эту причину. Зачем тратить время на то, что бесполезно.
В сухом остатке: какая бы причина не была, проблема не в custdev, а в неправильном применении этих методов.
#методика #полезное
Существуют 4 причины:
1. Он думает, что знает лучше, чем его клиенты, что им на самом деле нужно
2. Он не умеет проводить custdev в любом виде, кроме как пробными продажами
3. Он проводит custdev для галочки, формально и без глубокого анализа
4. Он не хочет тратить драгоценное время на эту ерунду
1️⃣Сложнее всего предпринимателям с большим опытом. Они убеждены, что все знают лучше самих покупателей. Еще есть знаменитая фраза Генри Форда: “Если бы я спросил людей, чего они хотят, они бы сказали, что хотят более быстрых лошадей”. Кстати, нет никаких подтверждений, что Форд действительно это говорил.
2️⃣Custdev — это концепция проверки соответствия идеи стартапа рынку. Самый интуитивно понятный способ — пробные продажи. Сделать продукт и продать его. Купили, все хорошо. Нет — изменим продукт, и снова попробуем продать. Будем изменять продукт, пока не купят. Сам по себе подход не противоречит концепции custdev, но он очень дорогой.
3️⃣Очень часто слышу: Ну мы пообщались, ничего интересного и нового не узнали… Отвечают поверхностно, пользы ноль. Тут все просто: не так общались. Чаще всего интервью подменяют опросом, а точнее даже просто анкетой с открытыми вопросами (это даже не опрос, друзья).
4️⃣Все вышеперечисленное аккумулирует в эту причину. Зачем тратить время на то, что бесполезно.
В сухом остатке: какая бы причина не была, проблема не в custdev, а в неправильном применении этих методов.
#методика #полезное
👍6🤔1🌭1
47. Почему custdev влияет на стоимость стартапа
В 2017 году я участвовал в переговорах о покупке сервиса заказа блюд в ресторане к определенному времени. Работало это так: выбираешь ресторан, выбираешь блюда, выбираешь время, оплачиваешь счет. Вроде просто и востребовано.
Сервис разрабатывали программисты, вся техническая интеграция была реализована: блюда берем из систему вправления рестораном, оплата интегрирована в нее же. У сервиса даже было два подключенных ресторана, готовы приготовиь блюда к нужному времени.
Владельцы сервиса запросили 3 млн. рублей, мотивируя цену трудозатрами: посчитали количество человекочасов, среднерыночную ставку одного человеко-часа и получилась соответствующая сумма.
На вопрос «Сколько пользователей прошли по всем процессам продукта, т.е. сколько человек со стороны попробовали воспользоваться сервисом и у них это получилось» был дан ответ: «Ни одного». Следовательно, стоимость компании также равна нулю.
Инвесторы покупают не технологии, покупают проверенный способ решения проблемы потребителей и работающую бизнес-модель. Именно процедуры custdev помогают это сделать.
В сухом остатке: Нет проверки гипотезы о потребительском поведении → стоимость компании 0 руб.
#полезное
В 2017 году я участвовал в переговорах о покупке сервиса заказа блюд в ресторане к определенному времени. Работало это так: выбираешь ресторан, выбираешь блюда, выбираешь время, оплачиваешь счет. Вроде просто и востребовано.
Сервис разрабатывали программисты, вся техническая интеграция была реализована: блюда берем из систему вправления рестораном, оплата интегрирована в нее же. У сервиса даже было два подключенных ресторана, готовы приготовиь блюда к нужному времени.
Владельцы сервиса запросили 3 млн. рублей, мотивируя цену трудозатрами: посчитали количество человекочасов, среднерыночную ставку одного человеко-часа и получилась соответствующая сумма.
На вопрос «Сколько пользователей прошли по всем процессам продукта, т.е. сколько человек со стороны попробовали воспользоваться сервисом и у них это получилось» был дан ответ: «Ни одного». Следовательно, стоимость компании также равна нулю.
Инвесторы покупают не технологии, покупают проверенный способ решения проблемы потребителей и работающую бизнес-модель. Именно процедуры custdev помогают это сделать.
В сухом остатке: Нет проверки гипотезы о потребительском поведении → стоимость компании 0 руб.
#полезное
👍10❤3👏2🌭1
48. Custdev и проверка целевых аудиторий
Регулярно слышу и читаю о том, что custdev нужен для валидации целевых сегментов. Что такое целевой сегмент? И как его валидировать?
Я уже писал о самом главном вопросе вашего стартапа: на каком рынке я работаю. По сути рынок — это потребители, готовые платить и/или пользоваться продуктом в сочетании с правильным восприятием вашего продукта.
Не всегда компания в итоге работает на том рынке, на котором планировала. И, конечно, если стартап думает, что у него нет конкурентов, то есть он работает на каком-то уникальном рынке, это тоже далеко от правды (конкуренты есть всегда!).
Валидация потребительских сегментов — это проверка гипотез о том, что потребитель нашего продукта.
Иначально мы предполагаем, что продукт интересен людям со схожими характеристиками. Отбираем респондентов в соответствии с предполагаемым портретом. Но допустим, что первые интервью показывают, что это не так и предполагаемый сегмент не заинтересован в продукте.
В этом случае мы продолжаем искать новые схожие характеристики среди тех респондентов, которые выражают намерение использовать наш продукт. То есть характеристики пользователей станут следствием, а не причиной. Вопрос: а кого тогда опрашивать, если мы не представляем их портрет?
Часто валидация является одной из задач исследований, а не ее основной целью.
В сухом остатке: валидация сегментов в custdev является важной дополнительной задачей при тестировании бизнес-модели.
#методика #валидациясегментов
Регулярно слышу и читаю о том, что custdev нужен для валидации целевых сегментов. Что такое целевой сегмент? И как его валидировать?
Я уже писал о самом главном вопросе вашего стартапа: на каком рынке я работаю. По сути рынок — это потребители, готовые платить и/или пользоваться продуктом в сочетании с правильным восприятием вашего продукта.
Не всегда компания в итоге работает на том рынке, на котором планировала. И, конечно, если стартап думает, что у него нет конкурентов, то есть он работает на каком-то уникальном рынке, это тоже далеко от правды (конкуренты есть всегда!).
Валидация потребительских сегментов — это проверка гипотез о том, что потребитель нашего продукта.
Иначально мы предполагаем, что продукт интересен людям со схожими характеристиками. Отбираем респондентов в соответствии с предполагаемым портретом. Но допустим, что первые интервью показывают, что это не так и предполагаемый сегмент не заинтересован в продукте.
В этом случае мы продолжаем искать новые схожие характеристики среди тех респондентов, которые выражают намерение использовать наш продукт. То есть характеристики пользователей станут следствием, а не причиной. Вопрос: а кого тогда опрашивать, если мы не представляем их портрет?
Часто валидация является одной из задач исследований, а не ее основной целью.
В сухом остатке: валидация сегментов в custdev является важной дополнительной задачей при тестировании бизнес-модели.
#методика #валидациясегментов
❤5👍3🤔2🌭2