An Exclusive Interview with Jim Kalbach
The Jobs-to-be-Done (JTBD) approach offers a unique lens for viewing the people you serve. Instead of looking at the demographic and psychographic factors of consumption, JTBD focuses on what people seek to achieve in a given circumstance. People don’t “hire” products and services because of the demographic they belong to; instead, they employ solutions to get a job done.
JTBD is not about your product, service, or brand. Instead of focusing on your own solution, you must first understand what people want and why that’s important to them. Accordingly, JTBD deliberately avoids mention of particular solutions in order to first comprehend the process that people go through to solve a problem. Only then can a company align its offerings to meet people’s goals and needs.
I had the opportunity recently to interview Jim Kalbach, a noted author, speaker, and instructor in user experience design, information architecture, and strategy. He is currently Head of Customer Experience at MURAL, the leading online whiteboard. Jim has worked with large companies, such as eBay, Audi, Sony, Elsevier Science, LexisNexis, and Citrix. His latest book is The Jobs To Be Done Playbook.
Below is the text of the interview:
1. What is one of the biggest misconceptions people have about Jobs-to-be-Done (JTBD)?
There are a couple, actually.
First, I often hear others referring to JTBD as something “new.” It’s not. People have been working in the field for a couple of decades now. And precursors to modern JTBD go back nearly 40 years. We really just now see a surge of interest around JTBD, and the hype around it makes it feel new.
Second, JTBD often gets conflated with existing methods in other fields. Marketers look at it is as just another type of “voice of the customer” program. Or, folks coming from human-centered design and related fields see JTBD as a version of UX design or similar. While there might be some overlaps with existing disciplines, JTBD offers a unique perspective and yields unique insights.
Finally, I see JTBD as a “language” of sorts to describe the objectives and needs of the people you want to serve, and learning a language takes practice. Even people who “get” JTBD quickly need to put time into understanding the language and techniques, which at times can be specific and rigorous. I often see people expect to walk away from reading a book or taking a workshop fully capable of practicing JTBD. That’s rarely the case, and it typically takes some effort to work into the topic and apply it.
2. What are some of the benefits of taking a JTBD approach to innovation?
JTBD offers a unique perspective that points to new insights and opportunities. The JTBD approach intentionally forces us to expunge any mention of technology, solutions, brands, or methods from our language. In doing so, you’re able to then see your domain as people do. First and foremost, they want to get their job done, not necessarily interact with your product or service. Viewing objectives and outcomes people have independent of technology opens up new possibilities and yields new conversations that point toward innovation opportunities.
Also, but removing ourselves and technology from the equation, we can better future-proof our thinking. Solutions come and go. Technology is often a fad. Jobs, on the other hand, are stable when you boil them down to their fundamental steps.
3. Who needs to be considered after selecting a job to focus on?
At first, simply consider job performers. Once you’ve defined your target job, you first want to understand how the job gets done independently of any specific technology or solution. I find that different types of job performers emerge based on the key factors, or circumstances, of getting the job done that can give rise to different personas.
Within your team, I recommending going as broad as possible and including stakeholders at all levels. Yes, JTBD can help you find hidden needs to address. But it’s also a catalyst for conversations and a way to get team alignment. Think of the various ways you can involve others in everything from the definition of your jobs landscape to interviews with job performers to creating a job map to finding opportunities.
4. What is your perspective on the interrelationship between functional, social and emotional jobs within JTBD?
I find that functional jobs give the most structure and reliability to work with initiation. So your work is generally framed by functional jobs, with emotional and social aspects layered on top. Emotional and social aspect then play a larger role when finding solutions to the unmet needs you’ve found and help frame how you’ll solve for them.
5. What is a job statement and what role does it play?
First and foremost, a job statement is an expression of a functional job, either the main job or a job step. JTBD provides a language–with grammar and syntax–to capture the core objectives the people you serve are trying to get done and the process by which they do it. By expunging any reference to technology, products, services, brands, and methods, you get a unique view of the world–one that truly solution independent. Following the rules for forming job statements is important in JTBD work. That’s why I start there in my live workshops to set a good foundation.
6. Are there different levels of jobs that people should be aware of?
Yes. Anytime you’re dealing with human goals and needs, hierarchy is involved. It’s one of the first things you need to confront when working with JTBD, and one of the trickiest two. I typically see things at three fundamental levels:
1) Aspirations are the intangible, emotional goals people have in any given domain. They are often not measurable (or hard to measure), like “Provide a better home life for my family” or “Achieve job satisfaction.”
2) Main jobs represent the big, core functional area you want to research. They are framed in a way that has a “done” state, with a beginning, middle, and end (e.g., “Finance a new home” or “Find a new job”).
3) Job steps are the sub-jobs that reflect the process of getting a job done, typically shown in a job map (e.g., “Determine affordability” and “Apply for financing” or “Set career goals” and “Give notice”).
There may be more levels depending on the domain, but typically you can navigate the jobs hierarchy starting with these three.
7. How do you explain the difference between needs and jobs to people?
Needs, or desired outcomes, are the measures of success that people have from getting the job done. So if the main job is the simply functional process of job execution, the outcomes are “metrics” that determine whether it was accomplished successfully or not.
Jobs to be done separates jobs (objectives) from needs (outcomes) in the analysis. So instead of saying “Find the cheapest airfares quickly,” JTBD would separate that insight into two different buckets: “Find airfares” is the simple functional job, with its accompanying job steps. “Minimize the cost of airfare” and “Reduce the time it takes to find airfares” are two desired outcomes.
By separating objectives from outcomes, we can then explore ALL of the potential needs, of which there may be many, e.g., “Minimize the number of connecting flights” or “Maximize the chance of getting a preferred seat.” This increases the chance of finding unmet needs and opportunities others have overlooked.
8. Why should people use job stories instead of user stories and how do you craft a good job story?
You shouldn’t. Or at least, I’ve never found that job stories replace user stories. They’re complementary, in my opinion. I’ve found that job stories are good for describing the unmet needs you’re targeting for a specific initiative. They encapsulate the human-centered growth opportunities your team has agreed on and bring them into solutioning cycles.
User stories, on the other, are best for breaking down a large body of work (e.g., all of the functions of a big piece of software) into small units that can be worked on individually. I’d not try to do that with job stories.
9. Should people use consumption journey maps in place of customer journey maps, or alongside? How are they different?
There might be a difference between the two, but I generally don’t see a huge difference. Or at least, if you base a customer journey map on the consumption jobs (which it totally logically anyway) you’d end up with the same things in the
10. What are some of the keys to successfully bringing Jobs-to-be-Done (JTBD) to your organization?
Great question–it’s one of the most frequent ones I get.
There’s no one-size-fits-all answer, but there are many tactics you can bring together into a broader plan.
It’s not comprehensive but gives some good starting points. Here are some highlights:
- Start small and include JTBD techniques into your existing workflow
- Identify others interested in JTBD around, especially leaders who are attracted to the technique.
- Gather evidence and create a standard pitch so you have an immediate answer when some asked about JTBD and why they should try it. Include success stories internal and external to your organization.
Thank you for the great conversation Jim! I hope everyone has enjoyed this peek into the mind of the man behind the in-depth new title The Jobs To Be Done Playbook!