Привет, Хабр!
Меня зовут Даниэль Халиулин и должен признаться, что я 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 в Т-Банке. Благодаря твоим комментам статья получилась точно лучше, чем могла бы быть.