5 отличий technical product manager от бизнес-ориентированного PM

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

Роль менеджера продукта в компании зависит от внутренней иерархии и сферы деятельности. Где-то достаточно одного менеджера, а в какие-то крупных корпорациях может работать целый департамент, в котором есть Product VP, директор продукта, product owner, менеджер продукта, junior PM или другие позиции. В технически-ориентированных компаниях и сфере разработки ПО все чаще встречается должность technical product manager. Чем она отличается от остальных продуктовых ролей?

image

Технический менеджер продукта


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

Это совсем не значит, что technical PM должен выполнять технические задания и находиться всегда “на одной волне” с разработчиками. В его работе нет кодов. Менеджер продукта не разрабатывает сам продукт, а осуществляет управление продуктом на разных его стадиях развития и координируют работу с разработчиками ПО в той же степени, что и с маркетологами, дизайнерами, sales-менеджерами. Оптимально, когда technical product manager сосредоточен на всех аспектах управления продуктом, а не на вопросах разработки.

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

При запросе technical product manager в социальной сети LinkedIn можно увидеть, что большинство из найденных менеджеров имеют техническое образование или профильные курсы.

image

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

image

Чем технический PM отличается от бизнес-ориентированного менеджера продукта?


Прежде, чем описать различия, обратим внимание на общие моменты, которые объединяют product manager и technical product manager: Оба управленца несут ответственность за следующее:

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

Теперь определим ключевые отличия.

5 отличий технического PM от бизнес-ориентированного


  1. Product manager “общего профиля” ориентирован на клиентов и участвует в определении общей стратегии продукта. Технический управленец, в большей степени, сосредоточен на возможностях и способах функционирования продукта или услуги, которой он/ она занимается.
  2. Менеджеры продуктов обычно вплотную сотрудничают с разными отделами и техническими и нетехническими членами команды. Они работают с маркетологами, sales-менеджерами, службой поддержки, финансистами, руководителями проектов, а также сотрудничают с внешними партнерами. Технический PM чаще находится в коммуникации с внутренними техническими командами, включая разработчиков, инженеров и тестировщиков.
  3. Проводя профессиональные исследования, product manager изучает диапазон конкурентов с точки зрения стратегического бизнеса и вывода продукта/ услуги на рынок, а technical product manager больше думает о новых тенденциях развития и технологиях, оценивают конкурентов в плане их технических возможностей.
  4. Чаще всего, образование менеджера продукта связано с бизнес-дисциплинами, в то время, как техническому управленцу продукта логичнее имеют степень в области инженерии, информатики и других технических дисциплин. Его навыки полезны для оптимизации приоритетов и планирования. Если есть четкое представление о том, как разрабатывается продукт, то тогда менеджеры могут оценивать риски определенных функций. Тесное общение с разработчиками помогает понять последствия определенных решений по продукту и достичь компромиссов.
  5. Technical PM хорошо разбираются в применении Agile или другой методологии, которую они используют. Многие технические PM приходят в product management из разработки и естественно знают в чем разница между Scrum или Kanban, однако углубляться в сложности и тратить время не на свои ключевые обязанности менеджера не стоит.

Как и любой управленец сегодня, технический PM нуждается в определенных онлайн сервисах и инструментах, которые помогают в работе.

Инструменты и сервисы для технического PM


Одним из главных инструментов в “обойме” менеджера продукта считается roadmap или дорожная карта продукта. Это стратегический документ, в котором они могут планировать цели продукта, фиксировать идеи, краткосрочные и долгосрочные инициативы.

Одной из первых крупных компаний, которая стала использовать план развития roadmap, была компания Motorola в 1970-х годах. С того момента все больше компаний стали обращаться к этому удобному инструменту визуализации.

В чем особенности технологическая дорожной карты и для чего она предназначена?


Технологическую дорожную карту (иногда — техническую) или technology roadmap иногда называют IT roadmap. В этой дорожной карте представляется ключевая информация, которая помогает IТ-специалистам принимать более эффективные решения в отношении технологий продукта. Особенность technical roadmap в том, что она рассчитана и на разработчиков.

Вести простую дорожную карту можно даже с помощью MS Excel. Однако сложные IТ-проекты и стратегии требуют тщательного подхода и применения специальных сервисов с удобным функционалом, таким, как Hygger, Aha, Asana, Trello и др. Командам разработчиков и менеджеру продукта технологическая дорожная карта помогает определить, какие технологии и когда следует применять, а также визуализирует график внедрения новых функций.

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

Технологические дорожные карты могут различаться по целям, стратегиям и участникам команд:
developers roadmaps, internal IT roadmaps, architecture roadmap, software roadmap, hardware procurement roadmap, и другие.

Два главных преимущества technology roadmaps


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

Компоненты technology roadmap


Чаще всего, technology roadmap включает в себя:

  • Цели продукта — это запланированные достижения, которые компании хотят достичь. Они могут быть краткосрочными и долгосрочными. Цели продукта основаны на его бизнес-возможностях.
  • Новые функции продукта, которые будут достигнуты и внедрены через применение технологий.
  • План релиза с поддержкой новых функций и возможностей. Обычно менеджеры планируют релизы за несколько месяцев.
  • Основные этапы или milestones — это ключевые ориентиры, которые должны быть достигнуты в процессе разработки. Заинтересованные стороны отслеживают milestones,, и это позволяет им видеть прогресс в достижении долгосрочных целей.
  • Ресурсы определяют участников для внедрения и обслуживания систем.
  • Факторами риска являются внешние и внутренние барьеры, которые могут препятствовать достижению целей и этапов в соответствии с технологическим планом.
  • Статус-отчет помогает информировать всех участников команды.

Для любой дорожной карты очень важна возможность поделиться ею. Эту возможность предлагает платформа для управления продуктами Hygger.io.

image

image

Сегодня можно встретить компании, в которых активно работают бизнес-ориентированный product manager и technical product manager. Но большинству компаний все же требуется один управленец, занимающийся продуктом.

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

Hygger

84,52

Hygger

Поделиться публикацией
Комментарии 2
    0
    никогда не понимал зачем нужен менеджер, который не технический — это большая трата времени на нахождения взаимопонимания с командами разработчиков.
    Он не может понять ни сложности разработки ни определить приблизительные сроки разработки.
    Из опыта точно знаю: нужен product owner и технический руководитель (иногда и архитектор по-совместительству — в небольших конторах).
    Не технарь PM — не нужен!
      0
      Статья про мою роль, про то, чем я занимаюсь каждый день. Пришел я в технические менеджеры продукта из прогеров, осознанно.
      Но! Не все так просто, как здесь описано. Из-за неимения возможности напрямую влиять на команду (уволить разгильдяев), не возможно эффективно следовать roadmap. Не имея стратегического видения продукта, т.к. продукт уже развит достаточно высоко — нет точного roadmap.
      В итоге — роль технического продукт менеджера офигенная, интересная, перспективная, но сильно зависит от команды, компании и многого другого.
      Так что если вы хотите перестать прогать или тимлидить и заняться управлением, — очень осторожно выбирайте продукт и компанию, вы будете зависеть от массы людей, с которыми у вас должно получаться взаимодействовать только win-win, иначе никак.

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

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