TL;DR Most pricing and packaging recommendations that never ship were unimplementable on the day they were written. The product could not emit the unit the licensing decision named, could not draw the boundary the packaging decision assumed, or could not compute the shape the pricing decision specified. That is an architecture failure, not a roadmap failure. Monetization infrastructure lowers the cost of shipping a change; it does not change the shape of what was specified. What a product can count, gate, and compute belongs in the diagnosis alongside the market evidence, not in the post-mortem.
The recommendation is finished. The direction has been agreed, the executive team is behind it, and the analysis underneath it is sound. Then nothing ships. A quarter later the packaging change is still sitting behind a platform migration, a security review, and whatever engineering had committed to before the pricing work began. A year later somebody asks what happened, and the answer is that the roadmap was full.
That answer is accurate and it is not the cause. A pricing recommendation the product cannot express is not a good recommendation that failed to ship. It is an incomplete recommendation. The distance between what a company decides about software monetization and what its product can enforce is where these recommendations end, and that distance is measurable before the work starts by anyone who thought to measure it.
The Objection Is True, and It Should Be Said Plainly
A large share of pricing and packaging recommendations never reach the product. They arrive, they are agreed with, and then they wait behind everything already in the queue. Software companies carry roadmaps with no room in them, and a pricing change competes with the compliance work, the platform migration, and the enterprise commitment that needs a capability by March. Anyone who has run engineering at a growing software company knows that arithmetic. Naming it is not an excuse.
The explanations that follow a stall are usually flattering to whoever produced the recommendation. It was a failure of nerve. The executive team was not serious. The roadmap happened to be full that quarter. Each of those reads is comfortable for the party that wrote the recommendation, and none survives a close reading of how a stall unfolds. Recommendations die in one specific way: somebody tries to write the change into a ticket and discovers the product has no way to do what was specified.
Peer-reviewed strategy research in industrial B2B markets reached the same place from a different direction: a company’s existing pricing systems can make a strategically sound price move impossible to execute, regardless of how well the move was reasoned. In the case studied, those systems could carry one discount position per customer, which ruled out the product-level differentiation the strategy called for. Pricing capability lives in systems and routines, not in the quality of the analysis.
Three Decisions, Three Enforcement Surfaces
Pricing architecture is three structural decisions: the licensing model selects the value metric and the rights granted, the packaging model groups capabilities into what a customer can buy, and the pricing model computes what each configuration costs at list and at net. Each of the three has a counterpart inside the running product, and the counterpart is where a recommendation lands or dies.
One asymmetry keeps this invisible while the work is happening. The three decisions are debated in a room; the three enforcement surfaces live in code. Nobody in the room is withholding anything, and the constraint was never on the table.
The unit the product does not emit
The licensing decision names a value metric. For that metric to hold commercially, the product has to emit the unit and attribute it to a specific customer at a resolution an invoice can stand behind. Emitting is not the same as logging. A product can log an event at high volume and still be unable to say which contract it belongs to, or to produce a count that survives a customer disputing it on a renewal call.
Metering infrastructure is often described as supporting custom value metrics across tokens, tasks, API calls, and transactions without engineering work each time the model changes. True, and bounded: supporting a unit the product already produces is a different problem from emitting a unit the product never captured. A recommendation naming a value metric the product has never counted has specified an event, not a metric, and no downstream configuration produces the event.
The boundary the product cannot draw
The packaging decision groups capabilities into what a customer can buy, and settles capability allocation, the choice about which capabilities move as buyers step up. That structure is not always an edition ladder. It can be modules, add-ons, a platform with apps riding on it, or a single all-in-one offer, and the allocation question is live in every one of them: which module carries a capability, whether it belongs to the core or to an app, whether it is in the offer at all. Whatever the shape, its enforcement counterpart is the same: which boundaries the product can grant and withhold separately.
Most products can turn a capability on for an account. Fewer can turn it on for one group of users inside that account and not another, or grant it at one volume and withhold it above that volume. A packaging structure exists only to the extent the product can draw its lines, and the license and entitlement layer is where those lines either exist or do not. A packaging recommendation that assumes a boundary the product cannot draw has produced a diagram, not an offer.
The price shape nothing downstream can compute
The pricing model is the computational rulebook: unit prices, volume breaks, commitment and renewal mechanics, discount governance and the floors that constrain it. Its enforcement counterpart is what the quote path and the invoice can compute.
A price shape a spreadsheet can produce and a quoting system cannot is a shape the sales organization will not use: the first rep who computes it by hand approximates it, and the second discounts around it. A shape the invoice cannot render is one finance refuses before a customer sees it. The pricing model is then real on paper and absent everywhere it would have to operate.
Which Enforcement Surface Is Letting Your Pricing Leak?
Your licensing model, packaging model, and pricing model each fail at a different enforcement surface. Find out which structural decision is breaking down before it dies in someone’s backlog.
Two Fixes That Do Not Fix It
The first answer on offer is infrastructure. Pricing changes are expensive because pricing and entitlement logic lives inside application code, so every change becomes a ticket, a review, and a deployment; move that state into a configuration layer and changes stop consuming engineering capacity. Concede this fully, because it is correct. The engineering tax on embedded entitlement logic is real, introducing a new pricing model without dedicated infrastructure can consume sprints promised elsewhere, and letting commercial owners adjust packaging without a release is a genuine improvement.
Peer-reviewed field research in B2B markets supports the premise underneath that: the internal and customer-facing costs of implementing a price change are real, measurable, and disproportionately larger for larger changes. Anything that lowers the cost of shipping earns its place.
None of which makes an unimplementable recommendation implementable. If the recommendation specifies a unit the product never counted, no configuration layer conjures the event. If it assumes a boundary the product cannot draw, moving the boundary definition out of the codebase relocates the problem without solving it. Infrastructure changes the cost of shipping a pricing change. It does not change the shape of what was specified.
The sharpest version of this argument goes past infrastructure and aims at advisory work: pricing advice stops at the recommendation, the company is left to extract the result on its own, so the reliable move is to buy a pricing application instead of the expertise. The first half describes a real failure. Advice that ends the day the recommendation is delivered does leave the company holding the part that decides whether any of it pays. The second half does not follow, because a pricing application executes decisions and does not make them. Hand it a value metric the product cannot emit and it fails where the advice failed.
The second answer: blame the follow-through
The second answer is that the company lacked follow-through. It is comfortable for whoever produced the recommendation, useless to the company holding it, and it predicts the wrong remedy: executive pressure applied to a specification the product cannot satisfy spends the organization’s credibility on a change it has no path to make.
The closest anyone comes to the real diagnosis is the observation that pricing strategies fail because teams underestimate the implementation work and the cross-functional coordination required. That is one step short: underestimated coordination cost is what an unabsorbable specification feels like from inside the company, the symptom rather than the cause. Both answers aim at the moment after the recommendation exists, and the failure is upstream of it.
Enforceability Is an Input, Not a Post-Mortem
What a product can count, gate, and compute today, and what it could plausibly express inside its own release cadence, belongs in the diagnosis next to the market evidence and the willingness-to-pay work. Not as a ceiling on ambition. As one of the facts the architecture is being fitted to.
The decision layer is where a software company’s licensing, packaging, and pricing choices are made, distinct from the runtime layers that execute them. Independence from those runtime systems is a different proposition from ignorance of them. Independence means the meter does not referee its own metric. It does not mean the metric can be chosen without knowing what the meter produces.
Constraints are not a compromise, they are part of the design problem
An architecture that cannot be enforced is a proposal. The same is true of a building. What the ground will carry is not a compromise imposed on the design after the fact; it is one of the conditions the design exists to satisfy.
Which reverses the polarity of the buyer’s own objection. A company told that its constraints are an obstacle to good pricing has been told something backwards. The constraints are inputs to good pricing, and a recommendation that ignored them was never fitted to that company. It is also why pricing run as a greenfield exercise fails so reliably: a recommendation designed for a company with no systems, no installed base, and no enforcement surface has been designed for a company that does not exist. The pattern that repeats across our engagements: the recommendations that landed are the ones whose enforcement surface was in view while the architecture was being fitted.
There is a real tension here, and it should be named rather than resolved with a rule. Some changes that genuinely should be made exceed what the product can express today, and pretending otherwise is its own failure. When that happens, the change becomes a named product dependency with an owner and a place in the roadmap, rather than an orphan item in a strategy document. Which parts of an architecture ship inside the current cadence and which become dependencies is judgment work, turning on where the company sits, what the market is doing to it, and what engineering can absorb. No sequence rule in an article will settle it.
What the rule-less version still allows is measurement. The distance between what the product enforces today and what the desired architecture needs is a scopable piece of work: so many quarters, so much engineering, so many dollars, knowable upfront rather than discovered at rollout. And the distance does not have to be waited out. One client’s desired value metric was a year of product maturity away, so the architecture shipped in two stages: an intermediate structure built on what the product could already enforce, designed from the start to migrate onto the desired metric once the capability existed and the data it needed had accumulated. The bridge was not a compromise on the destination. It was the only path that arrived there with the installed base intact.
Once a change is decided and the product can carry it, the work moves to migrating the installed base, which has its own discipline and costs. A company that runs pricing as a standing operating practice rather than a periodic project has a shorter path here, because the enforcement surface never left the room. If your company is holding a recommendation that will not ship, the useful next move is a working conversation about what the product can express, not another round of analysis on the price. That is what talking to a pricing expert is for.
The Questions to Settle Before the Work Starts
What does the product emit today? Not what it logs. What it can attribute to a named customer at a resolution an invoice could stand behind under dispute. This decides whether a value metric is available or only aspirational.
Which capability boundaries can the product draw? Grant and withhold, separately, at the level the packaging model assumes. If the structure needs a line the product cannot draw, it is a plan for a different product.
What can the quote path and the invoice compute? A price shape that exists only in a spreadsheet has already failed the two systems that would carry it every day.
Who knows the answers to the first three, and were they in the room when the pricing work was scoped? If nobody present can answer them, the diagnosis is not finished.
What happens to the parts of the change the product cannot carry yet? If the answer is silence, that is where the recommendation will end, without a decision and without a post-mortem.
The implementation gap is not evidence that pricing work does not pay. It is evidence that pricing work done without the enforcement surface in view produces specifications rather than architecture.
Most companies sitting on a stalled pricing recommendation do not need a new one. They need the recommendation they have re-fitted to what their product can express, and an explicit decision about which parts become product dependencies with owners and dates. Describe the change that will not ship and talk to an expert; a pricing expert will reply.
