A JTBD workshop stays on the job — not the feature — when four moves each get their own timed block: warming up on the customer's struggle, drafting job statements, force-ranking desired outcomes with scores, and parking every solution idea in a visible list everyone can see.

Run four timed blocks in a half day: struggle warm-up, job statement drafting, force-ranked outcome scoring, and a running parking lot for solutions. A facilitator who redirects "what if we just built X" into "which outcome would that improve" is what keeps engineers, design, and sales out of a feature debate.

Why JTBD Workshops Collapse Into Feature Debates

JTBD workshops turn into feature debates because job statements are abstract and features are concrete, and a mixed room of engineers, designers, and salespeople will always gravitate toward whatever's easiest to argue about. Nobody has to defend an opinion about a job statement the way they defend an opinion about a specific button.

This isn't a discipline problem. It's a structural one. Clayton Christensen's Jobs to Be Done theory — built out through the well-known milkshake study he ran with Bob Moesta for a fast-food chain — showed that customers don't buy products, they hire them to make progress on a struggle. A struggle is fuzzy, and a fuzzy conversation makes a room full of doers uncomfortable.

Each function in the room defaults to its own solutioning language:

  • Engineers default to architecture: "we could build this with an event queue."
  • Sales defaults to the deal: "the customer already asked for X."
  • Design defaults to the screen: "here's a mockup of what this could look like."

None of these defaults are wrong on their own — they're just premature. Solving before the room agrees on what's being solved for is exactly how a half day evaporates into a backlog-grooming session wearing a JTBD name tag.

Cross-functional misalignment isn't a soft problem either. Gallup's long-running workplace research has repeatedly found that teams unclear on shared priorities burn real time on duplicated or conflicting work — precisely the dynamic a JTBD workshop exists to prevent, not recreate at whiteboard scale.

If your team hasn't agreed on the underlying theory yet, it's worth reading the complete guide to jobs-to-be-done before you book the room. A workshop can't manufacture shared framework literacy in real time — it can only build on top of it.

The Half-Day Agenda: Struggle, Statements, Ranking, Parking Lot

A JTBD workshop that fits a half day needs four blocks, each with its own timer and a named output: a struggle warm-up, a job-statement draft, a force-ranked outcome scoring session, and a parking lot running the entire time. Skipping the timer is how sessions run long and drift into solutioning.

BlockTimeWho leadsOutput
Struggle warm-up20 minFacilitator + one customer voice (recording, quote, ticket)A struggle statement the whole room recognizes
Draft job statements55 minSmall mixed groups (3–4), then merge1–2 core job statements in a consistent format
Force-rank outcomes65 minFacilitator, silent scoring8–12 candidate outcomes, top 3–5 scored
Parking lotOngoingDedicated scribeA visible, timestamped list of solution ideas

Warm-Up on the Customer's Struggle

Open with 15–20 minutes of raw material, not opinions. Play a recorded support call, read three verbatim tickets, or bring a clip from a customer interview. The goal is getting the whole room looking at the same struggle before anyone starts theorizing about it.

Bob Moesta and Chris Spiek's Forces of Progress model — push, pull, anxiety, and habit — is a useful lens for the discussion that follows:

  1. What was pushing the customer away from their old way of doing this?
  2. What pulled them toward looking for something new?
  3. What made them anxious about switching?
  4. What habit did they have to break to even consider a change?

If your team already maintains a customer journey emotion curve, project it here. A shared curve gives everyone the same reference point for where the struggle actually lives, instead of relying on whoever tells the most vivid anecdote.

Draft Job Statements

Break into mixed small groups of three or four — deliberately mixing functions so no group is homogeneous. Each group drafts using the Job Story format popularized by Alan Klement and Intercom's product team: "When [situation], I want to [motivation], so I can [expected outcome]."

Use a consistent syntax across groups. The job statement format guide walks through the exact structure — verb, object, contextual clarifier — so statements are comparable when groups reconvene, instead of four paragraphs of freeform prose.

Post every group's statement on the wall, cluster by similarity, and vote on which cluster describes today's job. Park the rest rather than debating them; a workshop that tries to align on three jobs at once usually aligns on none.

Force-Rank Outcomes

From the agreed job statement, brainstorm desired outcome statements silently on sticky notes — five minutes, no talking. Phrase each as a direction plus a metric: "minimize the time it takes to…" or "increase the likelihood that…"

