The Specy PRD metamodel defines the vocabulary you use to describe why a product exists and what it should deliver — the layer upstream of system requirements and the domain model. It is organized in six layers: a Product & Problem layer that roots the document and states the pain it answers, a Demand layer that models who the users are and what they are trying to accomplish, an Intent layer that makes the business bet measurable, a Solution layer that describes what actually ships, an Uncertainty & Boundaries layer that names what the team does not know and cannot choose, and a Roadmap & Traceability layer that sequences delivery and links product decisions forward into .sysreq requirements.

Each layer below gives a one-sentence definition of every concept and a link to its detailed page. The PRD is the top of the provenance chain — Product → System Requirement → Domain → Code — so every concept here is eventually answerable by a testable EARS statement downstream.

The full, authoritative specification is PRODUCT-REQ-METAMODEL.md in the specy-ai/skills repository.

Product & Problem

This layer roots the document and grounds it in a real pain: the strategic container, the problem it exists to solve, the evidence that the problem is real, and the boundaries that keep it from sprawling.

Product — the top-level container that groups everything the PRD describes: its vision, its scope, and every persona, goal, feature, and release beneath it. See Product & Problem.

Problem Statement (SCQ) — the pain the product exists to solve, framed as Situation → Complication → Question without prescribing a solution; the why behind every feature. See Product & Problem.

Supporting Evidence — data, research, or analysis that grounds the problem and product decisions in fact rather than opinion, each item carrying a type, source, date, and confidence level. See Product & Problem.

Non-Goals — explicit declarations of what the product deliberately does not aim to do, by design rather than deferral — permanent strategic boundaries that prevent scope creep. See Product & Problem.

Demand

This layer models the demand side — the people the product serves and what they are trying to get done — independently of any solution.

Persona — a research-grounded behavioral archetype of a target user: their goals, frustrations, context, and weight (primary, secondary, or excluded). See Personas & Jobs.

Job — a situation-triggered task a persona is trying to accomplish, stated solution-independently in the form When [situation], I want to [motivation], so I can [outcome]; stable across product and technology pivots. See Personas & Jobs.

Desired Outcome — a measurable criterion from the persona’s perspective for how well a job is getting done; the customer’s yardstick, distinct from business success metrics. High importance plus low satisfaction marks an underserved outcome. See Personas & Jobs.

Intent

This layer makes the business bet explicit: the outcomes the product pursues, the numbers that decide whether it works, and the causal claims that connect features to those numbers.

Goal — a measurable business objective the product pursues, stated as an outcome rather than a feature, with a horizon and an accountable owner. See Goals & Hypotheses.

Success Metric — a quantitative decision criterion that determines whether a goal is met, with an indicator, a target, a baseline, and a measurement method. See Goals & Hypotheses.

Hypothesis — a testable causal claim linking a feature to a goal — if intervention, then outcome, because mechanism — with a validation method and a status (proposed … validated/invalidated). See Goals & Hypotheses.

Solution

This layer describes what the product actually offers: the capabilities, the persona-specific narratives that justify them, and the end-to-end flows that span them.

Feature — the primary unit of product planning: a named capability described in user terms, prioritized with MoSCoW, carrying a status, value proposition, feature-level non-goals, and design references. See Features, Stories & Journeys.

User Story — a persona-specific narrative of one way a feature delivers value, in the form As a [persona], I want [action], so that [outcome], whose acceptance criteria are the primary candidates for EARS formalization. See Features, Stories & Journeys.

User Journey — a sequence of steps a persona takes to accomplish a goal across one or more features, broader than a story and including moments the product does not control. See Features, Stories & Journeys.

Journey Step — a single interaction within a journey, capturing the persona’s action, the system response, the channel, an optional emotional tone, and its order. See Features, Stories & Journeys.

Uncertainty & Boundaries

This layer makes the unknown and the non-negotiable explicit — the four distinct ways a PRD acknowledges what it does not know, what could go wrong, and what it cannot choose.

Assumption — something believed true but not yet validated, carrying its impact-if-wrong, a validation plan, and a status; the hidden load-bearing walls of product decisions. See Risks, Assumptions & Constraints.

Risk — something that could go wrong and damage the product, users, or business, scored by likelihood and impact with a mitigation strategy and an owner. See Risks, Assumptions & Constraints.

Constraint — a non-negotiable boundary that limits product decisions — a fact, not a choice — sourced from regulation, contract, technology, or organization, and often generating system requirements directly. See Risks, Assumptions & Constraints.

Open Question — an acknowledged unknown the team must resolve before a decision can be made, naming the gap rather than hiding it, with an owner, a deadline, and a status. See Risks, Assumptions & Constraints.

Roadmap & Traceability

This layer sequences delivery and connects product decisions forward into the rest of the Specy chain.

Release — a planned delivery milestone that groups features into a shippable unit, with a theme, a target date, entry and exit criteria, and dependencies on other releases. See Releases & Traceability.

Traceability to System Requirements — the forward bridge from PRD to .sysreq: each EARS requirement’s source field references the feature, story, acceptance criterion, constraint, or goal it came from, enabling feature-to-requirement coverage and change-impact analysis along the full Product → Requirement → Domain → Code chain. See Releases & Traceability.