Когда TPM все таки нужен (а когда нет)

Пишу сейчас статью на Хабр про роль TPM (Technical Product Manager) - кто это, зачем нужен, как в нее попадают люди и все такое. И довольно продолжительное время пытался осмыслить какой-то ключевой фактор, который сильнее всего определяет, нужна такая роль в команде или нет.

Начал я с тезиса о том, что TPM нужен ТОЛЬКО тогда, когда пользователями продукта являются инженеры. Типа любой продакт должен знать своих клиентов, а тут вот клиенты технари, значит и продакт должен быть соответствующим. На что мои дорогие ревьюеры справедливо накинули мне пример продукта T-ID (Tinkoff ID) и его аналогов - система для упрощенной авторизации на сайте/приложении: заключаешь договор, подключаешь SDK в свой код и твои пользователи получают возможность залогиниться в два клика. Пользователями являются обычные люди, но продукт имеет явную техническую составляющую, которая сильно влияет на его развитие (инфра, SDK, комплаенс и т.д.). Соответственно, развивать такой продукт без технической насмотренности нельзя.

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

P.S. Кто готов поучаствовать в ревью статьи на Хабр - пишите в личку, я буду благодарен за помощь!😊