Push Forces: The Situational Pain That Starts Every Switch

A push force is the specific, dated pain inside a customer's current situation — the moment reality became bad enough that they started actively looking for an alternative. It's separate from pull, the appeal of your new solution. Without a strong push, even a brilliant pull rarely triggers an actual switch.

Push is the pain of "today," not the promise of "tomorrow." It shows up as a dated, specific event, not a mood. A weak push produces browsing. A strong push produces buying.

What a Push Force Actually Is (and Isn't)

A push force is the situational pressure that makes the status quo untenable — a missed deadline, a public mistake, an escalating cost that finally crosses a line. It's one of four forces that Clayton Christensen's Jobs-to-be-Done research calls the Forces of Progress, and it always precedes the search for a solution, not the other way around.

Christensen, Taddy Hall, Karen Dillon, and David Duncan formalized this model in Competing Against Luck (2016), building on decades of case work including the famous McDonald's milkshake study. Bob Moesta, who ran that original research alongside Christensen, later built the interview methodology PMs use today to surface push in practice. If you haven't worked through the core theory yet, the complete guide to Jobs-to-be-Done is the right place to start before digging into forces specifically.

Christensen's own oft-repeated estimate, referenced throughout the book, was that roughly 30,000 new consumer products launch in the U.S. every year, and independent industry tallies (Nielsen among them) have long put failure rates for new products well above half. A mismatched Forces of Progress read — strong pull, weak or absent push — is a recurring explanation for why.

The four forces work in opposing pairs:

A switch only happens when push plus pull outweighs anxiety plus habit. Push and habit both describe the current situation, just pulling in opposite directions; pull and anxiety both describe the new option, also pulling opposite ways. Most product teams over-invest in pull — sharper features, better messaging — while badly underestimating how much habit alone can hold a customer in place. Push is the force that breaks that inertia first.

Why PMs Habitually Underweight Push

Roadmap conversations are naturally pull-heavy: teams talk about their own product, their own roadmap, their own differentiation. It's far more comfortable to discuss what you're building than to sit with a stranger's bad week. Christensen's central critique in Competing Against Luck was that most companies study their products obsessively and their customers' struggles barely at all.

That bias shows up in discovery too. A PM who asks "what do you think of the current tool?" gets opinions about the product. A PM who asks "what happened right before you decided to look elsewhere?" gets the push. The second question is harder to ask because it requires sitting through an uncomfortable, specific story instead of a tidy rating.

Push Is Not the Same as a "Pain Point"

A generic pain point ("the export is slow") is a complaint. A push force is causal and dated: it's the specific event that made the complaint intolerable. Someone can be mildly annoyed by slow exports for years without switching — until the day slow exports cost them something they cared about in front of people who mattered.

This distinction matters because pain-point language tends to arrive as a feature request, which sends discovery down the wrong path. Push forces arrive as stories, with a "when" and a "who else was there." Treat feature requests as a hypothesis to test, and treat stories about a bad day as the primary data.

How to Elicit Push in a Discovery Interview

You surface push by anchoring the conversation in a specific past event rather than a general opinion, then walking backward through what actually happened. The single best opening question is some version of: "Tell me about the day you first started looking for something else." Everything else in the interview should trace back to that moment.

Anchor on a Date, Not a Feeling

Interviewees default to describing traits of your product ("I like that it's simple") because that's easier than reconstructing a memory. Your job is to keep pulling them back to the timeline:

• "What day was that, roughly?"
• "Where were you sitting? Who else was in the room or on the call?"
• "What had you just tried, right before that, that didn't work?"
• "What would have happened if you'd done nothing that week?"

Each of these questions forces specificity. Specificity is what separates a real push force from a rationalized, after-the-fact justification for a purchase the customer had already decided to make.

The JTBD Interview Timeline

Bob Moesta and Chris Spiek's timeline technique — developed at the Re-Wired Group and widely taught in JTBD practitioner circles — breaks the path to purchase into five stages. Push forces cluster at the first two.

This timeline overlaps closely with how you'd map a broader customer journey end to end, except here you're deliberately zooming into the seconds before "First Thought" — because that's where the push force lives, often unspoken until you ask directly.

From Raw Quote to Push Force

Here's what the transformation looks like in practice. An ops manager at a mid-size logistics company might tell you, in passing: "Yeah, the spreadsheet's been a pain for a while." Left there, that's a mood, not a push force — too vague to act on.

Pushed further ("what's the most recent time it was a pain?"), the same person says: "Two weeks ago, a formula shifted and our client-facing utilization report understated capacity by 20 percent. My director had to send a correction to the client the next morning." That's a push force: dated, witnessed, costed.

The write-up should preserve all three: the trigger event (formula error), the visibility (director, client), and the cost (a public correction). Stripped of any one of those, it degrades back into a generic complaint that's easy to deprioritize later.

Weak Push vs. Strong Push: What Actually Predicts a Switch

Not all push is equal, and treating a mild irritation the same as a career-threatening failure is the most common scoring mistake in discovery. A weak push is vague, private, and low-cost to ignore. A strong push is specific, witnessed by other people, and attached to a cost the customer can name.

Three tells reliably mark a strong push in an interview:

1. The story has a witness. Someone else saw the failure — a manager, a client, a board. Public failure changes urgency in a way private frustration never does.
2. The customer can name a cost. Not "it's annoying," but a number, a lost deal, a missed deadline, or a person who was upset.
3. The timeline is tight. Strong push moves someone from "first thought" to "active looking" in days, not months.

Moesta's own case studies — the mattress-buyer research is the best known — follow this pattern closely: the push wasn't "my back hurts a little." It was a specific week where the pain became visible to a spouse and started interrupting work. That's the level of specificity to listen for.

If the story doesn't have a witness or a cost attached to it, treat it as an opinion, not a push force — and keep digging until you find the dated event underneath it.

Common Mistakes That Blur the Push Signal

Teams most often lose the push signal by measuring general satisfaction instead of specific switching behavior, and by interviewing customers well after the purchase decision was already locked in. Both habits produce data that looks precise on a dashboard but explains almost nothing about why any particular person actually moved.

Watch for these five patterns:

• Relying on NPS or CSAT as a proxy for push. Satisfaction scores measure how someone feels about the status quo in general, not whether a specific event just made it untenable. A 6-out-of-10 score tells you nothing about last Tuesday.
• Confusing push with a feature request. "I wish it had X" describes a workaround, not the moment that made the workaround necessary. Ask what happened right before the wish showed up.
• Interviewing well after the purchase. Memory reorganizes itself around the decision that was made; you get a tidy, rationalized narrative instead of the messy, true one. Interview as close to the switch as you can get.
• Ignoring habit as a competitor. If push feels weak, it's often because habit and sunk cost are doing more work than anyone in the interview is willing to admit out loud.
• Writing the finding as an adjective, not a job. "Users are frustrated" isn't actionable. A push force belongs inside a proper job statement, where it's tied to a specific struggling moment and outcome.

Turning Push Into a Roadmap Decision

A push force only earns its keep once it changes what you build or how you prioritize — which means it has to survive the trip from interview transcript to backlog. That means writing it into a structured job statement, weighing its strength against pull and anxiety, and preserving the original context for engineering.

A simple five-point rubric makes push strength comparable across interviews instead of leaving it as a gut feel:

1. No push detected. Customer is content; no story of looking elsewhere exists.
2. Mild irritation. A recurring annoyance is named, but nothing dated or witnessed.
3. Situational trigger. A specific dated event occurred; passive looking has started.
4. Active searching. Customer has already compared at least one alternative.
5. Public cost. A witnessed failure or loss occurred; buying is likely within weeks.

Score every interview this way and patterns across a segment become visible fast — including whether the segment you're excited about actually has enough level-4-or-5 stories to justify the bet.

Once you've captured push, pull, anxiety, and habit for a segment, you're set up to score the opportunity, not just describe it. That's the same territory covered in how the opportunity score formula weighs importance against satisfaction gaps, an approach with roots in Tony Ulwick's outcome-driven innovation work — push forces are the qualitative complement to that quantitative gap.

Push forces also frequently turn out to be symptoms of something structural in the customer's organization — a broken handoff between two teams, a metric that rewards the wrong behavior. When a push force keeps recurring across interviews in a similar shape, it's worth mapping the surrounding causal loop rather than treating each instance as isolated; that's the kind of pattern systems thinking is built to expose.

And because push forces carry the "why now," they're the detail most likely to get stripped out during handoff — leaving engineers to build the feature without understanding its urgency. Preserving that context is exactly what's covered in making job statements survive the engineering handoff.

Where Prodinja Fits

Key Takeaways

• A push force is the specific, dated pain in a customer's current situation that starts the search for an alternative — distinct from pull, the appeal of your solution.
• Push works alongside three other forces — pull, anxiety, and habit — in Christensen's Forces of Progress model; a switch happens only when push plus pull outweighs anxiety plus habit.
• Elicit push by anchoring interviews on a specific date and event ("the day you decided to look"), not general opinions or satisfaction ratings.
• A weak push is vague, private, and low-cost to ignore; a strong push is specific, witnessed by others, and tied to a nameable cost.
• Feature requests and satisfaction scores routinely disguise the absence of real push — always ask what specific event made the status quo intolerable.
• Push only becomes actionable once it's written into a proper job statement and scored alongside the other forces, so it survives the trip to the roadmap.