How to start a sales call

You can now preorder my book on Amazon – HEYO! Here’s the link!

And here’s this week’s podcast, our last podcast of the year. We talk about this post (and my fight to keep the part about raccoon breeders in the book).https://open.spotify.com/embed/episode/5nm0nxRxZDJPwj05xgZkf9

If you read any sales book, you’ll see that the first part of a sales call – or even the whole first call – is supposed to be this very important thing called “discovery.”

In this “discovery” thing, we are supposed to ask questions. The prospect should respond with words. Their words should inform our pitch and demo.

At a high level, this makes sense. But what questions should we ask? What are we trying to learn?

I have now watched roughly 3,000 sales calls from startups, scaleups, and “normal” companies… and it’s clear that nobody really knows. Founders don’t know, sales reps – even experienced ones – rarely know, and prospects sure as hell don’t know.

When we fix this, our startups tend to take off. The new fastest-growing startup I’ve helped ($0-$6M in < 3 months)1 attributes “knowing exactly what to look for in discovery” as the thing that helped them (1) figure out what product to build, and (2) scale super fast as a result of knowing what product to build and how to sell it.

Unfortunately, sales playbook templates you’ll find out there don’t help with this. Most of the sales call playbooks I’ve seen come from companies where either:

They have such intense product-market fit & such a strong brand that they could ask prospects to lick sandpaper and they’d still buy
They have so much bottom-of-funnel inbound that they are mostly doing order-taking, not selling
The sales leader has figured out a few killer questions / signals in their situation, but their playbook doesn’t generalize

As a result, it’s not really clear what we’re looking for. So we often act as if discovery is (1) a checkbox exercise we’re supposed to do before we demo so our sales coach is happy, and/or (2) a blind search for something problem-shaped we can pitch a solution to.

And so this “discovery” thing turns into a game of whack-a-mole, where we ask a potpourri of random questions across these categories:

Open-ended questions about their current state, pain points, and problems… we learn interesting things that are mostly irrelevant (see: “the problem with problems”)
Leading questions that try to paint them into a corner to logically convince them to want our product: if you could increase revenue without lifting a finger, would you?
Questions about the supply they want, not the demand they have: which gives us a list of features they may or may not need (see: “building the right product”)
Questions from a qualification framework (like BANT or MEDDPICC)… it turns out, asking about “budget” or the “economic decisionmaker” (1) before you understand what they want and (2) before they understand what you do is awkward and offensive to your average prospect.

Prospects get annoyed with these questions, but can’t explain why they’re annoyed. They often ask to “just see the product” to skip what feels like an interrogation by Dory from Finding Nemo.

Then they get even more annoyed, because we pitch and demo something that doesn’t even try to fit their needs. Our pitch goes something like:

Here’s the $900b problem we’re solving in the world
Here’s why it’s even more urgent now and why you should want to solve it
Here’s why we’re solving it
Here’s our theory on the problem, its root causes
Here’s the overview of the solution, our rationale for it, and why it’s differentiated
Here’s how the product works at a detailed technical level

The pitch is designed around an abstract problem that buyers don’t actually have… or sometimes around a problem they agree exists, but isn’t what they’re trying to accomplish right now (or why they scheduled the call). So basically, the entire pitch is a mostly irrelevant lecture.2

Many slides / minutes / screens into this, the prospect is mostly confused and frustrated. They might express this, or they might politely ask a few questions and disappear.

My rough estimate is that founders waste ~75-90% of the time in their average sales call. I wish I was overstating this. It is hard to see because prospects are generally polite. If we could read their minds, we would be horrified.

In many cases, when buyers buy, they buy despite most of our sales call, not because of it – and they usually buy for reasons we don’t understand (which, of course, leads to product & retention issues)!

So what do I do?

First, we need a discovery framework – so we know what we are actually looking for.

Then we need a discovery process – so we fill out the framework by default in every call.

Here’s my attempt. (This is a major renovation to my approach to sales calls highlighted two years ago in my Harvard Innovation Labs deck.)

PULL is a discovery framework

Turns out, you can just use the PULL framework for your discovery framework.3

A refresher on PULL:

PULL is, I believe, the most important concept in startups and business. It is the hidden load-bearing wall that explains why some products take off but others don’t, why customers really buy things, and what is the “shape” of a new thing is needed in the market.

There are four elements of the PULL framework:

There is the project on a potential customer’s to-do list, which is being prioritized now.

There is a reason the project is urgent or unavoidable now, versus all the other projects they could prioritize on their to-do list’s infinite backlog. They are in some sort of situation where they would be weird if they didn’t prioritize this project!

They consider a list of options for accomplishing this project they’ve prioritized. These options are not just our direct competitors – they might be technologies, hiring, or a variety of other things.

But, the options they consider have severe limitations that prevent the potential customer from making the kind of progress they’re trying to make.

— The PULL Framework, In Detail

You should have this framework in your head – even in a doc – which you are filling out on a call. You are trying to understand:

What exactly are they trying to accomplish? (The “project” on their to-do list)
Of all the things they could prioritize, why this thing, and why now? (Why it’s “urgent” or “unavoidable”)
What have they looked into and/or tried so far? (Their “list” of options)
Why aren’t those things good enough? (The “limitations” of their options)

