Skip to content
Phil's Library

substack.com - Enterprise SaaS Truisms, Revisited

The Beliefs that AI Broke

Section titled “The Beliefs that AI Broke”

A few years back I published a list of enterprise SaaS truisms - operating principles I believed to be commonplace wisdom about B2B product development and distribution. Nuggets like “admin is not a JTBD”, “usage begets sprawl”, and “change management is a barrier” that were grounded in years of pattern-matching across products I’d built, advised, and used, and the response from readers suggested they resonated pretty broadly.

Recently I’ve been stress-testing this playbook against an AI-native world. And what I found is that several of these truisms are either flipping entirely, getting dramatically amplified, or quietly becoming irrelevant. Some of the beliefs still hold because the underlying organizational behavior they describe hasn’t changed. But others are colliding with something that’s changing the game faster than most teams are updating their approach - and I see lot of product teams applying early 2010s thinking thinking to a late 2020s market.

So consider this a follow-up. Not a repudiation of the original list, but an honest reassessment…

[1] Change Management is a Barrier

Section titled “[1] Change Management is a Barrier”

The original truism holds: getting teams to actually change how they work is hard, follows a step function, and tends to plateau unless it hits a tipping point. None of that has changed…

What has changed is the nature of the resistance. Historically, users pushed back because the learning curve was too steep - the new tool felt harder than the old workaround, and without enough motivation to push through, adoption stalled. The cost they were most sensitive to was the literacy tax: the upskilling required to get value out of something new.

In an AI-native context, that resistance flips. The tool often isn’t hard to use - in face, in many cases, it’s much easier. The resistance is more existential: am I training my replacement? That’s a very different root cause, and it demands a very different response from EPD and GTM teams. Reducing the learning curve won’t solve it. Building trust in the human-AI relationship (and being explicit about augmentation vs replacement) becomes the new change management playbook. The friction is now psychological before it’s ever procedural.

[2] Usage Begets Sprawl

Section titled “[2] Usage Begets Sprawl”

My original observation (or rather something I picked up from some smart people at Box): the more power users engage with a product, the more configurations, templates, folders, and custom workflows accumulate, which creates a cluttered experience that hinders novice user adoption. Enterprise SaaS products are full of this pattern (anti-pattern?). The very users who get the most value out of a product are the ones who make it hardest for new users to find any value.

AI interfaces (chat, agents) are beginning to change this dynamic in 2 distinct ways. The first is masking: when you interact with a product through an agentic interface, the system surfaces what’s contextually relevant to your query or workflow vs everything that exists. The sprawl is still there under the hood, but it becomes less visible, and this less cognitively taxing. You don’t need to know where the folder is if you can ask for what you need. The second is collapsing at the source: AI is beginning to compress the multi-tool, multi-step, multi-handoff workflows that generated sprawl in the first place. If an agent can do in one prompt what previously required three different tools and four manual steps, the accumulation slows down before it even starts; this is a meaningfully different kind of fix.

While this doesn’t fully solve sprawl, it certainly masks it, and in the case of workflow collapse, it reshapes where complexity accumulates rather than eliminating it. And this introduces a different problem: if users can’t see the full surface area of what they’ve built, maintenance and governance become even harder. And for admin and ops teams who need visibility into what’s in the system, an AI interface that surfaces only what’s “relevant” may actually create a false sense of order. Watch for this tension to surface as agentic products mature.

[3] A Learning Curve Isn’t Tolerated

Section titled “[3] A Learning Curve Isn’t Tolerated”

PLG taught us something important: whether you’re selling to an SMB or a Fortune 500, users want to reach their “aha moment” fast and let the product speak for itself. The consumer app expectation of elegance (which I explored in my enterprise consumerization post) has become the baseline expectation everywhere. A steep learning curve is a churn risk even before you’ve gotten to renewal.

