Jobs to Be Done for AI Tools: A Practical Approach

“We’re going to add AI to our product.” It’s the phrase I hear every week from technical teams wanting to stay relevant. But when I ask what specific job that AI will perform, they go blank.

The problem isn’t lack of technology. We have incredible models, accessible APIs, mature frameworks. The problem is we treat AI as if it were magic, not as a tool for solving specific jobs.

In my years helping companies implement AI successfully, I’ve seen a clear pattern: projects that work start with crystal-clear Jobs to Be Done (JTBD). Those that fail start with “it would be great if AI could…”

This is your practical guide for applying JTBD thinking to AI tools, from conceptualisation through implementation and continuous improvement.

Why JTBD is critical for AI tools

The problem with “AI-first thinking”

Most AI projects start backwards: “We have this incredible technology, where can we apply it?” It’s like having a hammer and desperately looking for nails.

AI-first thinking (incorrect):

1. “ChatGPT/Claude is impressive”
2. “Surely we can use this in our product”
3. “What might our users want?”
4. Build → wait → fail

JTBD-first thinking (correct):

1. “What specific job needs to be done?”
2. “How do users currently solve it?”
3. “Where do current solutions fail?”
4. “Can AI do that job better?”
5. Validate → build → iterate → scale

The difference in results

Typical AI-first projects:

• 73% fail in first 6 months
• Products that are impressive demos but no real adoption
• Teams frustrated because “users don’t understand the value”
• High investment, low ROI

JTBD-first projects:

• 64% achieve product-market fit within 12 months
• Organic adoption because they solve real pain
• Users requesting more features of the same style
• Efficient investment, measurable ROI

Why AI amplifies the importance of JTBD

AI is particularly seductive because it can do many impressive things. But “can do” doesn’t mean “should do”. Without clear JTBD, you build generic tools that do everything and solve nothing specific.

The generality trap:

• “Our chatbot can answer any question”
• “Our AI can analyse any type of data”
• “Our assistant can automate any workflow”

The power of specificity:

• “Reduces bug diagnosis time from 2 hours to 10 minutes”
• “Converts customer emails into support tickets automatically”
• “Generates financial reports in exactly the format your CFO needs”

JTBD framework for AI tools

Step 1: Identify the specific job

It’s not enough to say “they need help with X”. You need surgical specificity.

Job statement template: “When [SITUATION], I want [OBJECTIVE], so I can [OUTCOME].”

Vague examples (useless):

• “Users want faster answers”
• “The team needs to be more productive”
• “We want to automate processes”

Specific examples (useful):

• “When a customer reports a bug, I want to diagnose the root cause in less than 10 minutes, so I can give an accurate fix estimate”
• “When preparing for the board meeting, I want to generate actionable insights from our usage data, so I can make informed roadmap decisions”
• “When reviewing PRs, I want to automatically identify potential security issues, so I can focus on logic review”

Step 2: Map the current workflow

Before automating or improving with AI, you need to understand exactly how the work is currently done.

Workflow mapping framework:

1. Trigger: What initiates the job?
2. Steps: What are ALL current steps?
3. Decisions: What decisions are made at each step?
4. Inputs: What information is needed at each step?
5. Outputs: What does each step produce?
6. Pain points: Where is the friction/time waste?
7. Success criteria: How do you know the job is “done”?

Real example: Bug diagnosis workflow

Trigger: Customer bug report arrives
Step 1: Read bug description (2-5 min)
  - Decision: Is this really a bug or user error?
  - Pain: Often unclear bug descriptions
Step 2: Reproduce bug in staging (15-45 min)
  - Input: Customer environment details
  - Pain: Environment differences
Step 3: Check logs (10-30 min)
  - Decision: Which logs are relevant?
  - Pain: Too much noise in logs
Step 4: Identify root cause (30-120 min)
  - Input: Code knowledge, similar bugs history
  - Pain: Memory limitations, context switching
Step 5: Estimate fix complexity (5-15 min)
  - Output: Time estimate for customer
  - Pain: Often underestimate due to hidden complexity

Step 3: Identify where AI can help

Not all parts of the workflow benefit from AI. Be specific about where it can add real value.

AI value assessment framework:

Excellent AI fit:

• Pattern recognition in large datasets
• Information synthesis from multiple sources
• Repetitive analysis requiring consistency
• Tasks benefiting from speed more than perfection

