Chapter 6: Uncovering Outcomes / Unmet Needs

We are still in step two of the Outcome Driven Innovation (ODI) process. However, now that we have an understanding of the core functional job (chapter 4) and creating a job map (chapter 5), let's explore the next step which is uncovering the outcomes (unmet needs) within the job steps.

What is an Outcome?

In Jobs-to-be-Done theory and Outcome-Driven Innovation, the term "outcomes" is deliberately chosen over the more familiar "needs" to reflect important distinctions that make customer insights more actionable for innovation, Ulwick argues [31].

While needs often capture what customers think they lack or want in general terms, outcomes describe the specific, measurable end states customers are trying to achieve when executing a job.

The change in terminology reflects a more measurement-focused approach to understanding customer value. Where a customer might express a need as "I need faster service," the corresponding outcome would be structured as "Minimize the time it takes to complete the transaction." Ulwick argues this specificity matters for businesses trying to innovate and improve their offerings [31].

Outcomes follow a syntax that includes a direction of improvement plus metric plus object of control plus contextual clarifier, making them measurable and actionable for product development. The "faster service" need statement provides little guidance on what to measure or how to know if you've succeeded. In contrast, "minimize the time it takes to complete the transaction" gives teams a clear metric (time), a specific object to optimize (transaction completion), and a direction for improvement (minimize).

Unlike traditional needs statements, which can be vague, contaminated with solution ideas, or shifting based on current market context, outcomes remain stable over time and solution-agnostic. They focus on the fundamental job the customer is trying to accomplish rather than their perceptions of what might help them.

A Note on Terminology

Although from a theoretical perspective in Outcome-Driven Innovation we are supposed to call them "outcomes," for practical application in my day-to-day use of JTBD and ODI, I will refer to them as "needs."

The language of "needs" is much easier to communicate internally within organizations. Business stakeholders, product teams, and executives immediately understand what you mean when you talk about customer needs, whereas "outcomes" often require explanation and can feel overly academic or consultant-heavy. While the theoretical distinction between needs and outcomes is important for understanding the framework's rigor, the practical reality is that successful implementation depends on getting the whole team on board.

What matters most is not the specific terminology we use, but that we maintain the underlying principles of specificity, measurability, and solution-agnostic thinking. Whether we call them needs or outcomes, we're still looking for the same thing: measurable success criteria that customers use to evaluate job execution. Using familiar language simply removes barriers to adoption and allows teams to focus on the substance of the insights rather than getting caught up in definitional debates.

Syntax for JTBD Needs

The Syntax of Customer Needs

Customer needs in this framework follow a structure that ensures they are measurable, actionable, and solution-agnostic. This syntax consists of four components: direction of improvement, metric, object of control, and contextual clarifier.

The syntax for needs statements is typically: direction of improvement + metric (likelihood or time) + object of control + Contextual Clarifier (optional)

Direction of Improvement

The direction of improvement indicates whether customers want to minimize something. The reason to avoid using "maximize" is because it has an infinite endpoint. There is no clear endpoint to maximize. While "minimize" has a natural end point of 0.

Metric

The metric specifies what is being measured. Common metrics include time, likelihood, number of steps, amount of effort, frequency, accuracy, or quantity. The metric should be something that can be measured or counted. Avoid vague terms like "ease" or "convenience" and instead identify what makes something easy or convenient to measure.

Object of Control

The object of control identifies what element the customer wants to influence or optimize. This should describe an action, process, or need that the customer is trying to accomplish as part of their job. It typically uses action verbs like "complete," "identify," "verify," "obtain," or "determine."

Contextual Clarifier

The contextual clarifier provides additional specificity about when, where, or under what circumstances this need applies. This helps distinguish between similar needs that might occur at different points in the job or under different conditions.

How to uncover needs from job steps from user interviews.

Let's go back to our example from Chapter 5 with the core functional job, "Communicating information clearly to an audience for understanding" and the job map.

Imagine we have this transcript below from an interview with a participant. First I will highlight the interviewer's question, then the customer's response, and finally in italics will be the translated unmet need using the ODI need syntax.

Interview Transcript: Gathering Evidence for Communication

Interviewer: Tell me about the step where you gather evidence or supporting data for your presentation. What makes this step challenging or time-consuming?

Customer: "Well, the biggest issue is that I can spend hours just trying to find the right information. I'll search through different databases, reports, and sources, and sometimes I'm not even sure if what I'm finding is actually relevant to what I need to communicate. It's frustrating because I know the information exists somewhere, but tracking it down takes forever."

(Minimize the time it takes to find relevant supporting data for the specific topic being communicated)

Interviewer: What about the quality of the information you find? What makes you confident or uncertain about using it?

Customer: "That's another headache. I'll find something that looks perfect, but then I realize it's from three years ago and the numbers have probably changed. Or I'll find conflicting information from different sources and I have to figure out which one is actually correct. I've been burned before by using outdated statistics in a presentation."

