5 приёмов консультантов McKinsey, которые помогут менеджеру продукта

Сейчас ситуация на российском ИТ-рынке такая: все согласились, что менеджеры продуктов нужны в ИТ-компаниях. При этом что они должны делать — решительно неясно. Просто сравните описание вакансий продактов внутри Яндекса (а это одна компания и лидер рынка!). В других компаниях еще большая неразбериха: никто толком не понимает, какие функции выполняет менеджер продукта, и какие навыки для этого требуются. В такой неразберихе недостаточно опытный менеджер может оказаться загружен совсем не той работой, что дает на выходе стабильно отличный продукт. Эта статья о приёмах, которые помогут менеджеру продукта эффективно работать в условиях такой неопределённости. Кстати, по ссылке выше самые вдумчивые требования у команды Навигатора.

Я пришёл в продукты из другой индустрии — стратегического консалтинга. Сейчас я руковожу продуктами в стартапе Trucker Path и сам нанимаю менеджеров. Но полтора года назад, когда я только перешел из McKinsey в Яндекс в роли менеджера продукта, у меня не было четкого понимания, что будет входить в мои обязанности. И я впервые задумался, как применить полученные в McKinsey знания на новой работе. Оказалось, что многие приемы консультантов работают и в роли продакта. Расскажу вам о пяти самых эффективных из них:

1. Используйте аналитику для проверки гипотезы

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

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

Как это применить:

• Сформулируйте гипотезы
• Структурируйте их в виде дерева или пирамиды
• «Оцифруйте» гипотезы: добавьте измеряемые цели и параметры
• Соберите данные для проверки гипотезы
• Уточните гипотезу на основе полученных данных
• Примите решение о целесообразности и приоритете задачи

Вот пример такой цепочки уточнения гипотезы:
Давайте увеличим количество активных пользователей. → Чтобы получить больше пользователей, нужно лучше их привлекать и лучше удерживать. → Для роста количества активных пользователей сейчас важнее научиться их лучше удерживать, так как привлекаем мы их достаточно. → Фича А позволит нам лучше удерживать пользователей и нарастить пользовательскую базу. → За счет фичи А количество пользователей увеличится на 5% к концу первого месяца после запуска (за счет уменьшения оттока пользователей на 20%).

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

В Trucker Path мы думали, как сделать наши приложения понятнее для пользователей. Возникла разумная гипотеза: перевести на другие языки приложение для поиска грузов Truckloads. Для ее проверки мы сначала проанализировали язык операционной системы наших пользователей и выяснили, что отличный от английского язык используют менее 6% дальнобойщиков. Значимая доля была только у испанского (около 5%), а каждый из оставшихся (включая русский) выбирали меньше 0,2% пользователей.

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

2. Докопайтесь до сути

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

Консультанты тоже обычно работают с большими корпорациями, у которых много процессов, сотрудников и legacy. В таких ситуациях критически важно быстро избавиться от шелухи и понять, что же происходит на самом деле. Чтобы докопаться до сути консультанты используют простой инструмент, который называется «Пять зачем» (Википедия переводит «why» как «почему», но мне больше нравится «зачем»: этот вопрос больше сфокусирован на развитии продуктов и целях, а не причинах и обстоятельствах). Пяти последовательных «зачем» обычно достаточно, чтобы понять реальный смысл процесса или найти причину проблемы.

Как это применить:

• Выберите фичу или процесс для анализа (подойдут как существующие, так и планируемые).
• Начните задавать вопросы «Зачем?» или «Почему?» к рассматриваемой реализации.
• Спрашивайте, пока не упрётесь в первопричину. Обычно пяти последовательных вопросов «Зачем?» достаточно.
• Используйте знание о первопричине для уточнения или улучшения реализации.

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

Когда я занимался направлением банковских карт в Яндекс.Деньгах, в какой-то момент топ-менеджмент загорелся идеей кладризации адресов. В результате мне достался проект с названием «Кладризация», но без согласованного и проработанного понимания, что конкретно и зачем делать.

Я начал задавать вопросы «зачем» и понял, что наша цель — увеличить количество успешно доставленных карт. Следующие несколько «зачем» показали, что вообще-то мы хотели решить две проблемы: упростить пользователю ввод адреса на заказе карты (и расширить воронку) и уменьшить число возвратов карт с почты (когда пользователи за 30 дней их не забирали).

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

3. Отсекайте лишнее

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

Что делают консультанты в таких ситуациях? Они начинают отсекать лишнее. Сотрудники McKinsey привыкли внимательно управлять scope проекта (т. е. выбором задач, над которыми стоит работать). Первый шаг к тому, чтобы перенять этот навык, — чётко сформулировать не только задачу, но и то, что в нее не входит.

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

