Organizational Change: JTBD

Organizational Change for JTBD

Overcoming resistance, building jobs-oriented organizations, and avoiding the feature-factory trap.

Table of Contents

1. Common Objections to JTBD
2. The Feature-Factory Trap
3. Getting Executive Buy-In
4. Building a Jobs-Oriented Organization
5. Change Management Playbook
6. Handling Resistance
7. Measuring Adoption

---

Common Objections to JTBD

"We already know our customers"

The objection: "We've been in this business for years. We know what customers want."

The reality: You know what customers say they want and what they do. You may not know why they do it.

Counter:

• "Great—let's validate that knowledge. If we're right, research will confirm it quickly."
• "When was the last time we talked to customers about their struggles, not our product?"
• "Do we know why customers choose competitors, or why non-customers don't buy?"

"Jobs theory is too abstract"

The objection: "This sounds like academic theory. We need practical action."

The reality: JTBD is extremely practical—it tells you what to build and how to market.

Counter:

• "Let me show you a job statement for our product. Does this match how we talk about it?"
• "Here's how [successful company] used JTBD to [specific outcome]."
• "What if we ran one customer interview using this method and compared insights?"

"We don't have time for research"

The objection: "We need to ship features, not conduct research."

The reality: Shipping the wrong features wastes far more time than research.

Counter:

• "How much time did we spend building [feature that didn't work]?"
• "Five customer interviews take ~10 hours. What's the cost of a failed launch?"
• "We can learn the job from 10 interviews. We can't learn it from guessing."

"Our data tells us what to build"

The objection: "We have analytics. We know what users do."

The reality: Data shows what users do, not why. Jobs research explains the why.

Counter:

• "Data shows users drop off at step 3. Do we know why?"
• "Our most-used feature might not be our most-valued feature. Data can't tell us."
• "Correlation ≠ causation. We see patterns but don't understand motivations."

"Our roadmap is set"

The objection: "Leadership has already decided what we're building."

The reality: JTBD doesn't change what you build—it changes how you build and position it.

Counter:

• "Let's use jobs thinking to make sure we build [planned feature] the right way."
• "Understanding the job might reveal quick wins within current plans."
• "We can influence future roadmaps even if this quarter is set."

---

The Feature-Factory Trap

What It Looks Like

A feature factory is an organization that:

• Measures success by features shipped, not outcomes achieved
• Builds what stakeholders request without validating need
• Competes by feature matching competitors
• Has roadmaps full of features without hypotheses
• Celebrates launches, not impacts

Why It Happens

