Стоит отметить, что все дисциплины тяготеют к управлению людьми и программами по мере того, как вы продвигаетесь по служебной лестнице. И здесь речь идет не о том, что менеджеры продукта становятся руководителями бизнеса, а о том, что у них появляется больше лидерских задач по управлению и организации в общем.
Тем не менее, чтобы к вам как к менеджеру продукта относились серьезно, вам нужно будет продемонстрировать свои способности быть организованным, поддерживать согласованность множества движущихся частей в сложном проекте и их выполнение в срок. Также вы должны обладать навыками общения и работы с людьми для мотивации и поддержки команд, стремящихся работать вместе в сложных условиях.
! СВЕРХСПОСОБНОСТИ UX-ПРАКТИКОВ
Важным аспектом оперативного выполнения задач является работа с заказчиками. Это еще один случай, когда пригодятся навыки межличностного общения и умение понимать людей. Основатель стартапа и консультант по пользовательскому опыту, исследованиям и управлению продуктами Норин Уайзел отметила: «Навыки, которые вы развиваете как UX-дизайнер, помогут вам понимать также потребности бизнеса. Вы сможете применять эти методы, чтобы выяснить потребности заинтересованных сторон, стейкхолдеров, ведь они в некотором смысле тоже являются „пользователями“».
Финансовые навыки
Однако когда дело доходит до финансов, вполне вероятно, что вы вступаете в область, с которой в действительности никогда еще не сталкивались при исследованиях, составлении стратегий или дизайне в UX. Поскольку бóльшая часть команды не подчиняется менеджеру продукта, он или она редко владеет информацией о прибыли и убытках (P&L) своего продукта. Но даже в этом случае менеджеру продукта будет полезно понимать, во что команда обходится бизнесу и какую денежную отдачу она приносит.
Это не только напрямую влияет на производительность команды, но и предупреждает менеджера о том, что их бизнес-подразделение является центром затрат и потенциально уязвимо перед ветром перемен.
Не все роли по продукту имеют дело с транзакциями или доходом, но выполнение этой работы всегда требует определенной степени понимания того, как деньги проходят через бизнес, продукт и команду, которая его создает. Отстаивание стратегического приоритета всегда на каком-то уровне является конкуренцией за скудные ресурсы.
Ваша ответственность как менеджера продукта за создание и развитие ценности продукта в той же мере относится к получению настоящей финансовой ценности бизнесом (организацией), ведь он взял на себя затраты по разработке и выпуску кода, который достается клиенту и конечному пользователю.
Финансовые вопросы по большей части появляются на сцене при ценообразовании продукта и его функций, модели получения дохода и поиска прибыльности. Подробнее об этом – в главе 8 «Получение денег».
Продукты для бизнеса (B2B)
Пожалуй, наиболее пропитанной деловым мышлением и бизнес-контекстами областью управления продуктами является B2B (бизнес для бизнеса, в отличие от B2C – бизнеса для потребителя, B2G – бизнеса для правительства и B2B2C – бизнеса для бизнеса и для потребителя), то есть ведение бизнеса, клиентами которого являются другие предприятия. Можно заработать много денег на продаже инструментов и сервисов, которые необходимы предприятиям для получения своей прибыли. Некоторые сравнивают это со стратегией Леви-Стросса, который разбогател, продавая золотодобытчикам брезент и палаточные колышки, вместо того чтобы промывать породу в поисках золота.
В контексте B2B такие понятия, как рынки и клиенты, меняются, становясь одновременно более узкими и менее абстрактными. Продажи осуществляются предприятиям, а не отдельным людям. Конечный пользователь часто не является плательщиком («клиент»), и это означает, что его удовлетворение напрямую не влияет на его желание или возможности платить. Кроме того, клиенты – это конкретные люди в определенных компаниях, знакомые вашим коллегам из отдела продаж и бухгалтерии, а не широкая публика или все, кто знает, как найти окно Google. И это влияет на многие ваши стратегии в понимании поведения пользователя, на общение с пользователями и клиентами и даже на попытки проведения статистически достоверного анализа данных (подробнее об этом вы прочитаете в главе 6 «Анализ продукта: рост, вовлечение, удержание»).
Чтобы дать представление о том, как меняется роль, когда вашими клиентами являются предприятия, а не потребители, приведу описание дня из жизни другого менеджера продукта, в данном случае от Клемента Као из компании Blend, выпускающей программное обеспечение для банков. (Он также является автором книги «Прорыв в управлении продуктом» (Breaking into Product Management) и ведущим одного из лучших онлайн-сообществ по управлению продуктом Product HQ.)
ДЕНЬ ИЗ ЖИЗНИ ПМ КОРПОРАТИВНОГО СЕГМЕНТА
Клемент Као, менеджер продукта в Blend
Я просыпаюсь около семи. Пока я завтракаю, просматриваю Slack и электронную почту, просто пытаясь уловить суть того, с чем я сегодня столкнусь. При этом я стараюсь не торопясь поесть, пока все не превратилось в сверхсуету. Первые десять минут моего «рабочего дня» я трачу на проверку всех событий в календаре и пытаюсь понять, что является моим приоритетом на сегодня.
Одна из сложных задач в B2B – это непростой доступ к пользователям, потому что всё пропускается через заказчика. В B2C, как правило, вы можете легко набирать пользователей для тестирования. Дать возможность людям взглянуть на ваши разработки относительно просто.
В нашем бизнесе мы должны быть уверены, что даем возможность менеджерам по работе с корпоративными клиентами углублять отношения, а не превращать их в «суперхаос». Таким образом, обычно часть времени нужно потратить на то, чтобы понять, как мы хотим позиционировать отношения. Когда самое подходящее время для обсуждения?
Например, утром я могу встретиться с тремя-четырьмя разными менеджерами по работе с клиентами, и мы все пытаемся разобраться в том, каковы цели нашего запроса к клиентам и пользователям.
В таких тесных отношениях с менеджерами есть плюс – они показывают вам отзывы о качестве от своих конечных пользователей и говорят: «Есть проблема. Она усугубляется». А вот в B2C, если вашему пользователю не нравится продукт, он просто уходит.
Чтобы завершить встречи с менеджерами по работе с клиентами, действительно важно определить, кто, что и когда будет делать. Например: «Мы договорились, что вы все пишете электронные письма. Когда вы их отправите? И если на них не ответят вовремя, то когда вы собираетесь связаться с адресатами? Давайте убедимся, что мы четко определили, как расставляем приоритеты в этом вопросе. Какие следующие шаги?»
Наступает время обеда. Это происходит во время пандемии, и я хочу, чтобы у меня было время для перезагрузки. Я хочу отойти от компьютера и приготовить обед с моей половинкой. Приготовление обеда обычно занимает 30–40 минут, затем мы едим около 15 минут, я немного прогуливаюсь, возвращаюсь к столу и снова погружаюсь в работу.
Во второй половине дня я перехожу к другой своей функции, которую я пытаюсь довести до конца.
Я думаю, что мы должны помнить одну вещь: чтобы вести свой бизнес, люди в B2B используют не только одну функцию, но весь ваш продукт в целом. Постоянно появляются другие функции, и вы не можете просто оптимизировать их на свое усмотрение ради показателей удержания, вовлеченности и использования, потому что, если вы будете оптимизировать только для себя, вы нарушите рабочие процессы других людей.
Что бы мы ни проектировали и ни создавали, когда мы сдаем это заказчику, он может просто не принять работу. Это не Facebook[34] Messenger. И не Instagram*, где пользователи могут сначала пожаловаться на функцию, а потом привыкнуть к ней. В B2B так сделать не получится, потому что у них есть сотрудники, которые обучены всем этим сценариям и планам внедрения.
Моя роль как менеджера продукта, работающего непосредственно со многими из этих пилотных заказчиков, заключается в том, чтобы дать более полное представление не только о том, что скажет пользователь, но и о том, что может сказать руководитель со стороны заказчика, когда мы предложим это направление, контекст или управление изменениями.
Затем я встречаюсь с моей командой по эксплуатации продукта, чтобы разобраться, как сработало внедрение прошлой функции. Как мы видим внедрение для разных клиентов? Мы могли бы опираться на данные об использовании или отзывы о качестве от руководства заказчика, например: «Мы слышали, что этот заказчик столкнулся с реальными проблемами».
В основном мы работаем с менеджерами по эксплуатации продукта и разбираемся, как настроить обмен сообщениями для функции, находящейся в разработке, чтобы заказчик это точно принял.
Потому что, опять же, я не просто отправляю ее, а затем наблюдаю за поступлением данных. Сначала мне нужно обучить всех моих внутренних заинтересованных лиц. «Вот что делает эта функция. Это работает так. И не включайте те другие штуки, потому что они пока не сделаны. И если вы их включите, то все сломается».
Итак, сейчас время близится к вечеру, и какой-то клиент сообщает, что сломалось нечто важное. Они сходят с ума по этому поводу и хотят, чтобы кто-то глянул на проблему. Первое, что я делаю, – пытаюсь в этом разобраться.
Достаточно ли у нас информации от клиента, чтобы понять, что нам следует сделать с инженерной точки зрения? Каков масштаб проблемы? На кого она влияет? Если я направлю туда инженеров слишком рано, то они скажут, что у них недостаточно информации.
Мы запускаем экстренную конференцию в Zoom и вместе начинаем устанавливать приоритеты, пока не выясним все вопросы и не найдем решение. Теперь мы знаем, как будем исправлять, и составляем план выпуска.