We are back with more amazing insights from our AMA on our Slack channel. In case you missed it we regularly host product managers and talk about everything #product. In this edition, we have G C Mouli with us as our guest. He is Principal PM Lead at Microsoft and has worked on a bunch of travel startups earlier. As an experienced PM, his learnings are invaluable, let's get into - How to become better at Stake Holder Management as a PM.
Good Q. Management (Leadership) is one of the key stakeholders for any feature launch. What metrics you measure/present to manage these stakeholders depends on which slice of management you are talking to. Dev leadership - metrics should revolve around stability, resilience, and performance.Biz leadership - should be around conversion, value generated, optimization achieved and so on. Anything that makes an impact on $. For all other leaders, it should primarily revolve around
a) value to whatever that leader owns
b) what is the impact wrt resources etc in what the leader owns.
Metric you choose to look at every day completely depends on what you own.
Diagnosis of metrics is a separate field by itself. The only thing I would like to say is - Focus on DATA -> INFERENCE -> INTUITION model. (get data; make inferences; and after some time, your intuition will kick in.
I mentioned this earlier as well. Data and the Larger picture. A great PM establishes (by action) that he/she is acting in the larger interest of the team/firm. This coupled with a good people rapport can work wonders.
Haha. Get the ducks in a row. I told you Few pointers:
This is a great question. And happens a lot of time - mainly because each stakeholder holds their stake highest. They are most passionate about the success of their area. The key thing as a PM to achieve here is to convince the stakeholders (it takes some time) that you are working for the greater good, and the larger picture. Arm yourself with data too. Anecdotal data is good as well in these cases. Negotiation is not always about numbers. It could be examples of times when this renewed focus of 'beating a dead horse' has had very bad implications.<trick> In some cases, it might be a good idea to frame it as 'you are trying to help save-face for the stakeholder' </trick>
Super focused question. Thanks. You hit it on point - when you said 'conversations'. That is key. Ensure that it does not appear like you are 'directing' someone to do it. A great PM is one who asks the right direction and gets to a point where the stakeholder feels like they took the right decision themselves. The PM should facilitate that thinking process.
Need not always be a PPT. Depends on the org and size of org. I have had stakeholder conflicts resolved in a room and no computers in front of us. Only a whiteboard. And oh, man, The room was.
Strongly believe that is a beautiful role for a PM. This gets you the closest to the customer. I read somewhere recently that Data and UX behaviours can only get you what and how a user did something, but as customer success and engagement PM, you get to 'talk' with a customer and figure out 'why' a customer did something. Which is I hope you are not relating to this a Growth PM (that is a much different data-oriented beast)!
A day in the life of a PM at MSFT differs completely depending on which team you are in. For me, I am working on Exchange Ecosystem Programmability - exposing APIs which provide the rich data that Microsoft 365 has.
Currently looking at moving a bunch of partners on very old legacy API platforms to the brand new Microsoft Graph. Filling in the gaps basically is my and my team's mantra. So we do quite a bit of customer interaction. Work closely with devs on API structures. Work with data to figure out usage of the legacy protocols. Exciting stuff.
You will get an entirely different answer if you talk to a PM in the MS teams group or the Outlook group.
Twitter Twitter Twitter
It is a myth or not depending on your definition of CEO. If you take away the core business aspects of a CEO and the stress of keeping your business alive; I would argue, a PM would be a CEO of what the PM owns. Literally, a PM is the one who should be the glue holding together every stakeholder and getting them all to agree and keep MOVING FORWARD. Now, tell me, isn't that what a founder or a CEO would do?
Aha. Well, Microsoft is changing. It is a super vibrant agile place right now. I have been following MSFT in the last 10 years (My first stint at MSFT was exactly 10 yrs ago) ; and the direction that the company is headed is amazing. As for constrained by function - I strongly feel that this is something based on attitude. At least in the Microsoft of today. Yes, you are expected to do stuff that you have been hired to do. But going upwards and onwards is something you can definitely do. And one should do. And encouraged to do. I was looking for a structured scale. I was also looking for a good work culture - which MS excels at.
There was a time when PMing meant - do what the Devs, Designers, Management, CS will not do. (Exceptions existed though). It is no longer that. It carries a lot more responsibility.
TPF can help by exposing different sub-types of PM roles. Not too many folks are doing that. PMs should be exposed to what UX PMs do, what do API PMs do, what do growth PMs do, etc .. you get the drift. Folks should be able to identify their niche.
I am going to give you a philosophical answer to this. Product thinking is just being super intentional about your PM stuff. Go deep into your user behaviour. Into data. Into how your feature evolves. Into what you envision it to become. Into what your users envision it to become. In all, be more intentional in everything you do.
One thing that I needed to learn is Empathy for non-engineering functions and One thing I needed to unlearn is that everything is black/white. There is so much grey in this world. You need to be human.
Data. And a larger picture. These are two tools I have employed in influencing execs. You would be surprised how much these two can turn the tables. As I said before, data need not just be numbers. Data can be anecdotal as well. You as the PM is perfectly poised to have both the best data and the best view of the larger picture.
Undue advantages of an Engineer -> PM happen in small agile startups. Because you can form a bond with your engg team very quickly and things can be done faster. Trust builds up very quickly.
Regards to Intuition, as I mentioned earlier, the progression is Data -> Inference -> Intuition.
Let's take an example since you asked for one.
Let's say you need to redesign the signal at SonyWorld Signal in Koramangala Bangalore.
Measuring the traffic at SonyWorld Signal would give you the number of vehicles crossing the signal every minute. Data is probably an excel sheet.
Inference from that is that - this is a bottleneck and the traffic volumes are high per minute; and/or at different points in time etc. Maybe you can even plot some graphs etc.
Let's say you finish that project up. And leadership wants you to redesign the signal at Ejipura signal (adjoining signal for those not in the area). You do the same thing again. And you are getting better at it.
You know that this is a super hard project. What amount of data is sufficient. What solutions do not work etc?
Now leadership asks you to do the same thing in Indiranagar (a nearby locality for those not in Bangalore).
Intuition is what kicks in now - trying to extrapolate from what you have done so far and influencing your current project from learnings and data that you have ingrained into yourself.
This is Intuition. It comes over time. It accumulates. This is also called gut feeling. There will be some hits and misses initially. But over time, your intuition which is the collective refined past knowledge becomes really good.
Hope that example answered your question
I enjoy both actually. 0->1 brings about a satisfaction of 'creating something' from scratch. But Scale/Growth gives you the awesome feeling of impacting a large populace.
Hmm. Let's see. Be more open. Try out stuff. Be more intentional. Utilize your strengths (in my case - people strengths) and seek opportunities where you can leverage.
Aha. This is tricky. It takes time and some bonding with a few influential engineers. Once you get their attention, it will spread, trust me.
One thing to be wary of is, don't try to 'try too hard' to mix with the engineers and try to prove your point of knowing tech. Do it subtly and it will work better. Be on the engineer's side and help 'em. Works wonders.
This is a bit too generic. Depends on the org. Depends on the Product function. Depends on a lot of stuff.
In this case, where there is restricted dev and time-bandwidth, it is best to attack this backlog in a structured manner.
I would ideally have a matrix with rough cost (weeks/months etc), measurable impact (to the larger org), and complexity.
Depending on where your org is in terms of maturity, you can weight the above three differently, cost each task and stack rank based on those.
Want to join the next conversation? We’ll be having another Product Chat soon, get your invite to our Slack community to get all the details. See you inside.
In this AMA, Aatir answered questions about testing hypotheses and features, upskilling as a PM, and important product metrics. He also shared details about his day as PM. Find all this and more below!
In this AMA, Vaibhav answered questions about important product management skills to break into a PM role. He also shared about customer needs and essential metrics to be tracked.