In a previous post, I’ve argued that designers haven’t found the vocabulary and tools to frame users problems in a way that align 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.
- The Strategy Challenge
- What are Jobs to be Done, Really?
- Where Jobs to be Done Come From?
- Uncovering Jobs to be Done
- Avoid the Traps of “Listening to Customers”
- Techniques for Uncovering Jobs
- Learning through Sales Safari
- Learning Through Customer Interviews
- Observing Behavior Through Contextual Inquiries
- Learning Through Experience Sampling
- Brainstorming with Value Proposition Design
- Measuring Innovation Opportunities with Jobs to be Done
- Facilitating Investment Discussions with Jobs to be Done
- Jobs to be Done as a collaboration tool for creating Shared Understanding
- The Right Time for using Jobs to be Done
- Recommended Reading
- 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.
- Outcome-driven methods shifts our thinking towards answering the question “What is the job performer trying to achieve?“
- Only after a company chooses to focus on the job, not the customer, are they capable of reliably creating customer value.
- Jobs to be Done can be great a unit of analysis to help facilitate discussions 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.
- When the team engages in endless discussions around which customer/user problems we should be focusing on, Jobs to be Done can help frame what are the measures of success for their desired outcomes.
- Jobs to be Done can be a great help to finding ways to remove (or at least reduce) subjectivity while assessing value of pursuing an opportunity, especially with regards to desirability.
- Jobs to be Done can help identify how an opportunity for creating value decreases for any given outcome, and how opportunities are migrating to the other important, unsatisfied outcomes, ensuring the teams keep prioritising the creation of value continuously on jobs that are perceived as providing value for customers/user.
- While is important to recognise that value migrates over time, is probably more important to realize that 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.
- Jobs to be Done are a great way 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.
- Jobs to be done work as a great common exchange currency between leadership, designers, product managers and developers, and here are some 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 describe what users are trying to get done (the “why”s) not the solution (the “how”s), they are — directly or indirectly — a great way to help create the mindset of understanding the problem space before jumping to solutions.
- Provide clarity and scope of discovery activities: because uncovering Jobs to be Done requires clarity about who are the job performers and what are the things they are trying to get done, it makes it a lot easier for us recruit research participants, and zero-in on what are the problems we need to probe.
- Provide a great way to synthesise discovery findings: if Jobs to be Done are great way to share the output of research (e.g..: user needs, goals, success criteria) in a format that is easy to consume, like Job Stories.
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 align with stakeholder business strategies.
- Our user-centered methods have served us well in capturing the user 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 in 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 project/backlog/sprint planning phase).
- In reality any product that makes into the 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 pedalling in the same direction during execution.
From that perspective, the role of designers must change. We must move from focusing only specific innovation projects and design briefs to involvement in strategic decisions that influence and shape organisational strategy.
If designers are to take a more active role in shaping organisational 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 for? Focus on customers and users, but you may also have internal challenges you want to list here too.
- What are our challenges? To develop great strategy, we first need to clarify what is the purpose of our enterprise, our mission or winning aspiration. The term “winning” means different things to different people so the first step in developing 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 aspiration. 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. – narrows our focus.
It’s been my experience while working with Business Stakeholders that is 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 aspiration. 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. – narrows 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 priority such as information architecture, interaction design, 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)
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 objective discussions around prioritisation of problems we are to solve, which ideas to test, and what we should not build. And I’ve seen many designer — 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 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, synthesising human needs, etc.) closer to what 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 engage the stakeholders and influence the business decisions that would drive 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 though effective processes. There are few decisions that are harder than deciding how to prioritise.
I’ve seen too many teams that a lot of their decisions seem to be driven by the question “What can we implement with 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-realisation? Did I impact someone’s life in a positive way?)
The mistake I’ve seen many designers make is to look at prioritisation discussion as a zero-sum game: our user centered design tools set may have focused too much on needs of the user, at the expense of business needs and technological constraints.
To understand the risk and uncertainty of your idea you need to ask: “What are all the things that need to be true for this idea to work?” This will allow you to identify all three types of hypotheses underlying a business idea: desirability, feasibility, and viability (Bland, D. J., & Osterwalder, A., Testing business ideas, 2020):
- Desirability (do they want this?) relates to the risk that the market a business is targeting is too small; that too few customers want the value proposition; or that the company can’t reach, acquire, and retain targeted customers.
- Feasibility (Can we do this?) relates to the risk that a business can’t manage, scale, or get access to key resources (technology, IP, brand, etc.). This is isn’t just technical feasibility; we also look need to look at overall regulatory, policy, and governance that would prevent you from making your solution a success.
- Viability (Should we do this?) relates to the risk that a business cannot generate more revenue than costs (revenue stream and cost stream). While customers may want your solution (desirable) and you can build it (feasible), perhaps there’s not enough of a market for it or people won’t pay enough for it.
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 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).
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.
At its core, the concept of JTBD is straightforward focus on people’s objectives independent of the means used to accomplish them. 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 job could be the tasks that they are trying to perform and complete, the problems the 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).
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 tasks 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).
Related jobs are adjacent to the main job, but are significantly different. For instance, if you define grow retirement portfolio as a main job, related jobs may be finance a new home or balance 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 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 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).
- 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 on my family’s life (e.g.: my son’s soccer finals, 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 for keep my promise with 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 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 price over time
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’ve 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: you can help you quantify Emotional value from the perspective of users.
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 counter argument 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 the 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 afar outweigh the functional jobs.
Simon Sinek created an illustration that he calls “The Golden Circle, with concentric circles that he refers 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”.
If your business core values and vision align to what your customers and users want to become, it will speak louder than any advertising or marketing campaign.
Please mind the “behaviour 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 of us to visualise how our organization’s core values align with those of our customers/users.
Which brings us to Social Jobs at the Organizational Level.
Social Jobs at the Organizational Level
Going back to the 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 counter argument: if we don’t understand who our customers/user want to become, it’s going to be hard to have objective conversations about how to create products or a 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 my team’s full potential to drive individual & organisational 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 is either of Jobs to be Done, or only meant to help establish 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 (functional job at the Organizational Level), which indirectly leads to building their brand as a good employer (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 a services that help them become that.
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 a 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
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 in the wall… but why?
- People don’t want just the whole in the wall, they want to hang a picture in 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?
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?
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).
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”).
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.
Uncovering Jobs to be Done
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 doing working with any method that claims to be “Human-Centered” for any period of time, you will soon realize that why Jobs to be Done are well positioned in the lane of designers and user researchers, because the questions have a great overlap to the exploration of the problem space that designers are particularly interested in understanding before solving a problem, which is 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”, “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 designer — that I first learned from Tomer Sharon (more on him later): don’t listen to users!
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 then 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).
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).
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” or “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 (among government contractors, for instance).
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?”
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 behaviours (Garbugli, É., Solving Product, 2020):
- 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 Beahvior Through Contextual Inquiries can help you understand the customer job at a deeper level by studying prospects in their home or work environment. It’s the ideal technique when you’re able to ge a lot of face time with prospects.
- Learning Through Experience Sampling helps you answer high-level business (or roadmap) questions rather than evaluating a design or product that already exists.
- Brainstorming 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 to useful inputs to product development. Nor should they: It’s your role to get the right inputs. (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 reach their goals and needs. (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).
One variation of job interviews are the Switch interviews, developed by Bob Moesta and Chris Spiek, which focus on listening to story—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):
- First thought: The initial moment when a change is needed.
- Passively looking: The prospect notices options, but isn’t actively seeking change.
- Actively looking: The prospect starts investing time and energy into finding a solution. The second event transitions the prospect into making a purchase decision.
- Deciding: The prospect weighs alternatives. This stage ends with a purchase decision, or the act of signing up.
- Consuming: After signing up or making a purchase, the user uses, and ideally gets value from the product.
Jonathan Briggs 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 on 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:
Exploring how people solve a problem today helps you come up with a great idea tomorrow. Even if you have already 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).
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 which the user doesn’t know how to articulate (Holtzblatt, K., & Beyer, H., Contextual Design: Design for Life, 2016).
We will come back to the topic of discovery later on 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).
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).
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 customer together into a wall sized, hierarchical diagram. In the interpretation sessions you captured individual note representing the user’s data. We call these interpretation session notes affinity notes because you are now going ot use them to build the affinity diagram (Wendell, J., Holtzblatt, K., & Wood, S., Rapid contextual design, 2005).
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 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
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 participant are interrupted several times a day or week to note their experience in real time. The key is to asking the same question ever and over again at random time during the day or work . This cadence and repetition strenghens your finding’s validity and allows you to identify patterns (Sharon, T., Validating Product Ideas, 2016).
Brainstorming 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, 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 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 worry about parking, avoiding drink 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 trainings is that Jobs to be Done don’t come from nowhere: in order for teams to write jobs to be done that can confidently guide them towards creating value for their customers and/or users, these jobs to be done need to be based on real Customer Pains and Gains, which is hard to do 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.
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).
Satisfaction is all about what users say or think about their interaction with the product, traditionally captured during post-study surveys. Users might report what is was easy to user, 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.
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 —customer 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.
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 need 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):
- 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.
- If cost reduction is an important consideration in the market, then costs can be reduced by taking out costly function 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.
- 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 cost 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.
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).
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).
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).
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, 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 Kanon — can help identify how opportunity score decreases for any given outcome, and how opportunities for value creation are migrateing to the other important, unsatisfied outcomes. ensuring the teams keep prioritising the creation of value continuously on jobs that are perceived as providing value for customers/user.
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).
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 for 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).
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 the 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 contemplate and explore the problem space a little longer.
It’s easy to solve the wrong problems. Good design relentlessly questions assumptions, reframing the design problem to be solved.
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 the 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 of Facilitation
The Problem With Problem Statements
In the effort of bringing clarity and shared understanding on what problems we are trying to solve, I’ve seen a lot of organizations try to be more systematic and adopt artefacts 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 problem with problem statements (pun intended) that I’ve found is that there are many thinking traps and decisions 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:
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
Design a Vase
Design a better way for young families to enjoy flowers in their home
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 on 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 outcome”. Josh Seiden defines as outcome “a change in user behaviour 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 behaviours that drive business results? If the team gets stuck on 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.
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, it helps them choose the right customer opportunities to address, and it 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).
There are two fundamental principles for that (Cagan, M., Inspired: How to create tech products customers love, 2017):
- Never tell people how to do things. Tell them what to do, and they will surprise you with their ingenuity.
- 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 key here is — going back to Joshua Seiden’s “Outcomes” — to help the team connect the dots between what are the changes in human behaviour that drives business results?
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 described 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).
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 need that reflects 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 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
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 visualisation 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: team will lack engagement and slowly drift apart.
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 a 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 a 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).
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 develop a 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 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 synthesise 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 synthesising research outputs (e.g..: user needs, goals, success criteria) in a format that is easy to consume like — for example — with 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).
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):
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 in 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 looks like. As I mentioned earlier, since my colleagues are using Job Stories as 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 and mentioned previously and the incredible facilitation skills of Martina William and Anton Fischer) to connect the dots between Product Vision, Customers and/or 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 of 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 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 set up 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 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 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 characterises a degree to which the participants are informed about the process procedures, rules, requirements, workflow and other details. The higher is process awareness, the more profoundly the participants are engaged into 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 contemplate and explore the problem space a little longer.
Knowing when team 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 cheatsheet that maps which questions are more appropriate for different phases of the product development lifecycle. So the following set of activities is inspired in 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 of 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
- Value Proposition Design
- Jobs to be Done (JTBD)
- Testing Business Ideas
- A Value Opportunity Analysis (VOA)
- Desirability Testing
Jobs to be Done during “Define”
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 pay off in mitigating back-and-forth. 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
- 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 that 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 we should pivot, persevere, or stop.
Here are my recommendations for suggested quantifying and qualifying activities and methods:
- User Story Mapping
- Design Studio
- 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)
Jobs to be Done during “Deliver”
In this phase is too late to talking about Jobs to be Done as in “what are the problems we are trying to solve”, 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 on 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
- Pirate Metrics (a.k.a. AARRR!)
- UXI Matrix (Pugh Matrix)
- Objectives, Goals, Strategy & Measures (OGSM)
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)
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.
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..
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.