Эта статья наверняка огорчит многих.
Я сожалею об этом, но ситуация с постоянным шумом и путаницей вокруг роли продукта в технологических компаниях становится только хуже. Более того, я вижу, как противоречивые и проблемные модели поведения становятся официально принятыми на конференциях, в программах обучения и так называемых сертификационных программах для специалистов по продукту.
В прошлом я уже несколько раз говорил об этом, в частности, в статье и основном докладе «Продуктовые команды, наделенные полномочиями». Однако многие люди услышали в них только то, что захотели, и мне стало ясно — нужно быть более категоричным.
Итак, хотя ощущение от информации, полученной после прочтения этой статьи, возможно, будет для вас не совсем приятное, но если вы разочаровались в противоречивых и запутанных сообщениях людей из мира продукта, то еще немного потерпите, и тогда, я надеюсь, она внесет столь необходимую ясность.
Условно говоря, в мире технологий существует три различных типа «продуктовых команд».
Наиболее распространенные с точки зрения численности — это не совсем продуктовые, а деливери-команды. Деятельность таких команд направлена на разработку, отладку, тестирование и доставку продукта/решения до клиента. Их также называют «командами разработки», «scrum-командами» или «инженерными командами», и если ваша компания использует что-то вроде SAFe (Scaled Agile Framework — масштабированный гибкий фреймворк), то, к сожалению, это именно вы. Обычно здесь есть некоторое количество разработчиков и владелец продукта. Владелец продукта в этой модели — это то, что я называю «администратор бэклога». Кто-то должен выполнять такую административную работу, но это все о предоставлении результатов, и в действительности имеет очень мало общего с тем, что меня волнует с точки зрения необходимости реализации истинных, последовательных инноваций от имени наших клиентов. Я уже писал в другом месте о том, почему эта модель на самом деле является просто измененной каскадной моделью (waterfall — водопад) и не используется в настоящих компаниях, производящих технологические продукты. Так что давайте разберемся с этим.
Эта статья посвящена разнице между двумя другими типами команд.
Сразу предупреждаю, что я собираюсь ввести нестандартную и, конечно же, не согласованную номенклатуру. Но я должен это сделать, потому что сегодня в отрасли мы называем оба других типа команд «продуктовыми командами» или «сквадами» (squad — отряд). Но, несмотря на то, что внешне они похожи, на самом деле существуют значительные различия, особенно когда мы говорим о роли продакт-менеджера.
Когда я писал о достоинствах продуктовых команд, наделенных полномочиями, то подразумевал именно то, что здесь я буду называть продуктовыми командами. В частности, они являются межфункциональными (продукт, дизайн и проектирование); их работа сосредоточена на конкретных результатах (а не на простом выводе информации) и оценивается по ним; они наделены полномочиями для поиска наилучшего способа решения проблем, которые их попросили устранить.
Цель продуктовой команды в данном смысле — разрешать проблемы так, чтобы это нравилось нашим клиентам и одновременно работало на наш бизнес.
Как бы мне ни хотелось обратного, я знаю, что лишь небольшой процент команд является продуктовыми командами в таком понимании.
Гораздо чаще такие команды вообще не наделены полномочиями. Напротив, они существуют лишь для того, чтобы обслуживать бизнес.
В статье этот третий класс буду называть фиче-командами. Здесь я немного отклоняюсь от наиболее устоявшегося определения фиче-команд, но применяю этот термин, потому что он помогает подчеркнуть, что для таких команд главное — результат. Это фичи (возможности), а иногда и проекты. Обычно они предоставляются команде в виде списка приоритетов, который называется дорожной картой.
Но вот здесь мне нужно углубиться.
Вспомните, что в продукте всегда присутствуют четыре риска:
Риск ценности (купят ли люди его или решат использовать?)
Риск удобства использования (юзабилити) (смогут ли пользователи понять, как его использовать?)
Риск осуществимости (сможем ли мы создать его с имеющимися у нас временем, навыками и технологиями?)
Риск коммерческой жизнеспособности (будет ли это решение работать в различных аспектах нашего бизнеса?).
В продуктовой команде, наделенной полномочиями, продакт-менеджер несет прямую ответственность за обеспечение ценности и жизнеспособности, проектировщик — за обеспечение удобства использования, а техлид — за обеспечение осуществимости. Команда достигает этого благодаря настоящему интенсивному сотрудничеству путем взаимного обмена мнениями, чтобы найти решение, которое работает для нас всех.
Когда я говорю и пишу о том, как трудно быть настоящим продакт-менеджером в продуктовой команде, наделенной полномочиями, это связано именно с тем, что очень трудно обеспечить ценность и жизнеспособность. Если вам кажется, что сделать это легко, пожалуйста, прочтите это.
Однако в фиче-команде у вас все еще (надеюсь) есть проектировщик, который обеспечивает юзабилити, и инженеры, отвечающие за осуществимость, но, и это очень важно понять: за ценность и жизнеспособность в бизнесе отвечает стейкхолдер или руководитель, попросивший включить фичу в дорожную карту.
Раз они говорят, что им нужно, чтобы вы создали фичу x, значит, они верят, с ее помощью будет достигнута определенная ценность, и полагают, эта фича x окажется коммерчески жизнеспособной.
Стоит отметить, что даже если стейкхолдер является тем, кто несет косвенную ответственность за ценность и жизнеспособность, он все равно найдет способ обвинить вас и вашу команду, если ожидаемые им результаты не будут реализованы. Это заняло слишком много времени, дизайн был плохим, критические возможности пришлось сокращать, чтобы уложиться в срок, и т.д. И, конечно, ваша команда, вероятно, никогда не была убеждена в том, что это вообще стоило создавать. Это старая песня, и я подробно писал об этой проблеме.
На первый взгляд, фиче-команда и настоящая продуктовая команда с широкими полномочиями — обе те же самые сквады. Они похожи, но различия между ними очень глубоки.
Начнем с роли продакт-менеджера. В продуктовой команде, наделенной полномочиями, где продакт-менеджер должен обеспечить ценность и жизнеспособность, глубокое понимание клиента, данных, отрасли и особенно вашего бизнеса (продажи, маркетинг, финансы, поддержка, юридические вопросы и т.д.) безусловно не подлежит обсуждению и является необходимым.
Однако в фиче-команде эти знания, в лучшем случае, рассредоточены среди стейкхолдеров.
В любом случае, надеюсь, понятно, что обязанности продакт-менеджера при такой модели сильно отличаются от фиче-команды.
Работа продакт-менеджера в фиче-команде чаще всего описывается как роль фасилитатора, «пасущего кошек» [когда речь идет о задаче организовать не поддающуюся управлению группу людей] для того, чтобы фича была разработана и доставлена, или как некая неопределенная и слабая форма межфункционального лидера, который на самом деле не отвечает ни за что конкретное. Такие фиче-команды часто думают, что они занимаются изучением продукта, но на самом деле это просто дизайн и, возможно, небольшое тестирование юзабилити.
Но есть и другие результаты влияния фиче-команды на роль продакт-менеджера.
Поскольку команда не наделена полномочиями (точнее, когда вам дают задание обеспечить результат, а вы не наделены никакими значительными полномочиями), очень трудно привлечь и удержать настоящих продуктовых дизайнеров (тех, кто обладает навыками проектирования услуг, дизайна взаимодействия, наглядного дизайна и исследования пользовательской аудитории).
В подавляющем большинстве случаев, когда у вас есть фиче-команды, дизайнер (если он есть) — это дизайнер-график. Не то чтобы графический или визуальный дизайн не важен, но здесь главное то, что возникает большой пробел — кто-то должен разработать хотя бы дизайн взаимодействия и, надеюсь, провести исследование пользовательской аудитории. Поэтому в такой модели очень часто возникает избыточное давление на продакт-менеджера с целью восполнить эти пробелы.
Есть и дополнительные негативные последствия такой ситуации, поскольку несложно изучить инструменты, которые используют дизайнеры, но трудно научиться делать хороший дизайн и проводить исследования пользовательской аудитории. К сожалению, многие продакт-менеджеры никогда не имели возможности работать с настоящим, профессиональным дизайнером, поэтому они даже не предполагают, что именно упускают.
Если вам посчастливилось иметь в своей команде настоящего продуктового дизайнера (по крайней мере, до тех пор, пока он не уйдет в компанию, где его навыки могут быть использованы в полной мере), то обычно (и вполне справедливо) он задается вопросом о функции продакт-менеджера, поскольку для него не составит труда взять на себя дополнительные обязанности продакт-менеджера фиче-команды, так как основную часть его работы он все равно выполняет.
В результате в фиче-командах работа продакт-менеджера сводится в основном к роли менеджера проекта и частично (неквалифицированного) дизайнера.
Часто возникает аналогичное разочарование и в отношении инженеров. Продакт-менеджер, который на самом деле является менеджером проекта, часто расходится с мнением инженеров о том, как они должны работать. Не говоря уже о том, что в этой модели инженеры занимаются доставкой, и, как я уже много раз говорил, если это так, то мы получаем только половину их реальной ценности (поэтому, опять же, хорошие инженеры захотят уйти и присоединиться к продуктовой команде, наделенной широкими полномочиями, где они смогут по-настоящему заниматься своим ремеслом).
Поэтому, чтобы подвести итог по столь важному вопросу, когда я пишу, что продакт-менеджер должен «быть одним из самых сильных талантов в компании», и «генеральный директор должен рассматривать продакт-менеджеров как потенциальных будущих лидеров компании», и «сильный продакт-менеджер — это генеральный директор продукта», я определенно не имею в виду продакт-менеджера в фиче-команде.
Надеюсь, на данный момент вы уже поняли, работаете ли вы в модели фиче-команды или в модели продуктовой команды, наделенной расширенными полномочиями. Тем не менее, я узнал, что люди часто очень неохотно признаются, когда они работают в модели фиче-команды.
Вот несколько тестов, которые вы можете применить к своей команде:
Предоставляются ли вам дорожные карты с приоритетными фичами и датами, или же вам поручают решать проблемы с результатами бизнес-деятельности?
Есть ли путаница в ролях между вами и вашим дизайнером?
Есть ли путаница в ролях между вами и вашим деливери-менеджером?
Проводите ли вы большую часть своего дня, занимаясь управлением проектами?
Пробовали ли вы использовать методику OKR [Objective & key results — цели и ключевые результаты], и что из этого вышло — отбраковка в конечном итоге, или искусственный мэшап из результатов и реализованных фич?
Есть ли у вас команда миссионеров или наемников?
Каков уровень подотчетности?
Я могу сказать, что, за редким исключением, лучшие продуктовые команды в лучших компаниях придерживаются модели продуктовой команды, наделенной полномочиями. Однако я признаю, что даже в тех компаниях, которые я считаю лучшими, не все продуктовые команды наделены полномочиями. По правде говоря, некоторые из них являются фиче-командами. Обычно это происходит потому, что руководство еще не доверяет этой конкретной команде. Иногда такое доверие нужно сначала заслужить. А иногда проблема в том, что лидер хочет диктовать решения.
Я никогда не пытался скрыть свое предпочтение в пользу действительно наделенных полномочиями продуктовых команд. Но считаю, что сейчас мне нужно пойти дальше, чем просто выступать за команды, наделенные полномочиями; необходимо рассказать о фиче-командах, проблемах, которые они создают, и плохих результатах, выдаваемых ими.
Сегодня бесчисленное множество компаний осознают бесполезность модели деливери-команды и знают, что им нужно трансформироваться в настоящую, работающую на технологиях продуктовую компанию. Однако они думают, что могут всего лишь «поставить галочку», сделав поверхностные изменения для перехода к таким фиче-командам.
В заключение я хочу подчеркнуть разницу между продакт-менеджером в фиче-команде и продуктовой команде, наделенной полномочиями. Это совершенно разная работа, требующая совсем другого набора навыков. Возможно, их даже не следует обозначать как одну и ту же должность.
Меня печалит тот факт, что так много дизайнеров и инженеров никогда не сталкивались с настоящим продакт-менеджером и не имели возможности работать в команде с действительно широкими полномочиями. Вот почему я утверждаю, что существует так много недоиспользованных талантов, и почему продолжаю убеждать людей попробовать работать так, как это делают лучшие компании.
Одна вещь, которую вы сможете выполнить уже сейчас, заключается в том, что в следующий раз, когда будете читать статью или твит, присутствовать на конференции или посещать тренинг по продукту — это сделать вывод, говорит ли автор, докладчик или тренер о модели продуктовой команды, наделенной расширенными полномочиями, или о же модели фиче-команды?
Сегодня вечером пройдет открытый урок «Целеполагание, годовые планы и ОКР», на котором участники обсудят темы:
- подход ОКР и ограничения его применения,
- как свести планы на год, как ставить цели,
- как выявлять и разрешать кросс-зависимости.
Записаться можно на странице курса "Senior Product Manager".
