Jobs-to-Be-Done (JTBD) Framework

The JTBD framework, developed by Clayton Christensen and popularized in SaaS by Bob Moesta, proposes that customers don't buy products — they hire them to make progress in a specific situation. The classic illustration: a hardware store doesn't sell drill bits; it sells 1/4-inch holes. And people don't want 1/4-inch holes — they want to hang a picture. And they don't just want to hang a picture — they want to feel proud of their home. This layering of functional, emotional, and social dimensions of every job reveals that product decisions focused solely on feature function miss the emotional and social drivers that most powerfully influence customer behavior and loyalty. Applied to SaaS: customers don't "use a CRM" — they hire it to "feel in control of my sales pipeline and confident going into a forecast meeting."

Product Ops integrates JTBD by training PMs to use JTBD interview techniques in user research. A JTBD interview focuses on the customer's switching story — the moments leading up to them seeking a new solution, the specific event that triggered the search ("the push"), what they imagined the new solution would give them ("the pull"), and what almost stopped them from switching ("anxieties"). This timeline of events reveals: the specific context in which customers experience the job, the competitors they considered (including non-consumption — doing nothing), the factors that drove their decision, and the expectations they brought to the new product. Product Ops compiles JTBD insights into a "Forces of Progress" model that the PM team uses during prioritization — ensuring features are designed around the complete job context, not just the functional task.

Outcome-Driven Innovation (ODI), Tony Ulwick's implementation of JTBD, translates the theory into a quantitative prioritization tool. ODI defines "desired outcomes" as the specific metrics customers use to evaluate success at their job — expressed in the form "minimize the time it takes to [task]" or "minimize the likelihood that [unwanted situation] occurs." Customers rate each outcome on two dimensions: importance (how important is it that the product excels at this?) and satisfaction (how satisfied are they with the current product's performance?). The opportunity score = Importance + max(Importance - Satisfaction, 0). High importance + low satisfaction = high opportunity. This gives Product Ops a prioritized list of "unmet needs" that is statistically grounded in customer input, resistant to individual customer influence, and directly actionable for roadmap building.