Crafting Customer-Centric Roadmaps: A Jobs-to-be-Done Approach to Roadmap Planning and Better Backlog Grooming

In a previous post, I argued that Jobs to be Done could serve as an effective means of exchanging ideas on value in strategy discussions between designers, business stakeholders, and technology experts. Additionally, I shared some insights on how to utilize Jobs to be Done to engage stakeholders and drive business decisions that advance the product vision.

In this article, we’ll explore how to use JTBD in roadmap planning and backlog grooming. We’ll see how it can transform the entire product development process, from creating user-focused roadmap strategies to the nitty-gritty of backlog grooming: by keeping user needs at the forefront of every decision, we ensure that our solutions resonate with the true essence of what our customers are trying to achieve.

TL;DR;

• By focusing on the job performer’s goals independently of specific solutions, JTBD facilitates discussions with business stakeholders, ensuring alignment on crucial outcomes. This nuanced approach ensures that priorities align with what truly matters to the user, fostering a continuous cycle of value creation.
• JTBD eliminates subjectivity in opportunity assessment, revealing how the value of an opportunity evolves for specific outcomes. By anchoring decisions to the user’s job to be done, teams can objectively evaluate the value of pursuing an opportunity and understand how it aligns with user satisfaction.
• As value migrates over time, stable customer outcomes remain a focal point. JTBD becomes a compass for framing the value proposition and product vision, fostering a long-term focus on satisfying enduring customer needs. This communicates a resilient value proposition and guides long-term product vision, ensuring sustained relevance.
• JTBD serves as a common exchange currency that facilitates collaboration across diverse teams. Leveraging Jobs-to-be-Done during product discovery enhances problem space understanding, guides research efforts, and facilitates effective stakeholder communication and decision-making. Whether engaging with leadership, designers, product managers, or developers, the framework encourages discussions centered around problems, fostering clarity and alignment.
• Finally, JTBD injects user-centricity into every roadmap layer, shaping a dynamic balance between goals, audience, and effective communication. From construction to prioritization and alignment, JTBD serves as the compass, ensuring that product strategy aligns seamlessly with users’ desired outcomes. These outcome-focused roadmaps are more than just plans; they are strategic realignments guided by a profound understanding of jobs-to-be-done, steering the organization toward impactful product delivery.

Introduction

Roadmaps are strategic artifacts that outline the direction of a product over time. It helps teams prioritize features, set goals, and align stakeholders around a shared vision. A well-planned roadmap can help teams focus on the most critical work, avoid scope creep, and make informed decisions about what to build next.

Most organizations have roadmaps, but are we really making progress? We’re often chasing deadlines, delivering features, yet somehow, we’re missing the mark on our goals. Why? Because many roadmaps are just wishlists, not strategic plans. Without a clear ‘why’ behind each feature, teams get bogged down in endless cycles of development, only to find that we’ve solved the wrong problem.

A comprehensive plan with detailed timelines and budgets might seem comforting, but it’s not a strategy. True strategy involves embracing uncertainty and exploring uncharted territory.

As a strategic artifact, a product roadmap should reflect this dynamic nature. Instead of a rigid plan, it should be a living document that evolves as we learn and adapt. By focusing on outcomes and prioritizing flexibility, we can produce product roadmaps that create the clarity and agility that drive innovation and deliver long-term value.

A good roadmap is a strategic communications tool, a statement of intent and direction, and — when done right — a way of rallying the whole organization around the key problems that must be solved to achieve your product vision.

Lombardo, C. T., McCarthy, B., Ryan, E., & Connors, M., Product Roadmaps Relaunched, 2017

A product roadmap is not a detailed project plan or a release schedule. It’s a strategic tool that outlines the product’s long-term vision and the key initiatives required to achieve it. Instead of focusing on specific features and dates, a roadmap should prioritize outcomes and the value they deliver to customers. By shifting our focus from “what to build” to “why we’re building it,” we can ensure that our products are aligned with our strategic goals and truly meet the needs of our users.

The Jobs-to-be-Done (JTBD) framework has become a crucial tool in my practice as a strategist, helping teams make better decisions that drive experience and vision forward. This article’ll explore how JTBD can transform the entire product development process, from creating user-focused roadmap strategies to the nitty-gritty of backlog grooming. Let’s begin a journey where user needs lead the way, shaping every choice and guaranteeing that the solutions created align with the genuine goals of customers and our business.

Reasons for Crafting Roadmaps

Product roadmaps can be very useful tools for product leaders, as they serve multiple strategic purposes. Here are three strong reasons for creating product roadmaps, drawing on the insights of Bruce McCarthy, Teresa Torres, and Marty Cagan:

Strategic Alignment and Communication

Product roadmaps provide a clear communication tool that aligns the team’s efforts with the overall product strategy. According to Bruce McCarthy, a well-structured roadmap articulates the “why” behind product decisions, ensuring that all stakeholders understand the direction and objectives of the product. This alignment helps prevent feature bloat and ensures that resources are focused on initiatives that matter most to achieving strategic goals.

Prioritization and Decision-Making Framework

Teresa Torres emphasizes that roadmaps help product teams prioritize their work effectively. By focusing on strategic themes rather than individual features, teams can make informed decisions about which initiatives to pursue and which to defer. This approach allows for a more flexible response to changing market conditions and user needs, as it provides a framework for evaluating new ideas against existing priorities

Enhanced Stakeholder Buy-In

Marty Cagan points out that involving stakeholders in the roadmap creation process fosters buy-in and collaboration. A roadmap that reflects collective input is more likely to gain support from both internal teams and external stakeholders, as it demonstrates a commitment to transparency and shared goals. This collaborative approach not only enhances trust but also encourages diverse perspectives that can lead to better product outcomes.

Product Roadmaps and Jobs-to-be-Done

In a previous post, I mentioned that The Jobs to Be Done (JTBD) framework works a common currency facilitating discussions among designers, product managers, and developers on the inherent value of pursuing an opportunity. By focusing on the specific jobs that customers are trying to accomplish, teams can prioritize features and functionalities that deliver real value.

This alignment not only enhances the clarity of product roadmaps but also ensures that all stakeholders are working towards the same outcomes. When everyone—from product managers to engineers—understands the underlying motivations driving customer behavior, it fosters a cohesive approach to product development, ultimately leading to more innovative solutions that resonate with users and achieve business objectives.

Jobs-to-be-Done as a Facilitation and Prioritization tool 

When it comes to product management, Jobs-to-be-Done (JTBD) is incredibly valuable, particularly when communicating with business stakeholders. In this part of the blog post, I’ll make the case for the importance of JTBD in such discussions, emphasizing its ability to facilitate investment discussions and focus on critical outcomes.

It’s crucial for product managers and business stakeholders to understand that what I’ve found in my 25 years of experience design and strategy is that — more often than not — it 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. Therefore, before jumping into roadmap planning and backlog grooming, it’s important to address this issue and ensure that everyone is on the same page.

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

Facilitating Investment Discussions

Within the complex process of product development, the cooperation between product teams and business stakeholders is a crucial element that connects strategic objectives with practical insights. It is vital to facilitate meaningful discussions in this area to ensure that the diverse perspectives of stakeholders align seamlessly with the overall product vision. The Jobs-to-be-Done (JTBD) framework plays a central role in this collaborative effort by providing a structured approach that goes beyond individual preferences or biases. By focusing on the fundamental goals that users seek to achieve, JTBD enables a shared understanding that bridges the gap between the intricacies of product design and the broader business objectives.

The Jobs-to-be-Done (JTBD) methodology is a valuable tool that facilitates investment discussions with business stakeholders. It acts as a compass, directing conversations toward the most critical outcomes, all viewed through the lens of the job performer. As explained in an earlier blog post, a “job” in the JTBD framework refers to a goal or objective that exists independently of any specific solution. This independence is crucial to understanding that the service or product is simply a means to an end, and the focus should be on identifying the job that customers are trying to accomplish rather than the features of the product or service itself.

A key aspect of this approach is to focus on aligning with the critical objectives from the job performer’s perspective. As stated by Anthony Ulwick in his book What Customers Want, the JTBD framework is centered on people’s objectives, regardless of the methods used to achieve them. This perspective offers a structured and insightful way to understand customer needs, which in turn allows for more accurate predictions of future customer actions.

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

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

From that perspective, there are a few ways that my colleagues and I have been taking full benefit of the advantages of using Jobs to be Done to create a shared understanding of product outcomes and customer outcomes:

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

Focus on Critical Outcomes

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

Part of the challenge is that people’s decisions and actions are seemingly unpredictable. Resting your growth strategy on fuzzy concepts like “needs” and “empathy” is daunting (Kalbach, J., Jobs to be Done Playbook, 2020).

While psychology and other fields (including design) have precise definitions of human needs, business does not. As a result, risk-averse organizations struggle to grasp the customer perspective and align to it.

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

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 (JTBD) or “outcomes that customers are seeking”.

Customers and User Outcomes

Jobs-to-be-Done (JTBD) is a new way of approaching the innovation process. It revolves around understanding the customer’s job and the metrics they use to measure success. This helps companies to create breakthrough products and services systematically and predictably.

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

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

Because they don’t mention solutions or technology, jobs 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).

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):

1. Customers buy products and services to accomplish jobs: your product is just a means to an end.
2. Customers use a set of metrics to evaluate how a product performs: they don’t look at a list of features but how well it helps them get a job done.
3. These customer metrics enable the systematic and predictable creation of breakthrough products and services: we can use these jobs to identify growth opportunities, analyze competition, generate ideas, communicate value, and measure satisfaction.

The precursors to JTBD date back to Theodore Levitt, who famously said, “People don’t want a quarter-inch drill, they want a quarter-inch hole.” Peter Drucker was the first to use the term “job to be done” in conjunction with what he called a “process need.”

At its core, the concept of JTBD is a 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).

Product Outcomes

If you read my post on Bringing Business Impact and User Needs together with Jobs to be Done, you understand why I think we should add user or customer outcomes to this list and how product outcomes and customer outcomes are interconnected through Jobs-to-be-Done (JTBD).

As a general rule, product trios will progress more on a product outcome than a business outcome. Remember, product outcomes measure how well the product moves the business forward. By definition, a product outcome is within the product trio’s span of control. On the other hand, business outcomes often require coordination across many business functions. (Torres, T., Continuous Discovery Habits, 2021).

