Most feature requests tell you what a customer wants, not why they want it. You hear "add dark mode" or "let me export to CSV," and you build it, but the underlying problem often stays unsolved. That gap is exactly what jobs to be done user research is built to close: it pushes you past the surface ask and toward the real progress a customer is trying to make.
Jobs to Be Done (JTBD) is a framework for figuring out what job a customer "hires" your product to do. Instead of segmenting users by demographics, you look at the circumstances that trigger someone to seek a solution, the outcome they're chasing, and the alternatives they're currently settling for. Applied well, product strategy jobs to be done becomes a lens for deciding which features actually move the needle, not just which ones get the most upvotes.
In this article, you'll get a practical breakdown of the JTBD framework, how to run interviews that surface real jobs, and how to translate those findings into a roadmap your users understand and trust.
Most product teams collect feedback the same way: they log requests, count votes, and build whatever climbs to the top of the list. That approach feels data-driven, but it optimizes for loud requests instead of real problems. Jobs to be done user research flips the process by asking why a customer wanted that feature in the first place. When you understand the job, you often find a better, cheaper way to get the customer that outcome than the exact feature they asked for.
Clayton Christensen popularized JTBD with his now-famous milkshake study for a fast-food chain. Researchers found that a huge share of milkshakes were sold before 8 a.m., to solitary commuters who weren't hungry yet but wanted something to make a boring drive more interesting and keep them full until lunch. Competing against that job wasn't other milkshakes; it was bananas, bagels, and boredom. Harvard Business School has documented the case in detail as a teaching example of how reframing customer needs around outcomes rather than product categories changes what you build. That single reframe is the core promise of JTBD: stop asking what customers want and start asking what progress they're trying to make.
Traditional segmentation groups people by who they are: age, job title, company size, industry. But two people with identical titles at similar companies can be trying to solve completely different problems, while two people who look nothing like each other on paper might be hiring your product for the exact same job. Product strategy jobs to be done work sidesteps this by focusing on circumstance instead of category. A solo freelancer and a 200-person product team might both use a feedback tool to "prove to leadership that we're building the right things," even though their org charts look nothing alike.
If you don't know the job, every feature request looks equally important, and none of them are.
Once you separate the job from the feature request, you get more options for solving it. Take a common one in feedback tools: users ask for "a way to filter feedback by customer segment." The literal request is a filter. The job underneath it might be "help me show my boss that our biggest accounts want this feature before I commit engineering time." Once you see that job, you have several paths, and the filter is just one of them:
Each option solves the underlying job. Only one matches the literal ask. Teams that skip the JTBD step usually ship the first option and move on, without ever testing whether it solved the real problem.
Skipping JTBD research doesn't save time, it just moves the cost downstream. You end up shipping features that get low adoption, then spend more cycles figuring out why usage didn't follow the vote count. Teams that invest in job-based research upfront tend to see the opposite pattern: fewer features shipped overall, but higher adoption per feature, because each one is aimed at a real, validated outcome instead of a guess dressed up as a request.
| Approach | What you build for | Typical outcome |
|---|---|---|
| Feature request tally | The most-voted literal ask | High output, uneven adoption |
| Persona-based planning | A demographic profile | Broad appeal, unclear priority |
| Jobs to be done research | The underlying progress sought | Fewer features, higher adoption |
This is also where JTBD earns its keep in strategy conversations, not just research interviews. When a roadmap decision comes down to two competing features, "which one serves the bigger job" is a much sharper filter than "which one has more upvotes." It gives product managers language to defend a decision to stakeholders, and it gives support and sales teams a shared vocabulary for why a request was reprioritized instead of ignored. That shared vocabulary is often the difference between a roadmap people trust and one they quietly stop believing in.
Uncovering a real job takes more than a survey question asking "what features do you want." You need to interview people who recently bought, switched to, or churned from a solution, and walk them backward through the decision. This is often called a switch interview, and it's the core research method behind Jobs to Be Done user research: you're reconstructing the timeline of events that led someone to go looking for something new.
Start every interview with a specific, recent event rather than a general opinion. Ask when the customer first signed up for your product, then work backward to the moment they realized their old approach wasn't cutting it anymore. That moment, sometimes called the "struggling moment," is where the job actually gets defined. A good interview usually covers four stages:
The job isn't what someone says they want, it's the story of what pushed them to act.
Every switch involves four forces: the push of the old situation, the pull of the new solution, the anxiety about change, and the habit of sticking with what's familiar. Structuring questions around these forces gets you much closer to the job than asking "what would you like this tool to do." Try prompts like these in your next round of interviews:
- Walk me through the day you decided the old way wasn't working anymore.
- What were you using instead, and what did that cost you (time, money, credibility)?
- What almost kept you from switching?
- If this product disappeared tomorrow, what would you do instead?
Recent switchers and recent churners both matter here, and teams often only interview the former. Someone who canceled tells you exactly where the job went unmet, which is data you can't get from a satisfaction survey. Aim for five to eight interviews per segment before you start seeing repeated patterns; fewer than that and you risk building a strategy around one person's edge case.
Interviews aren't the only source. Support tickets, churn survey answers, and the free-text comments sitting in your feedback portal already contain job language, you just have to read past the literal request. When a Koala Feedback customer scans comments on a popular request, the phrasing people use to justify their vote ('so I can show leadership traction,' 'because I'm tracking this for a client deadline') is often a better clue to the underlying job than the request title itself.
Once you've pulled the job out of your interviews, you need to write it down in a way the rest of the team can actually use. A JTBD statement isn't a feature description and it isn't a persona blurb. It's a compact sentence that captures the situation someone is in, the progress they're trying to make, and what "better" looks like to them. Get this format right and it becomes a filter you can run every roadmap decision through.
Most job statements follow a simple structure: situation, motivation, expected outcome. Skip any of the three and the statement collapses into either a feature request or a vague mission statement. Here's the template teams at Koala Feedback customers often start with:
When [situation],
I want to [motivation],
so I can [expected outcome].
Apply it to the earlier filtering example and you get something like: "When I'm about to ask engineering for time on a feature, I want to show which accounts are asking for it, so I can get buy-in without a lengthy debate." Notice there's no mention of filters, dropdowns, or dashboards. The jobs to be done user research you already ran is what fills in the situation and outcome; the statement just packages it cleanly.
A job statement should survive even if the product it describes gets deleted tomorrow.
The fastest way to ruin a job statement is to smuggle a feature into it. "I want a CSV export so I can share data with my boss" is a feature statement wearing a JTBD costume. Strip out the how and you're left with the real job: "so I can show my boss that our feedback backs a decision." That distinction matters because a solution-free statement stays valid for years, while a feature-specific one expires the moment you ship something else that gets the same result.
Before you circulate a job statement to your team, run it through this checklist:
Once written, the statement belongs on the roadmap document itself, next to the feature it justifies, not buried in a research deck nobody reopens. Teams practicing product strategy jobs to be done typically keep a running list of five to ten core job statements per product area, then map every new request against that list before it enters the backlog. If a request doesn't map to an existing job, that's often a sign you've found a new job worth interviewing for, not a reason to ignore the request outright.
Teams often stack JTBD on top of personas, user stories, and journey maps without realizing the four tools answer different questions. Jobs to be done user research asks why someone acts, personas describe who they are, user stories describe what they do in the product, and journey maps describe when they do it. Confusing these leads to research decks that pile up documentation without ever clarifying priority.
A persona bundles demographic and behavioral traits into a fictional profile: "Marketing Mary, 34, manages a team of five." That profile can be useful for tone and messaging, but it says nothing about the circumstance that pushes Mary to buy a feedback tool today versus six months ago. Two people who look nothing like Mary on paper might be hiring your product for the identical job, while two people who match her profile exactly might be solving completely different problems. Product strategy jobs to be done work treats the persona as background context at best, never as the basis for a roadmap decision.
User stories follow the familiar format: "As a [user], I want [feature], so that [benefit]." That structure looks close to a job statement, but the benefit clause in a user story is usually a shortcut back to the feature, not a validated outcome pulled from an interview. A user story assumes you already know the solution; a job statement is what you write before you know the solution. Treat user stories as the implementation layer that sits downstream of a job, not as a substitute for the research.
A user story tells the team what to build next sprint. A job statement tells the team why anything is worth building at all.
Journey maps chart the steps a customer takes across touchpoints, from first visiting your site to renewing a contract. They're excellent for spotting friction and gaps in experience, but they describe the sequence of a job, not its cause. A journey map might show that users abandon a signup flow at step three; JTBD tells you why they started that flow in the first place and what "struggling moment" pushed them there. Used together, the job explains the motivation and the journey map explains the mechanics.
| Tool | Answers | Best used for | Risk if used alone |
|---|---|---|---|
| Persona | Who is the user | Messaging, tone | Masks real motivation behind a demographic label |
| User story | What to build | Sprint planning | Locks in a solution before the job is validated |
| Journey map | When friction occurs | Mapping touchpoints | Explains sequence, not underlying cause |
| JTBD statement | Why the user acts | Prioritization, roadmap decisions | Needs the other three to become actionable |
None of these tools replace each other. A mature research practice runs job interviews first, writes the job statement, then lets that statement inform which personas matter and which journey steps deserve attention next.
Abstract explanations only go so far. Seeing how the same framework plays out in different product categories makes it easier to spot jobs in your own backlog. Below are examples pulled from common product types, each showing the surface request next to the job actually driving it.
Consider a subscription video service. Customers don't sign up because they want "more content," even though that's the language they use in surveys. The job is closer to "help me unwind after a long day without having to decide what to watch." That's why autoplay and curated rows outperform raw catalog size in keeping people subscribed. A team chasing the literal request would keep licensing more titles; a team chasing the job builds better defaults and recommendation logic instead.
Take a project management app where users ask for "more fields on the task card." Dig into a few interviews and the real job often turns out to be "help me prove to my manager that my team is on track without a status meeting." That reframes the fix entirely, from a data-entry feature to a shareable summary view. Notice the pattern: the requested feature adds work for the user, while the job-based fix removes it.
The best JTBD fixes usually remove a step the customer was dreading, not add one they asked for.
In a feedback platform like Koala Feedback, a customer might submit "let me merge duplicate posts." The literal fix is a merge button. But jobs to be done user research into that request often surfaces something bigger: "help me trust that the vote count on this idea reflects real demand, not five people posting the same thing five different ways." That job might be solved with automatic duplicate detection instead of a manual merge tool, which saves the admin from doing the work at all.
| Product type | Surface request | Underlying job |
|---|---|---|
| Streaming service | "Add more titles" | Help me decide what to watch without effort |
| Project management tool | "Add more task fields" | Prove progress without a status meeting |
| Feedback platform | "Add a merge button" | Trust that vote counts reflect real demand |
| E-commerce site | "Add a wishlist" | Remember what I wanted without re-searching |
| Accounting software | "Add more report templates" | Show my accountant everything's in order before tax season |
Retail sites hear "add a wishlist" constantly, and most build exactly that: a saved-items page. The job behind it is frequently "help me remember what I wanted without having to search for it again next payday." Some retailers solve that better with price-drop alerts on browsing history than with a dedicated wishlist page, because the job is about memory and timing, not storage.
Each of these examples shares a structure worth noticing: the request names a feature, the job names a struggle, and the best solution rarely matches the feature word for word. That gap is where product strategy jobs to be done work pays for itself.
Even teams that understand the theory trip over the same handful of mistakes once they try to run jobs to be done user research in practice. Most of these errors don't come from a lack of effort, they come from shortcuts that feel efficient in the moment but quietly undo the whole exercise. Knowing what they look like ahead of time saves you from relearning the lesson the hard way.
Writing a job statement once and pinning it to a slide feels like closure, but jobs shift as the market, competitors, and customer expectations change. A job statement written two years ago might still describe last year's struggle, not this year's. Revisit your core statements every few quarters, especially after a wave of churn or a new competitor entering the space, and update them the same way you'd revise a persona that's gone stale.
Teams often write statements like "help me manage my project" or "help me collect feedback," which describe a product category, not a specific struggle. A real job names the moment and the stakes: "help me prove to my manager my team is on track before Friday's meeting" tells you far more than "help me manage my project." If your statement could apply to every competitor in your space without changes, it's too broad to guide a roadmap decision.
A job statement that fits every competitor's product fits none of your decisions.
It's tempting to only interview happy customers, since they're easier to schedule and nicer to talk to. But the people who evaluated your product and picked a competitor, or churned after a few months, hold information you can't get anywhere else. Their story usually reveals a force (anxiety, habit, or a missed feature) that your current customers never had to confront. Skip this group and your product strategy jobs to be done work ends up biased toward people the product already serves well.
A single vocal customer, especially a large account, can pull a whole roadmap toward their specific situation, which may or may not represent a broader job. Cross-check any single interview against your five to eight person sample before treating it as the job. A quick way to catch this drift:
Once teams build a tidy list of job statements, there's a pull to squeeze every new request into one of them rather than admit a new job has emerged. If a request keeps resisting classification, that resistance is itself a signal, not a problem to force away.
JTBD only pays off when it becomes a habit, not a one-time research sprint. Run switch interviews on a regular cadence, write job statements in plain language, and check every new feature request against the list before it hits your backlog. That routine is what separates jobs to be done user research from a framework you read about once and never touch again.
Getting this right doesn't require a research team or a new tool stack. It requires a place to capture the requests, tag them against the jobs they actually serve, and show your team why a decision got made. That's the gap Koala Feedback is built to close: collect feedback, organize it by the job behind it, and share a roadmap that reflects real progress instead of vote counts. Start applying JTBD to your next prioritization meeting, and watch how much faster disagreements resolve once everyone agrees on the job.
Start today and have your feedback portal up and running in minutes.