Bringing Business Impact and User Needs together with Jobs to be Done (JTBD)

In a previous post, I argued that designers haven’t found the vocabulary and tools to frame users’ problems in a way that aligns with stakeholder business strategies. In this post, I’ll make the case that Jobs to be Done work as a great “exchange” currency to facilitate strategy discussions around value between designers, business stakeholders, and technology people, and share some lessons I’ve learned on how to use Jobs to be Done to engage the stakeholders and influence business decisions that drive product vision forward.

TL;DV;

TL;DR;

• Jobs to be Done (JTBD) is valuable when working with Business Stakeholders because it helps facilitate discussions and focus on the most important objectives from the perspective of the job performer. A job refers to a goal or objective that is independent of any particular solution. Understanding the job performer’s desired outcome is crucial, as your service is merely a means to an end.
• Using outcome-driven methods shifts the focus towards determining what the job performer is trying to achieve. When the team debates which customer or user problems to prioritize, Jobs to be Done can provide a framework for identifying the measures of success tied to desired outcomes.
• Jobs to be Done also helps remove subjectivity when assessing the value of pursuing an opportunity. It assists in identifying how the value of an opportunity decreases for a specific outcome and how opportunities shift to other unsatisfied outcomes. By continuously prioritizing value creation for jobs that customers perceive as valuable, the team can adapt and evolve their solutions confidently.
• While value migrates over time, customers’ outcomes remain stable. What changes is the extent to which these outcomes are satisfied by new technologies and product features. Jobs to be Done serve as an effective way to frame the value proposition and product vision, enabling a long-term focus on stable customer outcomes.
• The use of Jobs to be Done as a common exchange currency promotes collaboration between leadership, designers, product managers, and developers. It encourages discussing problems rather than jumping to solutions, providing clarity and scope for discovery activities, and synthesizing research findings in a user-friendly format like Job Stories.
• Overall, leveraging Jobs to be Done during product discovery enhances understanding of the problem space, guides research efforts, and facilitates effective stakeholder communication and decision-making.

The Strategy Challenge

In a previous article, challenges that designers face to influence and translate strategy in ways that drive their user experience vision forward, I would say they begin with:

• Designers haven’t found the vocabulary and tools to frame users’ problems in a way that aligns with stakeholder business strategies.
  • Our user-centered methods have served us well in capturing the user’s voice by translating user needs and pain points into design insights.
  • However, we need a language, a tool, or a framework that can translate design insights into a currency that business stakeholders can understand.
• Designers may have naively mistaken position with influence.
  • While there are more and more Chief Design Officers (CDOs) leading innovation activities and fuelling internal design culture (“The increasing importance of strategic design” in Strategic Design, Calabretta et al., 2016), strategy cannot be effectively executed top-down.
  • Meanwhile, Even if a company has great design officials or design managers, we still need to translate strategy into something that teams working on products can turn into reality.
• Designers may have naively believed that the user perspective could be provided as simply one input at one point of the product development lifecycle (e.g. during the project/backlog/sprint planning phase).
  • In reality, any product that makes it into the world it’s actually the outcome of a set of dozens, hundreds, or — at times — thousands of decisions along the way (“Meet the Elements” in The Elements of User Experience: User-Centered Design for the Web and Beyond, Garret, J.J., 2010).
  • From that perspective, we need to “move upstream” and influence strategy, but also ensure we are all pedaling in the same direction during execution.

From that perspective, the role of designers must change. We must move from focusing only on specific innovation projects and design briefs to involvement in strategic decisions that influence and shape organizational strategy.

While in the past designers would concentrate on enhancing desirability, the emerging strategic role of designers means they have to balance desirability, feasibility and viability simultaneously. Designers need to expand their profiles and master a whole new set of strategic practices.

“Strategic Designers: Capital T-shaped professionals” in Strategic Design (Calabretta et al., 2016)

If designers are to take a more active role in shaping organizational strategy, how can they do that? Further, what is the skill set they need to acquire in order to think more strategically?

First, it is crucial that designers engage with their business stakeholders to understand what objectives and unique positions they want their products to assume in the industry, and the choices that are making in order to achieve such objectives and positions.

That’s why is important that designers engage with stakeholders early and often to make sure we’ve got the right framing of the problem space around the 3 vision-related questions (as per the Six Strategic Questions illustration above):

• What are our aspirations? Strategy implies the need for change, a desire to move from point A to point B. What are the hurdles to doing so? What opposing forces must you overcome to be able to reach the desired outcome? What problems are you solving? Focus on customers and users, but you may also have internal challenges you want to list here too.
• What are our challenges? To develop a great strategy, we first need to clarify what is the purpose of our enterprise, our mission, or our winning aspirations. The term “winning” means different things to different people so the first step in developing a great strategy is to specify exactly what winning will look like for us
• What will we focus on? Once we’ve stated are aspirations (“what winning will look like”), we then need to identify a playing field where we can realize our aspirations. No company can be all things to all people and win, so where-to-play choices – which markets, which customer segments, which channels, which industries, etc. – narrow our focus.

It’s been my experience while working with Business Stakeholders that Jobs to be Done are a great exchange currency when it comes to facilitating the discussions around what will we focus on.

What will we Focus on?

Once we’ve stated are aspirations (“what winning will look like”), we then need to identify a playing field where we can realize our aspirations. No company can be all things to all people and win, so where-to-play choices – which markets, which customer segments, which channels, which industries, etc. – narrow our focus. From a positioning perspective, we could pick a few segments/facets of the experience to focus on:

• USERS – Who will use our solution? We need to list the personas that are most relevant to the success of this strategy.
• REGIONS – What are the countries, languages, and cultures that are in play? 
• SCENARIOS – We need to indicate the key scenarios of use at a high level.
• AREAS OF UX – We need to strategically highlight aspects that should be prioritized such as information architecture, interaction design, and visual design, as well as attributes of usability such as control, learnability, or discoverability, among others.

If you’ve been working for any time with Human Centered Methods, you’ve probably noticed that there is a big overlap between these 3 strategic questions and the problem space that designers are particularly interested in understanding before solving a problem.

One of the tragedies in software development — and all product development for that matter — is that much of what we build doesn’t succeed. It doesn’t deliver the benefit we’d hoped. So, that’s a problem. But, even before that, it takes a bit of time to learn enough about the problems we’re solving to make good decisions about what we should build. We use discovery work to do all that. To answer questions, to test ideas, and to avoid – as much as possible – wasting time over-investing in quality stuff we shouldn’t have built in the first place (Patton, J., Dual Track Development is not Duel Track, 2017)

Product Discovery refers to the work that you do to decide what to build as discovery and the work that you do to build and ship a product as delivery.

Cagan, M., The origin of product discovery (2020)

This distinction matters: many companies put a heavy emphasis on delivery—they focus on whether you shipped what you said you would on time and on budget—while under-investing in discovery, forgetting to assess if you built the right stuff (Torres, T., Continuous Discovery Habits, 2021).

If you’ve been working for any time with Human Centered Methods, you’ve probably noticed how hard it is for us to have objective discussions around the prioritization of problems we are to solve, which ideas to test, and what we should not build. And I’ve seen many designers — myself included — make to mistake to turn these discussions into a zero-sum game: our user-centered design tools set may have focused too much on the needs of the user, at the expense of business needs and technological constraints.

What if there was a way that designers could bring our human-centered methods (seeking to gain empathy, understanding people’s decisions and actions, synthesizing human needs, etc.) closer to business stakeholders’ strategic thinking?

So back in 2010, my good friend Jon Innes introduced me to the concept of Outcome-Driven Innovation and I immediately saw how Jobs to be Done could be transformational in helping designers “speak” in a language that business people could understand.

From that point, it was not an easy journey: the challenge became how to engage the stakeholders and influence the business decisions that would drive the product vision forward.

Jobs to be Done as a common definition of Desirability

As I mentioned in a previous post, designers must become skilled facilitators that respond, prod, encourage, guide, coach, and teach as they guide individuals and groups to make decisions that are critical in the business world through effective processes. There are few decisions that are harder than deciding how to prioritize.

I’ve seen too many teams that a lot of their decisions seem to be driven by the question “What can we implement with the least effort” or “What are we able to implement”, not by the question “what brings value to the user”.

From a user-centered perspective, the most crucial pivot that needs to happen in the conversation between designers and business stakeholders is the framing of value:

• Business value
• User value
• Value to designers (sense of self-realization? Did I impact someone’s life in a positive way?)

The mistake I’ve seen many designers make is to look at prioritization discussion as a zero-sum game: our user-centered design tools set may have focused too much on the needs of the user, at the expense of business needs and technological constraints.

That said, there is a case to be made that designers should worry about strategy because it helps shape the decisions that not only create value for users but value for employees.

Companies that achieve enduring financial success create substantial value for their customers, their employees, and their suppliers.

Oberholzer-Gee, F. (2021). Better, simpler strategy (2021)

Therefore, a strategic initiative is worthwhile only if it does one of the following (Oberholzer-Gee, F. (2021). Better, simpler strategy. 2021):

• Creates value for customers by raising their willingness to pay (WTP): If companies find ways to innovate or improve existing products, people will be willing to pay more. In many product categories, Apple gets to charge a price premium because the company raises the customers’ WTP by designing beautiful products that are easy to use, for example. WTP is the most a customer would ever be willing to pay. Think of it as the customer’s walk-away point: Charge one cent more than someone’s WTP, and that person is better off not buying. Too often, managers focus on top-line growth rather than on increasing willingness to pay. A growth-focused manager asks, “What will help me sell more?” A person concerned with WTP wants to make her customers clap and cheer. A sales-centric manager analyzes purchase decisions and hopes to sway customers, whereas a value-focused manager searches for ways to increase WTP at every stage of the customer’s journey, earning the customer’s trust and loyalty. A value-focused company convinces its customers in every interaction that it has their best interests at heart.
• Creates value for employees by making work more appealing: When companies make work more interesting, motivating, and flexible, they are able to attract talent even if they do not offer industry-leading compensation. Paying employees more is often the right thing to do, of course. But keep in mind that more-generous compensation does not create value in and of itself; it simply shifts resources from the business to the workforce. By contrast, offering better jobs not only creates value, it also lowers the minimum compensation that you have to offer to attract talent to your business, or what we call an employee’s willingness-to-sell (WTS) wage. Offer a prospective employee even a little less than her WTS, and she will reject your job offer; she is better off staying with her current firm. As is the case with prices and WTP, value-focused organizations never confuse compensation and WTS. Value-focused businesses think holistically about the needs of their employees (or the factors that drive WTS).
• Creates value for suppliers by reducing their operating costs: Like employees, suppliers expect a minimum level of compensation for their products. A company creates value for its suppliers by helping them raise their productivity. As suppliers’ costs go down, the lowest price they would be willing to accept for their goods—what we call their willingness-to-sell (WTS) price—falls. When Nike, for example, created a training center in Sri Lanka to teach its Asian suppliers lean manufacturing, the improved production techniques helped suppliers reap better profits, which they then shared with Nike.

This idea is captured in a simple graph, called a value stick. WTP sits at the top and WTS at the bottom. When companies find ways to increase customer delight and increase employee satisfaction and supplier surplus (the difference between the price of goods and the lowest amount the supplier would be willing to accept for them), they expand the total amount of value created and position themselves for extraordinary financial performance. 

Organizations that exemplify value-based strategy demonstrate some key behaviors (Oberholzer-Gee, F., “Eliminate Strategic Overload” in Harvard Business Review, 2021):

• They focus on value, not profit. Perhaps surprisingly, value-focused managers are not overly concerned with the immediate financial consequences of their decisions. They are confident that superior value creation will result in improved financial performance over time.
• They attract the employees and customers whom they serve best. As companies find ways to move WTP or WTS, they make themselves more appealing to customers and employees who particularly like how they add value.
• They create value for customers, employees, or suppliers (or some combination) simultaneously. Traditional thinking, informed by our early understanding of success in manufacturing, holds that costs for companies will rise if they boost consumers’ willingness to pay—that is, it takes more-costly inputs to create a better product. But value-focused organizations find ways to defy that logic.

While in the past designers would concentrate on enhancing desirability, the emerging strategic role of designers means they have to balance desirability, feasibility and viability simultaneously. Designers need to expand their profiles and master a whole new set of strategic practices.”

“Strategic Designers: Capital T-shaped professionals” in Strategic Design (Calabretta et al., 2016)

For such a conversation to pivot towards focusing on value to happen, designers will need to get better at influencing the strategy of their design project. However, some designers lack the vocabulary, tools, and frameworks to influence it in ways that drive user experience vision forward. Advocating for how can we inform the decisions that increase our customer’s Willingness to Pay (WTS) by — for example — increasing customer delight.

Here is — yet again — another advantage of Jobs to be Done: when the team engages in endless discussions around which customer/user problems we should be focusing on, Jobs becomes a unit of analysis that helps teams have facilitated discussions around finding ways to remove (or at least reduce) subjectivity while assessing value, especially while we are devising ways to test our hypothesis.

Jobs to be Done as a Common Strategy Vocabulary

The challenge of arriving at a business definition for human needs starts with language. An agreed-on language is fundamental to success in any discipline, yet confusion has permeated product development because companies continue to define “requirements” as any kind of customer input: customer wants, needs, benefits, solutions, ideas, desires, demands, specifications, and so on. But really, those are all different types of inputs, none of which can be used predictably to ensure success (Ulwick, A. W., What customers want, 2005).

Part of the challenge is that people’s decisions and actions are seemingly unpredictable. Resting your growth strategy on fuzzy concepts like “needs” and “empathy” is daunting. While psychology and other fields (including design) have precise definitions of human needs, business does not. As a result, risk-averse organizations struggle to grasp the customer perspective and align to it.

Kalbach, J., Jobs to be Done Playbook (2020)

Jobs to be Done (JTBD) is a new way to think about the innovation process. Three key tenets define this approach (Ulwick, A. W., What customers want, 2005):

• Customers buy products and services to help them get jobs done. In our study of new and existing markets, we find that customers (both people and companies) have “jobs” with functional dimensions to them that arise regularly and need to get done. When customers become aware of such a job, they look around for a product or service that will help them get the job done. We know, for example, that people buy mowers so they can cut their lawns; and they buy insurance to limit their financial risks; Corn farmers, to take another example, buy corn seed, herbicides, pesticides, and fertilizers to help them grow corn. Carpenters buy circular saws to cut wood. Virtually all products and services are acquired to help get a job done.
• Customers use a set of metrics (performance measures) to judge how well a job is getting done and how a product performs. Just as companies use metrics to measure the output quality of a business process, customers use metrics to measure success in getting a job done. Customers have these metrics in their minds, but they seldom articulate them, and companies rarely understand them. We call these metrics the customers’ desired outcomes. They are the fundamental measures of performance inherent to the execution of a specific job. When cutting wood with a circular saw, carpenters may judge products for their ability to minimize the likelihood of losing sight of the cut line, the time it takes to adjust the depth of the blade or the frequency of kickbacks. Only when all the metrics for a given job are well satisfied are customers able to execute the job perfectly. Ironically, these metrics are overlooked in the customer-driven world because they are not revealed by listening to the “voice of the customer.
• These customer metrics make possible the systematic and predictable creation of breakthrough products and services. With the proper inputs in hand, companies dramatically improve their ability to execute all other downstream activities in the innovation process, including their ability to identify opportunities for growth, segment markets, conduct competitive analysis, generate and evaluate ideas, communicate value to customers, and measure customer satisfaction.

In the outcome-driven paradigm the focus is not on the customer, it is on the job: the job is the unit of analysis. When companies focus on helping the customer get a job done faster, more conveniently, and less expensively than before, they are more likely to create products and services that the customer wants.

Ulwick, A. W., What customers want (2005)

At its core, the concept of JTBD is a straightforward focus on people’s objectives independent of the means used to accomplish them. Only after a company chooses to focus on the job, not the customer, are they capable of reliably creating customer value. Through this lens, JTBD offers a structured way of understanding customer needs, helping to predict better how customers might act in the future (Kalbach, J. Jobs to be Done Playbook, 2020).

What are Jobs to be Done, Really?

Clayton Christensen credits Ulwick and Richard Pedi of Gage Foods with the way of thinking about market structure used in the chapter “What Products Will Customers Want to Buy?” in his Innovator’s Solution and called “jobs to be done” or “outcomes that customers are seeking”.

A customer’s job could be the tasks that they are trying to perform and complete, the problems they are trying to solve, or the needs they are trying to satisfy. (Osterwalder, A., Pigneur, Y., Papadakos, P., Bernarda, G., Papadakos, T., & Smith, A. Value proposition design, 2014).

What is the job performer trying to achieve? A job is a goal or an objective independent of your solution. The aim of the job performer is not to interact with your company but to get something done. Your service is a means to an end, and you must first understand that end.

Kalbach, J., Jobs to be Done Playbook (2020)

Because they don’t mention solutions or technology, jobs to be done should be as timeless and unchanging as possible. Ask yourself “How would people have gotten the job done 50 years ago?” Strive to frame jobs in a way that makes them stable, even as technology changes. (Kalbach, J. Jobs to be Done Playbook, 2020).

Distinguish between three main types of customer jobs to be done and supporting jobs (Osterwalder, A., Pigneur, Y., Papadakos, P., Bernarda, G., Papadakos, T., & Smith, A. Value proposition design, 2014):

• Functional Jobs: When our customers try to perform and complete a specific task or solve a specific problem
• Social Jobs: when our customers want to look good or gain power and status. These jobs describe how customers want to be perceived by others
• Personal/Emotional Jobs: When our customers seek a specific emotional state, such as feeling good or secure.

Functional (or Main) Jobs

The main job is the overall aim of the job performer. Determining the main job defines your overall playing field and sets your scope of innovation. You should express the main job in functional terms, such as a utilitarian goal (hence “functional”). It’s an act that will be performed and should have a clear end state—the “done” part of jobs to be done. The main job is broad and straightforward, serving as an anchor for all other elements of your JTBD investigation. For example, prepare a meal, listen to music, or plan long-term financial well-being are examples (Kalbach, J. Jobs to be Done Playbook, 2020).

The main job shouldn’t include adjectives like quick, easy, or inexpensive. Those are considered to be needs, or the metrics by which job performers compare solutions, which are handled separately. The main job is also different from your marketing message or value proposition statement, which tends to be persuasive to evoke an emotion.

Kalbach, J. Jobs to be Done Playbook (2020)

Related jobs are adjacent to the main job, but are significantly different. For instance, if you define growing a retirement portfolio as the main job, related jobs may be financing a new home or balancing cash flow. Identifying related jobs as such can help your team understand the main job—what it is and what it is not (Kalbach, J. Jobs to be Done Playbook, 2020).

Emotional Jobs

Emotional jobs reflect how people want to feel while performing the job. Statements usually start with the word “feel.” For example, if the main job of a keyless lock system is to secure entryways to a home, emotional jobs might be to feel safe at home or feel confident that intruders won’t break in while away (Kalbach, J. Jobs to be Done Playbook, 2020).

My colleague Ritesh Chopra has a great example of how to connect the dots between Aspirations, Emotional Jobs, Job Stories, and User Stories (more on laddering and Jobs Hierarchy later):

• Aspiration: I want to become a better father. 
• Job to be Done/Job Story: Participate in my kids’/family’s events. When there are upcoming events in my family’s life (e.g.: my son’s soccer finals, or my daughter’s ballet recital), I want to make sure I participate, so that I can become a better father.
• Emotional Job: I want to feel accomplished in keeping my promises to my kids. 
• User Story: As a parent, I want to have important events of my family’s life added to my calendar so that I can receive notifications (with time to departure) and not forget about the events.

I’ve been working on Enterprise Software for 25 years now, and I’ve seen many people in leadership ignore conversations about emotional needs. And I get it: for designers (and compassionate business leaders) it has been hard to make convincing arguments that connect the dots between emotional needs and the business bottom line. The COVID-19 pandemic — and the “Great Resignation” that followed — came as a wake-up call that emotional needs cannot be ignored for long. Research is pointing out that is about time we start talking about “feelings” in the Enterprise.

Research on positive organizational psychology demonstrates that not only is a cut-throat environment harmful to productivity over time, but that a positive environment will lead to dramatic benefits for employers, employees, and the bottom line (Seppäl, E., & Cameron, K. Proof that positive work cultures are more productive, 2015): 

• Businesses with disengaged workers had 37% higher absenteeism
• Businesses with disengaged workers had 49% more accidents
• Businesses with disengaged workers had 60% more errors and defects
• Businesses with disengaged workers had 65% lower share prices over time

When people’s basic emotional needs are met, they do better work. When they feel valued and important, they perform at much higher levels. When they have a sense of control, they will take initiative. When they feel a sense of belonging, they will contribute more. When they feel they are being treated fairly, they will go the extra mile.

Gray, D., Liminal thinking: Create the change you want by changing the way you think (2016) 

If you take these things away, you are starving them emotionally. When people are emotionally starving, they come up with conspiracy theories. They cover up, hide, and hoard information. They play political games (Gray, D., Liminal thinking: Create the change you want by changing the way you think, 2016).

In the previous article, I mentioned that — when customers evaluate a product or service — they weigh its perceived value against the asking price. Marketers have generally focused much of their time and energy on managing the price side of that equation since raising prices can immediately boost profits. But that’s the easy part: Pricing usually consists of managing a relatively small set of numbers, and pricing analytics and tactics are highly evolved. What consumers truly value, however, can be difficult to pin down and psychologically complicated (Almquist, E., Senior, J., & Bloch, N., The Elements of Value, 2016).

How can leadership teams actively manage value or devise ways to deliver more of it, whether functional (saving time, reducing cost) or emotional (reducing anxiety, providing entertainment)? Discrete choice analysis—which simulates demand for different combinations of product features, pricing, and other components—and similar research techniques are powerful and useful tools, but they are designed to test consumer reactions to preconceived concepts of value—the concepts that managers are accustomed to judging (Almquist, E., Senior, J., & Bloch, N., The Elements of Value, 2016).

This is yet another advantage of Jobs to be Done: they can help you quantify Emotional value from the perspective of users.

Social Jobs

Social jobs indicate how a job performer is perceived by others while carrying out the job. For instance, adult diapers have an important social job of avoiding embarrassment in public. Or, in the previous example, the person with a keyless door lock might be seen as an innovator in the neighborhood (Kalbach, J. Jobs to be Done Playbook, 2020).

Again, I realize it is hard to make convincing arguments that help connected the dots between social needs and the business bottom line. I’ve heard the argument that social jobs (“I want to be perceived as…”) are the realm of marketing and branding, not experience or service design. But here is the counterargument from Scott Lietzke (our VP of Product Design at SAP SuccessFactors): for most enterprises, the experience is the brand!

From that perspective, I find it very easy to connect Social Jobs to branding objectives and values at the Individual Level and at the Organizational Level.

Social Jobs at the Individual Level

As stated earlier, Social Jobs help us understand how customers/users want to be perceived. That said, for some categories of products — like Luxury Goods — the social jobs far outweigh the functional jobs.

People often make choices by tapping on their core values and priorities

Bucher, A., Engaged: Designing for Behavior Change (2020)

Simon Sinek created an illustration that he calls “The Golden Circle, with concentric circles that he refers to as WHY, HOW, and WHAT. He stresses that all conversations should start inside out. It all starts with why. He argues that customers buy your “why” not your “what”.

The Why is the purpose, cause, or belief that drives every organization and every person’s individual career. Why does your company exist? Why did you get out of bed this morning? And why should anyone care?

“The Golden Circle” in Start with Why: How Great Leaders Inspire Everyone to Take Action (Sinek, 2011)

If your business’s core values and vision align with what your customers and users want to become, it will speak louder than any advertising or marketing campaign.

As product designers, we can help people think about what really matters to them and draw connections between their values and behaviour change.

Bucher, A., Engaged: Designing for Behavior Change (2020)

Please mind the “behavior change” here, since we’ll come back to it when we talk about connecting outcomes to business impact.

Here is — yet again — another advantage of using Jobs to be Done to frame our value proposition: because the customers buy your “why” not your “what”, Jobs to be Done provide an objective way for us to visualize how our organization’s core values align with those of our customers/users.

This brings us to Social Jobs at the Organizational Level.

Social Jobs at the Organizational Level

Going back to the argument that social jobs (“I want to be perceived as…”) are the realm of marketing and branding, not experience or service design, here is my counterargument: if we don’t understand who our customers/users want to become, it’s going to be hard to have objective conversations about how to create products or services that help them become that.

My colleague Rebecca Reagan-Thieme has a great example of how Social Jobs help us connect to business objectives:

When I think about accomplishing our company goals, I want to leverage my team’s full potential to drive individual & organisational growth (Functional Job of a Leader)

Going up the ladder of abstraction (more on laddering and Jobs Hierarchy later), Rebecca would argue that:

• Leaders don’t want just to leverage their team’s full potential to drive individual and organizational growth, they want to be known for achieving ambitious goals (Social Job)… but why?
• Leaders don’t want just to be known for achieving ambitious goals, they want to be perceived as good managers (Social Job that translates into personal branding).

I’m not suggesting that social jobs are only good for justifying either of Jobs to be Done, or only meant to help establish a marketing/ branding approach, but that Jobs to be Done brings them together: for most enterprises, the experience is the brand!

Think about your own experience with — let’s say — your employer: when employers provide increased benefits to their employees, they do it in the hope of increasing employee retention (a functional job at the Organizational Level), which indirectly leads to building their brand as a good employer (a Social Job at the Organizational Level).

If you want to have stats and figures to justify social jobs like these, go back and read Proof That Positive Work Cultures Are More Productive that I mentioned earlier (Seppäl, E., & Cameron, K., 2015)

Here is — yet again — another reason for using Jobs to be Done to frame our value proposition: Jobs to be Done provide an objective way for us to understand and discuss who our customers and/or users want to become, allowing us to create products or services that help them become that.

Jobs Hierarchy

Goals are hierarchical. Through a process of laddering, you can roll up objectives to different levels. The goal at one level may be a stage for the next. In JTBD, there are four levels to consider (Kalbach, J. Jobs to be Done Playbook, 2020):

• Aspirations: An ideal change of state, something the individual desires to become
• Big Job: A broader objective, typically at the level of the main job
• Little Job: A smaller job that corresponds roughly to stages in a big job
• Micro-Job: Activities that resemble tasks, but are formulated in terms of JTBD

Getting the right level of abstraction is critical. Ask “why?” to move up in the JTBD hierarchy and ask “how?” to move down.

Kalbach, J. Jobs to be Done Playbook (2020).

When working with JTBD, you’ll confront the issue of granularity. The question you need to answer is, “At what level of abstraction do you want to try to innovate?” There’s no right or wrong answer—it depends on your situation and aim. Getting the right altitude is key. Objectives at one level roll up into higher-order goals, generally called laddering. In JTBD work, the principle of laddering applies as well. For instance, in his book Competing Against Luck, professor Clayton Christensen points to “big jobs,” or things that have a big impact on our lives (like finding a new career) and “little jobs,” or things that arise in our daily lives, such as passing time while waiting in line (Kalbach, J. Jobs to be Done Playbook, 2020).

Going back to the “People don’t want a quarter-inch drill, they want to hole in the wall” example, being able to navigate the levels of granularity through abstraction laddering can really help get to the heart of why functional jobs exist and understand what customers and users perceive as real value:

• People don’t want a quarter-inch drill, they want the hole on the wall… but why?
• People don’t want just the whole on the wall, they want to hang a picture on the wall… but why?
• People don’t want just to hang a picture on the wall, they want their house to look pretty… but why?
• People don’t want just to make their house look pretty, they want to impress their friends… but why?
• People don’t just want to impress their friends, they want to be perceived as someone with good taste… but why?

You get the idea!

Keeping your work at the appropriate granularity can be tricky, but part of the territory. Sometimes, you need to know the broadest possible jobs—how customers want to change their lives. Other times, you’ll be operating at a lower level with a narrower scope (Kalbach, J. Jobs to be Done Playbook, 2020).

Here is — yet again — another advantage of Jobs to be Done: we can use abstraction laddering to help teams transition from what users are trying to get done (the “why”s) to the solution (the “how”s).

Where Jobs to be Done Come From?

For a company to innovate, it must create products and services that let consumers perform a job faster, better, more conveniently, and/or less expensively than before. To achieve this objective, companies must know what outcomes customers are trying to achieve (what metrics they use to determine how well a job is getting done) and figure out which technologies, products, and features will best satisfy the important outcomes that are currently underserved (Ulwick, A. W., What customers want, 2005)

To define just what “faster” or “better” means, companies must be able to capture from customers the set of metrics that define how they want to get the jobs done and what it means to get the job done. These metrics are the customers’ desired outcomes.

Ulwick, A. W., What customers want (2005)

In order to capture these desired outcomes, the best place to start is to understand the context of where and when the job gets done, what customers are currently experiencing as pains, and what — from their perspective — they would perceive as gains.

Customer jobs often depend on the specific context in which they are performed. The context may impose certain constraints or limitations. For example, calling somebody on the fly is different when you are traveling on a train than when you are driving a car. Likewise, going to the movies with your kids is different than going with your partner (Osterwalder, A., Pigneur, Y., Papadakos, P., Bernarda, G., Papadakos, T., & Smith, A. Value proposition design, 2014).

Customer Pains

Pains describe anything that annoys your customers before, during, and after trying to get a job done or simply prevents them from getting a job done. Pains also describe risks, that is, potential bad outcomes, related to getting a job done badly or not at all. There are three types of customer pains and how severe customers find them (Osterwalder, A., Pigneur, Y., Papadakos, P., Bernarda, G., Papadakos, T., & Smith, A. Value proposition design, 2014):

• Undesired outcomes, problems, and characteristics: Pains are functional (e.g., a solution doesn’t work, doesn’t work well, or has negative side effects), social (“I look bad doing this”), emotional (“I feel bad every time | do this”), or ancillary (“It’s annoying to go to the store for this”). This may also involve undesired characteristics customers don’t like (e.g., “Running at the gym is boring,” or “This design is ugly”).
• Obstacles: These are things that prevent customers from even getting started with a job or that slow them down (e.g., “I lack the time to get this job done accurately,” or “I can’t afford any of the existing solutions”).
• Risks (undesired potential outcomes): What could go wrong and have important negative consequences (e.g., “I might lose credibility when using this type of solution,” or “A security breach would be disastrous for us”).

To clearly differentiate jobs, pains, and gains, describe them as concretely as possible. When you understand how exactly customers measure pain severity, you can design better pain relievers in your value proposition.

Osterwalder, A., Pigneur, Y., Papadakos, P., Bernarda, G., Papadakos, T., & Smith, A. Value proposition design (2014).

The following list of trigger questions can help you think of different potential customer pains (Osterwalder, A., Pigneur, Y., Papadakos, P., Bernarda, G., Papadakos, T., & Smith, A. Value proposition design, 2014):

• How do your customers define too costly? Takes a lot of time, costs too much money, or requires substantial effort?
• What makes your customers feel bad? What are their frustrations, annoyances, or things that give them a headache?
• How are current value propositions underperforming for your customers? Which features are they missing? Are there performance issues that annoy them or malfunctions they cite?
• What are the main difficulties and challenges your customers encounter? Do they understand how things work, have difficulties getting certain things done, or resist particular jobs for specific reasons?
• What negative social consequences do your customers encounter or fear? Are they afraid of a loss of face, power, trust, or status?
• What risks do your customers fear? Are they afraid of financial, social, or technical risks, or are they asking themselves what could go wrong? What’s keeping your customers awake at night? What are their big issues, concerns, and worries?
• What common mistakes do your customers make? Are they using a solution the wrong way?
• What barriers are keeping your customers from adopting a value proposition? Are there upfront investment costs, a steep learning curve, or other obstacles preventing adoption

Customer Gains

Gains describe the outcomes and benefits your customers want. Some gains are required, expected, or desired by customers, and some would surprise them. Gains include functional utility, social gains, positive emotions, and cost savings. There are four types of customer gains in terms of outcomes and benefits (Osterwalder, A., Pigneur, Y., Papadakos, P., Bernarda, G., Papadakos, T., & Smith, A. Value proposition design, 2014):

• Required gains: These are gains without which a solution wouldn’t work. For example, the most basic expectation that we have from a smartphone is that we can make a call with it.
• Expected gains: These are relatively basic gains that we expect from a solution, even if it could work without them. For example, since Apple launched the iPhone, we expect phones to be well-designed and look good.
• Desired gains: These are gains that go beyond what we expect from a solution but would love to have if we could. These are usually gains that customers would come up with if you asked them. For example, we desire smartphones to be seamlessly integrated with our other devices.
• Unexpected gains: These are gains that go beyond customer expectations and desires. They wouldn’t even come up with them if you asked them. Before Apple brought touch screens and the App Store to the mainstream, nobody really thought of them as part of a phone.

As with pains, it’s better to describe gains as concretely as possible to clearly differentiate jobs, pains, and gains from one another. When you understand how exactly customers measure gains (i.e., outcomes and benefits), you can design better gain creators in your value proposition.

Osterwalder, A., Pigneur, Y., Papadakos, P., Bernarda, G., Papadakos, T., & Smith, A. Value proposition design (2014).

The following list of trigger questions can help you think of different potential customer gains (Osterwalder, A., Pigneur, Y., Papadakos, P., Bernarda, G., Papadakos, T., & Smith, A. Value proposition design, 2014):

• Which savings would make your customers happy? Which savings in terms of time, money, and effort would they value?
• What quality levels do they expect, and what would they wish for more or less of?
• How do current value propositions delight your customers? Which specific features do they enjoy? What performance and quality do they expect?
• What would make your customers’ jobs or lives easier? Could there be a flatter learning curve, more services, or lower costs of ownership?
• What positive social consequences do your customers desire? What makes them look good? What increases their power or their status?
• What are customers looking for most? Are they searching for good design, guarantees, specific or more features?
• What do customers dream about? What do they aspire to achieve, or what would be a big relief to them?
• How do your customers measure success and failure? How do they gauge performance or cost?
• What would increase your customers’ likelihood of adopting a value proposition? Do they desire Lower cost, less investment, lower risk, or better quality

Uncovering Jobs to be Done

If you’ve got this far into this article, I bet you just want to know how to uncover these jobs and be done with them! That said, I have a couple of disclaimers (and some words of caution) before giving some tips on how to uncover jobs.

First, uncovering jobs is not much different from other human-centered design techniques for discovering human needs. So — from that perspective — nothing replaces understanding who your users and customers are, how they do their work, and what pains they are experiencing while at it.

There is no shortcut to understanding the domain you’re working on! After working in Enterprise software for 25 years in all kinds of applications — ranging from design software like Infrastructure Design Software (like AutoCAD Map3d) to Internet-of-Things (like Vehicle Tracking and Asset Management) to HR Software — the hard truth is that acquiring subject matter expertise takes time. Still, it will help you uncover jobs in the long run!

Second, even when you think you understand the domain and you’ve talked to “enough” customers, good strategists retain a good dose of skepticism to keep their biases in check and not jump to conclusions too early!

Third, good strategists need to live with the tension of making sure the team shares a good shared understanding of the problem before jumping to solutions while not having to know all the answers before getting started. In complex domains like Enterprise software, there will always be more jobs to uncover, and there will always be more problems to solve than we have time to solve! A good strategist helps the team create good problem framing, create great choices, and help teams prioritize the desirable, viable, and feasible solutions.

With these disclaimers out of the way, let’s learn how to uncover jobs!

Uncovering Jobs to be Done begins with uncovering the desired outcomes that people are looking for while performing the job (Kalbach, J. Jobs to be Done Playbook, 2020):

• What workarounds exist in your process?
• What do you dread doing? What do you avoid? Why?
• What could be easier? Why?
• Why do you avoid doing certain parts of the job?
• What’s the most annoying part? Why is that frustrating?
• How do you feel when the job is completed?”

If you’ve worked with any method that claims to be “Human-Centered” for any period of time, you will soon realize why Jobs to be Done are well positioned in the lane of designers and user researchers, because these questions have a great overlap with the exploration of the problem space that designers are particularly interested in understanding before solving a problem. That’s why I feel so strongly that Jobs to be Done is a good “exchange” currency between designers, business stakeholders, and — I dare to say — technology people.

Avoid the Traps of “Listening to Customers”

It’s no secret that customer interviews are key in helping innovators learn about and validate business opportunities. Innovators always hear: “You have to get out of the building”, “Go to customers”, or “Just interview prospects!” Now, the problem with customer discovery (and customer interviews specifically) is that, if done wrong, they can send innovators on the wrong path fast (Garbugli, É., Solving Product, 2020).

Here is something very controversial — especially coming from a designer — that I first learned from Tomer Sharon (more on him later): don’t listen to users!