PULL is the minimum essential information to know what they want – whether the deal is outbound, inbound, SMB, enterprise. Once we know PULL, we know what to offer – something that fits their PULL, with no extraneous concepts / screens / words!

Let see this in a full example:

Imagine you’re building an AI tool for cloud infrastructure.

During a sales call, a prospective customer says something like this:

“Yeah so we need to move our MVP from Vercel to something more serious because we’re scaling now and have outgrown Vercel, and so we are considering bringing in a DevOps consultant to help us build our new platform.”

Based on this quote, I fill out their PULL framework like this:

P = Move product onto “serious” infrastructure (?)

U = Scaling, have “outgrown” Vercel (?)

L = DevOps consultant

L = (?)

I’ve put question marks next to things I don’t really understand. What does “serious” mean to them? What does it mean to have “outgrown” Vercel to them? And why isn’t a DevOps consultant good enough?

Based on the framework and the question marks, I know what I need to ask to fill out their PULL framework and have confidence I can pitch the right thing.

I might learn:

Scenario A: “Serious” infrastructure is, in their mind, infrastructure-as-code on AWS/GCP. They have “outgrown” Vercel because their backend has some specific needs that Vercel can’t support. And the DevOps consultant is quite expensive ($30k+).
Scenario B: Scenario A but with one difference: I’m worried we’re not going to be able to maintain what the DevOps consultant gives us.

Given A, we would describe our product as “a way to create serious custom infra you can trust, at the same quality level as a DevOps consultant, for <10% of the cost.”

Given B, we would describe our product slightly differently, as “a way to create serious custom infra you can trust, at the same quality level as a DevOps consultant, but it’s basically self-managing so you don’t have to worry about maintaining it.”

Importantly, describing anything other than this gives the potential customer more things to think about – and these extra things are not directly related to their PULL. The more random things they have to think about, the less likely they are to decide and buy from me.

Given either of the above scenarios, what do we need to demo? Maybe nothing! Maybe just the description is enough! Or if we need to demo something, we could show:

Scenario A: Something that indicates that we can create serious infra – e.g., a cloud infra diagram our product generates.
Scenario B: Probably the diagram plus something to indicate that it is mostly self-managing (e.g., infra alert + AI suggestion + simple “yes/no” for the engineer)

—

When we know that we only need to fill out the PULL framework, we can skip the unhelpful questions and run super-tight discovery. Discovery might take 20 minutes or it might take 5, but it’s at least pointed in the right direction!

Plus, having the PULL framework is nice because we know what we’re looking for – if they don’t have PULL, they’re not going to buy and we don’t have to waste a bunch of effort following up with them!

(Note that after we’ve filled out the PULL framework, we will likely need to add a few qualification questions from BANT/MEDDPICC or another qualification framework, but that often comes between (1) us giving a conceptual overview of our supply, and (2) them saying that our supply sounds like it fits their demand.)

Discovery process to find PULL

Cool – now how do we put this into practice?

I have been experimenting in my own sales calls to figure out how to consistently get prospective customers to fill out the PULL framework.

Here’s my recommended playbook:

Start the beginning of the call asking them why they took the call and what they are hoping to get out of it. This is now required for all of your calls – outbound or inbound. They will often fill out some piece of the PULL framework, and you can just double-click into the other pieces.
If they don’t fill out some piece of the PULL framework for you from that question, ask 1 or 2 discovery questions, trying to get them to explain some piece of their PULL to you. For example: “As it relates to QA and release cycles, what are you trying to change in the near term?” (This performs much better than a very open-ended “what are your priorities?” question.)
If that gets you nowhere, talk about what others have said, and see if that rings a bell. You might have a “demand slide” where you show what other people’s PULL has been. Ideally they say something that gives you a hint of their PULL; if not, say “huh, seems like you’re all set then?”
If that gets you nowhere, you can end the call early or “YOLO-a-demo” (show the product/pitch and see if any PULL-related synapse fires). If you do YOLO-a-demo, remember that anything they say could help you fill out the PULL framework!

The flowchart looks like this:

If they have PULL, this should get it out of them. If they don’t have PULL, well, that’s a different problem.

PS: Work with me!

If you’re a B2B founder trying to figure out exactly why customers aren’t consistently ripping your product out of your hands, I am your guy. Three ways I do this:

PMF Camp is my bootcamp (next starts early Feb), where we focus on generating product-market fit and rapid growth… and avoiding getting stuck. We watch founders’ sales calls and learn how to see what customers really want, and based on that, what to pitch, how to pitch, and how to sell.

I’ve just completed a few Sales Call Teardowns for startups (pre-product to $25M+ ARR), where they feel like potential customers should be ripping the product out of their hands, but something is off in the sales call and they need help understanding exactly what it is and how to fix it. I give a brutally honest diagnosis, then we work together to quickly fix your sales call, pitch, demo, execution, etc.

And finally, I’m doing more general PMF-focused advising with a few startups at a time. If you want my ongoing help debugging everything on the path to PMF – demand, product, growth motion – this might be a fit.

Originally posted on the How To Grow substack

How to start a sales call