Cause	Dynamic
Easier to measure	"Did we ship it?" is binary; "Did it help?" is nuanced
Stakeholder demands	"Important person X wants feature Y"
Competitor pressure	"They have it, we need it"
Customer requests	"Customer asked for X" (but didn't explain job)
Short-term thinking	Features feel like progress

The Costs

• Wasted development: Features nobody uses
• Product bloat: Complexity without value
• Technical debt: Maintaining unused code
• Team demoralization: Shipping without impact
• Customer confusion: Product does everything, nothing well

Breaking Free

Step 1: Change the conversation

Instead of	Ask
"What features should we build?"	"What jobs aren't being well-served?"
"What did the customer request?"	"What job is the customer trying to do?"
"What does the competitor have?"	"What job does that feature serve? Do our customers have that job?"
"Did we ship it?"	"Did it help customers make progress?"

Step 2: Change the metrics

Feature-Factory Metrics	Jobs-Oriented Metrics
Features shipped	Customer outcomes improved
Velocity	Value delivered
Usage	Job completion rate
NPS	Would you hire us again?

Step 3: Change the process

Before greenlighting any feature:

1. What job does this serve?
2. Who has this job? How many?
3. How well is the job being served today?
4. How will we measure if this helps?

---

Getting Executive Buy-In

Speaking Their Language

Executives care about:

• Revenue growth
• Market share
• Competitive advantage
• Customer acquisition/retention
• Resource efficiency

Frame JTBD in these terms:

JTBD Concept	Executive Translation
Understanding the job	Reduce failed product launches
Job-based segmentation	Find underserved market opportunities
Competitive analysis	Identify sustainable differentiation
Job-oriented metrics	Improve customer retention

Making the Business Case

Case 1: Failed features "Last year we shipped 12 major features. 3 moved metrics. JTBD research could have identified which 3 before we built all 12."

Case 2: Churn analysis "Customers leave because we're not doing their job. Exit interviews reveal jobs we didn't know about. What if we knew before they left?"

Case 3: Competitive loss "We lose deals to [competitor]. Is it features or job understanding? Interviews with lost customers could tell us."

Case 4: Market expansion "Our market seems saturated. JTBD reveals non-consumers with the same jobs. That's greenfield opportunity."

The Pilot Proposal

Start small to prove value:

1. One focused research project (10 interviews, 2 weeks)
2. One product decision influenced by findings
3. Measure the outcome
4. Report back with concrete results

---

Building a Jobs-Oriented Organization

Team Structure

Option 1: Embedded researchers

• Researchers on each product team
• Continuous discovery, integrated with development
• Best for: Large organizations, complex products

Option 2: Central research team

• Shared research capability serving all products
• Standardized methodology, cross-product insights
• Best for: Multiple products, resource constraints

Option 3: Everyone does research

• Product managers, designers, engineers all interview
• Research is a skill, not a role
• Best for: Small teams, startups

Cultural Practices

Regular customer exposure:

• Monthly customer interviews for every PM
• Recordings shared team-wide
• "Customer of the week" highlights

Decision-making rituals:

• "What job does this serve?" in every roadmap discussion
• Job canvas for every major initiative
• Retrospectives include job validation

Metrics and reviews:

• Quarterly job completion metrics
• OKRs connected to customer progress
• Celebrate outcomes, not outputs

Knowledge Management

Job documentation:

• Job atlas maintained and updated
• Interview insights aggregated
• Competitive job mapping shared

Searchable repository:

• All interview notes and recordings
• Tagged by job, circumstance, dimension
• Accessible to entire organization

---

Change Management Playbook

Phase 1: Awareness (Weeks 1-4)

Activities:

• Present JTBD concepts to leadership
• Share case studies relevant to your business
• Identify internal champions
• Conduct one pilot research project

Milestone: Leadership agrees to pilot, one team engaged

Phase 2: Pilot (Weeks 5-12)

Activities:

• Train pilot team on JTBD methodology
• Conduct 10-15 customer interviews
• Document job findings
• Apply findings to one product decision
• Measure results

Milestone: Pilot produces actionable insights, one decision improved

Phase 3: Expansion (Months 4-6)

Activities:

• Share pilot results broadly
• Train additional teams
• Establish research operations
• Build job documentation
• Connect to roadmap process

Milestone: Multiple teams practicing, methodology documented

Phase 4: Integration (Months 7-12)

Activities:

• Jobs language in all product discussions
• Metrics shifted to job completion
• Hiring includes research skills
• Continuous discovery established

Milestone: JTBD is "how we work," not "that initiative"

---

Handling Resistance

From Engineers

Concern: "This is just going to change requirements mid-sprint."

Response:

• JTBD happens before sprint planning, not during
• Better job understanding = fewer requirement changes later
• You'll build things people actually use

From Sales

Concern: "Customers tell me what they want. I don't need research."

Response:

• Customer requests are input, not output
• Understanding why they want it helps you sell better
• Competitor feature requests aren't always right

From Marketers

Concern: "We already have personas and segments."

Response:

• Jobs complement personas with motivation
• Circumstance-based targeting often outperforms demographic
• Job statements make better copy than feature lists

From Product Managers

Concern: "I don't have time for research—I need to ship."

Response:

• Five interviews take less time than one failed feature
• Research prevents building the wrong thing
• Good PMs always talk to customers; this just structures it

---

Measuring Adoption

Leading Indicators

Indicator	Sign of Progress
Customer interviews conducted	Research is happening
Job statements documented	Learning is being captured
Decisions citing job research	Research is influencing work
Job questions in meetings	Language is changing

Lagging Indicators

Indicator	Sign of Impact
Feature success rate	Building right things
Customer satisfaction	Serving jobs better
Retention/churn	Jobs being done
Time to value	Onboarding aligned to jobs

Anti-Patterns to Watch

• "Job-washing": Using jobs language without doing research
• "One and done": Research project that doesn't continue
• "Cherry-picking": Only sharing findings that support existing plans
• "Performative interviews": Going through motions without learning