Review

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

You Might Also Like:

Book Review and Summary: Escaping the Build Trap by Melissa Perri

Get a comprehensive review and summary of the best-selling book "Escaping the Build Trap" by Melissa Perri, the product development expert. Learn about the key principles and practices for creating successful products and avoiding common pitfalls in the product development process.

andrewclark.co.uk

Book Summary: Continuous Discovery Habits by Teresa Torres

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

andrewclark.co.uk

Outcomes Over Output

I have heard many product managers say "outcomes over output," but few have a clear definition of an outcome. Defining an outcome as a change in behaviour that drives business results is key to linking this principle to product practice. It anchors to the core of product management, which is all about the value exchange between customers and the business. The author does an excellent job of taking a great product management principle and almost creating a full-stack product management model based on it. Changes in behaviour are observable and measurable. Customer behaviour can be visualised on a customer journey map. Executives can hold teams accountable for hitting outcomes. Businesses can be transformed by using the same techniques.

andrewclark.co.uk

Key Takeaways

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

• Why it’s so hard to build technology that achieves outcomes:
• Confirmation Bias: Undervaluing facts that don’t confirm what you believe, and favouring information that does
• Optimism Bias: We are less likely of experiencing a negative event compared to others
• Valuing outputs over outcomes: ideas are useless unless they solve a problem
• IKEA effect: If we ourselves are the creators, we perceive our creations as more valuable that what they really are
• Unchallenged assumptions: assumptions often remain unchallenged due to confirmation bias. It’s really easy to underestimate what happens if an assumption is false
• Sunk cost fallacy: when people involved feel like they’ve invested too much time and effort. They don’t want that to be a waste
• Siloed work: everyone just focuses on execution, rather than challenging existing assumptions
• More output fallacy: the belief that the more work we do the better it will be.

• Rule of thumb: Discovery should take about 10% of build time

Product Discovery Principles

Discovery Frameworks

• Being iterative and incremental allows good feedback loops
• Three Qualities of Successful Products:

• The three types of risk: user value, business value, feasibility
• What’s the least amount of discovery we need to do to address a particular risk?
• Four stages for clarity / The double diamond

The powerful holistic framework

• The framework can help you understand what you historically did, or are presently doing:
• It can help you identify how ‘holistic’ is the approach you’re taking to discovery
• Are we assessing the risks well?
• Do we understand the full scope of the problem?
• Are we choosing the smartest way to visualise the solution at this stage?
• Are we evaluating with the right kind of people in a way that fits them?
• Will this activity make us learn the most?
• It can help you evaluate your toolbox, do you have questions, workshops and artefacts you can use in each box?

• Use the power of triangulation throughout discovery: Use several methods for each part of the matrix to make sure you cover as much ground as possible.

Known Playbook: Focused on User value:

1. Hypothesis: We believe customers have [problem x]. If we provide [solution y], we will see [desired outcome z].
• Don’t be rigid about structure, but mention the problem you want to solve, a high-level solution statement and intended outcome.
2. Design Studio: Illuminate the problem with a presentation. Sketch solutions with everyone. Present back. Critique to highlight key concerns, does it solve the problem?. Iterate and loop back multiple times until you have a shared understanding of the problem and some good ideas.
3. Prototype: create something tangible that you can test on users
4. User test: Test your prototype on real users.
• Book recommendation: Rocket Surgery Made Easy
5. Team Pitch: playback to a larger group of stakeholders and colleagues. Get feedback from a business/ organisational perspective

UnKnown Playbook focused on User Value:

1. Research questions: Host a workshop with the team to gather research questions they have about the subject. Create an affinity map of the stickies, cluster them in different categories. Dot-vote on the most important research questions.
2. User research: Use 3 sources to gather research data (e.g. analytics, user interviews, customer support), Triangulate and validate the data from multiple perspectives
3. Design Sprint: Synthesise insights and create tangible solutions.
• Benefits: focus, time-boxed, functional , invite people from diverse perspectives, you have all the tools at your disposal
4. Team Pitch: Invite a wider group to review what you’ve accomplished and feedback

Bring your product and design functions together

• Avoid your design function continually working in a studio model without other functions. You risk their discoveries not being linked to the priorities of the business, getting stuck half finished with no clear learnings as a result
• Get to transparency, show where every initiative is:

• Doing so will…
• More discoveries will move into delivery
• Relationships will improve between product and deisgn
• Product will get better at discovery
• Discovery items will be linked to business goals
• More transparency on what’s in flight
• Common vocabulary and toolkit

6. Strategic Product Discovery

• Set measurable goals early for business value and customer value early on.
• Follow up on them as often as possible
• Express goals as desirable outcomes (or impacts → what happens when you achieve a goal)
• Establish and keep a clear connection between the goals throughout the process
• Tool: Opportunity Trees (Teresa Torres’)
• Tool: Impact mapping (InUse by Gojko Adzic)
• Structure problem space exploration → prioritise throughout development
• SMART goals are great. Specific, measurable, attainable, relevant, time based
• Goals should be outcome based → so they’re solution agnostic
• Impact mapping is good for when the emphasis is on different types of users

Outcome		x more of y by z
Target Groups	Group A	Group B	Group C
Needs	Need X	Need Ya Need Yb	Need Za Need Zb
Actions		Action Ta Action Tb

• Set and continuously measure the outcomes of business value and user value goals helps us to be strategic about product development from start to finsih.

• Feasibility Discovery in a nutshell:
• What skills do you have in the company?
• What technologies that you’re using might soon be obsolete
• What new technologies are there?
• How should we build things sustainably?
• What new competencies we need to develop?
• How we need to restructure organisation to meet future?
• Use Wardley Mapping to map: user needs → capabilities
• Use Thoughtworks Tech Radar to find a new potential solution and then build a spike to check if works

7. Discovery and Delivery sitting in a tree

• Product Discovery: Figuring out what to build
• Product Execution: Building it
• Product Definition
• Product Delivery
• Don’t confuse product definition with discovery.
• Discovery → Learning → Knowledge
• Delivery → Creating outcomes → Value
• Discovery isn’t a phase → It’s a mindset. Ideally we’d do it continuously.
• Feel you’ve learnt enough? → Be confident and move to delivery
• Feedback shows you don’t understand enough? → Be confident you should discover more
• Empowered teams and the Trio:
• Designer → customer point of view, user value
• Product → business view, value of the product
• Engineer → technology view, responsible for feasibility
• All → bring in additional expertise as required
• Discovery Brief
• Data: What trends are we seeing? (customer, sales, technology)
• Insight: Based on data, what are some clear insights we can leverage?
• Assumption: What are we assuming based on insights?
• Value: What’s the initial idea of the value proposition?
• Success: What does success look like?
• Discovery Stories: You can mix discovery and delivery by having discovery stories.
• Discovery Kanban: Work on the highest priority thing, balance learning rate and development rate over time
‣
Illustration:

• Not all problems are complex, and demand an iterative approach.
• Divide risk into 4 levels:
• No risk: Obvious problems → straight to delivery
• Low risk: Complicated problems → discovery process using playbook (mitigate risks)
• Medium risk: Complex problems → holistic discovery (iterate and increment through it)
• High risk: Complex problem, where if invalidated the product fails → quickly validate or invalidate our assumptions (e.g. Lean Startup)
• Ask the questions…
• How well do we understand the problem?
• How well do we understand the solution?
• Continuous Collaborative Discovery and Delivery:
• No risk? Go straight to delivery: Build, Measure, Learn
• Step A: No discovery Required
• Step B: Delivery (Build, Measure, Learn)
• Low/ Medium risk?
• Step A: Discovery Playbook (Triangulation Methods, double diamond)
• Step B: Delivery (Build, Measure, Learn)
• For high risk do Build, Measure, Learn loop before building
• Step A: Discovery assumption exploration (Build, Measure, Learn)
• Step B: Delivery (Build, Measure, Learn)
‣
Diagram

• Barriers to good discovery:
1. Lack of time and budget
2. Lack of buy-in and hard to prove value
3. Lack of involving the right people
4. Lack of access to users
• Change Model (Kurt Lewin)
‣
Thawing:
‣
Transitioning:
‣
Freezing:
• Peter Axbom’s Building Blocks for Change
• Lippitt-Knoster Model for Managing Complex Change, helps focus effort on a goal

Deep Summary

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

