“When we buy a product, we essentially hire it to help us do a job.” – Christensen, Harvard Business Review
Those of you who have worked with me have heard me frequently (and I mean frequently) opine on the criticality of this framework as a means to achieve product‑market fit. The key output of Jobs to Be Done (JTBD) thinking – and the North Star that aligns technology, marketing, and execution – is the deceptively simple user story. Writing a user story for a feature is one thing. Writing a user story for the company’s product or service – the very raison d’être of a start‑up – is a whole different kettle of fish (yes, I love idioms, analogies, and other figures of speech – as well as French).
“But it’s only one sentence, right? How hard can it be?” Bwahaha.
Getting to a JTBD mindset requires a bit of reframing. Cue algebraic analogy. We all remember fondly (well, at least I do) the elegant formula y = f(x). Pedantic but useful: y, the outcome, is a function f() of some input x. In JTBD terms, your product or service is f(x) and the outcome – the impact – is y. Customers care about the y. They also care about the total cost of f(x), but the why behind the purchase lives in y.
Leaving algebra behind and diving back into the real world of AI inference hardware: if x is tokens or images and f(x) is your PCIe card performing inference, I ask again, what’s your why?
User stories are a great technique for ferreting out that why. And it’s hard because many of us who arrived in B2B marketing via the engineering route love to talk about features and benchmarks – more technical, the better. Of course you need the data sheets, certifications, MLPerf results, etc. – but lead with those and you miss the why.
Clayton Christensen suggested a shorthand for uncovering JTBD:
- “Help me…”
- “Help me avoid…”
- “I need to…”
Some classical JTBD examples:
- Customers hire laundry detergent to help get their clothes clean and fresh.
- Customers hire a kettle to prepare hot beverages.
- Customers hire a television to relax and unwind.
The canonical template of a user story:
As a < type of user >, I want < some goal > so that < some reason >.
That’s the starter. Let’s dig into the main course.
1. Why JTBD Matters More Than Ever
In deep‑tech start‑ups, the gravitational pull toward “feature bingo” is overwhelming. We chase TOPS, token/s, frames/s, memory bandwidth, power consumption, etc., None of these are inherently wrong – they simply aren’t the job. Jobs transcend technology cycles. Customers say things like:
- “I need to cut queue times at security checkpoints by X%.”
- “I need to reduce retail shrink by turning video into actionable alerts.”
- “I need to launch an LLM‑powered chatbot without bankrupting the company via an exorbitant monthly GPU bill.”
These are jobs. If your technology doesn’t map to them, you are solving for x while your market pays for y.
2. Anatomy of a High‑Leverage User Story
A single sentence can guide you to the land of plenty – or bury you in the swamp of features. Let’s dissect.
| Component | What it really captures | Common Type of Failure |
|---|---|---|
| Actor | The buyer or end user | Vague personas (for example defining your users as “users” and your target actors as “customers”) |
| Motivation | The progress they seek | Listing internal metrics (for example stating the customer wants more of your offering) |
| Outcome | The business or personal win | Echoing your feature (for example the business outcome is to “run models faster”) |
| Context | Constraints, triggers, success signals | Missing situational detail (“when?”, “how often?”) |
This framing builds on an evolution from user stories to something called job stories, which aim to provide a richer, context-driven lens into customer intent.
Job stories were introduced by the product team at Intercom and further developed by Alan Klement. The format:
When <situation>, I want to <motivation>, so I can <outcome>.
Unlike traditional user stories, job stories focus on context over personas, reveal triggers and timing that drive product use and clarify underlying motivations and constraints
Example (Bad): “As a data‑center architect, I want higher TOPS so that my AI runs faster.” – Product features masquerading as job.
Example (Good): “When I’m deploying a new store, I want to process 1,000 camera streams per rack so that shrink due to theft drops below 0.5% of revenue by Black Friday.” – Measurable, temporal, business‑anchored.
By anchoring the job in a real-life context, we get insight into not just what customers want, but why they want it – and when they need it most. That insight provides the opportunity for solution differentiation.
3. The Soundview Five‑Step JTBD Discovery Sprint
This is our go-to method at Soundview for helping companies discover and validate the real jobs their customers are hiring them to do:
Step 1: Frame the Market Around Use Cases, Not Technologies
Start by asking: what real-world pain is this technology supposed to relieve? Identify “functional use cases” like fraud prevention, real-time quality control, or intelligent traffic management. Map the value chain — and look for friction. By the way, this step can be quite eye-opening and squirmy leading some to reach the realization of “I don’t why I built this product”.
Step 2: Interview the Market (Not Just Buyers)
Talk to end users, integrators, decision-makers — not just procurement. Use JTBD-style prompts: – “When do you struggle with…” – “What workarounds are you using today?” – “What happens if this problem goes unsolved for 6 months?”
The goal is to surface moments of struggle and progress.
Step 3: Cluster Jobs Into “Job Themes”
Take the interview data and group jobs by outcome type (e.g., cost reduction, risk avoidance, speed to decision). Look for convergence around: – Urgency (how often does the job arise?) – Budget (what’s the cost of not solving it?) – Strategic fit (can you actually deliver?)
Step 4: Translate Into Whole Product Strategy
Now take the job themes and ask: what features, integrations, partners, and services are required to actually deliver on the job? – This is where whole product thinking lives. – It’s also where ecosystem strategy is born — who else needs to be at the table? This is another potential existential point as your company and fellow travelers in your ecosystem may decide to not proceed based on the need for “guaranteed ROI”. There ain’t no guarantees…even in a Statement of Work.
Step 5: Craft and Test Your JTBD Story
Distill it into a clear, testable narrative: > “When <trigger>, I want to <goal>, so I can <impact>.”
Then pressure test it: Does it resonate in a pitch? Can you run a campaign on it? Does your product roadmap align with it?
4. Common JTBD Pitfalls (and How to Avoid Them)
- Fit At First Sight (aka Bright Shiny Customer Syndrome): Believing you have fit because you found one potential customer.
- Fix: Look for repeatable jobs across a segment, not one-off exceptions.
- Feature-First Thinking: Mistaking capabilities for outcomes.
- Fix: Always validate the “so I can…” part.
- Too Much Abstraction: Defining the job as “do inference better” or “enable digital transformation” or “herald a new age of artificial intelligence”.
- Fix: Tie the job to workflows and outcomes (e.g., “flag safety violations in real time to reduce injury claims”).
- Skipping Context: Assuming jobs happen in a vacuum.
- Fix: Document the when/where/who, not just the what.
5. Final Thoughts: JTBD as a Strategic Compass
Jobs to Be Done isn’t just a product discovery tool — it’s a strategic lens. When done right, it connects engineering to customers, marketing to messaging, and roadmap to revenue. It forces clarity.
And in a world drowning in specs, speeds, and feeds — clarity is a competitive weapon.
Let’s stop building for f(x), and start solving for y.
Also ask the question “why would a customer want this?” A little empathy goes a long way.
Philip Lewer
Managing Partner
Soundview Consulting 