In essence, Jobs-to-be-Done emerges as a powerful tool in the product manager’s arsenal, enabling meaningful discussions with business stakeholders that focus on the essence of the job performer’s goals and objectives, ultimately aligning the product or service with these critical perspectives.

Eliminating Subjectivity in Opportunity Assessment

The Jobs-to-be-Done (JTBD) framework helps teams compare, contrast, and debate the value of ideas and solutions. Outcome-Driven Innovation (ODI) is a reliable approach to reduce subjectivity while assessing the value of opportunities.

Ulwick’s opportunity algorithm measures and ranks innovation opportunities based on importance and satisfaction. By using this algorithm, product managers can pinpoint opportunities in the market and make important targeting and resource-related decisions.

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

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

Outcome-Driven Innovation (ODI) is a reliable approach to reduce subjectivity while assessing the value of opportunities. Ulwick’s opportunity algorithm measures and ranks innovation opportunities based on importance and satisfaction. (Ulwick, A. W., What customers want, 2005).

An opportunity for improvement exists when an important outcome is underserved. This means when it has a high opportunity score, it merits the allocation of time, talent, and resources, as customers will recognize solutions that successfully serve these outcomes to be inventive and valuable.

Jobs and outcomes that are unimportant or already satisfied represent little opportunity for improvement and consequently should not receive any resource allocation. 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: stop doing it, reduce investment in it, or improve it enough to create a new outcome.

In practical terms, the opportunity algorithm becomes a powerful tool for predicting where value migrates. This algorithm, as elucidated by Ulwick, allows product managers to pinpoint opportunities in the market at any given time and be the first to address them. This aligns seamlessly with the overarching goal of innovation: defining and delivering new solutions that continuously evolve each measure of value along its continuum, better satisfying the collective set of outcomes.

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

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

In the context of backlog grooming, these principles empower product managers to make strategic decisions that anticipate the market value’s dynamic nature. Since jobs are stable over time, by leveraging the insights gained from JTBD, product teams can navigate the shifting landscape of opportunities, ensuring that their investments align with their target audience’s evolving needs and priorities.

These principles help product teams navigate the shifting landscape of opportunities, ensuring their investments align with their target audience’s evolving needs.

Translating User Research Insights for Roadmapping and Backlog Grooming

Jobs-to-be-Done (JTBD) became a powerful tool when translating user research insights for roadmapping and backlog grooming. In a previous blog post, I mentioned that I’ve been using Job Stories — inspired by the pioneering work of the product development team at Intercom — as a powerful catalyst in synthesizing research findings into user-friendly formats.

JTBD is a useful tool for translating user research into roadmaps and backlogs. Job Stories are an alternative to user stories that focus on the user’s underlying motivation. While User Stories traditionally focus on the features and functionalities a user desires, Job Stories shift the narrative to the user’s underlying motivation or objective. Users Stories might articulate what a user wants within a system, while Job Stories delve into why they want it. By addressing the “Jobs-to-be-Done,” Job Stories inherently capture the context and motivation behind user actions. Such distinction will be important later when we talk about user story mapping.

That said, I want to make clear that Jobs to be Done is not a brainstorming tool! As I discussed with Jim Kalbach when I interviewed him for SAP’s UX Immersive Week: if you really want to create human-centered products, you have to (as our good friend Tomer Sharon always says) “get out of the building,” — either physically or metaphorically — and learn about the job performers. You might start with assumptions about what is the job your customers are trying to get done (heck, you might even want to start with ChatGPT!), but you have to talk to real humans and validate your assumptions!

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

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

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

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

Job Stories’ simplicity and ability to encapsulate the user’s Jobs-to-Be-Done provides a holistic view of users’ and customers’ outcomes. During backlog grooming, they become a shared language that enhances stakeholder communication and fosters collaboration and empathy among teams.

Outcome-Driven Roadmap Planning

In traditional planning, the solution provider commits to delivering specified deliverables (the scope) at a specified cost within a given time frame. This approach doesn’t work when requirements are volatile because it locks all parties into predetermined specifications that are likely to be outdated by the time the product is delivered (Podeswa, H., The Agile Guide to Business Analysis and Planning: From Strategic Plan to Continuous Value Delivery, 2021).

Requirements assume we know exactly what we need to build. Ideally, they come from engineering rigor. But in software, they usually don’t have the rigor behind them. Still, they are taken at face value based on their author’s credibility or organizational title.

Gothelf, J., & Seiden, J.,  Lean UX: Applying lean principles to improve user experience (2021)

Instead of focusing on predetermined deliverables, agile enterprises focus on desired outcomes, such as increased revenues and increased customer loyalty (Podeswa, H., The Agile Guide to Business Analysis and Planning: From Strategic Plan to Continuous Value Delivery, 2021).

Outcomes over Outputs

You might be asking, “what do you mean by outcomes?” Joshua Seiden defines outcome as “a measurable change in behavior that drives business results“:

• Outcomes refer to the benefits that customers receive from your products or services. To achieve these outcomes, you need to truly understand your customers’ needs by walking in their shoes.
• Outputs, such as revenue and profit, enable you to fund outcomes. To start thinking in terms of outcomes, ask three simple questions: what behaviors drive business results, how to get people to do more of these things, and how to know you’re right.

