Goals, Success Metrics, and Hypotheses are the supply-side of the PRD. A Goal is a measurable business objective the product pursues. A Success Metric is the decision criterion that determines whether the goal is being met. A Hypothesis is the testable causal claim that links a feature to a goal — the bet made explicit. Without these three, a PRD reads like a feature list; with them, it reads like a plan that can be checked.

Goal

A Goal is a measurable business objective the product pursues. Goals are not features — they are outcomes. A feature is a means to a goal; the goal is the end. A PRD that lists features without goals reveals a team that cannot explain why any of them should be built first.

A goal carries three attributes:

  • statement — what the product aims to achieve, stated as a measurable outcome. “Reduce average rider wait time to under 4 minutes in served markets” is a goal. “Build a matching algorithm” is not.
  • horizon — the timeframe the goal covers: short-term (this quarter), mid-term (this year), or long-term (multi-year).
  • owner — the person or team accountable. A goal with no owner is aspirational; goals with named owners tend to get decisions.

A goal relates to the jobs it serves and to the features that advance it. The expectation is that every goal traces upward to one or more jobs (demand-side justification) and downward to one or more features (supply-side execution). Goals that trace to neither are usually strategic slogans in disguise.

Example:

goal "Reduce rider wait time" {
  statement "Reduce average time from ride request to driver assignment
             to under 30 seconds in served markets"
  horizon short-term
  owner "Head of Ride Operations"
}

The statement is measurable (“under 30 seconds”), scoped (“in served markets” — not all markets, not forever), and framed as an outcome, not an activity. “Under 30 seconds” is concrete enough that the team will know unambiguously whether the goal has been hit.

Success Metric

A Success Metric is a quantitative indicator that determines whether a goal is being met. A success metric is not a vanity number — it is a decision criterion. If the metric moves in the wrong direction, the team changes course. If a team would not change course when the metric drops, it is not a success metric; it is a progress report.

A success metric carries four attributes:

  • indicator — what is measured (e.g., “Average time from ride request to driver assignment”).
  • target — the threshold that defines success ("< 10 seconds at p95").
  • baseline — the current value before the product intervention, if known. Without a baseline, “improvement” is unmeasurable.
  • measurement method — how the metric is collected. Ideally this names a real production signal: “Computed from RideRequested → RideRequestMatched event timestamps in production.”

Tying the measurement method to concrete events (rather than a handwave about “dashboards”) is load-bearing. It forces the team to confirm the signal actually exists — and it creates a direct bridge to the domain model, where those events live.

Example:

goal "Reduce rider wait time" {
  ...
  metric {
    indicator "p50 time from RideRequested to RideRequestMatched"
    target "< 30 seconds"
    baseline "45 seconds (current)"
    measurement "Event timestamp delta in production"
  }
}

The metric declares the percentile (p50), the target (< 30s), the baseline (45s), and the measurement method (event timestamp delta). Any engineer reading this block knows exactly which events to instrument and where the number will come from. Any product manager reading it knows what “winning” looks like.

A goal can have multiple metrics — for example, a rider-experience goal may track both median wait time and the percentage of rides with wait time over a threshold. Two metrics avoid the trap of optimising the median while the tail gets worse.

Hypothesis

A Hypothesis is a testable causal claim about how a feature will advance a goal. A hypothesis makes the bet explicit: “if we do X (intervention), then Y (outcome) will happen, because Z (mechanism).” Without a hypothesis, the connection between a feature and a goal is an assertion. With one, it is a testable prediction — something that can be validated, invalidated, or left inconclusive.

A hypothesis carries five attributes:

  • intervention — what the product will do. Typically a feature or a change to an existing feature.
  • expected outcome — the measurable result, stated in terms of a success metric moving in the desired direction.
  • mechanism — the causal reasoning. Why should the intervention produce the outcome? The mechanism is the part most often skipped — and the part most often wrong.
  • validation method — how the hypothesis will be tested. A/B test, pilot market, user research, analytics comparison.
  • status — proposed (not yet tested), testing (experiment in progress), validated (evidence supports it), invalidated (evidence contradicts it), or inconclusive (not enough signal).

A hypothesis is not a requirement. It is a bet. Validated hypotheses justify features; invalidated ones should trigger feature reconsideration or pivot. A feature without a hypothesis is building on faith; a hypothesis without a feature is theory without action.

The single most common failure mode is proposing a hypothesis without a mechanism. “Feature X will improve metric Y” is an assertion, not a hypothesis. “Feature X will improve metric Y because users currently abandon at step Z, and X removes Z” is a hypothesis. When the mechanism is written down, the team can see whether the mechanism is plausible before the experiment runs.

Example:

hypothesis "Upfront fare reduces abandonment" {
  intervention "Show fare estimate before rider confirms the ride request"
  expected-outcome "Rider conversion from request to confirmation increases by 20%"
  mechanism "Eliminating fare uncertainty reduces abandonment at the commitment step"
  validation-method "A/B test in pilot market — control: no estimate, variant: upfront estimate"
  status proposed
  proposes "Ride request and fare estimate"
  predicts "Reduce rider wait time"
}

The intervention is specific (show a fare estimate before confirmation). The expected outcome is quantified (+20% on a named conversion metric). The mechanism is explicit (fare uncertainty causes abandonment at the commitment step). The validation method is chosen (A/B test in a pilot market). And the hypothesis is explicitly linked: it proposes a feature, and it predicts movement on a goal.

When the experiment ends, the status moves to validated, invalidated, or inconclusive. If invalidated, the feature it proposes is up for reconsideration — the team should not quietly ship something it just ran an experiment to disprove. That outcome is a feature of the PRD, not a bug: the whole point of writing hypotheses is that they can fail, and the team has a place to put the answer when they do.