SYSTEM NOTICE

Auto translation by AI. Be sure, accuracy, nuances and authorial intent may not be fully reflected.
見出し画像

GTM Strategy in the AI Era (Part 1): 3 Models for 'Autonomous EXPAND' that Generate High NRR

Mayu Kudo | 工藤 真由 | Globis Capital Partners

Introduction: Can AI, with its heavy costs, scale GTM without increasing headcount?

On May 30th, LegalOn Technologies CEO Nozomu Tsunoda posted the following.

In my interpretation, this post pointed out that the AI-nativity of SaaS could become a 'SaaS suicide' that abandons high gross margins. If you cannot design a growth rate and a PLG-style GTM to match that, shouldn't you treat SaaS and AI companies as separate entities and choose a business model for each domain? It is often overlooked, but I think it is a very important question.

Although it was posted from the perspective of a transition from traditional SaaS, I think it is an issue that AI companies must also consider when thinking about their own strategies.

With a SaaS model, gross margins are high, so you can make upfront investments in GTM and launch a business with a Sales-Led approach. However, for AI companies with heavy costs, the budget available for GTM investment is more limited.Therefore, unless you can establish a Product-Led GTM model, there is a high possibility that the strategy will fail from the start, so to speak.

On the other hand, my experience so far has been that the areas where PLG (Product-Led Growth) works in B2B software, especially for enterprises, are quite limited. Most of the products that grew in a PLG-like way were developer-oriented software (or products that started there and expanded their target). In fact, I had the impression that because AI aims to replace tasks and therefore requires deeper knowledge and customization, the implementation costs would be higher than traditional SaaS.

If that is the case, how can AI companies with heavy costs realize a GTM that drives growth through products rather than personnel? Is that really working in enterprise settings? This time, I would like to delve into this question while tracing examples of global AI application layers. To preempt the conclusion, the key lies in how to make LAND (acquisition) autonomous, not EXPAND (expansion).

In other words, what I want to say in this article is not the simple story that 'PLG works even for enterprise AI.' A structure is emerging where, after landing with a high-touch approach, usage, data, workflows, and internal assets self-proliferate within the product, and only EXPAND becomes autonomous. This is my argument for the realistic form of 'product-led' in enterprise AI.

Chapter 1: The areas where PLG is effective in B2B software are limited

3 conditions for PLG to work

The term PLG was originally popularized by Kyle Poyar and others at the VC firm OpenView. It refers to a GTM model where the product itself becomes the engine for acquisition, education, and expansion. Free tiers, freemium, self-serve sign-ups, and viral spread within the product—Slack, Zoom, Figma, and Notion have been cited as representative examples.

However, PLG does not work for every product. Synthesizing the conditions mentioned in various places, I believe that for classic PLG to function, the following three conditions generally need to be met.

First, Time to Value must be immediate. You should be able to experience the value of 'Oh, this is useful' within minutes of signing up. For products that take weeks to set up or require integration with other systems, free users will leave before they feel the value.

Second, using it itself must be a motivation to involve others (virality). Sharing documents, editing designs together, inviting people to channels—the act of using the product itself must be structured to bring in new users.

Third, you must be able to make purchasing decisions alone. An individual or team leader must be able to decide to implement it with a single credit card without going through internal approval or the information systems department.

These three conditions were translated into the context of AI-native by GTM consultant Sachin Jha in his essay, 'Why I Stopped Recommending PLG to Early-Stage AI Startups.' His argument is simple: because most AI products require setup, integration with existing systems, and the acquisition of trust (building up pilots or reference customers) at the time of introduction, they fail to meet all three of the above conditions. They require preparation time before the value can be felt, cannot be decided by the frontline alone, and do not have mechanisms to spread on their own. That is why he says that to sell products in a certain price range or higher, some kind of sales and implementation support is ultimately unavoidable.

PLG is less effective for enterprises

Especially for enterprises, these three conditions are almost never met. In particular, for contracts exceeding 10 million yen in ACV, a purchasing process involving months of implementation and the involvement of information systems, legal, and procurement departments is a prerequisite. It is a world at the opposite extreme of 'alone, in minutes, and spreading on its own.'

