Applying Jobs-to-be-Done (JTBD) to Discovery and Feature Naming.

Jobs-to-be-Done (JTBD) represents a fundamental reframing of how product teams understand customers, shifting focus from what products are to why customers uses/hire them. Applied rigorously to discovery and feature naming, JTBD eliminates the most common sources of product failure: building the wrong features for the wrong reasons and naming them in ways that obscure rather than clarify their value.

The framework operates on a simple but profound insight: customers don’t care about features; they care about progress. They seek solutions to problems they’re trying to solve in specific contexts. When product teams ground discovery in customer jobs and name features according to the jobs they accomplish, conversion improves, adoption increases, and cross-functional alignment strengthens. Companies applying JTBD discover unmet needs competitors miss, avoid feature creep that clutters products, and craft messaging that resonates because it speaks to actual motivations rather than assumed ones.​

This blog synthesizes JTBD discovery methodology into an operational framework and demonstrates how job-centric language transforms feature naming from internal technical taxonomy to customer-comprehensible value articulation.

JTBD Discovery Methodology

The Fundamental Shift: From Product-Centric to Job-Centric Thinking

Traditional product discovery often begins with feature requests, user personas, or market research reports. Teams ask: “What features do our users want?” or “Who is our ideal customer?” JTBD inverts the question: “What progress is the customer trying to make in their life or business, and what circumstances are they in when they seek that progress?”​

This distinction proves critical. A user might request a “dashboard,” but the job could be any of several distinct goals: reduce time spent in reporting, increase confidence in data accuracy, or enable quick stakeholder communication. Each job suggests different features, different naming, different positioning. Without understanding the underlying job, teams risk building feature complexity that serves no one well.​

The JTBD Interview: Discovering Jobs Through Customer Narratives

JTBD discovery relies primarily on structured customer interviews designed to reconstruct the decision timeline that led to a purchase. Unlike broad satisfaction surveys or focus groups, JTBD interviews excavate the causal chain of events, emotional triggers, and competing solutions a customer evaluated.​

The Interview Timeline Framework

JTBD interviews follow a deliberate progression through the customer’s decision journey:

1. The Trigger Phase: What event or circumstance forced recognition that a problem needed solving? (“I was spending two hours daily on manual reporting and realized I was missing strategic work”)​

2. The Passive Search Phase: What did the customer do once they recognized a problem existed? Did they research solutions, or did they live with the problem temporarily? (“I started looking at alternatives but wasn’t in a rush”)

3. The Active Search Phase: What event catalyzed urgent seeking? (“Our board asked for real-time dashboard access; suddenly it became non-negotiable”)​

4. The Consideration Phase: What solutions did they evaluate, and what criteria mattered most? (“We looked at Tableau, Looker, and building something custom. We cared about ease of use, cost, and integration with existing tools”)​

5. The Hiring Moment: What tipped the final decision? What anxieties almost prevented purchase? (“We were worried about implementation time, but their free trial showed us we could go live in a week”)​

6. The Use Phase: How is the product being used? What is it actually solving in their day-to-day work? (“Every morning I pull the dashboard to understand yesterday’s metrics before my 9 AM standup”)​

Effective Interview Technique

The skill in JTBD interviewing lies in extracting narrative rather than direct answers. Customers are often poor reporters of their own motivations, they rationalize decisions after the fact, omit context, or provide generic answers when asked directly.​

Effective JTBD interviewers employ several techniques:​

Start Backwards: Begin not with “tell me about your problem” but with “where were you when you bought [product], and why did you decide to buy it that specific day?” This grounds the conversation in a concrete moment rather than abstract problems. The specificity triggers more accurate recall.​

Use Environmental Cues: If a customer says “I bought it sometime last year,” ask: “Was it summer or winter? What was the weather like? Had you taken a vacation yet that year?” These environmental anchors seem tangential but dramatically improve accuracy. Recall studies show concrete details activate associative memory far more effectively than temporal abstractions.​

Ask About Other Solutions: Rather than “What problems were you trying to solve?”, ask “What did you try before you chose us? What tools were you using? What didn’t work about them?” This reveals the competitive set from the customer’s perspective, which often includes non-product solutions like manual processes, spreadsheets, or DIY workarounds.

