Writing Job Statements That Survive Contact With Engineering

A job statement survives engineering when it carries three things past the backlog: the situation that triggers it, the motivation behind it, and a measurable outcome that defines done. Strip any one of those away and the statement decays into a feature request the moment someone estimates it in a sprint planning meeting.

Quick answer: A job statement holds up in engineering when it names the situation, the motivation, and an acceptance-level outcome metric — not just a desired feature. Attach a measurable "done," and the job survives estimation, refinement, and scope cuts intact.

Why Job Statements Die Between Discovery and the Backlog

Job statements dissolve into feature tickets because refinement rewards specificity, and a well-written job is deliberately non-specific about solutions. Engineers need something concrete to build; if the job statement doesn't supply an outcome to build toward, they'll supply a feature instead — and the original context quietly disappears.

This isn't a training problem, and it isn't an engineering problem either. It's a structural one: most teams write a job statement once, during discovery, then translate it into tickets during planning. Translation is lossy by nature. Every handoff drops whatever wasn't written down explicitly, and the situation and motivation usually lived only in a research readout or a Slack thread nobody linked to the ticket.

The pattern shows up in the data, too. The Standish Group's long-running CHAOS research has repeatedly flagged unclear or shifting requirements as one of the top few reasons software projects run over budget, slip their timelines, or get cancelled outright — a finding that has held up across decades of editions, even as the exact figures move. Ambiguity isn't a rounding error in delivery risk; it's a leading cause of it.

Marty Cagan's argument for empowered product teams, developed through the Silicon Valley Product Group, rests on the same fault line. Teams handed an output ("build X") can't reason about tradeoffs. Teams handed an outcome ("achieve Y, for this reason, under these constraints") can push back, resequence, or solve the job with less code than anyone assumed. A job statement is only useful to engineering if it survives as an outcome, not a to-do.

The failure is rarely visible in the moment. A job statement looks intact in the discovery readout, intact in the PRD draft, and only reveals what's missing once an engineer asks "what does done look like here?" in a standup and nobody in the room has the same answer. By then the job has already been silently replaced by whatever the loudest voice in that standup proposed.

Four things get stripped out in a typical translation from discovery notes to ticket:

• The situation — the specific trigger moment, replaced by a generic persona
• The motivation — the underlying stakes, replaced by "as a user, I want"
• The constraint — what's out of bounds technically or organizationally, left unstated
• The success measure — how anyone will know it worked, left to whoever reviews the PR

If you haven't nailed down the fundamentals of this thinking yet, the complete guide to jobs-to-be-done is the place to start before you try to make a job statement engineer-proof.

The Anatomy of a Job Statement That Holds

A job statement that survives contact with engineering has four load-bearing parts: the situation, the motivation, the constraint, and an outcome expressed as a metric. Drop any one, and the statement can be reinterpreted by whoever picks up the ticket next — which is exactly how "help users collaborate" becomes a comment box nobody asked for.

The format itself isn't new. Tony Ulwick's Outcome-Driven Innovation (ODI) research popularized the "job story" structure — when [situation], I want to [motivation], so I can [expected outcome] — precisely because "as a user, I want a feature" hides the situation that makes the feature necessary at all. If you haven't standardized on a template yet, the guide to writing the JTBD job statement format covers the canonical sentence structure in more depth than this article has room for.

Clayton Christensen's Forces of Progress model adds the other half: a job only fires when a push (frustration with the status quo) exceeds the pull of a new behavior, net of anxiety and habit. Both frameworks agree on the same thing — a job is a moment, not a persona. Neither framework, on its own, tells engineering when the job is done — that's what the fourth part, the outcome metric, is for.

The table below breaks each component down by the question it answers and what tends to go wrong when it's missing.

Situation

Name the specific circumstance, not the role. "Two reviewers editing the same clause of a contract at the same time" beats "a user collaborating." If you've already mapped where this moment sits relative to other moments a customer experiences, the customer journey guide is useful for pinpointing exactly which stage the trigger belongs to, so the situation doesn't get generalized away during handoff.

Motivation

State what's at stake if the job goes unmet — not the feature that would help. "Avoid silently overwriting a colleague's edit" is a motivation. "Wants real-time presence indicators" is already a solution wearing a motivation's clothes.

Constraint

Say what's off-limits: no new auth system, must render inside the existing document viewer, can't add latency to page load. Constraints often surface only when you trace second-order effects across adjacent systems, which is exactly the discipline covered in the systems thinking guide — a constraint you miss in isolation often shows up as a feedback loop somewhere else in the product.

