A Worth of Value Models

One has a gander of geese, a parliament of owls, and a murder of crows. What would we call a group of value models?

I asked Gemini, which I often use for casual prompts, and got the following suggestions. A group of value models might be playfully called a worth of value models. Other collective nouns, depending on context:

I think I will go with the first suggestion. A worth of value models.

Value models are popping up everywhere these days. Many different worths of them. Michael Mansard, Wolfgang Ulaga, and I use them extensively in our work on the Pricing for the Agent Economy book. More and more companies are making them a core part of product development and their sales process, and they are informing customer success processes.

The most interesting emergent use is by buyers, who are starting to use value models to define requirements. I wrote about this in Buyer-generated value models. But this is not the end of the evolution.

What I am most excited about is the use of value models to configure solutions: pulling together the best set of agents, data, and services to solve a current problem, and possibly dynamically adjusting the configuration as new agents become available or the challenge changes.

With all these different types and uses of value models, we need a way to organize the different types of model and how they connect. That is what I am proposing here.

The six types of value models, and others yet to be discovered, differ along two independent dimensions.

Axis 1. Who constructs and owns the model: buyer, vendor or product team, deal team, delivery team, independent third party, or machine and agent.

Axis 2. Where in the customer lifecycle and value chain the model operates: pre-purchase exploration, use-case justification, product-level differentiation, competitive deal-making, post-sale documentation, or real-time optimization.

One can also organize these on a grid.

Looking at this grid, I wonder if the empty cells will be filled. The configuration value model could evolve to play a role across the lifecycle, keeping the configuration optimized.

One could also focus in closer. A deal value model could take different forms and be used to tell different stories across the sales cycle. A customer success value model could evolve as new use cases are discovered and put into play.

Let's look in more detail at each of the six types.

Buyer models are built by the customer's own team. This could be procurement, finance, or a business-case owner. They are used to quantify the value a buyer expects from a category of solution before, or independent of, vendor influence.

These models let a buyer reason about total economic value versus willingness to pay. Tom Nagle has called out this distinction because economic value and price sensitivity are not the same thing: perceived value, risk, and uncertainty all shape what a buyer will actually pay, even when documented value is higher (see the admittedly overpriced The Strategy and Tactics of Pricing). Because buyers construct these models to support internal investment decisions, they tend to emphasize next best competitive alternative comparisons (build vs. buy, incumbent vs. new entrant) and often under-index emotional or community value, focusing narrowly on the economic dimension.

The Value Project's open specification is intended to support this. By 2028, an estimated 90% of B2B purchasing may be intermediated by AI buying agents that require a machine-readable value model.

A use-case value model quantifies value for one specific job-to-be-done rather than for a whole product, and it is the foundation of use-case pricing. This is an emerging alternative to pricing the product as a monolith. The approach is to define the buyer's job to be done, build a value model for that use case with its own equations, decide a target value-capture ratio per driver, and then derive pricing metrics from variables inside those equations.

This differs from product value models because a single product can generate multiple use-case models. A contract-management platform may have distinct value drivers for procurement-cycle acceleration versus litigation-risk reduction, each with its own revenue, cost, and risk equations. Use-case models are also the natural basis for value-path pricing, where value is estimated at each step of a user's journey and allocated probabilistically across steps. This is useful for products with long or branching workflows.

Product-level value models roll up value drivers to the level of a marketed SKU, platform or collection of agents. They are used chiefly for product marketing, packaging, and public-facing value communication. valueIQ treats the product value model as the parent from which use-case and customer-specific versions are derived, following a "build a base model, then instantiate per customer" pattern.

This is also the model type most directly implicated in pricing-metric design. Once value drivers are written as equations, one asks whether a driver's own variable (transaction volume, seats, processed records) can double as the pricing metric. This is the "connect the value metric and the pricing metric" principle that is central to B2B value-based pricing. Tom Nagle's classic three-part pricing architecture of offer configurations, price metrics, and price fences operates on top of product-level models to create a segmented price structure.

Deal value models are instantiated versions of the product or use-case model, customized to a specific prospect's numbers and explicitly benchmarked against a named competitive alternative rather than a generic one. Their purpose is tactical: to justify price in a live sales cycle, often as part of a value story used for value validation, value presentation, and, ultimately, closing.

Because deal models are single-opportunity artifacts, they sit lowest on abstraction and highest on customer-specific detail. Variables are populated with the prospect's actual revenue, cost structure, and usage assumptions rather than segment averages. Economic Value Modeling is favoured over simpler Customer Value Mapping at this stage precisely because it separates differentiated value from commoditized value against the named competitor. Customer Value Mapping risks underpricing by treating all benefits as equal.

