What MS Dhoni taught me about Product Management?
They say Product Management is an art, but can India's best cricket captain teach you something about it?
As some of you might know, I started my career as a Software Engineer and later transitioned into Product Management. Well, why and how I made that transition is a story for another day and today I’d like to talk about one of the key skills that I had to learn and unlearn - communicating with stakeholders.
A lot of emphasis is put around communicating upwards, which is important but not as important as dealing with your peers who don’t report to you, but the success of your product and essentially your career depends on them. I feel that its easy to wordsmith to an exec about why a deadline was missed or why was there an outage, but not so much to your peers who think why should there be a PM at all?
As an IC (Individual Contributor) Engineer, you know your systems in and out and act pretty much independently when it comes to designing and writing code. The need for communication is minimal and when you communicate, you do so with other engineers who have the same context about systems and can help unblock you and help solve the problems you’re working on.
Ofcourse as you grow in your career, your responsibilities also include guiding junior engineers about best design and coding practices and also influencing the same across teams. That said an engineer still owns their destiny, where a good engineer would still be rewarded if they designed well and wrote good code, even if the product failed or was delayed.
Now, as an IC Product Manager that story is completely different. You own neither the systems nor the business, but your job is to move the needle by getting things done. No one reports to you, but you have to influence others to do things. So how do you influence someone else?
Early in my PM career, I’d get frustrated that I’d have to explain the same “basic” details to everyone, I have to document every little thing and even if I did - people would still ask the same questions. People would get confused, forget the context in meetings and I’d have to explain the same things again and again. I would wonder why don’t people have the common sense to understand what I am talking about and why don’t they just do what I am talking about?
One day I stumbled onto an interview by MS Dhoni - arguably the greatest cricket captain India has produced so far1. The interviewer was asking Dhoni about leadership skills and Dhoni stressed the importance of communication.
Dhoni said that he is accessible to everyone in his team and he makes an effort to understand each and every individual as unless he spends more and more time with his players, they would not open up and he would not know how they think, what’s going on in their minds and would not be able to motivate them to perform on the field.
As a captain, Dhoni used to think something is common sense, but later realized that there’s nothing called common sense and everything needs to be communicated in a team environment. There would be some smart players who would understand exactly what the captain is thinking, but in a team everyone thinks differently and so communication is necessary so that everyone knows what their roles are and what exactly needs to be done.
I found this perspective to be quite interesting. A Product Manager is certainly not the captain of the team, but they are definitely the orchestrator of getting things done. This motivated me to setup 1-1s with my stakeholders, so that I could understand them better, understand how they think, what their priorities are, what are they concerned about and so on.
The other thing that I learnt was the importance of written communication, as every small thing needs to be documented and every member of the team should know exactly why are we solving a particular problem, what metrics would we impact, what is and is not the scope, what the priorities and dependencies are and when does something need to be done by.
At the end of the day, I have to control the controllables and follow a process. Product Management is an evolving journey and is an art, but my job is to ensure that I do my groundwork well, build relationships and understand how my teammates think, write docs, communicate expectations and then make people accountable for executing their tasks.
So I guess, when in doubt - overcommunicate?