Review

Escaping the Build Trap is a top 10 product book - there aren’t many better. It gets to the heart of what’s important about product management and how you can practically do it inside a company.

The ‘Build Trap’ is when product teams forget what drives value and they focus on (and celebrate) shipping features instead. They measure success based on outputs - not outcomes.

Project management culture infiltrating into product teams is a common mistake. Productivity metrics become more important than product metrics. Shipping becomes more important than solving problems.

To escape the build trap you need to understand and apply problem-solving and experimentation techniques throughout your product teams. You need to understand your goal and everything you do needs to be in service of it. You need to identify metrics that enable you to measure progress - and build a culture centred around learning.

You Might Also Like…

The Right It

Marty Cagan acknowledges in "Inspired" that most of our products and features won't meet expectations, and the ones that do require a lot of iteration to reach that point. I believe this is THE most important observation about product development. This book does a great job of articulating that phenomenon and proposes a robust way to navigate it. This is the best book on validating product ideas that I’ve read. I will forever be sharing this book.

andrewclark.co.uk

Holistic Product Discovery

This is a great product discovery reference book. It brings together product discovery and delivery, and provides a great overview of the theory to date. It’s a book without ego, introducing just a couple of frameworks whilst signposting other important work. It doesn’t quite achieve a single theory that ties everything together, which is a shame. I do love though that it assumes a little product knowledge, which is refreshing as it allows for brevity. Well worthy of a read.

andrewclark.co.uk

Book Summary: Continuous Discovery Habits by Teresa Torres

Get a comprehensive summary of the best-selling book "Continuous Discovery Habits" by Teresa Torres, the founder of ProductTalk. Learn about Teresa's practical framework for continuously improving your product strategy and staying ahead of the competition.

andrewclark.co.uk

Key Takeaways

The 20% that gave me 80% of the value.

• Building things feels productive - but building things that nobody want’s isn’t. Teams should be putting time and energy into researching customer needs, measuring the impact of previous work and creating a coherent strategy for the future. If you’re not doing these things, you might have fallen into the build trap.
• Being agile isn’t enough to ‘Escape the Build Trap’ - you need to shift the focus from building things to achieving outcomes. Product managers can help you do that - if you’re willing to become product-led.
• Becoming product-led is hard, you’ll have to rethink incentives, culture, team shape, org structure, product strategy and how you work.
• Organising around products (not projects) gives you space to do research and measure impact. It frees you from having to ‘know what to build’ in advance - by embracing research and measurement - you can learn faster and de-risk product development.
• Organise teams around goals (if small) OR value streams (if large) - doing so will encourage the shipping of value. Don’t organise teams around APIs or technologies. Once you’ve established an API, move on as many of that team as possible to tackle bigger priorities.
• Your strategy should be focused on outcomes not outputs - and your ability to deliver it depends on the gaps between plans, actions and outcomes. The alignment gap, the effects gap and the knowledge gap.
• To scale an organisation you need to deploy a strategy → and give teams autonomy. The 4 levels of strategy:

The Vision	In 5 yrs, what does the business look like? what impact is it having on the world?
The Strategic Intent	The challenges that stand in the way of achieving the vision
Product Initiatives	What user problems can be addressed in products, to address the challenge?
Product Options	What are the different ways to address those user problems?

• Product Kata helps you fall in love with the problem, not the solution. It’s a problem solving framework that encourages you to work on the most important thing (which might be research or experimentation)

1. Understand the Direction	· Company vision & strategic intent · Product Initiative
2. Analyse the current state	· Current state of intents · Current state of initiative/ product
3. Set the next goal	· Product initiative · Option Goal
4. Choose Step of Product Process	· Problem exploration · Solution exploration · Solution optimisation

• To determine if you’re getting closer to achieving your product initiative - you need to break success metrics into something we can measure on a short time scale. Every level of strategy should have a metric. Lower levels of strategy should have tractable metrics that respond quickly to change (leading not lagging). This allows the product team to iterate quickly
• You’re done only when you’ve achieved and measured the outcomes you set out to achieve. This is how you build with intent and get out of the build trap

Deep Summary

Longer form notes, typically condensed, reworded and de-duplicated.

What is the Build Trap?

When product teams forget what drives value and instead they focus on and celebrate shipping features. They measure success based on outputs - not outcomes. The focus gradually drifts from creating value for customers and realising value for the business, to shipping features and completing projects. Teams put outputs before outcomes. Outputs are easily quantified things that we produce (number of products, features, releases), development velocity).

