The most prolific meetings I have are with early stage founders, who’ve either just built a product, or are ideating the next big idea. And, nigh universally, they all have the same complaint.
They went and talked to a lot of CISOs. The CISOs all complained about some problem. The problem sounded really well articulated. The founder developed a solution to the problem. The founder brought the solution back to the CISOs, who all said some variant of, “Not like that!” That complaint though? Hadn’t been articulated up front. Wasn’t obviously inferrable from the problem space. It felt like a complaint out of left field.
Maybe it’s the identity-proofing vendor who hears, “sure, prevent account takeover, but you can’t add any friction into the process!” Or it’s the vulnerability remediation founder who never really hears that the obstacle is that there can never be a tool that’ll cause engineering teams to trust the security team to auto-deploy anything. Or it’s the SIEM optimization vendor who later gets told they’ll have to also be a SIEM replacement (a death knell for a company).
What’s going on here? By and large, many security professionals have never been product professionals (either developing or marketing them), and so they see a problem. Not the entirety of the problem, just the thing that hurts them the most. And that’s what gets complained about. That isn’t how you specify a product–it’s how you specify a feature (and a minimalist specification at that). Often, security professionals don’t understand why their business won’t accept certain types of solutions, and thus can’t articulate those problems to their vendors.
Until both sides of the equation understand why existing solutions aren’t organizationally viable, they don’t stand a chance at building better solutions that are viable.
