Может ли получиться менеджер продукта из ведущего разработчика

Главные роли в любом проекте играют архитектор и менеджер продукта.

Архитектор это возвышенное и нежное существо с ясным взором и мыслями, пронзающими пласты веков. Удел архитектора – техническая сторона проекта, и в силу своей возвышенности над бренным миром он не может управлять проектом. Поскольку со своей высоты ему недоступны желания пользователей.

Для этого и нужен менеджер продукта. Тот кто более приземлен и понимает потребности пользователей и доносит их архитектору.

Откуда берутся менеджеры продукта? Кто может ими стать? Может ли им стать бывший ведущий разработчик? Давайте попробуем разобраться.

[sendpulse-form id=”278″]

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

1. Анализирует, что может понадобиться пользователям и исследует рынок. То есть придумывает идеи новых проектов и ставит им приоритеты.
2. Совместно с командой разработки выбирает техническое решение.
3. Просчитывает экономику продукта и определяет, стоит ли этим, вообще, заниматься.
4. Собирает рабочую группу, ставит задачи архитекторам и остальным ключевым лицам проекта.
5. Следит за всем-всем-всем по организации, в частности, отвечает за взаимодействие с партнёрами и вендорами.
6. После внедрения сопровождает продукт, занимается его развитием и усовершенствованием минимум год.
7. Время от времени просыпается ночью с горящими глазами и идеей нового продукта.

Менеджер продукта может получиться из руководителя проекта. На этой роли ответственности больше, но и кайфа, оттого что ты сам что-то придумал и создал — море. Самое крутое в такой работе — это вместе с классной командой делать масштабные проекты, которые «взлетят». Это чувство окрыляет. Но и проблем в работе немало.

Важно: здесь и далее мы говорим про работу продуктового менеджера в сервисе, а не в разработке ПО. Это очень отличающиеся обязанности и задачи.

Как становятся менеджерами продукта?

Иногда это происходит как спонтанное квантовое явление. Был некий человек, который сначала поработал инженером, потом стал тимлидом, потом руководителем проекта, нахватался навыков защиты финмодели и общения с поставщиками… И вот к нему приходит идея. Он несёт её руководителю, руководитель даёт ему задачу разведать область посильнее, далее делается расчёт, и вот уже через месяц-другой наш герой занимается реализацией проекта, который сам и придумал. Ещё не понимая толком, во что ввязался.

На деле, конечно, в 98% случаев на продакта надо учиться. Менеджером по продукту может стать руководитель проекта, тимлид, инженер, редко маркетологи (и почти никогда не может стать продавец).

На первом проекте будет море грабель, пота и слёз, будут детские косяки и непонимание базовых вещей, но в конце всё, скорее всего, сложится. Потому что энтузиазм. И в этот момент, когда стало понятно, что человек довёл проект до конца, в глазах учредителей компании и генерального директора он приобретает особую ценность.

Дело в том, что им не нужно руководить. Это руководитель команды, который умеет сам находить себе работу, обосновывать её выгоду для компании и сам делать. То есть тот, кто двигает бизнес вперёд. Естественно, ему даются ресурсы для всего этого.

Поиск идеи

Есть стратегия компании, есть рынок, есть все ресурсы компании (как материальные, так и в виде знаний и связей) — можно двигать горы. При определённом умственном напряжении. Поэтому первое, что делает продуктолог — это анализирует возможные направления «куда копать». Иногда у него есть вводные вроде «мы хотим захватить вот этот рынок за два года», иногда продавцы говорят, что клиенты спрашивают часто что-то новое для какой-то задачи.

Первая часть работы — проработка идеи. Это поиск возможных гипотез, попытка их подтверждения, анализ рынка — и создание идеи продукта. Генерация идеи — творческий процесс. Процедура превращения идеи в продукт для рынка — это процесс или проект, где много участников из разных подразделений компании и у каждого своя роль. Сам менеджер по продукту отвечает за концепцию продукта. Для доказательства идеи приглашаются архитектор, юристы, финансисты и другие люди, но продуктолог всем этим дирижирует. И за всё это отвечает. И обеспечивает взаимодействие между всеми.

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

Источники появления продукта обычно это:

1. Мировые тренды.
2. Потребности заказчиков.
3. Инженерные идеи.
4. Собственная длительная разработка, меняющая рынок, то есть поиск инноваций. Так часто делают НИИ, софтверные стартапы или крупные вендоры в своих внутренних «инкубаторах».

