Product Management без ошибок. Гид по созданию, управлению и успешному запуску продукта

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Как мы определяем ценность?

• Как мы измеряем успех продуктов на рынке?

• Как убедиться, что мы создаем нужный продукт?

• Как устанавливать цену и упаковывать продукт?

• Как вывести продукт на рынок?