DEV Community

Cover image for Sales for developers
Andrew Owen
Andrew Owen

Posted on

Sales for developers

This article originally appeared on my personal dev blog: Byte High, No Limit.

You're a developer. Have you ever wondered how the software you write gets into the hands of users? No, me either. In over 15 years in IT, I never gave a thought to the sales process. But in my role as a solutions engineer, I've had to take a crash course. And now I'm convinced that everyone who isn't sales should at least understand something about it. Fortunately, my MasterClass subscription is still valid, so I was able to take Daniel Pink's class on Sales and Persuasion. Previously, I watched the entire John Barrows YouTube sales tips playlist (if I hear someone say “make it happen” one more time, I'm going to scream). But unless you work at one of those companies where you're told “everyone is in sales”, you probably don't want to spend half a day watching those. So I'll reduce it down to the essentials for you.

Evaluating a prospect

In the 1950s, IBM came up with a sales strategy known as BANT that's still in use today:

  1. Budget: Can the organization you're selling to afford what you're selling?
  2. Authority: Can the person you're dealing with approve the purchase?
  3. Need: Does what you're selling solve the organization's problems?
  4. Timeline: When will a purchase decision be made?

If they can't afford or don't need what you're selling, thank them for their time and move on. If your contact can't approve the purchase, involve the person who can. If the decision is more than a year away, park it for now and revisit closer to the time.

Consecutive selling

It's time for another acronym. In the 1980s, Neil Rackham came up with a series of questions to use in large sales deals known as SPIN-selling that's still in use today:

  1. Situation: Ask about the pain points and expectations to determine goals and needs.
  2. Problem: Ask leading questions to identify problems, such as “how much time a day do you spend on that?”
  3. Implication: Ask about the consequences of the problems, such as “how much time does that waste a month?”
  4. Need-payoff: Ask questions to lead the prospect to their own positive conclusions, such as “if you could be more productive, what effect would that have on your revenue?”

There are four stages, but no acronym this time, unless you mistype PAID:

  1. Preliminaries: Introduction. Don't talk about your product or service.
  2. Investigation: Situation questions. Don't talk about your product or service.
  3. Demonstration of capabilities: Implication and Need-payoff questions. Talk about your product or service in terms of (another acronym) FABs: “Product [feature], enables you to [advantage] which means you get [benefit].”
  4. Acquiring commitment: Close the deal. Ideally, set a date for a yes / no call.

The new rules

Glengarry Glen Ross” is a great film. But it's a terrible way to sell. Sellers used to have all the information and buyers were at their mercy. The internet changed all that. Be an active listener. Help the prospect to get to the root cause of the problems they are trying to solve. With luck, you've got the solution. If you don't, be honest about it.

“When people have their own reasons for doing something, they're more likely to do it.”—Daniel Pink

Less is more

Too much choice is a bad thing. In 1997 Apple offered 12 models of Macintosh. On his return, Steve Jobs narrowed it to four models and two choices: consumer or professional; desktop or laptop.

Mimicry works

Use the prospect's own language. This may be the only truism about selling that's backed up by research. If you're uncomfortable doing it on purpose, don't worry; you're probably doing it without thinking about it.

Be respectful of people's time

Everyone is busier than ever. If you want people to give you their time, make it worth their while.

Top comments (0)

Timeless DEV post...

Git Concepts I Wish I Knew Years Ago

The most used technology by developers is not Javascript.

It's not Python or HTML.

It hardly even gets mentioned in interviews or listed as a pre-requisite for jobs.

I'm talking about Git and version control of course.

One does not simply learn git