Continuous Discovery Habits

The problem it solves

Many teams put their effort into delivery: did we ship on time and on budget. Torres argues they under-invest in discovery, the work of deciding what to build, so they learn after launch that customers did not want it. Others do research in bursts, then build for months without contact, and the assumptions go stale.

Her answer is a different rhythm. The team that builds the product talks to customers every week, and each conversation serves a defined outcome. A month between conversations means a month of decisions made without customer input.

What changes in how you work

You start from an outcome, not a feature list. You interview regularly about specific past events and file what you learn as opportunities: needs, pain points and desires. You then pick one target opportunity, come up with several solutions and test the riskiest assumptions behind them before building.

The habit that matters most is comparing options. You weigh several opportunities against each other, then several solutions, and avoid the trap of asking whether one idea is good enough.

When to read it, and when not

Read it when your team ships features and cannot say which ones worked, or when roadmap debates are settled by the loudest voice. It suits small digital product teams, and it is written for a trio of a product manager, a designer and an engineer.

If you have no product team yet, or you sell something that is not built in iterations, you will have to adapt more. Start with the first two chapters and the one on interviewing before you take on the rest.

What to be careful about

The method assumes a team that is allowed to own an outcome. Torres says directly that many readers will think their company does not work this way, and her advice is to start small and show the benefit rather than argue.

It is also easy to treat the tree as paperwork. Her own warning is that research is not for its own sake: every conversation must serve the outcome. Keep the tree short and live, and update it after each week.

Connecting it to a repeatable system

The tree is a record of decisions: the outcome chosen, the opportunities weighed, the solutions compared and the tests with their results. If you log them with the reasons, you can see later why you built what you built. The weekly routine around it, such as recruiting interviewees, writing up a one-page snapshot and setting up a test, is repeatable work that can become a written playbook. Choosing the outcome and the target opportunity stay with people.

Torres argues that product teams do better when they treat discovery as a continuous activity and not a phase. She defines continuous discovery as weekly touchpoints with customers, by the team building the product, with small research activities in pursuit of a desired outcome. The book gives a framework, the opportunity solution tree, and eleven habits for using it, aimed at a product trio of a product manager, a designer and an engineer.

Introduction

Torres explains why she wrote the book. After years in startups she was tired of arguing with executives about strategy when she was the only one who had spent time with customers. She decided to help many teams work differently instead of changing one company at a time.

The What and Why of Continuous Discovery

The book separates discovery, deciding what to build, from delivery, building and shipping it, and says most companies over-invest in delivery. It traces how discovery moved from annual budgets owned by business leaders towards the whole product team talking to customers. It then lists six mindsets: outcome-oriented, customer-centric, collaborative, visual, experimental and continuous.

A Common Framework for Continuous Discovery

The chapter opens with a bank that set a target for accounts per customer without a customer-centric mindset, and its staff cheated. Torres calls customer needs, pain points and desires opportunities. The opportunity solution tree places the desired outcome at the top, the opportunity space below it, then the solution space and assumption tests. She says the tree helps a team resolve the tension between business and customer needs and share what it is learning.

Focusing on Outcomes Over Outputs

An output is something you ship, an outcome is a change in behaviour that drives results. The book distinguishes a business outcome, a product outcome and a traction metric, and warns that lagging measures such as 90-day retention are hard to steer by. It also warns that chasing one outcome at the cost of everything else derails a team, so teams should watch health metrics too.

Visualizing What You Know

Before interviewing, each team member draws an experience map of the customer's context, and the trio merges them into a shared one. The map is a first draft of what you think you know, not truth, and it will be tested. Torres urges drawing with boxes and arrows, because it makes disagreements specific.

Continuous Interviewing

Interviews are weekly and based on stories. Instead of asking what customers want, you ask them to tell you about a specific time something happened, then dig into the detail. After each one you write an interview snapshot, a one-page summary, so you synthesise as you go and do not batch. As Torres puts it, "We aren't doing research for research's sake."

Mapping the Opportunity Space

Opportunities from interviews are arranged on the tree as parents and children, where a child is a subset of a parent. A test of a good opportunity is whether it has more than one possible solution. Opportunities that are solutions in disguise, and feelings recorded as opportunities, should be traced back to their cause.

Prioritising Opportunities, Not Solutions

Pick a target opportunity by comparing and contrasting siblings. The chapter proposes four lenses: how many customers are affected and how often, market factors, company factors and customer factors. It advises you to time-box the decision and move on, since you will learn more from testing than from a perfect choice.

Ideation

Torres argues that quantity predicts quality, and that the most original ideas come late. She asks teams to generate many ideas for the target opportunity, give ideation time and not just one meeting, then choose a set of three that differ from each other. Analogous products from other industries help when you are stuck.

Identifying Hidden Assumptions

Every idea rests on assumptions, which the book sorts into desirability, viability, feasibility, usability and ethics. Write each so that you need it to be true, and make it specific enough to test. Teams tend to favour one category and forget the others, and most forget ethics.

Testing Assumptions, Not Ideas

Test the riskiest assumption, not the whole idea. A good test simulates an experience so people behave and do not just say what they would do. Define how many people you will test and what result counts as success before you start, and design for the best case first. Unmoderated tests and one-question surveys make this fast.

Measuring Impact

Delivery fuels discovery. Instrument only what you need to evaluate this week's tests, then connect the change in product outcome to the business outcome, since that link is itself a theory to be checked. Do not stop at a pleasing solution, because desirability is not enough without viability.

Managing the Cycles

Discovery is not linear. The chapter shows teams at several companies who learned something surprising and had to loop back, for example an opportunity that mattered less than expected. The skill is to avoid drawing conclusions from shallow findings and to remember that small changes add up.

Show Your Work

Stakeholders trust teams that show their thinking. Use the tree to walk them from the outcome through what you learned to the options and tests, and let them add what you do not know. Show, do not tell, choose your battles, and avoid ideological arguments.

Start Small, and Iterate

The last chapter answers the reader who says their company does not work this way. Build your trio, begin with weekly interviews, and add the other habits one at a time. You do not need permission to start.

What to do with it

• Agree one outcome with your leaders that your team can influence directly.
• Book a customer interview every week, ask for stories about specific past events, and write a one-page snapshot after each.
• Draw an experience map and an opportunity solution tree, and keep both on a wall or shared board.
• Pick one target opportunity, come up with several solutions, then list the assumptions behind each and test the riskiest.
• Record each decision and its test result, and share the tree with stakeholders every few weeks.