Продакт vs. Проджект: чем отличаются профессии, которые часто путают

    Ольга Стратанович, Program Director в ProductSense и Chief Product Officer в «Киноплан», рассказала о ключевых отличиях в мышлении и навыках менеджера продукта и менеджера проекта.



    Профессия «менеджер продуктов» пока еще молодая в СНГ, но уже востребована на рынке. Компании с собственной разработкой ищут человека, который сможет выпустить и сопровождать продукт. Заказная разработка тоже нуждается в продуктовом подходе. Но хороших менеджеров продуктов на всех не хватает, поэтому возникает необходимость брать джуниоров из других областей.

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

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

    Зона ответственности


    Главные метрики успешности проекта — срок, бюджет и объем задач. Менеджер проекта должен получить требования от стейкхолдеров, согласовать бюджет и проследить, чтобы проект сдали в срок. Его не интересует, что произойдет дальше:
    — как конечный пользователь получит проект и будет его использовать,
    — как проект будет или не будет развиваться.

    Для менеджера продукта главное — донести пользу до клиента. Создание продукта — только небольшая часть ответственности менеджера продукта. Ему нужно думать о необходимости и эффективности функционала, «упаковке», доставке, сопровождении и развитии продукта.

    Генерация и валидация гипотез


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

    Основная задача менеджера продукта — выявлять потребности и предлагать идеи для улучшения продукта. Менеджер продукта много общается с пользователями, проводит глубинные интервью, выдвигает, проверяет и отвергает гипотезы. Все это он может выполнять даже без команды разработки. Он не знает, что ему делать, но ищет свой путь.

    Условия неопределенности


    Менеджер проекта действует в заранее обозначенных условиях: объем задач известен (его можно уменьшить, но не намного), сроки и бюджет согласованы. Обязанности менеджера обычно четко прописаны в гайдах, внутренних регламентах и правилах компании.

    Менеджеру продукта повезло меньше: он никогда точно не знает, что должен сделать. Какая гипотеза окажется провальной, а какая принесет прибыль? Здесь появляются MVP, экономические расчеты, метрики, A/B тесты, валидация прототипов — всё, что помогает оценить идею.
    Менеджеру продукта надо признавать провал экспериментов и безжалостно удалять функционал, который не приносит ожидаемой пользы. Ему приходится отказываться от собственных идей и пожеланий клиентов.

    Метрики


    На собеседовании я всегда прошу кандидата рассказать, какие метрики были у его последнего продукта или какие метрики он бы выбрал, если бы был владельцем продукта. Бывшие менеджеры проектов отвечают: «Количество пользователей» или «Мы прикручивали аналитику, но я туда не заглядывал».

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

    Экономика


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

    Для менеджера продукта окупаемость стоит на первом месте. Сколько мы потратим? Какую модель монетизации выбрать? Как привлекать пользователей и увеличивать Lifetime Value? Как получить дополнительную прибыль? Это вопросы, на которые мы ищем ответы постоянно.

    Продажи, внедрение и сопровождение


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

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

    Коммуникации


    Менеджер проекта принимает требования от стейкхолдеров и передает команде разработки.

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

    Стратегия и видение


    Менеджер проекта действует в рамках срока проекта — обычно он длится не более года. Цели чаще всего ставят владелец бизнеса или заказчики. Менеджер проекта управляет только контрольными точками в рамках этого срока.

    Менеджер продукта формирует собственное видение, куда движется его продукт и каким он станет через 1−3−5 лет. Он должен четко понимать, как та или иная задача приближает продукт к цели, и иногда жертвовать краткосрочными результатами.

    Риск-менеджмент


    Хороший менеджер проектов всегда думает о рисках и минимизирует их негативное влияние.

    Менеджер продукта думает о возможностях. Любая неопределенность или проблема — это потенциальная возможность улучшить продукт. Менеджер продукта думает, как извлечь дополнительную выгоду и сделать то, чего еще никто не делал.

    Вдохновление


    Менеджер проекта должен принести в команду хорошо описанную понятную задачу: Что делать? Как делать? В какие сроки делать?

    Менеджеру продукта надо «продать» боль пользователя и вместе с командой выработать оптимальное решение этой боли. Команде с продуктовым мышлением нельзя просто принести задачу — они начинают задавать сложные вопросы. Это очень хорошо для продукта, но требует от менеджера навыков продвижения своих идей, вдохновления команды, объяснения проблем.
    В бизнесе много говорят о продуктовом мышлении команд. Появляется определение продуктового инженера — разработчика, который не просто берет и делает задачу, но думает о пользователе, предлагает свои решения.

    Карта компетенций


    Профессия менеджера проектов давно сформировалась. Набор его навыков определен и понятен.

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

    Менеджер продукта «болеет» за продукт. Продукт плохо продается — это его проблема. Нужно идти в отдел продаж и выяснять причины, помогать построить процесс, подготовить маркетинговые материалы. Нет ресурсов на разработку — идти к HR (это не обязанность менеджера, но что если важные задачи тормозит нехватка разработчиков?). Нет дизайнера — рисовать макеты самостоятельно. Пусть это будет непрофессионально, но целью должен быть не идеальный макет, а польза для клиента.
    Важно, чтобы менеджер продукта мог сделать что-то самостоятельно, если делать некому, или найти человека, которому это можно делегировать. Менеджеру продукта нельзя говорить: «Это не моя обязанность, я не буду за это отвечать». Ему надо делать все возможное, чтобы продукт был успешен.

    Подведем итог


    У меня нет цели показать, что менеджеры продукта круче, чем менеджеры проекта. Я видела прекрасных продуктологов, которые никогда не смогли бы вести сложные проекты и писать подробные ТЗ. Я хотела показать разницу в мышлении и сфере ответственности. Если вы решите перейти из проектной разработки в продуктовую, вам придется:

    1. Мыслить за пределами разработки: что делать и как доставить пользу, а не как сделать.
    2. Генерировать, проверять и отсекать гипотезы.
    3. Смириться с неопределенностью и уменьшать ее.
    4. Ставить и анализировать метрики.
    5. Думать об окупаемости.
    6. Искать новые возможности.
    7. Научиться жить с возросшим числом коммуникаций.
    8. Формулировать и «продавать» свои идеи.
    9. Быть готовым разбираться с любыми проблемами в продукте.
    10. Брать на себя ответственность за успех или провал продукта.
    • +15
    • 4,7k
    • 9
    ProductSense
    63,00
    Компания
    Поделиться публикацией

    Комментарии 9

      +2
      как-то слащаво описано
      в реальности работа менеджера продукта это бег между стейкхолдерами и приоретизация тасков, которые стейкхолдеры накидали
      в любом продукте полно людей которые и без менеджера продукта генерируют идеи
        0
        Генерировать идеи не сложно. Сложно генерировать идеи, которые будут приносить пользу. И топить свои же идеи, которые пользу не приносят. Если продакт только бегает между стейкхолдерами и приоритизирует таски, то либо остальное за него делают другие, либо продукт будет себя чувствовать не очень хорошо (и обычно наступает второй вариант). Я бы такого человека назвала фиче-мастер, а не менеджер продукта
          0
          ну стейкхолдеры на то и стейкхолдеры чтобы не на пустом месте фичи придумывать а из реальных потребностей
        0
        Если ближе к середине в голове складывался образ доктора Октавиуса, то ближе к концу мне показалось что я читаю о Кларке Кенте в роли PM. Такие требования могут быть уместны на роль PM в самых топовых компаниях и их претендентов уж точно нельзя джунами заменить. Я бы добавил в конце, что это образ идеального PM с окладом от 120K$ в год минимум. Это бы помогло не только чувакам, которые так делают todo продукты, но и их будущим кандидатам. Вспомните историю, когда на роль создателя банера предявляются требования от компании google, на роль оптимизации графических интерфейсов построенных с помощью webgl. Иначе в разделе о руководящих должностях скоро будут появятся темы — «кто придумывает эти тупые не имеющие к реальности вопросы?»…
          0
          Не соглашусь. Как раз в больших компаниях круг обязанностей продакта сильно ограничен, потому что там много людей, роли между ними распределены. В небольшой компании ты как раз этим и занимаешься — всем, что необходимо для успешности твоего продукта. Ну или ищешь тех, кто этим займется. Я тут не про требования писала, а про реальность, с которым сталкиваются менеджеры продукта, когда погружаются в это. И самое страшное — это как раз разнообразие и количество задач, которые нужно сделать. Потом ты привыкаешь и понимаешь, что все это не страшно, но в самом начале это все очень сильно накрывает. Это то, что мне говорят все начинающие продакты
            0
            Как же не требования? Если вы перечисляете скилы PM, то разве это не означаете, что эти самые скилы будут требовать соискатели без опыта и понимания и небольшим бюджетом? Разве не эти требования приведут к тому, что чтобы устроится в зачухлую конторку нужно будет обладать скилами топовых менеджеров? И я соглашусь что в топовых компаниях PM не делают сами перечисленную Вами работу, но перечисленными скилами они обладать обязаны. А вот в конторах, где платят меньшие деньги, эти скилы не должны ставятся как преоритетные. Хочешь скилы, как в топовых компаниях, плати как в топовых компаниях. Разве нет? И да, статья классная и я с ней и с Вами согласен! Просто я обратил внимание на возможность недоразумения, к которому она может привести. Я даже пример привел с кретериями отбора в пятисортные конторки после публикаций требования топовых компаний на очень специфичные и сложные позиции. Первые не поняли о чем речь и требуют тоже самое что и вон те крутые чуваки. Спасибо за статью. С наступающим! Всех с наступающим!
              0
              Как я понял, это скилы так называемого «идеального кандидата». По факту будут выбирать из кандидатов, укладывающихся в бюджет и наиболее близкие к идеальному, причём это может быть и 10% от идеального.
          0
          Отличная статья! Люблю, когда написано понятно, изложение четкое, разложено по полочкам.
            0
            Спасибо за разъяснение! Хорошая статья.

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое