How to run jobs to be done research with enterprise customers

Jobs to be done research asks what progress a customer was trying to make when they hired a product. With enterprise customers an organisation does the hiring, so the study has to capture two things separately: the job the organisation hired the product for, and the job each role inside it needs done. Then you merge them without averaging them away.

What jobs to be done research looks like inside an enterprise account

Jobs to be done research inside an enterprise account follows the same logic as with a single consumer, applied to a purchase that several people shape over months. You still write job statements, still map the forces behind the switch and still look at functional, emotional and social layers. Each of those steps changes once an organisation is the customer.

A job statement has three parts: the circumstance, the progress the customer wants, and the outcome that progress allows. "When a quarter closes, I want reconciliations done in one place, so I can sign off without chasing three teams." The four forces explain why a switch happens or stalls: the push of the current situation, the pull of the new option, the habit of the present way and the anxiety about the new one.

Three things change in an enterprise account. The switch takes months and runs through budget cycles and contract terms. Several people shape it, and each has a job of their own. Habit stops being a personal routine and becomes the integrations, reports and approvals built around the old tool.

Who counts as a switcher in a B2B account

A switcher in a B2B account is an account that recently adopted, replaced or abandoned a product in your category, together with the people inside it who drove the change or lived with it. Recruit by the switch event first and by person second, because the event is what dates the story.

Pull switch events from your CRM and onboarding records:

• New accounts that replaced another tool
• Accounts that churned
• Accounts that consolidated several tools into one
• Accounts that extended the product to a new business unit
• Accounts that evaluated a change and stayed where they were

Keep the last group in the sample. Their job was real, and the status quo won, which tells you how strong habit and anxiety were for that kind of account.

Interview more than one role per account: the person who drove the change, the person who signed, and someone who uses the product every day. Scope the study by switch type. Cover each distinct type of switch until new interviews of that type stop adding forces you have not heard.

Run the switch timeline at the level of the organisation

The switch timeline walks each interviewee from the first thought of change to the first value from the new product. In an enterprise account, that runs through the trigger, a period of passive looking, the moment someone took ownership, the shortlist, the decision and the first weeks of use.

Ask for dated anchors. Organisational memory attaches to events, such as a budget cycle, a reorganisation, a failed audit or a new leader. "Was this before or after the new CFO joined?" places a story that "When did you start looking?" leaves vague.

The four forces take a different shape when an organisation switches:

Force	For one consumer	Inside an enterprise account
Push	Frustration with the current way	A mandate, an incident, a failed audit or a new leader
Pull	The appeal of the new option	A peer company's approach, an internal pilot, a demo that convinced the steering group
Habit	A personal routine	Integrations, reports and approvals built on the old tool, and the contract term
Anxiety	Worry that the new option will disappoint	Migration risk, and the risk to the sponsor's standing if the rollout fails

Follow up on the first vague answer. "We needed something more scalable" is a placeholder for a job. "What happened the week you decided that?" gets to the circumstance behind it. For wording that does this, see these open questions that get past the first answer.

Separate the organisation's job from each role's job

Write one job statement for the organisation and one for each role you interviewed. The CFO's job, the operations lead's job and the analyst's job can all be true at once, and they can conflict. A single statement for the account hides that conflict.

The table below is an illustrative case: a document verification product at a large consumer lender, a composite rather than a real company.

Level	Job statement	What success looks like	What would make them leave
Organisation	When regulators tighten affordability checks, we want every application verified the same way, so we pass audit without slowing approvals	A clean audit with approval times held	A failed audit, or approvals slowing
Economic buyer (head of credit risk)	When the board asks about lending risk, I want one view of verification quality, so I can answer on the spot	Board questions answered from one report	Numbers she cannot defend
Day-to-day user (underwriter)	When an application is missing documents, I want to see what is missing in one place, so I can decide without chasing the applicant	Fewer applications parked for documents	More manual checks than before
IT or security	When a new vendor touches customer data, I want access reviewed once, so I am not re-approving it every quarter	One documented review	Repeated reviews or an incident

Keep the functional, emotional and social layers for each role. The social job, how a person wants to look to their boss or peers, can be what moved the purchase: the head of credit risk wanted to answer the board with confidence, and that sits behind her functional job.

Merge jobs across roles and business units

Merge jobs by clustering them, and never average them into one statement. An averaged job such as "teams want better visibility" fits every account and guides no decision. A cluster keeps its label tied to the quotes and roles behind it, so a product team can see whose job it is.

Work in this order:

1. Code each interview by switch moment and by force.
2. Group job statements that share a circumstance and a desired outcome, across accounts. An affinity diagram works for this.
3. Label each cluster and keep the quotes and roles behind it.
4. Mark which jobs appear across business units and which belong to one.

A job shared across business units points to a platform decision. A job unique to one unit points to a segment, a configuration or a separate offer. Keep the two kinds apart in the readout.

Pulse groups interview responses into themes with quotes traced to the transcript they came from, and keeps every study in a searchable insight repository. A job statement can be checked against what was said, and found again when next quarter's brief starts.

Hand the product team a jobs map for each segment: the roles, their job statements, the forces behind each switch and a representative quote for every job.

Where jobs to be done research goes wrong in enterprise accounts

Each failure below treats one voice or one moment as the whole account. Check your plan against them before fieldwork starts.

Interviewing only the champion

The champion drove the switch, so their job dominates the story. Interviewed alone, the account's job reads as the champion's career goal. Add the person who signed and a daily user.

Writing jobs about your features

"I want automated document checks" describes your product. "I want to decide on an application without chasing the applicant" describes the customer's progress, and it survives a change in how you build the product.

Treating a procurement requirement as a job

A security review or a preferred-vendor rule shapes how the job gets done. Record it as a constraint on the switch, beside the anxiety force, and keep it out of the job statements.

Letting one strategic account stand in for the segment

Your largest account gets the most attention, and its job can end up written as the segment's. Check each cluster for how many accounts it draws on before it reaches a roadmap.

Running it once

Jobs shift after reorganisations, new mandates and new leaders. Tie the study to a repeatable brief and rerun it when one of those events hits a segment. Pulse runs AI-moderated voice interviews that each role takes by link, and the last study's findings sit in the repository when the new brief starts. You can see a study run on your own accounts.

Questions readers ask

What is jobs to be done theory?

Jobs to be done theory holds that customers hire a product to make progress in a specific circumstance, and fire it when something serves that progress better. It moves the unit of analysis from the customer's profile to the situation and the outcome they want, which makes it useful for explaining why people switch.

What does a jobs to be done deliverable look like?

A useful deliverable is a jobs map for each segment: the job statements for the organisation and each role, the four forces behind the switch, and a representative quote for every job with its source interview. Product teams use it to see which jobs are underserved, and for which role.

How is jobs to be done research different from personas?

Personas describe who a customer is. Jobs describe the progress they are trying to make in a given circumstance. Enterprise teams use both: personas to keep the roles on a buying committee distinct, and jobs to explain what each role hires the product for.

How does jobs to be done theory apply to product development?

It tells a product team which jobs are underserved and for which role, so the roadmap targets progress customers are failing to make. In enterprise products, it also separates jobs shared across business units, which suit platform work, from jobs unique to one unit, which suit configuration or a separate offer.

How many enterprise accounts should a jobs to be done study cover?

No fixed number fits every study. Cover each distinct type of switch, such as replacement, consolidation and churn, and keep interviewing within a type until new accounts stop adding forces or jobs you have not heard. A study across several business units needs more accounts than one focused on a single segment.