Product and Problem Statement are the two anchors at the top of any PRD. The Product declares the strategic container — vision, scope, non-goals — that everything else belongs to. The Problem Statement names the pain the product exists to relieve, framed as a situation, a complication, and a question. Supporting Evidence grounds both of them in fact rather than opinion. Together they answer “why does this product exist, and on what basis do we believe it should?” before any feature is proposed.

Product

A Product is the top-level container of a PRD. It groups everything the document describes — the problem, the users, the goals, the features, and the plan — under a single strategic umbrella. A product carries three defining attributes:

  • vision — a one-to-three sentence statement of the product’s purpose and differentiation: what it does, for whom, and why it matters more than alternatives.
  • scope — what the product covers and, equally important, what it does not. Scope is a working boundary that changes over time.
  • non-goals — permanent strategic exclusions that prevent scope creep (see the Non-Goals section below).

Every other element in the PRD — personas, jobs, features, releases — belongs to exactly one product. The product also anchors strategic relations: it addresses a problem statement, serves personas, pursues goals, offers features, plans releases, assumes assumptions, faces risks, is bounded by constraints, and raises open questions.

Example:

product "RideNow" {
  vision "A ride-hailing platform that connects riders with drivers in real time,
         offering reliable, affordable transportation in urban markets."
  ...
}

The vision is compact and differentiating. It tells a reader what RideNow is, who it is for, and why it would be chosen over taxis, public transit, or a personal car. Everything downstream in the PRD must be justifiable in terms of this vision; anything that cannot be traced back to it is out of scope.

Problem Statement (SCQ)

A Problem Statement is the pain the product exists to relieve, stated without prescribing a solution. A well-formed problem statement is the why behind every feature. When a feature cannot be traced back to the problem statement, either the feature is out of scope or the problem statement is incomplete.

The PRD metamodel uses the SCQ framework (Situation-Complication-Question) popularised by Barbara Minto’s Pyramid Principle:

  • situation — what is happening today: the context and the actors involved.
  • complication — why that situation is painful, costly, or unsustainable.
  • question — the key question the product answers, framed from the user’s perspective rather than the builder’s.

SCQ is not decorative. Teams that skip straight to features repeatedly discover, weeks later, that they cannot explain why the feature exists in terms their users would recognize. Writing the situation and complication separately forces the team to distinguish “the world as it is” from “why that world is a problem” — a distinction that silently dissolves when both are collapsed into a single paragraph.

Example:

problem {
  situation "Urban commuters and occasional travelers need on-demand transportation."
  complication "Public transit is unreliable, taxis are expensive and hard to find,
                personal cars are costly to own and park."
  question "How can we provide reliable, affordable door-to-door transportation
            available within minutes?"
}

The question is not “how do we build a ride-hailing app?” — that is a solution. It is “how do we provide reliable, affordable door-to-door transportation available within minutes?” — a user-framed question that leaves the solution space open. A ride-hailing marketplace is one answer. A dynamic shuttle network would be another. The problem statement does not choose.

Supporting Evidence

Supporting Evidence is data, research, or analysis that grounds the problem statement and other product decisions in fact rather than opinion. Evidence transforms “we believe riders are frustrated” into “rider NPS dropped 15 points in Q3; exit surveys cite unpredictable wait times as the #1 reason.”

Each piece of evidence carries:

  • type — user-research (interviews, surveys, usability tests), analytics (product metrics, usage data), market-research (competitive analysis, market sizing), customer-feedback (support tickets, reviews, NPS verbatims), or domain-expertise (expert judgment, regulatory guidance).
  • summary — one to three sentences describing what the evidence shows.
  • source reference — a verifiable pointer: report slide, dashboard, expert name.
  • date — when the evidence was collected. Evidence ages; stale data should be flagged.
  • confidence — strong (large sample, rigorous method), moderate (reasonable sample, some bias), or weak (anecdotal, small sample, outdated).

Evidence is not proof. It is the best available information at the time of the product decision. The explicit confidence level is what keeps the team honest: a decision built on weak evidence should carry a matching assumption with a validation plan, and higher risk tolerance downstream.

Example:

evidence "Rider NPS drop Q3" {
  type analytics
  summary "Rider NPS dropped 15 points in Q3. Exit surveys cite unpredictable
           wait times (42%) and surge pricing surprises (31%) as top reasons."
  source-reference "Rider Experience Quarterly Report Q3-2025, slide 14"
  date 2025-10-15
  confidence strong
  supports "Reduce rider wait time"
}

This single block justifies the product’s focus on wait time reduction. If another team later proposes deprioritising it, the evidence block is where the debate should start. Evidence nodes also support specific goals or features — a downstream feature without any supporting evidence is building on belief, which is legitimate only if the team makes that belief explicit as an assumption.

Non-Goals

Non-goals are explicit declarations of what the product deliberately does not aim to do — by design, not by deferral. A non-goal answers the question “someone will propose this — here is why we say no.”

Non-goals differ from two related concepts:

  • Non-goals vs. wont features: a wont feature is deferred. A non-goal is excluded as a matter of strategy and is not expected to ever be reconsidered.
  • Non-goals vs. scope exclusions: scope is the working boundary of the product. Non-goals are permanent strategic boundaries that prevent scope creep even when the scope itself grows.

Non-goals appear at two levels. Product-level non-goals are strategic: they define what the business is deliberately not doing. Feature-level non-goals are tactical: they define what a specific feature deliberately does not do within its own scope (see Features).

Example:

non-goals {
  "Replace public transit — we complement it, not compete with it"
  "Own the vehicle fleet — we are a marketplace, not a fleet operator"
  "Serve rural areas — unit economics require urban density"
}

Each item carries a rationale after the em-dash. That rationale is the load-bearing part. Without it, a non-goal degrades into an opinion that the next product manager will quietly overturn. With it, the team has a written record of the trade-off and the reason it was accepted.

Product-level non-goals flow downstream into feature decisions: a feature that would require RideNow to own a fleet is not “deprioritised” — it is rejected on non-goal grounds. This keeps feature backlogs from slowly drifting into strategies the leadership team has already ruled out.

Non-goals also protect engineering. A system requirement that would only make sense in a fleet-ownership world has no business appearing in the backlog; when reviewers spot it, they can point at the non-goal and close the ticket without a meeting.