Очень кратко про сделку Google и Wiz
Зачем: усилить Google Cloud встроенной, мультиоблачной безопасностью и завоевать доверие крупных enterprise‑клиентов.
Почему сейчас: ускоренная AI‑революция создает новые угрозы в облаке, а также снижает рост традиционного поиска, требуя диверсификации доходов.
Почему столько стоит: прошлой осенью Wiz отклонил предложение в $23 млрд и с тех пор вырос до примерно $700 млн ARR, что оправдывает прайс‑тэг в $32 млрд. При этом Wiz оценивается примерно в 46× ARR и демонстрирует рост около 200 % YoY — показатели, характерные для быстрорастущих SaaS‑компаний в сегменте облачной безопасности (у CrowdStrike P/S ≈ 28×, но Wiz растёт быстрее и имеет мало прямых конкурентов; рынок cloud security прогнозируется в $123 млрд к 2032 г.).
На что расчет:
✔️ +2–3% доли рынка Google Cloud — это ~$8–12 млрд дополнительной выручки к 2027 году (при текущей доле GCP в 11%).
✔️ Интеграция с AI-стеком должна быть бесшовной. Например, автоматическое сканирование уязвимостей в моделях Gemini через Wiz API.
✔️ Регуляторные риски не наступят: хотя FTC уже изучает сделки Big Tech в облаке. Возможны требования «не закрывать экосистему» (как в случае с Microsoft и Activision).
Прогноз: 3–5 лет — реалистичный срок, если:
✔️ Кросс-селл: 30% клиентов Wiz подключат Google Cloud (по аналогии с тем, как AWS продвигает Security Hub).
✔️ Синергия с Mandiant/Chronicle: объединение данных о угрозах и автоматизация реагирования.
‼️ Риск перерасхода: Если интеграция затянется (как с Fitbit), а регуляторы наложат ограничения, ROI сместится за горизонт 5+ лет.
Pro Product
#Тренды #Рынок #AI
Зачем: усилить Google Cloud встроенной, мультиоблачной безопасностью и завоевать доверие крупных enterprise‑клиентов.
Почему сейчас: ускоренная AI‑революция создает новые угрозы в облаке, а также снижает рост традиционного поиска, требуя диверсификации доходов.
Почему столько стоит: прошлой осенью Wiz отклонил предложение в $23 млрд и с тех пор вырос до примерно $700 млн ARR, что оправдывает прайс‑тэг в $32 млрд. При этом Wiz оценивается примерно в 46× ARR и демонстрирует рост около 200 % YoY — показатели, характерные для быстрорастущих SaaS‑компаний в сегменте облачной безопасности (у CrowdStrike P/S ≈ 28×, но Wiz растёт быстрее и имеет мало прямых конкурентов; рынок cloud security прогнозируется в $123 млрд к 2032 г.).
На что расчет:
Прогноз: 3–5 лет — реалистичный срок, если:
А как вы готовитесь к грядущим изменениям в вашем флагманском продукте в связи с наступающей эрой AI? 👇
Pro Product
#Тренды #Рынок #AI
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2🔥2❤1
Зачем обычно нанимают продактов?
Довольно скоро после достижения PMF рост за счёт новых клиентов становится слишком дорогим (CAC > LTV), поэтому компании переключаются на монетизацию текущей базы. Отсюда спрос на специалистов, которые умеют с этим работать. И нет, это далеко не только коммерсы и маркетологи ☝🏻Продактов обычно нанимают волнами:
🔘 Scaling: core‑сеньоры для выстраивания архитектуры под механики роста.
🔘 Maturity: growth‑мастера, борющиеся за каждый процент NRR через A/B‑тесты, партнёрства и микро‑улучшения UX.
Если вы пришли “на общих условиях”, велика вероятность, что продукт в одной из этих фаз и перед вами будут поставлены цели, в логике, описанной ниже. И даже если вам не поставили цели (так бывает чаще, чем хотелось бы 😉) — поставьте их сами именно таким образом (разумеется, предварительно проделав работу в соответствии с вашим грейдом и согласовав результат с кем надо 🤭 иначе не полетит )👇🏻
Фокусы → Стратегии → Тактики
├── Go Up - рост за счёт увеличения ценности текущего продукта и вытягивания тарифной/продуктовой линейки в верхний сегмент: можно будет проапгрейдить текущих клиентов и привлечь новых.
│ └── Expansion → Upsell, Usage Expansion.
│
├── Go Down - вытягивание тарифной/продуктовой линейки в нижний сегмент: можно будет привлечь новых клиентов, главное при этом не обесценить текущий продукт и не сканнибализировать уже имеющуюся аудиторию.
│ ├── Localization → Адаптация цен/продукта под регион.
│ └──❓ Expansion (если получается развивать нижний сегмент) → Cross-sell, upsell, usage expansion.
│
└── Wide - горизонтальный рост.
├── Expansion (new use case) → Новые сценарии использования для текущей базы + Upsell и/или Usage expansion
├── Diversification (Side) → Запуск продуктов, дополняющих основной для своей базы + Cross-sell
└── Ecosystem → Партнёрства с чужими продуктами, API-интеграции + Cross-sell
Итак,
✔️ Go Up, Go Down, Wide — это стратегические фокусы (куда будем расти: вверх, вниз, в ширину).
✔️ Expansion, Localization, Diversification — подстратегии (что будем растить: ARPPU/СLTV, GRR/NRR, MRR или базу).
✔️ Upsell, Cross-sell, Usage expansion — тактика или механики роста (как или через что будем растить).
Про механики
📌 Механики — это универсальные инструменты роста, их чаще связывают с Expansion, т.к. это ключевая стратегия после PMF, но они применяются и в других стратегиях.
✔️ Usage expansion → клиент начинает использовать продукт в большем масштабе.
✔️ Up-sell → клиент переходит на более дорогой тариф из-за добавленной ценности/новой функциональности.
✔️ Cross-sell → клиент покупает модули/продукты/услуги, дополняющие основной продукт.
Механики в реальных продуктах часто живут на пересечении монетизационной модели (подписка, транзакции, гибрид), логики ценообразования (фичи, лимиты, условия SLA и т.д.) и поведенческой динамики клиента. Поэтому и метрики для оценки их успешности сложно универсализировать. Впрочем направление мысли тут можно задать - см.скрин
Выберите одну механику, отстройте её и только потом добавляйте следующую. Начните с Upsell - обычно это самый «низко висящий фрукт».ИМХО
💡 Совет: Делайте стратегический выбор!
Pro Product
#Стратегия
#Метрики
Довольно скоро после достижения PMF рост за счёт новых клиентов становится слишком дорогим (CAC > LTV), поэтому компании переключаются на монетизацию текущей базы. Отсюда спрос на специалистов, которые умеют с этим работать. И нет, это далеко не только коммерсы и маркетологи ☝🏻Продактов обычно нанимают волнами:
Если вы пришли “на общих условиях”, велика вероятность, что продукт в одной из этих фаз и перед вами будут поставлены цели, в логике, описанной ниже. И даже если вам не поставили цели (так бывает чаще, чем хотелось бы 😉) — поставьте их сами именно таким образом (разумеется, предварительно проделав работу в соответствии с вашим грейдом и согласовав результат с кем надо 🤭 иначе не полетит )👇🏻
Фокусы → Стратегии → Тактики
├── Go Up - рост за счёт увеличения ценности текущего продукта и вытягивания тарифной/продуктовой линейки в верхний сегмент: можно будет проапгрейдить текущих клиентов и привлечь новых.
│ └── Expansion → Upsell, Usage Expansion.
│
├── Go Down - вытягивание тарифной/продуктовой линейки в нижний сегмент: можно будет привлечь новых клиентов, главное при этом не обесценить текущий продукт и не сканнибализировать уже имеющуюся аудиторию.
│ ├── Localization → Адаптация цен/продукта под регион.
│ └──
│
└── Wide - горизонтальный рост.
├── Expansion (new use case) → Новые сценарии использования для текущей базы + Upsell и/или Usage expansion
├── Diversification (Side) → Запуск продуктов, дополняющих основной для своей базы + Cross-sell
└── Ecosystem → Партнёрства с чужими продуктами, API-интеграции + Cross-sell
Итак,
Expansion Revenue Benchmarks: SaaS с LTV/CAC > 3 достигают ~20 % expansion MRR, а с LTV/CAC > 5 — > 30 %
Про механики
✔️ Usage expansion → клиент начинает использовать продукт в большем масштабе.
✔️ Up-sell → клиент переходит на более дорогой тариф из-за добавленной ценности/новой функциональности.
✔️ Cross-sell → клиент покупает модули/продукты/услуги, дополняющие основной продукт.
Механики в реальных продуктах часто живут на пересечении монетизационной модели (подписка, транзакции, гибрид), логики ценообразования (фичи, лимиты, условия SLA и т.д.) и поведенческой динамики клиента. Поэтому и метрики для оценки их успешности сложно универсализировать. Впрочем направление мысли тут можно задать - см.скрин
Выберите одну механику, отстройте её и только потом добавляйте следующую. Начните с Upsell - обычно это самый «низко висящий фрукт».ИМХО
На мой взгляд, продуктовые команды в основном не страдают от того, что не видят возможности роста — проблема в том, что они пытаются одновременно ухватить всё и всех. Вместо того чтобы фокусироваться, они не рассчитывают силы, распыляются на десяток инициатив и в итоге не доводят до ума ни одну. Это касается и стратегии, и тактики.
Pro Product
#Стратегия
#Метрики
Please open Telegram to view this post
VIEW IN TELEGRAM
❤4🔥2
- Помогите! Сделайте что-нибудь!
- Что случилось, Лунтик?
- Не знаю, но это ужасно! (c)
Чистосердечное признание: я — фанат Discovery. Для меня это самая увлекательная и одна из самых важных частей продуктового процесса.
И, откровенно говоря, я не понимаю, как можно считать, что занимаешь продуктовую позицию, если ты не знаешь ничего ни про пользователей, ни про рынок. Тем более исследовать можно чужими руками и мозгами (если есть бюджет), но личная вовлеченность, особенно на входе, бесценна.имхо
В противном случае возможно вы занимаетесь управлением проектами запусков/доработок, а не развитием продукта.имхо 🫣
Почему это важно? Да потому что очень упрощенно продукт — это прежде всего ответ на вопрос «что делать?», чтобы увеличить ценность для пользователя и, соответственно, стоимость бизнеса. А откуда взять это «что»?
❌ Делать, что говорят
Игнорировать обратную связь или конкретную спущенную задачу/проект, конечно, глупо. Но и слепо следовать любому входящему фидбэку, особенно если он прошёл через призму чьих-то интересов, особенно если у этого кого-то нет фактических полномочий, — минимум непрофессионально, максимум — безответственно. Это прямой путь к feuture factory.
❌ Выдумывать и продавать
Пытаться «родить» инсайты на ходу в переговорке или интерпретировать сухие цифры без понимания «почему» — всё равно что гадать на Таро, а потом мериться... с другими выдумщиками старшими картами в раскладе (if you know what I mean). Это не приблизит вас к достижению бизнес-целей.
✔️ Искать инсайты (в том числе среди фидбэка), оценивать их масштаб, приоритезировать
Только так ваше ЧТО имеет шанс опереться на объективные данные о потребностях рынка. И это не гарантия, а возможность ☝🏻
________________________
Прежде чем поделюсь своими наработками в Discovery, забавная #История
Как-то на собеседовании меня спросили: «Как ты выстраиваешь работу с фидбэком?»
Я ответила, что подход напрямую зависит от зрелости команды и процессов. Если команда только учится поставлять ценность, то само по себе внимание к обратной связи — уже шаг вперёд. Но как только команда выходит на уровень проактивной продуктовой работы, где важно не просто чинить баги или выполнять пожелания парочки ключевых клиентов, а осознанно развивать продукт, — этого становится недостаточно. Тут уже нужны другие подходы: системные, исследовательские, ориентированные на выявление и проверку реальных потребностей рынка.
Собеседник слегка насупился и уточнил: «Что значит "проактивно"? Ты про опросы, мониторинги...?»
Я: «И про это тоже, но скорее про полноценный процесс Discovery.»
Тогда он еще больше напрягся: «Зачем нам тратить ресурсы на какие-то исследования, если у нас уже есть фидбэк?»
Я: «Хм... Исследования вовсе не отменяют фидбэк, просто делают его лишь ОДНИМ ИЗ источников бэклога. Они помогают его систематизировать, отфильтровывать и правильно встраивать в процесс разработки — как на уровне отдельных инициатив, так и на уровне общей стратегии...
Если же задача — поддерживать статус-кво и просто расставлять галочки в трекере, наем продакта, пожалуй, не самое эффективное решение.»
Думаю, не стоит объяснять чем дело закончилось. И да, чувак оказался ССO, а я "странным продактом" 😅
Pro Product
#Процессы
#Философия
#Исследования
- Что случилось, Лунтик?
- Не знаю, но это ужасно! (c)
Чистосердечное признание: я — фанат Discovery. Для меня это самая увлекательная и одна из самых важных частей продуктового процесса.
И, откровенно говоря, я не понимаю, как можно считать, что занимаешь продуктовую позицию, если ты не знаешь ничего ни про пользователей, ни про рынок. Тем более исследовать можно чужими руками и мозгами (если есть бюджет), но личная вовлеченность, особенно на входе, бесценна.имхо
Почему это важно? Да потому что очень упрощенно продукт — это прежде всего ответ на вопрос «что делать?», чтобы увеличить ценность для пользователя и, соответственно, стоимость бизнеса. А откуда взять это «что»?
❌ Делать, что говорят
Игнорировать обратную связь или конкретную спущенную задачу/проект, конечно, глупо. Но и слепо следовать любому входящему фидбэку, особенно если он прошёл через призму чьих-то интересов, особенно если у этого кого-то нет фактических полномочий, — минимум непрофессионально, максимум — безответственно. Это прямой путь к feuture factory.
❌ Выдумывать и продавать
Пытаться «родить» инсайты на ходу в переговорке или интерпретировать сухие цифры без понимания «почему» — всё равно что гадать на Таро, а потом мериться... с другими выдумщиками старшими картами в раскладе (if you know what I mean). Это не приблизит вас к достижению бизнес-целей.
Только так ваше ЧТО имеет шанс опереться на объективные данные о потребностях рынка. И это не гарантия, а возможность ☝🏻
________________________
Прежде чем поделюсь своими наработками в Discovery, забавная #История
Как-то на собеседовании меня спросили: «Как ты выстраиваешь работу с фидбэком?»
Я ответила, что подход напрямую зависит от зрелости команды и процессов. Если команда только учится поставлять ценность, то само по себе внимание к обратной связи — уже шаг вперёд. Но как только команда выходит на уровень проактивной продуктовой работы, где важно не просто чинить баги или выполнять пожелания парочки ключевых клиентов, а осознанно развивать продукт, — этого становится недостаточно. Тут уже нужны другие подходы: системные, исследовательские, ориентированные на выявление и проверку реальных потребностей рынка.
Собеседник слегка насупился и уточнил: «Что значит "проактивно"? Ты про опросы, мониторинги...?»
Я: «И про это тоже, но скорее про полноценный процесс Discovery.»
Тогда он еще больше напрягся: «Зачем нам тратить ресурсы на какие-то исследования, если у нас уже есть фидбэк?»
Я: «Хм... Исследования вовсе не отменяют фидбэк, просто делают его лишь ОДНИМ ИЗ источников бэклога. Они помогают его систематизировать, отфильтровывать и правильно встраивать в процесс разработки — как на уровне отдельных инициатив, так и на уровне общей стратегии...
Если же задача — поддерживать статус-кво и просто расставлять галочки в трекере, наем продакта, пожалуй, не самое эффективное решение.»
Думаю, не стоит объяснять чем дело закончилось. И да, чувак оказался ССO, а я "странным продактом" 😅
💡 Не настаиваю, что мое мнение на этот счет — истина в последней инстанции, однако подсвечиваю какой мощный рычаг представляет собой возможность определять ЧТО делать. Даже если мы говорим не о стратегии, а об Execution, как в этой истории ☝🏻
Pro Product
#Процессы
#Философия
#Исследования
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3😁1
Папу римского выбрали за 2 дня ☝🏻
Почему тогда менеджеров, которые ничего не решают и по факту ни на что не влияют, выбирают по полгода? 😁
#мысливслух
Почему тогда менеджеров, которые ничего не решают и по факту ни на что не влияют, выбирают по полгода? 😁
#мысливслух
😁7
Media is too big
VIEW IN TELEGRAM
Мой топ-10 ошибок в Discovery
Если вы все еще сомневаетесь, что вам нужно владеть навыком исследований, послушайте хотя бы Сэма нашего Альтмана😊 👆🏻
А я пока накидаю самые распространенные ошибки, совершаемые в этом процессе. Как всегда – проверено на себе😉
0️⃣ «Мы итак всё знаем»
Ничего не исследовать или "исследовать", чтобы подтвердить то, что вы итак знаете.
Самоуверенность неизбежно приведет к ошибкам.
1️⃣ Неэтичные методы
Собирать данные скрытно, шпионить, ставить ловушки в UI, проводить скрытые а/б тесты и делать прочие вещи, за которые в лучшем случае будет стыдно.
2️⃣ Непонимание разницы между исследованием проблемы и тестированием решения
Пытаться тестировать фичи, не разобравшись, зачем они вообще нужны.
Проблему мы исследуем, решение — тестируем. И именно в таком порядке! Путаница здесь приводит к тому, что вместо интервью запускаем A/B-тест или наоборот. Думать, что вместо исследования можно обойтись парой фидбэков сюда же. Но классика - это, конечно, пытаться сразу продавать фантазии вместо полноценного Discovery.
3️⃣ Эмоциональная привязанность или отсутствие объективности
Игнорирование результатов, которые противоречат «любимой/правильной» гипотезе. Либо подгон результатов эксперимента.
4️⃣ Discovery как разовое событие
Думать, что Discovery можно сделать один раз, а потом забыть об этом надолго и просто пилить фички.
Другое проявление - исследовать все подряд, либо не использовать результаты, либо двигаться быстрее/медленнее, чем Delivery-команда. Все это следствие не интегрированности Discovery в общий продуктовый процесс.
5️⃣ Увлечение только качественными или только количественными данными
Придумывать "почему", "зачем" или делать вывод о масштабности кейса по интервью.
6️⃣ Процессные проблемы
Весь спектр от неумения искать и формулировать гипотезы, цели, критерии успеха до проблем с приоритезацией, подверженности когнитивным искажениям, некорректный выбор метода и отсутствие необходимых компетенций.
Сюда же отсутствие инструментов, недостаточное или избыточное документирование или отсутствие этапа синтеза.
7️⃣ Недооценка рисков
Игнорирование технических, рыночных или юридических ограничений.
Т.е. принимать решение о внедрении изменений в продукт только на основании успешного теста.
"Продаем всем, кто мы такие чтобы осуждать клиента?"
8️⃣ Не доносить необходимость исследований стейкхолдерам
Например, не пояснять, что исследования не отменяют фидбэк или UX-тесты не всегда «удлиняют выход на рынок», значит нажить себе проблемы.
9️⃣ Не выбирать сегмент и/или контекст
Отличный способ зря потратить время, а в худшем случае еще и сформировать ложные представления.
1️⃣ 0️⃣ Over-research / research paralysis
Не всегда ошибка, но случается в компаниях, где много денег и мало product ownership'а. Можно выйти на рынок позже.
p.s. не понаслышке знаю, что последний совет может триггерить людей c комплексом отличника 😅
Pro Product
#Тренды #Исследования #AI
Если вы все еще сомневаетесь, что вам нужно владеть навыком исследований, послушайте хотя бы Сэма нашего Альтмана
А я пока накидаю самые распространенные ошибки, совершаемые в этом процессе. Как всегда – проверено на себе
Ничего не исследовать или "исследовать", чтобы подтвердить то, что вы итак знаете.
Самоуверенность неизбежно приведет к ошибкам.
Собирать данные скрытно, шпионить, ставить ловушки в UI, проводить скрытые а/б тесты и делать прочие вещи, за которые в лучшем случае будет стыдно.
Пытаться тестировать фичи, не разобравшись, зачем они вообще нужны.
Проблему мы исследуем, решение — тестируем. И именно в таком порядке! Путаница здесь приводит к тому, что вместо интервью запускаем A/B-тест или наоборот. Думать, что вместо исследования можно обойтись парой фидбэков сюда же. Но классика - это, конечно, пытаться сразу продавать фантазии вместо полноценного Discovery.
Игнорирование результатов, которые противоречат «любимой/правильной» гипотезе. Либо подгон результатов эксперимента.
Думать, что Discovery можно сделать один раз, а потом забыть об этом надолго и просто пилить фички.
Другое проявление - исследовать все подряд, либо не использовать результаты, либо двигаться быстрее/медленнее, чем Delivery-команда. Все это следствие не интегрированности Discovery в общий продуктовый процесс.
Придумывать "почему", "зачем" или делать вывод о масштабности кейса по интервью.
Весь спектр от неумения искать и формулировать гипотезы, цели, критерии успеха до проблем с приоритезацией, подверженности когнитивным искажениям, некорректный выбор метода и отсутствие необходимых компетенций.
Сюда же отсутствие инструментов, недостаточное или избыточное документирование или отсутствие этапа синтеза.
Игнорирование технических, рыночных или юридических ограничений.
Т.е. принимать решение о внедрении изменений в продукт только на основании успешного теста.
"Продаем всем, кто мы такие чтобы осуждать клиента?"
Например, не пояснять, что исследования не отменяют фидбэк или UX-тесты не всегда «удлиняют выход на рынок», значит нажить себе проблемы.
Отличный способ зря потратить время, а в худшем случае еще и сформировать ложные представления.
Не всегда ошибка, но случается в компаниях, где много денег и мало product ownership'а. Можно выйти на рынок позже.
💡 Узнали себя? Не страшно - практически невозможно внедрить идеальный Discovery, но можно создать работающую, зрелую и адаптивную систему, близкую к оптимуму для конкретной команды и ее ситуации. Главное - не страдать от несовершенства, и переставлять ноги.
p.s. не понаслышке знаю, что последний совет может триггерить людей c комплексом отличника 😅
Pro Product
#Тренды #Исследования #AI
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3🙏1
This media is not supported in your browser
VIEW IN TELEGRAM
Один к тысяче
Задумывались, каков шанс найти идеальную работу? Не просто «нормальную», а ту самую, где вы — на своём месте, продукт — интересен, команда — вровень, а в культуре, как рыба в воде.
Если вы идёте через стандартный массовый процесс найма — то есть:
📍без рекомендаций,
📍без инсайтов изнутри,
📍по публичным описаниям
то шанс оказаться в такой «идеальной» точке примерно 1 к 1000.
Почему?
Кандидат должен угадать:
🔍 Чего от него ждут (требования реальные и формальные)
🎓 Насколько он подходит (мэтч компетенций с требованиями и собственная оценка этих компетенций)
🔊 Как правильно упаковать свой опыт в ожидания для удачной самопрезентации
🕊 Правильную стратегию (быть собой/казаться лучше/казаться хуже)
Компания должна понять:
🌡 Какие реальные задачи нужно решать
📄 Как упаковать их во внятные требования
💰 Какую мотивацию назначить, чтобы не отпугнуть и не промахнуться
🧑💼 Как провести оценку, не перепутав харизму с экспертизой
🏁 Сколько у них времени на выбор
🤼♂️ Сколько кандидатов штурмуют воронку
И всё это должно совпасть, споткнуться можно на любом шаге.
Где чаще ломается?
📍 У кандидата:
— Самооценка скачет.
— Самопрезентация не соответствует опыту.
— Стратегии как таковой нет, либо есть неподходящая.
📍 У компании:
— В 70% случаев роли описаны по шаблону, а не под реальные цели.
— Оценивать сложно, особенно позиции типа продактов, особенно в темпе.
— Времени мало. Кандидатов или слишком много, или слишком мало.
📉 Так каков шанс совпадения?
Если оооочень упростить, можно представить, что в каждом факторе вероятность успеха = 50% (то есть: да - мэтч или нет - не мэтч), и все факторы независимы, то общая базовая вероятность — это произведение всех частичных вероятностей: 0,5 в 10 степени или примерно 0,001.
В реальности факторы, конечно, не полностью независимы (например, адекватная самооценка кандидата влияет на выбор стратегии самопрезентации) и вероятности не равны 50% (например, чёткие требования компании встречаются в 20% случаев), но это уже индивидуальная ситуация и она может быть как лучше, так и хуже базы ☝️
📊 Немного цифр
Рефералы — 5% всех соискателей, но 30% всех наймов.
Проход первого этапа:
📌 У рефералов — 50%
📌 У остальных — 12%
— WSJ
Как повысить шансы?
🔹 Кандидатам:
🔘 Снижать неопределённость. Узнавайте про реальную культуру: через знакомых, интервью с сотрудниками, даже посты в соцсетях.
🔘 Тестировать гипотезы о себе и рынке, тренировать самопрезентацию. Это Discovery, где продукт — это вы, иначе не понять, как надо.
🔘 Работать с рефералками и нетворкингом.
🔹 Компаниям:
🔘 Отделить реальные требования от "хотелок". Это повышает шанс найти не идеального, а подходящего.
🔘 Обеспечить прозрачность процесса найма (насколько это возможно) — это в ваших интересах не меньше, чем в интересах кандидатов.
🔘 Считывать ценности и стратегии кандидатов:
✔️ Притворяется сильнее, чем есть — амбиции, возможно без фундамента, риск выгорания или хуже — выжигания команды.
✔️ Прячется — иногда из страха, потому что нечего показать, иногда потому что не умеет показать. А может перед вами «лейтенант Коломбо» и это часть стратегии?
✔️ Держится ровно и не старается нравиться — не впишется в культуру, построенную на перегибах и лояльности. У вас такая? Отпустите человека с Богом, даже если он вам очень подходит.
Pro Product
#Рынок
#Компетенции
#Мысливслух
Задумывались, каков шанс найти идеальную работу? Не просто «нормальную», а ту самую, где вы — на своём месте, продукт — интересен, команда — вровень, а в культуре, как рыба в воде.
Если вы идёте через стандартный массовый процесс найма — то есть:
📍без рекомендаций,
📍без инсайтов изнутри,
📍по публичным описаниям
то шанс оказаться в такой «идеальной» точке примерно 1 к 1000.
Почему?
💡 Вся модель найма — это не отбор лучших, а поиск совпадений в искажённых картинах мира.
Кандидат должен угадать:
🔍 Чего от него ждут (требования реальные и формальные)
🎓 Насколько он подходит (мэтч компетенций с требованиями и собственная оценка этих компетенций)
🔊 Как правильно упаковать свой опыт в ожидания для удачной самопрезентации
🕊 Правильную стратегию (быть собой/казаться лучше/казаться хуже)
Компания должна понять:
🌡 Какие реальные задачи нужно решать
📄 Как упаковать их во внятные требования
💰 Какую мотивацию назначить, чтобы не отпугнуть и не промахнуться
🧑💼 Как провести оценку, не перепутав харизму с экспертизой
🏁 Сколько у них времени на выбор
🤼♂️ Сколько кандидатов штурмуют воронку
И всё это должно совпасть, споткнуться можно на любом шаге.
Где чаще ломается?
📍 У кандидата:
— Самооценка скачет.
— Самопрезентация не соответствует опыту.
— Стратегии как таковой нет, либо есть неподходящая.
📍 У компании:
— В 70% случаев роли описаны по шаблону, а не под реальные цели.
— Оценивать сложно, особенно позиции типа продактов, особенно в темпе.
— Времени мало. Кандидатов или слишком много, или слишком мало.
📉 Так каков шанс совпадения?
Если оооочень упростить, можно представить, что в каждом факторе вероятность успеха = 50% (то есть: да - мэтч или нет - не мэтч), и все факторы независимы, то общая базовая вероятность — это произведение всех частичных вероятностей: 0,5 в 10 степени или примерно 0,001.
В реальности факторы, конечно, не полностью независимы (например, адекватная самооценка кандидата влияет на выбор стратегии самопрезентации) и вероятности не равны 50% (например, чёткие требования компании встречаются в 20% случаев), но это уже индивидуальная ситуация и она может быть как лучше, так и хуже базы ☝️
Иными словами, найти идеальное совпадение кандидата и компании случайным образом почти невозможно.
📊 Немного цифр
Рефералы — 5% всех соискателей, но 30% всех наймов.
Проход первого этапа:
📌 У рефералов — 50%
📌 У остальных — 12%
— WSJ
Как повысить шансы?
🔹 Кандидатам:
Шансы для активного кандидата повышаются до 1 к 20
🔹 Компаниям:
✔️ Притворяется сильнее, чем есть — амбиции, возможно без фундамента, риск выгорания или хуже — выжигания команды.
✔️ Прячется — иногда из страха, потому что нечего показать, иногда потому что не умеет показать. А может перед вами «лейтенант Коломбо» и это часть стратегии?
✔️ Держится ровно и не старается нравиться — не впишется в культуру, построенную на перегибах и лояльности. У вас такая? Отпустите человека с Богом, даже если он вам очень подходит.
💡 Забить на «идеал» (тем более он меняется вместе с вами, да и компании не стоят на месте)?
Или зависеть только от себя, тогда неидеальность не так триггерит?
Каждый решает сам. Но если все же забивать, то хорошо бы расставить красные линии, за которые вы не готовы зайти и фокусно чекать именно их 😉
Pro Product
#Рынок
#Компетенции
#Мысливслух
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5🔥3💯2❤1
Forwarded from Strategic move: стратегия, продукт и AI (Julia Bilinkis)
Прототипирование интерфейсов с помощью AI для продактов, дизайнеров и всех, кто хочет быстрее валидировать идеи, чем я уже попользовалась и что я жду в ближайшее время
Итак, AI - это способ превратить любую идею в рабочий прототип буквально за минуты: сначала делаем дизайн, потом полноценное веб-приложение или сайт можно выкатить прямо из инструментов.
Почему это важно для продактов:
- Быстрая проверка гипотез (MVP за 2 часа, а не 2 недели)
- Уменьшение зависимости от фронта и бэка на ранних этапах
- Больше времени на идеи и сценарии, меньше на разработку
Это не просто дизайн — это путь от идеи к валидации внутри одного инструмента (ассистент в Product Discovery).
Ловите список:
1. Lovable.dev - генерация кода на основе текста: просто опишите, что вы хотите создать, и Lovable сгенерирует фронтенд и бэкенд. В Lovable.dev backend (Supabase), авторизация, интеграции (Stripe) — генерируются автоматически. В Lovable.dev вы можете всё делать визуально, как в Tilda или — и только если нужно, редактировать код. Я пользуюсь для интервью, мне нравится. Косяки тут с дизайном и красивостью - но это не для этого инструмент, а для быстрой проверки ценностного предлложения.
2. Vercel v0 - Vercel v0 уступает Lovable.dev в ряде ключевых сценариев — особенно для продакт-менеджеров, стартаперов и нетехнических пользователей. Фокусируется только на фронтенде - UI-компоненты на React.
Чтобы эффективно использовать v0, нужно понимать React/JSX, уметь править Tailwind, разбираться в Next.js. v0 выдаёт код, который нужно запускать отдельно или деплоить через Vercel.
👉 Для нетехнических продактов или дизайнеров это барьер. Это значит, что вы не можете создать полноценное приложение с логикой, базой данных или авторизацией без дополнительных инструментов и ручной работы. Я пробовала и бросила сразу, потому что мне лень было разбираться.
3. Builder.io - то "frontend-only". Хочешь собрать форму — подключай стороннюю базу данных, API или CMS вручную. AI генерирует блоки, тексты, layout’ы. Короче Webflow с AI-помощником для дизайнеров и контент-команд.
👉 AI помогает генерировать лендинги и контент, я его пробовала и мне не зашло, мне достаточно Lovable.dev.
4. Figma Make (новинка!) - что обещают:
- выделяешь фрейм → AI превращает его в кликабельный прототип
- можно будет дописать промпты и AI изменит внешний вид
- публикация как полноценное web-приложение (интеграция с Supabase)
Итого:
- Vercel v0 — Frontend-конструктор на базе AI, инструмент для front-end разработчиков.
- Lovable.dev — платформа для продактов, дизайнеров и стартаперов, где можно с нуля создать MVP с логикой, без кода и backend-разработки.
- Builder.io + AI Copilot - подходит для лендингов, e-commerce, маркетинга.
- Figma - ждем!
Мои ставки на Figma. Если Figma сделает все хорошо, у нее есть все шансы на победу.
1. Figma уже стандарт де-факто в дизайне, где все продакты, дизайнеры, исследователи уже работают, просто встраивается в привычный флоу.
2. Figma — экосистема, которая быстро растёт (FigJam, Slides, Sites, Make) без смены среды.
Идея и доска — в FigJam
👉 Маппите user flow, pain points, концепции
Первый UI — в Figma Design
👉 Создаёте фреймы, визуальные экраны, wireframes
AI-акселерация — в Figma Make
👉 Выделяете фрейм → AI превращает его в кликабельный прототип
👉 Можно дописать: “Сделай панель с фильтрами и поиском”
Landing Page или Web App — в Figma Sites / Make
👉 Публикация без кода
👉 Бэкенд через Supabase, формы, авторизация
Презентация или питч — в Figma Slides
Поживем увидим!
Итак, AI - это способ превратить любую идею в рабочий прототип буквально за минуты: сначала делаем дизайн, потом полноценное веб-приложение или сайт можно выкатить прямо из инструментов.
Почему это важно для продактов:
- Быстрая проверка гипотез (MVP за 2 часа, а не 2 недели)
- Уменьшение зависимости от фронта и бэка на ранних этапах
- Больше времени на идеи и сценарии, меньше на разработку
Это не просто дизайн — это путь от идеи к валидации внутри одного инструмента (ассистент в Product Discovery).
Ловите список:
1. Lovable.dev - генерация кода на основе текста: просто опишите, что вы хотите создать, и Lovable сгенерирует фронтенд и бэкенд. В Lovable.dev backend (Supabase), авторизация, интеграции (Stripe) — генерируются автоматически. В Lovable.dev вы можете всё делать визуально, как в Tilda или — и только если нужно, редактировать код. Я пользуюсь для интервью, мне нравится. Косяки тут с дизайном и красивостью - но это не для этого инструмент, а для быстрой проверки ценностного предлложения.
2. Vercel v0 - Vercel v0 уступает Lovable.dev в ряде ключевых сценариев — особенно для продакт-менеджеров, стартаперов и нетехнических пользователей. Фокусируется только на фронтенде - UI-компоненты на React.
Чтобы эффективно использовать v0, нужно понимать React/JSX, уметь править Tailwind, разбираться в Next.js. v0 выдаёт код, который нужно запускать отдельно или деплоить через Vercel.
👉 Для нетехнических продактов или дизайнеров это барьер. Это значит, что вы не можете создать полноценное приложение с логикой, базой данных или авторизацией без дополнительных инструментов и ручной работы. Я пробовала и бросила сразу, потому что мне лень было разбираться.
3. Builder.io - то "frontend-only". Хочешь собрать форму — подключай стороннюю базу данных, API или CMS вручную. AI генерирует блоки, тексты, layout’ы. Короче Webflow с AI-помощником для дизайнеров и контент-команд.
👉 AI помогает генерировать лендинги и контент, я его пробовала и мне не зашло, мне достаточно Lovable.dev.
4. Figma Make (новинка!) - что обещают:
- выделяешь фрейм → AI превращает его в кликабельный прототип
- можно будет дописать промпты и AI изменит внешний вид
- публикация как полноценное web-приложение (интеграция с Supabase)
Итого:
- Vercel v0 — Frontend-конструктор на базе AI, инструмент для front-end разработчиков.
- Lovable.dev — платформа для продактов, дизайнеров и стартаперов, где можно с нуля создать MVP с логикой, без кода и backend-разработки.
- Builder.io + AI Copilot - подходит для лендингов, e-commerce, маркетинга.
- Figma - ждем!
Мои ставки на Figma. Если Figma сделает все хорошо, у нее есть все шансы на победу.
1. Figma уже стандарт де-факто в дизайне, где все продакты, дизайнеры, исследователи уже работают, просто встраивается в привычный флоу.
2. Figma — экосистема, которая быстро растёт (FigJam, Slides, Sites, Make) без смены среды.
Идея и доска — в FigJam
👉 Маппите user flow, pain points, концепции
Первый UI — в Figma Design
👉 Создаёте фреймы, визуальные экраны, wireframes
AI-акселерация — в Figma Make
👉 Выделяете фрейм → AI превращает его в кликабельный прототип
👉 Можно дописать: “Сделай панель с фильтрами и поиском”
Landing Page или Web App — в Figma Sites / Make
👉 Публикация без кода
👉 Бэкенд через Supabase, формы, авторизация
Презентация или питч — в Figma Slides
Поживем увидим!
Lovable
AI App Builder | Vibe Code Apps & Websites with AI, Fast
Build apps, websites, and digital products faster using Lovable’s no-code and AI-powered platform, no deep coding skills required.
Мифы про Discovery
Когда кто-то критикует саму идею Discovery, обычно вспоминает великих:
🐎 Генри Форд: «Если бы я спрашивал, чего хотят люди, они бы сказали — быструю лошадь»
🍏 Стив Джобс: «Пользователь сам не знает, чего хочет, пока ты ему это не покажешь»
Эти фразы трактуют как «с пользователями говорить не нужно — надо придумывать». Но на деле они лишь о том, что не нужно задавать тот самый вопрос ("Что делать?" ). Про другие методы исследования, как и путь к правильному решению здесь ничего не говорится.
🧨 Ок, а какие вопросы тогда важны?
✔️ «Как выглядит эта сфера/отрасль/цепочка создания ценности и куда она движется?»
✔️ «В каком мире живет пользователь и/или принимающий решение? Какое место в этом мире занимает интересующий нас процесс/кейс? Как этот процесс сейчас организован? Какие в нем есть проблемы? Насколько они чувствительны и частотны?»
✔️ «Наше решение закрывает проблему? Оно несет ценность/за него готовы заплатить? Оно лучше конкурентов/на нас готовы перейти?»
✔️ «Как сделать наше решение лучше? Мы можем построить бизнес вокруг этого решения?»
1. Погружение в рынок и гипотезы верхнего уровня
Цель: понять рынок, сегменты, тренды.
Методы:
🎓 экспертные интервью
📊 отраслевые исследования
🔗 анализ цепочки создания ценности
🛃 JTBD
📈 конкурентный бенчмарк
📚 форумы, поддержка, отзывы
→ *B2B*: фокус на барьеры, драйверы, цепочки
→ *B2C*: фокус на привычках и массовом поведении
2. Исследование пользователей и проблем
Цель: выявить реальные кейсы, боли, мотивации.
Методы:
🧠 глубинные интервью
🔍 проблемные интервью
🛃 JTBD
📓 дневниковые исследования
📉 анализ поведения и использования → оценка частотности кейса
🧑🔬массовые опросы → оценка частотности кейса
→ *B2B*: важны процессы принятия решений, техдетали, экономика выгоды
→ *B2C*: эмоции, барьеры, сценарии
3. Генерация и тест решений
Цель: понять, работает ли решение.
Методы:
🛠 решенческое интервью
🧪 UX-тест (в т.ч. немодерируемый)
🚀 пилот
🤼♂️ фокус-группа
→ *B2B*: ценность + удобство
→ *B2C*: желание использовать + удобство
4. Оптимизация и масштабирование
Цель: улучшить реализацию, принять решение о масштабе.
Методы:
🧮 A/B-тесты
💼 тестовые продажи
📊 анализ продуктовых метрик ценности
🔁 когортный анализ + воронка
📣 фидбэк
→ *B2B*: фокус на валидации через пилотные продажи, анализ воронки от лида до контракта, метриках ценности, стабильности unit-экономики.
→ *B2C*: акцент на удержании и его повторяемости у разных когорт, CLTV, масштабируемости каналов привлечения.
‼️Важно не начинать с конца — оптимизировать надо только то, что уже подтверждено.
Напрашивается пара вопросов:
1️⃣ Зачем так сложно?
Каждое интервью, UX-тест или A/B — это возможность избежать бОльших потерь впоследствии. Поэтому мантра у команды должна быть "не запуститься быстрее", а "ошибиться быстрее". Но это легко только сказать 😉
2️⃣ Как не впасть в аналитический паралич?
Коротко — принцип минимума достаточности:
🔘 Ищите не «всё», а достаточные ответы для принятия решений
🔘 Комбинируйте методы: глубинка + данные = сила
🔘 Готовьтесь заранее. Исследования ради галочки — трата ресурсов
👥 А что же Джобс и Форд?
На самом деле оба глубоко погружались в контекст:
✔️ Форд наблюдал за фермерами, доставкой молока, поломками телег. Он не спрашивал — он видел, что не работает, что дорого и итеративно устранял барьеры. Да, через фидбэк, пилоты и доработки — как в B2B-Discovery.
✔️ Джобс сам был своим пользователем. Он жил в среде нердов, чувствовал боль, рефлексировал на опыте, прогонял флоу сотни раз, обсуждал с командой, тестировал десятки гипотез уже не на себе. Это ли не качественный B2C-Discovery?
Pro Product
#исследования #философия
Когда кто-то критикует саму идею Discovery, обычно вспоминает великих:
🐎 Генри Форд: «Если бы я спрашивал, чего хотят люди, они бы сказали — быструю лошадь»
🍏 Стив Джобс: «Пользователь сам не знает, чего хочет, пока ты ему это не покажешь»
Эти фразы трактуют как «с пользователями говорить не нужно — надо придумывать». Но на деле они лишь о том, что не нужно задавать тот самый вопрос (
🧨 Ок, а какие вопросы тогда важны?
В общем-то Discovery - это взгляд на мир через эту линзу☝🏻И помочь ее настроить могут не только ненавистные многим опросы 😁
1. Погружение в рынок и гипотезы верхнего уровня
Цель: понять рынок, сегменты, тренды.
Методы:
🎓 экспертные интервью
📊 отраслевые исследования
🔗 анализ цепочки создания ценности
📈 конкурентный бенчмарк
📚 форумы, поддержка, отзывы
→ *B2B*: фокус на барьеры, драйверы, цепочки
→ *B2C*: фокус на привычках и массовом поведении
2. Исследование пользователей и проблем
Цель: выявить реальные кейсы, боли, мотивации.
Методы:
🧠 глубинные интервью
🔍 проблемные интервью
📓 дневниковые исследования
📉 анализ поведения и использования → оценка частотности кейса
🧑🔬массовые опросы → оценка частотности кейса
→ *B2B*: важны процессы принятия решений, техдетали, экономика выгоды
→ *B2C*: эмоции, барьеры, сценарии
3. Генерация и тест решений
Цель: понять, работает ли решение.
Методы:
🛠 решенческое интервью
🧪 UX-тест (в т.ч. немодерируемый)
🚀 пилот
🤼♂️ фокус-группа
→ *B2B*: ценность + удобство
→ *B2C*: желание использовать + удобство
4. Оптимизация и масштабирование
Цель: улучшить реализацию, принять решение о масштабе.
Методы:
🧮 A/B-тесты
💼 тестовые продажи
📊 анализ продуктовых метрик ценности
🔁 когортный анализ + воронка
📣 фидбэк
→ *B2B*: фокус на валидации через пилотные продажи, анализ воронки от лида до контракта, метриках ценности, стабильности unit-экономики.
→ *B2C*: акцент на удержании и его повторяемости у разных когорт, CLTV, масштабируемости каналов привлечения.
‼️Важно не начинать с конца — оптимизировать надо только то, что уже подтверждено.
Напрашивается пара вопросов:
Каждое интервью, UX-тест или A/B — это возможность избежать бОльших потерь впоследствии. Поэтому мантра у команды должна быть "не запуститься быстрее", а "ошибиться быстрее". Но это легко только сказать 😉
Коротко — принцип минимума достаточности:
👥 А что же Джобс и Форд?
На самом деле оба глубоко погружались в контекст:
💡 Discovery — это про любопытство, системное мышление и уважение к реальности. Он помогает не просто бесконечно обсуждать идеи, а превращать их в работающие решения, за которые платят. И совсем неважно каким образом вы к этому приходите, главное - чем раньше столкнешься с реальностью — тем больше шансов, что продукт выживет.
Pro Product
#исследования #философия
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3🔥1
На днях Краснодар стал чемпионом России. Я давно не слежу за футболом, тем более за российским, но за такими личностями, как Галицкий — слежу. И, знаете, мало настолько же вдохновляющих, во всяком случае лично меня, людей. Почему? Потому что в эпоху инфоцыганства (видимости на пустом месте) и феодализма 2.0 (где всё временно и зыбко), люди с ценностями не из категории "power-driven" — редкость. А успешные люди с такими ценностями — нонсенс (в самом хорошем смысле этого слова)!
Можно, конечно, занудно (о, я мастер!) разбирать, почему получается именно у него: self-determination, способность к delay of gratification, openness to experience, servant leadership, высокий локус контроля, везение... вот это вот все. Но лучше я сравню его с другим очень успешным предпринимателем, который тоже имеет интерес в футболе. А еще постараюсь сделать это так, чтобы продуктоводы могли извлечь для себя какую-то практическую ценность.
🏗 Галицкий: Метафора Творца
🔘 Не клуб, а система: Академия, инфраструктура...
→ Продуктовый аналог: Думай не о фиче, а о продукте и его жизненном цикле.
🔘 Минимизация зависимости
→ Продуктовый аналог: свобода действия так долго пока амбиции не попросят инвестиций.
🔘 Краснодар = Люди + Культура: отбор по ценностям, развитие своих
→ Продуктовый аналог: Инвестиции в найм потенциала, обучение, рост внутри. А не "купить звезду".
🔘 Отказ от дорогих трансферов и "моды"
→ Продуктовый аналог: Смелость игнорировать хайп, если тренд не в фокусе твоей стратегии.
🔘 Вовлечение в детали (но не микроменеджмент!)
→ Продуктовый аналог: Держать руку на пульсе видения и контекста, не скатываясь в "тушение пожаров". Знать, про что код и почему именно так, но не писать его за разработчика.
👑 Абрамович: Метафора Правителя
🔘 Быстрый успех через вливание денег
→ Продуктовый аналог: Оборот ≠ зрелость. Купишь трафик, но не лояльность/retention.
🔘 Постоянная смена тренеров ради результата
→ Продуктовый аналог: Частая смена фокуса или людей (особенно ключевых) убивает команду. Хаос ≠ agility.
🔘 Случайность успеха
→ Продуктовый аналог: Можно выстрелить с кривым MVP без Discovery, но это как выиграть в лотерею, в следующий раз не повезет, а амбиции уже есть. Удача ≠ метод.
🔘 Делегирование всего
→ Продуктовый аналог: Если степень свободы не соответствует степени квалификации и мотивированности команды, рано или поздно вылазят проблемы.
🔘 Видимость успеха ≠ устойчивость
→ Продуктовый аналог: Рост выручки может маскировать глубокие системные проблемы, которые станут очевидны в более дальней перспективе (например, потеря сильной команды почувствуется только когда будет растеряно все ее наследие).
Диагноз эпохи: Два мира, два Шапиро
✔️ Творец (Галицкий): Инвестирует в среду, процессы, людей → Строит системно. Ставка на рост через ценность и устойчивость. Минус - рост будет медленнее, владелец несет все риски на себе.
✔️ Правитель (Абрамович): Управляет через ресурс, контроль, статус → Оптимизирует ранее созданное. Ставка на рост через контроль бюджета и найм "звезд". Минус - успехи будут временными и неустойчивыми.
Да, мне симпатичнее стиль Галицкого, и мне абсолютно плевать, если кто-то над этим посмеется.
Pro Product
#философия #мысливслух
Можно, конечно, занудно (о, я мастер!) разбирать, почему получается именно у него: self-determination, способность к delay of gratification, openness to experience, servant leadership, высокий локус контроля, везение... вот это вот все. Но лучше я сравню его с другим очень успешным предпринимателем, который тоже имеет интерес в футболе. А еще постараюсь сделать это так, чтобы продуктоводы могли извлечь для себя какую-то практическую ценность.
🏗 Галицкий: Метафора Творца
Источник капитала → Собственный бизнес (Магнит)
Стиль управления → Создание с нуля, bottom-up
Тип лидерства - Servant leadership
Горизонт планирования - Долгосрочный, устойчивое развитие
Имиджевая стратегия - Локальная идентичность, укоренённость
→ Продуктовый аналог: Думай не о фиче, а о продукте и его жизненном цикле.
→ Продуктовый аналог: свобода действия так долго пока амбиции не попросят инвестиций.
→ Продуктовый аналог: Инвестиции в найм потенциала, обучение, рост внутри. А не "купить звезду".
→ Продуктовый аналог: Смелость игнорировать хайп, если тренд не в фокусе твоей стратегии.
→ Продуктовый аналог: Держать руку на пульсе видения и контекста, не скатываясь в "тушение пожаров". Знать, про что код и почему именно так, но не писать его за разработчика.
👑 Абрамович: Метафора Правителя
Источник капитала → Приватизация
Стиль управления → Покупка готового, top-down
Тип лидерства - Патернализм + transactional
Горизонт планирования - Короткий
Имиджевая стратегия - Глобальная, soft power
→ Продуктовый аналог: Оборот ≠ зрелость. Купишь трафик, но не лояльность/retention.
→ Продуктовый аналог: Частая смена фокуса или людей (особенно ключевых) убивает команду. Хаос ≠ agility.
→ Продуктовый аналог: Можно выстрелить с кривым MVP без Discovery, но это как выиграть в лотерею, в следующий раз не повезет, а амбиции уже есть. Удача ≠ метод.
→ Продуктовый аналог: Если степень свободы не соответствует степени квалификации и мотивированности команды, рано или поздно вылазят проблемы.
→ Продуктовый аналог: Рост выручки может маскировать глубокие системные проблемы, которые станут очевидны в более дальней перспективе (например, потеря сильной команды почувствуется только когда будет растеряно все ее наследие).
Диагноз эпохи: Два мира, два Шапиро
💡 Продуктовая команда, как футбольный клуб, может жить на дотации или на культуре. У Галицкого — философия «вырастить и оставить». У Абрамовича — «купить и оставить» (и это два таких разных оставить). Обе стратегии могут дать результат, но у одной выше ROI на долгом горизонте, а вторая про прийти, увидеть, победить... и пойти дальше. И этот выбор определяет не только итоговый скорборд, но и то, кем ты будешь, когда игра закончится.
Да, мне симпатичнее стиль Галицкого, и мне абсолютно плевать, если кто-то над этим посмеется.
Pro Product
#философия #мысливслух
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4❤2
Кто вам нужен — Product, BizDev или Project? И при чём тут Discovery
Вопрос «А кого бы ещё нанять?» (он же — поиск козла отпущения) возникает, когда в команде кризис: идей нет — или наоборот, идей полно, встреч тоже, а результата нет. Крокодил не ловится, код не пишется, рынок не реагирует на запуски. И проблема тут почти никогда не в «нехватке человека в определенной должности» — она в сломанном процессе Discovery.
Почему не «или», а «и»
1. Why & What (Value)
🔹 Вопросы: «Какую проблему решаем?», «Для кого она критична?», «Заплатят ли?», «Какое MVP докажет это?»
🔹 Кто отвечает: Основатель (pre-seed), Product + UX Researcher (зрелые команды), Product + Sales (возможно в B2B)
🔹 Риски: Никому не нужное решение, ищущее проблему, или продукт, за который никто не заплатит
✔️ Цель: Доказать, что боль есть, решение работает, и за него готовы платить
2. How to Win (Scale)
🔹 Вопросы: «Как превратить ценность в бизнес?», «Через какие каналы и партнёров выйти на рынок?», «Какой GTM-сценарий рабочий?»
🔹 Кто отвечает: Основатель/Product (ранние стадии), далее — BizDev, Sales, иногда — Стратег
🔹 Риски: Продукт для “фанатов” (особенно в B2C), невоспроизводимые кастомные внедрения (в B2B), игнорирование регуляторики
✔️ Цель: Найти устойчивый путь от ценности к росту и деньгам
3. How & When (Feasibility)
🔹 Вопросы: «Какие ресурсы нужны?», «Какие сроки реальны?», «Где узкие места?», «Как снизить риски?»
🔹 Кто отвечает: Основатель/Tech Lead (в начале), в зрелости — Project/Delivery Manager, Tech Lead (очень редко Product)
🔹 Риски: Discovery ради Discovery, заведомо невыполнимые планы или нереализуемые решения
✔️ Цель: Сложить реалистичный путь от идеи до результата
А если уже наняли, всех троих… Как сделать так, чтобы они не подрались?
Discovery работает, когда все фокусы присутствуют, а люди не конкурируют, а усиливают друг друга:
✔️ Общий бэклог — один, но источники разные:
Product приносит в основном ценностные и монетизационные гипотезы (но не только), BizDev — рыночные, Project — варианты решения. Всё приоритизируется на общих основаниях — по стратегии и выбранной модели оценки.
✔️ Комбинированная валидация:
Проблемы ищет и валидирует в Product, иногда с участием BizDev (если нужен доступ к клиентам). Проверка решений делится: Product отвечает за то, чтобы решение работало и было удобно, BizDev — за доступ к масштабируемому спросу.
✔️ Совместные решения
Go/No-Go — это не чуйка, не продажа и не волевое решение одного, а проверка: есть ли ценность (Product), есть ли доступный масштаб (BizDev), можно ли сделать (Project).
✔️ Общее поле мышления
Все одинаково понимают, что строим, зачем и в каких ограничениях — без бесконечных согласований и театральных отчетных встреч.
✔️ Соблюдаем этапность
Сначала — проблема и рынок (Product + BizDev), потом — решение (Product + Project).
А кто главный в Discovery?
Тот, чья зона фокуса сейчас критична.
Но за целостность процесса отвечает Product Manager — как интегратор пользователя, бизнеса и технологии.
Pro Product
#Компетенции
#Процессы
#Исследования
Вопрос «А кого бы ещё нанять?» (он же — поиск козла отпущения) возникает, когда в команде кризис: идей нет — или наоборот, идей полно, встреч тоже, а результата нет. Крокодил не ловится, код не пишется, рынок не реагирует на запуски. И проблема тут почти никогда не в «нехватке человека в определенной должности» — она в сломанном процессе Discovery.
💡Вас должны волновать не должности, а фокусы:
– Проверка ценности и жизнеспособности идеи (Value)
– Оценка реализуемости и рисков (Feasibility)
– Проверка масштабируемости (Scale)
Правильный вопрос — не «кого ещё нанять», а «что из этого мы делаем плохо — и как это исправить?»
А уж справится ли с этим кто-то из текущей команды или потребуется найм — решается после.
Почему не «или», а «и»
1. Why & What (Value)
🔹 Вопросы: «Какую проблему решаем?», «Для кого она критична?», «Заплатят ли?», «Какое MVP докажет это?»
🔹 Кто отвечает: Основатель (pre-seed), Product + UX Researcher (зрелые команды), Product + Sales (возможно в B2B)
🔹 Риски: Никому не нужное решение, ищущее проблему, или продукт, за который никто не заплатит
✔️ Цель: Доказать, что боль есть, решение работает, и за него готовы платить
2. How to Win (Scale)
🔹 Вопросы: «Как превратить ценность в бизнес?», «Через какие каналы и партнёров выйти на рынок?», «Какой GTM-сценарий рабочий?»
🔹 Кто отвечает: Основатель/Product (ранние стадии), далее — BizDev, Sales, иногда — Стратег
🔹 Риски: Продукт для “фанатов” (особенно в B2C), невоспроизводимые кастомные внедрения (в B2B), игнорирование регуляторики
✔️ Цель: Найти устойчивый путь от ценности к росту и деньгам
3. How & When (Feasibility)
🔹 Вопросы: «Какие ресурсы нужны?», «Какие сроки реальны?», «Где узкие места?», «Как снизить риски?»
🔹 Кто отвечает: Основатель/Tech Lead (в начале), в зрелости — Project/Delivery Manager, Tech Lead (очень редко Product)
🔹 Риски: Discovery ради Discovery, заведомо невыполнимые планы или нереализуемые решения
✔️ Цель: Сложить реалистичный путь от идеи до результата
А если уже наняли, всех троих… Как сделать так, чтобы они не подрались?
Discovery работает, когда все фокусы присутствуют, а люди не конкурируют, а усиливают друг друга:
Product приносит в основном ценностные и монетизационные гипотезы (но не только), BizDev — рыночные, Project — варианты решения. Всё приоритизируется на общих основаниях — по стратегии и выбранной модели оценки.
Проблемы ищет и валидирует в Product, иногда с участием BizDev (если нужен доступ к клиентам). Проверка решений делится: Product отвечает за то, чтобы решение работало и было удобно, BizDev — за доступ к масштабируемому спросу.
Go/No-Go — это не чуйка, не продажа и не волевое решение одного, а проверка: есть ли ценность (Product), есть ли доступный масштаб (BizDev), можно ли сделать (Project).
Все одинаково понимают, что строим, зачем и в каких ограничениях — без бесконечных согласований и театральных отчетных встреч.
Сначала — проблема и рынок (Product + BizDev), потом — решение (Product + Project).
А кто главный в Discovery?
Тот, чья зона фокуса сейчас критична.
Но за целостность процесса отвечает Product Manager — как интегратор пользователя, бизнеса и технологии.
💡 ИМХО: Вам нужны не «люди с должностями», а правильные фокусы: Value, Scale, Feasibility, объединенные правильным процессом Discovery. Сколько людей и в какой должности будут это реализовывать — это вопрос второстепенный (если вы, конечно, про "сделать", а не про "править"😉)
Pro Product
#Компетенции
#Процессы
#Исследования
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2❤1
Как давно вы в последний раз проверяли актуальность своих знаний?
Ну, например, перечень метрик, которые вы считаете рабочими в той или иной ситуации, а также подходов к их расчету и интерпретации.
Я тут недавно сделала ревизию (спасибо Юлии и Илье за вдохновение), и меня ждали несколько любопытных апгрейдов. Поделюсь с вами — вдруг кому-то тоже пригодится.
1️⃣ От “средних” к контексту и поведению
Было:
Retention D30, ARPU, ARPPU, Session Duration, общая CVR, LTV, DAU/MAU
Стало:
CLTV (по платящим) вместо ARPPU, ARPU — больше не инструмент принятия решений, для остальных стал критичен другой подход — через призму:
🔘 сегментации и путей пользователя
🔘 распределений (перцентили, гистограммы)
🔘 когорт
🔘 декомпозиции драйверов
🔘 временных рядов
👉 Смысл:
Большинство продуктовых метрик — неэргодичны. Их нельзя усреднять без потери смысла: то, как «в среднем» ведёт себя группа, почти ничего не говорит о реальных траекториях конкретных пользователей (не скажу, что эта мысль нова, но в последнее время аналитикам таки удалось продвинуть ее в массы). Поэтому дробить, раскладывать, наблюдать во времени теперь must have для большинства метрик.
2️⃣ Удержание: долгосрочное и в деньгах
Было:
Churn rate, Retention D30
Стало:
GRR, NRR, MRR, Retention D90/180
👉 Смысл:
Удержание на 30 день больше не маркер устойчивого вовлечения в продукт. Нам нужно понять, приносит ли клиент деньги в долгую (от 3х месяцев). Деньги → основной язык продукта, время хайпа и доступных инвестиционных денег закончилось (по крайней мере в этом периоде).
Churn также не отражает деньги — вместо него считают GRR и NRR.
3️⃣ Unit-экономика 2.0
Было:
LTV / CAC, где LTV — средняя выручка за всё время, а CAC — только траты на привлечение
Стало:
CLTV / CLTC
CLTV — фактическая или прогнозная чистая прибыль с одного клиента (доход минус все переменные расходы).
CLTC = CAC + поддержка + удержание + инфраструктура
👉 Смысл:
Продукты стали сложнее, порой удерживать клиентов не менее дорого, чем привлекать.
Важно считать не просто “во сколько обошлось привлечение”, а “во сколько обходится пожизненное содержание клиента”.
Что касается CLTV, то это изменение связано с неэргодичностью ARPU, который использовался в прежней формуле. Прогноз CLTV в новой парадигме делается не по средним, а через моделирование поведения сегментов/когорт клиентов во времени.
4️⃣ Лояльность — это действия, а не слова
Было:
NPS, CSAT, CES
Стало:
Остались, но переосмыслены. Их дополняют открытые вопросы, поведенческие паттерны, качественные интервью.
👉 Смысл:
NPS хорош не как показатель, а как способ начать диалог с пользователем.
Важно не то, что он поставил 3 — а то, что он написал в поле “что бы вы улучшили”.
Метрика — триггер, не ответ.
5️⃣ Vanity-мeтрики уходят (теперь уже точно)
Было:
Количество установок, DAU/MAU, лайки, просмотры, сессии
Стало:
Метрики возврата инвестиций: прибыль с пользователя, CLTV, NRR, ROI от функций и каналов
👉 Смысл:
Мы больше не в фазе быстрого роста и дешевых денег. Инвесторы и компании требуют value.
Если метрика не отвечает на вопрос “приносит ли это деньги и рост?” — значит, это шоу, а не бизнес.
📌 Что это значит для продакта?
‼️ Если вы все еще не знакомы с понятием эргодичности, срочно познакомьтесь! Питерс, Гелл-Манн и Талеб вам в помощь 😌
‼️ Для продвинутой аналитики нужны продвинутые инструменты. Не владеете? Вы знаете какой следующий курс пройти 🙃
‼️ Продуктовая аналитика всё ближе к финансовой: нужно считать не сроки запуска фич и количество клиентов со средней конверсией, а около денежные показатели. Да, это тоже нужно знать 😊
‼️ Больше внимания работе с базой, меньше — хайпу и созданию видимости успешного успеха.
Pro Product
#Компетенции
#Метрики
#Тренды
Ну, например, перечень метрик, которые вы считаете рабочими в той или иной ситуации, а также подходов к их расчету и интерпретации.
Я тут недавно сделала ревизию (спасибо Юлии и Илье за вдохновение), и меня ждали несколько любопытных апгрейдов. Поделюсь с вами — вдруг кому-то тоже пригодится.
1️⃣ От “средних” к контексту и поведению
Было:
Retention D30, ARPU, ARPPU, Session Duration, общая CVR, LTV, DAU/MAU
Стало:
CLTV (по платящим) вместо ARPPU, ARPU — больше не инструмент принятия решений, для остальных стал критичен другой подход — через призму:
👉 Смысл:
Большинство продуктовых метрик — неэргодичны. Их нельзя усреднять без потери смысла: то, как «в среднем» ведёт себя группа, почти ничего не говорит о реальных траекториях конкретных пользователей (не скажу, что эта мысль нова, но в последнее время аналитикам таки удалось продвинуть ее в массы). Поэтому дробить, раскладывать, наблюдать во времени теперь must have для большинства метрик.
2️⃣ Удержание: долгосрочное и в деньгах
Было:
Churn rate, Retention D30
Стало:
GRR, NRR, MRR, Retention D90/180
👉 Смысл:
Удержание на 30 день больше не маркер устойчивого вовлечения в продукт. Нам нужно понять, приносит ли клиент деньги в долгую (от 3х месяцев). Деньги → основной язык продукта, время хайпа и доступных инвестиционных денег закончилось (по крайней мере в этом периоде).
Churn также не отражает деньги — вместо него считают GRR и NRR.
3️⃣ Unit-экономика 2.0
Было:
LTV / CAC, где LTV — средняя выручка за всё время, а CAC — только траты на привлечение
Стало:
CLTV / CLTC
CLTV — фактическая или прогнозная чистая прибыль с одного клиента (доход минус все переменные расходы).
CLTC = CAC + поддержка + удержание + инфраструктура
👉 Смысл:
Продукты стали сложнее, порой удерживать клиентов не менее дорого, чем привлекать.
Важно считать не просто “во сколько обошлось привлечение”, а “во сколько обходится пожизненное содержание клиента”.
Что касается CLTV, то это изменение связано с неэргодичностью ARPU, который использовался в прежней формуле. Прогноз CLTV в новой парадигме делается не по средним, а через моделирование поведения сегментов/когорт клиентов во времени.
4️⃣ Лояльность — это действия, а не слова
Было:
NPS, CSAT, CES
Стало:
Остались, но переосмыслены. Их дополняют открытые вопросы, поведенческие паттерны, качественные интервью.
👉 Смысл:
NPS хорош не как показатель, а как способ начать диалог с пользователем.
Важно не то, что он поставил 3 — а то, что он написал в поле “что бы вы улучшили”.
Метрика — триггер, не ответ.
5️⃣ Vanity-мeтрики уходят (теперь уже точно)
Было:
Количество установок, DAU/MAU, лайки, просмотры, сессии
Стало:
Метрики возврата инвестиций: прибыль с пользователя, CLTV, NRR, ROI от функций и каналов
👉 Смысл:
Мы больше не в фазе быстрого роста и дешевых денег. Инвесторы и компании требуют value.
Если метрика не отвечает на вопрос “приносит ли это деньги и рост?” — значит, это шоу, а не бизнес.
📌 Что это значит для продакта?
💡 Если вы давно не актуализировали свой аналитический инструментарий — возможно, пора.
А потом бегом смотреть свои дэшборды и последние принятые решения на предмет булшита 👀
Pro Product
#Компетенции
#Метрики
#Тренды
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3🔥2❤1🤔1
✅ Чек-лист применимости A_B.pdf
292.4 KB
«Сколько A/B-тестов вы запустили на прошлом месте работы?»
Вас спрашивали о таком на собеседовании? Если вы не сразу поняли, как реагировать, я вас понимаю. Действительно! Отвечать по-честному? Или улыбнуться и спросить, сколько строк кода написал их Senior Dev?
Дело в том, что в лучшем случае — это пустая болтовня и плохой hr-скрипт, в худшем — симптом того, что в компании "играют" в эксперименты и A/B там — не метод, а ритуал. Кстати, почему именно A/B? 🤔 Да не важно! Кто-то любит интервью — суть не меняется.
Когда вопрос про количество, простите, тупой:
1️⃣ Стартап на ранней стадии? У тебя нет трафика. Есть гипотеза, что люди не понимают ценность фичи? Это не решается тестом — интервью, скрины, интерактивы.
2️⃣ Или ты работаешь в хардкорном B2B с парой сотен клиентов, из которых важны только 10? Там тоже нет нужного объема трафика, а одно изменение обсуждают в трёх департаментах (иногда дольше, чем будет жить ваш продукт).
3️⃣ А еще бывает так, что тесты — это часть ценности, которую дает продукт. Например, вы делаете рекламную платформу. Там не вы тестируете интерфейс и улучшаете конверсии в своей продуктовой воронке, а клиенты запускают эксперименты. A/B здесь способ доказать: наш инструмент помогает принимать лучшие решения. Их тысячи, но смотреть нужно на CSAT, adoption, а лучше на влияние на те метрики, ради увеличения которых проводились эти тесты.
Когда вопрос про количество просто бесполезный:
Даже если потенциально A/B-тесты были заметной частью работы:
1️⃣ B2C-продукт после нахождения PMF.
2️⃣ B2B-продукт output которого связан с работой алгоритма, например, маршрутизатор или генерация картинок (тут речь не про продуктовую воронку, а про value).
Количество мало-что говорит о реальных компетенциях. Можно годами запускать A/B-тесты (или собирать специально обученных людей, чтобы они их запустили 😊), но так и не понять, когда и почему данные врут. И когда A/B вообще не стоило проводить.
‼️ Cписок ситуаций, когда A/B вас только запутает - аттач.
В общем, вопрос "Сколько тестов?" не про экспертизу. Эксперты (а не сектанты) спрашивают о методологии, ошибках, принятии решений...
Адекватный же ответ в этом случае может быть таким. ИМХО:
Впрочем, решайте сами, стоит ли так напрягаться, ведь человек, который ставит вопрос таким образом, ваш ответ, скорее всего, не поймет и низко вас оценит 😉
Pro Product
#Метрики #исследования #мысливслух
Вас спрашивали о таком на собеседовании? Если вы не сразу поняли, как реагировать, я вас понимаю. Действительно! Отвечать по-честному? Или улыбнуться и спросить, сколько строк кода написал их Senior Dev?
Дело в том, что в лучшем случае — это пустая болтовня и плохой hr-скрипт, в худшем — симптом того, что в компании "играют" в эксперименты и A/B там — не метод, а ритуал. Кстати, почему именно A/B? 🤔 Да не важно! Кто-то любит интервью — суть не меняется.
Когда вопрос про количество, простите, тупой:
Когда вопрос про количество просто бесполезный:
Даже если потенциально A/B-тесты были заметной частью работы:
Количество мало-что говорит о реальных компетенциях. Можно годами запускать A/B-тесты (или собирать специально обученных людей, чтобы они их запустили 😊), но так и не понять, когда и почему данные врут. И когда A/B вообще не стоило проводить.
В зрелых продуктовых командах лишь ~20–30% гипотез проверяют через классический A/B. Остальные требуют либо качественных, либо аналитических методов. Этот индустриальный ориентир подтверждён данными Amplitude, Reforge и кейсами Booking.
В общем, вопрос "Сколько тестов?" не про экспертизу. Эксперты (а не сектанты) спрашивают о методологии, ошибках, принятии решений...
Адекватный же ответ в этом случае может быть таким. ИМХО:
За два года мы сделали X экспериментов, Y из них были АБ-тестами (в остальных случаях целесообразнее было использовать другой метод), только W из них имели статистически значимый результат.
Самый заметный с точки зрения бизнес-вэлью эффект был получен в результате …
Но там был не просто A/B, мы дополнили его сегментированием, TST-анализом и подтверждали выводы юзабилити-тестами, потому что...
Впрочем, решайте сами, стоит ли так напрягаться, ведь человек, который ставит вопрос таким образом, ваш ответ, скорее всего, не поймет и низко вас оценит 😉
Pro Product
#Метрики #исследования #мысливслух
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6❤2
Про синтетические данные
К чему я? Оказалось, что "синтетика" не только живее всех живых, но и один из явных трендов теперь уже продуктовой аналитики. Со всем свойственным мне задротством и капелькой ностальгии собрала мысли по теме 👇🏻
1️⃣ Приоритизация бэклога
В большинстве команд приоритизация идей/решений строится на простых моделях (RICE, ICE...), где impact и confidence оцениваются «на пальцах». Для стартапа это нормально, но в зрелом продукте такой подход генерирует упущенную выгоду.
Более продвинутые команды внедряют uplift-модели (causal forests, DoubleML): они прогнозируют эффект каждой идеи на основе исторических данных и трендовых паттернов пользовательских событий. Но даже у продвинутых игроков остаются пробелы — редкие сегменты, новые рынки, неполные логи. Вот тут и нужен Synthetic control, он «дозаполняет» эти хвосты через GAN/VAE, затем проверяется качество синтетики (JS-дивергенция, F1) и uplift-прогноз обновляется.
2️⃣ Тестирование решений/идей
Здесь возможны разные реализации:
🔘 Реальный эксперимент → дополнение синтетикой
Запускается классический A/B или другой тип эксперимента на ограниченном пуле, после первых сигналов и «дозаполняется» синтетическими сессиями (GAN/VAE или probabilistic programming). Это повышает статистическую мощность и усиливает классические funnel-тесты.
🔘 Виртуальный эксперимент в test-sandbox
Вы создаёте «песочницу» — симулятор среды и/или агентов, которые генерируют поведение (трафик, клики, запросы). Так вы «прокатываете» вариант решения в виртуальных условиях, прежде чем принять решение выкатывать ли в прод. Особенно актуально для value-core сценариев, где важны покрытие corner-cases и конфиденциальность.
Примеры:
✔️ Meta («виртуальный фид» для тестов рекомендательной ленты)
✔️ Uber (симуляции спроса и supply-side для ценообразования)
Больше тут
3️⃣ Go-to-Market
Непосредственно перед и во время запуска фичи/продукта вам нужно:
🔘 Подготовить инфраструктуру (нагрузочные/атрибуционные симуляции через sandbox и synthetic traffic/data).
🔘 Запустить маркетинг (cинтетика здесь помогает ускорить запуск при холодном старте).
Примеры:
✔️ Amazon использует synthetic shoppers + synthetic traffic для стресс-тестов логистики.
4️⃣ Post-launch
У вас есть первые реальные цифры после запуска, и вы принимаете решения о масштабировании. В основе post-launch лежат аналитические методы (time-series forecasting, survival analysis, capacity planning), а синтетика их усиливает: дозаполняя данные или стресс-тестами пиковых нагрузок.
💰 Эффекты VS Ограничения 🚧 - на слайде
Pro Product
#История
#Тренды
Изучая тренды продуктовой аналитики, я тут вспомнила свою первую любовь —данные 😉
В 2016, 2017, 2018 я занималась digital-рекламой. Тогда на каждой конференции звучали лозунги типа «данные — новая нефть», и мы, как под гипнозом, погружались в рассказы о look-alike и других возможностях big data. Мало-кого тогда волновали мощности, компетенции специалистов, которые вещают об этих «чудесах» и прочие скучные штуки. Я была в меньшинстве - меня волновали, и даже заставили снова пойти учиться, в то время пока менее склонные к рефлексии коллеги делали карьеру... Свой приз я тоже получила, но чуть позже (не верю в честный быстрый успех, если ты андердог) — помню на технической сессии в один бигтех разработчик спросил меня как компания, в которой я сейчас работаю, моделирует соцдем. И я описала человеческими словами, как работает логистическая регрессия и даже обозначила, что мы планируем перейти на градиентный бустинг. Может про себя он посмеялся над моими объяснениями, но оффер я тогда получила и очень этим гордилась😊
К чему я? Оказалось, что "синтетика" не только живее всех живых, но и один из явных трендов теперь уже продуктовой аналитики. Со всем свойственным мне задротством и капелькой ностальгии собрала мысли по теме 👇🏻
В большинстве команд приоритизация идей/решений строится на простых моделях (RICE, ICE...), где impact и confidence оцениваются «на пальцах». Для стартапа это нормально, но в зрелом продукте такой подход генерирует упущенную выгоду.
Более продвинутые команды внедряют uplift-модели (causal forests, DoubleML): они прогнозируют эффект каждой идеи на основе исторических данных и трендовых паттернов пользовательских событий. Но даже у продвинутых игроков остаются пробелы — редкие сегменты, новые рынки, неполные логи. Вот тут и нужен Synthetic control, он «дозаполняет» эти хвосты через GAN/VAE, затем проверяется качество синтетики (JS-дивергенция, F1) и uplift-прогноз обновляется.
💡 Таким образом, синтетика может служить финальным усилением приоритизации: она не заменяет реальные данные и ML-модели, а помогает закрыть лакуны и принять более обоснованное решение.
Здесь возможны разные реализации:
Запускается классический A/B или другой тип эксперимента на ограниченном пуле, после первых сигналов и «дозаполняется» синтетическими сессиями (GAN/VAE или probabilistic programming). Это повышает статистическую мощность и усиливает классические funnel-тесты.
Вы создаёте «песочницу» — симулятор среды и/или агентов, которые генерируют поведение (трафик, клики, запросы). Так вы «прокатываете» вариант решения в виртуальных условиях, прежде чем принять решение выкатывать ли в прод. Особенно актуально для value-core сценариев, где важны покрытие corner-cases и конфиденциальность.
Примеры:
Больше тут
Непосредственно перед и во время запуска фичи/продукта вам нужно:
Примеры:
У вас есть первые реальные цифры после запуска, и вы принимаете решения о масштабировании. В основе post-launch лежат аналитические методы (time-series forecasting, survival analysis, capacity planning), а синтетика их усиливает: дозаполняя данные или стресс-тестами пиковых нагрузок.
💰 Эффекты VS Ограничения 🚧 - на слайде
💡 Синтетика дает возможность ранних, малошумных экспериментов при ограниченном трафике или высоком риске, а также усиливает аналитические методы. Но она НЕ ЗАМЕНЯЕТ живые данные полностью, и все еще остаётся сложным, дорогостоящим инструментом, эффективным только для зрелых команд.
Pro Product
#История
#Тренды
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥6❤2
В последнее время часто читаю и слышу тезис, что роль СРО деградировала (я, конечно, про русскоязычное пространство). И якобы тому виной поуехавшие (очень лестно для последних, но нет). Согласна только наполовину: роль деградировала, но отток лишь фактор, при том не главный. Гораздо важнее другое: горизонталь проиграла иерархии. И это пора признать, по крайней мере в этом периоде. Проиграла как сама, так и под давлением среды.
Что значит «сама»?
Значит — не оформилась. Не смогла стать ясной, устойчивой и воспроизводимой моделью. Не смогла убедить, что так будет лучше если не всем, то хотя бы основным стейкхолдерам. Даже в продуктовых компаниях трансформация проросла не везде. Слишком много теории и лозунгов, слишком мало реальных изменений в управленческих практиках. Почему так вышло можно рассуждать долго, но счет на табло. Рядом с девизом "продакт - это маленький CEO" ("только без полномочий" приписано самым мелким шрифтом внизу). Напрашивался вопрос: "А CPO тогда, простите, кто? Начальник группы CEO? Предводитель уездного дворянства?"
Среда добила.
В России снова виток централизации, и это надолго. А централизация всегда стремится к иерархии. Слуга царю, отец солдатам - вот теперь официальный девиз. А по сути... он таким был всегда, просто те из нас, кто играл в бирюзовые организации, не хотели это видеть... или видели, но хотели попробовать по-другому (у кого-то даже получилось). Тот же, кто видел и не хотел ничего менять, быстрее и проще продвигался в карьере, потому что понимал, что действительно важно. Лояльность важнее компетенций, их вообще можно прикрыть "харизмой", тем более в этих новых темах почти никто не разбирается, можно продержаться какое-то время. Главное складно трендеть про продуктовый подход, a/b-тесты и метрики. А иногда и этого не требуется, достаточно уметь грозным голосом спрашивать "когда" у всех вокруг, недовольно надувать накаченные губы, томно закатывать глаза с нарощенными ресницами и не обращать внимание, когда за спиной смеются, а в лицо просто игнорируют. Спихивай ошибки на других, а в идеале вообще ничего не делай - жди, когда у кого-то что-то получится, позаботься об атрибуции этого успеха себе, потом вовремя уходи и карьера попрет.
Во-вторых, есть "заводские настройки" (и по Хантингтону, и по Инглхарту), связанные с историей, религией, культурой и так далее. И определенные организационные модели на одну почву хорошо ложатся, потому что они ей органичны, на другую - не очень, но есть гетерогенные почвы, которым свойственно и индивидуальное, и коллективное начало. Вот там все зависит от ситуации. Надо признать, что горизонтальные модели на российскую почву легли плохо, но это не значит, что не могло быть по-другому. Тем более продуктовые оазисы тоже возникли. В этом и есть весь драматизм.
В-третьих, давайте будем честны: не народилась финансово-правовая и научная среда, которая могла бы поддерживать массовое создание и развитие продуктового бизнеса (не торгового, не услуг, а именно продуктового, где продукт не инфраструктура). Уже упомянутые оазисы возникли на свои и скорее вопреки. Старые же деньги распределяются и управляются по-старому - через иерархию.
Поэтому…
продакты, которые не брезговали залезть в функциональный колодец и в нем тихо высиживать свое счастье или того интереснее - кто угодно, кто стоял рядом с продуктом и докладывал куда надо в удобной форме что вообще происходит, теперь новые СРО. Выигрывает не тот, кто мыслит категориями value и окутывает невидимыми, но прочными смысловыми нитями каждое внедряемое изменение, а тот, кто надёжно встроен в цепочку командования. Т.е. теперь нужен транслятор воли сверху и контролер исполнения, то что мы называем трушным продуктовым лидерством больше... не поможет в карьере.
Нравится вам это или нет, это объективная реальность, которую лучше принять. Раунд.
Вот такие #мысливслух
Pro Product
#философия
Что значит «сама»?
Значит — не оформилась. Не смогла стать ясной, устойчивой и воспроизводимой моделью. Не смогла убедить, что так будет лучше если не всем, то хотя бы основным стейкхолдерам. Даже в продуктовых компаниях трансформация проросла не везде. Слишком много теории и лозунгов, слишком мало реальных изменений в управленческих практиках. Почему так вышло можно рассуждать долго, но счет на табло. Рядом с девизом "продакт - это маленький CEO" ("только без полномочий" приписано самым мелким шрифтом внизу). Напрашивался вопрос: "А CPO тогда, простите, кто? Начальник группы CEO? Предводитель уездного дворянства?"
Среда добила.
В России снова виток централизации, и это надолго. А централизация всегда стремится к иерархии. Слуга царю, отец солдатам - вот теперь официальный девиз. А по сути... он таким был всегда, просто те из нас, кто играл в бирюзовые организации, не хотели это видеть... или видели, но хотели попробовать по-другому (у кого-то даже получилось). Тот же, кто видел и не хотел ничего менять, быстрее и проще продвигался в карьере, потому что понимал, что действительно важно. Лояльность важнее компетенций, их вообще можно прикрыть "харизмой", тем более в этих новых темах почти никто не разбирается, можно продержаться какое-то время. Главное складно трендеть про продуктовый подход, a/b-тесты и метрики. А иногда и этого не требуется, достаточно уметь грозным голосом спрашивать "когда" у всех вокруг, недовольно надувать накаченные губы, томно закатывать глаза с нарощенными ресницами и не обращать внимание, когда за спиной смеются, а в лицо просто игнорируют. Спихивай ошибки на других, а в идеале вообще ничего не делай - жди, когда у кого-то что-то получится, позаботься об атрибуции этого успеха себе, потом вовремя уходи и карьера попрет.
Во-вторых, есть "заводские настройки" (и по Хантингтону, и по Инглхарту), связанные с историей, религией, культурой и так далее. И определенные организационные модели на одну почву хорошо ложатся, потому что они ей органичны, на другую - не очень, но есть гетерогенные почвы, которым свойственно и индивидуальное, и коллективное начало. Вот там все зависит от ситуации. Надо признать, что горизонтальные модели на российскую почву легли плохо, но это не значит, что не могло быть по-другому. Тем более продуктовые оазисы тоже возникли. В этом и есть весь драматизм.
В-третьих, давайте будем честны: не народилась финансово-правовая и научная среда, которая могла бы поддерживать массовое создание и развитие продуктового бизнеса (не торгового, не услуг, а именно продуктового, где продукт не инфраструктура). Уже упомянутые оазисы возникли на свои и скорее вопреки. Старые же деньги распределяются и управляются по-старому - через иерархию.
Поэтому…
продакты, которые не брезговали залезть в функциональный колодец и в нем тихо высиживать свое счастье или того интереснее - кто угодно, кто стоял рядом с продуктом и докладывал куда надо в удобной форме что вообще происходит, теперь новые СРО. Выигрывает не тот, кто мыслит категориями value и окутывает невидимыми, но прочными смысловыми нитями каждое внедряемое изменение, а тот, кто надёжно встроен в цепочку командования. Т.е. теперь нужен транслятор воли сверху и контролер исполнения, то что мы называем трушным продуктовым лидерством больше... не поможет в карьере.
Нравится вам это или нет, это объективная реальность, которую лучше принять. Раунд.
Вот такие #мысливслух
Pro Product
#философия
❤6🤔6👍2
Гайд.pdf
362.2 KB
Про внутренние продукты
Продолжаю топтаться по больному, сегодня решила поднять такую тему👇
Вы заметили, что в какой-то момент возникла странная мода всё называть продуктом? Любой скрипт авторизации, типовая админка, CMS без вариативности, CRM с простой фиксированной воронкой … Все эти штуки, которые раньше считались сервисами, вдруг резко стали «внутренними продуктами». Обрели своего оунера, а иногда и целую выделенную команду.
И да, так сделали многие, даже вполне себе крутые компании. Почему? Предположу, что «внутренний продукт» звучит гораздо моднее/круче, чем «обслуживание запросов бизнеса». А, значит, позволяет поднять статус этой работы в глазах сегмента соискателей, которым это важно.
Вот только есть нюанс… Продуктовый подход — это не “у нас теперь есть UX-дизайнер, воркфлоу в трекере и родмэп”,хотя по факту мы все также пилим фички по входящим заявкам. Это способ управлять неопределенностью через выбор. Мы понимаем, что и зачем мы делаем, а еще что НЕ делаем и почему. Наша цель в результате внедрения изменений — увеличивать ценность, которую можно монетизировать, и тем самым наращивать стоимость бизнеса. И здесь кроется первый подвох.
Монетизация — это большая сфера компетенций, которая у внутреннего продакта, как правило, не прокачивается. То же самое можно сказать про go-to-market (исключение - продакт CRM, у него могут быть как минимум обрывочные представления об этом). Но даже не это главное. Гораздо опаснее, что внутри такой конструкции у тебя якобы продуктовая роль: backlog, встречи, цели. А по факту часто — ни решений, ни ценности, ни гипотез, только координация чьих-то задач, в лучшем случае – управление требованиями. Выходишь на рынок — и внезапно выясняется, что рассказать-то про ПРОДУКТОВУЮ РАБОТУ и нечего.
Для компании этот маскарад тоже имеет сомнительное value – когда ты применяешь эту модель там, где нет ни альтернатив, ни вариантного поведения, ни данных и т.д. ты уводишь фокус с действительно важных вещей, таких как эффективность функции, на вещи, которые на бизнес влияют не сильно. Плюсом раздувается штат, создаются бесполезные артефакты, затягивается время разработки и формируются несбыточные ожидания друг от друга.
При этом, конечно, есть внутренние тулзы, где продуктовый подход уместен. Но большинство из них все же старый добрый сервис. Ценность там не в UX (он стандартен), а в надёжности, совместимости и стабильности. Очень простой маркер понять «как у вас» это честно себе ответить на вопрос, что в вашей тулзе, важнее: SLA и системные ограничения или возможность проверять гипотезы, UX и измеримая ценность.
Я это все к чему? Не стоит себя обманывать и изобретать велосипед. Если ваш инструмент решает условно один фиксированный сценарий, и выбора у пользователя нет, а менеджер не решает/исследует что и как делать, а что не делать — вам не нужен псевдопродуктовый подход.
С другой стороны, если все это есть – не комплексуйте, ведь внутренняя тулза может быть сложной, важной для бизнеса, интеллектуально насыщенной зоной ответственности и важной ступенькой в вашей карьере. Бизнес-эффекты могут заключаться не только в увеличении прибыли, но и в сокращении затрат. А как можно на мой взгляд упаковать эти эффекты в стройную систему смотрите в гайде👆
Pro Product
#философия #мысливслух #метрики
Продолжаю топтаться по больному, сегодня решила поднять такую тему
Вы заметили, что в какой-то момент возникла странная мода всё называть продуктом? Любой скрипт авторизации, типовая админка, CMS без вариативности, CRM с простой фиксированной воронкой … Все эти штуки, которые раньше считались сервисами, вдруг резко стали «внутренними продуктами». Обрели своего оунера, а иногда и целую выделенную команду.
И да, так сделали многие, даже вполне себе крутые компании. Почему? Предположу, что «внутренний продукт» звучит гораздо моднее/круче, чем «обслуживание запросов бизнеса». А, значит, позволяет поднять статус этой работы в глазах сегмента соискателей, которым это важно.
Вот только есть нюанс… Продуктовый подход — это не “у нас теперь есть UX-дизайнер, воркфлоу в трекере и родмэп”,
Монетизация — это большая сфера компетенций, которая у внутреннего продакта, как правило, не прокачивается. То же самое можно сказать про go-to-market (исключение - продакт CRM, у него могут быть как минимум обрывочные представления об этом). Но даже не это главное. Гораздо опаснее, что внутри такой конструкции у тебя якобы продуктовая роль: backlog, встречи, цели. А по факту часто — ни решений, ни ценности, ни гипотез, только координация чьих-то задач, в лучшем случае – управление требованиями. Выходишь на рынок — и внезапно выясняется, что рассказать-то про ПРОДУКТОВУЮ РАБОТУ и нечего.
Для компании этот маскарад тоже имеет сомнительное value – когда ты применяешь эту модель там, где нет ни альтернатив, ни вариантного поведения, ни данных и т.д. ты уводишь фокус с действительно важных вещей, таких как эффективность функции, на вещи, которые на бизнес влияют не сильно. Плюсом раздувается штат, создаются бесполезные артефакты, затягивается время разработки и формируются несбыточные ожидания друг от друга.
При этом, конечно, есть внутренние тулзы, где продуктовый подход уместен. Но большинство из них все же старый добрый сервис. Ценность там не в UX (он стандартен), а в надёжности, совместимости и стабильности. Очень простой маркер понять «как у вас» это честно себе ответить на вопрос, что в вашей тулзе, важнее: SLA и системные ограничения или возможность проверять гипотезы, UX и измеримая ценность.
Я это все к чему? Не стоит себя обманывать и изобретать велосипед. Если ваш инструмент решает условно один фиксированный сценарий, и выбора у пользователя нет, а менеджер не решает/исследует что и как делать, а что не делать — вам не нужен псевдопродуктовый подход.
С другой стороны, если все это есть – не комплексуйте, ведь внутренняя тулза может быть сложной, важной для бизнеса, интеллектуально насыщенной зоной ответственности и важной ступенькой в вашей карьере. Бизнес-эффекты могут заключаться не только в увеличении прибыли, но и в сокращении затрат. А как можно на мой взгляд упаковать эти эффекты в стройную систему смотрите в гайде
Pro Product
#философия #мысливслух #метрики
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5🔥4
Важная мысль в продолжение предыдущего поста.
‼️ Поясню мысль на примере. Любые совпадения случайны, все цифры - из головы, на точность и полноту схем не претендую 😉
Допустим речь про проблему доставки персонала домой после смены, когда общественный транспорт уже не работает. Типовая история для HoReCa, контактных-центров, производств и т.п. бизнесов.
Опустим детали discovery, фокусируемся на результатах: альтернативах и на том за счет чего формируется ценность в целевом решении.
Что этот кейс значит для бизнеса?
По форме речь о логистике, но по сути - об HR-инструменте.
Когда вы оплачиваете сотруднику поездку домой, вы на верхнем уровне (условно Nord Star) решаете следующие задачи:
🔹 Упрощение найма — это часть привлекательности оффера
🔹 Помощь в удержании — меньше стресса и выгорания
🔹 Снижение рисков — завтра сотрудник вовремя и в ресурсе
Хорошее решение должно, во-первых, привести к равновесию потребности всех стейкхолдеров:
🔘 Заказчик (HR, менеджер, собственник):
хочет дешевле, проще в управлении, меньше рисков.
🔘 Пользователи
— менеджер смены/логист: минимум времени и усилий, максимум экономии (если есть KPI по затратам);
— сотрудник: доехать быстро, безопасно и это решение ему выгодно.
🔘 Исполнители
— водитель: поездка должна быть выгодной;
— перевозчик (общЁ): заработать на марже и/или объёме;
— бухгалтер: меньше ручной работы, меньше рисков.
🔘 Государство:
чтобы всё по закону.
А во-вторых, быть привлекательнее альтернатив:
1️⃣ Платить на руки
2️⃣ Компенсация по чекам
3️⃣ Менеджер смены организует вручную
4️⃣ Фича внутри ride-hailing платформы
И да, решением4️⃣ будет комбинацией экономики, UX и технической реализации.
👉 TCO (общая стоимость) ≠ стоимость поездки — важно учитывать скрытые издержки: налоги, оргнагрузку и т.п.
👉 Организационная нагрузка имеет стоимость и потенциал для оптимизации — и это не всегда тривиальные затраты.
👉 Налоговая нагрузка зависит от формы предоставления и статуса исполнителя — без учёта этих нюансов легко ошибиться в расчётах.
👉 Стоимость поездки — результат сложного взаимодействия факторов — их наличие, сила и направление влияния проверяется аналитическими и/или экспериментальными способами.
👉 Риски и управляемость — следствия формы реализации — разные варианты по-разному масштабируются, контролируются и страхуются.
‼️ Не забывайте про Nord star 👆🏻 Самый дешевый и безрисковый вариант может просто не решать изначальную проблему.
- подробнее на слайдах
Pro Product
#Компетенции #метрики
💡 Внутренние продукты — отличный тренажёр для B2B-продакта. Особенно если будущая ценность будет связана с теми же процессами/jtbd. Но даже если нет — умение выявлять оптимизационные эффекты (большинство b2b-продуктов все еще process-impact, а не outcome-impact, отсюда и монетизация: подписка, transactional, PAYG и кастом сильно чаще, чем outcome-based и revshare) пригодится для формулирования метрик добавленной ценности, value proposition и выбора модели монетизации.
Допустим речь про проблему доставки персонала домой после смены, когда общественный транспорт уже не работает. Типовая история для HoReCa, контактных-центров, производств и т.п. бизнесов.
Что этот кейс значит для бизнеса?
По форме речь о логистике, но по сути - об HR-инструменте.
Когда вы оплачиваете сотруднику поездку домой, вы на верхнем уровне (условно Nord Star) решаете следующие задачи:
🔹 Упрощение найма — это часть привлекательности оффера
🔹 Помощь в удержании — меньше стресса и выгорания
🔹 Снижение рисков — завтра сотрудник вовремя и в ресурсе
Хорошее решение должно, во-первых, привести к равновесию потребности всех стейкхолдеров:
хочет дешевле, проще в управлении, меньше рисков.
— менеджер смены/логист: минимум времени и усилий, максимум экономии (если есть KPI по затратам);
— сотрудник: доехать быстро, безопасно и это решение ему выгодно.
— водитель: поездка должна быть выгодной;
— перевозчик (общЁ): заработать на марже и/или объёме;
— бухгалтер: меньше ручной работы, меньше рисков.
чтобы всё по закону.
А во-вторых, быть привлекательнее альтернатив:
И да, решением
ИМХО: найти и обосновать такую комбинацию невозможно, не понимая value chain (без нее можно придумать нужное, но нерентабельное решение) & JTBD (без нее можно идеально оптимизировать ненужное решение)
👉 TCO (общая стоимость) ≠ стоимость поездки — важно учитывать скрытые издержки: налоги, оргнагрузку и т.п.
👉 Организационная нагрузка имеет стоимость и потенциал для оптимизации — и это не всегда тривиальные затраты.
👉 Налоговая нагрузка зависит от формы предоставления и статуса исполнителя — без учёта этих нюансов легко ошибиться в расчётах.
👉 Стоимость поездки — результат сложного взаимодействия факторов — их наличие, сила и направление влияния проверяется аналитическими и/или экспериментальными способами.
👉 Риски и управляемость — следствия формы реализации — разные варианты по-разному масштабируются, контролируются и страхуются.
- подробнее на слайдах
💡 Если вы как внутренний продакт умеете:
— видеть цепочки бизнес-эффектов,
— формулировать ценность в метриках,
— аргументировать таким образом решения —
вы уже делаете важную часть core B2B-работы.
Останется освоить монетизацию, GTM, growth (и эксперименты, если раньше не практиковали).
ИМХО: То, что не требует аргументации — не требует и продакта. Настоящая практика начинается там, где ценность нужно найти и обосновывать, а не просто декларировать😉
Pro Product
#Компетенции #метрики
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5❤1