Understanding what developers want from the technology buying process
For many of you that have been long time readers, you know me from my days selling software at Stack Overflow. Before that however, I spent a decade helping startups to understand how to market and sell and in the process created a community called the Enterprise Sales Forum.
I wrote the following essay for that community on the process of selling technical products to developers. So I am doing something a bit different from the normal newsletter and sharing this post in its entirety to hear your thoughts and gather to your feedback. It may be a lofty goal, but I do think there is an opportunity to improve how salespeople sell to developers and hope this is at least a good first step in improving the buying experience. Thanks for reading as always 😁
Corporate decks in the B2B enterprise software world can be legendary. By legendary, I mean not good, like the one at Siebel. It was not the longest deck, but a few slides triggered people.
I was a sales engineer at the time on the team selling to Wall Street banks. I was onboarding, so I would join account executives on sales calls. It was policy to present the corporate pitch, and at this one meeting, we got to the slide touting our 400 screens, 1700 views, and 4000 tables.
The senior bank MD stopped the sales rep mid-sentence and said,” Why the f*ck do I care about 400 screens? I don’t want 400 screens, I want one screen, or no trader is going to use it!”
It was then that I learned the importance of know your audience, or that I call KYA.
The lack of KYA exhibited in meetings is still shockingly high, especially when engaging technical audiences. Many meetings are show up and throw up sessions. Sales people come armed with a prepared deck and demo and then fight with prospects over the content under the assumption that they know more than they do. Sales people may know about their products but are woefully handicapped when it comes to applying products from a technical perspective.
The other unhelpful assumption in sales situations is the understanding of the audience. There are presumptions of personas which are merely poor caricatures of developers. Sales people often do not appreciate the subtle differences in roles and work environments that can vary widely across organizations, companies, industries, and regions.
Developers are not all the same. They have different disciplines and skills. Some focus on back-end, others work on front-end. Some are integration specialists, others work on infrastructure. Some prefer to hang at hackathons over the weekend, but many others prefer dancing, cooking or other hobbies. Some are introverts yet others are extroverts. There is no one size fits all.
As a sales person, the first rule you need to understand about selling to developers is you do not sell to developers. This is not meant to be vague, but simply a reality of how developers “buy” today. Developers have little patience for qualifying questions, sales decks and demos. Their first goal of the buyer’s journey is to see how quickly they can get rid of the salesperson and get to people that know stuff.
The enlightened organizations that focus on developers as their key audience learned this a long time ago. This is probably because the founders of those companies are developers as well. Therefore they modeled their developer outreach in the same way they prefer to engage with companies about new products. They focused on openness and giving.
The open source movement is a marvel in technology innovation and value creation. Most of the world’s websites operate on Linux, which is open source software, and a majority of companies are now actively using open source in their commercial products. In turn it has spawned a massive industry and changed the way companies and developers use software. Open for developers means free access to software, at least before buying anything.
The open source movement also accelerated the willingness of developers to help each other. This existed in the days of bulletin boards when developers would ask questions, help others, and share code. Today that is manifest in sites like GitHub and Stack Overflow. Developers now expect the same level of help and sharing from the companies whose products they use.
This leaves salespeople is a difficult position. You probably cannot answer tech questions. You could probably provide access to a sandbox environment or software download, but the added hassle of talking to a salesperson probably does not help build rapport and trust with developers.
If you work at one of the enlightened companies that understands developers, they have already figured out how to address openness and giving. They give free access to software, sandboxes, and documentation for developers. Some go the extra step of creating API and SDK galleries to showcase the integration and flexibility of their technology.
When developers have questions, there is a team of developer advocates to ask. Really good developer advocate teams “sell” the product without ever selling. All they do is show developers how to use the product in their own scenarios. Developer advocates can be seen giving talks at conferences, attending hackathons, blogging and tweeting about cool things other developers are doing with the products, and generally being available to anyone that needs help.
You may be wondering then what salespeople have to do. Why have salespeople at all? It is because eventually developers need to buy the product. Once the developers see the value of solution, they will reach out to people inside their company to initiate a purchase. This is where professional sales skills come into play, because now the developers will need to create a business case and convince stingy layers of management to allocate budget for your product.
What you do early on in the buyer’s journey will greatly influence whether you get to the “let’s buy stage”. If you followed along this far, you realize that pushing your sales process, your deck, and your canned demo is not going to fly. You also realize answering tech question is not going to work. A developer will see right through the fact you don’t know what you are taking about.
The way then to engage developers early on is to be a connector. Connect developers directly with sources of information and people such as subject matter experts (SME’s) that can answer questions about the product. This requires being a good listener and understanding objections as they come up. Be involved in conversations and share content when relevant. And be wary of sharing marketing related content, developers are seeking to learn, not read marketecture. You want to keep the level of engagement light yet highly valuable to build up trust.
While the evaluation is progressing, you want to become an explorer. In anticipation for a buying opportunity, you are researching the company and learning about the key initiatives, how budget is allocated, who are the influencers and power centers. You are also building relationships within management and leadership because eventually they will be involved in the purchase.
At the point that the conversation moves from exploration to buying interest, you want to become the director. While you may not be equipped to talk about technology, you are the expert when it comes to managing a deal. Because you already did your research and made connections, this is not the first time decision makers are hearing about your product and the value it provides. The difference is now you have developers helping internally to support your efforts.
From connector to explorer to director, this is the sales motion that I have most often seen succeed when developers are your end users. However, I would make the case that this should be the way most software is sold, especially anything SaaS or Cloud related. Buyers are looking for more flexibility and openness in the buying process to explore products. When it comes to developers though, this is the only way to engage with them successfully.
What are your thoughts as a technologist to the above sales approach? What helps most when you are exploring new products and what is least helpful?
Why To Sell Is Human by Daniel Pink
In an interview with Adam Grant, Dan shares how sales has evolved and why we are all in fact selling even if we are not salespeople.
Check out past podcast episodes on Apple Podcasts, Google Podcast, or wherever you listen to your favorite podcasts. Please like and subscribe 😁
We help IT leaders in enterprises solve the cultural challenges involved in digital transformation and move towards a community based culture that delivers innovation and customer value faster. Learn more about our work here.