Using outcomes creates focus, eliminates needless work, and puts the customer at the center of everything you do. From the outcomes over outputs perspective, your strategy should say what you will do, not how you will do it. Managing by outcomes communicates to the team how to measure success, align around the work they should prioritize, and measure the impact of their experiments. It gives our teams the autonomy, responsibility, and ownership to chart their own path and solve customer problems or address business needs.

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

Seiden, J., Outcomes over Output (2019)

The key distinction between this strategy and traditional roadmaps is that we’re giving the team the autonomy to find the best solution. Alignment around strategy is created by a robust communication process that combines top-down strategy, bottom-up insight, and two-way communication.

Additionally, this strategy leaves room for doubt (Torres, T., Continuous Discovery Habits, 2021):

• A fixed roadmap communicates false certainty. It says we know these are the right features to build, even though we know from experience their impact will likely fall short.
• An outcome communicates uncertainty. It says we know we need this problem solved, but we don’t know the best way to solve it. It gives the product trio the latitude they need to explore and pivot when needed.

The keyword here is uncertainty, which sounds scary to many people! Uncertainty draws people to the conversation by admitting you don’t have all the answers, and inviting others to figure it out!

8 Mistakes to Avoid when Defining Product Outcomes

According to Hope Gurion and Teressa Torres, there are some common mistakes you should avoid when defining product outcomes (Defining Product Outcomes: The 8 Most Common Mistakes You Should Avoid, 2022):

• Disguising Outputs as Outcomes: This happens when a team defines an outcome as something that is easily delivered, but doesn’t add value to the business. For example, delivering an Android app is an output, but it is not an outcome. An outcome should be something that benefits the business, such as increasing customer satisfaction or revenue.
• Not Connecting Outcomes to Business Value: This can happen when a team focuses on a goal that seems important, but doesn’t align with the company’s strategy or how it makes money. For example, a team might focus on increasing the number of users of their product, but if this doesn’t lead to more paying customers, it is not a valuable outcome.
• Giving Teams Outcomes That Are Outside Their Span of Control: This can happen when a team is assigned a goal that relies on other departments or external factors for completion. For example, a product team might be assigned a goal of increasing customer satisfaction, but if customer satisfaction is also affected by the quality of customer support, then the product team cannot control the outcome on its own.
• Hyper-focusing on a Traction Metric: This can happen when a team focuses on a metric that shows user engagement but may not reflect true customer value. For example, a team might focus on the number of daily active users (DAUs) of their product, but if DAUs don’t translate into paying customers, then it is not a valuable outcome.
• Creating Too Many Dependencies Across Teams: This can happen when a team is assigned a goal that requires multiple teams to collaborate without clear direction or ownership. For example, a product team might be assigned a goal of increasing customer satisfaction, but if customer satisfaction is also affected by the quality of customer support and the sales process, then the product team cannot achieve the goal on its own.
• Measuring Actions Instead of the Value of Those Actions: This can happen when a team focuses on user actions, such as applying for a job, instead of the desired outcome, such as getting hired. For example, a team might focus on the number of users who apply for a job on their job board. However, this is not a valuable outcome if the number of users who get hired does not increase.
• Setting Sentiment Outcomes Without Any Further Direction: Customer satisfaction and customer sentiment are important, but when we have such a broad sentiment-based metric, it can be very challenging for teams to please everybody all the time, which is kind of where you end up when you just have a sentiment metric.

Roadmap Planning with Jobs-to-be-Done (JTBD)

To provide a comprehensive understanding of roadmaps in the context of this outcomes over outputs approach, let’s draw insights from Product Roadmaps Relaunched by C. Todd Lombardo, Bruce McCarthy, Evan Ryan, and Michael Connors and contrast those points with the Jobs-to-be-Done (JTBD) approach:

