Разбираем наши цели по кусочкам, декомпозируем..
Декомпозиция, простым языком – это переход от общего к частному, от сложного к простому.
Декомпозиция цели – это её детализация, наглядное разделение большой, объёмной цели на многоуровневую иерархию небольших, но связанных между собой задач.
Этапы работы:
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
Всем доброго утра и хорошего начала недели!
Если наш день начинается с того, что мы разгребаем кучу задач и пытаемся понять, за что хвататься, т.к. СРОЧНО - ВСЁ! Нам поможет матрица Эйзенхауэра..
Это старый, но эффективный инструмент.
Сделать квадрат с колонками «Срочно» и «Не срочно» и с двумя строками: «Важно» и «Не важно».
Срочные и важные дела. В этом квадранте сосредоточена критически важная работа с жесткими сроками, которая вносит значительный вклад в достижение ваших целей. Эта ячейка подобна шипящему котлу на плите – она требует немедленного внимания! Представьте себе завершение проекта, который нужно сдать завтра, или устранение прорыва трубы дома.
❗️ Если ты живешь только в этом квадрате, значит, где-то в планировании ты свернул не туда.
Важные, но несрочные дела. В этом квадранте сосредоточена наша основная работа. Возможно, она не срочная, но это настоящий сундук с сокровищами, полный задач, имеющих значение в долгосрочной перспективе, даже если у них нет немедленных сроков. Это наши стратегические шаги, такие как планирование карьеры или поддержание здоровья.
❗️ Чем больше времени мы будем проводить здесь, тем меньше задач будут залтать в срочное и важное.
Срочные, но неважные дела. Это рутинная работа – вроде неважных электронных писем или мелких просьб от коллег – которая привлекает внимание, но мало способствует достижению ваших общих целей.
❗️ Делегировать. Или вежливо слать лесом, если это не наша зона ответственности. Это квадрат-вор, который крадет твой ресурс.
Несрочные и неважные дела. В этом последнем квадранте находится ваша ненужная работа – все, что не имеет значения и, по сути, не должно происходить. Вам следует свести к минимуму или полностью исключить все, что находится в этом квадранте.
❗️ Удалять. Безжалостно.
Главное не путать СРОЧНОЕ и ВАЖНОЕ! СРОЧНОСТЬ – это давление извне (чей-то крик в личке), а ВАЖНОСТЬ – это то, что реально двигает метрики продукта.
Размышляем, делегируем, автоматизируем, бросаем вызов! 😁
#управлениепродуктом #приоритизация #матрица #Эйзенхауэр #проджектменеджмент
Если наш день начинается с того, что мы разгребаем кучу задач и пытаемся понять, за что хвататься, т.к. СРОЧНО - ВСЁ! Нам поможет матрица Эйзенхауэра..
Это старый, но эффективный инструмент.
Сделать квадрат с колонками «Срочно» и «Не срочно» и с двумя строками: «Важно» и «Не важно».
Срочные и важные дела. В этом квадранте сосредоточена критически важная работа с жесткими сроками, которая вносит значительный вклад в достижение ваших целей. Эта ячейка подобна шипящему котлу на плите – она требует немедленного внимания! Представьте себе завершение проекта, который нужно сдать завтра, или устранение прорыва трубы дома.
❗️ Если ты живешь только в этом квадрате, значит, где-то в планировании ты свернул не туда.
Важные, но несрочные дела. В этом квадранте сосредоточена наша основная работа. Возможно, она не срочная, но это настоящий сундук с сокровищами, полный задач, имеющих значение в долгосрочной перспективе, даже если у них нет немедленных сроков. Это наши стратегические шаги, такие как планирование карьеры или поддержание здоровья.
❗️ Чем больше времени мы будем проводить здесь, тем меньше задач будут залтать в срочное и важное.
Срочные, но неважные дела. Это рутинная работа – вроде неважных электронных писем или мелких просьб от коллег – которая привлекает внимание, но мало способствует достижению ваших общих целей.
❗️ Делегировать. Или вежливо слать лесом, если это не наша зона ответственности. Это квадрат-вор, который крадет твой ресурс.
Несрочные и неважные дела. В этом последнем квадранте находится ваша ненужная работа – все, что не имеет значения и, по сути, не должно происходить. Вам следует свести к минимуму или полностью исключить все, что находится в этом квадранте.
❗️ Удалять. Безжалостно.
Главное не путать СРОЧНОЕ и ВАЖНОЕ! СРОЧНОСТЬ – это давление извне (чей-то крик в личке), а ВАЖНОСТЬ – это то, что реально двигает метрики продукта.
Размышляем, делегируем, автоматизируем, бросаем вызов! 😁
#управлениепродуктом #приоритизация #матрица #Эйзенхауэр #проджектменеджмент
🔥5
А может погадаем на кофейной гуще? 😁
Всем доброго понедельничного утра! 👋
Прошу прощения за паузу в публикациях – одним продакт-менеджментом сыт не будешь, дел навалилось столько, что едва успеваю всё разгребать. Но я возвращаюсь! 😁
Сегодня открываем большую и важную тему – Продуктовую аналитику. Начнем с основ, а дальше пойдем по метрикам и фреймворкам.
Зачем нам вообще цифры?
Аналитика – это не просто графики, это процесс познания продукта. Она позволяет:
🪩 Понимать, как дела прямо сейчас (без иллюзий).
👀 Видеть, куда и как развивать продукт.
💨 Быстро ловить баги и аномалии.
📊 Строить прогнозы и лучше знать свою аудиторию.
🤖 Делать продукт, который реально нужен, а не который «кажется» правильным.
Есть несколько типов компаний и их отношение к данным:
1. Аналитику не собирают. Решения принимают «по чуйке».
2. Собирают всё подряд «на всякий случай», но не понимают, зачем.
3. Смотрят базовый набор счетчиков (трафик, регистрации), но не видят всей картины.
4. Четко понимают связь метрик и целей. Анализируют, как каждое изменение влияет на бизнес.
С чего мы начинаем?
🗣️ Первым делом мы строим модель работы продукта. На её основе мы предсказываем, что будет происходить.
🗣️ Если прогноз не сбылся, мы формируем гипотезы.
🗣️ Смотрим на данные, мы проверяем эти гипотезы.
🗣️ Уточняем модель и повторяем цикл.
На сегодня у меня всё.
#productmanagement #analytics #продуктоваяаналитика #данные #метрики
Всем доброго понедельничного утра! 👋
Прошу прощения за паузу в публикациях – одним продакт-менеджментом сыт не будешь, дел навалилось столько, что едва успеваю всё разгребать. Но я возвращаюсь! 😁
Сегодня открываем большую и важную тему – Продуктовую аналитику. Начнем с основ, а дальше пойдем по метрикам и фреймворкам.
Зачем нам вообще цифры?
Аналитика – это не просто графики, это процесс познания продукта. Она позволяет:
🪩 Понимать, как дела прямо сейчас (без иллюзий).
👀 Видеть, куда и как развивать продукт.
💨 Быстро ловить баги и аномалии.
📊 Строить прогнозы и лучше знать свою аудиторию.
🤖 Делать продукт, который реально нужен, а не который «кажется» правильным.
Есть несколько типов компаний и их отношение к данным:
1. Аналитику не собирают. Решения принимают «по чуйке».
2. Собирают всё подряд «на всякий случай», но не понимают, зачем.
3. Смотрят базовый набор счетчиков (трафик, регистрации), но не видят всей картины.
4. Четко понимают связь метрик и целей. Анализируют, как каждое изменение влияет на бизнес.
С чего мы начинаем?
🗣️ Первым делом мы строим модель работы продукта. На её основе мы предсказываем, что будет происходить.
🗣️ Если прогноз не сбылся, мы формируем гипотезы.
🗣️ Смотрим на данные, мы проверяем эти гипотезы.
🗣️ Уточняем модель и повторяем цикл.
На сегодня у меня всё.
#productmanagement #analytics #продуктоваяаналитика #данные #метрики
🔥4
Как обещал продолжаем..
Что такое метрики и зачем они нам?
Метрика – это показатель эффективности продукта или конкретной фичи. А главное: это всегда свершившееся и зафиксированное событие.
Зачем они нам нужны?
1. Для исследований. Изучаем пути пользователя. Где он «спотыкается»?
2. Для мониторинга. Контролируем критические точки (например, конверсию из посещения в регистрацию).
3. Для себя любимого. Чтобы видеть масштаб (общее количество скачиваний за всё время).
4. Для понимания контекста. Изучаем глубину просмотра страниц или время в приложении.
Какие бывают метрики?
• Абсолютные. Например, приложение установили 1000 раз за месяц.
• Относительные. Например, количество установок выросло на 10% к прошлому месяцу.
• Количественные. Например, 100 человек ежедневно совершают покупку.
• Качественные. Например, пользователи жалуются в поддержку на долгую доставку (фидбек тоже можно оцифровать).
А еще важное деление метрик разберемна примере сервиса подписки на кофе .
💻 Технические (Работоспособность): Например, Uptime сайта. Насколько быстро грузится страница выбора сорта кофе и не «падает» ли оплата?
🗣 Маркетинговые (Привлечение). Например, стоимость привлечения одного подписчика (CAC). Сколько денег мы потратили на рекламу в соцсетях, чтобы человек зашел на сайт?
💎 Продуктовые (Взаимодействие). Например, Retention (Удержание). Какой процент пользователей выбирает зерна для следующей посылки, а не удаляет аккаунт?
💰 Бизнесовые (Деньги): Например, LTV (Пожизненная ценность клиента). Сколько прибыли принесет один любитель кофе за все 12 месяцев подписки?
Цепочка связей выглядит примерно так..
• Если Технические метрики падают (сайт тормозит), то Продуктовые сразу проседают (пользователь уходит, не выбрав кофе).
• Маркетинговые деньги вылетают в трубу – мы привели трафик на неработающий сервис.
• Это мгновенно бьет по Бизнесовым метрикам (выручка падает).
Нельзя смотреть только на один тип. Нам важно следить за всеми ними.
#analytics #metrics #product #метрики #аналитика
Что такое метрики и зачем они нам?
Метрика – это показатель эффективности продукта или конкретной фичи. А главное: это всегда свершившееся и зафиксированное событие.
Зачем они нам нужны?
1. Для исследований. Изучаем пути пользователя. Где он «спотыкается»?
2. Для мониторинга. Контролируем критические точки (например, конверсию из посещения в регистрацию).
3. Для себя любимого. Чтобы видеть масштаб (общее количество скачиваний за всё время).
4. Для понимания контекста. Изучаем глубину просмотра страниц или время в приложении.
Какие бывают метрики?
• Абсолютные. Например, приложение установили 1000 раз за месяц.
• Относительные. Например, количество установок выросло на 10% к прошлому месяцу.
• Количественные. Например, 100 человек ежедневно совершают покупку.
• Качественные. Например, пользователи жалуются в поддержку на долгую доставку (фидбек тоже можно оцифровать).
А еще важное деление метрик разберем
💻 Технические (Работоспособность): Например, Uptime сайта. Насколько быстро грузится страница выбора сорта кофе и не «падает» ли оплата?
🗣 Маркетинговые (Привлечение). Например, стоимость привлечения одного подписчика (CAC). Сколько денег мы потратили на рекламу в соцсетях, чтобы человек зашел на сайт?
💎 Продуктовые (Взаимодействие). Например, Retention (Удержание). Какой процент пользователей выбирает зерна для следующей посылки, а не удаляет аккаунт?
💰 Бизнесовые (Деньги): Например, LTV (Пожизненная ценность клиента). Сколько прибыли принесет один любитель кофе за все 12 месяцев подписки?
Цепочка связей выглядит примерно так..
• Если Технические метрики падают (сайт тормозит), то Продуктовые сразу проседают (пользователь уходит, не выбрав кофе).
• Маркетинговые деньги вылетают в трубу – мы привели трафик на неработающий сервис.
• Это мгновенно бьет по Бизнесовым метрикам (выручка падает).
Нельзя смотреть только на один тип. Нам важно следить за всеми ними.
#analytics #metrics #product #метрики #аналитика
🔥3
Сегодня поговорим о деньгах и эффективности продукта, а именно о бизнес-метрика..
Именно на них мы будем смотреть, когда будем решать, выделять ли бюджет на эти новые фичи или нет.
Разберем на предыдущем примере про кофейный сервис..
1. Revenue (Выручка)
Это все деньги, которые упали на счет от клиентов или рекламодателей.
• Суть: Показывает масштаб и популярность продукта.
• Пример: За месяц продали подписок на 150 000 ₽. Это и есть Revenue.
2. Earnings / Net Income (Чистая прибыль)
Выручка – это еще не те деньги, которые можно положить в карман. Нужно вычесть все расходы.
• Формула: Revenue − Expenses (Расходы)
• Пример: 150 000 ₽ (выручка) − 100 000 ₽ (закупка кофе) − 5 000 ₽ (сайт) − 1 500 ₽ (налоги) = 43 500 ₽. Это чистая прибыль.
3. EBITDA (Операционная эффективность)
Прибыль до вычета процентов, налогов и амортизации.
• Суть: Позволяет оценить эффективность самой бизнес-модели, не учитывая особенности налогообложения или кредитов.
• Пример: К чистой прибыли (43 500 ₽) прибавляем налоги (1 500 ₽) и амортизацию сайта (5 000 ₽) = 50 000 ₽.
4. ARPU / ARPA / ARPC (Средний чек)
Сколько в среднем приносит один пользователь (User), аккаунт (Account) или клиент (Client).
• Формула: Revenue / Active Users
• Пример: Выручка 150 000 ₽ / 2000 покупателей = 75 ₽ приносит один средний клиент.
5. COGS (Себестоимость проданных товаров)
Прямые затраты на производство того, что вы продали.
• Пример: Кофе на начало месяца (150к) + закупки (200к) − остатки (250к) = 100 000 ₽. Это цена продукта «в себестоимости».
Скажите вы что здесь каких-то метрик не хватает.. и я вам отвечу это так!!! Первые какие еще на ум приходят и за что отвечают – это..
CAC (Customer Acquisition Cost): Сколько стоит "купить" одного нового клиента? (Реклама / кол-во клиентов).
LTV (Lifetime Value): Сколько денег принесет клиент за ВСЁ время жизни в продукте?
Churn Rate (Отток): Какой процент клиентов отменяет подписку на кофе каждый месяц?
ROI / ROMI: Окупаются ли вообще наши вложения в маркетинг и разработку?
❗️ Можно иметь огромную выручку (Revenue), но при этом быть убыточной компанией, если расходы (COGS и прочие) выше.
Наша задача – это растить не только обороты, но и маржинальность.
#productmanagement #businessmetrics #revenue #ebitda #аналитика #деньги
Именно на них мы будем смотреть, когда будем решать, выделять ли бюджет на эти новые фичи или нет.
Разберем на предыдущем примере про кофейный сервис..
1. Revenue (Выручка)
Это все деньги, которые упали на счет от клиентов или рекламодателей.
• Суть: Показывает масштаб и популярность продукта.
• Пример: За месяц продали подписок на 150 000 ₽. Это и есть Revenue.
2. Earnings / Net Income (Чистая прибыль)
Выручка – это еще не те деньги, которые можно положить в карман. Нужно вычесть все расходы.
• Формула: Revenue − Expenses (Расходы)
• Пример: 150 000 ₽ (выручка) − 100 000 ₽ (закупка кофе) − 5 000 ₽ (сайт) − 1 500 ₽ (налоги) = 43 500 ₽. Это чистая прибыль.
3. EBITDA (Операционная эффективность)
Прибыль до вычета процентов, налогов и амортизации.
• Суть: Позволяет оценить эффективность самой бизнес-модели, не учитывая особенности налогообложения или кредитов.
• Пример: К чистой прибыли (43 500 ₽) прибавляем налоги (1 500 ₽) и амортизацию сайта (5 000 ₽) = 50 000 ₽.
4. ARPU / ARPA / ARPC (Средний чек)
Сколько в среднем приносит один пользователь (User), аккаунт (Account) или клиент (Client).
• Формула: Revenue / Active Users
• Пример: Выручка 150 000 ₽ / 2000 покупателей = 75 ₽ приносит один средний клиент.
5. COGS (Себестоимость проданных товаров)
Прямые затраты на производство того, что вы продали.
• Пример: Кофе на начало месяца (150к) + закупки (200к) − остатки (250к) = 100 000 ₽. Это цена продукта «в себестоимости».
Скажите вы что здесь каких-то метрик не хватает.. и я вам отвечу это так!!! Первые какие еще на ум приходят и за что отвечают – это..
CAC (Customer Acquisition Cost): Сколько стоит "купить" одного нового клиента? (Реклама / кол-во клиентов).
LTV (Lifetime Value): Сколько денег принесет клиент за ВСЁ время жизни в продукте?
Churn Rate (Отток): Какой процент клиентов отменяет подписку на кофе каждый месяц?
ROI / ROMI: Окупаются ли вообще наши вложения в маркетинг и разработку?
❗️ Можно иметь огромную выручку (Revenue), но при этом быть убыточной компанией, если расходы (COGS и прочие) выше.
Наша задача – это растить не только обороты, но и маржинальность.
#productmanagement #businessmetrics #revenue #ebitda #аналитика #деньги
🔥7💯1
Как понять, что реклама работает?
Всем доброго утра и продуктивного начала недели!
🚀 Всех причастных к космонавтике – с прошедшим праздником!
Тут кратко рассказал что такое метрики..
Тут немного про бизнес-метрики..
Мы продолжаем погружение в аналитику. Сегодня будем говорить о маркетинговых метриках. Они живут на стороне привлечения, но тесно переплетены с бизнесом.
1. CPC, CPM, CPA, CPI, CPL (Стоимость за действие)
Эти показатели помогают сравнить эффективность разных источников трафика.
• CPC (Cost per click) – цена за клик.
• CPM (Cost per mille) – цена за 1000 показов.
• CPA (Cost per action) – цена за целевое действие (покупка, подписка).
• CPI (Cost per install) – цена за установку приложения.
• CPL (Cost per lead) – цена за лид (регистрация/заявка).
Cost per … = Стоимость / Количество единиц измеряемого показателя
Например, потратили 5000 ₽ на рекламу в поиске, получили 250 переходов. CPC = 20 ₽.
2. CTR (Эффективность креатива)
Показывает «кликабельность» нашей рекламы.
CTR = (Клики / Показы) × 100%
Например, наш баннер увидели 100000 раз, а нажали 1000 раз. CTR = 1%. Чем выше этот %, тем точнее мы попали в боли аудитории.
3. CR (Conversion Rate /Конверсия)
Трафик пришел, но что он сделал дальше?
Например, из 1000 человек, перешедших по ссылке, 50 зарегистрировались. CR = 5%.
Если конверсия низкая – проблема либо в качестве трафика, либо в удобстве лендинга.
4. CAC (Стоимость привлечения клиента)
Сколько денег мы потратили, чтобы один человек стал нашим пользователем/клиентом.
Например, потратили на рекламу 20000 ₽, получили 50 регистраций. CAC = 400 ₽.
5. ROI, ROMI, ROAS (Окупаемость)
Показывают, вернулись ли инвестиции в привлечение.
• ROMI (Marketing) – окупаемость именно маркетинговых затрат.
• ROAS (Ad Spend) – окупаемость только рекламного бюджета.
ROI = ((Выручка - Затраты) / Затраты) × 100%
Что еще важно знать?
В маркетинге также смотрят на:
• LTV / CAC Ratio: Золотое правило – LTV должен быть минимум в 3 раза выше CAC.
• Chun Rate (Отток): Как быстро уходят те, кого мы привели?
• Retention: Возвращаются ли они после первой покупки?
Постепенно мы будем углубляться в каждую из них, чтобы мы могли построить полноценную воронку своего продукта.
#marketing #metrics #cac #romi #аналитика #маркетинг #productmanagement
Всем доброго утра и продуктивного начала недели!
🚀 Всех причастных к космонавтике – с прошедшим праздником!
Тут кратко рассказал что такое метрики..
Тут немного про бизнес-метрики..
Мы продолжаем погружение в аналитику. Сегодня будем говорить о маркетинговых метриках. Они живут на стороне привлечения, но тесно переплетены с бизнесом.
‼️ Маркетинговые метрики всегда нужно анализировать в разрезе каналов (соцсети, поиск, блогеры), чтобы понимать, какой из них тянет вас вверх, а какой – на дно.
1. CPC, CPM, CPA, CPI, CPL (Стоимость за действие)
Эти показатели помогают сравнить эффективность разных источников трафика.
• CPC (Cost per click) – цена за клик.
• CPM (Cost per mille) – цена за 1000 показов.
• CPA (Cost per action) – цена за целевое действие (покупка, подписка).
• CPI (Cost per install) – цена за установку приложения.
• CPL (Cost per lead) – цена за лид (регистрация/заявка).
Cost per … = Стоимость / Количество единиц измеряемого показателя
Например, потратили 5000 ₽ на рекламу в поиске, получили 250 переходов. CPC = 20 ₽.
2. CTR (Эффективность креатива)
Показывает «кликабельность» нашей рекламы.
CTR = (Клики / Показы) × 100%
Например, наш баннер увидели 100000 раз, а нажали 1000 раз. CTR = 1%. Чем выше этот %, тем точнее мы попали в боли аудитории.
3. CR (Conversion Rate /Конверсия)
Трафик пришел, но что он сделал дальше?
Например, из 1000 человек, перешедших по ссылке, 50 зарегистрировались. CR = 5%.
Если конверсия низкая – проблема либо в качестве трафика, либо в удобстве лендинга.
4. CAC (Стоимость привлечения клиента)
Сколько денег мы потратили, чтобы один человек стал нашим пользователем/клиентом.
Например, потратили на рекламу 20000 ₽, получили 50 регистраций. CAC = 400 ₽.
5. ROI, ROMI, ROAS (Окупаемость)
Показывают, вернулись ли инвестиции в привлечение.
• ROMI (Marketing) – окупаемость именно маркетинговых затрат.
• ROAS (Ad Spend) – окупаемость только рекламного бюджета.
ROI = ((Выручка - Затраты) / Затраты) × 100%
Что еще важно знать?
В маркетинге также смотрят на:
• LTV / CAC Ratio: Золотое правило – LTV должен быть минимум в 3 раза выше CAC.
• Chun Rate (Отток): Как быстро уходят те, кого мы привели?
• Retention: Возвращаются ли они после первой покупки?
Постепенно мы будем углубляться в каждую из них, чтобы мы могли построить полноценную воронку своего продукта.
#marketing #metrics #cac #romi #аналитика #маркетинг #productmanagement
🔥4