Что такое ProductOps и ProductOps-менеджер?

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

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

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

При масштабировании и росте причинно-следственные связи становятся сложнее, компании обрастают внутренними барьерами (иногда их называют silos).

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

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

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

Вот в этот момент возникает мысль: мы такие неэффективные, потому что мы сфокусировались на execution, у нас неадекватные продакты, нам нужны срочно инновации, давайте мы пригласим кого-нибудь, кто сможет нам рассказать, как делать эти корпоративные инновации, CustDev и и т.п., и мы снова станем супер-гибкими и инновационными. Я сталкивалась с этим подходом уже много раз. Но после таких тренингов НИЧЕГО не менялось.

Во-первых, Lean-методология была придумана для стартапов, и она пропитана их культурой: выйди из здания и т.п. Даже Стив Бланк и Эрик Рис не смогли пока ее адаптировать для корпораций, и они часто про это говорят в интервью. Максимум, до чего дошли: создать или купить внутренний стартап в организации, обособленный от всех. Но это проще сказать, чем сделать так, чтобы его не настигла «корпоративная культура».

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

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

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

Исторически считается, что 80% деятельности CPO должно быть направлено на выстраивание эффективных процессов взаимодействия. Однако когда у вас в компании 2-3 продуктовых команды, обычно с координацией не возникает проблем. Как только количество ваших команд разрастается, становится сложнее соблюдать баланс между централизацией и децентрализацией управления. Казалось бы, давайте мы создадим единый центр, куда будет стекаться вся информация: кто что делаем, какие есть проблемы и т.д. Но такой подход быстро превратит этот центр – в бутылочное горлышко (поэтому я так не люблю «проектные офисы», «офисы трансформации» и «какие-либо офисы» вообще). С другой стороны, мы можем дать командам полную свободу в принятии решений (см. мой пост выше) – наделить их автономностью. Но и тут есть ограничения в части мышления, компетенций и др.

Поэтому вся «продуктовая операционка» должна как-то эффективно управляться как CPO, так и внутри команд, то есть продуктовые процессы тоже требуют оптимизации. Обычно так говорят про процессы разработки, поэтому появились новые роли «Agile-коуч» и «Scrum-мастер». Так как в продуктовом менеджменте еще нет какого-то «золотого стандарта», но думаю, что скоро что-то такое придумают, то многие компании действуют по наитию.

Итак, встречайте новая роль – ProductOps – менеджер😊. Понятно, что сейчас многим кажется, что создание отдельной роли для всего этого – это избыточно. Я уже слышу: “Подождите, вы собираетесь нанять кого-то, кто будет работать с менеджерами по продуктам, которых и так много, но сам не будет менеджером по продукту? Что тогда он будет делать?”

Что он делает (как мне кажется):

Конкретные обязанности ProductOps также могут сильно отличаться в разных организациях, в зависимости от того, что наиболее важно для бизнеса. Другие компании могут рассматривать это как набор навыков, которые может (и должен) оттачивать продакт-менеджер, а не как отдельную роль.

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

Полезные ссылки:

Спасибо за уделенное время! А вы считаете, что будет будущее у новой роли? Поделитесь в комментариях в статье!

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