Сегодня полезности..
Статья «4 главных показателя для оценки вашего рынка», автор Алексей Шабаршин
Статья «Карта восприятия» (полезно для поиска ниши и конкурентного анализа), автор Ирина Самаркина
Книга «Графики, которые убеждают всех», автор Александр Богачев
Подкаст «О конкурентном анализе, сегментировании индустрий и ниш, и копировании фич»
Статья «4 главных показателя для оценки вашего рынка», автор Алексей Шабаршин
Статья «Карта восприятия» (полезно для поиска ниши и конкурентного анализа), автор Ирина Самаркина
Книга «Графики, которые убеждают всех», автор Александр Богачев
Подкаст «О конкурентном анализе, сегментировании индустрий и ниш, и копировании фич»
✍4🔥2🤔1🏆1
Сегодня хочу с вами поговорить о Lean Canvas..
Это одностраничный шаблон бизнес-модели для записи наиболее важных гипотез о развитии бизнеса.
Lean Canvas помогает с агрегировать разные части нашего бизнеса и понять ничего ли мы не забыли.
На минуточку этой штуке уже 16 лет, ведь он был создан в 2010 году (в основу легла более ранняя "Бизнес-модель Остервальдера") и использовался преимущественно для работы с SaaS-стартапами, а сейчас используется как для стартапов, так и для зрелых продуктов при запуске новых фич или новых направлений.
❗️ Иногда мы заполняем одну бизнес-модель, а иногда несколько.
Например,
1. Маркетплейсы - отдельно делаем и для продавцов, и для покупателей.
2. Агрегатор Такси - отдельно делаем для водителей, для пассажиров, для автопарков.
Заполнять нужно последовательно..
1. Клиентские сегменты. Если только придумали продукт - пишем гипотезы про ранних последователей, новаторов (не весь рынок, а тех, кто побежит первым). Для B2B, мы указываем ЛПР и ЛВР.
2. Проблема. Сюда мы записываем какую проблему они испытывают, какие задачи они пытаются решить, а также какие решения они используют сейчас или не используют ничего.
3. Ценностное предложение. Пишем для каждого сегмента отдельно. Не «крутой продукт», а «мы решаем твою конкретную боль вот так».
4. Решение. Можно описывать параллельно с ценностным предложением. Здесь записываем как именно ваш продукт закрывает проблему.
5. Каналы привлечения. Где искать этих людей? И сразу прикидываем ёмкость канала: сколько там вообще наших клиентов?
6. Потоки доходов. Средний чек, LTV, количество продаж в период. На чём конкретно зарабатываем?
7. Структура издержек. Здесь расписываем: фиксированные расходы, переменные, расходы на привлечение клиента (CAC).
8. Ключевые метрики. Здесь указываем 2-3 метрики, к ним можно отнести те несколько цифр по которым мы сможем понять куда движется бизнес либо что-то пошло не так, либо бизнес стал расти.
Пример для мобильного приложения: DAU, LTV, Revenue.
Больше трех - уже не ключевые. Вы просто не успеете за ними следить.
9. Нерыночное конкурентное преимущество. Оно у нас уже должно быть, либо мы точно можем его очень быстро получить. Если у нас его еще нет, его нельзя сюда писать.
Например, эксклюзивная экспертиза, которую нельзя быстро купить на рынке, или патенты, изобретения, или уникальные партнёрства или доступ к ресурсам.
❗️ Главное правило: Заполнили - не забыли. Lean Canvas живёт, только пока мы в него заглядываете.
На старте заполняете его чуть ли не каждый месяц. Потом раз в квартал, раз в полгода.
Гипотезы заменяются реальными цифрами: «Думали, средний чек 3000, а он 2800». «Думали, CAC 300, а он 700». Находятся новые сегменты, новые решения, новые конкуренты.
Lean Canvas - это не статичный инструмент, а динамичный, который периодически нужно заполнять с командой.
#LeanCanvas #БизнесМодель #Стартап #Продукт #Метрики
Это одностраничный шаблон бизнес-модели для записи наиболее важных гипотез о развитии бизнеса.
Lean Canvas помогает с агрегировать разные части нашего бизнеса и понять ничего ли мы не забыли.
На минуточку этой штуке уже 16 лет, ведь он был создан в 2010 году (в основу легла более ранняя "Бизнес-модель Остервальдера") и использовался преимущественно для работы с SaaS-стартапами, а сейчас используется как для стартапов, так и для зрелых продуктов при запуске новых фич или новых направлений.
❗️ Иногда мы заполняем одну бизнес-модель, а иногда несколько.
Например,
1. Маркетплейсы - отдельно делаем и для продавцов, и для покупателей.
2. Агрегатор Такси - отдельно делаем для водителей, для пассажиров, для автопарков.
Заполнять нужно последовательно..
1. Клиентские сегменты. Если только придумали продукт - пишем гипотезы про ранних последователей, новаторов (не весь рынок, а тех, кто побежит первым). Для B2B, мы указываем ЛПР и ЛВР.
2. Проблема. Сюда мы записываем какую проблему они испытывают, какие задачи они пытаются решить, а также какие решения они используют сейчас или не используют ничего.
3. Ценностное предложение. Пишем для каждого сегмента отдельно. Не «крутой продукт», а «мы решаем твою конкретную боль вот так».
4. Решение. Можно описывать параллельно с ценностным предложением. Здесь записываем как именно ваш продукт закрывает проблему.
5. Каналы привлечения. Где искать этих людей? И сразу прикидываем ёмкость канала: сколько там вообще наших клиентов?
6. Потоки доходов. Средний чек, LTV, количество продаж в период. На чём конкретно зарабатываем?
7. Структура издержек. Здесь расписываем: фиксированные расходы, переменные, расходы на привлечение клиента (CAC).
8. Ключевые метрики. Здесь указываем 2-3 метрики, к ним можно отнести те несколько цифр по которым мы сможем понять куда движется бизнес либо что-то пошло не так, либо бизнес стал расти.
Пример для мобильного приложения: DAU, LTV, Revenue.
Больше трех - уже не ключевые. Вы просто не успеете за ними следить.
9. Нерыночное конкурентное преимущество. Оно у нас уже должно быть, либо мы точно можем его очень быстро получить. Если у нас его еще нет, его нельзя сюда писать.
Например, эксклюзивная экспертиза, которую нельзя быстро купить на рынке, или патенты, изобретения, или уникальные партнёрства или доступ к ресурсам.
❗️ Главное правило: Заполнили - не забыли. Lean Canvas живёт, только пока мы в него заглядываете.
На старте заполняете его чуть ли не каждый месяц. Потом раз в квартал, раз в полгода.
Гипотезы заменяются реальными цифрами: «Думали, средний чек 3000, а он 2800». «Думали, CAC 300, а он 700». Находятся новые сегменты, новые решения, новые конкуренты.
Lean Canvas - это не статичный инструмент, а динамичный, который периодически нужно заполнять с командой.
#LeanCanvas #БизнесМодель #Стартап #Продукт #Метрики
🔥5✍1💯1😈1
🎉 Поздравляю всех с прошедшим Днём святого Валентина и с Китайским Новым годом!
🔥 Пятничный вечер и вчерашний день прошли замечательно – надеюсь, у вас тоже.
Кстати, мы на этих выходных впервые посетили Воронежский Стендап Клуб. Что сказать – это был необычный экспириенс. Раньше смотрели по телеку, но живьём всё совсем иначе. Атмосфера решает.
Экспромт ведущего был самым топовым. Но и другие комики отлично зашли – хорошие шутки были у всех.
И снова напоминаю себе и вам: work-life balance – это ВАЖНЫЙ элемент нашей жизни.
Всё, ради чего мы работаем – это мы сами и наши близкие. Если есть гармония с собой и с семьёй, выхлоп на работе умножается кратно.
🔥 Пятничный вечер и вчерашний день прошли замечательно – надеюсь, у вас тоже.
Кстати, мы на этих выходных впервые посетили Воронежский Стендап Клуб. Что сказать – это был необычный экспириенс. Раньше смотрели по телеку, но живьём всё совсем иначе. Атмосфера решает.
Экспромт ведущего был самым топовым. Но и другие комики отлично зашли – хорошие шутки были у всех.
И снова напоминаю себе и вам: work-life balance – это ВАЖНЫЙ элемент нашей жизни.
Всё, ради чего мы работаем – это мы сами и наши близкие. Если есть гармония с собой и с семьёй, выхлоп на работе умножается кратно.
🔥6💯1👻1
Принимаю поздравления..
Одна веха моего обучения подошла к концу, вчера я получил ответ по своему Дипломному продукту..
На картинке выше – фидбэк по последней версии. Всего их было две. Всю прошлую неделю занимался корректировками. В первой версии были недочеты, после чего я их исправил и все, Я УСПЕШНО ЗАЩИТИЛ СВОЙ ПРОДУКТ.😁
Почему спросите одна?
Потому что мой курс расширенный и в данном случае я закончил базовую версию обучения..
В расширенной версии будет погружение в SQL, больше практики:
- по Customer development
- по UE и PnL
- по тестовым кейсам на собеседовании и в целом больше кейсов.
#диплом #продукт #стартап
Одна веха моего обучения подошла к концу, вчера я получил ответ по своему Дипломному продукту..
На картинке выше – фидбэк по последней версии. Всего их было две. Всю прошлую неделю занимался корректировками. В первой версии были недочеты, после чего я их исправил и все, Я УСПЕШНО ЗАЩИТИЛ СВОЙ ПРОДУКТ.😁
Почему спросите одна?
Потому что мой курс расширенный и в данном случае я закончил базовую версию обучения..
В расширенной версии будет погружение в SQL, больше практики:
- по Customer development
- по UE и PnL
- по тестовым кейсам на собеседовании и в целом больше кейсов.
#диплом #продукт #стартап
🔥9✍1💯1👨💻1
А теперь поговорим о ЦЕЛЯХ..
Ведь нужно понимать, к чему стремиться при создании и развитии продукта. Для этого нам и нужно понимать наши цели.
В своей работе я рассматривал 3 вида целей. Важно: у каждой должны быть метрики, конкретные значения и сроки. Иначе это не цель, а хотелка.
1. Бизнес-цели.
Это главные финансовые ориентиры компании.
Бизнес-цели компании направлены на достижение стратегических целей, будь то увеличение доли
рынка, изменение уровня продаж и уровня прибыли.
В первую очередь цель определяется текущей стратегией компании.
● Нас интересует доля, а не сиюминутная прибыль, если мы захватываем рынок.
● Смотрим на повторные покупки, средний чек, LTV, если повышаем лояльность.
А далее, она дополняется рыночной ситуацией.
● Если растущий рынок. Вкладываемся в маркетинг, терпим убытки сейчас ради будущего.
● Если насыщенный рынок. Доли поделены, конкурентов тьма. Цель - откусить свой кусок через новые фичи или демпинг.
● Если мы на стагнирующий рынок. Оптимизируем расходы и ищем новые ниши, пока не поздно.
Примеры:
● Увеличить продажи кредитной карты "Silver" (лимит не менее 15 000 рублей) в отделении на ул. Карла Маркса в 1,5 раза по сравнению с показателем прошлого года.
● Увеличить долю рынка на 10% в Казани по продуктовой линейке XYZ к концу финансового года.
2. Продуктовые цели.
Описывают свойства и метрики продукта, необходимые для достижения бизнес-цели, такие как целевой средний чек, retention и тд.
Примеры:
● Увеличить LTV на 20% за полгода.
● Снизить COGS на 10% к концу года.
● Увеличить средний чек на 10% до конца года.
3. Маркетинговые цели.
Тут главный вопрос: «Сколько и какой аудитории нам надо, чтобы выполнить бизнес-цель? И что они должны сделать?»
Правильные маркетинговые цели обычно про привлечения новой аудитории, про улучшения или изменения базы клиентов, про изменение привычек использования товара, про повышения лояльности к продукту компании и т.д.
Примеры:
● Получить 5000 регистраций в мобильном приложении через 6 месяцев, при этом стоимость регистрации не должна превышать затраты на привлечение.
● Увеличить частоту приобретения товара с 1 до 2 раз в год.
● Привлечь 1000 платящих пользователей в магазин за 3 месяца.
● Увеличить частоту пробных покупок среди молодой аудитории 18-23 года.
● Снизить цену привлечения платящих клиентов на 15%, при этом количество платящих поднять на 10% за год.
Главное: все эти цели должны быть связаны. Если связь рвётся — вы работаете вхолостую.
#Целеполагание #Метрики #БизнесЦели #Продукт #Маркетинг #Стратегия
Ведь нужно понимать, к чему стремиться при создании и развитии продукта. Для этого нам и нужно понимать наши цели.
В своей работе я рассматривал 3 вида целей. Важно: у каждой должны быть метрики, конкретные значения и сроки. Иначе это не цель, а хотелка.
1. Бизнес-цели.
Это главные финансовые ориентиры компании.
Бизнес-цели компании направлены на достижение стратегических целей, будь то увеличение доли
рынка, изменение уровня продаж и уровня прибыли.
В первую очередь цель определяется текущей стратегией компании.
● Нас интересует доля, а не сиюминутная прибыль, если мы захватываем рынок.
● Смотрим на повторные покупки, средний чек, LTV, если повышаем лояльность.
А далее, она дополняется рыночной ситуацией.
● Если растущий рынок. Вкладываемся в маркетинг, терпим убытки сейчас ради будущего.
● Если насыщенный рынок. Доли поделены, конкурентов тьма. Цель - откусить свой кусок через новые фичи или демпинг.
● Если мы на стагнирующий рынок. Оптимизируем расходы и ищем новые ниши, пока не поздно.
Примеры:
● Увеличить продажи кредитной карты "Silver" (лимит не менее 15 000 рублей) в отделении на ул. Карла Маркса в 1,5 раза по сравнению с показателем прошлого года.
● Увеличить долю рынка на 10% в Казани по продуктовой линейке XYZ к концу финансового года.
2. Продуктовые цели.
Описывают свойства и метрики продукта, необходимые для достижения бизнес-цели, такие как целевой средний чек, retention и тд.
Примеры:
● Увеличить LTV на 20% за полгода.
● Снизить COGS на 10% к концу года.
● Увеличить средний чек на 10% до конца года.
3. Маркетинговые цели.
Тут главный вопрос: «Сколько и какой аудитории нам надо, чтобы выполнить бизнес-цель? И что они должны сделать?»
Правильные маркетинговые цели обычно про привлечения новой аудитории, про улучшения или изменения базы клиентов, про изменение привычек использования товара, про повышения лояльности к продукту компании и т.д.
Примеры:
● Получить 5000 регистраций в мобильном приложении через 6 месяцев, при этом стоимость регистрации не должна превышать затраты на привлечение.
● Увеличить частоту приобретения товара с 1 до 2 раз в год.
● Привлечь 1000 платящих пользователей в магазин за 3 месяца.
● Увеличить частоту пробных покупок среди молодой аудитории 18-23 года.
● Снизить цену привлечения платящих клиентов на 15%, при этом количество платящих поднять на 10% за год.
Главное: все эти цели должны быть связаны. Если связь рвётся — вы работаете вхолостую.
#Целеполагание #Метрики #БизнесЦели #Продукт #Маркетинг #Стратегия
🔥6✍1💯1
Разбираем наши цели по кусочкам, декомпозируем..
Декомпозиция, простым языком – это переход от общего к частному, от сложного к простому.
Декомпозиция цели – это её детализация, наглядное разделение большой, объёмной цели на многоуровневую иерархию небольших, но связанных между собой задач.
Этапы работы:
1. Выясняем бизнес-цель. Для этого мы идем к менеджеру, владеющим информацией, и узнаем, какова бизнес-цель продукта и как она связана со стратегией компании. Всё оцифровываем.
2. Смотрим текущее состояние. Что сейчас с продуктом? Есть ли какие-то ограничения для реализации бизнес-цели? Какова пропускная способность бизнеса? (Сколько людей можем обслужить?😁)
3. Смотрим текущие метрики. В зависимости от бизнес-модели узнаем, например, какой у нас средний чек, частота покупок, LTV или проводим конкурентный анализ (желательно, с прозвоном конкурентов).
4. Моделируем целевые значения и метрики. На этом этапе мы думаем, что можно сделать для достижения нужных показателей.
5. Анализируем глубже то, что думаем взять в работу.
6. После анализа и размышлений над метриками у нас появятся гипотезы, которые нужно будет проверить.
7. Считаем бюджет. Сколько денег мы можем позволить себе потратить на то, чтобы привлекать пользователей: % от выручки, % от маржи, или фикс.
Давайте разберем на примере, систему лояльности для сети АЗС.
1. Акционеры поставили задачу увеличить месячную выручку на 15% к декабрю следующего года. Это значит, что у нас есть год на то, чтобы увеличить среднемесячную выручку компании.
Цель: с помощью новой системы лояльности обеспечить прирост выручки до 9 343 750 000 рублей в месяц.
2. Сейчас выручка – 8 125 000 000 рублей в месяц.
Пропускная способность АЗС позволяет обслуживать в 4 раза больше людей – ограничений нет.
3. Мы выяснили, что средний чек на заправках 1250 рублей за заправку (1000 рублей за бензин, 250 рублей за товары (сигареты, кофе, напитки, еда). Частота заправок: 1,3 раза в месяц на одного клиента.
4. Нужно подумать, как увеличить средний чек (например, за счёт доптоваров) или частоту заправок.
В нашем примере нашли точку роста: клиенты мало покупают кофе, снеки и фастфуд.
5. Анализируем из чего состоит средний чек. Выясняем, почему люди хотят возвращаться. Изучаем системы лояльности конкурентов.
6. Обсуждаем проверку гипотез в рамках пилотного запуска системы лояльности. Мы принимаем решение запустить пилот в Калуге на 10 000 человек.
7. Выясняем, что можем потратить 20% от суммы прироста выручки на привлечение пользователей.
Подытожим:
Бизнес-цель:
✅ Обеспечить с помощью новой системы лояльности прирост выручки на 15% (до 9 343 750 000 рублей).
Продуктовые цели:
✅ Рост среднего чека или ретеншн на 15%.
Продуктовая задача:
✅ Проведение пилота в Калуге на 10 000 человек (KPI: CAC до 49р, AvP +15%).
Маркетинговые цели:
✅ Установка и активация 5 000 000 приложений.
✅ САС до 49р.
#Декомпозиция #Целеполагание #Метрики #Продукт #БизнесЦели #Стратегия
Декомпозиция, простым языком – это переход от общего к частному, от сложного к простому.
Декомпозиция цели – это её детализация, наглядное разделение большой, объёмной цели на многоуровневую иерархию небольших, но связанных между собой задач.
Этапы работы:
1. Выясняем бизнес-цель. Для этого мы идем к менеджеру, владеющим информацией, и узнаем, какова бизнес-цель продукта и как она связана со стратегией компании. Всё оцифровываем.
2. Смотрим текущее состояние. Что сейчас с продуктом? Есть ли какие-то ограничения для реализации бизнес-цели? Какова пропускная способность бизнеса? (Сколько людей можем обслужить?😁)
3. Смотрим текущие метрики. В зависимости от бизнес-модели узнаем, например, какой у нас средний чек, частота покупок, LTV или проводим конкурентный анализ (желательно, с прозвоном конкурентов).
4. Моделируем целевые значения и метрики. На этом этапе мы думаем, что можно сделать для достижения нужных показателей.
5. Анализируем глубже то, что думаем взять в работу.
6. После анализа и размышлений над метриками у нас появятся гипотезы, которые нужно будет проверить.
7. Считаем бюджет. Сколько денег мы можем позволить себе потратить на то, чтобы привлекать пользователей: % от выручки, % от маржи, или фикс.
Давайте разберем на примере, систему лояльности для сети АЗС.
1. Акционеры поставили задачу увеличить месячную выручку на 15% к декабрю следующего года. Это значит, что у нас есть год на то, чтобы увеличить среднемесячную выручку компании.
Цель: с помощью новой системы лояльности обеспечить прирост выручки до 9 343 750 000 рублей в месяц.
2. Сейчас выручка – 8 125 000 000 рублей в месяц.
Пропускная способность АЗС позволяет обслуживать в 4 раза больше людей – ограничений нет.
3. Мы выяснили, что средний чек на заправках 1250 рублей за заправку (1000 рублей за бензин, 250 рублей за товары (сигареты, кофе, напитки, еда). Частота заправок: 1,3 раза в месяц на одного клиента.
4. Нужно подумать, как увеличить средний чек (например, за счёт доптоваров) или частоту заправок.
В нашем примере нашли точку роста: клиенты мало покупают кофе, снеки и фастфуд.
5. Анализируем из чего состоит средний чек. Выясняем, почему люди хотят возвращаться. Изучаем системы лояльности конкурентов.
6. Обсуждаем проверку гипотез в рамках пилотного запуска системы лояльности. Мы принимаем решение запустить пилот в Калуге на 10 000 человек.
7. Выясняем, что можем потратить 20% от суммы прироста выручки на привлечение пользователей.
Подытожим:
Бизнес-цель:
✅ Обеспечить с помощью новой системы лояльности прирост выручки на 15% (до 9 343 750 000 рублей).
Продуктовые цели:
✅ Рост среднего чека или ретеншн на 15%.
Продуктовая задача:
✅ Проведение пилота в Калуге на 10 000 человек (KPI: CAC до 49р, AvP +15%).
Маркетинговые цели:
✅ Установка и активация 5 000 000 приложений.
✅ САС до 49р.
#Декомпозиция #Целеполагание #Метрики #Продукт #БизнесЦели #Стратегия
🔥5✍1💯1
Пам-пам-пам.. у нас сегодня понедельник.. и выходной.. 😁
Неделя масленицы пробежала, надеюсь, все успели отдохнуть на выходных и наелись блинами вдоволь..
Сегодня хочу поздравить всех мужчин с мужественным праздником 23 февраля!
Желаю всем здоровья и мирного неба над головой!
Всех обнял, всех приподнял!🍻
Сегодня хочу поздравить всех мужчин с мужественным праздником 23 февраля!
Желаю всем здоровья и мирного неба над головой!
Всех обнял, всех приподнял!🍻
🔥9💯2👨💻1
Всем привет, цели мы с вами разобрали..
Сегодня хочу кратко рассказать про хороший метод постановки цели..
А именно о S-M-A-R-T.
Слово-акроним, а за ним – 5 критериев хорошей цели.
Данный метод позволяет сформулировать реалистичную и измеримую цель, определить сроки и необходимые ресурсы для ее достижения.
S – Specific (Конкретная)
Цель должна быть однозначной. Разные люди, читая её, должны понимать одно и то же.
❌ Плохо: Привлечь пользователей.
✅ Хорошо: Привлечь пользователей из запретграма.
M – Measurable (Измеримая)
Нужно понять, как мы узнаем, что достигли цели. В числах или чётких критериях.
❌ Плохо: Привлечь пользователей из запретграма.
✅ Хорошо: Привлечь 1000 пользователей из запретграма.
A – Achievable (Достижимая)
Цель должна быть реалистичной, но амбициозной. Опирайтесь на прошлый опыт и ресурсы.
❌ Плохо: Привлечь 1 млн пользователей из запретграма за месяц (если сейчас 100).
✅ Хорошо: Увеличить прирост подписчиков на 20% за квартал (если в прошлом было +10%).
R – Relevant (Значимая)
Цель должна вести к стратегии компании, быть важной здесь и сейчас.
❌ Плохо: Улучшить дизайн кнопки «Поделиться», если основная цель – удержание.
✅ Хорошо: Увеличить Retention на 5%, запустив цепочку приветственных писем.
T – Time bound (Ограниченная во времени)
У цели должен быть дедлайн, иначе она может выполняться вечно.
❌ Плохо: Привлечь 1000 пользователей из запретграма.
✅ Хорошо: Привлечь 1000 пользователей из запретграма до 30 ноября.
Собираем всё вместе
Вот так выглядит правильная SMART-цель из наших кирпичиков:
✅ Привлечь 1000 пользователей из запретграмма до 30 ноября, используя посевы в блогах.
ВАЖНО! Ошибочно делать цель недостижимой, завышая ожидания.
❌ Например: «За полгода увеличить продажи на 300%» при прошлом росте в 5%. Это демотивирует команду.
Или делать цель незначимой.
❌ Например: вкладывать бюджет в развитие поп-апов, когда вся стратегия компании завязана на чат-ботах.
Одна SMART-цель – один результат. В компании может быть несколько приоритетных направлений развития – формулируйте по одной цели для каждого направления.
Сегодня хочу кратко рассказать про хороший метод постановки цели..
А именно о S-M-A-R-T.
Слово-акроним, а за ним – 5 критериев хорошей цели.
Данный метод позволяет сформулировать реалистичную и измеримую цель, определить сроки и необходимые ресурсы для ее достижения.
S – Specific (Конкретная)
Цель должна быть однозначной. Разные люди, читая её, должны понимать одно и то же.
❌ Плохо: Привлечь пользователей.
✅ Хорошо: Привлечь пользователей из запретграма.
M – Measurable (Измеримая)
Нужно понять, как мы узнаем, что достигли цели. В числах или чётких критериях.
❌ Плохо: Привлечь пользователей из запретграма.
✅ Хорошо: Привлечь 1000 пользователей из запретграма.
A – Achievable (Достижимая)
Цель должна быть реалистичной, но амбициозной. Опирайтесь на прошлый опыт и ресурсы.
❌ Плохо: Привлечь 1 млн пользователей из запретграма за месяц (если сейчас 100).
✅ Хорошо: Увеличить прирост подписчиков на 20% за квартал (если в прошлом было +10%).
R – Relevant (Значимая)
Цель должна вести к стратегии компании, быть важной здесь и сейчас.
❌ Плохо: Улучшить дизайн кнопки «Поделиться», если основная цель – удержание.
✅ Хорошо: Увеличить Retention на 5%, запустив цепочку приветственных писем.
T – Time bound (Ограниченная во времени)
У цели должен быть дедлайн, иначе она может выполняться вечно.
❌ Плохо: Привлечь 1000 пользователей из запретграма.
✅ Хорошо: Привлечь 1000 пользователей из запретграма до 30 ноября.
Собираем всё вместе
Вот так выглядит правильная SMART-цель из наших кирпичиков:
✅ Привлечь 1000 пользователей из запретграмма до 30 ноября, используя посевы в блогах.
ВАЖНО! Ошибочно делать цель недостижимой, завышая ожидания.
❌ Например: «За полгода увеличить продажи на 300%» при прошлом росте в 5%. Это демотивирует команду.
Или делать цель незначимой.
❌ Например: вкладывать бюджет в развитие поп-апов, когда вся стратегия компании завязана на чат-ботах.
Одна SMART-цель – один результат. В компании может быть несколько приоритетных направлений развития – формулируйте по одной цели для каждого направления.
🔥6✍2👾2🤯1
Всех с добрым пятничным утром! Сегодня предлагаю немного поразмышлять вместе на тему..
«Нечестное» преимущество для нашего продукта
Помните, мы заполняли Lean Canvas? Там есть один блок, о котором и пойдёт речь. Это Unfair Advantage – нечестное, скрытое, неконкурентное, несправедливое преимущество.
Unfair Advantage – это уникальное качество продукта или бизнеса, которое конкуренты не могут быстро или дешево скопировать. В контексте создания продукта оно закладывается на ранних этапах, чтобы обеспечить долгосрочный успех на рынке.
В отличии от справедливого преимущества, которое конкуренты могут относительно легко имитировать или воспроизводить, несправедливое преимущество сложнее получить, и оно даёт долгосрочные стратегические выгоды.
• Технологии, которые нельзя повторить «на коленке».
• Данные, которые копятся годами.
• Связи, которые не купить за деньги.
• Репутация, которая строится долго.
Примеры из нашей реальности, чтобы было понятно:
• Яндекс: Не сам поиск (технологии копируются), а экосистема и big data от миллионов запросов и перемещений по навигатору. Это будут копировать годами.
• Wildberries/Ozon: Не сайт, а масштаб логистики и цепочки поставок. Новичку нужны миллиарды, чтобы просто приблизиться.
• Росатом: Тут вообще без вариантов – технологии и регуляторные барьеры.
Как нам найти такое преимущество для нашего продукта?
Допустим, мы делаем гипотетический сервис доставки фермерских продуктов в Москве. Ищем наше «нечестное» оружие.
1. Копаем инсайты о клиентах. Не просто «любят фермерское», а реальные данные и боли.
Пример: Мы провели 30 интервью и выяснили, что главная боль – не цена и не ассортимент, а страх нарваться на некачественную продукцию. Люди готовы переплачивать, если 100% уверены, что продукты действительно экологически чистые от фермеров.
Наш вывод: Преимущество не в удобстве доставки, а в доказанном доверии к поставщику.
2. Оцениваем наши ресурсы (экспертиза, связи, данные). Что у нас есть такого, чего нет у других?
Пример: У нас в команде есть человек, который 10 лет проработал в Россельхознадзоре и знает всех честных фермеров в Тверской области лично. А ещё у нас есть знакомый в «Пятёрочке», который готов отдать неиспользуемые полки в пилотном режиме.
Наш вывод: Это не просто «связи», это эксклюзивный доступ к поставщикам и каналам сбыта. Скопировать такие связи быстро – нельзя.
3. Смотрим на барьеры для конкурентов. Что заставит их потратить годы или миллиарды?
Пример: Допустим, мы договариваемся с сетью локальных кафе о том, что они становятся пунктами выдачи наших заказов. Люди забирают фермерские продукты по пути с работы, а кафе получает дополнительный трафик и процент.
Наш вывод: Сеть партнёрских точек выдачи + первые договорённости – это барьер на годы.
‼️ Самая частая ошибка – писать в Unfair Advantage просто «у нас AI» или «у нас мобильное приложение». Конкуренты это скопируют за месяцы, а то и быстрее.
Проверочный вопрос: «Если завтра в этот рынок зайдет Сбер (или Магнит) с их ресурсами, смогут ли они нас обогнать за полгода?»
Если да, у нас нет нечестного преимущества.
Если нет, потому что у них нет нашей сети фермеров и доверия, которое мы строили 3 года – мы на верном пути.
Если что, все приведенные примеры – это всего лишь моя фантазия.😁
#UnfairAdvantage #LeanCanvas #Стратегия #Продукт #Стартап #Пятница
«Нечестное» преимущество для нашего продукта
Помните, мы заполняли Lean Canvas? Там есть один блок, о котором и пойдёт речь. Это Unfair Advantage – нечестное, скрытое, неконкурентное, несправедливое преимущество.
Unfair Advantage – это уникальное качество продукта или бизнеса, которое конкуренты не могут быстро или дешево скопировать. В контексте создания продукта оно закладывается на ранних этапах, чтобы обеспечить долгосрочный успех на рынке.
В отличии от справедливого преимущества, которое конкуренты могут относительно легко имитировать или воспроизводить, несправедливое преимущество сложнее получить, и оно даёт долгосрочные стратегические выгоды.
• Технологии, которые нельзя повторить «на коленке».
• Данные, которые копятся годами.
• Связи, которые не купить за деньги.
• Репутация, которая строится долго.
Примеры из нашей реальности, чтобы было понятно:
• Яндекс: Не сам поиск (технологии копируются), а экосистема и big data от миллионов запросов и перемещений по навигатору. Это будут копировать годами.
• Wildberries/Ozon: Не сайт, а масштаб логистики и цепочки поставок. Новичку нужны миллиарды, чтобы просто приблизиться.
• Росатом: Тут вообще без вариантов – технологии и регуляторные барьеры.
Как нам найти такое преимущество для нашего продукта?
Допустим, мы делаем гипотетический сервис доставки фермерских продуктов в Москве. Ищем наше «нечестное» оружие.
1. Копаем инсайты о клиентах. Не просто «любят фермерское», а реальные данные и боли.
Пример: Мы провели 30 интервью и выяснили, что главная боль – не цена и не ассортимент, а страх нарваться на некачественную продукцию. Люди готовы переплачивать, если 100% уверены, что продукты действительно экологически чистые от фермеров.
Наш вывод: Преимущество не в удобстве доставки, а в доказанном доверии к поставщику.
2. Оцениваем наши ресурсы (экспертиза, связи, данные). Что у нас есть такого, чего нет у других?
Пример: У нас в команде есть человек, который 10 лет проработал в Россельхознадзоре и знает всех честных фермеров в Тверской области лично. А ещё у нас есть знакомый в «Пятёрочке», который готов отдать неиспользуемые полки в пилотном режиме.
Наш вывод: Это не просто «связи», это эксклюзивный доступ к поставщикам и каналам сбыта. Скопировать такие связи быстро – нельзя.
3. Смотрим на барьеры для конкурентов. Что заставит их потратить годы или миллиарды?
Пример: Допустим, мы договариваемся с сетью локальных кафе о том, что они становятся пунктами выдачи наших заказов. Люди забирают фермерские продукты по пути с работы, а кафе получает дополнительный трафик и процент.
Наш вывод: Сеть партнёрских точек выдачи + первые договорённости – это барьер на годы.
‼️ Самая частая ошибка – писать в Unfair Advantage просто «у нас AI» или «у нас мобильное приложение». Конкуренты это скопируют за месяцы, а то и быстрее.
Проверочный вопрос: «Если завтра в этот рынок зайдет Сбер (или Магнит) с их ресурсами, смогут ли они нас обогнать за полгода?»
Если да, у нас нет нечестного преимущества.
Если нет, потому что у них нет нашей сети фермеров и доверия, которое мы строили 3 года – мы на верном пути.
Если что, все приведенные примеры – это всего лишь моя фантазия.😁
#UnfairAdvantage #LeanCanvas #Стратегия #Продукт #Стартап #Пятница
🔥5👨💻2✍1
Весна пришла! Поздравляю всех с первым днём весны!
Кажется, только вчера мы лепили снеговиков и строили снежные башни, а сегодня уже слышно пение птиц. Зима в этом году выдалась настоящей, снежной и весёлой. Снежки, горки, сугробы по колено... Было круто! Жаль, что так быстро пролетела.
На прошедшей неделе мы с сыном наконец-то собрали кормушку для птиц. Знаю, немного запоздали, но как говорится: «Лучше поздно, чем никогда». Теперь пернатые друзья сыты. 😁
Как же все таки быстро летит время, чем старше ты становишься, тем быстрей.
Всем тёплого и радостного марта! Пусть весна ворвётся в жизнь яркими красками.
#весна #отдых #напоминание #осебе
Кажется, только вчера мы лепили снеговиков и строили снежные башни, а сегодня уже слышно пение птиц. Зима в этом году выдалась настоящей, снежной и весёлой. Снежки, горки, сугробы по колено... Было круто! Жаль, что так быстро пролетела.
На прошедшей неделе мы с сыном наконец-то собрали кормушку для птиц. Знаю, немного запоздали, но как говорится: «Лучше поздно, чем никогда». Теперь пернатые друзья сыты. 😁
Как же все таки быстро летит время, чем старше ты становишься, тем быстрей.
Всем тёплого и радостного марта! Пусть весна ворвётся в жизнь яркими красками.
#весна #отдых #напоминание #осебе
🔥8🤓1👻1
Когда MVP перестаёт быть MVP и становится продуктом?
Тут говорили про MVP.
Но возникает вопрос: а где та грань переход от MVP к настоящему продукту?
Сегодня будем размышлять об этом.
Характерные отличия:
MVP – это чаще всего ручные продажи и кастомизация под каждого клиента. Мы сами звоним, сами обсуждаем, сами дорабатываем под конкретного заказчика.
Продукт – это коробочное решение, которое можно отгружать с минимальной кастомизацией или вообще без неё. Чем меньше ручного труда, тем ближе мы к продукту.
Когда наступает момент перехода?
Не тогда, когда «захотелось», и не тогда, когда «инвестор сказал». А тогда, когда ручные операции становятся узким местом.
Представьте:
Сервис по подбору авто для маркетплейса.
Пользователь оставляет заявку → мы перезваниваем → согласовываем → записываем на установку. Всё руками.
Пока клиентов 10 – ок.
Стало 100 – уже нужен отдельный оператор.
Стало 1000 – целый колл-центр, CRM, обучение, контроль качества.
Выручка растёт, но затраты растут с той же скоростью. А в какой-то момент начинают даже обгонять.
Вот тут и наступает момент: пора автоматизировать. Превращать ручной процесс в продуктовый.
Главный принцип Lean-подхода:
Мы не делаем продукт целиком и сразу. Мы поэтапно автоматизируем только те части, которые стали узким местом. Шаг за шагом, итерация за итерацией.
📦 Кейс «Битрикс».
Много лет назад Сергей Рыжиков (основатель «1С-Битрикс») делал сайты на заказ. Сделал один, второй, третий.. И каждый раз с нуля.
В какой-то момент он понял: я каждый раз делаю одно и то же. База данных, админка, управление контентом – это же можно вынести в отдельную систему и не переписывать каждый раз.
Так родилась CMS. Сначала как внутренний инструмент, чтобы ускорить разработку своих же сайтов.
Потом он пошёл к другим студиям и сказал:
Зачем вы каждый раз пишете сайт с нуля? Берите мою систему, экономьте время, а я буду её развивать.
Студии начали покупать. Выручка пошла, но появилось новое узкое место: поддержка тысяч партнёров. Со всеми вручную не пообщаешься.
Тогда пришлось создавать методологию, обучение, сертификацию, рейтинг партнёров. Целую экосистему, которая работает без прямого участия команды.
Продукт вырос не по плану, а как реакция на ограничения, которые мешали расти дальше.
Какие мы можем сделать выводы?
❗️ Переход от MVP к продукту – это не момент, а процесс. Мы идём маленькими шагами и на каждом шагу автоматизируете только то, что стало тормозом.
❗️ Главный враг масштабирования – ручной труд. Как только он начнёт расти линейно вместе с выручкой – нужно искать, что можно автоматизировать.
❗️ Не делать «красиво», если это не решает реальную боль. Спрашивать себя: «А что будет, если я это НЕ сделаю?» Если ничего страшного – не делаем.
❗️ Концепция Lean-подхода:
Маленькие шаги → быстрая обратная связь → следующий шаг. Чем быстрее шаги, тем быстрее рост.
P.S. Каждый раз, когда нам кажется, что надо что-то улучшить, добавить, запрограммировать – останавливаемся. И задаёмся вопросами: станет ли от этого лучше бизнесу? Или это просто «хочется красивенько»?
#MVP #Продукт #Lean #Масштабирование #Битрикс #Кейсы #Стартап
Тут говорили про MVP.
Но возникает вопрос: а где та грань переход от MVP к настоящему продукту?
Сегодня будем размышлять об этом.
Характерные отличия:
MVP – это чаще всего ручные продажи и кастомизация под каждого клиента. Мы сами звоним, сами обсуждаем, сами дорабатываем под конкретного заказчика.
Продукт – это коробочное решение, которое можно отгружать с минимальной кастомизацией или вообще без неё. Чем меньше ручного труда, тем ближе мы к продукту.
Когда наступает момент перехода?
Не тогда, когда «захотелось», и не тогда, когда «инвестор сказал». А тогда, когда ручные операции становятся узким местом.
Представьте:
Сервис по подбору авто для маркетплейса.
Пользователь оставляет заявку → мы перезваниваем → согласовываем → записываем на установку. Всё руками.
Пока клиентов 10 – ок.
Стало 100 – уже нужен отдельный оператор.
Стало 1000 – целый колл-центр, CRM, обучение, контроль качества.
Выручка растёт, но затраты растут с той же скоростью. А в какой-то момент начинают даже обгонять.
Вот тут и наступает момент: пора автоматизировать. Превращать ручной процесс в продуктовый.
Главный принцип Lean-подхода:
Мы не делаем продукт целиком и сразу. Мы поэтапно автоматизируем только те части, которые стали узким местом. Шаг за шагом, итерация за итерацией.
📦 Кейс «Битрикс».
Много лет назад Сергей Рыжиков (основатель «1С-Битрикс») делал сайты на заказ. Сделал один, второй, третий.. И каждый раз с нуля.
В какой-то момент он понял: я каждый раз делаю одно и то же. База данных, админка, управление контентом – это же можно вынести в отдельную систему и не переписывать каждый раз.
Так родилась CMS. Сначала как внутренний инструмент, чтобы ускорить разработку своих же сайтов.
Потом он пошёл к другим студиям и сказал:
Зачем вы каждый раз пишете сайт с нуля? Берите мою систему, экономьте время, а я буду её развивать.
Студии начали покупать. Выручка пошла, но появилось новое узкое место: поддержка тысяч партнёров. Со всеми вручную не пообщаешься.
Тогда пришлось создавать методологию, обучение, сертификацию, рейтинг партнёров. Целую экосистему, которая работает без прямого участия команды.
Продукт вырос не по плану, а как реакция на ограничения, которые мешали расти дальше.
Какие мы можем сделать выводы?
❗️ Переход от MVP к продукту – это не момент, а процесс. Мы идём маленькими шагами и на каждом шагу автоматизируете только то, что стало тормозом.
❗️ Главный враг масштабирования – ручной труд. Как только он начнёт расти линейно вместе с выручкой – нужно искать, что можно автоматизировать.
❗️ Не делать «красиво», если это не решает реальную боль. Спрашивать себя: «А что будет, если я это НЕ сделаю?» Если ничего страшного – не делаем.
❗️ Концепция Lean-подхода:
Маленькие шаги → быстрая обратная связь → следующий шаг. Чем быстрее шаги, тем быстрее рост.
P.S. Каждый раз, когда нам кажется, что надо что-то улучшить, добавить, запрограммировать – останавливаемся. И задаёмся вопросами: станет ли от этого лучше бизнесу? Или это просто «хочется красивенько»?
#MVP #Продукт #Lean #Масштабирование #Битрикс #Кейсы #Стартап
🔥6👻1🗿1
У вас есть гениальная идея.. Инвесторы горят, команда в экстазе, вы уже видите себя на обложке Forbes. Но есть вопросики..
А технически это реализуемо? Сможем ли мы это сделать?
Для ответа на этот вопрос существует POC – Proof of Concept (доказательство концепции).
Что такое POC простыми словами?
Это не прототип и не MVP. Это техническая проверка:
• Будет ли алгоритм распознавать лица в полумраке?
• Потянет ли сервер 10 000 одновременных запросов?
• Синхронизируется ли наше приложение с 20-летней ERP-системой?
Компании, которые проводят POC перед масштабной разработкой, снижают риски провала проекта на 60%. А стоит такой эксперимент всего 5–10% от бюджета всего проекта.
Например,
🏦 Банк хочет внедрить биометрию
POC: Проверить, работает ли распознавание лиц в плохо освещённых банкоматах и на камерах низкого разрешения.
Прототип: Нарисовать в Figma экраны, как пользователь будет моргать и поворачивать голову.
MVP: Запустить вход по лицу для 100 сотрудников и померить, ускорил ли он процесс.
или
🚚 Логистическая компания
POC: Проверить, может ли наша нейросеть читать накладные, написанные от руки, с точностью 95%.
Прототип: Показать дизайн интерфейса для курьеров.
MVP: Запустить систему на одном складе и посмотреть, сократилось ли время обработки.
Какие же различия POC vs Прототип vs MVP?
POC:
Цель – Доказать, что можно сделать
Вопрос – Можем ли?
Результат – Знание, часто throwaway-код
Прототип:
Цель – Показать, как будет выглядеть
Вопрос – Как будет?
Результат – Кликабельные макеты
MVP:
Цель – Проверить, нужно ли это людям
Вопрос – Купят ли?
Результат – Работающий продукт с метриками
Без любого из этих элементов это не POC, а бессмысленное баловство. 😁
❗️ Плохой POC: «Давайте попробуем нейросеть, вдруг взлетит».
❗️ Хороший POC: «Проверим, сможет ли нейросеть распознавать бракованные детали на конвейере АвтоВАЗа с точностью не ниже 95% за 2 недели».
Когда POC жизненно необходим..
1. Новая или непроверенная технология
Пример: Вы хотите использовать LLM (большую языковую модель) для автоматизации поддержки в Т-Банке. До начала разработки надо проверить: не будет ли нейросеть галлюцинировать на финансовых вопросах?
2. Сложная интеграция с legacy
Пример: Вам нужно интегрировать новое мобильное приложение с ERP «1С» 15-летней давности. Документация потеряна, архитектор уволился. POC покажет, реально ли это вообще или проще переписать полсистемы.
3. Критичные требования к производительности
Пример: Вы запускаете онлайн-кинотеатр (ну, допустим, новый Okko) и обещаете 4K без буферизации. POC нагрузит сервер и покажет, не ляжет ли он под 100 000 зрителей во время премьеры.
4. Регуляторные или инфраструктурные ограничения
Пример: Вы делаете fintech-продукт и должны передавать данные в ЦБ. POC проверит, совместимы ли ваши форматы с их системами, до того как юристы подпишут договоры.
Подведем итог..
✅ POC – это про технику, а не про бизнес. Не спрашивайте у POC, купят ли продукт. Это вопрос к MVP.
✅ POC должен быть быстрым. 2–4 недели – норма. Если дольше – вы проверяете слишком много или гипотеза сформулирована размыто.
✅ Код POC часто идёт в мусорку. И это ок. Вы получили главное – знание, что технология работает (или не работает).
✅ Стоимость POC (5–10% от бюджета) – это дешёвая страховка от катастрофы. Лучше потерять эти деньги сейчас, чем миллионы через год, когда выяснится, что ваша гениальная идея технически нереализуема.
#POC #ProofOfConcept #MVP #Прототип #Разработка #Стартап #Технологии
А технически это реализуемо? Сможем ли мы это сделать?
Для ответа на этот вопрос существует POC – Proof of Concept (доказательство концепции).
Что такое POC простыми словами?
Это не прототип и не MVP. Это техническая проверка:
• Будет ли алгоритм распознавать лица в полумраке?
• Потянет ли сервер 10 000 одновременных запросов?
• Синхронизируется ли наше приложение с 20-летней ERP-системой?
Компании, которые проводят POC перед масштабной разработкой, снижают риски провала проекта на 60%. А стоит такой эксперимент всего 5–10% от бюджета всего проекта.
Например,
🏦 Банк хочет внедрить биометрию
POC: Проверить, работает ли распознавание лиц в плохо освещённых банкоматах и на камерах низкого разрешения.
Прототип: Нарисовать в Figma экраны, как пользователь будет моргать и поворачивать голову.
MVP: Запустить вход по лицу для 100 сотрудников и померить, ускорил ли он процесс.
или
🚚 Логистическая компания
POC: Проверить, может ли наша нейросеть читать накладные, написанные от руки, с точностью 95%.
Прототип: Показать дизайн интерфейса для курьеров.
MVP: Запустить систему на одном складе и посмотреть, сократилось ли время обработки.
Какие же различия POC vs Прототип vs MVP?
POC:
Цель – Доказать, что можно сделать
Вопрос – Можем ли?
Результат – Знание, часто throwaway-код
Прототип:
Цель – Показать, как будет выглядеть
Вопрос – Как будет?
Результат – Кликабельные макеты
MVP:
Цель – Проверить, нужно ли это людям
Вопрос – Купят ли?
Результат – Работающий продукт с метриками
POC = Конкретная техническая гипотеза + Минимальная реализация + Чёткие критерии успеха
Без любого из этих элементов это не POC, а бессмысленное баловство. 😁
❗️ Плохой POC: «Давайте попробуем нейросеть, вдруг взлетит».
❗️ Хороший POC: «Проверим, сможет ли нейросеть распознавать бракованные детали на конвейере АвтоВАЗа с точностью не ниже 95% за 2 недели».
Когда POC жизненно необходим..
1. Новая или непроверенная технология
Пример: Вы хотите использовать LLM (большую языковую модель) для автоматизации поддержки в Т-Банке. До начала разработки надо проверить: не будет ли нейросеть галлюцинировать на финансовых вопросах?
2. Сложная интеграция с legacy
Пример: Вам нужно интегрировать новое мобильное приложение с ERP «1С» 15-летней давности. Документация потеряна, архитектор уволился. POC покажет, реально ли это вообще или проще переписать полсистемы.
3. Критичные требования к производительности
Пример: Вы запускаете онлайн-кинотеатр (ну, допустим, новый Okko) и обещаете 4K без буферизации. POC нагрузит сервер и покажет, не ляжет ли он под 100 000 зрителей во время премьеры.
4. Регуляторные или инфраструктурные ограничения
Пример: Вы делаете fintech-продукт и должны передавать данные в ЦБ. POC проверит, совместимы ли ваши форматы с их системами, до того как юристы подпишут договоры.
Подведем итог..
✅ POC – это про технику, а не про бизнес. Не спрашивайте у POC, купят ли продукт. Это вопрос к MVP.
✅ POC должен быть быстрым. 2–4 недели – норма. Если дольше – вы проверяете слишком много или гипотеза сформулирована размыто.
✅ Код POC часто идёт в мусорку. И это ок. Вы получили главное – знание, что технология работает (или не работает).
✅ Стоимость POC (5–10% от бюджета) – это дешёвая страховка от катастрофы. Лучше потерять эти деньги сейчас, чем миллионы через год, когда выяснится, что ваша гениальная идея технически нереализуема.
#POC #ProofOfConcept #MVP #Прототип #Разработка #Стартап #Технологии
🔥6✍1💯1👻1
MLP.. Я не о мультсериале «Май Литл Пони», а о минимально привлекательном продукте (Minimum Lovable Product).
Про PoC рассказал..
Про MVP рассказал..
Следующий уровень у нас идет, как раз таки MLP..
Это не просто проверка «работает», а «работает так, что хочется вернуться, рассказать другу и заплатить ещё».
В чём разница между MVP vs MLP?
MVP:
• Проверить гипотезу
• Сделать, чтобы работало
• Фокус на функциях
• Ранние последователи простят косяки
MLP:
• Вызвать эмоцию
• Сделать, чтобы хотелось
• Фокус на опыте (UX)
• Новичкам должно быть приятно
Например,
📦 Доставка еды
MVP: Сайт, где можно выбрать блюдо и оформить заказ. Кнопка есть, дальше по телефону уточняют адрес.
MLP: Трекер заказа в реальном времени, фото блюда в заказе, история предыдущих доставок, кнопка «повторить» в один клик.
🚖 Такси
MVP: Подача машины, расчёт по счётчику.
MLP: Видимость машины на карте, фиксированная цена до поездки, оценка водителя, музыка в приложении, приветственный напиток.
📱 Банк
MVP: Переводы по номеру карты, баланс, выписка.
MLP: Перевод по фото контакта, умные уведомления («вы получили зарплату, хотите отложить 10%?»), приятный дизайн, быстрая поддержка в чате.
Зачем вообще заморачиваться с MLP?
Потому что конкуренция уже не на уровне функций. Если ваш продукт просто «работает», то это базовый входной билет. Чтобы оторваться от толпы, нужно, чтобы пользователь испытал эмоцию.
❕ Эмоция = запоминание.
❕ Запоминание = возврат.
❕ Возврат = деньги.
Сначала мы делаем MVP, чтобы убедиться, что идея вообще нужна.
Потом, собрав обратную связь, превращаем его в MLP, добавляя те самые мелочи, за которые продукт полюбят.
Можно сколько угодно полировать иконки и анимации, но если проблему не решаете, то MLP не спасёт.
#MVP #MLP #UX #Продукт #Стартап #Пользователи
Про PoC рассказал..
Про MVP рассказал..
Следующий уровень у нас идет, как раз таки MLP..
Это не просто проверка «работает», а «работает так, что хочется вернуться, рассказать другу и заплатить ещё».
В чём разница между MVP vs MLP?
MVP:
• Проверить гипотезу
• Сделать, чтобы работало
• Фокус на функциях
• Ранние последователи простят косяки
MLP:
• Вызвать эмоцию
• Сделать, чтобы хотелось
• Фокус на опыте (UX)
• Новичкам должно быть приятно
Например,
📦 Доставка еды
MVP: Сайт, где можно выбрать блюдо и оформить заказ. Кнопка есть, дальше по телефону уточняют адрес.
MLP: Трекер заказа в реальном времени, фото блюда в заказе, история предыдущих доставок, кнопка «повторить» в один клик.
🚖 Такси
MVP: Подача машины, расчёт по счётчику.
MLP: Видимость машины на карте, фиксированная цена до поездки, оценка водителя, музыка в приложении, приветственный напиток.
📱 Банк
MVP: Переводы по номеру карты, баланс, выписка.
MLP: Перевод по фото контакта, умные уведомления («вы получили зарплату, хотите отложить 10%?»), приятный дизайн, быстрая поддержка в чате.
Зачем вообще заморачиваться с MLP?
Потому что конкуренция уже не на уровне функций. Если ваш продукт просто «работает», то это базовый входной билет. Чтобы оторваться от толпы, нужно, чтобы пользователь испытал эмоцию.
❕ Эмоция = запоминание.
❕ Запоминание = возврат.
❕ Возврат = деньги.
Сначала мы делаем MVP, чтобы убедиться, что идея вообще нужна.
Потом, собрав обратную связь, превращаем его в MLP, добавляя те самые мелочи, за которые продукт полюбят.
Можно сколько угодно полировать иконки и анимации, но если проблему не решаете, то MLP не спасёт.
#MVP #MLP #UX #Продукт #Стартап #Пользователи
🔥5
💐 Дорогие девушки, женщины! 💐
На удивление Вас у меня на канале почти половина.
✨ Спасибо вам за то, что вы есть. За вашу красоту, мудрость, силу и нежность. За то, что вы умеете быть разными и вдохновляете нас на всё самое лучшее.
8 марта – лишь один день в календаре. По-хорошему, благодарить и восхищаться вами хочется постоянно. Но раз человечество решило особенно громко вспоминать об этом именно 8 марта (хотя этого явно мало и недостаточно), то хочу поздравить вас с этим прекрасным праздником!
💐 Спасибо вам, что вы есть!💐
На удивление Вас у меня на канале почти половина.
✨ Спасибо вам за то, что вы есть. За вашу красоту, мудрость, силу и нежность. За то, что вы умеете быть разными и вдохновляете нас на всё самое лучшее.
8 марта – лишь один день в календаре. По-хорошему, благодарить и восхищаться вами хочется постоянно. Но раз человечество решило особенно громко вспоминать об этом именно 8 марта (хотя этого явно мало и недостаточно), то хочу поздравить вас с этим прекрасным праздником!
💐 Спасибо вам, что вы есть!💐
🔥5💯1👻1
Надеюсь, все провели замечательно эти долгие праздничные выходные..
А сегодня давайте про CJM (Customer Journey Map). По простому «весь опыт» пользователя, включая его эмоции, даже за пределами нашего сайта или приложения.
Что такое CJM?
Это модель, которая в деталях показывает пользовательский опыт: как человек приходит к продукту, как взаимодействует с ним со временем, где находятся основные точки контакта. Визуализация, которая помогает нам понять, что вообще происходит и что чувствуют наши пользователи.
На CJM можно смотреть с разных сторон..
Маркетинговый подход – про взаимодействие с брендом в целом. У человека возникла потребность, он искал, нашёл нас, зашёл, активно использовал, удовлетворил потребность и дальше продолжил взаимодействие (или не продолжил).
UX-подход – про локальное взаимодействие внутри продукта. Это часть маркетингового подхода, но наша зона ответственности тут ограничена, например, сайтом или приложением. Что человек делает именно здесь?
Для чего нам это вообще? Для того, чтобы..
• Разбирать путь в деталях. Можно сколько угодно думать, что «мы и так всё знаем», но когда начинаешь строить карту – вылезают инсайты, которых не ждал.
• Находить точки контакта. Где именно мы пересекаемся с пользователем и как можем на это повлиять?
• Искать проблемы и сложности. Где человек спотыкается, раздражается, уходит?
• Искать решения. Как сделать жизнь людей проще? Как упростить переход в наш продукт?
Последние два пункта – самая суть. Ради них всё и затевается.
❗️ Важный момент..
Идеального CJM не существует. Каждый строит как может, как хочет, как умеет. Шаблонов в интернете полно, но это не значит, что надо тупо их копировать. Не стоит делать CJM, потому что «так надо». К сожалению, многие построенные карты не приносят никакой пользы из-за того, что их делали для галочки.
Продукт < Проблема > Пользователь
Каждый этап пути мы раскладываем на каналы: онлайн, офлайн или смешанные. И важно фиксировать не только где это происходит, но и:
• Потребность. Что человек хочет сделать?
• Действие. Что он реально делает?
• Проблемы. Где болит?
• Решения. Что с этим делать?
Где брать информацию для CJM?
Карту можно строить даже когда продукта ещё нет.
• Веб/апп-аналитика (самый точный, если уже есть данные)
• Интервью с пользователями
• Исследования (свои или чужие)
• Экспертность команды
Как структурировать интервью под CJM:
• Одинаковые или похожие сценарии объединяем
• Отклонения проверяем или отбрасываем
• Если вырисовываются несколько разных групп пользователей (делаем отдельные CJM для каждой)
• Учитываем платформы (моб, десктоп, офлайн)
• По возможности подтверждаем данными
Цель пользователя → Сегмент → Цикл проверки гипотез (Потребность → Проблема → Решение → Тест)
Какие ошибки чаще всего встречаются?
❌ Не используют реальные данные (строят «из головы»)
❌ Вообще не используют никакие данные, даже гипотезы
❌ Подменяют потребности пользователя функциональностью продукта
Пример: Пользователь ищет удобное кресло, и соответственно нам нужно делать поиск по параметрам, а не, например, поиск по названию кресла.
И последнее, но важное..
CJM нужно обновлять после каждого крупного релиза и вообще периодически. И вообще, на данный инструмент можно опираться при расчётах юнит-экономики, при разборе аналитики, при проектировании интерфейсов.. да вообще постоянно.
Я в дипломе использовал вот этот.
#CJM #CustomerJourneyMap #UX #Продукт #Исследования #ПользовательскийОпыт
А сегодня давайте про CJM (Customer Journey Map). По простому «весь опыт» пользователя, включая его эмоции, даже за пределами нашего сайта или приложения.
Что такое CJM?
Это модель, которая в деталях показывает пользовательский опыт: как человек приходит к продукту, как взаимодействует с ним со временем, где находятся основные точки контакта. Визуализация, которая помогает нам понять, что вообще происходит и что чувствуют наши пользователи.
На CJM можно смотреть с разных сторон..
Маркетинговый подход – про взаимодействие с брендом в целом. У человека возникла потребность, он искал, нашёл нас, зашёл, активно использовал, удовлетворил потребность и дальше продолжил взаимодействие (или не продолжил).
UX-подход – про локальное взаимодействие внутри продукта. Это часть маркетингового подхода, но наша зона ответственности тут ограничена, например, сайтом или приложением. Что человек делает именно здесь?
Для чего нам это вообще? Для того, чтобы..
• Разбирать путь в деталях. Можно сколько угодно думать, что «мы и так всё знаем», но когда начинаешь строить карту – вылезают инсайты, которых не ждал.
• Находить точки контакта. Где именно мы пересекаемся с пользователем и как можем на это повлиять?
• Искать проблемы и сложности. Где человек спотыкается, раздражается, уходит?
• Искать решения. Как сделать жизнь людей проще? Как упростить переход в наш продукт?
Последние два пункта – самая суть. Ради них всё и затевается.
❗️ Важный момент..
Идеального CJM не существует. Каждый строит как может, как хочет, как умеет. Шаблонов в интернете полно, но это не значит, что надо тупо их копировать. Не стоит делать CJM, потому что «так надо». К сожалению, многие построенные карты не приносят никакой пользы из-за того, что их делали для галочки.
Продукт < Проблема > Пользователь
Каждый этап пути мы раскладываем на каналы: онлайн, офлайн или смешанные. И важно фиксировать не только где это происходит, но и:
• Потребность. Что человек хочет сделать?
• Действие. Что он реально делает?
• Проблемы. Где болит?
• Решения. Что с этим делать?
Пример из жизни
Помните Икею? У них была проблема: люди сомневались в качестве недорогой мебели. Их решением было поставить в магазине стенд пресса и кресла со счётчиком количества нажатий. Каждый посетитель, заходящий в магазин видел цифры: сколько килограммов и какое количество раз выдерживает кресло. Просто, наглядно, без слов. Это и есть работа с точкой контакта.
Где брать информацию для CJM?
Карту можно строить даже когда продукта ещё нет.
• Веб/апп-аналитика (самый точный, если уже есть данные)
• Интервью с пользователями
• Исследования (свои или чужие)
• Экспертность команды
Как структурировать интервью под CJM:
• Одинаковые или похожие сценарии объединяем
• Отклонения проверяем или отбрасываем
• Если вырисовываются несколько разных групп пользователей (делаем отдельные CJM для каждой)
• Учитываем платформы (моб, десктоп, офлайн)
• По возможности подтверждаем данными
Цель пользователя → Сегмент → Цикл проверки гипотез (Потребность → Проблема → Решение → Тест)
Какие ошибки чаще всего встречаются?
❌ Не используют реальные данные (строят «из головы»)
❌ Вообще не используют никакие данные, даже гипотезы
❌ Подменяют потребности пользователя функциональностью продукта
Пример: Пользователь ищет удобное кресло, и соответственно нам нужно делать поиск по параметрам, а не, например, поиск по названию кресла.
И последнее, но важное..
CJM нужно обновлять после каждого крупного релиза и вообще периодически. И вообще, на данный инструмент можно опираться при расчётах юнит-экономики, при разборе аналитики, при проектировании интерфейсов.. да вообще постоянно.
Я в дипломе использовал вот этот.
#CJM #CustomerJourneyMap #UX #Продукт #Исследования #ПользовательскийОпыт
🔥5
Use Case.. Когда одной истории мало..
Мы уже разобрали CJM.. Посмотрели на путь пользователя целиком. Но в жизни бывают ситуации, когда панорамного взгляда недостаточно. Когда логика ветвится, появляются «а что, если..» и «а вдруг..».
В этом как раз и поможет разобраться Use Case (сценарий использования).
Что это такое простыми словами?
Это детальное описание того, как пользователь взаимодействует с системой для достижения конкретной цели.
Если в CJM нам нужно понять, кто пользователь, какой путь он проходит и где у него возникают проблемы.
То Use Case описывает конкретное взаимодействие пользователя с системой для достижения цели. Это уже не эмоции (как в CJM), а четкая логика: «Если пользователь нажал Х, система делает Y».
Давайте на примере доставки еды..
Структура будет выглядеть примерно так:
Название: Отменить заказ после оплаты
Акторы: Пользователь
Предусловия: Заказ оплачен, но ещё не передан в доставку
Постусловие: Деньги возвращены, заказ отменён
Основной поток:
1. Пользователь заходит в раздел «Мои заказы».
2. Система показывает список активных заказов.
3. Пользователь выбирает нужный заказ и нажимает «Отменить».
4. Система запрашивает подтверждение.
5. Пользователь подтверждает отмену.
6. Система отправляет запрос в платёжную систему на возврат денег.
7. Система меняет статус заказа на «Отменён».
8. Система отправляет пользователю уведомление «Заказ отменён, деньги вернутся в течение 3 дней».
Альтернативный поток:
4а. Пользователь передумывает и отменяет отмену → возврат к списку заказов.
6а. Заказ уже передан в доставку (изменилось предусловие) → кнопка «Отменить» неактивна, вместо неё показывается контакт поддержки.
Исключения:
6б. Платёжная система не отвечает → система помечает заказ как требующий ручной обработки и отправляет уведомление оператору.
❗️ Use Case заставляет думать о том, что может пойти не так.
Где брать информацию для Use Case?
• Из аналитики. Где люди спотыкаются? На каких шагах уходят?
• Из интервью с пользователями. Как они реально делают? Какие у них сценарии? С какими проблемами сталкиваются?
• Из мозговых штурмов. Обсуждения «а что, если», разбор негативных сценариев.
• Из данных техподдержки. Частые вопросы и жалобы пользователей.
❗️ Если вы ловите себя на мысли «а вдруг пользователь сделает вот так, а что тогда?» Нужно разрабатывать Use Case.
Главное, что стоит вынести:
❗️ Use Case – это качественно проработанный сценарий, который позволяет выявить, всё ли мы учли.
❗️ Он не отменяет User Story и CJM, а работает вместе с ними.
#UseCase #СценарииИспользования #Продукт #Разработка #Аналитика #Продакт #ТЗ
Мы уже разобрали CJM.. Посмотрели на путь пользователя целиком. Но в жизни бывают ситуации, когда панорамного взгляда недостаточно. Когда логика ветвится, появляются «а что, если..» и «а вдруг..».
В этом как раз и поможет разобраться Use Case (сценарий использования).
Что это такое простыми словами?
Это детальное описание того, как пользователь взаимодействует с системой для достижения конкретной цели.
Если в CJM нам нужно понять, кто пользователь, какой путь он проходит и где у него возникают проблемы.
То Use Case описывает конкретное взаимодействие пользователя с системой для достижения цели. Это уже не эмоции (как в CJM), а четкая логика: «Если пользователь нажал Х, система делает Y».
Давайте на примере доставки еды..
Структура будет выглядеть примерно так:
Название: Отменить заказ после оплаты
Акторы: Пользователь
Предусловия: Заказ оплачен, но ещё не передан в доставку
Постусловие: Деньги возвращены, заказ отменён
Основной поток:
1. Пользователь заходит в раздел «Мои заказы».
2. Система показывает список активных заказов.
3. Пользователь выбирает нужный заказ и нажимает «Отменить».
4. Система запрашивает подтверждение.
5. Пользователь подтверждает отмену.
6. Система отправляет запрос в платёжную систему на возврат денег.
7. Система меняет статус заказа на «Отменён».
8. Система отправляет пользователю уведомление «Заказ отменён, деньги вернутся в течение 3 дней».
Альтернативный поток:
4а. Пользователь передумывает и отменяет отмену → возврат к списку заказов.
6а. Заказ уже передан в доставку (изменилось предусловие) → кнопка «Отменить» неактивна, вместо неё показывается контакт поддержки.
Исключения:
6б. Платёжная система не отвечает → система помечает заказ как требующий ручной обработки и отправляет уведомление оператору.
❗️ Use Case заставляет думать о том, что может пойти не так.
Где брать информацию для Use Case?
• Из аналитики. Где люди спотыкаются? На каких шагах уходят?
• Из интервью с пользователями. Как они реально делают? Какие у них сценарии? С какими проблемами сталкиваются?
• Из мозговых штурмов. Обсуждения «а что, если», разбор негативных сценариев.
• Из данных техподдержки. Частые вопросы и жалобы пользователей.
❗️ Если вы ловите себя на мысли «а вдруг пользователь сделает вот так, а что тогда?» Нужно разрабатывать Use Case.
Главное, что стоит вынести:
❗️ Use Case – это качественно проработанный сценарий, который позволяет выявить, всё ли мы учли.
❗️ Он не отменяет User Story и CJM, а работает вместе с ними.
#UseCase #СценарииИспользования #Продукт #Разработка #Аналитика #Продакт #ТЗ
🔥6
Всем привет! Вот и подходит к концу воскресенье.
Надеюсь, ваши выходные прошли супер (в отличие от меня 😅). Потрясающая погода за окном: солнце, тепло.. НО!
Мы всей семьёй свалились с какой-то странной болезнью. Ломота в костях, сопли и у меня напрочь заложило уши. Я теперь почти вакуумирован от внешнего мира 🤣
Зато благодаря этому удалось устроить киномарафон:
🗡️ «Гладиатор»
🗡️ «Троя»
🗡️ «Меч короля Артура»
Если смотрели – ставьте 🔥
Если не смотрели – очень рекомендую найти время, не пожалеете 🙏
Надеюсь, ваши выходные прошли супер (в отличие от меня 😅). Потрясающая погода за окном: солнце, тепло.. НО!
Мы всей семьёй свалились с какой-то странной болезнью. Ломота в костях, сопли и у меня напрочь заложило уши. Я теперь почти вакуумирован от внешнего мира 🤣
Зато благодаря этому удалось устроить киномарафон:
🗡️ «Гладиатор»
🗡️ «Троя»
🗡️ «Меч короля Артура»
Если смотрели – ставьте 🔥
Если не смотрели – очень рекомендую найти время, не пожалеете 🙏
🔥5✍2
User Story (пользовательские истории).. ещё один важный инструмент..
Мы разобрали CJM – посмотрели на путь пользователя целиком.
Разобрали Use Case – расписали детальные сценарии со всеми «а что, если».
User Story – это короткое описание функциональности с точки зрения пользователя. Не техническое задание, не список фич, а именно история работающая по шаблону:
Я как [роль] хочу [действие], чтобы [ценность].
Например:
• «Я как покупатель хочу видеть стоимость доставки до оформления заказа, чтобы понимать итоговую цену».
• «Я как водитель хочу получать уведомление о новой поездке на экране, чтобы не пропустить заказ, когда телефон в держателе».
User Story – это 1-2 предложения про ценность для планирования и приоритезации. Она отвечает на вопросы «что и зачем».
Зачем это вообще нужно?
• Фокус на пользователе. История заставляет каждый раз думать: а кому это надо? А зачем? А какая тут ценность?
• Единый язык. И разработчик, и тестировщик, и дизайнер, и бизнес понимают одно и то же. Нет пространства для трактовок «ну я имел в виду другое».
• Основа для обсуждения. User Story – это приглашение к диалогу. Команда может (и должна!) задавать вопросы, уточнять, предлагать.
• Планирование. Истории можно оценивать, приоритезировать, резать на спринты.
User Story ≠ Техническое задание
ТЗ обычно звучит как:
«Реализовать форму обратной связи с полями имя, email, сообщение и капчей».
User Story на ту же тему:
«Я как посетитель хочу отправить сообщение в поддержку прямо с сайта, чтобы быстро решить свою проблему, не открывая почту».
Хорошие User Story соответствуют критериям INVEST:
Independent (независимые). Историю можно реализовать отдельно от других.
Negotiable (обсуждаемые). Отражает суть, а не детали; не содержит конкретных шагов реализации.
Valuable (ценные). История должна приносить ценность пользователю или бизнесу.
Estimable (оцениваемые). Она должна быть оцениваемая по сложности и трудозатратам.
Small (маленькие). Она должна быть компактная, может быть сделана командой за одну итерацию.
Testable (тестируемые). Имеет чёткие критерии приёмки.
❗️ Критерии – это условия, при которых история считается выполненной.
Например, к истории «Добавить поиск по товарам» можно дописать:
• Поиск ищет по названию и описанию.
• Выдаёт результаты при вводе от 3 символов.
• Если ничего не найдено, то показывает заглушку с предложением посмотреть новинки.
• Время ответа не более 2 секунд.
Без этих критериев разработчик сделает «как-то», а вы будете удивляться, почему оно работает «не так».
❗️ВАЖНО! Не делать слишком крупные истории (эпики).
❗️ВАЖНО! Самые полезные истории, которые команда обсуждает на уточнении, задаёт вопросы, находит подводные камни.
Берём информацию из..
• Из CJM. На каких этапах пути возникают потребности?
• Из Use Case. Какие шаги можно сгруппировать в ценность?
• Из интервью. Как пользователи формулируют свои проблемы?
• Из данных техподдержки. О чём чаще всего спрашивают?
#UserStory #ПользовательскиеИстории #Продукт #Разработка #Agile #Scrum #Продакт
Мы разобрали CJM – посмотрели на путь пользователя целиком.
Разобрали Use Case – расписали детальные сценарии со всеми «а что, если».
User Story – это короткое описание функциональности с точки зрения пользователя. Не техническое задание, не список фич, а именно история работающая по шаблону:
Я как [роль] хочу [действие], чтобы [ценность].
Например:
• «Я как покупатель хочу видеть стоимость доставки до оформления заказа, чтобы понимать итоговую цену».
• «Я как водитель хочу получать уведомление о новой поездке на экране, чтобы не пропустить заказ, когда телефон в держателе».
User Story – это 1-2 предложения про ценность для планирования и приоритезации. Она отвечает на вопросы «что и зачем».
Зачем это вообще нужно?
• Фокус на пользователе. История заставляет каждый раз думать: а кому это надо? А зачем? А какая тут ценность?
• Единый язык. И разработчик, и тестировщик, и дизайнер, и бизнес понимают одно и то же. Нет пространства для трактовок «ну я имел в виду другое».
• Основа для обсуждения. User Story – это приглашение к диалогу. Команда может (и должна!) задавать вопросы, уточнять, предлагать.
• Планирование. Истории можно оценивать, приоритезировать, резать на спринты.
User Story ≠ Техническое задание
ТЗ обычно звучит как:
«Реализовать форму обратной связи с полями имя, email, сообщение и капчей».
User Story на ту же тему:
«Я как посетитель хочу отправить сообщение в поддержку прямо с сайта, чтобы быстро решить свою проблему, не открывая почту».
Хорошие User Story соответствуют критериям INVEST:
Independent (независимые). Историю можно реализовать отдельно от других.
Negotiable (обсуждаемые). Отражает суть, а не детали; не содержит конкретных шагов реализации.
Valuable (ценные). История должна приносить ценность пользователю или бизнесу.
Estimable (оцениваемые). Она должна быть оцениваемая по сложности и трудозатратам.
Small (маленькие). Она должна быть компактная, может быть сделана командой за одну итерацию.
Testable (тестируемые). Имеет чёткие критерии приёмки.
❗️ Критерии – это условия, при которых история считается выполненной.
Например, к истории «Добавить поиск по товарам» можно дописать:
• Поиск ищет по названию и описанию.
• Выдаёт результаты при вводе от 3 символов.
• Если ничего не найдено, то показывает заглушку с предложением посмотреть новинки.
• Время ответа не более 2 секунд.
Без этих критериев разработчик сделает «как-то», а вы будете удивляться, почему оно работает «не так».
❗️ВАЖНО! Не делать слишком крупные истории (эпики).
❗️ВАЖНО! Самые полезные истории, которые команда обсуждает на уточнении, задаёт вопросы, находит подводные камни.
Берём информацию из..
• Из CJM. На каких этапах пути возникают потребности?
• Из Use Case. Какие шаги можно сгруппировать в ценность?
• Из интервью. Как пользователи формулируют свои проблемы?
• Из данных техподдержки. О чём чаще всего спрашивают?
#UserStory #ПользовательскиеИстории #Продукт #Разработка #Agile #Scrum #Продакт
🔥5
Помните я уже говорил про поиск идей..
Недавно прочитал про необычный метод с забавным названием SCAMPER..
В переводе с английского SCAMPER – это пробежка. Мы устраиваем нашему продукту веселую пробежку. 😁
Данный метод используют как для генерации идей, так и для улучшения продуктов или решения проблем путем постановки 7 типов вопросов к существующему объекту.
Как это работает?
Мы берём наш продукт (или любой существующий) и по очереди «пропускаем» его через каждую букву. И обязательно записываем всё, что приходит в голову.
Substitute (Заменить)
Вопросы: Что можно заменить в продукте? Материал, компонент, человека, правило?
Например,
• Заменили металлическую трубу на пластиковую стало легче и дешевле
• Заменили продавца в магазине на онлайн-чат и смогли работать 24/7
Combine (Комбинировать)
Вопросы: Что можно с чем объединить? Смешать функции, идеи, сервисы?
Например,
• Телефон + фотоаппарат = смартфон с камерой
• Шампунь + кондиционер = 2-в-1
• Такси + еда = доставка еды как в приложении такси
Adapt (Адаптировать)
Вопросы: Что можно позаимствовать? Есть ли похожее решение в другой сфере?
Например,
• Систему умного дома адаптировали для офисов
• Технологии из военной промышленности перевели в гражданскую
Modify (Модифицировать)
Вопросы: Что можно изменить? Размер, форму, цвет, атрибуты, громкость?
Например,
• Увеличили размер шрифта в приложении сделав версию для слабовидящих
• Изменили форму бутылки и теперь она стала удобнее лежать в руке
Put to other use (Использовать по-другому)
Вопросы: Где ещё можно применить продукт? Кто ещё может им пользоваться?
Например,
• Средство для мытья стёкол оказалось отличным средством для удаления пятен с одежды (моя сказка для примера)
• Детские салфетки стали использовать водители для протирки руля и панели(т.к. спиртовые вредят)
Eliminate (Убрать / Упростить)
Вопросы: Что можно удалить? От чего отказаться без потери ценности?
Например,
• Убрали лишние кнопки с пульта, оставили только самые нужные
• Убрали пластиковую упаковку сделали экологичнее
Reverse (Перевернуть / Реорганизовать)
Вопросы: Что будет, если сделать наоборот? Поменять местами начало и конец, причину и следствие?
Например,
• Вместо «пользователь ищет товар» → «товар сам ищет пользователя» (рекомендательные системы).
• Вместо «купил – получил бонус» → «получил бонус – потратил на покупку» (кешбэк).
Спасибо а внимание! Возможно вам поможет данный метод преодолеть творческий ступор и посмотреть на привычные вещи под новым углом..
#scamper #генерацияидей #креатив #продукт #развитие #инструменты
Недавно прочитал про необычный метод с забавным названием SCAMPER..
В переводе с английского SCAMPER – это пробежка. Мы устраиваем нашему продукту веселую пробежку. 😁
Данный метод используют как для генерации идей, так и для улучшения продуктов или решения проблем путем постановки 7 типов вопросов к существующему объекту.
Как это работает?
Мы берём наш продукт (или любой существующий) и по очереди «пропускаем» его через каждую букву. И обязательно записываем всё, что приходит в голову.
Substitute (Заменить)
Вопросы: Что можно заменить в продукте? Материал, компонент, человека, правило?
Например,
• Заменили металлическую трубу на пластиковую стало легче и дешевле
• Заменили продавца в магазине на онлайн-чат и смогли работать 24/7
Combine (Комбинировать)
Вопросы: Что можно с чем объединить? Смешать функции, идеи, сервисы?
Например,
• Телефон + фотоаппарат = смартфон с камерой
• Шампунь + кондиционер = 2-в-1
• Такси + еда = доставка еды как в приложении такси
Adapt (Адаптировать)
Вопросы: Что можно позаимствовать? Есть ли похожее решение в другой сфере?
Например,
• Систему умного дома адаптировали для офисов
• Технологии из военной промышленности перевели в гражданскую
Modify (Модифицировать)
Вопросы: Что можно изменить? Размер, форму, цвет, атрибуты, громкость?
Например,
• Увеличили размер шрифта в приложении сделав версию для слабовидящих
• Изменили форму бутылки и теперь она стала удобнее лежать в руке
Put to other use (Использовать по-другому)
Вопросы: Где ещё можно применить продукт? Кто ещё может им пользоваться?
Например,
• Средство для мытья стёкол оказалось отличным средством для удаления пятен с одежды
• Детские салфетки стали использовать водители для протирки руля и панели
Eliminate (Убрать / Упростить)
Вопросы: Что можно удалить? От чего отказаться без потери ценности?
Например,
• Убрали лишние кнопки с пульта, оставили только самые нужные
• Убрали пластиковую упаковку сделали экологичнее
Reverse (Перевернуть / Реорганизовать)
Вопросы: Что будет, если сделать наоборот? Поменять местами начало и конец, причину и следствие?
Например,
• Вместо «пользователь ищет товар» → «товар сам ищет пользователя» (рекомендательные системы).
• Вместо «купил – получил бонус» → «получил бонус – потратил на покупку» (кешбэк).
Спасибо а внимание! Возможно вам поможет данный метод преодолеть творческий ступор и посмотреть на привычные вещи под новым углом..
#scamper #генерацияидей #креатив #продукт #развитие #инструменты
🔥6
Всем привет! 👋
На этой неделе поговорим о приоритизации бэклога и сегодня поговорим о методе MOSCOW..
Как работает?
Разделяем бэклог на 4 кучки, чтобы не пытаться «впихнуть невпихуемое» в один спринт:
Must have (Нужно обязательно). Без этого продукт просто не имеет смысла. Это наш MVP.
Например, в приложении доставки еды – это корзина и оплата. Если юзер не может купить бургер, дизайн кнопок ему не важен.
❗️ Если хоть один Must не готов – релиз отменяется.
Should have (Нужно бы, но...). Важно, но не критично для немедленного успеха. Эти элементы значительно повышают ценность продукта, но их внедрение может быть отложено при необходимости.
Пример: Фильтры по калориям или история заказов. Полезно? Да. Критично для первой продажи? Нет.
❗️ Если «Should have (Нужно бы, но...)» отсутствует, стоит тщательно оценить последствия и внести корректировки в других областях.
Could have (Можно, если останется время). Те самые «бантики» и улучшения, которые которые были бы желательны, улучшили бы пользовательский опыт или повысили эффективность, но не являются необходимыми.
Пример: Анимированные стикеры в чате с курьером или праздничная иконка приложения.
❗️ Наше время и энергия всегда ограничены то.
Won’t have (Не в этот раз). Самая важная категория. Сюда мы осознанно выкидываем всё, что НЕ будем делать в текущем цикле. Это экономит кучу нервов команде.
Пример: Интеграция с умными холодильниками или VR-просмотр меню.
❗️ Важно следить, чтобы «Мастов» было не больше 60% от объема работ. Иначе при первом же факапе (а они будут) у нас не останется пространства для маневра. А также нужно помнить, что для стартапа является «обязательным», для устоявшейся компании может быть «желательным».
На практике обычно происходит так, сроки горят, мы должны просто «отрезать» хвост из категорий Could и Should. Продукт все равно выходит рабочим, а команда не умирает от переработок.
#управлениепродуктом #приоритизация #moscow #продактменеджмент
На этой неделе поговорим о приоритизации бэклога и сегодня поговорим о методе MOSCOW..
Как работает?
Разделяем бэклог на 4 кучки, чтобы не пытаться «впихнуть невпихуемое» в один спринт:
Must have (Нужно обязательно). Без этого продукт просто не имеет смысла. Это наш MVP.
Например, в приложении доставки еды – это корзина и оплата. Если юзер не может купить бургер, дизайн кнопок ему не важен.
❗️ Если хоть один Must не готов – релиз отменяется.
Should have (Нужно бы, но...). Важно, но не критично для немедленного успеха. Эти элементы значительно повышают ценность продукта, но их внедрение может быть отложено при необходимости.
Пример: Фильтры по калориям или история заказов. Полезно? Да. Критично для первой продажи? Нет.
❗️ Если «Should have (Нужно бы, но...)» отсутствует, стоит тщательно оценить последствия и внести корректировки в других областях.
Could have (Можно, если останется время). Те самые «бантики» и улучшения, которые которые были бы желательны, улучшили бы пользовательский опыт или повысили эффективность, но не являются необходимыми.
Пример: Анимированные стикеры в чате с курьером или праздничная иконка приложения.
❗️ Наше время и энергия всегда ограничены то.
Won’t have (Не в этот раз). Самая важная категория. Сюда мы осознанно выкидываем всё, что НЕ будем делать в текущем цикле. Это экономит кучу нервов команде.
Пример: Интеграция с умными холодильниками или VR-просмотр меню.
❗️ Важно следить, чтобы «Мастов» было не больше 60% от объема работ. Иначе при первом же факапе (а они будут) у нас не останется пространства для маневра. А также нужно помнить, что для стартапа является «обязательным», для устоявшейся компании может быть «желательным».
На практике обычно происходит так, сроки горят, мы должны просто «отрезать» хвост из категорий Could и Should. Продукт все равно выходит рабочим, а команда не умирает от переработок.
#управлениепродуктом #приоритизация #moscow #продактменеджмент
🔥5💯1👻1
Cегодня разберем метод RICE.. Формула, которая поможет не разрываться между «хотелками» стейкхолдеров.
О методе MOSCOW уже поговорили..
Когда задач мало, их легко раскидать.
А вот когда их дофига, кажется, что даже если разорваться, нужное всё равно не успеешь.
Формула выглядит так:
RICE = (Reach × Impact × Confidence) / Effort
Reach (Охват): Скольких юзеров это коснется за месяц?
Пример: Мы меняем кнопку на главной (охват 100к) или правим баг в настройках профиля, куда заходит 1% юзеров (охват 1к).
❗️ Считаем только активную аудиторию за период. Лучше занизить Reach, чем строить планы на мертвые души.
Impact (Влияние): Насколько это поможет цели? Субъективная шкала «от 0 до 3» – рай для оптимистов. Всем кажется, что их фича «космос» (3 балла).
Пример: Добавление оплаты по QR-коду может дать Impact 3, а смена цвета иконки – 0.25.
❗️ Необходимо привязывать баллы к метрикам. Если цель – конверсия, то «3» – это рост на 10%, а «1» – на 1%. Иначе это гадание.
Confidence (Уверенность): Насколько мы верим своим цифрам? 100% – твердые данные, 80% – есть исследования, 50% – если просто кажется, 20% – «пальцем в небо».
Например, представим что мы хотим сделать расширенный редактор профиля. Рассчитываем по формуле: Reach высокий (у всех есть профиль), Impact высокий (удобство), Effort средний.
❗️ А на самом деле пользователи не заходят в профиль вообще.
❗️ А мы поставили Confidence 100%.
Effort (Затраты): Сколько ресурсов сожрет разработка? Считаем в «человеко-месяцах» или просто в спринтах.
Пример: Фича А делается за 1 спринт, фича Б за полгода.
❗️ Закладывать буфер на багфикс и непредвиденные сложности. Т.к. спринт может превратиться в три спринта + техдолг.
❗️ Формула – это просто калькулятор. Если мы загрузим в него ерунду, то и на выходе получим красивый, но бесполезный результат.
❗️ RICE не спасет, если вы врете себе сами!
Пример:
Задача А. Тёмная тема
Reach 50 000 | Impact 1 | Confidence 100% | Effort 1 спринт
👉 RICE = (50 000 × 1 × 100%) / 1 = 50 000
Задача Б. Реферальная программа
Reach 10 000 | Impact 3 | Confidence 80% | Effort 0.5 спринта
👉 RICE = (10 000 × 3 × 80%) / 0.5 = 48 000
Казалось бы, рефералка круче по влиянию. Но охват и простота «тёмной темы» в этом раунде побеждают.
#управлениепродуктом #приоритизация #RICE #проджектменеджмент
О методе MOSCOW уже поговорили..
Когда задач мало, их легко раскидать.
А вот когда их дофига, кажется, что даже если разорваться, нужное всё равно не успеешь.
Формула выглядит так:
RICE = (Reach × Impact × Confidence) / Effort
Reach (Охват): Скольких юзеров это коснется за месяц?
Пример: Мы меняем кнопку на главной (охват 100к) или правим баг в настройках профиля, куда заходит 1% юзеров (охват 1к).
❗️ Считаем только активную аудиторию за период. Лучше занизить Reach, чем строить планы на мертвые души.
Impact (Влияние): Насколько это поможет цели? Субъективная шкала «от 0 до 3» – рай для оптимистов. Всем кажется, что их фича «космос» (3 балла).
Пример: Добавление оплаты по QR-коду может дать Impact 3, а смена цвета иконки – 0.25.
❗️ Необходимо привязывать баллы к метрикам. Если цель – конверсия, то «3» – это рост на 10%, а «1» – на 1%. Иначе это гадание.
Confidence (Уверенность): Насколько мы верим своим цифрам? 100% – твердые данные, 80% – есть исследования, 50% – если просто кажется, 20% – «пальцем в небо».
Например, представим что мы хотим сделать расширенный редактор профиля. Рассчитываем по формуле: Reach высокий (у всех есть профиль), Impact высокий (удобство), Effort средний.
❗️ А на самом деле пользователи не заходят в профиль вообще.
❗️ А мы поставили Confidence 100%.
Effort (Затраты): Сколько ресурсов сожрет разработка? Считаем в «человеко-месяцах» или просто в спринтах.
Пример: Фича А делается за 1 спринт, фича Б за полгода.
❗️ Закладывать буфер на багфикс и непредвиденные сложности. Т.к. спринт может превратиться в три спринта + техдолг.
❗️ Формула – это просто калькулятор. Если мы загрузим в него ерунду, то и на выходе получим красивый, но бесполезный результат.
❗️ RICE не спасет, если вы врете себе сами!
Пример:
Задача А. Тёмная тема
Reach 50 000 | Impact 1 | Confidence 100% | Effort 1 спринт
👉 RICE = (50 000 × 1 × 100%) / 1 = 50 000
Задача Б. Реферальная программа
Reach 10 000 | Impact 3 | Confidence 80% | Effort 0.5 спринта
👉 RICE = (10 000 × 3 × 80%) / 0.5 = 48 000
Казалось бы, рефералка круче по влиянию. Но охват и простота «тёмной темы» в этом раунде побеждают.
#управлениепродуктом #приоритизация #RICE #проджектменеджмент
🔥4