4 faced Product Manager
And how to master them all.
Amongst the key traits that a Good Product Manager should have, communication ranks amongst the top ones. As a matter of fact, communication would rank amongst the top for any role today but what makes it ineluctable for PMs?
If you break down the jobs a PM does, the atomic elements are all made of good communication -
how well you read between the lines when interviewing a user,
how well you steer the conversation to make the best use of time with users
how well you understand the roadblocks of your technology team
how well you convince senior stakeholders to invest resources, etc.
Not only does a PM have to enunciate well, but also at different levels of hierarchies and to a varied set of stakeholders.
There are primarily four different faces of communication. Let’s look at each with examples:
Senior Stakeholders:
a. As a PM interacting with senior stakeholders (pretty much guaranteed in every PM role), you need to be crisp, firm and smart to know what not to tell. The interactions would mostly happen when you are looking for sign-offs. These could be for annual planning roadmaps, changes to roadmap during the year, sign-offs on financial benefits of a product or feature, ask for additional resources, monthly metric updates, etc. and hence you would need to carefully position your priorities in a way to elicit a positive response. This is not to say you should mask what’s going south while falling behind on your deliverables is likely not going to get you a hike. Moreover, post factum arguments like ‘We did not have the resources’, ‘Our testing took longer than expected’, ‘We encountered a bug during launch’, ‘We could not convince the other platform for integration in time’ will not paint a rosy picture either. Try and put a positive spin around what’s happening. At least, show hope. Remember, you are the PM and you own the success and the failure. Always go with a Plan B. And then C.
b. The other common mistake people fall for is to reveal too many details. A VP of Product need not know you spent another USD 2000 on expanding your cache to deliver a solution. Sure, in some organisations and contexts, details matter but giving out details like ‘The cron job failed on a Sunday and hence we had to use stale data for 2 hours’ is likely not going to make you look Marty Cagan. Remember, you are the PM and they are the VP. What matters to them is whether things are on track or not. Usually, the metrics should be carefully chosen so they can communicate this without much explanation. How you manage to keep things on track is not of any relevance to them!
Engineers:
As a PM, engineers can make or wreck your life. They seriously can. For the simple reason that it is through your eyes and their hands that the product comes to life. How you use your brain to guide their hands is a skill that becomes of utmost importance and hence being absolutely clear on what and how you are trying to solve becomes the foundation of your product success.
a. One of the key elements of this communication is often rooted in how well you introduce problems to your engineering colleagues. While sharing the problem for the first time, do take the time to explain the what of the problem and the why of your solutioning (also often a good idea to share the dollar value of your product / feature). I often recommend a cadence (generally bi-weekly assuming a two-week sprint) dedicated to introduction of new epics (high level pieces of work which can be further broken into smaller pieces of work called user stories and further into tasks and sub-tasks).
b. On top, it is often a good idea to expose your engineering colleagues to users regularly so they can co-create with you. I have often brainstormed not only edge cases but also core solutions to the problem with my engineering partners! Make sure you leave enough time for people to think before you work with your engineering teams to execute the build of your solution.
Users (No Ice Cream questions!):
Probably the most important of them all. Get this wrong and you will play catch up for the rest of the product’s lifecycle.
a. There are varying techniques to recruit the best information but a core element of all these is how well you read between the lines. Asking straight questions will not get you straight answers. Someone telling you ‘I am unable to open your app’ could mean they don’t have time for your app, they don’t know your app, they don’t have a clear flow to follow or what your first instinct is - there is something technically wrong with your app. A good idea is to always ask follow up questions so you get clarity on the why.
b. Second, do not try to talk more than your users - the idea is to recruit information, not give. Do steer the conversation so you can extract the right information but do not go on a rant or a pitch. Settle in and listen. Make notes. Simple thumb rule - if you have spent majority of the time during your interview talking, you have ruined it. Let your users talk and reveal their personas (keeping in mind the rule of reading between the lines).
c. And oh, No Ice Cream questions!
Peer Platforms:
This one requires a delicate touch. Your interactions would often be when your product requires interactions or integrations with other platforms to develop. Often, you will find yourself trying to push something in your peer platform’s backlog as a priority. But your priority is (often) not their priority. As a result, you will find yourself trying to justify why a certain piece of work cannot wait or how it can be more useful than some of the other work.
a. A good way of alignment is to be extremely careful while doing your planning (OP or otherwise) and bringing your peers in when you are drawing up a high level plan for your product for the next few months. This way, they can flag the risks (resource cuts, legal complications, etc.) early and you can both work towards mitigating them. Else, you would at least know that some other piece of work needs to be prioritised to generate value (PMs are never short of work or ideas : )).
b. The other important piece of communication crucial to making this interaction successful is a balance between sharing what you know and what they need to know. There is definitely a higher level of detail (especially technical) that needs to be exchanged (compared to the interactions with senior stakeholders and users), however, it is also a coming together of two different stacks, ideologies, speed of execution, schemas and terminologies (especially in large organisations). And hence, it needs to be handled with care for a successful delivery.
There you have it. The four-faced PM!
Have a good next meeting.