Build Trap Red Flags 🚩

• User research is skipped in favour of building more stuff
• Roadmap is unrealistic and too many projects
• Deadlines and features are more important than customer metrics
• New features aren’t used and don’t drive results. Product is bloating, people are still celebrating shipping.
• Team’s don’t feel they can pull the cord - and work on more meaningful things
• Individuals don’t agree on what the most important thing is
• Don’t have strong Product Management in the team.
• Talking to customers, research and experiments are seen as a waste of time
• The team don’t know the strategy or vision

How to Escape the Build Trap?

• Become product-led.
• Shift focus from building features, to achieving outcomes
• Give PMs more space to find opportunities to maximise business and customer value
• Problems can run deep in some organisations, so be prepared to think about some of the below:
• Individuals Incentives
• Company Culture
• Team Structure
• Product Strategy
• Company Policy
• Team Processes
• Individuals

The Value Exchange System

Fundamentally a company survives due to value exchange. They provide a product or service, which helps a customer with a problem/want/need and they capture some of that value back. That value is usually monetary, but it can be data, knowledge, promotion etc.

Product teams should focus on generating value for the customer. Helping with a problem/want/need. To do that effectively, you need to understand your customers and their problems/wants/needs.

It’s easy to get distracted and lose focus. It’s tempting to ‘fast-follow’ the competition, or build what the sales team recommend, or what the boss wants.

You and your customers are part of a complex adaptive system, their wants and needs are changing, your opportunities and how to address them are changing too. You can’t control or predict them, your best bet is to understand them.

Businesses are complex, and can get in their own way. Be wary of creating a rigid development process and cadence, that allows no room for experimentation. Think people, process, policy, strategy and culture. It’s easy to optimise for achieving output, and get stuck in output mode.

Definitions (Projects, Products, Services)

Before we go any further, we should define these terms.

• A product repeatedly delivers value to users without the company needing to develop something new each time. It doesn’t require human intervention to give value to the user.
• A service uses human labour to deliver value to the user. A service can become a product if you standardise and automate.
• A project is a discrete scope of work with a particular aim. Usually has a deadline, milestones and specific outputs that will be delivered. Once complete you move onto the next one.

Projects are an essential part of product development - but thinking only in projects is really dangerous. If you’re in the build trap, it’s likely you are over indexing on project thinking.

• Project Based Development = Define → Build → Deploy → Celebrate and Move On

You need the discipline to move toward organising for products over projects.

• Product-led = companies that optimise their products to achieve value

Companies that are product-led are characterised by product-driven growth, scaling their business through software products and optimising products to reach the desired outcomes.

Organisation Types

Product-led - success of product is their primary growth driver. Prioritise, organise and strategise around product success (getting them out of the build trap). They align their product strategy to customer and business goals, and then prioritise the most effective projects that help develop products into sustainable drivers of growth.

Sales-led let contracts define strategy. Customers drive the roadmap. Works when you have one or two clients, but doesn’t scale to 100 customers.

Visionary-led. Propelled by a visionary leader, the company becomes reliant on them, not scalable, and distance from the customer grows overtime.

Technology-led. Driven by the latest technology. Not sustainable as their focus isn’t customer value. Often don’t have a clear value proposition.

What we Know and What we Don’t

Product development is full of uncertainty. As a product manager your job is to remove uncertainty even if that exposes complexity.

You have to review lots of information and identify the right questions to ask and when to ask them. You have to identify products and features that solve customer problems, while achieving business goals. To do that, Product Managers have to work across the disciplines. Product Managers are the key to becoming product led.

The Role of the Product Manager

PMs know the business and the customer - and identify the right opportunities to produce value. They synthesise multiple pieces of data and determine which direction the team should move.

Key Data Sources: user analytics · customer feedback · market research · stakeholder opinions

They keep the team focused on the why - why are we building this? what outcome will it produce. Don’t create detailed PRDs to avoid talking to engineers.

On Agile and Waterfall

Many PMs operate or at least learnt to do product in a waterfall way. Take stakeholder input → turn into specs → pass to design for UI → pass to developers → release to customers.

Agile is not a silver bullet for creating more value. It promotes better collaboration, and faster building - but it ignores how to do effective product management. Agile assumes that somebody at the front-of-funnel is generating and validating ideas. It isn’t enough.