• Roadmaps Misconceptions: A well-crafted product roadmap is more than a timeline; it’s a guiding document steering the entire organization toward delivering on the company strategy, which should be informed by its customers’ desired outcomes. JTBD complements this by emphasizing the user’s goals and desired outcomes independent of solutions. By understanding the job performer’s desired outcomes, the roadmap becomes a means to fulfill those objectives, aligning with the overall organizational strategy.
• Components of a Roadmap: When creating a roadmap, it is important to understand its basic building blocks, including strategic components like goals, audience, and the roadmap’s role as a communication tool. It would be best if you structured the roadmap into layers – primary, secondary, and complementary – for a comprehensive view. JTBD provides the why behind these components. It guides the identification of goals by focusing on the user’s job to be done. The layers in the roadmap align with the primary, secondary, and complementary aspects of the user’s objectives.
• Gathering Inputs: Before constructing a roadmap, gather inputs from various stages in a product’s life cycle, including market analysis, internal and external stakeholder input, customer feedback, and — more importantly — user research. This step ensures you have the relevant information and context for informed product decisions. JTBD serves as a powerful input source by focusing on the user’s needs and desired outcomes, working as common currency for teams to describe value. It ensures that the roadmap reflects the critical outcomes that contribute to fulfilling the user’s job.
• Establishing the Why with Product Vision and Strategy: It’s essential to establish a clear product vision and strategy for product development. This involves distinguishing between mission, vision, and values and crafting a compelling product vision. Developing a functional product strategy aligned with the vision is essential, emphasizing the importance of defining success metrics early on. JTBD helps establish the product’s purpose by focusing on the user’s needs. Since jobs are stable over time, developing a product that aligns with the user’s job can ensure continued user satisfaction in the long run and increase our confidence in our vision. It ensures that success metrics are grounded in the impact on the lives of the people your product serves. [Learn more about Product Vision in Strategy and the Importance of Vision]
• Uncovering Customer Needs Through Roadmap Themes:  It is all about understanding and expressing customer needs on your product roadmaps, and relate them to objectives to ensure a customer-centric approach. By exploring the significance of these practices, you can better uncover your customers’ needs and improve your product development process. JTBD is instrumental in describing themes that are clearly mapped to customers’ needs by focusing on their goals and desired outcomes. It guides the creation of themes and stories that resonate with the user’s objectives, ensuring a roadmap that truly serves the customer.
• Prioritizing—with Science!: When prioritizing tasks, it’s important to consider common frameworks and methods, as well as practical factors like dependencies, resources, and promises, before scheduling work. However, traditional scoring approaches may have limitations. JTBD complements prioritization by providing a clear framework based on the user’s priorities and what they perceive as value. It ensures that the resulting priorities align with the user’s job to be done and considers dependencies and resources that contribute to overall satisfaction [Learn more about prioritization methods in Strategy and Prioritisation].
• Achieving Alignment and Buy-in: Focus on achieving stakeholder alignment and presenting your visual roadmap through strategies such as diplomacy, co-creation workshops, and product-focused software to align teams effectively. JTBD aligns stakeholders by focusing on the common ground of fulfilling user needs. Roadmap co-creation workshops are enriched with JTBD insights, ensuring that stakeholders align not just with the plan but with the user’s objectives [Learn more about achieving buy-in in Strategy and Facilitating Good Decisions].
• Presenting and Sharing Your Roadmap: think about your roadmap as a conversation tool — internally and externally — that helps you communicate (and shape) the future of your product. Understand risks in different contexts and make tailored versions for diverse stakeholders. JTBD enhances the presentation by providing a compelling narrative centered around the user’s journey. Sharing roadmaps becomes a story of fulfilling user objectives, resonating with both internal and external stakeholders.

Overall, the combination of outcome-driven roadmap planning and JTBD provides a powerful framework for businesses to create products and services that truly meet the needs of their customers. By focusing on outcomes and jobs rather than features and functionality, businesses can create more effective solutions that are better aligned with customer needs and desires.

Backlog Grooming with Jobs-to-be-Done (JTBD)

Backlog grooming is a crucial process that ensures clarity, prioritization, and alignment within a product team. In his book User Story Mapping, Jeff Patton sheds light on successful organizations’ practices, emphasizing routine collaboration and detailed discussions in the backlog grooming process. In my experience, I have been using Jobs-to-be-Done (JTBD) as an exceptional facilitation tool, complementing and enhancing the principles outlined by Patton. Here are a few examples on JTBD helps align user stories with the user’s needs and goals, making the backlog grooming process more effective:

• Routine Collaboration and Story Workshops: Patton underscores the significance of routine collaboration in backlog grooming. Frequent story workshops, held at least once or twice a week, allow teams to review, reorganize, and plan their work effectively. Here, JTBD serves as a guiding framework that ensures these discussions remain focused on the user’s objectives, aligning the team’s efforts with the core jobs users are trying to accomplish.
• Opt-In Participation and Small Discussions: To foster productive discussions, Patton recommends allowing participants to “opt in” and keeping the discussions small. As I mentioned earlier in this article, JTBD becomes the facilitation tool and a common currency that creates clarity and generates team alignment on what users’ problems need to be solved. By focusing on the jobs users need to get done, discussions inherently become more concise and targeted, ensuring that every participant is actively contributing to the shared understanding of user needs [Learn more about Creating Shared Understanding at Strategy and the Need for Facilitation].
• Whiteboard Collaborations and Visual Storytelling: Moving conversations out of tools and back to the whiteboard is a Patton-recommended practice. JTBD complements this visual storytelling by providing the anchors of the backbone of your story maps (check the alignment diagrams later in this article). Utilizing the whiteboard to map out user journeys and jobs to be done facilitates a comprehensive understanding of the user’s context and goals. This visual approach enhances communication and ensures the team collectively grasps the user’s perspective.
• Acceptance Criteria and Building Shared Understanding: Patton emphasizes that acceptance criteria should follow the building of shared understanding. JTBD seamlessly aligns with this concept by encouraging teams to first understand the user’s jobs to be done before defining acceptance criteria. By identifying what success looks like from the user’s perspective, teams can craft acceptance criteria that truly reflect the user’s expectations and contribute to a more robust definition of “done.”

In essence, Jobs-to-be-Done emerges as a facilitation tool that adds a crucial layer to the backlog grooming process. By aligning user stories with the user’s jobs to be done, it ensures that the team not only understands what needs to be done but why it matters to the user. This user-centric approach enhances collaboration, drives prioritization based on user needs, and ultimately leads to a backlog that reflects a deep understanding of the customers and their desired outcomes.

Roadmap Planning and Visual Thinking

