You're a startup. You know your product is good — the demos land, early users love it, the technology is genuinely ahead of what the incumbents ship. And yet the large enterprises you most want as customers keep stalling: they go quiet, they "love it but the timing isn't right", or they vanish into a procurement process that never seems to end.
Why?
There are really two answers, and each one is a conversation worth having properly. What I bring to both is that I've spent years on the other side of the table — a senior IT and security leader inside large regulated enterprises, the person who actually decided which suppliers got through and which quietly didn't. I've watched genuinely excellent products fail to land for reasons that had nothing to do with the product. Here is what those reasons usually are.
Every IT, security and business leader in a large organisation carries a mental map of the things keeping them up at night — the handful of problems they've already decided are worth their scarce time, budget and political capital. Your product either has a place on that map or it doesn't. If it doesn't, it rarely matters how good it is: you're asking a busy person to take on a new thing to solve a problem they haven't prioritised.
And here's the part founders rarely hear, because the people inside will likely not say it to you directly: from where I sat, the buying decision tended to depend far less on the product itself than on everything around it — how painful the integration looks, who has to change how they work, what it does to existing vendor relationships, and whether adopting you creates more work than it removes. A strong product that lands as extra work for an already-stretched team can lose to a more ordinary one that arrives with the implementation and the hand-holding built in.
This conversation is about reading the buyer's real priority map — not the one your pitch deck assumes — and positioning what you sell as something that takes weight off that map rather than adding to it. I can tell you, specifically, how the IT, security and business leaders you're selling to actually rank their problems, and where you genuinely fit.
The second answer is more concrete, and it's where most startups lose deals they should have won. The instant a large enterprise takes you seriously, a different set of people enters the room — security, procurement, compliance — and their job is not to get excited about your product. Their job is to ask whether you are a risk to them: a supply-chain risk, a new door into their systems, a small company that might lose their data or disappear in a year.
So they ask for the evidence a mature supplier would have: SOC 2 and ISO 27001 certificates, penetration test reports, data-handling and retention policies, answers about exactly what happens to their data inside your cloud and AI components. At your stage you may have none of the certificates. The instinct is to go quiet, or to answer "we don't have that yet" — and to an enterprise reviewer both of those can read as a company that doesn't quite understand what's being asked. The deal cools.
It doesn't have to. There's a way to answer that keeps the momentum: showing the controls you genuinely do have against the frameworks they named, offering a credible readiness plan with real dates in place of certificates you don't yet hold, answering the data and AI questions with the precision their reviewer is actually testing for, and using the NDA to share the sensitive parts safely. What a good security function is really judging at this stage isn't whether you have the certificate — it's whether you're a safe bet who's moving in the right direction fast enough. That's a case you can make, and I've made it, from the side that decides.
From practice — under NDA
A product startup chasing a large regulated customer hit exactly this wall: the customer's GRC team asked for certifications, pen-test results and cloud/AI data-handling assurances the startup didn't formally have. Instead of stalling, the response mapped the controls it did have to the frameworks the buyer named, put dated readiness targets where certificates didn't yet exist, answered the data questions precisely, and sequenced the technical deep-dive to follow the baseline materials. The point was to turn a review designed to filter out immature vendors into a reason to keep going.
From practice — under NDA
As interim CTO of an early-stage company, I ran a full audit of its IT and security — the usual picture of a fast-moving product team: fragmented architecture, gaps in information security, inconsistent access control, intellectual property scattered across tools. The audit was written not as a list of faults but as a sequenced path to an ISO 27001 footing: secure the code and IP first, stand up the basics of a security management system, enforce single sign-on with MFA, then build out from there. The same posture that unlocks enterprise deals is the posture that protects the company's own value.
If either of these sounds like where you're stuck, the fastest start is a short note describing the deal that's stalling and who's blocking it: vshabad@vshabad.com.
Engagements are under NDA; the examples above are anonymised. This work sits alongside a broader research programme on why enterprise assurance underperforms at scale — the same gate, read from the supplier's side.