• This book is aimed at demystifying product discovery
• An effective product
• Business: makes money
• User: makes users happy
• Technical: is feasible to build
• Don’t just focus on your own part of the equation
• Why it’s so hard to build technology that achieves outcomes:
• Confirmation Bias: Undervaluing facts that don’t confirm what you believe, and favouring information that does
• Optimism Bias: We are less likely of experiencing a negative event compared to others
• Valuing outputs over outcomes: ideas are useless unless they solve a problem
• IKEA effect: If we ourselves are the creators, we perceive our creations as more valuable that what they really are
• Unchallenged assumptions: assumptions often remain unchallenged due to confirmation bias. It’s really easy to underestimate what happens if an assumption is false
• Sunk cost fallacy: when people involved feel like they’ve invested too much time and effort. They don’t want that to be a waste
• Siloed work: everyone just focuses on execution, rather than challenging existing assumptions
• More output fallacy: the belief that the more work we do the better it will be.
• Product is hard.
• Features: Only 20% of features built are often used by users, 30% are used infrequently or hardly ever (50%).
• Companies: 42% of startups fail because there’s no market need
• Product lessons:
• Don’t always listen to the customer
• Acknowledge test results
• Don’t be under time-pressure
• Excess capital creates complexity
• Software projects have two distinct stages:

• How important is discovery to success? (source nngroup.com)

It takes just as much effort to build the wrong thing as it does the right thing. John Allspaw

• Executives focus more on delivery than discovery. It’s easier to measure progress.
• Discovery is about:
• maximising impact be figuring out what to build
• minimising waste by figuring out what not to build
• Rule of thumb: Discovery should take about 10% of build time

Product Discovery Principles

• Problem-first approach over solution-first
• Fall in love with the problem not the solution
• Drill down to the core of the problem.
• Keep the problem top-of-mind, never forget the problem you’re solving.
• Outcomes over outputs
• it’s the outcome and impact that counts
• Team diversity, trust & openness over individual effort
• Diversity, inclusion, psychological safety, collaboration
• Diverse teams are 20% better at innovation and reduce risk by 30% (Source: Deloitte diversity and inclusion revolution)
• Holistic view over local optimisation
• Get the valuable perspectives of different disciplines
• Look beyond your silo, beyond your job, focus on what the company needs to achieve
• Continuous discovery over unplanned exploration
• The future is unknowable if you work in a complex domain. The only way to operate is to sense and respond

Discovery Frameworks

• Any approach requires a good feedback loops. Good feedback loops are iterative and incremental
• Iterative: repetition of a process to collect feedback and improve things for next time around
• Incremental: working in small batches, each increment builds on what came before
• Three Qualities of Successful Products:

• How can we fulfil the needs of customers, build the product in a sustainable way and build a sustainable business?
• The three types of risk: user value, business value, feasibility
• Highlight the risks upfront
• What’s the least amount of discovery we need to do to address a particular risk?
• See other books to learn about Ethical risk:
• Digital Compassion by Peter Axbom
• Future Ethics by Cennydd Bowels
• A designer’s code of ethics by Mike Monteiro
• Double Diamond (British Design Council)
‣
Diagram
1. User-centred design (UX) is one of the better existing frameworks
• Divergence: Exploring an issue more widely or deeply
• Convergence: Taking focused action
2. Diamond 1 (Explore the problem space)
• Spend time with customers, gather insight, define the problem
3. Diamond 2 (Explore the solution space)
• Generate potential solutions, validate them through prototypes
4. Not a linear process, can loop through it a few times
• Four stages for clarity

4. The powerful holistic framework

• Imagine an iterative and incremental process that systematically considers the three risks at each stage of the double diamond
• You can use the cells in the table to highlight questions or actual techniques

• The framework can help you understand what you historically did, or are presently doing:
• It can help you identify how ‘holistic’ is the approach you’re taking to discovery
• Are we assessing the risks well?
• Do we understand the full scope of the problem?
• Are we choosing the smartest way to visualise the solution at this stage?
• Are we evaluating with the right kind of people in a way that fits them?
• Will this activity make us learn the most?

• It can help you evaluate your toolbox, do you have questions, workshops and artefacts you can use in each box?
• You can run a workshop with your team to brainstorm product-discovery methods
• User value row: UX Design, Design Thinking, Service Design, Design Sprint, Lean UX
• Business value row: Business Model Generation, Customer Development, Jobs to be Done, Sense & Respond, Discover to Deliver and Lean Startup)

