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 centered around learning.

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.
• Organizing 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.
• Organize teams around goals (if small) OR value streams (if large) – doing so will encourage the shipping of value. Don’t organize 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 organization you need to deploy a strategy → and give teams autonomy. The 4 levels of strategy:

Vision	In 5 yrs, what does the business look like? what impact is it having on the world?
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. Analyze 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

In-depth Summary

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 realizing 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 favor 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 maximize business and customer value
• Problems can run deep in some organizations, 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 optimize 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 labor to deliver value to the user. A service can become a product if you standardize 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 organizing for products over projects.

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

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

Organization Types

Product-led – success of product is their primary growth driver. Prioritize, organize and strategize around product success (getting them out of the build trap). They align their product strategy to customer and business goals, and then prioritize 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.

Known Knowns	Facts (data and legal requirements)
Known Unknowns	Questions (questions, assumptions, experiments)
Unknown Knowns	Intuition (feels like the right thing to do)
Unknown Unknowns	Discovery (moments of surprise when talking to customers or looking at data)

The Role of the Product Manager

PMs know the business and the customer – and identify the right opportunities to produce value. They synthesize 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.

Bad PM Archetypes	How to Avoid Their Traits
Mini-CEO	Choose influence over authority. Choose producing value over implementing your own ideas Choose to listen to and involve your team Choose to fall in love with problems (not solutions) Choose to seek out data to disprove your ideas.
The Waiter	Choose not to blindly prioritize stakeholders, customers and manager requests Choose to have a vision and to have goals (makes prioritization easier) Avoid the product death cycle: nobody uses product → ask users what features are missing → build the missing features (ideas haven’t been validated) Don’t ask customers for solutions. Choose to understand their problems.
The Former Project Manager	Product Managers are responsible for the Why. Not the when. Answering why, is different to answering when. Keep a strategic mindset.

Great product manager:

• PMs balance meeting business needs with solving user problems
• Understands and works alongside the other disciplines, getting the most from their skills and expertise
• Connects the dots taking a wide variety of inputs
• They have a deep empathy for users
• PMs always focus on the problem – anchoring on the why – increasing the chance of building the right thing
• PMs own and communicate the why
• PMs Experiment to see which solution is best
• PMs need to be humble

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.

As Described in Scrum	Gaps
Define backlog and create actionable user stories	Understand the business and the customer. Gain insights from regular customer iterations. Ensure proposed solutions generate value for the customer that can be captured by the business.
Groom and prioritize the backlog	Focus on outcomes and measuring success. Identify leading measures that the team can influence. Measure and use results to inform future activities.
Test user stories against acceptance criteria	Lead the go to market strategy for the product. Work out how to integrate with the business operating model and work out how to reduce the uncertainty of product success in the market
	Work out how best to achieve the outcome (as broad as build vs buy discussions).

Most organizations 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

Tactical	Short-term. Getting features out the door. Breaking down work for developers and designers.
Operational	Tying the strategy back to tactical work. Create a roadmap connecting the current state of the product to the future state that aligns the teams around work.
Strategic	Positioning the product and company to win in the market and achieve goals. Future of the product and company, what it will take to get there.

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

Product roles differ at different levels of seniority