Score the top 8–12 with two silent numbers per outcome: importance (1–10) and current satisfaction (1–10). This is the same opportunity-score math Tony Ulwick built for Outcome-Driven Innovation — see how the opportunity score formula works for the full derivation — and it does double duty as a tiebreaker when the room can't agree by feel alone.

Opportunity Score = Importance + max(Importance − Satisfaction, 0)

Rank by score and carry the top three to five forward. Everything else stays visible but doesn't get argued over today.

Parking Lot for Solutions

Keep a physical or digital list visible for the entire session. Every solution idea gets a line — who said it, when — with no discussion and no ranking in the room. The parking lot only works if people trust it isn't a graveyard, so name a reviewer and a review date before the session ends.

Facilitation Moves That Send Solutioning Back to the Job

The facilitator's job is to notice the moment a comment shifts from describing the job to prescribing a fix, and to redirect it in one sentence without shaming whoever said it. Three techniques carry most of the weight: naming the shift out loud, silent scoring instead of open debate, and a standing "park it" ritual.

What someone saysWhat's actually happeningFacilitator redirect
"What if we just added a one-click button for this?"Jumping to a fix before the job is scored"Parked. Which outcome would that button move — speed, effort, or accuracy?"
"Sales already promised this to a customer."A commitment being used to skip prioritization"Which job is that serving? Let's see where it lands once we score outcomes."
"Engineering's already built half of this."Sunk cost steering the room"Noted for the parking lot. Does it move our top-ranked outcome?"
"That's not technically feasible anyway."Feasibility debate mid-scoring"Feasibility is next week's conversation — right now we're only scoring importance and satisfaction."
One person dominates the scoring discussionGroupthink, anchoring on the loudest voice"Everyone writes a number before anyone speaks. We reveal together."

A few standing habits make these redirects easier to land:

  • Keep a visible timer. A room that can see 4 minutes left on force-ranking argues less about tangents.
  • Score silently, reveal together. Writing a number before anyone speaks removes the anchor effect entirely.
  • Repeat the agreed job statement out loud before every vote, so scoring stays anchored to the job, not to whatever was just said.
  • Give the parking lot its own scribe, separate from the main facilitator, so a redirect doesn't stall the room's momentum.

Recurring feature requests are frequently a symptom, not a shortage of good ideas. When the same fix gets proposed by three different people across a single afternoon, that's usually a signal worth mapping separately with a systems thinking lens — an incentive loop or workflow bottleneck the workshop shouldn't try to solve on the spot.

A Worked Example: Three Scored Outcomes by Lunch

Here's how the four blocks play out for a hypothetical B2B expense-reporting team running a JTBD workshop on "getting reimbursed." The session starts at 9:00 a.m. and produces one job statement and three scored outcomes by 12:30 p.m. — without a single feature name entering the outcome list.

  • 9:00–9:20 — Struggle warm-up (a recorded support call about a rejected reimbursement)
  • 9:20–10:15 — Draft job statements in small groups, then converge
  • 10:15–10:25 — Break
  • 10:25–11:30 — Brainstorm and force-rank outcomes
  • 11:30–12:00 — Review the parking lot, assign an owner and review date
  • 12:00–12:30 — Recap the job, the top outcomes, and next steps

The room converges on one job statement:

"When I've paid for something out of my own pocket for work, I want to get reimbursed without having to remember every receipt or chase down an approver, so I can trust that doing the right thing for the company doesn't cost me personally."

The brainstorm produces roughly ten candidate outcomes. The group scores the top three using silent importance and satisfaction numbers:

Desired outcomeImportance (1–10)Satisfaction (1–10)Opportunity score
Minimize the time between submitting an expense and being reimbursed8412
Minimize the effort required to capture and attach proof of purchase759
Minimize the likelihood an approved expense gets rejected later9612

None of these numbers come from a real company — they're illustrative, meant to show the arithmetic, not a claim about what any actual tool's customers said. The two outcomes tied at 12 become the team's shared focus; the third stays visible but isn't the immediate priority.

By the time lunch arrives, the parking lot already has five or six feature ideas on it — a one-click reimbursement button, receipt OCR scanning, a Slack nudge bot. None of them got debated. All of them now sit next to the outcome they'd need to move to earn a place on the roadmap.