AI takes this further, but in a direction that’s worth thinking carefully about: the interface itself starts to disappear. You don’t learn a UI, you have a conversation. In one sense, that’s the elimination of the learning curve entirely because it democratizes access to powerful functionality for people who would have previously needed training, documentation, or a dedicated admin. The FTUX gets completely reimagined when “first time user experience” is just… asking a question in plain language.

But there’s a subtler problem lurking beneath this. There are actually three distinct jobs that enterprise products have always done in teaching new users: teaching the interface (how do I navigate this thing?), teaching the domain (what terminology and concepts does this product use?), and teaching the benefit (what will this actually do for me?). AI affects each of these very differently. The interface teaching problem nearly disappears since there’s no UI vocabulary to memorize. Domain teaching gets easier because users can ask questions in plain language rather than learning a product’s specific nomenclature. But benefit teaching gets harder, not easier. With a traditional UI, the product demonstrates its capability surface just by existing; you can browse features, try things, stumble upon value organically. With a conversational interface, none of that ambient exploration happens by default. The full scope of the product stays hidden until you know exactly what to ask for. The new question for product teams isn’t “how do we reduce the learning curve?” It’s “how do we make the full capability of the product legible through a blank text field?” That’s a different design problem entirely.

[4] Market to the Buyer, Build for the User

Section titled “[4] Market to the Buyer, Build for the User”

One of my favorite reader-contributed truisms from the original post: “market to the buyer, build for the user.” In B2B, the person providing the budget and the person living in the product have historically been different people with different priorities. Marketing speaks to business outcomes. The product speaks to daily workflows. The GTM and product teams often operate in separate lanes because of this split.

AI agents are starting to collapse this distinction in a fundamental way. When the “user” of your product is increasingly an AI agent (pulling data, executing tasks, triggering workflows) you have to ask: who are you actually building for? The human who configured the agent? The downstream human who consumes the output? The agent itself, optimizing for a success metric it was given?

This isn’t a theoretical question. As more enterprise workflows get delegated to agents, the product surface that matters is less the UI and more the API, the data model, and the reliability of the underlying service. The buyer is still human, but the user persona has become more complicated; product teams that don’t update their definition of “user” will find themselves over-investing in surfaces that are increasingly unmanned.

[5] Inbox is the End Goal

Section titled “[5] Inbox is the End Goal”

I’ve written before about how wild success in B2B SaaS looks like becoming yet another inbox. Look at how Slack, email, and task management tools have converged on the same set of primitives: notifications, snooze, search, archive, scheduled send. Every productivity product eventually ends up building these features because that’s where work lives (in a queue).

With AI, the locus of activity starts to shift from the inbox to the outcome. The inbox is a management tool for human attention. If an agent is triaging, routing, and responding on your behalf, the inbox becomes less a place you work and more a place you audit. The thing you care about is no longer “what’s in my queue?” but “what got done, and was it right?” If you manage people, you don’t ask to see their tasks lists - you have a conversation about the impact they drove.

That said, I don’t think the inbox disappears…I think it gets reinvented. The human-in-the-loop still needs a place to review, override, and redirect. What we’ll likely see is the inbox collapsing into the chat interface as a side panel: here’s what the agent did, here’s what’s pending your judgment. Less traditional inbox, more command center.

[6] Impatience around ROI

Section titled “[6] Impatience around ROI”

It has always been true that enterprise buyers want real, demonstrable ROI: productivity gains, risk mitigation, cost reduction, better margins. The justification process is part of how large organizations make decisions, and no one gets fired for asking for a business case. That maxim holds.

What’s changed is the expected timeline. There used to be an implicit understanding that a new software deployment involved a phased rollout, a change management cycle, a period of data accumulation before you could point to meaningful results. Buyers knew this, and a long-term contract was in part a bet on that future state of adoption. The initial deal was essentially runway for the vendor to prove value over time.

