Value based pricing for technical products, explained with a pump
Your buyer does not care what your technology cost to build. They care what their problem costs to keep. Value based pricing starts from their spreadsheet, not yours, and here is how to build one when you have no pricing data at all.
The pump that sold for ten times its parts
A founder I work with sells a sensor system that monitors industrial pumps. The hardware costs him about four thousand euros to build. He priced his first offer at eight thousand and felt generous. Then a plant manager did the math out loud in a meeting: one unplanned pump failure costs them sixty thousand in lost production, and they had four failures last year. The founder went home and repriced at forty thousand. The next three customers signed without negotiating, because against two hundred and forty thousand euros of annual losses, forty thousand is a rounding decision.
That is value based pricing in one story. The price is not a markup on your costs. It is a fraction of the customer's problem, sized from their spreadsheet. The idea is simple. The hard part is everything around it: finding the number, defending it, and believing it yourself.
Why cost-plus feels safe and is not
Technical founders default to cost-plus for understandable reasons. Costs are measurable, margins are defensible in front of investors, and the number feels honest. But cost-plus has two silent failure modes. First, it caps your price at what your technology costs, which in deeptech is often a small fraction of the value it creates: a material that halves a machine's downtime is not worth slightly more than a material. Second, it anchors the negotiation on your finances instead of their problem. The moment you say cost-plus, the buyer starts auditing your bill of materials instead of their own losses. You want the conversation on their spreadsheet, and cost-plus drags it onto yours.
Start from their spreadsheet
The practical method I use with founders is a value map, and it takes one honest conversation with a friendly customer. Ask: what does this problem cost you today, in a bad year? Then break the answer into the components the customer actually tracks. Downtime hours times production value per hour. Scrap rates times material cost. Energy consumption. Maintenance call-outs. Compliance fines. Quality claims from their own customers. You are not asking them what they would pay; nobody knows that. You are asking them to itemize the wound. The total of that itemization is your value ceiling, and your price is a fraction of it, commonly a fifth to a third, small enough that the payback period fits inside one budget cycle. If their problem costs two hundred and forty thousand a year, a price that pays back in under twelve months barely needs approval. That is the whole trick: price where the decision becomes easy for them.
What to do when you have no data yet
Early on you have no customer history, and founders use that as an excuse to price low. Do the opposite. Use the pilot to generate the value map. Instrument everything: measure the baseline before your system runs, measure during, and write the deltas into the pilot report in the customer's own units. I have written separately about what to put in a pilot agreement, and this is the commercial reason it matters: a pilot that produces a value map in their numbers is not a discounted trial, it is the foundation of your price list. One measured result at one credible customer is worth more than any market report, because every future buyer in the segment recognizes the plant in the story.
The objection you will get
Procurement will still try to drag you back to costs. That is their job. The counter is not to defend your margin but to keep returning to their arithmetic: here is what the problem costs you, here is what we measured, here is the payback. A total cost of ownership case, written from their side of the table, is the document that survives procurement, and it deserves its own article. The founders who lose this negotiation are the ones who start apologizing for the price. The ones who win treat the value map as a fact they discovered together with the customer, because it is.
The mistake underneath all pricing mistakes
Every pricing error I see in deeptech reduces to one thing: pricing from your situation instead of theirs. Your costs, your runway, your fear of hearing no. The customer's situation is the only stable ground for a price, and the discipline is learning their numbers before you state yours. This is also why the first price matters so much: as I wrote in the piece on pricing your first deal, that number becomes the industry anchor for years. Set it from their spreadsheet and it will hold. Set it from your nervousness and you will spend years climbing out of the hole.
Common questions
What is value based pricing for a technical product?
Pricing set as a fraction of the customer's problem cost, not as a markup on your build costs. You itemize what the problem costs them per year, then price so the payback fits inside one budget cycle, commonly a fifth to a third of the annual problem value.
How do you build a value case without customer data?
Use a paid pilot to generate it. Measure the baseline, measure with your system running, and write the deltas in the customer's own units. One measured result at one credible plant becomes the foundation of your price list.
How do you defend a value based price against procurement?
Return to their arithmetic rather than defending your margin: problem cost, measured results, payback period, expressed as a total cost of ownership case written from their side of the table.
If you are pricing from your costs because you do not yet have their numbers, that is fixable in weeks. Tell us what you have built.