Читать книгу Product Management без ошибок. Гид по созданию, управлению и успешному запуску продукта - Мелисса Перри - Страница 12

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

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

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

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

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

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

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

Технический эксперт и рыночный эксперт

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

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

Мне часто задают вопрос: «В чем разница между UX-дизайном и управлением продуктом?» Эти две дисциплины во многом пересекаются, но пользовательский опыт – это только одна часть создания хорошего продукта. Дизайн – его важнейший компонент. Но опять же это тоже только одна его часть. Управление продуктом – это изучение всей системы: требований, компонентов функций, ценности, пользовательского опыта, базовой бизнес-модели, ценообразования и интеграции. Это выяснение, как конкретный продукт может принести доход компании. Речь идет о понимании всей картины организации и выяснении того, как продукт – а не только опыт – в нее вписывается.

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

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

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

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

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

Грамотный продакт-менеджер

«Так что же представляет собой грамотный менеджер по продукту?» – спросила команда Marquetly. Я решила, что им надоело слушать мои рассуждения, поэтому пригласила Меган, знакомого мне продакт-менеджера. Она работала над программным обеспечением для потребительских ипотечных кредитов в крупном розничном банке. Меган пришла поговорить с командой о том, что она думает о своей роли, и какую работу она ежедневно выполняет.

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

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

«Я очень сопереживаю клиентам и выясняю, что им не нравится. Я называю их Мэри и Фред, – рассказала она команде Marquetly. – Они живут в Нью-Йорке и ищут свой первый дом в Коннектикуте, потому что Мэри беременна, и им нужно больше места. Вы не поверите, через что им пришлось пройти, чтобы подать заявку на ипотечный кредит. За последний месяц они несколько раз ходили в местное отделение банка на встречу с кредитным инспектором. Они заполняли огромное количество бумаг в офисе. Иногда они забывали нужные документы, и им приходилось за ними возвращаться на следующий день и делать все заново. Затем им приходилось ждать, чтобы узнать, одобрена ли сумма». Меган продолжала объяснять очень подробный процесс, через который пришлось пройти паре. Было ясно, что она хорошо знает клиентов и знает их болевые точки.

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

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

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

Меган периодически приглашала членов своей команды – разработчиков и UX-дизайнера – на сеансы исследования пользователей, чтобы все могли четко понять проблемы. Вскоре они обнаружили закономерность: многих потенциальных клиентов просили прийти в офис для проверки документов (поскольку это нельзя было сделать онлайн). Большинство людей предпочитали обратиться в другой банк, потому что в этом банке не было свободных мест на ближайшее время. Проведя опрос среди более широкого круга людей, Меган выяснила, что это была самая распространенная проблема. Только 25 % людей заполнили заявки в ее банке.

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

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

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

Отсюда команда Меган работала в обратном направлении: они определяли, что должно войти в первую версию нового продукта, и расставляли приоритеты по ценности и усилиям. Кроме того, они расширили эксперимент и создали более надежные способы для отправки документации и заявок. Одобрение по-прежнему выполняли люди. Хотя им не удалось проверить информацию каждого клиента в режиме онлайн, они смогли сократить количество необходимых визитов на 50 %. Это было отличное начало.

Команда планировала и дальше совершенствовать решения, включая компоненты искусственного интеллекта (ИИ) и онлайн-нотариусов, пока не достигнет своей цели – нулевого количества визитов для проверки. «Самое важное, чему я научилась в продакт-менеджменте, – это всегда фокусироваться на проблеме. Если вы будете ориентироваться на продукт, вы с большей вероятностью создадите правильную вещь», – сказала Меган.

Начните с «почему»

Теперь давайте поговорим о том, что помогло Меган и ее команде добиться успеха. Она начала с вопроса «почему?».

• Почему мы переходим на цифровое обслуживание в сфере ипотеки?

• Зачем вообще делать этот проект?

• Каков желаемый результат?

• Как выглядит успех?

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

• Как мы можем снизить этот риск?

Слишком часто менеджеры по продукту погружаются в создание решений, не продумав сопутствующие риски. Каждый из вышеупомянутых вопросов представляет для Меган риск, который потенциально может погубить ее проект. Здесь назревает вопрос: почему мы так поступаем? Во многих розничных банках и других организациях менеджерам по продукту не дают возможности задать вопрос «почему». Они получают функции и решения от заинтересованных сторон или менеджеров. Иногда эти функции определяются и утверждаются во время ежегодного периода бюджетирования. В других случаях их рассматривают как работу менеджера – диктовать решения, которые необходимо создать. Поступая таким образом, вы создаете риск неудачи, связанный с предвзятостью этих решений, организационной или личной. Единственный способ борьбы с этой предвзятостью – учиться у пользователей и экспериментировать.

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

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

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

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

• Выявление и расставление приоритетов работы в бэклоге.

• Приемка завершенных пользовательских историй и проверка работы на соответствие критериям.