AI has compressed this dramatically. When a product can demonstrate clear, measurable value in the pilot (and AI products increasingly can) the patience for a slow ramp evaporates. The appraisal tax (to borrow from Death & Taxes in B2B) hasn’t gone away, but the acceptable payback window has shrunk. If you can’t show ROI in weeks, you’re fighting an uphill battle that didn’t exist in the same way five years ago. And as much as reference-ability still matters for distribution, there is now an opportunity to create champions of your product faster than ever.

[7] Extensibility Matters

Section titled “[7] Extensibility Matters”

This one hasn’t flipped, but it’s been amplified quite a bit. B2B SaaS products have always benefitted from robust APIs and integrations. The ability to connect your tool to the rest of the stack has been a checklist item in enterprise evaluations for years, and it drove the rise of integration platforms, middleware layers, and a whole ecosystem of connectors.

The agentic world has raised the stakes. As AI orchestration layers (like Claude, ChatGPT, Gemini) become the interface through which users interact with multiple tools at once, the question is no longer “do you have an API?” It’s “are you reachable from the agent?” MCP (Model Context Protocol) is the emerging standard for this — essentially a way for AI models to interact with external tools and data sources natively. If your product isn’t MCP-enabled, it risks becoming invisible to users who are increasingly delegating their workflows to an AI layer.

I’ve felt this friction personally as I’ve been experimenting with these tools for enterprise use cases. The connectors that don’t exist are noticeable in a way that missing integrations never quite were. When you’re orchestrating across five tools in a single prompt and one of them breaks the chain, it’s a jarring experience. Extensibility used to be a nice-to-have for SMBs and a must-have for enterprise; in an agentic world, it’s table stakes for everyone.

[8] Centralized IT is Losing Power

Section titled “[8] Centralized IT is Losing Power”

The original observation captured something real: the shift from centralized IT procurement to line-of-business buying. Over the past decade, departments increasingly bypassed IT, swiped a credit card, and deployed their own solutions. Shadow IT became a governance nightmare for CIOs and a growth engine for PLG-driven SaaS companies. That trend loosened IT’s stranglehold on the enterprise tech stack considerably.

AI is beginning to reverse this. Not completely, and not uniformly but there are meaningful signs of a shift back. Here’s why: as AI tools proliferate and employees start connecting them to company data, the governance, risk, and compliance concerns become centralized again. Which data sources is the AI accessing? Who authorized that integration? Is the model being used storing prompts? These are not questions that a line-of-business manager can answer on behalf of the organization.

IT is being pulled back into the conversation - not as a gatekeeper of tool selection, but as the owner of the data and access policies that determine what AI can and can’t do. If your product doesn’t have a credible story for the IT and security buyer, it’s going to hit a harder ceiling than it did in the pure PLG era. The consumerization of enterprise drove power toward users - the AI-ification of enterprise is partially restoring it to IT.

[9] Shadow IT is Real

Section titled “[9] Shadow IT is Real”

Shadow IT, an industry term for the unsanctioned tools that employees buy, install, and use outside of official procurement, has been a feature of enterprise life for as long as there’s been a gap between what IT provides and what users actually want. The truism captured something important: user pull is stronger than IT policy, and enforcement is often futile.

What AI is doing is taking this one level further. It’s not just that employees are buying unapproved tools anymore…they’re building unapproved ones. With the right prompt engineering and a basic understanding of agent frameworks, a motivated employee can spin up a custom workflow or internal tool in an afternoon that would have taken an engineering sprint a few years ago. Shadow IT becomes shadow software development.

This is a fundamentally different challenge for organizations to grapple with. You can revoke a SaaS license. It’s much harder to govern a prompt that someone saved in a personal Notion doc and runs twice a week against your CRM. The implications for security, data governance, and audit trails are significant - and most companies haven’t caught up to the new surface area of risk yet.

As always, I’d love to hear from readers on which of these resonates or which I’ve gotten wrong - please chime in via comments👇 or join the chat via the Substack app.

And if you enjoyed this post, please share / subscribe.

further reading / references

childish drawing / interpretation