The One-Page Job Canvas: Everything a Squad Needs on a Single Sheet

A one-page job canvas is a single-sheet artifact that captures a customer's job-to-be-done, the executor performing it, the four forces driving switching behavior, a scored list of desired outcomes, and the one opportunity a squad is betting on this quarter — everything discovery produced, compressed into something a team can actually re-read before every planning meeting.

A job canvas is a one-page discovery summary with five blocks: job statement, executor, four forces (push, pull, anxiety, habit), scored outcomes, and the chosen bet. Keep it to one page or it stops getting read.

What a Job Canvas Actually Is (and Why One Page Is the Point)

A job canvas compresses weeks of interviews, support tickets, and win/loss notes into one sheet a squad can hold in their head: what job the customer is hiring you for, who's doing the hiring, what's pushing and pulling them, and which underserved outcome you're betting the quarter on. It is a decision document, not a research archive.

Most discovery work dies in a slide deck. A PM interviews a dozen customers, tags forty quotes, and produces a 35-slide readout that gets presented once and archived. Three weeks later nobody on the squad can say what job the product is actually hired to do, so the roadmap quietly drifts back toward whoever complained loudest in the last stakeholder sync.

The job canvas fixes that by refusing to be a deck. It borrows a trick from two very different playbooks: Amazon's narrative six-page memo, which Jeff Bezos introduced specifically to replace bullet-point thinking with full sentences that have to hold together, and Basecamp's Shape Up pitch document, which Ryan Singer caps at roughly a page so a team can decide in one sitting. Both bet that a hard length limit forces you to cut an argument down to what's actually true.

If it doesn't fit on one page, you haven't finished thinking — you've just moved the confusion into an appendix. A working canvas earns its length by cutting ruthlessly. It keeps:

• The job statement, not the full interview transcript
• The executor, not a full persona bio
• Four forces, not a SWOT analysis
• The top 5-8 outcomes, not every quote you collected
• One chosen bet, not a backlog

Everything else — raw notes, recordings, competitive teardowns — lives in a linked doc. The canvas is the summary you actually reread.

The Five Blocks Every Job Canvas Needs

Every job canvas needs five blocks and no more: the job statement, the executor, four forces of switching behavior, a scored outcome list, and the single bet the squad is committing to build against. Skip a block and the canvas either loses its evidence or loses its decision — and a canvas without a decision is just a mood board.

Block 1: The Job Statement

The job statement sits at the top of the canvas in a fixed format — usually a variant of "when [situation], I want to [motivation], so I can [expected outcome]." It names the job, not your product, and it stays stable even if you rebuild the feature three times. For the exact syntax, common phrasing traps, and how to keep solution language out of it, see how to write a JTBD job statement.

Keep it to one sentence. If your job statement needs a paragraph, you're describing a workflow, not a job.

Block 2: The Executor

The executor is the specific role performing the job in a specific context — not a persona deck with a stock photo and a made-up name. A dispatcher juggling four crews on a Tuesday morning is an executor; "busy professional, age 28-45" is not. Naming the executor precisely keeps the rest of the canvas honest, because forces and outcomes only make sense relative to someone's actual situation.

Block 3: The Four Forces

The four forces block borrows directly from the Forces of Progress model that Bob Moesta and Chris Spiek developed and that Clayton Christensen popularized in Competing Against Luck. It maps the psychology of switching in four short bullets:

1. Push — what's wrong with the current way, badly enough to make someone look for an alternative
2. Pull — what's attractive about the new way, specifically
3. Anxiety — what could go wrong if they switch, real or imagined
4. Habit — what keeps them anchored to the old way even after they've decided to change

Skip this block and your canvas explains the destination without explaining why anyone would ever leave home.

Block 4: The Outcome Scorecard

The outcome scorecard is a short table of desired outcomes, each phrased in Tony Ulwick's Outcome-Driven Innovation format ("minimize the time it takes to..." or "increase the likelihood that...") and scored on importance and satisfaction, usually on a 1-10 scale collected through structured interviews or a quantitative survey. The scorecard is where the canvas earns its credibility — scores turn opinions into a ranked list.

Each outcome gets an Opportunity Score, calculated as importance plus the gap between importance and satisfaction. Outcomes that are important but poorly satisfied score highest and get labeled underserved; outcomes where satisfaction already matches or exceeds importance get labeled appropriately served or overserved. The exact formula, worked math, and scoring thresholds are covered in the opportunity score formula explained — the canvas just needs the final scores and labels, not the arithmetic.

Block 5: The Chosen Bet

The chosen bet is the one line that makes the canvas a decision instead of a report. After the scorecard is ranked, the squad picks the single underserved outcome it will build against this quarter and states it as a testable hypothesis: if we do X, this specific outcome should move. Everything else on the scorecard waits.

A Filled-In Example: Fieldnote's Job Canvas

Here's what a completed canvas looks like for a fictional field-service scheduling tool called Fieldnote, used by HVAC and plumbing dispatchers to route technicians. The example is illustrative — a stand-in for the kind of one-pager a discovery-stage squad would actually produce, not a case study of a real customer.

