Product Operating Model: как масштабировать продуктовую команду?
Это вводный пост к серии, хочу в нем собрать мысли и комментарии по теме
Команда растёт: людей больше, встреч больше, задач больше.
А результат остаётся на прежнем уровне.
Проблема редко в людях и почти никогда не в мотивации.
Проблема в том, что команда работает без Operating Model - без понятной управленческой архитектуры.
Похоже на то, как строить пирамиду, просто насыпая песок в кучу:)
Продуктовая команда не просто набор ролей, это система.
В ней должно быть ясно, как стратегия превращается в реальные инициативы,
кто принимает решения и по каким правилам измеряется успех.
Если эти элементы не связаны, начинается предсказуемый хаос:
стратегия живёт отдельно от бэклога, решения пересматриваются, скорость доставки падает, появляется операционная усталость.
Люди начинают работать больше, но не эффективнее.
Operating Model - не бюрократия, а способ сделать рост управляемым.
В следующих 8 постах прорефлексирую архитектуру Product Operating Model. Без абстракций.
Только управленческие механизмы, которые позволяют команде расти без потери результата.
Если вы управляете продуктовой командой, эта серия для вас.
Какие управленческие механизмы реально работают у вас в команде?
❤️ есть работающие инструменты, отгружу в коммент
😈 у нас работает хаос
@product_lev
#pm #productmanagement #leadership #operating #model
Это вводный пост к серии, хочу в нем собрать мысли и комментарии по теме
Команда растёт: людей больше, встреч больше, задач больше.
А результат остаётся на прежнем уровне.
Проблема редко в людях и почти никогда не в мотивации.
Проблема в том, что команда работает без Operating Model - без понятной управленческой архитектуры.
Похоже на то, как строить пирамиду, просто насыпая песок в кучу:)
Продуктовая команда не просто набор ролей, это система.
В ней должно быть ясно, как стратегия превращается в реальные инициативы,
кто принимает решения и по каким правилам измеряется успех.
Если эти элементы не связаны, начинается предсказуемый хаос:
стратегия живёт отдельно от бэклога, решения пересматриваются, скорость доставки падает, появляется операционная усталость.
Люди начинают работать больше, но не эффективнее.
Operating Model - не бюрократия, а способ сделать рост управляемым.
В следующих 8 постах прорефлексирую архитектуру Product Operating Model. Без абстракций.
Только управленческие механизмы, которые позволяют команде расти без потери результата.
Если вы управляете продуктовой командой, эта серия для вас.
Какие управленческие механизмы реально работают у вас в команде?
❤️ есть работающие инструменты, отгружу в коммент
😈 у нас работает хаос
@product_lev
#pm #productmanagement #leadership #operating #model
1❤4✍3👍3😈1
Стратегия: от NSM к фокусу команды
В Target Operating Model стратегия первый слой.
Но в продукте она начинается не с красивых формулировок, а с конкретной метрики.
Сначала нужно понять контекст.
Какая ключевая метрика у вашего департамента? Что вы обязаны двигать?
Если это не определено, стратегия превращается в разговоры.
Дальше важный вопрос.
На какие показатели вы реально можете влиять как команда?
Стратегия продуктовой команды это не список идей и не набор инициатив.
Это выбор 3–5 жёстких фокусов, которые напрямую влияют на ваши метрики.
Логика простая:
→ NSM
→ метрики продукта
→ OKR
→ цели
→ конкретные гипотезы
Если этой связки нет, начинается хаос.
OKR живут сами по себе, гипотезы появляются из обсуждений, бэклог растёт.
Стратегия это дисциплина фокуса и отказа.
А вы строите её от ключевой метрики или от идей?
❤️ знаю NSM
😈 как карта ляжет
@product_lev
#pm #productmanagement #strategy #operating #model
В Target Operating Model стратегия первый слой.
Но в продукте она начинается не с красивых формулировок, а с конкретной метрики.
Сначала нужно понять контекст.
Какая ключевая метрика у вашего департамента? Что вы обязаны двигать?
Если это не определено, стратегия превращается в разговоры.
Дальше важный вопрос.
На какие показатели вы реально можете влиять как команда?
Стратегия продуктовой команды это не список идей и не набор инициатив.
Это выбор 3–5 жёстких фокусов, которые напрямую влияют на ваши метрики.
Логика простая:
→ NSM
→ метрики продукта
→ OKR
→ цели
→ конкретные гипотезы
Если этой связки нет, начинается хаос.
OKR живут сами по себе, гипотезы появляются из обсуждений, бэклог растёт.
Стратегия это дисциплина фокуса и отказа.
А вы строите её от ключевой метрики или от идей?
❤️ знаю NSM
😈 как карта ляжет
@product_lev
#pm #productmanagement #strategy #operating #model
1❤6👍4😈2
Governance: кто принимает решения
В Target Operating Model второй слой после стратегии это governance. Проще говоря, как в команде принимаются решения.
Во многих продуктовых командах проблема не в идеях и не в людях. Проблема в том, что решения принимаются… а потом пересматриваются. Это побочный эффект гибких подходов: обсуждаем, тестируем, возвращаемся, снова обсуждаем. В какой-то момент решение перестаёт быть решением.
Главный принцип простой: решение принимает тот, кто несёт ответственность за результат. Иногда это PM, иногда продакт овнер, иногда техлид. Всё зависит от масштаба и типа решения.
В управленческой теории это часто фиксируют через RACI:
• Responsible - кто делает
• Accountable - кто отвечает за результат
• Consulted - с кем нужно обсудить
• Informed - кого нужно уведомить
Если роль Accountable не определена, решение почти всегда будет пересмотрено. Глубже про это во фреймворке RAPID.
Я за консенсус, но без бесконечных обсуждений. Если время идёт, лидер должен разрубить Гордиев узел. Хорошее решение всегда можно разложить по SMART: понятно что делаем, кто отвечает и по чему проверим результат.
Самый опасный итог встречи звучит так: «Давайте ещё подумаем».
А у вас решения принимаются или обсуждаются?
❤️ принимаются
😈 обсуждаются
@product_lev
#pm #productmanagement #governance #operating #model
В Target Operating Model второй слой после стратегии это governance. Проще говоря, как в команде принимаются решения.
Во многих продуктовых командах проблема не в идеях и не в людях. Проблема в том, что решения принимаются… а потом пересматриваются. Это побочный эффект гибких подходов: обсуждаем, тестируем, возвращаемся, снова обсуждаем. В какой-то момент решение перестаёт быть решением.
Главный принцип простой: решение принимает тот, кто несёт ответственность за результат. Иногда это PM, иногда продакт овнер, иногда техлид. Всё зависит от масштаба и типа решения.
В управленческой теории это часто фиксируют через RACI:
• Responsible - кто делает
• Accountable - кто отвечает за результат
• Consulted - с кем нужно обсудить
• Informed - кого нужно уведомить
Если роль Accountable не определена, решение почти всегда будет пересмотрено. Глубже про это во фреймворке RAPID.
Я за консенсус, но без бесконечных обсуждений. Если время идёт, лидер должен разрубить Гордиев узел. Хорошее решение всегда можно разложить по SMART: понятно что делаем, кто отвечает и по чему проверим результат.
Самый опасный итог встречи звучит так: «Давайте ещё подумаем».
А у вас решения принимаются или обсуждаются?
❤️ принимаются
😈 обсуждаются
@product_lev
#pm #productmanagement #governance #operating #model
1❤6👍4😈4
Organization: как устроена продуктовая команда
Следующий слой Target Operating Model это структура команды.
Единой «правильной» модели здесь нет. Она всегда зависит от стадии продукта и масштаба компании.
Но есть универсальный принцип: команда должна быть способна доводить ценность до пользователя без постоянного ручного управления!
Проблемы начинаются, когда продакт превращается в диспетчера задач: распределяет тикеты, следит за статусами и ежедневно координирует людей. В этот момент продуктовая команда начинает работать как проектная.
Задача продакта другая: построить систему, в которой команда может двигаться самостоятельно.
Для этого роли внутри команды должны быть прозрачны.
Продакт отвечает за ценность продукта, цели и приоритеты.
Техлид - за архитектуру и техническую реализацию.
Дизайнер - за пользовательский опыт.
QA - за доставку изменений до продакшена и за передачу обратной связи из поддержки в продуктовый бэклог.
Чуть подробнее про каждую роль продуктовой писал выше.
Все участвуют в обсуждении и планировании. Но финальное решение о приоритете принимает продакт.
Хороший признак здоровой команды это автономность.
Если бэклог подготовлен и цели понятны, команда может несколько недель двигаться без постоянного участия PM.
Она опирается на цели продукта и на эмпатию к пользователю.
Самый опасный антипаттерн здесь это продакт как «секретарь Jira».
В такой модели команда перестаёт нести ответственность за результат.
А у вас продакт больше про продукт или про задачи?
❤️ про продукт
😈 про задачи
@product_lev
#pm #productmanagement #operating #model #team
Следующий слой Target Operating Model это структура команды.
Единой «правильной» модели здесь нет. Она всегда зависит от стадии продукта и масштаба компании.
Но есть универсальный принцип: команда должна быть способна доводить ценность до пользователя без постоянного ручного управления!
Проблемы начинаются, когда продакт превращается в диспетчера задач: распределяет тикеты, следит за статусами и ежедневно координирует людей. В этот момент продуктовая команда начинает работать как проектная.
Задача продакта другая: построить систему, в которой команда может двигаться самостоятельно.
Для этого роли внутри команды должны быть прозрачны.
Продакт отвечает за ценность продукта, цели и приоритеты.
Техлид - за архитектуру и техническую реализацию.
Дизайнер - за пользовательский опыт.
QA - за доставку изменений до продакшена и за передачу обратной связи из поддержки в продуктовый бэклог.
Чуть подробнее про каждую роль продуктовой писал выше.
Все участвуют в обсуждении и планировании. Но финальное решение о приоритете принимает продакт.
Хороший признак здоровой команды это автономность.
Если бэклог подготовлен и цели понятны, команда может несколько недель двигаться без постоянного участия PM.
Она опирается на цели продукта и на эмпатию к пользователю.
Самый опасный антипаттерн здесь это продакт как «секретарь Jira».
В такой модели команда перестаёт нести ответственность за результат.
А у вас продакт больше про продукт или про задачи?
❤️ про продукт
😈 про задачи
@product_lev
#pm #productmanagement #operating #model #team
❤6👍4😈4
Processes: как команда планирует работу
Следующий слой Target Operating Model это процессы, как стратегия превращается в конкретную работу команды.
Рабочая система обычно выстроена каскадом:
• собрана стратегия на год и дальше
• из неё формируются цели на год
• из них крупные инициативы в разрезе run, change, disrupt
• они формируют квартальные бакеты с задачами, сформулированными по SMART
И уже под них строится гант выполнения с разделением на discovery и delivery.
Чаще всего, даже в сильных командах, проблемы связаны с оценкой времени на discovery и с перегрузкой. В спринт начинают попадать задачи без приоритета и понятной ценности.
В такой системе полезно использовать дорожную карту продукта, как долгосрочный план и инструмент коммуникации. Она помогает команде и стейкхолдерам понимать, где и как инициативы расположены на временной оси, как они зависят друг от друга.
Главный признак хорошего процесса это предсказуемость. Команда понимает, что делает дальше. У процесса есть защита от постоянных срочных задач и система стабилизации фокуса.
Опасныо здесь уйти в бесконечный груминг и допускать постоянные влеты задач. В такие моменты важнее всего работа со стейкхолдерами и поддержание мотивации команды.
А у вас процесс сфокусирован или работаете в хаосе?
❤️ держим фокус
😈 живём в реактиве
@product_lev
#pm #productmanagement #process #operating #model
Следующий слой Target Operating Model это процессы, как стратегия превращается в конкретную работу команды.
Рабочая система обычно выстроена каскадом:
• собрана стратегия на год и дальше
• из неё формируются цели на год
• из них крупные инициативы в разрезе run, change, disrupt
• они формируют квартальные бакеты с задачами, сформулированными по SMART
И уже под них строится гант выполнения с разделением на discovery и delivery.
Чаще всего, даже в сильных командах, проблемы связаны с оценкой времени на discovery и с перегрузкой. В спринт начинают попадать задачи без приоритета и понятной ценности.
В такой системе полезно использовать дорожную карту продукта, как долгосрочный план и инструмент коммуникации. Она помогает команде и стейкхолдерам понимать, где и как инициативы расположены на временной оси, как они зависят друг от друга.
Главный признак хорошего процесса это предсказуемость. Команда понимает, что делает дальше. У процесса есть защита от постоянных срочных задач и система стабилизации фокуса.
Опасныо здесь уйти в бесконечный груминг и допускать постоянные влеты задач. В такие моменты важнее всего работа со стейкхолдерами и поддержание мотивации команды.
А у вас процесс сфокусирован или работаете в хаосе?
❤️ держим фокус
😈 живём в реактиве
@product_lev
#pm #productmanagement #process #operating #model
❤9👍3😈3🔥1
Performance: как измерять продуктовую команду
Одна из главных ошибок в управлении продуктом путать output и outcome. Команда может выпускать много фич, ускорять delivery и при этом не влиять на результат бизнеса.
Сильная продуктовая команда всегда связана со стратегией через метрики. Она понимает, какую продуктовую метрику должна двигать и как это отражается на выручке или росте ценности продукта.
Поэтому в центре измерения должны быть именно продуктовые показатели: retention, конверсия, использование ключевых сценариев. Но при этом нельзя терять связь с бизнесом и скоростью доставки изменений. Важно видеть и TTM, и влияние на экономику.
OKR в этой системе работает хорошо. Он помогает удерживать фокус на результате, а не на списке задач.
Моё мнение, что признак зрелости команды - это предсказуемость:
команда умеет планировать работу и стабильно двигает ключевую метрику + высокая скорость экспериментов при низком churn инициатив создаёт устойчивый рост.
Если метрики не связаны со стратегией, команда начинает оптимизировать локальные показатели и теряет направление.
А у вас команда измеряется фичами или результатом?
❤️ результатом
😈 количеством релизов
@product_lev
#pm #productmanagement #metrics #operating #model
Одна из главных ошибок в управлении продуктом путать output и outcome. Команда может выпускать много фич, ускорять delivery и при этом не влиять на результат бизнеса.
Сильная продуктовая команда всегда связана со стратегией через метрики. Она понимает, какую продуктовую метрику должна двигать и как это отражается на выручке или росте ценности продукта.
Поэтому в центре измерения должны быть именно продуктовые показатели: retention, конверсия, использование ключевых сценариев. Но при этом нельзя терять связь с бизнесом и скоростью доставки изменений. Важно видеть и TTM, и влияние на экономику.
OKR в этой системе работает хорошо. Он помогает удерживать фокус на результате, а не на списке задач.
Моё мнение, что признак зрелости команды - это предсказуемость:
команда умеет планировать работу и стабильно двигает ключевую метрику + высокая скорость экспериментов при низком churn инициатив создаёт устойчивый рост.
Если метрики не связаны со стратегией, команда начинает оптимизировать локальные показатели и теряет направление.
А у вас команда измеряется фичами или результатом?
❤️ результатом
😈 количеством релизов
@product_lev
#pm #productmanagement #metrics #operating #model
👍7❤4🔥2
People: как строить сильную продуктовую команду
В Target Operating Model заложен принцип роста команды вместе с продуктом.
Мне ближе роль PM, поэтому порассуждаю про него.
Команда мечты редко собирается только из «звёзд». Намного устойчивее работают команды, где сильные специалисты делают что-то новое для себя и продолжают расти. Такой рост не происходит случайно, его нужно строить системно.
Сильный продакт это самостоятельный специалист. Он понимает стратегию, умеет принимать решения, обладает насмотренностью и выстраивает коммуникации. При этом он знает процессы и их слабые стороны.
Одна из частых ошибок это отсутствие фокуса на развитии. Когда нет ПИРа и задачи планируются без учёта того, чему должен научиться человек, команда начинает топтаться на месте.
Рост продакта это прежде всего сравнение себя с собой из прошлого. Уже потом появляется сравнение с коллегами и внешним рынком.
Талант важен. Но сильные продуктовые команды появляются там, где талант выращивают через ответственность и развитие.
А у вас команда растёт или просто работает?
❤️ растёт ввысь
😈 растёт вшырь
@product_lev
#pm #productmanagement #people #operating #model
В Target Operating Model заложен принцип роста команды вместе с продуктом.
Мне ближе роль PM, поэтому порассуждаю про него.
Команда мечты редко собирается только из «звёзд». Намного устойчивее работают команды, где сильные специалисты делают что-то новое для себя и продолжают расти. Такой рост не происходит случайно, его нужно строить системно.
Сильный продакт это самостоятельный специалист. Он понимает стратегию, умеет принимать решения, обладает насмотренностью и выстраивает коммуникации. При этом он знает процессы и их слабые стороны.
Одна из частых ошибок это отсутствие фокуса на развитии. Когда нет ПИРа и задачи планируются без учёта того, чему должен научиться человек, команда начинает топтаться на месте.
Рост продакта это прежде всего сравнение себя с собой из прошлого. Уже потом появляется сравнение с коллегами и внешним рынком.
Талант важен. Но сильные продуктовые команды появляются там, где талант выращивают через ответственность и развитие.
А у вас команда растёт или просто работает?
❤️ растёт ввысь
😈 растёт вшырь
@product_lev
#pm #productmanagement #people #operating #model
2👍6✍4❤2
Culture: как поведение команды влияет на результат
В Target Operating Model культура это связующая среда, в которой работают все остальные элементы.
Культура не возникает сама по себе. Она формируется управленческими решениями лидеров, именно они задают, что в команде считается нормой.
Сильная продуктовая команда строится на прозрачности. Люди понимают цели, видят принятые решения и обмениваются опытом.
В такой среде можно аргументированно спорить и быть услышанным, это напрямую влияет на качество решений.
Культура часто ломается незаметно или в тишине: появляется blame culture(осуждаю), команда начинает избегать ответственности. Люди перестают поднимать проблемы, решения принимаются осторожно, скорость падает.
Ошибки в продуктовой работе неизбежны. Они допустимы, если из них сделаны выводы. Но масштаб ошибки всегда важен. Чем выше влияние решения, тем выше требования к подготовке.
Выстраивать культуру помогают управленческие ритуалы. Например, честные ретроспективы и открытые демо. Также сильное влияние оказывает найм специалистов, выросших в командах со зрелой культурой.
А у вас культура помогает принимать решения?
❤️ влияет сильно
😈 почти не влияет
@product_lev
#pm #productmanagement #culture #operating #model
В Target Operating Model культура это связующая среда, в которой работают все остальные элементы.
Культура не возникает сама по себе. Она формируется управленческими решениями лидеров, именно они задают, что в команде считается нормой.
Сильная продуктовая команда строится на прозрачности. Люди понимают цели, видят принятые решения и обмениваются опытом.
В такой среде можно аргументированно спорить и быть услышанным, это напрямую влияет на качество решений.
Культура часто ломается незаметно или в тишине: появляется blame culture(осуждаю), команда начинает избегать ответственности. Люди перестают поднимать проблемы, решения принимаются осторожно, скорость падает.
Ошибки в продуктовой работе неизбежны. Они допустимы, если из них сделаны выводы. Но масштаб ошибки всегда важен. Чем выше влияние решения, тем выше требования к подготовке.
Выстраивать культуру помогают управленческие ритуалы. Например, честные ретроспективы и открытые демо. Также сильное влияние оказывает найм специалистов, выросших в командах со зрелой культурой.
А у вас культура помогает принимать решения?
❤️ влияет сильно
😈 почти не влияет
@product_lev
#pm #productmanagement #culture #operating #model
❤6👍4✍2
Product Operating Model
С середины февраля разобрал ключевые элементы Operating Model.
Для меня это управленческая база, на которой можно строить меморандум продуктовой команды и её принципы работы.
Operating Model начинается со стратегии.
Команда должна понимать, какую метрику она двигает и как её работа влияет на бизнес-результат.
Дальше стратегия превращается в гипотезы и проверяется через HADI-циклы. Это задаёт ритм работы и помогает не терять фокус.
Решения принимаются там, где есть ответственность.
Структура команды строится вокруг способности доводить ценность до пользователя без постоянного ручного управления.
Процессы позволяют планировать работу предсказуемо и защищать фокус от реактивности.
Метрики связывают ежедневные инициативы со стратегией и экономикой продукта.
Развитие людей происходит через задачи и осознанные ПИРы.
Культура определяет скорость обучения команды и качество принимаемых решений.
В итоге Operating Model - это система координат, которая позволяет масштабировать продуктовую команду без потери результата и без опоры на героизм отдельных людей.
Посты серии:
1️⃣ Strategy: куда идём, какую метрику двигаем, за счёт чего побеждаем
2️⃣ Governance: кто принимает решения, по каким правилам, где ответственность
3️⃣ Organization: как распределены роли и зоны ответственности
4️⃣ Processes: как стратегия живет в задачах и релизах
5️⃣ Performance: как измеряется вклад каждого члена команды в результат
6️⃣ People: как растут продакты и команда в целом
7️⃣ Culture: нормы поведения, отношение к ошибкам, уровень ответственности
А у вас в команде сформулированы принципы работы?
❤️ есть понятная система
😈 живём от задачи к задаче
@product_lev
#pm #productmanagement #operating #model
С середины февраля разобрал ключевые элементы Operating Model.
Для меня это управленческая база, на которой можно строить меморандум продуктовой команды и её принципы работы.
Operating Model начинается со стратегии.
Команда должна понимать, какую метрику она двигает и как её работа влияет на бизнес-результат.
Дальше стратегия превращается в гипотезы и проверяется через HADI-циклы. Это задаёт ритм работы и помогает не терять фокус.
Решения принимаются там, где есть ответственность.
Структура команды строится вокруг способности доводить ценность до пользователя без постоянного ручного управления.
Процессы позволяют планировать работу предсказуемо и защищать фокус от реактивности.
Метрики связывают ежедневные инициативы со стратегией и экономикой продукта.
Развитие людей происходит через задачи и осознанные ПИРы.
Культура определяет скорость обучения команды и качество принимаемых решений.
В итоге Operating Model - это система координат, которая позволяет масштабировать продуктовую команду без потери результата и без опоры на героизм отдельных людей.
Посты серии:
1️⃣ Strategy: куда идём, какую метрику двигаем, за счёт чего побеждаем
2️⃣ Governance: кто принимает решения, по каким правилам, где ответственность
3️⃣ Organization: как распределены роли и зоны ответственности
4️⃣ Processes: как стратегия живет в задачах и релизах
5️⃣ Performance: как измеряется вклад каждого члена команды в результат
6️⃣ People: как растут продакты и команда в целом
7️⃣ Culture: нормы поведения, отношение к ошибкам, уровень ответственности
А у вас в команде сформулированы принципы работы?
❤️ есть понятная система
😈 живём от задачи к задаче
@product_lev
#pm #productmanagement #operating #model
❤4✍3🔥2👍1😈1
Что почитать?
Проектное управление, Павел Алферов
Кому: тем, кто работает с проектами и хочет навести порядок в голове
Количество страниц: 400
Оценка: 10 управляемых проектов из 10
Часть 1. Отзыв
В книге крепкая системная база по проектному управлению: аккуратная сборка практик, терминов и подходов, с разбором национальных особенностей!
Лично для меня она сработала как инструмент наведения порядка, особенно в моментах, где раньше действовал интуитивно. Например, интересный фрейм про круг проектного мышления. Когда ты отказываешься от какого-то фокуса в проекте, ты не только режешь косты, а принимаешь риски: круто делать это осознанно, а не просто на автомате.
Из того, что забрал себе: систему характеризует не масштаб проблем, а то, как она на них реагирует. Хорошо разложена разница между проектом и продуктом проекта. Из инструментов, освежил применимость MoSCoW для первичного сбора требований. Плюс для себя роль спонсора проекта.
Итого, это книга, которая структурирует инструменты ведения проекта с учетом национальных особенностей. Можно читать рядом с Русской моделью управления Александра Прохорова, в ней больше про историю.
Часть 2. Как читали в клубе
Книга очень зашла в Книжном клубе, обсудили много заметок и кейсов из практики.
Обсуждали «белых слонов» или чемоданы без ручки: проекты, которые все тянут, но никто не готов остановить.
Три субботы подряд говорили про разницу в проектном управлении, роли продакта и продакт овнера:)
Книга классно раскрылась именно в обсуждении: сам читаешь и забираешь пару идей, а в группе начинаешь видеть больше за счёт чужого опыта.
Если вам тоже интересно не просто читать, а разбирать такие вещи на практике, присоединяйтесь к Книжному клубу для менеджеров.
Часто обсуждение даёт еще больше, чем просто чтение! По полезности: чтение->обсуждение(рефлексия1)->применение->рефлексия2
@product_lev
#чтопочитать #проекты #управление #productmanagement #книжныйклуб
Проектное управление, Павел Алферов
Кому: тем, кто работает с проектами и хочет навести порядок в голове
Количество страниц: 400
Оценка: 10 управляемых проектов из 10
Часть 1. Отзыв
В книге крепкая системная база по проектному управлению: аккуратная сборка практик, терминов и подходов, с разбором национальных особенностей!
Лично для меня она сработала как инструмент наведения порядка, особенно в моментах, где раньше действовал интуитивно. Например, интересный фрейм про круг проектного мышления. Когда ты отказываешься от какого-то фокуса в проекте, ты не только режешь косты, а принимаешь риски: круто делать это осознанно, а не просто на автомате.
Из того, что забрал себе: систему характеризует не масштаб проблем, а то, как она на них реагирует. Хорошо разложена разница между проектом и продуктом проекта. Из инструментов, освежил применимость MoSCoW для первичного сбора требований. Плюс для себя роль спонсора проекта.
Итого, это книга, которая структурирует инструменты ведения проекта с учетом национальных особенностей. Можно читать рядом с Русской моделью управления Александра Прохорова, в ней больше про историю.
Часть 2. Как читали в клубе
Книга очень зашла в Книжном клубе, обсудили много заметок и кейсов из практики.
Обсуждали «белых слонов» или чемоданы без ручки: проекты, которые все тянут, но никто не готов остановить.
Три субботы подряд говорили про разницу в проектном управлении, роли продакта и продакт овнера:)
Книга классно раскрылась именно в обсуждении: сам читаешь и забираешь пару идей, а в группе начинаешь видеть больше за счёт чужого опыта.
Если вам тоже интересно не просто читать, а разбирать такие вещи на практике, присоединяйтесь к Книжному клубу для менеджеров.
Часто обсуждение даёт еще больше, чем просто чтение! По полезности: чтение->обсуждение(рефлексия1)->применение->рефлексия2
@product_lev
#чтопочитать #проекты #управление #productmanagement #книжныйклуб
👍5❤4✍2
Словарикпродакта: лонгитюдное исследование
В честь прошедшего 1го апреля делюсь откровением: в 30 лет можно кекнуть со слова лонгитюдное.
Мне название показалось забавным, поэтому метод идет в #словарикпродакта
Суть в том, что одних и тех же респондентов опрашивают несколько раз через промежутки времени, чтобы понять, как меняется их опыт, поведение или мнение.
Это похоже на дневниковое исследование, только там участник сам фиксирует наблюдения в дневнике.
Поэтому не каждое лонгитюдное исследование дневниковое, но дневниковое часто бывает лонгитюдным.
Классический пример: исследование первых пользователей iPhone, за которыми наблюдали пять недель после покупки, чтобы понять, как со временем меняется опыт использования.
Вы хоть раз проводили дневниковое исследование?
❤️ было
😈 только в книжках читал
#лонгитюдное #исследование #словарикпродакта #pm
В честь прошедшего 1го апреля делюсь откровением: в 30 лет можно кекнуть со слова лонгитюдное.
Мне название показалось забавным, поэтому метод идет в #словарикпродакта
Суть в том, что одних и тех же респондентов опрашивают несколько раз через промежутки времени, чтобы понять, как меняется их опыт, поведение или мнение.
Это похоже на дневниковое исследование, только там участник сам фиксирует наблюдения в дневнике.
Поэтому не каждое лонгитюдное исследование дневниковое, но дневниковое часто бывает лонгитюдным.
Классический пример: исследование первых пользователей iPhone, за которыми наблюдали пять недель после покупки, чтобы понять, как со временем меняется опыт использования.
Вы хоть раз проводили дневниковое исследование?
❤️ было
#лонгитюдное #исследование #словарикпродакта #pm
Please open Telegram to view this post
VIEW IN TELEGRAM
✍4❤3👍2😈2
Вайбкодинг для продакта: от FOMO к первому PoC
Последние месяцы у меня было классическое FOMO: из каждого утюга звучало про вайбкодинг, ИИ, который пишет продукты, и одиночек, собирающих то, что раньше делали команды. Долго смотрел на это со стороны, читал, кивал, сохранял в избранное посты.
Пока не случился простой триггер: мой руководитель сам собрал сервис.
В этот момент стало реально неловко просто читать-наблюдать.
Решил собрать руками PoC чат-бот мини-игры и понять, как это вообще работает.
Главный инсайт пришёл довольно быстро: вайбкодинг для продакта это не про код, а про понимание системы.
Когда ты сам проходишь путь от идеи до архитектуры, ограничений и рабочего сервиса, у тебя резко меняется уровень насмотренности.
Ты начинаешь лучше понимать, где рождаются реальные ограничения, чего на самом деле стоит «просто сделать фичу» и как продукт устроен под капотом. Это не делает тебя разработчиком, но делает чётче как продакта, ты начинаешь мыслить не только через идеи, но и через реализацию.
Мой вывод пока простой: вайбкодинг это не про хайп и не про замену команд, это быстрый способ прокачать системное мышление через практику, а заодно возможность ускорять получение прототипов для исследований.
А вот где заканчивается «вайб» и начинается реальность, и что на самом деле съедает больше всего времени разберу в следующем посте.
А вы уже пробовали собрать что-то сами?
❤️ да
😈 пока толькочитаюсохраняю в избранное
@product_lev
#pm #ai #productmanagement #vibecoding
Последние месяцы у меня было классическое FOMO: из каждого утюга звучало про вайбкодинг, ИИ, который пишет продукты, и одиночек, собирающих то, что раньше делали команды. Долго смотрел на это со стороны, читал, кивал, сохранял в избранное посты.
Пока не случился простой триггер: мой руководитель сам собрал сервис.
В этот момент стало реально неловко просто читать-наблюдать.
Решил собрать руками PoC чат-бот мини-игры и понять, как это вообще работает.
Главный инсайт пришёл довольно быстро: вайбкодинг для продакта это не про код, а про понимание системы.
Когда ты сам проходишь путь от идеи до архитектуры, ограничений и рабочего сервиса, у тебя резко меняется уровень насмотренности.
Ты начинаешь лучше понимать, где рождаются реальные ограничения, чего на самом деле стоит «просто сделать фичу» и как продукт устроен под капотом. Это не делает тебя разработчиком, но делает чётче как продакта, ты начинаешь мыслить не только через идеи, но и через реализацию.
Мой вывод пока простой: вайбкодинг это не про хайп и не про замену команд, это быстрый способ прокачать системное мышление через практику, а заодно возможность ускорять получение прототипов для исследований.
А вот где заканчивается «вайб» и начинается реальность, и что на самом деле съедает больше всего времени разберу в следующем посте.
А вы уже пробовали собрать что-то сами?
❤️ да
😈 пока только
@product_lev
#pm #ai #productmanagement #vibecoding
2❤7🔥5😈3👍1
Вайбкодинг для продакта: где заканчивается вайб и начинается реальность
продолжение поста
У меня не было ожиданий, что придётся писать код самому.
Я изначально предполагал, что код будет написан за меня, а моя задача только синхронизировать своё понимание системы с тем, что проектирует Codex: перепроверять и себя, и его.
Главное открытие: как глубока кроличья нора. Как только ты выходишь за рамки локальной проверки, начинается работа с системой.
Хочешь сделать что-то реально рабочее, с минимумом костылей, значит нужен сервер, домен для поднятия HTTPS, нормальный production-контур. И дальше ты начинаешь разбираться, как связаны между собой хостинг, вебхуки, nginx, docker и деплой.
В этот момент становится очевидно: без понимания системы ты начинаешь действовать вслепую. Можно не знать все термины, но нужно понимать, как всё устроено, иначе каждая проблема превращается в угадайку.
По факту большая часть времени уходит не на сборку фич, а на разбор того, почему что-то не работает. Отладка становится главным пожирателем времени.
Работа с агентом для меня сильно похожа на списывание сложного предмета у отличника. Можно просто переписывать и со всем соглашаться, но тогда легко пропустить ошибки и сдать неверное решение. А можно начать разбираться, но тогда есть риск не уложиться в срок. Баланс между скоростью и пониманием приходится искать постоянно.
Агент помогает собрать контур, но не заменяет понимание системы и не снимает ответственности за результат. Если его не корректировать, он может начать ходить по кругу или сложно решать простые задачи, от которых иногда разумнее отказаться.
И именно здесь заканчивается вайб.
В следующем посте разберу, как использовать вайбкодинг без FOMO и не тратить время впустую. Например, почему важно заранее понимать, что может оказаться платным и какие есть обходные решения.
А у вас где было самое большое трение?
❤️ инфраструктура
😈 отладка
@product_lev
#pm #ai #productmanagement #vibecoding
продолжение поста
У меня не было ожиданий, что придётся писать код самому.
Я изначально предполагал, что код будет написан за меня, а моя задача только синхронизировать своё понимание системы с тем, что проектирует Codex: перепроверять и себя, и его.
Главное открытие: как глубока кроличья нора. Как только ты выходишь за рамки локальной проверки, начинается работа с системой.
Хочешь сделать что-то реально рабочее, с минимумом костылей, значит нужен сервер, домен для поднятия HTTPS, нормальный production-контур. И дальше ты начинаешь разбираться, как связаны между собой хостинг, вебхуки, nginx, docker и деплой.
В этот момент становится очевидно: без понимания системы ты начинаешь действовать вслепую. Можно не знать все термины, но нужно понимать, как всё устроено, иначе каждая проблема превращается в угадайку.
По факту большая часть времени уходит не на сборку фич, а на разбор того, почему что-то не работает. Отладка становится главным пожирателем времени.
Работа с агентом для меня сильно похожа на списывание сложного предмета у отличника. Можно просто переписывать и со всем соглашаться, но тогда легко пропустить ошибки и сдать неверное решение. А можно начать разбираться, но тогда есть риск не уложиться в срок. Баланс между скоростью и пониманием приходится искать постоянно.
Агент помогает собрать контур, но не заменяет понимание системы и не снимает ответственности за результат. Если его не корректировать, он может начать ходить по кругу или сложно решать простые задачи, от которых иногда разумнее отказаться.
И именно здесь заканчивается вайб.
В следующем посте разберу, как использовать вайбкодинг без FOMO и не тратить время впустую. Например, почему важно заранее понимать, что может оказаться платным и какие есть обходные решения.
А у вас где было самое большое трение?
❤️ инфраструктура
😈 отладка
@product_lev
#pm #ai #productmanagement #vibecoding
👍6❤3🔥2😁1😈1
Вайбкодинг для продакта: от ступора к действию
Главное, что мешает начать, это не объективная сложность, а субъективный ступор.
Лично для меня было так: много контента, много мнений, ощущение, что сначала нужно всё понять, а потом уже пробовать.
Решил через очень простую логику действий, по примеру как было с поиском в гпт:
1. быстро что-то гуглю через GPT и задаю уточняющие вопросы, когда агент в контексте
2. если тема зацепила, иду в Perplexity и чуть глубже исследую на актуальных данных с онлайн поиском в интернете
3. если нужно понимание поведения, можно собрать персоны и прогнать через ИИ-интервью, например, в Gemini
Логика быстрого старта в вайбкодинге:
1. Возьмите простую задачу: что-то элементарное. Например, мини-игру - змейку или флуд-бота, который на любое сообщение в чате с «ура» отвечает «ура» в ответ.
2. Опишите идею в Codex и сразу задайте рамку: это учебный проект, вы хотите разобраться в программировании через ИИ, просите объяснять план действий.
3. Запустите локально и дотащите до прода(агент подскажет как!). Пусть это будет маленький, но реально работающий сервис.
Можно добавить в промпт, чтоб агент с вами сюсюкался - это полезно для обучения:
Ключевой момент в том, что не нужно всё понимать с самого начала. Понимание придёт в процессе:)
Лайфхак: если что-то не понятно при общении с агентом, не засоряйте основной тред. Уточните в отдельном чате у GPT и вернитесь с понятным контекстом.
Если возникли проблемы и непонимание - велком в комментарии, я скорее отвечу, что тоже не знаю - попробуем найти ответ вместе:)
Итого: за ОДИН субботний вечер вы герой-вайбкодер, можете обновлять резюме, вы прекрасны!🤝
А вы уже пробовали что-то собрать руками?
❤️ да
😈 всё ещё думаю начать
@product_lev
#pm #ai #productmanagement #vibecoding
Главное, что мешает начать, это не объективная сложность, а субъективный ступор.
Лично для меня было так: много контента, много мнений, ощущение, что сначала нужно всё понять, а потом уже пробовать.
Решил через очень простую логику действий, по примеру как было с поиском в гпт:
1. быстро что-то гуглю через GPT и задаю уточняющие вопросы, когда агент в контексте
2. если тема зацепила, иду в Perplexity и чуть глубже исследую на актуальных данных с онлайн поиском в интернете
3. если нужно понимание поведения, можно собрать персоны и прогнать через ИИ-интервью, например, в Gemini
Логика быстрого старта в вайбкодинге:
1. Возьмите простую задачу: что-то элементарное. Например, мини-игру - змейку или флуд-бота, который на любое сообщение в чате с «ура» отвечает «ура» в ответ.
2. Опишите идею в Codex и сразу задайте рамку: это учебный проект, вы хотите разобраться в программировании через ИИ, просите объяснять план действий.
3. Запустите локально и дотащите до прода(агент подскажет как!). Пусть это будет маленький, но реально работающий сервис.
Можно добавить в промпт, чтоб агент с вами сюсюкался - это полезно для обучения:
• объясняй каждое решение простыми словами, как для новичка
• перед реализацией коротко описывай план действий
• предлагай несколько вариантов, если есть выбор
• явно указывай, где могут быть ошибки или ограничения
• не делай лишнего, держись в рамках задачи
• если видишь упрощение, предложи его
• задавай уточняющие вопросы, если контекста недостаточно, не придумывай самостоятельно
Ключевой момент в том, что не нужно всё понимать с самого начала. Понимание придёт в процессе:)
Лайфхак: если что-то не понятно при общении с агентом, не засоряйте основной тред. Уточните в отдельном чате у GPT и вернитесь с понятным контекстом.
Если возникли проблемы и непонимание - велком в комментарии, я скорее отвечу, что тоже не знаю - попробуем найти ответ вместе:)
Итого: за ОДИН субботний вечер вы герой-вайбкодер, можете обновлять резюме, вы прекрасны!🤝
А вы уже пробовали что-то собрать руками?
❤️ да
😈 всё ещё думаю начать
@product_lev
#pm #ai #productmanagement #vibecoding
❤7✍2👍2😈2
Продакт не должен быть секретарем Jira
В работе продакта есть тонкий баланс между дисциплиной в трекере и временем на реальную продуктовую проработку.
Без порядка быстро начинается хаос: задачи теряются, статусы устаревают, договоренности остаются только в головах.
Но и обратная крайность не лучше, когда продакт слишком глубоко проваливается в операционку - он постепенно превращается в координатора карточек. Внешне все выглядит аккуратно, но на главное уже не остается ресурса.
Для меня ориентир простой: трекер нужен, чтобы команда держала delivery под контролем. Но трекер не должен становиться центром роли продакта.
Роль продакта в другом: держать фокус на ценности, приоритетах и решениях. Понимать, что действительно двигает продукт вперед, а что просто создает ощущение управляемости.
Хороший признак здоровой системы такой: команда умеет жить внутри процесса без постоянного ручного проталкивания со стороны продакта. А у самого продакта остается время на пользователя, гипотезы и следующий сильный шаг для продукта.
Если весь день уходит на статусы, пинги и переписывание задач, это уже не продакт менеджмент, это секретариат трекера!
Продакт не должен быть секретарем Jira, продакт -секретарь эксельки и паверпоинта.
Как разгружаете себя от джиры?
❤️ помогает проджект и тимлид
😈 веду задачи в кайтене
@product_lev
#pm #трекер #джира #кайтен
В работе продакта есть тонкий баланс между дисциплиной в трекере и временем на реальную продуктовую проработку.
Без порядка быстро начинается хаос: задачи теряются, статусы устаревают, договоренности остаются только в головах.
Но и обратная крайность не лучше, когда продакт слишком глубоко проваливается в операционку - он постепенно превращается в координатора карточек. Внешне все выглядит аккуратно, но на главное уже не остается ресурса.
Для меня ориентир простой: трекер нужен, чтобы команда держала delivery под контролем. Но трекер не должен становиться центром роли продакта.
Роль продакта в другом: держать фокус на ценности, приоритетах и решениях. Понимать, что действительно двигает продукт вперед, а что просто создает ощущение управляемости.
Хороший признак здоровой системы такой: команда умеет жить внутри процесса без постоянного ручного проталкивания со стороны продакта. А у самого продакта остается время на пользователя, гипотезы и следующий сильный шаг для продукта.
Если весь день уходит на статусы, пинги и переписывание задач, это уже не продакт менеджмент, это секретариат трекера!
Продакт не должен быть секретарем Jira, продакт -
Как разгружаете себя от джиры?
❤️ помогает проджект и тимлид
😈 веду задачи в кайтене
@product_lev
#pm #трекер #джира #кайтен
👍6❤5😁2👀2
Должен ли продакт понимать продажи?
Да, чтобы понимать, где именно интерес превращается в деньги. В противном случае будет переоценка фич и недооценка барьеров покупки.
Базово можно разложить продавание на 4 вопроса:
1. Потребность. Человеку это вообще надо?
2. Барьер. Что мешает купить?
3. Ценность. Оффер выглядит выгодно?
4. Триггер. Хочется именно сейчас?
Итого: убрать сомнения, сделать ценность очевидной, упростить выбор, подтолкнуть к действию в нужный момент.
Например в Booking, продукт помогает не только выбрать вариант, но и решиться на покупку: соцдоказательство, удобные условия отмены, подсветка выгоды, дефицит.
Так что понимание продаж нужно продакту, чтоб отвечать не только за интерфейс, но и за деньги.
А вы в своем продукте по всем вопросам прошлись?
❤️ еще и фреймворки из хэштегов использовали
😈 наш продукт не продается
@product_lev
#JTBD #ValuePropositionCanvas #FBM #pm
Да, чтобы понимать, где именно интерес превращается в деньги. В противном случае будет переоценка фич и недооценка барьеров покупки.
Базово можно разложить продавание на 4 вопроса:
1. Потребность. Человеку это вообще надо?
2. Барьер. Что мешает купить?
3. Ценность. Оффер выглядит выгодно?
4. Триггер. Хочется именно сейчас?
Итого: убрать сомнения, сделать ценность очевидной, упростить выбор, подтолкнуть к действию в нужный момент.
Например в Booking, продукт помогает не только выбрать вариант, но и решиться на покупку: соцдоказательство, удобные условия отмены, подсветка выгоды, дефицит.
Так что понимание продаж нужно продакту, чтоб отвечать не только за интерфейс, но и за деньги.
А вы в своем продукте по всем вопросам прошлись?
❤️ еще и фреймворки из хэштегов использовали
😈 наш продукт не продается
@product_lev
#JTBD #ValuePropositionCanvas #FBM #pm
👍5😈3✍2❤1
AI ускоряет бардак
Раньше можно было выигрывать за счет скорости.
Сейчас скорость стала доступна почти всем: Copilot ускоряет код, Cursor берет часть разработки, v0 и Replit быстро собирают прототипы.
Из-за этого дефицитом становится не скорость, а контекст.
Если у команды не собраны пользовательские инсайты, бизнес-ограничения, история решений и выводы из прошлых экспериментов, AI начинает масштабировать путаницу.
Поэтому новая задача продакта структурировать контекст так, чтобы команда и AI работали не быстрее сами по себе, а быстрее в правильную сторону.
Происходит сдвиг роли:
раньше сильный продакт управлял фокусом.
Теперь еще и шерингом контекста. Контекст становится новой валютой продуктовой команды.
Вы качественно храните контекст?
❤️ всё в Вики, HADI циклы крутятся
😈 ждем ии-агентов, которые сами соберут
@product_lev
#ai #pm
Раньше можно было выигрывать за счет скорости.
Сейчас скорость стала доступна почти всем: Copilot ускоряет код, Cursor берет часть разработки, v0 и Replit быстро собирают прототипы.
Из-за этого дефицитом становится не скорость, а контекст.
Если у команды не собраны пользовательские инсайты, бизнес-ограничения, история решений и выводы из прошлых экспериментов, AI начинает масштабировать путаницу.
Поэтому новая задача продакта структурировать контекст так, чтобы команда и AI работали не быстрее сами по себе, а быстрее в правильную сторону.
Происходит сдвиг роли:
раньше сильный продакт управлял фокусом.
Теперь еще и шерингом контекста. Контекст становится новой валютой продуктовой команды.
Вы качественно храните контекст?
❤️ всё в Вики, HADI циклы крутятся
😈 ждем ии-агентов, которые сами соберут
@product_lev
#ai #pm
❤6😈3👍2✍1💯1
Словарикпродакта: AI evals
Недавно занес себе в словарик термин AI evals - системный подход к оценке качества работы ИИ.
По сути, это структурированная проверка того, насколько AI в продукте делает именно то, что мы от него ждем, а не просто выдает правдоподобный ответ.
Например, в AI-агенте для поддержки обычно смотрят не только на качество ответа, но и на продуктовые метрики:
deflection rate - доля обращений, которые бот снял без передачи человеку
resolution rate - доля решенных обращений
CES(Customer Experience Score) - оценка клиентского опыта
То есть вопрос уже не в том, хорошо ли бот написал, а в том, снял ли он нагрузку с команды и реально решил ли вопрос клиента.
Зачем вы внедряете ИИ?
❤️ чтоб было эффективнее
😈 чтоб было
#cловарикпродакта #ai #evals #pm
Недавно занес себе в словарик термин AI evals - системный подход к оценке качества работы ИИ.
По сути, это структурированная проверка того, насколько AI в продукте делает именно то, что мы от него ждем, а не просто выдает правдоподобный ответ.
Например, в AI-агенте для поддержки обычно смотрят не только на качество ответа, но и на продуктовые метрики:
deflection rate - доля обращений, которые бот снял без передачи человеку
resolution rate - доля решенных обращений
CES(Customer Experience Score) - оценка клиентского опыта
То есть вопрос уже не в том, хорошо ли бот написал, а в том, снял ли он нагрузку с команды и реально решил ли вопрос клиента.
Зачем вы внедряете ИИ?
❤️ чтоб было эффективнее
#cловарикпродакта #ai #evals #pm
Please open Telegram to view this post
VIEW IN TELEGRAM
❤5😈3👍2
Шпора по A/B-тестам
Постарался собрать воедино базу по а/б-тестам, можете пробежаться взглядом и отдельно с изучить, чего не касались в своем опыте.
Разбил по этапам:
1. Формулируем гипотезу
одна гипотеза → одна основная метрика
фиксируем guardrail-метрики, чтобы рост CTR не оказался падением выручки, retention или качества
сразу определяем единицу рандомизации: кого делим, user/session/order
2. Фиксируем правила до старта
окно атрибуции: за какой период проверяем эффект
α=0,05 - ошибка первого рода: риск увидеть эффект, которого нет
power(1 − β)=80% -мощность(обратная вероятность ошибки второго рода), шанс заметить реальный эффект, если он правда есть
baseline + MDE: от чего отталкиваемся и какой минимальный эффект хотим поймать
Плюс заранее выбираем модель, если сравниваем..
..бинарную метрику, например CTR → z-test
..среднее, например time spent → t-test
..отношение, например ARPU → delta method
Главное: заранее определяем критерий принятия решения.
3. Считаем до запуска
размер выборки берем из калькулятора1
выдерживаем качество выборки - используем корректную рандомизацию
длительность считаем примерно так:
дней = выборка целиком / (DAU × доля пользователей в эксперименте)
4. Проводим тест
во время теста проверяем SRM, можно по калькулятору2 чекнуть критичность
если группы разъехались по размеру, сначала разбираемся с экспериментом, а не с результатом
5. Подводим итоги
считаем результат, но не отдаём решение на аутсорс калькулятору3.
статистика отвечает, похож ли эффект на случайность,
продакт решает стоит ли это раскатывать
#pm #abтесты #аналитика
Постарался собрать воедино базу по а/б-тестам, можете пробежаться взглядом и отдельно с изучить, чего не касались в своем опыте.
Разбил по этапам:
1. Формулируем гипотезу
одна гипотеза → одна основная метрика
фиксируем guardrail-метрики, чтобы рост CTR не оказался падением выручки, retention или качества
сразу определяем единицу рандомизации: кого делим, user/session/order
2. Фиксируем правила до старта
окно атрибуции: за какой период проверяем эффект
α=0,05 - ошибка первого рода: риск увидеть эффект, которого нет
power(1 − β)=80% -мощность(обратная вероятность ошибки второго рода), шанс заметить реальный эффект, если он правда есть
baseline + MDE: от чего отталкиваемся и какой минимальный эффект хотим поймать
Плюс заранее выбираем модель, если сравниваем..
..бинарную метрику, например CTR → z-test
..среднее, например time spent → t-test
..отношение, например ARPU → delta method
Главное: заранее определяем критерий принятия решения.
3. Считаем до запуска
размер выборки берем из калькулятора1
выдерживаем качество выборки - используем корректную рандомизацию
длительность считаем примерно так:
дней = выборка целиком / (DAU × доля пользователей в эксперименте)
4. Проводим тест
во время теста проверяем SRM, можно по калькулятору2 чекнуть критичность
если группы разъехались по размеру, сначала разбираемся с экспериментом, а не с результатом
5. Подводим итоги
считаем результат, но не отдаём решение на аутсорс калькулятору3.
статистика отвечает, похож ли эффект на случайность,
продакт решает стоит ли это раскатывать
#pm #abтесты #аналитика
👍6🔥4❤3🤝2
SRM: тревожная лампочка A/B-теста
Ух! 14 репостов это приятно, больше только под 50 на постах про книги:)
В шпоре по A/B-тестам упомянул SRM, штука заслуживает отдельного короткого пояснения.
SRM (sample ratio mismatch) - это проверка: попали ли пользователи в группы в той пропорции, в которой мы планировали
Можно решить, что это не проблема и проверить статзначимость разницы можно по формуле.
Но проблема не в разных размерах групп, а в причине, почему они разъехались, размер - это индикатор проблемы.
SRM, как health-check, может подсветить, что:
• рандомизация сломалась
• часть пользователей не логируется
• эксперимент раскатился не на всех, на кого должен был
...
По качеству SRM в одной корзине с AA-тестом.
AA-тест проверяет, не показывает ли наша экспериментальная система эффект там, где эффекта быть не должно.
SRM - не развалилось ли само распределение пользователей по группам.
Иначе можно посчитать результат на кривом эксперименте.
Я всю жизнь думал что ретропроверка групп просто health-check, а оказывается целый термин есть:)
А вы знали про SRM?
❤️ знали
😈 знали CRM
#srm #pm #abтесты #аналитика
Ух! 14 репостов это приятно, больше только под 50 на постах про книги:)
В шпоре по A/B-тестам упомянул SRM, штука заслуживает отдельного короткого пояснения.
SRM (sample ratio mismatch) - это проверка: попали ли пользователи в группы в той пропорции, в которой мы планировали
Можно решить, что это не проблема и проверить статзначимость разницы можно по формуле.
Но проблема не в разных размерах групп, а в причине, почему они разъехались, размер - это индикатор проблемы.
SRM, как health-check, может подсветить, что:
• рандомизация сломалась
• часть пользователей не логируется
• эксперимент раскатился не на всех, на кого должен был
...
По качеству SRM в одной корзине с AA-тестом.
AA-тест проверяет, не показывает ли наша экспериментальная система эффект там, где эффекта быть не должно.
SRM - не развалилось ли само распределение пользователей по группам.
Иначе можно посчитать результат на кривом эксперименте.
Я всю жизнь думал что ретропроверка групп просто health-check, а оказывается целый термин есть:)
А вы знали про SRM?
❤️ знали
#srm #pm #abтесты #аналитика
Please open Telegram to view this post
VIEW IN TELEGRAM
😈4❤3👍3😁3
Что живет рядом с A/B-тестами
A/B-тест - это строгий эксперимент: гипотеза, случайное деление пользователей, основная метрика, размер выборки и критерий решения.
Но рядом есть похожие методы, которые часто путают:
Сплит-тестирование
Это разлитие трафика между вариантами
Если есть рандомизация, выборка и статистика - это уже A/B.
Чистый сплит полезен разве что при роллауте.
Каждый A/B - это split, но не каждый split - это A/B.
Когортный анализ
Это не эксперимент, а наблюдение за группами во времени.
Например, заметить, что пользователи января удерживаются лучше, чем пользователи февраля, и пойти разбираться.
SBS (side-by-side)
Это прямое сравнение двух вариантов рядом.
Человек или эксперт видит два ответа, дизайна или сценария и выбирает лучший.
Holdout
Оставляем часть пользователей без изменений для долгого сравнения.
#pm #abтесты #аналитика
A/B-тест - это строгий эксперимент: гипотеза, случайное деление пользователей, основная метрика, размер выборки и критерий решения.
Но рядом есть похожие методы, которые часто путают:
Сплит-тестирование
Это разлитие трафика между вариантами
Если есть рандомизация, выборка и статистика - это уже A/B.
Чистый сплит полезен разве что при роллауте.
Каждый A/B - это split, но не каждый split - это A/B.
Когортный анализ
Это не эксперимент, а наблюдение за группами во времени.
Например, заметить, что пользователи января удерживаются лучше, чем пользователи февраля, и пойти разбираться.
SBS (side-by-side)
Это прямое сравнение двух вариантов рядом.
Человек или эксперт видит два ответа, дизайна или сценария и выбирает лучший.
Holdout
Оставляем часть пользователей без изменений для долгого сравнения.
#pm #abтесты #аналитика
🤝5👍3🔥3