Jha gives specific examples. Wiz, in cloud security, reached 100M ARR in 18 months with an enterprise-first, sales-led approach and was later acquired for $32 billion. Clay, which started with self-serve, also shifted to enterprise sales in the fall of 2023 when it reached several million dollars in ARR. What is impressive in his observation is the sentence, 'There are no companies that have moved from SLG to pure PLG; all transitions have been in the opposite direction.'

The only exception he names is products that start with developers. PLG is effective from an early stage only when value is generated in minutes without settings or human intervention and is inherently viral. The proof of this is Cursor (Anysphere). However, even Cursor has added high-touch enterprise sales later to go after the Fortune 1000.

The 'Winners of PLG' in the AI Era Are Still Skewed

This is supported by looking at the current AI application layer. The names cited as having 'exploded in the AI era through PLG' are remarkably skewed.

Representative examples of 'PLG companies recording high growth rates' include Lovable, Cursor, Gamma, and Perplexity. It is said that Cursor reached 500M ARR in mid-2025 and 2B ARR in February 2026, and barely hired any enterprise sales representatives until they exceeded 200M. Lovable reached 200M ARR in about 12 months from its public launch. Bolt.new went from zero to 20M ARR in just two months, and Gamma is said to have reached 100M ARR with about 50 employees as of January 2026, with 70 million users (according to SaaStr).

However, the names listed here are all of the 'you understand it as soon as you touch it' variety. In other words, classic PLG—PLG as an acquisition motion (free x viral x self-serve)—is,even in the AI era, mostly limited to the developer and prosumer domains.

Chapter 2: Even So, GTM in the AI Era Is a Problem for Every Company

We have looked at the limitations of PLG (acquisition motion) so far. So why is it that everyone is forced to think about a 'GTM that drives growth through the product rather than personnel'? The reason lies in the change in cost structure.

Going forward, it is inevitable that a new cost called inference cost will change the margin structure of AI companies. According to an ICONIQ report from January 2026, inference costs account for an average of 23% of revenue for AI B2B companies at the scale stage. Jason Lemkin of SaaStr calls this the 'AI tax' and points out that SaaS companies that once boasted 85% gross margins are now being forced to adjust to 60-70%. Bessemer's research also shows that the gross margins of AI-native companies generally remain at 60-65%, significantly lower than the 80-90% that defined the cloud over the past decade.

If gross margins fall, the 'amount' that can be allocated to S&M decreases. Consequently, high-cost SLG cannot be maintained at its current scale. That is why,GTM where revenue is not proportional to personnel = a product-led economic structure in a broad senseis something everyone is forced to explore.

This is a continuation of the 'AI-driven GTM (internal AI utilization)' I wrote about in a previous article. In the US, they are moving beyond mere 'utilization' of AI toward the 'autopilotization' of business operations themselves. By having AI agents take over sales and marketing operations, GTM is run with a small number of people. In other words,'compressing the seller's operations with AI' (= AI-driven GTM) and 'rebuilding the business model itself to be product-led' (= the theme of this article) are two sides of the same coin. In a world where gross margins are falling, you cannot survive unless you do both.

▼▼ Click here for an article summarizing the latest US initiatives regarding AI-driven GTM ▼▼
The Forefront of US AI-Driven GTM: The Thirst for Growth Seen at SaaStr AI 2026

Chapter 3: Two Meanings of 'PLG'—Acquisition or Economic Structure?

Here, I will organize the important concepts that serve as the premise for this article.

Even when we say 'PLG', two scopes are mixed together.
PLG itself is a concept proposed by Blake Bartlett of OpenView around 2016 and later widely popularized by Kyle Poyar and others.

The commonly used meaning is,

(A) PLG as an acquisition motion—a method of 'acquiring' customers through free tiers, virality, and self-serve.

