Проджект менеджер в продуктовой компании

В продуктовых компаниях проджект менеджеры не нужны, их не надо нанимать, а всем менеджерам желательно переучиться в "продактов", "скрам-мастеров" и "тимлидов". Или нет? :)

Поделюсь мнением на основании 17 лет работы в ИТ (и последних 6 лет в продуктовых компаниях).

Дисклеймер: Я с 2012 Head of PM (product & project management), Head of Delivery. Работал как в крупных, так и в небольших продуктовых компаниях (СберЕаптека, 3Commas, N3 и прочих).

Это вторая статья цикла, в прошлой разбирали оценку эффективности продуктовых ИТ компаний.

В этой статье о:
Стереотипных и объективных взглядах на работу проджекта. Почему "проджект" - это не маньяк с диаграммой Ганта, а “интегратор” с agile-майндсетом и широким набором инструментов (и диаграмма Ганта в него тоже входит - не надо ее бояться)
Причинах, по которым продуктовые компании избегают слова “менеджер”
Роли проджектов на примере Google и в глазах авторов Agile фреймворков (SAFe)
“Триаде” - как основном месте приложения усилий проджекта в продуктовых компаниях
Роли тимлида (уделим отдельное внимание тому, противопоставляется ли она проджекту)

Кто такой проджект менеджер “здорового человека”?

Компактно и емко навыки менеджера проектов ("проджекта") сгруппированы в "skillset" от PMI - talent triangle.
Согласно "треугольнику талантов" 3 группы навыков должны быть развиты у любого проджект менеджера:.

1. Hard skill (ways of working)
Это, в том числе и знание ключевых современных методологий и подходов (Scrum, Kanban, классического проектного подхода и прочих), и связанное с этим умение организовать работу в команде, приоритеты, планирование и сбор метрик, работу с рисками, улучшение процессов и так далее. Равно как и умение измерять собственную эффективность (статья про эффективность).

2. Soft skill (leadership / power skills)
Тут предполагаются навыки коммуникаций, развитый эмоциональный интеллект, эмпатия, навыки фасилитации, проведения ретро, работы с конфликтами, работы с мотивацией, работы с людьми 1:1 и так далее. Один из моих любимых вопросов на собеседованиях менеджеров - "Какие способы НЕфинансовой мотивации вы знаете/чаще применяете, если можно - с примерами" (по ответу обычно понятна реалистичность взглядов на то, что движет людьми в ИТ-команде, а это косвенно выдает прокачанность soft skill).

3. Business skill (business acumen)
Менеджеру важно понимать: что и для кого делаем (продукт, рынок, ниша). С кем интегрируемся, кто наши партнеры и конкуренты. Что важно для наших пользователей сейчас и что будет важно через год. Бизнес-грамотность необходима для понимания контекста, рисков, приоритетов - понимания, почему в компании принимаются те или иные решения, влияющие на проект. Все это помогает общаться со стейкхолдерами на разных уровнях.

Из трех групп навыков складывается классный “проджект”. Он умеет структурировать хаос вокруг себя, объединять команду, помогать ей справляться с кризисами и устранять препятствия. И "держит фокус" - не дает уйти в перфекционизм или как-то еще отклониться от цели.

Rita Mulcahy (признанный эксперт в менеджменте и проектном управлении):
"Одно слово, которое лучше всего отражает суть роли менеджера проектов - интегратор”.

Именно "интеграция" лучше всего отражает идею управления проектами.
Запрос на того, кто объединит людей, организует процессы, поработает с рисками, сделает команду эффективной в условиях высокой неопределенности, причем, в коллективе, где собраны профи из самых разных областей (инженеры, дизайнеры, аналитики, маркетологи и т.п.)

Запрос не на "босса-командира", а на интегратора есть и в "классических", и в продуктовых компаниях.

В чем особенность менеджмента в продуктовых компаниях?

Как бы все работало в "классических" компаниях?

Компании, в которых акцент сделан на классическое проектное управление, обычно работают на заказ или используют проекты, чтобы улучшить/создать что-то новое внутри себя (например, обновить внутренние информационные системы, внедрить новый ИТ-модуль на складе, открыть новый филиал и т.п.)

