10 Lessons in Product Management I Learnt From “Extreme Ownership”
In a Masters in Business podcast, Marc Andreessen recommended “Extreme Ownership” as one of the recent good reads. It codifies the abstract and unspoken best practices of ownership in an elegant manner.
Extreme Ownership is taking full responsibility for every aspect of your life. Every excuse given or any blame made is simply wasteful.
As a product manager at Zarget, high-growth startup, my mission is to:
- Understand what job, a customer is trying to get done
- Ship products or services to get a customer’s job done effectively
Inspired by Tren Griffin’s style, here are my lessons on product management from this excellent book.
Communicate. Communicate. Communicate.
I, as a Product Manager, should make sure that every team member who is contributing to that feature should understand the “why”. The “why” may vary:
If it is a big feature that requires aggressive timelines, I need to explain why it is important and how it affects the overall goals of the company. If it is a minor feature, I need to explain why it is important and what customer pain point it is solving. If it is feature contradicting the assumptions made a few months back, I should explain, why the assumptions were wrong and why it is right now and so on. Failure of communicating the mission or the “why” is a PM’s responsibility and I can never shrug it off.
Check Your Ego
As a PM, I may or may not be a CEO of the product. But if I don’t get well along with a team member, I need to keep my ego in check and ask myself if I’m the problem. Maybe the engineer assumed something completely different and went ahead with implementation. I have a choice. I can throw tantrums about engineer not updating me. Or I can keep my ego aside, put the mission first (product or delivery of feature), talk to the engineer without offending, make her/him understand your situation. I need to remember that as a PM, I need to influence people without authority. So no point in alienating myself from the team.
I should know that more than me, the product or the mission is important. I’m here to help a customer’s job get done. My ego and I need to take a backseat.
Relax. Look around. Make a call.
In a feature demo or a review meeting (or in a crisis ;-) ), a founder or a VP might point out a huge scenario being missed out and in turn that might derail the shipment of the feature. All fingers might be pointing at me. I have a choice. I can argue what were you guys doing in the spec/prototype review phase or blah blah. Or I can be calm, listen, assess the severity, think from the first principles, if that is an edge case or not. If yes, prioritise that to be delivered immediately in the next shipment. If not, go back to the drawing board and address it. Better to be criticised internally than by a competitor or a customer.
Leading up the chain.
It is very tempting to blame my boss for not understanding the problem. May be my boss sets unrealistic timelines or has impossible expectations. I need to own this and lead up the chain, by convincing my boss why that is not possible or unrealistic. My boss’ job is not to make me pathetic. (If I truly have such a boss, I need to own and change my company/team). So I need to treat my boss like a customer, explain or convince. If I am not able to do that, I need to follow the next lesson.
Disagree and commit.
If I disagree with my boss’ or board’s vision or if I am not able to convince why they are wrong, I should simply, commit and give my fullest. I should not be bickering or gossip why this is strategy is shit. I simply need to respect the team, commit and fully co-operate. Remember, the mission is higher than oneself.
Discipline = Freedom.
I can pursue my vices like reading, long walks or movies if I am disciplined in my work. It may be contradictory, but it’s not. If I’m disciplined in writing a spec document by thoroughly thinking through all scenarios upfront, I would not be interrupted by a developer or test engineer during implementation or release. If I’m disciplined enough to adhere to the timeline or communicate status, I will not be having any late night pings or quick calls from boss/teammates interrupting movie or a game.
Cover and move.
I know that “Product Manager” is a cross-functional role. But to be really effective, I need to really help other teams to get helped in my role. A new support engineer might have written something completely wrong about an issue to a customer. If needed, I should jump directly into the conversation and address it to the customer or guide the support engineer. In the future, the support engineer might point out to a scenario missed out in the new feature that an important customer was promised for or why the spec in review might not address a certain segment of customers’ pain point.
Simplify.
I always need to communicate the “why”, clearly but succinctly. But there are times in which a junior team member is overwhelmed with many things in her/his plate, cannot comprehend the “why”. I simply should break down the tasks in whatever way I can and communicate the next steps. I am not a project manager or a technical architect to know the nitty gritty of the “how”. But I can break down the tasks and simplify it as much as possible to get the team member focussed on the mission, which is shipping the feature.
No bad teams. Only bad leaders.
I should take complete ownership for the shipping of the product and get customers’ job done. If there is any mess up by any team member, be it engineering or marketing or design, I should take full responsibility. I should communicate clearly but responsibly. Sometimes loud, sometimes nudge, sometimes even offend. Whatever choice I am making, I need to remember that I have to work with the same team for the next release. If my multiple attempts of being sincere at extreme ownership are falling on the deaf ears of the team or boss, maybe its time for me to look for a new team or company. But this definitely will be a rare scenario.
Prioritize and Execute.
I know this is the basic lesson for a PM but it is worth reinforcing. It is easy to get into the vortex of incremental improvement, which is needed in some scenarios, but I need to be clear on the big problem I am solving. I really need to take steps to move the needle in the key metrics of the product/company, rather than being busy with issues/follow-ups/schlepping.
(The principles of Extreme Ownership are applicable for a parent or just a family member too. But I will save that for later. Thanks for reading.)