A Great product manager

Product Lifecycle affects priorities

• Early on - figuring out what problems are most important to solve
• Mid lifecycle - figuring out what will solve that problem (what to build)
• Towards end - figuring out if you solved that problem

Pushing Back - Understanding the Why

Often product teams get handed something to build. As a Product Manager you need to hit pause briefly. Don’t jump into building. Try to understand the origins of the request and think through the associated risks.

• Is this part of a larger strategy?
• What are we trying to achieve?
• How are we going to measure success?
• Has research been done?
• Is this creating value for the customer that can be captured by the business?
• What are the key risks and mitigations?

Don’t jump into creating solutions without thinking through the associated risks.

Confusion between a Product Manager and a Product Owner

A Product Owner has a specific and narrow definition in scrum. Product Ownership is just a piece of product management. Product Owner is a role you play on a scrum team, Product Management is a career.

Most organisations don’t give their people time to do product vision and research work. Instead they hold them responsible for a steady stream of outputs and measure success based on stacking backlogs and writing stories.

Product Managers need to work with leadership to agree a goal, and then need the space to achieve it. PMs marry the business goals with the customer goals to achieve value.

Types of Product Work

As you get more senior, you do more strategic work and less tactical work

‣

Organise teams around value not APIs

TL;DR Don’t organise teams around APIs or technologies. Organise around goals if small, or value streams if large (to prioritise shipping value)

Don’t organise teams around APIs or technologies.

• Once an API is built, move to a monitoring and support model. Allow the team to move on
• BECAUSE stable APIs should need a team to continuously work on it
• ELSE you won’t have enough capacity to tackle bigger problems
• ELSE teams will stay busy with low priority work

Organise around value instead - reduce the number of teams

• Balance coverage and scope of teams with the goals you’re trying to achieve
• Small teams can and should organise around goals (and across products/technologies)
• Example: TransferWise: Retention, New Currencies, Acquisition
• BECAUSE: you can give teams ownership of goals and judge success on outcomes
• BECAUSE: fewer teams helps with prioritisation - no useless work
• A Value Stream is defined as all the activities needed to deliver value to the customer
• Discover the problem → set the goals → conceive the date → deliver the product or service
• Organise around value streams. Optimise for the flow to get value out of the door faster.
• Work backwards from the value you provide to the user. Think about customer touch-points.
• How can you provide more value faster through the customer journey.

Don’t get confused by product. Products are vehicles for value. If something doesn’t add value on it’s own, it is just a piece of a larger entire product. Look beyond the apps, features and interfaces to structure your teams.

• E.g A car insurance has an app has no value without the car insurance
• Your Product Manager should be part of the care insurance devision (not just the app team) Example of organising around value streams.

Keep the strategy and the value execution together /red \

Product Strategy

• Strategy is about direction and decision making - focused on outcomes (goals and vision)
• Strategy ≠ Plan. It should transcend iterations and features
• Lock in a plan without validation and you risk building things your customers don’t want
• Strategy can be created at different levels in an organisation
• A good strategy can sustain an org for years - if in constant flux it’s a plan not a strategy

Strategy is a deployable decision making framework, enabling action to achieve desired outcomes, constrained by current capabilities, coherently aligned to the existing context. Stephen Bungay - The Art of Action

When Strategy Goes Wrong - the Gaps

Companies often fail to achieve what they expect. Failure comes from the following gaps between outcomes, plans and actions.

Autonomous teams

PMs will get frustrated if they don’t have autonomy. PMs are often asked to own the vision of the product - but they’re not allowed, and are handed solutions. Often PMs think leaders are being too descriptive, and leaders think PMs aren’t stepping up to own the vision. Autonomy is what enables organisations to scale. If you are aligned coherently, and you have a good strategic framework, you can then allow people to make decisions without a lot of management.

Creating a good strategic framework

• Are leadership aligned?
• Do PMs know why they’re working on things? Is it in service of a strategic goal?
• OKRs help. Make sure they’re outcome orientated thought - not action orientated
• Two parts of strategy:
• Operational Framework - keeping day-to-day running
• Strategic framework - realising the vision in the market by iterating products and services
• Strategy and Vision → aligned to → product teams
• Avoids swirl in planning and execution (Don’t do yearly, continuously evaluate)
‣
Spotify - Thinks in bets.
• DIBBs: Data + Insight + Beliefs → Inform Bets
• Not about mandates → environment where you can try new things and fail
• Strategy is working when product teams and management are synchronised - and results data is fed back into process

