Geek read: Inspired by Marty Cagan
Product design book review through the eyes of a software engineer
Intro
This time review of the book about product development. Something less technical and more focused on the discovery of what your customers want, tracking how happy your customers really are, and everything in between.
Structure
My copy has 300 pages with 67 chapters, meaning all the content is presented in super biteable chunks so that you can go through this book very quickly, making it a perfect companion for traveling or reading it on the go.
The book is divided into four parts:
- People
- Product
- Process
- Culture
People
This is the part where the author focuses on the team structure and the profile of people that you need in your successful team. There is a focus on the importance of relationships and interactions between specific roles in the team.
I really liked that throughout the book, the author’s advice is based on specific scenarios, which are really easy to digest and understand.
The key here is that teams should have autonomy and be responsible for the things they are building. It is important to have a team with drive and passion. To achieve that, we need a team built out of people who believe and are interested in the product. It’s hard to build something great with just a team of mercenaries. (more about it here).
There is one thing that is very exotic and controversial to me in the book I posted about some time ago:
I can’t wrap my head around one thing I read in the book. The author wrote in the book that engaging passionately with products and meeting customer expectations is not something that can be learned. You either have that feature or not. It’s almost product manager predeterminism.
source: https://www.linkedin.com/posts/marcinsodkiewicz_while-everyone-is-traveling-to-vegas-for-activity-7268697351974760448-oVZR
Product
Product is a solution to a problem. The key idea is that teams should have a vision and strategy for a product. We should focus on the problem, not the solution. We should be open to evolving, disrupting, redesigning, rebuilding, and innovating. Our North Star should be a product vision that should inspire the team, but it can’t be too specific.
To build a successful problem, it has to be customer-centric. We should focus on the customer, not our competition. We want to build the best product for our target audience, not mimic the functionalities of other products. Otherwise, we won’t be disruptive, and we will lose our competitive edge.
The reality is that we have to sell our product and sell the dream. We need to do it not only externally but also internally. Presenting a product is critical.
In multiple places in the book, the author highlights that he is not a big fan of road maps. Why? Because they might anchor in the minds of the people and companies are ending up with something that has to be done even though it might no longer be the best option. We should focus on business goals.
Process
This part of the book is focused on a philosophy of thinking about the product — through product discovery techniques and market analysis. How to know what to build, for whom, develop product vision, ways of verifying our hypothesis, identifying risks, and finally, how to measure our progress and success.
That part of the book was the hardest for me to read as many product discovery techniques described are primarily focused on a product manager role rather than engineering. Still, there is also plenty of content for engineers. Especially on product prototyping techniques, feasibility, data analytics, and A/B testing.
There is interesting technique described which reminds me a premortem technique in its essence. It’s called the customer letter where we are writing fictional letter from a customer letter or press release note about our product. So we are writing a note that could be written after our go-live that helps to focus on a main features and goals we want to achieve.
Culture
The author describes his vision of an innovative culture and literally, in bullet points, lists examples of behaviors that we should develop and ones that we should avoid in our organizations to keep our teams innovative, empowered, autonomous, and successful.
Some examples that could make you think and encourage you to read all:
- Great teams are celebrating meaningful business goal achievements, and bad teams are celebrating go-live
- Innovative organizations should have a focused product strategy. The worst thing to do is to create a product for everyone. You should have clear parts of the market that you want to focus on. Get in touch with your customers and use them as an inspiration to improve your product.
- Slowing down can have a root cause in not engaging engineers and designers in the very early stages of product discovery, which also results in lower quality of the final product.
The author closes the book by dividing cultures into cultures of innovation and cultures of execution (more details here).
- Culture of innovation: is a culture of experimenting, new technologies, open mind, and empowerment where everyone understands that with bold experiments and testing new approaches, failure here and there is inevitable. This is a product and customer-centric culture.
- Culture of execution: is a culture based on urgency, commitment, and team accountability for their deliveries. The question is: if the thing that matters is the output or effective results of the team?
Summary
This is a really good read. The book is short and on point, filled with practical advice and best practices, and served in super easily biteable chunks. Definitely, it’s worth spending time reading it. It can be an eye-opener for many.
Especially those working professionally on product development, as this is a book on product development rather than an engineering book. Still, you can learn a lot from it and look at your job from a slightly different angle. The angle that matters a lot. At the end of the day, what matters for the business is customer satisfaction.
It’s hard to achieve customer satisfaction without tech excellence and innovation, and the author does not neglect that; he highlights that. He also inspires engineers to focus on more product-related aspects of engineering.
If you are still not entirely convinced or don’t want to spend money on yet another book, you can go to the blog linked below, where plenty of blog posts are part of this book.