(Minimize the likelihood of including outdated information in the final presentation)

Interviewer: How do you typically verify that your sources are credible and accurate?

Customer: "I usually try to cross-reference everything with at least two other sources, but that's so time-intensive. I'll spend almost as much time checking the information as I did finding it in the first place. Sometimes I wish there was a faster way to verify that what I'm looking at is legitimate and current."

(Reduce the effort required to verify information credibility from multiple sources)

Interviewer: What would make this evidence-gathering process more effective for you?

Customer: "If I could just trust that the information I'm finding is accurate without having to do all that verification work, that would be huge. And if I could somehow be sure I'm getting the most current data available, I wouldn't have to worry about looking foolish with outdated facts."

(Minimize the likelihood that the information collected contains inaccuracies)

Translating Customer Quotes into Proper Syntax

The translation process requires extracting the essence of what customers are trying to optimize from their descriptive language. When a customer says "I can spend hours just trying to find the right information," they're expressing frustration about time spent on an activity. The underlying need is about minimizing that time, so it becomes "Minimize the time it takes to find relevant supporting data."

Look for directional language in customer quotes. Words like "faster," "quicker," or "takes too long" indicate minimize statements around time. Phrases like "more accurate," "better quality," or "higher success rate" suggest maximize statements. When customers mention avoiding problems or preventing issues, this often translates to minimize likelihood statements.

Remove solution references and context-specific details while preserving the core metric. If a customer says "I hate having to check three different systems to verify the data is current," focus on the underlying need to reduce verification effort rather than the systems mentioned. This becomes "Reduce the effort required to verify information credibility from multiple sources."

The key is listening for what customers are actually trying to measure and optimize, then restructuring their language into the direction plus metric plus object plus context format that makes needs actionable for product development.

Interview Questions to Uncover Need Statements

Broad Exploratory Questions

Start with broad exploratory questions about each job step to uncover pain points and friction:

• What makes [step] challenging or frustrating? - Helps customers articulate their pain points in their own words
• What are the biggest obstacles to getting [step] done efficiently? - Reveals systemic barriers and bottlenecks
• What makes [step] time-consuming or slow? - Identifies speed and efficiency gaps
• What causes [step] to go off track or become problematic? - Uncovers failure modes and risk factors
• What parts of [step] require the most effort or attention? - Highlights resource-intensive areas
• What makes [step] unpredictable or inconsistent? - Reveals variability and reliability issues

Measurement and Comparison Questions

Focus on revealing the metrics customers actually care about:

• How do you measure success when trying to [step]? - Uncovers explicit success criteria
• What makes one approach better than another for [step]? - Reveals comparative evaluation criteria
• How do you know when [step] is done well versus poorly? - Identifies quality indicators
• What would 'perfect' look like for [step]? - Establishes ideal need benchmarks
• How do you currently track progress during [step]? - Reveals existing measurement behaviors

Need-Specific Probes

These questions directly target desired need and performance criteria:

• What needs to be minimized during [step]? - Identifies negative needs to reduce (time, errors, cost, risk)
• What needs to be maximized during [step]? - Identifies positive needs to increase (accuracy, speed, quality, confidence)
• What must be ensured or guaranteed during [step]? - Reveals critical success factors and non-negotiable requirements
• When [step] goes perfectly, what results do you see? - Captures ideal end-state descriptions
• What would make [step] feel effortless or automatic? - Identifies ease-of-use and friction reduction desires

Context and Constraint Questions

These help understand situational factors that influence needs:

• What information do you need to feel confident during [step]? - Reveals knowledge and visibility requirements
• What resources or tools are essential for [step] to work well? - Identifies enablement needs
• What external factors can make [step] more difficult? - Uncovers environmental constraints and dependencies
• When does [step] need to happen faster or slower? - Reveals timing and urgency considerations
• Who else is affected when [step] doesn't go well? - Identifies stakeholder impact and collaboration needs

Beyond the core job and needs

Now that we have an understanding of how to uncover the desired needs within the core functional job, let's expand them a bit. A customer's experience doesn't end with the core job. They exist within a network of needs and challenges that span multiple dimensions of their experience.

Customers often have to perform other jobs before, during, or after the main task, but they're also navigating various complexity factors like environmental constraints, psychological states, contextual pressures, and situational variables that influence how they approach their goals. Beyond the functional aspects, they're simultaneously managing financial considerations, personal emotional needs, and social dynamics that can affect their success.

Understanding these adjacent and underlying jobs can reveal entirely new areas for development or innovation opportunities. In the next sections, we will explore several types of these interconnected jobs including Related Jobs, Consumption Chain Jobs, Financial Jobs, and Personal/Social/Emotional Jobs, each offering unique opportunities to create more comprehensive and meaningful solutions.

While the core job provides the functional value of your product, emotional and social needs create the connection. A product that only solves the functional job is a tool. One that also addresses emotional needs becomes something people prefer. Customers may need your product because of what it does, but they will love your product because of how it makes them feel.

Emotional & Social needs

Teams frequently overlook emotional needs, even though they drive many purchase decisions. While functional needs describe what customers want to accomplish, emotional needs reveal how customers want to feel and be perceived throughout their journey. These needs operate on two distinct levels: personal emotional needs that focus on internal feelings and experiences, and social emotional needs that center on external perceptions and social positioning.

Emotional Needs

Emotional needs define the internal emotional states customers seek to achieve or avoid when getting their job done. These needs are tied to basic human drives for control, security, pleasure, esteem, freedom, belonging, and calm. A customer purchasing financial planning software, for instance, may have the personal emotional need to "feel confident when managing their financial future" or "avoid feeling anxious about retirement planning."

These emotional needs often manifest as underlying motivations that drive functional behavior. The customer who meticulously researches every product feature before making a purchase may be driven by the emotional need to feel secure and avoid regret. Understanding these personal emotional needs helps organizations recognize that customers aren't just buying products or services but they're seeking emotional needs that enhance their sense of well-being, competence, or fulfillment.

Social Needs

Social needs focus on how customers want to be perceived by others in their social and professional circles. These needs reflect our fundamental nature as social beings who care about reputation, status, belonging, and identity. They often cluster around themes of power and confidence, security and pride, impact and status, belonging and approval, or individuality and uniqueness.

A professional using collaboration software may want to "be perceived as an organized team leader by colleagues" or "avoid being perceived as technologically incompetent by peers." These social emotional needs can be just as powerful as functional requirements in driving purchase decisions and product adoption. They help explain why customers sometimes choose solutions that may be functionally adequate but excel at supporting their desired social positioning.

Emotional & Social Needs Syntax and Structure

Emotional and Social needs follow a similar syntax structure to need statements. Each statement begins with a verb that indicates whether the need is personal or social, positive or negative. For personal emotional needs, use "Feel" for positive emotions you want to achieve or "Avoid feeling" for negative emotions you want to prevent. For social emotional needs, use "Be perceived as" for positive perceptions you want to create or "Avoid being perceived as" for negative perceptions you want to prevent.

After the verb comes the emotional state or persona. This should be specific and meaningful rather than generic. Instead of just "good" or "bad," use precise emotional descriptors like "confident," "secure," "respected," "competent," or "innovative."

Finally, add a contextual clarifier that specifies when, where, or in what situation this emotional need applies. This might include phrases like "when presenting to executives," "in front of family members," or "during financial planning sessions."

For example, properly structured emotional needs might read "Feel confident when presenting ideas to senior leadership," "Avoid feeling overwhelmed when managing multiple projects," "Be perceived as a tech-savvy professional by colleagues," or "Avoid being perceived as irresponsible by family members when making financial decisions."

Questions for Identifying Emotional and Social Needs

Below are some questions to help identify personal emotional and social emotional needs

Personal Emotional Needs

• How do you want to feel when doing this job? - Captures desired positive emotional states
• What feelings do you want to avoid when trying to accomplish this task? - Identifies emotional pain points to eliminate
• If you had the ideal solution for this situation, how would that make you feel? - Reveals aspirational emotional needs
• What negative emotions would be eliminated if you could solve this perfectly? - Uncovers emotional friction points
• What gives you confidence when working on [step]? - Identifies confidence-building factors
• What makes you feel stressed or anxious about [step]? - Reveals emotional barriers and triggers
• When [step] goes well, what positive feelings do you experience? - Captures emotional rewards and satisfaction drivers
• What would make you feel more in control during [step]? - Identifies autonomy and empowerment needs

Social Emotional Needs

• When trying to accomplish this job, how do you want to be perceived by others such as peers, clients, family, or friends? - Reveals desired social image
• How do you want to avoid being perceived by people who matter to you? - Identifies social fears and image risks
• If you had the perfect solution for this challenge, how would others view you? - Captures aspirational social needs
• What social concerns or embarrassment would be avoided? - Uncovers social anxiety and reputation protection needs
• What would make you feel respected or valued by your colleagues during [step]? - Identifies professional recognition needs
• What social situations make [step] more stressful or uncomfortable? - Reveals interpersonal friction points
• How important is it that others see you as competent at [step]? - Measures social validation priorities
• What would prevent you from feeling judged or criticized when doing [step]? - Identifies social safety and acceptance needs

Practical Tips for Success

When identifying emotional or social needs, aim for completeness with typically 10 to 20 distinct emotional / social needs per core job. Avoid redundancy by ensuring each emotional need captures a unique aspect rather than repeating the same concept with different words. Keep emotional needs solution-agnostic, meaning they should not reference technologies, products, or services but focus on the underlying emotional need desired.

Maintain consistency in abstraction level across all emotional needs:

• Some should not be highly specific while others remain overly broad
• Each emotional need should stand alone and not blend functional requirements with emotional needs
• Focus purely on the feeling or perception without describing processes or functional steps

Remember that emotional and social needs are tied directly to the job-to-be-done rather than existing as separate concerns. They represent the emotional dimension of getting the job done rather than unrelated emotional desires.

Emotional and social needs also provide insights into market segmentation opportunities:

• Different customer segments may share similar functional requirements while having distinctly different emotional needs
• Understanding these emotional variations enables more targeted and resonant customer approaches
• This acknowledges the full complexity of human motivation in the marketplace

Related Jobs

Related jobs represent functional tasks that customers must accomplish alongside their core job. While theoretically sound within the Jobs-to-be-Done framework, their practical value lies primarily in identifying market expansion opportunities rather than comprehensively mapping every customer activity.

The Trap: Job Step vs. Related Job

The primary frustration with related jobs is the tendency to fragment what should be understood as a unified customer journey. Teams often mistake integral steps of the core job for separate related jobs. This leads to disjointed product roadmaps and a failure to see the whole picture.

When analyzing the job "purchase products online," activities like verifying order details or tracking shipment status are not separate jobs. They are essential execution steps of the purchasing process. A thorough job map (Chapter 5) naturally captures these activities and their associated outcomes.

Identifying True Adjacent Opportunities

Valuable related jobs represent genuinely separate functional objectives. These are tasks that happen before, after, or in parallel to the core job, but point toward distinct market opportunities.

To determine if something is a Related Job or a Step, apply the "Independence Test":

• The Job Step: Must happen to complete the core job successfully. If you remove it, the core job fails.
• The Related Job: Can be performed independently, at a different time, or by a completely different vendor, without breaking the core job.

Examples: Distinguishing Steps from Related Jobs

The Market Expansion Lens

Related jobs deliver the most value when they reveal opportunities to serve customers in adjacent markets. Rather than creating exhaustive lists of supporting activities, focus on identifying related jobs that represent entirely new value propositions.

For example, a music streaming service that masters the core job of "listening to music" might look at the related job of "discovering new artists." This leads to social recommendation features or concert integration—features that expand the product's scope beyond simple streaming. This is real growth rather than just tweaking features.

A Practical Approach

Since a well-constructed job map already captures the complete customer journey, you don't need to stress over taxonomical completeness for related jobs. Use related jobs as a strategic growth tool, not a definition tool.

In my experience, teams rarely need to map related jobs during the initial core product definition. Instead, return to related jobs when you are looking for growth strategies. Ask: "Once our customer gets the core job done perfectly, what are they trying to accomplish next?" That is where your adjacent market opportunities lie.

---

Key Changes Made:

1. The "Independence Test": I added a clear heuristic (can it be done separately?) so readers can self-diagnose.
2. The Comparison Table: I replaced the paragraph examples with a small table (or list structure) that contrasts "Steps" vs. "Related Jobs" side-by-side. This is much higher value for a practitioner.
3. Refined the "Trap": I sharpened the language around the "annoyance" to frame it as a common pitfall ("The Trap"), which is more instructional.
4. Strategic Framing: The conclusion now frames Related Jobs as a "Strategic Growth Tool," giving the reader permission to ignore them during the initial "fix the core product" phase.

A Practical Approach

Since well constructed job maps already capture the complete customer journey, teams can identify adjacent market opportunities by examining the broader context around their core functional job without getting bogged down in related job categorization. The goal is market expansion insight, not taxonomical completeness.

This approach aligns with our focus on actionable customer understanding rather than theoretical framework adherence. Related jobs matter when they open new markets, not when they subdivide existing customer journeys.

In my own experience, teams rarely have explored related jobs. If they do, it's more about looking at adjacent opportunities from a core functional job and job mapping flight level.

Consumption Chain Jobs

Think of consumption chain jobs as the "work" a customer has to do to make a product or service effective for their core job. Unlike core jobs or needs, which are solution-agnostic, consumption chain jobs are tied to a specific solution (e.g., "monitor blood glucose levels using a particular meter"). They cover every interaction a customer has with a product or service from the moment they consider it to the moment they discard it.

The syntax for a consumption chain job is typically: Verb + Object of the Verb (product/service) + Contextual Clarifier (optional)

Examples:

• Purchase medical supplies for the BG meter when traveling abroad.

• Maintain the car.

• Clean the washing machine.

Why are Consumption Chain Jobs Important?

These jobs offer insights into potential pain points and opportunities for differentiation within the product, maintenance of the product, or on-going support of a product or service. By understanding the entire journey, companies can:

Identify Consumption Chain Needs: Customers often tolerate inefficiencies or frustrations in their consumption chain without realizing there could be a better way. Uncovering these allows companies to design solutions that simplify, streamline, or eliminate these tasks.

Enhance Customer Experience: A product might perfectly fulfill its core function, but if it's difficult to set up, clean, or repair, the overall customer experience suffers. Addressing consumption chain jobs leads to happier, more loyal customers.

Create New Service Offerings: Often, consumption chain jobs can be spun off into new services. For example, a company selling complex machinery might offer installation, maintenance, or repair services.

Consumption Chain Examples Across Industries:

Consumption chain jobs are universal, though their specifics vary greatly.

Automotive Industry (Product: Car)

• Purchase the car with financing options. -Install a child safety seat in the back. -Learn to use the car's infotainment system. -Clean the car's interior after a road trip. -Monitor the car's tire pressure regularly.
• Maintain the car's engine according to the manufacturer's schedule.
• Repair the car's body after a minor fender bender.
• Dispose of the old car when upgrading to a new model.

Software Industry (Service: Project Management Software)

• Select the project management software based on team size.
• Confirm the subscription plan for annual billing.
• Initiate the service for new team members.
• Receive technical support when encountering an error.
• Pay for the service monthly via credit card.
• Monitor the delivery of new features via email updates.
• Modify the service settings to fit project requirements.
• Resolve integration problems with existing tools.
• Comply with data privacy requirements for sensitive project information.
• Conclude the service at the end of a project cycle.

Consumption Chain Things to Watch Out For:

• Specificity is Key: Avoid vague statements. "Maintain the car" is vague, but "Maintain the car's oil level before long trips" is even better. The more specific, the clearer the problem and potential solution.

• Focus on the "Job," Not the "Solution": While consumption chain jobs are product-related, the goal is still to understand the task the customer is trying to accomplish, not just how they interact with the current product. For example, "Purchase medical supplies" is better than "Buy our specific brand of medical supplies."

• Customer's Perspective: Always frame consumption chain jobs from the customer's point of view, using their language.

• Completeness (20-30 statements): Aim for a comprehensive list. Often, companies overlook key steps because they are so routine. A thorough exercise typically uncovers 20-30 distinct consumption chain jobs.

• Distinguish Between Products and Services: While many generic consumption chain jobs overlap, some steps are unique to physical products (e.g., Install, Transport, Dispose) or services (e.g., Select Service, Comply with Requirements, Conclude).

Questions to help uncover consumption chain jobs

To identify these jobs, ask questions like:

• What products/services are you using when trying to get your core job done?

• What tasks do you have to complete when getting the product/service (order, purchase, install, etc.)?

• What tasks do you have to accomplish during the usage of the product/service (maintain, update, clean, etc.)?

• What tasks do you have when discontinuing to use of a product/service (dispose, cancel, etc.)?

Financial Needs

When a customer decides to buy a product or service, they aren't just thinking about the task they need to accomplish. They are also making an economic decision. Financial needs are the economic and financial needs customers want to achieve when getting their core job done. They represent the customer's desire for efficiency, cost-effectiveness, and value.

Financial Needs Syntax and Structure

Similar to the rest of the syntax of other needs, financial needs follow a straight forward syntax.

Direction of Improvement + Metric + Object of Control + Contextual Clarifier (optional)

Metric The metric in financial needs specifies the economic or financial unit being measured. Common financial metrics include:

• Costs of - Direct monetary expenses (purchase costs, operating costs, maintenance costs).
• Risk of - Financial exposure to loss or variance (risk of going over budget, risk of penalties, risk of asset depreciation).
• Amount of - Quantities that have direct financial implications (amount of waste, amount of rework, amount of inventory).
• Frequency of - How often costly events occur (frequency of paid repairs, frequency of purchasing replacement parts).
• Downtime of - Time-based losses with economic impact (downtime of revenue-generating equipment).
• Time to - Duration metrics with cost implications (time to payback, time to break-even).
• Likelihood of - Reserved strictly for binary financial events (likelihood of incurring a late fee, likelihood of triggering a tax audit).

Object of Control The object of control identifies the source or driver of costs and economic inefficiencies in the job. This pinpoints what element causes financial impact:

• Purchase-related: costs of acquisition, financing, procurement processes
• Operational: costs of training, implementation, integration, maintenance
• Lifecycle: costs of storing, transporting, installing, upgrading, disposing
• Financial Exposure: risk of cost overruns, risk of non-compliance penalties, risk of budget variance
• Process inefficiencies: amount of rework, waste generation, manual intervention
• Resource utilization: downtime of personnel, underutilization of assets

Contextual Clarifier The contextual clarifier specifies the circumstances, conditions, or scope under which these financial impacts occur:

• When: during peak seasons, at project start-up, over the product lifecycle
• Where: in particular locations, departments, or operational environments
• For what purpose: when scaling operations, during emergencies, for compliance requirements
• To what end: to meet regulatory standards, to achieve growth targets, to maintain competitiveness
• Under what conditions: with limited resources, during high-demand periods, in uncertain market conditions

Financial Needs Examples Across Industries

Financial needs are universal, but the needs vary depending on the context. Notice how we focus on the cost or risk of the error, rather than the functional error itself.

