Pricing an established product is comparison. You look at what the market pays, you decide whether you are cheaper or better, and you position accordingly. It is not easy but it is bounded.
Pricing something genuinely new is a different problem, and most teams handle it the same way: they pick a number that feels defensible, present it with confidence, and quietly hope. I have done this. I have also watched it go badly enough to want a better method.
Across marketing work in several industries and now in software, I have ended up with five reference points. None of them gives you a price. Together they give you a range narrow enough to be a decision rather than a guess.
One. Price the alternative, including the ugly one
Every new product replaces something, even when there is no competing product. The alternative might be a spreadsheet, a phone call, an agency, an employee's Tuesday, or doing nothing at all.
Doing nothing is the one people forget, and it is usually the market leader.
So the first exercise is to cost the alternative honestly. Not the version where you assume your buyer is inefficient, but the real one. If a task currently takes a competent person four hours a month, that is your reference, and you should compute it at their actual salary, not the number that flatters you.
This does not set your price. It sets the ceiling of easy argument. Above it, you are asking someone to believe something. Below it, you are having a much simpler conversation.
Two. Find the number they already have a budget line for
This is the single most useful thing I learned selling in a commercial environment, and it is underused by technical founders.
Organisations do not evaluate spending in the abstract. They evaluate it against existing categories. A cost that fits an existing budget line gets approved by one person. A cost that requires a new line gets approved by a committee, next quarter, maybe.
So before you set a price, find out what your buyer already spends money on that yours could sit beside. Not because you should match that number, but because knowing it tells you which approval path you are walking into. I have seen a lower price take longer to close than a higher one, purely because the lower one did not fit any existing category and the higher one did.
Three. Test the shape before the number
Buyers react as strongly to how they are charged as to how much. Per seat, per site, per use, per year, per asset. The shape carries a claim about what your product is.
Charging per user says this is a tool for individuals. Charging per building says this is infrastructure attached to a property. Those two options can produce identical revenue and completely different customer behaviour, because the shape decides who inside the organisation feels the cost, and therefore who inside the organisation argues about it.
Get the shape wrong and your customers will fight you at renewal even if the total is fair. Get it right and the total becomes much less contested, because it scales with something they already believe should cost money.
I would test the shape in conversations long before I tested the number. It is far harder to change later.
Four. Ask what it would have to cost to be irresponsible not to buy
This is a question from sales, not from finance, and it has served me better than any pricing model.
You are looking for the point where the decision stops being an evaluation and becomes obvious. Everyone has that threshold, and most buyers will tell you roughly where it is if you ask directly.
The answer is not your price. Pricing at obvious is usually leaving money on the table and, worse, it signals that the product is minor. But it locates your floor, and it tells you something more valuable: how far away from obvious your current thinking is. If your intended price is ten times that number, you do not have a pricing problem. You have a value communication problem, or the wrong buyer.
Five. Decide what you want the price to say
Price is the loudest piece of positioning you will ever ship. It arrives before the demo, survives every conversation, and gets repeated by people who have never used the product.
A low price on a serious product does not read as generous. It reads as unproven. In categories where the cost of being wrong is high, and building maintenance is very much one of those, an unusually low price actively creates doubt. Buyers reason that if this really prevented what you claim it prevents, it would cost more.
A high price makes a promise. It says this is meant to be relied upon, and it invites scrutiny you had better be able to survive.
Neither is right. But you should choose deliberately, because your buyers are reading the number as a statement about the product whether you intended it or not.
What I would not do
Two things I have learned to avoid.
I would not price off cost. Cost tells you whether you have a business. It tells you nothing about what the thing is worth, and for software the marginal cost is close to meaningless anyway. Cost plus pricing on a new category is how genuinely valuable products end up priced like commodities.
And I would not survey people on price. Asking someone what they would pay produces a polite fiction, every time. People are unreliable about hypothetical future spending and extremely reliable about past spending. Ask what they have actually paid for the alternative, what that came out of, and who signed it. That is real data. What they say they would pay is not.
The honest summary
You will not get it right the first time. Nobody does, and the good news is that you do not have to, because early pricing is a hypothesis and the market will correct it faster than any analysis.
What you must get right is the shape and the story, because those are expensive to change and they train your customers in how to think about you.
Pick the shape carefully. Choose what the number says. Then set the number, watch what happens, and be willing to be wrong in public.
I am Issam Fathi, a technology strategist and the product manager of AssetEye by Dronetjek, based in Tetouan, Morocco. I help companies build, adapt, and grow through technology.
Top comments (0)