Associate PM	Start here. Start here if switching. More companies should have these roles. Pair with a senior PM to tech them the ropes. Give them the coaching they need. Create the senior people you need by giving junior people a chance.
PM	Ideate & build the right solution for users (with Eng & Design) Talk to users. Make decisions on features. Enough strategy to craft vision of features. How they fit into product. Tactical enough to ensure smooth execution. Skew to more operational than strategic. Responsibilities are typically shorter-term impact and delivery of features. Quarterly time horizons. If they focus too much on tactical work, they fall behind on strategy and visioning work. Should also be feeding data up to more senior PMs. If you call this role a PO, then you’re missing the strategy piece, tying feature work to the product vision.
Senior PM	Same as PM but with more scope or complexity Still an individual contributor. Balancing being highly strategic and operational. Good for people who want to work on difficult product problems. Have entrepreneurial traits.
Director of Product	Important for scaling · when too many people report for head of product Scope of product and WIP ramps up. Strategic alignment + operational efficiency Connect products back to portfolio vision People management – oversee PMs of a portfolio or product line Responsible for strategic product roadmap. Time horizon of a year. Operational effectiveness of a team Aligning PMs to goal, working on the most important things
VP of Product	Strategy and operations for an entire product line Connecting company goals to growth of product line Set the vision and goals for the product. Responsible for the financial success of their product line – not just the delivery of features Align the strategy and purpose to a portfolio of products Entrepreneurial – great at launching and growing new products Successful VPs are more strategic, hire people to do the tactical
CPO	Oversees a company’s entire product portfolio – on the exec CPOs are usually added when a company adds a second product Driving economic success of the business through portfolio of products Interface at board level Inspire confidence (in the vision), empathise (peers and team) and are relentless and resilient

Organize teams around value not APIs

TL;DR Don’t organize teams around APIs or technologies. Organize around goals if small, or value streams if large (to prioritize shipping value)

Don’t organize 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

Organize 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 organize around goals (and across products/technologies)
BECAUSE: you can give teams ownership of goals and judge success on outcomes
BECAUSE: fewer teams helps with prioritization – 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

Organize around value streams. Optimize 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.

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 organization
  • 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.

1 – Knowledge Gap: What management want to know ≠ What company knows

• Ask for just enough information to help you make a decision
• Management should define the strategic intent, or the goals of the business. Pointing towards the outcomes the business wants to achieve

2 – Alignment Gap: What people do ≠ What management want them to do

• More detailed instructions don’t help
• Instead allow each level within the company to define how it will achieve the intent of the next level up
• Ensure you can connect activities of the teams back to the outcomes of the company
• Don’t send down mandates. Instead – align every level to ‘the why’ and allow the next layer to figure out what to do and report back
• Lack of leadership alignment often stops successful product management

3 – Effects Gap: What we expect actions to achieve ≠ What actually happens

• When you don’t get results, don’t put more controls in place. Give teams more freedom to adjust their actions to meet goals.

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 organizations 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 – realizing 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)

• Strategy is working when product teams and management are synchronized – and results data is fed back into process

Strategy Deployment

Strategies are interconnecting stories told throughout the organization 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 organization. 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:

Vision Company	What do we want to be in 5-10 years. Value for customers, position in the market, what our business looks like	CEO / Senior Leadership
Strategic Intent Company	What business challenges are standing in our way of reaching our vision?	Senior leadership / Business leads
Product initiative Product	What problems can we address to tackle the challenge from a product perspective	Product Leadership Team
Options Product	What are the different ways I can address those problems to reach my goals?	Product Dev Teams

Strategy creation

Strategy requires identifying problems and organizing 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.

1. Understand the Direction	· Company vision & strategic intent · Product Initiative
2. Analyze 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 optimization

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 endeavors 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

Example Intent → Goal

Intent	Goals
Expand into the enterprise business	Increase revenue from $5m to $60m in 3 years
Double revenue growth from individual users	Increase revenue growth from 15% to 30% yoy from individual users

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 optimizing 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 product vision emerges from experimentation around solving problems for users. It should be validated. A product vision statement…

• Includes the problem the user has – and the capability the product will provide them
• It shouldn’t include features
• It can include qualities that are important to the user (like ease of use)

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.

⚠️ The Build Trap:
When you focus more on building software – than you do on building the right software.

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.

1. Understand the Direction	· Company vision & strategic intent · Product Initiative
2. Analyze 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 optimization

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.

Product Metrics	Help you identify where to act and influence product direction by showing you how healthy your product and business are
Vanity Metrics	Don’t help product teams make decision – or change behavior or priorities. Sometimes you can make a vanity metric actionable by adding a time component.
Productivity Metrics	Burn-down, stories, features shipped. These aren’t product metrics, they tie the results of product development back to the strategy.