As organizations are shifting towards outcome-driven methods to deliver value that aligns with customer goals, Alignment diagrams serve as a hinge to facilitate the pivot from the problem space to the solution space by creating visualizations that draw stakeholders into conversations about creating value. The ultimate goal is to foster inclusive dialogues within the organization

In a previous blog post, I discussed using alignment diagrams, particularly in facilitating alignment between designers, business stakeholders, and technology teams.

Jim Kalbach uses the term alignment diagram to refer to any map, diagram, or visualization that reveals both sides of value creation in a single overview. They are a category of diagram that illustrates the interaction between people and organizations. If you want to learn more about it, you can check my post on visual thinking. For the purpose of this post, the alignment diagram that is worth mentioning is user story mapping.

User story mapping is a visual exercise that helps product managers and their development teams define the work that will create the most delightful user experience. User Story Mapping allows teams to create a dynamic outline of a set of representative user’s interactions with the product, evaluate which steps have the most benefit for the user, and prioritise what should be built next (Patton, J., User Story Mapping: Discover the whole story, build the right product, 2014).

Let’s contrast Jeff Patton’s levels of granularity in User Story Maps with Karl Wiegers’ levels of granularity in requirements and Jim Kalbach’s Job Hierarchy:

Jeff Patton’s Granularity Levels in User Story Maps

• Activities or Scenarios (Goals): Represents a process that unfolds over a more extended period, typically involving multiple steps. Each step can be further detailed in user tasks or user stories.
• User Tasks or Backbone (Narrative): Encompasses tasks that users aim to accomplish in a single sitting. It forms the backbone of the User Story Map, providing a comprehensive view of the user journey or the product’s usage sequence.
• Details or User Stories: Breaks down tasks into smaller, more manageable components. User stories at this level offer detailed insights into the specific functionalities or features required.

Karl Wiegers’ Levels of Granularity in Requirements

• Scenario (Kite Level): Describes a process that spans a more extended period, possibly hours, days, or weeks, involving numerous steps. Each step at this level is likely to be a separate user goal, detailed further in use cases at the sea level.
• Task (Sea Level): Focuses on whether the targeted personas can achieve satisfaction after completing a specific task. It is something a user seeks to accomplish in a single sitting, reflecting a complete action before a break.
• Detail (Fish Level): Involves smaller activities done in support of a more significant task. These details contribute to the overall completion of a larger task.

Jim Kalbach’s Job Hierarchy

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

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

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

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

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

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

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

You get the idea!

I know that we already spent a lot of time talking about hierarchies here, but there is one that is going to be important for our discussion later, which is to break down Aspirations into Social and Emotional Jobs.

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

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

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

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

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

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

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

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 connect the dots between social needs and the business bottom line. I’ve heard the argument that social jobs (“I want to be perceived as…”) are the realm of marketing and branding, not experience or service design. But here is the counterargument from Scott Lietzke (our VP of Product Design at SAP SuccessFactors): for most enterprises, the experience is the brand!

By now, I hope you realize that frameworks aim to break down complex processes into more understandable components, even if their terminology and emphasis slightly differ. Jeff Patton’s User Story Maps emphasize the progressive breakdown of user activities, tasks, and details, creating a visual representation of the user journey. Karl Wiegers’ granularity levels in requirements offer a comparable breakdown, with a scenario encompassing multiple tasks, and tasks broken down into smaller details. Jim Kalbach’s Job Hierarchy introduces four levels: Aspirations, representing an ideal change of state; Big Job, a broader objective aligning with the main job; Little Job, a smaller job corresponding to stages in a big job; and Micro-Job, activities resembling tasks but formulated in terms of JTBD.

Each hierarchy, whether in User Story Maps, requirements, or JTBD, reflects a hierarchical understanding of goals, emphasizing the importance of aligning higher-level objectives (whys) with detailed execution (hows). We will bring everything together in the next section when we talk about Ladders of Abstraction.

Creating Shared Understanding through Abstraction Laddering and Alignment Diagrams

As we mentioned in the previous section, Alignment Diagrams serve as a hinge that seamlessly bridges the gap between problem space and solution space. Employed in strategic discussions, these diagrams bring together designers, business stakeholders, and technology experts, fostering a shared understanding of objectives and creating a visual narrative of value creation.

Simultaneously, the introduction of Daniel Stillman’s Abstraction Laddering adds another layer to this collaborative foundation. Rooted in the philosophy that understanding shared goals is paramount for effective collaboration, Abstraction Laddering provides an interface for dissecting the layers of why, what, and how in goal-oriented discussions. It becomes a vital complement to Alignment Diagrams, providing a structured method to uncover deeper motives and intricacies in problem-solving.

While Jeff Patton’s User Story Maps, Karl Wiegers’ levels of granularity in requirements, and Jim Kalbach’s Job Hierarchy offer distinct frameworks, a striking similarity emerges when viewed through the lens of Daniel Stillman’s Abstraction Laddering:

• In both Patton, Wiegers, and Kalbach’s models, the higher levels, such as goals, scenarios at the kite level, or aspirations, correspond to the “whys” of the user journey.
• As one descends to lower levels, like details at the fish level, or microjobs, the focus shifts to the “hows” or the specific steps and actions necessary for task completion.
• This alignment underscores a shared principle across these frameworks: the importance of understanding the overarching goals (whys) at higher levels and the detailed execution (hows) at lower levels to create comprehensive and user-centric solutions, ensuring the teams are solving the “right” problems.

