Как стать старшим продакт-менеджером? Советы экс-продуктолога Meta (признана экстремистской и запрещена в России)

Статья Дебби Виджайя, экс-продуктолога Meta (признана экстремистской и запрещена в России) о том, как продвинуть свое мышление и стать лучшим продуктологом. По мнению автора любой может думать, как старший продакт-менеджер, независимо от своего звания, и наличие бейджа с одноименной должностью не гарантирует, что его обладатель действительно этого заслуживает. Перевод материала от блога «По-русски».

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

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

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

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

• Вы можете четко сформулировать ее влияние на бизнес и пользователей;
• Вы хорошо понимаете первопричину проблемы;
• Вы решили, что эта проблема сейчас имеет больший приоритет перед остальными, необходимо искать ее решение;

И вы можете ответить и назвать очевидное решение, если:

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

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

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

«Как мы можем сделать это быстро?»

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

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

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

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

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

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

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

• Юзабилити-тестирование прототипа или проверка эргономичности
  

Преимущество: тестирование покажет, знают ли пользователи, как использовать ваше решение.

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

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

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

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

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

• Пошаговое развертывание функции

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

• В том случае, когда вы хотите проверить, что новая функция не испортит уже имеющиеся. Как продакт-менеджер, вы должны держать в фокусе «контрольные показатели». То есть, это то, чему вы не хотите навредить, когда выпускаете новые функции, такие как частота сбоев приложений и количество жалоб клиентов.
• Пошаговое развертывание актуально, когда вы хотите измерить влияние вашей функции. Представить ее только на небольшому количеству пользователей (или наоборот, представить ее большей части пользователей) в течение определенного периода времени. Таким образом, проследить влияние вашей функции на показатель, который вы хотите усовершенствовать. Главное убедиться, что это распределение равномерно среди всех пользователей. PS: Технически это также считается A / B-тестом, но ради этой статьи я использую термин A / B-тест исключительно для двух или более разных решений.

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

• Проведите A / B тест

Смысл A / B-теста заключается в том, чтобы просто протестировать решение A и решение B и посмотреть, какое из них работает лучше. Это тестирование можно провести на прототипе или же в живой среде. Также добавить решение C и D (тест A / B / C / D). Возможно варьировать комбинации различных компонентов в каждой версии и т.д.

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

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

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

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

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

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

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

• Понимание важности проблемы в стратегии развития

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

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

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

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

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

• Обеспечение контекста и ограничений для вашей команды

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

Ограничениями могут быть:

• Ресурсы (время и количество инженеров);
• Сегменты пользователей;
  
• Крайние случаи, которые должны/ не должны быть охвачены;
  

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

• Накопление их опыта для поиска решений

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

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

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

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

Предлагаю вам несколько инструментов, которые помогут вам в этом.

• Количественная оценка влияния на изменения

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

• Охват: количество затронутых пользователей

• Болезненность: насколько плохо в текущий момент пользователям без предлагаемого решения?

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

По возможности, используйте достоверные данные и цифры, чтобы снизить субъективность.

• Понимание истинной стоимости функции

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

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

• Понимание и ценность временного фактора

Вопрос не всегда звучит как «Стоит ли решать эту проблему?». Это также может быть «Почему сейчас?».

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

• Отказывайтесь на основе логики

Теперь, когда вы выполнили все упражнения, вы убеждены, что эта проблема на самом деле не стоит того, чтобы ее решать, по крайней мере, на данный момент. Противодействие — необходимая часть работы. Как сказал Уоррен Баффет: «Разница между успешными людьми и по-настоящему успешными людьми в том, что по-настоящему успешные люди говорят ”нет" почти всему».

Мои принципы логичного отказа:

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

• Показать, насколько внимательно рассмотрена просьба. Поделиться собственными мыслями на этот счет и обосновать свой вывод.

• Показать, чем занимается команда на данный момент. Четко сформулировать, насколько ценны текущие проекты, которые придётся подвинуть

• Разногласия не должны влиять на работу команды

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

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

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

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

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

• Понимание задач пользователей, которые необходимо выполнить (JTBD)
• 
  

