The book “How to avoid the build trap” by Melissa Perri is often mentioned in many product talks, podcasts and articles. I had to pick up the book and read it for myself to see what it was all about. The verdict? It was definitely worth the read though I found some concepts like product kata, various research methods only are introduced at high level and Melissa didn’t go into a lot of detail. Having said that I think it is a great book for all product professionals to read as it gives you the tools and tips on avoiding the build trap.
Key message:
- Melissa talks about how many companies fall into the build trap where they are too busy focusing on building and shipping products. I’ve also worked in organisations where there was a lot of pressure on shipping features and meeting deadlines than taking the time to determine if we were building the right thing.
- Companies that are stuck in a build trap often measure their success by outputs rather than outcomes. These companies forget to create value for its customers and achieve business goals.
- To get out of the build trap, companies need to become product-led which not only involves changing the way it approaches software development, but also their entire organisation by changing its organisational structure, business strategy, policies and how it rewards and incentivise its people.
So here are my 11 key takeouts from the book:
#1 Every feature you build should result in outcomes
Many companies end up in the build trap when they misunderstand value. Instead of associating value to outcomes, they measure value by the number of ‘things’ produced ie. outputs. Outputs are easily quantifiable like the number of products, features, releases or velocity of development teams. Outcomes on the other hand, are the business and customer results from delivering those outputs. It’s important for companies to understand what creates value for its customers and the business. Melissa describes this as the ‘value exchange system.
#2 Projects are essential part of product development but approaching product management only in project framework will cause damage
Many companies operate on a project based product delivery cycle. A project is a discreet scope of work that has a deadline and specific outputs. It is focused on delivery of the outputs against a scheduled timeline. When the project is over, the team moves on to the next one. Many projects have their own measure of outcomes but often there is no aligning strategies above them. A product is something that needs to be nurtured and grown to maturity, which takes a long time. You need to keep iterating the product to reach the outcomes by scoping out new projects. Product thinking is focused on outcomes rather than outputs.
#3 Product-led organisations avoid the build trap as they prioritise, organise and strategise around product success
Many companies are led by sales, visionaries or technology. All of these can lead to the build trap.
- Sales led: Lets customer contracts define its strategy and the product roadmap.
- Visionary led: Operates based on a visionary which is not sustainable. Innovation needs to be built into the system so that one person is not the weakest link.
- Technology led: Driven by the latest and coolest technology but often suffers from lack of customer value. Often very cool things are built with no buyers.
On the other hand, product led organisations is able to optimise for outcomes and align product strategy to business goals. They are able to do this by having the right people in the product management roles, the right business strategy, policies and processes.
#4 Product development is full of uncertainty. You must explore the knowns and unknowns
- Known knowns: Before you build any product, it is important to layout what you know that are true such as facts, data and critical customer requirements.
- Known unknowns: These are assumptions you want to test, data points you want to investigate and problems you want to explore. You use experimentation to clarify these and turn them into facts.
- Unknown knowns: These are based on your intuition and experiences. It is important to test and validate these to remove biases.
- Unknown unknowns: These are things that you don’t know that are discovered when talking to customers or looking through the data.
It’s relatively easy to work on a solution for known knowns but the real value of product management is the skill it takes to investigate and explore the known unknowns, unknown knowns and unknown unknowns.
#5 Product owner is a role you play in a scrum team. Product manager is a career
One of the most important roles for a product manager is to marry the business goals with customer goals to achieve value. Good product management can figure out how to achieve goals for the business by creating or optimising products with a view to solving actual customer problems. When a company only thinks about the feature level, it loses track of the outcomes those features should produce. That is what leads to the build trap.
The role of a Product Owner is to:
- Define product backlog and create actionable user stories for the development team
- Groom and prioritise the stories in the backlog
- Accept the completed user stories to ensure the work fulfils the criteria
These are skills and functions taught in product owner workshops and still leave a lot of uncertainties for a Product Manager. The Product Manager needs to determine:
- How do we determine value?
- How do we measure the success of our products in the market?
- How do we ensure we are building the right thing?
- How do we price and package our product?
- How do we bring our product to market ?
- What makes sense to build vs buy?
- How do we integrate with third party software to enter new markets?
Melissa suggests that you need to hire and put the right people in Product Management in order to be successful.
#6 Company needs to understand the why before they can understand the how to build a product
A good strategy isn’t a detailed plan. It’s a framework that helps you make decisions. Melissa talks about the ineffective top down approach where the management provides the detailed product initiatives to the Product Teams who are not empowered to challenge back. Product Teams need the freedom to explore solutions and to adjust their actions according to the data they receive as long as they are aligned to the overall strategic intent and vision of the business. The role of the Management Team should be to set and deploy the right strategy for the business, communicate the why to the company and let the next level down figure out how to solve the problem and build the product.
#7 Product metrics tells you how healthy your product is but it is easy to measure the wrong things
Ongoing monitoring of product metrics is crucial to set direct for your product but you need to know what to measure. Vanity metrics are goals that make your product look shiny and attractive for investors but they don’t help product teams make decisions. Similarly, there are productivity metrics like number of features shipped storied worked on, which are good for checking how product development is going but these are not product metrics and cannot tie your product back to the business objectives. Melissa recommends two types of product metrics that can be used:
1. Pirate “Aarrr’ metrics: Also known as a product funnel. These metrics measure the customer conversion throughout the product lifecycle allowing you to see where customers are falling off and fix it.
- Acquisition: How many customers are signing up to your product?
- Activation: How many customers are taking the first step to use your product?
- Retention: How many customers are continuing to use your product?
- Referral: How many customers are referring your product to other new customers?
- Revenue: How many customer are paying you for your product?
The pirate metrics work well for consumer products with a freemium model as you can identify cohorts at each step and find solutions to move them through the funnel. One downside is that the metrics don’t talk about customer satisfaction.
2. HEART metrics: In addition to the funnel, these metrics takes into account how the customer is interacting with a product.
- Happiness: How do customers feel about your product?
- Engagement: How often customer is interacting with the product?
- Adoption: How many people complete the sign up and become regular customers? (similar to Activation in the pirate metrics)
- Retention: How many customers are continuing to use your product?(same as the pirate metrics)
- Task success: How long it takes users to complete the task or a goal?
The HEART metrics was developed to evaluate user experience. It is a useful tool to help product teams make better UX decisions.
#8 Product Kata is a scientific, systemic way to build better products
The Product Kata is a framework based off Toyota Kata that Melissa created. It is a process that allows the product manager to uncover the right solution to build by asking a series of questions. You first need to set the goal, and then ask:
- In relation to that goal, where are you now?
- What are the biggest obstacles standing in the way of reaching that goal?
- What can we do to learn? eg. Customer reserach, experiemntation, gather data
- What do we expect to happen after we run this experiement?
- What did you learn?
Then you do this again starting with “where are we now?” Did we move cloase to the goal? And you keep repeating it.
#9 The most important piece of the MVP is learning
Often when organisations are building a MVP, they are focused on getting the feature or a product out quickly and cutting corners to learn. Melissa defines MVP as the minimum amount of effort to learn so that the product teams can anchor on outcomes rather than outputs. Melissa touches on various research methods that can be used when building a MVP.
- Concierge experiment: Deliver the end result to customers manually and they do not look like the final solution. It doesn’t involve coding so it is quicker to get started. Because you work closely with customers, there is a lot of feedback flowing through.
- Wizard of Oz: It looks and feels like a real product but backend is manual. It can reach broad customer base.
- A/B testing: Splitting a portion of customer traffic to a new solution idea to see if the metric moves compared to the current solution.
- Concept testing: You show concepts to customers to gauge their feedback. It can range from landing pages to low fi wireframes to high fi prototypes.
#10 Prioritisation is top issue for many product managers. Try cost of delay framework to prioritise your work
There are many prioritisation methods. One method Melissa recommends is the Cost of Delay. It measures every feature in terms of Urgency vs Value. High urgency means that every moment that you don’t ship that feature to customers, you are losing out on opportunity to hit your goals. High value means solving the strongest problems or desires for the customer. Melissa references the Black Swan Farming for more details on Cost of Delay. https://blackswanfarming.com/cost-of-delay/
#11 The culture of safety and learning is vital for product teams success
Product Managers need a certain amount of trust and the flexibility from the organisation to experiment different options. If teams are not allowed to experiment, they will never be able to push the status quo. Many companies talk about how they want their staff to be innovative and how they want to create crazy new products but there has to be an understanding that it is safe to fail in order to get innovation. When there is no safety built into the company, the Product Managers will not feel comfortable in trying something new. No one will.
Experimentation is the ultimate risk management strategy because when you experiment early you can prevent the failure of something that you would have spent millions of dollars later. Many companies fail slowly because they release products and never measure whether those products do anything. This is the most costly way to fail. Taking 10 years to fail slowly and burning cash is more problematic than allowing smaller failures along the way. Early failure is the type of failures you want to encourage as it allows the Product Teams to fail quickly, quietly and at lower cost. We can also recover quickly.
Final thoughts
So there it is – my 11 key takeouts from the book “How to avoid the build trap”. Obviously the book contains other concepts and topics that I haven’t mentioned in this article. Melissa uses the real examples from a company she used to work in (called Marquetly) to explain the concepts which I found helpful. If you want to learn more about how to avoid the build trap, I suggest you pick up the book and read it 🙂
Julia
Awesome Product Squad 
Leave a Reply