Product Management Language
7 exercises covering the English vocabulary product managers use to write PRDs, run discovery, communicate roadmaps, and align stakeholders — with scenario-based exercises from real PM conversations.
PRD Writing Language
Practice writing problem statements, hypotheses, acceptance criteria, and scope boundaries.
Product Discovery Vocabulary
Master JTBD, assumption mapping, opportunity trees, and discovery anti-patterns.
Product Vision Language
Articulate vision statements, north star metrics, strategy framing, and roadmap tiers.
User Story Mapping Language
Use story map anatomy, vertical slicing, release sequencing, and story format vocabulary.
Product Metrics Communication
Classify metrics, narrate movements, and communicate A/B test results professionally.
Feature Prioritization Language
Apply RICE, MoSCoW, confidence scoring, and dependency vocabulary to prioritization.
Roadmap Storytelling
Frame roadmaps for executives, handle pushback, and narrate roadmap retrospectives.
Frequently Asked Questions
What is a PRD and what vocabulary does it use?
A PRD (Product Requirements Document) defines the problem a feature solves, the success criteria, scope boundaries, and non-functional requirements. Key vocabulary includes "problem statement," "hypothesis," "acceptance criteria," "out of scope," "assumptions," and "dependencies." A well-written PRD separates what to build from how to build it, leaving implementation decisions to the engineering team.
What does the MoSCoW prioritization framework mean and how is it used in English?
MoSCoW stands for Must Have, Should Have, Could Have, and Won't Have. Product managers use it to communicate scope decisions clearly to stakeholders: "The offline mode is a Must Have for launch; real-time collaboration is a Should Have that we'll target in the next sprint; the analytics dashboard is a Could Have if capacity allows." The framework forces explicit trade-offs rather than treating everything as equally urgent.
What is the RICE scoring model and how do product managers explain it?
RICE stands for Reach, Impact, Confidence, and Effort. Product managers calculate a RICE score to compare features objectively: Reach (how many users per period) multiplied by Impact (effect on a goal) multiplied by Confidence (how certain you are of estimates), divided by Effort (person-months). A typical explanation: "The onboarding redesign scored 480 on RICE — higher than the dashboard refresh at 210 — so it takes priority in Q3."
What does "north star metric" mean in product management English?
The north star metric is the single metric that best captures the core value a product delivers to its users and correlates with long-term business health. It guides prioritization decisions across the team. Engineers and PMs describe it by saying "we optimize for weekly active editors, not page views, because editing is the moment users experience our product's core value."
What vocabulary is used when describing a product roadmap to executives?
Executive roadmap language includes "now / next / later" horizon framing, "strategic bets," "key results," "release themes," and "confidence levels." PMs avoid committing to specific dates in favor of "by end of Q3" or "H2 2025." When handling pushback, phrases like "this is a capacity trade-off — accelerating feature X means delaying feature Y" help anchor the conversation in constraints rather than willingness.
What does Jobs-to-be-Done (JTBD) mean and how is it explained in English?
Jobs-to-be-Done is a framework that frames product decisions around the progress a user is trying to make in their life — "the job" — rather than demographic attributes or feature requests. A JTBD statement follows the format: "When [situation], I want to [motivation], so I can [expected outcome]." PMs use this vocabulary to argue against building features that don't serve a clear job: "We don't have evidence this maps to a real job customers are hiring us for."
What is user story mapping and what English vocabulary does it involve?
User story mapping is a technique that arranges user stories on a two-dimensional map: the horizontal axis shows the user journey in sequence (activities and tasks), while the vertical axis shows priority — with the top slice forming a minimum viable release. Key vocabulary includes "backbone," "walking skeleton," "vertical slice," and "release band." PMs say "we cut the map horizontally to define our MVP release" to explain scope decisions.
How do product managers communicate A/B test results in English?
A/B test communication uses vocabulary like "control variant," "treatment variant," "statistical significance," "p-value," "confidence interval," "lift," and "guardrail metric." A typical readout: "The treatment variant produced a 12% lift in activation rate with 95% statistical confidence, and no statistically significant degradation in our guardrail metric of customer support tickets." Distinguishing correlation from causation is a key part of this communication.
What is "discovery" in product management and what vocabulary does it use?
Product discovery is the process of validating that you are building the right thing before investing in development. Vocabulary includes "assumption mapping," "opportunity tree," "prototype test," "desirability vs. viability vs. feasibility," "continuous discovery," and "interview synthesis." PMs say "we ran five customer interviews and invalidated our core assumption about the pricing model before writing a single line of code."
What English phrases are commonly used to push back on feature requests professionally?
Professional pushback phrases include: "Can you help me understand the problem this solves?", "What outcome are we trying to move with this?", "This isn't in the current roadmap — can we discuss the trade-off if we add it?", and "We're not saying no — we're saying not now, based on current priorities." These phrases redirect the conversation from feature advocacy to outcomes, which is the hallmark of a strong product management communication style.