Полагаю, каждый Product Manager хотел бы стать Senior Product Manager и на эту тему написано множество статей. Поэтому эта статья не о том, как получить повышение до старшего руководителя, а о том, как улучшить свое мышление и стать лучшим руководителем. Любой человек может мыслить как старший PM, независимо от его должности — и если у кого‑то есть должность старшего PM, это еще не значит, что он ее заслуживает.

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

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

Постижение основ: Отличное исполнение

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

«Как мы можем отгрузить это быстро?»

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

В традиционной Scrum‑команде организация выполнения этих задач входит в обязанности владельца продукта. В более развитых организациях я часто вижу, что этим занимается технический руководитель. Если вам повезло, и в вашей команде есть хороший технический руководитель, не расстраивайтесь! Как PM, вы привносите свою уникальную ценность, поскольку можете убедиться, в том, что инженеры понимают видение и контекст работы и то, как она способствует достижению бизнес‑целей. Также вы помогаете им вертикально разделить работу на независимые куски, пригодные для отгрузки.

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

«Как мы можем гарантировать, что сделаем это хорошо?»

Здесь на помощь приходят тестирование и эксперименты. Возможно, вы захотите провести юзабилити‑тестирование с помощью прототипа, прежде чем просить инженеров написать код. Возможно, вы решите внедрять функцию постепенно или провести A/B‑тестирование, прежде чем выпустить финальную версию.

Различные типы тестов и экспериментов — это как инструменты в ящике с инструментами. Вы должны понимать, что делает каждый из них, чтобы выбрать нужный инструмент для конкретной ситуации.

Например, тестирование юзабилити прототипа:

Что оно дает: Проверяет, знают ли пользователи, как использовать ваше решение.

Что оно не делает: Проверяет, хотят ли пользователи использовать ваше решение.

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

Ваша задача — молча наблюдать и делать заметки. Знают ли они интуитивно, какую кнопку нажать? Понимают ли они, что произойдет, когда они совершат определенное действие? Не сбивает ли их с толку текст?

Этот тест — быстрый и недорогой способ убедиться, что вы не тратите впустую ценные инженерные ресурсы. Вы можете использовать платформу вроде usertesting.com, которая позволяет настроить тест прямо перед выходом из дома, и вуаля! Результаты будут готовы на следующий день!

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

Развертывание функции постепенно

Это означает, что вместо того, чтобы сразу же развернуть функцию для 100% пользователей, вы делаете это постепенно. Есть несколько случаев, когда это полезно:

Вы хотите убедиться, что эта функция ничего не сломает. Как PM, вы должны понимать, что такое ваши «контрольные метрики». Контрольные метрики — это то, что вы не хотите повредить при выпуске новых вещей, например частота сбоев приложения или количество жалоб клиентов.

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

PS: Технически это также считается A/B‑тестированием, но в рамках данной статьи я использую термин A/B‑тестирование исключительно для двух или более различных решений.

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

Проведите A/B-тестирование

Буквальное значение A/B‑теста — это просто тестирование решения A и решения B и наблюдение за тем, какое из них работает лучше. Можно провести A/B‑тестирование на прототипе, а можно — в реальной среде. Можно провести A/B/C/D‑тест, а можно использовать комбинацию различных компонентов в каждой версии и т. д.

Цель — определить выигрышный вариант решения. Возможно, вы слышали знаменитый пример о том, как Google экспериментировал с 41 оттенком синего и добился увеличения дохода на 200 миллионов долларов США. Но если у вас нет миллионов/миллиардов пользователей и крошечный% прироста равен огромному значению в $$$, я бы не рекомендовал перебарщивать с A/B‑тестами. Есть функции пользователей, которые вы захотите улучшить до тех пор, пока не будете уверены, что справились с ними, например, пути приобретения и активации. В этих точках контакта вы превращаете посетителя в платящего пользователя, и влияние $$ легко измерить. Но на других этапах пути, например, когда пользователи фактически используют ваш продукт для выполнения задачи, обычно достаточно простого A/B‑теста.

Критическая оценка (и продуманный отклик)

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

Критическая оценка решения («Есть ли лучший способ решить эту проблему?») и оценка проблемы («Стоит ли решать эту проблему?») — вот что выводит ваше продуктовое мышление на новый уровень. Это также может означать отказ или противодействие заинтересованным сторонам.