Job statement: When an emergency service call comes in on a fully booked day, I want to slot it into the right technician's route without blowing up everyone else's schedule, so I can protect same-day revenue without technicians driving in circles.

Executor: The dispatcher — office-based, on the phone with the customer, juggling four to six crews at once, working from a whiteboard and a paper map of the service area.

Four forces:

• Push: Last week's double-booked emergency call sent two technicians criss-crossing town twice, costing 90 minutes of drive time and an angry customer.
• Pull: A system that suggests the best slot for an emergency job, matched by location and skill, in under 30 seconds.
• Anxiety: Worry that an automated suggestion will assign a complex repair to an under-qualified technician, or that switching off the whiteboard will slow down the dispatcher who knows the territory by heart.
• Habit: The whiteboard and sticky notes have worked for nine years; the dispatcher's mental map of the service area still feels faster than typing into any tool.

Outcome scorecard:

Chosen bet: We're building against "minimize the time it takes to slot an emergency job into an existing route" — the highest-scoring underserved outcome and the one directly tied to last week's push moment. Hypothesis: if the dispatcher can get a ranked slotting suggestion in under 30 seconds, manual re-shuffling time drops without adding headcount.

Notice what's absent: no feature names, no UI mockups, no sprint dates. Those live in the spec that gets built from this canvas, not on the canvas itself.

Facilitating the Canvas With Your Squad

A job canvas gets built in a single structured working session, not written solo by a PM and emailed around for approval. The room needs a PM, a design lead, an engineering lead, and ideally someone close to support or customer success — the people who will actually build against the bet need to have argued about the scores before they commit to them.

A workable sequence for a 90-minute session:

1. Bring evidence, not opinions. Everyone arrives having reviewed the same interview notes, support tickets, or survey data — no fresh anecdotes invented in the room.
2. Draft the job statement and executor first, and get the whole room to agree on the wording before moving on.
3. Score outcomes independently, silently, before discussing — this is the single biggest defense against groupthink collapsing every score toward the loudest voice.
4. Reveal scores together and debate the outliers — if two people scored the same outcome five points apart, that gap is the conversation.
5. Converge on one chosen bet and write it as a hypothesis the squad can actually falsify next quarter.

The job canvas isn't a replacement for a customer journey map — the two answer different questions. The journey shows where in a process the friction lives and how emotion moves across it; the canvas shows why the job exists and which underserved outcome is worth building against. Strong discovery practices tend to use both, in either order, depending on whether the team is starting from a known workflow or an ambiguous job.

Five Mistakes That Turn a Canvas Into Shelfware

A job canvas fails the same way most one-pagers fail: it gets built once, printed or pinned to a wiki page, and never touched again. Five mistakes account for most of that outcome, and all five are avoidable with a bit of discipline in how the canvas is built and used.

1. Too many outcomes. A scorecard with twenty rows isn't a canvas, it's a spreadsheet with a border. Cap it at five to eight outcomes or the ranking stops meaning anything.
2. Scores from gut feel, not evidence. If nobody can point to the interview or ticket that justified a 9 for importance, the number is a guess wearing a decimal point.
3. Skipping the forces because "we already know why customers switch." Teams that skip this block usually rediscover, mid-build, that the anxiety force was the actual blocker all along.
4. No connection to the engineering handoff. A canvas that never turns into a spec engineers can build from is just a nicer-looking discovery deck. See how job statements survive the handoff to engineering for how to carry the job statement's intent through to tickets without it getting lost in translation.
5. Ignoring the wider system the job sits inside. Optimizing one outcome in isolation can create a feedback loop that makes a different part of the system worse — a faster slotting suggestion that quietly overloads your best technician, for instance. The systems thinking guide covers how to spot these loops before you commit a quarter to one bet.

Keeping the Canvas Alive for a Quarter

A canvas survives a quarter only if someone actually opens it between planning meetings, which means it needs an owner, a review cadence, and a place to live that isn't a slide buried in a shared drive. Treat it as a living document that gets re-scored as new evidence arrives, not a plaque.

A few habits keep it alive:

• Revisit at the quarter boundary, not just when a project kicks off — re-score outcomes with whatever new evidence came in.
• Version it, so the squad can see how satisfaction scores moved after you shipped against the chosen bet.
• Link it forward into the spec or PRD, so the bet doesn't just sit on the canvas — it shows up in what actually gets built.

Key Takeaways

• A job canvas is a five-block, one-page artifact: job statement, executor, four forces, scored outcomes, and a chosen bet.
• The one-page constraint is deliberate — it forces the same discipline Amazon's narrative memos and Basecamp's Shape Up pitches use to kill vague thinking.
• The four forces (push, pull, anxiety, habit) explain switching behavior; skipping them leaves out half the story.
• The outcome scorecard turns opinions into a ranked list using Ulwick's importance-minus-satisfaction opportunity score.
• The canvas only earns its keep if it ends in one chosen bet, not a menu of options.
• A canvas dies without a review cadence — revisit and re-score it every quarter, not just once at kickoff.