I think this is what is often referred to. When I hear PLG, this is the meaning that first comes to mind. The argument seen in Chapter 1 that 'PLG is limited to developers and prosumers' also refers to this narrow definition (A).

However, OpenView has defined PLG from the beginning as a 'growth strategy where the product itself becomes the primary driver ofacquisition, retention, and expansion'. If we return to this original definition, I believe the center of gravity of PLG is actually in

(B) Product-Led as an economic structure—unlike SLG, where personnel must be increased proportionally to grow revenue, this involves having the product itself handle acquisition, education, and expansion, removing people from being the bottleneck of growth.

I believe this is where it lies.

When we talk about decoupling revenue growth from personnel growth and leveraging S&M—that is, 'make GTM Product-Led to fill the gap in falling gross margins'—what we should be referring to is clearly (B).

This is where the framework I have been considering up to the previous chapter comes into play. The winning strategy for enterprise AI can be summarized as:

LAND with a high-touch approach, have the product autonomously EXPAND, and achieve high NRR (Net Revenue Retention).

Acquisition may be manual, but expansion is driven by product usage. This is the most realistic form of 'product-led as an economic structure' that can exist in the enterprise.

For reference, in terms of metrics, whether (B) is working can be measured by the following three points: (1) S&M efficiency (magic number or CAC payback), (2) usage-based automatic expansion (NRR), and (3) revenue per employee. To reiterate, the essence is 'whether expansion requires human labor'.

And this is the core of this article. Even if we say 'the product handles expansion,' unless we break down what kind of mechanism is actually driving that 'autonomous EXPAND', we cannot answer 'so, how do we build it specifically?' The mechanism of this self-proliferation can be broadly divided into three types. Let's look at them in the next chapter.

Chapter 4: The '3 Types' of Autonomous EXPAND

So, how do major US AI application layer companies achieve autonomous EXPAND? I would like to categorize the ingenuity of each company into three types based on the classification axis of 'in-product/in-customer mechanisms that strongly drive EXPAND.' I have also analyzed what kind of monetization model they often settle on as a receptacle for converting that EXPAND into revenue.

Note that this is not a table for classifying companies in a MECE manner. In reality, many companies possess multiple types, and here I am focusing on the primary mechanism that most strongly drives each company's EXPAND.

Created by the author

It should be noted that all types assume a high-touch LAND accompanied by 'implementation support that deeply enters the field.' This implementation support is increasingly being handled by a job role called FDE (Forward Deployed Engineer). Heavy LAND is common. What differs is how the subsequent EXPAND runs on its own.

Type 1: AI Business Transfer Model—The scope of tasks AI can handle expands

First, let's start with the type where EXPAND most directly links to revenue. In this model, EXPAND occurs as the range of existing tasks that AI can handle, the number of issues solved, and the volume of processing increase. Because the scope of tasks the product can solve expands, and that increase is converted into revenue in units of results, processing volume, medical cases, or actions, it is characterized by having the most direct autonomy in revenue generation among the three types.

So, what increases the rate of business transfer to AI?Type 1's autonomous EXPAND rides on 'the improvement of AI's capabilities'. And there are mainly two things driving that capability improvement.

One is the data loop where usage makes it smarter. By incorporating SOPs, past dialogues, business policies, and customer data, and evaluating/improving failures and escalations from actual dialogues, it increases the scope of response and resolution rate. The other is the vendor's own model and algorithm improvements. By refining dedicated search/re-ranking models and mechanisms for supervising agents, the resolution rate increases independently of the amount of accumulated data.

What I want to emphasize here is that the data accumulated in Type 1 is ultimately just 'fuel to make AI smarter'. The assets of Type 2 and Type 3, which we will look at later, are things that are repeatedly referenced and reused by customers. In contrast, the data in Type 1 is used as fuel to make AI smarter rather than as an asset that customers directly reuse. The value is delivered to the customer as 'the result processed by AI.' Therefore, billing is also based on the amount processed/solved by AI, not the amount of data held. Even without sales pushing for upsells, as the product gets smarter and the scope of tasks it can handle widens, the billing target also expands autonomously—this is the self-proliferation of Type 1.