Основной принцип JTBD (Jobs to Be Done) заключается в понимании того, чего пытается достичь пользователь, когда он “нанимает” ваш продукт. Ответ обычно глубже, чем очевидный. Представьте, что продукт, которым вы управляете это программа MBA (master of business administration). Люди получают степень MBA по целому ряду причин: чтобы сменить профессию, продвинуться по своему текущему карьерному пути, начать собственный бизнес и т.д.

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

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

• Понимание факторов перехода пользователя на ваш продукт

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

Какие 4 силы влияют на решение переключиться с одного продукта на другой:

• Подталкивающие факторы: триггерные точки и неудовлетворенность текущим решением;
• Факторы притяжения: преимущества нового решения;
• Тревога: Опасения и переживания по поводу нового решения
• Инерция: Комфорт и знакомство с существующим решением

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

Как мы можем обеспечить надежность нашего продукта в будущем?

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

• Понимание конкурентной среды вашего продукта

В предыдущем разделе, мы выяснили, что конкуренция не может быть очевидной. Университет X не просто конкурирует с университетами Y и Z в продвижении своей программы MBA; он также конкурирует с буткемпами, онлайн-курсами, подкастами, коучингом руководителей и даже Netflix.

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

PS: Также полезно выполнить дополнительные упражнения: (1) Составить карту ваших пользовательских сегментов, поскольку у каждого сегмента будут разные потребности, и не все сегменты одинаково ценны для вашего бизнеса, и (2) Сопоставить потребности с, производительностью и удовольствиями, иначе говоря, это модель Кано. Эта статья и так становится слишком длинной, поэтому я их сокращаю! Если вы хотите узнать о них больше, дайте мне знать в разделе комментариев, и я напишу о них подробную статью.

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

• Исследование возможностей для увеличения ценности вашего продукта

Это не просто конкурент или новичок, который может испортить ваш продукт. Здесь играют другие факторы, которые, были отображены Майклом Портером в концепции «How Competitive Forces Shape Strategy». В своей концепции Портер говорил о признании «переговорной» силы ваших клиентов и поставщиков. Если ваши поставщики могут уронить свои цены, а у вас не остается другого выбора, кроме как последовать им, то вы облажались. Если ваши клиенты могут без проблем отказаться от вас или могут торговаться с вами до цены около нуля, то у вас опять проблемы.

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

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

Давайте в качестве примера возьмем Shopify. Все началось с создания интернет-магазина: владелец малого бизнеса смог создать свой бренд и определить тематику магазина, добавил свои товары, и вуаля, у него есть собственный интернет-магазин за 15 минут. Их целевыми клиентами были люди, у которых уже был бизнес и товары для продажи, им просто нужно было найти соответствующую площадку для продаж в Интернете.

Затем Shopify определил другую возможность: как насчет начинающих предпринимателей, которые хотят начать свой собственный онлайн-бизнес, но пока не знают, что продавать? Они расширили свои предложения до оптового рынка и дропшиппинга.

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

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

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

Фух, это была длинная статья. Спасибо, что дочитали.

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

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

• Опасно слишком часто ставить под сомнение проблему и её решение. Не всегда есть необходимость использовать самый продвинутый инструмент только для того, чтобы выглядеть умным или доказать, что вы работаете как старший продакт-менеджер. Если ваши решения несоизмеримы с затратами создания, попробуйте протестировать гипотезу — именно рынок ответит вам, правы ли вы.
• Опасно слишком мало сомневаться в проблеме и ее решении. Эта ошибка часто встречается среди новых продакт-менеджеров (они думают, что кто-то другой уже разъяснил проблему и ее решение). Это касается и продакт-менеджеров, которые занимают эту должность несколько лет в этой компании (они слишком хорошо знакомы с компанией, пользователями и поэтому они воспринимают все как должное). Кстати, говоря «новый» я имел в виду их срок службы в компании, а не их возраст.

Если вы не уверены, насколько ясно представляете себе проблему или решение, у меня есть для вас один лайфхак: попробуйте это записать. Вы можете написать это в форме пресс-релиза, благодарственного письма клиенту или просто описать проблему и её решение.

Оригинальная публикация: https://medium.com/irlproduct/how-senior-product-managers-think-differently-c5d8cd0cb52c

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

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