Behavior change

The single most important question in product, marketing, and sales is the same: how do we get the customer to behave the way our product needs them to? That runs from a single funnel action — click the ad, register, link a card, complete the target action — up to the deepest change of all. In that deepest change the customer starts performing our Core Jobs on the way to their Big Jobs, and keeps performing them rather than leaving for a competitor. This document is about all of it — every type of behavior change, not only the switch to our product.

Every purchase, activation, retention event, churn event, and up-sell is a behavior-change event. Underneath each one, the customer either:

• adopted a new Job Graph (with our Core Jobs in it), and changed their behavior; or
• didn't adopt it, and stayed with their existing Job Graph and existing solution.

If we can engineer behavior change deliberately — at the level of a single funnel action, an individual customer, a segment, or a market — we can build, grow, and defend a product.

This document collects everything the methodology says about behavior change. It covers what it is in mechanism (psychology, neurobiology), what makes it happen, what blocks it, and how to design product, communication, and acquisition around it.

About the Four Forces of Progress. I used the Four Forces for a while as an intermediate tool inherited from the original JTBD literature. About a year ago the methodology moved past it. There are more than four forces, and the process itself is different. A Problem with the current Solution is not really a force. It is often the trigger that launches evaluation. The Four Forces influenced the early formulation, but they are preserved here only as an archive. AJTBD recommends anchoring your behavior-change practice on the theses below rather than on the Four Forces. In this canon I call the extended set of forces the forces of behavior change (§9), to mark the move past the legacy four.

1. What behavior change actually is

Behavior change is the customer swapping one Job Graph for another. It is not, fundamentally, "switching solutions" — solutions are downstream. What changes upstream is the way the customer performs their Big Jobs: which set of lower-level Core Jobs they pursue, with which success criteria, in service of those Big Jobs.

• Before: the customer reaches their Big Job through one set of Core Jobs, at certain success criteria, using whatever solution they hired for it today.
• After: the customer reaches the same Big Job through a different set of Core Jobs, at different success criteria, using a different solution — ours.

The customer didn't simply "switch products" the way the surface story tells it. The customer changed the set of Core Jobs they perform on the way to their Big Jobs. Our product got hired because it performs those new Core Jobs at the new criteria. The solution is the consequence, not the cause.

Concrete example: Zillow Rental Manager → Belong

A Bay Area homeowner who moved into a bigger place is renting out the original Oakland duplex. The Job hierarchy:

• Super Big Job: "Generate predictable monthly income from my real estate."
• Big Job, performed in order to perform the Super Big Job: "Rent out my duplex."
• Baseline success criterion that survives across every Core Job in the graph below: the work must not consume my evenings or my weekends.

Before, the owner performs the Big Job via Zillow Rental Manager, a listings site. The owner's Core Job is "Manage my own rental." Underneath sit ten Micro Jobs, one level below the Core Job, that the owner performs themselves:

• post the listing — multi-platform distribution to Zillow, Trulia, and HotPads, Fair-Housing-safe copy, photos that convert clicks to inquiries;
• screen incoming inquiries — filter time-wasters in one message;
• run credit, eviction, and income checks on shortlisted applicants via RentSafe or TransUnion SmartMove;
• show the unit on Saturday batches;
• negotiate the lease against California enforceability at target rent;
• collect first month, last month, and security deposit;
• hand over keys in under an hour;
• chase rent on the 1st via Zelle or ACH;
• dispatch emergency repairs through a pre-agreed plumber or electrician so the tenant doesn't escalate trivia;
• track expenses year-round for Schedule E.

After, the owner performs the same Big Job via Belong, a turnkey rental service. The chain collapses to two Core Jobs:

• "Onboard the property to Belong once." Criteria: done in a single 2-hour walkthrough; Belong handles listing, screening, and tenant placement; one dedicated rep to call when I have questions; no Fair-Housing exposure on my side.
• "Receive a guaranteed monthly payment from Belong." Criteria: paid on the 1st of every month; the amount doesn't depend on whether the unit is currently occupied; year-end 1099 and Schedule E inputs delivered ready to drop into TurboTax.

Now look at the behavior change at the Core-Job level. The Jobs "post a listing", "screen tenants", "negotiate the lease", "chase rent" — and all their success criteria — stop being performed by the customer at all. They are not done worse. They are done by zero people in this segment going forward. Belong didn't sell "a property-management app." It sold the cancellation of an entire chain of Core Jobs, and the substitution of two simpler ones in their place. The Belong app got hired onto the two new Core Jobs as the delivery format.

That is the actual behavior change. What was sold to the owner is the new set of Core Jobs and their success criteria, not "the Belong solution."