When contextualizing these tools within the Jobs-to-be-Done framework, they collectively offer a pragmatic approach to generating alignment in problem-solving discussions. Alignment Diagrams aid in visually articulating the alignment of objectives, while Abstraction Laddering becomes the scaffolding for exploring the layers of motivation behind these objectives. In the subsequent section, we’ll explore how this contextualization sets the stage for a unified framework, harmonizing the collaborative power of visual tools with the nuanced understanding of user needs and motivations encapsulated in JTBD.

Combining Abstraction Laddering with User Story Mapping and JTBD

In my practice of facilitating strategy discussions, the integration of Jeff Patton’s User Story Mapping, the hierarchical insight from Jim Kalbach’s Jobs-to-be-Done (JTBD), and the abstraction laddering methodology advocated by Daniel Stillman manifests a holistic framework for comprehensive product development.

As Patton’s User Story Map progresses from the broad strokes of “activities or scenarios” to the refined details of “details or user stories,” Kalbach’s JTBD hierarchy complements this journey with “functional jobs,” “social jobs,” and “emotional jobs.” Aligning these with Stillman’s abstraction laddering, jobs seamlessly substitute for the “whys,” encapsulating the core motives and user needs, while User Stories become adept substitutes for the “hows,” translating those motives into tangible functionalities.

Stillman’s emphasis on shared goals, visualized through concentric circles and abstraction ladders, finds resonance in the collaborative aspects of User Story Mapping and the nuanced layers of JTBD, creating a unified framework that harmoniously blends the why, what, and how of product development. This synthesis provides a robust interface for stakeholders to collaboratively navigate the complexities of strategy and execution collaboratively, ensuring a shared vision and clarity in goals, thus propelling the product development journey forward.

Roadmap Planning through Alignment Diagrams Step by Step

In the process of creating truly meaningful alignment diagrams, there are practical considerations that need to be taken into account. This section will explore the hands-on experience of developing job boards and conducting user story mapping workshops. This will involve examining the details of facilitating these sessions and providing step-by-step guidance on revealing jobs, aligning them with the customer journey, and mapping them to tasks. With insights drawn from real-world experiences, we will translate abstract ideas into tangible diagrams that represent tasks and user stories and serve as powerful tools for promoting shared understanding within your teams. Join us on this pragmatic exploration of how to turn theory into actionable frameworks.

Uncovering Jobs with Precision

The journey to alignment begins by uncovering the fundamental jobs that customers or job performers are trying to get done. Encourage your teams to explore and articulate these jobs for each task, leveraging their expertise on job performers’ or customers’ tasks. The generated list of jobs serves as the foundation. However, as I emphasized earlier, this is not a brainstorming process; it requires insights or visibility into the jobs. If lacking such insight, teams either need to conduct user research or acknowledge that the list is a set of hypotheses for future validation. Employ Abstraction Laddering to check the granularity of jobs, ensuring they align with Kalbach’s levels—jobs, micro jobs, or aspirations. Segregate aspirations into emotional and social jobs, forming the “why” behind jobs and enabling the crafting of a compelling narrative for your job board.

Aligning in the Customer Journey

With a list of jobs in hand, the next step is to align the sequence of steps within the customer journey. A clear understanding of tasks or business scenarios that customers or job performers aim to complete is crucial at this stage. Without this foundation, discussions on task details may result in unnecessary back-and-forth. This alignment forms the backbone of Jeff Patton’s User Story Map.

Managing Task Granularity and Iteratively Mapping Jobs to Tasks

Addressing the level of detail for tasks can be a challenge. My recommendation is to either define a clear level of granularity upfront (usually Wieger’s Kite/Sea/Fish level) or start the sequence of the tasks first and review the level of granularity through a clustering exercise later. Map tasks to jobs iteratively and visualize them using an abstraction ladder. For each task, ask “Why are the job performers trying to complete that task?” and move up one level on the ladder to establish a clear connection between the task and the job.

Transitioning to Solution-Oriented Discussions with User Stories

As the alignment diagram takes shape, the team transitions to solution-oriented discussions. The focus turns to the “how” as the team contemplates enhancements or new features required to help job performers complete each task. Enter the realm of user stories, where each user story is mapped to the backbone of the User Story Map.

Ultimate Discussion Tool for Value Perception

The alignment diagram, now a comprehensive job board, becomes the ultimate discussion tool. For each added user story, the team assesses its value by ascending the abstraction ladder and questioning whether the feature or idea contributes to job performers getting their jobs done. This iterative process fosters rich conversations, with the alignment diagram serving as a shared understanding that streamlines discussions during the execution phase.

Now that we have identified the user stories that align with the customer’s needs and job performers, we can begin negotiating with the business stakeholders. The goal is to determine the sequence in which the user stories will be delivered while meeting the expectations of the business stakeholders. Instead of creating a project plan, we should use a strategy tool that breaks down the user stories into epics, based on Lombardo et al.’s Now (features coming in the release plans), Next (what we should communicate in our Roadmaps), and Later (the long-term vision). This approach will help us prioritize what needs to be developed and communicated to stakeholders at different stages of the project.

