Finding the right problem to solve using jobs to be done

Executive overview

Most founders build a product first and then ask the market if it wants it. Jobs to be done (JTBD) inverts this: understand the problem the market is trying to solve before writing a line of code.

The framework gives founders a language for describing customer problems that is independent of any solution, product, or technology. This makes the insight durable — the same job applies whether the tool is a Rolodex, a spreadsheet, or a SaaS product.

Removing your solution from the conversation lets you see opportunities you would otherwise overlook.

What jobs to be done is

• A framework for understanding what problems people are trying to solve, without referencing any solution.
• Synonymous with "problems to be solved" — the job is the goal, not the task.
• Jobs are stable over time even as technology changes; describe them in technology-agnostic language.
• Test: would this job description have been true 20–30 years ago? If not, reword it.
• Example: "record contact information" is a stable job; "click a button and create a database record" is not.

Pre-product: scoping your innovation domain

• Define the who: list all actors and stakeholders, then narrow to the person who receives the most value.
• Define the what: list all problems in the domain, then narrow to one or three to focus on.
• Together, who + what defines your innovation domain before you touch a product.

Pre-product: interviewing to map the job

Conduct open interviews, probing along three lines:

1. Process — how did you get started? What did you do before that? After that? (Builds a job map: beginning, middle, end.)
2. Outcomes — what are you trying to achieve? What's the hardest part? What are the pain points?
3. Circumstances — under what conditions does this get easier or harder? (E.g., tech vs. manufacturing, bootstrapped vs. funded.)

• The goal is a job map: a sequence of sub-goals (not tasks) that describes how the job gets done.
• Anywhere you see a Google Sheet or spreadsheet, that is a signal a stable job exists and may be underserved.

Switch interviews: learning from existing customers

• Use when you have a product with at least some customers and want to understand what to build next.
• Reverse engineer the customer's journey back to the underlying job, independent of your product.
• Ask: what brought you to this solution? What were you trying to do before that? Keep going back until you reach the root problem.
• You are not mapping their purchase journey — you want to know what problem they were solving.
• Once you surface the root job, forward engineer: map the process and pain points for that job without your solution in the room.
• Then return to your product with that cleaner view of what to build.

Switch interview example: marketing dashboard

Rob described switching from a Google Sheet to Dash This for tracking marketing metrics. The interview surfaced:

• The immediate driver: automation (eliminating manual data entry a few times a week).
• A deeper need: confidence — knowing the numbers are accurate and current.
• A further insight: larger, interactive graphs let him spot trends and anomalies he would otherwise miss.

Across multiple interviews, recurring themes like "confidence" point toward the real job to solve — not the feature request.