Strategy Deployment

Strategies are interconnecting stories told throughout the organisation that explain the objective and outcomes, tailored to a specific time frame. We call this act of communicating and aligning those narratives strategy deployment.

Different levels tell stories on different time scales. Agile teams think 2-4 weeks out. Executives think 5 years out.

Strategy deployment is setting goals and objectives at the right level throughout the organisation. Teams need the right level of direction (not too narrow or too broad). OKRs are a type of strategy development. The 4 levels of strategy:

Strategy creation

Strategy requires identifying problems and organising teams (at different levels) around solving them. Don’t expect to be able to create a strategy in a single day. Bringing a strategy to life: Define a vision → identify problems and obstacles → experiment. Then repeat until you reach the vision (continuous improvement).

This is Product Kata

Steps 1,2,3 are strategy creation and development. Step 4 is execution.

Option goals are outcomes that you need to achieve in order to make progress toward your initiative or intent. When exploring and identifying problems us an art you uncover data that can inform the strategy and vision

Company Level Vision and Strategic Intents

Company Vision

The vision sets direction and provides meaning for everything that follows. It’s the keystone of the strategy and should remain stable.

To be earth’s most customer-centric company, where customers can find and discover anything they might want to buy online, and endeavours to offer its customers the lowest possible prices Amazon’s Vision Statement

Strategy needs to start at the company level, and move through the business lines. Refresh the vision statement if it’s not clear. Strategic intents help connect the vision back to the company operations - which is the difficult part of strategy.

Strategic Intents

Strategic Intents are a tool to communicate focus areas. BIG outcome orientated goals - should take 1-5 years to complete. Limit to a few - the goal is to create focus on how to achieve the vision. As they are aligned to the current state of the business - they can therefore change over time.

• What is the most important thing we can do to reach our vision, based on where we are now?
• What are the few things that need to happen to make a big leap toward the vision

Too many intents and you are peanut buttering. Limit to 3. High-level and business focused. About the whole company no just the product solution

Product Vision and Portfolio

Product initiatives translate business goals into problems we can solve with our product. Identify a product initiative by asking: How can I reach these business goals by optimising my products or building new ones?

Options are your bets. They represent the possible solutions that teams will explore to solve the product initiative. Sometimes experimentation is required, sometimes you know what to do.

Product initiatives set the direction of the product teams to explore options. They tie the goals of the company back to a problem we can solve for the users or customers. PMs responsible for making sure product initiatives and options are aligned with the vision.

Product Vision

Too many products don’t have a coherent vision. Product Vision ties together features and ways to deliver value to customers. Communicates why you are building something and what the value is for the customer.

The VP of product usually owns the product vision, but they might not be the first to set it.

Product Portfolio

To set the direction of a product portfolio answer these questions:

• How do all of our products work as a system to provide value to our customers?
• What unique value does each of the product lines offer that makes this a compelling system?
• What overall values and guidelines should we consider when deciding on new product solutions?
• What should we stop doing or building because it does not serve this vision?

The portfolio strategy is often owned by the CPO. Leaders need to make time to innovate.

The Product Management Process

The best solutions are linked to real problems that users want solved. PMs use a process to identify the problems that can be solved + that help towards the strategy. PMs can rely on Product Kata to develop the right experimental mindset to fall in love with the problem not (not the solution). You can continue iterating until you reach your desired outcome.

Product Kata

The process by which we uncover the right solutions to build. It’s approaching building products from a problem-solving standpoint.

Product Managers and teams should move through the steps to uncover the product initiatives and the options.

Phase 1: Get to the product initiative

Start by understanding the strategic intent and evaluating the current state of it in relation to where your products can help. Determine what problems you can solve to further that strategic intent. Doing so might surface many options.

To determine if you’re getting closer to achieving your product initiative - you need to break success metrics into something we can measure on a short time scale. This then becomes the team goal - its how we measure the success of the option.

It may take 6 months or more to change a product initiative - but team goals must be measurable after every release. That gives the team feedback and lets them know if the option is working.

Context Matters. After we have set the goal, we begin walking through the Product Kata.