Sierra is symbolic. It does not LAND as a plug-and-play vendor, but as a 'strategic partner' that co-builds custom agents tailored to each company's brand voice, policies, and workflows. What is important is that Sierra's EXPAND rides on the expansion of 'the amount of work AI solved on behalf of humans,' not the total volume of inquiries.

The mechanism by which Sierra increases its resolution rate is precisely a combination of the two drivers mentioned above. The agentification of business knowledge via Ghostwriter, the automatic generation of evidence-based knowledge from solved dialogues, and the improvement of dedicated search/re-ranking models and supervisory agents. Sierra itself has also announced that its dedicated models outperform commercial models, improving resolution rates by up to 16 percentage points. The data loop and model improvements work in tandem to continuously push up the range that AI can solve.

However, as it is Type 1, Sierra is adjacent to the 'COGS (Cost of Goods Sold) trap.' As the range of tasks AI can handle expands, revenue grows, but at the same time, inference, execution, and monitoring costs also increase. That is why the key to winning in Type 1 lies not only in expanding the scope that can be transferred to AI, but also in how much the resolution rate can be increased and the cost per case can be lowered. The structure of this trap and how to escape it will be described in detail in the second part.

▼▼ Click here for an article summarizing the details of Sierra's strategy ▼▼
Decacorn in 2 years since founding: A thorough dissection of the strategy of 'Sierra,' the synonym for US AI startups

Decagon is also the same type. Because it charges based on the amount processed/solved by AI rather than the number of seats, EXPAND rides on the expansion of channels and workflows handled by AI, not the total volume of inquiries. The key is a mechanism called Agent Operating Procedures (AOPs), which defines the business procedures of AI agents in natural language. It adds customer support workflows such as refunds, reservation changes, and identity verification, expands horizontally to voice/chat/email, and improves behavior through Testing & QA and Insights. In other words, what is increasing Decagon's business transfer rate is the workflow addition via AOPs and the cross-channel expansion/improvement loop.

Parloais a German-born player specializing in contact center voice. EXPAND here does not simply mean an increase in conversation volume, but rather an expansion of the operational scope handled by AI. By designing, testing, scaling, and optimizing agents on an AI Agent Management Platform, the scope expands from voice to other channels, from a single language to multiple languages, and from simple responses to business actions like identity verification, billing, returns, and appointment changes. It is a model that expands by gradually transferring tasks previously handled by BPO or human contact centers to AI.

Abridgeis a leading medical AI scribe. Leveraging the credibility of being founded by clinicians, it LANDs in hospital systems with a 90-day pilot. It starts with clinical documentation and, by deeply integrating into existing workflows within the EHR, expands the operational processes handled by AI from "note creation → ordering → diagnostic coding → billing documentation." Since billing is linked to the number of clinical encounters, the structure is such that EXPAND progresses as more clinical tasks are transferred to AI. Furthermore, if it expands into the revenue cycle area, which connects clinical content to insurance claims, it leads directly to not only cost reduction but also revenue recovery for the hospital. Note that while Abridge also has characteristics of Model 2 in that clinical conversations and notes are accumulated and reused, its billing and primary axis of expansion are strictly "the number of clinical encounters processed by AI," so its essence is Model 1. It is accurate to view the accumulated data not as a "referenced foundation" that drives expansion like in Model 2, but as "fuel to make the AI smarter," similar to Sierra in Model 1.

Although their billing structures differ, these four companies can all be classified into the same Model 1 in that they "expand the scope of tasks AI can handle within the product and convert that increase into revenue through the volume of processing and resolution." The key is the increase in the rate of task transfer to AI, and what drives this is the data loop, model improvement, and deep integration into business workflows.

The question remains the same for Model 2 and Model 3 viewed from this perspective. Rather than upsells and cross-sells by sales, which part of the product is driving the expansion? In Model 2, the accumulated data foundation attracts the next use case, and in Model 3, business assets newly created by users are reused within the organization.

Model 2: Data Accumulation Model — The next use case is built on top of an accumulated data foundation

