Jobs To Be Done

In this chapter, you’ll learn about these plays:

• How to create a jobs-driven roadmap
• Using job stories to solve specific design problems
• How to architect the structure of a solution
• Testing assumptions directed by JTBD

A software company I once worked for held what were called “hackweeks” once a quarter. This was a time for developers to work on “whatever they wanted,” as it was framed. Give engineers time to play around with technology, and they’re bound to find the next innovation, or so the theory went.

Hackweek was a big deal for us. Dozens of people organized it, and every developer in the company stopped work to contribute to the effort. It was costly, but we were committed to hackweek. After all, new software offerings come from new development, right?

Here’s how it went: small teams formed to cobble together starter projects representing the use of some new technology. At the end of the week, a panel judged the dozens of concepts that emerged, and the winning “solutions” were rewarded.

But in our case, hackweek was like shooting a shotgun in the wrong direction while blindfolded and hoping to hit the target. The result was inevitably a collection of concepts looking for a problem to solve. It was innovation theater at its best.

To be fair, not all hackathons are bad. Some organizations coordinate hackathons with strategic imperatives or with customer needs. And sure, it’s also good to flex creative muscles and practice collaboration across teams. But given their cost and imprecision, hackathons are often largely ineffective in producing usable concepts.

The problem is not a lack of ideas—companies are usually swimming in them. Like ours, many organizations have a Darwinistic outlook on innovation: generate more and more ideas, and the best will surely rise to the top. Said another way, when looking for a needle in a haystack, the best approach is rarely to add more hay.

The problem is knowing which ideas to pursue. The goal of innovation activities shouldn’t be to collect as many ideas as possible, but instead to get to the right ideas—the ones that matter most to the people you serve.

But more than that, the real challenge is in overcoming the natural forces in organizations that keep good ideas down. Chief among these is uncertainty, a leading deterrent to innovation. New ideas are a gamble for risk-averse managers, even if well-expressed in a high-fidelity prototype.

JTBD provides a way to increase your chances of success by first identifying the right problem to solve. Then JTBD gives you decision-making criteria for moving forward: bet on solutions that address unmet needs to create profitable differentiation.

Focus first on getting the main job done for the individual and fulfilling their needs in relation to the job. From this perspective, hackathons and other idea-generating efforts can be framed by JTBD as both inputs and outputs in terms of how concepts are evaluated.

After understanding the job landscape and defining the value you’re going after, you can continue using JTBD thinking to align teams around the design of your solution. Create a roadmap based on your JTBD landscape to set a common direction. Then use job stories to get everyone on the same page and tie local design efforts to the big picture and to architect the solution structure. JTBD can also guide the experiments you conduct to test your team’s assumptions.

Create a Development Roadmap#section2

At its highest level, a roadmap is a sequence of development events—the relative chronological order in which features and capabilities will be built. Roadmaps serve as a central point of reference for teams to align their efforts. They show the path forward without defining individual tasks.

In the age of Agile and Lean efforts, roadmaps have gotten a bad reputation. People are quick to point out—and rightfully so—that long-term plans inevitably fail: priorities change, unforeseen challenges arise, and timelines slip. The solution, they might argue, is to have no long-term plans and to work on short initiatives with the flexibility to change as needed.

But while providing decision-making power to local development teams makes sense, overall alignment is still needed. An alternative way of viewing roadmaps is to see them not as a definitive project plan, but as a vision of how you’ll create an offering that customers will value. Roadmaps are not unchanging predictions of future activity, but a way to provide transparency for the sequence of steps your team will take to design solutions.

The information in a roadmap helps the entire organization get aligned, not just developers. It’s a strategic communication tool reflecting intention and direction. More importantly, road mapping isn’t just about the artifact: it’s about getting a common understanding of where you’re headed. In this sense, the roadmap occupies the space between the vision and detailed project planning.

JTBD can help create roadmaps that focus on the value that the organization intends to create and deliver for customers. The trick is to get the right problem to solve. Use the insights from your JTBD investigation to formulate roadmaps that are grounded in real customer need.

Mapping the Road Ahead#section3

