How to Define Your Problem Around the Job Your Customer Is Trying to Get Done

Most founders describe their problem from the inside out.

They know what they want to build. They work backward to the problem it solves. What comes out sounds like a product brief. Clean, confident, and describing a customer who does not exist.

The customer is not living inside your product roadmap. They are living inside a situation. Something happened, a need became urgent, and they reached for whatever was closest to make progress. Jobs-to-Be-Done is the lens this piece uses to get at that. It earns its place by putting the customer's situation ahead of your product. It asks a different question than "what does my product do." It asks what the customer is trying to get done, and what they are currently hiring to do it.

That shift changes everything downstream. What you build. How you message it. And the exact moment a customer decides to switch.

TL;DR: You Do Not Have a Product Problem. You Have a Problem-Definition Problem.

A job is the progress a customer is trying to make in a specific situation. Not a demographic. Not a persona. A circumstance. Two people with nothing in common can share the same job if they are in the same situation, and two people who look identical on paper can have completely different jobs depending on what just happened to them.

A job has three dimensions, and most founders only see one:

Functional: the practical task, the output, the outcome the customer is working toward Emotional: how the customer wants to feel when the job is done well (relief, control, confidence, calm) Social: how the customer wants to be seen by others when the job is handled

Four signals indicate your problem is still defined around your solution rather than your customer's job:

• You can describe your product clearly but cannot describe the situation a customer is in when they first need it

• Your problem statement names a type of person, not a moment

• You cannot say what the customer is currently doing instead, or you assume the answer is "nothing"

• Sales conversations stall, messaging does not land, and early users try the product once and do not return, and none of it looks like a problem-definition issue

If any of those describe where you are, this article walks you through finding the situation, naming the full job, mapping what the customer is currently hiring, and writing a job statement you can actually use.

If You Found This Article by Searching for Something Else

Most founders who need this are not searching for "jobs to be done." They are searching for something that feels more immediate.

• Why won't customers buy my product.

• How to define my target customer.

• How to do customer discovery.

• Why does my messaging not resonate.

• How to find product-market fit.

All of those point at the same underlying question. Do you understand the job your customer is trying to get done well enough to know when, and why, they would switch to you? This article shows you how to answer it.

The Problem Is Almost Never Where It Looks Like It Is

Take a founder building scheduling software for therapists. The problem statement reads: therapists waste time on manual booking. The product books appointments automatically. Reasonable. And then the gap shows up everywhere except where the founder is looking.

Sales conversations stall and it looks like a sales problem. Messaging does not resonate and it looks like a marketing problem. Early users try the product once and do not come back and it looks like a retention problem. The founder hires a salesperson, rewrites the landing page, adds an onboarding flow.

Often none of it works. Not because the landing page was weak. Because the problem underneath it was defined from the inside out. The therapist's real situation was never about manual booking. It was the no-show that costs a full session fee, and the discomfort of having to charge for it. The founder built for a task. The customer was living a different problem.

Everything downstream inherits that error. Strong messaging cannot fully compensate for a problem you have defined wrong.

The Job Belongs to a Situation, Not a Person

Start with the moment, not the market.

Clayton Christensen, who built the Jobs-to-Be-Done lens, told the story of a fast-food chain trying to sell more milkshakes. The team studied the people who fit the milkshake-buyer profile and asked what they wanted. Sweeter? Thicker? Chunkier? They made the changes. Sales did not move.

Then someone looked at when the milkshakes were actually selling. Nearly half went out before eight in the morning, to solo commuters who bought nothing else. The job was not dessert. It was a long, boring drive with one free hand and a stomach that would be empty by mid-morning. The milkshake got hired because it was thick enough to last the whole commute through a thin straw, it did not make a mess in the car, and it held off hunger until lunch. Its real competition was a banana, a bagel, a donut, and boredom. None of which the chain had been thinking about.

The buyers had nothing demographically in common. They shared a situation. And you cannot see the competition until you can see the job.

The same move applies to your startup. Before you can name the job, you have to name the situation that produces it. What is happening around the customer when the need appears? What triggered the moment, a deadline, a failure, a transition, a responsibility that just landed? What are they trying to accomplish before the moment passes, and what happens if they do not?

Write it as one sentence. When [specific trigger], [specific person] needs to [specific progress they are trying to make]. If your sentence names a demographic instead of a circumstance, you are not at the job yet. You are still describing who the customer is, when the only thing that predicts whether they buy is what they are trying to do.

The job exists whether or not you build anything.

A Job Has Three Dimensions. Most Founders Build for One.

Take a founder choosing a CRM. The functional job is to track deals so none slip. The emotional job is the confidence that nothing is falling through the cracks between check-ins. The social job is to look organized and on top of the pipeline when an investor or a teammate asks where things stand. Same purchase, three jobs, and the third often decides it.

The functional dimension is the one founders see. The task. The output. The thing that has to get done. It is necessary and it is rarely the whole story.

The emotional dimension is how the customer wants to feel when the job is done well. Relief that it is handled. Confidence going into the meeting. Control over something that felt chaotic. The customer rarely says this part out loud, and it often drives the decision more than the functional task does.

The social dimension is how the customer wants to be seen when the job is handled. The signal it sends to their boss, their client, their team, their peers. For the founder buying the CRM, it is being the one who has clean answers in the room, not the one scrambling through notes when an investor asks about the pipeline.

Look at all three for your customer and ask which one is the strongest driver of urgency. That dimension is where your solution has to deliver most clearly. Build for the functional job and ignore the emotional and social ones, and you will lose to a worse product that makes the customer feel the way they want to feel.