2. A Solution lives in two registers — a thing in the world, and a label for a Job Graph

Solutions live in two registers at once. In the world they are real things: products, brands, services, self-performed routes such as Belong, Zillow Rental Manager, Wealthfront, or manage it myself. Inside the Job Graph, the same Solution exists as the label for the specific sub-graph of Core Jobs and Micro Jobs the customer walks under it. Both registers are real. Switching Solutions means switching the Job Graph below.

The label-side is what does the work inside the methodology. When we talk about "the customer hired Solution X", we mean the customer walked the sub-graph that Solution X installs. The brand handle is convenient shorthand. The sub-graph is what the customer actually performs.

The label can be a product or brand (Belong, Zillow Rental Manager, Wealthfront, Chase savings), a service request (hire a property manager, book a tax accountant, call a contractor), or a self-performed action (manage the rental myself, do my own taxes, fix the leak with a YouTube video). In every case, what the customer is actually picking is a specific Job Graph. That graph is a particular set of Core Jobs with their success criteria, the Small Jobs at the same level, and the Micro Jobs underneath, which together perform the Big Job the customer cares about. The "solution" is just the label for that sub-graph.

Behavior change, in this framing, is the customer swapping one labeled Job Graph for another — exactly what we saw in the worked example in §1. The label changes; the more interesting thing is the new graph underneath. §3 unpacks what that means in practice for product, marketing, and sales.

3. What this means in practice: different Core Jobs for different solutions

Treat the ontology of section 2 as the working principle and three structural facts fall out at once:

1. Different labels mean different Core Jobs, plus the sibling Small Jobs at the same level and the Micro Jobs underneath, each with their own success criteria. One Big Job served by many labels yields many different Core Jobs. That means many different segments, with many different behavior changes possible.
2. Switching a customer to your solution means switching the Core Jobs the customer performs. That switch is the behavior change. Switching the vendor without switching the Core Jobs and criteria is just shopping.
3. What you actually sell is the Core Jobs and their success criteria, not "the solution." The solution label rides along on top of the Core-Job-and-criteria sale. It gets hired onto those Core Jobs as the delivery format.

Two industry clusters below make this concrete. A consumer-services cluster (rental management) and a knowledge-work cluster (writing code) show the same pattern across different domains.

Cluster 1 — Rental management (the Zillow → Belong case from §1, extended)

The §1 case showed one switch: "Manage my own rental" (Zillow Rental Manager) → "Outsource turnkey" (Belong). That is one move on a wider landscape. For the same Big Job "Rent out my duplex", serving the Super Big Job "Generate predictable monthly income from my real estate," three different Core Jobs are available to the customer. Each comes from a different Solution:

• Zillow Rental Manager (DIY listings plus screening). Core Job: "Manage my own rental." Criteria: I run everything; Zillow distributes the listing and pulls credit and background reports; I keep all upside and eat all variance.
• Local property manager (traditional PM, 8–12% of gross rent). Core Job: "Delegate the rental to a local PM." Criteria: PM screens tenants and handles repairs; I approve major calls such as vacancies and repairs over $X; income still varies with occupancy and PM quality.
• Belong (turnkey rental management with guaranteed monthly payments). Core Job: "Outsource the rental entirely turnkey." Criteria: one 2-hour onboarding; Belong does listing, screening, leasing, and repairs; I receive a guaranteed amount on the 1st of each month regardless of occupancy.

Three Core Jobs, three sets of success criteria. The verbs differ (manage · delegate · outsource), the delegation level differs (none · partial · full), the criteria differ (control plus full upside · partial delegation plus approval rights · guarantee plus zero involvement). The §1 homeowner walked across this landscape from Core Job 1 to Core Job 3, deleting the Micro-Job chain that the §1 Before and After enumerated.

Cluster 2 — Writing code (same pattern, knowledge-work domain)

Take an engineer at a Series-B startup. The Super Big Job is "ship the feature my team committed to this sprint" and the Big Job is "ship a working change in this codebase." Three Core Jobs are available. With VS Code plus Stack Overflow, the Core Job is "write the code myself, line by line" — I own every keystroke and the architecture. With GitHub Copilot, the Core Job is "write the code with line-level AI assistance" — completions match my intent inside the function, I review every suggestion, I still own the architecture. With Claude Code or Codex, the Core Job is "describe the change in English; the agent writes it, runs the tests, iterates on failures" — I review diffs not characters, and intervene on architectural calls not syntax.

Same Big Job, three radically different verbs (write · assist · delegate), three different Micro-Job sets deleted. The look up the API in docs · type the call character by character · run the linter manually · re-run failing tests by hand class collapses entirely for the engineer who adopts agent-pair-programming.

