Escaping the Build Trap

Escaping the Build Trap

Author
Melissa Perri
Year
2018
image

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.

You Might Also Like…

image

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
image

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.

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

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 prioritise stakeholders, customers and manager requests Choose to have a vision and to have goals (makes prioritisation 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.

A Great product manager

PMs balance meeting business needs with solving user problems
  • They find user problems/wants/needs that are aligned with business goals
  • They work to understand how the goal of the product team fits into the goal of the business
Understands and works alongside the other disciplines, getting the most from their skills and expertise
  • They harness collective knowledge of other disciplines - bringing them in periodically to build a shared understanding of the problem
  • PMs are influencers not managers. They work alongside others, and utilise their strengths.
  • PMs shouldn’t be lone wolfs but instead generate solutions and explore problems with the team.
  • PMs need to be literate in technology, business and design. Enough to discuss key tradeoffs, ask the right questions
  • PMs balances priorities of all disciplines to strategise and decide what is best for the product
Connects the dots taking a wide variety of inputs
  • They can sift through the information and create a product vision that helps further the company and solves the customer needs/wants/problems
  • Understand the business model and the market
  • Understand the vision and goals of the company
  • Unlike UX - PMs look beyond the experience to the entire system.
    • Requirements, feature components, value propositions, the user experience, the underlying business model, the pricing and the integrations - revenue sources
They have a deep empathy for users
  • They put in the hard work to understand user problems/wants/needs
PMs always focus on the problem - anchoring on the why - increasing the chance of building the right thing
  • PMs need to identify what’s the next most important thing, and convince stakeholders of it
PMs own and communicate the why
  • They know the goal and understand the direction.
  • They craft the product vision, communicate and champion it.
PMs Experiment to see which solution is best
  • They work back from the vision with your team to determine what’s a sensible first step
  • They validate the vision, before implementing it
  • They work with the team to develop and test the idea
  • They make sure it achieves the goals of the customer, user and business.
PMs need to be humble
  • Realising they don’t know the answer. They need to tackle assumptions. PMs reduce risk by focusing on learning. They know not all good ideas are their own.

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 prioritise the backlog
Focus on outcomes and measuring success. Identify leadings 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 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.

An aside on (SAFe) Scaled Agile Framework (it doesn’t work well in practice)
  • In safe PMs manage product owners
  • PMs are responsible for external-facing interactions and work.
    • Speaking to customers, defining requirements and scope of the products to be built
  • Product Owners take instruction from PMs who communicate everything down
  • Product Owners are internal facing, defining the components of the solution and working with developers to ship it.

SAFe doesn’t work very well in practice.

  • PMs are waterfalling down requirements and it’s not clear how teams pushback or validate they’re sensible
  • POs are disconnected from users and not capable of creative solutions because they don’t understand problems well
  • Assumes one PM can do everything

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. Synth data. 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
Chief Product Officer
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.

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 \

image

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
Netflix Example

As a DVD business - started to invest 2% of revenue in streaming.

Vision: To provide movies and TV shows in the most convenient and easy way for customers

  1. Get big on DVD
  2. Lead streaming
  3. Expand worldwide
  • Killed their hardware device - and spun off Roku. Key partners would see them as a threat if they had their own hardware
  • Vision evolution “becoming the best global entertainment distribution service, licensing entertainment content around the world, creating marketing that are accessible to film makers, and helping content creators around the world to find a global audience”
  • Netflix organised around key outcomes and strategies to help reach its goals
    • Personalisation, instant access, ease of use. Teams were able to explore tactics to accomplish these goals, they were held accountable to success metrics for each
    • Delight customers, in margin enhancing, hard to copy ways
    • Strategies
      Tactics
      Metrics
      Personalised
      Ratings Netflix Prize
      % customers who rate > 50 titles at 6 weeks
      Instant
      Hub expansion, streaming
      % disks delivered in one day, % customers who watch > 15m a month
      Margin-Enhancing
      Previously viewed, advertising, price and plan testing
      Gross margin, LTV
      Easy
      Simplify + kill progressive disclosure
      %customers with > 3 titles in queue on day one
  • A strategic framework like the one Netflix uses is that it forces you to think about the whole before zooming in on the details. IT PROVIDES THE ZOOM OUT.

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.

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

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

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

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:

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

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

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
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 optimising my products or building new ones?

Netflix Example
  • As a Netflix subscriber, I want to be able to watch Netflix anywhere, with anyone, comfortably
  • Options: Roku, Xbox partnership, Enabling internet-connected devices

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. You can escape the trap by understanding and applying problem-solving and experimentation techniques → that lead you to the most impactful thing.

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

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

Pirate Metrics - AARRR (Dave McClure)

Acquisition
users find you (land and sign up)
Activation
users’ first experience with your product (takes a meaningful step)
Retention
keeping users returning
Referral
recommending others because they love your product
Revenue
users paying for your product

Centered around the life cycle of users through your product (like a funnel)

The HEART Framework

Happiness
How satisfied users are
Engagement
How often users interact with the product
Adoption
(similar to activation above)
Retention
Task Success
usability testing, how easy is your product or feature to use

  • 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 optimising your solution

Round
Current state
What to learn
Next Step
Expected
Learned
1
Key Metric hasn’t moved
What problems users have
User research 20 customers
Find out biggest problems
List of problems A,B,C
2
Key Metric hasn’t moved
Key pain points for problem A
Observe 20 users
Identify Top issues
Issues with A identified
3
Key Metric hasn’t moved
Do most users share this issue?
Survey 1000 users
Most have the issue
80% report the issue
4
Key Metric hasn’t moved
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 visualised 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

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.

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

Kodak was close to innovating well
  • Kodak conducted generative research into early digital photography sharing:
    • Users wanted to control how they present themselves
    • Users wanted to edit photos to improve them before posting
    • Users wanted their phone cameras to be better
  • “You should be looking about how to integrate your camera technology into phones”. Maybe photo editing software on phones, and the ability to share photos too.
  • A - Build your own phones
  • B - Provide the tech to phone manufacturers
  • Kodak made good strides in trying to innovate, but the organisation prevented it from doing so
    • small teams in innovation labs can’t change the future of a business
    • Kodak couldn’t get budget for 6 months

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.
🪤
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 prioritising 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 )
Experimental
Understand the problem and determine whether it’s worth solving. Conducting problem exploration and solution exploration activities
Alpha
Is the solution desirable to customers? Minimum feature set - or robust experiment Early access - feature might be killed
Beta
Determine if a solution is scalable Reduce risk Open to only a small subset of the population
Generally Available
Available to all customers
Larger organisations may benefit from a Product Operations Team
  • Help keep track of progress, goals and centralise process. . Typically a chief of staff or VP - that reports to the CPO.
  • A small team focused on streamlining operations, process and reporting
    • Set strategy cadence
    • Report on goals - outcomes - progress etc
    • Sometimes setup up an product analysis platform and make metrics available
    • Standardising the product process
    • Running key product meetings
    • Conduct any coaching or training for product teams
    • Don’t create roadmaps, but they create a system and template for teams to input their goals, themes, progress and details that can then be shared around the organisation.

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.

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

1) Who came up with the last feature or product idea you built?
  • Should be the team not management
  • Management should set goals - team given space to figure out how to reach them
2) What was the last product you decided to kill?
  • It’s unhealthy if you can’t kill a product or idea that won’t help achieve goals
  • Did the organisation commit to customers in advance?
  • Budgeting can’t budge
  • No pushback to management
3) When’s the last time you talked with your customers
  • Management doesn’t really let us
4) What is your goal?
  • The PM should be able to articulate a goal.
    • Should be outcome orientated, actionable, clearly communicated
    • Shouldn’t be output orientated!
  • Create value for the business by creating value for the customer
5) What are you currently working on?
  • Working on problems (not solutions) for user and the business
  • Solutions spoken about only in context of solving the problem
6) What are your product managers like?
  • PMs should be respected and well regarded. Seen as leaders who shape direction of the company. Respected partners in steering the ship forward.
  • PMs shouldn’t be seen as too strong, or too weak
    • Not dictators - but not beaten down by stakeholders or management either
7) Have you iterated on the last thing you shipped?