Product Management in Practice -Book Review and Summary
I recently completed this book and I have to say, this is one of those books that you would want to revisit at various stages of your Product Management career. You can buy it from Amazon here.
The learnings present in this book are timeless and would be applicable differently to product companies at various different stages but principles more or less remain relevant and highly applicable.
I highly recommend reading this book but just so you get a glimpse of what to expect, here is a summary of the book.
Table of Contents
Chapter 1: Product Management in Practice
Chapter 2: The CORE Connective Skills of Product Management
Chapter 4: Worst Thing About “Best Practices”
Chapter 5: Art of Egregious Over-communication
Chapter 6: Working with Senior Stakeholders
Chapter 7: Talking to Users
Chapter 8: Data, take the Wheel
Chapter 9: Realistic Roadmaps and Painless Prioritisation
Chapter 10: The Wonderful, Horrible Truth about Agile
Chapter 11: In Good Times and Bad
Chapter 1 Product Management in Practice
- Product Management as a career path seems to have gotten glamorised a lot lately. Many people get drawn with the promise of creating products that would be solving critical problems for millions of users but actual Product Management looks very different from this.
- As a Product Manager you have the responsibility for the success or failure of your product feature but you do not have any direct authority on any of the team members who are actually going to work on your feature such as the UX team, UI team, development team etc.
- If you are a PM in an early stage startup, your job is not well defined, you would be a PM, Community Manager, HR Lead, UX Designer; basically anything that no one is doing would be your job.
- In more structured organisations you would be working with stakeholders who have their own priorities and you would have to navigate through a lot of power dynamics to get your feature aligned.
- It is also vital to understand what Product Management is not.
- You are not anyone’s boss as a PM.
- You are not building the product yourself.
- You can’t really wait around for someone to tell you what to do.
- There are many broad categories of a bad PM detailed but as a rule as long as you understand what Product Management really is and what skills one needs to acquire and imbibe (covered in next chapter), one can fair well in his/her PM career.
Chapter 2 The CORE Connective Skills of Product Management
The CORE skills of Product Management
C = Communication between Stakeholders, Users, Teams
O = Organise the development and other teams and set them up for success
R = Research ideas and validate them with data and user analysis
E = Execute the day to day tasks
All of the above mentioned skills are soft skills that a Product Manager needs to acquire and embrace. Apart from these there are some hard skills also that a PM needs to master.
- Technical Skills: To win the respect and communicate easily with the tech team.
- Querying Skills: To be able to query the databases and look for information ourselves.
Chapter 3 Show Up Curious
Take genuine interest in the work that your team members from different departments do.
- Data Science Team
- Development Team
- Compliances and Legal Team
The following can be the ways of becoming a better collaborator.
- Learn ‘hard skills’ contextually, on the job, during the projects that you undertake.
- Build bridges in different departments much before you actually need them.
- Expand your network of influence inside the organisation.
Product Management at large organisations
- Try building relationships by understanding any challenges that team members face.
- Get in touch with people on the lower end to really understand the current situation of the products, development, influence dynamics etc.
Try and cultivate a Growth Mindset and not a Fixed Mindset
To succeed as a PM you must be willing to engage deeply with people whose knowledge and expertise in a specific area greatly exceeds your own. Also, while communicating with such people you cannot get defensive because of your limited knowledge else the best solution can never be uncovered.
If you like to be the smartest person in the room, most likely you won’t be a good PM.
Create a Curiosity Culture. If your colleagues are taking the time to come to you to ask questions, however trivial that is, encourage that behaviour.
Similarly, don’t feel bad for asking for someone’s time if you need to know something from them.
Chapter 4 Worst Thing About “Best Practices”
In the PM world specifically, there are certain worst things about “best practices”.
- Focusing on best practices leads to an incurious mind.
- Best practices focus on operational stories and not stories of user value.
- Best practices are considered a magic pill to fix all existing organisational challenges and problems.
Think of the organisation’s goals first and only then think about the practices that might help you achieve these goals.
If you don’t take time to truly understand how organisation’s current beliefs and practices are contributing to the internal problem you are trying to solve; implementation of best practices is just going to be a shot in the dark.
Best practices are a good starting point but constant iteration is a must and still they are never a guarantee of success.
Chapter 5 Art of Egregious Over-communication
Bad Product Managers never explain the obvious. The things that are obvious carry the most potential for disastrous communication. Asking or confirming the obvious can be very uncomfortable from personal perspective but sometimes can prove pivotal and useful from team’s perspective.
Meetings
Far too many meetings are adjourned without critical conversations because nobody wants to publicly offer their dissenting opinion. Here are some quick guidelines to follow.
- Interpret silence as disagreement and no agreement.
- Ask for affirmative commitment.
- Set clear goals and timelines.
Informal Channels
Encourage (and not cut off) informal channels of communication such as water cooler talks, coffee breaks, lunches etc.
There is a lot of information that circulates in such areas, this eventually helps in decision making in actual meetings. But then again, also don’t force such avenues, let it flow freely.
Asking Favors
As a Product Manager you have no direct authority, so if you have something to ask, be absolutely clear what it is and why you are asking for it.
Goals of the Project
Whenever communicating with designers, developers, account managers, just make sure that the actual goals of the project are absolutely clear and well understood.
Chapter 6 Working with Senior Stakeholders
- A Product Manager cannot succeed if there is no clarity among senior leaders about a company’s strategy and vision.
- If your leadership does not have enough clarity on goals, you should try and assist in creating the goals.
- As a PM you must have the skill to push back and have challenging conversations.
- If you get directions or inputs from Stakeholders which don’t make sense to you, explain to them why you think so, explain the trade off at play and the downstream implications about it.
- When talking to the tech team, always talk about why certain decisions were taken.
- Whenever it comes to decision making with Stakeholders, it is always better to walk them through individually and get a buy in; rather than introduce something new in a group setting.
- If the buy in needed is for a large vision, break it down and get buy-ins incrementally.
- As a PM, when talking to Stakeholders it is your job to advocate and push for users’ needs over and above Stakeholders’ requirements.
Chapter 7 Talking to Users
If you have UX researchers in your team, you should try to work closely with them and try to learn the thought process.
When talking to the users
- Ask for specific nuances rather than generalisations.
- Don’t get too excited if you hear what you want to hear. Users may describe the same solution as you envisioned but for a different reason; your job is to figure out the reason.
Chapter 8 Data, Take the Wheel
- Be absolutely clear and transparent about limitations and assumptions in any conclusions you draw.
- Always ask, “what other things would need to be true for my interpretation to be correct”.
- Have documenting the assumptions a critical and mandatory step in working with data.
- Book Recommendation — “Lean Analytics — O’Reilly 2013”
- Document in detail, the metrics that you expect the feature to move, so that you don’t have to retool an existing product to ensure effective measurement of metrics.
- You need to know the reason behind improvement or degradation of a certain metric so that you can replicate and multiply what works.
- You may not be an expert on data but you need to connect and align between people with people who are experts in data.
- Data often becomes a black hole into which unasked questions and untested assumptions disappear. You need to be careful and thoughtful when using data to draw product insights.
Chapter 9 Realistic Roadmaps and Painless Prioritisation
- Roadmaps are strategic communication document and not an actual plan for what we will execute and when.
- There is always a need to explain what to expect from a roadmap, retrospect on it and explain how and why we are using the roadmap.
- Roadmap should be open and shared for company wide discussions about what is being built, for whom and why.
- Find the right balance between how much time you should be spending on writing the product specifications versus facilitating, collaborating on it. Your team must feel that they are co-creators of the product and trusted partners.
- Everything in your document (specifications) must tie back to the goal that you are trying to achieve with it.
- Writing long and detailed specs might make you feel that you are getting a lot of work done towards building the product but it might not be the right work.
- Book Recommendation — “Radical Focus by Christine Wodtke”
- Technical POCs are a great way of testing whether the planned feature is going to be valuable for users or not.
- When it comes to last minute emergency requests (for addition of items in roadmap), have a process, a template to understand the criticality and prioritise it.
Chapter 10 The Wonderful, Horrible Truth about Agile
- Irrespective of what agile practice you use, teams need to connect, communicate and collaborate.
- Use the guiding principle — “change the rules, don’t break the rules”.
- If you don’t take time to reflect on the way you are working and improve the things that don’t work then agile won’t help you either.
- In services or client servicing model, agile doesn’t help because clients need to know the delivery timeline and cost upfront. Solution to this problem is to quickly figure out the development velocity and being able to guesstimate on the basis of that.
- Using agile, the development teams can collaborate with clients in a much better way and create a product which is much more useful.
Chapter 11 In Good Times and Bad
- As of 2017, there were 2.2M apps in Apple App Store and 2.8M in Google Play Store. 2015 Forrester Study suggests that vast majority of users interact with only 5 apps that don’t come pre-installed. So, there are many disappointed Product Mangers out there.
- PM is not an easy job but its a practice that can make everyone’s life easier (developers, marketers, executives etc.)
- Greatest challenge of a PM is to bring same level of energy and excitement among all team members, to your work, every single day.
- As a PM, it is vital that you stay grounded to the following
- Make a list of things outside of your controls
- Look for opportunities to delegate important things
- Protect the routines and rituals that bring your team together
“As a PM your title gives you nothing, no formal authority, no intrinsic control over product direction or vision and no ability to get a single meaningful thing done without the help and support of others.”
Hope you enjoyed reading this summary and learnt a thing or two to apply in your day to day PM job.
Thanks for reading. I’m Ayush Jain. In this blog I write about my learnings as a Product Manager.
If you liked this article, you might also like. . .
