My Insights: Escaping the Build Trap by Melissa Perri has become my go-to for the basics of Product Thinkings and Management. However, it does not stop there, it also shades light on the aspects required to setup the organizational systems and how to approach them (e.g.: consider setting up your teams and technical systems around value streams). To me this is a very interesting step towards having an holistic view of the systems required to achieve the end goals of Product Thinking: "maximizing the value exchange with customer". Failing to cater for this, and focusing purely on "understanding the customer", is recipe for issues down the road (i.e.: have great ideas but ill setup for the teams and technical artifacts they work with). This is why I find this book refreshing and a step forward on help setting up product-led organizations.
Analysis & Summary
(In the following you can read my book review, originally published here: Review & Reflect: Escaping the Build Trap )
TL,DR: Review & Reflections on the book “Escaping the Build Trap”, by Melissa Perri. This is a refreshing and up-to-date view on Product Thinking and Management as ways to avoid the "Build Trap" (where many companies fall: building features for the sake of quantity, and losing contact with the "Why" they do certain things for their customers). The book brings together a clear and sound narrative (and a nice running example) on why Product Thinking is a great methodology to find ways to maximize the "value exchange" with customers. It also shares guidelines to get these practices in the organization, namely by having Product Management in place. Several elements of Product Management are discussed: the role of Product Managers; the need to focus on the "Why" - to answer the questions that enable to identify "What" are the initiatives to focus moving forward; how to set up your organization around clear "Value Streams" to the customer; how to set up strategies to do these activities at scale; among many other interesting topics. I highly recommend this book to anyone interested on getting a clear understanding of Product Thinking and Management, but also people that are involved on setting up truly product-led organizations - e.g.: defining how to organize their teams around value streams, contrary to classical "feature" or "technical" organized teams (which we know lead to underperformance on maximizing the value exchange with the customer and also complex organizations setups). This is my reference to Product Thinking and Management. #ProductThinking #ProductManagement #OrgDesign #OrgEvolution
Book in 3 Sentences
1: Product thinking is about "outcomes" (for maximizing value exchange with customers) instead of "outputs" (sheer number of features built and released).
2: PM (and Product Thinking / Management) is about the "Why" and how to find answers for the "known-unknowns" with the customer involvement; and with that validate what is the best way to move forward (i.e.: "What" to do).
3: Organize your company to support the Value Streams identified in the Product Vision. This will enable to scope products / product areas, and necessary teams and technical systems, to maximize the value exchange with the customer.
Review & Reflect
Over the last decade(s) we have seen a lot of innovations towards improving how we build products, e.g.: Lean Startup, Agile, Design Thinking, etc. A common denominator across all these approaches is the moving away from "big full up-front specifications" of all the things we (may) need to build on our product. Why? Because they are (in general) a difficult thing to get right and furthermore those approaches takes away the amazing opportunity to empower the people building the product to actually do it with a clear involvement of the customer. There are some twists in this, as the approach to build something is very much depends on the type of challenge at hand (e.g.: the complexity of the problem - as in Cynefin Framework). Nevertheless, in general, I think there is no discussion around the fact that it is very beneficial to drive product development by continuously understanding and validating things with the product customer(s). This book focuses on exactly that: how "Product Thinking" and the philosophy of understanding the customer and building the product based on that enables effective value creation. This approach is contrasted with the alternative approach, which Melissa Perri calls the "Build Trap": evolving into a mode of working where we lose contact with the customer and end up building features (in sheer quantity) and "hope customers will like them". The "Build Trap" is a recipe for failure and waste.
The book is organized in five parts, in the following I give a short analysis (and some remarks) on each of the parts:
In the first part of the book, Melissa Perri starts by making very clear what the Build Trap is (the focus on "output", i.e.: number of features and projects delivered) and how dangerous this is for companies. Then she starts by plotting the "Value Exchange System", which models the interactions between the customer and the company. These interactions can be done in different forms, but in general they happen via a product or a service the company offers. She provides a clear explanation on the differences between products and projects: projects are iterations to develop something on the product. It is crucial that companies keep an eye on the product and how to make it better, i.e.: it is not just about projects, it is about understanding ("Why") how to improve the "value exchange" with the customer and based on that define ("What") projects to develop those improvements. Product is a long-lived thing, on which we iterate to improve. This is the gist of "Product Thinking". She goes on to explain why such an approach is so interesting: it is about addressing the "Known-Unknowns" (questions) and the "Unknown-Unknowns" (discovery through experiments), i.e.: get clarity for product developments with the involvement of customers.
The second part of the book focuses on the role of the Product Manager (PM). This is a rather misunderstood role and many people mix it (again like Products and Projects) with Project Manager. "They could not be more different": Project Managers tend to focus on the "When" of things, while Product Manager focus on the "Why" of things - i.e.: how to drive the discovery and validation of ideas with the customer and with that shape the "What" shall be built to maximize "value exchange" with the customer. It is clear that the PM also needs to think about "When" too, but the primary focus is "Why" (within a "feasible When"). Melissa shares archetypes and anti-patterns of PMs and provides excellent insights on how to set up a career path for this rather important role to power Product-led organizations. Linked with this is also the topic of organizing teams so that the different products can be defined from identified "value streams" to the customer. I find this a crucial principle for organization design and evolution, namely: organizations' Sociotechnical Architecture - i.e.: its organizational and technical systems, must be set up from the Product Vision, i.e.: the value streams that enable delivering that vision to the customer. The result of this is that these different systems and perspectives must be aligned to maximize the overall "performance" of this system of systems.
The third part focuses on "Strategy" and how to connect the Product Vision with the economic outcomes of the products (and product portfolios). To make this work it is essential to have a clear product strategy - i.e.: what is the direction for the product. This is in general driven by the company vision and strategy (which tends to be a multi-year stable mission, which provides clarity and direction for the product strategy - and consequently for the different products in the different parts of the company). To make this work it is essential to have good feedback loops and metrics to measure how things are progressing and what is the contribution of the different products. With this in place we can also find new ways to drive investment in our products (this is explored in a later part of the book). The end goal of Product Strategy is really about setting up a framework to help on decision making on "tactical levels" - i.e.: shorter term decisions within products and teams.
The fourth part discusses the Product Management process, i.e.: how to go about identifying the most interesting next initiatives to develop the product and manage the work around that. Melissa shares the concept of Product Kata to support this. The Product Kata is a four-step process to: 1) understand the direction; 2) analyze the current state; 3) set the next goal; and 4) choose the next step for the product process. This allows us to systematically iterate on product development, i.e.: understand direction, defining metrics and explore problem and solutions spaces to validate to finally build something sustainably.
The fifth and last part of the book focuses on the "Product-led organization" and how to drive and operate it. This is an organization focused on "outcomes" instead of "outputs", which empower teams to drive product development through learning/validation loops with the customer. To scale this in the organization, communication must be clear - i.e.: everyone should know to which value stream (to the customer) their product (or part) is connected and contributing. Another very interesting point is the fact that this organization should not focus on year budgets distributed based on "business plans". Instead, it should focus on product and/or product portfolios investments. What does this mean? Basically stop guessing in advance (and wasting resources on) how the different departments / parts of the company will perform, and focus on validated investment, i.e.: if the product is doing well and discovers huge potential developments it should get investment to enable the product team to work on such initiatives. This is very much what Venture Capitalists (VCs) do when investing in companies (invest on potential, but mostly on "validated potential" - i.e.: customer validates the opportunity). The book finishes with a set of six questions to check whether a company is really "Product-led or not" - things like "team comes up with ideas to build the product" and "killing a product if it does not show potential", among others.
Truly enjoyed reading this book, it provided a lot of clarity on what Product Thinking is and a wide range of of ideas and tools on how to develop true Product-led organizations. I would recommend this book to anyone interested in learning about Product Thinking, Product Manager role and Product Management. Furthermore, also very inspiring for people working on setting up and optimization product-led organizations. It is also very interesting for (Sociotechnical) Architects, and people that are working on setting up Organization Systems and Technical Systems behind the product - as Conway's Law shows these two systems are always inter-twinned, and to me they cannot be designed or evolved without having clarity on "where do we want to go as a company", i.e.: the Product Strategy and Vision.
Note: I have published some further "raw notes" on the book in this Twitter thread.
💡 #TLA_insights: From outputs to outcomes; from shipping (large #'s of) features to discover ("Why") the ways ("What") maximizes the value exchange with the customer, by enabling product teams to continuously do that.— Eduardo da Silva (@emgsilva) February 18, 2021