The pattern holds across domains: one Big Job, several Core Jobs, each Core Job a different Job Graph underneath, each with a different segment willing to hire it.

4. The necessary condition: Big Jobs and Super Big Jobs performed more effectively, by their success criteria

Everything else in the document depends on this condition.

The customer's Big Jobs and Super Big Jobs, measured by their own success criteria, must be performed more effectively through our Job Graph than through the Job Graph the customer performs today. Our Job Graph means our Core Jobs at our criteria. If that condition doesn't hold, the customer doesn't switch — no matter how impressive any individual Core-Job criterion of ours looks in isolation.

Three operational consequences follow, on three different planes: comparison, design, and communication.

Comparison ladders up to the Big Job and Super Big Job. Customers compare Core Jobs by how well they perform the Big Jobs above them, against the segment's Big-Job criteria, not by Core-Job criteria in isolation. Even a Core-Job criterion we deliver perfectly won't drive the switch unless it connects to a Big-Job criterion the customer cares about. "App loads in 800ms" is a Core-Job criterion. "Generate predictable monthly income" is the Big-Job criterion the customer evaluates against. If the 800ms doesn't visibly help generate predictable monthly income, it doesn't carry the switch, however true it is. In the rental example, Belong didn't beat Zillow on "managing the rental" compared as an isolated Core Job. Belong beat Zillow on "generate predictable monthly income from my real estate." Belong's Core-Job criteria — one-time onboarding, guaranteed payment, zero involvement — won because they delivered that Big-Job criterion, and Zillow's "manage my own rental" did not.

Design flows top-down: Big-Job criteria first, then Core-Job criteria, not the other way. The success criteria of our Core Jobs are downstream of the criteria of the Big Jobs and Super Big Jobs they serve, and must be derived against them. Every Core-Job criterion must ladder up to a Big-Job or Super-Big-Job criterion the customer cares about. "App loads in 800 ms" doesn't ladder up to "generate predictable monthly income," and so, however true, it's irrelevant to behavior change. The common error is to optimize Core-Job criteria in isolation. Local metrics look healthy and the customer still doesn't switch.

Communication, the Consideration Activators, goes through Big Jobs and Super Big Jobs, with their criteria. Messaging at the Core-Job level alone doesn't activate. Messaging that lands on the Big-Job and Super-Big-Job criteria does. This is why Consideration Activators doctrine emphasizes Big-Job framing — see §5 and Consideration Activators.

Without this condition holding, nothing downstream compounds. Neurobiology, forces, durability, and B2B specifics are all built on this gate. The Big-Job and Super-Big-Job success criteria are where the customer evaluates, where you must design, and where you must communicate. Get all three lined up and the rest of the document is operationalizable. Miss any one of them and the rest is decoration.

5. Consideration Activators — the mechanism that loads new Core Jobs into the customer's head

Behavior change happens when Consideration Activators land in the customer's head. That is the knowledge, or lived realization, that a more energy-efficient way to perform their Big Jobs exists, in a form they can act on. Consideration Activators can be loaded through any channel that lets the customer encounter the new way: communication (advertising, content, salesperson, peer story), social observation (seeing someone else use it), or first-hand trial ("I tried it, and — oh, it actually works"). Every act of behavior change is, in its core, an act of Consideration Activators loading — propositional or experiential. Loading Consideration Activators, by any of these channels, is the operational lever for changing customer behavior. (Full treatment: Consideration Activators. A parallel treatment in AJTBD key theses.)

For behavior change to start, the customer must learn five units of information:

1. A new Job Graph for performing their Big Jobs exists. Specifically: with this Job Graph, with these Small Jobs and Core Jobs (ours), to these concrete success criteria. This is the customer's knowledge of what they would now perform — rent a car through Zipcar, outsource the rental to Belong, file through TurboTax — not yet the value claim.
2. The new Job Graph performs the Big Job more efficiently than the customer's current way. The Core Jobs in our Graph sit one level below the Big Job and deliver it at better success criteria: cheaper enough, faster enough, higher-status enough, or more reliable enough to overweight the cost of switching. Abstract "more efficient" doesn't activate. The brain doesn't switch on a directional claim; it switches on a meaningful, criteria-anchored delta. The pitch is in the language of our Core Jobs and their criteria with the delta attached, not features.
3. A concrete named product performs that Job Graph, and here is the door. The customer needs a name (the product, service, or brand that runs the Core Jobs at the criteria) and a first concrete step (download the app, book a 15-min call, sign up at this URL, ask the bank teller). Without name plus door, components 1 and 2 stay unactable. The customer knows a better graph exists and why it matters, but has no handle to move — solution-aware but not product-aware, in Hunt's Pyramid terms.
4. Specific fears about this new Job Graph are reduced. A fear is the customer's prediction that the Big Job won't be performed well through our new graph — a Critical Chain of Jobs break, Problem, Tax Job, personal risk, or irreversible loss along the way. The message names the specific feared break, then shows why it is prevented, absorbed, reversible, insured, or irrelevant for this Solution. If the break is real, communication cannot reduce it; the team must change reality first.
5. Alternative Job Graphs are fired. Competing Job Graphs for performing the same Big Jobs are shown to be less energy-efficient by the Big Jobs' success criteria. (Per §2, the everyday-language label Solution names the Job Graph the customer walks under it.) The firing names the specific Problems and Risks that follow from sticking with the alternative — failures that produce Problems (see §7), forced Tax Jobs, criteria the alternative cannot hit, chain-breaks it leaves open. Abstract "they're worse" doesn't fire anything. The customer's brain doesn't down-weight an option without a concrete reason. The fire lands when the customer can name, in their own words, which Big-Job criterion the alternative misses and what it costs them when it misses.

Components 1, 2, 4, and 5 all ride on the Big Job. Only component 3 doesn't. Components 1, 2, and 5 carry the motivation: they run through the Big Jobs and the Big Jobs' success criteria (§4), where the customer's brain actually compares. Component 4 (specific fears reduced) rides on the Big Job too, but as blocker-removal. A fear is the customer's prediction that the Big Job won't be performed well through our graph, so reducing it deletes a predicted reason the Big Job would fail under us. Only component 3 (named product plus the door) is Big-Job-agnostic: pure actionability, the handle the customer grips once the other four have done the evaluation. Load the right Consideration Activators at the right moment, and our new Core Jobs (with our criteria) awaken in the customer's consideration set as a way to perform the Big Job they already have. Then they perform the new Core Jobs, and our Solution gets hired onto them. Trigger timing — when the customer is most receptive to a load — is unpacked in §8.

Environment is one of the most underweighted Consideration Activators channels. Not all Jobs are top-of-mind at the moment of contact. Many sit latent: the customer has the Job in their graph, but the conditions to activate it aren't present. Proximity and context can mass-activate latent Jobs, producing what looks like "impulse buying" but is really Consideration Activators loaded through environment.

The canonical case is IKEA. Its showroom route and furnished interiors work as visual Consideration Activators. The customer walks through finished room arrangements, and latent Jobs activate ("oh, I need a shelf like that," "so that's how you can organize a closet"). The low-cost food court functions as a loss leader that primes the latent Job "furnish my home."

Environmental context can mass-activate Jobs the customer wasn't consciously aware of having. Shopping malls, demo zones, showrooms, SaaS onboarding tours, "people you may know" suggestions in social products — all are forms of context-loaded Consideration Activators that wake latent Jobs.

(IKEA design analysis from TIME, This Is Why You Overshop in Ikea.)

6. The brain detects value as energy-efficiency above its own prediction

The brain runs as an energy-budget investor that predicts both cost and outcome on every Job performance, then compares reality against both predictions and registers a signed delta on each. A positive delta produces an Aha Moment, the customer-experience side of a Positive Prediction Error. A negative delta produces a Problem, the customer-experience side of a Negative Prediction Error, whose structural cause is a Solution hired for a Job performed below its success criteria. Value is the more energy-efficient experience itself. The Aha Moment and the Problem are the brain's noticing of value delivered above or below the prediction the customer arrived with.

Full neuroscience grounding: Scientific Foundations §1, §11. Full value canon: Value Creation §2–§7. Short version: AJTBD key theses §6, §7.

7. Prediction errors rewire behavior — one cycle, two signs

§6 set up what the prediction error is. This section is what happens after it fires. The Aha Moment and the Problem run through the same five-step cycle. What differs is the sign of the delta at step 4 and the direction of re-learning that follows.

1. Customer arrives with a prediction, set by past experience plus the success criteria they came in with.
2. Customer encounters the Job Graph being performed, through communication, observation, or first-hand trial — the three Consideration Activators channels (§5).
3. Reality lands and is compared against the prediction. The Big Job is performed at some level of energy-efficiency against the customer's own criteria, and the brain produces a signed delta on each prediction term (cost and outcome).
4. The brain registers the signed delta as a teaching signal, and bifurcates:
   • Positive delta produces an Aha Moment. A dopamine spike fires (Schultz RPE, Current Biology 2017). The teaching signal is "this Job Graph performs the Big Job well — repeat it." Habit autopilot loosens; conscious evaluation engages.
   • Negative delta produces a Problem. Dopamine dips below baseline, and negative emotions fire (irritation, anxiety, anger). The teaching signal inverts: "this Job Graph performs the Big Job worse than I thought — avoid it next time." The most toxic case is when the Job isn't performed at all and the customer is forced into a Tax Job the Solution promised to absorb.