Такие проекты должны как минимум:

достичь цели
“попасть в треугольник” (сроки, деньги, содержание)
удовлетворить ожидания главных стейкхолдеров (причем не только и не столько “больших начальников”, но и ключевых пользователей)

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

Что иначе в продуктовых компаниях?

Задача продуктовой компании - создать продукт(-ы).

Сам этот продукт не имеет заказчика. Его делают “для рынка”, где он должен понравиться пользователю.

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

Впрочем, классическому управлению проектами в продуктовых компаниях находится место.

В продуктовой разработке мы не знаем на 100%,что именно нужно сделать, чтобы идеально “попасть” в аудиторию. Если бы это было иначе, то и “плановая экономика” возможно имела бы хорошие шансы обходить рыночную, однако, мировая история пока уверенно свидетельствует об обратном.

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

Для продуктов повседневного использования среди таких метрик - retention ("удержание” пользователей) и ее производные. Грубо говоря, достижение определенных и стабильных значений retention - показатель того, что продукт регулярно решает какую-то задачу пользователя. И наоборот (если только речь не идет о каких-то заведомо-одноразовых продуктах, вроде мобильного приложения для конференции).

Итак, принцип “не проверишь - не поймешь” является определяющим во вселенной создания продуктов, влияет на организацию всех процессов в ИТ-компаниях.

Фирмы, ориентированные на продукт, как правило:

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

Производят замеры даже до прототипа (через опросы, анонсы и анализ кликов, "фейковые" посадочные страницы для сбора статистики и так далее)

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

Из-за описанной выше специфики именно Agile-образ мышления (майндсет) получил в продуктовых компаниях самое широкое распространение. Основанные на нем методы и фреймворки (Scrum и просто близкий по духу Kanban - строго говоря, последний не относят к Agile) легче сочетаются с итеративностью, частой проверкой гипотез и так далее. Классическое управление проектами (с описанным выше "тройственным ограничением") используется лишь от случая к случаю, когда иным способом и с использованием лишь agile-подходов - справиться с задачей невозможно (об этом ниже).

Естественный акцент на роли продакта и частом тестировании гипотез подталкивает к очевидному решению:
команды сделать маленькими (до 7-8 человек)
сами команды сделать, насколько возможно - "самоорганизованными" и стабильными (без ротации, чтобы люди по-минимуму отвлекались)
наперед и “вдолгую” ничего не планировать (или хотя бы не тратить на это много сил)
сформулировать глобальную цель или видение (vision) и двигаться к нему маленькими шагами (итерациями или иными “релизами”), держать размеренный темп

Если все перечисленное получается - со временем формируются сплоченные agile-команды . Они постепенно отбрасывают неудачные идеи в попытке сделать конкурентный продукт.

В таких командах нет острой потребности в менеджерах. Коллектив маленький, стабильный, а планирование ведется “в короткую” (на несколько итераций - читай на 1 - 1,5 месяца вперед). Так что менеджеров обычно замещают “фасилитаторы” (например, Скрам-мастера).

Задача фасилитаторов (Скрам-мастеров) - помогать команде придерживаться минимально-достаточных правил и организовывать / поддерживать / модерировать митинги, ретроспективы и другие обсуждения. Тут требуются почти исключительно софт-скиллы (навыки коммуникации, эмпатии).

По моим наблюдениям, сегодня Скрам-мастер - привлекательная позиция для тех ,кто хочет “войти в ИТ” (инженерных и иных специальных знаний, навыков такая роль не требует и позволяет “нахвататься” ИТ-шной специфики уже в процессе). Порой проджект (с трем и более годами опыта) на такой позиции быстро “скисает” и демотивируется. Ведь из трех реальных групп навыков, которыми он обладает, задействуется лишь один, да и то, как правило, в сработавшихся самодостаточных командах - не на полную катушку. А, согласно Михай Чиксентмихайи (см. “Поток” / “Flow: The Psychology of Optimal Experience“), нужная концентрация и вообще удовольствие от работы возникают, когда большинство задач соответствуют нашим навыкам: не слишком простые и не чрезмерно сложные.

Формулирование же и проверку идей (гипотез, фичей) обеспечивает так называемый "продакт".
Делает он это через А/Б тесты для потенциальных обновлений или прототипов , "ранние запуски" в регионах, где низкая стоимость привлечения пользователя (cost per install - CPI), непрерывный сбор и анализ установок, заходов, кликов, "отвалов" и так далее. Серьезную поддержку продакту, обычно, оказывают дата-аналитики, дизайнеры, маркетологи..

Далее я буду чаще использовать именно сленговое "продакт" вместо Product Manager и Product Owner. В некоторых компаниях эти термины- синонимы, в других, между ними огромная разница (в одних фирмах менеджер продукта понимается как более ответственная и широкая роль, чем PO, в других- наоборот). Но, независимо от подобных пристрастий, практически все сходятся на одинаковом именовании "самого главного продакта в компании" - Chief Product Owner (CPO).

Когда же проджект менеджер незаменим в продуктовых компаниях?

Потребность I - масштабирование

Как обсуждали выше - на уровне отдельной команды в 8 человек проджект-менеджер обычно не нужен. Но что происходит, если 3-5 небольших команд работает в рамках одного домена, одного блока продукта? И разработки одной команды могут блокировать (или ожидаться) другими командами? Что делать, если поставленной общей цели можно достигнуть только тщательно скоординировав усилия?

Нет, вовсе не обязательно рисовать план проекта с помощью диаграммы Ганта. Но важно учесть риски, зависимости, банально подумать, кто и когда может уйти в отпуск, в какой момент этой группе команд потребуется привлечь юриста для формирования legal texts или маркетолога, чтобы те успели подготовиться к привлечению трафика или наоборот, не совершили фальстарт в случае пробуксовок в разработке, организовать заранее DevOps инфраструктуру и убедиться в готовности в нужный момент и так далее.

Многие agile подходы фокусируются только и исключительно на маленьких командах и группах, дают хороший рецепт как самоорганизоваться (т.е. работать без менеджера). Сложности возникают при масштабировании. И решаются эти сложности добавлением "интегратора", обладающего hard, soft and business skil и работающего фулл-тайм.

Процитируем сотрудника Google, одного из преподавателей Google Project Management (сертификационный курс для руководителей проектов от одной из самых известных продуктовых компаний):

“Project management's a huge part of Google. But here, many of our project managers are described as "program managers," because they manage multiple projects for specific products, teams, or programs. [...]”

Гугл активно использует управление проектами. Но менеджер там закономерно стоит “на ступеньку выше” (не иерархически, а организационно). Менеджеры проектов в Гугл, как и во многих похожих компаниях - это Program Managers (менеджеры программ).

Программа, в свою очередь (тут определение Гугл никак не отличается от PMI), это совокупность проектов (и не только), объединенных вместе потому ,что так ими проще управлять.

Простой пример программы: вы запускаете программу лояльности для авиапассажиров. Она включает выпуск членских карт для постояльцев, модернизацию сайта и обоих мобильных приложений (под Android и IOS), открытие отдельной линии поддержки в колл-центре (включай найм и обучение сотрудников), а также производство и показ рекламы в интернете, TV, на улицах и в аэропортах.
Все это отдельные проекты, которые полезно скоординировать и управлять сообща. Чтобы не возникло рассинхрона между сайтом и приложениями, чтобы не допустить фальстарта или задержек с рекламой и т.п.

Из моей практики - о подобии программы в продуктовых компаниях можно говорить, когда происходит масштабирование и некогда компактная команда теперь достигает 20+ человек и состоит из 3 и более коллективов, делающих что-то логически связанное. Тут и потребуется фулл-тайм менеджер.

В одном из самых популярных фреймворков для масштабирования Agile-подходов : SAFe (Scaled Agile Framework) можно проследить похожую логику. На уровне базовых agile-команд роль менеджера отсутствует (есть скрам мастер). "Интегратор" появляется выше, на уровне delivery, в составе “тройственного союза”.

Триада вообще очень популярный концепт в управлении продуктами (встречается и у Google, и у SAFe, и в других подходах, разбирать которые тут мы не будем).

В общем виде триаду обычно составляют:

Техлид - отвечает за качество разработки / качество кода (находим оптимальные способы технической реализации, пишем хороший код, хорошо его документируем, проверяем, публикуем).
Продакт - отвечает за продуктовые решения и гипотезы (делаем ли “правильный продукт” - тот что нужен пользователю и радует нас своими показателями)
Проджект - “интегратор”, удерживает в поле зрения планы, настраивает процессы, вовлекает коллег и проактивно решает проблемы.

В каждом конкретном подходе терминология может и будет отличаться. Например, на языке SAFe: Техлид = System Architect, Продакт = Product Manager, а Проджект = The Release Train Engineer (RTE).

То, чем все они рулят, на языке Гугл называется программой, а в SAFe - замысловатым термином “The Agile Release Train (ART)” https://scaledagileframework.com/release-train-engineer/

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

Потребность II - кросс-командные взаимодействия

Ад любого менеджмента - это “стыки”.

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

из других продуктовых команд
из технических команд (например, они совершенствуют ядро продукта: отвязываются от “монолитной архитектуры”, создают новый API и т.п.)
системных команд (стандартный термин, он может обозначать, например, команду объединяющую DevOps и QA-automation инженеров которые помогают продуктовым и техническим командам)
других подразделений (юристы, "безопасники", саппорт и многие другие, кто обычно не входит full-time в состав перечисленных выше команд)

Избежать на практике кросс-командных зависимостей практически невозможно.

По мере роста бизнеса и развития продукта команда неизбежно сталкивается с противоречием "оставаться ей компактной" или "быть автономной".

Тех же юристов, финансистов, DevOps инженеров, технические команды, не говоря уже о членах других продуктовых групп, приходится периодически вовлекать в работу. А значит и количество кросс-командных зависимостей неизбежно множится и никакое “переструктурирование”, “уплощение структуры” от этого в полной мере не избавит. Но избавление и не требуется.

Нужен человек, который привык иметь дело с большим количеством зависимостей. Привык учитывать специфику работы других, договариваться о правилах, совершенствовать процессы, следить за такими "стыками" и проактивно отслеживать “поломки” и “пожары”, выявлять корневые причины и т.п.. А главное, сочетать навыки коммуникаций (soft-) с необходимыми hard- и business-skill. .

Мы говорим об "интеграторе", как бы не называлась его роль (project manager, или program manager терминологии PMI, RTE в SAFe и так далее).

Потребность III - классические проекты в продуктовой компании

Классические проекты - не нонсенс в продуктовой компании. Однако часто коллеги, находясь в agile-окружении. даже не предполагают, что какие-то задачи можно и нужно решать с помощью диаграммы Ганта. Автоматически применяют доски и бэклоги (а ведь у них есть свои границы применимости).

Поясним на примере.
Представим “рождественскую распродажу” глазами компании, которая разработала интернет-магазин и теперь хочет устроить акцию. ИТ-решение включает: сайт, приложение и разветвленную ERP систему для складской и транспортировочной логистики.

В рождественскую неделю дизайн сайта и приложения должен временно измениться.
В магазине для клиентов будут доступны уникальные предложения скидок (которые должны завершиться в определенный день и час), а пользователи увидят изменения в личном кабинете, получат рассылки, обретут возможность просматривать акционные предложения от некоторых магазинов и т.п.
Кроме того, по ходу акции мы хотим очень тщательно собирать аналитику (кто и куда заходит, пользуется акционными купонами, как меняется retention и выручка до, во-время и после распродажи и т.п.).
Предположим вдобавок, что заказы, которые отправляются с наших собственных, а не партнерских складов - мы будем заворачивать в особую упаковку и снабжать персонифицированной открыткой.

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

В такой работе, весьма вероятно, обнаружится много рисков и зависимостей.. Нельзя запустить рекламу раньше, чем обновятся приложения и окажутся доступны промокоды, скидки и т.п. Чтобы отразить нужную последовательность потребуется нечто большее, чем просто бэклог. Недостаточно будет просто добавить нужные "таски" с говорящим ярлыком, вроде “Christmas sale”. Потребуется, как минимум, собрать ключевых представителей команд, составить и согласовать общий план, объединиться для дальнейшей координации (в чатах и на минимально-достаточных митах) и не только.

Вот это сочетание: жесткие дедлайны, очень разнородные команды, высокая неопределенность, зависимости, риски - все это признаки классического проекта. Да, вот так внутри продуктовой компании появляются классические проекты.

И важнейший инструмент в управлении ими, как ни странно - диаграмма Ганта. По моему опыту, при всей интуитивности “Ганта” невозможно хорошо составить ни с первого, ни с третьего раза. Нужна определенная насмотренность. И она, по всей вероятности, лучше всего развита у проджект менеджера. Именно он - наиболее вероятный кандидат в “интеграторы” и вообще, в лидеры такого проекта.

Таким образом, проджект менеджер незаменим в продуктовых компаниях, для решения “интеграторских задач”.

И это не все потребности

Не буду перечислять остальные случаи, думаю, главная идея понятна. Роль проджекта в продуктовой компании - это роль “интегратора”.
Несколько таких интеграторов (ПМ-команда) хорошо стабилизируют компанию, помогают работать слаженно, не буксуя с координацией, коммуникациями, улучшением процессов.

А почему в половине продуктовых компаний проджект менеджеров называют как-то иначе?

Перенесемся мысленно на 15-20 лет назад, когда идея Agile-майндсета, повсеместно используемого в продуктовых компаниях, только набирала популярность.

Одним из первых, широко распространившихся фреймворков был Scrum (Скрам).

К сожалению, в первые годы завоевания рынка и симпатий в ИТ, авторы “евангелисты” Скрам продвигали не только хорошие стороны фреймворка, они еще и боролись с воображаемым врагом. Собирательным образом такого “врага” был закостенелый в своих убеждениях, инертный и токсичный корпоративный менеджер. Чуждый духу сотрудничества, отвергающий саму идею вовлечения пользователя, раннего тестирования гипотез и так далее.

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

Базовые принципы эффективного менеджмента были изложены за сотни лет до возникновения Скрам, а применительно к ИТ в 1970 году, например, о них писал Уинстон Ройс. Он критиковал неадекватные подходы и предлагал вовлекать пользователя ("Involve Customer") и совершенствовать софт, используя циклы обратной связи (принцип "Do it twice").

Период примерно с 2010 по 2016 оказался наиболее жарким по части критики "менеджеров". Некоторые компании стали избегать термина manager - чтобы снискать больше популярности у ИТ-специалистов на высоко конкурентном рынке.
Представление о менеджере, как о чем-то неактуальном, едва ли не вредном, получило широкое распространение. Усилили эффект идеи “плоских оргструктур” и “бирюзовых организаций”, в которых, впрочем, потребность в роли “интегратора” ничуть не ниже, а порой и намного выше.

“Под общую гребенку” досталось и менеджерам проектов. Ведь их роль содержит слова менеджер, что с легкой руки некоторых agile-евангелистов интерпретировалось как “командир” или “начальник”, а в маленьких и самоорганизованных командах такие не нужны.

Позднее, тенденция существенно спала. Отчасти потому, что выяснилось то, о чем мы писали выше (без интегратора ни масштабироваться, ни управлять разношерстными “стыками” и действительно большими проектами практически невозможно). А доверие к плоским и самоорганизующимся структурам подрывали кейсы вроде Valve: с маркетингово-ориентированными текстами про магию плоских структур и самоорганизации - [2013 ENG], [RUS] и последующее разоблачение (2018 - ENG), [RUS], [RUS-2]

В 2023 многие команды по инерции избегают употреблять слово менеджер, хотя именно его и имеют в виду. Получается, как в Гарри Поттере - есть “тот кого нельзя называть”, и любые разговоры о нем нужно вести, используя синоним слову менеджер.

Сейчас примерно половина продуктовых компаний любого размера, например, Google, Wargaming, Semrush и многие другие, спокойно и уверенно используют project и program manager.

Компании, применяющие Канбан метод также спокойно опираются на предложенные Дэвидом Андерсоном в кратком руководствуйтесь по Канбан от 2016 года (“Essential Kanban Condensed)” две необязательные роли: delivery manager и service request manager.

На практике request manager выступает хоть и не полным, но достаточно близким аналогом “продакта”, а роль delivery manager часто поручают как раз “интегратору”.

Другие компании используют термины lead/leader, champion и другие. Напомню, что я обещал не погружаться в специфику противопоставления менеджмента и servant leader-ства. Просто упомяну, что во многих компаниях перечисленные ниже роли де-факто являются синонимами менеджера проектов, где нужен не просто "лидер-слуга команды", но опытный профессионал со сбалансированными hard-, soft- и business-skills и хорошей насмотренностью.

Не походят на нее, например, коллеги, которые свою работу видят, как “диктат начальника над подчиненными”, но на них мы договорились в этой статье не останавливаться.

А кто такой тимлид?

Некоторые источники трактуют роль тимлида очень широко. Так например, сайты вакансий - payscale и hiring.monster фактически не видят разницы между тимлидом и проджектом (а иногда, и аж с руководителем портфеля)

Глоссарий Disciplined Agile дает очень общее определение и фокусируется в роли тимлида на поддержке самоорганизующихся команд.

Есть мнение, что в SAFe тимлид фактически соответствует роли Скрам-мастера / team coach в самоорганизованных Agile-командах. Т.е. фактически не является менеджером, а относится к фасилитаторам (и тоже servant leader), которые в минимально-достаточной степени поддерживают самоорганизацию команды. Мне наиболее близок именно такой подход.

На практике мы с коллегами обычно исходили из того, что тим-лиды это такая “точка кристаллизации для agile-команд”. Обычно это играющие тренеры - программисты, аналитики или дизайнеры, которые в дополнение к основной работе подхватили “в нагрузку” еще и работу с командой (коммуникации, проведение 1:1, решение простых вопросов и конфликтов и опять же минимальное соблюдение правил работы - чтобы карточки задач передвигались в таск-трекере, чтобы команда не брала чрезмерное количество задач, пока не завершит текущие и тому подобное).

В наших командах тим-лид это не фулл-тайм менеджер, но скорее лидер по призванию, совмещающий функции "лидера" с основной работой. Де факто он - главная опора проджекта в командах, главный и "естественный" союзник.

Обычно проджект определяет вместе с тимлидом чем тот реально может ему помочь.
Сможет проводить 1:1 сам? Отлично. Нет - значит в какой-то степени их подхватит проджект.
Может сам настроить канбан-доску в Jira? Ну а уж минимальную "гигиену" смены статусов и комментирования задач-то точно может обеспечить? Супер, с остальным поможем.

Обычно связка проджекта и тимлида очень крепкая.

Если тимлида в команде нет и пока никто не выдвинулся - значит, перечисленные hard- и soft-skill активности останутся на плечах проджекта. И наоборот, при поддержке тимлида проджект сможет больше сфокусироваться на "интеграции" в команде-команд.

Пять итоговых тезисов

Итого, в продуктовой компании:
"Проджект" - это “интегратор” с agile-майндсетом и сбалансированным набором soft-, hard- и business-skills), о конкретных скиллах поговорим в другой статье (не душный маньяк с клыками и диаграммой Ганта)
Продуктовые компании иногда вообще избегают слова “менеджер”, а иногда уклоняются от самой формулировки project manager, заменяя ее на delivery manager (в Канбан), release train engineer (SAFe), program manager (Google) и другие.
Над продуктовыми задачами project manager, как правило, работает в составе "триады", вместе с "product manager" и "technical lead". Особо сильно запрос на работу проджекта возникает, например, при масштабировании, при необходимости управлять кросс-командными зависимостями, при реализации крупных инициатив с жесткими дедлайнами и вовлечением множества команд.
Усилия проджекта востребованы не на уровне самоорганизованных Agile-команд, а выше - Agile Release Train в терминологии SAFe или Program в терминологии Google.
Тимлид в одном из вариантов понимания этой роли - важная опора и соратник проджекта в самоорганизованных Agile-командах

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

Иван Селиховкин https://www.linkedin.com/in/selikhovkin/