SPIN Selling for Engineers and Founders: Discovery Questions and a Sales Call Checklist That Uncover Real Pain

If you're an engineer, a solutions engineer or a founder doing founder-led sales, discovery questions are probably the part of the sales call that feels least natural. You know the product cold, so the instinct is to explain it. SPIN selling is a sales framework that fixes that instinct by giving you four kinds of questions to ask, in a rough order, before you pitch anything. This post turns SPIN into a practical sales call checklist with example discovery questions, a worked example, and the mistakes engineers make most often.

What SPIN selling actually is

SPIN comes from Neil Rackham's book SPIN Selling. The idea is simple: in larger B2B sales, the questions you ask matter more than the pitch you give. SPIN groups those questions into four types:

• Situation: facts about how the buyer works today.
• Problem: where that way of working hurts.
• Implication: what that pain costs, and what it causes downstream.
• Need-payoff: what solving it would be worth, in the buyer's own words.

Engineers tend to like SPIN because it reads like debugging. Situation is reproducing the environment. Problem is finding the bug. Implication is measuring the blast radius. Need-payoff is agreeing on what "fixed" means before you ship a patch.

Situation questions: ask fewer than you think

Situation questions are the easiest to ask and the easiest to overdo. Every one of them is work for the buyer and gives them nothing back. Do your homework (website, LinkedIn, job posts) and only ask what you genuinely can't find.

Good situation questions:

• "Walk me through how a new rep gets ready for their first customer call today."
• "Who's involved when you evaluate a tool like this?"
• "What does the process look like between a lead coming in and a first meeting?"

Keep it to three or four. If you're ten minutes in and still asking about team size, you're running an interview, not a discovery call.

Problem questions: find where it hurts

Problem questions invite the buyer to name dissatisfaction. They are the bridge from "this is how we work" to "this is what bothers us."

• "Where does that process break down?"
• "What's the hardest part of that for your team?"
• "When a deal slips, what's usually the reason?"
• "What have you already tried to fix it?"

The last one matters more than it looks. If they've tried and failed twice, you learn what not to pitch and how much appetite is left.

A simple rule: when the buyer names a problem, don't jump to your solution. Write it down and go one level deeper.

Implication questions: the step everyone skips

This is where SPIN earns its reputation, and where most founders and engineers fall short. A problem on its own is a minor annoyance. A problem connected to revenue, time, risk or reputation is a priority.

Implication questions connect the dots:

• "When new reps take longer to ramp, what does that do to the quarter?"
• "If a rep fumbles a price objection on a first call, what happens to that deal?"
• "How much of your own time goes into covering for that?"
• "Who else feels it when this goes wrong?"

You are not trying to scare anyone. You're helping the buyer see the full size of something they've been living with. Often they've never said it out loud, and the moment they do, the conversation changes.

A warning: implication questions can feel manipulative if you fire them in a row. Ask one, listen, reflect back what you heard, then ask the next.

Need-payoff questions: let them sell it to themselves

Need-payoff questions ask the buyer to describe the value of solving the problem. The point is that they say it, not you.

• "If new reps could handle the common objections before their first live call, what would that change?"
• "What would it mean for you to get those hours back?"
• "If this was fixed by next quarter, how would you know?"

When the buyer answers these, you get two things: their success criteria, and the exact language to use when you finally show the product. Quote them back during the demo: "You said the biggest win would be X, so let me show you that first."

A worked example

Here's a compressed discovery call for a founder selling a developer tool, using all four types:

Situation: "How do you handle code review on your team today?"
"PRs go to one of two seniors."

Problem: "Where does that slow you down?"
"Reviews sit for a day or two. The seniors are swamped."

Implication: "When a PR sits for two days, what happens to the release?"
"We batch, then merge conflicts pile up, and Friday becomes cleanup day."
"And the seniors?"
"Honestly, one of them has mentioned burning out."

Need-payoff: "If reviews turned around the same day, what would that free up?"
"Fridays back, and I'd stop worrying about losing a senior."

Notice the pitch hasn't started. By the end, the buyer has described a retention risk in their own words. That is a much stronger opening for your demo than any feature list.

SPIN sales call checklist

Copy this into your call notes:

• [ ] Researched the account so I ask 4 or fewer situation questions
• [ ] Got at least 2 problems named in the buyer's words
• [ ] Asked "what have you tried?" for the main problem
• [ ] Asked at least 2 implication questions per problem, one at a time
• [ ] Heard who else is affected (other stakeholders)
• [ ] Got a need-payoff answer I can quote back in the demo
• [ ] Agreed what "solved" looks like before showing the product
• [ ] Booked the next step with a date

Common mistakes engineers make with SPIN

1. Treating it as a script. SPIN is a map, not a sequence to read top to bottom. If the buyer opens with a problem, go there.
2. Pitching at the first problem. The moment you hear a pain you can solve, the urge to demo is huge. Hold it for two more questions.
3. Skipping implication because it feels awkward. It is awkward at first. It's also the part that turns "nice to have" into "let's talk budget."
4. Answering your own questions. Ask, then stop talking. Silence after a good implication question is the buyer thinking, not a gap to fill.

Practice the questions before the call

Reading a list of discovery questions is easy. Asking an implication question calmly, while a buyer gives you a short, guarded answer, is a different skill. The only way it becomes natural is sales practice: role play with a teammate, record yourself, or run the same call several times until the follow-up questions come without thinking.

If you want to rehearse SPIN-style discovery calls against realistic virtual customers before the real one, that's what we're building at Kulissa.