Разработчики ненавидят, когда работа превращается в бурную имитацию кипучей деятельности.

Конкретно в управлении продуктами проблема в том, что выросло поколение людей, которых учили управлять продуктом только с помощью метрик и глубинных интервью, и для них это единственный здравый способ растить продукт. Этот подход обещает успешный успех и активно продвигается на курсах для начинающих продактов. Когда рынок рос, это даже работало: можно было скопировать чью-то идею и дальше А/Б-тестами с миллионом итераций её докручивать. Но при росте рынка росли и метрики, а с этим — и ЧСВ таких продуктов.

Сейчас эти продукты превратились в продуктов «+/- полпроцента».

Собирательный образ такого продакта — это человек, который не отвечает ни за какие решения, прикрывается исследованиями и не развивает продукт. И на вопросы вроде «А почему пользователи к тебе должны прийти?» или «Зачем это нужно?» они отвечают с недоумением: «В смысле? Мне же руководители не дают принимать решения и бюджет на исследования, а разработчики всё ставят под сомнение и ничего не хотят делать!..»

Но вот в чём штука: микроизменения — это не зло, ведь опытные разработчики также двигаются небольшими итерациями. Проблема — в микроизменениях БЕЗ понимания, куда идём.

Я занимаюсь евангелизмом и развитием продуктового подхода уже много лет, начинал с первого ProductCamp, преподавал в БШВД, потом — ВШЭ, участвовал в формировании продуктовых процессов в Авито (времён, когда появилась тема «зубастых продуктов»), Strategy Mindset c ProductSense. Сейчас у нас мастерская развития инструментов управления продуктами. Плюс я погружался в работу в Wargaming, Kaspersky, Яндекс, ЦФТ, Райффайзен Банк, Lamoda, BTS Digital, IBA и так далее.

Менеджеры «полпроцента» и ложная дилемма

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

Микрооптимизация — это нормальный инструмент для большого устоявшегося продукта: где-то чуть улучшить конверсии, где-то перекрасить кнопку, добавить пуш в онбординг. Это как ювелирная обработка лобзиком — важная и нужная работа.

Но вот ключевой момент, который упускают: микроизменения без стратегии — это хаос. Стратегия без микрошагов — это фантазии. Нужно и то и другое.

Три стадии жизни продукта

Стартап/создание — у вас нет ресурсов для продуктового штаба. Нужно быстро валидировать гипотезы, выбрать правильные ставки, докатить до деливери и доказать жизнеспособность идеи.

Рост — работа с Jobs to be Done, поиск недообслуженных потребностей, выстраивание новых каналов. Это классика продукт-менеджмента.

Оптимизация — продукт-кормилец генерирует прибыль, есть потоки клиентов. Здесь уместны A/B-тесты и микрооптимизации.

Проблема: если методы оптимизации применять к стадии роста — вы не сможете ничего вырастить. Но продукт 0,5% не умеет переключаться между режимами.

Продакт 0,5% не умеет так делать, потому что его учили те, кто сделал свою карьеру в оптимизации:

• Проведи исследование.

• Сделай А/B-тест по результатам.

• Проверь, как это повлияло на главные метрики.

• Повторяй до достижения результата.

Это означает зацикленность на мелких улучшениях. Такие продукты ставят метрику во главу угла, хотя она должна быть лишь способом измерения, а не целью. Они отрицают подходы, которые нельзя измерить мгновенно, считая, что если что-то не покрывается экспериментами, то этого не существует в этом мире.

На других этапах «изобретение» продуктовых решений и нащупывание аудитории по принципу парковки по «хрусту» тоже возможно, но отбирает три самых ценных ресурса: время, ресурсы разработки и доверие целевой аудитории.

Инженерный подход: от хаоса — к паттернам

Если вы задумаетесь о том, как работают инженеры, то увидите, что «методом научного тыка», как правило, страдают джуны, за что получают «канделябром» по голове, и это при том, что в рамках CI/CD проблемы выявляются в тот же день, а опытные разработчики довольно редко используют микроитеративный подход эволюционного типа.

Это связано с тем, что есть работающие системы шаблонов проектирования. Это модели, которые в других подобных условиях уже доказали свою эффективность, имеют чёткие названия, структуру, а также преимущества и недостатки решения, что позволяет использовать их для быстрого и качественного решения возникающих вопросов.

