Personas, Jobs, and Desired Outcomes are the demand-side of the PRD. The Persona is an archetype of a target user — a behavioural model, not a demographic. A Job is a situation-triggered task the persona is trying to accomplish, stated independently of any solution. Desired Outcomes are the persona’s own yardstick for whether the job was done well. Together, these three concepts describe what the product must respond to before it decides how.

Persona

A Persona is an archetype of a target user grounded in research or domain expertise. A persona is not a marketing profile. It is a behavioural model that tells the team what the user is trying to accomplish, what frustrates them today, and what context shapes their decisions.

A persona carries five attributes:

• role — a short label from the ubiquitous language: “Daily commuter rider”, “Part-time driver”, “Fleet operations manager”.
• goals — outcomes, not features. “Get to work reliably within 30 minutes,” not “Request a ride”.
• frustrations — what blocks or degrades the persona’s experience today.
• context — device, time pressure, technical literacy, frequency of use — the environment that shapes how the persona interacts.
• weight — how important this persona is to the product’s success: primary (the product is built for them), secondary (the product serves them but is not optimized for them), or excluded (explicitly not served — documented to prevent scope creep).

The excluded weight is unusual but valuable. Writing down “we do not serve rural-only drivers” prevents a year of debate about features that would only matter to riders the product has deliberately declined to court.

Example:

persona "Daily commuter rider" {
  role "A working professional who commutes to the office 5 days a week"
  goals {
    "Get to work reliably within 30 minutes"
    "Know the fare before committing"
    "Avoid cash transactions"
  }
  frustrations {
    "Unpredictable wait times"
    "Surge pricing during peak hours"
    "No recourse when driver cancels"
  }
  context "Uses smartphone, rides during morning and evening rush, price-sensitive"
  weight primary
}

A PRD typically carries 2–5 named personas. More than that is usually a sign that the team is describing segments rather than archetypes, or that it is modelling the whole market rather than the product’s actual target.

Job

A Job is a situation-triggered task a persona is trying to accomplish, stated independently of any solution. The distinction matters: people have been “trying to get financing quickly to seize a time-sensitive opportunity” for centuries. Only the solutions change. Jobs are stable — they survive product pivots and technology changes.

A job captures why a persona acts, rooted in a specific circumstance rather than in identity. The same rider has very different jobs when commuting at 8 AM, heading to the airport at 4 AM with luggage, or leaving a bar at midnight.

A job follows the canonical form:

When [situation], I want to [motivation], so I can [expected outcome].

A job carries four structured attributes:

• statement — the job in canonical form.
• type — functional (a practical task), emotional (how the persona wants to feel or avoid feeling), or social (how the persona wants to be perceived).
• importance — critical (the persona actively seeks a solution), important (the persona cares but tolerates imperfection), or nice-to-have (noticed but not acted upon).
• satisfaction — how well current solutions (competitors, workarounds, manual processes) serve this job: unserved (no solution exists), underserved (solutions exist but fall short), adequately-served, or overserved (current solutions exceed needs — opportunity to simplify or reduce cost).

The combination of high importance + low satisfaction identifies underserved jobs — the primary opportunities for the product to create value. Overserved jobs signal opportunities to simplify or offer a cheaper alternative.

Example:

job "Know total cost before committing to a ride" {
  persona "Daily commuter rider"
  statement "When I need a ride but have a limited budget,
             I want to know the exact fare before I commit,
             so I can decide whether to ride or take a cheaper alternative."
  type functional
  importance critical
  satisfaction underserved
}

The statement is anchored in a situation (“when I need a ride but have a limited budget”) and a motivation (“know the exact fare before I commit”), not in a product action. A Feature later addresses this job — but the job would still exist if the product were never built.

Jobs are optional in the PRD. A product team may choose to work with personas and goals alone. But when jobs are present, they provide a stable demand-side architecture that survives product pivots and technology changes.

Desired Outcome

A Desired Outcome is a measurable criterion — from the persona’s perspective — for how well a job is getting done. Unlike success metrics (which measure business objectives), desired outcomes measure customer satisfaction with job execution. They are the persona’s yardstick for whether a solution is worth hiring.

A desired outcome follows the canonical form:

[Direction] + [metric] + [object of control] + [contextual clarifier]

For example: “Minimize the time it takes to know whether my financing request will be approved”, or “Minimize the likelihood of being surprised by hidden fees after committing to a ride”.

A desired outcome carries:

• statement — the outcome in canonical form.
• importance — how much the persona cares: high, medium, low.
• current-satisfaction — how well current solutions deliver: low (big gap — opportunity), medium (adequate but improvable), or high (already well-served).

High importance + low current-satisfaction identifies an underserved outcome — the most promising target for product investment. This is the core of Outcome-Driven Innovation (Ulwick): prioritise features that address underserved outcomes on important jobs.

Example:

desired-outcomes {
  "Minimize the difference between estimated fare and actual fare" {
    importance high
    current-satisfaction low
  }
  "Minimize the likelihood of being surprised by surge pricing" {
    importance high
    current-satisfaction low
  }
}

Both outcomes measure the same job (“know total cost before committing”) from the rider’s perspective. They are the evaluation criteria a feature must move to be considered successful — and they become natural inputs to the success metrics the business tracks.

Job and Other PRD Concepts

Jobs complement — they do not replace — other PRD concepts. Each serves a different purpose:

Jobs sit between personas and goals: a persona has jobs; the product pursues goals that address those jobs; features address jobs by delivering capabilities. Jobs are demand-side (what the customer wants); goals are supply-side (what the business measures). A well-formed PRD connects both sides: every goal should trace to one or more jobs, and every job should be addressable by one or more features.