I was taught this concept by one of my managers many months ago but it didn’t really click for me until I had an opportunity to be a Product Manager (PM) for a few weeks. This experience gave me the empathy to articulate what I, as a developer, want from a PM. The original diagram came from a white boarding session in our conversation.
A good Product Manager is a communication gateway. In fact, I would say that this should be a PM’s primary responsibility. What is a gateway? A gateway is “a means of access or entry to a place.” So, when a PM is effectively doing their job, communication should look like this:
Lets describe these arrows by starting at the top and working down. The stakeholders and customers are talking to the PM so that he can gather requirements that the development team could work on in the future. The PM is talking back to the stakeholders and customers to clarify requirements, set expectations (e.g., other higher priorities, “we’ll have to wrap up x before we can start work on this”), and pushing back (e.g., “I know you want this end of month, but the devs say this will easily take two months even if they dropped everything else on their plate. We can either cut scope or increase the deadline”).
The PM talks to devs after the PM has converted the stakeholder/customer requirements into use cases and prioritized the work. This is easily a part time job as stakeholders/customers often suggest implementations when they think they’re suggesting requirements. Also, three individual stakeholder/customers may tell the PM that their requirement is the highest priority. The developers can’t always work on all three at once, so the PM needs to figure out a reasonable way to pick the order and communicate new expectations back to stakeholders/customers.
In these PM to Dev communications, it is extremely important that the developers are told why they are being asked to work on these use cases. With that information in hand, they can suggest better ways of approaching the problem and have a better chance of reading between the lines correctly when they have to make a technical decision that the PM won’t be able to answer.
Developers talk to the PM to clarify and change use cases. Developers are also the ones estimating the level of effort to complete these use cases. The PM will bring those estimates back to stakeholders/customers to set expectations.
I’m sure there are developers who have communicated directly to stakeholders/customers and felt that was more efficient than going through a PM. This can be true and these direct communications should be set up by the PM when they see that it would be more efficient to do so. But to do this habitually will slow the developers down as they’ll be spending their time gathering requirements and turning them into use cases instead of developing software. When this developer to stakeholder/customer communication needs to occur, the developer should bring the requirements to the PM so that the PM can convert them to use cases for the team. This is also important because the PM needs to be kept in the loop.
When a PM is doing their job, they act like a communication gateway. But what about PMs that aren’t doing their job? They act more like food chains. I’m going to talk more about this in my next blog article, but here’s a sneak peak of what the problem looks like:
