Какие приемы консультантов «большой тройки» стоит перенять менеджеру продукта

Менеджер продукта приложения для дальнобойщиков Trucker Path Александр Мемус рассказал vc.ru, как он применил знания, полученные в консалтинговой компании McKinsey, на должности менеджера продукта, и привел примеры из своего опыта в Trucker Path и «Яндекс. Деньгах».

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

Прежде я работал менеджером продукта в «Яндекс. Деньгах», куда перешел из McKinsey с позиции стратегического консультанта. Когда я менял род деятельности, у меня не было четкого понимания, что будет входить в мои обязанности. Тогда я впервые задумался, как применить полученные в McKinsey знания на новой работе. Оказалось, что многие приемы консультантов очень полезны и в новой роли. Расскажу вам о пяти самых эффективных из них.

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

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

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

«Мы измеряем вовлеченность пользователей»? «Вовлеченность пользователей увеличится»? «За счет А вовлеченность пользователей увеличится на 5% к концу первого месяца».

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

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

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

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

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

Роли и консультанта и менеджера по продукту крайне перегружены. Что делают консультанты? Они начинают отсекать лишнее. Сотрудники «Большой тройки» мастерски управляют scope проекта, то есть выбором задач, над которыми стоит работать. Первый шаг к тому, чтобы перенять этот навык, - в дополнение к задаче четко сформулировать то, что в нее не входит.

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

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

4. Делегировать

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

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

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

5. Сделать простой расчет прибыли

Часто консультанту нужно быстро проверить какой-нибудь числовой показатель - например, оценку прибыли компании через год. Консультант не будет выгружать весь объем данных для детального анализа. Сначала он сделает простой back-of-the-envelope - так называемый расчет на обратной стороне конверта, с которым можно на основе простой формулы проверить основные гипотезы и получить грубую оценку величины. Этот принцип легко применим в управлении продуктами.

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

Суть этого упражнения: вместо подготовки финансовой модели на 1000 строк в Excel формулируются только основные четыре-шесть показателей, которые влияют на финансовый результат. Дальше они собираются или в простенький Excel-файл, или вообще в формулу в описании продукта.

У такого приема есть много преимуществ:

1. Все гипотезы превращаются в числа. Соответственно, аналитику можно настроить еще до запуска, ведь заранее известны желаемые параметры для измерений и диапазоны их потенциальных значений.
2. Формула сразу показывает все узкие места модели: в ней явно сформулированы параметры, от которых сильнее всего зависит прибыль. Становится понятно, что если фактическое значение параметра существенно расходится с гипотезой, то продукт не будет зарабатывать.
3. Формула выявляет параметры, которые можно проверить еще до запуска, что позволяет сэкономить ресурсы разработки. Если какие-то параметры в формуле оценить не удается, то и прибыль рассчитать будет невозможно. Такие параметры можно проверить на основе более детальной аналитики еще до запуска.
4. Расчет позволяет «на коленке» сравнивать проекты по прибыли и определять приоритетность их запуска.