A pricing unit can change the way a product is used

Pricing is sometimes handed to a commercial team after the product has been designed. The assumption is that the software determines the experience and the price determines how much the customer pays for it. In institutional workflows, the separation is rarely so clean. A charging unit can decide who is invited into the process, who receives an export instead of a live view and who is expected to rely on someone else's explanation. Those choices affect the product's usefulness. I therefore regard packaging as part of the operating model we ask a client to adopt.

Map the work before counting the seats

Our proposed named-seat package appeared easy to explain. Each person with access carried a price. In conversations with four prospective institutional clients, however, we found that the list was being narrowed to preparers and formal approvers. Occasional reviewers and branch finance colleagues were expected to receive exported documents. The package was encouraging the client to treat some readers as dispensable even when their ability to see context was part of the intended workflow.

Some participants suggested sharing access. We would not support that approach. Individual identities and appropriate permissions mattered regardless of how we charged. But simply rejecting shared access would not resolve the economic pressure behind the suggestion. We needed to understand why a client found the authorised access model difficult to justify and whether the charging unit reflected the service obligation created by each role. A product policy that ignores the commercial incentive can leave both sides repeating the same argument.

We mapped the work performed by creators, approvers and readers. A reader did not need permission to alter a proposal, but might need to examine its context without waiting for an export. Adding that person did not necessarily create the same support burden as adding a complex workflow or another operating institution. That did not make the reader costless. It did mean that a uniform charge per named person was a choice, rather than an inevitable representation of our costs.

The alternative was an institution-and-workflow subscription with read-only reviewers included. The client's administrators still controlled access, and every person retained an individual identity. Included access did not mean that every employee could see every record. The distinction between commercial entitlement and data permission was essential. We were changing what the contract charged for, not removing the institution's responsibility to decide who should be allowed to read sensitive work.

The product team could not approve that change alone. Finance needed to examine the economics, and commercial leaders needed a proposition they could explain and sustain. Our contribution was to show how the earlier package might alter behaviour and to make the alternative concrete. That allowed the discussion to move beyond a general preference for lower prices. We could debate a defined service, its expected use and its cost, rather than assume that more seats always meant more value.

State the commercial sacrifice accurately

The annualised contract value of the four proposals moved from ₹1.8 crore to ₹1.52 crore under the revised package. I kept those figures in the decision paper. The change was not free, and a product rationale should not erase the commercial consequence. At the same time, it would have been inaccurate to describe ₹28 lakh as revenue already lost. These were offers under discussion, not recognised sales. The numbers described alternative propositions, with uncertainty about whether and when either would be accepted.

I was equally careful about the upside. We expected the revised model to make appropriate participation easier, but we could not promise that wider access would produce enough expansion to offset the initial difference. A persuasive forecast can become an excuse to avoid acknowledging a real choice. I wanted the decision to stand even if the hoped-for expansion took longer than expected. That required agreement about the package's purpose and the evidence we would review after implementation.

The sales lead's concern was legitimate. A simpler named-seat model had an established story and a higher initial value in those proposals. Moving to a different basis created work for quoting, explaining and comparing offers. We discussed where the new model would apply and how to keep it from becoming an informal concession for every negotiation. A product package needs a rationale that can survive the next client conversation; otherwise it becomes a collection of exceptions that neither customers nor colleagues can interpret consistently.

There was also a risk of underestimating support demand from additional readers. Read-only users still need orientation and can raise questions. We asked implementation and support colleagues to describe those needs, rather than assuming that lack of editing permission meant lack of cost. The result was a more honest proposition. We could include a role because it supported the workflow while still planning for the service required to make that inclusion useful.

Review the operating consequences after sale

The immediate result was a revised access model and four revised offers. It was not proof of improved control or a completed commercial success. We agreed to review actual participation, support demand and the use of exports as contracts progressed. Those observations would tell us whether the package was working as intended. They would also reveal whether the client's process, rather than the charging unit, was the main reason some reviewers remained outside the system.

I prefer evidence tied to the intended task. A larger number of accounts is not necessarily a better result if those accounts are unused or have inappropriate permissions. The question is whether the people who need to review the work can do so through an authorised and understandable route. That may involve fewer exports, clearer handovers or a more direct view of the current proposal. The institution remains responsible for its controls; our product should make the intended process practical rather than merely available in theory.

The same reasoning applies when a company charges by transaction, stored record or active workflow. Every unit creates incentives. A client may batch work differently, retain less history or avoid a useful review if the commercial structure makes that action unexpectedly expensive. None of those charging units is inherently wrong. The task is to understand which behaviours the unit encourages and whether those behaviours are consistent with the value the company claims to provide.

For product leaders, this requires a working relationship with finance and sales that goes beyond requesting a discount. We need to describe the operating consequence, offer an alternative and accept scrutiny of its economics. Commercial colleagues in turn need access to research that shows how a package changes use. The strongest discussion combines both forms of evidence. It does not assume that a higher initial price is always better, or that broader access will automatically justify itself through future growth.

I would bring the same question to a board: does the revenue model reinforce the behaviour on which the product's value depends? Directors do not need to set every package. They should understand when a charging choice creates tension with the promised customer outcome and how management monitors that tension. A clear answer helps distinguish deliberate commercial trade-offs from unintended consequences that have simply been left for implementation teams to absorb.

The lesson from our four proposals was modest but useful. We changed the basis on which access was sold because the original structure discouraged participation that the workflow needed. We accepted a lower proposed annualised value and kept the uncertainty about future benefit visible. Product quality includes those decisions. The experience a client receives is shaped not only by what the software can do, but also by what the contract makes sensible for people to use.