Your company needs a pricing constitution.

To keep up with all of your increased shipping velocity

Every company needs a pricing and packaging philosophy that controls how everyone makes packaging decisions. Period.

But most do not. Instead, they’ve got… a pricing page. They’ve got a spreadsheet. They’ve got 14 Slack threads (each with different participants) arguing about whether some new feature should be in Free or Pro. Some even have the privilege of storing a 97-slide pricing research deck from Simon-Kucher Price that no one has ever actually read (Can I do a rant about SKP? Yes I can, but I shouldn’t… Not here.)

This has always created problems but it’s about to become a much bigger one, with every software company shipping faster and faster. Not only can engineers code faster, but growth/marketing teams are getting in on the fun, and if your CEO hasn’t yet added something to the roadmap that they vibe-coded over the weekend, they will!

So if everyone is shipping more product, we’re also gonna have more monetization decisions. Every new feature comes with the same questions: Is this free? Is this paid? Which paid plan? Is it usage-gated? Is it an add-on? Does Enterprise get it?

Without a pre-agreed philosophy, every feature becomes its own little pricing negotiation, and each team fights for their own priorities. So companies either ship a bunch of disconnected and confusing updates, or lock everything down until negotiations (and renegotiations and counters) can be completed.

Is there a way out of this? Yes there is.

---

Sponsors: Elena’s Picks

You don’t want generic ads, right? To make things more valuable for you, I’m featuring products and services that I personally recommend or am trying out:

→ Research Flow by Typeform: I built and ran an entire qualitative study of 300+ people (for my ‘What people really think of IC roles’ report) with the Research Flow product and got to work closely with the Typeform team to hear their vision for it. I’m excited for all teams (growth, marketing, product, everybody) to get to do way more high-quality qual research.
🎁 Offer: Schedule a demo and get $500 off. See terms and conditions.¹

→ Amplitude’s Agent Analytics: I’m checking this out because… do you really know if your AI features are working? Just like Amplitude let teams everywhere understand the actual impact of product usage, their new thing is helping you figure out how all those agents and assistants are affecting your conversion, retention, and revenue.
👀 Check it out: Learn more.

→ ‘Ask the Experts: Pricing AI products for revenue growth’ with Stripe: For any AI or SaaS leaders out there working on your AI pricing (all of us right?), this virtual event looks cool: Sam Lee (Stripe’s head of global pricing) and Andrew Garvin (COO/cofounder at Metronome, a Stripe product) are doing a full Q&A on Oct 6. I want to hear how they discuss usage-based vs. hybrid vs. outcome-based.
📅 Check it out: Register for free.

---

The way to stop this is by documenting your company’s specific philosophy in a pricing and packaging constitution. This is a single doc that maps out the key trade-offs and the reasoning behind them.

I’ll start with the bad news: This will be tough. The hard part is getting everyone to agree and commit to the document. The negotiations are happening because each department has conflicting priorities. That won’t go away with this document. But once you’ve set it up, at least you can stop having the same arguments over and over, and repeating them every time anyone wants to launch something new.

And there’s also good news: You don’t have to reinvent the wheel. You do need to get everyone aligned internally, but most companies should have pretty similar constitutions. There are definitely some differences based on your product category (enterprise-only vs. social vs. gaming, etc), but the central ‘laws’ have a lot in common.

As you’re navigating this with your team, here are a few of the core principles that I always want to see in this kind of doc:

1. Charge for adding value, not removing pain you created.

One of the frameworks from Reforge that has stuck with me for years is:

Price < Perceived Value - Friction

Unfortunately, it seems like a lot of teams take this in the wrong direction - yeah, you can create value from reducing friction. But it doesn’t count if you’re the one who created the friction in the first place.

One of our principles at Lovable is: ‘Never manufacture pain to monetize it. We charge for more value, not for removing friction we intentionally created.’

