Defining the Customer's Core Functional Job: What Is a Product Manager Without This Skill?
This skill teaches you how to identify and articulate the single functional job your customer is trying to get done, using precise job statement syntax that separates the task from any product or solution.
Start by observing what customers are actually trying to achieve, independent of your product. Write the job as a verb plus object plus contextual clarifier, such as 'manage personal finances over time.' Strip away solutions, technologies, and emotional language. The result is a stable, solution-agnostic statement that anchors all downstream JTBD work.
Outcome: You produce a single, stable, solution-agnostic job statement that serves as the anchor for job mapping, outcome statements, and opportunity scoring across your entire product strategy.
Prerequisites
- Basic understanding of the Jobs-to-be-Done (JTBD) Framework and its vocabulary
- Access to qualitative customer data such as interview transcripts, support tickets, or behavioral observations
- Familiarity with the difference between functional, emotional, and social jobs
Overview
Every product exists because a customer is trying to get something done. The core functional job is the underlying task or goal that persists regardless of which product, service, or workaround the customer chooses. When you ask what is a product manager's most foundational responsibility in the Jobs-to-be-Done (JTBD) Framework, the answer is this: defining the core functional job with enough precision that every team member, from engineering to marketing, shares the same understanding of what the customer is trying to accomplish. Without that shared definition, outcome statements drift, job maps fracture, and opportunity scoring loses its anchor.
Defining the core functional job is deceptively difficult. Teams routinely confuse the job with a solution ('use a spreadsheet to track expenses'), an activity step ('enter receipt data'), or an emotional aspiration ('feel financially secure'). A well-formed functional job sits between those layers. It describes the objective the customer would still need to accomplish even if your product, your category, and your entire industry disappeared tomorrow. The classic example is 'manage personal finances over time,' not 'use budgeting software' or 'feel confident about money.'
The artifact you produce is a single sentence following a precise syntactic pattern: action verb plus object of the action plus contextual clarifier. This sentence becomes the root node of your job map, the filter for which outcome statements belong in scope, and the lens through which you evaluate competitive alternatives. A core functional job defined at the right altitude of abstraction is stable for years or even decades, giving your team a durable strategic foundation rather than a moving target tied to market trends or feature requests.
This skill sits at the very beginning of the JTBD workflow. You will use its output directly when creating job maps, writing desired outcome statements, and eventually identifying underserved outcome opportunities. Getting the job statement wrong at this stage cascades errors through every downstream artifact, which is why experienced practitioners spend more time here than anywhere else in the framework.
How It Works
The core functional job works as an abstraction layer between what customers do (observable behavior) and why they do it (motivations and emotions). By stripping away solutions and emotional language, you isolate the task itself, which is the most stable element in the customer's world. Products come and go, emotional contexts shift with demographics and culture, but the functional job endures. People needed to 'manage personal finances over time' long before spreadsheets existed, and they will need to do it long after today's fintech apps are obsolete.
The syntax, action verb plus object plus contextual clarifier, is not arbitrary. Each component does specific analytical work. The action verb anchors the statement to an observable, measurable activity. Verbs like 'manage,' 'transport,' 'acquire,' or 'maintain' describe what the customer is doing at a functional level. Verbs like 'feel,' 'enjoy,' or 'avoid' signal that you have slipped into emotional territory. The object of the action identifies what is being acted upon: finances, goods, knowledge, health. The contextual clarifier scopes the job to the relevant situation without over-narrowing it. 'Over time' is different from 'on a daily basis,' and both differ from 'during a cross-country move.'
The most common failure mode is setting the altitude of abstraction incorrectly. Too high and the job becomes meaningless ('live a good life'). Too low and you have described a step rather than a job ('enter receipt data into a ledger'). The right altitude passes two tests. First, the job is stable across solutions: would this job exist if no current product existed? Second, the job is specific enough to generate distinct outcome statements: can you list 10-15 measurable things the customer would want to be true when this job is done well?
Within the Jobs-to-be-Done (JTBD) Framework, the core functional job also determines the competitive frame. Once you define the job, you can identify every solution the customer considers, not just direct competitors in your product category but workarounds, manual processes, and adjacent products that get the same job done. This expanded competitive lens is one of the framework's most powerful strategic outputs, and it depends entirely on defining the job at the right level.
Finally, a well-formed job statement acts as a coordination mechanism across functions. Engineers use it to evaluate feature requests ('does this help the customer get the core job done better?'). Marketers use it to write messaging that resonates with the customer's actual goal. Sales teams use it to qualify leads by checking whether the prospect actually has this job. The job statement is not a research artifact filed away after a workshop. It is the operating definition that your product organization returns to every time priorities conflict.
Step-by-Step
Step 1: Gather raw customer evidence
Collect qualitative data that reveals what customers are trying to accomplish. Sources include interview transcripts from JTBD customer interviews, support tickets, sales call recordings, onboarding surveys, and behavioral analytics showing what users do immediately before and after using your product. You need at least 8-12 distinct customer accounts to see patterns. Pull verbatim quotes where customers describe their goals, frustrations, and the sequence of actions they take.
Organize these quotes in a single document or spreadsheet, tagging each with the customer segment and context.
Tip: Pay special attention to 'switching stories,' moments when customers describe moving from one solution to another. These reveal the underlying job more clearly than satisfaction feedback, because the customer is articulating what they needed that the old solution failed to deliver.
Step 2: Extract candidate job statements from the evidence
Read through your evidence and write down every plausible job statement you can identify. Do not filter yet. Write each as a verb-object-context phrase. You will likely generate 10-25 candidates ranging from very broad ('improve quality of life') to very narrow ('compare weekly grocery prices at two stores').
Include overlapping and redundant statements. The goal is exhaustive coverage, not elegance. Each statement should describe something the customer is trying to get done, not something they feel or something your product does for them. If you catch yourself writing a product feature or an emotional state, rewrite it as a functional task.
Tip: If a candidate statement includes your product name or any specific technology, it is a solution, not a job. Replace the product reference with the function it serves: 'use Mint to see spending' becomes 'monitor spending patterns over time.'
Step 3: Test each candidate for solution independence
Take each candidate and ask: would this job exist if my product category did not exist? Would it have existed 50 years ago? If the answer is no, the statement is tied to a solution or a technology era. Rewrite it at a higher level of abstraction.
For example, 'create a playlist for my workout' is tied to digital music products. ' Apply this test to every candidate and either promote it, rewrite it, or discard it. You should end up with 5-10 surviving candidates.
Tip: A helpful forcing function: imagine explaining the job to someone from a completely different era or culture. If the statement requires knowledge of modern technology to understand, it is not yet solution-agnostic.
Step 4: Check the altitude of abstraction
For each surviving candidate, apply two tests. First, the 'too high' test: can you generate at least 10 distinct desired outcomes for this job? If you cannot, the statement is probably too narrow and describes a step within a larger job. Second, the 'too low' test: does the statement feel so broad that any product in any category could claim to address it?
If so, add a contextual clarifier or narrow the object. A job like 'manage health' is too broad. 'Manage chronic pain without medication dependency' passes both tests. Work through each candidate, adjusting the verb, object, or context until both tests pass.
Eliminate candidates that resist adjustment.
Tip: If two candidates seem to be at different altitudes on the same ladder, the higher one is likely the core job and the lower one is a job step that will appear later in your job map.
Step 5: Consolidate overlapping candidates into a single job statement
You should now have 3-6 refined candidates. Group any that describe the same underlying task from different angles. Choose the phrasing that is most precise, most stable, and most generative of outcome statements. If two candidates are truly distinct jobs, you may have identified two separate markets or use cases.
In most product contexts, you want a single core functional job per product line. Write your selected statement in the canonical format: [action verb] + [object of the action] + [contextual clarifier]. Read it aloud. ' in plain language.
Tip: Run the final statement past a colleague who was not involved in the exercise. If they need more than one sentence of explanation to understand it, the statement is not clear enough.
Step 6: Validate against the evidence and with customers
Return to your original customer evidence from Step 1. Read through every quote and ask: does our job statement accurately describe what this person was trying to accomplish? If more than 20% of the quotes describe a goal that falls outside the job statement, your statement may be too narrow or you may have the wrong job entirely. ' Their reaction, whether they nod immediately or look confused, is the most direct validation you can get.
Adjust the wording based on feedback, but resist the urge to add emotional or aspirational language.
Tip: Customers will often try to add solution language ('yes, and that is why I use X'). Acknowledge their input but keep the job statement solution-free. You are validating the goal, not the method.
Step 7: Document the job statement with supporting context
Create a one-page reference document that includes the final job statement, 3-5 supporting customer quotes that illustrate the job, a brief note on the altitude decision (why this level and not higher or lower), and a list of known solutions customers currently use to get this job done. Include the competitive frame: direct competitors, adjacent products, manual workarounds, and non-consumption (choosing not to do the job at all). This document becomes the input for creating job maps and writing desired outcome statements. Store it where your product team can reference it easily, such as a shared wiki or product brief.
Tip: Add a 'not this' section listing common misinterpretations of the job. For example: 'The job is not to use budgeting software. The job is not to feel financially secure. The job is to manage personal finances over time.' This prevents drift as the document circulates.
Examples
Example: B2C fintech startup defining a personal finance job
A 12-person fintech startup building a budgeting app. The team has conducted 15 customer interviews and has transcripts from onboarding calls. They have 3 weeks before a strategy offsite where the job statement needs to be finalized. The product currently serves young professionals aged 22-35.
The team pulled 87 verbatim quotes from interviews and tagged each with a candidate job. ' The first three failed the solution-independence test, because they are tied to specific activities within budgeting products. 'Track monthly spending' is a step, not a job. 'Build an emergency fund' is a desired outcome, not a job.
'Stop overspending on subscriptions' references a specific solution category. The team consolidated around 'manage personal finances over time,' which passed both altitude tests: they generated 18 distinct outcome statements, and the job clearly existed before any fintech product. Validation with 5 customers produced immediate recognition. The final documented statement included a competitive frame listing spreadsheets, envelope budgeting, financial advisors, bank apps, and non-consumption as alternative solutions.
This statement anchored the strategy offsite and directly fed into a job map with 8 process steps.
Example: B2B SaaS company defining a project coordination job
A mid-stage B2B SaaS company (80 employees) selling project management software to marketing agencies. The product team has access to 200+ support tickets and 30 sales call recordings. They serve teams of 5-50 people working on client deliverables with tight deadlines.
The team initially proposed 'manage projects using agile methodology' as the core job. This failed the solution-independence test immediately, because agile is a methodology, not a job. Removing the methodology reference yielded 'manage projects,' which failed the altitude test as too broad (it could describe construction, software development, event planning, or anything else). ' The team tested this against their support tickets and found that 78% of tickets aligned with this job scope.
They validated with 4 agency owners who confirmed the statement resonated. The competitive frame expanded beyond other PM tools to include email threads, shared spreadsheets, Slack channels, and whiteboards. The contextual clarifier 'from brief to handoff' was critical because it scoped the job to the lifecycle their product actually supports, excluding pre-sale scoping and post-delivery maintenance, which are related but separate jobs.
Example: Healthcare startup defining a patient monitoring job
A 6-person healthcare startup building a remote patient monitoring platform for managing chronic conditions. They have access to transcripts from 10 interviews with patients and 8 interviews with clinicians. Regulatory constraints mean the product can only support specific clinical workflows.
The team started with 'monitor patients remotely,' which is solution-dependent (it assumes remote monitoring technology). Stripping the solution yielded 'monitor patient health indicators,' which felt too narrow because it described one step in a larger job. ' This passed the solution-independence test (patients managed chronic conditions long before remote monitoring existed, using journals, phone calls to nurses, and self-observation). It also passed the altitude test, generating 14 outcome statements across medication adherence, symptom tracking, lifestyle adjustments, and clinician communication.
The 'between clinical visits' clarifier was essential because it distinguished this job from the clinician's job during a visit. The competitive frame included paper symptom diaries, phone-a-nurse services, pharmacy consultations, patient portals, and caregiver observation. Both patient and clinician interviewees validated the statement, though clinicians initially tried to reframe it around their own workflow rather than the patient's perspective.
Example: Large enterprise defining an internal knowledge management job
A Fortune 500 company's internal product team is building a knowledge management platform for 15,000 employees across 40 offices. They have data from an internal survey with 2,300 responses and 20 contextual inquiry sessions observing employees searching for information.
The initial proposal was 'find information in the company wiki,' which is deeply solution-bound. ' The second version failed the altitude test as too broad, since it could describe attending a training session, asking a colleague, or reading a textbook. ' This passed both tests: it generated 16 outcome statements covering discoverability, accuracy, recency, applicability, and time-to-use. It also passed the solution-independence test since employees in the pre-digital era had the same job, using filing cabinets, departmental binders, and hallway conversations.
The competitive frame included asking colleagues directly, calling subject matter experts, searching email archives, recreating knowledge from scratch, and simply guessing. The 'institutional' qualifier was important because it excluded general professional knowledge (which is a different job served by external learning platforms) and focused on company-specific knowledge that only exists inside the organization.
Best Practices
Write the job statement before discussing solutions, features, or competitive positioning. Once solution language enters the conversation, it anchors the team's thinking and makes it harder to see the underlying job. Skipping this sequence leads to job statements that are just product descriptions in disguise.
Use verbs that describe observable functional activity: manage, acquire, transport, maintain, prepare, monitor, resolve. Avoid verbs that describe internal states: feel, enjoy, hope, avoid. If a verb is ambiguous, test it by asking whether you could watch someone doing it. You can watch someone 'manage finances.' You cannot watch someone 'feel secure.'
Keep the contextual clarifier situational, not demographic. 'Over time' or 'while traveling' scopes the job without tying it to a persona. Demographic qualifiers like 'for millennials' or 'for enterprise buyers' belong in your segmentation work, not in the job statement itself. Mixing the two conflates the job with the market.
Revisit the job statement quarterly during the first year of use. Teams often discover that their initial altitude was slightly off once they begin writing outcome statements and building job maps. A small adjustment early, such as narrowing 'manage health' to 'manage chronic conditions,' can prevent weeks of rework downstream.
Involve at least one person from outside the product team in the definition exercise. Customer success, sales, or support team members hear different language from customers and will catch solution-dependency that product teams miss because they are too close to their own features.
Test the job statement against non-obvious competitors. If your job is 'stay informed about industry developments,' your competitors include newsletters, podcasts, industry conferences, peer networks, and doing nothing. If the statement does not accommodate this full competitive set, it is too narrow or solution-bound.
Distinguish between the core functional job and related jobs. A customer hiring a financial planning tool has a core job ('manage personal finances over time') and related jobs ('prepare tax filings,' 'plan for retirement'). Related jobs are real, but they get their own job maps and outcome statements. Mixing them into one statement creates a bloated, unfocused foundation.
Common Mistakes
Defining the job at the solution level instead of the task level
Correction
This is the most frequent error. ' The signal is any mention of a product category, technology, or specific tool in the statement. To fix it, remove the solution reference and ask what task the solution was helping the customer accomplish. That task is the job.
If you find yourself unable to remove the solution without losing meaning, you have not yet identified the underlying job.
Setting the altitude too high, producing a job statement that is unfalsifiable
Correction
Statements like 'achieve success in life' or 'be productive' are too abstract to generate useful outcomes. The diagnostic is the outcome test: try to write 10 specific, measurable desired outcomes for the job. If every outcome you write sounds like a platitude ('minimize the time it takes to succeed'), the job is too high. Drop down one level of specificity by adding a concrete object and context until the outcomes become tangible and measurable.
Blending functional and emotional jobs into a single statement
Correction
A statement like 'feel confident while managing investments' mixes a functional job (manage investments) with an emotional job (feel confident). This creates confusion downstream because outcome statements for functional jobs and emotional jobs have different structures and different measurement approaches. Separate them. Write the functional job as one statement and capture emotional and social jobs in their own dedicated section.
The functional job always comes first in the JTBD workflow because it is the most stable and measurable.
Defining multiple jobs as one compound statement
Correction
' Each of these is a distinct job with its own job map, steps, and outcomes. The compound statement makes it impossible to prioritize or measure. Pick the one job that is most central to your product's value proposition and define it cleanly. List the others as related jobs in your documentation.
You can build separate job maps for each later, but they should never be crammed into a single statement.
Anchoring to your most vocal customer segment instead of the broadest job executor
Correction
Teams often define the job based on power users or early adopters, whose needs are more specific and more solution-aware than the broader market. The result is a job statement that feels right for 15% of the market but excludes 85%. Check your statement against the full range of people who execute this job, including those who use competing products, manual workarounds, or nothing at all. The job should resonate across all of them.
Treating the job definition as a one-time workshop exercise and never revisiting it
Correction
The initial definition is a hypothesis. As you build job maps and write outcome statements, you will discover that the job is slightly broader, narrower, or differently scoped than you assumed. Teams that lock in the statement on day one and refuse to adjust it end up with misaligned downstream artifacts. Schedule a review after your first complete job map and again after your first round of outcome-based customer research.
Other Skills in This Method
Conducting JTBD Customer Interviews
How to run switch interviews and timeline interviews that uncover the real jobs, hiring criteria, and switching triggers behind customer decisions.
Identifying Underserved Outcome Opportunities
How to use opportunity scoring (importance vs. satisfaction) to quantify which desired outcomes are most underserved and represent the best innovation targets.
Applying JTBD Insights to Product Strategy and Roadmaps
How to translate job maps, outcome scores, and opportunity landscapes into actionable product roadmaps, feature priorities, and go-to-market positioning.
Writing Desired Outcome Statements
How to craft properly structured outcome statements (direction + metric + object of control + context) that capture measurable customer success criteria at each job step.
Creating Job Maps to Visualize Customer Processes
How to break down a core functional job into its universal process steps (define, locate, prepare, confirm, execute, monitor, modify, conclude) to map the full customer journey.
Segmenting Customers by Unmet Needs
How to create outcome-based customer segments that group people by shared underserved outcomes rather than demographics, enabling more targeted product strategies.
Frequently Asked Questions
How do I know if my job statement is at the right level of abstraction?
Apply two tests. First, try to write 10-15 distinct desired outcome statements for the job. If you can only write 3-4, the job is probably too narrow and describes a step rather than a complete job. Second, check whether the job is so broad that any product in any category could claim to address it. If both tests pass, you have the right altitude. When in doubt, write the statement at two different levels and generate outcomes for each. The level that produces more specific, measurable outcomes is usually correct.
Should I define the core functional job before or after conducting JTBD interviews?
You need some customer evidence before you can define the job, so at least a handful of interviews or existing qualitative data should come first. However, you do not need to complete your full interview program. A common workflow is to conduct 5-8 initial interviews, draft a candidate job statement, then validate and refine it during your remaining interviews. Waiting until all interviews are complete often leads to analysis paralysis. See [conducting JTBD customer interviews](/skills/conducting-jtbd-customer-interviews) for the interview process.
Can a product address more than one core functional job?
Yes, but each job should be defined and mapped independently. A ride-sharing app addresses 'get to a destination on time' for passengers and 'earn supplemental income on a flexible schedule' for drivers. These are separate jobs with separate outcomes, separate competitors, and separate job maps. Trying to merge them into one statement creates confusion. Define the primary job your product is designed around first, then define secondary jobs separately.
How long should defining the core functional job take?
Expect 2-4 hours of focused work for the definition exercise itself, assuming you already have customer evidence gathered. If you need to collect evidence first, add the time for interviews or data analysis. Do not rush this step. Teams that spend 30 minutes picking a job statement in a meeting almost always end up with a solution-dependent or incorrectly-scoped statement that requires rework later. The investment here pays off tenfold in downstream JTBD work.
What is a product manager's role versus a researcher's role in defining the job?
What is a product manager's unique contribution here is the strategic judgment about altitude and scope. A researcher gathers and synthesizes the evidence. A designer may help articulate the job in customer-friendly language. But the product manager decides which job to anchor the product strategy around, especially when multiple valid jobs emerge from the evidence. This is a strategic decision, not a research finding, because it determines your competitive frame and your innovation priorities.
How do I handle stakeholders who want to include product features in the job statement?
This is common and understandable, since stakeholders naturally think in terms of what the product does. Redirect the conversation by asking 'what would the customer still need to accomplish if our product did not exist?' This question forces solution-independent thinking. You can also show the competitive frame exercise: list 5-6 different ways customers get this job done today, including workarounds that have nothing to do with your product category. When stakeholders see the full competitive landscape, they usually understand why the job must be solution-agnostic.
Why does my job statement keep drifting every time I revisit it?
Drift usually indicates one of two problems. Either the original statement was not validated against enough customer evidence, so each new data point shifts the definition. Or the team is conflating the core functional job with adjacent related jobs, causing the scope to expand and contract. Fix this by returning to the evidence from Step 1, tagging each quote to a specific job candidate, and counting which job appears most frequently. Anchor the statement to the highest-frequency job and move the others to a 'related jobs' list.