The two messaging approaches for selling software

When you work in software, it's easy to assume everyone buys like you do… but they usually don't. Which means that if you market the way you think rather than the way your buyer thinks, you end up with the wrong message in front of the right person.

There are two main messaging approaches. Which one you run depends on the type of buyer you're selling to.

(Note: Knowing these approaches doesn’t negate the need for deep buyer research and frontline listening loops. But they can stop you from questioning whether your product marketing is doing enough, well, product marketing.)

I covered this approach in more detail here. The short version: lead with outcomes, be clear about what your product is and who it’s for, show the product and allow any differentiated mechanisms to play a supporting role. 

The big difference here is that technical buyers typically have a higher level of sophistication. And a higher level of sophistication means higher skepticism. In other words, when you’re selling to a technical buyer, there's less room for error and far less forgiveness when you get it wrong. You have to be really, reaaaaally good at anticipating and overcoming objections. And your brand needs a detailed understanding of the technical buyer’s vocabulary and mindset. 

For example, if you sell to DevOps, your brand needs to be fluent in DevOps. Fluency in the language means using your buyer’s terminology, acronyms, and day-to-day phrases correctly and consistently. So things like canary deployments, rolling updates, CI/CD, rollbacks, feature flags and feature toggles will all be part of your brand’s core vocabulary. 

Understanding the buyer’s mindset means knowing how your buyer really thinks, what else they're weighing, and what objections are already forming… and getting ahead of them before they're voiced. The marketing that lands with a technical buyer answers the question that's forming on the tip of their tongue. Going back to our DevOps example, you should know when your buyer starts thinking about the (dreaded) build vs. buy question, so you can get ahead of it early.

For the technical buyer, you typically also lead with (or at the very least, heavily feature) any differentiated mechanisms. 

Lift the hood, show and tell how your software works and what makes it different from the other products and competitive alternatives they're considering. And do this early and often in your marketing. The demo can’t be the first time you plan to show your buyer your unique mechanism, because the risk is you’ll book far fewer demos than you otherwise could. (I’ve said it once and I’ll say it again: we can’t expect buyers to willingly hand over 30-60 minutes of their time just so they can see our software.)

Both messaging approaches serve the same goal: close the gap between what the buyer wants and what the product offers, so your product becomes the obvious choice. 

But the messaging architecture, brand voice and the copy that comes out of these two approaches will look fundamentally different.

‘Til next week,

Carolyn