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.
For a deep dive into our JTBD philosophy:
Watch the following video for a brief overview of why JTBD are so valuable towards the product development process:
For a quick how-to, follow the below guidance.
First, let's set the terminology we use for JTBD.
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 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.
When my development ecosystem begins to mature, I want an overall understanding of my organization’s registries and specific package usage, so I can make effective architectural decisions.
As an Engineering Leader, I want to know what packages are being used and by which projects, so that I can ensure my team is using the correct versions and not introducing risk into the pipeline.
View a list of packages we use.
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.
Job statements can be written at different levels or altitudes. For the majority of our work, we write job statements for stage groups as we craft experiences for features or sets of related features.
JTBD can also be written for stage or cross-stage jobs to help determine longer-term product direction.
If you're writing a job statement for your stage group, consider this guiding principle to determine the appriopriate altitude: If the job is applicable to more than 3 user types, it's likely the altitude is set too high.
Often we find there are many JTBD for one category. 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.