«Есть ли лучший способ решить эту проблему?»

Есть разные способы определения «лучшего» решения. «Лучшее» может означать более быстрое создание, более низкую стоимость интеграции, более ценное для бизнеса в долгосрочной перспективе или более эффективное в решении краткосрочной проблемы.

Ваша задача как PM — понять стратегическую важность проблемы, которую вы создаете, что позволит вам установить правильные ограничения для решения. Затем вы должны объединить опыт людей в вашей команде (инженеров, специалистов по анализу данных и дизайнеров), чтобы найти различные решения, удовлетворяющие ограничениям.

Понимание стратегической важности проблемы

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

Как руководитель, вы должны уметь формулировать:

Какую цель компании вы пытаетесь решить, работая над этим проектом?

Какие проблемы пользователей вы решаете? (И мой любимый последующий вопрос: откуда вы знаете, что это проблема?)

Как вы узнаете, что решили проблему? Какие показатели результата будут затронуты? Какие выходные метрики вы будете измерять и как они повлияют на итоговые метрики?

Предоставление контекста и ограничений вашей команде

Я не поклонник страниц и страниц PRD (документации по требованиям к продукту), и уж точно не поклонник «передачи» PRD инженерам для создания. Вы должны предоставить контекст (как мы только что обсуждали — цель компании, проблемы пользователей, метрики и т. д.) и ограничения. Ограничениями могут быть:

• Ресурсы (время и количество инженеров)

• Сегменты пользователей

• Краевые случаи, которые должны/не должны быть охвачены

Помните, что цель не всегда состоит в том, чтобы создать что‑то идеальное для всех. Вполне можно сказать: «Нам просто нужно быстрое и грязное решение для сегмента пользователей X, и нас не волнуют крайние случаи Y и Z», при условии, что вы тщательно продумали их и довольны компромиссами.

Собирайте их опыт и знания, чтобы найти решения.

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

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

«Стоит ли решать эту проблему?»

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

Если «исходить из добрых намерений, если не из компетентности», то все идеи и запросы на продукты имеют определенную степень обоснованности. Возможно, ни одна из них не является по‑настоящему бесполезной — что усложняет отпор.

Поиск стратегических возможностей

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

Итак, на какую проблему, имеющую наибольшую ценность, нам следует обратить внимание?

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

Понимание задач пользователей (JTBD)

Главный постулат JTBD — понимание того, чего пытается достичь пользователь, когда «нанимает» ваш продукт. Ответ обычно глубже очевидного. Представьте, что продукт, которым вы управляете, — это программа MBA. Люди получают степень MBA по разным причинам: чтобы сменить профессию, продвинуться по текущей карьерной лестнице, начать собственный бизнес и т. д.

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

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

Как мы можем усовершенствовать наш продукт?

Совершенствование продукта не всегда ограничивается текущим игровым полем. Радикальные инновации, как правило, появляются в результате взгляда вовне, а не постепенного совершенствования.

Как мы уже говорили в предыдущем разделе, конкуренты вашего продукта — это не только очевидные конкуренты. Университет X конкурирует не только с университетами Y и Z в продвижении своей программы MBA; он также конкурирует с буткампами, онлайн‑курсами, подкастами, коучингом руководителей и даже Netflix.

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

Заключение

В заключении приведем две ловушки, в которые может попасть PM:

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

Он может задавать слишком мало вопросов о проблеме и решении. Обычно это ошибка очень нового руководителя (он думает, что кто‑то другой уже сделал работу по прояснению проблемы и решения) или очень старого руководителя (он слишком хорошо знаком с компанией, пользователем и областью, поэтому воспринимает все как должное). Говоря «новый» и «старый», я, кстати, имел в виду их стаж работы в компании, а не возраст.

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

Если вы работаете с продуктами и хотите глубже понимать процессы управления ими, приглашаем вас на два открытых урока курса Senior Product Manager.

• 12 августа в 20:00 пройдет занятие «MVP, HADI, GTM — что нужно знать инженеру», где разберем ключевые подходы к тестированию гипотез и выводу продукта на рынок.

• 21 августа в 20:00 состоится урок «Из Project в Product Manager: шаги и подводные камни» — поговорим о различиях ролей и типичных сложностях при переходе к продуктовой работе.

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