Антипаттерны продакт-менеджмента, или почему у многих компаний не получается внедрить продуктовый подход

Привет, меня зовут Юлия Билинкис. Я консультант, руководитель программ в Высшей школе бизнеса НИУ ВШЭ, стратег в МТС Финтех. С этого года я начала вести свой канал "Strategic Move", на котором делюсь своими заметками на тему стратегии и управления продуктами.

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

Итак, поехали. Всего 6 антипаттернов:

№ 1 Продакт-менеджер — это человек, который пишет ТЗ, согласовывает его с "бизнесом" и контролирует сроки

№2 Мы создали продуктовые команды, но задачи нам ставит все равно наш непосредственный руководитель, с ним нужно это все согласовать

№3 "Фабрика функций" вместо создания ценности

№4 Отсутствие волшебного слова "НЕТ"

№5 Недостаток доверия и отсутствие свободы принятия решений

№6 Недостаток продуктового мышления и прозрачных процессов управления продуктом

Это очень сильное заблуждение, которое берет свои корни из бизнес- и системного анализа. Во многих компаниях, которые только встают на продуктовые рельсы, задача управления продуктами превращается исключительно либо в задачу написания ТЗ (PRD) и передачу этого важного артефакта разработчикам, либо в задачу согласования (либо в то и другое). В них до сих пор считают, что менеджер проекта и менеджер продукта — это одно и то же.

Если раньше разработка, маркетинг, бизнес были отделены друг от друга организационными барьерами, менеджер проектов – был ключевой ролью, связывающей это все воедино и синхронизирующий всех (в лучшем случае), в худшем случае – это был человек, который ничего не понимал, но всех «пинал». Сейчас многие компании работают на базе продуктовых команд, которые имеют в составе всех ключевых игроков, выделенных от всех отделов. Таким образом, многие из менеджеров проектов, которые когда-то существовали в этих компаниях, теперь стали менеджерами по продуктам, но так и не перестроили свое мышление.

Я часто вижу продактов, утомленных часами написания документа, уходящих с работы за полночь, погрязших в согласовании документов с кучей заинтересованных лиц, на которое требуется больше недели встреч, чтобы передать его команде разработки. Обычно у них нет времени, и они носятся по офису с кучей блокнотов, ну а сейчас видимо с переполненными календарем zoom-встреч. Эти люди присутствуют на множестве встреч, отвечают на множество звонков и чувствуют себя незаменимым звеном цепочки. Нет никакой цели. Нет никакого видения. Здесь нет никакого процесса принятия решений. Зато они постоянно заняты. Так как такие продакты не сосредоточены на «почему», они, как правило, сосредотачиваются на «когда». Соответственно основной показатель эффективности работы – СРОКИ, фактически выраженные в человеко-часах. Если цель – написать и согласовать документ, то как следствие продакт вынужден идти на уступки этих лиц, что и делается: в требования добавляется то, что они хотят. Чаще всего приоритет получает фича, которую сказал сделать начальник. Именно тут они попадают в замкнутый круг создания никому не нужных фич. Обычно этому способствует некоторое количество выученной беспомощности.

2 самых частых вопроса от таких продактов на курсах: «Какой шаблон написания ТЗ мне использовать?» и «Как мне приоритезировать фичи?».

Если вы думаете, что agile — это серебряная пуля для создания большей ценности в программном обеспечении, то будете разочарованы, так как он в значительной степени игнорирует, как сделать эффективное управление продуктом, сфокусировавшись на value delivery, но не на value creation – методах. Тут можно вспомнить знаменитый цикл Gartner:

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

Если вы делаете что-то не так, не имеет значения, насколько эффективно или быстро вы это делаете, и ваш результат не обязательно имеет смысл или полезен, если вы не создаете ценность для клиента или бизнеса

Обычно это так: есть отдел маркетинга, отдел анализа, отдел разработки, то каждый из них разбирает продукт на «свои зоны ответственности». Здесь можно вспомнить закон Конвея: любая организация, разрабатывающая систему (в широком смысле), создаст продукт, структура которого является копией системы связей организации». Обычно этот закон применяют к разработке: в идеале каждый «кусок» продукта создается командой, которая тесно сотрудничает и хорошо понимает остальные команды. В этой команде («правило двух пицц» у Amazon) все знают друг друга, и общение проходит легко. Таким образом, конечный кусок-продукт, поставляемый этой командой, будет ощущаться как единый и хорошо интегрируемый кусок.

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