Two Metric Frameworks – AARRR and HEART

• 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..

User Research	E.g: Observations, Surveys, Customer Feedback → help you understand the problem from a users perspective
Evaluative Research	E.g: Usability Testing → Does it work?
Generative Research	E.g: Observational Studies → Helps you identify the problem – What is the biggest problem stopping x? – What’s the pain point? – What’s the root cause of the problem? – What do they value in a solution?

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

User Research	E.g: Observations, Surveys, Customer Feedback → help you understand the problem from a users perspective
Evaluative Research	E.g: Usability Testing → Does it work?
Generative Research	E.g: Observational Studies → Helps you identify the problem – What is the biggest problem stopping x? – What’s the pain point? – What’s the root cause of the problem? – What do they value in a solution?

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 optimizing your solution

Round	What to learn	Next Step	Expected	Learned
1	What problems users have	User research 20 customers	Find out biggest problems	List of problems A,B,C
2	Key pain points for problem A	Observe 20 users	Identify Top issues	Issues with A identified
3	Do most users share this issue?	Survey 1000 users	Most have the issue	80% report the issue
4	Will taking away this step improve metrics	Concierge experiment to eliminate step	Improvement in key metric	Key Metric improves for concierge participants

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:

North Star Document

Explains the product in a way that can be visualized by the entire teams and company. It includes ◦ The problem you are solving ◦ The proposed solution ◦ The solution factors that matter for success ◦ The outcomes the product will result in Great for providing context to a wide audience. Keep them up to date and evolve them as you learn more They are not action plans and don’t include how the team will be building the product. That’s where story mapping comes in.

Story Mapping (Jeff Patton)

To break down work and align the team around goals To help team communication and understanding of what needs to be done To think through all the factors needed to deliver a successful solution To break down desired actions from the user standpoint To build shared understanding within the team

Prioritization Frameworks (Benefit mapping – Cost of Delay – KANO)

• Cost of delay can be quantified and used to help prioritize work. It combines urgency and value so that you can measure impact and prioritize 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.

BUT what if you’re done only when you’ve achieved and measured the outcomes you set out to achieve for the business and the user
Most important point in the book!

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 optimizing 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 Organization

Product-Led organization are characterized by a culture that understands and organizes around outcomes over outputs.

• Strategy is organized 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 behavioral patterns, concerns and needs of users. Immerse yourself in the users problems.

Kodak was close to innovating well

To get out of the build trap you need to become a product led organization. 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.

Companies get stuck in the build trap when they aren’t patient enough to see outcomes emerge. So they instead measure progress by the number of features shipped.

• 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

Meeting	Cadence
Business Review · Quarterly · Senior Leadership	Share progress toward strategic intents. Share financial & outcome metrics (revenue, churn, op. costs) CPO + VPs of Product say how product initiatives are furthering strategic intents New strategic intents can be introduced Avoid prioritizing product initiatives
Product Initiative Review · Quarterly · Product & Design Leaders	Review progress of options against the product initiatives Results of experimentation, research, releases and how they relate to the goals New product initiatives discussed, feedback, buy-in Funding requests
Release Reviews · Monthly	Teams show off the hard work they have done Talk about success metrics Focus on what is going to be released Roadmap communication to sales, marketing and execs Not talking about experiments and things that aren’t shipping

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).

Build a shared understanding of terminology for stages of development (Alpha, Beta etc )

Larger organizations may benefit from a Product Operations Team

Rewards and Incentives

Evaluate your current reward structure to incentivize the right behavior. 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.

Product companies invest in and budget for work based on portfolio distribution and the stage of their work.

• Allocate funds across product lines for known knowns (ready to build or maintain)
• Allocate funds for discovering new opportunities that will propel your business model forward

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 organizational 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

1) Who came up with the last feature or product idea you built?

2) What was the last product you decided to kill?

3) When’s the last time you talked with your customers

4) What is your goal?

5) What are you currently working on?

6) What are your product managers like?

7) Have you iterated on the last thing you shipped?