Feature Prioritization Language

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

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

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

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

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