Product Operations — что это такое и куда движется мир продуктовых специальностей? (Илья Трегубов)

Илья Трегубов, Head of Product Operations, PandaDoc

Сегодня мы поговорим о том, что же такое Product Operations, когда компаниям стоит задумываться о том, чтобы внедрять более системный, структурный продуктовый подход, что происходит с продуктовыми профессиями и как вообще появился Product Ops. Здесь больше мой взгляд. Из чего состоит Product Operations с примерами и как же построить Product Ops.

Что же такое Product Ops? Это, по сути, операционное направление, которое занимается созданием среды для системной, прозрачной и результативной работы продуктовой команды. То есть это некий внутренний сервис, который позволяет всем остальным продуктовым ребятам быть более эффективными в работе.

Когда же компании стоит задумываться о более системном, структурном продуктовом подходе? На мой взгляд, когда компания находится на стадии Problem-Solution Fit. По сути, это обычно еще не компания, это поиск валидной гипотезы. Здесь не нужна такая продуманная operations. Все, что нужно, — это очень быстрая проверка гипотез, большая возможность экспериментировать. И здесь как раз таки системные подходы могут даже убивать, потому что нужно больше креатива, экспериментов и т. д.

На стадии Product-Market Fit, когда у нас уже есть продукт и мы пытаемся правильно найти под него рынок, здесь уже… Тут мне нравится слово «промассировать». Здесь нужно промассировать тему того, насколько системные подходы могут помочь. К примеру, более структурированная работа с гипотезами, их приоритизация и работа с обратной связью — уже может хорошо лечь.

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

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

И когда у вас уже много стримов и больше восьми продакт-менеджеров (к примеру, в Panda у нас уже примерно 17 или 18 человек), конечно, без отдельного operations, на мой взгляд, уже не обойтись.

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

Какие основные признаки того, что пора внедрять Product Ops в компании?

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

Все ответственны за всё. Это значит, что никто не ответственен ни за что в команде.

Чтобы найти важную инфу, нужно написать куче людей.

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

Стратегия в целом не связана с повседневными задачами. То есть эта связка от того, что мы поставили на уровень компании, к тому, что делает конкретная команда, конкретный PM, отсутствует.

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

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

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

Теперь шагнем немножечко в историю, про то, как вообще появился, на мой взгляд, Product Ops. И шагнем в далекие 2000-е.

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

Тогда же примерно и набрал популярность PMBOK (The Project Management Body of Knowledge) и вместе с ним большое количество проджектовых сертификаций: PMI, PMP, Program Management, Portfolio Management, аналитика и т. д.

Где-то к 2005 году начали набирать движение Agile и Lean в IT-кругах. Потихонечку докатилось также до СНГ.

В 2010-м уже пошла тема того, что продукт — основная часть продуктовой компании. Все стали делать Customer Development, по Стиву Бланку тогда еще. И в целом появилась такая специализация, особенно в СНГ пришла потихонечку, как Product Management.

И где-то, по моим ощущениям, в 2017 году уже рынок захлестнула волна продуктовых трансформаций компаний, которые не считали себя продуктовыми. К примеру, те же банкинги. Они все стали IT-компаниями и продуктовыми IT-компаниями. И, по сути, продукт начал править бал.

Продуктовым стало практически всё. Но что важно — что старые процессные подходы и PMBOK уже не особо работают, а новые для продуктовых компаний еще не переосмыслены. Так, на мой взгляд, и появился Product Ops, который как раз призван помочь решить эту проблему.

Давайте еще раз копнем историю немножечко с другой стороны. Изначально компании строились как набор функциональных направлений. Был CEO, который управляет, или VP of Product и различные функциональные направления: Project Management, Design, Development, Business-аналитика, Marketing и т. д. При этом CEO, по сути, были лидеры, визионеры, коммуникаторы, и за функциональную специализацию отвечали разные направления, которые реализовывали видение основателя компании.

Постепенно, когда пришел продукт, Project Management потихонечку начал смещаться, и часть функций стали внутри продукта: дизайн, разработка и аналитика. При этом маркетинг долгое время был в стороне, но сейчас и маркетинг стал продуктовым маркетингом. И даже разработка постепенно превратилась в продуктовую инженерию. Тем самым Product Management теперь стал больше как лидерская и визионерская роль. А все внутри продукта — дизайнеры, аналитики, инженеры — по сути, это как PM’ы, которые были раньше, но с более узкой и глубокой функциональной специализацией.

