Lessons in Product Management
People often ask me the worst part about Product Management. Here’s what I usually tell them — Nobody works for you or reports to you, but you are the one responsible for building the most amazing next product for your company. It’s totally unfair.
Product Management can sometimes feel very lonely. And building products can simultaneously be liberating as well as intimidating if you don’t know what you are doing.
My first few weeks as a product manager were full of self doubt. I was still coming to terms with the fact that there was no team I could call my own but I was somehow supposed to turn my ideas into reality working across multiple teams — Software development, Hardware engineering teams, User Experience folks, Mobile apps teams, Sales & Marketing, Operations & Supply Chain people, Product packaging. You name it.
But my biggest question (to myself) was
Why would people listen to me and work on my product ideas when they don’t report to me?
3 years and as many product launches later, here is what I know about navigating teams, leading by vision and getting things done, even when nobody reports to you.
Understand that teams are made of people.
Teams are made of people, so the first order of business is to be personable and respectful of the people you are dealing with. The last thing you can do is be a douche and alienate the team that you need for your product's success
In my case, some of the people I was dealing with had been around here for over two decades, and my product development principles were often too radical for them. There were times when I wanted to scream at these people for not wanting to learn new stuff. Thankfully, I didn’t.
You’ve got to be patient. It takes time for people to change the way they have done things for 20 years. Instead of getting mad and complaining, take control. Place yourself in their shoes and think what would motivate you to change.
Get to know the team outside work. Work environments are usually stressful, and most people are not themselves when in office. The grumpy IT guy you don’t want to deal with may be an awesome singer outside work. The lady in the finance team that questions you on everything might be a celebrated part time brewmaster . Take the software team out for an offsite lunch and break bread together, it really helps you become a part of the team. These are basic human tendencies. we do things for people that we know and like. Use that to your advantage.
Get rid of complexity
Product Managers deal with a lot of big product ideas that are vague and broad, but when its time to build — it is also their responsibility to break big ideas down into immediate executables for the team. Something the team can execute on immediately. This is the single most important thing that you can do to start getting things done.
Over these past few years, there have been instances when I failed to remove complexity from my requests upfront and every time I did that, it invariably caused massive delays to the team’s deliverables. Instead of writing code, the team started to spend time decoding my requests, and often their interpretation of the request was way off that what I really wanted — resulting in rework.
Unnecessary rework is a massive waste of organizational resources as well as a direct negative impact to time to market.
In my experience, teams really like to work with Product Managers that have crystal clear requests and take the time to reduce complexity from those requests upstream.
Context is Everything
I was a software developer early in my career, and if there was one thing I hated the most, it was being asked to do something without any context around it. Sure I’d do it anyway, but only after I was done working on all the other requests I had some context about. You can probably see where I am going with this.
It is the PM’s core responsibility to provide context around all requests to execution teams.
One of the ways I like to provide context around, say a new feature, is by literally drawing out the ‘big picture’ on a white board & breaking it down into executable tasks for the team. I then traverse this ‘tree’ with the team that will build it, discuss how each small piece fits into the big product vision and get feedback.
Again, I can tell you from experience that builder teams love whiteboard sessions. It unleashes their creativity and you get a lot of great feedback on how to do something even better. Needless to say, these sessions makes the team take direct ownership of your requests and it gets them fired up to work on them because they know the back story.
Bottomline? Context is everything.
Be decisive & get comfortable with trade offs
As a Product Manager, you’ve got to be decisive. You are the one that makes final decisions on your product, so your team expects you to be comfortable with making key decisions. It sounds obvious, but it’s probably the hardest thing in Product Management.
For new Product Managers, one of the key things to learn and master is the art of making good trade-offs. You might have the most amazing vision for your product that is full of cool features, but in reality team resources are limited. To add to that there are often other products competing for time on the development team’s workflow.
In such a scenario, a product manager has to learn the art of building small and trade off bells and whistles of their product for the most important & indispensable features (a.k.a MVP) that deliver value to the customer.
Just dropping off some of the less important features drastically reduces the time to develop your product and its time to market. Additionally, It usually saves the organization a ton of expensive resources.
Being able to make good product tradeoffs is what often separates Product Managers who get things done from the ones that get lost in the product development loop.
Be Genuine
People that create stuff and build things are a smart lot, so the last thing you want to do is to ‘trick’ them into working for you. Instead, be genuine.
Earn the respect of your team members and you will see an organic lift in your ability to move things faster through product development pipelines. In my experience, the very best work happens when the teams are motivated and when they understand and support the vision of the Product Manager. I call it the ‘Trust Zone’.
Once both you and the team are in the trust zone, it doesn’t matter if anybody reports to you or not. All that matters is hard work, creativity and collaboration — key ingredients for the genesis of a great Product.