Why the framework I didn't learn until my first month at Clear changed how I write every PRD since
Ayush Sharma · Product & Operations Lead, Medoc Health IT
I didn't know what Jobs to Be Done was until I joined Clear. It was the first thing they taught, in the first week, before anything about their actual product. At the time it felt almost too simple to be a "framework" — of course people don't want a drill, they want a hole in the wall. But once you actually try to apply it to a real feature decision, it stops being a slogan and starts being uncomfortable, because it forces you to admit that most feature requests are described in terms of the solution the customer already imagined, not the problem underneath it.
That discomfort is the whole value of JTBD. It's also exactly why it's underrated — it's easy to nod along to the milkshake story and then go right back to writing a PRD titled "Add Filter to Dashboard."
Jobs to Be Done, most associated with Clayton Christensen, reframes the basic product question. Instead of asking who is this user and what do they want, it asks: what job is this person "hiring" the product to do, in a specific situation, and what would make them "fire" it for something else?
A job isn't a feature request and it isn't a demographic. It's a situation-shaped need: when [situation], I want to [motivation], so I can [outcome]. The situation matters as much as the outcome — the same person wants completely different things from the same product depending on what's happening around them at that moment.
Most product teams skip straight from "user said X" to "we should build X." JTBD forces a stop in between: why did they ask for X, and is X actually the best way to get that job done? Skipping that stop is how products end up with a pile of shipped features that technically satisfy requests but don't move any outcome that matters — because nobody asked what the request was actually standing in for.
It's underrated specifically because it doesn't look like it's doing anything. There's no dashboard, no framework diagram people love pinning to a wall. It's a discipline applied at the moment a requirement is written down — which makes it invisible when done well, and very expensive when skipped.
These get treated as interchangeable and they're not. A persona describes a type of person — role, context, goals, frustrations, roughly stable over time. A job describes a situation — and the same persona can have wildly different jobs depending on what's happening when they open the product.
Take a hospital billing clerk. As a persona, she's consistent: daily user, low tolerance for friction, values speed. But her job on a normal Tuesday ("close this bill fast so the patient can leave") is a completely different job than the one she has when an insurance approval changes mid-treatment ("adjust the line-item breakdown without voiding and re-entering the whole bill"). Same persona, two different jobs, two different feature answers. Personas tell you who you're designing for. Jobs tell you what to actually build for them, in the moment it matters.
<aside> 💡
Read more about how I build out personas →
Beyond the Template: How I Build User Personas
</aside>
Generic PRD, no JTBD:
Feature: Bill Editing Allow staff to edit an existing bill after it's generated. Add an "Edit" button on the billing screen. Editable fields: amount.
This isn't wrong, exactly. It's just underspecified in a way that guarantees engineering will build the minimum version — a single editable "amount" field — because nothing in the spec tells them why editing is needed or what happens if the minimum version doesn't cover the real situation.