A Method for Applying Jobs-to-Be-Done to Product and Service Design

Say you’re designing something new for a product or service. Of course, you have your own ideas for what to do. But, how informed are you really about what is needed?

This is a question I faced in thinking about game mechanics used in a social platform. A common product approach is to work up some game mechanics ideas, get them designed and deployed. The source for ideas? My own fertile mind. Inbound suggestions (“in World of Warcraft, you can…”). Competitors. What companies in other markets are doing.

But that wasn’t sufficient. Game mechanics are an evolving, somewhat complex field.  I wanted to understand at a more fundamental level: why game mechanics? So I decided to learn more from our customers. What needs would game mechanics address? Initial question: what’s the best way to go about this?

Jobs-to-Be-Done: Only for game-changing innovation?

The jobs-to-be-done framework struck me as the right approach here. What are customers trying to get done? As legendary professor Theodore Levitt said:

People don’t want to buy a quarter-inch drill. They want a quarter-inch hole.

Similarly, I didn’t believe customers wanted to buy “game mechanics”. They want to buy results, which game mechanics can help deliver. Using the jobs-to-be-done framework, what jobs were game mechanics being hired for?

Yet, in reading the advice on jobs-to-be-done, one gets the impression that eliciting jobs-to-be-done can only be done effectively via intensive in-person interviews. Well, I didn’t have the capacity to fly around for one-day deep-dive sessions to understand the jobs-to-be-done related to game mechanics.

And this gets at something related to jobs-to-be-done as it stands today. It’s very much positioned for high-impact, game-changing innovation. Which is awesome, by the way. Firms like Strategyn and ReWired Group are setting the tone here. When the payoff for intensive, expensive efforts like in-person interviews is high-value innovation, you do them.

But my needs were at a lower level than that. In the Customer Insightini™ to the right, I segment the types of initiatives where customer insight can be useful. The bottom is the minor stuff (“it should support colors red, green, blue…”). The top is the game changing endeavors (e.g. surgery stents). My game mechanics inquiry? Right there in the middle. Introduction of something new in the same market.

Since I couldn’t find a good framework to elicit customers’ jobs-to-be-done, I hacked together my own methodology. It’s described below.

1. Job-to-be-done structure (link)
2. Focus the effort (link)
3. Rate satisfaction with fulfillment of each job (link)
4. Rank order importance of jobs to create an Opportunity Map (link)
5. Use a website to manage the jobs-to-be-done (link)
6. Conversations are as valuable as the jobs themselves (link)
7. Step-by-step plan (link)

Job-to-be-done structure

I needed a common language for the various jobs-to-be-done. Specifically, I needed a reliable format that provided the right information. I came up with the following:

Context: “When I am…”

Job: “I want to…”

Success metric: “Increased…”

Context is important, because I want to understand the background for the job to be done. When did it happen? What was the larger goal? The job itself is the core information to be collected. The success metric told me what the customer valued in an outcome, and provided a basis for measuring whether the idea implemented to fulfill the job was actually doing so.

Focus the effort

Something I’ve learned in the realm of innovation management: focused initiatives outperform post-whatever-you-want initiatives. In other words, participants should be asked for insight on a specific topic. Otherwise the exercise risks spinning off in many directions you’re not ready to pursue.

In the game mechanics effort, I started with a definition of gamification itself. This set the tone for the discussion. I believed there were several areas that could benefit, so I focused the discussion around collaboration, engagement and three other areas. This framed the discussion without corralling customers too tightly in what they wanted to express. It also gave a nice rhythm, as we worked through each of the five areas.

Unsurprisingly in the discussions with customers, they had ideas for applying game mechanics to a job-to-be-done. Since the discussion was focused on their needs and wants, I would take these ideas and add them to a separate Spigit idea community.

Rate satisfaction with fulfillment of each job

This step was critical. It wasn’t enough to have the various jobs-to-be-done. Understanding the level of satisfaction with each one is the metric which shows where good opportunities lie.  I asked customers to bucket each job-to-be-done as:

• Satisfaction with current outcomes = HIGH
• Satisfaction with current outcomes = MODERATE
• Satisfaction with current outcomes = LOW