Keeping the Job Alive After the Workshop Ends

The job statement and scored outcomes only matter if they survive contact with the backlog, and that takes the same rigor used in the room: a stable, solution-agnostic statement, a named owner, and a visible link between anything that gets built and the outcome it was meant to move.

Job statements that get rewritten as user stories the moment they hit a sprint board tend to lose the "why" within two sprints. The piece on how job statements survive the handoff to engineering walks through the specific points where that erosion happens and how to guard against each one.

Two habits matter most after the whiteboard is wiped clean:

  1. Re-score quarterly, not annually. Satisfaction moves faster than most teams expect once a competitor ships something adjacent.
  2. Route the parking lot through the outcome it serves, not through whoever shouts loudest in backlog grooming the following week.

Teresa Torres's continuous-discovery work makes a related point worth borrowing here: outcomes aren't a one-time scoring exercise, they're a living map that gets revisited every time your team runs another round of customer interviews. A workshop's outcome list is a strong starting snapshot, not a permanent ranking.

Capturing the Alignment So It Survives the Whiteboard

The most common way a JTBD workshop dies is boring: the whiteboard gets erased, the job statement lives only in a recap email, and the ranked outcomes fade within a sprint. What the session actually needs to produce is a durable record, not just a good afternoon.

This is the specific gap Prodinja's Customer Jobs tool is built to close. It walks you through capturing the agreed job statement, scoring outcomes with the same Ulwick opportunity-score math your team used on the whiteboard, and logging the Forces of Progress context from the warm-up — so the workshop's output becomes a structured record instead of a fading memory.

You can carry the same three scored outcomes straight from the parking lot into the tool, then revisit and re-score them the next time priorities shift, without re-litigating the whole session from scratch. The whiteboard photo fades. The record doesn't have to.

Key Takeaways

  • Structure beats willpower. Four timed blocks — struggle, statements, outcomes, parking lot — prevent solutioning by design, not by asking people to behave.
  • Warm up on raw customer material (calls, tickets, quotes) before anyone theorizes, organized by the Forces of Progress: push, pull, anxiety, habit.
  • Draft job statements in mixed small groups using a consistent, solution-agnostic format, then converge on one shared statement for the session.
  • Force-rank outcomes with silent scoring and the Ulwick opportunity-score formula so ties get broken by math, not the loudest voice in the room.
  • Give solutioning a visible, trusted home. A parking lot with a named reviewer and review date is what makes people willing to let an idea go mid-session.
  • Redirect with one-line facilitator moves that name the shift from job to fix without shaming whoever made it.
  • Capture the job and scored outcomes somewhere durable immediately after the session — before the whiteboard gets erased and the alignment goes with it.

Frequently Asked Questions

How long should a JTBD workshop actually be?

A half day — roughly three and a half to four hours — is enough for one job with a cross-functional group of six to ten people, as long as the four blocks (warm-up, statements, outcomes, parking lot) are timeboxed and a facilitator enforces the schedule. Trying to cover more than one job in the same session is the most common reason half-day workshops run long.

Who should be in the room for a JTBD workshop?

Include a facilitator (often the PM, or a neutral outside facilitator if the PM has a strong opinion to defend), an engineering lead, a designer, and someone from sales or customer success who talks to customers directly. Six to ten people keeps small-group breakouts functional; past twelve, breakout groups get unwieldy and quieter voices disappear.

What's the difference between a job statement and a feature request?

A job statement is stable and solution-agnostic — it describes a struggle and the progress someone's trying to make, regardless of how it gets solved. A feature request names one specific implementation. A single job statement can justify dozens of different features over a product's lifetime, which is exactly why teams score outcomes instead of features.

How do you handle it when the group can't agree on outcome scores?

Score silently and simultaneously first, so no one's number anchors anyone else's. Then discuss only the outliers — the outcomes where individual scores spread widest — rather than re-litigating every number. Use the opportunity-score formula as the tiebreaker instead of calling for a re-vote; math ends debates that opinion alone won't.

What happens to the parking lot after the workshop ends?

The named reviewer works through it within the agreed window — 48 hours is typical — and routes each idea against the outcome it would serve if built. Ideas aren't discarded; they become candidate solutions attached to a scored outcome, which is what lets a team revisit them later without re-running the whole workshop.