Плохой Product Manager: портрет и симптомы

Что вообще значит «плохой» продакт

Вопрос «кто такой плохой Product Manager» звучит как попытка навесить ярлык, но на деле это рабочая диагностика. Плохой PM — не обязательно злой, ленивый или глупый. Чаще это менеджер, который системно не создаёт ценность: ни для пользователя, ни для бизнеса, ни для команды. Он может быть очень старательным, много работать, красиво говорить и делать презентации, а продукт при этом стоит на месте или едет туда, где нет устойчивого результата.

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

video:youtube

Ради чего вообще нужен продакт

Если упростить, Product Manager выбирает, какую проблему решать и для кого, объясняет, почему это важно (ценность плюс эффект на бизнес), проверяет гипотезы через дискавери, эксперименты, данные и интервью, организует доставку этой ценности через приоритизацию, требования и синхронизацию, и в конце измеряет результат, чтобы скорректировать курс. Это не «человек-идея» и не «человек-табличка», а человек выбора и ответственности: он принимает решения в неопределённости и не даёт команде месяцами делать то, что не работает. Отсюда определение от обратного. Плохой PM — тот, кто системно проваливается в одном или нескольких ключевых звеньях: выбор проблемы, валидация, приоритизация, коммуникация, измеримость.

12 архетипов плохого продакта

Самый опасный тип — тот, при котором всё кипит. Встречи идут, Jira заполнена, презентации красивые, roadmap расписан, релизы каждую неделю, а ценность и результат не растут. Это busy work: активность, которая не превращается в эффект. Плохой PM часто оптимизирует не продукт, а собственное чувство контроля. Ниже собраны самые частые маски; один человек нередко носит сразу несколько.

Секретарь — администратор задач вместо владельца продукта: основная работа сводится к созвонам, статусам, протоколам и вечному «кому что передать», любимое слово «апдейт», а решений и собственной позиции ноль; команда остаётся без направления, продукт едет по инерции, и решения принимают самые громкие стейкхолдеры. Лечится это через ownership — гипотезы, метрики, decision log, внятные рамки приоритизации. Рядом стоит фанат фич (feature factory), у которого успех измеряется числом выпущенных фич, вопрос «зачем?» раздражает, метрики вторичны («потом померяем»), а пост-релизного анализа нет; продукт превращается в свалку функций: растёт сложность, падает UX, команда выгорает, рост замедляется. Антидот — управление по outcome: цель → гипотеза → эксперимент → метрика → вывод.

Оракул верит интуиции против проверок: «я чувствую, что пользователям нужно…», исследования «не нужны», данные «врут», а обратную связь легко отмести: «эти пользователи просто не поняли»; отсюда высокая частота ошибок: иногда случайно выстреливает, но чаще команда платит за это кварталами потерь, и спасает только дисциплина доказательств, когда даже сильное видение имеет чекпоинты проверки. Согласователь угождает всем, никогда не говорит «нет», у него всё важно, а roadmap превращается в список желаний всех сторон, отсюда постоянная смена приоритетов, распыление ресурсов и отсутствие фокуса; антидот — прозрачная приоритизация (RICE/ICE/WSJF/Cost of Delay), стратегические запреты и умение отказывать через рамки. Политик выигрывает игры, а не рынок: главный KPI — чтобы начальник был доволен, цель не value, а «выглядеть хорошо», в ход идут манипуляции, скрытые повестки и презентации важнее реальности; решения начинают обслуживать организационную динамику, а не пользователя — это один из самых токсичных типов, и лечится он культурой прозрачности: общие метрики, открытые решения, постмортемы без поиска виноватых.

Питчер вечно продаёт идею, а не делает продукт: презентации, демо, большие анонсы, любовь к крупным ставкам и игнор деталей; до устойчивого эффекта доводит редко, продукт живёт обещаниями, а команда работает на видимость, а не на поведение пользователей, и антидот здесь — короткие циклы MVP → измерение → итерация с обязательным этапом «после релиза». Юрист требований влюблён в PRD и спецификации: 20-страничные документы на каждую мелочь, работа считается сделанной, когда написано ТЗ, а дискавери подменяется описанием решения: медленно, дорого, бесполезно, команда теряет гибкость, а продукт — связь с реальностью; лечится минимумом коротких артефактов: problem statement, гипотезы, success metrics, acceptance criteria. У типа без метрик всё упирается в «мы не можем это померить»: нет определения успеха, нет понимания базовой воронки и удержания, нет привычки к аналитике; решения не улучшаются, потому что нет обратной связи, а споры решаются мнением, и антидот — базовая система метрик acquisition → activation → engagement → retention → monetization плюс North Star и набор input-метрик.

