Привет, Хабр!

Меня зовут Даниэль Халиулин и должен признаться, что я Technical Product Manager (TPM) или технический менеджер продукта, если по-русски. Последние годы провел в этой должности на разных направлениях работы в Т-Банке. Одно время отвечал за направление производительности и надежности основного мобильного приложения - мобильного банка для физлиц. Другое время отвечал за продуктовое развитие главной системы наблюдаемости в компании - Sage. В этой статье я бы хотел рассказать немного о роли TPM: кто это такой и зачем нужен, какие основные навыки нужны для успеха в этой роли и как люди становятся TPMами. Все это по моему личному мнению, конечно.

Я надеюсь, что эта статья будет полезна таким людям:

• Инженерам и системным аналитикам, которым интересно прокачиваться в сторону "бизнеса", но при этом не хочется оставлять "технику". Для них статья подсветит еще одну возможную ветку развития.

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

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

Что ж, погнали.

Для начала давайте определимся...

Кто же такой TPM?

Technical Product Manager (TPM) - это менеджер такого продукта, для развития которого критически важны технические скиллы. TPM = Product Manager + Technical. По сути, это обычный продакт-менеджер, со всеми типичными для него навыками типа стратегирования, исследования пользователей, работы с данными, маркетинга и всего такого, НО, в дополнение, еще и с круто развитыми инженерными навыками. 

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

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

По опыту, такие инженерные продукты со временем могут перерастать в целые платформы, которыми начинают пользоваться другие команды в компании для реализации задач уже своих продуктов. Это умножает техническую сложность, которую надо уметь переваривать и учитывать в развитии своего технического продукта.

Кроме привнесения своего релевантного инженерного опыта, TPM компетентно реализует интерфейс общения с клиентами, а это отдельная наука. Простите, если это уже моветон, но «Если бы я спросил людей, чего они хотят, они бы сказали, что хотят более быстрых лошадей» - эту фразу приписывают Генри Форду и она замечательно иллюстрирует, в чем хитрость общения с клиентами. Одни клиенты просят сделать кнопку, другие приходят с проблемой и ждут ваших предложений о решении, кто-то говорит о третьем, а имеет в виду четвертое - все это будни продакт-менеджера, который общается с клиентами. Как доставать из клиентов информацию об их задачах? Какие вопросы задавать и НЕ задавать? Что из этого должно стать фичами продукта, а что ни в коем случае? Добавьте сюда еще то, что многие инженеры имеют собственный взгляд на коммуникацию и общение, и станет чуть более ясно, почему с ними должен общаться именно Technical PM.

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

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

Как можно понять, эта роль довольно специфическая, а значит актуален вопрос...

Где нужен TPM, а где точно нет?

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

Следствием является то, что TPM не нужен в большинстве IT-продуктов. Если ваши клиенты — не технические специалисты и не интегрируются с вашим продуктом через API, то скорее всего вы можете обойтись обычным продакт-менеджером.

Типичные примеры, где TPM избыточен:

• Мобильные приложения (кроме, пожалуй, совсем уж огромных приложений)

• CRM и HR-системы для бизнеса

• Интернет-магазины

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

Ок, а когда TPM все-таки нужен?

Получается, TPM нужен в двух основных сценариях:

1. Продукты для инженеров
Когда основные пользователи — разработчики, DevOps или другие технические специалисты. Для развития таких продуктов критически важно понимать их пользовательские сценарии "на кончиках пальцев", что обычный продакт-менеджер обеспечить не сможет в силу специфичности нужных навыков и опыта. При этом реализация их сценариев это почти всегда обуздание технической сложности. Я с трудом представляю себе обычного продакт-менеджера, который вникает в сценарий деплоя приложения, который ему надо понимать для разработки платформы автоматизации. Другие примеры таких продуктов: IDE, системы мониторинга, CI/CD платформы, всякие developer tools, облачные сервисы типа AWS.

2. Технически сложные продукты
Когда конечные пользователи — не инженеры, но продукт требует сложных технических интеграций, и его успех зависит от качества API/SDK/технической документации или других технических особенностей. В таких условиях и нужен человек, который совместит в себе продуктовый надзор и техническую насмотренность, чтобы итоговый продукт не был слишком перекошен в ту или иную сторону. Например, платежные системы: рядовые покупатели просто нажимают "Оплатить", но за этим стоят API для интеграций, SDK для партнеров, compliance требования (и вытекающие из них особенности обработки и хранения данных) и много других технических деталей, которые самым прямым образом влияют на бизнес.

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