While the outlined steps provide a general roadmap, the true essence lies not in the final artifact—the job board—but in the conversations that weave through its creation. This collaborative endeavor establishes a shared understanding within the team, a profound shift from solitary ideation to collective thinking.

Collaboration means shift from thinking big ideas alone and moving into the real-mess of thinking with others.

Van Der Meulen, M., Counterintuitivity: Making Meaningful Innovation (2019)

The act of thinking together, as emphasized by Van Der Meulen, bridges gaps and enables decisive action without constant reassessment. In embracing collaboration, we cultivate an environment where discussions are streamlined, paving the way for a more efficient and purposeful execution phase. Let the collective intelligence of your team propel your endeavors, turning abstract ideas into a tangible, shared understanding.

Call to Action

As you embark on the journey to integrate Jobs-to-be-Done (JTBD) into your product management practices, consider the following tips to kickstart implementation:

1. Define Product Clear Outcomes: Define a strategy aligned with your vision and establish success metrics early on. Begin by defining clear outcomes for your product or service. What are the fundamental goals customers aim to achieve through your offering? For example, if you’re developing a project management tool, a clear objective might be to help users streamline collaboration and improve project efficiency.
2. Pick Your Favorite JTBD Uncovering Method: Whether it’s Learning Through Sales Safaris for consumer products, the versatile Learning Through Customer Interviews, the in-depth exploration offered by Observing Behavior Through Contextual Inquiries, or the scalability provided by Analyzing Quantitative and Analytics Data, each method offers a unique perspective. Tailor your approach, selecting from this toolkit to gain precise insights into your customers’ jobs and inform your product strategy effectively. [Learn more about JTBD uncovering methods in Techniques for Uncovering Jobs].
3. Craft Job Stories: Transition from traditional user stories to Job Stories. Use the JTBD lens to articulate what users are trying to achieve. For example: instead of a user story like “As a user, I want to see all the posts of someone’s feed in their profile page quickly,” frame it as a Job Story: “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.”
4. Create Job Boards: Combine JTBD with User Story Mapping for a holistic approach to defining and prioritizing features. For example, create a Job Board that visually represents the user’s journey, ensuring that features align with their jobs to be done. This fosters collaboration among cross-functional teams.
5. Prioritize Based on Customer Outcomes: Prioritize features and enhancements based on their impact on customer outcomes. Consider how each element contributes to fulfilling the user’s job to be done. For example, in a banking app, prioritize features that directly contribute to customers efficiently managing their finances, aligning with the job of achieving financial control.

If you are wondering why you might never be able to apply this approach in your organization, I suggest trying the Scale What Works approach.

In another blog post, I mentioned that I’ve intuitively developed a model that I call Scale What Works and it has proven to be a potent strategy, especially when teams encounter challenges or stagnation. As I mentioned above, the approach leverages the concept of finding bright spots within an organization or industry to identify areas where teams are already successfully addressing similar problems:

• Notably, this approach stands out as a bottom-up strategy, empowering teams at the grassroots level to drive change. Unlike traditional top-down models, Scale What Works fosters a sense of ownership and involvement among the teams where the change will unfold.
• This inherent empowerment minimizes resistance to change, as it is not perceived as a mandate from the top, but rather a collaborative effort driven by those directly involved.
• The model, with its built-in mechanism for capturing both successes and failures, provides compelling evidence and valuable insights to mitigate skepticism often associated with trying new approaches.

In my role as VP of Design Strategy at SAP SuccessFactors, the adoption of best practices is crucial for driving product vision and ensuring a cohesive narrative across our suite. When confronted with challenges or the need for innovation, the first step is to apply the “find the bright spots” approach. I examine different areas within the organization or industry where teams are excelling, seeking inspiration and insights.

When bright spots are challenging to find, I tap into my supportive network and identify allies willing to experiment with new methods or frameworks. For instance, introducing the Jobs-to-be-Done (JTBD) framework at SAP SuccessFactors required collaboration with supportive allies — like Rebecca Reagan Thieme and Martina Willam — who were open to experimentation.

Here are a few suggestions for getting traction with JTBD by using the Scale What Works approach:

• Find Allies: identify stakeholders who might be willing to experiment with new methods.
• Pilot Projects: Initiate small pilot projects to test new methods and gather insights.
• Reflection in Action: Encourage teams to practice reflection in action during pilot projects, capturing real-time insights on what is working and what needs refinement.
• Iterative Improvement: Continuously refine and improve the adopted methods based on project outcomes.

Remember, the successful integration of JTBD requires a commitment to ongoing learning and iterative refinement. Embrace the methodology as a dynamic tool for understanding customer needs, and let it guide your product management practices towards customer-centric innovation.

Recommended Reading

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

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/

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

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.

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

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

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

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

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

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

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

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

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

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.

Stillman, D. (2020). Good Talk: How to Design Conversations That Matter. MGMT IMPACT PUB; 1st edition.

Todd, L. (2020). Adding a feature to Lyft: a UX case study. Retrieved 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.

Torres, T, Gurion, H., “Defining Product Outcomes: The 8 Most Common Mistakes You Should Avoid.” Product Talk (blog), December 21, 2022. https://www.producttalk.org/2022/12/defining-product-outcomes/

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

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