🌍 TPM в США, Европе, России: где ты работаешь, там ты и TPM

Продолжаем наш сериал про Technical Product Manager’ов. Сегодня поговорим про то, как TPM-роль устроена в разных странах и типах компаний.

Спойлер: везде по-разному. И это ок.

🗽 В Штатах TPM — это инженер с фокусом на продукт.
Сильно завязано на технический бэкграунд. Часто бывшие разработчики. Часто в FAANG-подобных компаниях: Meta, Google, Amazon и прочих. Там TPM — это glue role между продактом и инженерами. Он отвечает за архитектуру решений, roadmap фичей, stakeholder-менеджмент — но руками не кодит.

📈 В Европе TPM — это чуть ближе к платформенным продактам.
В большинстве европейских компаний TPM скорее про инфраструктурные решения, архитектурные вызовы и согласование кросс-командной работы. Может быть продактом внутренних платформ, API, data layer, IAM и прочих внутренних штук. Очень часто совмещает роли системного аналитика, платформенного продакта и деливери менеджера в одном лице.

🌍 В России (и странах постсовка) TPM — это почти всегда либо:
— продакт, у которого просто технарский бэкграунд (и его за это очень уважают);
— системный аналитик, который тащит на себе ещё и продуктовые куски, потому что “ну а кто ещё?”.
А иногда — разработчик, который стал писать задачи в джиру и стал продактом.

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

🏢 В корпорациях TPM — это менеджер зависимостей.
Если твоя команда делает кусок, который зависит от 8 других команд, и ты не хочешь превратиться в хаос — вот тут нужен TPM. Он следит за API, схемами, контрактами, SLA, и отвечает, чтобы всё приехало вовремя и не взорвалось.

💡 Общая идея — TPM закрывает дырку между продуктом и инженерией.
Где она будет — зависит от зрелости компании, состава команды, и просто от культуры. Где-то TPM будет про архитектуру, где-то — про delivery, где-то — про приоритезацию внутреннего техдолга, где-то — про API как продукт.

В следующем посте — разберём, какие скиллы нужны TPM и как их качать.

А у вас TPM чем занимается? Или, может, ваша команда сама решает без TPM? Поделитесь опытом — интересно, насколько у всех по-разному.