JTBD/ODI at GitLab

⚠️ This framework is undergoing evaluation in a pilot program ⚠️

We use Jobs-to-be-Done (JTBD) and Outcome-Driven Innovation (ODI) to achieve a deeper understanding of our users and the underlying Job they’re trying to accomplish. Though JTBD can be applied in various ways, we use our own interpretation that fits best with our design process. We leverage the framework for “categorizing, defining, capturing, and organizing users’ needs, and tying user-defined performance metrics (in the form of desired outcome statements) to the JTBD” (Ulwick).

At it’s core, we focus on asking: What outcome are you trying to influence?

Framework Overview

Here are the key steps to apply the framework:

1. [Define Job Performers and their Jobs]: Understand who your [Job Performers] are and the [Jobs] they are responsible for in your [Domain].
2. [Investigation Interviews, Job Mapping and Outcome Survey Preparation:] Interview [Job Performers] to understand their process, create [Job Maps] to assist with drafting [Outcome statements] to baseline the experience, evaluate solutions, and prioritize future efforts.
3. [Construct Outcome Statements] and [Survey] Conduct a quantitative analysis to understand how well the current experience meets users needs. Baseline the [Outcomes] for their effectiveness.
4. Evaluate Solutions: Continually refer to the baselined Outcomes when creating and validating solutions to ensure significant impact on meeting user needs.

For a step-by-step process, follow the [JTBD playbook]

Core Concepts

Job Performers vs. Personas

Understanding the roles and contributions of [Job Performers] (someone executing a Job) and Personas is crucial and highly valuable in the JTBD framework. Each Persona, like a Software Developer, may undertake various [Jobs] as part of their role (writing code, reviewing code, maintaining infrastructure, and so on). Similarly, other job titles or Personas may also undertake the [Main Job] in JTBD; for example, an engineering manager may review code or plan projects. Both Personas and [Job Performers] are valuable constructs that help understand and improve your product, but it is essential to keep them separate and recognize how they’re related, but different.

Job Types

Understanding the different [Job types] and how they relate to each other is crucial for mapping out the entire user experience and identifying opportunities to create value. There are several key [Job types] to consider in the JTBD framework:

• Main Jobs: The overarching goal or objective that the [Job Performer] is trying to achieve is the [Main Job]. This is the highest-level job for a given [Domain]. Main Jobs are the primary goal the Job Performer is trying to achieve when using your product. It’s why they chose to use your product. [Main Jobs] are mapped using a Job Map and are always solution-agnostic.
• Consumption Chain Jobs: The supplemental tasks a [Job Performer] undertakes when interacting with a product or service are the [Consumption Chain Jobs]. These include every step from identifying a need, finding and selecting a solution, purchasing, configuring, using, maintaining, and eventually discontinuing its use. [Consumption Chain Jobs] do not have a Job Map and are often solution-dependent.
• Related Jobs: Other jobs that the [Job Performer] may be trying to get done, either before, during, or after the [Main Jobs] (this may include Consumption Chain Jobs). Understanding the Related Jobs is vital to providing the best platform experience for the user.

Job Maps

The Job Map is a visual representation of the sequence of [Stages] a [Job Performer] goes through to complete the [Main Job]. It reveals the underlying patterns of intent and the sub-goals that comprise accomplishing the overall Job.

Common [Stages] of a Job Map include, but are not limited to:

• Define: Determine objectives and plan how to get the Job done
• Locate: Gather materials and information needed to do the Job
• Prepare: Organize materials and create the right setup
• Confirm: Ensure that everything is ready to perform the Job
• Execute: Perform the Job as planned
• Monitor: Evaluate success as the Job is executed
• Modify: Modify and iterate as necessary
• Conclude: End the Job and follow-up

These [Stages] are arranged in a logical flow, with related [Job Steps] clustered together with their relevant [Job Stage]. When complete and validated with users, the Job Map will serve as a foundation for creating [Outcome statements] and uncovering [Underserved Needs].

Outcomes

[Outcomes] are the specific, measurable, and actionable results that users want to achieve when getting a Job done. They represent the desired end-state or performance metrics that users use to evaluate the success of a solution.

[Outcomes] are the most crucial part of the JTBD framework, as they help you understand what users truly value and how to design solutions that better meet their needs. By focusing on Outcomes rather than features or functionality, you can uncover unmet or [Underserved Needs] and identify opportunities to create differentiated value. By understanding the [Outcomes] that users care about, you can design more effective solutions, make better prioritization decisions, and measure the true impact of your work.

Continuous Evaluation

Using [Outcomes] to prioritize, design, and measure, allows for predictable, repeatable, and consistent evaluation methods, creating feedback loops that relate directly to the outcomes you are trying to influence.

• Benchmarking: Evaluate the Main Job and Consumption Chain Job Outcomes to establish a benchmark and assist with prioritization by identifying underserved needs.
• Solution Evaluation Evaluate how your solution improves the targeted Outcome(s), using the established benchmark as reference.

Jobs GitLab helps get done

Main jobs

placeholder for jtbd-yml file

Reference Material

• [JTBD topics and definitions]
• Jobs to be Done Playbook by Jim Kalbach
• Jobs to be Done by Anthony Ulwick
• Competing Against Luck by Clay Christenson
• Intercom on Jobs to be Done by Intercom

View page source - Edit this page - please contribute.