By 6days · v1.0 · Updated 7/20/2026
Four kinds of question that let a buyer talk themselves into the size of their problem.
Fill this in for your own situation — a private worksheet only you can see.
When to use
Use it in considered, higher-value sales where the buyer has a real problem they have not fully priced, and where the purchase requires internal justification. It is especially strong when your advantage is genuine but not obvious in a feature comparison.
When not to use
Avoid it in low-value transactional selling, where the buyer knows what they want and the questioning reads as an obstacle between them and a purchase. It fails when the buyer has already diagnosed themselves and wants a price — implication questions asked of a decided buyer feel like manipulation, because at that point they are. It also requires real preparation; run cold it produces an interrogation.
A seller who explains why their product is excellent gets polite agreement and no purchase. Buyers do not act because a solution sounds good; they act when a problem feels expensive enough to be worth the disruption of fixing. Telling someone their problem is expensive rarely persuades them. They have to arrive there themselves, and most sales conversations never create the conditions for that.
SPIN structures discovery around four question types asked in rough sequence: situation questions to establish facts, problem questions to surface difficulties, implication questions to expose what those difficulties cost, and need-payoff questions that invite the buyer to articulate the value of solving them. The engine is the implication stage — it converts a mild annoyance into a quantified business problem, and it does so in the buyer's own words, which is why it survives their internal review after you leave the room. The corresponding discipline is restraint: the seller's job is to ask, not to pitch.
Framework by 6days on 6days — https://6days.apexaion.ai/framework/spin-selling
An ordered process with 4 phases.
Establish the facts you genuinely need — sparingly.
Surface the difficulties, gaps, and dissatisfaction.
Develop what those problems actually cost.
Let the buyer state the value of solving it.
Establish the facts you genuinely need — scale, current tools, process, who is involved. Research everything you can beforehand. Situation questions bore buyers and buy you no credit, so the fewer you need, the better prepared you look.
Probe for what is not working: where things break, what is slow, what is manual, what people complain about. You are looking for dissatisfaction, not gaps in your feature coverage. Resist the reflex to solve the first problem you hear.
Take a surfaced problem and follow it outward. What does that delay do downstream? Who else is affected? What has it cost this year? This is the step sellers skip because it feels uncomfortable — and it is the step that does the actual work.
Invite the buyer to describe what solving it would be worth: what changes if this goes away? A benefit you assert is a claim to be checked. A benefit the buyer articulates is a position they will defend to their own colleagues.
Present your solution against the problem they have now sized, in their language and their numbers. Everything you say here lands against a need they built, which is why it is heard as relevant rather than as a pitch.
Worked example
A field-service software rep meets an operations director. Situation: 40 engineers, paper job sheets, manual scheduling. Problem: sheets arrive late and some never arrive. Implication: how long until an unbilled job is noticed? Six weeks. What share never get billed? Perhaps 3%. On what revenue? £8m. Who chases them? Two admins, most of a week each month. The director has now said, unprompted, that paper is costing roughly £240k a year plus most of two salaries. Need-payoff: what would same-day billing be worth? The rep has still not mentioned the product, and the business case is already written — by the buyer.
The model was published by Neil Rackham in the late 1980s, drawing on a large observational study of sales calls conducted by his research organisation. It is unusual among sales methods in having been derived from recorded behaviour rather than from a successful practitioner's intuition. The named method and its book are the author's commercial work; this description is our own.
Related ways to think about this.
A jointly owned, dated plan from here to live — so the deal has no invisible middle.
Use when Use it on complex deals with long cycles, multiple approval gates, and implementation work after signature — especially where you have been burned by late-stage procedural slippage or where the buyer has a hard date they must hit.
Avoid when Avoid it on small or fast transactions, where it is bureaucratic overhead the buyer will resent. It is worthless if it becomes a seller-authored document emailed for agreement — that is a project plan with a friendly name, and it will not predict anything. And it cannot fix a deal with no genuine urgency; it will simply document the drift precisely.
Lead with a commercial insight that reframes the buyer's problem, rather than asking what keeps them up at night.
Use when Use it in complex B2B sales where you have genuine cross-customer data the buyer lacks, where the competition is undifferentiated on features, and where the real enemy is the buyer's inertia rather than another vendor.
Avoid when Avoid it when you have no real insight — performed without substance it is just contrarianism, and buyers detect it immediately. Avoid it with sophisticated buyers who know their domain far better than you, where a reframe reads as condescension. It also demands enablement most sales organisations do not have: the insight must be built centrally, because individual reps cannot see across the customer base.
A checklist for whether a complex deal is real, before you spend a quarter finding out.
Use when Use it on high-value B2B deals with several stakeholders and a long cycle, especially where forecast accuracy matters and pipeline reviews have become exercises in optimism. It is most useful as a shared vocabulary that lets a manager ask 'what don't we know?' without it reading as an attack on the rep.
Avoid when Avoid it in transactional or self-serve sales, where the overhead exceeds the deal value and there is no committee to map. Applied mechanically it becomes a CRM compliance ritual that reps fill in after the fact, which produces the paperwork and none of the thinking. It also qualifies deals; it does not create them.
