Jobs to be Done at GitLab

JTBD is a framework for viewing products and solutions in terms of jobs customers want to achieve. It’s about understanding the goals that people want to accomplish.

Jobs to be Done (JTBD) is a framework for viewing products and solutions from the user’s perspective. It’s about understanding what people want to achieve so we can build a better solution that reflects those desires. The purpose of these materials is to empower GitLab team members to uncover user needs, identify strategic opportunities, validate existing plans, and open the door to innovation.

Much of what follows on this page and our other JTBD pages (Playbook, Deep Dive) borrows heavily from Jim Kalbach and his book, “The Jobs to be Done Playbook”.

This page covers the ‘what’ of Jobs to be Done. To skip to the ‘how’, or the practice of doing Jobs to be Done research, head over to the playbook.

Note: the previous single source of truth for all the JTBD at GitLab (a yml file, internal only) is in the process of being replaced. In the meantime, GitLab teams performing JTBD should keep track of their playbook work in FigJam. A handbook page containing all the JTBD will be created shortly.

Anatomy of a JTBD Canvas

A Job to be Done Canvas is a way to arrange all of the elements of a main job in an easy to read format, well-suited for iteration, sharing, and documentation. We use canvases throughout our JTBD playbook, as part of our FigJam template. Each canvas has a number of different sections which combine to provide a holistic picture of a main job and its job performer. It can be a bit daunting, so here’s a breakdown of each part:

JTBD canvas

Main Job: Where do you want to innovate?

The main job serves as the central focus for innovation efforts. It represents a goal and has specific criteria. It should be formulated using action verbs, without references to technology, solutions, or methods, and avoid complex combinations. It follows a pattern of ‘verb + object + (optional) clarifier’. The level of granularity for the main job can vary, depending on the innovation’s purpose and feasibility. If the main job isn’t obvious, move to the related jobs field on the canvas to explore the domain.

Main jobs hint at a task that can be completed, for example:

  • Buy (verb) a new home (object) within 10 minutes of my work (clarifier)
  • Write (verb) a book (object)
  • Ensure (verb) code changes (object) meet organizational standards (clarifier)

Bad examples:

  • Purchase the house at 123 Main Street for less than asking. (Too specific)
  • Be a best selling author (Aspirational goal, but not a main job)

Job Performer: Who do you want to innovate for?

To innovate effectively, start by identifying and understanding the specific job performer for the task, emphasizing that it refers to the person executing the job. Focus your research on one job performer at a time and align it with the main job, ensuring a clear and straightforward approach. A job performer is rarely the same as someone’s job title.

For the examples above, our job performers would be:

  • New home buyer
  • Author
  • Code reviewer

Bad examples:

  • Millionaire real estate investor (being a millionaire real estate investor is a relevant circumstance to how the job gets done, and what kind of homes they would be looking for, but this doesn’t describe the main job that’s getting done – this person could be buying, selling, renovating, etc.)
  • Steven King (job performers are not a specific person)
  • Software Engineer (job title, not a job performer)

Note: Job Performers vs. Personas

A common area of confusion is the difference between a job performer and a user persona. In short, a persona is more or less at the level of a job title, a Software Developer, for instance. However, a software developer may take on a number of different main jobs as part of their role (writing code, reviewing code, maintaining infrastructure, and so on). Similarly, other job titles or personas may also do the main jobs we look at in JTBD (an engineering manager may also review code, for example).

Both personas and job performers are useful constructs in helping to understand and improve your product, but it is important not to conflate the two. Job performers in the JTBD framework don’t correspond to job titles (some exceptions apply) - they tend to live ‘closer’ to the main job we’re investigating. For instance, we might have a dozen personas that each ‘review code’ as part of their jobs - but if the experience of reviewing code is the one we’re focused on we only need to have one job performer - a ‘code reviewer’ - that encapsulates what all of these different personas have to go through in order to do that part of their jobs.

Outcomes: How does the job performer measure the success of getting the job done?

Outcomes represent how the job performer gauges the success of completing the main job and are often subjective. An outcome statement is a sentence with a specific formula:

  1. A verb indicating a direction of change (e.g., minimize, reduce, decrease).
  2. A unit of measure, often time, effort, or likelihood.
  3. Qualifiers that make the outcome statement specific and relevant to the target job.

For example:

  • Minimize (direction) the time it takes (measure) to identify a potential new home (qualifiers)
  • Reduce the number of compromises made when deciding on a new home
  • Minimize the distance to the place of employment

These outcome statements provide insights into the job performer’s criteria for success in accomplishing the job.

