Семь месяцев назад я опубликовал на Хабре статью про ментальные ограничения в управлении продуктом. Перечитал ее, остался недоволен. Слишком плоско. Слишком абстрактно. Главного я тогда не сформулировал.
Меня зовут Александр Козуб и я уже двадцать лет в финтехе, последние несколько из них в качестве CPO. Специализируюсь на ситуациях, когда очевидные рычаги роста уже не работают, и нужны системные решения, а не новые фичи. В симптомах вижу систему, об этом и пишу
Эта статья представляет вторую попытку, и в ней я попробую разложить то, чего в первой не было: механизм. То, как именно добросовестная продуктовая работа методично сужает рамку возможного у тех, кто ее делает.
Парадокс, который вы видели на этой неделе
Десять человек в стартапе за два месяца делают то, что команда из двухсот опытных специалистов в зрелой компании, с бюджетом, с экспертизой, с правильной методологией, не может сделать за год.
Признайтесь: вы такое наблюдали. Возможно, даже на этой неделе.
Привычные объяснения известны: бюрократия, долгий путь принятия решений, технические долги, дефицит ресурсов, конкуренты, которые тянут одеяло на себя. Каждое из этих объяснений работает локально: его можно подтвердить примерами, под него можно подвести метрики. Но в сумме они не сходятся в причину, потому что объясняют только часть ситуации. На мой взгляд, все это следствия, а не причины.
Тезис, к которому я пришел за последние два года работы CPO продукта с MAU 500K и командой за 200 человек, формулируется так: ваш продукт не выстреливает не из-за внешних обстоятельств. Главный блокер — ваши ментальные ограничения и ваша внутренняя рамка принятия решений, которая со временем сжимается до точки. И сжимаете ее вы сами. Через те самые лучшие практики, которыми гордитесь и о которых все пишут на Хабре.
Никто, кроме вас, эту рамку не сожмет и не разожмет.
Дилемма Кристенсена на этаж ниже
Когда я готовил эту статью, я обнаружил, что описываю похожую проблему, которую Клейтон Кристенсен описал в «Дилемме инноватора» почти тридцать лет назад. Только он писал про корпорации и топ менеджмент, а я смотрю на этаж ниже: продакт-менеджеры, команды, фичи.
У Кристенсена менеджеры компаний делают все правильно по канонам корпоративного управления и проигрывают рынок. Финансовая логика акционеров не дает инвестировать в маржинально слабые сегменты, на которых растет подрывная технология. Это структурная ловушка корпоративного уровня.
На уровне продакт-команды ловушка устроена по-другому, но имеет ту же природу. Продакт-менеджеры делают все правильно по канонам продуктовой методологии и теряют способность к значимым решениям. Логика приоритизации не дает поднимать задачи, которые не вмещаются в текущую формулу эффективности. Это структурная ловушка операционного уровня. Та же дилемма, другой этаж.
И как у Кристенсена, проблема не в том, что люди работают плохо. Проблема в том, что они работают по системе, у которой есть встроенный дефект.
Где это случается, а где нет
Прежде чем разворачивать механизм, важно очертить периметр.
Эта проблема не появляется у стартапов из десяти человек: у них рамка и ограничения еще не успели сформироваться, они еще бегут и пробуют. Эта проблема не появляется в больших корпорациях: там работают совсем другие законы, и сужение рамки происходит не через приоритизацию, а через регуляторку, compliance и многоуровневую согласованность.
По теории жизненного цикла организаций Ицхака Адизеса, проблема, о которой я говорю, локализуется в очень специфической точке: после стадии «давай-давай», когда продукт построен, команда выросла, доля рынка занята, и впереди должен быть расцвет. Должен быть, но не наступает. Вместо роста и доминирования начинается то, что Адизес называет преждевременным старением: год без значимого изменения продукта, метрики растут на полпроцента в квартал, лучшие специалисты начинают уходить, потому что им скучно.
Если узнаете свою компанию: дальше разворот.
Механизм спирального падения
Спираль состоит из четырех витков. Каждый следующий вытекает из предыдущего. Это не четыре параллельных проблемы, а одна разворачивающаяся история.
Виток первый: приоритизация как инструмент потока
Все мы используем приоритизацию: RICE, ICE, MoSCoW, WSJF, кастомные скоринговые модели, правило Парето. Все эти инструменты работают на одну задачу: выбрать следующий шаг, который даст максимальный эффект при минимальных ресурсах.
Это правильно. Бизнес неотделим от продукта, а бизнес должен расти. Поток задач должен быть оптимизирован.
Вот в чем проблема: приоритизация — это инструмент потока, а не инструмент состояния. Она оптимизирует следующий шаг, а не картину системы в целом.
Посмотрите на формулу RICE: (Reach × Impact × Confidence) / Effort. В этой формуле Effort учитывается как константа в момент оценки. Вы оцениваете задачу так, словно она существует в вакууме.
Но в реальности эффорт не константа, а динамическая величина. Каждое ваше решение, даже локально оптимальное, оставляет в системе след: появляются исключения, нарастает связность, накапливаются обходные пути и устные договоренности, плодятся строчки в регламентах и кастомные элементы в дизайн-системе. И вчерашняя простая задача сегодня уже не такая простая: она требует больше ресурса, потому что состояние системы вокруг нее изменилось.
Каждый раз, когда вы пользуетесь RICE, вы оптимизируете движение в системе, которую сами же сделали тяжелее. И инструмент вам этого не показывает, потому что не умеет.
Это и есть первый виток: долги в продукте накапливают не разработчики, накапливаем мы, продакты, через инструмент, которым гордимся.
Виток второй: четыре слоя долга
Когда мы говорим о долге, мы почти всегда подразумеваем технический. И понятно, почему: технический долг единственный, у которого есть наглядное отражение в виде кодовой базы. Разработчики о нем сигнализируют на каждом груминге, на каждом планировании, на каждом ретро. Из всех долгов он один говорит за себя.
На самом деле тех. долг только видимая верхушка. Под ватерлинией копятся еще три слоя, которые почти никогда не управляются осознанно.
Бизнес-долг: устные договоренности между подразделениями, исключения из правил, неотруленные конфликты интересов, которые при каждом новом решении прорываются в продукт, в решения и усложняют, усложняют, усложняют.
Продуктовый долг: незавершенные сценарии, неактуальный функционал, который никто не убрал, половинчатые решения, которые когда-то были компромиссом и остались как норма.
Дизайн-долг: кастомные элементы, которые завелись по одному поводу и остались жить как сорняки, локальные правки в дизайн-системе, которые не были интегрированы обратно в библиотеку, грязные обходные решения визуальных проблем.
Эти три слоя копятся молча, и именно они, а не технический долг, в основном перекрывают команде кислород. Когда продакт-менеджер видит, что простая задача занимает шесть недель вместо двух, он автоматически смотрит на тех. долг, потому что разработка именно о нем говорит. На самом деле в эти шесть недель входит работа со всеми четырьмя слоями: согласовать неотруленные конфликты, доделать недоделанные сценарии, привести в порядок локальный дизайн, и только потом разобраться с архитектурой.
Видим один долг из четырех. Поэтому жалуемся на разработку.
Виток третий: когнитивная перегрузка
Хорошо, в системе четыре слоя долга, из которых мы видим один. Что с этим не так?
С этим вот что. Растущая совокупная сложность системы перегружает мышление того, кто ею управляет. Каждое решение требует держать в голове все больше нюансов: исключений, зависимостей, особых случаев, договоренностей. «Не трогай этот модуль, иначе все сломается». «В этом сегменте у нас особый процесс согласования». «Эту фичу мы три раза не смогли убрать, потому что в ней зацепился ключевой клиент».
В какой-то момент картина перестает помещаться в голову. Не потому, что специалист недостаточно сильный, а потому, что объективная сложность переросла индивидуальный когнитивный лимит. Это не патология, это нейропсихологическая норма.
И что делает мозг под перегрузкой? Он начинает экономить. Сужает фокус до сиюминутного, подтверждает то, во что хочется верить, не замечает того, чего нет в актуальном поле зрения. Все это вместе называется когнитивными искажениями, и работают они автоматически, помимо воли носителя.
У этого механизма есть имя в науке и серьезная исследовательская база. Если вы еще не погружались в когнитивные искажения, настоятельно рекомендую «Думай медленно… решай быстро» Даниэля Канемана. По моему опыту, после этой книги у читателя меняется отношение к доброй половине решений, которые он принял за последний год.
Это и есть третий виток: сложность системы превышает когнитивный лимит, лимит перегружен, перегруженный мозг принимает решения автоматически, автоматические решения держатся внутри известного.
Виток четвертый: лингвистика рамки
Пожалуй, самое важное наблюдение из всего, что я хочу донести в этой статье, формулируется так: сужение рамки принятия решений не объявляет о себе, оно проявляется во фразах.
Вот четыре фразы, по которым можно диагностировать сужение рамки на любой продуктовой встрече:
«Так исторически сложилось». «Это слишком дорого». «Без рефакторинга мы это не изменим». «Зачем переусложнять, если есть простое решение».
Каждая из них кажется разумной. Каждая может быть фактически правдой. Я уверен, что вы слышали все четыре на этой неделе, а возможно, и сами их говорили.
Но каждая из них не аргумент, а симптом. Симптом того, что облако возможных решений в этой голове или в этой команде уже сжалось. Аргумент защищает позицию через логику. Симптом защищает позицию через инстинкт сохранения статус-кво.
И есть пятая фраза. Звучит редко, и звучит так: «А что, так можно было?».
Эта фраза является симптомом обратного. Симптом того, что из рамки удалось выйти, что облако расширилось, что в комнате появилось решение, которое не вмещалось в текущую картину мира.
Если вы давно не слышали ее в своей команде, задумайтесь. Кажется, ваша рамка затянулась.
Тирания мелких изменений
У состояния, в которое продукт-команда попадает после четырех витков спирали, есть имя. Альфред Кан, американский экономист, в 1966 году ввел понятие tyranny of small decisions. Им он описывал ситуацию, в которой серия отдельных рациональных решений в сумме приводит к коллективному результату, который не устраивает никого.
В продуктовой работе это выглядит так. Команда работает. Релизы идут. Метрики чуть-чуть улучшаются. Все заняты, все профессиональны, все добросовестны. И при этом совокупно за год значимого результата не получается: передвигаются кнопки, меняются плейсхолдеры, синенькое перекрашивается в красненькое, красненькое в зеленое. Каждое отдельное решение оптимально по RICE. Совокупный итог — преждевременное старение продукта.
Это и есть тирания мелких изменений на продуктовом этаже: не лень, не глупость, не плохой менеджмент, а закономерное последствие добросовестной работы внутри методологии, которая по построению оптимизирует следующий шаг, а не общее состояние.
Признание, без которого статья была бы нечестной
Я сейчас описываю спираль так, словно я ее преодолел, но это не совсем правда.
В 2023 году я стал CPO продукта, который четыре года не рос по выручке, но активно расширялся по фичам. Я был уверен, что знаю, что делать.
Первый год я вычистил продукт от лишнего: аудит, скоринг, ухудшающие тесты. Отказались от трети функционала, не потеряв ни в деньгах, ни в пользовательских метриках. Это получилось.
Второй год должен был быть годом роста. И вот тут я обнаружил, что не могу.
Моя команда — сильные продакты, прошедшие через несколько кризисов. Я сам двадцать лет в индустрии, два диплома, выученная теория, полевой опыт. Мы все вместе не могли двинуть продукт дальше косметики. Я провел год, расширяя облако вариантов вручную: на каждом 1:1, на каждом ревью, на каждом груминге. У единиц получалось процентов на тридцать, у остальных не получалось вовсе.
Я ушел из этого проекта, не решив проблему. Те самые рекомендации, которые я писал в собственных статьях почти год назад, а именно реестры долгов, аудиты, debt-mapping, я их не успел проверить на практике в полном объеме. Я диагностировал систему, но не вылечил систему.
И вот что я понял за это время. То, с чем я столкнулся, не моя личная неудача. Это неизбежность: любой добросовестный CPO, любой опытный продакт-менеджер, работая внутри стандартной методологии, упрется в ту же стену. Не потому, что он плохой, а потому, что методология по построению не видит того, что мы оставляем за собой.
Мы, продакт-менеджеры, сами это создаем. И только мы можем это исправить.
Что с этим делать
Я не дам вам шесть шагов, не дам формулу успеха, не дам реестр, не дам инструмент.
Через минуту вы поймете, почему. А сначала одно смещение вопроса.
Стандартный продуктовый вопрос звучит так: «Что мне сейчас протестировать?» или даже «Какую следующую гипотезу мне протестировать?». Этот вопрос всегда дает ответ внутри рамки, потому что ответ ищется в текущем облаке гипотез, а это облако с каждой итерацией сужается. Эксперимент идет, дает “нулевой” результат, добавляет в продукт еще один слой долга, рамка сужается еще на чуть-чуть.
Я предлагаю заменить вопрос. Не «что протестировать?», а «какое следующее сильное решение мы реализуем?». Не «как поднять метрику на полпроцента?», а «какие наши решения могут увеличить ценность продукта кратно?».
В этой формулировке три ключевых слова, и каждое работает против рамки.
Сильное. Не «эффективное». Эффективность измеряется в рамках, которые у вас уже есть. Сила и значимость измеряются в более широкой картине, в которой можно усомниться в самой рамке.
Реализуем. Не «протестируем». Тестирование готовится получить «нет», и при этом оно все равно оставит след в продукте. Реализация готовится получить продукт.
Кратно. Не «плюс N процентов». Проценты остаются внутри текущей картины мира, а кратность ее ломает: если вы планируете вырасти в три раза, вы не можете использовать те же инструменты, те же сегменты и те же предположения.
И один методологический принцип, который вытекает из этого вопроса. Работайте не над следующей фичей, а над снятием ограничения. Если за пределами вашей рамки есть задача, которая выведет продукт на новый уровень, и вы ее не делаете только потому, что у вас ограничение, переключайтесь с фичи на снятие этого ограничения. Это и есть сильное решение.
Передача эстафеты
На последок, почему я не дам шесть шагов.
У вашего продукта свой контекст: своя история, своя команда, свои фразы, свои долги на каждом из четырех слоев, своя рамка, сжавшаяся определенным конкретным образом. Я этих деталей не знаю. Их знаете только вы.
Я могу дать диагноз и вопрос. Дальше у каждого своя работа: свои наблюдения за фразами в своей команде, свои гипотезы про то, какое решение будет сильным именно для вашего продукта, свое решение, что снимать в первую очередь, в какой последовательности и какой ценой.
Никаких универсальных шести шагов здесь нет, и кто бы их вам ни предложил, в его шагах не будет вашего контекста. Есть только ваша конкретная система и ваш собственный исследовательский путь внутри нее.
Финал
Я начал эту статью с одного тезиса. Закончу тем же.
Ваш продукт не выстреливает не из-за конкурентов, топ-менеджмента или бюрократии. Главный блокер — ваши собственные ментальные ограничения и ваша внутренняя рамка принятия решений, которая со временем сжалась до точки. И сжали ее вы сами через лучшие практики, которыми гордитесь.
Никто, кроме вас, ее не разожмет.
Идите и услышьте на ближайшей продуктовой встрече фразу «А что, так можно было?». Если не услышите, задайте этот вопрос сами.
5-7 июня буду спикером на ProductCamp ’26, там же будет место для разговора и спора вокруг этой темы. Если у вас в команде уже звучат фразы из четвертого витка, или вы видите признаки преждевременного старения продукта, напишите в комментариях, какая из четырех фраз у вас звучит чаще всего. Это даст коллективный срез по индустрии.
ссылка на оригинал статьи https://habr.com/ru/articles/1034536/