In Search of Pricing/Market Fit
When a disruptive technology like AI emerges onto the scene, everyone wants to get into the act one way or another. The challenge is that no one knows exactly how to price things. There is no reference price, nor will there be until the category gets inside the tornado. This creates serious roadblocks for early market development, and both vendors and buyers need to iterate to find what one might call pricing/market fit.
For early adopting customers with visionary aspirations, project pricing is the best place to start. Because the technology is novel, and the use cases are aspirational, the offering will necessarily be heavily services-weighted, so pricing it as if one were a systems integrator, as opposed to a technology vendor, accomplishes several things. From the customer’s point of view, it gives them a reference price of sorts. That is, they can evaluate the pricing based on the expertise and labor it would take to design, build, and deploy the new system, and they can justify the price based on anticipated ROI from achieving their aspirational outcomes. They also know that as an early customer, they can have material influence on the vendor’s product roadmap and can demand bespoke features that they would not get once the category is underway.
From the vendor’s point of view, project pricing supports a large price for the overall deal, one that they can credit to the product they are selling, thereby upping its perceived value. Vendors should not fool themselves, however, so they need to be wary of two pitfalls. The first is a contract that radically discounts the services in order to support a high product price. The problem is that the customer has no incentive to wean themselves off the services of expensive, highly talented personnel, and this creates painful economics for the professional services organization, as well as tying it to a single customer when it is needed by many others.
The second pitfall is thinking that an early market contract has established a viable reference price for the product, leading to market development plans and a fundraising pitch based on replicating that price. This is a hallucination. There is no reference price as yet, nor will there be until the category has crossed the chasm. What you get from an early market win is a lighthouse account that shows what is possible. It will put you on the map, but it does not put you in the money.
Crossing the chasm will. That’s because there is a more replicable price to reference, namely the cost burden of not addressing the target use case effectively. This is value-based pricing, and it is both industry and use-case-specific. The customer is buying a solution to a vexing problem, which they will fund in large part by redirecting their current spend that is not producing the desired results, augmented by a one-time implementation and start-up charge. Customers can calculate the ROI directly in terms of cost reduction and productivity improvement, and are willing to pay a premium for getting the relief they need. Interestingly, they will often get an additional benefit from risk reduction, but they will not pay a premium for this—not because it is not valuable, but because they have no budget to cover it, nor do they want to draw attention to the latent risk they have been incurring all along. Calling attention to the risk reduction, nonetheless, is a valuable talking point and can help accelerate closing the sale.
From the vendor’s point of view, crossing the chasm is game-changing because for the first time they have a forecastable business with low cost of marketing, predictable sales cycles, supportive customer references, and an ecosystem of partners who share a stake in their success. Pricing will begin to look more and more like traditional product pricing as the vendor expands into new use cases where the urgency may not be as great, but the risk of adoption is much lower and the probability of success much higher. This allows customers to allocate budget for the category in their next annual operating plan, which further reduces go-to-market friction.
If and when the category goes inside the tornado, that will initiate a market share land grab. Depending on how much competition there is, pricing may be heavily discounted in order to win a gorilla position. Once the gorilla is established, its price provides the reference price for the category, with other vendors having to price well below it to get the deal (these are the monkeys) or actually price above it by offering niche applications that serve narrow but high-value use cases. These are well-trodden paths, meaning by this point the challenge of pricing/market fit has been met.
So much for pricing in terms of the amount of payment. AI is also bringing to the fore another disruption in relation to pricing models. Historically, B2B hardware and software have been priced on a license and maintenance model. The rise of cloud computing and the hyper-scaler computing contracts have subsequently brought consumption pricing to the fore. As AI contracts are being drafted, these two models are interacting with each other, causing customers to ask for a flex model that lets them move spend out of areas of low or no usage to areas of greater interest. In addition, consumption contracts, in and of themselves, are attractive at the outset—pay as you go—but can become concerning if they are not modified for going all in. Hence, there is another kind of ask coming from customers, namely for pricing caps.
While for start-ups all this novelty does not create a big problem, for established enterprises that have a multiplicity of contracts with virtually every one of their major customers, it can create legal bottlenecks of considerable proportions. There is no quick fix for this, but sales teams need to understand this can be a big time sink, and forecast their close dates accordingly.
In short, pricing per se, which one would normally put in the Productivity Zone, is better suited in the short term to the Incubation Zone. The goal is to get to pricing/market fit first, then to standardize and scale. This is not what the average finance team is used to, so it calls for the entire ELT to weigh in to get things right.
That’s what I think. What do you think?