• Use the power of triangulation throughout discovery: Use several methods for each part of the matrix to make sure you cover as much ground as possible.
• Early on: qualitative methods are to be preferred
• Later on: quantitative methods are better (as they can understand what users are doing)

5. Product Discovery Playbooks

• Playbooks help teams navigate discoveries
• Known vs Unknown Playbook:
• Problems can have a varying degree of complexity
• Sometimes problems are easy to solve, else problems might need a lot of research
• Harder problems require more work, to find the root cause

Known Playbook: Focused on User value:

1. Hypothesis: We believe customers have [problem x]. If we provide [solution y], we will see [desired outcome z].
• Don’t be rigid about structure, but mention the problem you want to solve, a high-level solution statement and intended outcome.
2. Design Studio: Illuminate the problem with a presentation. Sketch solutions with everyone. Present back. Critique to highlight key concerns, does it solve the problem?. Iterate and loop back multiple times until you have a shared understanding of the problem and some good ideas.
3. Prototype: create something tangible that you can test on users
4. User test: Test your prototype on real users.
• Book recommendation: Rocket Surgery Made Easy
5. Team Pitch: playback to a larger group of stakeholders and colleagues. Get feedback from a business/ organisational perspective

UnKnown Playbook focused on User Value:

1. Research questions: Host a workshop with the team to gather research questions they have about the subject. Create an affinity map of the stickies, cluster them in different categories. Dot-vote on the most important research questions.
2. User research: Use 3 sources to gather research data (e.g. analytics, user interviews, customer support), Triangulate and validate the data from multiple perspectives
3. Design Sprint: Synthesise insights and create tangible solutions.
• Benefits: focus, time-boxed, functional , invite people from diverse perspectives, you have all the tools at your disposal
4. Team Pitch: Invite a wider group to review what you’ve accomplished and feedback

Bring your product and design functions together

• Avoid your design function continually working in a studio model without other functions. You risk their discoveries not being linked to the priorities of the business, getting stuck half finished with no clear learnings as a result
• Get to transparency, show where every initiative is:

• Doing so will…
• More discoveries will move into delivery
• Relationships will improve between product and deisgn
• Product will get better at discovery
• Discovery items will be linked to business goals
• More transparency on what’s in flight
• Common vocabulary and toolkit

6. Strategic Product Discovery

• Set measurable goals early for business value and customer value early on.
• Follow up on them as often as possible
• Express goals as desirable outcomes (or impacts → what happens when you achieve a goal)
• Establish and keep a clear connection between the goals throughout the process
• Tool: Opportunity Trees (Teresa Torres’)
• Tool: Impact mapping (InUse by Gojko Adzic)
• Structure problem space exploration → prioritise throughout development
• SMART goals are great. Specific, measurable, attainable, relevant, time based
• Goals should be outcome based → so they’re solution agnostic
• Impact mapping is good for when the emphasis is on different types of users

Outcome		x more of y by z
Target Groups	Group A	Group B	Group C
Needs	Need X	Need Ya Need Yb	Need Za Need Zb
Actions		Action Ta Action Tb

• Set and continuously measure the outcomes of business value and user value goals helps us to be strategic about product development from start to finsih.

• Feasibility Discovery in a nutshell:
• What skills do you have in the company?
• What technologies that you’re using might soon be obsolete
• What new technologies are there?
• How should we build things sustainably?
• What new competencies we need to develop?
• How we need to restructure organisation to meet future?
• Use Wardley Mapping to map: user needs → capabilities
• Use Thoughtworks Tech Radar to find a new potential solution and then build a spike to check if works

7. Discovery and Delivery sitting in a tree

