Product teams often find themselves building features that customers requested but rarely use. The disconnect stems from a fundamental misunderstanding: treating customer feedback as a shopping list rather than symptoms of deeper needs. The Jobs-to-Be-Done framework offers an alternative approach, one that looks beyond stated desires to uncover the underlying motivations driving every purchase decision.
What is the Jobs-to-Be-Done Framework?
Imagine product development as detective work. Your customers leave clues about what they need, but those clues rarely tell the complete story. The Jobs-to-Be-Done framework teaches teams to investigate these clues more thoroughly, treating every product purchase as a hiring decision where customers select solutions to accomplish specific objectives in their lives.
This perspective transforms how teams interpret customer behavior. Rather than cataloging feature requests, product managers learn to identify the circumstances that push someone toward making a purchase. What situation prompted this need? What alternatives did they consider? What tradeoffs were they willing to accept? The answers reveal patterns that traditional market research frequently overlooks.
The framework distinguishes itself by recognizing that customers rarely think in terms of product categories or features. They think in terms of progress—moving from their current unsatisfactory state to a better one. Your product is simply the vehicle they’ve chosen for that journey. Understanding the destination matters far more than obsessing over the vehicle’s specifications.
How Does the Jobs-to-be-Done Theory Apply to Product Development?
Traditional approaches to building products often create a dangerous illusion of customer understanding. Teams conduct surveys, run focus groups, and compile extensive lists of desired capabilities. Yet these methods capture only the most superficial layer of customer thinking—the part customers can easily articulate.
Jobs-to-Be-Done operates differently. It assumes that customers often can’t fully explain their own motivations, not because they’re uninformed, but because human decision-making involves complex emotional, social, and functional dimensions that resist simple explanation.
Take someone shopping for a meal kit delivery service. On the surface, they might say they want convenient recipes with pre-measured ingredients. Dig deeper, and you discover they’re actually trying to reduce weeknight stress while maintaining their identity as someone who cooks “real food” rather than ordering takeout. Even deeper still, you might find they’re navigating relationship dynamics—perhaps trying to spend quality time with a partner in the kitchen, or proving to themselves they can maintain work-life balance.
These layered motivations create opportunities for differentiation that feature-focused thinking misses entirely. A competitor might match your ingredients and recipes, but they can’t easily replicate an experience designed around emotional progress and social identity.
The practical application involves reorienting your entire product conversation. Instead of asking “What features should we add?” teams learn to ask “What progress are our customers trying to make?” This shift influences everything from roadmap prioritization to marketing messaging to customer support interactions.
What is the Origin of the Jobs-to-Be-Done Framework?
Every influential framework has a creation story, and Jobs-to-Be-Done emerged from Tony Ulwick’s recognition that traditional innovation approaches were fundamentally backward. Through his firm Strategyn, Ulwick developed what he initially called Outcome Driven Innovation—a systematic method for identifying the results customers wanted to achieve rather than the products they claimed to want.
The timing matters. Ulwick began refining these ideas in 1991, an era when most companies still viewed market research as straightforward: ask customers what they want, then build it. This seemed logical, but it produced disappointing results. Products failed despite checking every box on customer wish lists. Competitors with “inferior” feature sets somehow captured market share.
Ulwick’s insight was recognizing that customers don’t want products—they want outcomes. This distinction might sound academic, but it has profound practical implications. When you organize your innovation process around outcomes rather than product concepts, you discover opportunities that traditional approaches systematically miss.
The framework’s credibility rests partly on its track record. Strategyn’s client work across hundreds of companies has demonstrated remarkably consistent success—around 86% of initiatives achieve their objectives. Those results suggest the framework captures something genuine about how markets actually work, not just how we wish they worked.
What are Pros and Cons of JTBD?
Pros of jobs-to-be-done
Escaping the feature trap
Most product teams accumulate features the way attics accumulate junk—gradually, without much strategy, until the clutter becomes overwhelming. Jobs-to-Be-Done provides an organizing principle that cuts through this chaos. Every feature gets evaluated against a simple question: does this help customers make progress on their job? Capabilities that seemed obviously necessary suddenly become questionable. Features you hadn’t considered become priorities. The framework doesn’t just help you build better products; it helps you build simpler, more focused products.
Accessing unarticulated needs
Customers are terrible at predicting what they’ll want in the future. They describe improvements to existing solutions because that’s all they know. Ford’s apocryphal faster horse perfectly captures this limitation. Customers knew they wanted better transportation, but they could only conceptualize it within their existing framework of horses. Jobs-to-Be-Done gives teams a method for looking past these articulated requests to the underlying needs. What job was the horse performing? Personal mobility across distances. Once you frame it that way, entirely different solutions become possible.
Cons of jobs-to-be-done
Abstraction without action
The framework’s greatest strength can become its greatest weakness. Uncovering deep customer motivations is intellectually satisfying, but those insights don’t automatically translate into product decisions. You might spend considerable time determining that your customers are hiring your product to feel more competent in their professional roles, but then what? How does that abstract understanding inform whether you should invest in automation features or collaboration tools next quarter? Without disciplined translation from insight to action, teams can find themselves with fascinating anthropological understanding but no clearer roadmap.
Design and experience gaps
When you become hyper-focused on job completion, everything else can fade into the background. A product might successfully accomplish the customer’s job while being unpleasant to use, aesthetically unappealing, or just generally uninspiring. Think of enterprise software that technically solves business problems but makes users feel slightly depressed every time they open it. The framework doesn’t naturally guard against this outcome because it centers functional progress over experiential quality. Teams must consciously balance job-focused thinking with attention to craft, delight, and emotional resonance.
Implementing this framework successfully requires navigating these tensions thoughtfully. The insights it generates are valuable, but they demand interpretation, translation, and integration with other product development considerations. Teams that treat it as a complete methodology often stumble; those that use it as one lens among several tend to extract its benefits while avoiding its pitfalls.
Is Jobs-to-be-Done Worth a Try for Any Product Team?
Every product exists because someone believes it will help them achieve something meaningful. This obvious truth gets obscured in the daily chaos of sprint planning, bug triage, and competitive analysis. Jobs-to-Be-Done simply provides a structured way to keep that truth central to your decision-making.
The framework doesn’t require abandoning other tools in your product management toolkit. Teams practicing agile development, design thinking, or lean startup methodologies can incorporate jobs thinking without overhauling their entire process. It works as a complementary perspective that enriches customer understanding and surfaces opportunities that other frameworks might miss.
Perhaps the most compelling argument for trying this approach is recognizing what happens without it. Products become feature museums—impressive collections that nobody visits. Roadmaps reflect internal politics or competitor moves rather than genuine customer needs. Innovation becomes incremental improvement rather than meaningful progress. Jobs-to-Be-Done offers a path out of these traps, one that starts with a deceptively simple question: what job did your customer wake up trying to accomplish today?
Conclusion
The Jobs-to-Be-Done framework asks product teams to become better listeners, not just to what customers say, but to what their choices reveal about deeper motivations. It’s a demanding approach, one that resists easy application and can lead teams astray when applied mechanically. Yet for organizations willing to look beneath surface-level requests and grapple with the messy reality of human motivation, it unlocks a level of customer understanding that transforms how products get built. The choice isn’t whether to adopt it dogmatically, but whether to let its central insight—that customers hire products to make progress in their lives—reshape how you think about innovation itself.
