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

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

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

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

Так как такие продакты не сосредоточены на "почему", они, как правило, сосредотачиваются на "когда". Соответственно основной показатель эффективности работы – СРОКИ, фактически выраженные в человеко-часах.

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

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

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

Тут можно вспомнить знаменитый цикл Gartner, поясняющий эту проблему:

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

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

"Наш продукт прекрасен, вы просто не умеете его рекламировать"

"Мы профессионалы в маркетинге. Сделайте нормальный продукт, который можно продать."

Знакомо?

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

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

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

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

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

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

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



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

Искусство налаживания партнерских отношений напрямую влияет на конечную архитектуру продукта: 80% деятельности CPO должно быть направлено на выстраивание эффективных процессов взаимодействия.

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

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

Что происходит после того, как вы найдете product-market fit? Вы переходите от стратегии поиска к стратегии роста и масштабирования бизнеса, от MVP к построению полноценного продукта. И тут возникает ловушка, когда команда пытается усовершенствовать продукт.

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

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

Кроме того любая значимая и популярная функция копируется (если нет «нечестного» преимущества в виде инновационной технологии, но она тоже в конечном итоге скопируется) ,— это феномен жизненного цикла инноваций: любая инновация превращается со временем в commodity.

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

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

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

Продуктовая стратегия обозначает границы продукта - того, что мы готовы с ним делать, а что нет.

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

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

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

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

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

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

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

Соответственно мы приходим к необходимости создания прозрачных процессов и прозрачной приоритезации.

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

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

Пример основан на старой централизованной модели командования и управления. Напротив, в модели продуктовой команды предполагается, что команды должны быть оснащены и наделены полномочиями для определения наилучших способов решения конкретных бизнес-задач. Но для того, чтобы это произошло, недостаточно иметь сильных продактов. Им нужен контекст и стратегия с пониманием общих целей. У каждой команды должен быть четко определенный, приоритетный набор бизнес – целей, связанных со стратегией. Мне близка концепция OKR, хотя она, конечно, не всегда применима: скажите команде, что вам нужно, чтобы они выполнили, и как будут измеряться результаты, и пусть команда придумает лучший способ решения проблем.

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

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