• Обязательно: Что должно быть обязательно сделано? Какой будет MVP? Без чего MVP просто не заработает?
• Желательно: Что можно отложить на второй этап? Какие есть некритичные «хотелки»? Что имеет смысл делать, только если это технически несложно?
• Не делаем: Что точно не является частью этого проекта? Какие задачи не решает планируемый релиз? Какие направления были осознанно отклонены на этапе проработки?

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

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

- Желательно: начать привлекать клиентов в мобильном приложении Truckloads. Эту часть проекта мы отнесли ко второму этапу, потому что для предварительной обкатки процесса и проверки гипотез хватало и email-рассылки. В итоге такой подход оправдал себя: email был менее эффективен, зато сразу дал результаты. Сценарий в приложение мы впиливали уже после, и это заняло некоторое время, при этом мы уже знали наверняка, что он выстрелит.

- Не входит в scope проекта: мгновенная выплата денег через дебетовые счета. Нынешний стандарт на рынке — использовать для факторинга ACH-переводы (с одного банковского счета на другой). Тракеры привыкли именно к такому формату, и на этом этапе мы решили тоже использовать его. Эта гипотеза себя тоже оправдала — и тракеры всем довольны.

4. Делегируйте

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

То же самое верно и для менеджера продукта: он должен четко понимать свою зону ответственности, те задачи, которые может выполнить только сам.

Как быстро начать делегировать:

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

В Яндекс.Деньгах сильный отдел дизайнеров, и ребята много помогали команде карт с UX и дизайном. В итоге у нас лучше всего заработал такой формат взаимодействия:

- На первой встрече я формулировал проблему и от руки рисовал мокап (версия “ноль”).

- Дизайнер на его основе готовил варианты или генерировал новые идеи решения (концепции, отличные от версии “ноль”).

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

Например, когда в Яндекс.Деньгах планировали расширение линейки карточных продуктов, я подготовил два мокапа: горизонтальный и вертикальный. В обоих мы сравнивали три карточных продукта визуально и на основе продуктовых фич (по три-четыре пункта на продукт). Спустя несколько итераций горизонтальный вариант ушел в продакшн.

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

5. Сделайте простой расчёт прибыли/эффекта

Консультанту часто бывает нужно быстро проверить какой-нибудь числовой показатель — например, оценку прибыли компании через год. В такой ситуации консультант не будет начинать с выгрузки гигабайта данных из хранилища и их последующего детального анализа. Сначала он сделает простой back-of-the-envelope calculation — так называемый расчёт на обратной стороне конверта. С его помощью консультант проверит основные гипотезы и получит грубую оценку исследуемой величины (обычно использую одну простую формулу для этого).

Этот принцип легко применим в управлении продуктами. Понятно, что в российских реалиях рассчитывать на точность бизнес-плана по прибыли на пять лет вперед не приходится. К сожалению, альтернативой проработанной долгосрочной финансовой модели регулярно становится ситуация, где никакой оценки эффекта запускаемого продукта или фичи нет вообще. Пользуясь принципом 80/20, в таких ситуациях я обычно делаю простейший back-of-the-envelope расчет и оцениваю ожидаемый эффект “на коленке” (часто даже без моделирования в экселе).

Как это применить:

• Разложите эффект на параметры. Для это сформулируйте основные 4–6 показателей, которые влияют на итоговый финансовый результат. Дальше соберите их в формулу, по которой этот самый результат рассчитывается.
• Численно оцените параметры. На основе вашего опыта и здравого смысла выберите наиболее вероятные значения параметров. По сути, все ваши гипотезы должны на этом этапе превратиться в числа. Соответственно, аналитику можно будет настроить еще до запуска, ведь вы уже определили желаемые параметры для измерений и диапазоны их потенциальных значений.
• Найдите узкие места модели. В формуле уже есть параметры, от которых зависит прибыль — выберите те из них, что сильнее всего влияют на итоговый эффект. Особое внимание обратите на волатильные параметры, ведь если фактическое значение важного параметра существенно разойдется с гипотезой, то продукт не будет зарабатывать.
• Проверьте свои гипотезы. Да-да, аналитика снова поможет сэкономить ресурсы разработки. Для этого отберите параметры, которые можно проверить еще до запуска, и проверьте их на основе детальной аналитики.
• Сравните разные проекты. Расчёт «на коленке» позволяет быстро сравнивать проекты по прибыли. Используйте это для определения приоритетности разных проектов. Так вы сможете проще решить, за какую задачу браться в первую очередь.

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

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

Кстати, я написал сиквел к этой статье с еще 5 навыками для крутого продакта.

Текст сначала был опубликован на vc.ru.