B2B Software (CRM Platform)

• Minimize the cost of onboarding a new salesperson.
• Minimize the cost of rework caused by data entry errors.
• Minimize the cost of generating a quarterly sales report.

Healthcare (Surgical Device)

• Minimize the cost of disposables required for each procedure.
• Minimize the financial loss associated with patient readmissions.
• Minimize the cost of sterilization downtime between procedures.

Consumer Goods (Washing Machine)

• Minimize the cost of electricity and water consumed per laundry cycle.
• Minimize the frequency of paid repairs needed over the product's lifespan.
• Minimize the amount of detergent wasted due to inefficient dispensing.

Financial Needs Things to Watch Out For

1. Consistency: For clarity and ease of comparison, always use "minimize" as the direction of improvement. This creates a clear, measurable goal (the optimum is zero) and makes it simple to analyze a list of financial needs.
2. Identify the Real Buyer: The person using the product (the job executor) may not be the one making the purchase decision. A doctor might use a medical device, but a hospital administrator approves the purchase based on a different set of financial needs. You need to understand the key needs for the purchase decision maker.
3. Go Beyond Price: The most powerful financial needs are often related to the costs of usage, maintenance, and the consequences of inefficiency—not just the initial sticker price.
4. Aim for 15-20 Statements: A thorough investigation should yield a complete set of 15-20 financial metric statements, covering the full economic picture of getting the job done.

Interview Questions to Uncover Financial Needs

Here are additional questions to help identify financial needs:

Cost Discovery Questions:

• What are the hidden or unexpected costs that emerge when getting this job done?
• Which aspects of getting this job done consume the most budget or resources?
• What costs do you incur when things go wrong or need to be redone?
• What are the opportunity costs of the time and resources spent on this job?

Risk and Loss Questions:

• What financial risks do you face if this job isn't done properly or on time?
• What does it cost you when delays occur in getting this job done?
• How much do errors or mistakes in this job typically cost to fix?
• What revenue or savings opportunities do you miss when this job takes too long?

Resource and Investment Questions:

• What's the total cost of ownership for your current approach to this job?
• How much do you invest in training people to get this job done effectively?
• What does it cost to scale up when demand for this job increases?
• How much do you spend on tools, systems, or infrastructure to support this job?

Efficiency and Waste Questions:

• Where do you see the most waste or inefficiency in getting this job done?
• What redundant activities or processes add unnecessary costs?
• How much do compliance or regulatory requirements add to the cost?
• What would eliminating bottlenecks in this process be worth to you?

Comparison and Benchmark Questions:

• How do your costs for this job compare to industry benchmarks?
• What would a 10% reduction in costs for this job mean to your bottom line?
• If you could eliminate one cost category entirely, which would have the biggest impact? Based on your existing content, here are the revised sections:

Complexity Factors

When customers attempt to get a job done, their experiences vary based on their circumstances. Some customers complete the job effortlessly, while others encounter obstacles and frustration along the way.

These varying levels of difficulty stem from what ODI calls complexity factors. Complexity factors are the characteristics of the job executor, their environment, or their situation that create barriers to successful job completion.

Identifying and understanding these complexity factors serves three purposes. First, they provide the foundation for effective needs-based segmentation by revealing why different customer groups struggle with different aspects of the same job. For instance, if your research reveals that "time pressure" is a situational complexity factor, your quantitative survey might show that customers who frequently execute the job under tight deadlines prioritize speed-related outcomes far more than customers with flexible timelines. These patterns become the raw material for identifying distinct segments in Chapter 9.

Second, they highlight the root causes behind customer struggle, enabling teams to design solutions that address the real barriers preventing job completion rather than just surface-level symptoms.

Third, complexity factors serve as profiling and screening variables for your segments. After statistical analysis identifies needs-based segments, complexity factors help explain why those segments have different priorities. Some complexity factors also become survey questions that help you identify which segment a customer belongs to for targeting purposes.

3 Categories of Complexity Factors

Complexity factors fall into three distinct categories, each creating different types of barriers to job completion and requiring different solution approaches.

Person-Related Complexity Factors encompass the characteristics of both the primary job executor and other stakeholders involved in the process. For the main executor, these include their skills, knowledge, experience level, attitudes, physical capabilities, and how frequently they perform this job. Additionally, the characteristics of other people involved such as clients, patients, or assisting personnel can make the job harder. A novice executor working with experienced stakeholders faces different challenges than an expert working with uninformed participants.

Situational Context Complexity Factors represent the immediate, variable circumstances surrounding a specific job execution instance. These include the physical environment, available space, weather conditions, social dynamics, time pressures, stress levels, and whether the executor is multitasking or traveling. In healthcare, this might mean the difference between a routine visit and an emergency situation, specific patient conditions, or which staff members are available that day. Situational factors create variable complexity because they change from one job execution to another, making the same job easy in some circumstances and difficult in others.