Инженер не придумывает на ходу новую реализацию плагинной архитектуры. Он знает паттерны от Observer до Factory, от Chain of Responsibility до Strategy. Он проектирует систему исходя из мирового опыта.

В разработке есть и макродизайн (архитектура на основе паттернов), и ежедневная работа по реализации. Одно без другого не работает.

В продукте должно быть точно так же. В современном управлении продуктами интуиция и «метод научного тыка» должны закончиться.

Почему разработчикам это важно? Потому что смена подхода в структуре решения, как и изобретение велосипедов, ведёт к кратным потерям времени на создание, поддержку и переделки.

Сравнение подходов: микрошаги и видение

Проблема — не в выборе между подходами. Проблема — в их разрыве. Продукты 0% — Совы-стратеги: «мыши, станьте ёжиками». Бесят ещё больше, чем продукты 0,5%.

Кризис управления продуктами

Как я уже говорил, у меня хорошее положение на рынке, и я вижу ситуацию на разных уровнях управления: из-за преподавания и консультаций в лидирующих компаниях я могу оценивать, что сейчас происходит в целом.

В целом популярные подходы к разработке продуктов сломаны и неэффективны. Если CEO или HR в теме «каcдева», то «починить» управление продуктами достаточно сложно.

С каждым годом это всё больше напоминает карго-культ.

Системные проблемы подходов, основанных ТОЛЬКО на микроизменениях:

1. Отказ от ответственности. Вместо принятия решений — «Пойду спрошу пользователей». Это инфантильная позиция, когда ответственность перекладывается на исследования.

2. Страх стратегических решений. Многие паттерны дают «отрицательный рост» на первом этапе. Продакт «полпроцента» никогда их не примет: это же квартальный бонус!

3. Создание хаоса. Без долгосрочного видения микроизменения превращаются в суету: «Всё, бежим сюда!», «Ой, теперь другая метрика, молимся на retention!»

4. Накопление техдолга. Постоянные метания = нет времени на нормальную реализацию = техдолг растёт = разработчики в ярости.

Как отличить слабых продуктов

Первый симптом слабого продукта — постоянная имитация бурной деятельности. Ведь нужно показать, что работа идёт, что исследования ведутся, что продукт развивается, вот график, а вот презентация, почему не получилось, но мы очень старались, просто эксперименты не окрасились!

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

Из-за постоянных авралов идёт накопление технического долга. У команды просто нет времени на исправление ошибок и улучшение кодовой базы.

Появляется банальное неуважение к разработчикам. Продакт не может объяснить, как продукт должен работать, и не хочет разбираться в технических деталях.

Если у вас нет времени сделать по-человечески,
то где вы будете брать время на то, чтобы переделывать?

Почему так?

Потому что продакт не знает, что делать.

Его обучение говорит, что надо выбрать метрику и проводить А/B-тесты. Мир же показывает, что этот подход очень правильный, защищённый, приятный, легко обосновывается, но совершенно не даёт принципиальных сдвигов и главное — ничего не гарантирует: это понимает любой инженер ).

Таблица динамики изменений в зависимости от результатов тестирования

Капитанство на конкурентном рынке не даёт преимуществ и ведёт к 0,5%. Реальные сдвиги дают стратегические решения, которые неэффективны в краткосрочной перспективе.

Многие стратегические паттерны невозможно измерить на первом этапе. Многие другие дают «отрицательный рост» на первом этапе, поэтому ХОРОШИЕ решения никогда не будут приняты такими продактами.

В результате появляются беспомощность и оптимизация уже дохлой лошади.

Как надо: разберём на примере паттерна Product-Led Growth (PLG)

Если очень коротко, то он говорит о том, что в основе лежит хороший продукт. «Хорошо делать хорошо», конечно, звучит, но тут есть ряд особенностей. Как шаблон проектирования его сформулировали в OpenView в 2016 году, а потом подтвердили на примерах Slack, Dropbox, Zoom и др., которые выросли в основном через вирусность и ценность своего продукта, а не через классические продажи.