Дело в том, что, когда таких небольших самостоятельных единиц стало много, между ними стало производиться очень большое количество разных взаимодействий. При этом им же нужно еще поддерживать связь с топ-менеджментом, с CEO и т. д. Тогда здесь сейчас уже начинают зарождаться новые роли, такие, как Product Enablement, Product Intelligence. Product Enablement — это коммуникация с другими частями компании. Product Intelligence — это работа с данными, аналитикой, research и взаимосвязями между всем вот этим. И Product Operations — это как раз про ту самую среду взаимодействия всего вот этого.

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

Если говорить чуть более детально, то это процессы, которые не раздувают бюрократию. Это подход Single Source of Truth, о котором я тоже поговорю чуть-чуть. Это прозрачная и четкая связь от стратегии компании к инициативам и гипотезам. Это связь данных и исследований для принятия продуктовых решений. Это все, что касается роста, грейдинг, шеринг знаний.

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

В качестве примера я хотел бы погрузиться в подход Single Source of Truth. Потому что всё это не покрыть за короткий доклад, но эту конкретную вещь хотелось бы покрыть глубже.

Что же это такое? Когда у нас происходит вот это сложное взаимодействие большого количества людей, в основном время до получения знаний достаточно сильно растет. При этом также растет и риск ошибки вследствие того, что мы обращаемся к неактуальной информации. Подход Single Source of Truth говорит о том, что помимо того, что люди коммуницируют между собой для решения непосредственно задач, для работы с информацией они коммуницируют с единой системой. И эта единая система позволяет всегда поддерживать единое хранилище актуального состояния рабочих изменений.

К примеру с OKR’ами. У нас в Panda заведено отдельное представление для всех OKR’ов продуктовой части компании. Всегда можно посмотреть, что в каком статусе находится, и посмотреть, что именно случилось за последние обновления две недели назад. Соответственно, можно в любой момент считывать то, что происходит в компании по OKR’ам. То же самое с инициативами: посмотреть, кто за что ответственный, в какой стадии инициатива, к какому OKR привязана. И еще у нас там много различных информационных колоночек, которые позволяют как раз полностью считать всё, что нужно для конкретной инициативы, а также пошарить это с другими частями компании.

Single Source of Truth пересекается еще с так называемыми «невидимыми» процессами, о которых я говорил. И здесь, как пример, у нас компании внедрена такая штука, как IRD (это Initiative Requirements Document), когда по инициативе (мы так называем любую фичу или изменение в продукте) всё собирается в одном месте. Создается документ (мы используем Coda, чуть позже тоже о ней скажу), который состоит из основных четырех разделов. После короткого питча это разделы Problem Discovery, Solution Design, Delivery и Go to Market. И всё, что касается конкретной инициативы, можно найти в этом одном документе. Он всегда поддерживается и в течение работы всегда актуален. Там, к примеру, был Pitch. И пример Problem Discovery, где мы описываем проблему, где выкладываем данные research с шаблонами и т. д. Это позволяет всем оперировать одним и тем же набором шаблонов.

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

На примере Single Source of Truth. Изначально мы хотели понять, что за сущности есть, которыми мы оперируем, для того чтобы сделать более прозрачной работу для всех команд. У нас есть уровень стратегии, это ключевые стратегические ставки. Есть уровень OKR’ов — все Objectives и Key Results продуктовые на уровне компании. Есть инициативы — все фичи и субпродукты продуктовой команды. И непосредственно люди и команды внутри продукта.

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

После этого начинаем строить различные отображения. И это, опять же, те самые «невидимые» процессы. У нас есть timeline от годовой стратегии до недельных продуктовых обновлений, и можно посмотреть все разные срезы того, как мы работаем. То же самое по конкретной инициативе. Есть те самые фазы, которые позволяют посмотреть, что в какой фазе было сделано по инициативе.

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

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

Напоследок хотел бы обратить еще раз внимание на то, что всё циклично. И если в начале я показывал визуализацию того, что CEO управляли функциональными направлениями, тем самым сами были лидерами, визионерами и комментаторами, то постепенно мы пришли к тому, что продакт-менеджеры — это те самые лидеры, визионеры и коммуникаторы, их задача — принимать важные решения внутри. При этом та самая специализация, теперь уже не совсем функциональная, а продуктово-функциональная, она ушла внутрь этих командочек рядом с продакт-менеджерами. Но после этого еще появились действительно функциональные специализации, и это те самые продуктовые функции, как я говорил: Product Operations, Product Operation, Product Enablement и т. д.

Что будет дальше? У меня есть на этот счет разные мысли, но какой будет следующая итерация — я буду рад обсудить с вами в кулуарах. Спасибо вам. На этом всё.