1. Мобильное приложение OneScore: монетизируем автомобильные пробки
🚙🚕💰🚗🚛🚌
В 2016 году работал над проектом мобильного приложения, идея которого — монетизации автомобильных пробок. Пользователь зарабатывает на том, что стоит в пробке: одна минута — один доллар (потом посчитали экономику, конечно, ничего не сошлось). В итоге: за одну минуту в пробке пользователь получал один балл приложения. Баллы тратит на предложения партнеров (скидки, купоны), именно на этом мы и зарабатываем.
📱Сделали MVP, запустили тесты каналов трафика, стоимость установки равна 12 руб. при средней по рынку в 60 руб. Успех? Не совсем. После установки нужно, чтобы пользователь запустил и начал пользоваться. В нашем приложении это накопление баллов. Конверсия из установок в первый запуск составила >80%. Тоже отличный результат. Далее — копит баллы. Таких оказалось от 40 до 80% в зависимости от канала, но в среднем — 70%. Тоже неплохо. Но вот незадача, почти никто баллы не тратит, а монетизация зависит от трат накопленных баллов.
💡Решили касдевить. Гипотеза №3 (про остальные расскажу в других постах): добавить больше предложений партнеров с высокой ценностью. База клиентов с контактными данными есть, сегментируем пользователей на группы по частоте использования приложения и трат баллов, обзваниваем и проводим с ними диалог. Методика п телефонный звонок и включала стандартизированные вопросы, ключевой из которых: «Что нужно добавить в приложение, чтобы Вы потратили накопленные баллы?» Вроде бы вопрос прямой и понятный, но ответы на него слишком банальные.
👉🏻48% сказали «ничего».
👉🏻22% — «что-нибудь интересное».
Ошибка заключалась в том, что не было задано уточнений: почему, что именно, почему именно это? Остальные респонденты хоть и проговаривали конкретные предложения, но работать с ними не получилась, например, скидка на бензин 10%. 🙄
В сухом остатке: ошибка в методике и подготовке интервьюеров, нет уточняющих вопросов, формально это был телефонный опрос, а не глубинное интервью.
#кейс@custdevlab #ошибки@custdevlab #mvp@custdevlab #onescore@custdevlab
🚙🚕💰🚗🚛🚌
В 2016 году работал над проектом мобильного приложения, идея которого — монетизации автомобильных пробок. Пользователь зарабатывает на том, что стоит в пробке: одна минута — один доллар (потом посчитали экономику, конечно, ничего не сошлось). В итоге: за одну минуту в пробке пользователь получал один балл приложения. Баллы тратит на предложения партнеров (скидки, купоны), именно на этом мы и зарабатываем.
📱Сделали MVP, запустили тесты каналов трафика, стоимость установки равна 12 руб. при средней по рынку в 60 руб. Успех? Не совсем. После установки нужно, чтобы пользователь запустил и начал пользоваться. В нашем приложении это накопление баллов. Конверсия из установок в первый запуск составила >80%. Тоже отличный результат. Далее — копит баллы. Таких оказалось от 40 до 80% в зависимости от канала, но в среднем — 70%. Тоже неплохо. Но вот незадача, почти никто баллы не тратит, а монетизация зависит от трат накопленных баллов.
💡Решили касдевить. Гипотеза №3 (про остальные расскажу в других постах): добавить больше предложений партнеров с высокой ценностью. База клиентов с контактными данными есть, сегментируем пользователей на группы по частоте использования приложения и трат баллов, обзваниваем и проводим с ними диалог. Методика п телефонный звонок и включала стандартизированные вопросы, ключевой из которых: «Что нужно добавить в приложение, чтобы Вы потратили накопленные баллы?» Вроде бы вопрос прямой и понятный, но ответы на него слишком банальные.
👉🏻48% сказали «ничего».
👉🏻22% — «что-нибудь интересное».
Ошибка заключалась в том, что не было задано уточнений: почему, что именно, почему именно это? Остальные респонденты хоть и проговаривали конкретные предложения, но работать с ними не получилась, например, скидка на бензин 10%. 🙄
В сухом остатке: ошибка в методике и подготовке интервьюеров, нет уточняющих вопросов, формально это был телефонный опрос, а не глубинное интервью.
#кейс@custdevlab #ошибки@custdevlab #mvp@custdevlab #onescore@custdevlab
👍6❤5🔥1
19. Мовиста (Movista): слишком сложно, потребители не поняли
Проект Мовиста, основанный примерно в 2017-2018 годах, появился как попытка сделать первые в России и одни из первых в мире мультимодальные перевозки по принципу «одного окна».
Мультимодальные перевозки — когда пользователь строит маршрут из точки А в точку Б, а сервис подбирает оптимальные варианты с учетом пересадок на нескольких видах транспорта (авиа, Ж/Д, автобусы) и приобретает билеты сразу же в сервисе.
Традиционная модель поездки, например, из Москвы в Сочи от дома до гостиницы выглядит примерно так:
1. Поиск Гостиницы в Сочи (определение точки Б)
2. Поиск авиабилетов или ж/д билетов
3. Покупка авиабилетов или ж/д билетов
4. В день вылета или заранее: заказ такси до аэропорта
5. Организация трансфера от аэропорта до гостиницы в Сочи (такси или автобус) (поиск/покупка)
Мовиста предлагала решение следующим образом:
1. Указываете место проживания (точка А)
2. Указываете место назначения (точка Б)
3. Указываете даты поездки
4. Выбираете оптимальный маршрут с учетом мультимодальности (разные виды транспорта)
Все, система сама предложит оптимальное сочетание авиа (или ж/д), трансфер от аэропорта, даже такси поможет заказать. Если на маршруте есть рейсовые автобусы, купит билет и на него. Волшебство! Невероятно сложный сервис с технической точки зрения. Более 1,5 лет понадобилось, чтобы сделать часть технической составляющей.
Но вот главная проблема — поведение потребителей — команда проекта явно недооценила. Продела титанический труд в плане технической организации сервиса, Мовиста не уделила должного внимания модели поведения потребителя.
📲 Готов ли потребитель пользоваться таким сервисом?
🦋В какой форме его лучше организовать: приложение, сайт, чат-бот, все сразу?
🤷🏼♂️Будет ли понятно, что именно сервис предлагает?
🦚Много вариантов маршрутов — много настроек. Как их оптимально организовать в интерфейсе?
Это лишь малая потребительская часть проблем, которые необходимо было решить. Как можно убедиться, компания их не решила. Например, компания Фудфокс играла «в долгую», обучая и готовя потребителей к смене привычной ему модели поведения.
В сухом остатке: даже решив технически сложные вопросы стартап в первую очередь должен учитывать потребительские привычки и модели поведения. Битва за рынок — это битва не технологий, а битва за удобство потребителя.
#кейс #управлениеопытом #mvp
Проект Мовиста, основанный примерно в 2017-2018 годах, появился как попытка сделать первые в России и одни из первых в мире мультимодальные перевозки по принципу «одного окна».
Мультимодальные перевозки — когда пользователь строит маршрут из точки А в точку Б, а сервис подбирает оптимальные варианты с учетом пересадок на нескольких видах транспорта (авиа, Ж/Д, автобусы) и приобретает билеты сразу же в сервисе.
Традиционная модель поездки, например, из Москвы в Сочи от дома до гостиницы выглядит примерно так:
1. Поиск Гостиницы в Сочи (определение точки Б)
2. Поиск авиабилетов или ж/д билетов
3. Покупка авиабилетов или ж/д билетов
4. В день вылета или заранее: заказ такси до аэропорта
5. Организация трансфера от аэропорта до гостиницы в Сочи (такси или автобус) (поиск/покупка)
Мовиста предлагала решение следующим образом:
1. Указываете место проживания (точка А)
2. Указываете место назначения (точка Б)
3. Указываете даты поездки
4. Выбираете оптимальный маршрут с учетом мультимодальности (разные виды транспорта)
Все, система сама предложит оптимальное сочетание авиа (или ж/д), трансфер от аэропорта, даже такси поможет заказать. Если на маршруте есть рейсовые автобусы, купит билет и на него. Волшебство! Невероятно сложный сервис с технической точки зрения. Более 1,5 лет понадобилось, чтобы сделать часть технической составляющей.
Но вот главная проблема — поведение потребителей — команда проекта явно недооценила. Продела титанический труд в плане технической организации сервиса, Мовиста не уделила должного внимания модели поведения потребителя.
🦋В какой форме его лучше организовать: приложение, сайт, чат-бот, все сразу?
🤷🏼♂️Будет ли понятно, что именно сервис предлагает?
🦚Много вариантов маршрутов — много настроек. Как их оптимально организовать в интерфейсе?
Это лишь малая потребительская часть проблем, которые необходимо было решить. Как можно убедиться, компания их не решила. Например, компания Фудфокс играла «в долгую», обучая и готовя потребителей к смене привычной ему модели поведения.
В сухом остатке: даже решив технически сложные вопросы стартап в первую очередь должен учитывать потребительские привычки и модели поведения. Битва за рынок — это битва не технологий, а битва за удобство потребителя.
#кейс #управлениеопытом #mvp
Please open Telegram to view this post
VIEW IN TELEGRAM
👍7🌭3🤔2🔥1👨💻1
23. Вернитовар.ру — быстро и недорого проверяем гипотезу. Часть 1
В посте про маркетинг vs custdev написано, что цель custdev — проверить соответствие идеи/продукта потребностям потребителей. Custdev это не только глубинные интервью с потенциальными клиентами. Провести custdev можно и без прямого общения с клиентом, но обязательно на основе фактических данных с рынка.
Идея продукта: сервис по возврату товара в магазин за покупателя.
Сценарий поведения: покупатель приобретает товар в магазине (например, телевизор), он ему не понравился, а чтобы вернуть нужно ехать в магазин с тяжелым телевизором, писать заявления, ждать возврата денег и пр.
Гипотеза: потребителю «влом» заниматься возвратом непонравившегося товара (сложности с документами, не хочет ехать и т.д.)
Решение: покупатель заполняет заявку на сайте сервиса, приезжает курьер, забирает товар, отвозит его в магазин, проходит процедуры возврата, получает деньги и возвращает их покупателю.
Конечно, идея требует уточнения: как вернуть деньги, если оплата была картой, как вернуть технически сложные товары, что делать, если прошло больше 14 дней и пр. Эти задачи можно решать по принципу уменьшения сегмента. Первоочередная задача custdev сейчас — определить, есть ли потребность в такой услуге и готовы ли потребители за нее платить.
Custdev начался с проверки запросов в Wordstat: как вернуть товар, условия возврата товара и почему нельзя вернуть товар в магазин. Получилось несколько сотен тысяч запросов в месяц: потенциально есть спрос, тема популярна. Время на проведение этого исследования 15-20 минут.
Далее было решено сделать лендинг с простейшим описанием и формой для сбора лидов (как на картинке).
Купили домен Вернитовар.ру за 190 руб., настроили одностраничный сайт на конструкторе, проверили работу формы лидогенерации (важный шаг!) и установили Яндекс.Метрику. Время на проведение подготовки — 24 часа.
Продолжение...
#кейс #методика #mvp #проверкагипотез
В посте про маркетинг vs custdev написано, что цель custdev — проверить соответствие идеи/продукта потребностям потребителей. Custdev это не только глубинные интервью с потенциальными клиентами. Провести custdev можно и без прямого общения с клиентом, но обязательно на основе фактических данных с рынка.
Идея продукта: сервис по возврату товара в магазин за покупателя.
Сценарий поведения: покупатель приобретает товар в магазине (например, телевизор), он ему не понравился, а чтобы вернуть нужно ехать в магазин с тяжелым телевизором, писать заявления, ждать возврата денег и пр.
Гипотеза: потребителю «влом» заниматься возвратом непонравившегося товара (сложности с документами, не хочет ехать и т.д.)
Решение: покупатель заполняет заявку на сайте сервиса, приезжает курьер, забирает товар, отвозит его в магазин, проходит процедуры возврата, получает деньги и возвращает их покупателю.
Конечно, идея требует уточнения: как вернуть деньги, если оплата была картой, как вернуть технически сложные товары, что делать, если прошло больше 14 дней и пр. Эти задачи можно решать по принципу уменьшения сегмента. Первоочередная задача custdev сейчас — определить, есть ли потребность в такой услуге и готовы ли потребители за нее платить.
Custdev начался с проверки запросов в Wordstat: как вернуть товар, условия возврата товара и почему нельзя вернуть товар в магазин. Получилось несколько сотен тысяч запросов в месяц: потенциально есть спрос, тема популярна. Время на проведение этого исследования 15-20 минут.
Далее было решено сделать лендинг с простейшим описанием и формой для сбора лидов (как на картинке).
Купили домен Вернитовар.ру за 190 руб., настроили одностраничный сайт на конструкторе, проверили работу формы лидогенерации (важный шаг!) и установили Яндекс.Метрику. Время на проведение подготовки — 24 часа.
Продолжение...
#кейс #методика #mvp #проверкагипотез
👍5🌭3👌2
24. Вернитовар.ру — быстро и недорого проверяем гипотезу. Часть 2
В прошлом посте написал про Вернитовар.ру. Для custdev сделали:
1. Лендинг с формой для записи
2. Купили домен.
3. Установили Яндекс.Метрику
4. Протестировали работоспособность всего вышеперечисленного (очень важно!).
Осталось обеспечить посещаемость сайта и замерить конверсионные параметры.
Для трафика настроили контекстную рекламу по тем самым запросам (как вернуть товар, условия возврата товара, почему нельзя вернуть товар в магазин) за исключением чисто информационных или юридических. Бюджет составил около 5000 руб., а время на проведение рекламной кампании — 5-6 дней.
Как итог: за период рекламной кампании было получено более 250 переходов на сайт... и ни одной заявки. Эта конверсия, а точнее, ее отсутствие, фактически показывает отсутствие интереса в услуге.
Даже если было получено 2 заявки, каждая из них стоила бы 2500 руб. (CPO). Представим, что все заявки останутся актуальными и конвертируются в клиентов, тогда клиент стоит 2500 руб. Вряд ли возможно окупить такую стоимость привлечения клиента (CAC) в сервисе с высоким уровнем логистических и иных издержек или стоимость услуги будет превышать стоимость возвращаемого товара.
Делаем вывод: идея не жизнеспособна, потому что даже в целевом трафике конверсия меньше 1%.
Стоимость custdev: около 5200 руб.
Длительность: 1 неделя.
Для проведения custdev сначала рассматривали идею пойти к потенциальным потребителям и уточнять у них намерение воспользоваться подобными услугами (проблемное интервью). Но где найти таких потребителей так и не придумали.
Как определить, что человеку не понравился товар и он хочет его вернуть? До сих пор не знаю ответ на этот вопрос, если вы знаете — пишите в комментариях.
В сухом остатке: не всегда custdev — это интервьюирование, узнать востребованность идеи можно и другими методами, главное — факты с рынка, а не догадки основателей.
#кейс #методика #mvp #проверкагипотез
В прошлом посте написал про Вернитовар.ру. Для custdev сделали:
1. Лендинг с формой для записи
2. Купили домен.
3. Установили Яндекс.Метрику
4. Протестировали работоспособность всего вышеперечисленного (очень важно!).
Осталось обеспечить посещаемость сайта и замерить конверсионные параметры.
Для трафика настроили контекстную рекламу по тем самым запросам (как вернуть товар, условия возврата товара, почему нельзя вернуть товар в магазин) за исключением чисто информационных или юридических. Бюджет составил около 5000 руб., а время на проведение рекламной кампании — 5-6 дней.
Как итог: за период рекламной кампании было получено более 250 переходов на сайт... и ни одной заявки. Эта конверсия, а точнее, ее отсутствие, фактически показывает отсутствие интереса в услуге.
Даже если было получено 2 заявки, каждая из них стоила бы 2500 руб. (CPO). Представим, что все заявки останутся актуальными и конвертируются в клиентов, тогда клиент стоит 2500 руб. Вряд ли возможно окупить такую стоимость привлечения клиента (CAC) в сервисе с высоким уровнем логистических и иных издержек или стоимость услуги будет превышать стоимость возвращаемого товара.
Делаем вывод: идея не жизнеспособна, потому что даже в целевом трафике конверсия меньше 1%.
Стоимость custdev: около 5200 руб.
Длительность: 1 неделя.
Для проведения custdev сначала рассматривали идею пойти к потенциальным потребителям и уточнять у них намерение воспользоваться подобными услугами (проблемное интервью). Но где найти таких потребителей так и не придумали.
Как определить, что человеку не понравился товар и он хочет его вернуть? До сих пор не знаю ответ на этот вопрос, если вы знаете — пишите в комментариях.
В сухом остатке: не всегда custdev — это интервьюирование, узнать востребованность идеи можно и другими методами, главное — факты с рынка, а не догадки основателей.
#кейс #методика #mvp #проверкагипотез
🔥5👍3🌭2😢1
35. MVP продукта: как узнать, что «отсечь» от куска мрамора
MVP (от англ. minimum viable product) — продукт, обладающий минимальными, но достаточными для удовлетворения первых потребителей функциями. Представьте, что «идеальный» продукт для потребителя — это идеальное утро.
⏰Можно спать столько, сколько хочется, не глядя на будильник.
☕️Выпить чашечку свежесваренного кофе.
🛀Провести в душе столько времени, сколько хочется.
🍳Вкусно позавтракать.
📰Прочитать все те каналы в телеграмме, которые хочется.
👔Примерить несколько разных вариантов одежды, выбрать самый приятный и удобный.
MVP — это утро, когда вы проспали будильник и через 30 минут будет важная встреча.
— Кофе? Не нужен.
— Душ? Примем завтра.
— Разнообразный завтрак? Что получится съесть на бегу, то и будет завтраком.
— Читать каналы в Телеграме? Если успем по пути на работу.
— Одежда? Надеваем то, что успеем, выбор не на основе удобства, а на основе быстроты.
В сухом остатке: MVP — это отсекание всего лишнего от функций продукта, чтобы протестировать главную гипотезу.
#mvp
MVP (от англ. minimum viable product) — продукт, обладающий минимальными, но достаточными для удовлетворения первых потребителей функциями. Представьте, что «идеальный» продукт для потребителя — это идеальное утро.
⏰Можно спать столько, сколько хочется, не глядя на будильник.
☕️Выпить чашечку свежесваренного кофе.
🛀Провести в душе столько времени, сколько хочется.
🍳Вкусно позавтракать.
📰Прочитать все те каналы в телеграмме, которые хочется.
👔Примерить несколько разных вариантов одежды, выбрать самый приятный и удобный.
MVP — это утро, когда вы проспали будильник и через 30 минут будет важная встреча.
— Кофе? Не нужен.
— Душ? Примем завтра.
— Разнообразный завтрак? Что получится съесть на бегу, то и будет завтраком.
— Читать каналы в Телеграме? Если успем по пути на работу.
— Одежда? Надеваем то, что успеем, выбор не на основе удобства, а на основе быстроты.
В сухом остатке: MVP — это отсекание всего лишнего от функций продукта, чтобы протестировать главную гипотезу.
#mvp
👍7❤5🌭2
54. Мобильное приложение OneScore: новая бизнес-модель
Раз не получается зарабатывать на пользователях, можно найти иные способы монзтизации. Пусть будет много пользователей, а платить нам будет кто-то другой.
Идея: продавать аналитику о пользователях. Мы знаем больше, чем другие приложения: не просто точку А и точку Б на маршруте, но и каким образом пользователь будет добираться от А к Б, с какой скоростью. За счет наличия партнеров и статистики по купонам, мы будем знать, что пользователям интересно. Остально придумать, кому эта информация может быть насколько нужна, что он будет тратить деньги за ее получение.
Яндекс сам собирает такие данные. Даже в большем количестве, чем мы. А вот Mail.ru, скорее всего, такими данными не располагает (подумали мы). Следовательно, мы предложили концепцию данных, не имея даже адекватного API или интерфейса, т.е. без MVP, потенциальному покупателю. Однако, Mail.ru нам ответил, что подобные данные ему не очень нужны для его рекламной модели, а те данные, что нужны, он и без нас без труда уже собирает.
Следовательно, гипотеза не подтверждается, а значит, тратить ресурсы в реализацию API или изменению интерфейса аналитики нет смысла. Это тоже простой и быстрый custdev.
В сухом остатке: проверка бизнес-модели без custdev невозможна, или применение custdev-методик позволит сократить время и деньги на проверку гипотезы.
#методика@custdevlab #гипотезы@custdevlab #полезное@custdevlab #mvp@custdevlab #кейс@custdevlab
Раз не получается зарабатывать на пользователях, можно найти иные способы монзтизации. Пусть будет много пользователей, а платить нам будет кто-то другой.
Идея: продавать аналитику о пользователях. Мы знаем больше, чем другие приложения: не просто точку А и точку Б на маршруте, но и каким образом пользователь будет добираться от А к Б, с какой скоростью. За счет наличия партнеров и статистики по купонам, мы будем знать, что пользователям интересно. Остально придумать, кому эта информация может быть насколько нужна, что он будет тратить деньги за ее получение.
Яндекс сам собирает такие данные. Даже в большем количестве, чем мы. А вот Mail.ru, скорее всего, такими данными не располагает (подумали мы). Следовательно, мы предложили концепцию данных, не имея даже адекватного API или интерфейса, т.е. без MVP, потенциальному покупателю. Однако, Mail.ru нам ответил, что подобные данные ему не очень нужны для его рекламной модели, а те данные, что нужны, он и без нас без труда уже собирает.
Следовательно, гипотеза не подтверждается, а значит, тратить ресурсы в реализацию API или изменению интерфейса аналитики нет смысла. Это тоже простой и быстрый custdev.
В сухом остатке: проверка бизнес-модели без custdev невозможна, или применение custdev-методик позволит сократить время и деньги на проверку гипотезы.
#методика@custdevlab #гипотезы@custdevlab #полезное@custdevlab #mvp@custdevlab #кейс@custdevlab
👍4🌭4❤2
55. Custdev и пробные продажи: дорого и долго
Самый частый ответ на вопрос «Как можно проводить custdev?» звучит «Сделать продукт и продать».
Удивительно, но это один из правильных ответов custdev, ведь наша задача понять, подходит ли продукт для решения проблемы потребителя и готов ли потребитель за продукт платить. Именно готовый продукт лучше всего ответит на этот вопрос.
Но у данного метода custdev есть несколько недостатков:
1. Это очень дорого. Сделать даже MVP (не говорю о готовом продукте) стоит ресурсов.
2. Это очень долго. Много работы может быть «не туда», т.е. что-то происходит, но непонятно, нужно ли это потребителю.
3. Шанс ошибиться очень велик. Из-за того, что мы просто делаем продукт, а потом продаем, слишком много факторов будут влиять на провал.
4. Понять, где и что в нашем продукте работает плохо, будет сложно. Потому что придется раскручивать продукт «от продукта к проблеме потребителя», а не наоборот — «от проблемы потребителя к продукту».
В сухом остатке: делать custdev через готовый продукт и первые продажи можно, если есть много ресурсов, времени и терпения.
#методика #mvp
Самый частый ответ на вопрос «Как можно проводить custdev?» звучит «Сделать продукт и продать».
Удивительно, но это один из правильных ответов custdev, ведь наша задача понять, подходит ли продукт для решения проблемы потребителя и готов ли потребитель за продукт платить. Именно готовый продукт лучше всего ответит на этот вопрос.
Но у данного метода custdev есть несколько недостатков:
1. Это очень дорого. Сделать даже MVP (не говорю о готовом продукте) стоит ресурсов.
2. Это очень долго. Много работы может быть «не туда», т.е. что-то происходит, но непонятно, нужно ли это потребителю.
3. Шанс ошибиться очень велик. Из-за того, что мы просто делаем продукт, а потом продаем, слишком много факторов будут влиять на провал.
4. Понять, где и что в нашем продукте работает плохо, будет сложно. Потому что придется раскручивать продукт «от продукта к проблеме потребителя», а не наоборот — «от проблемы потребителя к продукту».
В сухом остатке: делать custdev через готовый продукт и первые продажи можно, если есть много ресурсов, времени и терпения.
#методика #mvp
👍8👏3🌭3
123. Идеального продукта не существует
Предприниматель часто ждет «идеальную» степень готовности продукта перед запуском его на рынок. Кажется, что есть кто-то, кто скажет, что в продукте должно быть и чего быть не должно. Сделай это — и успех на банковском счете обеспечен.
Или предприниматель ждет, что проведение 100-200 интервью даст ответ на вопрос «какой должен быть наш продукт?»
Это заблуждение. Идеального продукта не бывает и быть не может.
Интервью нужны (customer interview), но не 100 штук. Правильный отбор респондентов и предварительная сегментация позволяют значительно сократить количество интервью.
На основе интервью логично сделать MVP — сырой продукт, но с минимальной достаточной ценностью для пользователя. И уже выпустив MVP на рынок стоит смотреть на метрики продукта, опираясь на которые добавляем или убираем функции.
Идеальный продукт как линия горизонта — цель к которой мы должны стремиться, но никогда достичь ее не сможем.
В сухом остатке: работа над продуктом — это непрекращающийся итеративный процесс.
#продукт #MVP #метрики #идеальныйпродукт
Предприниматель часто ждет «идеальную» степень готовности продукта перед запуском его на рынок. Кажется, что есть кто-то, кто скажет, что в продукте должно быть и чего быть не должно. Сделай это — и успех на банковском счете обеспечен.
Или предприниматель ждет, что проведение 100-200 интервью даст ответ на вопрос «какой должен быть наш продукт?»
Это заблуждение. Идеального продукта не бывает и быть не может.
Интервью нужны (customer interview), но не 100 штук. Правильный отбор респондентов и предварительная сегментация позволяют значительно сократить количество интервью.
На основе интервью логично сделать MVP — сырой продукт, но с минимальной достаточной ценностью для пользователя. И уже выпустив MVP на рынок стоит смотреть на метрики продукта, опираясь на которые добавляем или убираем функции.
Идеальный продукт как линия горизонта — цель к которой мы должны стремиться, но никогда достичь ее не сможем.
В сухом остатке: работа над продуктом — это непрекращающийся итеративный процесс.
#продукт #MVP #метрики #идеальныйпродукт
👍10🌭6👏2🤔1
124. Что важнее: знание о клиентах или реализация продукта
Предположим, вам предстоит выбрать один из двух похожих по идее проектов.
1️⃣ Готово MVP и понятен его функционал. Можно «потыкать» кнопочки. Не проведены интервью с целевыми сегментами.
2️⃣ Нет MVP, «потыкать» ничего пока нельзя. Проведены 20 customer interview, в ходе которых сформирован список функций для MVP.
Какому проекту отдать предпочтение?
Команда первого проекта, конечно, молодцы. Но нет гарантии, что они «не галюцинируют». Т.е. не надумали функционал. Как в кейсе о продукте «заказ еды ко времени», когда функционал готов, но ни одного теста не было сделано. Конечно, есть вероятность, что они делают продукт для таких же, как они сами, т.е. они сами и есть представители своего целевого сегмента.
Команда второго проекта узнала у потенциальных клиентов, что им нужно. Конечно, важно понять, «как, сколько и кто» участвовали в этих исследованиях. Но они не галюцинируют. MVP отсутствует, и понять, как именно будет работать их продукт, может быть затруднительно. Но сделать MVP на основе данных от потенциальных клиентов уже технический вопрос.
От провала не застрахован ни первый, ни второй. Но второй, по крайней мере, уже общался с клиентом, а значит, вероятность сделать продукт, обладающий потребительской ценностью, значительно выше, чем у первой команды.
В сухом остатке: лучше знать, что нужно клиенту, чем думать, что знаешь, что ему нужно.
#продукт #MVP #галюцинации
Предположим, вам предстоит выбрать один из двух похожих по идее проектов.
1️⃣ Готово MVP и понятен его функционал. Можно «потыкать» кнопочки. Не проведены интервью с целевыми сегментами.
2️⃣ Нет MVP, «потыкать» ничего пока нельзя. Проведены 20 customer interview, в ходе которых сформирован список функций для MVP.
Какому проекту отдать предпочтение?
Команда первого проекта, конечно, молодцы. Но нет гарантии, что они «не галюцинируют». Т.е. не надумали функционал. Как в кейсе о продукте «заказ еды ко времени», когда функционал готов, но ни одного теста не было сделано. Конечно, есть вероятность, что они делают продукт для таких же, как они сами, т.е. они сами и есть представители своего целевого сегмента.
Команда второго проекта узнала у потенциальных клиентов, что им нужно. Конечно, важно понять, «как, сколько и кто» участвовали в этих исследованиях. Но они не галюцинируют. MVP отсутствует, и понять, как именно будет работать их продукт, может быть затруднительно. Но сделать MVP на основе данных от потенциальных клиентов уже технический вопрос.
От провала не застрахован ни первый, ни второй. Но второй, по крайней мере, уже общался с клиентом, а значит, вероятность сделать продукт, обладающий потребительской ценностью, значительно выше, чем у первой команды.
В сухом остатке: лучше знать, что нужно клиенту, чем думать, что знаешь, что ему нужно.
#продукт #MVP #галюцинации
👍11🌭5👏3