Bad examples:

  • Find the best home quickly (Why? No verb indicating direction, ‘best’ is not specific enough to be useful.)
  • Have the most attractive house on the street (Why? No direction, ‘most attractive’ is not a good unit of measure.)

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

Job steps detail the sequential process through which a job performer accomplishes their task, forming a chronological job map. These steps typically begin with a first-person action verb, exclude references to technology, solutions, or methods, and avoid using “ANDs” or “ORs” for conciseness. Being product agnostic is critical to understanding the core of a job, and not simply how your users use your product.

For example:

  • Decide where to look for a new home
  • Determine selection criteria
  • Seek new homes
  • Transfer home ownership

Bad example:

  • Ask Richard what neighborhoods are popular to live in (Who’s Richard? Does everyone who does this job have a Richard? Too specific.)

Emotional and Social Aspects: How does the job performer feel while doing the job? How do they want to be perceived while doing the job?

When considering the emotional and social aspects of the job, explore how the job performer feels during the task and how they aim to be perceived. These are sort of the ‘experiential’ side of the job, as opposed to the functional aspect of the job. It’s important to solve for the functional side of the job first (without it you’re not really solving the core unmet need), and then consider the emotional and social aspects afterwards.

Understanding the emotional and social aspects of the job helps to determine how potential solutions could be delivered, and how to ensure the job performer’s needs are met.

Emotional aspects typically start with “feel” or “avoid feeling,” while social aspects often begin with “appear as” or “avoid appearing as.” For example:

Emotional Aspects:

  • Feel in control of the home acquisition process
  • Avoid feeling uncertain about new home selection

Social Aspects:

  • Appear as a good future neighbor
  • Avoid appearing unknowledgeable about the new home acquisition process

These aspects can vary widely and provide insights into the job performer’s emotional and social motivations and challenges, which can be crucial in determining how potential solutions ought to be delivered. For example, if a programmer is worried about appearing fast to his coworkers, we can design a solution that includes lots of time-saving features (code completion, AI summarization, other automatic actions, and so on).

Circumstances: What are the factors or conditions that make a difference in how the job gets done?

Circumstances are the factors that influence how the job gets done. They often encompass time, manner, or place, among other characteristics. Circumstances are introduced with the word “if”, indicate a range of options, and use “versus/vs.” when applicable. For our real estate example, circumstances might include:

  • If the job performer is single vs. married
  • If the job performer has young children or not
  • If the potential new home is local (within driving distance) vs. far away from the current location

Additionally, you can qualify the main job in order to narrow its scope, such as “get energy in the morning” or “get energy in the afternoon at work.” These are often called job differentiators, and provide a more focused perspective on the target job.

When considering innovation, it’s essential to explore the additional goals that job performers have within the domain – known as related jobs. These related jobs are distinct objectives, each with its own distinct phases, and should be formulated at a similar level of detail for comparison, typically numbering between 3 to 6 per job performer. For our aspiring homeowners, related jobs may include:

  • Finance a new home
  • Move homes
  • Sell old home

Aspirations: What does the job performer aspire to become by doing the job?

Aspirations represent the “be” goals of the job performer, signifying their desire for personal growth or transformation while completing the job. These aspirations should be derived from conversations with job performers and are placed at the top of the canvas as they hold a hierarchical position above the target job. Typically, there are 1 to 3 aspirations associated with any target job. For instance, in the context of a real estate organization, potential top-down elements for innovation related to “home ownership” could include:

  • Job performer: New homeowner
  • Target job: Acquire a new home
  • Related jobs: Finance a new home, Move homes, Sell old home
  • Aspirations: Be happy with home life, Be part of a local community

Actors (optional): Who affects our job performer when doing their job?

It may help to think about the other actors or job performers that relate to your main job performer. Who does the job performer interact with in the course of performing their tasks? Where does information (or responsibility) reside before or after the main job? The related job performers or actors are often those performing the related jobs.

So, if the related jobs are: Finance a new home, Move homes, Sell old home

The related job performers might be: Mortgage broker, Real Estate Agent, Mover

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.

JTBD hierarchy diagram

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.


How we do JTBD research at GitLab (A Playbook)
GitLab follows a series of steps and exercises to discover and develop job canvases from basic assumptions all the way to validated and ranked outcomes and opportunities.
JTBD - Beyond the Playbook
JTBDs can be used to clarify and refine strategic opportunities in many of the research and design activities GitLab conducts.
Validated GitLab JTBD Canvases and Opportunity Scores
This page contains links to the JTBD canvases that have gone the GitLab JTBD Playbook process and the top outcome statements and opportunity scores from those canvases.