Классические продажи строят через отделы продаж (Sales Led Growh) или оптимизацию воронок. При этом формируется отдельная команда оптимизации пути клиента, и стоимость привлечения клиентов (CAC) через этот канал постоянно растёт. Теперь даже корпоративные пользователи хотят сначала потрогать, а потом решить, покупать или нет. Стратегия Product-Led Growth предлагает перестроить бизнес-модель так, чтобы продукт продавал себя сам. Это означает, что продукт становится основным инструментом привлечения и удержания: компания делает упор на бесплатные версии, модель try-before-you-buy, вирусные механики (реферальные программы, встроенное приглашение коллег) и высокое качество core-ценности, которую пользователь получает сразу.

Монетизация при PLG обычно происходит через модель Freemium или премиум-функции: базовый продукт бесплатен, но за расширенные возможности или масштаб взимается плата — это снижает порог входа и создаёт широкий топ воронки. Ключевые метрики смещаются на продуктовые — активацию, удержание, вирусный коэффициент. Например, Slack вырос без агрессивных продаж: люди сами начинали использовать бесплатный чат, а затем компании переходили на платные тарифы для дополнительного функционала. Паттерн PLG структурирует такой подход: фокусируйся на продукте и пользователях, убери трения входа, дай ценность сразу — и продукт станет двигателем роста бизнеса.

Так вот, я не представляю, как этот шаблон будет открывать каждый новый продакт, у которого проблемы с ростом CAC. Придётся уйти от классического отдела продаж, придётся сфокусировать маркетинг на пути внутри продукта и так далее — это очень тяжело сделать через постепенные итерации, и в процессе переключения подходов будет просадка. А просадка даже на полпроцента недопустима! Это ведь квартальный бонус!

Вот и получается в итоге, что сильных решений боятся и не знают, как их принимать, а слабые решения безопасны, комфортны и не вызывают осуждения.

Паттерн Product-Led Growth (PLG)

Сформулирован в OpenView в 2016 году, подтверждён на примерах Slack, Dropbox, Zoom.

Проблема:

Падение доверия потребителей к рекламным обещаниям.

Как работает:

• Продукт продаёт себя сам.

• Freemium или try-before-buy-модель.

• Вирусные механики встроены в продукт.

• Метрики смещаются с продаж на активацию и retention.

Критический момент: переход на PLG означает временную просадку выручки. Придётся отказаться от классического отдела продаж.

Паттерн Hook Model (Nir Eyal)

Проблема:

Низкая вовлечённость пользователей в использование продукта.

Структура:

Заменить внешний триггер — рекламу — на внутренний импульс и создать подкрепление.

1.     Trigger (внешний → внутренний) — что заставляет вернуться.

2.     Action — простейшее действие в ожидании награды.

3.     Variable Reward — непредсказуемое вознаграждение.

4.     Investment — вклад пользователя, повышающий ценность.

Пример — Instagram Stories.

• Trigger: пуш-уведомление → скука.

• Action: свайп вверх для просмотра.

• Variable Reward: интересный контент от друзей (или нет).

• Investment: создание своей истории.

Результат: DAU/MAU вырос с 45 до 72%.

А теперь — вопрос к сообществу:

Как вы думаете, должно ли управление продуктами эволюционировать в сторону паттернов проектирования по аналогии с разработкой? Или это попытка натянуть инженерный подход на творческий процесс?

Варианты для размышления:

• Паттерны убьют креативность и превратят продуктов в шаблонных исполнителей.

• Паттерны дадут общий язык между продуктами и разработчиками.

• Паттерны работают только для зрелых рынков, а для инноваций нужен хаос.

• Паттерны — это просто новое модное слово для старых практик.

Особенно интересно мнение тех, кто работал и с продуктами «старой школы» (интуиция + опыт), и с продуктами «новой волны» (метрики + A/B-тесты). Что работало лучше? И готовы ли вы к третьей волне — продуктовой инженерии?

Делитесь опытом в комментариях. И заодно — что ждёт паттерны проектирования в разработке.

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

С приходом AI-агентов всё это будет неважно

AI меняет игру на обоих уровнях.

Сейчас AI может улучшить и качество стратегических решений, и скорость микрошагов:

• GPT генерирует 100 гипотез в секунду, но без стратегического контекста это просто умножение хаоса.

• AI ускоряет A/B-тесты, но куда тестировать, если не знаешь, куда идёшь?

• Можно быстрее валидировать паттерны, но нужно их знать.

AI — это усилитель. Он усиливает и хаос без стратегии, и скорость движения со стратегией.