Reference file

pull-framework.md

pull-framework-md.md

The PULL Framework

The canonical reference for the PULL framework. Skills that apply PULL to a specific input (call transcript, ICP, pitch, outbound, demo) load this file as their source of truth on definitions.

What PULL is

PULL is a mechanistic, predictive model of why buyers buy. It is both the physics and logic of a purchase. It is not a heuristic, not a sales technique, and not a description.

Specifically: It is a falsifiable claim about the conditions under which it would be weird if a purchase action didn't happen. In all other cases, it would be weird if a purchase action DID happen.

PULL's claims about reality

There are infinite things a buyer could do at any one point in time. But at any one point in time, they can only do one thing.

When a buyer does any one thing, they can do this by means of infinite ways other than purchasing the seller's product.

Which means in any one moment, it would be weird if the buyer bought the seller's product. Even if they have pain points or problems (because they might not take action on these things; they have infinite things they could do). Even if they are prioritizing something relevant (because they can take action on it in infinite ways other than buying the seller's product).

Which means that almost all of the time, a buyer COULD buy the seller's product… but it would be weird if they bought the seller's product. But occasionally - when they are prioritizing something relevant and don't have good-enough options, so they are blocked from doing the thing - and the seller's product can unblock them - they would be weird NOT to buy.

PULL = One situation with four conditions

PULL describes a situation that a buyer is in, where it would be weird if they didn't buy a product. There are four criteria to the situation, where if they are all not present, the buyer could buy, but it would be weird.

1. Project (P)

A project is a "job-to-be-done", and makes sense as an Asana or Trello project. There are different levels of abstraction for Projects -

Project examples:

  • "Minimize my time spent taking client meeting notes"
  • "Pass our SOC 2 audit"
  • "Stop losing 30% of trial users in the first week"
  • "Get the new pitch in front of every rep before next Monday's pipeline review"

A Project is not:

  • A desire/need for a product or service ("we want a CRM by Q3") - projects are product/service-agnostic, in that they must exist independent of solutions.
  • A pain point ("we're frustrated with manual reporting") - because this is not talking about action.
  • An interest in the seller ("we'd love to learn more about your product")
  • A goal or outcome ("we'd like to grow faster," "we need to hit our number") - these are end-results of hitting a project, and may fit into why a specific project is Unavoidable.

The test: Is there a P for which U and LL are true? (If so, PULL passes).

2. Unavoidable (U)

There are infinite Projects a buyer could pursue at any moment, but only finite hours and attention. For PULL to exist, this Project — the one named in P — must be one the buyer would be weird not to prioritize as their top priority right now. The structural logic of their situation makes it weird if they didn't do this.

U is always relative to a specific P.

