A Job to be Done (JTBD) is a framework, or lens, for viewing products and solutions in terms of the jobs customers are trying to achieve. It's about understanding the goals that people want to accomplish. It lets us step back from our business and understand the objectives of the people we serve. It opens the door to innovation.
At GitLab, we have our own flavor of JTBD and use it throughout the design process, but most notably to:
JTBD come directly from research and customer conversations with those people who do the tasks/jobs we need to design for. Problem validation is one of the most effective ways to confidently inform the writing of a JTBD.
To learn more about our JTBD philosophy, see the JTBD deep dive and How to create a Job Map
You can also watch the following video for a brief overview of why JTBD are so valuable in the product development process:
All GitLab Jobs to be Done can be found in the jobs-to-be-done.yml file.
First, let's set the terminology we use for JTBD.
When we refer to JTBD in our work at GitLab, we are referring to the job statement. A job statement provides the context of what is happening while someone is trying to accomplish a goal. In contrast, a job is only the thing they want to accomplish. A job statement includes: the job, the situation, and the outcome.
In the broader industry, what we call a job statement is usually referred to as a job story. Why do we call job stories "job statements" at GitLab? Because "job stories" sounds too similar to "user stories," and we tend to fall into the trap of writing those, instead. That doesn't give us room to innovate and ensure that we're helping people accomplish the job.
We write our job statements using the standard format:
"When [situation], I want to [job], so I can [outcome]."
JTBD are difficult to get right. Before you begin, you have to have a clear understanding of what someone is wanting to accomplish, and that understanding should be validated with past research and customer conversations.
It is crucial to ensuring that the job statements are grounded in experience and not theory. We must have a high level of confidence in our job statements before we can put them into use.
Job statements can be written at different levels or altitudes.
To help determine longer-term product direction, JTBD can be written for an entire stage or across multiple stages.
A main job is often expressed as a utilitarian goal. It’s an act that will be performed and should have a clear end state—the “done” part of JTBD. It shouldn’t include adjectives like quick, easy, or inexpensive (because those are considered to be needs) or the metrics by which job performers compare solutions (this is handled separately). The main job is also different from your marketing message or value proposition statement, which tends to be persuasive to evoke an emotion.
Don’t define a main job too narrowly. A small job will limit your field of vision, but also will constrain your efforts. When in doubt, go broader, and define a main job that is larger rather than smaller. Ask “why?” and “how?” to move the level of granularity of the main job up or down.
Example: Release secure code
For the majority of our work, we write job statements for stage groups as we craft experiences for features or sets of related features. If you're writing a job statement for your stage group, consider this guiding principle to determine the appropriate altitude: If the job is applicable to more than 3 user types, it's likely the altitude is set too high for a sub-job (consider whether it is a main job, instead).
Examples: Identify vulnerabilities that can lead to an exploit; Identify applications most at risk in an organization
Often, we find there are many JTBD for one category. We are striving to have 2-3 JTBDs per category, at the most. Using user research to help determine which JTBD are the most crucial to our users can help when planning for future research, design, and product needs.
Read "What is and isn't a JTBD".
Job statements are different than user stories and tasks. They are designed to be persona, product, and solution agnostic and have a close relationship with user stories and tasks. This allows us to think more deeply about the context, rather than just a role with a goal.
Example:
In its most basic form, you will have a job statement that is associated with one or more user stories that are made up of multiple tasks. You'll use each of these at different moments within the design process.
Job statements offer a high-level view of the main objective. User stories guide your solutions as you create wireframes and tasks become the steps required to complete the job.
If you want a detailed breakdown of each segement of the job statement, learn more about the structure of a JTBD.