For a concrete approach to road mapping, I recommend the book Product Roadmaps Relaunched by C. Todd Lombardo, Bruce McCarthy, Evan Ryan, and Michael Conners.^[1] In it, the authors clearly articulate the steps to creating meaningful product roadmaps.

JTBD plays a key role in aligning to customer needs, as the authors write: “We recommend starting with the chunks of value you intend to deliver that will build up over time to accomplish your visions. Often this is a set of high-level customer needs, problems, or jobs to be done.”

Their approach breaks down the four key elements of a good product roadmap:

• Product vision: The vision outlines how your customers will benefit from your offering. How will the job performer benefit from the solution? What will getting the job done look like after the solution is in place?
• Business objectives: A roadmap must be aligned with the organization’s strategy and objectives. The goals of the business are important for measuring progress.
• Timefames: Rather than committing to specific dates, good roadmaps sequence work and set broad timelines for completion.
• Themes: These are the key problems that customers face when completing a job, or clusters of needs that align to the overall solution to be created. JTBD helps frame the themes of your roadmap in particular.

Figure 5.1 shows an example from their book of a basic roadmap overview for a fictional company, The Wombatter Hose, illustrating these main components. Note the disclaimer, as well, indicating that the roadmap is subject to change.

Putting it all together, the process for creating a JTBD-driven roadmap can be broken down into four phases.

Step 1: Define the solution direction.

Define the various elements of your overall product strategy to get agreement on how you’ll be using them. In addition to your solution vision, also define the following together with the team:

• Mission: What are your business intentions? The mission is about what your organization wants to ultimately achieve.
• Values: What are your beliefs and ideals? What is the philosophy of your organization and solution? Values define the philosophy of the team and what it believes.
• Business objectives: What are the specific goals your offerings will accomplish for the organization? Frame these in terms of outcomes, not outputs.

Step 2: Determine customer needs to pursue.

Next, decide on the customer needs to pursue. Here, the authors of Product Roadmaps Relaunched stress the importance of grounding the roadmap in actual customer need. JTBD is central to this step. They write:

“Identifying customer needs is the most important aspect of your roadmapping process. Roadmaps should be about expressing those customer needs. Therefore, most items on your roadmap will derive from a job the customer needs to accomplish or a problem the customer must solve.”

As outlined in Chapter 2, “Core Concepts of JTBD,” needs are hierarchical—from high-level aspirations to main jobs and sub-jobs to micro-jobs. Figure out the top-level jobs to explore and then drill down into the specific themes to target.

The “value themes,” as they are called, might come right from the job map. Locate the areas of highest underserved needs and use those stages as the categories of your roadmap themes. Or you can cluster needs to form themes that don’t necessarily follow the chronology of the job map. The important point is to ground the division of the roadmap in real-world observations of the customer’s job to be done and align the timeline to it.

Step 3: Set a timeline.

Next, create a sequence of value themes that your team will work toward. Timelines can be absolute, relative, or a mix of both. Absolute timelines with specific dates carry the risk of changing, which, in turn, can cause confusion or missed expectations.

Relative timelines give more flexibility but still provide insight into what’s coming and why. There are various terms to use, but the timeline is often broken into three phases for near-term, mid-term, and long-term. Examples include “now, later, future” or “going, next, later” or something similar. Find what works best for you.

Step 4: Align development effort to the roadmap.

Finally, conceptualize specific solutions to design and create. Use job stories to tie the overall project intent to customer needs, outlined in the next section. Then conceptualize solutions around getting the entire job done or the parts of it determined to be most strategically relevant to your business.

After a roadmap is created, you may then need detailed project plans to track progress. A simple Kanban board can serve that purpose in many cases. Or, for more complex software development efforts, tracking software may be needed. In Agile efforts, epic planning and then sprint planning come after you have an overall roadmap.

Tying the overall plan to customer needs gives the design and development teams the feeling that they are building something that matters to customers. Staying focused on customer needs helps avoid building things your customers don’t want. The nature of a job stays the same, even as features may shift. Grounding the roadmap in JTBD ensures that both its longevity and ability to absorb will change.

Learn More About This Play#section4

Lombardo, C. Todd, Bruce McCarthy, Evan Ryan, and Michael Conners.^[3] Product Roadmaps Relaunched. Sebastopol, CA:O’Reilly, 2018.

