Example: Food Delivery Service
A complete walkthrough showing how jobs, competing solutions, steps, and resources work together
lightbulb The Central Concept
In JTBD, jobs are stable but solutions compete. This food delivery example demonstrates the complete model: one stable job with multiple competing solutions, each with different steps and resources.
1 Job
Stable, timeless goal
Multiple Solutions
Competing approaches
Different Steps
Each solution has its own process
The Complete Food Delivery Model
This is the structure as it appears on the Blueprint: who is served, what they need done, and — once a job is selected — the competing solutions with their steps and resources.
The food delivery workspace on the Blueprint: the "Food App Customer" segment breaks down into a sub-segment, which links on to its four jobs. Each kind of connection leaving a card gets its own small box below it, counting what hangs beneath through that connection, and every line starts at the box that counts it. Clicking a job below opens its competing solutions. (Click to zoom)
Why Multiple Solutions?
The job "Deliver food to customer" hasn't changed in 1000 years. But the solutions have evolved dramatically: from walking, to horse, to bicycle, to car, to drone. Each solution competes to accomplish the same stable job.
work The Stable Job
Job: Deliver Food to Customer
This is the stable, timeless goal. Whether it's 1024 AD or 2024 AD, the fundamental job remains the same: get food from point A to point B reliably and safely.
Job Characteristics
- • Functional: Physical task with clear success criteria
- • Stable: Doesn't change over time or with technology
- • Solution-agnostic: Doesn't specify HOW to accomplish it
- • Universal: Same job for restaurants, platforms, and customers
Why This Matters
By keeping jobs stable, you can compare solutions across time. "Is drone delivery better than car delivery?" is a meaningful question because they're solving the same job.
Job Statement
When a customer places a food order,
I want to deliver it to their location,
So I can fulfill their expectation for fresh, hot food delivered on time.
What this job is NOT:
- ❌ "Deliver food by car" (too specific - that's a solution)
- ❌ "Manage delivery fleet" (that's a different job)
- ❌ "Track delivery status" (that's a supporting job)
compare_arrows Three Competing Solutions
Each solution is a different approach to accomplishing the same job. They compete based on cost, speed, reliability, range, and other factors.
Solution 1: Car Delivery
Advantages
- ✓ Large capacity (multiple orders per trip)
- ✓ Weather-resistant
- ✓ Established infrastructure (roads, traffic rules)
- ✓ Human driver can handle exceptions
Disadvantages
- ✗ Traffic congestion delays
- ✗ High labor costs
- ✗ Parking challenges in cities
- ✗ Carbon emissions concerns
Typical firing trigger: "Switched to drone delivery due to chronic traffic delays during peak hours"
Solution 2: Drone Delivery
Advantages
- ✓ No traffic - direct line delivery
- ✓ Low operational costs (no driver)
- ✓ Fast for short distances
- ✓ Environmentally friendly (electric)
Disadvantages
- ✗ Limited payload capacity
- ✗ Weather-dependent (wind, rain)
- ✗ Regulatory restrictions
- ✗ Limited range on battery
Typical hiring trigger: "Hired drone delivery for dense urban areas where traffic makes car delivery unreliable"
Solution 3: Bicycle Delivery
Advantages
- ✓ Low cost (no fuel, low maintenance)
- ✓ Agile in dense urban areas
- ✓ Eco-friendly
- ✓ No parking issues
Disadvantages
- ✗ Limited to short distances
- ✗ Weather-dependent
- ✗ Physical strain on riders
- ✗ Small capacity
Best for: Dense urban centers with short delivery distances (under 2 miles)
The Competition is Real
Notice how these three solutions compete on different dimensions: cost vs. speed vs. capacity vs. reliability. A delivery company might use ALL three solutions simultaneously, choosing the best one for each order based on distance, weather, urgency, and item size.
checklist Different Solutions = Different Steps
This is critical: each solution has its own unique process steps. The steps belong to the solution, not to the job. Car delivery steps are completely different from drone delivery steps.
Each solution keeps its own steps under its own tab — switch tabs and the step sequence and staged resources change with it. (Click to zoom)
directions_car Car Delivery Steps
- Accept order assignment (input: order details)
- Navigate to restaurant (resource: GPS app)
- Pick up food (output: secured order)
- Navigate to customer (resource: GPS app)
- Find parking near destination
- Deliver to door (output: completed delivery)
flight Drone Delivery Steps
- Pre-flight system check (resource: Flight Controller)
- Load food into drone payload bay
- Launch and ascend to cruise altitude
- Autonomous flight to destination (resource: GPS Navigation)
- Descend to landing zone
- Release payload (output: delivered order)
- Return to base
Both lists read as a straight sequence, one step after the next — but real processes rarely stay that tidy. While the drone runs its pre-flight check, the kitchen is still packing the order, and the two wait on each other only at the payload bay. Sub-steps like those go on separate branches under the step they hang off, and the board draws them side by side; sub-steps that genuinely follow one another share a single branch and are drawn as one run. It matters for improvement work: a sequence is as long as the sum of its steps, while parallel branches are only as long as the slowest one.
Why This Matters
When you're improving a delivery service, you need to know WHICH solution you're optimizing. The pain points, bottlenecks, and improvement opportunities are completely different:
- • Car delivery pain point: Traffic delays between pickup and delivery
- • Drone delivery pain point: Landing zone obstacles at customer location
These are the same job, but completely different problems to solve!
inventory_2 Resources: Bidirectional Visibility
Resources (tools, systems, documents) are shared across solutions. This is where RoleDream's bidirectional visibility shines: you can see which solutions depend on each resource.
The "Food Delivery Platform" resource is used by all three solutions. Click the resource to see which solutions depend on it - this reverse lookup is unique to RoleDream. (Click to zoom)
Shared Resources
Food Delivery Platform, Order Management System
Solution-Specific
Flight Controller (drone), Vehicle (car), Bicycle (cyclist)
Common Tools
GPS Navigation, Communication App
Impact Analysis
Question: "If we deprecate the Food Delivery Platform API, what breaks?"
Answer (from bidirectional view): All three solutions (car, drone, bicycle delivery) depend on it. You'd need to migrate all three to a new platform.
timeline Tracking Solution Evolution
Over time, companies hire and fire different solutions. RoleDream tracks this evolution through Hiring Decisions , creating institutional memory of what worked and what failed.
The real thing: hiring decisions for "Order food for delivery" — hires and fires per solution, dated and tagged to the interviews behind them. (Click to zoom)
Example Evolution Timeline
2020: Hired Car Delivery
Initial solution for metro area coverage
2021: Hired Bicycle Delivery
Added for dense downtown areas (< 2 miles)
2023: Switched to Drone Delivery (Pilot)
Trigger: Peak hour traffic causing 45+ min delays
Previous: Car delivery in suburban zones
2024: Fired Walking Delivery
Reason: Too slow, limited range, courier burnout
Why track this? It creates institutional memory. When someone asks "Why aren't we using walking delivery?", the answer is documented: "We tried it in 2020-2024, fired it due to courier burnout and limited range."
school Key Takeaways
Jobs are stable, solutions compete
"Deliver food" is timeless. Car vs. drone vs. bicycle are competing solutions that evolve.
Each solution has unique steps
Steps belong to solutions, not jobs. Drone steps are completely different from car steps.
Resources enable bidirectional visibility
View a resource to see which solutions depend on it. Critical for impact analysis.
Track what works and what fails
Hiring decisions create institutional memory of solution evolution over time.