📐 Framework продуктовой стратегии: от портфеля до исполнения (пост 1 из 4)
Часто стратегию сводят к амбициям, KPI или красивому roadmap. На мой взгляд, стратегия — это обоснованный выбор точки B и маршрут к ней через трансформацию продукта и команды, а иногда и рынка. Этот процесс разворачивается на 3х взаимосвязанных уровнях и схематично может выглядеть следующим образом:
➖ Portfolio & Governance
Раз в год (или полугодие) CPO вместе с CEO и CFO задают «куда и сколько» инвестировать:
💼 Portfolio-Review — уточняют North‑Star и ключевые бизнес‑цели, формируют общий CAPEX/OPEX.
💵 Capital Allocation — ресурсы делят на четыре «корзины»:
🔘 Run — поддержка ядра продукта;
🔘 Change — развитие в близких сегментах;
🔘 Disrupt — прорывные проекты для новой ценности;
🔘 Exploration — тактическое Discovery: быстрые PoC‑гипотезы, короткий спринт, ясная метрика, малая команда.
Теперь нужно заполнить "корзины" инициативами. Первый источник - то, что осталась с прошлого периода. В остальном Наполнение происходит двумя параллельными курсами: сверху идет фокус, снизу - идеи.
Top-Down vs Bottom-Up
🔘 Top-Down задаёт цели (например, рост ARPU на 15 %) и фильтрует любые инициативы по релевантности этим целям.
🔘 Bottom-Up позволяет командам приносить идеи через Exploration и Pitch-Gate: если PoC показывает наличие эффекта, на Strategy Sync они могут получить основной бюджет из одной из корзин.
Так более эффективные гипотезы вытесняют менее эффективные в каждом пуле, а реальный бюджет получает только то, что проверено (исключение high‑confidence).
Движение идей: PoC → Pitch‑Gate → Strategy Sync → Execution.
📅 Monthly Pitch Gate
• Уровень: Portfolio & Governance ↔️ Strategic Design ↔️ Execution
• Задача: отбор PoC‑гипотез из пула Exploration → решение Scale → Run/Change, Incubate или Kill.
• Связь: именно здесь Bottom‑Up‑идеи получают шанс «попасть» в основной бюджет.
📆 Quarterly Strategy Review (Strategy Commit & Refresh)
• Уровень: Portfolio & Governance ↔️ Strategic Design
• Задача:
– команды презентуют сценарии (проблема, метрики, риски, kill‑критерии) и результаты PoC;
– Steering Committee решает approve / refine / reject крупные инициативы и перераспределяет Run/Change/Disrupt‑бюджеты;
– апдейт roadmap на основе свежих данных.
➖ Strategic Design
🧩 Проблематизация или формулирование требований к Discovery
🔎 Strategic Discovery (JTBD, value chain, объем рынка и сегментов, конкуренты, тренды)
👥 Выбор целевых сегментов / ICP
📒 Черновой Backlog идей (без фильтра, из любых источников), описанных с точки зрения Effect или TAM+SOM /Capacity/Risks.
🔖 Сценарирование (2–4 варианта)
🏢 «консервативный» (упор на Run),
⚖️ «сбалансированный» (Run+Change),
💥 «смелый» (+Disrupt).
✅ Выбор сценария
☣️ ROAM-план (Resolve / Own / Accept / Mitigate)
📝 Сценарный Backlog + Roadmap (эпики, таймлайн, зависимости)
🔄 Strategy Commit — цель: подтвердить, что Roadmap приближает к North-Star, ресурс укладывается в бюджет, риски покрыты. Исход: «commit / доработать / не вписывается»
🔄 Strategy Refresh — вносим проверенные PoC
➖ Execution
🎯 Декомпозиция North-Star → Team OKR/KPI
🕵️♀️ Continuous Discovery (тактические проверки гипотез отдельной командой)
🛠 Приоритизация & Планирование итераций
🔧 Dev → CI/CD → Pre-Release (QA, Security, Legal)
🚀 Запуск фичи / эксперимента
📊 Анализ
🔄 Delivery Review: Ежемесячно/еженедельно отрабатываем Risk Burndown, kill‑критерии, roll‑out, доработку фич и прокачку новых PoC для Exploration.
🔄 Перезапуск (Discovery ↔️ Delivery циклы)
В следующем посте — чек‑лист зрелости команды: как подобрать темп и не просить у неё невозможного.
Pro Product
#стратегия
Часто стратегию сводят к амбициям, KPI или красивому roadmap. На мой взгляд, стратегия — это обоснованный выбор точки B и маршрут к ней через трансформацию продукта и команды, а иногда и рынка. Этот процесс разворачивается на 3х взаимосвязанных уровнях и схематично может выглядеть следующим образом:
➖ Portfolio & Governance
Раз в год (или полугодие) CPO вместе с CEO и CFO задают «куда и сколько» инвестировать:
💼 Portfolio-Review — уточняют North‑Star и ключевые бизнес‑цели, формируют общий CAPEX/OPEX.
💵 Capital Allocation — ресурсы делят на четыре «корзины»:
Теперь нужно заполнить "корзины" инициативами. Первый источник - то, что осталась с прошлого периода. В остальном Наполнение происходит двумя параллельными курсами: сверху идет фокус, снизу - идеи.
Top-Down vs Bottom-Up
Так более эффективные гипотезы вытесняют менее эффективные в каждом пуле, а реальный бюджет получает только то, что проверено (исключение high‑confidence).
Движение идей: PoC → Pitch‑Gate → Strategy Sync → Execution.
📅 Monthly Pitch Gate
• Уровень: Portfolio & Governance ↔️ Strategic Design ↔️ Execution
• Задача: отбор PoC‑гипотез из пула Exploration → решение Scale → Run/Change, Incubate или Kill.
• Связь: именно здесь Bottom‑Up‑идеи получают шанс «попасть» в основной бюджет.
📆 Quarterly Strategy Review (Strategy Commit & Refresh)
• Уровень: Portfolio & Governance ↔️ Strategic Design
• Задача:
– команды презентуют сценарии (проблема, метрики, риски, kill‑критерии) и результаты PoC;
– Steering Committee решает approve / refine / reject крупные инициативы и перераспределяет Run/Change/Disrupt‑бюджеты;
– апдейт roadmap на основе свежих данных.
➖ Strategic Design
🧩 Проблематизация или формулирование требований к Discovery
🔎 Strategic Discovery (JTBD, value chain, объем рынка и сегментов, конкуренты, тренды)
👥 Выбор целевых сегментов / ICP
📒 Черновой Backlog идей (без фильтра, из любых источников), описанных с точки зрения Effect или TAM+SOM /Capacity/Risks.
🔖 Сценарирование (2–4 варианта)
🏢 «консервативный» (упор на Run),
⚖️ «сбалансированный» (Run+Change),
💥 «смелый» (+Disrupt).
✅ Выбор сценария
☣️ ROAM-план (Resolve / Own / Accept / Mitigate)
📝 Сценарный Backlog + Roadmap (эпики, таймлайн, зависимости)
🔄 Strategy Commit — цель: подтвердить, что Roadmap приближает к North-Star, ресурс укладывается в бюджет, риски покрыты. Исход: «commit / доработать / не вписывается»
🔄 Strategy Refresh — вносим проверенные PoC
➖ Execution
🎯 Декомпозиция North-Star → Team OKR/KPI
🕵️♀️ Continuous Discovery (тактические проверки гипотез отдельной командой)
🛠 Приоритизация & Планирование итераций
🔧 Dev → CI/CD → Pre-Release (QA, Security, Legal)
🚀 Запуск фичи / эксперимента
📊 Анализ
🔄 Delivery Review: Ежемесячно/еженедельно отрабатываем Risk Burndown, kill‑критерии, roll‑out, доработку фич и прокачку новых PoC для Exploration.
🔄 Перезапуск (Discovery ↔️ Delivery циклы)
💡 Что запомнить:
🔘 Три уровня: Portfolio → Strategic Design → Execution
🔘 Четыре пула: Run, Change, Disrupt, Exploration
🔘 Top‑Down задаёт рамки, Bottom‑Up приносит PoC
🔘 Monthly Pitch Gate и Quarterly Strategy Review — точки фильтрации
🔘 Kill‑критерии и регулярный Refresh поддерживают живость стратегии
В следующем посте — чек‑лист зрелости команды: как подобрать темп и не просить у неё невозможного.
Pro Product
#стратегия
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2😱1
Зачем оценивать зрелость команды? (2 из 4)
1️⃣ Скорость Delivery vs Discovery: без чётких процессов CI/CD и навыков запуска PoC гипотезы валидируются медленно, burn rate растёт.
2️⃣ Адекватный выбор стратегий: без базового уровня run/change disrupt-инициативы «убьют» и команду, и стратегию.
3️⃣ Баланс прав и ответственности: зрелость определяется не только навыками, но и мандатом на эксперименты и бюджет.
1️⃣ Состав и структура команды
Продукт — это не только код и UX, но и взаимодействие трёх ключевых функций: Discovery (продакты, UX‑исследователи, аналитики), Delivery (разработчики, QA, DevOps) и Go‑to‑Market (маркетинг, продажи, customer success).
На ранних этапах PSF–PMF все эти роли часто работают единым сквадом: это максимизирует скорость общения и позволяет быстро проверять гипотезы «проблема–решение». При подготовке к масштабированию удобно вынести Go‑to‑Market в отдельную группу, чтобы основная команда непрерывно улучшала продукт. На зрелых фазах допустимо формировать три независимых сквада, плюс выделять небольшой disrupt‑R&D‑сквад для новых направлений.
2️⃣ Модель зрелости
Для оценки зрелости продуктовой команды существуют десятки фреймворков, но чаще всего на практике применяют три подхода:
✔️ Thoughtworks DPM³
✔️ Atlassian Team Health Monitor
✔️ Spotify Squad Health Check
В каждом случае короткий воркшоп даёт «радар зрелости» и план улучшений.
Я же предлагаю использовать кастомную четырёхуровневую модель зрелости, которую вы видите на слайде:
1 — Delivery‑Only (стабильные релизы, баг‑фиксинг),
2 — Reactive Discovery (доработка по incoming‑фидбэку),
3 — Proactive Discovery (A/B‑тесты, customer interviews),
4 — Strategic Innovators (участие в портфеле, запуск disrupt‑ и ecosystem‑треков).
Она сочетает строгость DPM³ (четыре чётких уровня вместо шести и 36 практик) и простоту Health Monitor/Health Check (короткие воркшопы и наглядные результаты), но при этом сразу привязывает ваш уровень к выбору стратегий (Run / Change / Disrupt).
3️⃣ Три столпа зрелости
Уровень maturity складывается из 3х компонентов:
✔️ Компетенции. Навыки product discovery, работы с данными, быстрой валидации гипотез, фасилитации.
✔️ Процессы. Отлаженные CI/CD‑пайплайны, code review, регулярность Discovery, наличие Research Repository.
✔️ Мандат. Право принимать решения (в т.ч. kill), бюджет на исследования, доступ к данным, участие в Strategy Sync.
Без хотя бы базового сочетания «компетенции+процессы» ваши PoC‑идеи либо «утонут» в баг‑фиксе, либо не найдут финансирования. Без мандата же даже идеальная команда не сможет влиять на стратегию и портфель.
4️⃣ Уровень зрелости ↔️ Тип стратегии
По мере роста maturity горизонты возможных стратегий расширяются:
🔘 Delivery‑Only → Run. Фокус на стабильности: надёжные релизы, снижение технического долга.
🔘 Reactive Discovery → Run + лёгкий Change. Реактивные доработки и ценовые/UX‑эксперименты.
🔘 Proactive Discovery → Run + Change + первые ограниченные disrupt‑PoC.
🔘 Strategic Innovators → Run + Change + Disrupt. Доступна любая стратегия: и амбициозные R&D‑проекты, и партнерские экосистемы, при условии жёстких financial guardrails.
Если команда слабее заявленных амбиций, вы рискуете «сгореть»: PoC не пройдут, команда выйдет из цикла continuous learning, а ресурсы будут исчерпаны. Вернитесь к run/change‑фокусу и вложитесь в прокачку навыков и процессов.
Когда же команда сильнее текущих планов, дайте ей mini‑PoC‑мандат — с чёткими kill‑критериями и лимитами бюджета.
5️⃣ Уровень команды ↔️ Уровень участников
🔘 Если отдельный участник слабее команды, поручите ему тактические задачи под наставничеством.
🔘 Если участник сильнее команды без формального мандата, предложите ему quick‑win проект, чтобы продемонстрировать ценность новых подходов. В противном случае он первый кандидат на выход.
Pro Product
#стратегия
1️⃣ Состав и структура команды
Продукт — это не только код и UX, но и взаимодействие трёх ключевых функций: Discovery (продакты, UX‑исследователи, аналитики), Delivery (разработчики, QA, DevOps) и Go‑to‑Market (маркетинг, продажи, customer success).
На ранних этапах PSF–PMF все эти роли часто работают единым сквадом: это максимизирует скорость общения и позволяет быстро проверять гипотезы «проблема–решение». При подготовке к масштабированию удобно вынести Go‑to‑Market в отдельную группу, чтобы основная команда непрерывно улучшала продукт. На зрелых фазах допустимо формировать три независимых сквада, плюс выделять небольшой disrupt‑R&D‑сквад для новых направлений.
2️⃣ Модель зрелости
Для оценки зрелости продуктовой команды существуют десятки фреймворков, но чаще всего на практике применяют три подхода:
✔️ Thoughtworks DPM³
✔️ Atlassian Team Health Monitor
✔️ Spotify Squad Health Check
В каждом случае короткий воркшоп даёт «радар зрелости» и план улучшений.
Я же предлагаю использовать кастомную четырёхуровневую модель зрелости, которую вы видите на слайде:
1 — Delivery‑Only (стабильные релизы, баг‑фиксинг),
2 — Reactive Discovery (доработка по incoming‑фидбэку),
3 — Proactive Discovery (A/B‑тесты, customer interviews),
4 — Strategic Innovators (участие в портфеле, запуск disrupt‑ и ecosystem‑треков).
Она сочетает строгость DPM³ (четыре чётких уровня вместо шести и 36 практик) и простоту Health Monitor/Health Check (короткие воркшопы и наглядные результаты), но при этом сразу привязывает ваш уровень к выбору стратегий (Run / Change / Disrupt).
3️⃣ Три столпа зрелости
Уровень maturity складывается из 3х компонентов:
✔️ Компетенции. Навыки product discovery, работы с данными, быстрой валидации гипотез, фасилитации.
✔️ Процессы. Отлаженные CI/CD‑пайплайны, code review, регулярность Discovery, наличие Research Repository.
✔️ Мандат. Право принимать решения (в т.ч. kill), бюджет на исследования, доступ к данным, участие в Strategy Sync.
Без хотя бы базового сочетания «компетенции+процессы» ваши PoC‑идеи либо «утонут» в баг‑фиксе, либо не найдут финансирования. Без мандата же даже идеальная команда не сможет влиять на стратегию и портфель.
4️⃣ Уровень зрелости ↔️ Тип стратегии
По мере роста maturity горизонты возможных стратегий расширяются:
Если команда слабее заявленных амбиций, вы рискуете «сгореть»: PoC не пройдут, команда выйдет из цикла continuous learning, а ресурсы будут исчерпаны. Вернитесь к run/change‑фокусу и вложитесь в прокачку навыков и процессов.
Когда же команда сильнее текущих планов, дайте ей mini‑PoC‑мандат — с чёткими kill‑критериями и лимитами бюджета.
5️⃣ Уровень команды ↔️ Уровень участников
💡 Важно: зрелость команды — не линейный путь, а осознанный выбор на основании сочетания имеющихся/желаемых навыков, процессов и организационного мандата. Соответствие стратегии уровню команды позволяет управлять рисками и безопасно двигаться, не «перепрыгивая» без опоры.
Pro Product
#стратегия
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
🚀 Как выбрать стратегию? (3 из 4)
1️⃣ До Problem–Solution Fit
Вы уточняете проблему (у кого, частотность) и тестируете идею решения (работает, готовы платить). Сигналы: положительные отзывы, раннее удержание 20–30 %.
🔘 Проблемная диагностика (run) — глубинные JTBD‑интервью и наблюдения, чтобы подтвердить саму боль без лишних фич.
🔘 Валидация решения (change) — быстрый MVP/PoC, минимальный UI и фокус на проверке ключевой гипотезы ценности.
🔘 Pivot — радикальная смена гипотезы или сегмента, если рост и удержание не растут в первые пилоты.
2️⃣ Launch → PMF
Надо доказать, что продукт можно продавать системно и окупать привлечение клиентов.
Вехи:
Ранний PMF: MoM >15% + Retention 30 ≥30% (органический рост)
Устойчивый PMF: MoM 5–15% + Retention ≥40% + CAC Payback ≤12 мес + LTV:CAC ≥3:1 на протяжении 3-6 месяцев
🔘 Сегментный фокус (run) — выбираете 1–2 сегмента и шлифуете под них value proposition.
🔘 Итерации модели монетизации (change) — тестируете сами модели, проводите ценовые эксперименты.
🔘 Pivot — если спустя несколько кварталов рост < 5 % MoM или удержание «застыло», переходите к новой гипотезе, сегменту или модели.
3️⃣ Масштабирование (Scale‑Up)
У вас есть PMF, хорошая unit economics, пора наращивать объем.
Ключевые метрики: MoM > 15 % (или ≥ 10 % на больших объемах), CAC Payback ≤ 6 мес, LTV:CAC ≥ 4:1, Unit Margin > 20 %.
🔘 Run (run) — максимальная оптимизация ядра: автоматизация, персонализация, рефералки, целевой маркетинг и рост CR воронок.
🔘 Go Up (change) — премиум‑версия с доп‑фичами и/или vip-поддержкой для верхнего сегмента.
🔘 Go Down (change) — вытягивание продуктовой линейки вниз: снижение порога входа для массового рынка.
🔘 Wide: Expansion (change) — копать вширь внутри своей базы: новые сегменты и сценарии использования (upsell и увеличение объёма потребления).
‼️ Disrupt‑in‑Depth (disrupt) — отдельная R&D‑команда строит или встраивает новую технологию, способную заменить текущее ядро.
‼️ Disrupt‑in‑Width (disrupt) — упаковываете продукт для нового «голубого океана» без прямых конкурентов (а-ля Canva).
4️⃣ Плато/Зрелость
Рост стабилизировался (0–5 % MoM), продукт генерирует cash flow, но ядро достигло потолка.
🔘 Customer Retention (run) — loyalty‑программы, персонализация, инициативы для удержания клиентов.
🔘 Product Refresh (run) — редизайн, оптимизация UX/UI, интеграция новых технологий, чтобы «освежить» продукт.
🔘 Wide: Diversification (change) — собственные side‑продукты и сервисы на базе вашей экспертизы.
🔘 Pricing Strategy (change) — динамическое ценообразование, пакеты, акции для разных сегментов и ситуаций.
🔘 Efficiency Strategy (change) — оптимизация процессов, снижение издержек, повышение эффективности.
🔘 Go Deep (change) — укрепляете барьеры входа (патенты, эксклюзивные партнёрства).
🔘 Wide: Ecosystem (change) — строите открытую платформу или маркетплейс: внешние партнёры и разработчики расширяют вашу ценность без роста R&D‑бюджета.
🔘 Localization (change) — адаптация продукта под новые рынки: перевод, локальный UX, интеграции с местными сервисами и учёт регуляторных требований.
5️⃣ Спад
MoM уходит в минус, retention и unit‑метрики падают, продукт теряет актуальность.
🔘 Exit (change) — продажа активов или миграция клиентов на другие решения.
🔘 Niche (run) — сужаете фокус до узкого прибыльного сегмента и оптимизируете продукт под него.
🔘 Integration (change) — предлагаете white‑label/OEM‑решения и встраиваетесь в чужие платформы.
Pro Product
#стратегия
1️⃣ До Problem–Solution Fit
Вы уточняете проблему (у кого, частотность) и тестируете идею решения (работает, готовы платить). Сигналы: положительные отзывы, раннее удержание 20–30 %.
2️⃣ Launch → PMF
Надо доказать, что продукт можно продавать системно и окупать привлечение клиентов.
Вехи:
Ранний PMF: MoM >15% + Retention 30 ≥30% (органический рост)
Устойчивый PMF: MoM 5–15% + Retention ≥40% + CAC Payback ≤12 мес + LTV:CAC ≥3:1 на протяжении 3-6 месяцев
3️⃣ Масштабирование (Scale‑Up)
У вас есть PMF, хорошая unit economics, пора наращивать объем.
Ключевые метрики: MoM > 15 % (или ≥ 10 % на больших объемах), CAC Payback ≤ 6 мес, LTV:CAC ≥ 4:1, Unit Margin > 20 %.
💡 Стратегии Disrupt крайне рискованны на фазе Scale-Up, они могут "съесть" ресурсы ядра. Подходит для компаний с устойчивым cash flow (>$50M ARR) и при замедлении core-метрик >2 кварталов.
4️⃣ Плато/Зрелость
Рост стабилизировался (0–5 % MoM), продукт генерирует cash flow, но ядро достигло потолка.
💡 Good practice: сначала - Retention + Efficiency, потом - Diversification /Localization.
Ecosystem — для гигантов с сетевой моделью.
5️⃣ Спад
MoM уходит в минус, retention и unit‑метрики падают, продукт теряет актуальность.
💡 Важно:✔️ Финансы > Роста: CAC Payback < 12 мес., LTV:CAC > 3 — ваши KPI №1.✔️ Дисциплина > Распыления: На Scale-Up/Зрелости — максимум 1–2 стратегии за раз, ядро в приоритете.✔️ Disrupt ≠ Pivot✔️ Надежда убивает компании в фазе Спада.
Инфографика — лишь шаблон для вдохновения😉
Pro Product
#стратегия
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4❤3
Как определить фазу жизненного цикла продукта? (4 из 4)
Продолжаем тему – сегодня разбираем через какие измерения можно выяснить на каком этапе находится ваш продукт.
🚀 Спрос → Growth MoM
Вопрос: есть ли устойчивый рынок для вашего продукта?
Метрика: (MRRₜ – MRRₜ₋₁)/MRRₜ₋₁, скользящее среднее за 6–12 мес.
Что показывает: способность продукта генерировать рост без временных «всплесков» рекламы.
🔄 Качество дохода → Retention / NRR
Вопрос: насколько «липким» оказывается ваш продукт?
Метрика: cohort-retention 30/90/180 дн. (B2C) или Net Revenue Retention (B2B).
Что показывает: процент пользователей или выручки, остающихся с вами спустя время. 30-дневный retention > 20 % уже считается редкостью для масс-маркет B2C.
💰 Экономика клиента → CAC-Payback
Вопрос: когда мы окупаем расходы на привлечение?
Метрика: CAC ÷ (ARPU × валовая маржа) = месяцы до возврата затрат.
Почему Payback: в отличие от соотношений LTV/CAC или просто LTV, Payback показывает скорость возврата инвестиций, критичную для управления кэш-позицией и рисками «выгорания» бюджета.
🔥 Эффективность капитала → Burn Multiple
Вопрос: сколько капитала «сгорает» на единицу роста?
Метрика: Net Burn ÷ Net New ARR за период.
Что показывает: экономическую устойчивость — чем меньше, тем лучше.
⚙️ Операционная готовность → процессы
Вопрос: готова ли команда масштабировать без провалов?
Метрика: наличие DevOps/CI-CD, observability, on-call-рутины, кросс-функциональных команд.
Что показывает: зрелость инфраструктуры и процессов, без которых даже «выстреливающий» продукт может остановиться из-за инцидентов.
🛠 Упрощённый алгоритм диагностики
1️⃣ Соберите данные по всем пяти метрикам за 6–12 мес.
2️⃣ Определите фазу каждой метрики по порогам (см. таблицу👆🏻она шаблонизирует прогрессию метрик по мере роста продукта, но это не догма - двигайте цифры под свой продукт, рынок и бизнес-модель).
3️⃣ Фаза продукта = минимум из пяти фаз (самое слабое измерение).
4️⃣ Действуйте: устраните узкое место, прежде чем двигаться дальше; выбирайте стратегию в соответствии с фазой.
📋 Пример диагностики
🚩 Типичные ошибки
❌ Игнорировать Burn Multiple при высоком росте GMV — vanity metric, может скрыть огромные траты.
❌ Слишком большое значение придавать возрасту продукта или размеру команды — один стартап в 3 года может быть в Launch, а другая в 3 месяца — в Scale, если цифры соответствуют.
❌ Сравнивать Retention B2C и NRR B2B напрямую — это разные вещи, разные окна и разные бизнес-модели.
Pro Product
#стратегия
Продолжаем тему – сегодня разбираем через какие измерения можно выяснить на каком этапе находится ваш продукт.
🚀 Спрос → Growth MoM
Вопрос: есть ли устойчивый рынок для вашего продукта?
Метрика: (MRRₜ – MRRₜ₋₁)/MRRₜ₋₁, скользящее среднее за 6–12 мес.
Что показывает: способность продукта генерировать рост без временных «всплесков» рекламы.
🔄 Качество дохода → Retention / NRR
Вопрос: насколько «липким» оказывается ваш продукт?
Метрика: cohort-retention 30/90/180 дн. (B2C) или Net Revenue Retention (B2B).
Что показывает: процент пользователей или выручки, остающихся с вами спустя время. 30-дневный retention > 20 % уже считается редкостью для масс-маркет B2C.
💰 Экономика клиента → CAC-Payback
Вопрос: когда мы окупаем расходы на привлечение?
Метрика: CAC ÷ (ARPU × валовая маржа) = месяцы до возврата затрат.
Почему Payback: в отличие от соотношений LTV/CAC или просто LTV, Payback показывает скорость возврата инвестиций, критичную для управления кэш-позицией и рисками «выгорания» бюджета.
🔥 Эффективность капитала → Burn Multiple
Вопрос: сколько капитала «сгорает» на единицу роста?
Метрика: Net Burn ÷ Net New ARR за период.
Что показывает: экономическую устойчивость — чем меньше, тем лучше.
⚙️ Операционная готовность → процессы
Вопрос: готова ли команда масштабировать без провалов?
Метрика: наличие DevOps/CI-CD, observability, on-call-рутины, кросс-функциональных команд.
Что показывает: зрелость инфраструктуры и процессов, без которых даже «выстреливающий» продукт может остановиться из-за инцидентов.
Эти пять показателей ортогональны: вместе они закрывают
спрос → качество дохода → экономику клиента → эффективность капитала → операционную готовность.
🛠 Упрощённый алгоритм диагностики
📋 Пример диагностики
Допустим, ваш продукт за последний квартал:
Growth MoM: 12 % (PMF)
CAC‑Payback: 8 мес (PMF)
Retention 30 d: 25 % (PMF, порог 20 %)
Burn Multiple: 1.8 (PMF, порог для PMF ≤ 2)
Орг‑готовность: есть DevOps/CI‑CD, но нет on‑call (Launch)
→ Минимум фаз = Launch → продукт «заблокирован» между Launch и PMF:✔️ Наладить орг‑процессы (on‑call, observability, SLO/SLI),✔️ Повысить 30‑дневный retention до ≥ 40 % через онбординг и ре‑энгейджмент.
После этого вы сможете полноценно выйти на фазу PMF и безопасно наращивать маркетинг и продажи.
💡 Важно: жизненные циклы продукта и используемой в нём технологии не одно и то же, и они редко совпадают. Задача CPO сглаживать это расхождение, привязывая выпуск фич и финансовые цели к ключевым техническим обновлениям и миграциям.
Pro Product
#стратегия
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5
Хочу сегодня поднять тему, за которую меня можно растащить “на сотню маленьких медвежат” © Но, если честно, на то и надежда - очень уж хочется спровоцировать вас на какую-то дискуссию 😁
Итак, как продакт, я нахожу вакансии в финтехе абсолютно непривлекательными. Независимо от бренда, влияния, огромной базы пользователей, зарплаты и бла-бла-бла-бла-бла… И вот почему 👇
1️⃣ Core-продукты финтеха — вещь довольно сомнительная с точки зрения возможности нарастить в них какую-то ценность, за которую можно взять деньги. По сути это нечто вроде инфраструктуры, и, соответственно, чем она дешевле, доступнее и незаметней, тем лучше. Да, есть еще такие атрибуты, как безопасность и прозрачность, но брать дополнительные деньги за то, что вы просто делаете свою работу качественно, кажется мне за гранью добра и зла. В идеале для пользователя это стоит 0, что бы вы ни придумали, при этом если что-то не работает, вас все начинают ненавидеть.
2️⃣ Вы можете мне сказать, что нормальные компании это тоже понимают, поэтому вместо крохоборства (микро комиссий на большом масштабе) пытаются монетизировать аудиторию или данные, выстраивая экосистемы (часто через партнерства). Ну и вообще не core-ом единым, есть еще growth-позиции… Но давайте будем честны: в таких продуктах вы вряд ли разовьете навыки discovery, проектирования или построите полноценную стратегию. Скорее всего, вы будете заниматься интеграцией партнеров или привлечением пользователей. Всё это приведет к тому, что эксперименты, сами проекты и проектные команды будут выглядеть совершенно иначе, чем в других продуктах на рынке.
Короче, скорее всего, вы станете кем-то вроде, как сейчас модно говорить, “delivery-менеджера”. И самое страшное — при этом вас будут называть "продактом". И с этими вводными вы потом будете искать работу. Ещё страшнее, что людей с подобным, будем откровенны, операционным и/или проектным опытом и записью “менеджер продукта” в трудовой на рынке довольно много (ведь в РФ много действительно крутых компаний в сфере финтеха), как и руководителей таких подразделений с записью "CPO". И это затуманивает восприятие нашей и без того не всем понятной профессии 🙄
Поэтому мой вердикт всегда один — неинтересно, ни в какой роли.
И да, поймите правильно, я вовсе не ставлю под сомнение важность и крутизну финтеха, как бизнеса ‼️
Просто продакты более одного там не нужны.имхо
Pro Product
#Философия
Итак, как продакт, я нахожу вакансии в финтехе абсолютно непривлекательными. Независимо от бренда, влияния, огромной базы пользователей, зарплаты и бла-бла-бла-бла-бла… И вот почему 👇
1️⃣ Core-продукты финтеха — вещь довольно сомнительная с точки зрения возможности нарастить в них какую-то ценность, за которую можно взять деньги. По сути это нечто вроде инфраструктуры, и, соответственно, чем она дешевле, доступнее и незаметней, тем лучше. Да, есть еще такие атрибуты, как безопасность и прозрачность, но брать дополнительные деньги за то, что вы просто делаете свою работу качественно, кажется мне за гранью добра и зла. В идеале для пользователя это стоит 0, что бы вы ни придумали, при этом если что-то не работает, вас все начинают ненавидеть.
2️⃣ Вы можете мне сказать, что нормальные компании это тоже понимают, поэтому вместо крохоборства (микро комиссий на большом масштабе) пытаются монетизировать аудиторию или данные, выстраивая экосистемы (часто через партнерства). Ну и вообще не core-ом единым, есть еще growth-позиции… Но давайте будем честны: в таких продуктах вы вряд ли разовьете навыки discovery, проектирования или построите полноценную стратегию. Скорее всего, вы будете заниматься интеграцией партнеров или привлечением пользователей. Всё это приведет к тому, что эксперименты, сами проекты и проектные команды будут выглядеть совершенно иначе, чем в других продуктах на рынке.
Короче, скорее всего, вы станете кем-то вроде, как сейчас модно говорить, “delivery-менеджера”. И самое страшное — при этом вас будут называть "продактом". И с этими вводными вы потом будете искать работу. Ещё страшнее, что людей с подобным, будем откровенны, операционным и/или проектным опытом и записью “менеджер продукта” в трудовой на рынке довольно много (ведь в РФ много действительно крутых компаний в сфере финтеха), как и руководителей таких подразделений с записью "CPO". И это затуманивает восприятие нашей и без того не всем понятной профессии 🙄
Поэтому мой вердикт всегда один — неинтересно, ни в какой роли.
И да, поймите правильно, я вовсе не ставлю под сомнение важность и крутизну финтеха, как бизнеса ‼️
Просто продакты более одного там не нужны.имхо
Pro Product
#Философия
👍4😁1
Discovery backlog и оценка рынка
Сегодня про Discovery backlog — список гипотез и идей, которые мы отбираем для экспериментов (Exploration бюджет), прежде чем вкладывать в них значимые ресурсы. А в бэклоге главная ценность — скоринговые модели: набор факторов для приоритизации инициатив. Можно взять стандартные фреймворки (Lean, ICE, RICE, HEART, AARRR…) или сделать кастомную модель. Я предпочитаю второе — так проще привязать скоринг к стратегическим целям.
Поскольку со стандартными методами скоринга знакомы все, сегодня сосредоточимся на одном факторе для предварительного отбора в Discovery backlog — прогнозе эффекта от запуска. Этот показатель есть в любой модели, но именно на этапе черновой фильтрации ему стоит уделить особое внимание.
Пару оговорок об оценках на этапе Discovery:
1️⃣ Финансовые метрики (NPV, ROI, PBP, IRR) в Discovery почти не применимы, потому что:
– точные прогнозы часто недоступны, а сложные расчёты замедляют скорость принятия решений при том, что проверка гипотез требует динамики;
– на ранних стадиях также важна проверка ценности (проблем/решений), а не детальная экономическая модель.
2️⃣ Сравнение «оптимизирующих» и «генерирующих» фич в одном списке приводит к перекосу:
– фичи для улучшения воронки требуют эксперимента и анализа метрик, прежде чем переводить эффект в деньги;
– фичи для новых потоков дохода проще оценить сразу, но по ним в Discovery мы делаем лишь грубую оценку.
Для высокоуровневой оценки эффекта и фильтрации гипотез в Discovery backlog можно применить упрощённый top‑down‑подход — PAM → TAM → SAM , дополненный Bottom-Up предположениями (SOM).
Идея как будто простая - двигаясь сверху вниз нужно сужать рынок фичи, двигаясь снизу вверх можно понять сколько с ее помощью можно заработать в наших ограничениях. Но на деле оказывается не все так просто.
У всех возникает ряд вопросов: как двигаться (в людях/компаниях и/или деньгах; через какие факторы сужать рынок на каждом шаге), где брать данные и как с ними работать, наконец, как быть если ты - лишь часть цепочки создания ценности, но cash flow проходит через тебя?
И если вы будете искать информацию о том, как это правильно делать, вы не найдете ни одного однозначного ответа. Поэтому моя интерпретация, выработанная в результате неоднократных подходов к снаряду, тоже имеет право на существование 😁
Enjoy!👇
PAM
TAM
SAM
SOM
Pro Product
#Стратегия #Рынок #Инструменты
Сегодня про Discovery backlog — список гипотез и идей, которые мы отбираем для экспериментов (Exploration бюджет), прежде чем вкладывать в них значимые ресурсы. А в бэклоге главная ценность — скоринговые модели: набор факторов для приоритизации инициатив. Можно взять стандартные фреймворки (Lean, ICE, RICE, HEART, AARRR…) или сделать кастомную модель. Я предпочитаю второе — так проще привязать скоринг к стратегическим целям.
Поскольку со стандартными методами скоринга знакомы все, сегодня сосредоточимся на одном факторе для предварительного отбора в Discovery backlog — прогнозе эффекта от запуска. Этот показатель есть в любой модели, но именно на этапе черновой фильтрации ему стоит уделить особое внимание.
Пару оговорок об оценках на этапе Discovery:
1️⃣ Финансовые метрики (NPV, ROI, PBP, IRR) в Discovery почти не применимы, потому что:
– точные прогнозы часто недоступны, а сложные расчёты замедляют скорость принятия решений при том, что проверка гипотез требует динамики;
– на ранних стадиях также важна проверка ценности (проблем/решений), а не детальная экономическая модель.
2️⃣ Сравнение «оптимизирующих» и «генерирующих» фич в одном списке приводит к перекосу:
– фичи для улучшения воронки требуют эксперимента и анализа метрик, прежде чем переводить эффект в деньги;
– фичи для новых потоков дохода проще оценить сразу, но по ним в Discovery мы делаем лишь грубую оценку.
Для высокоуровневой оценки эффекта и фильтрации гипотез в Discovery backlog можно применить упрощённый top‑down‑подход — PAM → TAM → SAM , дополненный Bottom-Up предположениями (SOM).
Идея как будто простая - двигаясь сверху вниз нужно сужать рынок фичи, двигаясь снизу вверх можно понять сколько с ее помощью можно заработать в наших ограничениях. Но на деле оказывается не все так просто.
У всех возникает ряд вопросов: как двигаться (в людях/компаниях и/или деньгах; через какие факторы сужать рынок на каждом шаге), где брать данные и как с ними работать, наконец, как быть если ты - лишь часть цепочки создания ценности, но cash flow проходит через тебя?
И если вы будете искать информацию о том, как это правильно делать, вы не найдете ни одного однозначного ответа. Поэтому моя интерпретация, выработанная в результате неоднократных подходов к снаряду, тоже имеет право на существование 😁
Enjoy!👇
PAM
TAM
SAM
SOM
Pro Product
#Стратегия #Рынок #Инструменты
👍2❤1
PAM (Potential Addressable Market)
Определение: Если ваш продукт купит вся целевая аудитория с учетом трендов внутри нее и ее привычек. И это нестандартное определение ☝🏻
Сужение: демография, география и/или язык, инфраструктура (проникновение интернета, наличие смартфона и т.п.), интерес/причастность к проблеме, которую решает продукт... + поправка на тренд
Подход:
Где брать данные: Статистические отчеты, демографические данные, исследования инфраструктурных рынков, исследования в сфере вашего продукта, прогнозы трендов. Научитесь пользоваться chat GPT - он поможет как найти источники, так и интерпретировать информацию из них‼️
Пример:
PAM может быть меньше TAM, но очень-очень редко. И вам вряд ли будет интересен такой рынок.
TAM
SAM
SOM
Pro Product
#Стратегия #Рынок #Инструменты
Определение: Если ваш продукт купит вся целевая аудитория с учетом трендов внутри нее и ее привычек. И это нестандартное определение ☝🏻
Сужение: демография, география и/или язык, инфраструктура (проникновение интернета, наличие смартфона и т.п.), интерес/причастность к проблеме, которую решает продукт... + поправка на тренд
Подход:
Люди/Компании × ваша цена/медиана стоимости продукта конкурентов × количество покупок за период
Где брать данные: Статистические отчеты, демографические данные, исследования инфраструктурных рынков, исследования в сфере вашего продукта, прогнозы трендов. Научитесь пользоваться chat GPT - он поможет как найти источники, так и интерпретировать информацию из них
Пример:
Если вся ваша целевая аудитория с учетом трендов составит 38 миллионов русскоязычных женщин 14-50 лет, активно интересующихся одеждой, и вы предполагаете, что каждая из них могла бы потратить в среднем $50 на вашу услугу в год, PAM = 38 млн × $50 = $1,9 млрд.
PAM может быть меньше TAM, но очень-очень редко. И вам вряд ли будет интересен такой рынок.
TAM
SAM
SOM
Pro Product
#Стратегия #Рынок #Инструменты
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
TAM (Total Addressable Market)
Определение: Если купит вся целевая аудитория без учета трендов.
Сужение: демография, география и/или язык, инфраструктура (проникновение интернета, наличие телефона и т.п.), интерес/причастность к проблеме, которую решает продукт...
Подход:
Где брать данные: Статистические отчеты, демографические данные, исследования инфраструктурных рынков, исследования в сфере вашего продукта.
Пример:
И да, TAM может быть большим, но особенно не радуйтесь, лучше подумайте о критичных признаках вашей аудитории, например, отсутствие/наличие какой-либо болезни или умение программировать. Чем точнее вы определите вашу аудиторию, тем меньше вы будете галлюцинировать 🙂
PAM
SAM
SOM
Pro Product
#Стратегия #Рынок #Инструменты
Определение: Если купит вся целевая аудитория без учета трендов.
Сужение: демография, география и/или язык, инфраструктура (проникновение интернета, наличие телефона и т.п.), интерес/причастность к проблеме, которую решает продукт...
Подход:
Люди/Компании × ваша цена/медиана стоимости продукта конкурентов × количество покупок за период
Где брать данные: Статистические отчеты, демографические данные, исследования инфраструктурных рынков, исследования в сфере вашего продукта.
Пример:
Если вся ваша целевая аудитория без учета трендов на сегодня составляет 30 миллионов, а стоимость также $50 в год, TAM = 30 млн × $50 = $1,5 млрд и это значит, что PAM = 127% TAM.
И да, TAM может быть большим, но особенно не радуйтесь, лучше подумайте о критичных признаках вашей аудитории, например, отсутствие/наличие какой-либо болезни или умение программировать. Чем точнее вы определите вашу аудиторию, тем меньше вы будете галлюцинировать 🙂
PAM
SAM
SOM
Pro Product
#Стратегия #Рынок #Инструменты
👍2
SAM (Serviceable Available Market)
Определение: Часть ЦА, которая уже покупает/решает проблему любым из возможных способов.
Сужение: + факт потребления через определенный канал (онлайн/офлайн).
Подход:
✔️ Здесь можно брать цифры из готовых отчетов (даже в деньгах, если стоимость вашего решения примерно такая же, как у конкурентов, в противном случае попытайтесь пересчитать деньги в людей/компании), но процесс извлечения данных будет сложным: нужно будет определить все рынки “заменителей”, учесть их разную структуру и как-то учесть пресечения аудитории. А также не забудьте о сужении, которое вы применяли выше, его нужно транслировать.
✔️Если же на рынке нет публичных компаний, придется проявить большую изобретательность. Например, отталкиваться от поисковой выдачи по вашему основному запросу, посещаемости этих сайтов/приложений, залезть в СПАРК/Rusprofile и т.п. В принципе это полезно сделать даже если отчеты есть - для проверки себя.
Где брать данные: Рыночные отчеты, финансовые показатели и отчеты лидеров отрасли, исследования пользователей, Similarweb и т.п.
Пример:
SAM не может быть больше ТAM.
PAM
TAM
SOM
Pro Product
#Стратегия #Рынок #Инструменты
Определение: Часть ЦА, которая уже покупает/решает проблему любым из возможных способов.
Сужение: + факт потребления через определенный канал (онлайн/офлайн).
Подход:
Люди/Компании × ваша цена/медиана стоимости продукта конкурентов × количество покупок за период
✔️ Здесь можно брать цифры из готовых отчетов (даже в деньгах, если стоимость вашего решения примерно такая же, как у конкурентов, в противном случае попытайтесь пересчитать деньги в людей/компании), но процесс извлечения данных будет сложным: нужно будет определить все рынки “заменителей”, учесть их разную структуру и как-то учесть пресечения аудитории. А также не забудьте о сужении, которое вы применяли выше, его нужно транслировать.
✔️Если же на рынке нет публичных компаний, придется проявить большую изобретательность. Например, отталкиваться от поисковой выдачи по вашему основному запросу, посещаемости этих сайтов/приложений, залезть в СПАРК/Rusprofile и т.п. В принципе это полезно сделать даже если отчеты есть - для проверки себя.
Где брать данные: Рыночные отчеты, финансовые показатели и отчеты лидеров отрасли, исследования пользователей, Similarweb и т.п.
Пример:
Компания А производит аналогичный продукт и за прошлый год имела оборот X. Компании B и C, с оборотами Y и Z соответственно, представляют собой основные альтернативы, и они работают не только с вашей ЦА. Наша цена составляет $50 и примерно совпадает с ценой компании А. Для расчета SAM, берем оборот компании А и пересчитываем обороты B и C по нашей цене с поправкой на ЦА. И это W% от TAM.
SAM не может быть больше ТAM.
PAM
TAM
SOM
Pro Product
#Стратегия #Рынок #Инструменты
👍2
SOM (Serviceable Obtainable Market)
Определение: Часть ЦА, которая купит именно у нас.
Сужение: +ваши ограничения: JTBD или кейс, бюджет на продвижение, каналы привлечения, конверсии, конкурентные факторы и т.п.
Подход: чтобы определить SOM вам нужно просуммировать потенциальный доход от каждого канала. Иными словами это считается снизу - от ваших ресурсов.
✔️ Ваша цена - очень важный момент для сервисов а-ля агрегатор (где вы лишь часть цепочки создания ценности): если до этого шага можно было использовать цены конечной услуги, то здесь нужно считать именно свою часть (комиссию).
✔️ Объем аудитории - статистические данные, например, об объеме поисковых запросов вашей ЦА или проходимости какого-то офлайнового места за период.
✔️ Доля охвата по бюджету - оценить затраты на рекламу и уровень активности конкурентов с помощью специальных сервисов. Если это невозможно, попробуйте хотя бы подсчитать их число исходя из поисковой выдачи, и используйте дробь где в числителе - 1, а в знаменателе - количество конкурентов.
✔️Конверсия - используйте свои данные или бенчмарки.
Где брать данные: Аналитика бюджета и сплита, данные о конверсиях; WordStat, Google Trends, Google planner - помогут собрать семантическое ядро и понять уровень конкуренции; SimilarWeb, SEMrush, SpyFu - помогут лучше изучить конкуренцию и семантическое ядро; встроенная аналитика Instagram* и других площадок поможет понять общие объемы ЦА в канале; открытые источники и ChatGPT - помогут с бенчмарками, ну и в целом.
Пример:
Если вы собираетесь использовать данные для приоритезации, можно ограничиться только SOM. Понимание SAM и TAM пригодятся разве что для “торговли” за ресурсы или произведения впечатления на инвестора.
Надеюсь, мой разбор сделает вашу жизнь чуточку легче😊
PAM
TAM
SAM
Pro Product
*запрещен в РФ
#Стратегия #Рынок #Инструменты
Определение: Часть ЦА, которая купит именно у нас.
Сужение: +ваши ограничения: JTBD или кейс, бюджет на продвижение, каналы привлечения, конверсии, конкурентные факторы и т.п.
Подход: чтобы определить SOM вам нужно просуммировать потенциальный доход от каждого канала. Иными словами это считается снизу - от ваших ресурсов.
Доход в канале = Ваша цена × Объем аудитории × Доля охвата по бюджету или Коэффициент конкуренции × Конверсия
✔️ Ваша цена - очень важный момент для сервисов а-ля агрегатор (где вы лишь часть цепочки создания ценности): если до этого шага можно было использовать цены конечной услуги, то здесь нужно считать именно свою часть (комиссию).
✔️ Объем аудитории - статистические данные, например, об объеме поисковых запросов вашей ЦА или проходимости какого-то офлайнового места за период.
✔️ Доля охвата по бюджету - оценить затраты на рекламу и уровень активности конкурентов с помощью специальных сервисов. Если это невозможно, попробуйте хотя бы подсчитать их число исходя из поисковой выдачи, и используйте дробь где в числителе - 1, а в знаменателе - количество конкурентов.
✔️Конверсия - используйте свои данные или бенчмарки.
Где брать данные: Аналитика бюджета и сплита, данные о конверсиях; WordStat, Google Trends, Google planner - помогут собрать семантическое ядро и понять уровень конкуренции; SimilarWeb, SEMrush, SpyFu - помогут лучше изучить конкуренцию и семантическое ядро; встроенная аналитика Instagram* и других площадок поможет понять общие объемы ЦА в канале; открытые источники и ChatGPT - помогут с бенчмарками, ну и в целом.
Пример:
Дано:
✔️У вас 2 канала: Поиск и Pinterest.
✔️Вы планируете вести трафик в веб-приложение для подбора косметики с помощью AI.
✔️Услуга стоит 2К руб.
Расчет:
✔️С помощью Google Keyword Planner, WordStat, Ahrefs или SEMrush собрали семантическое ядро. Получилось X запросов в Google и Y в Яндексе.
✔️ C помощью встроенной статистики Pinterest оценили количество запросов там - Z и сопоставили общим количеством ЦА для перепроверки.
✔️ C помощью SEO-инструментов оценили уровень конкуренции в каналах, получили коэффициент 1/3 и 1/4.
✔️ Бенчмарки по конверсиям нашли с помощью chatGPT.
✔️ Рассчитали все по формуле выше для каждого канала.
✔️ Сложили и получили SOM.
Если вы собираетесь использовать данные для приоритезации, можно ограничиться только SOM. Понимание SAM и TAM пригодятся разве что для “торговли” за ресурсы или произведения впечатления на инвестора.
Надеюсь, мой разбор сделает вашу жизнь чуточку легче
PAM
TAM
SAM
Pro Product
*запрещен в РФ
#Стратегия #Рынок #Инструменты
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3❤1
Вот уж не думала, что тема моего сегодняшнего поста может быть интересна в 2024 году для людей, которые занимаются разработкой продуктов. Но одна история, которую я узнала буквально на прошлых выходных, очень меня повеселила и заставила таки написать на эту тему 😁
Итак, представьте себе большой банк, большое подразделение, занимающееся внутренними продуктами. Банк пришел ко мнению, что со внутренними продуктами нужно работать также, как со внешними, т.е. сменить подход с сервисного на продуктовый. Большой начальник просит подчиненных накидать новый рабочий процесс. С горем пополам какие-то глобальные части были согласованы, и вот дело доходит до согласования метода приоритезации бэклога. Сотрудники, которых, в основном, не на улице нашли, предлагают разные классные, не очень варианты… А начальник их выслушал и говорит:
Я напоминаю, это банк — структура жутко иерархичная, люди боятся начальнику высказать мнение напрямую. И с помощью всяких наводящих вопросов и примеров пытается объяснить, что MoSCoW не самый подходящий метод, когда речь идёт о бэклоге, а не о функциональности. Чем бесят его ещё больше, и он говорит:
Не знаю чем его так привлек этот метод (надеюсь, не названием 😅). И, надеюсь, никого не уволили, ведь завтра, конечно, никакой первой версии не было 🤭
Но знаю в чём он, собственно говоря, был неправ. Впрочем, предлагаю это решить вам самим, посмотрев мои гайды 👈
Ну а я на всякий случай зафиксирую мысль 👇
Pro Product
#Стратегия #история #Инструменты
Итак, представьте себе большой банк, большое подразделение, занимающееся внутренними продуктами. Банк пришел ко мнению, что со внутренними продуктами нужно работать также, как со внешними, т.е. сменить подход с сервисного на продуктовый. Большой начальник просит подчиненных накидать новый рабочий процесс. С горем пополам какие-то глобальные части были согласованы, и вот дело доходит до согласования метода приоритезации бэклога. Сотрудники, которых, в основном, не на улице нашли, предлагают разные классные, не очень варианты… А начальник их выслушал и говорит:
“Все х.. фигня басурманская, хочу MoSCoW.”
Я напоминаю, это банк — структура жутко иерархичная, люди боятся начальнику высказать мнение напрямую. И с помощью всяких наводящих вопросов и примеров пытается объяснить, что MoSCoW не самый подходящий метод, когда речь идёт о бэклоге, а не о функциональности. Чем бесят его ещё больше, и он говорит:
“MoSCoW. И чтобы завтра была первая версия”.
Не знаю чем его так привлек этот метод (надеюсь, не названием 😅). И, надеюсь, никого не уволили, ведь завтра, конечно, никакой первой версии не было 🤭
Но знаю в чём он, собственно говоря, был неправ. Впрочем, предлагаю это решить вам самим, посмотрев мои гайды 👈
Ну а я на всякий случай зафиксирую мысль 👇
Методов приоритизации действительно очень-очень много. Но они способны давать реальную пользу только если используются в правильном контексте. Как минимум нужно понимать уровень принятия решений, для которых применяется приоритизация. И он может быть стратегическим — когда мы отбираем фичи в roadmap для того, чтобы реализовывать какую-то стратегию. Или тактическим— когда мы реализовываем стратегию и раскладываем функциональность выбранных фичей на релизы.
Pro Product
#Стратегия #история #Инструменты
👍3❤2😁1
Что важнее для успеха продукта/фичи: идея или реализация?
Anonymous Poll
15%
Идея, конечно!
54%
Только реализация.
31%
Я не знаю, покажите результат 😁
Идея или реализация?
Вдохновение поднять эту тему пришло совсем неожиданно. Сижу, смотрю интервью одной успешной предпринимательницы... и просто не могу поверить своим ушам. Во-первых, она искренне убеждена, что её идеи абсолютно уникальны. Во-вторых, считает, что в стартапе всё строится на «фишечке». Наконец, в-третьих, она даже не помнит имена тех, с кем начинала свой проект, и кто чем в нем занимался. Это всё никак не укладывалось у меня в голове — как человек, который действительно САМ построил большой бизнес, может так думать? А потом она упомянула менторов, которые учат мировоззрению, эзотерику, которая помогает выбирать сотрудников и важные даты... Тут многое встало на свои места. И, честно говоря, стало грустно.
К чему я это?
Да к тому, что раньше тоже придавала слишком много значения идеям. Однажды это даже стоило мне оффера.
Представьте: я — почти зелёная пионЭрка, приехала в Москву учиться, ищу свою первую работу в роли продакт-менеджера.
Собеседование с нанимающим менеджером. Хорошая компания, и сейчас вполне успешная. Всё идёт, как мне кажется, отлично: задачу про монетки решила, алгоритм распределения звонков предложила, про построение команды саппорта рассказала, учебной программой похвасталась. И вот под конец он задаёт контрольный вопрос:
Не задумываясь, я выпалила:
Какие у меня были аргументы не помню, да это и не важно. Он просто улыбнулся и сказал:
Я была уверена, что это успех, но это был... урок, который осознала только спустя время 👇
📍Учеба и правда помогла, зафиксировав в моей голове два постулата:
1️⃣ Идеи есть у всех, и всем доступны методы их генерирования. Оригинальных же идей очень мало, особенно если взглянуть на них с точки зрения удовлетворения глубинных человеческих потребностей, которые не меняются тысячелетиями. Новые продукты просто находят, реализовывают и поставляют новые способы их удовлетворения. А раз так, то выигрывает тот, кто может реализовать идею с максимальной выгодой для как можно большего числа людей.
2️⃣ Инвесторы, особенно на ранних стадиях, больше обращают внимание на команду, чем на идею. Почему? Во-первых, см. п. 1. Во-вторых, статистика причин смерти стартапов показывает, что проблемы команды находятся в ТОПе, немного уступая проблемам продукта. Продуктовые проблемы(не нужно/плохо работает/не вовремя) часто возникают как раз из-за увлечённости "гениальной" идеей или из-за отсутствия правильных процессов и ценностей в команде.
📍Ну а опыт... опыт сегодня кричит мне: реализация решает всё. Ты можешь начать с "так себе" идеи, но с правильной командой превратить её в нечто по-настоящему крутое. И наоборот, самая блестящая идея “умрет в переговорках”, если количество “идейных” в команде не будет уравновешено количеством Левшей.
Поэтому сегодня для меня вопрос: "идея или реализация?" - высокоуровневый быстрый маркер реальности продуктового опыта.
Но я бы с удовольствием об этом поспорила 🙃👇
Pro Product
#история #Философия
Вдохновение поднять эту тему пришло совсем неожиданно. Сижу, смотрю интервью одной успешной предпринимательницы... и просто не могу поверить своим ушам. Во-первых, она искренне убеждена, что её идеи абсолютно уникальны. Во-вторых, считает, что в стартапе всё строится на «фишечке». Наконец, в-третьих, она даже не помнит имена тех, с кем начинала свой проект, и кто чем в нем занимался. Это всё никак не укладывалось у меня в голове — как человек, который действительно САМ построил большой бизнес, может так думать? А потом она упомянула менторов, которые учат мировоззрению, эзотерику, которая помогает выбирать сотрудников и важные даты... Тут многое встало на свои места. И, честно говоря, стало грустно.
К чему я это?
Да к тому, что раньше тоже придавала слишком много значения идеям. Однажды это даже стоило мне оффера.
Представьте: я — почти зелёная пионЭрка, приехала в Москву учиться, ищу свою первую работу в роли продакт-менеджера.
Собеседование с нанимающим менеджером. Хорошая компания, и сейчас вполне успешная. Всё идёт, как мне кажется, отлично: задачу про монетки решила, алгоритм распределения звонков предложила, про построение команды саппорта рассказала, учебной программой похвасталась. И вот под конец он задаёт контрольный вопрос:
"Что важнее: идея или реализация?"
Не задумываясь, я выпалила:
"Конечно, идея!"
Какие у меня были аргументы не помню, да это и не важно. Он просто улыбнулся и сказал:
"Будет интересно узнать твой ответ на этот вопрос после того, как ты что-то сделаешь или хотя бы глубже изучишь теорию управления продуктом."
Я была уверена, что это успех, но это был... урок, который осознала только спустя время 👇
📍Учеба и правда помогла, зафиксировав в моей голове два постулата:
1️⃣ Идеи есть у всех, и всем доступны методы их генерирования. Оригинальных же идей очень мало, особенно если взглянуть на них с точки зрения удовлетворения глубинных человеческих потребностей, которые не меняются тысячелетиями. Новые продукты просто находят, реализовывают и поставляют новые способы их удовлетворения. А раз так, то выигрывает тот, кто может реализовать идею с максимальной выгодой для как можно большего числа людей.
2️⃣ Инвесторы, особенно на ранних стадиях, больше обращают внимание на команду, чем на идею. Почему? Во-первых, см. п. 1. Во-вторых, статистика причин смерти стартапов показывает, что проблемы команды находятся в ТОПе, немного уступая проблемам продукта. Продуктовые проблемы
📍Ну а опыт... опыт сегодня кричит мне: реализация решает всё. Ты можешь начать с "так себе" идеи, но с правильной командой превратить её в нечто по-настоящему крутое. И наоборот, самая блестящая идея “умрет в переговорках”, если количество “идейных” в команде не будет уравновешено количеством Левшей.
Поэтому сегодня для меня вопрос: "идея или реализация?" - высокоуровневый быстрый маркер реальности продуктового опыта.
Но я бы с удовольствием об этом поспорила 🙃👇
Pro Product
#история #Философия
👍4
Тут в соседнем канале обсуждали чем страшна токсичность в бизнес-среде и как контролировать свою токсичность. Я подумала - крутая тема, раскрою ее с позиции создания и развития продуктов.
А чем страшна токсичность именно в продуктовой команде? Тем, что она разрушает креативность или творческое начало.
📍Креативность — это не просто способность придумать что-то новое, это целая энергия, которая движет команды и компании вперёд, заставляя находить нестандартные решения. Но вот проблема: токсичная рабочая среда очень легко эту энергию убивает. Как именно это происходит?
1️⃣ Повышенный контроль
Когда каждый твой шаг рассматривают под лупой, креативность куда-то испаряется. Не так ли? Для творчества нужно ощущение свободы и возможность экспериментировать, а они несовместимы с бесконечными отчетами и попытками соответствовать чужим не всегда понятным ожиданиям. Помимо создания атмосферы нервозности и конкурентности излишний контроль сжирает время и силы, которые можно было потратить на созидание.
Маркеры:
🚩 Соотношение отчетных и рабочих активностей в пользу первых.
🚩 Высокий уровень бюрократии (много согласований, решения принимаются медленно).
🚩 Низкая автономность сотрудников.
2️⃣ Стресс и выгорание
Творческий процесс требует “тонких настроек”, но откуда им взяться в токсичной среде, где стресс — это ежедневная реальность? Люди переживают за свою финансовую безопасность, карьеру, думают о том, что скажут коллеги, перерабатывают, не чувствуют возврата затраченной энергии и просто истощаются. В этом состоянии мозг не способен создавать что-то новое — он перераспределяет свои ресурсы, чтобы справляться с угрозами, направляя энергию на выживание и повышение бдительности. Высшие когнитивные функции, включая творческое мышление, в этом случае значительно ослабляются. Источник
Маркеры:
🚩 Частые болезни и повышенная текучесть кадров
🚩 Рост ошибок и ухудшение качества работы
🚩 Постоянные переработки: неадекватная нагрузка и/или требования к скорости
3️⃣ Никакой fair play
Манипуляции и непонятные “правила игры” - классика токсичной среды. Представьте, вы делаете большую важную работу, а ее никто не замечает или ещё хуже — приписывают себе или коллеге, который не принимал никакого участия. Помимо уже описаного в п.2 механизма работы мозга (он переключится на выживание) и очевидной потери мотивации очень важными для продуктовой команды здесь будут эффекты потери доверия и отсутствия желания кооперироваться.
Маркеры:
🚩 Нечеткость ролей, ответственности и критериев оценки эффективности
🚩 Похвала или награды не соответствуют вкладу. Частный случай: провалы - личные, победы - общие.
🚩 Отсутствие кооперации, скрытность, попытки повлиять на атрибуцию успехов любыми методами
🚩 Частые конфликты и напряженность
4️⃣ Критика, сарказм, негатив
Сарказм в малых дозах — это прикольно, но когда вся рабочая атмосфера пропитана насмешками, творческое мышление блокируется. Зачем что-то предлагать, если их или тебя сразу "захейтят"?
Неконструктивная критика и того хуже — твоя инициатива плоха просто потому что это инициатива… или потому что она твоя… да кто там разберет? Ясно только одно: как ее улучшить - неясно.
Наконец, негатив. Во-первых, испытывать его на себе неприятно, особенно, если он не заслужен. Во-вторых, он заразителен, и если вы подхватили эту “бациллу”, вам будет не до творчества.
Маркеры:
🚩 Низкий уровень инициативности (например, нет бэклога)
🚩 Низкий уровень вовлеченности (например, брейнштормы, где все молчат)
🚩 Гнетущая атмосфера на встречах
🚩 Обратная связь всегда негативная
Токсичная рабочая среда — это жесткий блокатор творчества. Самое главное отрицательное влияние именно на продуктовые команды в том, что она порождает страх перед выражением себя и ошибками, переключает мозг в режим выживания и отворачивает людей друг от друга. Cтрах и отсутствие внутренних ресурсов сжирают желание что-то делать на корню.
Уверена, что все испытывали нечто подобное на себе ☝️
А как вы сохраняете себя в такой ситуации?👇
Pro Product
А чем страшна токсичность именно в продуктовой команде? Тем, что она разрушает креативность или творческое начало.
📍Креативность — это не просто способность придумать что-то новое, это целая энергия, которая движет команды и компании вперёд, заставляя находить нестандартные решения. Но вот проблема: токсичная рабочая среда очень легко эту энергию убивает. Как именно это происходит?
1️⃣ Повышенный контроль
Когда каждый твой шаг рассматривают под лупой, креативность куда-то испаряется. Не так ли? Для творчества нужно ощущение свободы и возможность экспериментировать, а они несовместимы с бесконечными отчетами и попытками соответствовать чужим не всегда понятным ожиданиям. Помимо создания атмосферы нервозности и конкурентности излишний контроль сжирает время и силы, которые можно было потратить на созидание.
Маркеры:
2️⃣ Стресс и выгорание
Творческий процесс требует “тонких настроек”, но откуда им взяться в токсичной среде, где стресс — это ежедневная реальность? Люди переживают за свою финансовую безопасность, карьеру, думают о том, что скажут коллеги, перерабатывают, не чувствуют возврата затраченной энергии и просто истощаются. В этом состоянии мозг не способен создавать что-то новое — он перераспределяет свои ресурсы, чтобы справляться с угрозами, направляя энергию на выживание и повышение бдительности. Высшие когнитивные функции, включая творческое мышление, в этом случае значительно ослабляются. Источник
Маркеры:
3️⃣ Никакой fair play
Манипуляции и непонятные “правила игры” - классика токсичной среды. Представьте, вы делаете большую важную работу, а ее никто не замечает или ещё хуже — приписывают себе или коллеге, который не принимал никакого участия. Помимо уже описаного в п.2 механизма работы мозга (он переключится на выживание) и очевидной потери мотивации очень важными для продуктовой команды здесь будут эффекты потери доверия и отсутствия желания кооперироваться.
Маркеры:
4️⃣ Критика, сарказм, негатив
Сарказм в малых дозах — это прикольно, но когда вся рабочая атмосфера пропитана насмешками, творческое мышление блокируется. Зачем что-то предлагать, если их или тебя сразу "захейтят"?
Неконструктивная критика и того хуже — твоя инициатива плоха просто потому что это инициатива… или потому что она твоя… да кто там разберет? Ясно только одно: как ее улучшить - неясно.
Наконец, негатив. Во-первых, испытывать его на себе неприятно, особенно, если он не заслужен. Во-вторых, он заразителен, и если вы подхватили эту “бациллу”, вам будет не до творчества.
Маркеры:
Токсичная рабочая среда — это жесткий блокатор творчества. Самое главное отрицательное влияние именно на продуктовые команды в том, что она порождает страх перед выражением себя и ошибками, переключает мозг в режим выживания и отворачивает людей друг от друга. Cтрах и отсутствие внутренних ресурсов сжирают желание что-то делать на корню.
Уверена, что все испытывали нечто подобное на себе ☝️
А как вы сохраняете себя в такой ситуации?
Pro Product
Please open Telegram to view this post
VIEW IN TELEGRAM
👍7
Наша песня хороша — начинай сначала!
Кто бы мог подумать, что в 2024 году мы всё ещё будем обсуждать, чем отличается проектное управление от продуктового, и какое из них лучше 😒 Даже в крутых компаниях с высоким порогом входа 😎 Даже опытные профессионалы продолжают спорить 🤓 Когда фокусно занимаешься этим вопросом лет десять, в это сложно поверить. Но факты говорят сами за себя: все же знают эти истории, когда проектный офис за один день сделали продуктовым, потому что так “моднее”? Или наоборот — после неудачного запуска все продуктовое вдруг становится не в почете("это они во всем виноваты 😱") и команду переназывают проектным офисом. По сути же в обоих случаях не меняется ничего, кроме места расположения кроватей 🫣🤭
Больших кейсов столкновения подходов тоже предостаточно. Взять хотя бы Boeing, где попытка сократить сроки проекта привела к катастрофе. Продемонстрировав всем, что приоритет проектных целей (запустить продукт быстрее) над продуктовыми (в данном случае — надёжность и безопасность) может стоить компании очень дорого. Впрочем, кейсов со счастливым концом тоже немало.
В чём секрет успеха? Они не выбирали между продуктом и проектом, а сочетали оба подхода:
1️⃣ Понимая разницу и взаимосвязи, синхронизировали разработку и реализацию стратегии (упрощенно — читай метрики).
2️⃣ Внедрили гибридные подходы.
Собственно, этот пост — про разницу, связи и синхронизацию с точки зрения продакта ☝️ Вдруг кому будет полезно 🤗❤️
Ну а следующий будет про гибридные подходы.
p.s.: Проджекты, welcome в комментарии! Очень хочется поспорить 😊
Pro Product
#Стратегия
#Метрики
Кто бы мог подумать, что в 2024 году мы всё ещё будем обсуждать, чем отличается проектное управление от продуктового, и какое из них лучше 😒 Даже в крутых компаниях с высоким порогом входа 😎 Даже опытные профессионалы продолжают спорить 🤓 Когда фокусно занимаешься этим вопросом лет десять, в это сложно поверить. Но факты говорят сами за себя: все же знают эти истории, когда проектный офис за один день сделали продуктовым, потому что так “моднее”? Или наоборот — после неудачного запуска все продуктовое вдруг становится не в почете
Больших кейсов столкновения подходов тоже предостаточно. Взять хотя бы Boeing, где попытка сократить сроки проекта привела к катастрофе. Продемонстрировав всем, что приоритет проектных целей (запустить продукт быстрее) над продуктовыми (в данном случае — надёжность и безопасность) может стоить компании очень дорого. Впрочем, кейсов со счастливым концом тоже немало.
В чём секрет успеха? Они не выбирали между продуктом и проектом, а сочетали оба подхода:
1️⃣ Понимая разницу и взаимосвязи, синхронизировали разработку и реализацию стратегии (упрощенно — читай метрики).
2️⃣ Внедрили гибридные подходы.
Собственно, этот пост — про разницу, связи и синхронизацию с точки зрения продакта ☝️ Вдруг кому будет полезно 🤗❤️
Ну а следующий будет про гибридные подходы.
p.s.: Проджекты, welcome в комментарии! Очень хочется поспорить 😊
Pro Product
#Стратегия
#Метрики
👍4❤1