- Why Land and Expand Strategies Fail to Expand
- Failure one: the wrong account for a land and expand motion
- Failure two: a first deal built to close, not to expand
- Failure three: expansion pricing that breaks down at scale
- Expand and land: expose the expansion pricing upfront
- Land and expand is a pricing architecture problem
- FAQs
Why Land and Expand Strategies Fail to Expand
TL;DR: When land and expand stalls, the cause is rarely the sales motion. It is the pricing architecture underneath: the wrong account, a first deal built to close, or expansion pricing that stops scaling with value. The fix is expand and land, which puts the whole expansion schedule on the table before the first deal closes.
Land and expand is a go-to-market motion in which a vendor sells a limited initial footprint, proves value with an early user group, then grows revenue by expanding to more users, teams, and capabilities over time. It describes how you acquire and grow an account, not how you charge for the value inside it.
When land and expand works, expansion feels almost automatic: customers add users and upgrade over time, and most of that revenue falls to the bottom line because you already paid to win the logo.
The trouble is that the expand phase often never arrives. The initial sale closes, the account sits flat, sometimes it shrinks. The renewal comes in at the footprint you landed, and the growth you modeled turns out to be a slide nobody can execute.
One reframe changes how you fix it. Land and expand is a channel decision, not a pricing model. The advice you will hear at the late-growth stage, optimize your land and expand model to drive expansion revenue, treats the motion as the lever and misses where expansion is actually decided. Whether an account expands is decided upstream, in the pricing architecture you built before the first quote. When expansion stalls, it traces to one of three structural failures, and naming yours is most of the fix.
Failure one: the wrong account for a land and expand motion
Not every deal deserves a land and expand motion, and applying it where it does not belong is the first place expansion dies. An account can promise a large future rollout that never materializes, whether or not the buyer ever intended it to. The small first order lands, the promised expansion evaporates, and you hold a discounted footprint with no growth path.
The accounts where expansion compounds share a shape: software that will touch many people across distinct functional groups rather than a handful of specialists, a buyer with genuine will to standardize and support adoption, no entrenched vendor with political protection, and a first user group representative enough to be a credible reference for the groups that follow. What you are reading for is whether the account has enough internal surface area for adoption to travel. When most of that shape is absent, forcing the motion produces the flat account you were trying to avoid.
Failure two: a first deal built to close, not to expand
Even in a well-chosen account, expansion stalls when the first deal was configured for the signature rather than for what comes after it. This is the failure we see most often, and the most expensive, because the damage is invisible at close and only surfaces at renewal.
Why a thin first deal stalls expansion
Take a first sale that licenses part of a customer’s sales team but leaves out the managers and assistants on the same workflow. The users you included see some benefit, but the workflow around them stays marbled with manual steps. Before long someone concludes the software is not a complete solution, and the door opens for a competitor. A manager who was never in the first deployment has no stake in the renewal, and that is an account structure problem, not a sales problem.
A thin first deal also punishes your own expansion team. Account managers walk into friction they cannot explain, find the initial configuration was wrong, and have to re-cut the original deal before they can grow it. That costs money, and worse, momentum.
The value metric decides whether the first deal pulls
The deeper version of this failure sits in the licensing model. The value metric, the unit your price attaches to, has to track how users actually turn the software into economic gains. Attach it to how buyers imagine value, or to whatever unit was easiest to quote, and the first sale generates no outward pull. Attach it to how customers genuinely create economic value, and usage growth turns into revenue growth on its own. Peer-reviewed research in industrial markets finds that a vendor’s ability to tie price to the monetary value a customer actually gains is a measurable predictor of firm performance. The value metric is the upstream decision in the architecture, and the wrong unit here means every expansion conversation inherits the mistake.
A related claim is that moving to usage-based or consumption pricing is what lifts expansion revenue and net revenue retention. The correlation is real, but the billing model’s name is not doing the work. The lift comes from a value metric that tracks value; a consumption meter on the wrong unit only grows the invoice, not the account.
Was Your First Deal Configured to Close or to Expand?
Answer a few questions and see exactly where your licensing, packaging, and pricing decisions create expansion friction before the renewal conversation begins.
Failure three: expansion pricing that breaks down at scale
The third failure shows up later, when the account is genuinely trying to expand and the pricing stands in the way. A deal that made sense at a hundred units has to also make sense at a thousand, or ten thousand, and often it does not.
Value per added group diminishes as you expand
Your first landfall usually captures the highest-value users, the group whose work most directly drives revenue. As you penetrate deeper, you reach groups that use a narrower slice of the product for work that affects revenue without producing it directly, and the value each additional group derives diminishes.
Peer-reviewed work on quantity-discount design describes the same shape from the buyer’s side. A discount schedule does two jobs at once: it rewards volume, and it separates buyers by willingness to pay. That second job gets stronger the more buyers differ in how they use the product and what they will pay, and a schedule tuned to neither underperforms. If your pricing does not bend to that reality, someone in the account eventually says, “I would love to buy more, but at that rate it no longer makes economic sense,” and expansion stops there. We call the result a shallow deployment: the software stays lodged in the one narrow slice of the workflow where the economics still work, and never reaches the rest of the account.
Shallow deployment leaves you easy to leave
When the pricing model stands in the way, the customer keeps the highest-value work on your platform and cleaves the rest off to cheaper alternatives: a workaround, people doing work the software could absorb, or a point solution for the lower-value groups. Every one of those costs you expansion revenue that would have fallen almost entirely to margin. The deeper danger is quieter. A customer lodged in one narrow slice of the workflow has little embedded in you, so their switching costs stay low. Peer-reviewed work on switching costs locates them in the learning and integration a customer accumulates over time, the very embedding a shallow deployment never creates. That is tolerable in a steady market and dangerous during market chaos, when buyers consolidate vendors and cut anything that never went deep.
This is where the discount surface itself becomes the lever. Discretionary discounts that are re-litigated at every expansion turn the initial concession into the customer’s new anchor, and each expansion becomes a fresh fight. A discount structure that scales with value, and that the customer can see, does the opposite: it makes buying more the obvious move. The mechanics of engineering that discount surface, and the discounting patterns that quietly slow growth, decide whether the structure holds.
Expand and land: expose the expansion pricing upfront
The resolution to all three failures has a name: expand and land. It flips the motion. Instead of landing a small footprint and negotiating each expansion afterward, you expose the full expansion pricing at the start, so the customer sees their investment at every increment and becomes invested in their own growth path. Discounts are earned and visible, not discretionary and negotiated.
A worked example: how per-unit negotiation stalls
An illustration shows the mechanism. List price is $100 per unit per month. A 100-unit contract at a 25 percent volume discount runs $7,500 per month, and at that size the customer hesitates. So the rep “lands” a 10-unit pilot at the same 25 percent, $750 per month, offered as good faith toward the expansion to come.
At expansion, the negotiation restarts with 25 percent as the new floor. Because the per-unit price never scaled with value, the first 10 units generate enough on their own that expansion slips to a date that never arrives. Even when it happens, it lands lower after a long stretch of back-and-forth.
Why expand and land pulls the expansion forward
Now run the same account as expand and land. The rep exposes the pricing model upfront, showing the customer’s investment at every increment. At 10 units the price is $100 per unit; committing to more scales the per-unit price down along a visible schedule. The customer calculates their own utilization path and learns that discounts are earned, not given.
That visibility does several things at once. It orients the conversation around the expansion path from the first meeting, which makes expansion more likely. It makes pricing transparent and universal, so a discount reads as a rule rather than a favor. It protects the pricing model from discretionary erosion. It cuts quoting and negotiating time, because the schedule already answers what the customer would otherwise negotiate. And it hands the financial-risk decision to the buyer. Instead of a salesperson arguing why coming in all at once is safe, the customer weighs the visible schedule and chooses their own depth of commitment.
Across our engagements, that shift lets customers skip the pilot and come in at full scale. They reach value faster, and the software company’s average sale price rises.
It also greases the sales skids for what comes later. A buyer who is not ready for a second module or an add-on still learns what discount a later commitment will earn. That known, earned price is worth more to them than renegotiating a point solution a year on, and it gives them a reason to come back to you rather than shop around. Salespeople who expose the schedule seed their own upsell and cross-sell motions.
Most teams cannot flip to expand and land by rewriting a discount table alone, because the schedule has to reflect how each Customer Group creates value. If you want a read on whether your expansion pricing can carry that weight, talk to an expert before you rebuild it.
Land and expand is a pricing architecture problem
Step back and the three failures line up against the three decisions that make up SPP’s pricing architecture: the licensing model, the packaging model, and the pricing model. One failure sits in each. Land and expand does not fail as a sales tactic. It fails when the architecture underneath it was never built to expand.
That is also why the fix is rarely a single clever discount table. The three decisions compose in order: licensing sets the value metric, packaging bundles the rights, pricing attaches the numbers and the discount discipline. A break in any one shows up at renewal as an account that will not grow. Treat expansion as an ongoing property of the architecture rather than a one-time deal geometry. That is the continuous monetization frame. The accounts that compound are the ones whose architecture was built to expand.
LevelSetter surfaces which part of the architecture is breaking down after launch; diagnosing which decision to repair takes practitioner judgment.
In our work with software companies, the failure we see most often is the second one: a first deal built to close rather than to expand, with a value metric that never tracked how the customer actually creates value.
If your expansion revenue is not matching the story you told at the first close, the answer is not more pressure on the account team. It is a diagnosis of which structural failure you are carrying, and that diagnosis moves faster when someone who has seen the pattern across many software companies looks at your accounts with you. Talk to an expert about the accounts that stalled, and name which structural failure you are carrying before you re-cut another deal.