Processes: как команда планирует работу

Следующий слой Target Operating Model это процессы, как стратегия превращается в конкретную работу команды.

Рабочая система обычно выстроена каскадом:
• собрана стратегия на год и дальше
• из неё формируются цели на год
• из них крупные инициативы в разрезе run, change, disrupt
• они формируют квартальные бакеты с задачами, сформулированными по SMART
И уже под них строится гант выполнения с разделением на discovery и delivery.

Чаще всего, даже в сильных командах, проблемы связаны с оценкой времени на discovery и с перегрузкой. В спринт начинают попадать задачи без приоритета и понятной ценности.

В такой системе полезно использовать дорожную карту продукта, как долгосрочный план и инструмент коммуникации. Она помогает команде и стейкхолдерам понимать, где и как инициативы расположены на временной оси, как они зависят друг от друга.

Главный признак хорошего процесса это предсказуемость. Команда понимает, что делает дальше. У процесса есть защита от постоянных срочных задач и система стабилизации фокуса.
Опасныо здесь уйти в бесконечный груминг и допускать постоянные влеты задач. В такие моменты важнее всего работа со стейкхолдерами и поддержание мотивации команды.

А у вас процесс сфокусирован или работаете в хаосе?
❤️ держим фокус
😈 живём в реактиве

@product_lev
#pm #productmanagement #process #operating #model

Performance: как измерять продуктовую команду

Одна из главных ошибок в управлении продуктом путать output и outcome. Команда может выпускать много фич, ускорять delivery и при этом не влиять на результат бизнеса.

Сильная продуктовая команда всегда связана со стратегией через метрики. Она понимает, какую продуктовую метрику должна двигать и как это отражается на выручке или росте ценности продукта.

Поэтому в центре измерения должны быть именно продуктовые показатели: retention, конверсия, использование ключевых сценариев. Но при этом нельзя терять связь с бизнесом и скоростью доставки изменений. Важно видеть и TTM, и влияние на экономику.

OKR в этой системе работает хорошо. Он помогает удерживать фокус на результате, а не на списке задач.

Моё мнение, что признак зрелости команды - это предсказуемость:
команда умеет планировать работу и стабильно двигает ключевую метрику + высокая скорость экспериментов при низком churn инициатив создаёт устойчивый рост.

Если метрики не связаны со стратегией, команда начинает оптимизировать локальные показатели и теряет направление.
А у вас команда измеряется фичами или результатом?

❤️ результатом
😈 количеством релизов

@product_lev
#pm #productmanagement #metrics #operating #model

People: как строить сильную продуктовую команду

В Target Operating Model заложен принцип роста команды вместе с продуктом.
Мне ближе роль PM, поэтому порассуждаю про него.

Команда мечты редко собирается только из «звёзд». Намного устойчивее работают команды, где сильные специалисты делают что-то новое для себя и продолжают расти. Такой рост не происходит случайно, его нужно строить системно.

Сильный продакт это самостоятельный специалист. Он понимает стратегию, умеет принимать решения, обладает насмотренностью и выстраивает коммуникации. При этом он знает процессы и их слабые стороны.

Одна из частых ошибок это отсутствие фокуса на развитии. Когда нет ПИРа и задачи планируются без учёта того, чему должен научиться человек, команда начинает топтаться на месте.

Рост продакта это прежде всего сравнение себя с собой из прошлого. Уже потом появляется сравнение с коллегами и внешним рынком.
Талант важен. Но сильные продуктовые команды появляются там, где талант выращивают через ответственность и развитие.

А у вас команда растёт или просто работает?
❤️ растёт ввысь
😈 растёт вшырь

@product_lev
#pm #productmanagement #people #operating #model

Culture: как поведение команды влияет на результат

В Target Operating Model культура это связующая среда, в которой работают все остальные элементы.

Культура не возникает сама по себе. Она формируется управленческими решениями лидеров, именно они задают, что в команде считается нормой.
Сильная продуктовая команда строится на прозрачности. Люди понимают цели, видят принятые решения и обмениваются опытом.
В такой среде можно аргументированно спорить и быть услышанным, это напрямую влияет на качество решений.

Культура часто ломается незаметно или в тишине: появляется blame culture(осуждаю), команда начинает избегать ответственности. Люди перестают поднимать проблемы, решения принимаются осторожно, скорость падает.
Ошибки в продуктовой работе неизбежны. Они допустимы, если из них сделаны выводы. Но масштаб ошибки всегда важен. Чем выше влияние решения, тем выше требования к подготовке.

