How to be a security person who doesn't suck at product
It's important to sell a good experience
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:
Over the last couple of years, I’ve written extensively about the delicate interpersonal relationships that define our industry. I’ve broken down the exact mechanics of how to be a security person that engineers don’t hate, and flipped the script to look at how to be an engineer that security people don’t hate. More recently, as teams began rushing models into production, I mapped out the playbook on how to be a security person AI/ML teams don’t hate.
The core thread through all of those pieces was empathy, trying to figure out how separate engineering factions with completely different incentives could coexist without breaking things.
But I’ve been thinking a lot about those past articles lately, and they inspired me to look at this dynamic from a much more cynical angle. With the rapid acceleration of AI, we are past the point of just adjusting our communication styles or trying to “get along” with developers. The entire architecture of the security organization is splitting in two, and it is exposing a lot of comfortable hiding places.
I was inspired by a LinkedIn post by Rinki Sethi, who shared an excellent visual mapping out this structural transformation.
If you look at the traditional enterprise security blueprint, it is organized strictly around functional silos: AppSec, Cloud Security, SOC, GRC, and Identity and Access Management. This old layout was explicitly built for a world where human analysts spent their days grinding through repetitive, manual tasks.
The future framework looks completely different It is organized entirely around business outcomes: Security Strategy and Risk, AI and Automation Engineering, Platform Operations, Engineering Enablement, and Trust Resilience. It is designed from first principles for a lean, human-in-the-loop setup that leverages AI to deliver real, high-velocity business value.
The move to “fixers”
If we are being completely honest, a massive portion of traditional security work has historically been an exercise in professional problem creation. They set up an automated scanner, hit export on a 400-page vulnerability report, dump it over the fence to the engineering team, and call it “risk management.” They act as administrative toll booths, generating problems and blocking releases without taking an ounce of responsibility for actually fixing the underlying code.
On the other side of the house, you have the GRC and operational compliance teams. This layer has historically been a race to the bottom, functioning purely on manual paperwork, check-the-box user access reviews, and commodity dependency bumps. These functions don’t solve security issues; they create operational friction.
In an AI-forward organization, paying an army of human analysts to manage this paperwork makes absolutely no sense. These tasks are trivial to automate. Modern security teams run automated Claude jobs on a quarterly basis that handle our user access audits and dependency monitoring. Tasks that used to require weeks of cross-team coordination and manual spreadsheet tracking now require almost zero human effort and cost pennies.
The budget for traditional, check-the-box GRC operations is shrinking permanently. The people who refuse to move past this passive, administrative mindset will find their comfortable routines fully automated out of existence.
With the administrative busywork automated away, true security engineering is intensifying at an unprecedented scale. The hands-off auditor model is dead. Armed with terminal-native coding agents like Claude Code and advanced repository indexers, the expectation has shifted entirely. It is no longer enough for a security person to just run an AST scan and log a ticket for someone else to deal with. A great security practitioner is now expected to step directly into the repository, generate the code patch, run the test suite, and submit the completed pull request themselves.
This creates a unique, highly disruptive cultural challenge. The plain reality is that the vast majority of traditional security professionals are not used to operating as software engineers. They are comfortable analyzing risk from a safe distance, but they lack the technical capability and the muscle memory required to safely write and ship production-grade code.
The shift from syntax to experience
This talent gap becomes even more acute when you look at how the broader software engineering discipline is evolving. Because AI has made the raw mechanical act of generating syntax trivial, the role of the traditional software developer is shifting up the stack.
Engineers are no longer prized simply for typing lines of code fast. Instead, they are spending their cycles on high-level technical design, systems architecture, and crafting exceptional, fluid user experiences. Because iterating on an application is now incredibly easy, companies are moving at an organic velocity where the boundary between product management and engineering is completely blurred. The modern builder has to think deeply about taste, user friction, and product feel because the code itself changes by the hour.
This is entirely new, unmapped territory for the traditional security engineer who sucks at product. Historically, security teams operated by simply saying no from a distance, building rigid, clunky authentication walls and heavy endpoint agents without ever considering how those controls impacted the actual human experience of the product. But in an AI-native world, if your security control ruins the user journey or adds friction to a fluid engineering line, the builders will use AI to write a workaround and bypass your team entirely. Security leaders must learn to think like product managers.
The rise of security development tooling
This dramatic shift in talent and responsibility reveals a massive, wide-open market opportunity for next-generation security vendors.
If security professionals are being forced to transition from administrative auditors into code-shipping builders, they cannot use the tools of the last decade. They don’t need another passive monitoring dashboard or an alert aggregator. They need an entirely new category of software: security development tooling.
Think about the massive enterprise markets that were unlocked when developers shifted to cloud infrastructure. We saw the rise of entire platforms dedicated to helping engineers write, test, version, and orchestrate their infrastructure pipelines. Security engineering now needs its own dedicated development lifecycle environment.
The winning platforms of the next five years will be the tools that abstract away the complexity of the codebase for the security practitioner. We need platforms that help security generalists easily build, validate, and maintain programmatic context files, construct automated prompt-injection test suites, and safely deploy self-healing remediation loops across disparate repositories. The vendors who figure out how to seamlessly turn traditional security analysts into high-impact code contributors will capture the entire modern enterprise security budget.
I don’t know any companies doing this now, but I believe some of the applications for the AI labs are trending this way. This is the topic of a separate newsletter to better understand and define this market.
Guidelines for the product-minded security practitioner
If you are a security professional or leader trying to navigate this transition and ensure your team isn’t left behind, you have to fundamentally change how you view the business. Here are five pragmatic principles to help guide your team into this new builder persona:
Think of the user and shadow them directly. Do not build security controls in a vacuum based on what makes sense to your internal framework. You must design for the end-user experience. Force your team to step into the shoes of your developers and customers. Test your own security frameworks to see how smooth the flow actually is. You have to develop a sense of product taste, thinking deeply about the feel, flow, and friction of a security requirement, not just whether it functions and checks a compliance box.
Design strong, modular foundations. When you are building security engineering platforms or policy-as-code guardrails, invest the time to make the underlying architecture incredibly clean. AI-native environments iterate at a blistering pace. If your security code is brittle and tightly coupled, it will snap the moment an engineering team runs a rapid iteration cycle. Build modular foundations that make it easy to adapt and iterate in the future.
Redefine what success means with engineering metrics. Drop the legacy operational metrics like the number of vulnerabilities discovered or audits passed. You need to align your KPIs with business velocity and operational resilience, mimicking the playbook of infrastructure product managers. Track metrics like developer adoption rates for your security tools, the change failure rate of your automated guardrails, and the aggregate time-to-remediate for critical paths.
Gather regular feedback and prioritize simplicity. Treat your internal security tools like a commercial product. Run regular feedback loops with engineering leads to see where your guardrails are causing friction. Always push your team to see if you can strip away UI clutter and engineering steps to achieve your defensive goal through a simple, elegant interface.
Be opinionated and sell a great experience. Do not offer developers a loose checklist of thirty different ways they can choose to secure an application. Build the gold-standard pathway, make it exceptionally easy to use, and be highly opinionated about how security should run in your environment. You aren’t just enforcing a rule; you are selling an internal experience that engineers should actively want to adopt because it makes their lives easier.
Ultimately, organizing security for outcomes means accepting that the era of the lazy administrative gatekeeper is over. If security teams refuse to upskill and adopt a developer-centric mindset, they will be left behind completely, and software engineers will simply absorb the security budget themselves. The future of defensive leadership belongs to the builders who know how to protect a company by shipping exceptional product experiences.