How RoleDream Connects Them

Bridging the gap between customer motivation (JTBD) and service delivery (Service Design)

The problem

The Gap Between Frameworks

Jobs To Be Done and Service Design are both powerful frameworks, but they traditionally focus on different questions:

JTBD: The "WHY"

Jobs To Be Done answers why customers choose solutions:

What job is the customer trying to get done?
What are the competing solutions?
Why do they hire or fire each solution?
What are the customer's desired outcomes?

Great for: Understanding motivation, prioritizing features, finding innovation opportunities

Service Design: The "HOW"

Service Design answers how services are delivered:

How do multiple teams and systems coordinate to deliver value?
What are the frontstage and backstage activities?
What touchpoints and channels are involved?
What support systems enable the service?

Great for: Mapping operations, improving delivery, coordinating teams

The Problem

Most tools force you to pick one framework or the other. You can understand customer motivation OR map service delivery, but not both at once. This creates a gap: you might know what customers want but not how to deliver it, or you might optimize operations without understanding what truly matters to customers.

The answer

RoleDream's Unified Model Bridges Both

RoleDream doesn't make you choose. Instead, it uses a unified data model that can be viewed through either lens—or both simultaneously.

The Same Data, Two Perspectives

Unified Data Model

Jobs, Solutions, Steps, Resources

View as JTBD

View as Service Design

💡 Key Insight

When you model a customer job in RoleDream, you're simultaneously capturing what customers want (JTBD) and how the service delivers it (Service Design). Change perspective, and the same data answers different questions.

The mapping

Side-by-Side: The Same Data, Different Lenses

Here's how RoleDream entities serve both perspectives:

Entity	Customer Perspective (JTBD)	Delivery Perspective (Service Design)
Job	Stable customer goal "Get lunch quickly during work hours"	What the service must deliver The need that segments organize around on the Blueprint
Solution	What gets hired/fired "Food delivery app" vs. "Microwave meal" vs. "Food truck"	Service journey for this segment The complete customer experience or staff workflow
Solution Step	Process steps "Browse menu" → "Place order" → "Track delivery" → "Receive food"	Frontstage touchpoints Customer-facing interactions and visible activities
Resource	Tools and support needed "Mobile app", "GPS tracking", "Payment method"	Backstage support Infrastructure, systems, and physical evidence
Hiring Decision	Why customers switch "Hired delivery app because more convenient than going out"	Service transition triggers Critical moments that cause users to change services

Example

Practical Example: Food Delivery (Both Perspectives)

Let's see how the same RoleDream data answers different questions depending on your perspective:

Viewing as JTBD: Understanding Customer Motivation

Job: "Get lunch quickly during work"

A stable goal that doesn't change with technology

Competing Solutions:

• Food delivery app (convenient but expensive)
• Microwave meal from convenience store (fast but limited quality)
• Nearby food truck (good quality but weather-dependent)
• Skip lunch (free but unsatisfying)

Hiring Decision: Why they chose delivery app

"I hired the delivery app because I have back-to-back meetings and can't leave my desk. The push/pull forces: Push away from food truck (can't leave office), Pull to delivery app (brings food to me), Anxiety (will food arrive on time?), Habit (I'm used to going out for lunch)."

JTBD Questions Answered: What job is being done? What solutions compete? Why did customers switch? What outcomes matter most?

Viewing as Service Design: Mapping Service Delivery

Actors (Segments):

• "Hungry Customers" - the segment being served
• "Chefs" - segment preparing orders
• "Delivery Drivers" - segment transporting food
• "Platform Operations" - segment managing infrastructure

Customer Journey (Frontstage Touchpoints):

1. Browse restaurants and menu in app (touchpoint: mobile app)
2. Place order and pay (touchpoint: checkout flow)
3. Track order status (touchpoint: live tracking map)
4. Receive delivery (touchpoint: driver handoff)

Backstage Support Processes:

• Payment processing system (invisible to customer)
• Order routing algorithm (assigns orders to drivers)
• Restaurant POS integration (syncs menu and availability)
• GPS tracking infrastructure (powers live tracking)

Service Design Questions Answered: How do the actors coordinate? What are the touchpoints? What happens backstage? Where can operations be optimized?

In practice

When to Use Which Perspective

Start with JTBD When:

You're trying to understand customer motivation
You're prioritizing features or finding product-market fit
You want to identify competing alternatives (including non-consumption)
You're looking for innovation opportunities

Then switch to Service Design view to see how to deliver what customers need.

Start with Service Design When:

You're mapping or improving existing operations
You need to coordinate multiple teams or systems
You're identifying pain points in touchpoints or handoffs
You're designing a new service from scratch

Then switch to JTBD view to validate that you're solving the right job.

Hiring decisions

The Hiring Model in Action

RoleDream's hiring decisions feature is a perfect example of synthesis. It captures both:

JTBD View

Why customers hired, fired, or switched solutions based on push/pull/anxiety/habit forces

Service Design View

When users transition between services, revealing critical touchpoints and triggers

The Power of Both

By capturing hiring decisions, you understand both the motivation (JTBD) and the moment of transition (Service Design). This dual insight is impossible with either framework alone.

Ready to Experience Both Perspectives?

Open the Blueprint and see how the same canvas can answer both "Why do customers choose this?" and "How do we deliver it?"

Open Blueprint