Лидер без команды теряет людей: конфликты с дизайном и инженерами, пассивная агрессия, перекладывание, отсутствие доверия, и команда делает минимум, скорость и качество падают, лучшие уходят, продукт деградирует; антидот — управлять не людьми, а контекстом: ясность целей, приоритетов и критериев успеха, вовлечение команды в решения. Копипастер конкурентов живёт по принципу «у конкурента есть — нам надо», сводит дискавери к мониторингу чужих релизов и не понимает, почему у конкурента это работает, так что вы становитесь второй версией чужого продукта, без их контекста, бренда, каналов и стратегии; конкурентный анализ должен быть источником гипотез, а не roadmap, и всегда через вопрос, какую работу пользователя это закрывает у нас. Слепой к сегментам делает «для всех»: нет ICP, персон и сегментов, все пользователи в голове одинаковые, продукт распухает из-за противоречивых требований, теряя фокус и сильную ценность для ядра, а вместе с ними усложняются коммуникация и маркетинг, — лечится сегментацией: кто core, кто edge, кто «никогда», и чёткой ставкой на early adopters. Наконец, жертва процесса ставит процесс выше результата: Scrum ради Scrum, ритуалы есть, а эффекта нет, ретро превращается в жалобы, любое изменение трактуется как «нарушение процесса»; стоит помнить, что процесс — инструмент с одной целью: быстрее учиться и доставлять ценность.

Красные флаги: как распознать плохого PM по следам в продукте

Почти всегда с плохим продакт-менеджментом коррелирует одно и то же. Roadmap выглядит как список фич без целей и метрик; определения успеха перед стартом разработки нет; после релиза никто не возвращается посмотреть на результат; споры решаются авторитетом, а не данными и логикой; команда не может одной фразой объяснить, зачем делает эту работу; сам PM не знает, кто его основной пользователь и почему тот платит и возвращается. Добавьте сюда приоритеты, которые меняются чаще, чем успевают появиться данные, постоянные «срочные хотелки» от стейкхолдеров, растущий функционал на фоне падающих NPS, retention и конверсии, и команду, которая выгорает и чувствует бессмысленность. Один-два таких признака ещё не приговор, но когда они складываются, продукт уже теряет курс.

Почему PM становится плохим: причины не всегда в человеке

Часто «плохой PM» — это продукт плохой системы. Если компания оценивает output, а не outcome и хвалит за то, «сколько релизов сделал», человек и будет штамповать релизы. Если нет аналитики, событий, трекинга и культуры экспериментов, требовать метрики бессмысленно: их не на чем построить. Если роль не определена и PM одновременно менеджер проекта, бизнес-аналитик, скрам-мастер, маркетолог и саппорт, он неизбежно проваливает стратегию и дискавери. А в токсичной оргполитике, где решения принимаются «по близости к начальнику», PM будет играть в эту игру, иначе не выживет.

Цена ошибки

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

Как «плохому PM» стать хорошим

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

1. Переводите каждую задачу из бэклога от фичи к проблеме: она должна отвечать на три вопроса — чью проблему решаем, почему это важно сейчас и как поймём, что стало лучше.
2. Фиксируйте метрики успеха до разработки, минимум в трёх точках: baseline (что сейчас), target (что хотим) и окно измерения (через сколько смотрим).
3. Держите короткие циклы discovery: каждую неделю хотя бы 2–5 разговоров с пользователями, либо один анализ воронки или когорт, либо один эксперимент (A/B, fake door, тест прототипа).
4. Заведите decision log и фиксируйте, что решили, почему, на каких данных, какие риски и когда пересмотрите, — это резко снижает хаос и «перепридумывание».
5. Научитесь говорить «нет» профессионально, не как конфликт, а как управление ресурсом: «сейчас это не в топ-3 целей квартала», «это не влияет на North Star и ключевую воронку», «вернёмся после проверки гипотезы X».

Плохие формулировки против хороших

Плохой или просто неопытный?

Разница чаще всего в обучаемости и честности. Неопытный PM признаёт пробелы, задаёт вопросы, улучшает процесс и быстро учится на ошибках. Плохой — в устойчивом смысле — защищает эго, а не продукт: оправдывается вместо проверки, обвиняет команду, рынок или данные и повторяет те же ошибки. Ключевой тест простой: становится ли качество решений лучше от итерации к итерации?

Если свести всё к одному предложению

Плохой Product Manager — это тот, кто системно превращает неопределённость в шум, а не в ясность. Он наращивает хаос вместо фокуса, выпускает output вместо outcome и строит иллюзию прогресса вместо реального обучения.