Проведя эксперимент, Меган смогла доказать, что лучший способ достичь своей цели и угодить пользователям это разработать онлайн-версию банка. «Мы знали, что на тот момент ресурсов у нас не хватало, но теперь у нас появилась концепция. Мы должны были работать в этом направлении и детально изучать каждый компонент».
Отсюда команда Меган работала в обратном направлении: они определяли, что должно войти в первую версию нового продукта, и расставляли приоритеты по ценности и усилиям. Кроме того, они расширили эксперимент и создали более надежные способы для отправки документации и заявок. Одобрение по-прежнему выполняли люди. Хотя им не удалось проверить информацию каждого клиента в режиме онлайн, они смогли сократить количество необходимых визитов на 50 %. Это было отличное начало.
Команда планировала и дальше совершенствовать решения, включая компоненты искусственного интеллекта (ИИ) и онлайн-нотариусов, пока не достигнет своей цели нулевого количества визитов для проверки. «Самое важное, чему я научилась в продакт-менеджменте, это всегда фокусироваться на проблеме. Если вы будете ориентироваться на продукт, вы с большей вероятностью создадите правильную вещь», сказала Меган.
Начните с «почему»
Теперь давайте поговорим о том, что помогло Меган и ее команде добиться успеха. Она начала с вопроса «почему?».
Почему мы переходим на цифровое обслуживание в сфере ипотеки?
Зачем вообще делать этот проект?
Каков желаемый результат?
Как выглядит успех?
Что произойдет, если мы перейдем на цифровое обслуживание, но никто не будет брать кредит?
Как мы можем снизить этот риск?
Слишком часто менеджеры по продукту погружаются в создание решений, не продумав сопутствующие риски. Каждый из вышеупомянутых вопросов представляет для Меган риск, который потенциально может погубить ее проект. Здесь назревает вопрос: почему мы так поступаем? Во многих розничных банках и других организациях менеджерам по продукту не дают возможности задать вопрос «почему». Они получают функции и решения от заинтересованных сторон или менеджеров. Иногда эти функции определяются и утверждаются во время ежегодного периода бюджетирования. В других случаях их рассматривают как работу менеджера диктовать решения, которые необходимо создать. Поступая таким образом, вы создаете риск неудачи, связанный с предвзятостью этих решений, организационной или личной. Единственный способ борьбы с этой предвзятостью учиться у пользователей и экспериментировать.
Во многих случаях, когда организации предлагают решения, они не устанавливают метрики успеха и цели. Проект Меган мог бы пойти совсем по-другому, если бы это было так, и если бы ей просто сказали: «Сделайте процесс подачи заявки цифровым, чтобы никому не пришлось лично обращаться в банк». А что, если бы она обнаружила, что ее клиенты не хотят подавать заявки онлайн и им удобнее делать это в офисе? Что, если бы цифровизация процесса привела к резкому снижению процента оформления заявок? Как она могла принять решение и исправить ситуацию, если у нее не было для этого никакого пространства?
Самая большая проблема, которую я слышу от руководителей, приходя в их организации, заключается в том, что продакт-менеджеры не хотят делать шаг вперед и «владеть продуктом». Однако это обоюдоострый меч. Во многих случаях менеджер может сделать больше. Например, он может поставить под сомнение определенные решения. Работа, необходимая для сбора данных и доказательства эффективности решения, требует времени. И вот именно здесь люди обычно путаются между тем, что в Agile называется владельцем продукта и менеджером по продукту.
Если посмотреть на роль владельца продукта в большинстве литературы по Scrum (методология управления проектами), то в обязанности этой должности входит следующее:
Определение бэклогов и создание действенных пользовательских историй для команд разработчиков.
Выявление и расставление приоритетов работы в бэклоге.
Приемка завершенных пользовательских историй и проверка работы на соответствие критериям.
Примечания
1
Майкл Сол Делл американский предприниматель, основатель и руководитель компании Dell. Прим. ред.