Customer Success & Product Alignment

Here's how most feature requests travel through a SaaS company: A CSM hears "we need bulk export" from a frustrated customer. The CSM logs it in the CS platform as a feature request. The PM reads "bulk export: 4 accounts" in the weekly feedback digest. It goes into the backlog below 30 other requests. Six months later, the customer churns. Post-exit interview: "We couldn't get our data out to run the reports our leadership needed."

The feature request was real. But "bulk export" was the customer's proposed solution, not the job they were hiring the product to do. The actual job was: when I need to report externally, I need to get data out in a format my stakeholders can read, without having to copy-paste row by row.

That's a different problem. It might be solved by export. Or by a shareable dashboard link. Or by a native Salesforce integration. The CS team had the raw signal. Nobody translated it.

Jobs-to-be-Done (JTBD) is the translation layer. It doesn't require new data collection. It's a reinterpretation discipline applied to data CS already has.

What JTBD Actually Is (and Isn't)

Clayton Christensen's original framing was simple: people don't buy products. They hire products to get a job done. Christensen's foundational HBR article on JTBD laid this out clearly: the milkshake example is famous. McDonald's discovered that morning commuters were hiring milkshakes to make a boring commute go by and keep them full until lunch, not because they were hungry or indulgent. The job defined the product strategy. Thicker milkshakes, easier straws, sold at the drive-through window.

Bob Moesta, who operationalized JTBD at the practitioner level, pushed it further: jobs aren't just functional. They have a context (the situation that triggers the need), a desired outcome (what "done" looks like), and a constraint (what the customer can't or won't do). The job statement format his work produced is the one CS teams should use:

Job statement structure:

"When [situation], I need to [functional outcome], without [constraint]."

This is not user-story format. "As a user, I want bulk export" describes a preference. The JTBD statement describes a situation, an outcome, and what makes the current approach unworkable. These are different things, and the difference matters for product decisions.

JTBD is also not the same as "pain points." Pain points describe friction. Jobs describe intent. A customer who says "the reports are slow" is describing pain. The underlying job is "when I'm presenting live to leadership, I need to pull customer data in under five seconds, without losing credibility to a spinning loading wheel." Pain point → fix the performance. Job statement → what situations trigger the need, and what does "done well" actually look like?

For VP CS and Head of Product conversations, Moesta's operational lens is more useful than Christensen's theoretical one. The question isn't "what job does our product do?" It's "what jobs are customers actually hiring it to do, and which of those jobs are we failing?" McKinsey's research on customer success 2.0 makes a parallel point: CS teams that draw on customer knowledge to surface unmet jobs create more durable retention than those focused on relationship management alone.

Key Facts: JTBD and CS Signal Quality

According to ProductPlan's 2024 Product Management Report, 72% of product teams say customer feedback is one of their top three inputs for roadmap decisions, but only 31% have a structured process for interpreting that feedback at the job level rather than the feature level.

Churn interviews are consistently rated the highest-signal CS data source for JTBD extraction, per Gainsight's Customer Success Benchmark research, yet fewer than 40% of CS teams conduct structured exit interviews that ask what the customer was trying to accomplish.

Teams that apply ARR weighting to job statements (not just feature request counts) report 2.3x higher alignment between CS feedback and shipped roadmap items, per Productboard's State of Product Management survey.

Where CS Data Fits the JTBD Model

CS data is the richest raw material for job extraction in most SaaS companies. The challenge is that it comes in the wrong format. Here's how each source maps to JTBD components.

Call notes as situation context. When a CSM writes "customer said the reporting workflow is painful during their Monday planning meeting," that's the situation clause: "when I'm running the Monday planning meeting." It's buried in a note, but it's there. CSMs capture the "when" constantly. They almost never surface it as a JTBD input.

Churn exit interviews as the most honest job-failure signal. When a customer churns, they're firing the product from a job. A well-run exit interview asks: what were you trying to accomplish that the product didn't help you do? What are you going to do instead? These are pure JTBD gold. The constraint clause almost always appears in churn interviews: "I couldn't do X without Y," where Y is the thing the product failed to provide. CS teams that pair exit interviews with early warning system signals can often catch the job failure before churn rather than after.

QBR verbatims as outcome statements in disguise. When a customer says in a QBR "we want to see this become our single source of truth for customer data," they're stating a desired outcome. That's the middle clause of the job statement. The CSM hears it as an aspiration. It's actually a job definition.

Support ticket spikes as negative job evidence. When 15 tickets arrive in a week about the same workflow, that's evidence the product is failing a job for enough customers to trigger active frustration. The job isn't "fix the bug." It's "understand what job all 15 of these accounts are trying to do when they hit this wall."

NPS verbatims from promoters vs. detractors. Promoters describe jobs the product does well. Detractors describe jobs the product is failing. The contrast between the two cohorts maps directly to where job performance is strong and where it's broken. NPS trend data becomes far more actionable when it's layered against product usage and customer health signals. Accounts with high usage and declining NPS are the most urgent cohort.

The raw material is there. The gap is the extraction process that converts it into job statements product can act on.

The Extraction Process: From Raw Signal to Job Statement

Named Framework: The 5-Step JTBD Extraction The 5-Step JTBD Extraction converts raw CS data into validated job statements using situation-based tagging, job statement drafting, multi-account verbatim validation, ARR weighting, and job-map handoff to product. The framework was developed from Clayton Christensen's original JTBD theory and Bob Moesta's practitioner operationalization, adapted for mid-market SaaS CS teams that need structured job intelligence without overhauling their existing CS data processes.

This is a five-step process. It doesn't require a specialized tool. A shared doc works.

Step 1: Pull CS data by theme, not by feature request. Don't start with "what did customers ask for?" Start with "what situations do customers keep describing?" Pull call notes, support tickets, and QBR verbatims from the last quarter and tag them by situation type, not by product area.

Step 2: Rewrite each cluster as a job statement. Take the cluster of notes around a theme and write one or two job statements using the format: "When [situation], I need to [desired outcome], without [constraint]." Don't smooth over the constraint. It's often the most important part.

Step 3: Validate with three or more verbatims from different accounts. A job statement that can only be sourced to one account is anecdote, not pattern. You need at least three verbatims from different accounts (ideally from accounts at different ARR tiers) before treating it as a validated job.

Step 4: Attach ARR weight and account count to each job. "7 accounts representing $420K ARR are failing this job" is a product prioritization input. "7 accounts" is just a count. ARR weight turns job statements into business decisions. The same quantification discipline applies here as in the broader feedback pipeline.

Step 5: Hand off a job map, not a feature list. The output to product is a set of job statements with supporting verbatims, ARR weight, and account count. Not a list of feature requests. If you hand product a feature list, you get feature-level decisions. If you hand them a job map, you get capability-level decisions.

Rework Analysis: Based on CS team benchmarks, product teams that receive job maps rather than feature lists during quarterly feedback sessions make capability-level roadmap decisions in roughly half the time of those evaluating raw feature request queues. The job statement format (situation + outcome + constraint) gives PMs the context to evaluate trade-offs without scheduling follow-up interviews for each item. The three-verbatim validation threshold further filters anecdote from pattern, reducing the percentage of roadmap discussions consumed by single-account edge cases.

Practical Examples: Before and After

These two examples show the translation in practice.

Example 1:

Feature request: "We need bulk export."
Job statement: "When I need to present customer data to our leadership team quarterly, I need to get that data into a format our BI tool can read, without having to manually copy 300 rows into a spreadsheet."
Product implication: bulk export might solve this, but so would a native BI integration, an API endpoint, or a shareable view with export formatting. The job statement opens the solution space.

Example 2:

Feature request: "Can you fix the slowness in reports?"
Job statement: "When I'm in a live customer meeting and need to pull their usage data to answer a question, I need the report to load in under five seconds, without losing the customer's attention to a spinning loading wheel."
Product implication: "fix slowness" is vague. The job statement tells product that the trigger is a live meeting, the outcome is maintaining customer attention, and the constraint is the loading delay. That's a much more specific engineering brief.

Example 3:

NPS detractor verbatim: "We can't manage permissions the way our IT security team requires."
Job statement: "When we onboard a new team to the platform, I need to configure role-based access that matches our internal security policies, without having to ask your support team to make manual changes."
Product implication: the feature request implied here is "granular permissions." The job statement reveals the context (onboarding), the desired outcome (self-serve policy compliance), and the constraint (dependency on vendor support).

Example 4:

Churn exit interview: "We ended up just building our own solution because we couldn't get the workflow to fit our process."
Job statement: "When we handle [specific workflow], we need the system to adapt to our existing process, without having to redesign the process to fit the tool."
Product implication: this is a classic "the product is too opinionated" job failure. The customer hired the product to fit their workflow. The product hired them to fit its workflow. They fired it.

Where JTBD Breaks Down with CS Data

JTBD extraction fails in predictable ways. Knowing them upfront prevents wasted synthesis sessions.

CSMs who summarize instead of quote. When a CSM writes "customer wants better reporting," the situation, outcome, and constraint have all been stripped out. Paraphrasing kills JTBD extraction. The discipline fix is simple: call notes require one verbatim quote per escalated issue, not a summary. This is a tagging practice change, not a tool change.

Small account bias. Ten SMB tickets about the same feature will drown out two enterprise verbatims in a raw count. But if those two enterprise verbatims represent $800K ARR and the SMB tickets represent $50K combined, the ARR weighting in Step 4 corrects this. Don't run JTBD extraction without attaching ARR numbers.

Recency bias in call notes. A QBR verbatim from 18 months ago about a job the product was failing is still evidence, especially if the product hasn't addressed it. Date-filtering job extraction to the last 90 days misses persistent, unresolved job failures.

The customer who describes symptoms, not intent. Some customers can articulate the job clearly. Others describe only the symptom ("the dashboard doesn't work for us"). When the verbatim is symptom-only, the extraction step is a hypothesis: what job might this symptom indicate? This hypothesis needs at least three corroborating verbatims before becoming a validated job statement.

Building a JTBD Practice at the CS-Product Seam

A monthly job-mining session is the right operational cadence for most mid-market teams. TSIA's State of Customer Success research consistently finds that structured feedback practices (not ad-hoc escalations) are the primary differentiator between CS teams that influence roadmap and those that don't. The session runs for 90 minutes, involves VP CS, Head of Product, and one CS Ops representative. This session is an extension of CS as a voice-of-customer channel, the structured discipline that converts field signals into product intelligence. The output is three to five validated job statements, not a feature list.

What the session covers: CS Ops pulls the quarter's feedback data by theme. VP CS presents two to three candidate job statements with supporting verbatims. Product asks clarifying questions on situation context and constraints. The group validates whether each candidate meets the three-verbatim threshold and applies ARR weighting. The session ends with a ranked job map that feeds into the quarterly feedback review.

The tagging change that makes this possible: CSMs need to tag call notes with situation type at the time of capture. Not retroactively. Four situation tags cover 80% of CS-relevant jobs: executive reporting, team onboarding, cross-team workflow, and live customer meeting. These are the trigger situations that appear most often in high-signal JTBD extraction.

How many jobs per quarter: three to five validated job statements is the right volume. More than five overwhelms the roadmap conversation. Fewer than three suggests the extraction process isn't pulling from enough data sources.

Integration with the Rest of the VoC Pipeline

JTBD sits at a higher abstraction level than feature requests. It feeds roadmap strategy, not sprint backlog. This is a critical distinction.

Feature requests are backlog inputs. They answer "what specific capability do customers want?" Job statements are strategy inputs. They answer "what progress are customers trying to make?" Product teams need both, but they should be routed differently. Feature requests go to the VoC pipeline that feeds the product backlog. Job maps go to the roadmap strategy conversation: specifically the quarterly customer feedback review, where VP CS and Head of Product make prioritization decisions at the capability level.

When CS brings a job map to the quarterly customer feedback review, it changes the nature of the conversation. Instead of "which of these 20 feature requests should we build?" the question becomes "which of these five jobs should we solve for next quarter?" Product can respond to job statements with a wider range of solutions. And the ARR-weighted feedback quantification step ensures that job prioritization reflects commercial reality, not ticket volume.

The distinction matters because JTBD and ARR-weighted feature requests answer different questions. Feature requests answer "what do customers want?" JTBD answers "what are customers trying to accomplish?" Both are valid. Use JTBD when the product decision is about capability investment. Use ARR-weighted feature requests when the decision is about specific functionality.

Tooling Notes

No specialized tool is required. A structured template in Notion, Confluence, or a shared Google Doc handles the job map for most mid-market teams. The template fields: situation, desired outcome, constraint, supporting verbatims (minimum three), account count, ARR weight, and source data type (call note / churn interview / QBR / support ticket).

Gong and Chorus transcripts are useful raw material. Search by keyword clusters, not by intent, because AI search on transcripts doesn't surface job intent reliably yet. Search for "when we," "we need to," "we can't," "we have to" patterns. These phrases appear most frequently in the situation and constraint clauses of job statements buried in customer conversations.

Gainsight and ChurnZero surface feedback at the account level, which is useful for ARR weighting. But they don't extract job statements. That's a human synthesis step. What CS platforms help with is pulling the verbatims associated with a specific account cluster. What they obscure is the job-level pattern across accounts, because they're built around account records, not job categories.

Diagnostic: Is Your Current Tagging Supporting JTBD Extraction?

Before investing in a monthly job-mining session, run this diagnostic. Five questions:

Do call notes include at least one verbatim quote per escalated issue, or only CSM paraphrases?
Are support ticket themes tagged by situation type, or only by product area?
Do churn exit interviews ask "what were you trying to accomplish?" explicitly?
Are QBR verbatims captured in a searchable format, or buried in deck notes?
Is ARR attached to any feedback record before it reaches product?

If you're answering "no" to three or more of these, the JTBD extraction process will produce low-quality raw material. Fix the tagging before scheduling the mining session.

The 2-Week Job-Mining Sprint

For teams new to JTBD, this is the fastest way to produce your first validated job map without overhauling your CS data process.

Week 1, days 1-2: Pull last quarter's churn interview notes (all of them) and tag each by situation type. Write a draft job statement for each cluster of two or more.

Week 1, days 3-5: Pull the top three support escalation themes from last quarter. Check whether each maps to a situation already tagged in the churn interviews. If yes, strengthen the job statement with the support verbatims.

Week 2, days 1-2: Pull QBR verbatims from the last two quarters. Tag any outcome statement ("we want to use this for...") or constraint statement ("we can't do this because..."). Add to the relevant job clusters.

Week 2, days 3-5: Finalize three to five job statements with at least three verbatims each. Attach ARR weight and account count. Present to three PMs and ask: "Does this sound like a problem our product strategy should be solving?" If PMs add new verbatims, the job is real. If they push back with "we're already solving that," ask them to show where. The gap between their answer and the customer evidence is where customer-impact scoring for product decisions is most useful.

The 2-week sprint produces your first job map. The pattern recognition process that runs continuously across CSMs is what keeps the job map current between quarterly sessions.

Frequently Asked Questions

What is Jobs-to-be-Done (JTBD) in the context of CS data?

Jobs-to-be-Done is a framework, developed by Clayton Christensen and operationalized by Bob Moesta, that reframes customer feedback from stated preferences ("I want bulk export") to underlying progress goals ("when I need to present to leadership, I need to get data out in a format my BI tool can read, without copying 300 rows manually"). Applied to CS data, JTBD is a reinterpretation discipline. It converts existing call notes, churn interviews, and QBR verbatims into job statements that product teams can use for capability-level roadmap decisions rather than feature-level backlog additions.

How is a JTBD job statement different from a user story?

A user story describes a preference: "As a user, I want bulk export." A JTBD job statement describes a situation, a desired outcome, and a constraint: "When I need to present customer data to leadership quarterly, I need to get that data into a format our BI tool can read, without manually copying 300 rows into a spreadsheet." The job statement opens the solution space. It might be solved by export, a native BI integration, an API endpoint, or a shareable view with export formatting. The user story narrows the solution to a specific feature before the PM has evaluated the full range of options.

How many verbatims does a job statement need to be considered validated?

The 5-Step JTBD Extraction framework requires at least three verbatims from three different accounts before treating a candidate job as a validated pattern rather than a single-account anecdote. Ideally, those three accounts span different ARR tiers. An enterprise verbatim and an SMB verbatim describing the same job situation carry more validation weight than three SMB accounts. Once validated, the job statement should also carry ARR weight and account count before it enters the product conversation.

What CS data sources produce the best JTBD raw material?

Churn exit interviews are the highest-signal JTBD source: customers who are firing the product describe the job it failed to do with unusual clarity. QBR verbatims surface outcome statements in the middle clause of the job format ("we want this to be our single source of truth"). Call notes capture situation context in the opening clause ("when we're in our Monday planning meeting"). Support ticket spikes are negative job evidence. When 15 tickets hit the same workflow, the product is failing a job for enough customers to trigger active frustration. NPS detractor verbatims complete the picture: promoters describe jobs the product does well, detractors describe jobs it's failing.

Why does JTBD extraction fail in practice, and how is it fixed?

The three most common failure modes are CSMs who summarize rather than quote (stripping out situation and constraint in the paraphrase), small-account bias in raw ticket counts (fixed by ARR weighting in Step 4), and recency bias in data pulls (fixed by extending the extraction window to 12-18 months, since unresolved job failures persist beyond 90 days). The foundational fix is a tagging change at the time of capture: CSMs tag call notes with one of four situation types (executive reporting, team onboarding, cross-team workflow, live customer meeting) rather than by product area. This makes retrospective JTBD extraction significantly faster.

How does JTBD differ from pain point analysis?

Pain points describe friction: "the reports are slow." JTBD describes intent: "when I'm presenting live to leadership, I need to pull customer data in under five seconds, without losing credibility to a spinning loading wheel." Pain point analysis leads to a fix (improve performance). JTBD leads to a product brief: what triggers the need, what "done well" looks like, and what makes the current experience unworkable. Product teams that receive job statements rather than pain point lists make higher-quality prioritization decisions because they understand the context of the failure, not just the symptom.

How many validated job statements should a CS team produce per quarter?

Three to five validated job statements per quarter is the right volume for most mid-market CS teams. Fewer than three suggests the extraction process isn't pulling from enough data sources or the tagging discipline is too weak to surface distinct patterns. More than five overwhelms the roadmap conversation. Product teams making capability-level decisions against eight or ten jobs simultaneously tend to defer all of them. Three to five creates the right forcing function: enough pattern breadth to surface real strategic gaps, narrow enough to produce actual decisions in the quarterly customer feedback review.

Learn More

Tara Minh

Senior Operations & Growth Strategist