1. What is the goal?
2. Where are we now in relation to that goal?
3. What is the biggest problem or obstacle standing in the way of me reaching that goal?
4. How do I try to solve that problem?
5. What do I expect to happen? (hypothesis)
6. What actually happened? What did we learn?

Questions 1 to 4 help us plan our next move as a team. Questions 5 and 6 help us reflect on that work in determine whether to go back to the beginning for the next round

Do just enough in each phase to get to the goal.

Common Mistakes

• Applying a tool or practice at the wrong stage E.g experimenting when you don’t need to - or when you have a strong idea about the solution
• Over-designing solutions for things that are not core to your value proposition (e.g login). If the problem has been solved elsewhere: copy and verify. Focus your time and energy on things that will make or break your value proposition.

Principles

• All design and development work done is in service of reaching a goal
• You don’t have to ship anything - stopping bad ideas is encouraged
• The fewer features the better
• Focus on quality not quantity

Metrics

Set success metrics. Doing so helps you understand your direction and measure your progress. It’s easy to measure the wrong things. Make sure you’re using Product Metrics.

• Consider the meaning and context behind the metrics carefully. How do they inform your decisions and understanding. Do you have more users this month than last What did you do differently?
• Every level of strategy should have a metric. Lower levels of strategy should have tractable metrics that respond quickly to change (leading not lagging). This allows the product team to iterate quickly
• Connect product metrics back to business outcomes by measuring their contribution to revenue or cost.
• Use a system of metrics to guide product decisions (not just a north star). Single metrics can be gamed - they don’t tell the full story. Increasing user acquisition without negatively impacting user activation or retention - makes for a much smarter goal; than targeting acquisition alone
• Some metrics can’t be moved quickly. E.g: Retention is a lagging indicator - you can’t act on it immediately. To influence retention we should focus on leading indicators like activation, happiness and engagement. Leading indicators help us understand if we’re on our away to achieving those lagging indicators like retention
• Make sure you have enough data to act upon
• Set realistic goals. You can’t get your funnel to 100%. Consider benchmarking against the market - or historical highs in your business
• Investigating the problem before identifying success metrics

Phase 2: Problem Exploration

Data analysis can tell you what is happening - but it’s not the whole story. To understand the problem fully, you need to understand customers. PMs don’t talk to (or observe) their customers enough.

What’s the biggest obstacle standing in the way of you reaching that goal? What do you need to learn next?

Balance an analytical approach with..

You may need to find creative ways to talk to you customers

Principles:

• Don’t ask customers what to build - ask the right questions to understand their wants and needs
• Don’t start solving problems before you understand them (and the root cause)
• Test hypothesis at the earliest possible point (research and experiment before building)
• Doing the work to understand the problem early saves time - you’ll chase the right things

Phase 3: Solution Exploration

Experiment to learn

When there’s uncertainty - spending time to understand and experiment before building is key. Don’t confuse building to learn with building to earn. Experimentation is about building to learn - to understand your customers and to prove whether there is value in solving a problem. Experiments shouldn’t be designed to last a long time - you want to prove true or false ASAP. You should plan to scrap what you’ve built, and figure out how to make it sustainable and scalable.

Don’t use ‘MVP’ methodology as an excuse to focus on churning out features - cutting corners sacrifices what you can learn. Think of an MVP as the minimum amount of effort to learn - this keeps you anchored on outcomes rather than outputs.

Use the term solution experimentation instead of MVP. Experiments should be designed to help companies learn faster (they are not about robustness or scalability). We experiment because we don’t know the best solution when we start work.

Product Kata grounds you in learning

What do you need to learn next? → Keeps the team on track, a set up for creating the right experiments.

Basic Experiment Types

Limit exposure to customers - think about how to end the experiment - to close the loop. Concierge, Wizard of Oz and Concept Testing are all used for high uncertainty problems. Prototypes don’t make sense when you need to validate the problem, they only make sense when exploring solutions.

Experimenting in complex industries

Learning reduces risk - get creative - if you can’t learn in the exact environment you want, get creative. The opportunity cost of building the wrong thing is too high - every industry and product has unknowns - getting creative about how you answer the unknowns is key.

Phase 4: Building and optimising your solution

After the direction is set for the product vision, its important to make sure everyone understands the context and work that needs to be done. Two techniques:

Prioritisation Frameworks (Benefit mapping - Cost of Delay - KANO)

