Principle · Chief Product Officer

Jobs to Be Done.

Source: Clayton Christensen, with Taddy Hall, Karen Dillon, and David S. Duncan, Competing Against Luck: The Story of Innovation and Customer Choice (2016), HarperBusiness. Earlier development in Christensen's The Innovator's Solution (2003).

The Principle

Customers do not buy products. They hire products to do a job. The job is the progress they are trying to make in their life or work, given a specific context. The product is one of many candidates the customer evaluates for that job. When a product gets hired, another product gets fired. Understanding what is being fired is as important as understanding what is being hired.

Jobs are stable over time even as the products that get hired to do them change. People have always wanted to communicate at a distance. Letters, telegraphs, telephones, email, and text messaging are different products hired for variations of the same underlying job. Companies that build for the demographic, the feature list, or the category miss the underlying job and lose to whoever names it correctly. Companies that build for the job find demand the competition cannot see, because the competition is busy benchmarking against products that share the same category but compete for different jobs.

Why It Matters Here

Chief Product Officer is the seat that translates customer problems into something worth paying for. Without the Jobs lens, the role drifts into feature-list management and demographic targeting. With it, the role is forced to ask "what is the customer actually hiring this for, and what is currently doing that job badly," which is the only question that produces real product-market fit.

Signals (When to Apply)

The product roadmap is being driven by feature requests rather than customer outcomes
The team disagrees about who the customer is or what the customer wants
A new product is being scoped and the value proposition is feature-led
Customer churn is happening but the team cannot articulate why
The competitive analysis is happening at the category level instead of the job level

How to Apply

Interview customers about the moment they decided to buy. Not the demographics, not the satisfaction, the moment of switching. What were they doing? What were they frustrated with? What were they trying to make progress on?
Articulate the job in the customer's own language as a single sentence. The format: "When I am [situation], I want to [motivation], so I can [expected outcome]." If the team cannot complete that sentence with conviction, the job has not been identified.
Identify what is being fired. If a customer hires your product, they are firing something else. Sometimes a competitor. Often a workaround, a manual process, or doing nothing. Knowing what got fired tells you where the bar is.
Map the functional, emotional, and social dimensions of the job. Most jobs have all three. A consulting engagement is hired for the work product (functional), the relief of "someone has this handled" (emotional), and the credibility of having engaged the right firm (social). Build for all three.
Test product decisions against the job statement. Every proposed feature, price change, or positioning shift gets evaluated by whether it helps the customer do the job better. Features that do not move the job get killed.
Re-interview when behavior changes. Jobs are stable, but the contexts and constraints around them shift. New technology, new regulations, new competitor moves all change which products get hired for the same job.

Examples

Applied well A team selling project management software is losing customers to spreadsheets, not to competing software. The instinct is to add features that match what the competitive software offers. Applying Jobs, the team interviews churned customers and discovers the job is not "manage projects." The job is "give my boss confidence I have the project under control without me having to update them." Spreadsheets win the job because they produce a printable summary in two minutes. The product team rebuilds the dashboard around the "summary I can send my boss" job, retention recovers, and the team stops losing to a product they were not actually competing with.

Misapplied The same team frames the job as "be the best project management tool for product managers." That is a category, a persona, and a feature aspiration, not a job. Every roadmap decision optimizes for matching competitor feature lists. Customers continue to leave for spreadsheets. The team concludes "we need more features to compete" when the actual issue is that the team never identified the underlying job, so every build is targeted at the wrong thing.

When to Break It

When the customer sample is too small to surface a stable job pattern. Three interviews are anecdotes. Twenty are signal. Do not lock a job statement on insufficient evidence.
When the team is using "the job" as shorthand for the founder's preferred narrative. Real jobs come from customer language, not from internal preference. If the job sounds like marketing copy, it is probably not a job.
When jobs analysis becomes a substitute for shipping. The framework is a tool, not the work. At some point the bet has to be made and the build has to ship.