SaaS has gotten annoyingly creative with manufacturing friction part - we take something useful away, make the lower plan sufficiently frustrating, then charge customers to make the frustration disappear. Revenue go up! For a short period of time that is. Then the struggle bus begins.

If your principles take this approach off the table, your team can focus on things customers actually love, like a more effective/efficient product, more obvious ways to use it, and removing friction that wasn’t manufactured by your co-workers. Long term growth, here we come!

2. Outcomes, not inputs

What are your customers paying for? I always opt to monetize as close to the outcome as you can. Obviously this isn’t always possible because many products create outcomes that are difficult to directly measure, but if you can measure the outcome, I would much rather monetize there than monetize every input required to produce it.

Every time you monetize an input, you give customers a reason to ration the exact behavior that leads them toward value. If someone needs to perform 100 actions to get one valuable outcome and you charge them for every action, congratulations, you have successfully created a pricing model that encourages people to use your product less.

At Lovable, our approach is: ‘Monetize the outcome. Not the steps required to get there.’

Yeah, this is extra hard because of, you know, LLM token costs. Yes, we are painfully aware of this at Lovable :) But just like we don’t want to foot the bill for someone endlessly pinging the AI while they’re bored, users aren’t going to pay for products that don’t actually generate the eventual outcomes they want.

Do the hard thing and put this principle in writing, so you can start figuring out where customers actually experience incremental value and line up your monetization with that.

3. Choose some things NOT to monetize

Not all value should be captured immediately.

Repeat after me, class: Not. All. Value. Should. Be. Captured. Immediately.

When you leave some of the value uncaptured, that’s you investing it back into growth.

If collaboration drives retention, don’t immediately ask how much you can charge per user. If sharing drives acquisition, don’t go and paywall all the stuff that people are sharing. If repeated usage dramatically increases conversion, maybe restricting that usage isn’t the brilliant monetization optimization the spreadsheet says it is. I’ve seen companies discover an insight like ‘users who invite teammates retain 3x better!’ and then somehow conclude that this means they should charge these users to invite teammates.

All of these trade-offs mean that you’re picking constraints. But if you understand your growth model, you can choose the right ones.

At Lovable, the relevant principle is: ‘Freemium is our growth engine. If it spreads Lovable or brings people back, it should probably be free. Don’t tax your own distribution.’

Yeah, that can be frustrating sometimes! But that’s kinda the point: it means there will be things we could charge for that we deliberately choose not to, because the value to the ecosystem is greater than the immediate monetization potential.

4. How simple can we make it?

‘The customer totally understands it’ packaging and ‘We make as much money as possible from each tier’ packaging are mortal enemies. And every company has to figure out the principles that they’ll follow, but for this one: Please go with the clear, transparent option.

One of the most obvious places you see this is in how many variables you’re going to ask customers to hold in their heads to understand what they’re actually going to pay. Is it… seats + storage + credits + projects + API calls + premium actions + some new unit invented internally that customers have never heard of? Or is it… yeah, just one primary metric? Some products really do need 2, but even 3 is too many.

I’m a big believer in this because it’s not just your customers who will thank you. Each new pricing dimension you add is something Product has to meter, Engineering has to build, Support has to explain, Sales has to negotiate, and Marketing has to build a (probably confusing) campaign around.

The same principle applies to plans. I almost always recommend Free-Good-Better-Best packaging with 4 plans max. Plus, each plan has to represent a different customer need, so that the customer can recognize themselves and naturally gravitate toward one of those needs. Each plan is a different destination for a different segment, even if they all have the same starting point. That’s how you really keep things simple.

Here’s an exercise I like to do to test this: I ask the team to give me the 3 biggest reasons someone chooses each plan. Not which 47 features it contains, but why this customer needs it. Maybe one plan is for individuals and teams getting started. Another is for companies running applications with SLAs that need more control and reliability. Another is for large organizations that need governance, security, procurement, and enterprise support. Once those needs are clear, the features usually become much easier to place.

5. Rules of engagement for revenue channels

