A letter to security vendors
Stop making it hard to buy your product!
Disclaimer: Opinions expressed are solely my own and do not express the views or opinions of my employer or any other entities with which I am affiliated.
I’ve intentionally made all of my posts free and without a paywall so that my content is more accessible. If you enjoy my content and would like to support me, please consider buying a paid subscription:
I still remember one of my first vendor emails after returning to the startup operating world. I don’t remember the vendor, but I remember the moment: I asked, “How can I get started with your product?”
What followed felt like corporate theater. First, a discovery call. Then another with a sales engineer. Then a third with their field CISO. Then one more to define PoC requirements. Eventually, five calls in, I got the privilege of being allowed to try the product, pending an mNDA, and some internal approvals on my end.
It didn’t stop there. The salesperson wanted to join internal meetings that would’ve otherwise been Slack messages. They wanted weekly check-ins. I had to explain (again) that I’d ping them if I ran into issues. We debated how long the PoC should last because apparently it was expensive. Finally, I had to push the contract through legal.
Three months later, we had a signed one-year contract (maybe two, if the discount was good). And just like that, I’d need to do it all over again in three quarters. This experience wasn’t unique. It’s just how most security vendors operate today.
This post is a bit different. It’s structured as a letter — a direct message to security vendors and a call for change.
But before we begin, let me acknowledge why things got this way. I understand the value of GTM teams and sales processes. Done right, they ensure customer needs are met and build long-term relationships that reduce churn. This model has worked for traditional SaaS and especially in security, where buyers historically lacked the technical background to evaluate products hands-on. But times have changed.
More security teams now build. They’re staffed with engineers who understand how these products are made and why they work. And they’re buying not because they can’t build, but because they don’t want to maintain yet another internal service.
Just like engineering teams prefer Stripe over building a payments platform or GitHub over maintaining their own Git server, modern security teams are looking for tools that work out of the box. They don’t need five calls and a sales script. They just need to try the product.
The best security vendors will be the ones who adapt to this. So, here’s my letter:
Dear Security Vendors,
I know you want to sell me a product. But let me ask: are your salespeople here to find a good fit or just hit quota? Are they trained to understand my environment, or are they just following the playbook you gave them? And more importantly, are they even allowed to go off-script?
I’m a security engineer. I don’t need a high-level demo. I want to get hands-on. I want to click around and try things in my environment. That’s the only way to know if your product works for my team.
There are countless subtle differences in how tools behave in real-world environments. I need my team, the people who will actually use this, to test it themselves. That’s why the most effective path is getting to a trial or PoC as quickly as possible.
I understand your concern: PoCs cost money. But honestly, the infrastructure isn’t the expensive part. The real cost is your salesperson’s time… and mine. The longer it takes me to set up, the later it will take you to get the contract going. Similarly, the longer it takes me to set up, the more negative I feel about the product.
You could close deals faster if you spent that money enabling frictionless self-service trials instead. Let me start testing immediately. Make it easy to onboard. If I hit a snag, I’ll reach out.
The companies that get this, e.g., Snyk, Semgrep, and others, are already adapting for security engineers. They understand the modern buyer: someone technical, time-constrained, and uninterested in wasting cycles on a drawn-out sales process.
If I’m trying a new feature or tool, it’s usually because I’m consolidating vendors or solving a real gap. Help me move quickly. That’s the moment when I’m ready to buy.
Security GTM is expensive and hard, yes. But adapting your sales motion to your customer isn’t optional anymore. It’s survival.
Sincerely,
Frank
Procurement needs to change too.
Companies often complain about sales cycles, but then build massive procurement pipelines that are just as painful. It’s become a self-perpetuating problem. Security teams have had to hire full-time staff just to manage vendor relationships. That’s not normal, and it’s not sustainable.
Part of the reason we’re in this mess is that there are simply too many tools. I’ve written about this before, and the result is an operational nightmare. Security teams now spend more time managing vendors than managing risk. It’s also bad because not only are we wasting talent, we’re giving people the wrong impression about security is about. This is why we are perceived as operational rather than delivering value.
AI may help. By making it easier to build tooling in-house, it could force vendors to focus on the differentiated value they offer, not just the operational glue they’ve historically provided. If a company can build it in a week, the bar is higher for you to justify your cost and complexity.
In the end, this is just another expression of what I’ve written before: security has an effectiveness problem. We need to spend more time securing things, and less time managing the mechanics of buying the tools that help us do that.
Fixing the sales motion is low-hanging fruit. Let’s start there.