By Lea Martin
What is “Jobs to be Done” theory?
“Jobs to be done,” at its most basic level, is the theory that people seek out products and services because they have jobs that they then “hire” those products and services to do.
In the Jobs to be Done (JTBD) framework, you're not simply buying a magazine at the airport: you're hiring The Atlantic to do the job of keeping you occupied during a long flight with unstable internet access. You could hire a book, a crossword, or Sudoku for the same job, but you choose to hire The Atlantic for a reason. JTBD helps companies understand what jobs people need done, as well as the “why” behind which products they hire.
How JTBD connects customer needs with product solutions
The Jobs to be Done framework was pioneered by engineer Tony Ulwick after he endured a massive professional failure that cost his employer IBM more than a billion dollars. The experience left him determined to figure out why the criteria for the failed product had been so off. Jobs to be Done was the template he came up with to assess the value of products to customers while they were still in the development process. “Companies confuse needs with solutions,” Ulwock stated in an interview. “[People] didn’t know they needed a microwave oven, for example, but they did know they wanted to minimize the time it takes to prepare a meal.”
Jobs to be Done was further popularized by Clayton Christensen, Professor of Business Administration at Harvard Business School. “Jobs-to-be-done theory…transforms our understanding of customer choice in a way that no amount of data ever could,” Christensen wrote, “because it gets at the causal driver behind a purchase.”
The Jobs to be Done theory is especially relevant to our current era, which is seemingly overflowing with demographic data. We've never known more about consumers—yet Christensen points out that still, for most companies, “innovation is still painfully hit-or-miss.”
We see this gap frequently with our clients. One appliance manufacturer believed its high-end, smart refrigerator was leading the market, until our hardware research revealed that participants found far more value in simple basics like spacious drawer bins than they did in modern amenities like voice control.
Why research frameworks like JTBD prevent product failure
Despite millions of dollars of investment, a shocking percentage of product, content and service launches still fail. Time after time, we see that demographic data or site analytics doesn't get to the “why” behind a consumer need or decision. In the words of Harvard marketing professor Theodore Levitt, “People don’t want to buy a quarter-inch drill. They want a quarter-inch hole!” Yet, brands focus all their energy on types of drills and drill price points, benchmarking the features and functions of their drill against rival drills. They spend millions to build the best-ever drill, completely losing sight of the job the customer needs done.
We’ve seen this misapprehension of user needs during our client research. For example, before running a JTBD study that focused on knowledge workers’ needs, our client believed that the need for connection, especially among remote coworkers, would rank highly. Our study found users did feel the need for connection, but that connection paled in comparison with their need to receive accurate information from others. Had this client moved forward with their assumptions around connection, they would have overlooked a far more important need.
How we use Jobs to be Done in practice
Along with Customer Success Outcomes (CSOs) and Critical User Journeys (CUJ), Jobs to be Done is a measurement framework for clients who are uncertain of what’s important to their customers, whether they’re heading in the right direction, or how to measure success. (To be clear, if a client has never done JTBD, and isn’t familiar with the framework statements, it can be difficult for them to adopt. CUJs and Mental Models are often much easier to comprehend and put into practice because of their plain language.)
All of the measurement frameworks have the same core approach. As with all foundational research, we start with qualitative interviews to understand needs and pain points. These interviews usually give us a laundry list of needs. In the case of JTBD, these needs are translated into a list of “Job Statements,” and can number well over 100.
From our aforementioned interviews and diary study with knowledge workers, we heard repeatedly that their work would be derailed because they were waiting on information from another team member. When the information did arrive, it might be inaccurate, which would force them to restart their process. We translated this issue into the job statement "Minimize the time it takes to receive accurate information."
Job Statements include four key components:
- Direction
- Performance metric
- Object of control
- Contextual clarifier (when needed)
Here's an example of what a JTBD statement might look like:
Once we have draft statements, the goal is to down-select around 25 statements so they can be prioritized via a quantitative survey at scale. We customize the down-selection process based on the client’s needs and timeline, but it often includes processes like client workshops to understand where within the problem space the team wants to position themselves, as well as conducting another round of qualitative sessions to refine and prioritize the statements from the user’s perspective.
Then, the quantitative survey prioritizes statements based on users’ relative satisfaction and importance, and can be used to evaluate clients’ own products and/or their competitors.
Once we have the prioritized list of statements, they can be used throughout the development process in evaluative research sessions to understand how the design changes are impacting user satisfaction across these key needs.
Alternatives to the Jobs to be Done framework
JBTD helps align teams by establishing a common, accessible language to describe user needs and define success. But like any system, JTBD has its limitations, and isn’t the best tool for every project. Its rigid statement format can make it difficult to pull out the emotional component of the job.
Before undertaking the process of developing a measurement framework, it's critical to figure out which framework is right for your team. If the specific approach and sentence syntax of the statements don’t resonate with your team, they will struggle to truly integrate the framework into their process, blocking the development of that common language.
We consider a number of different factors, based on the specific demands of a product or service, when evaluating which framework we recommend to a client. Things like:
- Are you looking to standardize how to measure needs based on time or effort? If so, consider JTBD.
- Do you want to highlight user success criteria? If so, consider using Blink’s Customer Success Outcomes (CSOs) or Customer Experience Optimization (CXO) popularized by Amazon.
- Do you need to understand the specific path users take through an existing product? If so, consider Critical User Journeys (CUJ) developed by Google.
- Do you want to understand people deeply and innovate beyond your current products? If so, consider Mental Models and Thinking Styles, a system developed by Indi Young that explores users’ motivations, intentions, and unmet needs. (Blink offers deep expertise in this system, reach out if you’d like to know more!)
JTBD = Make Things People Want
The JTBD framework helps make products people actually want. Rather than looking for correlations in oceans of customer data or getting caught up in investor hype, Jobs to Be Done provides a structure that helps break down data silos, establishes clear customer experience metrics, and guides businesses to innovate with intention.
At the same time, JTBD isn't the ideal framework for every instance. We advise clients on a case-by-case basis which outcome-driven framework will best help their team align, measure success, and inform ideation and innovation.
Still trying to decide which framework fits with your project? We can help with that—let’s discuss.
Lea Martin is Principal Researcher at Blink. She leverages her creative background and analytical mindset to strengthen collaboration between design and research. Prior to joining Blink, Lea worked as an industrial designer, developing consumer electronics, and as a UX researcher, creating educational and family safety apps.
