[ GLOSSARY ]

Product management.
Defined.

Clear, precise definitions for every PM term — with examples, comparisons, and how to apply each concept in real product work.

How-To GuidesDocuments & SpecsRequirementsPrioritizationStrategy & Frameworks

Documents & Specs

PRD→

What Is a PRD? (Complete Definition + Examples)

A PRD (Product Requirements Document) is a specification written by a product manager that describes what a feature or product should do, who it is for, how success will be measured, and what constraints the engineering team must work within. PRDs are written before development begins to align engineering, design, and stakeholders on what is being built and why.

PRD vs BRD→

PRD vs BRD: What's the Difference? (With Examples)

A PRD (Product Requirements Document) describes what a feature should do from a product and user perspective — written by a product manager for engineering teams. A BRD (Business Requirements Document) describes what a project should achieve from a business process perspective — written by business analysts for stakeholders and executives. PRDs focus on user needs and acceptance criteria; BRDs focus on business rules and system integrations.

Product Spec→

What Is a Product Spec? (Definition, Types & Examples)

A product spec (product specification) is a document that defines what a feature or product should do, how it should behave, and what constraints it must work within. Product specs range from lightweight one-page briefs to full Product Requirements Documents (PRDs) with engineering tickets and architecture blueprints. They are written by product managers before development begins.

PRD Template→

PRD Template: All 10 Sections Explained (With Examples)

A complete PRD template has 10 sections: (1) Problem statement — who has the problem and why. (2) Target users — primary and secondary users. (3) Goals and success metrics — measurable outcomes with targets. (4) User stories — 'As a / I want / So that' format. (5) Feature scope — in scope and out of scope. (6) Technical constraints. (7) Architecture considerations. (8) Engineering tickets with story points. (9) Edge cases — at least 2 per user story. (10) Acceptance criteria — 3–5 Gherkin conditions per ticket.

Prioritization

RICE Scoring→

RICE Scoring: What It Is, Formula & Examples (2026)

RICE scoring is a feature prioritization framework developed by Intercom. RICE stands for Reach (how many users are affected), Impact (how much it moves the primary metric per user), Confidence (how certain you are of the estimates, as a percentage), and Effort (person-weeks to build). RICE Score = (Reach × Impact × Confidence) / Effort. Higher scores should be prioritized first.

MoSCoW Method→

The MoSCoW Method: Definition, Examples & How to Use It

The MoSCoW method is a prioritization and scope management framework that categorizes requirements into four groups: Must have (non-negotiable launch requirements), Should have (important but not launch-blocking), Could have (nice-to-have if time permits), and Won't have this time (explicitly deferred for this release). It is used to define release scope and prevent scope creep during development.

Prioritization Frameworks→

Feature Prioritization Frameworks: RICE, ICE, MoSCoW, Kano & More

The most used feature prioritization frameworks are: (1) RICE — (Reach × Impact × Confidence) / Effort. Best for data-driven backlog ranking. (2) ICE — Impact × Confidence × Ease. Best for early-stage or fast-moving teams. (3) MoSCoW — Must/Should/Could/Won't. Best for release scope decisions. (4) Kano model — categorizes features as Basic, Performance, or Excitement. Best for strategic differentiation. (5) WSJF — Weighted Shortest Job First. Best for enterprise SAFe teams. (6) Value vs Effort matrix — simple 2×2 for quick triage.

Strategy & Frameworks

Jobs to Be Done→

Jobs to Be Done (JTBD): Complete Framework Guide (2026)

Jobs to Be Done (JTBD) is a theory of consumer action that states customers don't buy products — they 'hire' them to accomplish a specific 'job' or desired outcome. Developed by Clayton Christensen and Tony Ulwick, JTBD helps product teams understand customer needs as desired outcomes rather than feature requests, leading to innovations that compete with unexpected alternatives.

OKRs→

OKRs in Product Management: Definition, Examples & How to Use Them

OKRs (Objectives and Key Results) in product management are a goal-setting framework where Objectives are ambitious qualitative goals ('become the default PRD tool for product teams') and Key Results are 2–5 measurable outcomes that define what achieving the Objective looks like ('achieve 50% trial-to-paid conversion within 90 days'). OKRs connect product roadmap decisions to company strategy and make prioritization defensible.

Product Roadmap→

What Is a Product Roadmap? (Definition, Types & Examples)

A product roadmap is a strategic document that communicates what a product team plans to build, in what order, and why — connecting day-to-day development decisions to company strategy and customer needs. Roadmaps align engineering, design, marketing, sales, and leadership on product direction and serve as the communication bridge between product strategy and sprint-level execution.

Product Discovery→

Product Discovery Process: Steps, Methods & Examples (2026)

The product discovery process has 5 steps: (1) Frame the problem — identify who has the problem, how often, and what they currently do instead. (2) Research — user interviews, usage data analysis, and competitive review. (3) Synthesize — identify patterns, rank pain points by frequency and severity, and form hypotheses. (4) Validate — test hypotheses with prototypes, fake-door tests, or data analysis. (5) Define — write the problem statement, success metrics, and first-draft user stories that form the basis of the PRD.

Put these concepts to work

Scriptonia uses every framework in this glossary — RICE, MoSCoW, Jobs to Be Done, OKRs — to generate complete PRDs in under 30 seconds.

Try Scriptonia free →
Product Management Glossary — Scriptonia | Scriptonia