Software development teams rarely buy products
And when they do, they buy them early and differently than other technical teams
Over the years, I have developed an (untested) hypothesis: software engineering organizations don’t buy products outside a core set, like some of the ones listed below.
There are a few reasons for my hypothesis.
First, payroll accounts for ~80% of a software engineering organization’s budget. Not only is the budget payroll heavy, but the portion that is allocated to tooling and products tends to be dominated by the products listed above.
Second, the products listed above tend to be used/purchased very early on in the organization's lifetime. Choosing which cloud to run on, what CI/CD system to use are foundational decisions and are likely done very early in the organization's lifetime. Not only are they decided on early, but tend to be irreversible unless absolutely necessary. One does not switch from running on AWS to Azure without much deliberation.
Third, it isn’t terribly difficult to find OSS equivalents for many of these products. Don’t want to pay for Datadog? Perhaps you can use Prometheus & Grafana. Similarly rather than use PagerDuty maybe use Cabot or one of the many other OSS equivalents.
One way that I attempted - very naively - to test this hypothesis is to analyze the marketing emails I get over a period of time. I looked at all the marketing emails (read spam) I received for the month of February and applied a simple categorization to each. For example, an email from a CI/CD vendor would be categorized as Platform/DevOPs, whilst one from a recruiting agency would be classified as “Hiring” The results are shown below.
Unsurprisingly, the most spam I get is from hiring agencies, recruiters and offshore contractors. The next most voluminous category was “Other”, which tended to be emails for lead generation, events, pricing. These aren’t entirely relevant to an engineering organization. Security and Compliance is the third largest source of marketing emails. Examples include vendors that facilitate SOC2, or ones that offer penetration tests and so on. Products and tools that target DevOps and Platform teams come next and finally vendors in the Cloud Cost Optimization space are the last.
A few observations from this data:
It should be no surprise that the largest source of spam was hiring related. This volume is commensurate with the % of my budget allocated to hiring (payroll). These vendors know that I spend money on hiring.
My response rate was 0. Nothing that these vendors were offering was relevant to me, or made me want to start a dialog with them.
Why was my response rate 0 then?
The short answer is whatever products these vendors were offering were not ones solving problems I have. For problems that I want to solve, I will likely default to the vendors shown earlier or look at ones from the recent StackOverflow survey.
Additionally, my buying process is predicated on word of mouth, trying best in class products and garnering bottom’s up adoption for products that will be used by the entire engineering team. Notably, though, is the fact that I have never (I searched my entire email history) received unsolicited marketing material from any of the major vendors listed in the ICONIQ report.
And here comes an interesting conundrum.
The vendors that spam me, I never respond to and will likely never use their products. The vendors whose products I, or more generally my technical teams use have never spammed me or reached out to me directly. They have avoided me. Maybe I am too small for them, maybe I already use them (I do), or maybe they have realized that I am not the buyer persona ← That :)
Let’s quickly revisit the ICONIQ list and expand on it some more by adding a few other popular choices. This time, I will augment the list by highlighting if these vendors reached out to companies I work, or previously worked for and who they contacted first.
It seems that these vendors know that I am not the target buyer. I might control the budget and might be an approver in the buying process, but the technical buyer is not me. Hence they start from teams outside the core software development teams, namely security, IT, Data and DevOps.
There are a few implications of these observations, assuming they are true. Remember, this is a hypothesis.
First, try and position your products to organizations on the periphery of core software development. These organizations buy products, whereas a VPE doesn’t - outside a few core ones. CISOs, CIO, CDOs have a much larger percentage of their budget allocated to tools versus headcount. Their budget is primed for buying products. Mine is not, it is optimized for hiring.
Second, if you are targeting the core software development team know that the buying process is very different. This isn’t going to be your classical enterprise sales cycle with RFPs and so on. The vast majority of the products that my software development teams purchased were done so very early on in the company’s lifecycle and done with direct outreach from us to the vendor. It’s a process that is predicated on free trials, word of mouth and almost contactless with sales; a pull vs push model.