Выстраивать культуру помогают управленческие ритуалы. Например, честные ретроспективы и открытые демо. Также сильное влияние оказывает найм специалистов, выросших в командах со зрелой культурой.

А у вас культура помогает принимать решения?
❤️ влияет сильно
😈 почти не влияет

@product_lev
#pm #productmanagement #culture #operating #model

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

Что почитать?
Проектное управление, Павел Алферов
Кому: тем, кто работает с проектами и хочет навести порядок в голове
Количество страниц: 400
Оценка: 10 управляемых проектов из 10

Часть 1. Отзыв
В книге крепкая системная база по проектному управлению: аккуратная сборка практик, терминов и подходов, с разбором национальных особенностей!

Лично для меня она сработала как инструмент наведения порядка, особенно в моментах, где раньше действовал интуитивно. Например, интересный фрейм про круг проектного мышления. Когда ты отказываешься от какого-то фокуса в проекте, ты не только режешь косты, а принимаешь риски: круто делать это осознанно, а не просто на автомате.

Из того, что забрал себе: систему характеризует не масштаб проблем, а то, как она на них реагирует. Хорошо разложена разница между проектом и продуктом проекта. Из инструментов, освежил применимость MoSCoW для первичного сбора требований. Плюс для себя роль спонсора проекта.

Итого, это книга, которая структурирует инструменты ведения проекта с учетом национальных особенностей. Можно читать рядом с Русской моделью управления Александра Прохорова, в ней больше про историю.

Часть 2. Как читали в клубе
Книга очень зашла в Книжном клубе, обсудили много заметок и кейсов из практики.
Обсуждали «белых слонов» или чемоданы без ручки: проекты, которые все тянут, но никто не готов остановить.
Три субботы подряд говорили про разницу в проектном управлении, роли продакта и продакт овнера:)

Книга классно раскрылась именно в обсуждении: сам читаешь и забираешь пару идей, а в группе начинаешь видеть больше за счёт чужого опыта.

Если вам тоже интересно не просто читать, а разбирать такие вещи на практике, присоединяйтесь к Книжному клубу для менеджеров.
Часто обсуждение даёт еще больше, чем просто чтение! По полезности: чтение->обсуждение(рефлексия1)->применение->рефлексия2


@product_lev
#чтопочитать #проекты #управление #productmanagement #книжныйклуб

Вайбкодинг для продакта: от FOMO к первому PoC

Последние месяцы у меня было классическое FOMO: из каждого утюга звучало про вайбкодинг, ИИ, который пишет продукты, и одиночек, собирающих то, что раньше делали команды. Долго смотрел на это со стороны, читал, кивал, сохранял в избранное посты.
Пока не случился простой триггер: мой руководитель сам собрал сервис.
В этот момент стало реально неловко просто читать-наблюдать.

Решил собрать руками PoC чат-бот мини-игры и понять, как это вообще работает.
Главный инсайт пришёл довольно быстро: вайбкодинг для продакта это не про код, а про понимание системы.
Когда ты сам проходишь путь от идеи до архитектуры, ограничений и рабочего сервиса, у тебя резко меняется уровень насмотренности.

Ты начинаешь лучше понимать, где рождаются реальные ограничения, чего на самом деле стоит «просто сделать фичу» и как продукт устроен под капотом. Это не делает тебя разработчиком, но делает чётче как продакта, ты начинаешь мыслить не только через идеи, но и через реализацию.

Мой вывод пока простой: вайбкодинг это не про хайп и не про замену команд, это быстрый способ прокачать системное мышление через практику, а заодно возможность ускорять получение прототипов для исследований.

А вот где заканчивается «вайб» и начинается реальность, и что на самом деле съедает больше всего времени разберу в следующем посте.

А вы уже пробовали собрать что-то сами?
❤️ да
😈 пока только читаюсохраняю в избранное

@product_lev
#pm #ai #productmanagement #vibecoding

Вайбкодинг для продакта: где заканчивается вайб и начинается реальность
продолжение поста

У меня не было ожиданий, что придётся писать код самому.
Я изначально предполагал, что код будет написан за меня, а моя задача только синхронизировать своё понимание системы с тем, что проектирует Codex: перепроверять и себя, и его.

Главное открытие: как глубока кроличья нора. Как только ты выходишь за рамки локальной проверки, начинается работа с системой.

Хочешь сделать что-то реально рабочее, с минимумом костылей, значит нужен сервер, домен для поднятия HTTPS, нормальный production-контур. И дальше ты начинаешь разбираться, как связаны между собой хостинг, вебхуки, nginx, docker и деплой.

