The Four Forces of Progress: A PM's Map of Why Customers Switch

Push, pull, anxiety, and habit are the four forces that decide whether a customer switches to your product — a framework first mapped by Clayton Christensen, Bob Moesta, and Karen Dillon in their Jobs to Be Done research. Push and pull create momentum toward change; anxiety and habit create inertia that holds people in place, no matter how good your feature is.

Customers switch only when the combined pull of a new solution and push of their current situation outweigh the anxiety of trying something new and the habit of their existing routine. Low adoption of a "clearly better" feature almost always means anxiety or habit is winning, not that the feature itself is weak.

The Four Forces of Progress, Explained

Every switching decision is a contest between two forces pulling someone forward and two forces holding them back. Push is the pain of the current situation reaching a breaking point. Pull is the magnetism of the new solution. Anxiety is fear about the switch itself. Habit is loyalty to the current routine.

This is the Forces of Progress diagram from Competing Against Luck (2016), and it's the single most useful mental model for explaining why "better" doesn't automatically mean "adopted." It builds on the same jobs-to-be-done logic covered in our complete guide to Jobs to Be Done — people don't buy products, they hire them to make progress in a specific situation.

• Push of the situation — the frustration, deadline, or event that makes the status quo untenable. A CRM that can't handle a new reporting requirement. A mattress with a permanent dip in the middle.
• Pull of the new solution — the vision of a better life the new option promises. A dashboard that finally answers the CFO's question in one click.
• Anxiety of the new solution — the fear of the unknown: Will it work? Will I look foolish? Will I lose data in the migration?
• Habit of the present — the comfort of "the way we've always done it," including sunk-cost workarounds and tribal knowledge that make the old tool feel safe.

JTBD researchers call the initiating event a first thought — the exact moment push crosses from background noise into an active search for alternatives. Mapping that moment is often more revealing than mapping the eventual purchase, because it tells you what to say and when, not just what to build.

Most roadmaps only manage two of these four boxes. Product teams pour effort into pull — more features, better design, a sharper pitch — and occasionally lean on push through urgency messaging. Anxiety and habit are left to sales, support, or nobody at all.

This isn't a niche failure mode. A team can nail push (customers are clearly in pain) and pull (the demo gets applause) and still watch adoption stall, because nobody budgeted time to treat anxiety and habit as separate, testable hypotheses. Push and pull get discovery interviews and launch metrics; anxiety and habit get a support ticket after the fact, if they get tracked at all.

The Tug-of-War: Two Forces Pull You Forward, Two Hold You Back

Switching is not a scorecard where the highest total wins — it's a tug-of-war where the side with more net force wins, and small increases in anxiety or habit can cancel out large increases in pull. This is why "10x better" products routinely lose to "good enough" incumbents that are simply less scary to leave.

The asymmetry here is well documented outside JTBD circles too. Daniel Kahneman and Amos Tversky's work on loss aversion found that losses register roughly twice as painfully as equivalent gains — so the perceived risk of switching (a loss-framed decision) tends to outweigh the perceived benefit of switching (a gain-framed decision) by default. Richard Thaler and William Samuelson's research on status quo bias found the same pattern from a different angle: people disproportionately stick with a default option even in low-stakes hypothetical scenarios, and the bias gets stronger as the number of competing alternatives grows.

The four forces don't need to be equal to produce a decision. They need to be net positive, and inertia has a structural head start.

In practice, all four forces usually show up in the same interview, layered on top of each other. A customer describes the pain that started the search (push), the moment a demo clicked for them (pull), and in the same breath explains why they still haven't pulled the trigger (anxiety, habit) — often without realizing they've just told you which force to address first.

The Mattress Test

The mattress-buying case from Competing Against Luck is the canonical illustration. A couple sleeps on a sagging mattress for years. The push builds slowly — sore backs, restless nights — but it isn't enough on its own, because the habit of "we'll deal with it" and the anxiety of "buying the wrong mattress is expensive and embarrassing to return" hold the line.

The moment that tips the decision is rarely the mattress ad. It's a first thought: houseguests are coming, and the old mattress will be visible and judged. That single event spikes push and, combined with a low-anxiety trial period (sleep on it 100 nights, free returns), finally outweighs the habit of doing nothing. Notice that the winning move wasn't a better mattress — it was a lower-risk way to try one. The trial period is an anxiety lever, not a product lever: the mattress itself didn't change, only the perceived cost of being wrong about it.

The CRM Switch

Run the same lens over a hypothetical B2B scenario: a 40-person sales team using a legacy CRM. Push is real — reports take hours to build, mobile access is broken. Pull is real too — the new CRM has the automation everyone wants. Yet adoption stalls for a year.

Why? Anxiety dominates: nobody wants to be the one who breaks the pipeline data during a live quarter, and migrating custom fields feels irreversible. Habit reinforces it: reps have built personal shortcuts and macros in the old system that took months to learn. A team assessing this switch has to weigh all four forces, not just compare feature lists — which is exactly the kind of comparison covered in our guide to writing a JTBD job statement that captures the full situation, not just the desired outcome.

Teams that do get through a transition like this rarely win by piling on more automation. They win by shrinking anxiety — a parallel-run period where both systems stay live — and by porting old shortcuts into the new tool before asking anyone to give them up.

Why "Just Add More Pull" Fails Even When Your Product Really Is Better