This book distills a wealth of practical information into a compact guide on roadmapping. The authors go to great lengths to provide numerous examples and stories from real-world cases. They use a realistic, modern approach for creating a roadmap that is driven, in part, by JTBD.

Align Teams to Job Stories#section5

Agile development enables teams and organizations to work in a flexible way. The approach started in software development, but has spread to other domains, including government and the military. The principles of Agile development can apply to just about any field.

A key part of Agile is to break down efforts into individual units of work. User stories are short descriptions of features and functionality written from the perspective of the end user. Teams can focus on only a small part of the whole and make progress in a controlled way.

User stories are commonly written in a three-part format. The first element indicates a user’s role in the system. The second points to a capability that enables the person to get a task done. The last part often describes a benefit or reason for using the capability.

Although specific styles can vary, a typical user story resembles something like the following:

As a <role> I can <capability>, so that <benefit>

Examples of use stories in this format include:

• As a system admin, I can specify files or folders to back up based on file size, date created, and date modified.
• As a user, I can indicate folders not to back up so that my drive isn’t filled up with things I don’t need to be saved.
• As a user, I want to update the name of a document so that I can categorize it.

For any given system, there may be hundreds of user stories. Some can be quite granular, such as describing a single button and why a user would click it. Stories are then organized into a backlog or repository of functionality to be built. Teams break off logical groups of user stories in sprints or two- to four-week cycles of work.

Job Stories#section6

Although user stories are good for breaking down work, they typically fail to connect the solution being built with user needs. They lack an indication of why someone would behave in a certain way and what they need to get a job done. In fact, often user stories are derived from the capability being built, not from observing actual behavior.

Job stories are an alternative to user stories. They follow the tradition of breaking down efforts into smaller pieces, but through the JTBD lens. The technique was first pioneered by the product development team at Intercom, a leading marketing communications solution. They wanted to avoid leading designers with a preconceived solution, as well as tying development to the company vision and strategy.

Paul Adams, an Intercom product manager, wrote about job stories for the first time, saying: “We frame every design problem in a Job, focusing on the triggering event or situation, the motivation and goal, and the intended outcome.”^[4]

As a result, their job story format also has three parts. But instead of focusing on a generic role, like a “user” or an “admin,” job stories begin with a highlight on the situation and context, not the individual:

When [situation], I want to [motivation], so I can [expected outcome].

Examples of job stories include:

• When an important new customer signs up, I want to be notified so that I can start a conversation with that person.
• When I visit someone’s profile page, I want to see how many posts they have in each topic so that I have an understanding of where they have the most knowledge.
• When I have used the application multiple times, I get nudged to contribute so that I am encouraged to participate.

JTBD author and leader Alan Klement has done the most work refining the job story format.^[5] He believes that adding more information about the circumstances shows causality better. Focusing on the context shifts attention from a persona to the situation. Klement advises that you avoid writing vague situations, but instead be as specific as possible.

For instance, consider these three possible situations for the first element of job stories:

• When I’m hungry…
• When I’m lost…
• When I want to check my email…

Instead, Klement recommends describing the circumstances in rich detail:

• When I’m hungry, running late to get somewhere, not sure when I’m going to eat again, and worried that I’ll soon be tired and irritable from hunger…
• When I’m lost in a city that I’ve never been to, don’t know the local language, and am worried that I’ll be wasting my time in places I don’t want to be in…
• When I want to check my email, but don’t want anyone around me to know I’m checking my email because they’ll think I’m being rude…

Each of these example situations provides more context for designing an appropriate solution.

Working with Job Stories#section7

Job stories are modular, giving designers and developers the flexibility to solve problems in alternative ways. Job stories are grounded in real-world insight, and they are more powerful than user stories in guiding solutions. But creating job stories is more free-form than other JTBD techniques. Still, there are patterns that you can follow. Using the elements from Chapter 2, I suggest the following structure for job stories:

When I [circumstance + job stage/step], I want to [micro-job], so I can [need].

Examples:

• When I am one of the top posters while updating my social media feeds daily, I want it to show on my profile so that I can increase recognition as an expert on the subject.
• When I run out of materials needed while completing an art project, I want to find alternative materials so that I can maximize the number of uses of my current supplies.
• When preparing for my commute and running late, I want to know the current weather along my journey so that I can minimize the chance of arriving wet.

Consider the last example. The first element combines information about the circumstances (running late) of getting the main job done (commute to work) within a stage of the process (prepare for commute).

The second element points to an even smaller step or micro-job (check forecast). It should be formulated without reference to specific technology, but should be specific enough for designers and developers to create a specific capability.

Finally, the last element can be taken right from your list of needs. In this case, the job performer (commuter) wants to avoid showing up to the office wet (minimize the chance of arriving at work wet). You can leverage the elements your JTBD landscape already uncovered in research directly in the formulation of the job story statements.

In researching this book, I’ve come across various alternative approaches to formulating job stories. Andrea Hill, a prominent advocate of JTBD on social media, suggests a slightly different approach. She sees the middle element pointing directly to a feature or solution of some kind, thus explicitly crossing from the problem space into the solution space. Her basic format is as follows:

When I [circumstance], I want to [solution capability], so I can [need].

A job story for the previous example of commuting to work might then look like this:

When I’m preparing to commute to work, I want to have weather forecast notifications pushed to my phone, so I can minimize the chance of arriving wet.

Steph Troeph, research and JTBD instructor in the UK, approaches job stories in yet another way. She thinks of them with this formula:

When I [circumstance], I want to [job], so that [benefit a solution offers].

Regardless of your interpretation, the key is to find a consistent structure and stick with it. The form you end up with needs to be appropriate to your team and your situation.

Jobs Stories in Action#section8

Ultimately, job stories tie a local design and development effort to a broader JTBD framework. Because the format of job stories includes contextual details, they are portable. In other words, a job story should make sense without having to know the larger JTBD landscape or job map. As a result, job stories have a more “plug-and-play” versatility that is often required for Agile designs and development teams.

For instance, Agile planners can manage a backlog of job stories much in the same way that they would manage user stories. If a given sprint gets slowed down or changes direction, stories not addressed can be carried over to the next sprint. Having a smaller, self-contained description of the smaller job to be done has advantages during the design and development phases.

But to be clear: I have found that job stories typically do not replace user stories for development completely. Instead, job stories guide and frame the conceptualization of a solution rather than track implementation. They serve best as a design tool to create or determine concept direction and design. Developers and engineers will likely still need user stories to measure the burndown rate and overall progress.

Your job map provides an overall orientation to your JTBD landscape and allows you to zero in on a specific area for design and development. A roadmap gives you a high-level sequence of development with the rationale for planning activities. Job stories are more specific and guide the local design and development of features and capabilities.

Follow these steps to create job stories based on your JTBD research:

Step 1: Understand job stages and circumstances.

Base the relevant jobs and circumstances on previous interviews and observations. For each area of development in your solution, consider the steps in the main job. Then drill down and list the smaller and smaller steps as micro-jobs, using the rules of formulating JTBD. Also identify the circumstances that apply to that part of the main job in particular.

Depending on the depth of your prior research and how well you and your team understand the job, you may not need to do more research to create and validate job stories. It’s never a bad idea to speak with people again and drill down on specific problems and objectives they have. During additional interviews, ask “how?” until you get more granular in understanding of subgoals and objectives.

Step 2: Formulate job stories.

As a team, write job stories that are specific to your design and development effort. Decide on a consistent format for the job stories and stick to it.

Strive to come up with unique, mutually exclusive stories that target specific jobs and circumstances. Avoid redundancy. For instance, in the previous example, you probably don’t need separate stories for commuting by train versus commuting by car. Develop the job stories that matter the most and focus on a limited set. You may end up with anywhere from three to eight job stories per project or sprint.

Step 3: Solve for the job stories.

Make job stories visible and transparent to the entire team to solve for the job stories. For instance, post a relevant list of job stories in a brainstorming session for everyone to see. Or list job stories at the beginning of a design critique so that the team has context for making comments. Use JTBD to guide design and development decisions.

It’s also possible to then use the job stories to review the appropriateness of your solutions. First, the design team can use the job stories relevant to a project as heuristics. They should constantly ask if their designs are meeting the user’s goals set out in the job stories.