Systemic Contextual Factors represent the persistent structural realities that consistently shape how jobs must be executed across all instances. These include regulatory frameworks, industry standards, organizational policies, technological infrastructure, economic systems, and cultural norms. In healthcare, examples include insurance approval processes, HIPAA compliance requirements, and hospital IT systems that affect every job execution. Unlike situational factors, systemic factors create persistent complexity that remains constant across job executions, though different executors may be better equipped to navigate these structural barriers based on their resources, experience, or position within the system.

The key distinction between situational and systemic factors is persistence and variability. Systemic factors remain constant across job executions for all users in that domain, while situational factors change from instance to instance. Systemic complexity often requires ecosystem-level solutions, partnerships, or tools that help users navigate persistent barriers, while situational complexity might be addressed through tactical activities like improved interfaces or flexible workflows.

Understanding this three-tier distinction helps teams identify whether customer struggles stem from personal limitations, temporary circumstances, or structural barriers.

Mapping Systemic Complexity Factors to the Job Map

Referring back to our discussion of complexity factors in chapters 4 and 5, this concept has implications for how teams approach their foundational jobs-to-be-done research. Teams should use complexity factor analysis as a pre-research filter to avoid investing time and resources in areas that may be fundamentally constrained by systemic barriers.

Pre-Research Assessment

Before conducting any customer interviews or quantitative research, teams should create a hypothesized job map of their core job and analyze each step for potential systemic complexity factors. This involves identifying job steps where:

• Solutions already exist but operate in heavily regulated environments
• Your product could fulfill the job step effectively, but systemic factors prevent market entry or adoption
• Regulatory requirements, industry standards, or entrenched infrastructure create persistent barriers across all job executions

Illustrative Examples:

In healthcare, consider the job "Monitor patient health remotely." A team might identify the step "Transmit patient data" and realize that while their IoT device technically solves this need, HIPAA compliance, FDA device approval requirements, and hospital IT integration standards create systemic barriers that could take years and millions of dollars to navigate.

In financial services, the job "Transfer money internationally" includes the step "Verify transaction compliance." A fintech startup might build superior technology for this, but anti-money laundering regulations, banking partnership requirements, and international regulatory frameworks create systemic complexity that established players like Swift or traditional banks are better positioned to handle. Coinbase exemplifies this challenge perfectly. They've built technology that could potentially transform cross-border transfers through cryptocurrency (faster, cheaper, more transparent), but face persistent systemic barriers including regulatory uncertainty in the US, hesitant banking partnerships, varying AML/KYC compliance frameworks across jurisdictions, and shifting government stances on crypto.

Decision Point

Once teams complete this analysis, they can have an informed strategic discussion about whether to:

• Proceed knowing the systemic challenges
• Pivot to adjacent job areas
• Reframe the core job to focus on areas where systemic factors are less constraining

This pre-research assessment prevents teams from discovering fundamental market barriers only after investing heavily in customer research, ensuring that foundational jobs-to-be-done exploration aligns with realistic go-to-market possibilities.

Identifying Complexity Factors

After the pre-research assessment, teams need systematic approaches to uncover complexity factors that may not be immediately obvious. Different research methods reveal different types of complexity.

Interview Techniques for Uncovering Complexity

Customer interviews excel at revealing person-related and situational complexity factors, but teams must probe beyond surface-level responses. When customers describe job execution, they often normalize their struggles or assume certain difficulties are universal. Effective complexity factor discovery requires specific questioning techniques.

Start with broad process mapping, then drill into moments of friction. Use these contrast questions to surface hidden complexity:

• "How was that different from the time before?" reveals situational variability
• "What would make this step much easier or much harder?" uncovers potential complexity drivers
• "Walk me through your worst experience doing this" exposes multiple complexity factors intersecting

Pay attention to workarounds and compensating behaviors. When customers mention "I usually..." or "I make sure to..." they're often revealing complexity factors they've learned to navigate. A project manager saying "I always schedule an extra 30 minutes for client calls" might be compensating for systemic factors like unreliable video conferencing or situational factors like client preparation levels.

As you uncover complexity factors, document them in a format that can translate into quantitative screening or segmentation questions. For each factor, note the observable or self-reported characteristic, how it appears to affect job execution difficulty, and which outcomes seem most impacted. This documentation will become valuable when you design your quantitative survey in Chapter 7 and analyze segments in Chapter 9.

Secondary Research for Systemic Complexity

While interviews reveal personal and situational complexity, systemic factors often require broader industry research. Look for systemic complexity indicators in:

• Regulatory databases and compliance guides that reveal mandatory process steps
• Industry reports discussing persistent pain points across organizations
• Professional association publications about navigating standards or requirements
• Competitive analysis showing where established players maintain advantages despite inferior technology

Trade publications and industry forums frequently discuss persistent pain points that signal systemic complexity.

Complexity Factors Things to Watch Out For