Outcome, as a metric

This is the part most job statements skip entirely, and it's the subject of the next section — because without it, "done" is whatever the engineer who picked up the ticket decided it meant.

From Vague to Engineer-Ready: A Side-by-Side Rewrite

A vague job statement and an engineer-ready one can describe the exact same underlying need — the difference is entirely in what's written down. "Help users collaborate" gives an engineer nothing to estimate, test, or push back on. The rewrite below shows what changes when you add situation, constraint, and a measurable outcome.

Notice the engineer-ready version never mentions "presence indicators," "live cursors," or any other implementation. That omission is deliberate — it's what requirements-engineering practitioners, including the discipline formalized by INCOSE (the International Council on Systems Engineering), call solution-free requirements: a description of what must be true, without dictating how it gets built. The moment a job statement names a UI pattern, it stops being a job and starts being a spec — and a premature one, since engineering hasn't had the chance to find a cheaper path to the same outcome.

Attaching Acceptance-Level Outcome Metrics

An outcome metric turns a job statement into something engineering can treat as a testable acceptance criterion, not a subjective judgment call at review time. Ulwick's ODI method gives a reusable formula: a direction (minimize, maximize, increase the likelihood of), a metric a person or system is trying to control, and a contextual clarifier that scopes when it applies.

Applied to the collaboration example: minimize the time it takes to identify who else is currently editing a shared clause, when multiple reviewers have the document open simultaneously. That single sentence is now falsifiable. QA can write a test against it. An engineer can propose three different technical approaches and evaluate them against the same yardstick, instead of debating whether "collaboration" has been achieved.

Four steps turn a job statement into one with an attached acceptance metric:

1. Identify the metric someone is trying to control — time, error rate, number of steps, probability of a bad outcome.
2. Choose a direction — minimize, maximize, or increase the likelihood of the metric moving.
3. Add a contextual clarifier — the specific circumstance under which the metric applies, borrowed straight from the situation you already wrote.
4. Attach a threshold or baseline — "from X to Y" or "within N seconds" — so acceptance isn't a matter of opinion during code review.

Outcome metrics only work if they're computable, and computability is a data problem before it's a delivery problem. If your metric depends on knowing which reviewer last touched which clause, that's an entity and an event that has to exist in your schema before anyone can measure it. The data modeling guide walks through mapping the entities and events a metric depends on, which is worth doing before you promise engineering a number you can't actually query.

A job statement without an outcome metric is a hypothesis. A job statement with one is a contract.

Keeping the Job Alive Through Handoff

The job statement's biggest vulnerability isn't the day it's written — it's every subsequent edit as it moves from discovery notes into a PRD, then into tickets, then into a pull request description. Each contributor who touches the document tends to compress it toward whatever they need it to say for their part of the work, and the situation and constraint are usually the first casualties.

Two disciplines protect against this. First, treat the PRD's problem section as a direct restatement of the job statement, not a paraphrase — if the job changes shape when it moves into the PRD, that's a signal something got lost, not a stylistic choice. Teresa Torres's opportunity-solution-tree approach makes the same point from the discovery side: keep the job and the opportunities visibly connected to the eventual solution, so nobody downstream can quietly swap in a different job.

Second, treat the handoff to engineering the way you'd treat an API contract rather than a Jira description. Specificity about inputs, outputs, and constraints is exactly what makes an interface reliable, which is the same logic covered in the API product design guide — a job statement with a named situation, constraint, and outcome metric functions like an interface spec for the problem itself, not just the endpoint.

Key Takeaways

• A job statement needs four load-bearing parts to survive handoff: situation, motivation, constraint, and an outcome metric — drop one and it gets reinterpreted downstream.
• Vague jobs like "help users collaborate" give engineering nothing to estimate against; engineer-ready jobs name a specific moment and a measurable finish line instead.
• Use Ulwick's ODI outcome-statement formula — direction, metric, contextual clarifier, threshold — to turn a job into a testable acceptance criterion.
• Keep job statements solution-free: naming a UI pattern or technical approach prematurely forecloses cheaper solutions engineering might otherwise find.
• Outcome metrics are only real if they're computable — check the underlying data model before promising a number nobody can query.
• Treat the handoff to engineering like an interface contract, not a ticket description, and audit the PRD's problem section against the original job statement at each revision.