While Model 1 expanded through "AI capability improvement," Model 2 expands through "the accumulated data itself becoming a reusable foundation." Whereas the data in Model 1 is consumed as "fuel to make the AI smarter," the data in Model 2 becomes a foundation that is itself repeatedly referenced and reused. Therefore, the marginal cost of expansion is low, and it has a stock-like character.

A prime example is Glean (enterprise search). What drives Glean's EXPAND is not just a search UI, but an Enterprise Graph that connects data, permissions, people, and business context across all company apps. Glean connects to over 100 apps, making information scattered across Slack, Google Drive, Jira, Salesforce, etc., searchable, summarizable, and inferable while maintaining permissions.
What is important here is that once the Enterprise Graph is built, the cost of placing the next use case on top of it drops significantly. Even if it starts with "internal search" or "Q&A," on that same data, permissions, and context, Glean Assistant can perform summaries and answers, and Glean Agents can execute workflows like requests, investigations, updates, and report creation. Without sales having to pitch additional modules every time, users expand the scope of use themselves, thinking, "This data is already connected, so I can use it for this task too." This is the self-proliferation of Model 2. In terms of billing, Glean has a receptacle that converts agent execution or AI processing—i.e., "the amount of work AI completed on top of connected data"—into revenue by placing a usage-based meter at the organizational level called "FlexCredits" on top of seat-based billing.
Harvey (legal AI) is also a player that is easier to understand as a data accumulation model, at least as far as its current expansion drivers are concerned. At first glance, Harvey appears to be a seat-expansion model where "the success of one department propagates to others, increasing seats." Indeed, that aspect exists, and it uses a seat-based billing model anchored to the high hourly rates of lawyers, and it is likely that sales and CS efforts are significantly involved in increasing seats.
However, what essentially supports Harvey's stickiness and expansion is the case knowledge accumulated in the Vault/Memory—precedents, contracts, past cases, document analysis, and research results—a data foundation specialized for legal affairs. Once this foundation is built, research, drafting, and review can all be performed on the same data, and when a neighboring practice group wants to use those assets, they need their own seats. Lawyers cannot leave Harvey because their case data and business context are accumulated within it.
It is easy to understand if you view it as a contrast between general and specialized within the same Model 2: Glean "cross-connects general data across the entire company," whereas Harvey "deeply accumulates data specialized in one area, legal affairs."
Note that the assets accumulated in Model 2 are characterized by the vendor crawling and structuring the customer's existing data (documents scattered within the company or uploaded case files) and linking them with permissions and business context to make them a reusable foundation. While Model 3, which we will look at next, is "assets newly created by the users themselves from scratch," Model 2 is a "foundation born from aggregating and structuring data that already existed." The initial company-wide data connection or input of case data requires the involvement of administrators and staff, but once the foundation is built, the self-proliferation of Model 2 is that use cases are autonomously placed on top of it.

Model 3: User Asset Model — Users create new business assets, which are then shared and reused

The third is a model that expands as users themselves create business knowledge as new assets, which are then shared and reused within the organization. While Model 2 "aggregates and structures data that already existed," Model 3 is decisively different in that "field users create new business assets that did not exist before." If Model 2 is a "passive stock generated by the vendor connecting things," Model 3 is an "active stock created by field users themselves." The vendor provides a "place to create (platform)," and the users are responsible for the creation and diffusion of value. It is the structure closest to the original PLG self-proliferation, and because users take over the work, the vendor's marginal cost is also low.

Writer is the representative of this model. What drives Writer's EXPAND is a mechanism where users can create and share business knowledge as reusable assets. Skills are reusable blocks that encode a team's methodology, quality standards, and decision-making patterns. The Playbook builder allows even non-technical users to combine these Skills to create workflows and agent capabilities in natural language. Furthermore, by connecting the Knowledge Graph to company-wide data, the Skills and Playbooks created by users become not just templates, but business assets connected to the company's unique context (this data connection is a Model 2-like foundation, but the protagonist of Writer's expansion is the Skill side created by users).