Защита идеи

Идею мало найти, надо её защитить. То есть приземлить и монетизировать. Надо четко понимать, как это продавать и кому. Начинается оценка рынка, технический маркетинг, составление бизнес-кейса. Нужно учесть расходы на технологии, проектирование. Продумать участие третьих сторон — партнеров. Узнать цены на всё. Получить оценки на разные части проекта. Договориться предварительно, собрать прайсы, посчитать железо и все ресурсы.

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

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

Для этого оценивается рынок: можно или поставить реалистичную цель вроде «хотим 10% от мирового рынка», или же экстраполируются данные текущих продаж, делается оценка по аналогам на западе. Большая аналитическая работа из серии вопросов на собеседованиях «Сколько каблуков в Харькове». Естественно, есть некие допущения, но они минимизируются разными инструментами.

Например, есть много PaaS и SaaS-сервисов. Мини-проект может выглядеть так: есть потребность в объектном хранилище с полной поддержкой Amazon S3 API — сколько клиентов перейдёт? Сделали оценку, пригласили — начали пользоваться.

С совершенно новой услугой сложнее всего. Часто надо пройти сотни клиентов с исследовательскими агентствами. Важно проверить прогноз и попасть в ожидания заказчика, может, даже сделать некий тест с заказчиком. А ещё само появление продукта на рынке меняет прогноз его потребления, но это отдельная история.

Реализация

Это работа проект-менеджера (хорошо, когда у менеджера по продукту есть отдельный проджект, это сильно облегчает жизнь) и архитектора. Мои коллеги по ссылкам очень хорошо всё расписали. По сути — рисуем план, собираем рабочую группу и арбайтен. Действуем.

Пока архитекторы, программисты и подрядчики выполняют свои задачи, продуктолог формирует тарифы, готовит комплект документации по продукту — sales kit и маркетинговые материалы по продукту (включая контент для сайта). Может совместно с маркетологом составлять план продвижения продукта.

Далее запускается тестирование перед приёмкой.

После приёмки

После приёмки продуктолог проводит обучение для продавцов и всем всё объясняет. Что за идея, кому нужна, почему крута, как продать.

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

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

Когда продукт сдан, менеджер по продукту продолжает его поддерживать. Часто нужно развитие и доработка, переработки пакетирования услуг. Кончается это обычно тем, что продукт инкапсулируется во что-то крупное или просто заканчивает свой срок жизни.

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

Сложности

Первое — нужно всегда быть в курсе всего, что происходит на рынке. То есть следить за новыми трендами. Чаще всего это море мусора, и выживают хорошо если 10% новых технологий. Но знать надо все, чтобы не пропустить что-то важное.

Иногда идея нового крутого продукта приходит во время реализации чего-то достаточно обыденного. Иногда приходится жертвовать и отдавать её другому продуктологу после защиты перед продуктовым комитетом. Жалко, но если вообще не делать — будет плохо.

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

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

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

Иногда нужна железная воля руководителя компании. Самые серьезные бои идут в области информационной безопасности. Причём как своей, так и заказчиков — например, в истории с облачными технологиями службы ИБ заказчиков относятся к внешнему с недоверием. Бывает и смешное: «А кто вендор? Иванов? Он нашего CSO в школе бил, работать не будем». Бывают вещи вроде «не используем беспроводные сети», «не работаем с вендрами на «М»» и так далее.

Как оценивают продуктолога?

• По срокам запуска сервиса. Если вовремя не вывести, компания понесет прямые или косвенные убытки.
• За доход. После запуска продукта продуктолог мониторит продажи и решает вопросы. Если не достигается плановый доход, выясняет почему это происходит, по чьей вине (у продавцов может быть свой план или сами продавцы могут не продать, или само продвижение продукта поставлено плохо). Если всё же проблема в продукте, составляется план доработок.
• За ценообразование: тарифы, маржинальность продукта.
• За формирование метрик SLA (за соблюдение отвечает уже служба эксплуатации).
• Ну и за качество идей новых продуктов. Точнее, идеи сами по себе никому не нужны — за качество сначала просчётов и защиты, а потом реализации.

Вместо заключения

Когда твой продукт работает — это еще не победа. Победа — это когда твой продукт приносит прогнозируемый доход. Каждый продукт это огромная история, где, с одной стороны, менеджером продукта просчитано всё от начала до конца и удалось добиться реальных финансовых результатов, а с другой — понимание, сколько ещё всего надо сделать!

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