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