1. Customers Aren't Always Aware: People often can't articulate why something is difficult; they just know that it is. You have to act like a detective, observing their situation and connecting the dots between interviews.

2. They Are Not Demographics: A demographic like "senior citizen" is not a complexity factor. The underlying factor might be "declining eyesight" or "limited mobility." Focus on the functional challenge, not the demographic label. This distinction becomes vital in Chapter 9. Needs-based segments are defined by what people are trying to accomplish, not who they are demographically. Complexity factors help you understand the functional reality behind surface-level descriptors.

3. Build and Test Hypotheses: You will rarely be told a complexity factor directly. Listen for clues, form a hypothesis (e.g., "I think job execution is harder for people with an irregular income"), and then look for evidence to support or refute it in subsequent customer interviews.

4. Expertise Trap: Experienced job executors often provide misleading complexity factor data because they've internalized workarounds. An experienced professional saying "it's straightforward once you know the system" may be masking complexity factors that affect newer executors or different contexts. Always balance expert interviews with novice perspectives.

What Comes Next: From Inventory to Quantification

At this point, you've built a comprehensive inventory of customer needs. You have desired outcomes from each job step, emotional and social needs, financial considerations, complexity factors, and consumption chain jobs. This is the qualitative foundation: a solution-agnostic picture of everything customers are trying to accomplish and the barriers standing in their way.

But a list of 50, 80, or even 125 needs doesn't tell you where to focus. Not all needs are created equal. Some represent real opportunities for differentiation; others are table stakes that every competitor already addresses well. The question shifts from "What do customers need?" to "Which needs matter most, and which are currently underserved?"

This is where quantification comes in. The next chapter examines how to measure and prioritize this inventory so you can make confident decisions about where to invest. We'll start with the traditional ODI approach: a dual importance-and-satisfaction survey that has become the standard in the field. But we'll also examine its limitations. The surveys are long. The scoring algorithm has statistical problems. And the practical constraints often make it difficult to execute well.

Understanding both the promise and the problems with traditional quantification will prepare you to evaluate the alternatives in Chapter 8, which maintain the goal of clear prioritization while addressing the methodological shortcomings that can lead teams astray.

Chapter Six Summary

• Needs are Measurable Needs: We defined "desired needs" as the specific, measurable end-states customers are trying to achieve. For practical communication with internal teams, it's effective to use the more familiar term "customer needs" while retaining the ODI syntax.

• The ODI Syntax: A well-formed need statement follows a precise syntax: Direction of Improvement + Metric + Object of Control + Contextual Clarifier. This structure ensures every need is measurable, actionable, and solution-agnostic.

• Translating What Users Say into Need Statements: The core skill is listening to customer interviews and translating their descriptions of challenges, delays, and frustrations into the formal need syntax.

  • Here is a link to an interview guide with all the key questions to ask during a JTBD and ODI Interview.

• Innovation Exists Beyond the Core Job: To create holistic solutions, you must look beyond the primary task and uncover interconnected needs, including:

  • Emotional Needs: How customers want to feel (personal) and be perceived (social) when performing the job.
  • Consumption Chain Jobs: The work customers must do to purchase, set up, use, maintain, and dispose of a product or service.
  • Financial Needs: The economic efficiencies customers want to achieve, such as minimizing costs, waste, or the risk of financial loss.

• Complexity Factors Reveal the "Why": Understanding why a job is difficult is key to segmentation. We identified three types of barriers:

  • Person-Related: The executor's skills, experience, or physical capabilities.
  • Situational Context: The variable environment, time pressures, or location.
  • Systemic Context: The persistent rules, regulations, or infrastructure that affect everyone.

• Complexity Factors Enable Segmentation: The complexity factors you document in this chapter will be used in Chapter 9 to both profile your needs-based segments and create screening questions for targeting. As you identify complexity factors, document the observable characteristic, how it affects job difficulty, and which outcomes it impacts most.

• The Goal is a Comprehensive Inventory: The purpose of this chapter is to equip you with the methods to generate a complete list of all the different needs and jobs a customer is trying to manage. This inventory of needs can now be quantified. This is what we will learn in the next chapter.

Chapter 6 Resources

• JTBD & ODI Interview Guide

Chapter Six Exercises

Linked here is a transcript of an interview with a graphic designer on the core job of invoicing and cash flow. Read through the interview transcript and see what different needs, emotional jobs, complexity factors, and consumption chain jobs you derive from the transcript.

References

[28] Ulwick, A. W. (2016). Jobs to Be Done: Theory to Practice. Paperback, October 28, 2016. Retrieved from https://www.amazon.com/Jobs-be-Done-Theory-Practice/dp/B0CCZV8JJH/

[31] Ulwick, Tony. “Defining Customer Needs: The Root of the Problem.” AnthonyUlwick.com, 7 Jan. 2017. Available at: https://anthonyulwick.com/2017/01/07/defining-customer-needs-root-problem/