# How to find jobs to be done in customer feedback

> A job to be done is the progress a customer is trying to make in a situation. To find jobs in feedback, read past the requested solution, rewrite each request as a job statement with situation, motivation and outcome, then group the statements that describe the same progress.

Source: https://escutaproduto.com/resources/jobs-to-be-done-from-feedback
Last updated: 2026-10-11

## What is a job to be done?

A job to be done is the progress a person is trying to make in a specific situation. People do not buy a tool for its features. They hire it to get a job finished, such as sending a weekly update without rewriting the same table or finding out why a customer left. The feature they ask for is only one route to that progress.

Customer feedback is full of requested solutions: "add a button," "let me filter by date," "support a spreadsheet import." Each one hides a job underneath. Finding the job lets you solve it in the best way, which may not be the one the customer proposed.

## How do you rewrite a request as a job statement?

Use a simple format: "When [situation], I want to [motivation], so I can [outcome]." Each part does one job:

- **Situation**: the moment or context that triggers the need.
- **Motivation**: the progress the person is trying to make right now.
- **Outcome**: what they get once it works, which is the reason it matters.

Take a request such as "Add CSV export." Asking what it is for, the answer is usually something like a team that reviews feedback in a spreadsheet every Monday. The job statement reads: "When I prepare the Monday product review, I want to work with the full feedback list in my own spreadsheet, so I can spot patterns before the meeting." Now the job is visible, and other ways of meeting it, such as a dashboard view or a weekly digest, are easier to consider.

Write the statement in the customer's words where you can. Your own jargon hides the job.

## Which words signal a solution instead of a job?

Solutions use verbs for interface elements: add, show, put, let me click, support, integrate. Jobs use verbs for progress: finish, check, prove, send, decide, avoid. If the request names a button, a field, a menu or a tool, you are looking at a solution.

A quick test: if the request still makes sense after you swap out every product noun, it is probably a job. "I need to see which bugs happen on checkout before my release" survives that test. "Add a checkbox to the bug form" does not.

## A worked example: five requests, one job

Take five requests from one month, each phrased as a solution:

| Request | Stated solution | Job behind it |
| --- | --- | --- |
| Add a date filter | Filter the inbox by date | Review only last week's feedback in the team meeting |
| Export to spreadsheet | Download a CSV | Share feedback with a colleague who does not log in |
| Show a chart of counts | Add a chart | Tell whether volume is rising after a release |
| Email me new bugs | Email alerts | Learn about a serious bug before a customer tweets it |
| Let me star items | Star feature | Mark the few items to revisit in the next planning session |

The five requests are five solutions. Read as jobs, several share one underlying progress: the founder wants to notice a change in feedback and act on it before the next meeting. The date filter, the chart and the star all serve that. The most useful response may be a single view that answers the question directly, rather than four small features. For example, a weekly summary in the inbox plus the existing filters may cover most of the need.

Not all five are the same job. Export serves a sharing job for someone outside the team, which is a separate progress. Keeping them apart stops you from building one feature that half-solves two problems.

## How do you check the job with the customer?

Ask about the last time the problem happened. Good questions focus on the past, not on hypothetical future features:

1. What were you trying to get done that day?
2. What did you do instead, and what did it cost you in time or confidence?
3. What would the finished version look like for you?

Stop when you can write the job statement and the customer agrees with it. If they add a detail that changes the outcome, rewrite the statement and check it again. One well-checked job is more useful than three guesses.

The [problem behind a feature request guide](/resources/problem-behind-feature-request) covers the same method from the angle of asking why, and the [Kano model guide](/resources/kano-model-feature-requests) helps you judge which jobs customers expect versus which ones delight them.

## How do jobs change the backlog?

Group feedback by job, not by feature name. Each group becomes one line in the backlog, with the number of distinct customers who share it. Several solutions can then compete to serve one job. The team can pick the smallest one that works, test it, and see whether the job gets easier.

Jobs also explain why some requests do not belong on the roadmap. A request whose job no one else shares is a preference, not a pattern. Note it, and move on. The [deduplicating feature requests guide](/resources/deduplicate-feature-requests) shows how to merge wording variants into one canonical request before you count jobs.

## Where Escuta Produto keeps the job notes

Escuta Produto stores each request as a feedback item with its message, email and page URL. Internal notes are private to your team, so write the job statement there, along with the number of distinct customers who share it. Filter by type to see only ideas, then search the inbox for the situation words, such as "release" or "report," to find related requests.

Use the status to show what happened to each job: planned when you commit to a solution, in progress while you build it, and done when customers who asked can see the change. The [widget docs](/docs/widget) explain where requests come from, and the [spreadsheet analysis guide](/resources/analyze-feedback-spreadsheet) shows how to group the export by a job column you add yourself.

## Frequently asked questions

### What is a job to be done in customer feedback?

It is the progress a customer is trying to make in a specific situation. Feature requests are usually one proposed route to that progress, so finding the job lets you choose the best solution rather than the first one suggested.

### How do you write a job statement?

Use the form: when a situation happens, I want to make a particular progress, so I can reach an outcome. Keep the wording close to the customer's own words, and check the statement with them before you group it with other feedback.

### How many customers do you need to share a job before acting on it?

There is no fixed count, but look for several distinct customers describing the same progress in similar words. One customer with a clear, recurring job may still be worth a small test, especially if it blocks a core task.

### Can you find jobs in feedback you already have?

Yes. Export the feedback, read each request, and rewrite it as a job statement in a new column. Group the rows that share a job, then count distinct customers within each group to see which jobs come up most.