• Cost of delay can be quantified and used to help prioritise work. It combines urgency and value so that you can measure impact and prioritise what you should be doing first.
• Urgency: every moment you do not ship - you are losing customers or revenue
• Value: solving strongest problems or desires of the customer

Change Your Definition of Done!

Definition of done is traditionally a checklist of key activities - and defines when something is ready to ship.

Set success or exit criteria before launch, while measuring and iterating until you reach it. Version 1 should be a hypothesis.

Success criteria can be used in the Product Kata - repeat the steps until you reach the goal

• set the direction with success criteria
• understand what problems are standing in the way of you reaching it
• systematically tackle through experimentation
• No matter whether you’re building a new feature, or optimising one, the process is the same
• problem exploration might be small for a smaller feature
• This is how you build with intent, and get out of the build trap

Part 5: The Product Led Organisation

Product-Led organisations are characterised by a culture that understands and organises around outcomes over outputs.

• Strategy is organised and revised around meeting outcomes (not outputs)
• People are rewarded for learning and achieving goals (not just shipping)
• Teams are encouraged to get close to their customers
• PMs are seen as a critical function that furthers the business

Market-Driven Innovation: Doing generative research well to understand the behavioural patterns, concerns and needs of users. Immerse yourself in the users problems.

To get out of the build trap you need to become a product led organisation. Both in mentality and practice. You’ll need to change communication, culture, policies and rewards.

Outcome-Focused Communication

• You need to understand outcomes - and get what it means to see results.

• How to become more patient:
• Meetings to review progress
• Transparency into the outcomes and activities of the company
• Communication cadence and content should be tailored for the audience - at every level
• The main reason companies fail to transition to product-led is a lack of leadership buy-in to move to an outcome-orientated company
• Outputs feel good. People feel like they’re accomplishing things - checking off boxes
• We must remember shipping things is not the only measure of success

Visibility is key

The more leaders can see where teams are, the more they will step back and let them execute. Transparency gives you the freedom to become autonomous.

Agree a communication approach that maps back to the strategic framework (vision, strategic intent, product initiatives, options).

Example Communication Structure

Roadmaps and Sales Teams

Showing roadmaps with features and dates can create a loop of over-promising and underdelivering. Think of roadmaps as an explanation of the strategy and the current stage of your product (not a plan).

• Combine Strategic Goals - with themes - and emergent product deliverables
• Keep your roadmap alive - update it constantly
• Flex your roadmaps for different audiences.

You can include (themes, hypothesis, goals and success metrics, status, milestones).

Rewards and Incentives

Evaluate your current reward structure to incentivise the right behaviour. Don’t align compensation to shipping. You want to avoid ‘it doesn’t matter what the goal is, we just need to deliver this feature’. Don’t force people into the build trap by company policy.

Reward people for achieving outcomes, learning about users and finding the right business opportunities. We want to create a culture of experimentation and learning.

Empower teams to push back - talk to the boss about what success really means.

• Define your metrics → Always come with data

Avoid sales over-promising (commission being too much part of their reward structure)

Safety and Learning

Build safety into your company and freedom for PMs to experiment, fail and learn. Ultimately this makes your failures quicker, quieter and lower cost - it encourages the type of failure you can recover from. Your response to failure as a leader is important. Let people explore. Celebrate learning NOT failure.

Think of Product Managers as risk mitigators: The most costly thing you can do is build a product without knowing if it’s the right product to build. The question then becomes: how do I test and ensure that this is actually what we want?

Leaders need to set boundaries - boundaries make an experimentation culture less scary. Boundaries can be time, budget or user base. You can experiment - but you’ve only got £10,000.

Budgeting

Yearly roadmapping - business casing -budgeting ties next years funding to last years promised deliverables. It creates a culture of building things for the sake of retaining funding.

Instead - fund products like a VC. This is where we are. These are our next goals. We need this much money to achieve our goals.

Not all investments start off tiny - come with data and evidence and you can place larger bets

Customer Centricity

Create a culture that focuses on the customer. How executives talk about and treat their customers is important. Put yourself in customers shoes

• What would make your customer happy and move the business forward
• The most important thing you can do to create great products is to deeply understand your customers

Conclusion

Escaping the build trap requires entire organisational change

• focus on outcomes over outputs
• have the right people in the right roles
• follow the motions to create a good strategy or deployment process
• make sure you have the right structure and policies

Questions to determine if you’re product led