В этот момент становится очевидно: без понимания системы ты начинаешь действовать вслепую. Можно не знать все термины, но нужно понимать, как всё устроено, иначе каждая проблема превращается в угадайку.

По факту большая часть времени уходит не на сборку фич, а на разбор того, почему что-то не работает. Отладка становится главным пожирателем времени.

Работа с агентом для меня сильно похожа на списывание сложного предмета у отличника. Можно просто переписывать и со всем соглашаться, но тогда легко пропустить ошибки и сдать неверное решение. А можно начать разбираться, но тогда есть риск не уложиться в срок. Баланс между скоростью и пониманием приходится искать постоянно.

Агент помогает собрать контур, но не заменяет понимание системы и не снимает ответственности за результат. Если его не корректировать, он может начать ходить по кругу или сложно решать простые задачи, от которых иногда разумнее отказаться.

И именно здесь заканчивается вайб.

В следующем посте разберу, как использовать вайбкодинг без FOMO и не тратить время впустую. Например, почему важно заранее понимать, что может оказаться платным и какие есть обходные решения.

А у вас где было самое большое трение?
❤️ инфраструктура
😈 отладка

@product_lev
#pm #ai #productmanagement #vibecoding

Вайбкодинг для продакта: от ступора к действию

Главное, что мешает начать, это не объективная сложность, а субъективный ступор.
Лично для меня было так: много контента, много мнений, ощущение, что сначала нужно всё понять, а потом уже пробовать.

Решил через очень простую логику действий, по примеру как было с поиском в гпт:
1. быстро что-то гуглю через GPT и задаю уточняющие вопросы, когда агент в контексте
2. если тема зацепила, иду в Perplexity и чуть глубже исследую на актуальных данных с онлайн поиском в интернете
3. если нужно понимание поведения, можно собрать персоны и прогнать через ИИ-интервью, например, в Gemini

Логика быстрого старта в вайбкодинге:
1. Возьмите простую задачу: что-то элементарное. Например, мини-игру - змейку или флуд-бота, который на любое сообщение в чате с «ура» отвечает «ура» в ответ.
2. Опишите идею в Codex и сразу задайте рамку: это учебный проект, вы хотите разобраться в программировании через ИИ, просите объяснять план действий.
3. Запустите локально и дотащите до прода(агент подскажет как!). Пусть это будет маленький, но реально работающий сервис.

Можно добавить в промпт, чтоб агент с вами сюсюкался - это полезно для обучения:

• объясняй каждое решение простыми словами, как для новичка
• перед реализацией коротко описывай план действий
• предлагай несколько вариантов, если есть выбор
• явно указывай, где могут быть ошибки или ограничения
• не делай лишнего, держись в рамках задачи
• если видишь упрощение, предложи его
• задавай уточняющие вопросы, если контекста недостаточно, не придумывай самостоятельно

Ключевой момент в том, что не нужно всё понимать с самого начала. Понимание придёт в процессе:)
Лайфхак: если что-то не понятно при общении с агентом, не засоряйте основной тред. Уточните в отдельном чате у GPT и вернитесь с понятным контекстом.
Если возникли проблемы и непонимание - велком в комментарии, я скорее отвечу, что тоже не знаю - попробуем найти ответ вместе:)
Итого: за ОДИН субботний вечер вы герой-вайбкодер, можете обновлять резюме, вы прекрасны!🤝

А вы уже пробовали что-то собрать руками?
❤️ да
😈 всё ещё думаю начать

@product_lev
#pm #ai #productmanagement #vibecoding

Продакт не должен быть секретарем Jira

В работе продакта есть тонкий баланс между дисциплиной в трекере и временем на реальную продуктовую проработку.

Без порядка быстро начинается хаос: задачи теряются, статусы устаревают, договоренности остаются только в головах.
Но и обратная крайность не лучше, когда продакт слишком глубоко проваливается в операционку - он постепенно превращается в координатора карточек. Внешне все выглядит аккуратно, но на главное уже не остается ресурса.

Для меня ориентир простой: трекер нужен, чтобы команда держала delivery под контролем. Но трекер не должен становиться центром роли продакта.

Роль продакта в другом: держать фокус на ценности, приоритетах и решениях. Понимать, что действительно двигает продукт вперед, а что просто создает ощущение управляемости.

Хороший признак здоровой системы такой: команда умеет жить внутри процесса без постоянного ручного проталкивания со стороны продакта. А у самого продакта остается время на пользователя, гипотезы и следующий сильный шаг для продукта.