The self-proliferation of this model occurs when excellent Skills or Playbooks created by someone are shared within the organization and reused by other members or teams. For example, a competitive analysis Skill created by the marketing team is used in sales materials and management meetings, and review procedures created by legal and HR are incorporated into the workflows of other departments. Because users are responsible for both the creation and diffusion of value, assets increase within the product without the vendor having to implement or sell them individually each time. Writer's NRR is 160%, and it is said that some customers expand from an initial contract of $200,000–$300,000 to about $1 million.

While Model 2 (Glean/Harvey) "aggregates existing data to build a foundation," Model 3 (Writer) "has users create new business assets." Even though both are "accumulating stocks," Model 2 and Model 3 are clearly separated by these two points: whether it is an aggregation of existing things or the creation of new ones, and whether the entity doing the accumulating is the vendor's engine or the field users themselves.

Piercing the 3 models with the self-proliferation mechanism

If we line up the three models again based on "what accumulates and drives expansion," the differences become clear. In Model 1 (task transfer), what accumulates is data as fuel to make the AI smarter—it is consumed, and the value is delivered as the result processed by the AI. In Model 2 (data accumulation), what accumulates is foundation data that is repeatedly referenced—data that was originally in the company is aggregated and structured by the vendor's engine (Glean is company-wide, Harvey is legal-specialized). In Model 3 (user assets), what accumulates is business assets that users themselves create from scratch—created by the field and reused within the organization.

Whether "AI gets smarter and the scope it can handle expands (Model 1)," "use cases are placed on top of an accumulated data foundation (Model 2)," or "assets newly created by users are reused (Model 3)." Even with the same "autonomous EXPAND," the driving sources are this different. And this difference in driving sources dictates the differences in billing models we will look at next, and the "fate of gross margin" we will cover in the second part.

Chapter 5: The AI era 'accelerates' product-led EXPAND — but as a double-edged sword

Here, I would like to take a step back and pose a big question.Is product-led EXPAND inherently easier to trigger in the AI era than in the SaaS era? My assessment is "Yes, it is structurally easier to accelerate." However, with the reservation that this acceleration is not something to be happy about unconditionally.

Why does it accelerate? There are three reasons.

First, expansion no longer requires 'increasing headcount'. In the SaaS era, product-led EXPAND was ultimately centered on "increasing the number of people using it (increasing seats)." For Figma and Slack, expansion meant an increase in the number of users, and the upper limit was tied to "how many people use it on the customer side." In the AI era, the unit of EXPAND has shifted from "people" to "the scope of tasks and processing volume handled by AI" (Model 1). Even without increasing the number of people, it expands if the tasks AI can handle expand. With the ceiling of headcount removed, the theoretical room for expansion has expanded at once.

Second, it can have a feedback loop where 'being used itself makes the product stronger'. SaaS-era products remained at the functionality they had at the time of creation, and improvements had to be added manually by the vendor. The AI era is different. In Model 1, as it is used, data is sent for evaluation and improvement, increasing the resolution rate; in Model 2, as connection and usage progress, the value of the data foundation increases; and in Model 3, as more assets are created, reuse occurs. This self-reinforcing loop, which runs through all three models, is an accelerator that turns being used directly into EXPAND.

Third, the hurdle for the 'creation side' of value has dropped dramatically. In the SaaS era, specialized knowledge was required to build advanced workflows or apps within a product. In the AI era, non-technical users can create agents and Skills in natural language (Model 3). The entity creating value has expanded from vendors and a few advanced users to everyone in the field. The reason Model 3's self-proliferation is fast is that the base of creators has expanded at once due to AI.

In other words, in the AI era, there are many more accelerators for product-led EXPAND than in the SaaS era. This is definitely a tailwind.
However, one must be careful about the point that it is accompanied by the acceleration of inference COGS. Especially in models like Model 1, which grow in conjunction with processing volume and resolution count, the more it grows, the more tokens and execution costs it consumes. Product-led EXPAND in the SaaS era had a structure where the marginal cost associated with additional usage was relatively low, and it was easy to contribute to high gross margins as seats and usage increased. In the AI era, the acceleration engine of EXPAND itself brings costs. "It has become easier to accelerate, but that acceleration can erode gross margins"—this is the "COGS trap" of the AI era.

