As we discussed last week, A Good PM is a Communication Gateway. This is a diagram of how communication flows to and from a good PM (Product Manager):
If you want to know more details about how a good PM interacts people around them, check out my previous blog post.
This time I want to talk about how bad PMs interact with people around them. The communication flows look more like a food chain. If you’ve never seen a food chain before, it looks like this:
Similarly, a bad PM communicates like this:
I call this a food chain communication style because communication flows in one direction and the arrows at the top often point to multiple layers below.
The PM usually transfers the messages from the stakeholders/customers directly to the developers with no translation or pushback along the way.
This lack of translation means that the developers have to spend time converting stories into use cases themselves. As I said in the previous article, translating requirements into use cases is easily a part time job. This takes away from the time that the developers are building software and instead makes everyone into a mini-PM. These raw requirements may not make much sense or be unclear. The developers will waste even more cycles trying to get clarification.
Getting this clarification is not always easy. A bad PM tends to not understand “why” they’re asking the development team to implement something. This means the developer has to ask the PM who to ask (wasting more cycles). In a worst case scenario, the PM will actively interfere with the developer communicating with a stakeholder to get clarification. As a result, the wrong thing is often created, has to be undone, and created again the right way. This is very demoralizing and a waste of time for the company.
When a PM doesn’t know “why”, it is very difficult to prioritize requirements. Without knowing “why”, the loudest stakeholder/customer goes first. And if there are multiple squeaky wheels, then all requirements get to go first. Everything becomes top priority. In other words, the developers’ bandwidth, workload and velocity is rarely considered and new requirements are added to the beginning of the pile of work that’s already in progress. These usually come in the form of interruptions to the developers who are unable to wrap up the stories they’re working on because there’s always something new that’s more important.
Usually when a PM doesn’t know “why”, they don’t push back on stakeholder deadlines. When a stakeholder learns that the PM prioritizes the loudest person first and doesn’t push back on deadlines, the stakeholders often take advantage of this by creating a bunch of artificial deadlines so that their features get worked on sooner. The PM will pass these deadlines off to the development team who will suffer as a result.
In these environments, it can be common for stakeholders to reach out to developers directly. As I said in my previous article, this can be advantageous sometimes but it causes a lot of issues if it’s habitual. When the PM is bypassed, they get out of sync with the stakeholder and the product vision. The PM will know less and less about what’s going on in the project and why. The dev who talked to the stakeholder may be working on something that the PM has no idea about. This is another way prioritization issues occur because the developer is being told different things should be worked on by different people.
Finally, a bad PM tends to involve and include the developers in lots of meetings. They do this because they’re not putting any forethought into what needs to be worked on next so they place the burden on the development team. These meetings interrupt a developer’s train of thought and take away time that could be better spent developing. Some meetings are necessary, but most can and should be avoided. Better to have face to face contact whenever possible.
If you’re at a company and have experienced these symptoms, the PM needs to provide more value to the team. They need to understand the project, understand “why” all requirements are requested and act as a communication gateway between stakeholders/customers.