When your product is an AI agent: The new PLG playbook

A friend asked me recently whether mdhub has a product-led or sales-led growth motion. "Product-led," I said – then paused, because I wasn't sure that was true.

We have a sales cycle. We go to conferences. At times we sign contracts before any agent touches a clinic's systems. That sounds sales-led. But calling it sales-led feels wrong too, because the product isn't just what we're selling – it's doing most of the work of growing the business. 

Two years of building AI agents for behavioral health clinics has given me a motion that doesn't fit either label. I suspect it's what happens for most enterprise AI agents – and it’s worth being aware of the shift in the growth motion when building these products.

Why the traditional PLG playbook doesn't fit

Deploying AI agents across enterprises, like health systems, isn't like building a SaaS product. Every clinic has its own workflows and nuances; getting an agent to successfully complete the end-to-end job requires deep integration work that can't happen before a contract is signed. That rules out the traditional PLG motion: there's no free tier, no self-serve onboarding, no "try before you buy." 

But a traditional sales process doesn't quite fit either. It's slow, it doesn't scale, and more importantly, it misrepresents what actually happens in those early conversations.

What prospects experience before signing looks more like product discovery than a sales pitch. They see the agent operating on our native platform. They run through simulated workflows – seeing what the agent can do and how it would execute the job. And they look at what comparable clinics have already deployed, examining real workflows rather than a polished demo. 

Conferences play a specific role here: when we get the chance to present our work with a customer to a room full of peers, other operators encounter the product's results without a salesperson involved at all. The product is doing the selling – through results it already delivered somewhere else.

So is this just sales with a better demo? That's a fair question, and it's worth sitting with. There's a sales cycle. There's a conference circuit. A signed contract precedes system integration. By the textbook PLG definition – where the product drives acquisition without sales involvement – this doesn't qualify. And anyone building enterprise AI agent products should resist the temptation to call it product-led just because the product feels central to the pitch.

Where the product-led motion kicks in

But here's what changes the moment the contract is signed.

Initial contracts for enterprise AI agents don't capture the real value. A deal might start at $100k – one use case, one workflow, one team. But with expansion, the contract grows to $500k or more, and that growth happens without a new sales cycle. No RFP, no procurement process, no AE scheduling a quarterly business review.

What makes this growth product-led rather than account management is where the pull comes from. The initial contract is typically championed by senior leadership (COO or CFO) – they're bought in on the strategic case. But they're not the ones who drive expansion. That comes from their reports, the people whose daily output the agent is directly affecting. When they start seeing a noticeable change in what their team can produce, something shifts. The agent stops feeling like a vendor tool and starts feeling like a member of the team.

The signal that this has happened isn't a renewal conversation. It's when those stakeholders start proactively sharing SOPs with you, asking whether the agent could learn to handle the next workflow. They're not waiting for a sales call – they're coming to you. That pull is coming from the product, not from sales. And that, to me, is where the product-led motion fully reasserts itself.

The real PMF signal isn't the first contract

This also changes how I think about product-market fit (PMF) for AI agent products.

The conventional PMF signal for enterprise software is something like this: you close deals consistently, churn is low, and customers renew. By that measure, the initial $100k contract looks like the milestone. But what does that contract say about the product? It tells me that the organization is making a strategic bet, but it doesn't tell me whether the product has actually earned its place in the organization.

The real signal comes later, and it's more specific. It's whether the first use case reliably generates pull for the second. Whether the direct stakeholders, without being prompted, start sharing SOPs and asking what else the agent could take on. If that happens consistently across customers, the product has done something a sales process can't manufacture: it's made itself indispensable to the people using it every day.

The $100k contract is a bet. The $500k expansion is the signal.

How to design for expansion

With the expansion loop being the biggest growth lever, as a PM I have to design for it deliberately. I do this through three principles.

Principle #1:Start with the simplest possible first use case

The temptation is to show the full scope of what the agent can do – but complexity at the start slows everything down and raises the stakes of the first impression. 

You want to demonstrate value as soon as possible. A narrower, faster-to-deploy first use case gets the agent into a real workflow sooner, which is the only way the customer starts building trust and the expansion dynamic begins.

Principle #2: Measure what matters

From there, measure what actually matters to the people the agent is working alongside – not only the CFO's cost savings, but the operational output the team is being measured by. 

Optimizing for the number of appointments booked versus time spent on unproductive calls makes a difference. Getting those numbers right is what makes the agent feel like a team member rather than a software tool. They're also what gets shared internally, without prompting, when that stakeholder goes back to their team.

Principle #3: Show what else your agent is capable of

The piece most PM thinking misses is this: stakeholders need to understand how the agent works, not just what it produces. 

If they only see the output, they have no mental model for what else the agent could take on. The expansion loop only fires when the people closest to the work understand the agent's capabilities well enough to start connecting them to their own unsolved problems. That means being clear – not with technical documentation, but with a practical sense of what kinds of tasks this agent can learn, and what it would take to get there.

Closing thoughts

While I’m mindful that this doesn't answer whether we have a product-led or a sales-led growth motion, what I hope it does show is that the growth motion for enterprise AI agent products is genuinely hybrid: the initial foot in the door requires sales, conferences, and contracts. There's no way around that, and pretending otherwise sets you up for the wrong strategy.

But once inside, the dynamics change. Expansion is driven by whether the product delivers measurable value to the people using it day-to-day – and whether those people understand it well enough to want more of it. You can't manufacture that pull. Either the product is useful enough that people want more of it, or it isn't.

That shifts the PM role in ways that don't show up in most job descriptions: less time on feature roadmaps, more time on deployment simplicity, tracking what actually matters to the people using it, and the kind of clarity about what the agent can take on that turns a daily user into an internal champion. 

It's not purely product-led. But the part that compounds – and the part that builds something defensible – is.