Customer success (or value-documentation) models operate after the sale to track and communicate value actually realized over the customer lifecycle, closing the loop between promised and delivered value. These are part of the broader discipline of Customer Value Management, whose lifecycle spans value quantification, communication, delivery, documentation, and optimization, aligning sales, marketing, delivery, and customer success around a shared value language.

These models feed net revenue retention strategy by aligning realized value with usage-based pricing mechanics. This helps to justify expansion pricing and reduces churn, since documented value delivered becomes the evidence base for renewal and upsell conversations. This is where the value capture ratio, typically 5% to 30% of documented value in mature B2B SaaS, is tracked and defended over time rather than merely projected.

These are what I am most excited about. They are also more theoretical than real at the beginning of fall 2026. Configuration value models are the newest category and the one I am working to define. They are built and executed by an AI system, at run time, to assemble and tune a working combination of agents (often from multiple vendors) that jointly optimize value for a specific task or workflow. This differs structurally from all prior categories because the model is not a static artifact used by humans for reasoning or communication. It is a computable object consumed by a machine to make configuration decisions.

This is consistent with The Value Project's requirement that value models be machine-readable so agents can retrieve, validate, and act on them via protocols like Google A2A or Anthropic MCP. The nine-layer agentic pricing stack (energy and water, infrastructure, inputs, actions, workflows, outputs, business actions, outcomes, and economic value) gives configuration models their structural logic. At each layer a different unit of work becomes visible, and a configuration engine has to decide which combination of agents, at which layer, produces the best economic-value outcome relative to cost and risk absorbed. See A nine-level stack for pricing AI agents, but note that Michael Mansard and I continue to revise this stack.

The Mapper component in credit-based pricing systems is an early concrete example. It aligns credit consumption to value drivers dynamically, essentially running a real-time configuration value model behind the scenes. See The Mapper in the Credit Pricing System.

Configuration value models also introduce a distinct risk-transfer logic absent from the other five types. As pricing (and implicitly, value optimization) moves up the stack from inputs toward verified outcomes, the vendor absorbs more variance. Input quality, retries, model errors, integration failures and authorization gaps all become the vendor's problem. Configuration models must explicitly price and manage that absorbed risk rather than simply optimize for output completion.

This is also why outcome-based pricing is explicitly not the same as value-based pricing in this framework. A price per resolved ticket is an outcome metric. It becomes value-based only when tied to customer-specific economic value against a credible next-best alternative. A configuration engine must encode this if it is to optimize for true economic value rather than a proxy. And there is no reason to believe that the best configuration will use agents from one vendor. In a competitive market, and the agent economy is likely to be ultra-competitive, the best combination of agents will draw from more than one vendor, and that combination will change over time.

Two further dimensions cut across all six categories and are worth making explicit as modifiers rather than separate top-level types.

These modifiers mean, for example, that a deal value model is really a customer-specific instantiation of a product or use-case model, filtered through the economic dimension and benchmarked against a named competitor. The six types in the taxonomy are not mutually exclusive silos. They are points where ownership, lifecycle stage, dimension, and instantiation level intersect.

The proliferation of value models is not a documentation problem. It is an operating-model opportunity.

The organizations that get ahead will not treat these six models as isolated sales tools, finance artifacts, or product-marketing collateral. They will build a connected value-model architecture: a canonical set of value logic, clear ownership of customer variables, and governed ways to instantiate, validate, communicate, and improve that logic across the lifecycle.

Buyer-generated models reveal what customers are trying to optimize. Use-case models clarify the jobs worth solving. Product models guide packaging and price metrics. Deal models test the claims against a real competitive alternative. Customer-success models replace promises with evidence.

Configuration models may eventually turn all of this into a continuous, machine-executed process: selecting, combining, and reconfiguring agents, data, and services against an explicit economic objective.

Start by taking inventory of your own worth of value models.

The important question is no longer, "Do we need a value model?"

It is: which value model is needed here, who should own it, what decision should it improve, and how does it connect to every other model in the system?

A company that can answer those questions will be better able to justify differentiated prices, design offers around real customer outcomes, defend value capture at renewal, and participate in an agent economy where the best solution may be a changing configuration rather than a single product.

That is a much more ambitious purpose for value modelling. Not a better calculator, but a shared, and eventually executable, model of how value is created, verified, priced, and continually optimized.

This essay first appeared on Steven's Pricing Innovations newsletter.