‘Escaping the Build Trap’ by Melissa Perri offers some practical insights into why organisations fall into the habit of just building stuff. She works her approach through a case study format which makes the book an enjoyable and relatable read
Although the mandate to escape build trap often requires CXO-level interventions, there are quite a few takeaways from the book for product people at every level
What is the Build Trap?
The build trap is when organizations become stuck measuring their success by outputs rather than outcomes. It’s when they focus more on shipping and developing features rather than on the actual value of those things
Companies can get out of the build trap by setting themselves up to develop intentional and robust product management practices
Fundamental premise in the book is to view companies as a value exchange system and explaining product management as a key driver of this exchange
Companies which fall in the build trap typically confuse this fundamental exchange. They also cannot define value for their customers since they don’t understand customer problems
Figure 1. Companies as a Value Exchange by Melissa Perri
Community, technology and market typically act as outside constraints on this system, although companies can control their own policies, strategy, incentives and structures to efficiently provide value to customers
The book also argues that the most optimal way for organizations to deliver customer value is to morph into product led organisation which has the following key components
-
- Creating a product manager role with the right responsibilities and structure
- Enabling those product managers with a strategy that promotes good decision making
- Understanding the process of determining what product to build, through experimentation and optimization
- Supporting everyone with the right organizational policies, culture, and rewards to allow product management to thrive
A major chunk of the book is organised along these four themes – role, strategy, process and incentives for product managers. I summarize the book in the same buckets
Part 1. ROLE of product managers
A few short chapters focus on the following key questions
1.1 How do you define Product?
The author discriminates between products and projects since the two can be interchangeably used in some orgs. Products are defined as vehicles of value, which can provide recurring value to customers without requiring a company to build something new every time. OTOH services use human labor to primarily deliver value to users and projects are discrete pieces of work towards a specific aim
Product-led companies have the following characteristics
-
- They optimise their products to achieve value and desired outcomes
- Growth is driven by product
- Organisation is scaled through software products
1.2 What is product management?
Defined as the domain of recognising and investigating known unknowns and reducing the universe around unknown unknowns
1.3 What does it take to be a great PM?
-
- Product managers are focused on WHY whereas projects managers on WHEN
- Goal of a good product manager is to reduce risk by focusing on learning
- Great product managers always focus on the problem and WHY
1.4 How should the product teams and their roles be organised?
Traditional teams are organised around value streams (think end-to-end customer value prop), features or technology. However best teams are organised around org strategy
Part 2. What is STRATEGY?
-
- It is a framework which helps make decisions. It is not a plan. Sometimes it can also be thought as what a company would NOT do
- It can also be thought of as a deployable decision-making framework, enabling action to achieve desired outcomes, constrained by current capabilities, coherently aligned to the existing context (Ref. Steven Bungay, The Art of Action)
- Strategy should not change every year or month, lest it be confused with a plan
2.1 What are the pitfalls of strategy as a plan?
It typically fails owing to divergence between outcomes, plans and actions. This gives rise to three gaps a. Knowledge gap b. Alignment gap c. Effects gap
Organisations try to respond to the knowledge gap by more detailed information, alignment gap by detailed instructions and effects gap by tighter control. And this does not work smoothly across functions unless companies view strategy as an action enabler towards achieving results
Figure 2. The Effects Gap by Stephen Bungay
2.2 What does a good strategy framework contain?
Should be made up of two parts 1. Operational framework for day to day activities 2. Strategy framework detailing how the company realises the vision while strategy deployment is the act of communicating and aligning narratives and stories told through the org
It has four levels in the org 1. Vision 2. Strategic intent 3. Product Initiatives and 4. Options or Solutions
2.3 How to create strategy?
The book introduces a framework called The Product Kata for scientifically creating products
Figure 3. The Product Kata Framework by Melissa Perri
2.4 What is a company Vision?
A good mission explains why the company exists. A vision explains where the company is going based on that purpose. Sometimes the vision is clear, the difficult part is connecting it back to the company’s operations. This is where it’s necessary for company leaders to specify strategic intents. These few, concise, outcome-oriented goals focus the company around how to reach the vision. Strategic intent is always aligned to a company’s current state. They are also at a higher level and business focussed
2.5 Where do product initiatives come in picture?
The product vision communicates why you are building something and what the value proposition is for the customer. OTOH Product initiatives translate the business goals into the problems that we will solve with our product. The product initiatives answer how
If there is no coherent vision, product may not be able to scale
Part 3. How to uncover the right solutions to build? What is the PROCESS behind it?
Enter the Product Kata as explained earlier, there are 4 steps to this. However understanding which phase in a product under is critical to success
-
- Understanding the direction
- Problem exploration
- Solution exploration
- Solution optimization
3.1 How do we understand the product direction?
This is where product metrics come in. She introduces two frameworks
-
- Pirate metrics or AAARR framework as promulgated by Dave McClure. The familiar acquisition, activation, retention, referral and revenue framework does not capture customer happiness and therefore…
- HEART framework which stands for happiness, engagement, adoption, retention and task success. However overly relying on retention has the lacunae of it being a lagging indicator. A product may not have that long a runway and therefore need to focus on leading indicators like engagement
3.2 How do we perform problem exploration?
There are well known frameworks like problem based user research aka generative research whose objective is to find which problems to solve. They key here is to ask customers the right questions
3.3 Which solutions to build?
First the PM has to be clear about the distinction between building to learn and building to earn. She defines MVPs as something which is built to learn and therefore should be scoped out as something which contains the minimum effort taken to learn
There are 3 frameworks introduced to explore solutions 1. Concierge which is essentially delivering solutions to customers manually and see if it works. More suited for B2B companies and of course it is labor intensive and won’t scale 2. Wizard of Oz which is real-like product rolled out to a larger set of users. The key here is to not run the experiment longer than it should since the experiment is still essentially manual 3. Concept testing like with a prototype. It is more generative than evaluative in nature
3.4 When should you not do a design sprint?
Although design testing has become a preferred method to experiment and learn, they should not be conducted before user research and identifying customer problems to solve
3.5 How do we optimise a solution?
This is where product vision helps, in sensing direction of progress and helping teams find alignment in solutions proposed. North Star document is one such tool
North Star document explains the product in a way that can be visualized by the entire team and company. This includes the problem it is solving, the proposed solution, the solution factors that matter for success, and the outcomes the product will result in
3.6 How do we prioritise among different solutions?
Although there are many framework prioritization, she talks about the Cost of Delay in prioritizing work. Cost of Delay is a numeric value that describes the impact of time on the outcomes you hope to achieve. It combines urgency and value so that you can measure impact and prioritize what you should be doing first
Figure 4: Qualitative Cost of Delay by Arnold and Yuce
Part 4. How to transition to being a product-led ORGANISATION in ethos and practice?
In product-led organizations, people are rewarded for learning and achieving goals. Management encourages product teams to get close to their customers, and product management is seen as a critical function that furthers the business
4.1 Why is communication important in organisation?
Visibility in organizations is absolutely key. The more leaders can understand where teams are, the more they will step back and let the teams execute. The more PMs try to hide their progress, the wider the knowledge gap becomes and it becomes difficult to sustain the product for long
4.2 How should one communicate product roadmaps?
Instead of thinking of roadmaps as a Gantt chart, one should view them as an explanation of strategy and the current stage of product. This combines the strategic goals with the themes of work and the emerging product deliverables from it
4.3 Why should one communicate the product phases clearly?
It is important for company wide alignment on what stage a product is in – experiment, alpha, beta or generally available (GA). This helps in reducing friction among different units as well. For example, alpha – a phase in which the objective is to determine whether the solution is desirable to a customer – cannot be included in the sales presentation to customers. Beta products – to see whether the solution is scalable – can be
4.4. How should people be rewarded?
One should be rewarding people for moving the business forward— achieving outcomes, learning about your users, and finding the right business opportunities. Rest is vanity!
4.5. Why should experimentation be encouraged?
Experimentation is the ultimate risk-management strategy because, when you experiment early, you can prevent the failure of something you will have spent billions
4.6 How to budget products?
Fund them like VCs. One should allocate the appropriate funds across product lines for things that are known knowns and ready to be built, and also in discovering new opportunities
Lastly the book ends with tips for identifying whether a company is product-led. My favorites are
-
- Who came up with the last feature or product idea you built? The answer should normally be the team
- What was the last product idea that you killed? Killing products is sign of a healthy product culture
- When was the last time you talked to your customers?
- What are your PMs like?
Overall this is an excellent succinct resource for all product professionals. Some of the things I think could have been better covered because of their relative importance in avoiding the build trap are
-
- She could have elaborated more on aligning CXOs towards the need for being product-led org. Also for people below in hierarchy, it becomes quite impossible to manage this chasm and the book does not quite offer tactics to manage this transition without the risk of becoming a product martyr!
- Delving deeper into which product metrics to adopt since they are critical to assessing the product direction and identify product initiatives
- Product roadmap’ing and communication have been largely not covered although she does refer excellent resources on the same