Продакт-менеджмент в ИТ и «неИТ»: в чем корень различий
За последний десяток лет функция продакт-менеджера (PM, Product Manager) получила свое распространение далеко за пределами ИТ-индустрии. Позиции PM открываются во многих индустриях, где технологии играют существенную роль - в банках (особенно розничных), торговых и логистических компаниях и т. д. В компаниях из этих секторов рынка много внимания уделяют разработке собственных ИТ-продуктов и, соответственно, им необходимы собственные PM.
При этом функции продакт-менеджеров в технологических и нетехнологических компаниях существенно отличаются, так как отличается подход к разработке приложений. Вот основные различия в подходах, их достоинства и недостатки.
Оргструктура
Технологические компании, как правило, имеют продуктоцентричную организационную структуру (product-centric), то есть команды создаются вокруг определенного продукта или продуктовой области внутри компании. Таким образом, цели и ответственность продуктовой команды напрямую связаны с успехом вверенного им продукта в долгосрочной перспективе. Это неудивительно - ИТ-продукт и есть главный продукт такой компании.
В компаниях нетехнологического профиля часто встречается проектно-ориентированную модель, когда команду программистов и продактов привлекают на проектные инициативы с четко определенными датами. Что тоже понятно: она должна дать продукт для обеспечения потребностей основного бизнеса.
Определение ролей
В технологических компаниях при создании продуктов, как правило, нет необходимости формализовывать роли участников команды: согласно Agile-манифесту, качество продуктов в гораздо большей степени определяется взаимодействием между людьми, нежели формализованными процессами.
В нетехнологических организациях с укоренившимися практиками проектного управления есть «привычка» документировать роли и зоны ответственности, например, используя метод RACI (матрица распределения ответственности: Responsible, Accountable, Consulted, Informed). Подобный подход не соответствует современным практикам разработки по двум причинам. Во-первых, сильные продуктовые команды имеют способность к самоорганизации и тогда распределение обязанностей либо становится очевидным, либо претерпевает изменения. Во-вторых, ответственность за конечный результат в любом случае несет продакт-менеджер, и попытки формально разделять ее среди участников команды (разработчиков, дизайнеров, и т.д.) могут привести только к ненужным спорам.
Определение целей и ключевых результатов
В технологических компаниях распространена методология OKR (Objectives and Key Results), которая предполагает, что успех команды оценивается исходя из бизнес-результатов. В нетехнологических компания зачастую такие подходы используются довольно формально или не используются вовсе. В отсутствие OKR цели продуктовым командам устанавливаются традиционным способом - «запуск или внедрение такой-то функциональности к такой-то дате». Основная проблема такого подхода заключается в том, что цели продуктовой команды могут расходиться с целями компании, например, функциональность создана, но при этом желаемые бизнес-результаты не достигнуты.
Основное преимущество метода OKR заключается в том, что он обеспечивает значительную свободу действий для команды, которая должна определить и построить наиболее эффективное решение для поставленной бизнесом задачи. В этом случае фокус дискуссий с бизнесом сдвигается от обсуждения той или иной продуктовой функциональности к обсуждению ее влияния на метрики роста. Таким образом, продуктовая команда имеет повышенную мотивацию за счет творческой свободы в поиске решений, но при этом отвечает за конкретный бизнес-результат, предусмотренный OKR.
Основными недостатками (точнее, сложностями в реализации) данного метода является необходимость в согласовании установленных целей между командами или подразделениями компании. Особенно затратным этот процесс может быть в компаниях со сложной организационной структурой и множеством продуктов и сегментов пользователей. Необходимо помнить, что конечная цель OKR заключается в создании общего понимания контекста, задач и приоритетов. Поэтому в случаях, когда использование методологии ограничивается формальным заполнением громоздких, едва читаемых эксель-таблиц с целевыми показателями, организация должна пересматривать свой подход.
Важно отметить, что OKR определяются на уровне организации, подразделения или команды, но использовать OKR для постановки индивидуальных целей не рекомендуется. Основное предназначение метода состоит в том, чтобы создать фокус на тех задачах, которые дадут максимальный результат для бизнеса, а для оценки работы персонала в ходе их выполнения используются иные подходы и решения.
Продуктовые стратегии и диалог с бизнесом
В технологических компаниях с сильной продуктовой культурой продакт-менеджер стремится к тому, чтобы договоренности с бизнесом формулировались в терминах бизнес-задач (например, повышение конверсии переходов или снижение времени на отклик на запрос клиента). Такой подход означает, что продуктовая команда будет замотивирована с помощью экспериментов и итераций построить именно то решение, которое будет действительно эффективно.
В нетехнологических компаниях функционал определяется в начале разработки и документируется с помощью технического задания, что может явным или неявным образом ограничивать «пространство для маневров» для продуктовой команды. И дело здесь не только в документации - у участников команды подсознательно возникает обязательство перед бизнесом или руководством осуществить запуск нужного функционала в оговоренный срок, и любое отклонение воспринимается как неудача.
Данный подход может иметь негативные последствия, ведь если функционал продукта не тестируется в реальных условиях и не претерпевает изменений на основе обратной связи от пользователей, существенно повышаются риски коммерческой несостоятельности продукта.
Итак, качественная продуктовая стратегия должна быть сформулирована в терминах бизнес-целей или задач, для которых необходимо найти решения. Такой подход предполагает определенную свободу и дает продуктовым командам стимул для поиска наиболее эффективного решения с помощью экспериментов и итераций. Тем не менее, в ряде случаев в продуктовой стратегии вполне уместно указывать конкретное функциональное решение, например, когда команда уже провела необходимое тестирование и готова переходить к его внедрению.
Компании, которые до сих пор формируют свои продуктовые планы и стратегии с точки зрения фиксированного функционала, должны задуматься о пересмотре подходов. В компаниях с традиционным, проектоориентрованным подходом такой переход тяжело будет произвести в одночасье. Рекомендация для продакт-менеджеров в этом случае состоит в ведении диалога с бизнесом и поэтапным переходом от функциональных планов к целевым. Например, в качестве эксперимента можно добавить несколько бизнес-целей в продуктовую дорожную карту с тем, чтобы руководство постепенно начало «привыкать» к данному подходу и осознавать его преимущество, и с большей открытостью отнеслось к внедрению продуктовых стратегий нового типа.