Просто процессы позволяют планировать тройственное ограничение: деньги, время, ресурсы. Когда это всё ваше собственное, поверьте ни от какого планирования вы отказываться не будете. Это как в поход собираться в горы. Поверьте, когда в горы собираешься, точно решишь посчитать количество еды, вес, и собственные силы, это не прихоть, это вопрос вашего выживания.
Я был и PM, и PO. И ключевая ошибка в подобных текстах — путать «у нас получилось» с «так можно управлять».
Процессы нужны не для контроля людей и не ради отчётов наверх.
Процессы — это про управляемость и снижение неопределённости, чтобы с высокой вероятностью получить ровно тот результат, который задумывали, в нужный срок и с понятными рисками.
По тексту создаётся ощущение, что автор никогда не нёс ответственности за бюджет, занятые деньги или стоимость срыва сроков — либо воспринимал их как абстрактные фантики, хотя по тому как вы себя позиционируете это явно не так. В реальности за потраченные ресурсы нужно отвечать: перед бизнесом, инвесторами, иногда — буквально своей позицией.
Да, в маленькой, изолированной, супер-мотивированной команде без внешних зависимостей можно работать без Scrum, оценок и спринтов. Я сам так работал — и это действительно эффективно. Но это частный кейс, а не воспроизводимая модель для продукта, платформы или бизнеса.
Как только появляются:
— несколько команд
— зависимости
— бюджет и стоимость простоя
— ожидания бизнеса до, а не после результата
любая антипроцессная романтика быстро заканчивается.
Проблема не в Scrum, сторипойнтах или дейли.
Проблема в том, что процессы часто внедряют без понимания зачем, превращая их в имитацию контроля.
Но отсутствие процессов — это не свобода.
Это ставка на удачу и мотивацию, а не на управляемую систему.
Как продакт, который сам много работает с UI, текст в целом откликнулся. Очень точно показан разрыв между «красиво в Figma» и тем, как интерфейс реально живёт в цеху — с железом, шумом и людьми, которые работают на рефлексах, а не по гайдлайнам.
При этом посыл сильный и правильный. Круто, что дизайн показан как часть продукта и инженерная работа, а не как «наведение красоты». Если после изменений оператору реально стало проще и спокойнее работать — значит UI сделан правильно, независимо от трендов и наград.
Читаю как продакт и не могу отделаться от ощущения, что это очень аккуратно упакованный гайд про процесс, а не про стратегию.
Текст подробно объясняет, как писать, согласовывать и защищать стратегию, но почти не отвечает на самый сложный вопрос — какие реальные решения приходится принимать и чем за них потом расплачиваться.
В жизни стратегия — это не CJM и не six-pager. Это моменты, когда ты говоришь «нет» деньгам, рынку, командам или популярным идеям. Это конфликты приоритетов, ошибки и решения, которые нельзя просто откатить. Именно этого в статье не хватает больше всего.
Фреймворки описаны корректно, спору нет. Но фреймворки сами по себе ничего не решают — они просто фиксируют уже принятые решения. Без живых кейсов Avito, цифр, провалов и неприятных компромиссов всё выглядит как универсальный корпоративный шаблон.
Думаю, для продактов, которые только начинают работать со стратегией в большой компании, статья будет полезной. Но для тех, кто реально отвечает за рост, P&L и портфель продуктов, нового здесь немного.
Было бы гораздо интереснее прочитать честный разбор одного конкретного стратегического решения в Avito: что выбрали, от чего отказались, кто был недоволен и какую цену за это заплатили. Вот в этом месте и начинается настоящая продуктовая стратегия, ваша компания постоянно отжимает у нас кучу денег за продажу товаров на вашей площадке, очень было бы интересно узнать про что-нибудь реальное, а не пустую писанину.
Процессы в продуктовой команде очень хорошо работают, просто есть одно ограничение - ваш PO должен понимать куда движется ваш продукт/ы и иметь виденье куда вых хотите придти. Если этого нет, никакие процессы в этом не помогут.
А… вы иронизируете. Ясно ясно
Не спорю с вами, даже в некотором роде согласен.
Просто процессы позволяют планировать тройственное ограничение: деньги, время, ресурсы. Когда это всё ваше собственное, поверьте ни от какого планирования вы отказываться не будете. Это как в поход собираться в горы. Поверьте, когда в горы собираешься, точно решишь посчитать количество еды, вес, и собственные силы, это не прихоть, это вопрос вашего выживания.
Я был и PM, и PO. И ключевая ошибка в подобных текстах — путать «у нас получилось» с «так можно управлять».
Процессы нужны не для контроля людей и не ради отчётов наверх.
Процессы — это про управляемость и снижение неопределённости, чтобы с высокой вероятностью получить ровно тот результат, который задумывали, в нужный срок и с понятными рисками.
По тексту создаётся ощущение, что автор никогда не нёс ответственности за бюджет, занятые деньги или стоимость срыва сроков — либо воспринимал их как абстрактные фантики, хотя по тому как вы себя позиционируете это явно не так. В реальности за потраченные ресурсы нужно отвечать: перед бизнесом, инвесторами, иногда — буквально своей позицией.
Да, в маленькой, изолированной, супер-мотивированной команде без внешних зависимостей можно работать без Scrum, оценок и спринтов. Я сам так работал — и это действительно эффективно. Но это частный кейс, а не воспроизводимая модель для продукта, платформы или бизнеса.
Как только появляются:
— несколько команд
— зависимости
— бюджет и стоимость простоя
— ожидания бизнеса до, а не после результата
любая антипроцессная романтика быстро заканчивается.
Проблема не в Scrum, сторипойнтах или дейли.
Проблема в том, что процессы часто внедряют без понимания зачем, превращая их в имитацию контроля.
Но отсутствие процессов — это не свобода.
Это ставка на удачу и мотивацию, а не на управляемую систему.
Как продакт, который сам много работает с UI, текст в целом откликнулся. Очень точно показан разрыв между «красиво в Figma» и тем, как интерфейс реально живёт в цеху — с железом, шумом и людьми, которые работают на рефлексах, а не по гайдлайнам.
При этом посыл сильный и правильный. Круто, что дизайн показан как часть продукта и инженерная работа, а не как «наведение красоты». Если после изменений оператору реально стало проще и спокойнее работать — значит UI сделан правильно, независимо от трендов и наград.
Будет ещё больше неподдерживаемого ковнокода.
Читаю как продакт и не могу отделаться от ощущения, что это очень аккуратно упакованный гайд про процесс, а не про стратегию.
Текст подробно объясняет, как писать, согласовывать и защищать стратегию, но почти не отвечает на самый сложный вопрос — какие реальные решения приходится принимать и чем за них потом расплачиваться.
В жизни стратегия — это не CJM и не six-pager. Это моменты, когда ты говоришь «нет» деньгам, рынку, командам или популярным идеям. Это конфликты приоритетов, ошибки и решения, которые нельзя просто откатить. Именно этого в статье не хватает больше всего.
Фреймворки описаны корректно, спору нет. Но фреймворки сами по себе ничего не решают — они просто фиксируют уже принятые решения. Без живых кейсов Avito, цифр, провалов и неприятных компромиссов всё выглядит как универсальный корпоративный шаблон.
Думаю, для продактов, которые только начинают работать со стратегией в большой компании, статья будет полезной. Но для тех, кто реально отвечает за рост, P&L и портфель продуктов, нового здесь немного.
Было бы гораздо интереснее прочитать честный разбор одного конкретного стратегического решения в Avito: что выбрали, от чего отказались, кто был недоволен и какую цену за это заплатили. Вот в этом месте и начинается настоящая продуктовая стратегия, ваша компания постоянно отжимает у нас кучу денег за продажу товаров на вашей площадке, очень было бы интересно узнать про что-нибудь реальное, а не пустую писанину.
Тут и да и нет. В зависимости от типа управления, я могу выделить примерно 6 типов:
Команда → процессная / функциональная
Инициатива → проектная
Продукт → продуктовая
Организация → матричная
Бизнес в целом → портфельная (если >1 проекта)
В зависимости от типа управления, и структуры CLVL: видение, стратегия, а также риски будут по-разному разделены между управляющим составом.
Но в любом случае PO/ CPO будет нести основную ответственность.
Процессы в продуктовой команде очень хорошо работают, просто есть одно ограничение - ваш PO должен понимать куда движется ваш продукт/ы и иметь виденье куда вых хотите придти. Если этого нет, никакие процессы в этом не помогут.