Price belongs in the offer from the start

October 8, 2026 · 10 min

In short: if you design the whole offer and only then work out the price, you risk building something expensive that the customer doesn’t value. Price should come in while the scope is still open. To do that, I combine three pricing logics (market, cost and perceived value) with an investigation of the customer’s willingness to pay, one benefit at a time.

When I think about building a business, one thing that stands out to me is the moment price enters the conversation. It’s easy to imagine an offer, gather everything I’d like to deliver, add up what it costs, and only then decide what to charge. But in that order, I can spend a lot of time building something without knowing whether the customer values it at anything close to the price I need to ask.

To me, price needs to be part of building the offer from the start, while I can still choose what goes in, what stays out, and who I’m selling to. The customer’s willingness to pay helps guide those choices. If I leave that question for the end, I risk finding out too late that I built an expensive solution to deliver benefits that don’t weigh much in the buying decision.

Three ways to think about price

To organize this, I separate three pricing logics: start from the market, start from costs, or start from perceived value. They can be combined, but each one changes where the analysis begins. Costing tells me what things cost; pricing uses that information, along with other references, to decide the price.

In the first logic, I’m looking at a market where products are very similar and buyers recognize little difference between them. Think of a commodity, or an item where brand, reputation and technology don’t meaningfully change the choice. If the market pays a certain amount for that product, my individual power to charge more is limited.

In that case, I start from the market price and work backwards. If I can sell at X, how much is left after the costs and expenses needed to make that sale and keep the business running? The challenge is to operate within that price through efficiency, scale and a structure that allows a profit. Scale can help, as long as the extra volume also makes economic sense.

In the second logic, I start from the cost structure. I calculate the unit cost, consider fixed costs and how they spread over the expected volume, and apply a markup to reach the asking price. It’s the traditional way to build the number: understand how much I need to recover and what profit I want. I just need to be careful with the bases, because markup on cost and margin on the selling price are different measures.

This path settles internal viability, but it leaves a question open: will the market accept the calculated price? If my costs are high or my expected volume is optimistic, the math can produce a price that makes sense in the spreadsheet and meets resistance in the sale. Having a reason to charge a certain amount doesn’t mean the customer sees a reason to pay it.

The third logic is about differentiation and perceived value. Brand, reputation and technology can push willingness to pay far away from the cost of production. I sometimes call this “leveraged costing,” but the more precise name for the mechanism is value-based pricing. I use my own term as a personal way of thinking about the relationship.

Here, price doesn’t have to rise in step with every real added to cost. The buyer may see a benefit that is worth a lot to them and doesn’t cost the company much to deliver. Costs still matter: I need to know whether I can produce, sell and sustain that delivery viably. Contribution margin, which is revenue minus variable costs and expenses, helps cover fixed costs and build profit. I can’t count contribution and profit as two separate slices of the same leftover.

The price that seems fair in my head

Even understanding these three logics, I can make the same mistake in any of them: build the whole offer around what I find interesting and only look at willingness to pay afterwards.

Take a consulting engagement. I can list an initial analysis, several deliverables, meetings and follow-ups, adding everything I believe would make the service more complete. With customer service software, the move is similar: I think of the core solution and keep adding features that seem useful.

Then I calculate the cost of those deliverables, apply a markup, look at a few market references and arrive at a price I consider fair. In my head, the offer is great. It packs a lot in, it takes work, and it seems to deserve the price I’m asking.

But that conclusion is still a hypothesis. This matters most with a new product, a new idea or a channel where I don’t yet know how people buy. I can be confident about the effort it takes to produce something and, at the same time, know little about the value the buyer sees in the result.

I may also be comparing my package with offers that solve different problems, serve a different audience or sell in a different context. Market references help, but I need to understand what is being compared. A longer list of deliverables doesn’t, by itself, justify a higher price commercially.

What the customer is trying to buy

Before closing the package, I would try to understand the end goal of the purchase. What does the person want to achieve? What makes them believe this offer will help? Which parts of the delivery matter for that result, and which only seem interesting to whoever is creating it?

My own reflection is a starting point. I can imagine needs and talk to people I know, but I need to get close to customers and to people who actually have the problem I want to solve. Otherwise I risk collecting kind opinions from people who like the idea and have no reason to buy it.

This is where willingness to pay, or WTP, comes in. It’s how much someone would be willing to pay for an offer under given conditions. Liking a proposal, wanting a benefit and agreeing to pay a price for it are related, but they are not the same.

