Я 7 лет работаю руководителем продуктовой разработки. Сейчас расскажу, на что это похоже.
Самое возвышенное и нежное существо на проекте — это архитектор. У него всегда мысль, пронзающая пласты веков. Но архитектор — это техническая специальность, и архитектор не может управлять проектом в том плане, что он не решает напрямую, что нужно будет пользователям. Это делает продакт-менеджер.
Продакт-менеджер сильно пересекается по функционалу со многими другими ролями. Может выполнять задачи руководителя проекта. И ещё делать кое-что до и после этого. Вот его функционал вкратце:
- Анализирует, что может понадобиться пользователям и исследует рынок. То есть придумывает идеи новых проектов и ставит им приоритеты.
- Совместно с техкомандой выбирает техническое решение.
- Просчитывает экономику продукта и определяет, стоит ли этим, вообще, заниматься.
- Собирает рабочую группу, ставит задачи архитекторам и остальным ключевым лицам проекта.
- Следит за всем-всем-всем по организации, в частности, отвечает за взаимодействие с партнёрами и вендорами.
- После внедрения сопровождает продукт, занимается его развитием и усовершенствованием минимум год.
- Время от времени просыпается ночью с горящими глазами и идеей нового продукта.
Продуктолог может получиться из руководителя проекта. На этой роли ответственности больше, но и кайфа, оттого что ты сам что-то придумал и создал это — море. Самое крутое в нашей работе — это взять команду и начать делать масштабные проекты, которые «взлетят». Это чувство окрыляет. Но и проблем в работе немало.
Важно: здесь и далее мы говорим про работу продуктового менеджера в сервисе, а не в разработке ПО. Это очень отличающиеся обязанности и задачи.
Как становятся продуктологами?
Крайне редко это происходит как спонтанное квантовое явление. Был некий человек, который сначала поработал инженером, потом стал тимлидом, потом руководителем проекта, нахватался навыков защиты финмодели и общения с поставщиками… И вот к нему приходит идея. Он несёт её руководителю, руководитель даёт ему задачу разведать область посильнее, далее делается расчёт, и вот уже через месяц-другой наш герой занимается реализацией проекта, который сам и придумал. Ещё не понимая толком, во что ввязался.
На деле, конечно, в 98% случаев на продакта надо учиться. Продуктологом может стать руководитель проекта, тимлид, инженер, редко маркетологи (и почти никогда не может стать продавец).
На первом проекте будет море грабель, пота и слёз, будут детские косяки и непонимание базовых вещей, но в конце всё, скорее всего, сложится. Потому что энтузиазм. И в этот момент, когда стало понятно, что человек довёл проект до конца, в глазах учредителей компании и генерального директора он приобретает особую ценность.
Дело в том, что им не нужно руководить. Это руководитель команды, который умеет сам находить себе работу, сам обосновывать её выгоду для компании и сам делать. То есть тот, кто двигает бизнес вперёд. Естественно, ему даются ресурсы для всего этого.
Поиск идеи
Есть стратегия компании, есть рынок, есть все ресурсы компании (как материальные, так и в виде знаний и связей) — можно двигать горы. При определённом умственном напряжении. Поэтому первое, что делает продуктолог — это анализирует возможные направления «куда копать». Иногда у него есть вводные вроде «мы хотим захватить вот этот рынок за два года», иногда продавцы говорят, что клиенты спрашивают часто что-то новое для какой-то задачи.
Первая часть работы — проработка идеи. Это поиск возможных гипотез, попытка их подтверждения, анализ рынка — и создание идеи продукта. Генерация идеи — творческий процесс. Процедура превращения идеи в продукт для рынка — это процесс или проект, где много участников из разных подразделений компании и у каждого своя роль. Сам менеджер по продукту отвечает за концепцию продукта. Для доказательства идеи приглашаются архитектор, юристы, финансисты и другие люди, но продуктолог всем этим дирижирует. И за всё это отвечает. И обеспечивает взаимодействие между всеми.
Продуктолог думает, кому нужен продукт, какой бизнес удастся привлечь, на какую долю рынка можно рассчитывать. Главное в идее — УТП, то есть уникальное торговое предложение. Иногда бывает так, что идея берётся уже имеющаяся, но на новом техническом решении, и это позволяет обеспечить куда более интересный функционал и фичи.
Источники появления продукта обычно это:
- Мировые тренды — мы в РФ отстаём от облачного рынка США и Европы примерно лет на 5, поэтому нужно смотреть туда. Например, году в 2010, когда продажи IaaS в Европе шли полным ходом, наши заказчики с подозрением относились к этому явлению.
- Потребности заказчиков. Продуктолог ездит с продавцами к крупным клиентам, заказывает глубинные интервью по потребностям, общается со специалистами в компании. Одни из самых опытных продуктологов — те, кто работал в целевой отрасли. Это хорошее подспорье для удовлетворения ожиданий заказчиков. Такой продакт точно знает, что и у кого болит, и созданные им продукты вызывают слёзы счастья у технарей из отрасли.
- Инженерные идеи. Бывает так, что в компании появляется человек, который говорит, вот тут у вендора новая технология, а давайте её слепим вот с этим — и получится что-то прикольное. Или инженер на спор собирает какую-нибудь адскую штуку в виде прототипа, а потом у неё находится неожиданное коммерческое применение. И так далее. Кстати, удачно найденная инженерная идея — это ещё редкая возможность для инженера попробовать себя на проекте, если душа лежит.
- Собственная длительная разработка, меняющая рынок, то есть поиск инноваций. Так часто делают НИИ, софтверные стартапы или крупные вендоры в своих внутренних «инкубаторах».
Защита идеи
Идею мало найти, надо её защитить. То есть приземлить и монетизировать. Надо четко понимать, как это продавать и кому. Начинается оценка рынка, технический маркетинг, составление бизнес-кейса. Нужно учесть расходы на технологии, проектирование. Продумать участие третьих сторон — партнеров. Узнать цены на всё. Получить оценки на разные части проекта. Договориться предварительно, собрать прайсы, посчитать железо и все ресурсы.
Например, чтобы запустить ТехноДиск (наш облачный файлообменник), мы развернули ИТ-инфраструктуру и софт, адаптировали на основе готового решения портал пользователя, интегрировали с ИБ и другими системами, проработали лицензионные соглашения, договоры с поставщиками и т. д. Всё это надо было заранее посчитать.
Потом проект защищается, потом идут детальные спеки, но в рамках бюджета, который был обоснован шагом ранее. Дальше дается согласование на закупку.
В подготовке бизнес-кейса самое сложное — спрогнозировать доходы.
Для этого оценивается рынок: можно или поставить реалистичную цель вроде «хотим 10% от российского рынка», или же экстраполируются данные текущих продаж, делается оценка по аналогам на западе. Большая аналитическая работа из серии вопросов на собеседованиях «Сколько каблуков в Екатеринбурге». Естественно, есть некие допущения, но они минимизируются разными инструментами.
Например, на базе нашего облака (IaaS) есть много PaaS и SaaS-сервисов. Мини-проект может выглядеть так: есть потребность в объектном хранилище с полной поддержкой Amazon S3 API — сколько клиентов перейдёт? Сделали оценку, пригласили — начали пользоваться.
С совершенно новой услугой сложнее всего. Часто надо пройти сотни клиентов с исследовательскими агентствами. Важно проверить прогноз и попасть в ожидания заказчика, может, даже сделать некий тест с заказчиком. А ещё само появление продукта на рынке меняет прогноз его потребления, но это отдельная история.
Реализация
Это работа проект-менеджера (хорошо, когда у продуктолога есть отдельный проджект, это сильно облегчает жизнь) и архитектора. Мои коллеги по ссылкам очень хорошо всё расписали. По сути — рисуем план, собираем рабочую группу и арбайтен. Действуем.
Пока архитекторы, программисты и подрядчики выполняют свои задачи, продуктолог формирует тарифы, готовит комплект документации по продукту — sales kit и маркетинговые материалы по продукту (включая контент для сайта). Совместно с маркетологом составляет план продвижения продукта.
Далее запускается тестирование перед приёмкой.
После приёмки
После приёмки продуктолог проводит обучение для продавцов и всем всё объясняет. Что за идея, кому нужна, почему крута, как продать.
Дальше продуктолог всех поддерживает и консультирует: может участвовать в продажах. Может ходить на конференции и клиентские мероприятия, чтобы там рассказывать про продукт.
Продуктолог ездит на продажи. Первые разы разбирается что и как. Получает обратную связь: как продается, что поправить, как продукт встречается с реальным миром. Нельзя просто взять и отправить продукт в свободное плавание.
Когда продукт сдан, продуктолог продолжает его поддерживать. Часто нужно развитие и доработка, переработки пакетирования услуг. Кончается это обычно тем, что продукт инкапсулируется во что-то крупное или просто заканчивает свой срок жизни.
Проект заканчивается приемкой, далее развитие услуги, может быть, новый проект или ведение бэклога. То есть по мере развития продукта после приёмки продуктолог тратит всё меньше времени на него, и всё больше на что-то другое, новое. Продукт-менеджер может вести несколько продуктов, например, несколько в сопровождении и развитии, один в запуске — новый.
Сложности
Первое — нужно всегда быть в курсе всего, что происходит на рынке. То есть следить за новыми трендами. Чаще всего это море мусора, и выживают хорошо если 10% новых
технологий. Но знать надо все, чтобы не пропустить что-то важное.
Иногда идея нового крутого продукта приходит во время реализации чего-то достаточно обыденного. Тут иногда приходится жертвовать и отдавать её другому продуктологу после защиты перед продуктовым комитетом. Жалко, но если вообще не делать — будет плохо.
Очень часто в обсуждении идеи продукта накаляется обстановка между продуктологом и инженером-разработчиком. Дело в том, что у разработчика может быть своё видение продукта, и он знает, как надо лучше. Часто это выражается в перфекционизме, но технический перфекционизм не всегда продается. Решается очень детальным объяснением, почему и какой продукт нужен рынку. И что стартовать надо с минимального пакета, а потом по мере развития заниматься навешиванием фич.
Иногда бывают эпические битвы архитекторов, у каждого из которых есть свой план реализации чего-то, и нужно отстоять конкретную технологию. Сложно понять, но побеждает не наиболее красивое, а наиболее функциональное и рациональное решение.
Редко бывает, что у инженеров, наоборот, не хватает знаний или опыта в конкретной области и тогда они пытаются убрать из продукта куски, где неуверенно себя чувствуют. Или частный случай — то, что инженеру кажется невероятно сложным, может быть вполне земным. Сложность в деньги не всегда выливается, поэтому иногда надо очень много думать и получать красивую реализацию. У меня был проект, где инженеры мне говорили, что это невозможно, а потом через несколько дней приходили и говорили, что придумали, как реализовать.
Иногда нужна железная воля руководителя компании. Самые серьезные бои идут в области информационной безопасности. Причём как своей, так и заказчиков — например, в истории с облачными технологиями службы ИБ заказчиков относятся к внешнему с недоверием. Бывает и смешное: «А кто вендор? Иванов? Он нашего CSO в школе бил, работать не будем». Бывают вещи вроде «не используем беспроводные сети», «не работаем с вендрами на «М»» и так далее.
Как оценивают продуктолога?
- По срокам запуска сервиса. Если вовремя не вывести, компания понесет прямые или косвенные убытки.
- За доход. После запуска продукта продуктолог мониторит продажи и решает вопросы. Если не достигается плановый доход, выясняет почему это происходит, по чьей вине (у продавцов может быть свой план или сами продавцы могут не продать, или само продвижение продукта поставлено плохо). Если всё же проблема в продукте, составляется план доработок.
- За ценообразование: тарифы, маржинальность продукта.
- За формирование метрик SLA (за соблюдение отвечает уже служба эксплуатации).
- Ну и за качество идей новых продуктов. Точнее, идеи сами по себе никому не нужны — за качество сначала просчётов и защиты, а потом реализации.
Ещё пара вещей
Когда твой продукт работает — это еще не победа. Победа — это когда твой продукт приносит прогнозируемый доход. Например, для меня облако Техносерв — это огромная история, где, с одной стороны, я просчитала всё от начала до конца и смогла добиться реальных финансовых результатов, а с другой — понимаю, сколько ещё всего надо сделать, например, обновление OpenStack.
Куда можно пойти из продакт-менеджера? В руководителя подразделения, директора портфеля продуктов, директора по развитию бизнеса, консультанта, пойти в продажи или открыть свой бизнес. Но это требует очень хороших навыков управления и общения, которые начинают быть актуальными, начиная с роли руководителя проекта.
Текст подготовлен Милой Лепехиной, продакт-менеджером Техносерв Cloud.
Автор: TS_Cloud
