eRKa

Если время на фичи выделите Вы, с большой долей вероятности, это время будет провалено. Задачи должны оценивать те, кто эти задачи будет выполнять. Судя по вопросу, Вы не в курсе возможностей своих отделов, нюансов реализации и т.д., значит не сможете адекватно оценить их затраты по времени. Когда поработаете с ними пол годика-год, тогда, возможно, Вы и станете понимать на что они способны и какие типовые задачи за сколько сделают. Ключевое слово "ТИПОВЫЕ", т.к. на нетиповые неопределенность временных затрат резко возрастает.

Быть pm это только дело опыта, а не книг и видосиков. Хотя бы опыт в управлении своих опенсерс проектах.

Я для себя давно вывел: хороший начальник всегда сможет быть хорошим подчиненным, хороший подчиненный не всегда сможет быть хорошим начальником.

Потому, что начальник в курсе, какие должны быть подчиненные, чтоб контора работала как по маслу, он видел их сверху, он руководил и знает все грабли и проблемы, подчиненный - это всегда исполнитель, но думает, что ему виднее. У каждого своя зона ответственности.
Программист отвечает за свой код, манагер за то, как он понял заказчика и что он предложил к реализации. Манагер видит проект сверху, у него есть понимание как все должно выглядеть. Манагер поставил задачу, он видит проект целиком, он знает чего хочет. Если он полезет к кодеру рассказывать как классы должны быть связаны и какие патерны использовать, то это не его зона ответственности, но если прогер начнет рассказывать надо делать спа или нет, то это не его дело.
Каждый получает по шапке за свою работу. Если манагер сказал, будем делать спа и от этого цена разработки увеличилась вдвое, а заказчику все равно, да и в тз это не указано, то по шапке получит манагер, поэтому прогера это не должно интересовать. Если на странице полезли баги, то вопрос к компетенции тех, кто кодил и это не вина манагера.

В общем мой совет: не парьтесь тем, что делает менеджер, парьтесь задачами за которые Вы отвечаете.