Employ the Five Whys Technique: When a customer states a motivation, ask “why?” until you reach the emotional or social core. Surface answer: “I wanted better reporting.” First why: “Because our CEO needed real-time metrics.” Second why: “Because board meetings were becoming data-focused.” Third why: “Because our competitors were showing higher transparency.” Fourth why: “Because I wanted to appear competent and prepared in front of the board.” This progression reveals functional job (reporting), emotional job (confidence, competence), and social job (appearing prepared).​

Avoid Leading Questions: Never ask “Would you want a feature that did X?” or “How important is Y?” These preset the solution. Instead, ask: “Have you ever encountered a situation where [context]? What did you do?” This keeps the interview open-ended, allowing genuine problems and surprising solutions to surface.​

Interview Sampling and Recruitment

Effective JTBD discovery requires 10–20 interviews minimum, though patterns often emerge after 7–10 conversations with the right participants.

The choice of whom to interview matters substantially. Teams should interview across multiple customer profiles to understand the full spectrum of jobs:

• Best customers: Longest tenure, highest engagement, strong retention signals

• Power users: Deepest feature adoption, most advanced use cases

• Recent purchasers: Decision timeline fresh in memory (within 3–6 months)

• Lost deals or churned customers: Illuminate anxieties, barriers, or unmet needs

Interview distinct segments separately. A job that drives SMB adoption may differ materially from an enterprise job. Running interviews with mixed segments obscures these differences and produces generic outputs.​

Synthesis and Job Statement Development

After interviews conclude, teams move to coding, identifying recurring patterns in the data. What themes emerge? What language do customers use repeatedly? What triggers appear across multiple interviews?​

From these patterns, teams develop Job Statements, formal descriptions of the job capturing functional, emotional, and social dimensions:

Example Job Statement (Project Management Tool):

• Functional Job: Help teams make progress on shared goals without confusion about who’s doing what

• Emotional Job: Feel confident that nothing is falling through the cracks

• Social Job: Be seen by leadership as organized and on top of commitments

• Circumstances: When the team grows beyond 5 people and informal communication breaks down

This statement is vastly more actionable than generic user feedback like “users want better collaboration features.” It provides a standard against which every feature decision can be evaluated.

From Jobs to Feature Naming and Prioritization

The Feature Naming Problem

Most product teams name features based on internal implementation or design taxonomy. A team building collaboration might name their feature “Workspace,” “Kanban Board,” or “Real-Time Collaboration Engine.” These names reflect how engineers built the feature or what category it occupies in the codebase, but they often obscure what job it actually solves for customers.

Customers don’t think in implementation terms. They think in progress terms. A customer’s internal dialogue isn’t “I need to access a Kanban board”; it’s “I need to make sure my team knows what I’m working on and that I know what they’re doing.” The feature name should bridge that gap, signaling progress rather than implementation.

Job-Centric Naming Framework

When naming features, teams should follow this principle: name the job, not the solution. Use customer language, not technical terminology.

Job-Driven Feature Prioritization

Once teams understand customer jobs, feature prioritization becomes systematic rather than political. The question shifts from “Which feature is easiest to build?” or “Which feature did the loudest customer request?” to “Which feature best serves the most critical customer job?”

The Feature-to-Job Mapping Process:

1. List Identified Jobs (from discovery phase): Primary jobs, secondary jobs, related emotional/social jobs

2. Map Existing Features: For each current or planned feature, identify which job(s) it serves

3. Identify Feature Gaps: Are any critical jobs underserved? What features would address them?

4. Evaluate Feature Relevance: Do any features serve no identified job or only solve for one obscure job? These are candidates for removal or lower prioritization

5. Prioritize by Job Criticality: Rank jobs by importance to target segment and current market underservice. Prioritize features addressing top-ranked jobs first

Example: Project Management Tool Prioritization

Assume discovery identified these jobs (ranked by criticality):

