5 exercises — Practice vocabulary for product discovery: continuous discovery habits, hypothesis validation, validated problem statements, and opportunity solution trees.
0 / 10 completed
1 / 10
A PM says: "We're in the discovery phase right now — we haven't started building anything." A stakeholder asks what that means. Which explanation is correct?
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
2 / 10
A PM mentions "continuous discovery habits" as the basis for the team's research cadence. Which practice best describes continuous discovery?
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
3 / 10
A PM says: "We ran 20 customer interviews to validate the hypothesis." A colleague asks what hypothesis was being validated. What does "validate a hypothesis" mean in discovery?
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
4 / 10
After a discovery sprint, the team produces a "validated problem statement." What does this output represent?
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
5 / 10
A PM describes the "opportunity solution tree" as the team's central discovery artefact. A new product designer asks how it guides the team's work. Which answer is most accurate?
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
6 / 10
Sarah (Product Manager) sends a Slack message to the engineering team: 'Okay team, let's focus on confirming the core user need for this feature. We'll be using 'jobs to be done' as our framework.' Which of the following best describes Sarah's intention?
'Jobs to be done' is a framework for discovery that centers around understanding the user's motivation and goals. Sarah isn't just asking about requirements; she's prompting the team to investigate *why* users are seeking this feature – what 'job' they're trying to accomplish. Option A is incorrect because it focuses on a different aspect of product definition, while option D suggests a misprioritization of tasks.
7 / 10
David (Lead Engineer) writes a commit message for a pull request: 'Refactored the user authentication flow. Added logging for error tracking.' A junior developer asks: 'What's the purpose of this refactoring in the context of discovery?' Which explanation is most accurate?
In discovery, refactoring isn't just about making things 'cleaner'; it's often about creating opportunities to gather data. By improving logging and error tracking, David is setting up the system to collect more information about how users interact with the authentication flow – valuable insights for validating assumptions or identifying new problems. Option A correctly identifies that the refactoring directly supports data collection which is a core aspect of discovery.
8 / 10
Maria (Product Manager) asks the team: 'Let's build out this opportunity solution tree to map out all potential solutions.' What is Maria referring to?
An 'opportunity solution tree' is a discovery artifact designed to systematically explore potential solutions for a problem. It visually maps out different options and their associated characteristics (complexity, impact) – a key tool in identifying the most promising avenues for investigation during the discovery phase. Options A and D are incorrect because they describe other product development outputs.
9 / 10
Ben (UX Designer) is reviewing a PR description for a feature that adds a new user onboarding flow. The description reads: 'Implemented the initial steps of the onboarding process based on our research.' What does Ben likely need to consider next?
The PR description highlights that the onboarding flow is based on prior research. Ben's primary responsibility now is to ensure this implementation *actually addresses* the validated problem – meaning it solves the user need identified during discovery and aligns with the team's goals. Options A, C, and D represent secondary considerations, not the core focus of validating a discovery outcome.
10 / 10
Chloe (Product Manager) is presenting to stakeholders. She says: 'We're running several A/B tests to optimize the user flow.' Which of the following statements best describes Chloe's approach to discovery?
Chloe's use of A/B testing demonstrates a commitment to continuous discovery – gathering data through experiments to refine hypotheses and validate solutions. This iterative process is central to the discovery phase, allowing for dynamic adjustments based on measurable results. Options A, C, and D represent less agile or effective approaches to product development.
What will I practice in "Discovery Vocabulary — Product Management Language | CoderLingo"?
This is a Product Management Language exercise set. It walks through 10 scenario-based multiple-choice questions built around real usage of product management language terminology that IT professionals encounter on the job.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to complete with no account, sign-up, or paywall.
How many questions are in this exercise?
This set contains 10 questions. Each one shows immediate feedback and a detailed explanation after you answer, so you learn the correct usage right away rather than waiting for a final score.
Do I need prior experience to complete this exercise?
No prior experience is required. Each question includes a full explanation covering the reasoning behind the correct answer, so the exercise itself teaches the product management language vocabulary as you go.
Can I retry the exercise if I get questions wrong?
Yes — use the "Try again" button on the results screen to reset your answers and go through all the questions again. There is no limit on attempts.
Is my progress saved?
Your answers and score for the current session are tracked in the browser as you go. No account or login is needed, and there is nothing to install.
What if I don't understand a term used in a question?
Read the explanation shown after you answer each question — it breaks down the correct term in plain English with a real-world example. You can also check the site Glossary for quick definitions.
How is this different from reading a blog article on the topic?
Exercises like this one are interactive drills that test and reinforce specific vocabulary through multiple-choice questions, while blog articles explain concepts in prose. Practising here after reading builds active recall, not just passive recognition.
Where can I find more Product Management Language exercises?
See the Product Management Language exercises hub for the full set of related pages, or browse all exercise categories from the main Exercises index.
Can I use this exercise to prepare for a technical interview?
Yes — product management language vocabulary comes up often in technical discussions and interviews. Pair this exercise with our dedicated Interview Preparation section for role-specific practice.