Фраза «плохой Product Manager» почти всегда звучит как личный приговор. Ее адресуют конкретному человеку, подразумевая нехватку интеллекта, опыта или старания. В профессиональных обсуждениях плохой PM часто предстает в виде карикатуры - некомпетентного, ленивого или токсичного специалиста, который мешает команде и губит продукт. Такой образ удобен, но он плохо объясняет реальность.
На практике большинство Product Manager, которых называют плохими, не являются ни глупыми, ни безразличными. Они много работают, переживают за результат и искренне хотят сделать хороший продукт. Проблема в том, что «плохой PM» чаще всего является не характеристикой личности, а следствием роли, в которую человек поставлен, и системы, в которой он работает. Именно эта разница принципиальна для понимания происходящего.
Эта статья посвящена идее, что плохой Product Manager - это роль, а не человек. Мы разберем, где возникает путаница, почему ошибка в продукте не равна плохому PM, и как системные искажения превращают даже сильных специалистов в носителей слабых продуктовых решений.
Неверная логика, по которой судят продакт-менеджеров
Самая распространенная ошибка мышления заключается в персонализации проблемы. Когда продукт буксует, сроки срываются, а метрики не растут, организация инстинктивно ищет виноватого. Product Manager становится удобной мишенью, потому что формально именно он отвечает за продукт. Так роль подменяется личной оценкой.
Эта логика опасна тем, что она упрощает реальность. Вместо анализа системы, процессов и ограничений внимание концентрируется на человеке. Его начинают оценивать через призму результата, не задавая вопросов о контексте, полномочиях и реальных возможностях влиять на ситуацию. В итоге проблема не решается, а лишь меняет носителя.
Еще одна ошибка - вера в то, что существует некий универсальный «хороший PM», который будет эффективен в любой среде. В реальности Product Manager всегда является функцией контекста. Один и тот же специалист может быть сильным в одной компании и выглядеть слабым в другой, не потому что он изменился, а потому что изменилась роль.
Где в компании теряется управление, если PM не тянет
Роль Product Manager находится на пересечении бизнеса, технологий и пользователей. Это означает, что она крайне чувствительна к разрывам в управленческом контуре. Если хотя бы одна из сторон не включена или искажена, PM начинает выполнять подменные функции и теряет способность принимать качественные продуктовые решения.
Один из частых разломов - отсутствие реальных полномочий. Product Manager формально отвечает за продукт, но не может влиять на стратегию, приоритеты или ресурсы. В такой ситуации он превращается в координатора задач или переводчика требований, а не в владельца продукта. Снаружи это выглядит как плохая работа PM, хотя на самом деле это следствие роли без власти.
Другой системный сбой возникает, когда организация ожидает от PM невозможного. Например, совмещения стратегического мышления, операционного управления, аналитики, UX и продаж без поддержки и времени. Перегруженная роль неизбежно деградирует, и ошибки начинают восприниматься как личная некомпетентность.
Почему ошибки — часть здорового процесса
Ошибка в продукте - это не аномалия, а норма. Product Manager работает в условиях неопределенности, где невозможно заранее знать, какое решение сработает. Гипотезы проверяются рынком, а не интеллектом команды. Поэтому ошибки в выборе приоритетов, сегментов или фич допустимы и даже необходимы.
Допустимой является ошибка, сделанная осознанно. Это означает, что гипотеза была сформулирована, основания для решения были понятны, а критерии успеха определены заранее. Если результат оказался отрицательным, такая ошибка становится источником знаний и улучшает качество следующих решений.
Важно также различать ошибку и эксперимент. Если PM целенаправленно проверяет предположение и получает отрицательный результат, это не провал, а завершенный цикл обучения. В здоровой системе такие ошибки не наказываются, а анализируются и используются для корректировки курса.
Грань между ошибкой и профнепригодностью
Ошибка превращается в некомпетентность тогда, когда она повторяется без изменения подхода. Если Product Manager снова и снова принимает решения без гипотез, данных и анализа последствий, речь идет не о случайных промахах, а о системной проблеме роли или мышления.
Еще один признак некомпетентности - отказ признавать ошибку. Когда PM защищает решение, игнорируя сигналы рынка и команды, он перестает выполнять продуктовую функцию. В этот момент роль смещается от поиска лучшего решения к защите собственного эго или формального статуса.
Важно подчеркнуть, что такое поведение часто поддерживается средой. Если организация наказывает за ошибки, но поощряет уверенность и «продажу решений», Product Manager будет вынужден вести себя именно так, чтобы выжить в роли.
Как это выглядит на деле
Симптомы в discovery
В discovery плохой Product Manager как роль проявляется через отсутствие реального исследования. Интервью с пользователями проводятся формально, вопросы задаются так, чтобы подтвердить уже принятое решение. Результаты исследований не влияют на приоритеты, а используются как обоснование.
Другой симптом - подмена проблемы решением. Вместо изучения контекста и боли пользователей команда сразу обсуждает фичи. Это часто происходит не по вине конкретного PM, а из-за давления сроков и ожиданий сверху.
В итоге discovery превращается в ритуал, а не в инструмент принятия решений. Формально процесс есть, но его ценность близка к нулю.
Симптомы в delivery
В delivery роль плохого PM проявляется через постоянные срывы ожиданий. Roadmap существует, но не отражает реальности. Приоритеты меняются хаотично, решения принимаются реактивно, без связи с целями продукта.
Часто PM оказывается зажат между стейкхолдерами и командой, не имея возможности сказать «нет». Внешне это выглядит как слабость, но по сути это следствие роли без поддержки и ясных рамок.
Delivery становится процессом тушения пожаров, а не осознанного движения к результату.
Симптомы в коммуникации
В коммуникации плохой PM как роль проявляется через неясность. Команда не понимает, зачем делается та или иная задача. Стейкхолдеры не понимают, чего ожидать и когда. Сам PM тратит большую часть времени на объяснения и оправдания.
Коммуникация становится реактивной и защитной. Вместо обсуждения проблем и вариантов решений ведется борьба за интерпретацию происходящего. Это усиливает недоверие и снижает эффективность всей системы.
[ПРОДОЛЖЕНИЕ В СЛЕДУЮЩЕМ СООБЩЕНИИ]
Что в инструментах говорит о зрелости, а что — о её отсутствии
Зрелость Product Manager как роли хорошо видна по артефактам, которые он использует. Речь идет не о наличии шаблонов или документов, а о том, какую функцию они выполняют. Зрелые артефакты помогают принимать решения, незрелые - создают иллюзию контроля.
Например, roadmap может быть инструментом согласования ожиданий, а может быть списком обещаний, оторванных от реальности. В первом случае он регулярно пересматривается и связан с целями. Во втором случае он используется как щит от вопросов и источник будущих конфликтов.
То же касается PRD, гипотез, метрик и отчетов. Если артефакты не используются для изменения поведения и решений, они сигнализируют о незрелости роли, а не человека.
10 решений, делающих PM неэффективным
1. Отсутствие явных гипотез.
Решения принимаются интуитивно и задним числом оправдываются логикой.
2. Игнорирование пользовательской боли.
Фокус смещается на внутренние запросы и политические компромиссы.
3. Подмена целей фичами.
Количество задач становится важнее результата для бизнеса.
4. Защита решений вместо их проверки.
Критика воспринимается как личная атака.
5. Отсутствие приоритизации.
Все задачи считаются одинаково важными.
6. Реактивное управление.
Работа строится вокруг срочных запросов, а не стратегии.
7. Непрозрачная коммуникация.
Команда не понимает контекст и причины решений.
8. Отказ от ответственности.
Неудачи объясняются внешними факторами.
9. Отсутствие рефлексии.
Ошибки не анализируются и повторяются.
10. Вера в процессы вместо мышления.
Процедуры заменяют осознанные решения.
Слова, которые сигналят: PM не понимает продукт
«Мы уже решили, давайте просто сделаем».
«Пользователи сами не знают, чего хотят».
«Это не моя зона ответственности».
«Сейчас не время что-то менять».
«Давайте добавим еще одну фичу, вдруг поможет».
Эти фразы отражают не характер человека, а искаженную роль, в которой нет места сомнению, обучению и ответственности.
Кейс-пример: было / стало / сработало
Команда работала над B2B-продуктом для автоматизации отчетности. Product Manager формально отвечал за продукт, но стратегические решения принимались коммерческим директором. PM выполнял роль координатора задач.
В какой-то момент продукт начал терять клиентов. Руководство обвинило PM в плохом понимании рынка и слабом управлении приоритетами. Сам PM чувствовал перегрузку и потерю контроля.
После серии разговоров выяснилось, что PM не имел возможности влиять на стратегию и отказывать в запросах продаж. Его роль изначально была сконструирована как подчиненная.
После перераспределения полномочий и явного разделения ответственности подход к продукту изменился. Те же самые навыки PM начали давать другой результат.
Продукт стабилизировался, а «плохой PM» внезапно оказался вполне компетентным специалистом.
Было — сделали — получили
В стартапе на ранней стадии Product Manager совмещал роли аналитика, проджект-менеджера и саппорта. Его считали слабым из-за постоянных срывов сроков и хаотичных решений.
На деле проблема была в отсутствии фокуса и перегруженной роли. От PM ожидали стратегического мышления, но не давали времени и ресурсов для исследования.
После явного пересмотра роли и сокращения операционной нагрузки качество решений выросло. Ошибки остались, но стали осознанными и управляемыми.
Команда перестала воспринимать PM как источник проблем и начала видеть в нем партнера.
Самодиагностический список
- Понимаю ли я, за что реально отвечаю.
- Есть ли у меня полномочия для этой ответственности.
- Формулирую ли я гипотезы явно.
- Проверяю ли я их на пользователях.
- Есть ли у решений критерии успеха.
- Анализирую ли я провалы.
- Меняю ли я подход после ошибок.
- Понимает ли команда контекст решений.
- Могу ли я сказать «нет».
- Связаны ли задачи с целями.
- Есть ли фокус.
- Не подменяю ли я мышление процессами.
- Получаю ли я честную обратную связь.
- Учитываю ли я ограничения среды.
- Не защищаю ли я эго.
- Учусь ли я системно.
- Есть ли время на discovery.
- Понимают ли стейкхолдеры мою роль.
- Ясна ли стратегия продукта.
- Осознаю ли я свои слепые зоны.
FAQ
Плохой PM - это всегда слабый специалист?
Нет, чаще это результат искаженной роли и контекста.
Можно ли быть хорошим PM в плохой системе?
Можно, но это требует больших усилий и редко бывает устойчивым.
Всегда ли ошибки означают плохую работу?
Нет, ошибки неизбежны в продуктовой работе.
Что важнее - опыт или среда?
Среда определяет, как проявится опыт.
Можно ли исправить роль без смены человека?
Да, в большинстве случаев именно это и нужно делать.
Почему компании любят персонализировать проблему?
Потому что это проще, чем менять систему.
Как понять, что проблема в роли, а не в человеке?
Если похожие проблемы повторяются с разными людьми.
Нужно ли говорить PM, что он «плохой»?
Нет, нужно говорить о проблемах роли и ожиданий.
Плохой Product Manager - это не ярлык для человека, а симптом сломанной или искаженной роли. Когда ответственность не совпадает с полномочиями, ожидания противоречат реальности, а ошибки наказываются вместо анализа, даже сильные специалисты начинают выглядеть слабо. Менять нужно не людей, а контуры управления, в которых они работают. Именно в этом и заключается зрелый продуктовый подход.