jobs-to-be-done
Jobs-to-be-Done
I help product teams understand demand from the customer's point of view — why they switch, what they're hiring a product to do, and what forces drive or block that decision. This is not about demographics or psychographics. It is about the causal mechanisms behind a purchase.
The Jobs-to-be-Done framework, as developed by Bob Moesta, starts with a deceptively simple question: when a customer switched to your product, what was happening in their life that made them say "today is the day"? The struggling moment. Everything else flows from that.
Essential Principles
Jobs Are About Progress, Not Tasks
A job is not a task someone performs. It is the progress a person is trying to make in a specific circumstance. When someone hires a milkshake for a morning commute, the job is not "consume calories" — it is "make this commute manageable and give me something to do with my hand." Understanding the job means understanding the life circumstances that created the need.
Demand-Side Thinking
Most product teams think supply-side: they start with a product and ask how to make it better or sell it to more people. Demand-side thinking starts with the customer and asks: what forces are acting on this person that caused them to make a switch? Supply-side thinking asks "what features do customers want?" Demand-side thinking asks "what was happening in their life when they decided to change?"
The Struggling Moment Is the Starting Point
Customers don't wake up wanting your product. They wake up with a problem they've been tolerating until something tips the balance. That tipping point — the struggling moment — is when the push of current frustration outweighs the combined drag of anxiety about change and the inertia of habit. Find the struggling moment and you find the causal mechanism of demand.
More from rohanpatriot/product-skills
continuous-discovery
Applies Teresa Torres's continuous discovery habits to help product teams discover products that create customer and business value. Use when setting product outcomes, interviewing customers, mapping opportunities, generating solutions, testing assumptions, or when user mentions Opportunity Solution Trees, product trios, assumption testing, or continuous interviewing.
11shape-up
Applies Ryan Singer's Shape Up methodology to help product teams ship meaningful work on a fixed cycle. Use when shaping raw ideas into pitches, setting appetite, running a betting table, tracking progress with hill charts, scope hammering, or when user mentions pitches, cool-down, building period, appetite, breadboards, fat marker sketches, betting table, hill charts, scopes, or cycle planning.
6story-mapping
Applies Jeff Patton's User Story Mapping to help teams build shared understanding, decompose work, and plan releases. Use when creating story maps, mapping user activities, writing user stories, slicing releases, planning walking skeletons, decomposing backlogs, breaking down features, facilitating discovery sessions, identifying MVPs, or when user mentions backbone, user journey mapping, release slicing, or flat backlog problems.
6