5. Re-learning runs in the direction of the signal. On the positive side, a window opens in which the customer is biologically inclined to perform the new Job Graph again, if reinforced. Without reinforcement the old habit reasserts and the customer reverts (see Scientific Foundations §15). On the negative side, behavior shifts away from the Graph, and if the Problem is severe or repeated the customer abandons it. The customer may even generalize ("the whole class of Solutions is a Tax-Job factory") and avoid the category in the future.

What this means for the product

• One Aha Moment is necessary but may not be sufficient. Durable behavior change typically requires a stream of Aha Moments against the rising prediction bar (Red Queen — Value Creation §6).
• A single severe Problem can undo months of Aha Moments. The brain's negative-learning rate is faster than its positive-learning rate, since loss aversion has a neurobiological substrate (Scientific Foundations §13). Tax Jobs are especially toxic.
• Activation is an engineered first Aha Moment. Retention is a sustained Aha-stream, reinforced by the habit and switching cost that can hold a customer even when fresh Aha Moments thin out. Churn is accumulated Problems overwhelming all three.
• Overpromise is a manufactured-Problem machine. Inflated expectations lead to reality below them, which produces a Problem and re-learning in the wrong direction. Match the promise to what the chain actually delivers (§4).

8. Triggers that launch behavior-change evaluation

A behavior-change event has a moment of launch. That is the point at which the customer goes from performing their current Job Graph to actively evaluating alternatives. The forces in section 9 operate after this moment, on a customer who is already in evaluation mode. Without a trigger, no evaluation happens, and most forces don't act on a customer in steady-state habit.

The methodology recognizes the following triggers of behavior-change evaluation. Some are events in the customer's life, some are events created by the world, and some are events we can deliberately engineer.

