How to provide help to Technical Product Manager with regards to filtering incoming requirements

Question

TLDR: Working in Switzerland, in a company writing software with long time support and continuous improvement (support more than ten years). How can you provide all the necessary tools to the (sometimes stubborn) product manager so he can correctly filter between all new incoming requirements?

I am working in a company in the Switzerland for the past 9 years now in a team of 7. The software we are writing is quite complex due to the problem we are solving. Recently a new team member took the role of Technical Product Manager (let's call him John) which means for our team that all new requirements must go through his approval. He then evaluates the importance of the requirements, assesses whether it should be done or not and give a first estimate. It is his first role as Technical Product Manager.

The problems:

• John does not know everything about the application and does not have all the knowledge/tooling/background to decide correctly what should be developed within our application and what should be done outside. This affects us (the rest of the team) in having to implement functionalities that bring a lot more complexity to our software, making the maintenance and continuous improvement harder. We are suffering from bad decisions that have been taken 7 years ago (not by John).
• John has a mentality of "I know everything" and will not come to discuss with the expert when discussing new requirements.
• John has very strong opinion and can sometimes be stubborn.
• Questioning again the importance of the requirements while starting the implementation is too late as it has usually already been promised to customers. This would make the team looks extremely unprofessional.

What can we (the rest of the team) provide help so that better decisions can be taken and without giving the impression we are by-passing John?

Of course, this has been raised several times within the team and escalated higher, but nothing has been done.

Answer 1

You manager seems to be fine with the concerns that you have raised, or hopefully taking action behind the scenes.

I recommend you raise any concerns in private with John, to give him the chance to change decisions without losing too much face.

Ultimately, if John decides to make uninformed decisions, there is not much you can do.

It sounds like there needs to be structural changes regarding how decisions are made, but it appears that you manager is happy with things how they stand.

Answer 2

John has a mentality of "I know everything" and will not come to discuss with the expert when discussing new requirements.

This is very unfortunate for John and will probably bite him in the ass, when he starts making promises he cannot keep.

It is very typical for a PM to decide for priorities of new features. And it is the job of the development team to implement those. It is also the job of the development team to make sure that features are implemented in a way that the software stays maintainable and complexity is managed.

I this scenario it can easily happen that the PM promises something to be delivered in 3 month and the development team coming back with an estimate of 12 month to develop the feature.

As a developer it is important to not budge on your estimate, or compromise on the approach to match the unrealistic estimates. Instead be clear about the mismatch and give John the chance to change the requirements or change the deadline. It also will help John if you give alternative suggestions to reach the same goals: "Doing it within our service A will take 12 month. But if we change service B as well, it could be done in 3."