The idea isn’t only mine. Madhavan Ramanujam and Georg Tacke, of Simon-Kucher, argue in Monetizing Innovation (2016) that companies should design the product around the price, not the other way around. It’s the same reversal I’m proposing here.

Conversations help me find out what to investigate. I want to understand choices, priorities and what the person already does to solve the problem. A positive answer in a survey is still only an early signal. To gain confidence, I need to test it against concrete offers and purchases, because stated intent can change once real money is involved.

The T-shirt and the add-on that made the bundle expensive

An example that helps me see this is an ultra-luxury clothing brand. Picture a R$1,000 T-shirt and, for this example, a customer who values the status and sense of belonging attached to the brand. By wearing it, they make that association visible to others.

Now imagine the company decides to sell the T-shirt bundled with a fridge magnet, as a R$3,000 package. To whoever created it, the bundle may look like a great idea: one more branded object, an exclusive set, a more complete delivery.

But I need to go back to that buyer’s motivation. If the value they want lies mainly in wearing the brand and being recognized for it, an accessory that stays inside the house adds little to that goal. The package got more expensive without increasing, in the same proportion, the benefit that drove the purchase.

In this case, I may end up making the T-shirt itself harder to sell by forcing the customer to take an add-on they barely value. The accessory has production, packaging and logistics costs, and it takes up the team’s attention. Those costs explain the higher price for the company, but they don’t automatically create a reason to buy for the customer.

I’m not assuming every luxury purchase is about status. There are other possible motivations. In this example I assume that one precisely to show that the quality of an offer depends on understanding the benefit being sought. Another buyer might value the object for their home; I would need to identify that interest instead of assuming it for everyone.

Break features apart to see benefits

This line of thinking leads me to take the offer apart before locking it in. Instead of looking only at a complete package, I would separate its features or deliverables and try to translate each one into a concrete benefit. In consulting, what does each analysis let the client decide or do? In customer service software, what does each feature change in the user’s work?

That translation matters because several features can produce the same benefit. A long list can look like a lot of added value when, to the buyer, the items overlap. There can also be a small deliverable, easy to miss in the pitch, that is decisive for reaching the desired result.

I would look at how important those benefits are, how much they influence willingness to pay, and what it costs to deliver them. If a feature requires a lot of investment and carries little weight for the customer, it becomes a candidate to cut, simplify or postpone. If it supports the main result, I need to protect it even if it isn’t the flashiest item in the offer.

I would also be careful not to turn the investigation into mechanical addition. Willingness to pay for each benefit in isolation doesn’t necessarily add up to the value of the package. Some benefits complement each other; others repeat. The customer evaluates the whole, the alternatives available and what fits their situation. So I need to investigate both the parts and the combination I plan to sell.

The central point is recognizing that my interest in creating something can differ from the buyer’s goal. I can love a deliverable and still find that it makes the offer more complex, more expensive or less accessible, without making it meaningfully more attractive.

Protect the entry offer

From there, I would try to build an entry offer that delivers the main result well. That means choosing what is essential for that audience and keeping extras from becoming an unnecessary barrier. If the customer has to buy everything to get what they actually want, I may be losing a sale that made sense for both sides.

Add-ons can come later, as bundles, extras or different plans. That way I can serve those who value a broader delivery without making everyone pay for it. In the brand example, the T-shirt could remain available on its own, while the set with the accessory is offered to those who show interest in that combination.

The same goes for consulting and software. Some clients need a more focused solution and others see value in closer support or extra features. The offer can reflect those differences, as long as each version still delivers what it promises.

Test the price while you can still change the offer

In the end, the change I consider important is bringing price into a stage where the scope is still open. I want to connect the customer’s problem, the benefits they want, their willingness to pay and the cost of delivery before investing heavily in the full solution.

I still need to do the math and look at the market. But I also need to test whether what I’m building makes commercial sense for the chosen audience. If I find out early that an item makes the offer much more expensive and adds little perceived value, I can still redesign the package without carrying all the investment already made.

To me, that is what price contributes to building a business: it helps decide what is worth building and offering. When I treat pricing as a calculation at the end, I give up information that could have improved the offer from the beginning.

If you are building or reviewing your company’s offer, this is the kind of work I do in my sales, finance and management consulting. And every week I send an essay like this one to the newsletter.