Таким образом, ключевые сигналы о необходимости TPM — это когда глубокое понимание архитектуры критично для продуктовой стратегии и когда технические решения становятся частью ценности от продукта, а не просто средством реализации. Например, если вы делаете CDN, то выбор алгоритмов кеширования и предоставление возможностей их настройки для клиентов через API - это не просто "детали реализации", а вполне себе продуктовая фича.

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

Какими навыками должен обладать TPM?

Как я уже писал выше, TPM это вполне себе продакт-менеджер, со всеми присущими навыками для этой роли, но в придачу еще и с круто развитыми инженерными навыками. Поэтому требования к навыкам TPM являются, по сути, гибридом навыков продакт- и технического менеджера. Перед переходом к самим скиллам оговорюсь, что, как и в любой профессии, TPMы могут быть разных уровней с разной глубиной прокачки того или иного навыка, а также в разных компаниях могут требоваться или не требоваться те или иные навыки. При этом, по моему мнению, в природе не может существовать Junior Technical Product Manager - люди на этой позиции не могут быть "начинающими", они попадают в TPMы сразу с хорошим опытом в продактстве или инженерии.

Так что за навыки должны быть у TPM? 

Опущу всякие "коммуникабельности", "системные" и "критические" мышления, сфокусируемся на сути. Порядок случайный, не по приоритетам и не по важности т.к.   часто важность того или иного навыка специфична для компании. Например, шарить в АБ-тестировании хорошо, но я ни разу не видел, чтобы TPMы делал такие тесты регулярно. Что, впрочем, не означает, что такого не бывает. Итак, к навыкам.

1. Работа с данными

• Знать основные продуктовые метрики и уметь их считать и визуализировать

• Уметь писать SQL-запросы для загрузки нужных данных

• Уметь проверять на начальном уровне свои гипотезы на существующих и выявлять недостающие данные

2. Качественные и количественные исследования

• Уметь составлять правильные опросники для этих исследований, чтобы не смещать ответы на желаемые

• Уметь проводить разные типы качественных исследований типа JTBD-интервью, проблемных интервью, коридорок, тестирования прототипов и т.д.

• Уметь применять разные методы выявления и анализа требований к продукту типа JTBD, CJM, USM и т.д.

3. Экономика продукта

• Уметь посчитать сходимость экономики продукта, включая вложенные метрики типа CAC (стоимость привлечения платного клиента) и LTV (какую прибыль компании принёс клиент)

• Понимать, как влияют продуктовые решения на основные финансовые показатели бизнеса

4. Построение процессов

• Уметь визуализировать бизнес-процессы

• Уметь выявлять слабые звенья в процессах и предлагать улучшения

• Уметь внедрять процессы с нуля

5. Ведение проектов

• Уметь выявлять заинтересованные стороны проектов (RACI и т.п.)

• Уметь составлять план проекта и доносить его до заинтересованных сторон

• Уметь выявлять риски проекта и обрабатывать их

• Уметь балансировать 3 кита: сроки, стоимость и качество

6. Ведение переговоров, презентации, публичные выступления

• Уметь выявлять интересы сторон переговоров

• Уметь аргументированно вести устные и письменные переговоры

• Уметь достигать win-win решения в переговорах

• Уметь составлять и проводить презентации продукта/проекта/etc.

• Не бояться и уметь хорошо выступать на публике

7. Приоритизация

• Уметь применять разные подходы к приоритизации типа RICE, ICE и т.д.

• Уметь учитывать неочевидные факторы в приоритизации

8. Стратегия

• Уметь составлять стратегию развития продукта на N месяцев вперед и грамотно защищать ее

• Уметь доносить стратегию до команды и вдохновлять этим людей

9. Гипотезы

• Уметь корректно формулировать гипотезы по развитию продукта

• Уметь формировать критерии проверки гипотез (что докажет/опровергнет)

• Уметь быстро тестировать MVP / фичи

• Уметь масштабировать успешные гипотезы в стабильные решения

10. People-менеджмент

• Уметь в оперативное целеполагание на уровне месяцев и кварталов

• Уметь проводить полезные 1-1 встречи

• Уметь организовать процесс разработки на уровне хотя бы одной команды (по Scrum, Kanban по вкусу)

