Review

A super short but powerful artefact that’ll help you get started with Product Discovery. You can’t go wrong by starting with this basic approach and adding in complexity later should you need it.

You Might Also Like:

The Right It

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

andrewclark.co.uk

Sprint

I have a real soft spot for this book. I read it soon after it was published, just in time for it to inform some discovery work I was doing. It is refreshingly practical and amazing for those doing discovery work for the first time. While more experienced individuals may find the Sprint format a little rigid, each time I re-read this book, I discover something new.

andrewclark.co.uk

Book Summary: Continuous Discovery Habits by Teresa Torres

In Continuous Discovery Habits, Teresa Torres introduces a framework for building the right product by maintaining ongoing, weekly touchpoints with customers. She advocates for continuous discovery—a process of conducting small research activities to uncover valuable insights. Rather than viewing discovery as a one-time event, Torres emphasizes the importance of consistently framing problems in a customer-centric way and exploring the opportunity space. Using the Opportunity Solution Tree, teams can prioritize what to do next and focus on high-impact opportunities. Ideal for product managers seeking to balance discovery and delivery, and build products that create value for both the business and its customers.

andrewclark.co.uk

Key Takeaways

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

Discovery recipes provide a robust team-based process to iteratively identify, validate and refine product hypotheses through rapid learning cycles with real users and customers before over-investing in the wrong solutions.

Introduction

• Most software development efforts end up wasting a lot of time building the wrong things. Studies show 50-80% of software features fail to accomplish their objectives.
• Product discovery work helps get evidence that the problems being solved really exist, customers want the solutions, and the team can feasibly build them.
• Discovery work validates ideas before fully investing in them. While you can't always be right, you can at least validate ideas have a reasonable chance of success.

Product Discovery Team:

• A good discovery team has a mix of business, user experience, and technical skills to create solutions that are valuable, usable, and feasible.
• The team should be able to work with stakeholders, identify and interview customers, design user experiences, create prototypes, etc.
• The team works together collaboratively, sometimes splitting up tasks then coming back together to rebuild shared understanding.
• Discovery goes better if the team follows this checklist:
• Creates and maintains an evidence board
• Talks to 10+ users per week
• Tries new experiment types
• Ideates together
• Expresses beliefs as hypotheses
• Creates a learning backlog
• Tracks hypothesis changes
• Kills at least one idea
• Breaks into pairs to work on several concurrent discovery tasks.

Validated Learning Cycle:

1. Declare your hypotheses about:
• the problems you’re solving for specific customers / users
• solutions you believe will solve them
• outcome - how customers will react and use your solution
• impact - what business impact the expected customer behaviour change will have
2. Identify risks, assumptions and questions that need to be learned
3. Create a test plan
4. Run the test
5. Synthesise results and update hypotheses

Evidence Board:

• Like a detective team, the discovery team should maintain a shared evidence board to build shared understanding and move faster.
• Hypothesis statements (We believe…)
• Problem hypotheses (user profiles, current user journeys, problem sketches),
• Solution hypotheses (sketches, journey maps, metrics)
• Next thing to learn
• Next thing to test
• Learning backlog (prioritised risks, assumptions, questions)
• Discovery task board
• Learnings that changed hypotheses (Deltas)
• Past interview notes

Simple User Models:

• Create simple user profiles or proto-personas based on differences in goals, behaviours, motivations, not just demographics.
• Gather profile info like general characteristics, relevant behaviours, and motivations (pains, obstacles, rewards).
• Use personas as design targets. Start with assumptions and replace with facts from discovery.
• Consider age, expertise, tech skills, frequency of use, collaborators, locations, other tools used, and alternatives.

Map User Experience:

• Use simple journey maps or story maps on stickies to map how target users do things today and in the future with the product.
1. Identify target user types and key activities with a clear start and end
2. Map the main story steps in a narrative flow, then add alternatives
3. Add where users encounter pains and rewards
4. Add frequency, duration, location, tools, collaborators for each step

Ideate With Your Team:

• Identify better solutions by ideating many possibilities as a team, then combining and refining the best ideas.
• Discuss target users, their current journeys and challenges. Review inspirational examples.
• Write a "How Might We" statement to focus efforts.
• Timebox rounds where everyone quickly sketches as many ideas as possible.
• Share ideas with the group, discuss from the user's POV. Vote on favourites.
• Converge best ideas into more detailed designs.

Identify Questions & Tests:

• Collaboratively plan the next user interview or test using a 2-column approach:

1. What the team wants to learn (about the user or their usage):
• Challenges or frustrations?
• Motivations or joys?
• Characteristics and skills
2. What they will ask to elicit stories, examples and demonstrations

• Brainstorm both columns, map questions to ask, prioritise what's most important.

Interview Planning:

• Outline interviews with an intro, background gathering, problem understanding through usage stories, testing ideas/prototypes, note-taker questions, and wrap-up.
• Pick an interviewer to lead and seconds to take notes. Have the interviewer ask users to imagine using a new solution.

Note-Taking:

• Take notes on paper or stickies to avoid distracting computer clicking.
• Watch for revealing body language, actual behaviours, and quotes.
• Capture facts about the subject, what they do (verbs), how they feel (adjectives), direct quotes.

Interview Synthesis:

• Immediately after, highlight best notes and transfer to stickies if not already.
• Use a 2x2 to group notes into: About (the subject), What they do, How they feel, What they say (quotes)
• Take turns discussing and adding related notes until all are captured.
• Discuss key takeaways and insights across interviews.

Learnings in Delta-Next:

• After each round of interviews, reflect on how learnings change hypotheses.
• Capture:
• Δ What did you gain confidence in?
• Δ- What were you wrong about?
• Δ+ What new info changes your hypothesis?
• ? What new questions do you have?
• Discuss if deltas can change hypotheses now or need more testing.
• Update artefacts like personas, journey maps, and designs.