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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. На первой встрече я от руки рисовал мокап (версия ноль).
2. Дизайнеры на его основе готовили варианты или генерировали новые идеи решения страниц.
3. Мы выбирали один вариант и доводили его до ума. Во многих случаях он оказывался сильно доработанной версией самого первого мокапа.

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

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

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

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

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

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

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

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

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