Comparing by fit
Two ways of thinking, side by side. There is no winner here — read across each row and choose the one that fits your situation.
Product
People don't buy products, they hire them for a job — find out what the job is.
By 6days
Product
Score competing work on reach, impact, confidence and effort so the argument is about evidence.
By 6days
When to use — Jobs To Be Done
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 to use — RICE Prioritisation
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.
When not to use — Jobs To Be Done
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.
When not to use — RICE Prioritisation
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.
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.
Every roadmap has more candidates than capacity, and the selection usually goes to whoever argues best — the loudest stakeholder, the most recent customer escalation, the executive's pet idea. The team cannot articulate why one item beat another, so the decision cannot be revisited when things change, and everyone suspects, often correctly, that the process is political rather than analytical.
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.'
RICE scores each candidate on four factors and combines them into a single number: reach (how many people it affects in a period), impact (how much it moves the thing you care about, per person), confidence (how much you trust your own reach and impact estimates) and effort (person-time to deliver). Multiply the first three, divide by effort. The output is deliberately crude. Its value is not the ranking but the conversation the scoring forces: confidence makes the team say out loud how much of the case is guesswork, and comparing two items usually reveals that a disagreement about priority was really a disagreement about an estimate.
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.
Worked example — Jobs To Be Done
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.
Worked example — RICE Prioritisation
Two candidates. A bulk-export feature: reach 400 users/quarter, impact 1 (medium), confidence 80%, effort 2 person-months — score 160. A redesigned onboarding flow: reach 3,000 new signups/quarter, impact 2 (high), confidence 50% (the evidence is one small study), effort 6 — score 500. Onboarding wins by roughly three to one, which surprises the room because export is what customers ask for by name. The disagreement resolves to a single input: the sales lead thinks onboarding's confidence should be 20%, not 50%. At 20% the ranking flips. Now the team knows exactly what to go and find out, which the argument alone would never have produced.
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.
The scoring model was developed and published by the team at Intercom in the mid-2010s to prioritise their own roadmap, and was shared openly rather than commercialised. It sits within a much older tradition of weighted scoring in project selection; its contribution is the specific inclusion of a confidence discount, which is what distinguishes it from earlier value-over-effort schemes.
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.
Decide what 'impact' means before scoring anything — activation, retention, revenue, support load. Without one agreed metric, scores are not comparable and the whole exercise produces a number that means nothing.
Count how many users or events this touches per quarter, using real numbers wherever they exist. Reach is the factor most amenable to evidence, and grounding it prevents the whole score from floating free of reality.
Use a deliberately blunt scale — massive, high, medium, low, minimal — rather than pretending to precision you do not have. False precision here creates unearned confidence in the ranking.
Discount for how speculative your estimates are. This is the factor that does the real work: it stops a thrilling idea with no evidence from outranking a modest one with data, and it makes the team admit which is which.
Estimate total person-months across all functions, not just engineering. Compute the scores, then interrogate the ranking — where the number offends someone's intuition, find out which input they disagree with. That argument is the actual output.