And the trap is not limited to Model 1. A different kind of risk lurks in Model 2 and Model 3, which have seat-based billing as a pillar of revenue. As AI takes over tasks on the customer side, customers may reduce personnel = seats. If revenue is tied to seats, it could turn into contraction rather than expansion—this is the "AI seat risk." The fact that Model 2 and Model 3 try to layer usage-based meters (FlexCredits, etc.) or user assets on top of seat-based billing can also be seen as an attempt to shift revenue from "number of people" to "use of accumulated foundations/assets" to mitigate this risk.

Chapter 6: Conclusion (Part 1) — Autonomous EXPAND is realized through '3 models'

I will conclude by returning to the initial question once more.

The proposition thrust upon AI companies burdened by high costs is that 'unless you can establish a Product-Led GTM model, you will fail.' However, that 'Product-Led' should be read as referring to (A) PLG as an acquisition motion, not (B) product-led as an economic structure. And (B) is already a reality in the enterprise sector, in the form of 'LAND with high-touch, have the product autonomously EXPAND, and achieve high NRR.' The three models examined in this article—AI Business Transfer Model (Model 1), Data Accumulation Model (Model 2), and User Asset Model (Model 3)—are the concrete ways to realize that autonomous EXPAND.

In other words, the answer to my initial hesitation—'How can you realize a GTM in enterprise software where the product, not people, drives growth?'—is this: PLG as an acquisition motion certainly continues to be prevalent in the developer and prosumer domains. However, product-led as an economic structure is quietly permeating the enterprise as well, through three self-propagating mechanisms.Moreover, in the AI era, that expansion is easier to accelerate than it was in the SaaS era.

That said, 'high NRR,' the key to (B), cannot be taken at face value. As touched upon in the previous chapter, two pitfalls threaten it. One is the 'COGS-linked trap' lurking in models that grow based on processing volume or number of resolutions, like Model 1—where expansion itself brings inference costs and can actually erode gross margins. The other is the 'AI seat risk' lurking in Model 2 and Model 3, which rely on seat-based billing—if customers reduce headcount using AI, revenue tied to seats can shrink. Even with the same '130% NRR,' whether it is an expansion that increases gross profit or one that erodes it, and whether it is a sustainable expansion, are completely different things.

However, in the three models seen in this article, a direction to mitigate these pitfalls is beginning to emerge. Model 1 is trying to increase resolution rates to lower COGS per case, and Models 2 and 3 are trying to shift the center of gravity of revenue from 'number of people' to 'utilization of accumulated infrastructure and user assets.' What they have in common is that they are trying to shift expansion away from relying solely on 'things that flow and disappear' (processing volume, number of people) and onto 'assets that accumulate and remain' (referenced data, business assets created by users)In the second part, after dissecting the true nature of this 'COGS-linked trap' and 'AI seat risk' with numbers, I will delve into how to distinguish the 'quality' of NRR—whether it is an expansion that increases gross profit and is sustainable—and what it specifically means to shift expansion from 'things that flow and disappear' to 'assets that accumulate and remain.'

Note: Main sources referenced in this article

Economic Structure of Gross Margin Compression

PLG Conditions for Success and Skepticism

Self-Propagation and Billing Models of Each Company

NRR Benchmark

  • FE International, Prospeo (Public SaaS median NDR approx. 108% in early 2026, enterprise median 118%, top quartile over 130%)

Note: The figures, dates, and facts mentioned in this article are based on public information available as of June 8, 2026. While AI was used in the writing of this article, the final editing and fact-checking were performed by the author. This article represents the author's personal views and analysis and does not reflect the official position of any company or organization the author is affiliated with. Furthermore, it does not recommend any specific investment or business decisions.


いいなと思ったら応援しよう！