In a lot of companies pricing is set by finance, negotiated by sales, and handed to product as an implementation ticket. That sequence produces pricing that models well in a spreadsheet and lands badly in the product, because three of the four decisions inside a pricing change are product decisions and one of them has a long engineering lead time.
The four decisions
1. The value metric. What you charge per — seats, transactions, volume, accounts, workflows, events. This is the most consequential and least reversible choice in the entire exercise. It determines what your customers optimize for, what your roadmap gets pulled toward, and what you have to be able to measure.
Three tests: does it grow when the customer gets more value, is it predictable enough that a buyer can forecast their own bill, and can you measure it accurately today. Most value metrics fail the third test, which is where the timeline goes.
2. Packaging. Which capabilities sit in which tier. This is a product decision wearing a commercial costume, and it feeds straight back into the roadmap — the moment a capability becomes the reason to upgrade, its priority changes permanently. Packaging decided without product in the room routinely puts the wrong things behind the gate: features that are cheap to build and easy to copy, rather than the ones that hold accounts.
3. Price points. Genuinely finance and sales-led, informed by win/loss and discount data. Product's contribution is honesty about what the product actually does relative to alternatives.
4. Migration. What happens to customers already on the old model. This is a full product project — comparison tooling, in-product communication, a grandfathering policy, an internal support story — and it is invariably the piece that gets discovered late.
The instrumentation lag
You cannot bill on what you do not measure, and most companies do not measure their new value metric to billing-grade accuracy on the day they choose it. There is a difference between a number that is directionally right on a dashboard and a number a customer will dispute on an invoice: idempotency, retries, timezone boundaries, cancellations, partial usage, and what counts as a billable event when a request fails halfway.
That gap is engineering work, and it typically has to land before anything else can be announced. If the pricing change has a launch date, the honest planning question is when the metering is trustworthy, not when the pricing page is ready.
Grandfathering is the decision most often deferred and least often revisited. Deciding it late means the answer gets made by whoever is handling the first angry renewal, which is a bad place for policy to come from.
A note on payments and fintech
If part of your cost base is pass-through — interchange, network fees, processor costs, sponsor bank arrangements — the pricing conversation has a floor that pure software does not. Gross margin varies with the mix of what customers transact, not just how much, so the same headline volume can produce materially different economics depending on the composition underneath it.
The practical consequence: model the change against your actual transaction mix rather than a blended average, and make sure product understands which parts of the price are cost recovery and which are margin, because those two behave completely differently in a negotiation. More on that context in fractional product leadership in fintech and payments.
Where product should insert itself
Before the value metric is chosen, not after. The useful contributions are: what we can actually measure and how long it would take to measure it properly, what packaging does to the roadmap, what the migration project really costs, and what customers do today when the bill surprises them.
Practically, ask for a seat at the second pricing meeting — the first one is usually a finance model with no product implications yet, and by the third the structure is fixed.