🧩 Ошибки начинающих TPM — и как их избежать
(из личных наблюдений и немного боли)

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

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

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

🔧 «Я пришёл из разработки — теперь буду всё контролировать»
И начинается: ревью каждой строки, диктовка архитектурных решений, участие во всех daily. В итоге ты превращаешься в микроменеджера, команда тебя боится, а никто не понимает, зачем вообще тут ещё и продакт.

📄 «Я пришёл из аналитики — сейчас всё опишу!»
50 страниц спецификаций, три версии диаграммы, обсуждения по каждой кнопке — и ноль понимания, когда и как это пойдёт в прод. TPM — это не архивариус, TPM — это драйвер. Надо не только понимать требования, но и доводить их до результата.

🧠 «Я слишком технический — про пользователей пусть продакт думает»
Так не работает. Ты всё ещё должен понимать, зачем мы вообще это делаем, для кого и какую боль решаем. Без этого ты не TPM, а просто техлид с расписанием встреч.

🚫 «Я больше не технический, я теперь про процессы»
Ошибка в другую сторону. TPM не обязан писать код, но и «не лезть в технику» — путь в никуда. Ты обязан понимать последствия решений, видеть узкие места и уметь перевести боль команды в действия.

💬 «Я веду 1000 обсуждений — но ни одно не довожу до конца»
Плохой TPM — это хаос. Хороший TPM — это glue, который сшивает всех и всё. Ты не просто созываешь митинг — ты обеспечиваешь, чтобы после него стало понятнее. Чтобы договорились. Чтобы пошли делать.

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

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