Discovery Vocabulary

Discovery is not a one-time phase — it is a continuous discipline that runs alongside delivery to ensure the team always has a validated pipeline of opportunities.

Teresa Torres popularised "continuous discovery" to distinguish it from the old waterfall model where discovery was a single up-front research project. In modern product teams, discovery is a weekly habit: short user interviews, prototype tests, and assumption experiments feed a constantly evolving opportunity solution tree. The goal is always the same — reduce the risk of building the wrong thing by validating that you understand the problem and the solution before committing full engineering effort.

Key vocabulary:
• discovery phase — the research and validation work done before (and during) development to ensure problem-solution fit
• continuous discovery — the practice of conducting small-batch research touchpoints every sprint rather than in a single waterfall phase
• validated problem statement — a problem definition confirmed by evidence from user research and data

Continuous discovery is a rhythm, not a project — it is the habit of talking to users weekly so that insights arrive continuously rather than in quarterly batches that quickly go stale.

Teresa Torres defines the minimum viable continuous discovery habit as "at least one touchpoint per week with customers by the product trio." The product trio (PM, designer, engineer) participates together to build shared understanding. Sessions are short — 30-45 minutes — focused, and connected to the current opportunity solution tree. Over time, the team builds a repository of customer quotes and patterns that inform every prioritisation decision. The contrast is with "big discovery": months of research that produce a report no one reads by the time engineering is ready to build.

Key vocabulary:
• product trio — PM, designer, and engineer participating together in discovery activities
• touchpoint — any structured interaction with a customer that generates insight (interview, test, observation)
• research cadence — the regular schedule of discovery activities a team commits to maintaining

In discovery, "validate" means test with evidence — not get approval, not estimate, but find data that could prove the assumption wrong and see whether it survives.

A good discovery hypothesis looks like: "We believe that [user type] experience [problem] when [situation], and we will know this is true when [evidence threshold]." The evidence threshold makes it testable: "5 of 7 interviewees describe unprompted that they struggle to share reports with external stakeholders." Validation with 20 interviews is strong signal — it means the PM talked to enough people across different segments to have confidence the problem is real and widespread, not just a vocal-minority complaint.

Key vocabulary:
• hypothesis — a falsifiable belief about a user need, problem, or behaviour that shapes discovery work
• validate — to confirm a hypothesis through evidence that could have disconfirmed it
• evidence threshold — the predefined criterion (e.g., "5 of 7 users") that determines when a hypothesis is considered supported

A validated problem statement is discovery's primary deliverable — a grounded, evidence-backed definition of a user problem that the team is now confident is real and worth solving.

The classic structure: "We've observed that [user segment] struggles with [specific situation], causing [negative outcome]. We've validated this with [N] interviews and [data point] — [X%] of users in this segment experience the problem monthly." This gives the team a stable anchor for the design phase. Without validation, a problem statement is just a hypothesis — a hunch that might be wrong. The discovery sprint's job is to move from hypothesis to validated statement through evidence. The output then drives opportunity exploration and ideation rather than jumping straight to solutions.

Key vocabulary:
• problem statement — a clear, scoped description of a user problem that a product team is addressing
• discovery sprint — a time-boxed research period focused on validating a specific problem or opportunity
• evidence-backed — supported by data from research rather than assumptions or stakeholder opinion

The opportunity solution tree is the discovery team's "north star" artefact — it keeps everyone anchored to the desired outcome and prevents the common trap of building solutions that aren't connected to validated user needs.

Developed by Teresa Torres, the tree has four levels: (1) the desired outcome — a measurable change in user behaviour the team is responsible for; (2) opportunities — needs, pains, and desires discovered through research; (3) solutions — specific product ideas that address a particular opportunity; (4) experiments — small tests that validate assumptions about each solution. The tree is never "done" — it grows as interviews add new opportunities and experiments resolve unknowns. Its value is in making discovery work transparent: anyone can look at the tree and understand why the team is building what it's building.

Key vocabulary:
• desired outcome — the measurable user or business behaviour change the team is responsible for achieving
• opportunity node — a discovered user need, pain point, or desire that represents a potential avenue for the product to improve the outcome
• experiment — a small, fast test designed to reduce uncertainty about a solution assumption