Selling Outcomes Not Tools

The trap of selling a product

Eric Glyman, the co-founder and CEO of Ramp, frames a strategic choice he says every software company faces: are you selling a product or an outcome. He puts the risk of the first plainly. "What starts as a breakthrough product becomes what traps companies," because once a company sells a card, or expense management, or bill-payment software, "you're going to keep selling this thing."¹ For Ramp, in his account, "cards and expenses were a means to an end." The service being sold was "your business but better," with the unit of value being dollars and hours saved rather than features shipped.

Output metrics, not feature metrics

Glyman describes holding the company to two output numbers from the start, reported monthly and pushed up each month: how much money Ramp saved its customers, and how much time it saved them. He traces the savings figure from roughly two percent at the February 2020 launch to around five percent later. The claim he makes is that this reframes the roadmap. Instead of shipping features, the monthly job is to cut steps out of a workflow and then expand into adjacent ones, so that the product being sold is, in effect, the removal of work.

He grounds this in the business model rather than treating it as a slogan. Glyman says he considered seat-based pricing, the Concur model, and rejected it as the spine of the company: "you don't want to sell people more seats, you want to drive more outcomes." His reasoning is that under AI, "what used to take months will take days," features stop functioning as a defense, and per-seat pricing mis-slopes when fewer people are needed to do a given job. Outcome and consumption pricing, in his view, ages better, a point he connects to his related argument that there is no durable moat in software itself.

From the software budget to the labor budget

The strategic payoff Glyman describes is a shift in the addressable market. "The size of the software market is this large; the size of the market for people doing general work, labor, is much larger." Because computers can increasingly reason over unstructured data, work that only people could do before becomes software-addressable, "especially the work people hate," such as expenses, categorizing, and reconciling. Selling the outcome, in his framing, lets a software company expand out of the software budget and into the far larger labor budget: "Ramp can be selling not just the tool but actually selling work."

The proof he points to

Glyman's concrete example is Ramp's policy agent, which reads a company's expense policy and clears transactions at what he states is ninety-nine percent accuracy across millions of transactions, with a full audit trail for the monthly compliance review humans tend to do poorly. "The agent did real work a manager would have had to do, and now it's just gone." He presents this as the literal sale of an outcome, a compliant reviewed expense, rather than a tool, review software.

Where it strains

Glyman does not treat the framing as costless. Selling work rather than software raises the accuracy and liability bar, since a wrong automated clearance is a compliance failure rather than a display bug, and ninety-nine percent across millions of transactions still leaves a meaningful absolute error count. The output metrics themselves, money and time saved, are partly self-reported and modeled, which makes them harder to audit than revenue and creates an incentive to flatter them. Glyman's move is to make the outcome the single thing the product team optimizes, so the metric and the business model point the same direction rather than fighting each other.