Product Management без ошибок. Гид по созданию, управлению и успешному запуску продукта - страница 15

Ник сидел и вникал в происходящее.

– Я хочу добиться успеха. Скажите, что нужно сделать, чтобы стать лучше и создавать крутые продукты.

– Начни прислушиваться к своей команде. Вовлекай их. Слушай своих клиентов и фокусируйся на их проблемах, а не на собственных решениях. Влюбись в эти проблемы. Ищи данные для доказательства и подтверждения своих идей. Обращайся к конкретным доказательствам, а не к мнениям.

Ник принял совет близко к сердцу, и мы вместе разработали подход. Он начал с привлечения команды, проведя мозговой штурм. В течение месяца мнение сотрудников о Нике начало меняться в лучшую сторону. Он слушал их, спрашивал мнение и выражал благодарность. Ему еще предстояло завоевать их доверие, но он определенно двигался в правильном направлении.

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

«Официант» – это менеджер по продукту, который в душе является исполнителем. Такие люди приходят к заинтересованным сторонам, клиентам или менеджерам, спрашивают, чего те хотят, и превращают желания в список вещей, которые необходимо разработать. Здесь нет цели. Нет концепции. Нет принятия решений. Такой архетип встречался у 90 % владельцев продукта в Marquetly.

Самый распространенный вопрос, который я получаю от продакт-менеджеров, находящихся в таком положении, звучит так: «Как мне расставить приоритеты?» Поскольку у них нет цели, способной обеспечить контекст для компромиссов, это превращается в некий конкурс. Чаще всего приоритет получает самый главный человек. Такое часто случается в очень крупных компаниях. Менеджеры по продукту с самыми благими намерениями отправляются поговорить с клиентами и узнать, чего они хотят. Но вместо того чтобы обнаружить проблемы, менеджеры спрашивают: «Чего вы хотите?» Клиент просит конкретное решение, а менеджеры его реализуют. Именно здесь вы попадаете в то, что мой друг Дэвид Блэнд, советник и консультант по продукту, называет циклом смерти продукта. См. схему 6.1.

Схема 6.1. Цикл смерти продукта, автор Дэвид Дж. Блэнд

Цикл смерти продукта – это специфическая форма ловушки. Вы реализуете идеи, не подтвердив их. Придумывать собственные решения не входит в обязанности клиента. Это ваша работа. Вы должны глубоко понять их проблемы, а затем определить лучшие стратегии.

«Официанты» обладают реактивным, а не стратегическим мышлением. Обычно этому способствует чувство беспомощности. Они не верят, что смогут оттолкнуться от решений и глубже погрузиться в проблемы. Но это не так. Клиенты хотят, чтобы их проблемы разрешились, а руководители хотят достичь поставленных целей. Решения необходимы для создания успешного продукта. Это – часть работы.

Очень часто архетип «официанта» идет в паре с другим архетипом – управлением проектами. Поскольку они не сосредоточены на причинах и результатах, они склонны уделять много внимания срокам. Менеджеры проектов, которых назначают на должности менеджеров продуктов, часто становятся «официантами», размахивающими календарем.

Менеджеры по продукту не являются менеджерами проектов, хотя для правильного выполнения своей роли необходимо разбираться в обеих областях. Менеджеры проектов отвечают за сроки. Когда закончится проект? Все ли идут по плану? Уложимся ли мы?

Менеджеры по продукту отвечают за причины. Почему мы это создаем? Как это принесет пользу нашим клиентам? Как это поможет достичь целей? На последние вопросы ответить сложнее, чем на первые, и слишком часто менеджеры по продукту, которые плохо понимают свою роль, прибегают к выполнению такого рода работы. Многие компании до сих пор считают, что менеджер проектов и менеджер по продукту – это одно и то же.

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