• High Priority: Build cross-project timeline (serves Job #1, currently weak)

• High Priority: Weekly digest feature (serves Job #2, currently missing)

• Medium Priority: Presence indicators (serves Job #3, partially addressed)

• Lower Priority: Automated status (serves Job #4; manual updates work for most customers)

This framework eliminates subjective debate. Teams can point to job-centric reasoning rather than gut feel.

Avoiding Feature Creep Through Job Discipline

One of JTBD’s most powerful applications is preventing feature creep, the accumulation of low-value features that clutters products and increases cognitive load without meaningfully advancing customer progress.

A fitness app that added social leaderboards and advanced biomechanical analysis might have thought both features enhanced the product. But if the core job was “Feel more confident and healthy,” neither feature served that job directly. Leaderboards created anxiety (competitive comparison); biomechanical data confused and intimidated users. By returning to the core job, feel confident, the team realized it should prioritize motivational check-ins and milestones celebrating personal progress instead.​

Job-Centric Elimination Criteria:

• Does this feature help customers make progress on an identified job? (If no, eliminate)

• Does it address an important job or a niche job? (Niche jobs → lower priority)

• Does it create friction or require ongoing education? (High friction → evaluate if job is critical enough to justify complexity)

• Does it materially improve the core experience or provide marginal enhancement? (Core improvements only)

The discipline isn’t arbitrary; it’s grounded in understanding what customers actually use the product to accomplish.

 

JTBD in Organizational Practice

Making Jobs Visible in Daily Work

JTBD creates most value when it becomes the language of daily product work, not a one-time research artifact, but an active compass guiding decisions.

Job Stories in Backlogs and Development

The most effective mechanism is replacing traditional User Stories with Job Stories, a format that captures context and motivation alongside functionality:​

Traditional User Story:

As a project manager, I want to view team member workload,
so I can balance assignments fairly.

Job Story:

When my team is starting a new sprint and I’m assigning tasks,
I want to see each person’s current load so I can distribute work
without overloading individuals and ensure everyone feels respected.

The difference is subtle but consequential. The job story includes:

• Situation/Context: “When my team is starting a new sprint”

• Motivation: “ensure everyone feels respected” (emotional dimension emerges)

• Outcome: “distribute work without overloading” (progress-centric)

This format forces design teams to think about context and constraints, not just task completion. It naturally surfaces edge cases and emotional considerations that user stories miss.

Job-Focused Roadmaps

Rather than organizing roadmaps by feature theme (“Build Q2: Automations, Integrations, Reporting”), organize by job theme:

Q2 Roadmap: Help Teams Move Faster
├─ Weekly digest email (Enable quick status understanding)
├─ Template library (Reduce setup friction)
├─ Bulk editing (Speed up routine updates)

Q3 Roadmap: Build Leadership Confidence
├─ Cross-team timeline view (See full picture)
├─ Health checks (Verify no surprises)
├─ Executive dashboard (Communicate status upward)

This organization clarifies not just what you’re building, but why. When teams see “we’re building Q2 around helping teams move faster,” feature discussions cohere around job relevance rather than feature-of-the-quarter popularity contests.

Decision Rubric Grounded in Jobs

Product leadership should establish a formal decision rubric that requires every feature proposal to articulate its job alignment:

Cross-Functional Alignment Through Shared Job Language

One of JTBD’s most underestimated benefits is its power as a common language across functions. When marketing, sales, product, and customer success all share the same job statements, silos dissolve.

How Each Function Uses the Same Job Framework

Product Development:

• Prioritize features by job criticality

• Name features by job, not implementation

• Build success criteria around job achievement, not feature launch

Marketing:

• Craft positioning around jobs, not features (“Help your team move faster” not “Kanban boards + real-time sync”)

• Create content addressing each job’s key anxieties (“How to ensure nothing falls through the cracks”)

• Use job language in value propositions and ad copy

Sales:

• Conduct discovery calls using job-centric questions, not feature-focused discovery

• Position solutions around customer jobs, not feature comparison

• Build customer narratives around job achievement (“Here’s how similar teams use this to stay aligned”)

Customer Success:

• Design onboarding around job achievement, not feature tours

• Measure success by job progress, not feature adoption

• Proactively recommend features addressing customer’s stated jobs

Example: Alignment in Action

Sales discovers a prospect struggling with “keeping leadership updated without daily meetings”, a job. Rather than calling it a sales opportunity and moving on, the sales rep shares this with product. Product reviews discovery and realizes: “We identified this job, but our ‘Weekly Digest’ feature isn’t being discovered in onboarding.” Marketing reviews the discovery and realizes: “This is a compelling angle we haven’t articulated, we should emphasize async communication in positioning.” Customer Success notes: “New customers with this job should see the Digest feature in week-one onboarding, not week three.”

A single job insight cascades across four functions, improving outcomes across acquisition, development, and retention. This alignment is nearly impossible without a shared language like JTBD.

Implementation Framework

Discovery Workshop (Weeks 1-4)

Week 1: Scope Definition

• Identify target customer segment with precision (avoid “all users”)

• Define discovery goal (problem understanding vs. solution ideation)

• Establish hypotheses about customer jobs (to test, not confirm)

Week 2-3: Interview Execution

• Conduct 10+ interviews following JTBD timeline structure​

• Use two-person teams: facilitator + note-taker​

• Record or transcript interviews for later coding

Week 4: Synthesis

• Code interviews for jobs, outcomes, anxieties, behaviors, competing solutions​

• Group patterns by frequency (what emerges across 7+ interviews?)

• Draft job statements capturing functional, emotional, social dimensions

Job Prioritization and Mapping (Weeks 5-6)

• Rank jobs by importance to target segment and current market underservice

• Map existing/planned features to jobs

• Identify gaps: which jobs are underserved? Which features serve no job?

• Create job map: visualize steps and outcomes within core job

Feature Naming and Roadmap Alignment (Weeks 7-8)

• Rename features using job language, not technical terms

• Organize roadmap by job themes, not feature categories

• Create job-to-feature mapping document for ongoing reference

• Update marketing positioning to reflect job-centric language

Continuous Refinement (Ongoing)

• Conduct quarterly JTBD refresh interviews to test if jobs evolve​

• Monitor feature adoption against job-achievement metrics

• Revisit naming and positioning quarterly based on product evolution

• Add job statements to PRDs, backlogs, and strategy documents​

Case Studies in JTBD Application

Clarity (Dan Martell)

Dan Martell’s Clarity: a marketplace connecting entrepreneurs to mentors, illustrates how JTBD transforms feature decisions. Initially, Clarity was building features based on direct customer requests. One such request: “Save search results when looking for experts.”​

Using JTBD methodology, the team flipped the question: What job are customers trying to accomplish when they search for experts? They interviewed users and discovered the real job wasn’t “save expert results” but rather “find the right expert without wasting time evaluating unsuitable options.”​

When they dug deeper with job-centric questions, they learned customers were already using Evernote, Buffer, and browser bookmarks to manage information. They didn’t need Clarity to replicate what existing tools did. What they needed was confidence in expert selection, reducing the anxiety of hiring someone unqualified or expensive.​

This insight shifted the roadmap entirely. Instead of building a save feature, Clarity:

• Improved expert profile detail to reduce uncertainty

• Added verified credentials and customer testimonials

• Created onboarding flows to explain vetting criteria

• Built messaging around “find the right expert with confidence”

The feature that would have satisfied immediate requests was avoided because it didn’t serve the actual job. The features built instead directly addressed the real job and achieved higher adoption.

Fitness App’s Job Reframing

A fitness app initially focused on tracking runs and calories, the surface job. But JTBD interviews revealed the real jobs were emotional: users use fitness apps to feel confident, healthy, and accomplished.​

With this insight, the team redesigned:

• Onboarding: Shifted from metrics collection to values clarification (“What does being healthy mean to you?”)

• Progress Tracking: Renamed from “Calories Burned” to “Building Confidence,” emphasizing emotional milestones

• Messaging: Moved from “Track all your workouts” to “Achieve the health confidence you deserve”

• Feature Prioritization: Deprioritized social leaderboards (create comparison anxiety) in favor of personal milestone celebrations

The same product, reframed through jobs, achieved higher engagement and retention because features were named and positioned to resonate with actual motivations.

Intercom’s Job Stories

Intercom created the Job Stories framework specifically to avoid the feature-first bias common in User Stories. By reformulating stories as “When [situation], I want to [motivation], so I can [outcome],” Intercom forced teams to stay context-aware and job-focused during design sprints.​

The result: features that solved real customer problems rather than iterated on vague requirements. Teams could ask “Is this feature helping the customer make progress toward the outcome?” rather than just “Does it implement the requirement?”

Conclusion

Jobs-to-be-Done applied systematically to discovery and feature naming transforms product teams from feature factories into progress engines. By grounding discovery in customer jobs, systematically naming features using job language, and organizing development around job themes, teams eliminate the ambiguity and misalignment that plague most product development.

The framework is not magical, it requires rigor, discipline, and willingness to unearth uncomfortable truths about what customers actually need versus what they request. But for teams committed to this rigor, JTBD delivers a durable competitive advantage: products customers can’t describe without your language, because your language is their language. Products organized around customer progress rather than internal categories. Products where every feature can be justified not by executive preference but by customer job criticality.

In a world where feature parity commoditizes products, job-centric discovery and naming create durable differentiation. Start with one customer segment. Run 10 interviews. Write job statements. Use them to reorganize your roadmap and rename your features. Measure the result not in features launched but in jobs served. The framework provides the compass; organizational discipline provides the navigation.