5 exercises — Practice JTBD framing, problem-space thinking, assumption mapping, continuous discovery, and anti-pattern identification.
0 / 10 completed
1 / 10
You're learning about the Jobs to be Done (JTBD) framework. A PM describes user behavior as "they hire our app to..." — a new team member asks what this language means. Which explanation is correct?
JTBD reframes product thinking around user goals rather than product features — users "hire" products to make progress in their lives, not to use specific functionality.
The classic JTBD example: people don't buy a drill — they hire it to make a hole. More profoundly, they hire it to hang a shelf so their home feels organised. The emotional job (feeling organised) is as important as the functional job (making a hole). In product discovery, JTBD interviews use the "timeline interview" technique: walk the user through the last moment they used a competing solution or made the purchase decision — not asking about features, but about the circumstances and motivations.
Key vocabulary:
• functional job — the practical task the user needs to accomplish
• emotional job — how the user wants to feel while doing the task
• social job — how the user wants to be perceived by others while using the product
2 / 10
During a discovery session, a user says "I need a button that exports my report to PDF." A skilled PM responds: "So the job you are trying to do is share this report with people who do not have access to our tool?" Which PM behaviour best describes what happened?
Solution-to-problem reframing is a core discovery skill — it prevents teams from building the first feature requested rather than the best solution to the actual job.
Users naturally propose solutions because they've already been solving the problem. A skilled PM listens for what's underneath the proposed solution: what job was unsatisfied that caused them to reach for this solution? In this case, "PDF export" is one solution to "sharing reports with non-users" — but shareable links, scheduled digests, or portal views might serve the job better with less engineering effort. Problem-space insights generate a richer solution space.
Key vocabulary:
• problem space — the domain of unmet user needs and pain points; explored before committing to solutions
• solution space — specific product ideas and implementations; entered after validating the problem
• reframing — translating a stated solution back into the underlying problem or job to be done
3 / 10
Your team is starting work on a new feature. A senior PM suggests running an assumption mapping exercise first. What does this mean in practice?
Assumption mapping externalises and prioritises the beliefs a team is building on before committing to a solution — it prevents building on a foundation that hasn't been tested.
Every product decision rests on assumptions: "users will pay for this", "this integration is technically feasible", "users currently do X manually". By plotting assumptions on a 2x2 matrix (importance vs. confidence), teams identify which ones are "leap of faith" assumptions — high importance, low confidence. These become the first experiments to run. Tools like the Assumption Mapping canvas (by David Bland) or the risk matrix in continuous discovery make this tangible and collaborative.
Key vocabulary:
• assumption — a belief you're treating as true that hasn't been empirically verified
• riskiest assumption — a belief that is both critical to success and currently unvalidated
• assumption mapping — plotting beliefs on importance vs. confidence to prioritise validation experiments
4 / 10
A PM mentions they structure their discovery using an "opportunity solution tree." A new PM asks what that means. Which explanation is correct?
The opportunity solution tree is a visual tool that keeps discovery teams outcome-focused by structuring the relationship between their target outcome, discovered opportunities, and proposed solutions.
The tree prevents a common anti-pattern: jumping directly from outcome to solution without deeply understanding opportunities. Each branch of the tree represents a discovered user opportunity — a quote, pattern, or pain point from research. Solutions are proposed only beneath specific opportunities, making the reasoning transparent. Teams then run small, rapid experiments to evaluate solutions before committing to build. The tree evolves continuously as new interviews and experiments add data.
Key vocabulary:
• opportunity — an unmet need, pain point, or desire discovered through user research
• outcome — the desired change in user or business behaviour that anchors the tree
• continuous discovery — the practice of conducting small-batch research touchpoints every week rather than in large, infrequent projects
5 / 10
In a user discovery interview, a PM asks: "Would you use a feature that lets you schedule your reports weekly? We think it would save you time." What discovery anti-pattern does this demonstrate?
Solution-first leading questions are one of the most common discovery anti-patterns — they generate false validation because users naturally agree with suggested benefits rather than sharing their actual behaviour.
"Would you use a feature that X?" almost always gets a "yes" — users want to be helpful, and the hypothetical framing doesn't anchor to real behaviour. This produces data that confirms the PM's existing belief (confirmation bias) rather than revealing how users actually work. The correct pattern: ask about past behaviour ("tell me about the last time you..."), not future hypotheticals; let the user name the problem before proposing solutions; and never suggest the outcome you hope to hear ("save you time").
Key vocabulary:
• leading question — a question that suggests a preferred answer or outcome within its framing
• confirmation bias — the tendency to seek and favour information that confirms existing beliefs
• behavioural question — asks about past, observable behaviour rather than hypothetical preferences
6 / 10
You're working with a user to understand their needs for a new project management tool. They repeatedly say, 'I need something that helps me keep track of all my tasks and deadlines.' A Product Manager asks you: 'What does this statement tell us about the *job* they're trying to get done?'
The correct answer identifies that the statement reflects a 'job' – in this case, managing tasks and deadlines. Simply stating symptoms (like 'struggling with time') doesn't reveal the core motivation behind the user's actions. The key is understanding what they are *trying to achieve*.
7 / 10
A Product Manager is facilitating a workshop with stakeholders to define the requirements for a new mobile app. During the session, one stakeholder says: 'We need an interface that's intuitive and easy to use.' What does this statement most accurately represent in terms of product discovery?
This statement represents an early hypothesis – a preliminary idea about what the users want. It's not yet validated by research or testing. Framing it as a 'detailed technical specification' would be premature and wouldn't reflect the exploratory nature of product discovery.
8 / 10
During a Slack conversation about a new feature for an e-commerce platform, a PM types: 'Let's explore if users are willing to pay a premium for expedited shipping.' What discovery technique is the PM primarily employing?
The PM is using the Opportunity Solution Tree technique to systematically explore different ways to address a potential user need—in this case, faster shipping. The Jobs to be Done framework focuses on *why* people choose a product or service (the 'hire' decision), which aligns with testing willingness to pay.
9 / 10
A developer is reviewing a PR and sees the following comment: 'This code doesn't handle edge cases properly. It could crash if the user enters invalid data.' What does this comment highlight regarding the product discovery process?
The comment points to a lack of consideration for how users might interact with the system – specifically, invalid data input. This reveals a missing piece of information about the user's potential behavior and constraints during the discovery phase. It's not simply 'technical debt'; it's a failure to anticipate a user scenario.
10 / 10
A PM is leading a standup meeting and says: 'Okay team, let's focus on understanding what the core problem our users are trying to solve with this new dashboard is. What's the *real* need we're addressing?' Which of the following best describes the PM's intention?
The PM is using this question to shift the focus from technical implementation (feasibility) to *why* users want a dashboard in the first place. Understanding the 'job' they are trying to get done is central to effective product discovery and ensures the team builds something truly valuable.
What will I practice in "Product Discovery Vocabulary — Product Management | 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.