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 story. A job story 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 story includes: the job, the circumstance, and the need.
We write our job stories using the standard format:
"When [Circumstance], I want to [job], so I can [need/outcome]."
Example: When I am on triage rotation, I want to address the business-critical risks in my organizations assets, so I can minimize the likelihood of a security incident.
Job stories are modular, allowing us to innovate and solve problems in different ways. A practical application of this flexibility is to craft the job story at a lower altitude making it more applicable to the problem area we are addressing. Keep in mind that the circumstance and need will not change from the main job story; however, by including more detail in the form of the job stage or step [small job(s)] and narrowing our job (I want to) down to the micro-job level, we achieve a job story that can guide our work more tactically.
"When [Circumstance + job stage/step], I want to [micro-job], so I can [need]
Example: When I am on triage rotation and prioritizing business-critical risks, I want to review the most recent risks detected in my assets, so I can minimize the likelihood of a security incident.
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 stories are grounded in experience and not theory. We must have a high level of confidence in our user's jobs, circumstances, and needs before we can put them into use.
Job stories can be written at different levels or altitudes. For the majority of our work, we write job stories for stage groups as we craft experiences for features or sets of related features. If you're writing a job story 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 small job (consider whether it is a main job, instead).
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?” to move higher in altitude during interviews, and “how?” to lower the altitude of the main job.
Example: Address business-critical risk in my organization's assets.
Small jobs are more practical and correspond to the main job's stages or steps. Small jobs answer the question, "How does the job get done?" in the context of the main job and approximate the process a user moves through to accomplish their goal. Each job step is a small job.
Examples: Prioritize business-critical vulnerabilities in my assets; Determine the impact of a business-critial risk in my application; Escalate a business-critical risk for remediation.
Tasks a user may undergo to accomplish their small job. At this level, we define the sub-processes or actions a user will take to complete a step (small job) of their main job.
Examples of tasks related to the small job, Prioritize business-critical vulnerabilities in my assets; Review the most recent risks detected in my assets; Refine the list of risks by relevancy; Refine the list of risks by impact.
Using our examples, we can produce a JTBD hierarchy, confirming we operate at the right altitude.
JTBD hierarchy diagram
Read "What is and isn't a JTBD".
Job stories differ from user stories because they are persona, product, and solution agnostic. This allows us to think more deeply about the user's context, motivations, and needs rather than just a title, task, and goal.
Example:
Job stories offer a higher-level view of the main objective. However, when written at a lower altitude, they can serve the same function as user stories, guiding your solutions while keeping the main job, circumstances, and need in mind.
If you want a detailed breakdown of each segement of the JTBD, learn more about the structure of a JTBD.
User personas are people who use GitLab. Each persona represents a person with a particular job title or role in an organization. A job performer in our JTBD framework is any user doing a specific task. In practice, the person who is the job performer could change and is not strictly tied to a job title.
For example, anyone who creates a merge request is considered a Code Author (job performer) in the JTBD Framework. This is a different perspective of a user persona that attempts to fit any person in an organization with the title Software Developer into the Sasha user persona.
