Intro
Every technology leader faces the same challenge: how do we know we are building the right thing? Traditional product thinking often focuses on features, user demographics, or internal assumptions. Jobs to be Done (JTBD) offers a different lens. It shifts the focus from what customers are to what customers are trying to accomplish. This article explains JTBD in practical terms for technology managers. You will learn what the framework is, when it applies, how to use it in a realistic technology organization example, and how to govern decisions around it. By the end, you will have a clear method for identifying customer needs, prioritizing work, and measuring success in a way that aligns teams and stakeholders.
Management Context
JTBD is a management tool for understanding demand. It helps leaders prioritize investments, align cross-functional teams, and avoid building features nobody wants. The core idea is that customers 'hire' a product or service to make progress in a specific situation. The job is the progress, not the product. For example, a person does not buy a drill because they want a drill; they hire the drill to make holes. In a technology context, a business might hire a project management tool to coordinate distributed work, not because they want the tool itself. This subtle shift has big implications for how you define value, scope roadmaps, and measure success.
JTBD is not a replacement for other management frameworks; it is complementary. It works well with OKRs for setting outcome-based goals, with SWOT for situational analysis, and with Lean Startup for hypothesis testing. However, JTBD has a distinct purpose: it uncovers the underlying motivation behind customer behavior. While OKRs define what you want to achieve, JTBD helps you understand why the customer cares. This distinction matters because many technology initiatives fail not due to poor execution but due to a flawed understanding of the problem.
When should managers use JTBD? It is most valuable when:
- You are entering a new market or segment.
- Existing products fail to gain traction despite high usage.
- Teams disagree on what to build next.
- You need to prioritize a backlog with many competing ideas.
- You are designing a new product or platform capability.
In these situations, JTBD provides a structured way to gather evidence about customer needs and translate that into actionable decisions. It is less useful for incremental improvements to a mature product where user behavior is well understood. For those cases, process improvement methods like PDCA or DMAIC may be more appropriate. JTBD is a discovery tool, not a continuous improvement cycle.
One important note: JTBD is not a formula that gives a single answer. It is a lens for inquiry. The quality of your JTBD insights depends on the quality of your customer interviews, observations, and analysis. Later, we will discuss how to avoid common pitfalls such as confirmation bias and superficial listening.
Technology Organization Example
To make JTBD concrete, consider a fictional technology company called CloudCore, which provides a platform for managing cloud infrastructure. CloudCore's leadership wants to improve customer retention. They suspect customers are churning because the platform is too complex. Instead of jumping to solutions, they decide to apply JTBD.
Step 1: Define the customer and context
CloudCore focuses on small and medium-sized businesses (SMBs) that are moving to the cloud but lack dedicated DevOps staff. The context is the struggle to manage infrastructure with limited resources.
Step 2: Conduct customer interviews
The team interviews 15 current and former customers. They ask questions like: 'What were you trying to accomplish when you signed up for CloudCore?' and 'What happened the last time you used the platform?' They avoid asking about features or satisfaction.
Step 3: Identify jobs
From the interviews, they discover several distinct jobs:
- 'When my cloud bill spikes unexpectedly, I need to understand why before my boss asks.'
- 'When I deploy a new application, I need to ensure it does not break existing services.'
- 'When a server goes down, I need to restore service quickly without waking my team at 3 a.m.'
These are functional jobs. They also uncover emotional jobs: 'I need to feel confident that I am not making a costly mistake.'
Step 4: Prioritize jobs
The team scores each job on importance, frequency, and current satisfaction. The job about unexpected bill spikes ranks highest because it is frequent, important, and poorly served.
Step 5: Translate jobs into requirements
For the top job, the team defines success as: 'Customers can identify the source of a cost anomaly within 10 minutes and take action to prevent recurrence.' This becomes the basis for a new feature: a cost anomaly detection dashboard with alerts and recommendations.
Step 6: Test and learn
CloudCore builds a minimal version of the dashboard and tests it with a small group of customers. They measure time to identify anomaly, reduction in support tickets related to billing, and customer satisfaction. Based on results, they iterate.
This example illustrates how JTBD moves a team from vague assumptions to measurable outcomes. It also shows that the method requires active listening, structured analysis, and iterative testing.
Jobs vs. Features in the CloudCore Example
| Customer Job (what they want to accomplish) | Feature or Solution (what the product provides) | Success Metric |
|---|---|---|
| Understand unexpected cloud cost spikes | Cost anomaly detection dashboard | Time to identify anomaly < 10 minutes |
| Deploy applications without breaking services | Gradual rollout and canary testing tools | Deployment failure rate < 1% |
| Restore service quickly after outage | One-click rollback and incident alerts | Time to recovery < 5 minutes |
Notice that the features are not the jobs; they are possible solutions. The job remains stable over time, but the solution may change.
Decision and Governance Checklist
Adopting JTBD requires clear decision rights and governance. The following checklist helps managers evaluate whether a JTBD initiative is well-formed and who should own decisions.
JTBD Initiative Review Checklist
| Question | Yes/No | Owner |
|---|---|---|
| Is the customer segment clearly defined? | Yes | Priya Shah, Product Manager |
| Have we interviewed at least 10 customers from that segment? | Yes (15 interviews) | Marcus Lee, Research Lead |
| Are the jobs described in the customer's language, not internal jargon? | Yes | Priya Shah, Product Manager |
| Have we prioritized jobs using importance, frequency, and satisfaction? | Yes | Priya Shah, Product Manager |
| Do we have a measurable success outcome for the top job? | Yes (time to identify anomaly < 10 minutes) | Priya Shah, Product Manager |
| Have we validated the job with additional customers beyond the initial interviews? | Yes (5 additional interviews) | Marcus Lee, Research Lead |
| Is there a plan to test potential solutions with a narrow pilot? | Yes (beta with 20 customers) | Elena Rodriguez, Engineering Lead |
| Have we defined guardrail metrics to avoid negative side effects? | Yes (system uptime > 99.9%) | Elena Rodriguez, Engineering Lead |
| Is there a decision point to continue, modify, or stop the pilot? | Yes (after 30 days) | Tom Baker, VP of Product (Executive Sponsor) |
| Have we documented assumptions and open questions? | Yes (assumption log in Confluence) | Priya Shah, Product Manager |
This checklist ensures that JTBD is not just a brainstorming exercise but leads to concrete, evidence-based decisions.
Governance considerations
- Decision rights: The product manager typically owns problem definition and prioritization. Engineering owns solution feasibility and implementation. The executive sponsor owns the final go/no-go for investment.
- Cadence: JTBD work is not a one-time event. It should be revisited when market conditions change, new segments are considered, or product strategy shifts. The cadence depends on the planning horizon and evidence availability.
- Failure modes: Beware of these common pitfalls:
- Confirmation bias: hearing what you want to hear in interviews. Mitigate by having multiple interviewers and independent analysis.
- Solution jumping: proposing features before fully understanding the job. Mitigate by separating problem definition from solution ideation.
- Over-generalizing: treating a job from one segment as universal. Mitigate by segment-specific validation.
Conclusion
Jobs to be Done is a powerful framework for understanding customer needs and aligning technology investments. This article explained what JTBD is, when to use it, and how to apply it with a realistic technology organization example. We provided a decision and governance checklist to help managers evaluate JTBD initiatives and assign ownership.
Next steps for managers:
- Identify a current product or initiative where customer needs are unclear.
- Conduct a small set of customer interviews using JTBD principles.
- Define the top jobs and test your understanding with a narrow, measurable pilot.
- Use the governance checklist to review progress and make informed decisions.
Remember, JTBD is not a silver bullet; it is a disciplined way to ask better questions. By focusing on the progress customers seek, you can reduce rework, avoid building unused features, and deliver real value. Start small, measure outcomes, and let evidence guide your choices.