Продакт-менеджеры против традиционных менеджеров
Продакт идеален для чисто ИТ-продукта, а традиционный менеджер — для стройки, финансового или образовательного проекта. Только вот у нас стык цифрового и образовательного проекта, и потому ни тот ни другой не подходят в полной мере.
Продуктовый менеджер, или ПМ, — относительно новая профессия, появившаяся в момент, когда стало нужно управлять командами в бизнесе, который основан на ИТ.
Главная сила ПМ — возможность очень быстро разворачивать продукт в сторону потребностей рынка. Это руководители, которые в первую очередь знают, что нужно рынку, и уже потом делают общее руководство вроде планирования, бюджетирования, работы с командой и так далее. То есть главное требование к ПМ — умение проверять гипотезы.
«Обычные» менеджеры заточены под другое: они умеют продвигать проект вперёд. Они знают, почему важно заполнять кучу скучной документации, почему после встреч нужно закреплять результаты, они оставляют артефакты после каждого действия, они планируют риски сильно заранее, они считают в XLS-таблицах, рисуют диаграммы Ганта и знают, как зовут детей каждого в команде.
На практике в наших проектах «чистый» ПМ, уж простите, скорее всего, пропустит важные риски и с некоторой вероятностью сделает суперпродукт, но, скорее, облажается по срокам, юнит-экономике или команде. «Чистый» менеджер сделает всё в бюджете, в срок, экономика будет сходиться, но продукт не будет нужен рынку.
Про важность общего управления почему-то говорят очень мало. Кажется, пора признать, что нам всем оно нужно.
Что такое продуктово-простая и продуктово-сложная задача
Построить аэропорт или завод — это очень сложная операционная задача, но при этом очень простая с продуктовой точки зрения.
Вы точно знаете, как будет выглядеть аэропорт, который планируете. Сюрпризы будут ждать вас на каждом этапе, но они будут внутри прогнозируемых отрезков, то есть проект не кончится тем, что вместо аэропорта вы строите десять домов, соединённых подземными тоннелями. Вам надо один раз спроектировать всё в целом, подробно понять, что нужно на каждом этапе, связать системы в единое целое и начать впахивать.
Цифровой сервис обычно проще в плане операционного управления (вам не надо получать тысячи согласований, синхронизировать бюджеты, отчётность, управление командами, решать проблемы забухавшей бригады, доставать технику, договариваться про топливо, ездить к поставщику принимать выпить за качество поставляемого кабеля и так далее) — вам нужно найти основное, что нужно пользователю, и доставить до него.
Если по дороге выпадет что-то в других аспектах, обычно это не очень страшно, можно быстро подтянуть. Цифровые проекты более толерантны к ошибкам, потому что гибче и не так зависят от точности исполнения по бюджету — обычно их маржинальность куда выше операционных, что даёт запас прочности. Но время от времени в цифровых сервисах забывают что-то важное по пути (например, ИБ в доставке еды) — и это оборачивается серьёзной проблемой.
В современном виде надо строить аэропорт непонятно какой конфигурации. Все знают, сколько самолётов он должен принимать и сколько должен стоить, когда он нужен —, но никто не знает, какие это будут самолёты, зачем это пассажирам и откуда они возьмутся.
Как выглядит жизненный путь ПМ
Обычная история — это освоить аджайл-практики (либо Канбан, Скрам или что-то ещё похожее) и заходить с этим в управление продуктовой командой. Главный эффект от управления достигается в цифровых проектах от того, что проект правильно деливерится.
Поиск правильных фич, кастдевы, исследования, проверка гипотез, приоритизация бэклога — это то, что делает продакта продактом. Он постоянно находится в поиске тех вещей, которые улучшают продукт, правильно ставит приоритеты команде, следит за метриками и точно знает, как всё это сделать хорошо.
Это идеальный сценарий для ситуации, когда вы не знаете точно, что хотите получить. То есть весь аджайл заточен, можно сказать, под стартапы — ситуации, когда информации о конечном состоянии продукта нет. Это и отличает его от классического планирования того же строительства. Возьмём для примера дом. На ранних этапах, например при выборе дизайна, методология аджайла подходит, потому что есть пространство для манёвра и рефакторинга. А непосредственно на этапе строительства нужен другой подход, иначе получится, что потом придётся разбирать и рефакторить здание, потому что забыли вентиляцию или что-то ещё важное.
Или ждать 3 месяца, потому что забыли заказать стройматериалы сильно заранее. И так далее.
При этом очень мало внимания в обучении ПМ уделяется классическому общему управлению.
Общее управление — это в первую очередь про понимание того, как наиболее надёжно идти к желаемому результату. То есть управляющий строительством заранее представит себе конечный результат, а потом начнёт раскладывать его назад во времени, представляя каждый этап и что для него нужно. И из этого рисовать графики поставок, графики работ, количество работников и ресурсов для каждого этапа — и сразу же продумает риски.
Современные продукты сочетают в себе и вот эту стартап-составляющую с неизвестностью вокруг, и понимание результата. Но в общих чертах.
Наши образовательные проекты — классический случай, когда операционный проект (где много работы людей, то есть услуг) встречается с цифровым. Например, чтобы открыть школу Юнити для детей, нужно иметь возможность и правильно адаптировать уже созданную нами образовательную платформу под курс, и найти методологов, и нанять десятки учителей, и продумать рекламную поддержку и так далее.
Чистый ПМ не вывезет ту часть, где нужно планировать. Точнее, конечно же, может, но это у него не в фокусе и он будет регулярно что-то упускать из контроля. Это кончится либо тем, что учителей на старте будет слишком мало (реальный случай), либо тем, что упущен какой-то важный системный риск (просто потому что не нашлось времени подумать), и то, что проект его избежал, — чистая лотерея. То есть просто сыграли в русскую рулетку и выиграли, а не продумали, как обойти риск.
«Общий» менеджер же, с другой стороны, скорее всего, провалит работу на этапе определения необходимости запуска, потому что надо смотреть на метрики и исследовать мир, чтобы понять нужен ли сам продукт. А ему спокойнее играть в шахматы, когда есть чёрное, белое и все поля квадратные. Он может заранее продумать что угодно, если знает результат точно. То есть с ИТ-составляющей он справится успешно, а с решением каких-либо базовых вопросов, например, как назвать или какую цену выставить, — уже нет.
У нас получается, что нужны и те и другие навыки. И это не только у нас, это практически везде по рынку, где чисто цифровые проекты пересекаются с чем-то ещё. А поскольку это происходит в любой отрасли, растут и требования к навыкам общего управления у ПМ.
Почему именно общего управления у ПМ, а не аджайл-подхода у менеджеров? На самом деле и так и так. Но, как это ни странно, ПМ легче приобретает «скучные» навыки, чем классический менеджер учится быстро проверять гипотезы.
Собственно, джуниор ПМ знает только инструментарий аджайла, метрики, кастдевы, немного умеет считать юнит-экономику. Их проекты бодро стартуют, но статистически ничем не заканчиваются. То есть даже не неудачи, а именно просто повисшие в воздухе проекты, которые никому уже не нужны, потому что что-то пошло не так.
Мидлы уже знают, что есть функциональные навыки, и силой воли умеют себя заставить мыслить системно, а не текущим моментом. У них в фокусе уже куда больше аспектов проекта, подключаются риски. Они умеют доводить проекты до конца, но часто промахиваются мимо обещаний. Часто они не учитывают какой-то риск в зоне, которую считают недостаточно важной для контроля, и это сильно осложняет проект.
Сеньоры уже повидали некоторое дерьмо и знают, отчего проект может пойти ко дну. У них существенно реже страдает само исполнение проекта. Они сочетают в себе и компетенцию ПМ, и компетенцию классического менеджера. Поэтому, собственно, хорошие ПМ редко задерживаются на этой должности и становятся кем-то со словами «генеральный» или «исполнительный» в должности.
Как это работает на наших проектах «на стыке»
Обычно надо подготовить:
- контент продукта — методологию и конкретное наполнение уроками и материалами;
- преподавателей — отработать их найм, контроль качества и так далее;
- маркетинг — поиск учеников;
- работу с командой и операционку;
- связку с технической платформой. К счастью, она уже давно готова и очень гибкая, так что это по большей части интеграция и доработки, а не разработка с нуля.
Архитектурно обычно справляются все. А вот дальше вопрос дисциплины, которой может не хватить. Если руководитель охватывает весь проект, то всё в порядке. Но это, вообще-то говоря, достаточно сложно без привычки, а привычка развивается упражнением.
Нужно фокусироваться не на том, что прямо сейчас интересно и даёт эффект, а видеть картину в целом и думать на два шага вперёд. Это, объективно говоря, очень скучно.
Поэтому часто происходит «в теории я знаю, но прямо сейчас не буду».
Очень часто это компенсируется тем, что есть уже проджект-менеджер высокого уровня, который следит за тем, чтобы проект правильно исполнялся.
Почему не работают связки двух людей? В типовой ситуации ПМ + проджект второй обычно подчинён первому. То есть когда есть что-то тяжёлое для проекта, что нужно скучным образом сделать, ПМ может просто сказать, что заморачиваться не надо. И у проджекта не хватит полномочий это дотащить. Бывают ситуации, когда предприниматель и администратор — это партнёры и у них равные полномочия. Но тогда предприниматель (ПМ) побеждает в большинстве ситуаций просто потому, что он по характеру своей личности и опыту чаще всего гораздо лучше убеждает и ищет доводы. Он просто продавливает харизмой администратора.
Причём, что самое печальное, в некоторых случаях (у нас это около 30–40%) он бывает прав и победа в лотерее даёт огромный выигрыш. Почему это печально — потому что так закрепляется опыт, что так и надо делать, и дальше такой человек становится опаснее и опаснее для бизнеса, как бы это странно ни звучало. Каждая победа повышает его авторитет, и дальше всё меньше и меньше вещей учитывается. На каждое неструктурное действие растёт уровень энтропии проекта — где-то растёт легаси, где-то не учитываются риски и так далее.
В ИТ-проектах с этим очень быстро столкнулись как раз на техническом долге. ПМ всегда хочет его нарастить, а команда — снизить. В аджайл-методологиях самое главное — система сдержек и противовесов, которые очень ограничивают такие поползновения ПМ'а и вовремя возвращают баланс. Там ответственность разнесена между членами проекта очень сильно. А вот когда проекты кросс-функциональные, продакты их ещё недавно даже близко не касались, а теперь делают повсеместно. И там к таким людям ещё не готовы, и модели управления с балансировкой нет. Там никто не придумывал фреймворки, если человек не хочет администрировать. Я часто вижу, что с командой разработки у него скрам, а с остальными кривой аджайл. То есть такой аджайл без аджайла.
Почему тогда обычные менеджеры не идут в таких продактов? Во-первых, всё-таки идут.
Во-вторых, им сложно, нужна «продуктовая мышца», которая определяет, по сути, конкуренцию воронок продуктов. Классические менеджеры про воронку вспоминают в последнюю очередь, а для продуктов с ИТ-составляющей это критично. Очень тяжело, чтобы продукт не расходился со смыслами продажи, когда обещают одно, а сделано другое. Как раз эту часть великолепно выравнивает продакт, но очень плохо классический менеджер без дополнительных компетенций.
Собственно, маркетологи как таковые (по Котлеру) появились именно для того, чтобы производства занимались не оптимизацией конвейера, а как раз выравнивались с внешним миром. Можно сказать, что ПМ — это эволюция маркетолога (того же автоконцерна для примера), а администратор — эволюция руководителя производства или главного инженера.
И поскольку сейчас нет внятных фреймворков связки этих двух людей — они ещё появятся, я в этом уверен, но их нет сейчас в моменте — нужны продакты с пониманием общего администрирования.
Вот коротко примеры, что может пойти не так, если этого нет:
- Не наняли достаточно учителей к старту обучения. Или перенаняли. Просто не подумали заранее, хотя это можно было обложить метриками и предсказать.
- Придумали процесс, потом скопировали его на другую тарифную линейку. Начинаются занятия — и вдруг мы с ужасом понимаем, что преподаватели не знают, когда у них занятия. Потому что на тарифе А был менеджер, который это делал вручную для каждого в индивидуальном сопровождении, а на тарифе Б автоматизация, и эту часть просто забыли правильно перенести. Потому что процессы надо рисовать, а это требует дисциплины.
- Всё классно запланировали, но 30% пользователей из источника не могут оплатить. Просто не прошлись по рискам и не «прокопали» каждый элемент процесса. Узнали в стиле аджайла, уже на бою.
- Выкатили в бой продукт, на котором нет оферты. Закатили обратно. С такой историей можно получить с десяток исков в суд буквально за сутки. А закатить обратно продукт, у которого уже вся реклама и всё остальное, — это локальный ад.
- Пользователь не может что-то сделать. Интерфейс есть, бэка нет. Забыли, потому что это же в жизни не главное, главное — доставлять основную ценность.
По факту юнит-экономика оказалась в полтора раза хуже калькулятора. Это не потому что в калькуляторе плохо, а потому что реализовали и структурировали так, что добавили допрасходы.
Просто не учли, что они могут быть значимы. Администратор бы начал как раз с этого, кстати.
Нужно ли это одному человеку или это две разные роли?
Каждый руководитель проекта или стартапер хочет вырасти до CEO. Обычно он не хочет бросить компанию, когда у него 10 человек и получен первый раунд инвестиций. На венчурном рынке нормальный CEO извне нанимается около оценки в миллиард. До этого миллиарда компании ещё надо дорасти, и она дорастает с менеджментом.
То есть не получится нанять хорошего управляющего когда-то потом, когда возникнет нужда и будет возможность. Нужно самому, и это обычно одна роль. Управляющего нужно воспитать в себе, и, судя по всему, это как с поддержанием физической формы — получается у всех, если уделить достаточно внимания. Вопрос желания и дисциплины.
Сильный менеджер достигает цели. Он определяет, что надо сделать, чтобы достичь цели максимально полно и надёжно. Планирует, декомпозирует, делегирует и организовывает сопровождение исполнения. Это не про амбиции в духе «мы можем на две недели быстрее», это про достижение цели независимо от погоды и случайностей. Для этого есть понятные инструменты. Можно, конечно, проект делать и на краткосрочных костылях, выгорании команды и прочих вещах —, но тогда рано или поздно сработает какой-то риск и проект остановится.
Можно сравнить это со стратегиями. Там есть два состояния карты: вообще чёрная и «туман войны». Так вот, задача администратора — узнать состояние всей карты. Задача ПМ — уже работать с «туманом войны». Тогда, посмотрев на эту карту, можно предсказать, где могут быть риски критичные, где нет.
