I’ve previously written about collecting jobs-to-be-done from customers. Because I was analyzing a broad topic across the entire innovation lifecycle, it was a good way to get a breadth of insight. However, it doesn’t work as well in the more common situation for product managers and innovators: analyzing a specific flow. In that case, there are three requirements for collecting jobs-to-be-done:
- Comprehensive capture of job elements
- Map collection as closely as possible to the actual job flow
- Understand importance and satisfaction of individual tasks
Comprehensive is important, because you can’t address what you don’t know. A limitation of my previous effort was that it was not comprehensive. Actual job flow is a powerful framework. Needs captured in context are more valuable, and it’s critical to follow the steps in the job. Importance and satisfaction become the basis for prioritizing effort.
To address these requirements, I’ve put together a process to understand customers’ jobs-to-be-done. The major elements are:
For purposes of this write-up, assume you’re an automotive product manager. You’re tasked with understanding people’s needs to get work done on the commute to the office. Note this is a job that becomes more readily enabled by self-driving cars.
A job-to-be-done has a flow. For example, take this job:
When I commute to the office, I want to get work done.
A job flow consists of the job’s major activities, in sequence. The job flow looks something like this:
The purpose of the flow is to provide a framework for capturing specific tasks. Putting this together is primarily the responsibility of the product manager (or innovation team). By stating the major activities that define the job, expect a much more comprehensive capture of all the job elements.
Each activity consists of a series of tasks. Task are what the customer actually does. They are independent of specific features, although may often be intertwined. Here’s an example task:
Previously, I’d focused on including context in job statements. But when these tasks are organized according to the job flow, the context is readily known. So task statements don’t include a context element.
But they do include an expectation statement. For every task we do, we have an expectation for it. It defines whether we consider the current experience wonderful or painful. This expectation is formalized for each task, captured in the customer’s own words. It’s valuable to know what the customer expects, as that becomes the basis of design.
Next step is to conduct the actual customer interviews. Whether done in the customer’s environment (best) or via a web conference call (acceptable), the job flow provides a familiar framework to the customer.
When I worked at eFinance, I conducted brown paper sessions with clients to understand their commercial credit processes. A staple of the Capgemini consulting model, the brown paper is a step-by-step process flow of what the customer does today. Collecting the job tasks is similar here. Similarities and differences:
- Brown papers are conducted with groups of people together. Job-to-be-done capture will more often be solo interviews.
- Brown papers are done in a strict step-by-step flow, captured visually on a wall. If doing this for job-to-be-done interviews works for you, go for it. But a simpler post-it note capture style works as well.
- After capturing the steps in a brown paper, the group is invited to post stickies describing points where improvement is needed. In the job-to-be-done interviews, each task includes a statement of what the customer expects for it.
A key element of the interview process is to probe the responses of the customer. In a perfect world, they will lay out the individual tasks and easily express their expectations. But likely, customers will talk a lot about features. Which is valuable in its own right. But the objective here is to capture what they are trying to get done. So apply the simple question why. Not in a robotic way. But make sure to probe past the expression of features. These are the tasks – versus features – to place on the job canvas.
Here’s an example of the approach:
Customer: I want a 4G internet card.
Interviewer: Why do you need that?
Customer: So I can connect to email and the web.
Interviewer: What is your expectation for connecting to email and the web?
Customer: Always-on internet.
One tip: Use different color sticky notes for each major activity’s group of tasks. This color coding will help later in identifying where the tasks occur in the job flow.
For each major activity, job tasks are collected onto that customer’s job canvas. An example (with fewer tasks than would actually be there):
In reality, there will be a large number of tasks per customer interviewed. Strategyn’s Tony Ulwick states there will be between 50-150 outcomes collected from multiple customer interviews. Gerry Katz of Applied Marketing Science sees 100 or more needs collected as well. Sheila Mello of Product Development Consulting says it’s not unusual to extra several hundred images from the customer interviews.
Once the job tasks have been captured, the customer selects the tasks:
- That are most important
- That are least satisfied
The customer will select the 3-5 tasks that are most important for each major activity in the flow (e.g. there are 3 major activities shown in the job canvas above). These tasks will be assigned points. For example, assume three tasks are identified as important. The most important task would receive 3 points, the next most important 2 points, and so on.
The customer will also select the 3-5 tasks that are least satisfied for each major activity in the flow. Assuming three selected tasks, the task that is least satisfied receives 3 points, the next least satisfied task receives 2 points, and so on.
Keep this insight handy, but separate from the collected stickies (or however you’ve collected the job tasks). We’ll come back to how to use this information.
Note: it will help to apply unique numbers to the individual job tasks. You’re going to want to know the most important and least satisfied tasks across multiple customers later in the process.
A general rule of thumb is that 15-20 customer interviews will provides solid coverage of customers’ needs. You can take it further, as George Castellion advocates 40 interviews. Each interview starts with a blank canvas containing only major activities.
After conducting multiple interviews, you will have a large number of job tasks, with information on which ones are most important and least satisfied. Working with a large number of statements by people is a challenge that others have faced. They key is to reduce the large number to a manageable set of insights. There’s a proven approach called the KJ-Method to systematically abstract hundreds of statements into a few key groups.
UX expert Jared Spool provides a detailed series of steps to run the K-J Method. I’ll use his description here.
Bring together group of people do the affinity grouping
The first step is to determine who will do the affinity grouping with you. Try to keep this group at 5 people or fewer. Draw on people from different disciplines.
Put all the job tasks on a wall
In a single space, all the job tasks should be visible and accessible. They need not be laid out in the job flow, which might introduce a bias to the grouping. The color of the stickies will be the basis for knowing where the tasks fall in the flow.
Group similar items
The next step is for the team members to group like job tasks together. The process is one of looking at pairs of tasks, and determining if they share characteristics. This how Jared instructs clients to do this:
“Take two items that seem like they belong together and place them in an empty portion of the wall, at least 2 feet away from any other sticky notes. Then keep moving other like items into that group.”
“Feel free to move items into groups other people create. If, when reviewing someone else’s group, it doesn’t quite make sense to you, please feel free to rearrange the items until the grouping makes sense.”
“You’re to complete this step without any discussion of the sticky notes or the groups. Every item has to be in a group, though there are likely to be a few groups with only one item.”
Each participant then gets to label each group. This entails looking at the grouped job tasks and determining the common theme. Again, here’s how Jared instructs teams on this process:
“I want you to now give each group a name. Read through each group and write down a name that best represents each group on the new set of sticky notes I just gave you.”
“A name is a noun cluster, such as ‘Printer Support Problems’. Please refrain from writing entire sentences.”
“As you read through each group, you may realize that the group really has two themes. Feel free to split those groups up, as appropriate.”
“You may also notice that two groups really share the same theme. In that case, you can feel free to combine the two groups into one.”
“Please give every group a name. A group can have more than one name. The only time you’re excused from giving a group a name is if someone has already used the exact words you had intended to use.”
Note that part of the exercise in this step is to give one more consideration to the groupings. If, upon trying to determine a label one finds that the groups doesn’t actually make sense, the groups can be split up as needed.
I’ll add this caveat to Jared’s instructions. For purposes of this affinity group work, lots of different labels for each group of tasks are not important. It’s OK to go with one person’s good label for a group, a point to emphasize more strongly.
Here’s an example of labeling a group of job tasks:
Once done, you’ve organized a solid group of job tasks into major themes for what customers are trying to do.
Remember asking the customers to rate the three most important and three least satisfied job tasks? Now it’s time to use those ratings. In each group, calculate the following for both importance and dissatisfaction:
- Total points
- Average points per task
For each group, you’ll have something like this:
The Total score gives a sense for where the customer energy is. Large scores on either metric will demand attention. The Average score is good for cases where a group has only a few, highly scored job tasks. It ensures they don’t get overlooked.
You now have major groups scored with customers’ view of importance and dissatisfaction. Within each group are the tasks and expectations that customers have. This is the good stuff, the insight that fuels design efforts. It’s also the data-driven, factually based input that helps clear the fog when tackling a new area for development.
The expressed customer insight – what they want to do, what is important, what is not satisfied – becomes the foundation for constructing a roadmap. The team can layer on other considerations: business strategy, adjacent initiatives that impact the effort, internal priorities. Balance these with what customers actually value. Anything that ignores this hard-won customer insight needs a compelling reason, and an understanding of the higher risk it entails.
(Cross-posted @ I'm Not Actually a Geek)