Unavoidability comes from things like:

  • Regulatory or legal forcing functions ("we'll fail the audit and pay fines")
  • Constraints-based business logic ("if we don't do this, nothing else matters")
  • Public commitments with deadlines ("I promised the board this ships in Q2")
  • Cascading dependencies ("we can't hire reps until we've nailed the pitch")
  • Personal / identity / emotions (career, identity, things the buyer can't walk away from being)

Unavoidability is not:

  • The buyer being interested or even excited
  • The buyer agreeing the Project is "important"
  • The buyer saying "this would be great to fix"
  • The buyer specifying ROI or value or pain this would solve.

The test: Is there a specific reason that makes it weird if the buyer doesn't do this project now? (If so, U passes.)

3. List of options + Limitations (L+L)

The buyer has considered or tried ways to accomplish the specific Project named in P — DIY, competitors, workarounds — and each one has at least one specific Limitation that prevents it from getting them there. The List does not include what the seller is selling. PULL is generated by the gap between what the buyer needs (to accomplish this Project) and what their existing options can deliver.

L+L is always relative to P. Options that fail for one Project may be fine for another. "Hire more reps" might be a failed option for "ship the new sales script by Friday" (wrong timeframe, wrong leverage point) but a perfectly good option for "increase pipeline by Q3." The Limitations only make sense relative to what the Project actually requires.

Examples (each tied to a specific Project):

  • Project: cut notetaking time. Option: generic AI notetaker. Limitation: doesn't sync to our CRM, so still requires manual transfer.
  • Project: hit Q3 number. Option: hire two more SDRs. Limitation: budget freeze through Q3.
  • Project: pass SOC 2 by August. Option: keep doing it manually with the consultant. Limitation: he says we won't be ready in time.

L+L requires:

  • Specific options the buyer has actually considered or tried, for this Project
  • Specific reasons each one fails, for this Project

L+L is not:

  • The buyer expressing dissatisfaction in general
  • The seller listing competitors and explaining why they're worse

The test: can you name one or more options the buyer has considered, with one concrete failure mode each, all for this specific Project, in the buyer's words? (If so, LL passes.)

4. Product is positioned as a thing that unblocks PULL

The PULL criteria expose a buyer stuck in a situation where they are blocked from doing P because of LL. The buyer would be weird not to buy the seller's product ONLY IF it unblocks them from LL and enables them to do P.

This condition is about the seller's positioning (description of the product), which is the only condition the seller controls. Conditions 1-3 are facts about the buyer's situation that exist before the call and persist after. Condition 4 is whether the seller positioned their supply as the unblocking force.

Product fitting PULL means:

  • The positioning addresses the specific Project (not adjacent ones)
  • The positioning directly resolves the named Limitations of the buyer's named options
  • The positioning is the smallest version of supply that does this — no extraneous capabilities

Product not fitting PULL means:

  • The positioning is feature-led ("here's what we do" or "here's how it works")
  • The positioning addresses a different Project than the one the buyer named
  • The positioning piles on capabilities that aren't asked for and aren't needed

The test: Does the product unblock LL so the buyer can do P? (If so, Positioning passes.)

What a PULL action looks like

When all four conditions are met, the buyer initiates a forward action during the call without the seller prompting it. Two flavors count:

Purchase action (strict):

  • Asks for pricing
  • Asks for the link / contract / order form
  • Asks how to start
  • Asks who to send payment to

Unprompted urgent next step (looser, but still counts):

  • "Can you meet with my CTO tomorrow?"
  • "I want to bring this to my team this week — when can you do it?"
  • "How fast can we get this in?"

The asymmetry that matters: the buyer must initiate. If the seller says "should we book a follow-up?" and the buyer says "sure, next week works," that is not a clear PULL action. The deal could still close, but it is unclear whether there is real PULL there.

What does not count, regardless of how warm it sounded:

  • "Let me think about it"
  • "Send me more info"
  • "I'll loop in my team and get back to you"
  • "This is interesting"
  • Any next step the seller suggested first

Common false positives (fake PULL traps)

These are the failure modes where the framework looks satisfied but isn't. Watch for them.

Incoherent PULL. Three boxes get checked but they belong to three different situations — Project from one thing, Unavoidability from another, L+L from a third. PULL is one thing, not multiple different things.

Altitude inflation in P. Strategic outcomes ("hit Q2 number," "find PMF") get labeled as Project. They aren't — they're so-whats. The Project is the actionable thing the buyer would do this week toward those outcomes. If the candidate Project can't be put on a calendar this week, it's the wrong altitude.

Product-talk masquerading as Project. "We need a CRM by Q3" is not a Project — it's a buyer who has already decided which category of supply they want and is shopping. The underlying Project (the demand-side thing) is unstated. If you can't restate the Project without naming a category of product, you don't have a real Project yet.

Importance masquerading as Unavoidability. Buyers will say things are "important" or "a priority" because it's polite and because they believe it in the moment. Unavoidability is structural — there is a consequence of not doing it. "Yes, this is important to us" is not Unavoidability. "We will lose the contract if we don't fix this by April" is.

Dissatisfaction masquerading as L+L. A buyer venting about how nothing works is not the same as having considered specific options with specific limitations. L+L requires named options and named failure modes, all relative to the specified P. Generalized frustration does not generate PULL — it generates conversation.

Interest masquerading as recognition. "Interesting," "this looks great," "I like what you're doing" are interest-shaped responses, not recognition-shaped ones. Recognition sounds like "yes, this is exactly what we need" or "so this would solve [specific Limitation]" — language that connects supply to the named Project and Limitations and . If the buyer is praising the product without connecting it to their situation, that's a flag.

Prompted next step masquerading as PULL action. As above — if the seller suggested the next step first, even by hinting, it is not a PULL action.

pull-framework.md - PULL call review - GTM Skills