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

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

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

Менеджер продукта приложения для дальнобойщиков 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. Расчет позволяет «на коленке» сравнивать проекты по прибыли и определять приоритетность их запуска.

Испанский школьник из-за нежелания делать уроки подал в суд...

Испанский школьник из-за нежелания делать уроки подал в суд на мать

В Испании произошел интересный случай - подросток не хотел учить уроки и решил подать в суд на мать. В непростых отношениях отцов и детей пришлось разбираться судье Луису Мигелю Колумна из города Эхидо в Альмерии. Об этом сообщает News-for.me. Судье подробнее ...

загрузка...

 

Вверх