Менеджер продукта vs владелец продукта: навыки и полномочия
Заключительная часть цикла из 4-х статей про менеджера продукта и владельца продукта, которая поможет вам понять ландшафт продуктового менеджмента.
С популярностью Agile-подходов в обиходе менеджмента компаний начали использовать термин владелец продукта. Для многих до сих пор остается загадкой, чем эта новая роль отличается от менеджера продукта. А еще больше путаницы добавляет тот факт, что и product manager и product owner сокращенно называют «продакт».
В этом цикле статей попробуем найти ответы на следующие вопросы:
- Product manager и product owner — это разные роли?
- Кто кому подчиняется?
- У кого больше полномочий и зона ответственности?
Для поиска ответов изучил несколько десятков статей и книг по темам product management и product ownership. В первой части мы рассмотрели историю появления деятельности по управлению продуктом (product management). Во второй части разобрали историю появления и эволюции владельца продукта. Третья часть рассказывает, как меняется роль владельца продукта в зависимости от фреймворка масштабирования Nexus, LeSS и SAFe. В этой статье сравним навыки, полномочия и зоны ответственности product manager и product owner.
Содержание статьи
Предисловие
За три года углубленного изучения данной темы мое отношение к различиям между product owner и product manager менялось несколько раз — от позиции «те же яйца только в профиль» до представления, что это совершенно разные по смыслу роли. На текущий момент свое видение опишу так: если рассматривать продуктовый менеджмент как разделение участников процесса на «богов» и «людей», то владелец продукта это «полубог» или «получеловек», если вам так больше нравится. Надеюсь, у меня получится раскрыть смысл метафоры и донести свою точку зрения, которая, как и любая другая, не является истиной.
При составлении и сравнении навыков менеджера по продукту и владельца продукта опирался на личный опыт и практику взаимодействия с более чем сотней продактов, а также на идеи следующих книг:
INSPIRED: How to Create Tech Products Customers Love
EMPOWERED: Ordinary People, Extraordinary Products
The Product Book: How to Become a Great Product Manager
The Product Manager’s Survival Guide
The Guide to the Product Management and Marketing Body of Knowledge
Product Development and Management Body of Knowledge
The Professional Product Owner: Leveraging Scrum as a Competitive Advantage
Scrum Product Ownership: Balancing Value from the Inside Out
Agile Product Management with Scrum: Creating Products that Customers Love
Для снижение градуса холивара в статье нет разделения навыков на hard и soft. Для термина навык выбрал определение, которое встретил в книге CRAFT/ed:
Навык — алгоритм, последовательность мыслей и действий, который помогает в решении определенных задач.
Открывайте ваши мозговые шлюзы, мы начинаем погружение.
Как развивается менеджер продукта внутри компании
Для начала рассмотрим факт, что внутри компаний существует разделение менеджеров продукта на junior, middle и senior. Также существует разделение продуктовых менеджеров по специализациям, как правило, их называют менеджерами функции: маркетинг, монетизация, дизайн, разработка и т.д. Еще встречал менеджеров по продукту, которые совмещают функциональное и продуктовое лидерство, другими словами, отвечают за часть продукта и выполнение определенных задач внутри функции по другим продуктам или проектам.
Получаем три вектора развития менеджера продукта внутри компании:
1) рост компетенций и полномочий в рамках одного продукта;
2) рост компетенций и полномочий в рамках одной функции;
3) рост компетенций и полномочий в рамках и продукта, и функции.
На графике выше желтым цветом обозначаются позиции downstream (contribution) product management, зеленым стикером — upstream product management. Символ “~” означает, что в некоторых компаниях senior product manager может выполнять задачи product director, а иногда между ними ставят знак равенства. Давайте разбираться в новых понятиях: upstream и downstream product management.
В книге The Guide to the Product Management and Marketing Body of Knowledge продуктовый менеджмент разделяется на два уровня:
Upstream product management отвечает за стратегию, финансы, развитие бизнес-моделей продуктов и направлений, управление портфелем продуктов, запуск новых продуктов, выход на новые рынки, принятие решений об инвестициям в перспективные технологии, компании и т.д. В других источниках данные позиции называют мanagement position: Chief Executive Officer (CEO), Product Lead, Head of Product, VP of Product, Chief Marketing Officer (CMO), Chief Information Officer (CIO), Chief Product Officer (CPO), Chief Technical Officer (CTO, Chief Financial Officer (CFO) и другие C-level позиции. Как вы заметили в эшелоне намешаны топ-позиции на уровне продуктов и функций, что отражает реальность компаний, вспомните хотя бы состав любой из ваших стратегических сессий.
Downstream product management отвечает за реализацию намеченной стратегии, достижение стратегических целей и задач, включает в себя: исследование рынков, разработка и развитие продуктов, улучшение и разработка внутренних систем, улучшение показателей эффективности и т.д. В других источниках данные позиции называют contribution position: Product Manager, Junior Product Manager, Middle Product Manager, Senior Product Manager, Product Marketing Manager, Data/Analytics Product Manager, Product Designer, UI/UX Product Manager, Product Monetization Manager и другие исполнительные позиции на уровне продукта и на уровне функции.
Подводя черту, менеджер по продукту может раскрываться как профессионал, расширяя свои полномочия в рамках одного продукта, так и в пределах одной функции на уровне всей компании, а может и вовсе совмещать оба вектора развития.
Как развивается владелец продукта внутри компании
В отличии от продуктового менеджмента (product management) в области владения продуктом (product ownership) не существует градаций и разделений на junior, middle, senior, так и нет уровней upstream и downstream. Кто-то из читателей, предполагаю, знаком со статьей «Эволюция владельца продукта» от Ron Eringa, где автор раскрывает пять стадий эволюции владельца продукта, начиная от аналитика и заканчивая предпринимателем. Раньше эта концепция мне казалась достаточной, чтобы дать представление о том, как следует развиваться владельцу продукта. Когда впервые познакомился со статьей в 2017 году, у меня сложилось впечатление, а сейчас я понимаю, что это было заблуждение, что можно стартовать scrum с владельцем продукта на любом уровне зрелости, а далее человек как-то будет расти до уровня предпринимателя, главное, предоставлять ему для этого возможности, полномочия и поддержку. Спустя пять лет позиция касательно различных уровней владельца продукта трансформировалась до бинарной: либо у вас есть владелец продукта, либо его нет, а есть продуктовый менеджер, продакт, менеджер по продукту и группа топ-менеджеров управляющая продуктом. Когда консультант начинает занимать бинарную позицию, то клиентам сложно это воспринимать, ведь они заходят в продуктовую и/или agile-трансформацию со сложившейся структурой. Заказчикам хочется понимать, как они могут развить своих текущих проектных и продуктовых менеджеров до владельца продукта. В июне этого года под вдохновившись техникой покер делегирования из Management 3.0 появилась карта оценки зрелости владельца продукта.
Карта состоит из десяти зон ответственности владельца продукта:
- создание product vision;
- формирование product strategy;
- определение product goal;
- развитие бизнес-модели;
- бюджетирование и ROI;
- отстройка маркетинга и продаж;
- определение экономики и монетизации;
- запуск исследований и экспериментов;
- наполнение бэклога продукта;
- приоритизация бэклога продукта.
Каждая зона имеет семь уровней зрелости product ownership, начиная от полного контроля топ-менеджеров и заканчивая полным контролем владельца продукта.
Так мы получаем матрицу 10х7, где владелец продукта отмечает, как сейчас у него обстоят дела с полномочиями и ответственностью в каждой зоне. Подробнее о том, как мы используем данную карту в работе с клиентами, рассказываем на тренинге Владелец продукта: краткий курс выживания.
Карта оказалась удобным инструментом для оценки текущего положения дел и позволяет владельцу продукта понять, в каком направлении ему развиваться. Далее суммируете ваши оценки и получаете текущий уровень зрелости product ownership, но выводы остаются бинарными: либо вы product owner, либо нет.
Еще одно преимущество этой карты заключается в том, что она позволяет вам понять, а кто сейчас в компании выполняет функции владельца продукта. Product owner в компании есть всегда, даже если вы не работаете по scrum и даже об этом никогда не слышали, просто в компаниях это крайне редко оказывается один человек, скорее всего, это группа лиц, подробнее читайте в статье «Как найти владельца продукта в компании». И тут фраза из руководства по scrum «Product owner — это один человек, а не комитет» приобретает вес и начинает играть новыми красками. Следовательно, главная задача компании, перед тем как переходить на scrum или вводить роль владельца продукта, это собрать необходимые полномочия в одном человеке, и тогда у вас появится true product owner.
Полномочия владельца продукта охватывают как upstream product management активности, так и downstream активности. Из чего можем сделать вывод, что это некий гибрид из двух миров продуктового менеджмента, который обладает полномочиями топ-менеджмента и продолжает плотно работать с командой.
Карта навыков product management and product ownership
Изучая литературу и статьи по этой скользкой и липкой теме, заметил, что авторы используют различные глаголы для описания одних и тех же навыков, которые необходимы менеджеру по продукту: set, identify, validate, evaluate, understand, define, create, manage and so on. После анализа, кластеризации и объединения получилось 45 аспектов продуктового менеджмента, которые для простоты восприятия разделил на 6 блоков:
- Manage (управление)
- Create and validate (создание и валидация)
- Identify and testing (выявление и проверка)
- Analyze (анализ)
- Incorporated (личностные)
- Expertise (опыт и экспертиза)
Manage (управление)
В эту категорию попали следующие аспекты:
- product lifecycle: управление жизненным циклом продукта;
- discovery process: управление процессом исследований;
- delivery process: управление процессом реализации;
- budgeting and ROI: управление бюджетом и возвратом инвестиций;
- stakeholder: управление ожиданиями заинтересованных лиц;
- objectives: управление целями;
- scope or product backlog: управление объемом работ;
- roadmap and release: управление релизами;
- customer support: управление клиентской поддержкой;
- public relationship: управление связями с общественностью;
- legal: соблюдение законодательства;
- finance: управление финансовой составляющей.
Create and validate (создание и валидация)
Сюда осели высокоуровневые аспекты продуктового менеджмента:
- mission: нематериальные цели, которые хотим достичь;
- vision: желаемый образ будущего, который хотим достичь;
- strategy: стратегия.
Identify and testing (выявление и проверка)
В этой категории разместились многие хорошо известные вещи:
- market opportunity: возможности на рынке;
- risks: риски;
- competitors: конкуренты;
- target audience: целевая аудитория;
- business model: бизнес-модель;
- market positioning: позиционирование на рынке;
- channels and message: каналы и коммуникация;
- product concept: концепция продукта;
- prototype and MVP: прототипы и ранние версии продукта;
- value proposition: ценностное предложение;
- user experience and design: клиентский опыт и дизайн.
Analyze (анализ)
В блоке анализа разместились:
- trends: анализ трендов;
- business: анализ бизнес-процессов;
- data: анализ данных;
- metrics: анализ метрик;
- market: анализ рынка.
Incorporated (интегрированные в личность)
Самый интересный и трудно прокачиваемый список навыков:
- leadership and motivation: лидерство и мотивация;
- negotiating and collaboration: переговоры и сотрудничество;
- creativity and problem solving: креативность и решение проблем;
- persistent and persuasiveness: настойчивость и убедительность;
- evangelism and influence: евангелизм и влияние;
- being adaptable and flexible: способность к адаптации и гибкости;
- being accountable and making decisions: ответственность и способность принимать решения;
- coaching and mentoring: коучинг и наставничество;
- strategic thinking: стратегическое мышление;
- systemic thinking: системное мышление;
- entrepreneurial thinking: предпринимательских дух.
Expertise (опыт и экспертиза)
И завершает самый явный и понятный блок:
- business domain: бизнес;
- market domain: индустрия;
- technology domain: технологии.
Карта навыков собрана, теперь попробуем понять, какие из них относятся к upstream product management, что попадает в downstream product management, а что находится в зоне product ownership. Напоминаю, что карта не есть территория и, учитывая, что в downstream product management входят десятки функций и как минимум три общепринятых уровня (junior, middle, senior), то вариаций ландшафтов продуктовой функции могут быть сотни. Понимаю, что на развесовку навыков также влияет жизненный цикл продукта, отрасль, тип продукта, бизнес-модель и другие факторы, поэтому рекомендую использовать данный взгляд как отправную точку для построения своих собственных карт.
Как вы заметили, в столбце Product Ownership рядом с надписью «совместно с командой» поставил звездочку, этим хочу подсветить три аспекта:
1) владелец продукта хоть и отвечает за максимизацию ценности продукта, но продукт создается командой или командами, поэтому он активно с ними взаимодействует;
2) чтобы не плодить дополнительную иерархию между собой и командами при столь широкой зоне ответственности владельцу продукта необходимо разделять полномочия с командами;
3) звездочка сообщает о том, что пока команда не будет готова разделять полномочия и ответственность с владельцем продукта, на это время ответственность остается за ним.
Чтобы третий пункт как можно скорее растворился, в scrum есть специальный человек, скрам-мастер, который помогает сбалансировать зоны ответственности продуктовой функции между участниками команды или команд.
Заключение
Подведем итоги ответами на изначальные вопросы исследования:
- Product manager и product owner — это разные роли?
Зависит от того, что вы вкладываете в эти определения. Если вы скажете, что product owner — это product manager, который работает над продуктом, используя scrum, то скорее всего, вы будете правы. И добавлю, что не всякий product manager захочет стать product owner, но многие владельцы продуктов вышли из продуктовых менеджеров.
- Кто кому подчиняется?
Если компания использует true scrum (еще на рынке распространена фраза professional scrum), то между владельцем продукта и топ-менеджментом вряд ли выстроится модель взаимоотношений начальник-подчиненный, скорее это будет напоминать бизнес-партнерство. Если вы используете SAFe®, то там product manager дирижирует командами, к которым приставлены владельцы продуктов, но помните, это fake product owners (подробно это тема разбиралась в третьей части). Если вы используете только роль product owner из scrum, а над продуктом работают несколько команд, то внутри этих команд могут быть менеджеры по продукту разного калибра, которые помогают ему максимизировать ценность продукта, но не называйте это scrum.
- У кого больше полномочий и зона ответственности?
Как вы уже догадались, и тут нет однозначного ответа. Если вы используете professional scrum, то product owner будет иметь больше полномочий над продуктом, чем любой product manager. Если мы рассматриваем различные суррогаты scrum и применение его отдельных частей, то скорее всего, это будет upstream product manager.
На этом мы заканчиваем рассматривать многогранный product management и таинственный product ownership. Надеюсь, вы не потерялись в волнах рассуждений и у вас получилось сформировать свой более целостный взгляд на данную тему.
Подключайтесь к Telegram-каналу, где мы делимся интеллектуальными сладостями на тему product management и product ownership.
Хочу рассказать вам о методе Бережливого планирования продуктов и месте, которое он занимает в современной деятельности по созданию технически сложных и комплексных продуктов, таких как беспилотный автомобиль, аэротакси или современные космические ракеты. А заодно порассуждать, почему некоторые технологические стартапы превращаются в глобальные корпорации, как например Tesla, а некоторые входят в анналы истории как имена нарицательные для обозначения кринжовых концепций и безумных проектов, например как ё-Мобиль.
Что такое минимально жизнеспособный продукт (MVP)? Почему MVP так важен в процессе разработки и как его эффективно использовать? В этой статье ответим на все эти вопросы и посмотрим примеры самых узнаваемых брендов, история которых начиналась с MVP.
Обсудим, как написать хорошую User Story, какие существуют паттерны декомпозиции пользовательских историй, как их использовать и главное — зачем на самом деле декомпозиция нужна команде.