By 6days · v1.0 · Updated 7/20/2026
People don't buy products, they hire them for a job — find out what the job is.
Fill this in for your own situation — a private worksheet only you can see.
When to use
Use it when demographic segmentation has stopped generating insight, when you cannot explain why customers churn or convert, when entering an adjacent market, or when a roadmap has become a queue of the loudest requests with no organising logic.
When not to use
Avoid it for incremental optimisation of a well-understood product — you know the job, and reopening it is procrastination. It is weak for infrastructure and compliance work with no discretionary hiring decision. Done badly it collapses into vague poetry about customer aspirations, and 'the job' becomes whatever the loudest person already wanted, now with better rhetoric.
Teams describe customers demographically and build for the description. But 'marketing managers aged 30-45' do not share a need; they share a census category. So the roadmap fills with features requested by whoever asked loudest, competitors are defined as companies that look like you, and the actual reason people started or stopped using the product remains a mystery — because nobody asked about the situation that triggered the switch.
Jobs To Be Done reframes demand around the progress a customer is trying to make in a particular circumstance. People 'hire' a product to get a job done, and 'fire' it when something does the job better. The job is stable over time while the solutions churn — the job of getting a household's laundry clean has outlived every washing technology that ever served it. The reframe has two sharp consequences: your real competitor is anything else hired for the same job, including a spreadsheet or doing nothing at all, and the useful research question is not 'what do you want?' but 'walk me through the last time you switched.'
Framework by 6days on 6days — https://6days.apexaion.ai/framework/jobs-to-be-done
Find customers who recently started or stopped using something, and reconstruct the episode in detail: what happened, what they tried, what finally pushed them. Anchor on a specific event. General preference questions produce a plausible story rather than a true one.
Identify the circumstance that made the old way intolerable on that particular day. People tolerate bad solutions for years; something specific changed. That trigger, not the feature comparison, is what actually created the sale.
State it as circumstance plus motivation plus desired outcome — 'when a client emails a change at 6pm, help me update the quote without reopening the whole file, so I can leave on time.' No product nouns. If your solution is in the sentence, you have written a feature request instead.
List everything currently hired for that job — rival products, a spreadsheet, an assistant, an established habit, doing nothing. The incumbent is almost never the company you benchmark against, and the status quo is the most common winner.
For each planned feature, ask which job it serves and whether it beats the current hire for that job. Features that serve no articulated job are the ones to cut, and the exercise usually finds several.
Worked example
A team building invoicing software for freelancers assumes the job is 'create professional invoices' and invests in templates and branding. Switch interviews tell a different story: nobody switched for a nicer invoice. They switched after a client paid late and an awkward chasing conversation followed. The real job is 'get paid without having to ask twice.' The competitors are not other invoicing tools but the freelancer's own dread of chasing. The roadmap turns to automated reminders, payment-status visibility, and gentle escalation wording — none of which was on the template-driven plan, and all of which address the trigger that actually moves people.
The framing is most associated with Clayton Christensen, who popularised it from the mid-2000s alongside collaborators including Bob Moesta and Rick Pedi, and it connects to earlier outcome-driven work by Anthony Ulwick. Several schools now interpret it differently — some treating jobs as functional specifications, others as situational narratives — and the disagreement between them is genuine rather than cosmetic.
Related ways to think about this.
Score competing work on reach, impact, confidence and effort so the argument is about evidence.
Use when Use it when you have many comparable candidates competing for one team's capacity, when prioritisation has become political and you need a neutral vocabulary, or when you need to explain to stakeholders why their request did not make the cut without it being personal.
Avoid when Avoid it for work that is not discretionary — security fixes, legal obligations and keeping the service up do not get scored, they get done. It handles strategic bets badly: anything genuinely new scores low on confidence and reach by construction, so a team that follows RICE mechanically will optimise itself into small safe increments forever. It also cannot see dependencies or sequencing.
Not all features are equal: some delight, some merely satisfy, and some only hurt when missing.
Use when Use it when a roadmap needs to balance table-stakes against differentiation, when entering an established category where expectations are already set, or when heavy feature investment is somehow producing no measurable satisfaction gain.
Avoid when Avoid it in a genuinely new category, where customers have no expectations to classify against and the survey returns noise. It is survey-based, so it inherits every weakness of stated preference — people are poor predictors of their own delight. It is also expensive to run properly and stale quickly; a three-year-old Kano study is a historical document.
Understand the person, frame the real problem, build something rough, and learn from their reaction.
Use when Use it on ill-defined problems where the need is genuinely unclear, where the people affected are not you, and where the cost of building the wrong thing is high. It is strongest early, when the framing is still open and cheap to change.
Avoid when Avoid it when the problem is well-specified and the answer is known — it is expensive ceremony for work that needs execution. It struggles with problems whose constraints are technical or regulatory rather than human. And it is the most ritualised framework in common use: workshops, sticky notes and a five-stage poster routinely produce the appearance of the method with none of the substance, because nobody left the building to observe anyone.