What happens to a SaaS org when AI makes everyone capable of doing most roles?
No toes: I once advised a company where this was a core value. It was incredibly difficult for people to adjust to, so much so, that it became a main reason for employees leaving the company (many embraced it and are lifers). With AI, this is now the norm, what does it mean?
The short answer: a lot of well-intentioned people start stepping on each other, and the coordination costs that emerge are real enough to offset much of the productivity gain. When everyone can do 80% of everyone else's job, the clarity about who decides, who owns, and who communicates what starts to erode in ways that slow everything down even as individual output speeds up.
A story that's been rattling around in my head: a sales lead at a company I know brought in a working prototype to a customer meeting last month. Built it themselves with an AI coding tool. The customer loved it. Nobody inside the company knew what to do with that, because a sales rep shipping a prototype sits entirely outside the org design they'd built. Not a bad outcome, but no process for handling it.
That moment is representative of something broader that's happening in B2B SaaS orgs right now, and I think most operators are underestimating how much organizational friction it's going to generate before anyone figures out the right response.
Why does the blurring of role boundaries create operational chaos rather than just flexibility?
The value of defined roles in a product company isn't just task ownership. It's signal routing. When a customer has a feedback conversation with a CSM, the role boundary tells you that information should flow to product. When engineering finishes a feature, the role boundary tells you it should flow to PMM before it goes to sales. These flows are the connective tissue of a functioning go-to-market organization.
When roles blur, signal routing breaks down. The PMM who used to receive a structured brief from product now might receive a half-finished draft from an engineer who built the feature and figured they'd write their own positioning. The PM who used to run a discovery call might find out that a sales rep already ran something similar and produced outputs that are circulating in the account. Nobody did anything wrong. But the coordination is now much more complicated, and the outputs are inconsistent.
The phrase I keep hearing is "stepping on everyone else's toes." That's not malice, and it's not incompetence. It's what happens when the technical barriers that naturally enforced role separation disappear faster than the organizational habits built around them.
Isn't more flexibility a good thing? Why is this a problem worth addressing?
The flexibility is genuinely valuable, and I don't want to argue against it. A PM who can prototype their own concept before handing it to engineering, a sales rep who can create a quick product mockup for a customer conversation, a marketer who can analyze their own data without waiting for a data team: these are real productivity gains.
The problem isn't the flexibility itself. It's that the infrastructure for deciding when to use it and when not to hasn't been built. Anyone can develop with the right tools and guardrails, but the guardrails are usually technical, not organizational. They prevent bad code from shipping; they don't prevent a sales rep's prototype from creating customer expectations that product wasn't planning to build.
We are going back in time a bit in the sense that a lot of the specialization that built up over twenty years of SaaS was a response to real coordination problems. Early-stage startups have always run with blurred roles; that's normal and usually fine. But as companies scaled, they added structure because the cost of miscommunication rose with customer count and headcount. AI is erasing some of that specialization faster than teams can figure out what to replace it with, and we're going to have to relearn some of these lessons the hard way.
How is this affecting PMM and product marketing specifically?
Product marketing is a useful lens here because it sits exactly at the intersection of all the roles that are blurring. PMM historically relied on having a privileged position in the information flow: they got the feature brief from product, they developed the positioning, they fed the messaging to sales and CS. That position assumed PMM was the translation layer between build and market.
Now engineers can write their own positioning drafts, product managers are being asked to take on messaging work, and sales reps are creating their own collateral. Some of that output is good. Some of it is inconsistent with what's in the market. PMM's job has become less about producing the first draft and more about maintaining consistency across a larger volume of outputs they didn't create and weren't consulted on before they circulated.
That's a real role change, and most PMM teams haven't been formally restructured to reflect it. They're still staffed and measured as if they're the source of all launch communication, even though they've effectively become an editorial and quality function on top of distributed production.
What org design adjustments are operators actually making in response?
The honest answer is that most aren't making explicit adjustments yet. They're managing case by case, which means a lot of ad hoc decisions that create inconsistent precedent. The sales rep who shipped a prototype either gets celebrated or quietly told not to do it again, depending on who's in the room and how the customer conversation went. Neither response is a policy.
The teams handling this more deliberately are doing a few specific things. They're defining which role-crossing activities are encouraged, which require coordination, and which need explicit sign-off before they touch a customer or a product. They're treating that document as a living thing rather than a one-time org chart update, because the technology is changing fast enough that the specific lines will need to move.
They're also investing in the communication infrastructure that lets them see when role-crossing is happening, rather than finding out after the fact. If a sales rep builds a prototype, the question isn't whether they should have. It's whether the right people know about it quickly enough to either support it or redirect it before it becomes a customer commitment that nobody planned for.
The underlying shift is from managing roles as static assignments to managing flows of work and information as the primary thing. That's a harder operating model to build, but it's the one that actually fits the environment teams are in.
FAQ
What does it mean that AI is collapsing role boundaries in SaaS companies?
AI tools now enable people in non-technical roles to build prototypes, analyze data, and produce content that previously required specialized skills. The practical effect is that the natural enforcement of role separation through technical barriers has weakened, leading to coordination challenges when multiple people work on overlapping tasks without clear ownership or sign-off processes.
Why is role boundary collapse a revenue or go-to-market risk, not just an HR issue?
When role boundaries blur without corresponding coordination processes, inconsistent messaging reaches customers, customer-facing commitments get made without product alignment, and signal routing between functions breaks down. Each of those outcomes has direct effects on deal quality, feature adoption, and the accuracy of customer expectations, all of which affect revenue.
How should B2B SaaS companies adjust their org design for AI-driven role blurring?
Rather than trying to enforce old role boundaries, operators are finding more success by explicitly categorizing which cross-role activities are encouraged, which require coordination, and which need sign-off. The goal is replacing implicit enforcement through technical barriers with explicit organizational agreements that can be updated as the technology evolves.
How does this affect product marketing team structure?
PMM teams are shifting from being the primary source of launch communication to being an editorial and quality function on top of distributed output they didn't generate themselves. That requires different staffing ratios, different measurement criteria, and a different relationship with product and sales than most PMM teams were originally built for.