TPM — вроде бы «идеальная» позиция: ты понимаешь бизнес, шаришь в технике, умеешь говорить с командой и стейкхолдерами. Что может пойти не так?

Спойлер: многое.

За последние годы я видел (и сам проходил через) довольно типичные антипаттерны. Вот самые частые:

• 🔧 «Я пришёл из разработки — теперь буду всё контролировать" И начинается: ревью каждой строки, диктовка архитектурных решений, участие во всех daily. В итоге ты превращаешься в микроменеджера, команда тебя боится, а никто не понимает, зачем вообще тут ещё и продакт.
• 📄 «Я пришёл из аналитики — сейчас всё опишу!" 50 страниц спецификаций, три версии диаграммы, обсуждения по каждой кнопке — и ноль понимания, когда и как это пойдёт в прод. TPM — это не архивариус, TPM — это драйвер. Надо не только понимать требования, но и доводить их до результата.
• 🧠 «Я слишком технический — про пользователей пусть продакт думает" Так не работает. Ты всё ещё должен понимать, зачем мы вообще это делаем, для кого и какую боль решаем. Без этого ты не TPM, а просто техлид с расписанием встреч.
• 🚫 «Я больше не технический, я теперь про процессы" Ошибка в другую сторону. TPM не обязан писать код, но и «не лезть в технику» — путь в никуда. Ты обязан понимать последствия решений, видеть узкие места и уметь перевести боль команды в действия.
• 💬 «Я веду 1000 обсуждений — но ни одно не довожу до конца" Плохой TPM — это хаос. Хороший TPM — это glue, который сшивает всех и всё. Ты не просто созываешь митинг — ты обеспечиваешь, чтобы после него стало понятнее. Чтобы договорились. Чтобы пошли делать.

TPM — это не роль между. Это не медиатор. Это связующее и движущее. Glue & driver. Если хочешь быть полезным — не прячься за бэкграунд. Используй его. Но иди дальше. Так что если чувствуете, что роль СА вас ограничивает - велком в ТРМ!

Если было полезно — с радостью услышу в комментах и ваши грабли. Уверен, их у всех было достаточно.