Now, there was a natural bias for customers to provide jobs where their satisfaction was lower. They wanted to talk about things that need to be improved. But I wanted to ensure a broader look at the landscape of jobs. So in the course of the discussion, there were three sources of jobs-to-be-done that came outside of these  low-satisfaction ones:

1. Seeded obvious jobs: I seeded the site with some of the more obvious jobs, to provide examples.
2. Jobs provided by previous customers: As I learned new jobs from a previous discussion, I’d add them to the new discussion. This was good to see how customers felt about what others were trying to get done.
3. Jobs elicited in discussions: After getting one job from a  customer, we’d discuss it. In that discussion, you’d hear another job-to-be-done. While that one may not be low satisfaction, it was important to capture it for a fuller understanding.

As you can imagine, there were varying views on level of satisfaction for the same job across customers. Is the software performing differently for each? No. But each customer was communicating the level of outcome they deemed satisfactory.

Rank order importance of jobs to create an Opportunity Map

After the jobs were sorted into the LOW, MODERATE, HIGH satisfaction buckets, I asked the customer to rank them in relative importance, highest to lowest. This was their chance to tell me just what they valued most. Even if their satisfaction was moderate with a job’s outcome, it was valuable to know what they deem most important. Useful for fuller understanding of why customers buy. Because you want to avoid being one of these companies:

The vast majority of companies have no clue what their customers value in the products and services they buy.

Here’s what you get after you’ve done this: an Opportunity Map as determined by the customer’s expressed needs.

After talking with each customer, you’ll be able to generate an Opportunity Map. By aggregating the responses by customers, you have a broader Opportunity Map    that begins to reflect something of the market.

Use a website to manage the jobs-to-be-done

The preceding elements of eliciting jobs-to-be-done are the method. The method needs a place to execute it. For my gamification project, I used the free post-it note site Listhings. With that site, I can add unlimited canvases (for different customers) and individual notes (for the jobs). You can color code the different sub-topics within the question you are asking.

Examples of Listhings culled from an actual customer discussion:

Conversations are as valuable as the jobs themselves

In the process of collecting the jobs-to-be-done, I found the discussions around each job-to-be-done to be incredibly valuable. And this is an important point: customers want to talk to you about what they’re trying to get done! The discussions were intelligent and gave me insight into their world. An insight I cannot get from data about usage or the user stories I write in a vacuum.

This experience is what makes me cringe when I read others throwing around the old Henry Ford chestnut: “If I had asked people what they wanted, they’d have said faster horses.” It assigns customers to the Dumb Bucket.

Interesting experience in doing these with 8 different customers. I would schedule a one-hour session with our admin leads at each. Inevitably, we’d run out of time in that first session. Every single customer was up for a second session. One customer even wanted a third and fourth session, bringing actual end users into it for their perspective.

Perhaps this can be a good path for a design thinking approach, as it really boosts your empathy for what customers are trying to get done as you discover their jobs-to-be-done.

Step-by-step plan

OK, that was a lot of information about individual parts of this jobs-to-be-done methodology. Let’s put it together into a plan:

1. Establish a topic you want to explore more deeply with customers.
2. If the topic is somewhat broad, break it down into sub-themes.
3. Sign up for a site where you can collect jobs. Criteria for such a site:
   • Each job is visible in full on screen
   • Ability to segment the jobs by sub-themes
   • Ability to categorize jobs by level of satisfaction
4. Seed the site with some obvious jobs that your product/service provides.
5. Select customers to engage.
6. Use a web/screen sharing tool to run the discussion (e.h. WebEx, GoToMeeting, Skype, Google Plus).
7. Plan for an hour, expect to need a second one.
8. As you talk with the customer, post the jobs in real time so she sees them on screen.
9. Run through the satisfaction bucketing (LOW, MODERATE, HIGH)
10. Rank order the jobs within each satisfaction bucket
11. Collate and aggregate the responses after you have finished the customer discussion. I used Excel for this.
12. Identify the jobs that were most important and received LOW or MODERATE satisfaction across your customers.
13. Plumb your notes from the discussions for additional insight that will be useful

The other thing you’ll gain from this are customers who have a demonstrated interest in the phases that follow in the design and development process: ideas, prototypes, early purchasers.

I’m @bhc3 on Twitter.