The most common mistake in low-adoption postmortems is treating the problem as a pull problem and responding with more features, better onboarding copy, or a flashier launch — while anxiety and habit stay exactly where they were. Everett Rogers' Diffusion of Innovations research found that an innovation's adoption speed correlates more strongly with perceived compatibility and low complexity than with its raw technical superiority.

In other words, Rogers was describing anxiety and habit decades before the JTBD vocabulary existed. A feature that is "objectively" faster but requires relearning a workflow, migrating data, or convincing a skeptical teammate is competing against forces the roadmap never touched.

Three questions expose which force is actually blocking your "better" feature:

1. Is push actually shared, or just felt by you? A pain point your team feels acutely (dashboard load time) may barely register for the user still on the old workflow.
2. Is pull vivid in the user's specific context, or only in your demo? A feature that looks great in a sales deck can feel abstract until it's mapped to the user's actual situation.
3. What would the user have to unlearn, undo, or explain to a colleague to adopt this? That's your habit tax, and it's rarely zero.

Why RICE and Kano Scores Miss This

RICE (reach, impact, confidence, effort) and Kano prioritization are built to rank what customers want, not to explain why they haven't adopted something they already have access to. A feature can score high on RICE — large reach, strong impact, high confidence — and still sit unused, because none of those four inputs measure anxiety or habit.

Kano gets a little closer by separating "must-have," "performance," and "delighter" attributes, but it still assumes the customer will notice and adopt the attribute once it ships. Neither framework asks the two questions that actually predict adoption: what is this person afraid of, and what do they already know how to do instead? The Forces of Progress lens is meant to run alongside prioritization scoring, not replace it — a high-RICE feature with high anxiety needs a rollout plan, not just a launch date.

The counterintuitive lever, backed by both the JTBD literature and Rogers' diffusion research, is this: reducing anxiety and habit is usually cheaper and faster than adding more pull. A migration wizard, a reversible setting, or a "keep your old shortcuts" bridge often moves adoption more than a new capability nobody asked for.

How to Map the Four Forces for a Feature You're Struggling to Land

Mapping the four forces for a specific feature means running structured interviews with recent switchers (and non-switchers), then plotting what pushed them, what pulled them, what scared them, and what they had to give up. This turns a vague "adoption is low" complaint into four concrete, separately fixable problems.

A practical sequence:

1. Interview 8-12 people along a timeline, from "first thought" of change through the decision to switch (or not). Anchor the interview to the customer journey emotion curve so you capture the moment doubt or relief actually occurred, not just the final outcome.
2. Write down every force verbatim, in the customer's language. "I didn't want to be the person who broke the report" is a habit-and-anxiety statement, not a feature request.
3. Translate the pattern into a proper job statement using the JTBD job statement format, so the situation, motivation, and desired outcome are separated from your product's feature list.
4. Score the opportunity, not just the demand. The opportunity score formula tells you which underserved outcomes are worth resourcing — but pair it with the forces map, because a high-opportunity job with high habit-and-anxiety resistance needs a different plan than a high-opportunity job with low resistance.
5. Check for reinforcing loops that entrench habit. If a workaround gets praised in a team standup every time it "saves the day," that's a self-reinforcing loop worth diagramming with the causal-loop approach from our systems thinking guide — habit is rarely a single behavior, it's a small system defending itself.
6. Hand the forces map to engineering intact. A finding like "anxiety spikes at the data-migration step" needs to survive the handoff as a testable requirement (a preview mode, a rollback button), not get flattened into a generic ticket — see how job statements survive the engineering handoff for the format that keeps the nuance.

Some teams turn this into a recurring ritual — a twenty-minute "forces retro" after each notable launch, reviewing what pushed adoption, what pulled it, and what almost stopped it — instead of treating force-mapping as a one-off exercise reserved for big migrations.

Done well, this process stops treating "low adoption" as one problem. It becomes four separate, comparably-sized problems, and the cheapest fix is usually not the one at the top of the backlog.

Where Prodinja Fits: Seeing Momentum vs. Inertia at a Glance

The point isn't a magic score — it's a shared, visual way for a team to see whether momentum or inertia is currently winning for a specific feature, before more roadmap time gets spent adding pull to a problem that's actually anxiety or habit. You can inspect the same underlying job statements, opportunity scores, and forces side by side rather than juggling four separate interview transcripts.

Because the read sits next to the same job statements and opportunity scores you built earlier in the flow, it's designed to keep the conversation anchored in what customers actually said, rather than a gut feel about which force "must" be the culprit.

Key Takeaways

• The Forces of Progress framework (Christensen, Moesta, and Dillon) explains switching as a tug-of-war between push and pull (forward) versus anxiety and habit (backward), not a simple feature comparison.
• Loss aversion and status quo bias research suggest inertia has a built-in advantage — a switch has to feel clearly net-positive, not just marginally better.
• The most common roadmap mistake is treating every adoption problem as a pull problem and shipping more features while anxiety and habit stay untouched.
• Everett Rogers' diffusion research found compatibility and low complexity predict adoption speed better than raw technical superiority — a direct echo of anxiety and habit.
• Reducing anxiety (reversible trials, migration wizards, visible undo) and habit (bridging old shortcuts, targeting reinforcing loops) is often a faster lever than adding more pull.
• Mapping all four forces for a specific feature turns a vague "adoption is low" complaint into four distinct, separately solvable problems.