Writing jobs-to-be-done statements from video research
A job statement is only as good as the situation behind it. Practitioner video shows the situation directly, which is why it is a better source than a recollection of it.
The short answer: watch for the trigger, the struggle and the result someone checks for, write one sentence per job in the form “when … I want to … so I can …”, strip out any mention of a tool, and keep only the statements that three independent sources support. Then rank them. The ranking, not the list, is what shapes the product.
Jobs-to-be-done is one of the few product frameworks that survives contact with a real build, because it forces a description of the progress someone wants rather than the thing they asked for. Its weak point has always been sourcing. Job statements written in a workshop from memory tend to describe the product the team already wanted to make. Statements written from footage of people doing the work are harder to bend.
The three parts, and where each one shows up on screen
A usable job statement has a situation, a motivation and an outcome. Each has a distinct signature in practitioner content, and knowing what to look for turns an hour of video into a handful of sentences rather than a page of notes.
| Part of the statement | What it sounds like in a video | Where it usually appears |
|---|---|---|
| Situation (“when …”) | “Every time a client sends over …”, “At the end of each month …” | The first two minutes, before any tool is opened |
| Motivation (“I want to …”) | “What I’m trying to do here is …” | Narration over the working steps |
| Outcome (“so I can …”) | The thing they check at the end to confirm it worked | The last minute, often unspoken |
| Struggle (the reason the job is unserved) | “This part is annoying”, a sigh, a copy-paste between tabs | The middle, at the hand-off between tools |
The outcome is the part most often missed, because creators rarely say it out loud. They simply look at a number, a preview or a sent confirmation and move on. That glance is the definition of done for the job, and it is worth more than any stated goal. The same close reading of routine work is described in mapping workflows from day-in-the-life videos.
The tool-removal test
Most first-draft job statements are feature requests. The test is mechanical: delete the tool from the sentence and see whether anything is left.
- ✗When I open the app, I want a dashboard, so I can see everything
- ✗I want an integration with my calendar
- ✗I want AI to write the report for me
- ✗I want better filters on the export screen
- ✓When Monday starts, I want to know which clients are behind, so I can chase before it becomes a problem
- ✓When a booking changes, I want everyone affected to find out without me telling them
- ✓When the month closes, I want the summary sent without rebuilding it by hand
- ✓When I am asked a question mid-call, I want the one record that answers it
The second list is uncomfortable in a useful way, because each line can be served by several different products, and some of them are not software at all. That is the point. A job that only your planned feature can satisfy is a job you wrote backwards from the feature.
A repeatable extraction pass
The pass works best on content where someone is doing real work rather than explaining a concept: tutorials, workflow walkthroughs, “how I run my week” videos and tool-switching stories. Twenty to thirty videos from unrelated creators is enough for a first map; the reasoning behind that number is in how many videos a research corpus needs.
For each video, record four things and nothing else: the trigger that started the work, the step where effort or irritation spiked, the result they checked for, and the timestamp of each. Resist summarising the video. A summary records what the creator said, and a job statement needs what the creator did.
Then cluster. Statements that share a situation and an outcome belong together even when the wording differs completely. A bookkeeper who wants “the reconciliation off my plate by the fifth” and one who wants to “stop spending the first week of the month in spreadsheets” are describing one job. The clustering step is where an AI synthesis earns its place, since matching meaning across different vocabulary is tedious by hand and quick for a model that keeps the citations attached.
When you write the final statement, use the verbs practitioners used. “Chase”, “reconcile”, “sign off” and “hand over” carry meaning that “manage” and “track” flatten. The same vocabulary later becomes your navigation labels and your landing page headline.
Ranking jobs by evidence, not enthusiasm
A list of jobs is not a strategy. The primary job is the one with the strongest combination of three signals: how often the situation occurs, how much visible effort the current approach takes, and how many independent sources show it. A job that appears in eighteen of twenty-five videos and involves a manual copy between two tools outranks a more interesting job that one articulate creator described once.
Visible effort is the signal people underweight. A practitioner who has built a spreadsheet, a checklist and a reminder to get a job done is showing you what the job is worth to them. That behaviour is covered in depth in spotting manual workarounds in creator content, and it is the closest thing to a willingness-to-pay signal that exists before you have a product.
Jobs that are frequent but already well served should be marked and set aside. They belong on the map, because your product has to coexist with whatever serves them, but they are not where a new entrant wins. Deciding what to leave to existing tools is the subject of build, buy or integrate.
From the primary job to a first version
Once one job is ranked first, the scope of a first version becomes a much smaller question: what is the least a product must do for someone in that situation to reach that outcome? Everything that does not sit on the line between the trigger and the checked result is a later release.
This is also where the job statement starts paying for itself in places other than the roadmap. The situation becomes the opening line of the landing page. The outcome becomes the success state of onboarding. The struggle becomes the demo. Each of those is a direct lift from the statement, which is why the wording is worth the care — the prioritisation step itself is laid out in prioritising features with research evidence, and the cut-down to a first release in scoping a v1 from build-along videos.
Three ways job statements go wrong
The first is writing at the wrong altitude. “Run my business better” is true and useless. “Rename a column” is precise and too small to build a product around. The right altitude is a job someone would recognise as a named chunk of their week.
The second is merging two jobs because the same person has both. An agency owner who needs to win new clients and also needs to report to existing ones has two jobs with different triggers, and a product that tries to serve both in its first version usually serves neither.
The third is trusting a single persuasive source. A well-produced video from a large channel can dominate a research corpus by sheer clarity. Counting sources rather than weighing eloquence is the correction, and checking who is speaking matters as much as how many — the difference between people who do the work and people who sell to those who do is set out in vendor content versus independent creators.
What this costs
A job map needs breadth across creators more than depth on any one, so 20 to 30 videos is a sensible first corpus. As of October 2026, Hobby is $19 a month with 25 videos and 2 projects, Pro is $59 with 80 videos and 8 projects, and Studio is $199 with 250 videos, 20 projects and 3 seats, each with a 7-day free trial — details on the pricing page.
Add 20 practitioner videos to a project and synthesise them into ranked job statements, each with the sources and timestamps behind it. 7-day free trial.
Closing thought
A job statement is a claim about other people’s lives, and claims need evidence. The framework has been around for a long time. What is new is being able to check each sentence against thirty people doing the work on camera, in an afternoon.
Frequently asked
What is a jobs-to-be-done statement?
A single sentence describing the progress someone is trying to make in a specific situation, independent of any product. The usual shape is: when a situation occurs, I want to do something, so I can reach an outcome. It describes the job, never the tool.
Why write job statements from video instead of interviews?
Because video shows the situation rather than a recollection of it. In an interview people summarise and tidy up. In a tutorial or a workflow walkthrough you see the trigger, the tool they reach for, the step they dread and the result they check for, all in sequence and unprompted.
How many job statements should a product have?
One primary job and two or three supporting ones for a first version. A list of fifteen is a feature backlog in disguise. If you cannot rank the jobs, you have not finished the research, and the ranking is the part that shapes the product.
How do I tell a job from a feature request?
Remove the tool from the sentence. If the sentence still makes sense, it is a job. 'I want a dashboard' collapses when you remove the dashboard. 'I want to know by Monday morning which clients are behind' survives, and a dashboard is only one of several ways to serve it.
What evidence should sit behind each statement?
At least three independent sources showing the same situation and the same desired outcome, each cited with a link and a timestamp. One creator describing a need is an anecdote. Three unrelated ones describing it in different words is a pattern you can build on.
Do job statements replace user personas?
They do different work. A persona describes who someone is, a job describes what they are trying to get done and when. For a first version the job is the more useful of the two, because the same job is often shared by people who look nothing alike on a persona sheet.
What does it cost to run this research?
As of October 2026, Hobby is $19 a month for 25 videos and 2 projects, Pro is $59 for 80 videos and 8 projects, and Studio is $199 for 250 videos, 20 projects and 3 seats, with a 7-day free trial on every plan. A job-mapping corpus of 20 to 30 videos fits inside Hobby or Pro.