Gathering requirements for a product is not simply a matter of asking users what they need, like gathering pebbles from a beach. One cannot simply ask for design requirements, in part because people don’t know what technology is capable of, but more because most people are not aware of what they really do. The everyday things people do become habitual and unconscious, so they are usually unable to articulate their practices .

Holtzblatt, K., & Beyer, H., Contextual Design: Design for Life (2016)

Managers must be aware of the types of information they are obtaining when listening to the “voice of the customer.” Many firms unknowingly capture a combination of all these types of information and attempt to use them all–adding to the confusion. That challenge is that — more often than not — customers can provide their input in a very unstructured way: wants, needs, benefits, solutions, ideas, desires, demands, specifications, and so on. But really, those are all different types of inputs, none of which can be used predictably to ensure success. (Ulwick, A. W., What customers want, 2005).

What many managers fail to recognize is that none of these types of inputs provide developers, engineers, marketers, and others with the information they need to devise breakthrough solutions and transform the innovation process into a predictable discipline.

Ulwick, A. W., What customers want (2005).

Don’t Listen to Solutions

Many customers offer their requirements in the form of a solution to a problem. Often, customers will describe the physical or tangible features they want to see in the products or services they use. For instance, customers may tell a razor manufacturer that they want a rubberized handle or a lubrication strip on the razor head. Each of these statements represents a possible solution to a problem the customer faces. But most customers are not technologists, engineers, or scientists. They do not always have the best solutions, which means their suggestions may lead to products and services that ultimately disappoint them. Customers also do not know how the features they are requesting will affect other, possibly more important, dimensions of the product. Again, ultimately they may not like a version of the product that incorporates their requested features. Such customer feedback also can inhibit the company from looking beyond what its customers are requesting–a practice that leads to the creation of “me-too” rather than breakthrough products and services (Ulwick, A. W., What customers want, 2005).

This is not to say that companies should not consider customer ideas–they should. But when capturing customer requirements, managers must be looking for the criteria customers use to measure the value of a product or service–not their ideas about the product or service itself.

Ulwick, A. W., What customers want (2005)

Don’t Listen to Specifications

Customers often focus on product specifications, giving interviewers detailed instructions on particular design characteristics: size, weight, color, shape, look, or feel. Razor users may request “a wider handle”, “a lighter weight”, or “a sleek look.” Again, by accepting this input from customers, companies assume that the customer knows the best solution–which is often not the case. A wider handle, for example, may have been requested to prevent the razor from slipping out of the user’s hand while shaving. Although a wider handle may be helpful in solving the problem, a better option might be a regular-size handle with a ribbed, rubberized grip. Although this type of feedback may be appropriate in certain situations, like among government contractors, for instance. (Ulwick, A. W., What customers want, 2005)

Accepting specifications as customer inputs inherently prevents engineers and designers from using their creative skills to devise breakthrough products and services

Ulwick, A. W., What customers want (2005)

Don’t Listen to Needs

Customers’ needs are usually expressed as high-level descriptions of the overall quality of a product or service. They are typically stated as adjectives and inherently do not imply a specific benefit to the customer. For instance, customers commonly say they want a product or service to be “reliable,” “effective,” “robust,” “dependable,” or “resilient.” Razor users may want the product to be “durable and strong.” Although these simple statements provide some indication as to what customers are looking for, they have one major drawback. They are imprecise statements open to interpretation and present designers, developers, and engineers with the impossible task of figuring out just what customers really mean by “durable” or ” strong.” If engineers faced the task of making a razor more “durable,” would they try to make the blade last longer, resist bending, or withstand constant moisture? Would any of these actions satisfy the customer’s true measure of “durable?” (Ulwick, A. W., What customers want, 2005).

Because these inputs are imprecise, they leave too much to chance. This often leads to frustration and friction between the marketing and development departments. Marketing believes it is providing product developers with customer requirements, and developers believe they are receiving useless information–which from their perspective, they are. Good customer input must be concise, actionable, and measurable.

Ulwick, A. W., What customers want (2005)

Don’t Listen to Benefits

Customers often use benefits statements to describe what value they would like a new product or service feature to deliver. They often use words like “easy to use,” “faster,” or “better.” A razor user may want “a better shave,” “an easy cleanup,” or “a faster shave.” These statements may be useful for marketing-communication purposes, but, again, they present designers and engineers with ambiguous information that can’t be measured or acted upon. In one study we conducted with Motorola cell phone users, for example, we found there were twenty-one different ways in which customers defined “easy to use.” Their desired outcomes included, “minimizing the time it takes to look up a needed phone number,” “minimizing the likelihood of calls being made by inadvertently hitting the keypad,” and “minimizing the time it takes to dial a number without looking at the keypad.” In each of those situations, ‘”easy to use” takes on a different meaning and has different implications for designers seeking to improve or extend the product. Without understanding exactly what is meant, and which measures of value are most important to customers, managers run the risk of focusing on the wrong opportunities and making the wrong design decisions (Ulwick, A. W., What customers want, 2005).

Techniques for Uncovering Jobs

In order to capture jobs, it’s important to base your innovation on real behaviors- not preferences or opinions. You can’t count on prospects, executives, or other stakeholders to tell you what to build. It’s your responsibility to make sure that you are addressing a real opportunity (Garbugli, É., Solving Product, 2020):

There are a few techniques that can help reveal true customer behaviors:

• Learning Through Sales Safaris will be particularly useful if you intend to work on consumer products. Sales Safaris can be a good option when customer access is limited.
• Learning Through Customer Interviews can help you understand specific behaviors or explore customer segments. Interviews are the Swiss Army knife of customer research.
• Observing Behavior Through Contextual Inquiries can help you understand the customer’s job at a deeper level by studying prospects in their home or work environment. It’s the ideal technique when you’re able to get a lot of face time with prospects.
• Analyzing Quantitative and Analytics Data helps you narrow the places where you want to start looking for jobs and help you scale!
• Learning Through Experience Sampling helps you answer high-level business (or roadmap) questions rather than evaluating a design or product that already exists.
• Clustering Analysis with Value Proposition Design helps you tackle a core challenge of every business — creating compelling products and services customers want to buy.

Learning through Sales Safari

Sales Safari is a research technique based on ethnography developed by serial entrepreneurs Amy Hoy and Alex Hillman. In a way, the technique applies the idea of ethnography — direct observation of users in their natural environment — to the Internet. Part of the thesis behind the technique is that the problems are already all out there. Instead of looking for new problems, you go and find problems people already have.  Organizing a Sales Safari first means homing in on a market, looking for their online watering holes–places where prospects gather for pleasure or for work-to-do research (Garbugli, É., Solving Product, 2020).

Watering holes can be found by performing searches around your target market. For example:

• “[ Market ] + mailing list”
• “[ Market ] + forum”
• “[ Market ] + competition”

Learning Through Customer Interviews

Jobs don’t come in neat, little packages. You have to hunt for them. You won’t find jobs from analytics or marketing surveys, and you can’t just “brainstorm” jobs and needs. You have to get out and talk to job performers in formal interviews. Start by getting the right people—job performers (Kalbach, J., Jobs to be Done Playbook (2020).

Now, the problem with customer discovery-and customer interviews specifically-is that, if done wrong, they can send innovators on the wrong path fast. Customers and users are not skilled at identifying their own pain points and struggling moments — or at least, not in a way that translates into useful inputs to product development. Nor should they: It’s your role to get the right inputs. (Garbugli, É., Solving Product, 2020).

Start by defining the market you would like to learn from. Unless you have a clear idea of the market you’re targeting, it’s generally a good idea to start broader, and gradually refine your segmentation as you learn. Once you’re starting to get interviews, start putting together an interview script.

Garbugli, É., Solving Product (2020).

Open-ended questions–questions often starting with “Why”, “What”, “Where”, or “How”-help capture needs, opinions, stories, or feedback, while closed-ended questions-questions that can often be answered by “Yes” or “No”-help converge on relevant information (Garbugli, É., Solving Product, 2020).

Note that jobs interviews are not intended for gaining empathy for participants per se, although that is often inevitable. Critics point out that jobs interviews miss a lot of the details about the person’s overall experience. Jobs interviews also don’t get at psychological states, even if there are questions about emotions and social aspects. Instead, the JTBD approach assumes that people are first and foremost motivated to get the job done so they can make progress. The interviews favor a more surgical approach to reaching their goals and needs. (Kalbach, J., Jobs to be Done Playbook (2020).

Jobs interviews are not research about your product or existing customers. In fact, you don’t even have to talk to people who know your brand or offering. That might cloud their responses to your questions. Because you’re not yet concerned about purchasing decisions or brand awareness, you just need to get job performers—the people executing your main job. It’s as simple as that.

Kalbach, J., Jobs to be Done Playbook (2020).

Your primary goal during the interview is to encourage the interviewee to tell you stories about things that happened to them in the recent past. These stories will help you get a deeper understanding of who your users are, what motivates them, and why (Sharon, T., Validating Product Ideas, 2016).

This is a key point in interviews: no matter what questions you ask, your goal is extracting stories about things that happened very recently.

Sharon, T., Validating Product Ideas (2016)

Switch Interviews

One variation of job interviews is Switch interviews, developed by Bob Moesta and Chris Spiek, which focus on listening to stories—in this case, the story of how customers and/or users realized that they had an unmet need and discovered your product.

You’re trying to recreate the timeline leading up to using the product (Spiek, C., & Moesta, B., The Jobs-to-be-Done Handbook, 2014):

1. First thought: The initial moment when a change is needed.
2. Passively looking: The prospect notices options but isn’t actively seeking change.
3. Actively looking: The prospect starts investing time and energy into finding a solution. The second event transitions the prospect into making a purchase decision.
4. Deciding: The prospect weighs alternatives. This stage ends with a purchase decision or the act of signing up.
5. Consuming: After signing up or making a purchase, the user uses, and ideally gets value from the product.

Jonathan Briggs JTBD Cards

Another great resource to get your feet wet for interviewing customers is Jonathan Briggs‘ deck of JTBD Cards.

The cards are divided into 5 groups: green cards provide a starting point for interviews. blue add additional questions, orange are insights to watch out for, red are questions to avoid (and rephrase) and purple cards support business-to-business interviews.  On the reverse face of the cards are 50 questions that are designed to help the interviewer progress the questioning. Cards provide a much more flexible way to learn about JTBD interviewing than books and learners are encouraged to choose the questions that work for them (Briggs, J., JTBD Cards: Learning to interview customers, 2016) 

Use a Research Protocol

If you want to get started with interviewing customers from a task/job analysis, you probably think of a script upfront to guide you through your interview (what user researchers call a research protocol). You can take a look at the interview protocol that I’ve shared with my students at Köln International School of Design, inspired by the work of my friends David Aurelio and Chauncey Wilson:

Mixed Interview Methods

You can be creative in developing a range of methods for any one project. While interviewing is at the core, you can organically include a larger set of techniques that goes beyond merely asking questions. For example, you can vary the activities in the session itself, ask participants to prepare for the interview, or take materials specifically to facilitate the discussion. You can also do the following (Portigal, S., Interviewing users: How to uncover compelling insights, 2013):

• Ask for a demonstration of an activity that might not otherwise take place.
• Observe a behavior or a task as it happens to occur naturally (more on that coming up on Contextual Inquiries).
• Use a mapping exercise to create a tangible representation of something abstract that you can refer to repeatedly throughout the interview (and then take away with you at the end).
• Show provocative concepts at varying levels of fidelity and create concepts that will generate discussion around the issues at hand (rather than testing your best guess at the best solution).
• Use images as stimuli to prompt a deeper discussion. When mounted on cards, they can be sorted, grouped, annotated, referred to later, and so on.
• Assign homework (for example, take a few pictures, save some artifacts, complete a questionnaire, and document a set of activities to give you some data before the interview and to prime the participant about the interview topics.

Limitations of Interviews

Although the general idea of interviews is to get job performers to talk about their work (and the desired outcomes they are trying to achieve while on it), we have to acknowledge the limitations of interviews:

“Humans are very bad at predicting their future behaviour. Instead, explore people’s current behaviour, which is the best predictor of future behaviour.”

Sharon, T., Validating Product Ideas (2016)

Exploring how people solve a problem today helps you come up with a great idea tomorrow. Even if you have already a product idea, figuring out the problem it solves might lead you to improve it significantly. It is pointless to ask what they would do. So — when thinking of questions to ask during interviews — eliminate any question that starts with the words would or will. For example, “Would you pay for such a feature if we offer it? (Sharon, T., Validating Product Ideas, 2016).

So, a better way to predict future behavior is to observe their current behavior. That’s when Contextual Inquiries come in!

Observing Behavior Through Contextual Inquiries

People can say what they do in general terms and can identify critical problems; they can say what makes them angry with the tools they use. But they usually cannot provide day-to-day details about what they do. They cannot describe inner motivations such as the need to express a particular identity or to feel connected with people they care about. They are likely to forget about the workarounds they had to invent to overcome problems in their current products. This low-level detail of everyday practice is critical to design for life (Holtzblatt, K., & Beyer, H., Contextual Design: Design for Life, 2016).

Contextual Inquiry reveals unconscious and tacit aspects of life. It guides designers in going out into the field and talking with people about their work and life while observing them.

Holtzblatt, K., & Beyer, H., Contextual Design: Design for Life (2016)

If designers watch people while they engage in their activities, then people do not have to articulate their practices. If they do blow-by-blow retrospective accounts of things that happened in the recent past, people can stick with the details of specific cases using artifacts and reenactments to remind them of what happened.

Contextual Inquiry immerses designers in the user’s whole life—including those aspects that the user doesn’t know how to articulate (Holtzblatt, K., & Beyer, H., Contextual Design: Design for Life, 2016).

Empathy about understanding how another person thinks—what’s going on inside her head and heart. And most importantly, it’s about acknowledging her reasoning and emotions as valid, even if they differ from your own understanding

Young, I., Practical Empathy: For Collaboration and Creativity in Your Work (2019)

We will come back to the topic of discovery later in this post we talk about collaboration within product teams.

You can learn more about how to conduct Contextual Inquiries by checking my lecture on Discovery Mode for the MA Integrated Design at Köln International School of Design: 

Jobs to be Done and Mental Models

Designing something requires that you completely understand what a person wants to get done. Empathy with a person is distinct from studying how a person uses something. Empathy extends to knowing what the person wants to accomplish regardless of whether she has or is aware of the thing you are designing (Young, I., Mental Models: Aligning Design Strategy with Human Behavior. 2008).

Mental models are simply affinity diagrams of behaviors made from ethnographic data gathered from audience representatives. They give you a deep understanding of people’s motivations and thought processes, along with the emotional and philosophical landscape in which they are operating (Young, I., Mental Models, 2008).

Mental models give you a deep understanding of people’s motivations and thought-processes, along with the emotional and philosophical landscape in which they are operating.

(Young, I., Mental Models: Aligning Design Strategy with Human Behavior (2008)

To create a mental model, you talk to people about what they’re doing, look for patterns, and organize those patterns from the bottom up into a model. From the field research, you will glean maybe 60 or 120 behaviors per person. Over time you see the same behaviors and you group them together. You line them up in towers; then line up the towers into groups that represent different cognitive spaces. The diagram looks a lot like a city skyline (Young, I., Mental Models: Aligning Design Strategy with Human Behavior. 2008).

Using a mental model can advance several tasks for you—both from a tactical and a strategic standpoint. It can guide the design of the solution you are working on. It can help you, and your team, make good user and business decisions. And, it can act as a roadmap, ensuring continuity of vision and opportunity as the makeup of your team evolves over the next decade.

(Young, I., Mental Models: Aligning Design Strategy with Human Behavior (2008)

A mental model helps you visualize how your business strategy looks compared to the existing user experience. Thus, it is a diagram that can support your experience strategy (Young, I., Mental Models: Aligning Design Strategy with Human Behavior. 2008).

Jobs to be Done and Affinity Diagrams

The Affinity Diagram brings issues and insights across all customers together into a wall-sized, hierarchical diagram. In the interpretation sessions you captured individual notes representing the user’s data. We call these interpretation session notes affinity notes because you are now going to use them to build the affinity diagram (Wendell, J., Holtzblatt, K., & Wood, S., Rapid contextual design, 2005).

The affinity diagram is your fastest and best method to see all the issues across your user population. Consolidating the affinity notes and individual work models enables you to see the issues for your whole user population, not just one individual.

Wendell, J., Holtzblatt, K., & Wood, S., Rapid contextual design (2005).

The system design must address a whole market or use population. It must take into consideration the issues of the population as a whole, the structure of work, and the variations natural to that world. Affinity diagrams are built from the bottom up, grouping individual notes that reveal key themes in your data (Wendell, J., Holtzblatt, K., & Wood, S., Rapid contextual design, 2005).

You can learn more about how to interpret data from Contextual Inquiries by checking my lecture on Interpretation Mode for the MA Integrated Design at Köln International School of Design

Analysing Quantitative and Analytics Data

Quantitative data is easy to understand. It’s the numbers we track and measure–for example, sports scores and movie ratings. As soon as something is ranked, counted, or put on a scale, it’s quantified. Quantitative data is nice and scientific, and (assuming you do the math right) you can aggregate it, extrapolate it, and put it into a spreadsheet. But it’s seldom enough to get a business started. You can’t walk up to people, ask them what problems they’re facing, and get a quantitative answer. For that, you need qualitative input (Croll, A., & Yoskovitz, B. Lean Analytics. 2013)

Qualitative data is messy, subjective, and imprecise. It’s the stuff of interviews and debates. It’s hard to quantify. You can’t measure qualitative data easily. If quantitative data answers “what” and “how much,” qualitative data answers “why.” Quantitative data abhors emotion; qualitative data marinates in it (Croll, A., & Yoskovitz, B. Lean Analytics. 2013).

Quantitative research can tell you how many customers are doing (or not doing) something. But it won’t tell you why the customers are doing it (or not doing it).

Olsen, D. The lean product playbook (2015)

This is not to say that you cannot use quantitative techniques for uncovering jobs! I would rather use quantitative techniques to narrow the places where you want to start looking for jobs and help you scale!

You should continue doing customer interviews (after the first 10-20 or so) and iterate on the questions you ask, dig deeper with people, and learn as much as you can. But you can also expand the scope of your efforts and move into doing some quantitative analysis. This does several things (Croll, A., & Yoskovitz, B. Lean Analytics. 2013):

• It forces you to formalize your discussions, moving from subjective to objective.
• It tests whether you can command the attention–at scale–that you’ll need to thrive.
• It gives you quantitative information you can analyze and segment, which can reveal patterns you won’t get from individual groups.
• The respondents may become your beta users and the base of your community.

To talk with people at scale you can employ a number of tactics, including surveys and landing pages. These give you the opportunity to reach a wider audience and build a stronger, data-driven case for the qualitative feedback you received during interviews.

Croll, A., & Yoskovitz, B. Lean Analytics (2013)

While there’s no substitute for qualitative data, you can use technology to dramatically improve the efficiency of collecting that data. In the Empathy stage (a.k.a. discovery), focus on building tools for getting good feedback quickly from many people. Just because customer development isn’t code, it doesn’t mean you shouldn’t invest heavily in it (Croll, A., & Yoskovitz, B. Lean Analytics. 2013).

There is one aspect of customer development that could potentially have a code component, which is tracking usage data. Making the investment in creating the visibility and traceability systems will help you collect data from real customer usage and will help you make hard choices about pivot, persevere, or stop on next iteration of the product.

Once your product is in the hands of customers and users — we should be able to collect the richest data from live usage that can inform decisions about our viability hypothesis, enabling you to adjust strategic choices accordingly.

We will talk about a couple of quantitative techniques that allow scale when we discuss Experience Sampling and Outcome-Driven Innovation.

Learning Through Experience Sampling

Experience Sampling is a strategic research technique that answers a high-level business (or roadmap) question rather than evaluating a design or product that already exists. Experience Sampling is good for uncovering unmet needs, which will lead to generating great ideas for new products and for validating (or invalidating) ideas you already have (Sharon, T., Validating Product Ideas, 2016).

In an experience sampling study, research participants are interrupted several times a day or week to note their experiences in real-time. The key is to ask the same question over and over again at a random time during the day or at work. This cadence and repetition strengthen your finding’s validity and allow you to identify patterns (Sharon, T., Validating Product Ideas, 2016).

Clustering Analysis with Value Proposition Design

Value Proposition Design helps you tackle a core challenge of every business — creating compelling products and services customers want to buy. Value Proposition Design can help you (Osterwalder, A., Pigneur, Y., Papadakos, P., Bernarda, G., Papadakos, T., & Smith, A. Value proposition design, 2014):

• Precisely define your customer profiles: Identify your customer’s major Jobs-to-be-done, the pains they face when trying to accomplish their Jobs-to-be-done, and the gains they perceive by getting their jobs done.
• Visualize the value you create: Define the most important components of your offering, and how you relieve pain and create gains for your customers.
• Achieve Product-Market fit: Adjust your Value Proposition based on the insights you gained from customer evidence and achieve Product-Market fit.

The Value Proposition Design method has two parts (Osterwalder, A., Pigneur, Y., Papadakos, P., Bernarda, G., Papadakos, T., & Smith, A. Value proposition design, 2014):

• The Customer Profile describes (on the right side of the canvas) a customer segment in your business model in a more structured and detailed what. It breaks the customer down into jobs, pains, and gains.

• The Value Map describes (on the left side of the canvas) the features of a specific value proposition in your business model in a more structured and detailed way. It breaks your value proposition down into products and services, pain relievers, and gain creators.

As an example, a user of Lyft is trying to get from point A to point B, but that isn’t the only job they are trying to complete when they use Lyft. There are many jobs that can be completed, including social and emotional ones. On a functional level, a person may be dropping something off or picking something up, trying to travel with privacy, not worrying about parking, and avoiding drunk driving. On an emotional level, they may feel confident they are not being price gouged (the price you see is the price you pay before confirming your ride) and relaxed that they themselves don’t need to sit in traffic or deal with other drivers (Todd, L., Adding a feature to Lyft: a UX case study, 2020).

The caveat about Value Proposition Design that I tell teams during my training sessions is that Jobs to be Done don’t come out of thin air! For teams to write jobs to be done that can confidently guide them towards creating value for their customers and users, these jobs to be done need to be based on real Customer Pains and Gains! It can be hard to do it if you haven’t been exposed to user research data, either directly or through storytelling during interpretation sessions.

Measuring Innovation Opportunities with Jobs to be Done

One could argue that all the advantages listed above make Jobs to be Done a great method for improving strategic collaboration during product discovery. The beauty of Anthony Ulwick’s Outcome-Driven Innovation (ODI) is that he takes it one step forward and proposes a way to quantity innovation opportunities by comparing and contrasting two sets of preference data: Importance and Satisfaction.

Job Importance

It is important to acknowledge that not all jobs have the same importance to your customer. Some matter more in a customer’s work or life because failing to get them done could have serious ramifications. Some are insignificant because the customer cares about other things more. Sometimes a customer will deem a job crucial because it occurs frequently or because it will result in a desired or unwanted outcome (Osterwalder, A., Pigneur, Y., Papadakos, P., Bernarda, G., Papadakos, T., & Smith, A. Value proposition design, 2014).

Job Satisfaction

Satisfaction is all about what users say or think about their interaction with the product, traditionally captured during post-study surveys. Users might report that it was easy to use, that it was confusing, or that it exceeded their expectations. Users might have opinions about the product being visually appealing or untrustworthy (Tullis, T., & Albert, W., Measuring the user experience, 2013).

Perhaps surprisingly, performance and satisfaction don’t always go hand-in-hand.

We’ve seen many instances of a user struggling to perform key tasks with an application and then giving it glowing satisfaction rating. Conversely, we’ve seen users give poor satisfaction ratings to an application that worked perfectly.

Tullis, T., & Albert, W., Measuring the user experience (2013).

So it is important that you look at both performance and satisfaction metrics to get an accurate overall picture of the user experience (Tullis, T., & Albert, W., Measuring the user experience. 2013).

I’ve covered satisfaction metrics (also known as preference data) extensively in a previous post. But here is yet another difference between Jobs-to-be-done and traditional user-centered methods: JTBD advocates that — because jobs exist independent of our product —customers and users should be able to rate their job satisfaction without talking about your product! That means you don’t have to wait to put your product in front of customers/users and collect satisfaction through some sort of post-study survey.

Innovation Opportunity Algorithm

Outcome-Driven Innovation (ODI) is a strategy and innovation process that links a company’s value creation activities to customer-defined metrics. Ulwick found that previous innovation practices were ineffective because they were incomplete, overlapping, or unnecessary.

Outcome-Driven Innovation® (ODI) is a strategy and innovation process that enables a company to create and market winning product and service offerings with a success rate that is 5-times the industry average

Ulwick, A.,  What customers want: Using outcome-driven innovation to create breakthrough products and services (2005)

At the core of ODI is an algorithm that reveals two complementary pieces of information: where the market is underserved and where it is overserved. We use this information to make some important targeting and resource-related decisions (Ulwick, A. W., What customers want, 2005).

Where Is the Market Underserved?

An opportunity for improvement exists when an important outcome is underserved–that is, when it has a high opportunity score. Such outcomes merit the allocation of time, talent, and resources, as customers will recognize solutions that successfully serve these outcomes to be inventive and valuable. Given that higher opportunity scores represent better opportunities, we have devised the following set of rules (Ulwick, A. W., What customers want, 2005):

• Outcomes and jobs with opportunity scores greater than 15 represent extreme areas of opportunity that should not be ignored. This range is denoted in the lower-right section in Figure 3.2. Outcomes with scores in this range are rare in mature markets, but common in newer markets, such as those for medical devices. Companies can also expect to see outcomes with scores this high when they employ the segmentation methods described in Chapter 4 to fine-tune where they search for opportunities.
• Outcomes and jobs with opportunity scores between 12 and 15 can be defined as “low-hanging fruit,” ripe for improvement. Outcomes with scores in this range are common in many markets as products and services rarely execute a job perfectly. Here again, the segmentation methods described in the next chapter reveal a greater number of opportunities of this magnitude in certain segments of the market.
• Outcomes and jobs with opportunity scores between 10 and 12 are worthy of consideration especially when discovered in the broad market. Many such opportunities are commonly revealed even in the most mature markets.
• Outcomes and jobs with opportunity scores below 10 are viewed as unattractive in most markets and offer diminishing returns. In some less functional markets, such as those for packaging materials, however, opportunity scores in this lower range may be worthy of consideration.

Similar to Outcome-Driven Innovation, Dan Olsen‘s Importance Versus Satisfaction framework proposes you should be quantifying and qualifying customers’ needs that any particular feature of the product is going to address (Olsen, D. The lean product playbook, 2015):

• How important is that?
• Then how satisfied are people with the current alternatives that are out there?

What I like about Olsen’s approach to assessing opportunities is that he created a couple of variations of opportunities scores:

• Customer Value Delivered = Importance x Satisfaction
• Opportunity to Add Value = Importance x (1 – Satisfaction)
• Opportunity = Importance – Current Value Delivered

Where Is the Market Overserved?

Almost as important as knowing where the market is underserved is knowing where it is overserved. Jobs and outcomes that are unimportant or already satisfied represent little opportunity for improvement and consequently should not receive any resource allocation in most markets, it is not uncommon to find a number of outcomes that are overserved-and companies that are nevertheless continuing to allocate them development resources. We say that an outcome is overserved when its satisfaction rating is higher than its importance rating. When a company discovers these overserved outcomes, it should consider the following three avenues for possible action (Ulwick, A. W., What customers want, 2005):

1. If the company is currently focusing on these overserved outcomes, those efforts should be halted. Making additional improvements in areas that are already overserved is simply a waste of resources and is likely to add cost without adding additional value.
2. If cost reduction is an important consideration in the market, then costs can be reduced by taking out costly functions in areas that are overserved. For example, if a five-dollar feature can be redesigned so that it satisfies an outcome 80 percent as well as it does currently but for half the cost, then the company may want to make this trade-off.
3. If many overserved outcomes are discovered in a market, then the company should consider the possibility of engaging in disruptive innovation. This would mean taking out costs along multiple dimensions and creating a lower-cost business model that existing competitors would be unable to match. The concept of a low-end disruptive innovation, as described in The Innovator’s Solution, is only possible when the customer population, or a segment of that population, is overserved.

In the outcome-driven paradigm, companies do not brainstorm hundreds of ideas and then struggle to figure out which — if any — have value. Instead they figure out which of the 50 to 150 outcomes for a given job are important and unsatisfied and then systematically devise a few ideas that will better satisfy those underserved outcomes.

Ulwick, A. W., What customers want (2005)

Since they know which outcomes are underserved, they know where to make improvements, and, more importantly, they know doing so will result in products that customers want. This flips the innovation process on its head (Ulwick, A. W., What customers want, 2005).

Value Migrates Overtime

In Value Migration, Adrian Slywotzky describes how changing customer priorities are responsible for the displacement of old business models. Opportunities for improvement migrate over time in a dynamic fashion; today’s big opportunity is not necessarily tomorrow’s, and to succeed over the long term, companies must be able to determine exactly where opportunities exist in a market at any point in time and be the first to address them.? This, in essence, is the goal of innovation: to define and deliver new solutions that evolve each measure of value along its continuum, better satisfying
the collective set of outcomes. Using the opportunity algorithm, it is possible to predict just where value is migrating (Ulwick, A. W., What customers want, 2005).

Opportunity Score = Importance + max(Importance – Satisfaction, 0)

Ulwick, A. W., What customers want (2005)

It is important to remember that the customers’ outcomes are stable over time. People who shave, for example, have always wanted to minimize the number of nicks, minimize shaving time, and minimize the number of passes that must be made. These and other shaving-related desired outcomes will remain the same for years to come. What does change is the degree to which these outcomes are satisfied by new technologies and product and service features (Ulwick, A. W., What customers want, 2005).

Customers’ outcomes are stable over time. What does change is the degree to which these outcomes are satisfied by new technologies and product and service features.

Ulwick, A. W., What customers want (2005)

Once an outcome is well satisfied by a feature or technology, the opportunity score decreases for that outcome, and opportunities for value creation migrate to the other important, unsatisfied outcomes. If a company were to continue to focus on the same outcome, it would only lead to overserving the market along that dimension (Ulwick, A. W., What customers want (2005).

When companies fail to look to other outcomes or jobs, they leave the door open for some other company to devise new product features, new business models, and new value propositions specifically aimed at addressing those remaining opportunities in the market and the innovator just might be able to take over the market leadership position

Ulwick, A. W., What customers want (2005)

Here is — yet again — another advantage of using Jobs to be Done to frame our value proposition, especially with regards to product vision: because the product vision communicates why you are building something and what the value proposition is for the customer, if we focus on the customers’ outcomes can deliver the greatest value we can be confident to push our vision horizon far out, knowing that the outcomes our vision are trying to address are stable over time.

Since I first came in contact with Jobs to be Done, I’ve always been curious to combine it with another method for quantifying desirability that also states that value migrates over time: that is the Kano Model.

Jobs to be Done and Kano

The Kano Model, developed by Dr. Noriaki Kano, is a way of classifying customer expectations into three categories: expected needs, normal needs, and exciting needs. This hierarchy can be used to help with our prioritization efforts by clearly identifying the value of solutions to the needs in each category (“Kano Model” in Product Roadmaps Relaunched, Lombardo, C. T., McCarthy, B., Ryan, E., & Connors, M., 2017):

• The customer’s expected needs are roughly equivalent to the critical path: if those needs are not met, they become dissatisfiers.
• If you meet the expected needs, customers will start articulating normal needs, or satisfiers — things they don’t normally need in the product but will satisfy them.
• When normal needs are largely met, then exciting needs (delighters or wows) go beyond the customers’ expectations.

The Kano methodology was initially adopted by operations researchers, who added statistical rigor to the question pair results analysis. Product managers have leveraged aspects of the Kano approach in Quality Function Deployment (QFD). More recently, this methodology has been used by Agile teams and in market research (Moorman, J., “Leveraging the Kano Model for Optimal Results” in UX Magazine, 2012).

Here is — yet again — where Jobs to be Done — when combined with Kano — can help identify how opportunity score decreases for any given outcome, and how opportunities for value creation are migrating to the other important, unsatisfied outcomes. ensuring the teams keep prioritizing the creation of value continuously on jobs that are perceived as providing value for customers/users.

You can learn about how prioritisation can help us focus on what is important, steering us ever closer to our vision and goals.

Jobs to be Done and Competitive Analysis

Companies typically conduct competitive analysis by comparing competitors’ product specifications rather than by comparing each competitive offering against the criteria customers use to measure value. In many high-tech industries, this is referred to as comparing speeds and feeds. Although product specs may offer some insight into a product’s strengths and weaknesses, using them as a basis of comparison assumes that customers measure value along these same dimensions–which is not the case. As a result of this flawed thinking, companies often continue to make improvements in areas that are overserved in the eyes of the customer (Ulwick, A. W., What customers want, 2005).

The outcome-driven paradigm directs companies to keep their eyes on the job customers are trying to get done, not on their competitors’ product specifications. By using the 50 to 150 desired outcomes statements as metrics against which to compare the performance of competitive products, managers can gain unique insight into how well products perform against customers’ measures of value.

Ulwick, A. W., What customers want (2005)

In addition, an outcome-driven competitive analysis makes it possible for a company to (Ulwick, A. W., What customers want (2005):

• Identify competitors’ strengths and weaknesses
• Know which of its competitors’ features to emulate
• Know when competitors are headed in the wrong direction and should be left to go it alone.

W. Chan Kim and Renée Mauborgne, professors at INSEAD and authors of Blue Ocean Strategy, created The Strategy Canvas to help capture the strategic landscape of an organization. Early-stage businesses can use this canvas to explore possible positionings for their innovation. In its essence, the canvas helps compare how well competitors meet customer buying criteria or desired outcomes (Garbugli, É., Solving Product, 2020).

To create your own Strategy Canvas, list the 10-12 most important functional desired outcomes – or buying criteria- on the x-axis. On the y-axis, list the 3-5 most common competitors (direct, indirect, alternative solutions, and multi-tool solutions) for the Job (Garbugli, É., Solving Product, 2020).

To avoid going down the wrong path, only compare competitors and attributes that were uncovered through early research. Although there may be other criteria or outcomes that could help differentiate your offering, you should definitely confirm the existence of these criteria before basing your strategy on them

Garbugli, É., Solving Product (2020)

Use the information collected through your competitive research to rate competitors on each criterion. Explore alternative positionings by reducing or raising the importance of certain attributes, or by creating or completely removing other attributes (Garbugli, É., Solving Product, 2020).

Learn more about Strategy Canvas and other kinds of Alignment Diagrams in Strategy, Facilitation and Visual Thinking.

Facilitating Investment Discussions with Jobs to be Done

Once you’ve obtained the opportunity scores for each use case, what comes next? There are two complementary pieces of information that the scores reveal: where the market is underserved and where it is overserved. We can use this information to make some important targeting and resource-related decisions.

Jobs to be Done as an Ideation Tool

I’ve mentioned in a previous article that — in my experience — the biggest disconnect between the work designers need to do and the mindset of every other team member in a team is usually about how quickly we tend — when not facilitated — to jump to solutions instead of contemplating and exploring the problem space a little longer.

It’s tempting to appear decisive by jumping straight to the conclusion and making rapid decisions. But the chances are that those rapid decisions are predictable courses based on existing assumptions and prejudices, and that another chance for innovation as escaped.

Sloane, P., The leader’s guide to lateral thinking skills (2017)

It’s easy to solve the wrong problems. Good design relentlessly questions assumptions, reframing the design problem to be solved.

A brilliant solution to the wrong problem can be worse than no solution at all: solve the correct problem.

Norman, Donald A., The design of everyday things (2013)

When your team can’t agree on a solution, it’s probably a good time to take a step back and align on the problem you are solving for. I’m of the opinion that designers — instead of complaining that everyone else is jumping too quickly into solutions — should facilitate the discussions and help others raise awareness around the creative and problem-solving process.

Here is — yet again — another advantage of Jobs to be Done: when the team engages in endless discussions around which customer/user problems we should be focusing on, Jobs becomes a unit of analysis that helps have facilitated discussion around which problems are more important from their perspectives, and where are the opportunities for us to disrupt the market by focusing on which problems they are most dissatisfied with.

Learn more about how to become a skilled facilitator in Strategy and the Need for Facilitation

The Problem With Problem Statements

In the effort of bringing clarity and shared understanding of what problems we are trying to solve, I’ve seen a lot of organizations try to be more systematic and adopt artifacts like Problem Statements.

Problem statements are widely used by most businesses and organizations to execute process improvement projects. A simple and well-defined problem statement will be used by the project team to understand the problem and work toward developing a solution. It will also provide management with specific insights into the problem so that they can make appropriate project-approving decisions. As such, it is crucial for the problem statement to be clear and unambiguous (Annamalai, Nagappan; Kamaruddin, Shahrul; Azid, Ishak Abdul; Yeoh, TS, 2013).

The way you state your problems frame your decisions. It determines the alternatives you consider and the way you evaluate them. Posing the right problem drives everything else.

Hammond, J. S., Keeney, R. L., & Raiffa, H., Smart choices: A practical guide to making better decisions (2015)

The problem with problem statements (pun intended) that I’ve found is that there are many thinking traps and decision biases that stakeholders and team members might not even be aware of.

The most classic is to bake the solution into the problem statement. This has been illustrated really well by Marc Rettig:

Design a Vase
Design a better way for young families to enjoy flowers in their home

Rettig, M., (2010) “Design a Vase”, in An evening of conversation about Design, Interaction, Work and Life, May 25th, 2010, IxDA Gathering, 399, Pu DianRoad, Pudong New District, Shanghai, 200122, P.R. China

Learn more about Problem Framing and other techniques to prevent teams from jumping to solutions in Problem Framing for Strategic Design:

Many product people are used to filling roadmaps with features and solutions, and we can attest from experience that old habits die hard. The key question to ask yourself when faced with a list of concrete deliverables is why? Why are these things important? What will result from doing them? How will the fortunes of the company or the happiness of the customer improve? Why would we do this at all? (Lombardo, C. T., McCarthy, B., Ryan, E., & Connors, M., Product Roadmaps Relaunched, 2017).

Here is — yet again — another advantage of using Jobs to be Done while discussing solutions for features: Jobs becomes a unit of analysis that helps have facilitated discussion around what constitutes a problem from the perspective of customers/users, and what are the measures of success for their desired outcomes.

Focus on Outcomes, Not Outputs

In a previous post, we’ve taken a deep dive into some problem-framing techniques that can help you get team alignment by creating clarity of what problems they are trying to solve.

In the old days of engineering, setting project goals wasn’t that hard. How have we historically given teams a goal that they can work on? Mostly, we simply asked teams to build features—but features are the wrong way to go. We often build features that create no value. Instead, we need to give teams an outcome to achieve. (Seiden, J., Outcomes over Output, 2019).

You might be asking, “what you do mean by an outcome?”. Josh Seiden defines as outcome “a change in user behavior that drives business results.”

You can help the team and leaders to start thinking in terms of outcomes by asking three simple questions (Seiden, J., Outcomes over Output, 2019):

• What are the user and customer behaviors that drive business results? If the team gets stuck in trying to answer that question, there is a good chance that working on alignment diagrams will help.
• How do we get people to do more of these things?
• How do we know we’re right? The easiest (and the hardest) way to answer that question is to design and conduct tests.

Using outcomes creates focus and alignment. It eliminates needless work. And it puts the customer at the center of everything you do

Seiden, J., Outcomes over Output (2019)

By building, measuring, and learning, designers are able to get closer to great user experiences sooner rather than later (Gothelf, J., & Seiden, J., Lean UX: Applying lean principles to improve user experience, 2021).

Team Objectives and Managing by Outcomes

Managing by outcomes communicates to the team how they should be measuring success. A clear outcome helps a team align around the work they should be prioritizing, helps them choose the right customer opportunities to address, and helps them measure the impact of their experiments. Without a clear outcome, discovery work can be never-ending, fruitless, and frustrating (Torres, T., Continuous Discovery Habits, 2021).

There are a few ways of helping teams measure their success through outcomes, including John Doerr’s Management by Objectives using Objectives and Key Results (Doerr, J., Measure what matters, 2018).

One obvious use of these OKRs is that they allow us to prioritise work on the roadmap based on its expected impact. Meaning we can prioritise work based on the goals of the business.

Wodtke, C. R.,  Radical focus: Achieving your goals with objectives and key results (2021)

There are two fundamental principles for that (Cagan, M., Inspired: How to create tech products customers love, 2017):

1. Never tell people how to do things. Tell them what to do, and they will surprise you with their ingenuity.
2. Performance is measured by results. The idea here is that you can release all the features you want, but if it doesn’t solve the underlying business problem, you haven’t really solved anything.

The first principle is fundamentally about how to empower and motivate people to get them to do their best work, and the second is about how to meaningfully measure progress.

Cagan, M., Inspired: How to create tech products customers love (2017)

The key here is — going back to Joshua Seiden’s “Outcomes” — to help the team connect the dots between what are the changes in human behavior that drives business results?

What are the changes in human behaviour that drives business results?

Seiden, J., Outcomes over Output (2019)

Here is — yet again — another advantage of using jobs to be done as a common exchange currency between leadership, designers, product managers, and developers: jobs describe what users are trying to get done (the “why”s), which — in turn — provides a good framing to discuss objectives for the team (the “what”‘s the solution, not the “how”s).

Opportunity-Solution Tree

Many teams generate a lot of ideas when they go through a journey-mapping or experience-mapping exercise. There are so many opportunities for improving things for the customer that they quickly become overwhelmed by a mass of problems, solutions, needs, and ideas without much structure or priority (“Opportunity-Solution Tree” in Product Roadmaps Relaunched, Lombardo, C. T., McCarthy, B., Ryan, E., & Connors, M., 2017).

Opportunity solution trees are a simple way of visually representing the paths you might take to reach a desired outcome (Torres, T., Continuous Discovery Habits, 2021):

• The root of the tree is your desired outcome—the business needs that reflect how your team can create business value.
• Below the opportunity space is the solution space. This is where we’ll visually depict the solutions we are exploring.
• Below the solution space are the assumption tests. This is how we’ll evaluate which solutions will help us best create customer value in a way that drives business value.

Opportunity solution trees have a number of benefits. They help product trios (Torres, T., Continuous Discovery Habits: Discover Products that Create Customer Value and Business Value, 2021):

• Resolve the tension between business needs and customer needs
• Build and maintain a shared understanding of how they might reach their desired outcome
• Adopt a continuous mindset
• Unlock better decision-making
• Unlock faster learning cycles
• Build confidence in knowing what to do next
• Unlock simpler stakeholder management

Impact Mapping

Like highway maps that show towns and cities and the roads, connecting them, Impact Maps layout out what we will build and how these connect to ways we will assist the people who will use the solution. An impact map is a visualization of the scope and underlying assumptions, created collaboratively by senior technical people and business people. It’s a mind map grown during a discussion facilitated by answering four questions: WHY, WHO, HOW, and WHAT of the problem the team is confronting (Adzic, G., Impact Mapping, 2012)

Describing Customer Needs, not Solutions

Describing customer needs without getting into the solution can be tricky business. To make it easier, many product teams use a framework to tease out the reasons behind a need and justify its importance. The purpose is to prevent assumptions and avoid building things that don’t match the real needs of the customer. The two most common forms of this method are called user stories and job stories  In each of these frameworks, the focus is on the customer, what they want or need, and (critically) why that’s important to them (Lombardo, C. T., McCarthy, B., Ryan, E., & Connors, M., Product Roadmaps Relaunched, 2017).

Jobs to be Done as a collaboration tool for creating Shared Understanding

In my practice, I’ve found that — more often than not — is not for the lack of ideas that teams cannot innovate, but because of all the friction or drag created by not having a shared vision and understanding of what the problems they are trying to solve.

Just to make sure I’m not misunderstood: it doesn’t matter at that point if the team lacks a vision or the vision is just poorly communicated, the result is the same: the team will lack engagement and slowly drift apart.

Shared understanding is the collective knowledge of the team that builds over time as the team works together. It’s a rich understanding of the space, the product, and the customers.

“Creating Shared Understanding” in Lean UX: Applying lean principles to improve userexperience, Gothelf, J., & Seiden, J. (2013)

Shared Understanding (“Cognitive synchronization”) enables partners collaborating in a distributed design environment to reach two objectives (Falzon, Montmollin, & Béguin, 1996):

• Assure that they each have knowledge of the facts relating to the state of the situation – problem data, state of the solutions, accepted hypothesis, etc, and
• Assure that they share common knowledge regarding the domain – technical rules, objects in the domain and their features, resolution procedures, etc.

Teams that attain a shared understanding are far more likely to get a great design than those teams who fail to develop a common perception of the project’s goals and outcome (Jared Spool, “Attaining a Collaborative Shared Understanding” in Govella, A., Collaborative Product Design, 2019).

When teams share an understanding, everyone knows what they’re working on, why it’s important, and what the outcome will look like.

Govella, A., Collaborative Product Design (2019)

Here is — yet again — another advantage of Jobs to be Done: when the team engages in endless discussions around which customer/user problems we should be focusing on, Jobs becomes a unit of analysis that helps teams develop common knowledge regarding the domain – technical rules, objects in the domain and their features, resolution procedures, and — more importantly — what are our customer/user problems and why.

Collaboration within the Product Teams using Jobs to be Done

If you are still not convinced of the benefits of using Jobs to be Done, my colleagues Ritesh Chopra, Kevin Simmons, and I are very confident of the usefulness of Jobs to be Done as a common “exchange currency” for collaboration between Designers, User Researchers, and Product Managers, especially during product discovery.

Jobs to be Done to support Product Discovery

There are a few ways that my colleagues and I have been taking full benefit of the advantages of using Jobs to be Done during product discovery:

• Discuss problems instead of solutions: because Jobs to be Done are a great way of describing Customer and/or User Needs independent of Solutions, they are — directly or indirectly — a great way to help create the mindset (that designers keep complaining about that lack in product teams) of understanding the problem space before jumping to solutions.
• Provide clarity and scope of product discovery activities: because uncovering Jobs to be Done requires clarity about who are the job performers we need to focus our research on, and what are the things these job performers are trying to get done, it makes it a lot easier for us to prepare for research, especially when it comes to recruiting research participants and what are the problems we need to probe.
• Provide a great way to synthesize discovery findings: if you know me, you know that my design and research philosophy is to get everyone involved during the processing of research data (instead of long reports for stakeholders to read out about research). But even when you do the processing of the research data together with the team, Jobs to be Done are great for synthesizing research outputs (e.g..: user needs, goals, success criteria) in a format that is easy to consume, — for example — Job Stories (coming up next)!

Jobs to be Done in Agile Backlog Planning and Grooming

A key part of Agile is to break down efforts into individual units of work. User stories are short descriptions of features and functionality written from the perspective of the end user. Teams can focus on only a small part of the whole and make progress in a controlled way. User stories are commonly written in a three-part format. The first element indicates a user’s role in the system. The second points to a capability that enables the person to get a task done. The last part often describes a benefit or reason for using the capability (Kalbach, J. Jobs to be Done Playbook, 2020).

The format for user stories is typically (Lombardo, C. T., McCarthy, B., Ryan, E., & Connors, M., Product Roadmaps Relaunched, 2017):

As a [user type]
I want [desire]
So I can [result]

Although user stories are good for breaking down work, they typically fail to connect the solution being built with user needs (Kalbach, J. Jobs to be Done Playbook, 2020).

User Stories lack an indication of why someone would behave in a certain way and what they need to get a job done. In fact, often user stories are derived from the capability being built, not from observing actual behaviour.

Kalbach, J. Jobs to be Done Playbook (2020)

Job stories are an alternative to user stories. They follow the tradition of breaking down efforts into smaller pieces, but through the JTBD lens. The technique was first pioneered by the product development team at Intercom, a leading marketing communications solution. They wanted to avoid leading designers with a preconceived solution, as well as tying development to the company vision and strategy (Kalbach, J. Jobs to be Done Playbook, 2020).

The generally accepted format for a job story is (Lombardo, C. T., McCarthy, B., Ryan, E., & Connors, M., Product Roadmaps Relaunched, 2017):

When [situation/motivation]
I need [desire]
So I can [result]

Examples of job stories include (Kalbach, J. Jobs to be Done Playbook, 2020):

• When an important new customer signs up, I want to be notified so that I can start a conversation with that person.
• When I visit someone’s profile page, I want to see how many posts they have on each topic so that I have an understanding of where they have the most knowledge.
• When I have used the application multiple times, I get nudged to contribute so that I am encouraged to participate.

If you look closely, these job stories can inform the scrum team — while they are writing user stories — of what are your customers and/or user goals, and what their success criteria look like. As I mentioned earlier, since my colleagues are using Job Stories as the synthesis of user research findings, scrum teams can have more confidence that their user stories are actually based on real user input.

In the next post, I’ll be talking about how I’ve been coaching Agile Teams (with the help of the colleagues I mentioned previously and the incredible facilitation skills of Martina William and Anton Fischer) to connect the dots between Product Vision, Customers, and User Desired outcomes, Roadmap Planning and Backlog Planning through combining Storytelling, Job Maps, and User Story Mapping.

Collaboration with other parts of the organization using Jobs to be Done

Because JTBD detaches up-front understanding from implementation, it gives a consistent, systematic approach to understanding what motivates people. As a result, JTBD has broad applicability inside an organization, beyond design and development. The framework provides a common unit of analysis for teams to focus on- the job to be done- and then offers a shared language for the whole team to understand value as perceived from the customer perspective (Kalbach, J. Jobs to be Done Playbook, 2020):

• Sales can leverage JTBD thinking in customer discovery calls to uncover the objectives and needs that prospects are trying to accomplish.
• Marketing specialists can create more effective campaigns around JTBD by shifting the language from features to needs.
• Customer success managers can use JTBD to understand why customers might cancel a subscription.
• Support agents are able to provide better service by first understanding the customer’s job to be done.
• Business development and strategy teams can use insight from JTBD to spot market opportunities, e.g., to help decide the next acquisition target.

The Right Time for using Jobs to be Done

You might be asking yourself “These are all great, but when should I be doing what?”. Without knowing what kind of team setup you have, and what kinds of processes you run in your organization, the best I can do is to map all of the techniques above the Double Diamond framework.

The Double Diamond Framework

Design Council’s Double Diamond clearly conveys a design process to designers and non-designers alike. The two diamonds represent a process of exploring an issue more widely or deeply (divergent thinking) and then taking focused action (convergent thinking).  

• Discover. The first diamond helps people understand, rather than simply assume, what the problem is. It involves speaking to and spending time with people who are affected by the issues.
• Define. The insights gathered from the discovery phase can help you to define the challenge in a different way.
• Develop. The second diamond encourages people to give different answers to the clearly defined problem, seeking inspiration from elsewhere and co-designing with a range of different people.
• Deliver. Delivery involves testing out different solutions at a small scale, rejecting those that will not work, and improving the ones that will.

Map of Activities and Methods that benefit from using Jobs to be Done

Process Awareness characterizes the degree to which the participants are informed about the process procedures, rules, requirements, workflow, and other details. The higher the process awareness, the more profoundly the participants are engaged in a process, and so the better results they deliver.

In my experience, the biggest disconnect between the work designers need to do and the mindset of every other team member in a team is usually about how quickly we tend — when not facilitated — to jump to solutions instead of contemplating and exploring the problem space a little longer.

Knowing when teams should be diverging, when they should be exploring, and when they should closing will help ensure they get the best out of their collective brainstorming and multiple perspectives’ power and keep the team engaged.

My colleagues Edmund Azigi and Patrick Ashamalla have created a great set of questions and a cheat sheet that maps which questions are more appropriate for different phases of the product development lifecycle. So the following set of activities is inspired by their cheat sheet.

Jobs to be Done during “Discover”

As the name of the phase suggests, this is when most of the discovery activities should be happening. Because there is a high level of ambiguity, a bit of back and forth is expected. You can help the team move to clarity faster by having a strong shared vision and good problem framing, defined through customers’ and/or users’ desired outcomes upfront, all of which Jobs to be Done can help as a common currency for describing value.

Here are my recommendations for activities and methods for — and around — uncovering jobs to be done Here are my recommendations of activities and methods for — and around — uncovering jobs to be done:

• User Research
• Hypothesis Writing
• Problem Framing
• Challenge Briefs
• Visioneering
• Value Proposition Design
• Jobs to be Done (JTBD)
• Testing Business Ideas
• A Value Opportunity Analysis (VOA)
• Desirability Testing

Jobs to be Done during “Define”

In this phase, we should see the level of ambiguity diminishing, and facilitating investment discussions using Jobs to be Done (especially with regards to defining priorities using Job Importance and Job Satisfaction) have the highest payoff in mitigating back-and-forth and creating focus. Helping the team make good decisions by creating great choices is critical.

Here are my recommendations of activities and methods for — and around — defining priorities using Jobs to be Done:

• User Story Mapping
• Stories/Epics
• Design Sprints / Studio
• Concept Validation
• Outcome-Driven Innovation / JTBD
• Importance vs. Satisfaction Framework
• Kano Model
• Objectives, Goals, Strategy & Measures (OGSM)
• Product Backlog & Sprint Planning

Jobs to be Done during “Develop”

In this phase, we are getting to a point where the cost of changing your mind increases rapidly as time passes. Discussions around Job Importance and Job Satisfaction should have been concluded, so teams should be moving away from which jobs we should work on to focusing on answering questions about whether we should pivot, persevere, or stop.

This is the phase where the Jobs-to-be-done as an “exchange” currency has the highest payoff: whenever the teams discuss aspects of the solution (e.g.: during demos sessions, design reviews, etc.) they should be asking themselves “does this helps the job performer get the job done?”

Here are my recommendations for suggested quantifying and qualifying activities and methods:

• User Story Mapping
• Design Studio
• Specifications
• Collaborative Prototyping
• UXI Matrix (Pugh Matrix)
• Usability Testing
• Usefulness, Satisfaction, and Ease of Use (USE)
• American Customer Satisfaction Index (ACSI)
• System Usability Scale (SUS)
• Usability Metric for User Experience (UMUX)
• UMUX-Lite

Jobs to be Done during “Deliver”

In this phase is too late to be talking about uncovering Jobs to be Done since the teams should be focusing on execution. The best you can do is to collect data from real customer usage from your systems of visibility and traceability, connecting the dots between the “why”s (what desired outcomes customers and users expect from our product) and the “how”s (demonstrating the value we are delivering from our solutions) and make hard choices about pivot, persevere, or stop the next iteration of the product.

On the other hand — since the product is now in the hands of customers and users — we should be able to collect the richest data from live usage that validate if our hypothesis around the value you wanted to deliver to customers and users matches the desired outcomes they expected, enabling you to adjust strategic choices accordingly.

Here are my recommendations for suggested quantifying and qualifying activities and methods:

• Designer – Developer Pairing
• Fit-and-Finish
• Pirate Metrics (a.k.a. AARRR!)
• UXI Matrix (Pugh Matrix)
• Objectives, Goals, Strategy & Measures (OGSM)

Recommended Reading

Adzic, G. (2012). Impact Mapping: Making a big impact with software products and projects (M. Bisset, Ed.). Woking, England: Provoking Thoughts.

Almquist, E., Senior, J., & Bloch, N. (2016). The Elements of Value: Measuring—and delivering— what consumers really want. Harvard Business Review, (September 2016), 46–53.

Bland, D. J., & Osterwalder, A. (2020). Testing business ideas: A field guide for rapid experimentation. Standards Information Network.

Brown, T., & Katz, B. (2009). Change by design: how design thinking transforms organizations and inspires innovation. [New York]: Harper Business

Bucher, A. (2020), Engaged: Designing for Behavior Change. Rosenfeld Media (3 Mar. 2020).

Briggs, J. (2016). JTBD Cards: Learning to interview customers (Second Edition). Crimson Sunbird LLP.

Cagan, M. (2017). Inspired: How to create tech products customers love (2nd ed.). Nashville, TN: John Wiley & Sons.

Cagan, M. (2020). The origin of product discovery. Retrieved February 7, 2022, from Silicon Valley Product Group website: https://svpg.com/the-origin-of-product-discovery/

Calabretta, G., Gemser G., Karpen, I., (2016) “Strategic Design: 8 Essential Practices Every Strategic Designer Must Master“, 240 pages, BIS Publishers; 1st edition (22 Nov. 2016)

Croll, A., & Yoskovitz, B. (2013). Lean Analytics: Use Data to Build a Better Startup Faster. O’Reilly Media.

Design Council. (2015, March 17). What is the framework for innovation? Design Council’s evolved Double Diamond. Retrieved August 5, 2021, from designcouncil.ork.uk website: https://www.designcouncil.org.uk/news-opinion/what-framework-innovation-design-councils-evolved-double-diamond

Doerr, J. (2018). Measure what matters: How Google, Bono, and the gates foundation rock the world with okrs. Portfolio.

Garbugli, É. (2020). Solving Product: Reveal Gaps, Ignite Growth, and Accelerate Any Tech Product with Customer Research. Wroclaw, Poland: Amazon.

Gothelf, J., & Seiden, J. (2021). Lean UX: Applying lean principles to improve user experience. Sebastopol, CA: O’Reilly Media.

Holtzblatt, K., & Beyer, H. (2016). Contextual Design: Design for Life (2nd ed.). Morgan Kaufmann.

Gray, D. (2016). Liminal thinking: Create the change you want by changing the way you think. Rosenfeld Media. 

Kalbach, J. (2020), “Mapping Experiences: A Guide to Creating Value through Journeys, Blueprints, and Diagrams“, 440 pages, O’Reilly Media; 2nd edition (15 December 2020)

Kalbach, J. (2020). Jobs to be Done Playbook (1st Edition). Two Waves Books.

Lombardo, C. T., McCarthy, B., Ryan, E., & Connors, M. (2017). Product Roadmaps Relaunched. Sebastopol, CA: O’Reilly Media.

Moorman, J., (2012), “Leveraging the Kano Model for Optimal Results” in UX Magazine, captured 11 Feb 2021 from https://uxmag.com/articles/leveraging-the-kano-model-for-optimal-results

Norman, Donald A. (2013). The design of everyday things. London, England: MIT Press.

Oberholzer-Gee, F. (2021). Better, simpler strategy: A value-based guide to exceptional performance. Boston, MA: Harvard Business Review Press.

Oberholzer-Gee, F. (2021). Eliminate Strategic Overload. Harvard Business Review, (May-June 2021), 11.

Olsen, D. (2015). The lean product playbook: How to innovate with minimum viable products and rapid customer feedback (1st ed.). Nashville, TN: John Wiley & Sons.

Osterwalder, A., Pigneur, Y., Papadakos, P., Bernarda, G., Papadakos, T., & Smith, A. (2014). Value proposition design: How to create products and services customers want. John Wiley & Sons.

Patton, J. (2014). User Story Mapping: Discover the whole story, build the right product (1st ed.). Sebastopol, CA: O’Reilly Media.

Patton, J. (2017). Dual Track Development is not Duel Track. Retrieved February 7, 2022, from Jpattonassociates.com website: https://www.jpattonassociates.com/dual-track-development/

Portigal, S. (2013). Interviewing users: How to uncover compelling insights. Brooklyn, New York: Rosenfeld Media.

Seiden, J. (2019). Outcomes Over Output: Why customer behavior is the key metric for business success. Independently published (April 8, 2019).

Sharon, T. (2016). Validating Product Ideas (1st Edition). Brooklyn, New York: Rosenfeld Media.

Sloane, P. (2017). The leader’s guide to lateral thinking skills: Unlock the creativity and innovation in you and your team (3rd ed.). London, England: Kogan Page.

Spiek, C., & Moesta, B. (2014). The Jobs-to-be-Done Handbook: Practical techniques for improving your application of Jobs-to-be-Done. Createspace Independent Publishing Platform.

Todd, L. (2020). Adding a feature to Lyft: a UX case study. Retrived 7 March 2022 from UX Collective https://uxdesign.cc/adding-a-feature-to-lyft-ux-design-project-c3c2afc518c1

Torres, T. (2021). Continuous Discovery Habits: Discover Products that Create Customer Value and Business Value. Product Talk LLC.

Tullis, T., & Albert, W. (2013). Measuring the user experience: Collecting, analyzing, and presenting usability metrics (2nd edition). Morgan Kaufmann.

Ulwick, A. (2005). What customers want: Using outcome-driven innovation to create breakthrough products and services. Montigny-le-Bretonneux, France: McGraw-Hill.

Wendell, J., Holtzblatt, K., & Wood, S. (2005). Rapid contextual design: A how-to guide to key techniques for user-centered design. The Morgan Kaufmann series in interactive technologies. Elsevier Science & Technology.

Wodtke, C. R. (2021). Radical focus: Achieving your goals with objectives and key results (2nd ed.). Cucina Media.

Young, I. (2008). Mental models: Aligning design strategy with human behavior. Brookly, New York: Rosenfeld Media.

Young, I. (2019). Practical Empathy: For Collaboration and Creativity in Your Work. Brooklyn, New York: Rosenfeld Media.