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.

Customer Insightini

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 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.

JTBD Opportunity Map

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:

Listhings example

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, and I’m a Senior Consultant with HYPE Innovation.


About Hutch Carpenter
Chief Scientist Revolution Credit

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

  1. Pingback: Geek Reading January 15, 2013 | Regular Geek

  2. Pingback: A Method for Applying Jobs-to-Be-Done to Product and Service Design « fred zimny's serve4impact

  3. Great article. I agree that Ulwick and Christensen are focused on large innovations instead of incremental improvements. I’ve been trying to create a similar framework to what you’ve established to ensure that incremental improvements are developed in light of the jobs-to-be-done and measurable success criteria. I’ve been using Trello as my online tool. I’m curious whether you are concerned about how to aggregate your Opportunity map data. Since you are gathering data from individual customers rather than in a survey format, do you have any concerns about trying to aggregate which types of customers consider one job successful vs unsuccessful?

    • Thanks Dan. You’re right about the aggregation part. There will be some consistency in responses, but you also see divergence in what customers are focused on, and what they prioritize. The information is still valuable, and there is a certain amount of judgment you need to bring to it.

      One shortcoming of Listhings is that I really would like the conversation to be among participants as much as it is with me. In an online venue, this would mean comments. But Listings doesn’t support that. Also, the satisfaction rating and prioritization exercise is unique to each customer, so a single Listhings canvas cannot support everyone’s point of view. I suspect there are better ways, but this is a good start.

  4. Do you know any JTBD online communities or discussion forums? DM me if you ever want to discuss methodology/frameworks. Check out my blog post on #JTBD for WCM. http://www.percussion.com/community/blogs/tech-corner/20130111-jobs-to-be-done

  5. Hutch,

    Great stuff here…I agree that the Jobs process seems like too much effort when you first approach it.

    One detail question: how important do you think it is to put metrics on the outcomes? In the example here I suspect they’re looking for increased engagement, which presumably serves a larger marketing goal. The proxy metrics chosen are number of posts and comments. So where do those metrics come from? Are they already decided by some executive committee, and your mission is to move that needle?

    I point is out because choice of metric is non-trivial, and rarely arrived at with sufficient rigor. For example, it took Blogger quite some time and experimentation to determine that increasing the overall number of blog posts was the best way to improve the health of their business (vs. number of users, or comments, or something else). Twitter, on the other hand, looks to increase the number of people you’re following.

    I’ll attempt to put a bow on this whole thing: do you have any advice on how to proceed when you expect the team is focused on a “bad” metric?

    • Hey Ross – thanks for weighing in.

      I agree about the metric, but I don’t get as concerned *yet* about selecting a bad one. Because the entire notion that you could tie the outcome to something is frankly a bit revolutionary itself. A lot of innovation and development operates without such a clear view about what constitutes success.

      That being said, your point is well-taken. I think it is incumbent on the people managing the JTBD initiative to run the outcome through their own understanding of what’s important. But keep in mind that satisfying customer’s jobs is ultimately the path toward market share and growth.

  6. Pingback: Pricing the Customer’s Experience.. « Wim Rampen's Blog

  7. Pingback: McDonald’s wins on the fast food jobs-to-be-done that matter « I'm Not Actually a Geek

  8. Hi Hutch:

    Completely agree with the notion that using a jobs framework is the right way to approach all innovation (not just disruptive). One thing that seems to be missing is how you validate that these are the highest value jobs (and not just issues raised by the squeakiest wheels), and that your proposed solution (gamification, in this case) is the best way to do that job. The risk I see without a validation step/process is that you have a hammer, so everything is a nail.

    I don’t think it needs to be a big deal wrapped in formal methodology but it feels like some kind of gut check is important, and the more resources you need to spend on design/implementation, the more formality you want to attach to validating your jobs. Although closely related, I don’t think rating satisfaction and ranking importance is quite enough to validate the need or the means of addressing it. I know it’s more of an issue with big innovations, but there is also the problem that the customer doesn’t know what they want/need until they see it, or that they ask for specific (but wrong) things based on their current understanding that don’t solve the problem. (The truth is in what they do, not what they say….)

    Curious what your experience has been and whether/what you are doing in the way of validation?

  9. Solid framework, Hutch! A couple of things:
    – How do you adjust for frequency of jobs when aggregating results vs. priority given by users.
    – Would it make sense to add a ‘non-existent’ attribute for jobs that users want to accomplish but the product/service offers no way to do so? This would be in addition to low/medium/high for satisfaction for satisfaction with current outcomes?

  10. Pingback: Collecting and analyzing jobs-to-be-done | I'm Not Actually a Geek

  11. Pingback: Liens de la semaine (weekly)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: