A product manager explains user stories at a team training: "A user story captures value from the user's perspective: 'As a [user type], I want [feature] so that [benefit].' The key is the 'so that' — it connects the feature to a user outcome, not just a capability. Acceptance criteria make it testable: 'Given [context], when [action], then [result].' The mistake I see most: acceptance criteria that describe implementation instead of behaviour — 'the system calls the cache API' vs. 'search results appear within 500ms.'" What is the purpose of acceptance criteria in a user story, and what makes them well-written?
Acceptance criteria (AC): the specific conditions a story must satisfy to be accepted as done. Format: Given [precondition] / When [action] / Then [expected outcome]. Example: Given a user is on the search page / When they type 'laptop' and submit / Then results appear within 500ms and show at least 10 items. Good AC is: Observable: can be tested without reading the code. User-facing: describes behaviour the user (or QA) can verify. Specific: 'within 500ms' not 'fast.' Outcome-focused: not 'calls the cache layer' but 'results appear quickly.' Bad AC: describes implementation ('the API must be RESTful'), is ambiguous ('the page loads'), or is untestable ('users feel satisfied'). User story vocabulary: User story: 'As a [user type], I want [capability] so that [benefit].' The 'so that' is the business value — it prevents building features for no reason. Story point: a relative size estimate (Fibonacci sequence: 1, 2, 3, 5, 8, 13). Not hours. Epic: a large body of work spanning multiple stories. Vertical slice: a story that delivers end-to-end value (UI + API + DB) vs. a horizontal slice (UI only). Walking skeleton: the thinnest possible vertical slice that demonstrates the full system works end-to-end. In conversation: 'When engineers say they're not sure what done looks like, that's a signal the AC needs more specificity. Good AC eliminates that uncertainty before the sprint starts.'
2 / 14
A product manager introduces Jobs-to-be-Done (JTBD) to the team: "JTBD reframes the question: users don't want your product — they want to get a job done. The job is the progress they're trying to make in a specific situation. 'Job': I need to communicate a decision to remote stakeholders. 'Hired': email, Slack, Notion doc. We 'hired' these tools for that job. JTBD helps discover what our users are actually trying to accomplish — it stops us from building features that look good in demos but don't solve real problems." What is Jobs-to-be-Done (JTBD) and how does it differ from traditional feature-based thinking?
JTBD (Jobs-to-be-Done) (Clayton Christensen): When people buy or use a product, they 'hire' it to do a job for them — to make progress in a specific situation. JTBD format: 'When [situation], I want to [motivation / job], so I can [expected outcome].' Feature vs. JTBD thinking: Feature: 'Users want a document editor.' JTBD: 'When collaborating with remote colleagues on a decision, I want to capture and share our reasoning clearly, so stakeholders can review it asynchronously and trust the decision.' The JTBD reveals: the real competitors are email, Google Docs, Loom, a Slack thread — not just 'other document editors.' Product discovery vocabulary: Opportunity solution tree (Teresa Torres): structured visualization linking desired outcomes → opportunities (unmet needs/jobs) → solutions → experiments. Assumption mapping: identifying assumptions in a solution and ordering by importance + uncertainty. Highest importance + highest uncertainty = test first. Customer interview: the primary discovery tool for understanding jobs, struggles, and context. Rule: listen for stories ('tell me about a time when...'), not opinions ('would you use this?'). Problem statement: a crisp articulation of the job and the gap. Switch interview: asking users why they switched from a competitor — reveals the job more clearly than asking about their current behaviour. In conversation: 'JTBD stopped us building a feature 60% of users said they wanted in surveys. A JTBD interview revealed the real job — which we solved with a two-line copy change, not a new feature.'
3 / 14
A PM presents RICE scoring to justify deprioritising a feature request: "RICE helps us compare unlike things on the same scale. Reach: how many users does this affect per quarter? Impact: what's the effect per user (0.25=minimal, 0.5=low, 1=medium, 2=high, 3=massive)? Confidence: how certain are we about these estimates (100%=high, 80%=medium, 50%=low)? Effort: engineering weeks. Formula: (Reach × Impact × Confidence) ÷ Effort. A feature affecting 10K users with high impact and high confidence, taking 2 weeks: (10000 × 2 × 1.0) ÷ 2 = 10,000 RICE. That beats a fancy feature affecting 500 power users even if it sounds more exciting." What is the purpose of RICE scoring in product prioritisation, and what does the Confidence factor account for?
RICE (Reach × Impact × Confidence ÷ Effort): A prioritisation framework by Intercom. Reach: number of users/customers affected in a time period. Source: analytics. Impact: magnitude of effect per user. 0.25=minimal, 0.5=low, 1=medium, 2=high, 3=massive. Subjective but forces calibration. Confidence: how sure you are about your Reach and Impact estimates. 100% = data-backed. 80% = some evidence. 50% = mostly a guess. Prevents gaming: inflating Confidence requires justification. Effort: person-weeks from all roles. Denominator: penalises large items. RICE score interpretation: higher is better. Comparable across items. Limitations: RICE is not a strategy. It optimises for what you're measuring (reach × impact) — which may not align with strategic bets. Use alongside qualitative judgement. Prioritisation framework vocabulary: MoSCoW: Must have / Should have / Could have / Won't have. Simple; doesn't handle uncertainty. Kano model: classifies features by how they affect satisfaction (basic needs vs. performance vs. delight). Opportunity scoring: (importance × (importance - satisfaction)) — identifies gaps. Stack ranking: force-ranking all items 1–N. Eliminates ties. Now/Next/Later roadmap: three-bucket roadmap without dates. Reduces over-commitment. In conversation: 'RICE is a conversation tool more than a truth machine. The value is in making assumptions explicit — if two PMs disagree on a RICE score, it reveals a disagreement about Reach or Impact that's worth having explicitly.'
4 / 14
A product lead defines the north star metric for the team: "Our north star metric is weekly active users who complete at least one search and one save action. It captures the core user behaviour that correlates with long-term retention — both parts matter. We don't use DAU alone (that could include low-quality sessions) or saves alone (someone could save without finding value). Guardrail metrics prevent optimising for the north star in ways that hurt the business: we track page load time, support ticket volume, and NPS — if any cross a threshold while we improve the north star, we stop." What is the role of guardrail metrics in product metric design?
North star metric: the single metric that best captures the core value delivered to users — when it goes up, the business goes up. Examples: Airbnb: nights booked. Spotify: time spent listening. Slack: daily active users sending messages. Properties of a good north star: reflects user value (not just revenue), correlates with long-term retention, actionable by the product team. Guardrail metrics: metrics that must not be degraded while improving the north star. If they cross a threshold: stop the experiment or deprioritise the initiative. Examples: support volume (north star improving → users confused?), page load time (feature addition slowing the product?), NPS (users frustrated by a change?), churn rate. Metric vocabulary: Leading indicator: predicts future outcomes. Early signal. Example: 7-day engagement predicts 30-day retention. Lagging indicator: reflects past outcomes. Example: annual revenue. Activation metric: the moment a user first experiences the product's core value. Example: Dropbox: user places at least one file in a folder. Retention metric: % of users returning after N days. AARRR (Pirate Metrics): Acquisition → Activation → Retention → Revenue → Referral. L7/L28: percentage of users active in the last 7 or 28 days. In conversation: 'Without guardrail metrics, teams can game the north star. We once boosted DAU 40% by sending daily push notifications — and NPS dropped 8 points. Guardrails would have caught it in week one.'
5 / 14
A senior PM explains theme-based roadmaps to stakeholders: "We use a theme-based roadmap instead of a feature roadmap. A theme is a strategic bet — 'Reduce time-to-first-value for enterprise customers.' We don't commit to specific features 6 months out because we don't yet know what will solve the problem best. The roadmap shows themes with timeframes: Now (this quarter, committed), Next (next quarter, planned but not committed), Later (later this year, direction only). Each theme links to the business outcome we're trying to move." What is the key difference between a theme-based roadmap and a feature roadmap?
Feature roadmap: 'In Q3 we will build feature X.' Problems: commits to a solution before validating it, creates stakeholder expectations that become hard to change, encourages building features you don't end up needing, leads to 'roadmap debt' — features promised but never built. Theme-based roadmap: 'In Q3 we will focus on theme Y (reducing time-to-first-value).' Benefits: preserves optionality, focuses team on outcome not output, easier to update as you learn, aligns stakeholders on what problem matters without committing to how. Roadmap vocabulary: Now / Next / Later: three-bucket roadmap without specific dates. Reduces over-commitment. Committed vs. aspirational: committed items are resourced and planned; aspirational are directional. Horizon 1 / 2 / 3: short/medium/long-term bets from McKinsey framework. Initiative: a large group of related work (larger than an epic, smaller than a strategy). Milestone: a significant checkpoint, often with external visibility (beta launch, general availability). Discovery: the work to determine what to build. Delivery: the work of building it. Dual-track agile: running discovery and delivery in parallel. In conversation: 'When a stakeholder says 'is Feature X on the roadmap?' the answer with a theme roadmap is: 'We're committed to Theme Y — whether Feature X is the right solution for it is what we're discovering in Q2.' That keeps optionality without ambiguity about the strategic direction.'
6 / 14
Reviewer: "This commit adds a new logging statement. It's great to see you tracking down the root cause, but it's overly verbose and doesn't provide much actionable information. Can we refactor this to be more concise and focus on key error codes?" What does the reviewer likely mean by 'actionable information' in this context?
The reviewer is suggesting the logging statement should offer relevant data – specifically, information that can actually *help* developers fix problems. 'Actionable information' implies details that are useful for debugging and troubleshooting, not just a general record of events.
7 / 14
"Sarah: 'Just pinged the team to see if anyone can help with the API integration. We need to get this up and running ASAP!' What does 'pinging the team' likely mean in this Slack message?
'Pinging' in Slack typically refers to sending a direct message or posting a quick update to a channel that notifies multiple people. It's a fast and informal way to get attention and request assistance, rather than a structured request.
8 / 14
API Response: {
"status": "200",
"data": {
"user": {
"id": "12345",
"name": "John Doe",
"email": "john.doe@example.com"
}
}
} The 'status' field indicates success. What does the 'data' field represent in this API response?
The 'data' field in an API response typically contains the actual information requested by the client. In this case, it's structured data representing a single user object, containing details like ID, name, and email.
9 / 14
"David: 'Yesterday, I spent two hours working on the onboarding flow. It's still not intuitive for new users, and I need to redesign the wizard.' What does David likely *not* want to hear in this stand-up update?
Stand-up updates are meant to be brief and focused on progress and roadblocks. Asking for a detailed effort estimate at this stage would derail the stand-up's purpose – which is to quickly identify potential issues and coordinate solutions; David's needs to raise that he has a roadblock.
10 / 14
Reviewer: 'This PR introduces a dependency on the `analytics-sdk`. While it's good to gather data, we haven't yet defined key performance indicators (KPIs) for this tracking. Let's hold off until we have clear goals. What is the reviewer primarily suggesting?
The reviewer isn't criticizing the technical implementation itself. They're pointing out a lack of alignment between the new feature (tracking data) and overall product goals – specifically, the absence of defined KPIs. This highlights the importance of connecting technical work to strategic objectives in product management.
11 / 14
"Maria: 'The team is blocking on a decision from Legal regarding GDPR compliance for the new user profile field. It's impacting our ability to launch the beta.' What does Maria likely mean by 'blocking'?
'Blocking' in this context signifies that Legal's decision (or lack thereof) is directly preventing progress. It indicates a dependency where one team's actions are contingent on another's – a common situation in complex product development environments and the core meaning of 'blocking' within project management.
12 / 14
"Product Manager: 'Let's prioritize the 'Dark Mode' feature based on a RICE score. Reach: 500 users/quarter; Impact: 0.75; Confidence: 80%; Effort: 2 days. What does the 'Confidence' value in the RICE scoring represent?
In RICE scoring, 'Confidence' reflects the product manager's assessment of how reliable their estimates are. It's a subjective measure of certainty regarding the assigned impact score – higher confidence means the manager trusts their judgment more and therefore assigns a potentially larger value to the feature.
13 / 14
"Sarah (Product Manager): 'We're shifting our focus this sprint to 'Improve User Onboarding'. This aligns with our north star metric – weekly active users who complete one search and one save action. It's a critical step towards driving long-term engagement.' What does Sarah primarily emphasize about the 'Improve User Onboarding' initiative?
Sarah clearly connects 'Improve User Onboarding' to the north star metric – weekly active users with specific behaviors. This demonstrates how product management decisions are driven by strategic metrics and highlights the importance of aligning features with core user value.
14 / 14
"David (Senior Product Manager): 'I'm going to spend the next week exploring potential integrations with Salesforce. We need to understand how this can help our enterprise customers achieve their business goals.' What is David primarily focused on?
David's statement reveals a focus on understanding how Salesforce integration can provide *value* to enterprise customers. This aligns with JTBD principles – identifying the 'jobs' (business goals) that users are trying to accomplish and then exploring solutions (like Salesforce integration) that help them do so effectively.
What does the "Product Management Vocabulary" vocabulary exercise cover?
This exercise tests real IT vocabulary related to product management vocabulary through 14 multiple-choice questions, each built from realistic workplace sentences rather than abstract definitions.
Is this vocabulary exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is completely free — no account, sign-up, or payment required.
How many questions does this exercise have?
This exercise has 14 questions. Each one shows a real-world sentence or scenario with multiple-choice options and an explanation once you answer.
What happens after I answer a question?
You'll see immediate feedback showing whether your answer was correct, along with a short explanation of why — then a button to move to the next question, and a full results screen at the end.
Can I retry the exercise if I get questions wrong?
Yes. Once you reach the results screen, click "Try again" to reset your answers and go through the exercise from the start as many times as you like.
Do I need to create an account to take this exercise?
No account is needed. Your answers are scored in your browser during the session — nothing is saved to a server, so you can jump straight in.
Is my progress saved if I leave the page?
No — progress within an exercise resets if you navigate away or reload. Each exercise is short enough to complete in a few minutes in one sitting.
Are these vocabulary exercises connected to other topics?
Yes — browse the full vocabulary exercises hub to find related modules covering adjacent IT topics and roles.
How is this different from reading a glossary or blog article?
Exercises like this one are active recall drills — you have to choose the correct term or phrasing yourself, which builds retention faster than passively reading a definition.
Where can I find more vocabulary exercises?
Browse the full Vocabulary exercises hub for hundreds of modules covering Agile, DevOps, security, databases, architecture, and more — organised by IT role and skill.