In a lot of companies, pricing lives in a spreadsheet owned by finance. Someone models gross margin, picks a number that hits a target, and the rest of the organization treats it as a setting to be tuned later. I understand the appeal. Pricing touches revenue, revenue is a finance concern, so pricing must be a finance decision. That logic is clean and it is wrong. Pricing is one of the most consequential product decisions you will ever make, and handing it to a spreadsheet is how good products end up with the wrong customers and a confused roadmap.
Here is the claim I will spend the rest of this piece defending. Your price is a product feature. It shapes who shows up, how they use what you built, what they expect from you, and what you are forced to build next. Change the price and you change the product, even if not a single line of code moves. That is why on our team pricing strategy sits with product, in close partnership with finance, and never the other way around.
Price decides who walks in the door
The first thing a price does, long before it affects margin, is select your customers. A 9 dollar a month tool and a 900 dollar a month tool can do nearly identical things and yet attract entirely different people with entirely different needs. The cheap tool fills up with individuals and tiny teams who want it to be simple, self-serve, and forgiving. The expensive tool fills up with companies who expect onboarding, security reviews, a contract, and a roadmap that responds to them. Same software, two different products, because the price sorted the room.
This is why I get nervous when someone proposes lowering a price to grow faster. Sometimes that is right. But a lower price does not just bring more of the same customers. It brings different customers, often ones who cost more to support and churn more easily, and who will pull your roadmap toward features that serve the low end. You can absolutely build a great low-end business. What you cannot do is set a low-end price and expect a high-end customer base to magically appear. The price already decided who is coming.
The reverse is just as real. Price too high too early and you starve yourself of the usage and feedback that make a young product good. I lean toward underpricing at launch, accepting thinner margins, because early on what a product needs most is engaged users who show you where it is weak. That is a product decision dressed as a pricing one. Finance would not choose it on margin alone.
Price shapes how people use the product
The second effect is subtler and, to me, more interesting. Pricing structure changes user behavior inside the product. If you charge per seat, you create a quiet incentive for customers to share logins and under-provision, which means fewer of their people actually adopt the tool, which means weaker stickiness and a higher chance they leave. If you charge per usage, customers watch the meter, and some of them will avoid the very actions that make your product valuable to them, just to keep the bill down. The pricing model is a set of instructions for how to behave, and people follow it.
This is squarely a product question because it determines whether your product gets used the way it works best. When we price Atlas, we think hard about not punishing the behaviors that lead to retention. We want every person on a team in the tool, because a work platform that half a team uses is a half-broken product. So the pricing has to make it painless to add the whole team rather than fence them out. That is not a finance calculation. That is a judgment about how the product is supposed to feel in daily use.
Example: early on we considered metering a particular AI feature by the action, since each call had a real cost. The margin math liked it. But we realized a meter would make people ration the exact feature that, once people relied on it, made them never want to leave. Rationing it would have throttled the habit that drove retention. We folded it into the plan instead and ate the variable cost, because the product logic overruled the spreadsheet logic. That is the kind of call that only makes sense when you treat pricing as product rather than as a margin dial.
Price sets expectations, and expectations set your roadmap
The third effect closes the loop. Whatever you charge sets what customers expect, and what they expect quietly writes your roadmap. Customers paying enterprise prices expect enterprise things, single sign-on, audit logs, granular permissions, a real support commitment, a contract their legal team can sign. The moment your price says enterprise, you have promised that roadmap whether you meant to or not. If you take their money and the product still feels like a 12 dollar tool, they will feel cheated, and they will be right.
I have watched companies set a premium price to look serious, win a few big logos, and then spend the next two years drowning in feature demands they never planned for, because the price wrote checks the product had to cash. The price was a promise about what the product would become. Pricing without thinking through the roadmap it implies is how you accidentally commit to building things you never wanted to build, for customers you are not sure you wanted.
The same dynamic runs in the other direction, and it is just as costly. Price below what a serious buyer expects and you train the market to see you as a toy. It is a common trap: a product launches cheap to drive adoption, which works, and then the moment its maker tries to sell to larger teams, the low historical price has already set the mental anchor. A buyer cannot quite believe a 15 dollar tool can be trusted with real work, even after the product has grown well past that. The early price wrote a perception that then takes a long time to unwrite. Your price teaches people what to think of you, and that lesson is sticky.
Why finance owning pricing goes wrong
None of this means finance should be absent. We need finance deeply involved. They model the unit economics, they keep us honest about margin and burn, they catch the plan that loses money on every customer at scale. That work is essential and I would not run pricing without it. The failure mode is not finance participating. It is finance owning the decision, because finance optimizes the variable they can see, which is the number, and the most important effects of pricing do not show up in their spreadsheet until much later.
A finance-owned price tends to be locally optimal and strategically off. It hits this quarter's margin target and quietly attracts the wrong customers, distorts usage, and over-promises on the roadmap, costs that land six and twelve months out. By then the number looks great and the product is in trouble, and nobody connects the two. The discipline is to treat the price as a lever on the whole system, not a dial on a single metric. That systems view is what product is supposed to bring.
The packaging question is a product question too
People conflate pricing with the single number, but most of the real product work lives in packaging, which is how you slice your capabilities into plans. Packaging is where you decide what belongs in the entry tier and what is reserved for the tier above, and those choices are pure product judgment. Put a feature too low and you give away the thing that would have justified an upgrade. Put it too high and you cripple the lower plan so badly that people never get far enough to see the value and upgrade in the first place. The art is leaving the entry tier genuinely useful while keeping a clear, honest reason to move up.
We think about this in terms of which features deepen with scale. A capability that an individual barely needs but a growing team cannot live without is a natural upgrade trigger, because the customer feels the pull themselves as they grow. Advanced permissions, automations, the API and MCP server, admin controls, these belong higher up not because we are gating value for its own sake but because that is genuinely when customers need them. Good packaging follows the shape of how customers actually mature, so the upgrade feels like a natural next step rather than a tollbooth. Bad packaging fights that shape and makes every upgrade feel like extortion.
The trap to avoid is packaging by feature count, slicing arbitrarily so the comparison table has satisfying rows of checkmarks. Customers see through it, and worse, you end up withholding things that should be standard just to fill out a tier. We try to package by customer type instead. The question is never "what can we move up to make this plan look fuller," it is "what does this kind of customer actually need," and the table sorts itself out from there.
How we actually make pricing decisions
So how do we run it in practice? We start from the customer we want and work backward, not from the margin we want and work forward. We ask who should this plan be for, how should they use the product, and what do we want them to expect from us. Only then do we ask what price selects that customer, encourages that usage, and matches those expectations. Finance pressure-tests the answer for viability. If the economics do not work, we change the product or the customer, not just the number, because the number was never the real choice.
We also accept that pricing is iterative and we treat changes with the same care as a product release. A price change is a product change, so it gets the same scrutiny, the same rollout plan, and the same honesty with existing customers. We grandfather people when it is right to, we communicate clearly, and we never spring a repricing on someone mid-contract. You can see how we have landed on our current structure on our pricing page, and you will notice it reads like a product decision, organized around who each plan serves, not around margin tiers.
A few principles guide us when we get into the details:
- Do not punish the behaviors that lead to retention. Make it cheap and easy to do the things that make customers stay.
- Let the price match the promise. If you charge serious money, ship the serious product that price implies.
- Choose your customer on purpose. The price will select one regardless, so select deliberately rather than by accident.
The takeaway for anyone building a product
If you take one thing from this, let it be that SaaS pricing and monetization are not the final step after the product is built. They are part of the product, as load-bearing as your core feature set. The number you put on the page reaches back and reshapes everything, who uses it, how they use it, and what you will spend the next two years building. Treat it with that weight.
So bring finance to the table, lean on their rigor, and then keep the pen in product's hand. Ask who you are selecting, how they will behave, and what you are promising, before you ask what hits the margin target. Get those right and the margin tends to follow. Get them wrong and no amount of spreadsheet optimization will save you, because you will have built the wrong product for the wrong people and charged them a number that made it inevitable.