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

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

Можно задать такой вопрос: «Вот что я планирую изменить. Это хорошая идея или я что-то упускаю?» После только что проведенного совещания попросите ментора или коллег дать обратную связь и поинтересуйтесь, что, по их мнению, надо улучшить в совещаниях. По окончании первой недели в новой должности устройте ретроспективную встречу и обсудите, какие изменения вы хотели бы внести в работу команды, а что оставить как есть.

ЧЕГО ДЕЛАТЬ НЕ СТОИТ

Не стоит с самого начала говорить людям, что они все делают неправильно

Так вы их только от себя оттолкнете. Вместо этого выясните, почему они решили поступить именно так, и проявите искренний интерес к тому, что вам скажут. После этого можно смело спросить: «А вы рассматривали возможность сделать это по-другому?»

Не давайте категоричных отказов – скажите: «Да, но…»

Бывает, что новичка начинают атаковать просьбами или навязыванием идей о том, чем ему стоит заняться. Многие из таких предложений либо не очень удачные, либо не имеют первостепенного значения. Но вместо того, чтобы отвечать: «Нет, это плохое решение», лучше согласиться: «Да, я думаю, что этим стоит заняться». Даже если сразу после этого вы дадите собеседнику понять, что его предложение будет далеко не первым в списке ваших дел, он почувствует, что его услышали, и будет более охотно работать с вами в будущем.

Не пытайтесь сразу что-то серьезно менять

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

Не думайте, что обязаны следовать всем принятым ранее решениям

Часто новому PM проекты достаются на середине жизненного цикла продукта. Скорее всего, вы будете не согласны с некоторыми решениями, которые принял ваш предшественник, но вам придется мириться с таким положением дел. Ситуация требует деликатности: поговорите со своим руководителем и командой и попробуйте понять, насколько обоснованы предыдущие решения. Может оказаться, что коллеги рады сменить курс или же им просто нужна ваша помощь, чтобы закончить начатое.

Основные выводы

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

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

• Инвестируйте в отношения: хорошие взаимоотношения сделают вашу работу проще и приятнее. Найдите время, чтобы познакомиться с коллегами.

• Четко поймите, чего от вас ждут: в позиции каждого PM есть свою нюансы, поэтому в первые 90 дней недопонимание – это обычное дело. Выясните, как именно люди хотят работать с вами, чтобы вы случайно не задели чьи-то интересы либо не сумели взять на себя те обязанности, выполнение которых от вас ждут. Убедитесь, что вы с руководителем одинаково понимаете ваши приоритеты и сроки предоставления результатов. Изложите свой план в письменном виде и поделитесь им с остальными, чтобы все действовали заодно.

Часть 3

Навыки работы с продуктом

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

• Глава «Понимание потребностей пользователя» (с. 43) научит вас понимать, что действительно нужно людям и какие проблемы они хотят решить с помощью продукта. Вы узнаете, как собирать информацию от пользователей и вычленять из нее ключевые идеи. Наконец, мы рассмотрим различные варианты проведения пользовательских исследований.

• Из главы «Анализ данных» (с. 60) вы узнаете, как проводить обзор данных, анализировать их и использовать для принятия более эффективных решений. Мы расскажем о том, как работать с метриками компании, а также рассмотрим A/B-тестирование и способы работы со статистикой.

• Глава «Аналитический подход к решению задач» (с. 75) описывает главные принципы принятия эффективных решений. Мы разберем такую тему, как системное мышление, и изучим методы устранения сложных проблем.

• Информация, изложенная в главе «Продукт и навыки дизайна» (с. 90), будет полезна для развития продуктового мышления и способности влиять на решения о продукте. Вы узнаете о создании прототипов и мозговых штурмах, а также о том, как правильно расставлять приоритеты.

• Прочтя главу «Технические навыки» (с. 109), вы научитесь взаимодействовать с инженерами и лучше оценивать затраты на разработку. Здесь же дается экспресс-курс по технологиям – API, развертывание, SQL, алгоритмы и многое другое.

• Содержание главы «Документация по продукту» (с. 123) полностью соответствует ее названию. Из нее вы узнаете, какие методы составления и использования продуктовых спецификаций являются самыми эффективными.

Чаще всего навыки по работе с продуктом используются на ранних стадиях жизненного цикла продукта (с. 23), но могут понадобиться и на любом другом этапе проекта.

Глава 4

Понимание потребностей пользователя

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

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

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

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

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

Чувствовать, чего хотят клиенты, – основной навык, необходимый каждому PM. Вы должны развивать глубокое понимание и эмпатию, чтобы безошибочно определять возможности продукта и находить решения, отвечающие потребностям пользователей[18 - Некоторым не нравится термин «пользователь» из-за его обезличенности, но мы используем его в нашей книге, поскольку такие замены, как «клиенты», «читатели» или «участники», применимы не ко всем продуктам.].

Обязанности

РАЗГОВАРИВАТЬ С ДЕЙСТВУЮЩИМИ И ПОТЕНЦИАЛЬНЫМИ ПОЛЬЗОВАТЕЛЯМИ

Пользователи – это люди. Что мы делаем, чтобы узнать человека получше? Мы с ним разговариваем!

Начиная работу над новым продуктом, опросите хотя бы с пять-десять человек и увеличивайте это количество еще на пять-десять человек с каждым новым проектом. Если продукт предназначен для разных типов пользователей (например, авторы + читатели или пассажиры + водители), поговорите с пятью-десятью представителями каждого типа.

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

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

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

Копайте глубже

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

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

В Xanar учли это и просто уравновесили манипулятор. Он не стал легче (на самом деле технически он был даже тяжелее), но зато его управляемость сильно возросла.

Как оказалось, люди не всегда знают, чего они хотят. Они чувствуют «боль» и превращают ее в конкретное решение. И отчасти ваша задача состоит в том, чтобы это решение трансформировать обратно, то есть выслушать запрос, а затем выявить лежащую в его основе проблему. Она-то и становится в итоге «jobs to be done» – «работой, которую нужно выполнить» (с. 49)[19 - Речь идет о методе JTBD (jobs to be done), который позволяет выяснить, какие задачи ваш продукт будет решать для клиента. – Примеч. пер.].

Чем глубже PM вникает в проблему, тем ему проще понять клиента и направить команду в нужном направлении в поисках эффективного решения.

Чтобы тщательнее проработать тему, попробуйте задать пользователю такие вопросы:

• Расскажите, как вы собираетесь использовать запрашиваемую функцию. Что происходит перед ее применением? Что происходит после?

• Является ли это действие частью более масштабной задачи?