• A break in the customer's Critical Chain of Jobs. The current solution stops performing one of the Jobs in the chain to a Big Job. The chain breaks, the Big Job is at risk, and the customer launches an Orientation Job ("what else can I use?") and becomes much more receptive to Consideration Activators. (See Critical Chain of Jobs.)
• Accumulated Problems with the current solution. Even when the chain isn't broken, a steady drip of failures produces repeated Negative Prediction Errors until the threshold is crossed. The customer reframes: "this isn't working well enough; I should look for something else." (See section 7 on Problem dynamics.)
• Life events and context shifts. A move, a new role, a child, a new market entry, a new regulation. The person ends up in a new context where new Jobs appear and old Jobs change — different success criteria, different triggers, different Big Jobs above. The previously fine Job Graph stops fitting. (Maps to the Job-structure element Trigger — see Job Structure.)
• Status or identity shift. Promotion, new role, life-stage change, social-group change. Who the customer wants to be has shifted, and the Job Graph that fit the old identity no longer fits the new one. (Related to Life events but distinct: the trigger is internal identity reformation, not external context.)
• External shock or forced switch. A regulatory change, a vendor discontinuation, a supplier failure, a price hike, a merger. The customer is forced to evaluate alternatives whether or not they wanted to.
• External Consideration Activators load. An advertisement, a peer's story, a piece of content, or a salesperson's outreach surfaces a new Job Graph the customer didn't know existed. The new load wakes up an Orientation Job: "wait, what robot vacuums are out there?" (See Consideration Activators § Sources of Consideration Activators.)
• First-hand trial of a new way. The customer encounters the new Job Graph directly (free trial, demo, friend's product) and experiences a strong Aha Moment. The Aha Moment itself becomes a trigger. Behavior change can begin from the experience side, not only from the information side. (See §5.)

Two practical implications:

• Marketing that hits a customer in steady-state habit, still satisfied with their current way of performing their Big Jobs, is mostly wasted. With no Problem and no chain-break, the current Job Graph still meets their criteria. The customer isn't evaluating, and the forces in section 9 aren't acting. Effective acquisition either creates a trigger (loads Consideration Activators that wake up an Orientation Job) or times itself to a trigger already firing — a Critical Chain of Jobs break, life event, identity shift, or shock.
• Trigger-timing dominates message quality. Even brilliant messaging delivered to a habit-state customer underperforms mediocre messaging delivered at the moment of a Critical Chain of Jobs break or a life-event window.

9. Forces of Behavior Change

The classic Four Forces of Progress tool captured part of the behavior-change algorithm. Its four levers are the added value of the new solution, the Problems with the current solution, the fears toward the new solution, and the habit of the current way. Its authors saw a real slice of how a customer moves at the moment of evaluation. The list below is not an extension or a successor of that tool. It was developed independently, from first principles, and arrives at a more complete list of forces and a more complete logic of behavior change. A mapping at the end of the section shows where the two pictures overlap.

These forces act on a customer already in evaluation mode (see section 8 on triggers). On a customer in steady-state habit, most of them don't fire at all.

Forces below are grouped by lever type — what kind of intervention works against each. Diagnosing a stuck behavior change reduces to finding which lever-group is failing and choosing a move from that group. The §12 diagnostic uses this grouping.

Drivers: forces that drive behavior change forward

Brain-side, the neurobiological dopamine machinery itself:

• Positive Prediction Error, the Aha Moment from our product. Strongest single driver, neurobiologically primary (see §7).
• Curiosity. A genuinely curious customer treats an unfamiliar Solution as opportunity rather than threat. Perceived switching risk drops, and Consideration Activators are easier to absorb. Curiosity opens a brief learning window before the answer arrives, not after. (Neuroscience: Scientific Foundations §17.)
• Positive emotions during use. Joy, calm, relief, satisfaction, status uplift. The brain seeks to repeat experiences that produced them (Scientific Foundations §9, §11).

Information-side, the Consideration Activators:

• Knowledge of a more energy-efficient way to perform the Big Jobs. The Job-Graph and value-delta components of Consideration Activators (§5, components 1–2). Once the customer learns a better Job Graph exists and the delta is meaningful, they are biologically motivated to evaluate it.
• Firing the competing Job Graph. Consideration Activators component 5 (§5): showing the current or competing Solution is concretely worse by the Big Job's success criteria, naming its Problems and Risks. This down-weights the alternative during the comparison and drives the customer toward switching. We can't manufacture those Problems, only surface the real ones (see Working with the forces below).

Identity-side:

• Identity alignment with the new Job Graph. When our Big-Job framing matches who the customer thinks they are ("I'm a person who takes care of their health"; "I'm a founder who decides on data"), motivation is significantly stronger and more durable than at the outcome level (Scientific Foundations §7, §8).

Blockers: forces that block behavior change

Brain-side, neurobiological:

• Negative Prediction Error from the new Job Graph, the Problem. Strongest single blocker, mirror of the Aha Moment. When reality from our Graph falls below prediction, or the Job isn't performed at all and becomes a forced Tax Job, the brain re-learns not to perform it next time. A single severe Problem can undo months of Aha Moments (§7).
• Cost asymmetry, price-as-pain. The brain registers price and effort in the same region it uses for physical pain (Scientific Foundations §4). New Solutions demand investment now while gains are deferred, and the brain overweights present pains against future gains.
• Negative emotions during use. Frustration, anxiety, shame, anger, boredom while performing the new Graph. The brain learns not to repeat (Scientific Foundations §9, §11).

Habit and identity-side:

• Habit. A physical change in the brain: neural networks tuned to the current way of performing the current Job (§7; Scientific Foundations §15). Customers and product teams systematically underestimate its strength.
• Identity-as-current-solution. When the customer identifies with the existing Solution ("I'm an Apple person", "I'm a Nike runner"), switching threatens identity itself. This is the hardest blocker to address with logic alone.

Reality-side:

• Objective barriers. Facts on the ground that derail the new Job Graph regardless of customer belief: incompatible data schema, missing permit, unsupported ZIP, land unsuitable. Reduced only by changing reality, not by communication. (See Barrier Removal.)

Mental-models-side, conscious predictions plus unconscious commitments:

• Specific fears about the new Job Graph. Conscious predictions of a Critical Chain of Jobs break, Problem, Tax Job, personal risk, or irreversible loss. Reduced by stories, demos, guarantees, reversibility, insurance, and trusted proof — only if the feared break is not real. Real blockers require changing reality first (Barrier Removal).
• Unconscious competing Jobs, Immunity to Change (Kegan). Jobs the customer is unconsciously performing in service of the current state, beneath their conscious fears. The customer rationally wants to switch but is unconsciously performing a hidden Job like "don't look incompetent while learning a new tool" or "don't make my boss feel his earlier choice was wrong." Standard fear analysis won't surface these; they have to be dug out at the unconscious-Jobs and identity level (Kegan & Lahey).

Working with the forces

• We can create added value — a stronger positive prediction error against the customer's criteria.
• We can load Consideration Activators.
• We can reduce specific fears, with stories, demos, guarantees, reversibility, insurance, and social proof.
• We can reduce objective barriers, by changing reality through migration tools, integrations, and fundament fixes.
• We can time our outreach to Critical Chain of Jobs breaks and life events.
• We largely cannot create problems in the customer's current solution. We can only surface them.
• We largely cannot reduce the customer's habit toward the current solution. We should reuse it instead of fighting it (see section 11).
• We largely cannot directly change identity. But we can speak in identity-level language and let the customer's identity match ours.

Mapping back to the Four Forces of Progress

For readers familiar with the classic tool, here is how the legacy four map to the extended list above:

Forces above that the Four Forces tool did not capture:

• Negative prediction error from our new Job Graph. Once the customer has tried the new way, a Problem on our side becomes a fast, powerful blocker. It is distinct from "problems with the current solution" and absent from the classic tool.
• Negative emotions during use of the new way. This is the mirror of positive emotions, where the brain seeks not to repeat. It is not in the classic list.
• Curiosity. Anticipatory dopamine firing in the SN/VTA → hippocampus circuit before the answer arrives (Gruber, Gelman & Ranganath 2014), which lowers the cost of absorbing Consideration Activators about a new Solution. It is not in the classic list.

For the original Four Forces of Progress tool — its self-contained framing, the segment-selection use case, and the case studies — see the archive at the bottom of this document.

10. Two classes of behavior change

The distinction is about whether our Core Jobs are familiar or unfamiliar to the customer.

Take a US example. The Big Job "run my errands across the city" exists for almost every adult in San Francisco, and has for decades. Underneath it sit Core Jobs of several kinds: the familiar one ("get from A to B in my own car"), a less-old-but-now-familiar one ("get from A to B in an Uber"), and a new one that's still becoming familiar ("get from A to B in a Waymo robotaxi"). The Big Job is constant. The Core Jobs differ in how familiar they are to the segment.

That familiarity dimension is what splits behavior change into two classes, with very different operational difficulty.

Class 1: our Core Jobs are familiar to the segment

The customer already understands the category of our Core Jobs. They have a mental model for what hiring this kind of Core Job looks like and how to evaluate it. Behavior change here means moving the customer from one familiar Core Job to another familiar Core Job. Examples: Uber → Waymo (both ride-hailing Core Jobs); Chase → Wealthfront (both savings Core Jobs); Word → Notion (both document Core Jobs).

• Communication leads on Core Jobs and their criteria, because the customer can evaluate at that level, with Big Jobs as reinforcement. "Waymo gets you from A to B with no driver, 20% cheaper, no surge."
• Fears center on whether our specific Core Job actually delivers on its criteria ("is a driverless car actually safe?"), not on whether the Core Job is sensible at all.
• Consideration Activators is often about firing the competing solution and reducing those specific delivery fears. The customer doesn't need to be convinced the Core Job category is real; they need to be convinced our Core Job is the best instance in the category.
• The Aha Moment usually fires in the first session, because the customer has a clear prediction to be exceeded.

Class 2: our Core Jobs are unfamiliar to the segment

The customer's Big Job exists, but our specific Core Job — the way we propose to perform that Big Job — is new and unfamiliar. Examples: own-car → first-ever Uber (in 2010, asking a stranger via app for a ride was unfamiliar); cash → first-ever Robinhood (asking an app to buy fractional stocks was unfamiliar); offline tutor → first-ever Coursera MOOC (learning at scale from a recorded professor was unfamiliar).

Behavior change here is structurally harder, and the rules are different:

• Communication leads on Big Jobs, not Core Jobs. The customer doesn't yet have a mental model for the new Core Job, so pitching its features doesn't land. The pitch lands when it shows that our Big Job outcomes are radically better ("never own a car again — get anywhere in 5 minutes for less than you spend on gas"), and only then back-fills the Core Job that delivers them.
• The Aha Moment is forward-loaded. The customer needs heavy Consideration Activators (peer stories, demos, free trial, social proof) before the first session, because they can't predict what the new Core Job will feel like.
• Fears are about the Core Job itself being a sensible thing to do at all ("is it safe to get in a stranger's car?"), not about delivery quality. Fear reduction has to address the category-existence question first.
• Waking up an unfamiliar Core Job is a significantly higher-risk move. The category-creation curve is long, expensive, and full of failures.

Diagnostic question

Before designing communication for a behavior change, ask the segment: "Have they performed the category of our Core Job before — with anyone? Or is this their first encounter with this kind of Core Job?" The answer routes you to Class 1 or Class 2, and the operational playbook is different in each.

Note. The methodology contains a specific algorithm for distributing an unfamiliar-Core-Job product through a market — sequencing across segments, the role of opinion-leader segments, the role of free-trial and loss-leader phases, the timing of fear-reduction content versus value-demonstration content. That algorithm is intentionally not part of the public canon. It will be part of future paid products. To get notified when those materials become available, subscribe to the newsletter on the canon website.

11. Durable behavior change requires engineered streams of Aha Moments against rising prediction bars

Engineer positive prediction errors in the first session, then keep delivering them. The Aha Moment is necessary but not sufficient (§7). Durable behavior change requires repeated positive prediction errors over time, because the customer's expectations rise as they adapt. Yesterday's wow is today's baseline, and the bar for "above prediction" climbs with every comparison the customer makes against every adjacent product they touch.

Reuse existing habits; don't try to install new ones. A habit is a physical neural network, and building a new one is expensive in dopamine, time, and customer patience. Three rules. First, don't instill new habits — it is painful, slow, and expensive. Second, reuse existing habits — embed your product into rituals the customer already runs. Apple Pay reused the existing physical-card-tap gesture at the terminal instead of teaching a new payment ritual, and adoption ran far ahead of competitors who tried to install their own ritual from scratch. Third, roll out changes to existing products very gradually.

Hit identity, not just outcomes, when motivation needs to be durable. "Lose 5 kg" is an outcome; "I'm someone who takes care of their health" is identity. Identity is multi-need (status, consistency, self-actualization) and harder to drop. Frame Big Jobs at the identity level wherever the customer is ready for that framing. Outcome-level framing is enough for one purchase, while identity-level framing carries renewal and word-of-mouth.

Time outreach to receptivity windows. The same Consideration Activators delivered to a customer in steady-state habit costs an order of magnitude more to land than one delivered at a Critical Chain of Jobs break, a life event, or a market or regulatory shift. Most marketing budgets are spent on customers in habit-state, which is why most marketing budgets underperform their best case. The full taxonomy of receptivity windows, including the engineerable ones, is in §8.

Don't substitute communication for product. A positive prediction error has to be experienced, not promised. Communication loads Consideration Activators; the product delivers the prediction error. If communication promises a Big Job that the product only partly performs, the customer arrives with inflated expectations, hits a negative prediction error, and is disappointed, no matter how well the Core Jobs were actually performed. The promise must match what the chain actually delivers. Overpromise is the single most common way teams manufacture their own churn.

Stack-rank behavior changes against unit economics. Not all behavior changes are worth engineering. Some are too expensive — fighting habit, fighting identity, fighting Immunity to Change — for the per-unit margin they unlock. The decision to engineer a specific behavior change is itself a strategic choice. Segment selection upstream determines which behavior changes a product is even trying to engineer (see AJTBD key theses § Strategy and Segmentation).

12. Diagnose broken metrics by asking which force is missing or dominating

When a metric is broken — low conversion, slow activation, high churn — the right diagnostic question is:

"Which behavior change is supposed to happen at this step, and which of the driving forces is missing — or which blocking force is dominating?"

This question routes you upstream of the broken metric, into the actual cause:

• No Aha Moment in the first session? The positive prediction error is missing. Fix the value, fix the criteria match, fix the expectations alignment.
• Customer activates but churns? There is no repeated reinforcement and habit reasserted. Engineer more prediction errors over time.
• Customer doesn't even start to evaluate? Consideration Activators isn't loaded, or it doesn't land on their Big Jobs.
• Customer evaluates but doesn't switch? Fears not reduced; competing solution not fired; identity-as-current-solution holding them; Immunity-to-Change protecting an unconscious commitment.
• Whole segment isn't moving? Maybe the segment-and-Job choice is wrong. Switch segment (see AJTBD key theses §12).

13. Behavior change as the unifying lens of Next Move Theory

Every algorithm in Next Move Theory is, at the most basic level, an algorithm for engineering a specific behavior change in a specific segment. Launch, scale, grow conversion, exit competition, decrease churn, increase retention, create acquisition channel, grow existing product — each one decides which Big Jobs to hit, which Consideration Activators to load, which prediction error to engineer, which habit to reuse, which fears to reduce, and which competing Job Graph to fire.

A churn-diagnostic and a positioning rewrite are the same behavior-change algorithm applied at two different steps in the customer lifecycle. The lens is invariant across the work. What changes is which forces are dominant at the step in question and which Consideration Activators land in the customer's head at that step. For a product organization, this is the unifying instruction set. Every functional team — acquisition, growth, product, support, marketing — is engineering behavior change at its own step, and the algorithm reduces to: who is the segment, what is the Big Job, which prediction error are we engineering, which forces are blocking, which Consideration Activators close the gap.

If you don't see the behavior change underneath the algorithm, you're applying the algorithm mechanically. If you see it, you understand why the algorithm works and when it doesn't.