Then you can test solutions with users against the job stories. Show users your solutions (e.g., as a mock-up or prototype) and ask them how well each addresses the job stories. This can be done in an interview-style fashion or with a survey. The job stories ultimately become a measure for success of the designs before anything is built.

Job stories let you take a step back and look at the context of the job while designing a product or service. In this respect, job stories fill an important gap between the observations of customers and solution development, connecting insights into customer needs to individual features and development efforts.

Related Approaches: Needs Statements#section9

Design thinking is a broad framework for creative problem solving. It is rooted in human-centered methods that seek to develop deep empathy for people and then to devise solutions that meet their needs. In design thinking, it is important to define the problem to solve before generating options for solutions.

One technique to encapsulate insights from research is to generate need statements, greatly resembling job stories in form. But these statements differ from “needs,” as defined in Chapter 2, in that need statements in design thinking are not specifically limited to the outcomes of a getting a main job done, and they can be aspirational in nature.

Need statements in design thinking also tend to be much more focused on a persona or an individual rather than the circumstances. For instance, writing for the Norman Nielsen Group, Sarah Gibbons refers to need statements representing a point-of-view for the user of a system:^[6] “A user need statement is an actionable problem statement used to summarize who a particular user is, the user’s need, and why the need is important to that user.”

Like job stories, need statements have three components: a user, a need, and a goal. The user corresponds to a goal-based persona based on research (as outlined in Chapter 4, “Defining Value”). A need is expressed independent of a feature or technology. The goal is the result of meeting the need. Gibbons provides an example:

Alieda, a multitasking, tech-savvy mother of two, needs to quickly and confidently compare options without leaving her comfort zone in order to spend more time doing the things that really matter.

Note that the insight at the end of this statement, “doing the things that really matter,” is very broad and hard to measure. Job stories, on the other hand, favor a more specific context and outcome. For instance, rewriting the above example through the lens of job stories might yield something like the following:

When I’m multitasking and in a rush, I need a familiar way to quickly and confidently compare options so that I can minimize the time spent on finding a solution.

Like need statements in design thinking, job stories also avoid the mention of features or technology. Yet, they are much more specific to a given job and its context. While both a need statement from design thinking and a job story can feed into the creative generation of solutions, job stories will provide more direct guidance without prescribing a solution.

But the definition of a need in design thinking can vary greatly. For instance, IBM’s Enterprise Design Thinking approach also includes guidelines for generating statements.^[7] Not surprisingly, there are three parts: a user, a need, and a benefit. Here’s an example from the IBM site:

A developer needs a way to make sense of minimal design so that they can prototype faster.

This example is much more specific than Gibbon’s approach, yet still avoids mentioning a specific solution. There are no aspirational elements, such as “pursuing lifelong dreams,” sometimes found elsewhere in design thinking. IBM’s approach to need statements is closer to the job story approach, but is also light on describing the circumstances of use.

In some sense, the differences between job stories—even with the variations in format—and need statements points to a key distinction between JTBD and design thinking. The former focuses much more on the circumstances than the person’s state of mind or psychology. Where design thinking seeks to gain empathy for the individual as a starting point, JTBD seeks to understand the circumstances of accomplishing an objective before factoring in emotional and personal aspects.

Learn More About This Play#section10

Klement, Alan. “Replacing the User Story with the Job Story.” JTBD.info (2013); “5 Tips for Writing a Job Story,” JTBD.info (2013); “Designing Features Using Job Stories,” Inside Intercom (2015).

Klement has done the most extensive work to develop the job story technique. These three articles outline the basis for creating them. The technique has evolved slightly, but Klement points clearly to how he’s updated his approach. Klement and others have posted widely about their use for development efforts, but start with these resources.

van de Keuken, Maxim. “Using Job Stories and Jobs-to-be-Done in Software Requirements Engineering.” Thesis, Utrecht University, 2017.

This thesis project offers a detailed investigation of how job stories are applied to date. After illustrating the history of job stories, Van de Keuken presents the results of his original research variations in application of job stories as seen in practice. This work contributes greatly to making job stories a more formal part of software requirements engineering.