• Product Discovery: Figuring out what to build
• Product Execution: Building it
• Product Definition
• Product Delivery
• Don’t confuse product definition with discovery.
• Discovery doesn’t always inform us that we should build something.
• Focus is on finding the right problem to solve → finding the right solution for that problem
• Discovery → Learning → Knowledge
• Delivery → Creating outcomes → Value
• It’s not easy to switch between discovery and delivery, they focus on different things and have different personalities.
• Discovery isn’t a phase → It’s a mindset. Ideally we’d do it continuously.
• Feel you’ve learnt enough? → Be confident and move to delivery
• Feedback shows you don’t understand enough? → Be confident you should discover more
• Look for virtual walls between discovery and delivery → replace them with collaboration and feedback loops
• Sprint Zero: Don’t misunderstand it, it’s getting ready for build, it’s not discovery
• Design Sprints: can break down silos, and help delivery teams learn discovery
• Holistic Product Discovery: a structured way of doing discovery.
• Dual track scrum: Make sure it doesn’t divide discovery and delivery.
• Cadences and signals:
• A cadence is the beat and rate of a rhythmic sequence, they enable feedback loops and shifts between discovery and delivery mindsets
• A signal is an indication that we need to do something else. E.g. running continuous quantitative and qualitative tests → switching mindsets if you get certain results.
• Do we have enough knowledge? Is the risk low enough?
• Empowered teams and the Trio:
• Designer → customer point of view, user value
• Product → business view, value of the product
• Engineer → technology view, responsible for feasibility
• All → bring in additional expertise as required
• Discovery Brief: (inspired by Spotify Data, Insight, Belief, Bet)
• Data: What trends are we seeing? (customer, sales, technology)
• Insight: Based on data, what are some clear insights we can leverage?
• Assumption: What are we assuming based on insights?
• Value: What’s the initial idea of the value proposition?
• Success: What does success look like?
• Discovery Stories: You can mix discovery and delivery by having discovery stories.
• Discovery Kanban: Work on the highest priority thing, balance learning rate and development rate over time
‣
Illustration:
• Cynefin Model (Dave Snowden)

Complex	Complicated
Enabling constraints Loosely coupled Probe → Sense → Respond Emergent Practice	Governing constraints Tightly coupled Sense → Analyse → Respond
Chaotic	Clear
Lacking constraint De-coupled Act → Sense → Respond Novel Practice	Tightly constrained No degrees of freedom Sense → Categorise → Respond Best Practice

• Not all problems are complex, and demand an iterative approach.
• Divide risk into 4 levels:
• No risk: Obvious problems → straight to delivery
• Low risk: Complicated problems → discovery process using playbook (mitigate risks)
• Medium risk: Complex problems → holistic discovery (iterate and increment through it)
• High risk: Complex problem, where if invalidated the product fails → quickly validate or invalidate our assumptions (e.g. Lean Startup)
• Ask the questions…
• How well do we understand the problem?
• How well do we understand the solution?
• Do we know that the solution solves the problem effectively, efficiently and sustainably?
• Lean Startup:
• Loop: Build → Measure → Learn
• Mimics the scientific method and experimentation
• Combine two loops:
• Discovery or Idea based: Build, Measure, Learn
• Delivery or backlog based: Build, Measure, Learn
• Ideas that are promising make the backlog
• Learning from implemented backlog items feed ideas/discovery
• Lean UX is like Lean Startup but is based mainly on qualitative where the Lean Startup method is Quantitative
• Continuous Collaborative Discovery and Delivery:
• No risk? Go straight to delivery: Build, Measure, Learn
• Step A: No discovery Required
• Step B: Delivery (Build, Measure, Learn)
• Low/ Medium risk?
• Step A: Discovery Playbook (Triangulation Methods, double diamond)
• Step B: Delivery (Build, Measure, Learn)
• For high risk do Build, Measure, Learn loop before building
• Step A: Discovery assumption exploration (Build, Measure, Learn)
• Step B: Delivery (Build, Measure, Learn)
‣
Diagram

8. How to get started

• Understanding the culture is important. 4 main reasons for not being able to do good discovery:
1. Lack of time and budget
2. Lack of buy-in and hard to prove value
3. Lack of involving the right people
4. Lack of access to users
• Existing processes can make it hard to do a good discovery
• Three types of change:
• Operational: improve what you do already
• Transitional: change what you do (process)
• Transformational: change mindsets and behaviours, organisational and cultural change

Know Your Change Models:

• ADKAR Model (Jeff Hiatt)
• 8 Step Change Model (John Kotter)
• Change Model (Kurt Lewin)
• Thawing:
• Getting ready to change
• Establish that change in necessary
• Getting ready to leave comfort zone
• Compelling message required to get people to let go
• Having insight into the disease when you’re ill
• Transitioning:
• Making the changes that are needed
• A process, a transition
• Involve people in the process changes
• Get people’s feedback?
• Is it working
• Get to a shared understanding
• Freezing:
• Make the change permanent
• Develop ways to sustain the change
• Peter Axbom’s Building Blocks for Change
• Lippitt-Knoster Model for Managing Complex Change, helps focus effort on a goal