Assumptions, Risks, Constraints, and Open Questions are the four ways a PRD acknowledges what it does not know, what could go wrong, and what it cannot choose. An Assumption is a belief the team is willing to act on but has not validated. A Risk is a threat to the product, users, or business. A Constraint is a non-negotiable fact — regulatory, contractual, technical, or organizational — that bounds product choices. An Open Question is an explicit gap in understanding the team commits to resolve. Each of these carries a different kind of load, and collapsing them into one list (as many PRDs do) loses the distinctions that matter.

Assumption

An Assumption is something believed to be true but not yet validated. Assumptions are the hidden load-bearing walls of product decisions — if an assumption proves wrong, the features built on it may collapse.

An assumption carries four attributes:

  • statement — what is believed.
  • impact if wrong — what happens to the product if the belief is false. This is the part that decides whether the assumption deserves attention: a wrong belief with no downstream consequence is not really an assumption.
  • validation plan — how the belief will be tested. Measurement, pilot, research, domain expert interview.
  • status — unvalidated, validated, invalidated.

The most dangerous assumptions are the ones the team does not know it is making. Writing them down in the PRD forces them into the open, where other readers — engineers, designers, operations — can challenge them. An assumption that underpins a must feature deserves a funded validation plan; one that underpins a could feature can live as unvalidated longer.

Example:

assumption "GPS accuracy sufficient for matching" {
  statement "Driver smartphones in target markets have GPS accuracy within 20 meters"
  impact-if-wrong "Matching assigns wrong drivers, ETAs are unreliable, no-show rate rises"
  validation-plan "Measure GPS accuracy on 100 driver devices in first pilot market"
  status unvalidated
  underpins "Ride request and fare estimate"
}

The impact-if-wrong is concrete enough that the team can price it: a rise in no-show rate means lost rides, which means missed wait-time goals. The validation plan is cheap and specific. And the underpins link connects the assumption to a feature — so if the measurement comes back bad, the team knows exactly which feature must be rethought.

Risk

A Risk is something that could go wrong and damage the product, the users, or the business. Unlike assumptions (about beliefs), risks are about threats. An assumption is “we believe X”; a risk is “Y might happen.”

A risk carries five attributes:

  • statement — what could happen.
  • likelihood — low, medium, high.
  • impact — low, medium, high, critical.
  • mitigation — the strategy: accept (monitor and live with it), mitigate (reduce probability or impact), avoid (change approach so the risk no longer applies), or transfer (insurance, contractual indemnity).
  • owner — who is responsible for monitoring and responding.

Risks with high × critical scoring deserve escalation before the PRD is approved. Risks with low × low are documentation — there mostly to show the team looked. The value of the register is the middle: risks that are plausible and painful enough to matter, with a named owner and a chosen response strategy.

Example:

risk "Regulatory surge pricing ban" {
  statement "Local regulators may ban or cap surge pricing in key markets"
  likelihood medium
  impact high
  mitigation mitigate
  owner "Head of Legal"
  threatens "Reduce rider wait time"
}

Mitigation is mitigate — the team has chosen to reduce exposure (perhaps by preparing a non-surge pricing variant) rather than accept the risk or pivot away from surge entirely. The threatens link points directly at a goal: if the risk materialises, the “Reduce rider wait time” goal is the one at stake.

Constraint

A Constraint is a non-negotiable boundary that limits product decisions. Constraints are facts, not choices — they come from regulation, contracts, technology, or organizational reality. A constraint cannot be “prioritised away” or traded against features; either the product complies or it does not ship.

A constraint carries three attributes:

  • statement — the constraint itself.
  • source — where it comes from: regulatory (law, standard), contractual (agreement with a partner, investor, or customer), technical (hardware limits, platform rules), organizational (corporate policy, team capacity), or market (competitive or customer expectation).
  • impact — which features or goals are affected.

Constraints often generate system requirements directly. A regulatory constraint like “GDPR right to erasure within 30 days” becomes an EARS requirement scoped to the organization. The source field on the downstream system requirement references this constraint — the bridge is discussed in Releases & Traceability and in the domain-side companion, Requirement Traceability.

Example:

constraint "PCI-DSS compliance" {
  statement "All payment card data must comply with PCI-DSS Level 1"
  source regulatory
  constrains "Ride request and fare estimate",
             "Driver weekly payout",
             "Instant payout"
}

Three features are explicitly constrained. Any system requirement derived from these features must carry the PCI-DSS constraint forward — either in its own source field or through satisfaction links to domain elements that implement the compliance. The constraint is not optional guidance; it is a hard edge.

Open Question

An Open Question is an acknowledged unknown that the team needs to resolve before a decision can be made. Open questions differ from assumptions (beliefs to validate) and risks (threats to mitigate). An open question is an explicit gap in understanding — the team knows it does not know, and it names the gap rather than hiding it.

An open question carries six attributes:

  • question — the specific unknown, stated as a question.
  • context — why this question matters and what decision is blocked until it is answered.
  • owner — who is responsible for finding the answer.
  • deadline — when the answer is needed — typically tied to a release or feature decision point.
  • status — open (not yet answered), investigating (actively being researched), resolved (answer found), deferred (deliberately postponed with rationale).
  • resolution — when resolved, the answer and the evidence that supports it.

Open questions are living artifacts. They should be reviewed on a regular cadence and either closed or escalated. A PRD with many long-standing open questions is a signal that the team is building on uncertain ground — and the PRD is doing its job by making that visible.

Example:

open-question "Cancellation fee in competitive markets" {
  question "Should we charge cancellation fees in markets where competitors don't?"
  context "Charging fees protects drivers but may drive riders to competitors.
           Not charging fees exposes drivers to rider abuse."
  owner "Head of Product"
  deadline 2026-04-01
  status open
  blocks "Free cancellation before driver assignment"
}

The question is specific, the trade-off is named in the context, there is an owner, and there is a hard deadline. The blocks link states exactly which feature cannot be finalised until the answer lands. When it is resolved, the resolution field records the answer and the evidence — so six months later, a new team member can find out not just what was decided but why.

A resolved open question often turns into a constraint (a rule the product now honours) or an assumption (a belief the team is now willing to bet on).