Плохой продакт обычно занят с утра до вечера: созвоны, Jira, презентации, релиз каждую неделю. А продукт стоит, потому что ни одно из этих действий не меняет поведение пользователя.
Ярлык "плохой продакт" при этом вешают легко и часто не по делу: за ним стоит то неудобный человек, то чужая зона ответственности. Полезнее другой вопрос. Какие решения и привычки регулярно уводят продукт не туда, кто бы ни был их автором?
Продакт отвечает за выбор
Плохой PM не обязательно злой, ленивый или глупый. Чаще он системно не создаёт ценность: ни для пользователя, ни для бизнеса, ни для команды. Он старается, много работает, красиво говорит. Продукт при этом стоит на месте или едет туда, где нет устойчивого результата.
Чтобы увидеть провал, сначала нужно понять, за что продакт вообще отвечает. Он выбирает, какую проблему решать и для кого. Объясняет, почему это важно пользователю и бизнесу. Проверяет догадки: разговаривает с пользователями, ставит эксперименты, смотрит данные. Организует работу: расставляет приоритеты, пишет требования, сводит людей вместе. И в конце измеряет результат, чтобы поправить курс.
Его роль не сводится ни к "человеку-идее", ни к "человеку-табличке". Он тот, кто выбирает: принимает решения, когда многое неизвестно, и не даёт команде месяцами делать то, что не работает. Отсюда определение от обратного. Плохой продакт раз за разом проваливает одно или несколько звеньев: выбор проблемы, проверку догадок, приоритеты, общение, измерение результата.
Маски, за которыми прячется пустая занятость
Опаснее всего случай, когда всё кипит. Встречи идут, Jira заполнена, план развития расписан, релизы выходят каждую неделю, а ценность не растёт. Это пустая занятость (в англоязычных командах говорят busy work): активность, которая не превращается в эффект. Плохой PM оптимизирует собственное чувство контроля, продукт остаётся на втором плане. Ниже самые частые маски; один человек нередко носит сразу несколько.
Секретарь ведёт задачи вместо того, чтобы отвечать за продукт. Его день состоит из созвонов, статусов и протоколов, любимое слово "апдейт", а своей позиции нет. Решения в итоге принимают те заказчики внутри компании, кто громче. Помогает одно: взять продукт в свои руки. Свои гипотезы, метрики, журнал решений и понятные правила выбора приоритетов.
Фанат фич (feature factory) меряет успех числом выпущенных функций. Вопрос "зачем?" его раздражает, метрики "потом померяем", пост-релизного анализа нет. Продукт превращается в свалку функций: растёт сложность, падает UX, команда выгорает. Антидот один: управлять по результату, по цепочке цель → гипотеза → эксперимент → метрика → вывод.
Оракул верит интуиции больше, чем проверкам. "Я чувствую, что пользователям нужно…", исследования "не нужны", данные "врут", а неудобный отзыв легко отмести: "эти пользователи просто не поняли". Иногда случайно выстреливает. Чаще команда платит за это кварталами потерь. Спасает дисциплина доказательств: даже у сильного видения есть чекпоинты проверки.
Согласователь никогда не говорит "нет". У него всё важно, и план развития превращается в список желаний всех сторон. Приоритеты меняются постоянно, ресурсы распыляются, фокуса нет. Помогают прозрачная приоритизация (RICE/ICE/WSJF/Cost of Delay), стратегические запреты и умение отказывать через рамки.
Политик выигрывает внутренние игры вместо рынка. Его главный KPI в том, чтобы начальник был доволен; в ход идут скрытые повестки, а презентация важнее реальности. Решения начинают обслуживать организационную динамику, пользователь выпадает из расчёта. Это один из самых токсичных типов. Лечится он культурой прозрачности: общие метрики, открытые решения, постмортемы без поиска виноватых.
Питчер вечно продаёт идею вместо того, чтобы делать продукт. Демо, большие анонсы, любовь к крупным ставкам и равнодушие к деталям. До устойчивого эффекта он доводит редко, и команда работает на видимость. Антидот: короткие циклы MVP → измерение → итерация с обязательным этапом "после релиза".
Юрист требований влюблён в документы с требованиями (PRD). На каждую мелочь пишется документ на 20 страниц, работа считается сделанной, когда готово техническое задание, а поиск проблемы подменяется описанием решения. Медленно, дорого и мимо реальности. Помогают короткие записи: формулировка проблемы, гипотезы, признаки успеха, условия приёмки.
У типа без метрик всё упирается в "мы не можем это померить". Нет понимания, что считать успехом, как устроена воронка и удержание, нет привычки смотреть данные. Споры решает мнение, и решения не становятся лучше: нет обратной связи. Начинать приходится с основы: путь пользователя от привлечения через первое действие, вовлечённость и удержание до оплаты, плюс главная метрика (North Star) и показатели, которые на неё влияют.
Лидер без команды теряет людей. Конфликты с дизайном и инженерами, пассивная агрессия, перекладывание ответственности. Команда делает минимум, скорость и качество падают, лучшие уходят, продукт деградирует. Антидот в том, чтобы управлять контекстом: ясные цели, приоритеты и критерии успеха, команда участвует в решениях.
Копипастер конкурентов живёт по принципу "у конкурента есть, значит и нам надо". Дискавери у него сводится к мониторингу чужих релизов, и он не понимает, почему у конкурента это работает. Итог предсказуем: вторая версия чужого продукта без его контекста, бренда, каналов и стратегии. Конкурентный анализ должен давать гипотезы, и каждую стоит проверить вопросом, какую работу пользователя она закрывает у вас.
Слепой к сегментам делает "для всех". Нет портрета идеального клиента, персон и сегментов, все пользователи в голове одинаковые. Продукт распухает от противоречивых требований и теряет сильную ценность для ядра, а вместе с ней усложняются коммуникация и маркетинг. Лечится сегментацией: кто ядро, кто периферия, кто "никогда", и чёткой ставкой на ранних последователей.
Наконец, жертва процесса ставит процесс выше результата. Scrum ради Scrum, ритуалы есть, эффекта нет, ретро превращается в жалобы, любое изменение объявляется "нарушением процесса". Протокол встречи есть, решения нет. У процесса одна цель: быстрее учиться и доставлять ценность.
Красные флаги видны в продукте раньше, чем в человеке
Следы плохого продакт-менеджмента почти всегда одни и те же. Roadmap выглядит как список фич без целей и метрик. Определения успеха перед стартом разработки нет. После релиза никто не возвращается посмотреть на результат. Споры решаются авторитетом.
Команда не может одной фразой объяснить, зачем делает эту работу. Сам PM не знает, кто его основной пользователь и почему тот платит и возвращается. Добавьте приоритеты, которые меняются быстрее, чем появляются данные, постоянные "срочные хотелки" от заказчиков внутри компании и всё новые функции при падающих NPS, удержании и конверсии. Команда при этом выгорает и не видит смысла в работе.
Один-два таких признака ещё не приговор. Когда они складываются, продукт уже теряет курс.
Жанр "хороший продакт против плохого" старше таких списков. Бен Хоровиц и Дэвид Вайден написали меморандум "Good Product Manager / Bad Product Manager" в Netscape в середине 1990-х. Почти каждый его пункт сформулирован через поведение, черты характера там почти не упоминаются: хороший продакт сам определяет цель и отвечает за результат, плохой ждёт, что ему скажут, и объясняет неудачу обстоятельствами. Архетипы выше стоит читать так же: как поведенческие следы, которые можно изменить.
Цена этих следов копится медленно. Плохой PM редко ломает всё сразу. Деньги уходят на неработающие гипотезы, кварталы уходят на функции без эффекта, растут техдолг и продуктовая сложность, команда перестаёт верить, что делает что-то важное. А пока всё это копится, закрывается рыночное окно. Самая дорогая потеря здесь в скорости обучения: рынок не прощает команды, которые медленно понимают реальность.
Плохого продакта часто производит система
Нередко "плохой PM" оказывается продуктом плохой системы. Если компания оценивает объём выпущенного вместо результата и хвалит за число релизов, человек будет штамповать релизы. Если нет аналитики, событий, трекинга и культуры экспериментов, требовать метрики бессмысленно: их не на чем построить.
Если роль не определена и продакт одновременно руководитель проекта, бизнес-аналитик, скрам-мастер, маркетолог и поддержка, он неизбежно провалит стратегию и работу с пользователями. А там, где решения принимают "по близости к начальнику", продакт будет играть в эту игру. Иначе не выживет.
Поэтому до разговора о замене человека стоит проверить среду по трём пунктам. За что его хвалили в последнем квартале: за число релизов или за сдвиг метрики. Есть ли у команды события и дашборд, на которых этот сдвиг вообще виден. Сколько чужих ролей он тянет параллельно. Если все три ответа неудобные, новый PM через полгода окажется на том же месте.
Привычки, которые возвращают продакта к результату
Если вы узнаёте в описании себя или коллегу, двигаться стоит примерно в таком порядке:
- Переформулируйте каждую задачу из бэклога от фичи к проблеме, чтобы она отвечала на три вопроса: чью проблему решаем, почему это важно сейчас и как поймём, что стало лучше.
- Фиксируйте метрики успеха до разработки, минимум в трёх точках: исходный уровень (что сейчас), цель (что хотим) и окно измерения (через сколько смотрим).
- Держите короткие циклы исследования (discovery): каждую неделю хотя бы 2-5 разговоров с пользователями, либо один анализ воронки или когорт, либо один эксперимент (A/B, fake door, тест прототипа).
- Заведите журнал решений (decision log) и фиксируйте, что решили, почему, на каких данных, какие риски и когда пересмотрите. Так становится куда меньше хаоса и "перепридумывания".
- Научитесь говорить "нет" профессионально, как часть управления ресурсом, без перехода в конфликт: "сейчас это не в топ-3 целей квартала", "это не влияет на North Star и ключевую воронку", "вернёмся после проверки гипотезы X".
В хорошей формулировке есть сегмент, число и срок
| Плохая формулировка | Почему плохо | Хорошая формулировка |
|---|---|---|
| "Нужно добавить кнопку" | решение без проблемы | "Падает конверсия на шаге оплаты: -12%. Гипотеза: пользователи не замечают кнопку." |
| "Сделаем как у конкурента" | нет контекста | "Конкурент упрощает первые шаги новичка через X. Проверим, мешает ли нам то же самое: долгий путь до первой пользы." |
| "Пользователи просят" | кто? сколько? какие? | "Сегмент A (30% MAU) теряет 15 минут на задачу B. 8 интервью подтвердили боль." |
| "Срочно нужно" | срочность без критерия | "Риск потери контракта на $X. Нужна минимальная версия до даты Y." |
Плохой или просто неопытный?
Разница чаще всего в обучаемости и честности. Неопытный PM признаёт пробелы, задаёт вопросы, улучшает процесс и быстро учится на ошибках. Плохой, в устойчивом смысле, защищает своё эго: оправдывается вместо проверки, обвиняет команду, рынок или данные и повторяет те же ошибки. Сравните несколько решений за согласованный период: какие данные использовал PM, что изменил после обратной связи и какие ограничения оставались вне его контроля?
Неопытность лечится временем и наставником. Устойчивую привычку защищаться время почти не лечит. Поэтому первому дают пару кварталов и понятные критерии, а со вторым разговор идёт уже о роли.
Три последних решения скажут больше ярлыка
Плохой продакт-менеджер системно превращает неопределённость в шум там, где от него ждут ясности: наращивает хаос вместо фокуса, выпускает функции вместо результата и изображает прогресс вместо обучения. Прежде чем вешать ярлык, проверьте систему вокруг него по разделу о причинах. Потом возьмите три последних решения этого человека и посмотрите, есть ли у каждого исходный уровень, цель и запись в журнале решений. Если нет ни у одного, разговор пора начинать именно с этого.