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

На практике в наших проектах «чистый» ПМ, уж простите, скорее всего, пропустит важные риски и с некоторой вероятностью сделает суперпродукт, но, скорее, облажается по срокам, юнит-экономике или команде. «Чистый» менеджер сделает всё в бюджете, в срок, экономика будет сходиться, но продукт не будет нужен рынку.

Статью стоило назвать - "Как превратить разработчиков в рабов в кандалах тайм трекера", "Практикуем галерный подход к организации работы разработчиков","Как заставить разработчика писать код под бой барабанов менеджера" и т.д.

Просто удивительно, как много этой пакости.

Давайте сразу разделим понятия пользователи и комьюнити. У каждого продукта есть пользователи, но не у каждого — комьюнити. Это не одно и то же. Пользователи из разных сообществ помогают генерировать ценные, полезные советы по продукту. Например, сегодня комьюнити фронтендеров приходит и говорит, что фронтенд неудобно катить через наш CI/CD. Это резонная обратная связь, которая помогает менять продукт в лучшую сторону.

А завтра люди из этого комьюнити придут к лиду разработки фронтенда и предложат обновить версию JS или переехать на другой фреймворк. Вроде бы и там и там обратная связь, только с разными отделами. Но это уже будет фидбек от пользователей, а не от комьюнити в целом.