• Уметь мотивировать и развивать команду (в том числе через фидбек, рост зон ответственности и пр.)

• Уметь адаптировать стиль управления под разных людей и контексты

• Уметь решать конфликты внутри команды

11. Маркетинг

• Уметь сегментировать аудиторию продукта и адаптировать коммуникации под сегмент

• Понимать воронку привлечения и уметь находить точки роста в ней

• Уметь взаимодействовать с маркетинг-командой на уровне постановки и анализа результативности (например, запуск лендингов, email-кампаний, соцсетей)

12. CI/CD

• Уметь ориентироваться в CI/CD системах и понимать, что делают настроенные пайплайны

• Понимать жизненный цикл фичи от pull request до продакшена, где могут быть узкие места

13. Программирование

• Уметь программировать на базовом уровне хотя бы на одном языке программирования

• Уметь читать чужой код

14. System Design

• Уметь проектировать верхне уровневую архитектуру системы с учетом требований (C1-C2 уровень из модели C4)

• Уметь находить слабые места архитектуры и предлагать улучшения

• Уметь применять общепринятые архитектурные паттерны при проектировании (например, при сложном фронте предложить backend for frontend)

15. Технические метрики и мониторинг

• Уметь выявлять технические метрики, по которым нужно настроить мониторинг

• Быть способным оценить покрытие системы мониторингом, зная ее архитектуру

• Уметь применять все типы телеметрии (логи, метрики, трейсы и т.д.) для организации мониторинга

• Уметь участвовать в обсуждении SLO/SLA и влиять на них как продуктовая сторона

16. Базы данных

• Уметь аргументированно предложить выбор СУБД под задачу

• Уметь писать SQL-запросы

• Уметь компетентно вместе с инженерами решать концептуальные вопросы резервирования и производительности (типа знать, когда реплицировать, когда шардировать и т.д.)

17. Инфраструктура

• Уметь на базовом уровне понимать, как устроено продакшн-окружение: сервера, контейнеры, облака, балансировщики

• Уметь отличить проблему инфраструктуры от проблемы кода/продукта

• Уметь выходить из vim

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

Как становятся TPMами?

По моим наблюдениям в TPMы значительно чаще переходят люди из инженерии, чем со стороны "бизнеса". Типичные сценарии перехода такие:

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

2. "T-Shaped сеньор-помидор"
Зрелый состоявшийся инженер рассматривает возможности для дальнейшего развития, но не хочет уходить в тим-лиды, где надо непосредственно управлять командой. Продуктовое управление - хороший кандидат для прокачки в формате T-Shaped, тем более, что на Senior уровне вопросы про бизнес и клиентов это совершенно привычное дело. По ходу углубления в тему, он открывает для себя все больше возможности влиять на продукт на том уровне, который ранее был недоступен. Если ему это по душе или если он задумывается о перспективе получения более близкого к настоящему бизнесу опыта для своего гипотетического будущего стартапа, он решает перейти в TPM.

3. "Аналитик в тупике"
Системный аналитик, который тоже думает о дальнейшем развитии, оценивает разные ветки: 

• Двигаться ли ближе к "бизнесу"? Но тогда технические навыки будут ржаветь, а потом и вовсе атрофируются.

• Двигаться ли глубже в "технику" и расти в архитектора? Но тогда бизнес будет дальше, а это тоже интересно.

• Становиться ли менеджером других аналитиков? Но people management это специфичная история не для всех.

Вот тут и может появиться ветка развития в TPM.

4. "Медиатор бизнеса и инженерии"
Есть такие специальности, которые изначально находятся как бы на стыке бизнеса и техники, требуя от человека в той или иной мере участия в обоих сферах. Например, это могут быть ML-инженеры, аналитики или продакт-менеджеры - всем им особенно важно понимать не только бизнес-контекст, но и технические особенности и ограничения для успешного выполнения задач.
Люди из таких направлений могут не ограничиваются каким-то одним вектором развития, а пойти в ветку TPM, где обе этих "ноги" должны быть отлично развиты.

Что ж, в этой статье я постарался рассказать о том, кто такой TPM, где он нужен и нет, какие навыки ему нужны и как люди попадают в эту позицию.

P.S. Отдельное спасибо Марине Григорьевой - лидеру профессии TPM в Т-Банке. Благодаря твоим комментам статья получилась точно лучше, чем могла бы быть.