Если весь день уходит на статусы, пинги и переписывание задач, это уже не продакт менеджмент, это секретариат трекера!
Продакт не должен быть секретарем Jira, продакт - секретарь эксельки и паверпоинта.

Как разгружаете себя от джиры?
❤️ помогает проджект и тимлид
😈 веду задачи в кайтене

@product_lev
#pm #трекер #джира #кайтен

Должен ли продакт понимать продажи?

Да, чтобы понимать, где именно интерес превращается в деньги. В противном случае будет переоценка фич и недооценка барьеров покупки.

Базово можно разложить продавание на 4 вопроса:
1. Потребность. Человеку это вообще надо?
2. Барьер. Что мешает купить?
3. Ценность. Оффер выглядит выгодно?
4. Триггер. Хочется именно сейчас?
Итого: убрать сомнения, сделать ценность очевидной, упростить выбор, подтолкнуть к действию в нужный момент.

Например в Booking, продукт помогает не только выбрать вариант, но и решиться на покупку: соцдоказательство, удобные условия отмены, подсветка выгоды, дефицит.

Так что понимание продаж нужно продакту, чтоб отвечать не только за интерфейс, но и за деньги.

А вы в своем продукте по всем вопросам прошлись?
❤️ еще и фреймворки из хэштегов использовали
😈 наш продукт не продается

@product_lev
#JTBD #ValuePropositionCanvas #FBM #pm

AI ускоряет бардак

Раньше можно было выигрывать за счет скорости.
Сейчас скорость стала доступна почти всем: Copilot ускоряет код, Cursor берет часть разработки, v0 и Replit быстро собирают прототипы.

Из-за этого дефицитом становится не скорость, а контекст.

Если у команды не собраны пользовательские инсайты, бизнес-ограничения, история решений и выводы из прошлых экспериментов, AI начинает масштабировать путаницу.

Поэтому новая задача продакта структурировать контекст так, чтобы команда и AI работали не быстрее сами по себе, а быстрее в правильную сторону.

Происходит сдвиг роли:
раньше сильный продакт управлял фокусом.
Теперь еще и шерингом контекста. Контекст становится новой валютой продуктовой команды.

Вы качественно храните контекст?
❤️ всё в Вики, HADI циклы крутятся
😈 ждем ии-агентов, которые сами соберут

@product_lev
#ai #pm

Шпора по 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тесты #аналитика

Что живет рядом с A/B-тестами

A/B-тест - это строгий эксперимент: гипотеза, случайное деление пользователей, основная метрика, размер выборки и критерий решения.

Но рядом есть похожие методы, которые часто путают:

Сплит-тестирование
Это разлитие трафика между вариантами
Если есть рандомизация, выборка и статистика - это уже A/B.
Чистый сплит полезен разве что при роллауте.
Каждый A/B - это split, но не каждый split - это A/B.

Когортный анализ
Это не эксперимент, а наблюдение за группами во времени.
Например, заметить, что пользователи января удерживаются лучше, чем пользователи февраля, и пойти разбираться.

SBS (side-by-side)
Это прямое сравнение двух вариантов рядом.
Человек или эксперт видит два ответа, дизайна или сценария и выбирает лучший.

Holdout
Оставляем часть пользователей без изменений для долгого сравнения.

#pm #abтесты #аналитика

Плохие выводы из хорошего A/B-теста

Финальная мысль - скелет лекции готов:)

Можно идеально разлить A/B-тест, проверить SRM, дождаться выборки, получить p-value и всё равно принять плохое продуктовое решение.

Что моет пойти не так:

Статзначимость без продуктового смысла

На большой базе можно поймать эффект в +0,1%.
Да, статистически значимо.
Нет, большого смысла выкатывать нет, если вы не Амазон.

Нужно оценить, окупает ли эксперимент разработку
не просаживает ли guardrail-метрики, не усложняет ли продукт, не конфликтует ли со стратегией

Можно выиграть тест, но проиграть продуктово.

Сегменты после итогов

Представьте, тест не прокрасился, но мы же не зря запускали!
Можно выковырять, что у новых пользователей на iOS из Воронежа в вечернее время выросла метрика!

Если нарезать кучу сегментов, где-нибудь почти всегда найдется победа.

Лучше зафиксировать ключевые сегменты до старта, а приятные находки после - считать не прокрасом, а новой гипотезой.

A/B-тест снижает неопределенность, помогает оценить сигнал.
Но не снимает с продакта ответственность за вывод и
не принимает за него решение, стоит ли по этому сигналу менять продукт.

#pm #abтесты #аналитика