Product-Led Growth Engineering in the AI Era

Product-led growth (PLG) was built on a premise: let the product sell itself. Users sign up, use the product, get value, convert to paid. The engineering team's job was to make the product good enough to drive this loop — fast onboarding, clear aha moments, low friction on the path to value.

That premise is still valid. What has changed is the nature of the user. AI agents are now users of products. Not metaphorically — Cursor's users are developers using the product to build things faster; the "product" those developers use is partly AI-native. Lovable's users are non-technical founders whose relationship with the product is fundamentally different from a traditional SaaS user. Engineering for PLG in 2026 requires designing for this new user type alongside the old one.

From PLG to ALG: Agentic-Led Growth

Agentic-Led Growth describes products where AI agents are both the primary tool users interact with and the delivery mechanism for value. The user does not "use the product" in a traditional sense — they describe what they want to an agent, and the agent does the work.

The implications for growth engineering are significant. Traditional PLG tracks activation events (user reached aha moment), engagement metrics (DAU, feature usage breadth), and expansion triggers (seat count, data volume). In an ALG product, these metrics are still relevant but the events that matter have shifted. "User completed a task using an agent" is more meaningful than "user clicked a feature button."

The activation metric for an AI-native product is often "first successful outcome" rather than "first session" or "first feature used." Engineering teams building growth infrastructure for these products need instrumentation that tracks outcome completion, not just feature interaction.

The Death of Per-Seat Pricing

Per-seat pricing assumes that value scales with the number of humans using the product. In a world where AI agents do the work, "seats" is the wrong unit. A team of 5 using an AI-heavy product may derive 50x the value of a team of 5 using a traditional tool — and a team of 2 using agents may do more than a team of 20 without them.

Two models are replacing per-seat: WaaS (Work as a Service, per-task pricing) and RaaS (Results as a Service, per-outcome pricing). WaaS: you pay per agent task completion. RaaS: you pay based on measurable outcomes (revenue generated, costs saved, tickets resolved).

The engineering work for per-task pricing: task definition, task completion detection, task attribution, and usage reporting infrastructure. This is non-trivial. A task that starts as "user asked agent to do X" needs to be tracked through to completion, with idempotency (so a task does not get double-billed if the agent retries), rollback handling, and clear user-visible reporting.

The Inference Cost Problem Killing Freemium

Classic PLG depends on a generous free tier to drive top-of-funnel adoption. The economics work when the marginal cost of an additional free user is near zero. For AI-native products, the marginal cost of an additional free user is significant — every interaction involves LLM inference, which costs real money.

Lovable, Cursor, and similar products have all navigated this tension. Lovable moved from unlimited to credit-based free tiers. Cursor offers a limited number of fast requests per month free. The free tier still exists, but it is carefully bounded to keep the unit economics viable.

Engineering AI Agents as Users

AI agents are now users of products in a literal sense: API-consuming agents that sign up, activate, and expand exactly like human users — except they do it at machine speed with no friction. A well-designed PLG product that exposes a good API will have agentic users without deliberately targeting them.

The growth engineering implication: your activation and expansion funnels need to handle agents. This means machine-readable onboarding (API keys without email verification requirements that an agent cannot complete, webhook-based activation confirmation rather than click-confirmation), machine-readable documentation, and usage-based expansion that works when the "user" making 10,000 API calls is an agent rather than a human.

What 80% GenAI Embedding Means for PLG

Gartner's estimate that 80%+ of software vendors will embed GenAI in their products by 2026 means your competitive differentiation is increasingly not "do you have AI features" but "how well do your AI features deliver outcomes." PLG for commodity AI features (summarise, generate, rewrite) will not work — the features are table stakes. PLG for domain-specific AI that solves a problem no horizontal AI tool addresses is where the growth leverage lives.