За два года PM не сказал «нет» ни одному запросу продаж. Он ни разу не поссорился с разработкой и каждый месяц вовремя обновлял roadmap. Метрики при этом стояли, а потом начали падать.
Плохой Product Manager редко выглядит как открытый вредитель. Чаще он вежлив, рационален и выглядит «нормально». Этим он и опасен: продукт под его управлением не ломается резко. Он медленно теряет ход.
Сам PM не считает, что вредит делу. Он думает, что действует разумно и профессионально, и каждое его решение по отдельности это подтверждает. Тихий саботаж почти никогда не бывает осознанным. Шансов на развитие продукт лишает сумма решений, бездействий и защитных реакций.
Тихий саботаж складывается из разумных компромиссов
Плохого PM обычно ищут по результату: продукт стагнирует, значит кто-то «не справился». Упрощение удобное, но оно скрывает механизм. Продукт редко умирает из-за одного неверного решения. Его разрушает цепочка мелких компромиссов, каждый из которых в моменте выглядит разумным.
PM соглашается, откладывает, не спорит, не уточняет. Ни одно из этих действий не тянет на ошибку. Вместе они складываются в устойчивое торможение.
Ловушку усиливает то, что плохой PM не нарушает правил. Он следует процессам, заполняет документы, ходит на встречи. Формально обвинить его не в чем, поэтому проблема так долго остаётся незамеченной. Искать нарушение бессмысленно, когда беда в том, что ничего не происходит.
Роль, в которой тормозить безопаснее
Если присмотреться к процессу, тихий саботаж начинается там, где сломано управление продуктом. PM оказывается между ожиданиями и реальностью, без власти и без ясных ориентиров. И вместо продукта начинает гасить напряжение.
Механика простая. Стратегия не определена, и PM подменяет её списком задач. Цели не зафиксированы, и приоритеты определяет громкость голоса стейкхолдера. За ошибки наказывают, и PM перестаёт рисковать. Каждое условие делает торможение безопаснее движения. Вместе они создают роль, в которой разумный человек выбирает тормозить.
Саботаж в такой системе похож на осторожность, аккуратность и «взвешенность», то есть на качества, за которые обычно хвалят. Продукту же нужно движение, а его в этой роли никто не требует.
Ошибка допустима, пока за ней стоит проверка
Осторожный PM объясняет своё поведение нежеланием ошибаться. Но в продуктовой работе ошибки неизбежны, и их отсутствие говорит об отсутствии поиска. PM, который никогда не ошибается, скорее всего, ничего не проверяет.
Ошибки гипотез, сегментации, позиционирования и приоритизации входят в обычную работу discovery. Они ценны, если записаны и приводят к корректировке курса. Допустимую ошибку выдаёт действие за ней: PM что-то проверил и поэтому ошибся быстро и дёшево. Если из пяти гипотез за квартал подтвердилась одна, а четыре закрыты с записанным выводом, команда работает нормально.
Некомпетентностью ошибка становится в трёх случаях. Первый: неопределённость служит оправданием бездействия, и PM прикрывается сложностью рынка, чтобы не решать. Второй: одни и те же ошибки повторяются, а выводов никто не делает. Третий, самый опасный: ошибку маскирует процесс. Формально всё сделано правильно, результата стабильно нет, и продукт умирает без единого пункта, к которому можно предъявить претензию.
Как саботаж выглядит в работе
На каждом участке у тихого саботажа своё лицо, но устроен он одинаково: острый вывод, жёсткое решение или чёткая формулировка подменяются безопасной имитацией.
Симптомы в исследованиях
В исследованиях саботаж выглядит как их имитация. Интервью проводятся, но вопросы ничего не меняют в картине. Боль пользователя описана так общо, что по ней нельзя принять решение.
Дело не в неумении. Острые выводы потребовали бы конфликтов и пересмотра планов, и PM их избегает. Проверка простая: возьмите последние 10 интервью и найдите решение, которое после них изменилось. Если таких нет, исследования только консервируют неопределённость, и команда постепенно перестаёт относиться к ним всерьёз.
Симптомы в разработке
В разработке избегание выдаёт себя за «разумную осторожность». Релизы дробятся до бессмысленности, решения откладываются, потому что «ещё не всё понятно», roadmap становится списком намерений без обязательств.
Чтобы избежать конфликта, PM соглашается на любые правки сверху. Продукт теряет целостность, команда теряет направление, и разработка превращается в поток мелких задач без эффекта.
Симптомы в коммуникации
В коммуникации саботаж проявляется через сглаживание углов. PM избегает чётких формулировок, не называет риски прямо и не фиксирует договорённости. Стейкхолдеры получают иллюзию контроля вместо реальной картины, команда не понимает, что действительно важно, и в зоне комфорта оказываются все, кроме продукта.
Артефакт, который не помогает сказать «нет», работает против продукта
Раз сам саботаж невидим, искать его стоит по следам в артефактах. Само наличие документов мало что говорит, важнее, как ими пользуются. Зрелые артефакты создают напряжение, потому что заставляют принимать решения. Незрелые это напряжение снимают.
Документ с гипотезами может быть инструментом фокуса, где записаны предположения, риски и критерии проверки. А может быть файлом, который «нужен для процесса» и ни на один выбор не влияет. То же касается roadmap, OKR, отчётов и презентаций.
Проверить это можно за полчаса. Откройте roadmap за последние два квартала и посчитайте, сколько пунктов из него убрали с записанной причиной. Ноль за полгода почти всегда означает, что артефакт ничего не отсекает: работа ведётся, продукт не движется.
Самый полезный артефакт против тихого саботажа занимает одну строку на решение: что решили, почему, на каких данных, когда пересматриваем. Например: «Не делаем интеграцию с CRM для малого бизнеса в этом полугодии: 3 из 40 клиентов сегмента о ней просили, пересмотр в марте». Такой журнал невозможно вести, не принимая решений, и пустой журнал за месяц сам по себе диагноз.
За десятью провалами стоят три страха
Типичных провалов около десяти. Решения откладываются под предлогом дополнительного анализа. PM соглашается со всеми стейкхолдерами. Тактика подменяет стратегию. Discovery имитируется. Публичной ошибки боятся настолько, что выбирают самое безопасное и бесполезное решение. Критериев успеха нет. Процесс защищают вместо результата. Коммуникация размыта. Слабые сигналы рынка видят, но не проговаривают. Бездействие выдаётся за осторожность.
По отдельности эти провалы не выглядят ошибками, но у них всего три корня:
- Страх решения: откладывание, выбор самого безопасного варианта, бездействие под видом осторожности.
- Страх конфликта: согласие со всеми, размытая коммуникация, замалчивание неприятных сигналов.
- Отсутствие измерения: подмена стратегии задачами, имитация discovery, работа без критериев успеха, защита процесса.
Третий корень делает возможными два первых. Там, где результат никто не измеряет, имитацию нельзя отличить от работы. Все три корня ведут к тому, за что PM оценивают, и уже потом к его характеру.
Отчёт о работе вместо результата: беда роли, а не характера
У этого паттерна есть имя в продуктовой литературе. Марти Каган из Silicon Valley Product Group (книги «Inspired», 2017, и «Empowered», 2020) разделяет «команды фич» и «уполномоченные продуктовые команды». Первым выдают список задач и спрашивают за факт поставки. Вторым дают проблему и спрашивают за результат.
Тихий саботаж почти всегда означает режим «команды фич», навязанный ролью. Если PM меряют по закрытым тикетам и соблюдённому процессу, безопаснее исправно поставлять и не спорить, чем брать на себя исход.
Отсюда диагностика, которая работает лучше списка личных качеств. Спросите про любую недавнюю инициативу, какой измеримый результат она должна была изменить и на сколько. Зрелый ответ звучит как «снизить отток первого месяца с 12% до 9%». Ответ тихого саботажа: «выкатили фичу, сделали редизайн, провели интервью». В первом случае речь о результате для бизнеса (outcome), за который отвечают. Во втором о сделанной работе (output), которой отчитываются.
Практический вывод честнее: чинить надо систему, в которой сделанную работу ценят выше результата. Дайте PM проблему и право сказать «нет», свяжите оценку с метрикой, и тот же вежливый осторожный человек начнёт принимать другие решения.
У этого переключения есть цена, и её лучше назвать заранее. Уполномоченной команде нужен доступ к данным, право отказывать стейкхолдерам и терпение руководства к неудачным попыткам. Конфликтов в первые месяцы станет больше, и часть ставок не сыграет. Руководителю, который не готов к этому, честнее оставить режим «команды фич» и не ждать от PM продуктовых результатов.
Отслеживать переход можно одной метрикой и одним ограничителем. Метрика: медианное число дней от момента, когда вопрос поднят, до записанного решения. Если было 30, а стало 10, торможение уходит. Ограничитель: доля решений, которые пришлось откатить. Если она поднялась выше 20-25%, команда решает быстрее, чем успевает думать, и стоит вернуть один шаг проверки.
Квартал ожидания стоит около 100 тысяч долларов в год
Тихий саботаж трудно заметить ещё и потому, что его цена не попадает ни в один отчёт. Прикинем её на выдуманных, но правдоподобных цифрах.
Допустим, команда давно обсуждает изменение онбординга, которое по оценке поднимет конверсию из пробного периода в оплату с 10% до 12%. В продукт приходит 4 000 пробных пользователей в месяц, средний платёж 50 долларов. Цена каждого месяца без изменения считается одной строкой:
Цена месяца = пробные пользователи × прирост конверсии × средний платёж = 4 000 × 2% × 50 = 4 000 долларов
За этой суммой стоят 80 платящих клиентов, которых могло бы быть больше. И это только одна месячная когорта.
PM откладывает решение «до следующего квартала». За три месяца продукт недополучает три когорты по 80 клиентов. Если 70% из них остались бы к концу квартала, это около 170 клиентов и примерно 8 400 долларов ежемесячной выручки, которой нет. В годовом выражении это около 100 тысяч долларов, и ни в одном отчёте не будет строки «ошибка PM».
Оценка в 2 пункта может не подтвердиться, и это нормально. Тест на месяц стоил бы дешевле квартала ожидания и ответил бы на вопрос. Правило здесь простое: если решение обратимо, а ожидаемый эффект за месяц больше стоимости проверки, откладывать его дороже, чем ошибиться.
Как звучит отложенное решение
Распознать такой режим можно и на слух. «Давайте пока не будем делать резких движений». «Сейчас слишком много неопределённости, чтобы решать». «Интересная идея, вернёмся к ней позже». «Нужно собрать больше мнений». «Давайте подождём следующего квартала».
Ни одна из этих фраз не агрессивна, каждая звучит как здравый смысл. Разрушительны они тем, что не ведут к действию и не оставляют следов. Решение, отложенное до следующего квартала, не попадёт в отчёт как ошибка, хотя продукт за этот квартал не сдвинется.
Две истории: страх решения и страх конфликта
Начнём с сюжета, сведённого из нескольких похожих команд. Компания развивала потребительский продукт в конкурентном рынке. PM был опытным, аккуратным и очень вежливым и всегда находил компромиссы. Исследования растягивались, разработка дробилась на мелочи, приоритеты постоянно уточнялись. Упрекнуть его было не в чем.
Со временем команда начала терять мотивацию. Результатов не было, явных ошибок тоже. В итоге поменяли роль, человека оставили: появилась жёсткая фиксация гипотез и дедлайнов, то есть критерии и даты, по которым идею можно закрыть. Через несколько месяцев продукт сдвинулся с мёртвой точки, хотя в команде никого не заменили.
Второй сюжет разворачивается в B2B. PM постоянно сглаживал конфликты между продажами и разработкой и считал это своей главной задачей. Запросы клиентов противоречили друг другу, PM не отказывал никому, и roadmap раздувался. Арифметика такого раздувания проста: если команда принимает 6 запросов в месяц, а успевает сделать 4, очередь растёт на 2 пункта ежемесячно, и за два года в ней копится почти 50 обещаний.
Когда метрики начали падать, выяснилось, что за два года не было ни одного чёткого отказа. Здесь корнем был страх конфликта, поэтому и лечение оказалось другим: PM получил мандат на жёсткую приоритизацию. Конфликтов стало больше, но продукт начал восстанавливаться. Рост числа споров здесь, пожалуй, самый честный признак того, что тихий саботаж закончился.
Когда медленный PM прав?
Бывают продукты, где медленный PM прав. В медицинских сервисах, платежах или продуктах под надзором регулятора цена ошибки несопоставима с ценой задержки. Один неудачный релиз платёжного сценария может стоить больше, чем год упущенного роста, и «давайте подождём» там означает ответственность.
Это касается необратимых решений: смены ценовой модели, миграции данных клиентов, изменения, затрагивающего деньги или безопасность пользователей. Там дополнительный анализ оправдан. Но и у него должны быть дата и критерий, после которых решение принимается. Осторожность без даты остаётся тем же тихим саботажем.
Для обратимых решений, а их в продуктовой работе большинство, правило обратное. Если изменение можно откатить за день, а эффект измерить за месяц, неделя на обсуждение уже много.
Второй законный случай касается нового PM. В первые 60-90 дней на роли много слушать и мало решать нормально: человек собирает контекст, и резкие решения без него опаснее медлительности. Отличить адаптацию от саботажа помогает тот же критерий даты. У адаптации есть конец и план: к 90-му дню PM называет три главные проблемы продукта и предлагает, что с ними делать. Если к полугоду таких предложений нет, адаптация закончилась, а торможение осталось.
6 вопросов для самодиагностики за полчаса
Для самопроверки достаточно открыть документы за последний квартал и честно ответить на шесть вопросов:
- Сколько решений за последний квартал вы отложили без даты возврата к ним.
- Сколько запросов стейкхолдеров вы отклонили с записанной причиной.
- Есть ли у каждой текущей инициативы измеримый результат с исходным и целевым значением.
- Сколько гипотез вы явно закрыли за квартал, включая неподтвердившиеся.
- Может ли любой человек в команде назвать два главных приоритета так же, как вы.
- Изменилось ли хоть одно решение после последних интервью с пользователями.
Ноль в любом из вопросов 2, 4 и 6 уже повод остановиться. Чаще за этим стоят одно-два отложенных решения, которые тянут остальное. Закрыть одно из них явно, с критерием успеха и датой проверки, полезнее, чем разбирать все шесть ответов сразу.
Для руководителя, который узнал в описании своего PM, вывод неприятнее. Право на ошибку, готовность к конфликтам и дедлайны у решений зависят от того, что поощряет организация. Если PM оценивают за закрытые тикеты и отсутствие конфликтов, тихий саботаж будет воспроизводиться с любым человеком на этой роли.