Find What the Customer Is Already Hiring

Customers are already doing something about the job. If they were not, the job would not be worth building against.

Whatever they are doing now is your real competition. Not the other startup in your category. The spreadsheet. The intern. The agency. The duct-taped stack of three tools. The decision to live with it and do nothing. List every option the customer uses or has tried, including the workarounds and including doing nothing.

Picture an operations lead running the company's billing out of a shared spreadsheet. That spreadsheet is the current hire. It costs a few hours every month and the occasional formula error nobody catches until a customer complains. It works well enough that switching to real software keeps sliding down the list.

Then take their primary current hire and get specific. What does it cost them in time, money, effort, or reliability? Where does it fail them, at what exact moment does it break down? And here is the question founders skip: what do they tolerate about the current hire because switching feels harder than staying?

That last one is the whole game. The gap between what a customer tolerates and what they would actually prefer is the space your solution has to fill. Not by being slightly better. By being meaningfully better at the specific moment the current hire fails. A customer paying a real cost can still stay with their workaround for years, because switching to you carries its own cost: a new tool to learn, data to move, a habit to break. The current hire being bad is not enough. You have to be better exactly where it breaks.

One question pulls most of this out of a customer in a single sitting. Ask them: tell me about the last time you tried to solve this problem. Not what they want. Not what they imagine they would do. The last actual time. The answer reconstructs the situation, the current hire, and the moment it failed, in their own words.

The Switch Moment Is the One You Have to Be Present For

Customers do not switch because a better solution exists. They switch when something breaks their tolerance for the current hire.

That break is the switch moment. It is the point of highest urgency, and it is the moment your solution has to be in front of them. A better product that shows up a month after the switch moment loses to a worse product that was there when the tolerance snapped.

For the operations lead and the billing spreadsheet, the switch moment is not a sales call. It is the month a formula error bills a top customer twice, the customer is angry, and the founder wants to know how it happened. That is the morning the spreadsheet gets fired. A billing tool that was already in the room gets hired. A better tool that shows up the following month hears that the problem is handled.

So ask what would have to happen for your customer to fire their current hire today. Has that moment already happened for anyone you have spoken to, and what did they do when it did? What is the specific trigger that moves someone from tolerating the current hire to actively looking for something better?

Then ask whether that trigger is predictable or not. If it is predictable, a renewal date, a quarter close, a new hire's first week, you can position around it and be present on schedule. If it is unpredictable, your acquisition has to be always-on, or you have to ride a partner who is already in the room when the trigger hits. The answer changes how you spend every marketing dollar.

Write the Job Statement

A job statement is not a problem description. It describes the progress a customer is trying to make in a specific situation, including what they are currently hiring and where it falls short. It follows a structure:

When [specific situation or trigger], a [specific person] is trying to [functional job]. They want to feel [emotional dimension] and be seen as [social dimension]. They are currently hiring [current solution], but it fails them when [specific failure point]. They would switch if [specific condition for switching].

Write yours. Then run it through one test.

Does the statement describe the customer's situation, or does it describe the gap your product fills? If your product appears in it, you have written a product brief again. Rewrite it until the product is invisible and only the customer's situation remains. The job exists whether or not you build anything. The statement should read that way.

The One Sentence That Tells You Where You Stand

A founder who has done this work can complete one sentence with specifics:

The job my customer is trying to get done is this specific job in this specific situation, their current hire fails them at this specific point, and the switch moment I need to be present for is this specific trigger.

A founder who is still working from the inside out will reach for general words. "People need a better way to do this." "Everyone struggles with this." The vagueness is the diagnosis. Specific and observed beats broad and inferred every time.

If you can fill that sentence with a real situation, a real failure point, and a real switch moment, you have a problem definition you can build on. If you cannot, you have found a more specific question to answer, which customer, which moment, which trigger. Either outcome moves you forward.

Jobs-to-Be-Done and Your Problem Clarity

In the Startup Readiness Framework, Problem Clarity evaluates whether a founder has moved beyond a solution-shaped problem statement to one grounded in the customer's actual situation. A weak problem signal is one of the most common flags in early assessments. Not because founders have not thought about the problem, but because they have described it through the product they already want to build.

A founder who can describe their product has demonstrated conviction. A founder who can name the situation a customer is in, the job they are trying to get done, and the moment their current hire fails has demonstrated clarity.

If your Problem Clarity flagged a weak problem signal, start here. Name the situation. Name the full job across all three dimensions. Map the current hire and where it breaks. Find the switch moment. Then write a job statement your product cannot hide inside.

Problem Clarity is one of the six pillars in the Startup Readiness Framework. If your problem is grounded in a real job, the next question is whether the rest of your startup is as ready as your problem definition.

The Startup Readiness Assessment gives you a full-system diagnostic across all six pillars in under twenty minutes.

Take your Startup Readiness Score free today at startupreadinessscore.com →

Published

By Dr. Shaun P. Digan

Original Publication Date: June 4, 2026

Last Updated: June 4, 2026

About the Author

Dr. Shaun P. Digan is the founder of Startup.Ready and the creator of the Startup Readiness Framework, a research-based system for evaluating and validating early-stage startups before launch and early growth. He holds a PhD in Entrepreneurship from the University of Louisville and has spent over 15 years teaching, advising, and consulting with founders on startup strategy, validation, and growth.

In his writing, including The Foundations of Innovation, he focuses on how founders can make better decisions by improving clarity, alignment, and readiness before scaling.