Jobs to be Done at GitLab

The material in this page and related pages (Playbook, Beyond the Playbook) draws from Jim Kalbach and his book, “The Jobs to be Done Playbook”.

For practical JTBD research guidance, see the playbook.

Note: The previous JTBD source (yml file, internal only) is being replaced. Teams should track JTBD work in FigJam until a new handbook page is created.

Anatomy of a JTBD Canvas

A Job to be Done Canvas organizes the elements of a Job Performer’s Main Job for easy iteration, sharing, and documentation. We use canvases in our JTBD playbook within our FigJam template.

The Domain: Where do you want to innovate?

Start by identifying the relevant area within your Stage Group to help determine who you’re innovating for and what they need to accomplish.

Job Performer: Who do you want to innovate for?

A Job Performer is the person executing a specific job, distinct from their job title. After identifying your domain, focus on one Job Performer aligned with the Main Job.

Key characteristics:

• Describes an individual role, not a job title
• Avoids compound descriptions (no AND/OR)
• Remains high-level, not a detailed persona
• Simple and directly connected to the target job

[Optional] Related Job Performers: Who affects our Job Performer?

Identifying other actors who relate for your Domain can provide valuable context and aide in selecting a primary Job Performer. Once a Job Performer is selected, these related Job Performers can be documented and explored with their own canvases later if needed.

Job Performers vs. Personas

While user personas represent job titles (like “Software Developer”), Job Performers focus on specific tasks within roles. One persona may handle multiple Main Jobs (coding, reviewing, maintaining infrastructure), and different personas may share the same Job Performer role. For example, various roles might review code, but we’d use a single “Code Reviewer” Job Performer to understand that specific task.

Main Job: What is the Job Performer trying to get done?

A Main Job is a timeless, functional goal that serves as the focus for innovation, representing what the Job Performer wants to accomplish independent of any specific solution.

Key characteristics:

• Begins with an action verb
• Has a clear end state
• Avoids compound descriptions (no AND/OR)
• Remains solution and technology agnostic
• Excludes adjectives (which belong in Outcomes)
• Stays broad enough to allow innovation

Structure: [verb] + [object] + [optional clarifier]

• Verb: Action to accomplish
• Object: Target of the action
• Clarifier: Additional context or conditions

Related Jobs: What else is the Job Performer trying to get done?

Consider 3-6 other goals the Job Performer has within the Domain. They should be distinct objectives and forumlated at a similar level of detail. These Related Jobs can be explored with their own canvases later if needed.

Aspirations: What does the Job Performer aspire to become?

Aspirations are typically 1-3 “be” goals representing the Job Performer’s desired personal growth from completing the Main Job. They sit at the top of the canvas, hierarchically above the Main Job.

Example hierarchy for home ownership:

• Job Performer: New homeowner
• Aspirations: Be happy with home life, Be part of a local community
• Main Job: Acquire a new home
• Related Jobs: Finance a new home, Move homes, Sell old home

Job Steps: How does the Job Performer get the job done?

Job Steps are the sequential objectives a Job Performer must complete to accomplish their Main Job. They form a Job Map, with each step being high-level rather than individual tasks. Keep steps broad enough to apply to all performers of the job.

Key characteristics:

• Begins with an action verb in first person
• Avoids compound descriptions (no AND/OR)
• Remains solution agnostic
• Flows left to right through stages
  • Sub-steps stack vertically within each stage

Outcomes: How does the Job Performer measure success?

Outcomes are the subjective criteria Job Performers use to gauge success. A Main Job typically has 50-100 Outcome statements.

Key characteristics:

• Begins with a directional verb (minimize, increase, etc.)
• Includes a measurable unit (time, effort, likelihood)
• Ends with job-specific qualifiers
• Avoids compound statements (no AND/OR)
• Remains solution agnostic

Emotional/Social Aspects: How does the Job Performer feel and want to be perceived?

Emotional and social aspects represent the experiential side of the job, helping shape how solutions should be delivered to meet Job Performers’ personal needs.

Key characteristics of Emotional aspects:

• Begins with “feel” or “avoid feeling”
• Indicates a specific emotion
• Avoids compound statements (no AND/OR)
• Remains solution agnostic

Key characteristics of Social aspects:

• Begins with “appear as” or “avoid appearing as”
• Indicates social perceptions
• Avoids compound statements (no AND/OR)
• Remains solution agnostic

Understanding these aspects helps design solutions that address both functional and personal needs - like adding time-saving features for programmers concerned about appearing efficient.

Job Differentiators: What factors influence how the job gets done?

Job Differentiators are circumstances that affect how the job is performed, typically involving time, manner, or place.

Key characteristics:

• Begins with “if”
• Shows range of options using “versus/vs”
• Avoids compound statements (no AND/OR)
• Remains solution agnostic

These differentiators can help narrow the Main Job’s scope (e.g., “get energy in the morning” vs. “get energy in the afternoon at work”).

Main Jobs to micro jobs

When talking about Jobs to be Done, we’re often talking about different levels of jobs. It’s important to note the differences in terminology between these levels so that you and your stakeholders can communicate effectively.

Main Jobs

A Main Job is a means to an end. It’s an act that will be performed and should have a clear end state (the “done” part of JTBD). That is why we write jobs in the pattern Verb + Object + Clarifier when writing job statements.

Example: Buy a new home

Small jobs

Small Jobs are more practical and correspond to a process or workflow. They answer the question, “How does the job get done?” in the context of the Main Job and moves the user closer to accomplishing their goal.

Example: Put in an offer on a house

Micro-jobs

Micro-jobs are the small tasks a user may undergo to accomplish their small job and Main Job. Micro-jobs should be self-explanatory and easy to understand without much context.

Example: Decide how much you’re going to offer in relation to the asking price.

It’s important to be able to identify and correctly place jobs at the right altitude as you work through the Jobs to be Done process. It will help keep you focused on the Main Job and allow you to quickly incorporate (or discard) new information that you hear during interviews into your job steps.

Job Stories

Job Stories synthesize data from your Job Canvas to encapsulate customer pain points without prescribing solutions. They help align development with company vision and strategy. Each domain typically has 3-5 Job Stories.

Key characteristics:

• Evidence-based from Job Canvas data
• Specific about the pain point
• Builds empathy through context
• Aspirational but achievable
• Self-evident and well-researched

Pain points must:

• Express needs, not solutions
• Be concrete, not abstract
• Be measurable, not anecdotal

Job Story Format

1. When I [at this Job Step] + [under the conditions of these Job Differentiators]
2. I want [this New Ability/customer imperative]
3. So I can [reach these Outcomes] + [and have these Emotional/Social Aspects]

Ways to use Job Stories

• Generate How Might We (HMW) statements
• Define Design Sprint challenges
• Create testable MVP hypotheses:
  • We believe that [job performers]
  • Will achieve [desired outcome]
  • While performing [job step]
  • Using [proposed solution].
  • Success will be evidenced by [specific measure]
• Ensure issues are solving validated problems
• Define usability testing criteria

View page source - Edit this page - please contribute.