Poor AI fit:

• Decisions requiring nuanced human judgement
• Tasks needing very specific domain expertise
• Workflows that change frequently
• Situations where errors have very high cost

For our bug diagnosis example:

✅ Good AI fit:

• Log analysis and noise filtering
• Pattern matching against similar historical bugs
• Initial bug classification
• Code impact assessment

❌ Poor AI fit:

• Deciding if customer complaint is valid
• Final root cause determination for edge cases
• Customer communication
• Fix time estimation (requires project context)

Step 4: Design task-specific tools

Once you’ve identified where AI can help, design specific tools for those tasks. Not generic tools.

Design principles:

1. One tool, one job: Each tool should solve ONE specific job very well
2. Clear inputs/outputs: It should be obvious what goes in and what comes out
3. Human-in-the-loop: AI suggests, human decides
4. Verification built-in: Easy ways to verify output is correct
5. Graceful fallback: What happens when AI fails

Example: Bug Diagnosis Assistant

Tool: LogAnalyzer
Input: Error logs + timestamp + user session
Output: Top 3 potential root causes with confidence scores
Verification: Links to relevant code sections
Fallback: Raw log analysis if no patterns found

Tool: SimilarBugFinder
Input: Bug description + error patterns
Output: Similar historical bugs + their solutions
Verification: Human confirms relevance
Fallback: Manual search in bug database

Tool: CodeImpactAssessor
Input: Potential root cause + codebase
Output: Files likely needing changes + complexity estimate
Verification: Static analysis results
Fallback: Manual code review

Practical implementation

Phase 1: Single-tool validation (Weeks 1-4)

Don’t build a complete system. Start with ONE tool that solves the most painful part of the workflow.

Selection criteria:

• Highest pain point in current workflow
• Clearest success/failure measurement
• Lowest risk if tool fails

Implementation approach:

1. Build minimal version
2. Test with real users in real workflows
3. Measure improvement against baseline
4. Iterate based on feedback

Success metrics:

• Time reduction in that specific step
• Accuracy improvement
• User adoption rate
• Error rate reduction

Phase 2: Tool integration (Weeks 5-12)

Once you have one working tool, build the next ones and start integrating them.

Integration principles:

• Each tool should work independently
• Shared context but separate responsibilities
• Clear handoff points between tools
• Consistent UX patterns

Example: Bug Diagnosis Suite Integration

Integrated workflow:
1. Bug report ingested → Auto-classification tool
2. If classified as "likely real bug" → LogAnalyzer tool
3. LogAnalyzer output → SimilarBugFinder tool
4. Combined results → CodeImpactAssessor tool
5. All outputs → Human developer for final diagnosis

Handoff protocol:
- Each tool outputs confidence score
- Below threshold → human review required
- Tool failures → graceful fallback to next tool or manual process

Phase 3: System optimisation (Weeks 13-24)

With tools working independently, you can start optimising the system as a whole.

Optimisation areas:

• Tool sequencing for maximum efficiency
• Confidence scoring refinement
• Error handling improvement
• Performance optimisation
• User experience flow

Feedback loop implementation:

• Track where humans override AI suggestions
• Identify common failure patterns
• Retrain models based on real usage
• Add new tools for identified gaps

Phase 4: Verification and scaling

Verification system components:

1. Output validation: Automated checks that output makes sense
2. Human feedback loops: Easy ways for users to mark outputs as correct/incorrect
3. Performance monitoring: Track accuracy, speed, user satisfaction
4. A/B testing: Compare AI-assisted vs manual workflows
5. Error analysis: Regular review of failure cases

Scaling considerations:

• Model performance with increased usage
• Infrastructure costs vs value delivered
• Team training on new tools
• Integration with existing systems

Real implementation cases of JTBD+AI

Case 1: Customer Support Ticket Classification

Job identified: “When a customer support ticket arrives, I want to classify it correctly in less than 1 minute, so I can route it to the right team immediately.”

Current workflow pain: Support agents spent 15-20 minutes reading context and deciding routing. Many tickets mis-routed.

JTBD-based solution:

• Tool 1: Ticket content analysis → suggests department + priority
• Tool 2: Customer history lookup → provides context
• Tool 3: SLA calculator → estimates response time needed

Results after 6 months:

• Classification time: 20 min → 2 min
• Routing accuracy: 73% → 94%
• Customer satisfaction: +31%
• Agent productivity: +67%

Case 2: Code Review Security Scanning

Job identified: “When reviewing a PR, I want to automatically identify potential security vulnerabilities, so I can focus my review on business logic.”

Current workflow pain: Security review required deep expertise and lots of time. Many vulnerabilities not detected.

JTBD-based solution:

• Tool 1: Static code analysis → identifies potential issues
• Tool 2: Pattern matching → compares against known vulnerability patterns
• Tool 3: Context analyser → evaluates risk level based on code location

Results after 8 months:

• Security issues detected: +187%
• False positive rate: under 15%
• Review time: -40%
• Developer adoption: 91%

Case 3: Sales Proposal Generation

Job identified: “When I need to create a proposal for a prospect, I want to generate a customised first version in 30 minutes, so I can focus on refinement and personalisation.”

Current workflow pain: Proposals took 4-6 hours of manual work. Lots of error-prone copy-paste.

JTBD-based solution:

• Tool 1: Company research → pulls public information + news
• Tool 2: Template selector → chooses best proposal template
• Tool 3: Content customiser → adapts language to industry + company size
• Tool 4: Pricing calculator → suggests pricing based on scope

Results after 4 months:

• Proposal creation time: 6 hours → 45 minutes
• Win rate: +23%
• Proposal accuracy: +41%
• Sales team adoption: 87%

Common mistakes and how to avoid them

Mistake 1: Trying to automate everything

Wrong approach: “Let’s automate the entire diagnosis workflow with AI”

Right approach: “Let’s use AI to accelerate the parts of the workflow where pattern recognition adds value”

Why it matters: Full automation often fails because edge cases, context changes, and human judgement remain necessary.

Mistake 2: Building before validating

Wrong approach: Spend 3 months building sophisticated system before testing with users

Right approach: Build minimal version of one tool, test immediately, iterate

Why it matters: Assumptions about user workflows are often wrong. Early feedback prevents wasted effort.

Mistake 3: Ignoring verification

Wrong approach: Assume AI output is always correct

Right approach: Build verification mechanisms from the beginning

Why it matters: Trust in AI tools comes from reliability, not just capability.

Mistake 4: Generic over specific

Wrong approach: “Our AI assistant can help with any developer task”

Right approach: “Our tool reduces bug diagnosis time by analysing logs and finding similar historical bugs”

Why it matters: Specific tools with clear value props get adoption. Generic tools get ignored.

Metrics and measurement

Leading indicators (measure during development)

• Tool usage frequency: How often users choose the AI tool vs manual process
• Completion rate: Percentage of times users complete the full AI-assisted workflow
• Override rate: How often users ignore AI suggestions
• Error detection rate: How quickly users identify AI mistakes

Lagging indicators (measure impact)

• Task completion time: Total time reduction to complete the job
• Quality improvement: Fewer errors, better outcomes
• User satisfaction: NPS score specific to AI tools
• Business impact: Revenue/cost impact attributable to AI tools

Measurement framework

Weekly tracking:
- Usage patterns per tool
- Success/failure rates
- User feedback collection

Monthly analysis:
- Workflow efficiency improvements
- Tool performance trends
- User behaviour changes

Quarterly review:
- Business impact assessment
- ROI calculation
- Strategy adjustment planning

Conclusion

The difference between AI tools that transform workflows and those that remain impressive demos is simple: JTBD thinking.

The non-negotiable principles:

1. Job clarity: Define specifically what work will be performed
2. Workflow understanding: Map current state completely before optimising
3. Specific tools: One tool, one job, very well done
4. Verification systems: Build trust through reliability
5. Iterative improvement: Start small, measure, learn, expand

Don’t build AI because you can. Build it because there’s a specific job that needs to be done better, faster, or cheaper than how it’s currently done.

Teams that master JTBD-first AI development will create tools their users can’t live without. Those who start with AI-first thinking will create impressive demos nobody uses.

Your choice will determine whether you build transformative tools or expensive toys.

Is your team building AI without clear Jobs to Be Done?

We facilitate JTBD workshops applied to AI projects. In 4 hours we define specific jobs, map current workflows, and design tools that actually solve problems.

Request JTBD + AI workshop →