Есть еще один нюанс. Помимо барьеров коммуникации, существуют еще «силовые поля», не все команды имеют одинаковую власть: в какой-то команде есть сильный продакт, в какой-то доверие спонсора и т.д. Таким образом, окончательная структура продукта будет отражать не только границы команд; она будет отражать относительное влияние этих команд на релизные циклы. Искусство налаживания партнерских отношений напрямую влияет на конечную архитектуру продукта: 80% деятельности CPO должно быть направлено на выстраивание эффективных процессов взаимодействия.

“Мы не можем сейчас ничего сделать, у нас бэклог расписан на 2 года вперед”. “Я куплю ваш продукт, если только вы добавите функцию X”.

Оба утверждения выше просто убийственны. Одно я услышала от CPO продуктовой команды, второе — от потенциального клиента. Мы добавляем фичу, но они не покупают. Этот замкнутый круг известен как Product Death Cycle. Что происходит после того, как вы найдете product-market fit? Вы переходите от стратегии поиска к стратегии роста и масштабирования бизнеса, от MVP к построению полноценного продукта. И тут возникает ловушка, когда команда пытается усовершенствовать продукт.

Концепция Feature fit была придумана Кейси Винтерсом (Casey Winters), в одной из своих статей он написал:

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

Быть функционально другим недостаточно (“sameness trap"). С помощью новых фич вы можете работать над постепенными улучшениями своего продукта, но не над дифференцированием. Вы можете очень долго заниматься оптимизацией. Например, у вас есть приложение и вы улучшаете процесс регистрации и онбординга. Для этого делаете различные АБ-тесты: изменяете цвета кнопок, текст, графику—в надежде, что это повысит метрики на пару процентов. Как правило, такого рода изменения не представляют реальной ценности для клиентов и имеют очень мало общего с ценностью. Я не против оптимизации как часть growth-экспериментов, я против того, чтобы команда занималась только ей. Она не может заменить реальные инновации. Кроме того любая значимая и популярная функция копируется (если нет «нечестного» преимущества в виде инновационной технологии, но она тоже в конечном итоге скопируется) ,— это феномен жизненного цикла инноваций: любая инновация превращается со временем в commodity:

- Влияет ли данная фича на удержание пользователей? Если да, то что это за пользователи?

- Как я могу сделать эту фичу удобной только для этой категории пользователей? какая существует стратегия адаптации фичи пользователями?

- Как эта фича положительно влияет на удержание, вовлеченность и монетизацию для всего продукта?

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

Как это обычно происходит? Да очень просто. Начинается встреча с руководством. Выступает директор по продажам. Он не может продавать больше, потому что не реализованы функции А и B. Затем выступает ответственный за «счастье клиентов» и говорит, что клиенты жалуются на баги C и D. И т.д. Виноват в итоге продакт-менеджер.

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

Продуктовая стратегия обозначает границы продукта - того, что мы готовы с ним делать, а что нет. При отсутствии стратегии границы становятся размытыми, и любой клиент может попросить о любой новой фиче, и команда может ее пообещать, поскольку мы же "клиентоцентричные" (страх потери ЛЮБОГО клиента превалирует над стратегическими целями).Про что продуктовая стратегия? Она про выбор, но выбор осмысленный, основанный на результатах диагностики вашего продукта с механизмом оценки обратной связи от клиентов.

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

Как создать клиентоцентричный бизнес? Сфокусируйтесь на своем сегменте и поймите его боли. Только так вы сможете перейти от фабрики фич к созданию ценности.

Часто проблема – это следствие несоответствия продакта руководителю/основателю/основному заказчику. Особенно это распространено в стартапах. У основателей есть свое мнение о развитии продукта, и они в целом хотят только его реализации вне зависимости от валидации рынка и т.д. Они хотят, чтобы продакты помогли реализовать это видение в виде ТЗ, и зачастую воспринимают другое мнение как критику. Продакт превращается в аналитика, записывающего идеи и реализующего их в продукте. От такой деятельности приходит усталость, неверие в свои силы и желание соскочить с роли секретаря при "важном человеке".

Есть известная «дилемма ежа», которую приводит в своих книгах Фрейд: человеческие отношения имеют значительную степень амбивалентности: у всех нас есть одновременная потребность в близости и страх перед ней, что создает дилемму. Дистанция, которую ежи в конце концов обнаруживают как единственное приемлемое условие взаимного взаимодействия, представляет собой общий кодекс поведения. Для каждой организации это расстояние между «ежами» уникально: страх делегировать полномочия и потерять контроль укрепляет стереотип героического лидера, однако принятие решения самому может привлечь к непоправимым ошибкам. Проблема в микроменеджменте, а значит в недоверии. Но микроменеджмент не масштабируется. Он создаете бутылочные горлышки в процессах, начиная с малейших изменений в продукте, заканчивая стратегией. Более того обычно никто на самом деле не понимает, что делает/думает руководство и почему.

ЛПР всегда выбирает свой путь в виде приоритетного списка функций или проектов, которые, по его мнению, действительно решат какую-то проблему. Каждый запрос рассматривается как приоритет номер один, и ожидается, что менеджер по продуктам уделит им 100% своего внимания. Это невозможная ситуация для продуктовой команды, которая препятствует масштабированию компании за пределами одного лица, принимающего решения. Соответственно мы приходим к необходимости создания прозрачных процессов и прозрачной приоритезации.

Если вы работаете продактом или CPO в продукте на фазе масштабирования и роста в достаточно зрелой компании, то в один прекрасный момент столкнетесь с тем, что знаний о клиентах, Lean-подходов и спринтов уже недостаточно, чтобы создать успешный продукт. То, что хорошо в данный момент на уровне продуктовой задачи, становится песчинкой в рамках организации. Не знаю, бывало ли у вас чувство, когда кажется, что все реально классно делают свою работу, но пазл не складывается, и результат получается так себе.

При масштабировании и росте причинно-следственные связи становятся сложнее, компании обрастают внутренними барьерами (иногда их называют silos). Вот в этот момент возникает мысль: мы такие неэффективные, потому что мы сфокусировались на execution, у нас неадекватные продакты, нам нужны срочно инновации, давайте мы пригласим кого-нибудь, кто сможет нам рассказать, как делать эти корпоративные инновации, CustDev и и т.п., и мы снова станем супер-гибкими и инновационными. Я сталкивалась с этим подходом уже много раз. После таких тренингов НИЧЕГО не менялось. Во-первых, Lean-методология была придумана для стартапов, и она пропитана их культурой: выйди из здания и т.п. Даже Стив Бланк и Эрик Рис не смогли пока ее адаптировать для корпораций, и они часто про это говорят в интервью. Максимум, до чего дошли: создать или купить внутренний стартап в организации, обособленный от всех. Но это проще сказать, чем сделать так, чтобы его не настигла «корпоративная культура».Во-вторых, может быть дело не в инновациях? Корпорации копируют паттерны стартапов, но не получают результата, кроме постеров на стенах.

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

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

В организациях зачастую отсутствует само понятие продуктовых процессов как функции, необходимой для принятия стратегических решений. Отсюда как следствие непонимание, на какие продукты/процессы и как тратить деньги (90% штата занимается операционкой, а не созданием нового), у всех проблемы с оттоком, как (не создавать!), а развивать свои продукты и делать кросс-сейл эффективно, отсутствие взаимосвязи финансовых показателей компании с показателями продуктов, нужно 15 подписей, чтобы потратить 15 тысяч рублей и т.д. Все это время клиенты и стратегия полностью игнорируются. Пример основан на старой централизованной модели командования и управления. Напротив, в модели продуктовой команды предполагается, что команды должны быть оснащены и наделены полномочиями для определения наилучших способов решения конкретных бизнес-задач. Но для того, чтобы это произошло, недостаточно иметь сильных продактов. Им нужен контекст и стратегия с пониманием общих целей. У каждой команды должен быть четко определенный, приоритетный набор бизнес – целей, связанных со стратегией.

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

Вместо функционального подхода лучше работает подход, основанный на проблемах в формате: "Это бизнес-проблема. Выясните, что нам нужно для этого сделать." (подробнее про этот подход можно почитать у Марти Кагана) Продуктовая команда может в конечном итоге добавить ту же функцию, но даже если они это сделают, разница в том, что если эта функция не сработает в первый раз, а это, скорее всего, не сработает, они знают, что они еще не закончили. Они должны пройти итерацию по этой функции, или попробовать другой подход, или сделать редизайн вместо новой функции, что бы они ни делали.

Спасибо за уделенное время! Какие из этих подходов вам знакомы? Какие антипаттерны вы можете добавить? Поделитесь в комментариях в статье!

Хотите больше статей: подписывайтесь на канал "Strategic Move", на котором делюсь своими заметками на тему стратегии и управления продуктами.