5 exercises — Practice RICE scoring narration, MoSCoW classification criteria, professional declining language, confidence score vocabulary, and dependency framing.
0 / 10 completed
1 / 10
A PM has collected RICE data for a feature: Reach = 2,000 users/quarter, Impact = 3 (high), Confidence = 80%, Effort = 4 person-weeks. What is the RICE score and how do you present it in a planning meeting?
RICE is a multiplicative formula that normalises expected impact against the cost of building: (Reach × Impact × Confidence%) ÷ Effort. Confidence is entered as a decimal (0.8 not 80) to produce a meaningful score.
The power of RICE is in its vocabulary: when you present a RICE score you are not just giving a number — you are narrating your evidence (Reach), your user value judgement (Impact), your epistemic humility (Confidence), and your engineering cost (Effort) in a single transparent structure. A 40% Confidence score tells stakeholders "our discovery is incomplete" rather than hiding uncertainty behind a confident number. In planning meetings, use RICE scores as conversation starters, not conversation enders — a lower-scored item with strategic alignment may still beat a higher-scored one.
Key vocabulary:
• RICE — Reach × Impact × Confidence (as decimal) ÷ Effort; produces a score for prioritisation stack-ranking
• Confidence — how validated your Reach and Impact estimates are; reflects the quality of your discovery evidence
• Effort — total person-weeks (or points) required; normalises scores so quick wins don't get buried under large projects
2 / 10
A stakeholder insists that a dark mode feature is a "Must Have" for the MVP. Which response correctly applies MoSCoW prioritisation thinking?
The MoSCoW test for "Must Have" is strict: the release must fail without it — not just be less polished, but genuinely non-viable. This is the only definition that prevents "Must Have" from becoming a catch-all for everything someone prefers.
Common MoSCoW language:
• Must Have — the MVP does not work or fails compliance without it. Think: authentication, core data persistence, legal requirements.
• Should Have — important and expected; painful to omit but the product still ships. Think: email notifications, search, dark mode with strong accessibility data.
• Could Have — desirable but easily deferred; a "nice to have" that won't damage perception much if absent.
• Won't Have — explicitly out of scope for this release; documented to prevent scope creep.
When a stakeholder inflates a Could Have to a Must Have, the PM's job is to test that classification with the failure question, not to accept the label at face value.
Key vocabulary:
• Must Have — the release fails without it; the strictest MoSCoW category
• scope creep — gradual expansion of scope beyond agreed boundaries, often caused by unchallenged Must Have claims
• Won't Have — explicitly out of scope; documenting this in the PRD prevents repeated requests for the same item
3 / 10
A sales team requests a one-off custom CSV export format for a single enterprise prospect. How do you decline this request professionally while preserving the relationship?
Saying no professionally means: acknowledging the business context, applying product judgment transparently, leaving the door open with conditions, and offering an alternative path forward in the current situation.
Option A is dismissive and damages trust. Option B defers without any signal about likelihood (false hope). Option D uses engineering effort as a shield rather than product strategy as the reason. Option C (correct) names the specific reason for declining (doesn't pass the multi-customer threshold), offers a pathway to reconsideration (aggregate signal from multiple enterprise customers), and redirects to a practical question (does the existing export cover the use case?). This preserves the relationship, is honest about prioritisation, and keeps the conversation actionable.
Key vocabulary:
• one-off feature — a capability requested by a single customer; generally deprioritised unless it signals a broader pattern
• platform capability — a feature serving multiple customer segments or use cases; higher generalisation = higher justification
• prioritisation reasoning — explaining why a feature doesn't rank, not just that it doesn't; builds stakeholder trust in the product process
4 / 10
In a RICE exercise, a PM assigns a 40% Confidence score to a feature. A stakeholder challenges this, saying "If we're less than 50% confident, we shouldn't build it at all." How do you professionally respond?
Confidence in RICE is an epistemic honesty lever — it penalises features with under-validated assumptions so that they don't crowd out well-evidenced work on the priority stack.
A 40% confidence score does not say "this feature will fail." It says "we have low-quality evidence for our estimates, so we should not commit full effort yet." The correct response is a discovery spike: a time-boxed research or prototyping activity designed to raise the confidence score. If the spike confirms the hypothesis, Confidence rises to 70–80% and the feature competes more strongly. If the spike challenges the hypothesis, the team saves the effort of building the wrong thing. This language — "let's raise our confidence through a spike" — is far more productive than arguing about whether to include the feature at all.
Key vocabulary:
• Confidence score — reflects the quality of evidence behind Reach and Impact estimates; discounts under-validated features
• discovery spike — a time-boxed research or prototyping activity to validate assumptions and raise confidence before full investment
• epistemic humility — honestly representing what you know vs. what you assume in product decisions and scoring
5 / 10
During sprint planning, the PM says: "Feature B is blocked by Feature A, and Feature A is a prerequisite for Feature D." A new developer asks whether these phrases mean the same thing. Which explanation is correct?
Same relationship, different rhetorical emphasis — "blocked by" is empathetic to the blocked item's urgency; "prerequisite for" is empathetic to the enabling item's strategic value. Choose based on what you're amplifying for your audience.
In engineering planning: "Feature B is blocked by Feature A" is precise and actionable — it tells the team B is on hold, and unblocking B requires completing or partially completing A. In roadmap communication to non-technical stakeholders: "Feature A is a prerequisite for Feature D" is more natural and forward-looking — it explains why A must be in scope even if D is the headline feature. Being fluent in both directions of the same dependency is a sign of communication sophistication that shows you understand both technical constraints and strategic narrative.
Key vocabulary:
• blocked by — the dependent item cannot proceed until the blocking item is resolved; emphasises impediment
• prerequisite for — the enabling item must be completed before the dependent item can begin; emphasises sequencing logic
• dependency — the general term; "blocked by" and "prerequisite for" are directional framings of the same relationship
6 / 10
Sarah (Product Manager): 'Okay team, let's prioritize these new UI components. We've run a quick RICE score – Reach = 1500 users, Impact = 4 (high), Confidence = 70%, and Effort = 2 weeks. What's the overall priority?'
RICE scoring calculates a weighted average. Reach * Impact * Confidence / Effort gives the score. A higher score indicates greater potential value relative to the effort involved. Option A is incorrect because RICE provides a single prioritized ranking; options C and D misinterpret the meaning of the score itself.
7 / 10
Mark (Senior Developer) leaves this comment on a code review: 'This data validation is overly complex. We should prioritize returning a simple boolean indicating success or failure.' How does this best align with the concept of 'Technical Debt'?
Technical Debt represents the implied cost of rework caused by choosing an easy solution now instead of a better approach that would take longer. Mark's comment prioritizes immediate usability over future maintainability, directly contributing to this debt. Option A is incorrect as it describes proactive scalability; option C misunderstands edge case handling and option D is about performance optimization, not prioritization.
8 / 10
Liam (Product Owner) sends this Slack message to the development team: 'Hey guys, I need a custom API endpoint that returns all user profiles in CSV format. It's crucial for our sales team's reporting.' What is the most appropriate initial response?
Before committing to a bespoke request, it's crucial to clarify requirements and assess impact. This response initiates the necessary conversation about scope, volume, and potential technical challenges – preventing scope creep and ensuring alignment with overall product strategy. Option A is premature; option C delays critical discussion; option D is unnecessarily dismissive.
9 / 10
David (Product Manager): 'Okay team, Feature X is dependent on Feature Y being completed first. Then Feature Z needs to be built upon both.' A junior developer asks: 'So, does that mean we have to finish Y and Z before we can even start working on X?' What's the most accurate explanation?
Dependencies represent relationships between tasks. Feature X's progress is *contingent* upon Y and Z being done, meaning it cannot begin until they are complete. However, parallel work might still be possible – the junior developer's interpretation is too rigid. Option A is an oversimplification; option C ignores a key aspect of project management; option D misinterprets the nature of dependencies.
10 / 10
Emily (Product Manager) writes this PR description for a new feature: 'Implemented user authentication using OAuth 2.0. This allows users to sign in with their Google accounts.' What does this primarily reflect about the prioritization of this feature?
The description highlights security (OAuth 2.0) and user convenience (Google sign-in). These are often prioritized based on risk mitigation – enhancing security reduces potential vulnerabilities – and improving the user experience increases adoption. Options A, C, and D focus on technical aspects or standard practices without explicitly acknowledging the prioritization rationale.
What will I practice in "Feature Prioritization Language — 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.