The Price Tag Is Part of the Product

Imagine a product team preparing to launch a new subscription plan. The features are ready, the demo is polished, and someone opens a spreadsheet to settle the price. Competitor rates go into one column, costs into another. A number begins to look reasonable.

Then a simple question interrupts the exercise: what exactly is the customer being asked to pay for?

My answer is that pricing is a product decision because it defines the relationship between customer value, product usage, and business growth. A spreadsheet can test whether that relationship is sustainable. It cannot decide what the relationship should be.

Pricing begins with the customer’s progress

As Founder & Growth Head at Vahmine Technologies, my work spans enterprise SaaS, product building, and technology consulting. Across field sales automation with Toolyt, interactive demos with Dale, and learning through Acadle, I find it useful to begin with the progress a customer wants to make—not the list of capabilities we can package.

A buyer may describe the requirement as software. But the underlying ambition could be better field execution, clearer product understanding, or a more structured learning experience.

Those are different kinds of progress. They should make us question whether the same pricing logic belongs everywhere.

Charging per user may feel familiar, but familiarity is not a strategy. If broader participation makes the product more valuable, a rigid seat-based model can make customers hesitate before inviting others. Usage-based pricing may align with consumption, but it can also make a successful customer anxious about the next bill.

Neither model is inherently wrong. The product decision is to understand which behaviour we want to encourage, which uncertainty the customer can tolerate, and where value becomes visible.

Every pricing boundary shapes behaviour

I think of a pricing plan as a set of instructions, even when it does not look like one.

A limit says, “Use this carefully.” An included capability says, “Make this part of your routine.” An upgrade boundary says, “At this stage, your needs are different enough to justify another commitment.”

That makes packaging part of the product experience.

Consider a hypothetical learning platform that charges for every additional learner. The model might suit some customers perfectly. For another customer trying to encourage organisation-wide participation, the same model could turn adoption into a budget negotiation.

The feature has not changed. The economics around using it have changed its practical value.

This is why I would not leave pricing entirely to finance or sales. Product needs to understand the behaviour it creates. Engineering needs to understand what must be measured and enforced. Sales needs to explain it without translating a maze. Customer-facing teams need to handle the moments when usage crosses a boundary.

Finance remains essential. But the conversation is larger than margin alone.

A plan should tell a coherent story

When I look at a pricing structure, I want to understand the customer journey behind it.

Who is the first plan genuinely useful for? What changes when a customer moves to the next one? Is that change about more volume, greater coordination, stronger governance, or a different level of service?

If the only explanation is “we needed three tiers,” the structure is unfinished.

I prefer an entry plan that delivers a complete, bounded outcome rather than a deliberately frustrating preview. A customer should be able to succeed within its intended scope. The next plan should become relevant because the customer’s needs have expanded, not because a basic workflow was held hostage.

Enterprise requirements make this particularly important. Implementation, integrations, support expectations, and governance can change the work required to deliver value. Those differences deserve explicit consideration rather than being hidden inside a loosely negotiated subscription price.

Clarity also matters inside the company. A pricing promise that the product cannot enforce or the team cannot support becomes operational debt.

The checklist before the spreadsheet closes

Before approving a pricing decision, I would ask the team to work through this checklist:

• Name the customer: Who is this plan designed to serve, and who is it not for?
• Define the outcome: What useful progress can the customer achieve without upgrading?
• Test the value metric: Does the charging unit reasonably track value, and can the buyer predict it?
• Inspect the incentives: Are we encouraging adoption or accidentally penalising it?
• Explain the upgrade: What meaningful change in customer needs justifies the next plan?
• Check delivery economics: Can we sustainably provide the promised product, implementation, and support?
• Walk through the boundaries: What happens when a customer exceeds a limit, reduces usage, or changes plans?

Only then does the spreadsheet become fully useful. It helps examine the consequences of a strategy rather than substitute for one.

For me, pricing is where product intent becomes a commercial promise. The number matters. But I want to be equally careful about the behaviour, expectations, and obligations that travel with it. A good price should make sense not only when the customer signs, but when they begin to succeed.