Book review: Product Management in Practice
During Christmas I had the chance to carefully read this book from Matt Lemay which I spotted while I browsing around for PM literature. In this post I will write about what you can expect from it, things I liked and some other that I missed.
First of all, the book is not meant to be a detailed guide of tools, frameworks or methodologies you should implement as PM. It is rather a novel about general ideas, experiences and concepts you should consider to succeed as a PM. With that said, the book does suggest templates and actionable checklists that sum up every chapter and which maybe handy in your everyday life as PM. Also, it comes with lots of specific experiences and stories from other Product Managers as real examples for you to take into account.
The first chapter investigates the role and responsabilities of a Product Manager and defines five types of profiles for Bad Product Managers. These are recurring figures throughout the book and have quite self-decriptive and hilarious names: The Jargon Jockey, The Steve Jobs Acolyte, The Hero Product Manager, The Product Martyr and The Nostalig Engineer. The author creates these profiles to point out archetypes that usually show up in every kind of organization and triggers the reader to recognize as such in some case.
In the next chapters, the book deepens on specific characteristics of Product Management, mainly in the area of communication and facilitation. The author proposes an advanced set of skills for the role which integrate the classic UX/Tech/Business definition by focusing on clarity over comfort to build communication skills, live in the user’s reality and be willing to do whatever it takes to help your team to succeed.
The book also highlights the importance of curiosity as a tool to cultivate a growth mindset:
As a product manager, it is your responsability to communicate, align and translate between people who might have wildly diverging skill sets, goals and agendas. The only way to do this is by taking an open, genuine, and curious interest in the work that they do.
In Chapter 5: The Art of Egregious Overcommunication, the author proposes some methods to manage and schedule meetings where all members find it relevant and valuable to attend. Also, introduces a trick called “Disagree and Commit”, as a way to avoid meetings where everyone agrees with whatever someone just showed or pitched, usually driven by uninterest or boredom. Also, the book tackles the challenges of working with distributed teams, where I found very interesting the story from Tony Hale (CEO, Scroll), as they decided to create an alway-on video link between their two offices to foster the sense of shared space and make space for informal communication.
In this book, you will also find different scenarios you may encounter as a PM: account managers asking for new features at random, designers asking you to decide which design is the best form a bunch of options, programmers annoyed by bureaucracy or processes, stakeholders boycotting your product… For all of these cases, the author comes up with things you might do and patterns and traps to avoid.
Finally, the book also gives some tips on how to do good User Research, how to properly use Data in your role and focus on metrics that matter and how to take care of Roadmaps and Priorization. Also, it comes with valuable criticism about Agile and the way to deal with its odds.
From my point of view, I found the book to be extremely useful and actionable, as you can implement all of its tools and tips from day one. Real-world stories of success and failures included in the book give you a clear picture on things you should not miss while working with your team or approaching the market and templates and checklists are great to put everything in practice. On the other hand, I missed some chapter about available technology or ideas for structuring and documenting your work or even help with connectivity, communication and alignment.
Matt Lemay states the following at the beginning of the book:
Simply, put this is the book that I wish I had on my first day as a product manager, and many, many days thereafter.
And that I think is really the best way to define and summarize this book.
