A customer job is a choice, not a slogan
A product team can learn what customers are trying to accomplish and still leave the business largely unchanged. Product revises a feature, marketing changes its message, and service continues to resolve the same complaints. Each function has acted on the insight, but each still works to a different definition of success.
In Competing Against Luck: The Story of Innovation and Customer Choice, Clayton M. Christensen, Taddy Hall, Karen Dillon and David S. Duncan explain customer choice in terms of the progress people want to make in particular circumstances. The Christensen Institute develops this idea through its work on Jobs to Be Done. Its value for leaders extends beyond improving a product: it provides a starting point for deciding what the offering, purchase, delivery and use experience must accomplish together.
That starting point becomes strategic when it also helps the business decide what to leave out. Folding every adjacent request into the chosen job gives competing priorities a customer-centered description without resolving them. Leaders need to choose which progress this part of the business will support, then accept that some attractive requests will belong elsewhere.
Follow the obstacle beyond the product
The Christensen Institute recounts a builder's effort to understand why prospective customers hesitated to leave their longtime homes for condominiums. The response extended beyond the physical unit: it included changes to dining-room space and help with moving, storage and sorting possessions. The case illustrates how the purchase experience can matter alongside the product. It is a retrospective account, so it cannot establish how much of any financial result those changes caused.
The important point is the location of the obstacle. A buyer could want a condominium and still hesitate because leaving a home required decisions about possessions and routines. A team focused only on the physical unit might keep improving floor plans while leaving that difficulty untouched. A team focused on the move would have to consider what happened before the purchase as well as what it sold.
That possibility applies well beyond housing. A business might promise to help a customer get a new employee productive, settle an unexpected expense or make a consequential decision with confidence. In each case, the product could be necessary without being sufficient. Eligibility rules, onboarding, a handoff between teams or the first attempt to use the offering might determine whether the customer makes progress.
A report from the Christensen Institute and Innosight connects identifying a job with designing the purchase and use experience and aligning the processes that deliver it. The operating implication is straightforward: someone has to own the obstacles that sit between functions. Whether that arrangement improves performance still depends on choosing a job customers value and serving it at a workable cost.
Turn the job into five connected decisions
The proposed OutcomesLab Job-to-System Map carries the customer insight into operating decisions. It brings five choices into the same conversation so that product, marketing and service do not each act on a different interpretation of the job.
1. Define customer progress. Name the customer, circumstance and change sought. Investigate what prompted actual choices and which alternatives were considered, including doing nothing. Check vivid interview accounts against broader behavior and the economics of serving those customers.
2. State the value promise. Explain the progress the offering and experience will support. Set a boundary around that responsibility: helping a customer through one transition need not mean solving every adjacent problem.
3. Identify required capabilities. Work backward through product, service, channels, partners and handoffs. A promise of rapid setup requires more than a fast sale: the teams receiving the customer need the information and authority to complete it.
4. Choose operating measures. Pair customer progress with delivery costs and business results. McKinsey & Company recommends examining end-to-end journeys rather than isolated touchpoints. In the setup example, time to a usable result and repeat help requests can reveal whether faster sales have simply moved the delay elsewhere.
5. Specify exclusions. Make the operating consequence explicit. Hands-on assistance and the lowest-cost unassisted transaction can require different capabilities, channels and measures. Leaders may serve both through distinct offers; they should not silently ask one model to optimize for both.
The decisive moment comes when an attractive request contradicts the chosen experience. Does leadership decline it, put it in a separate offer or fund a change to the model? That decision gives the map its strategic value. Without it, a precise customer description can coexist with incompatible operating promises.
Focus requires refusing compatible-sounding work
Exclusion seldom arrives as a dramatic decision to abandon a market. It appears in smaller choices: whether to add a feature that lengthens onboarding, open a channel requiring a separate support model or preserve an exception process built for an earlier promise. Each request may sound reasonable in isolation. Together, they can leave teams supporting several incompatible definitions of value.
Michael E. Porter’s argument about strategy supplies a discipline that customer research alone cannot: distinctive positioning requires choices about which needs to serve and fit among the activities serving them. Jobs to Be Done can help leaders identify meaningful customer progress. Strategic trade-offs determine whether the organization will build a coherent way to support it. Neither replaces the other. A tidy operating model does not prove customers value its promise, while evidence of a customer need does not settle how much complexity a business should accept to meet it.
At OutcomesLab, we use Focus Multiplier to examine what concentrated effort can build and Coherence Premium to examine how connected choices reinforce one another. A chosen customer job brings these questions together. It can direct investment toward the capabilities the promise needs, while giving teams a common basis for designing channels, handoffs and measures. Leaders should then look for evidence that these choices improve the customer's progress and the economics of delivery.
Keep the boundary visible—and revisable
The strongest objection to organizing around one job is that many businesses legitimately serve several. A shared platform may support different customer propositions, and imposing a single enterprise-wide job could obscure important differences or sacrifice useful shared capabilities. Customers’ circumstances can change, too. Yesterday’s precise definition may become tomorrow’s excuse to disregard a new need.
The answer is to choose the appropriate level of focus. An offering, customer segment or business unit can have an organizing job without requiring the entire enterprise to claim just one. Several jobs can share capabilities where that helps deliver each promise. Where they demand conflicting service levels, channels or measures, leaders should make the differences explicit rather than average them into a vague statement about the customer.
A boundary also needs a review trigger. Reconsider the job when customers repeatedly choose an unexpected alternative, progress measures deteriorate, delivery costs change materially or an adjacent job becomes strategically attractive. That review should reopen the questions of capabilities and economics—not automatically add another promise to the existing model. Coherence becomes rigidity when protecting the current system matters more than noticing that it no longer fits the customer’s circumstances.
Start with one important customer journey and bring its functional leaders together around a real path from need to use. Find the point where progress stalls, examine the measure that rewards the interruption, and identify who can change the handoff. That makes the next discussion concrete: which customer job will guide this part of the business, what must change to deliver it, and which appealing requests will receive less attention?
A customer job becomes useful to the operating model when teams can use it to make those choices together. The test comes when a plausible new request competes with the chosen promise and leaders have to decide which one the organization will honor.