This is probably at the foundation of most monetization debates - who’s getting credit for the revenue?

You can tell things are broken when you hear things like my personal favorite version of this: ‘We lost the deal to self-serve.’ You lost the deal... to your own company? The customer chose your product. They’re sending you money, probably lots of it. So, yeah, maybe we should send that other team a thank-you note instead of opening a Salesforce investigation?

Customers do not care which VP has the number, and they definitely don’t care that according to your beautifully color-coded segmentation model, a company of their size is ‘supposed’ to talk to Sales. If you give customers multiple ways to buy, they will choose the one they prefer. This should not be surprising. But we still somehow end up acting personally betrayed when customers don’t follow the routing logic we designed for them.

This is why companies need to clarify the broader roles before they design all the individual channel rules. At Lovable, we say ‘Self-serve lands. Sales expands. Self-serve maximizes how many customers start. Sales maximizes how far the company goes.’

This makes the role of Self-serve and Sales much cleaner. Sales joins in when humans can actually unlock an amazing value through expansion support, procurement sherpa’ing, implementation guidance, education, complexity management, or whatever else the company needs. And they add SO much value! On the other hand, the job of the Self-serve is to discover, acquire, engage, and do an initial sell to the customer. That is a much healthier relationship between PLG and Sales than drawing an arbitrary line at 500 employees and announcing that everyone above it must now fill out a form.

Why you need a Monetization Council on top of this

The Constitution should be clear and publicly posted so that everyone can reference it. I’m working on that at Lovable right now. But you can’t have everyone creating this doc or constantly maintaining it.

Enter: The Monetization Council. This should include representation from Product, Engineering, Growth/Marketing, Sales, and Finance (but keep it small!). And not to lean too hard into this governmental/legal analogy, but you could say this group acts like a Supreme Court. As people across the company are applying the rules, this is the central body that keeps track of whether it’s working. And even with a great Constitution, you’re going to need to escalate some scenarios. When you have edge cases or situations that show that the lines may not have been drawn quite right, use the Monetization Council to sort it out.

Argue now or argue later.

If everyone agrees at the beginning, you’re doing it wrong. A good Constitution is intentionally restrictive and chooses some hard trade-offs: Everyone wants ‘Keep pricing simple’ in there, but what happens when some extra complexity could add another $2M in theoretical revenue?

You’ll be able to tell that your Constitution is working when it actually costs you something.

• ‘Don’t tax your distribution’ means you will sometimes give away something you could have charged for.

• ‘Self-serve by default’ means Sales might not get some large customers, even if they’ve crossed an arbitrary ARR threshold.

• ‘Never manufacture pain to monetize it’ means some very tempting upgrade levers are off-limits.

• ‘One primary usage metric’ means you won’t be as efficient as possible when added layers would confuse users.

If you can settle this ahead of time, your org will move so much faster. This kind of constitution is critical infrastructure if the company is going to ship in a rapid, iterative way. Old-school, centralized decision making on monetization updates just will not work. If a company is trying to execute at warp speed, you have to not only get everyone on the same page for pricing, but also for the philosophy behind it. That’s the only way for everyone to make these decisions for themselves and stay moving in the same direction.

Bringing up this topic is going to be frustrating and cause some arguments now. That’s because your team disagrees about some of these trade-offs. So you can either go ahead and have those arguments now and sort it out, or you can pretend like it’s not an issue… and renegotiate those disagreements across every feature, surface, and launch, forever.

Go ahead and have the one frustrating conversation now and get things documented so you can avoid having that same convo 100x over the next 6 months.

---

Edited by Jonathan Yagel.

---

1. Terms for $500 discount on Research Flow: Valid until September 30, 2026. New Research Flow customers only. $500 off the first annual subscription, applied after eligibility is confirmed. One per customer/account. Not combinable with other offers; no cash value; non-transferable. Subject to a signed order form and Typeform’s applicable subscription terms. Typeform may change or withdraw this offer at any time. Data handled per our Privacy Policy.