As you know, I hate ‘growth hacks’. Growth is a discipline that deserves systems, not only ‘hacks’. However, I gave into it once, at Qonto. It involved pricing, and more specifically ‘billing’.

Pricing is the most powerful growth lever, once you’ve reached ‘product market fit’. It’s quite obvious why. Yet it’s so hard to get it right, and to crown it all, we rarely iterate on it.

But why is that?

TL;DR

The usual way to iterate on pricing (and I’ve been there) within Growth and Revenue teams:

• Business teams play with a spreadsheet with countless pricing models for hours/days/nights
• Engineers are looped in at the end of the process, kill the pricing grid, and a much simpler version is implemented (if any). Business teams still have no idea of the intricacies of the billing system and ask engineers to ‘just do it’
• No one really owns the pricing changes implication across teams, while it’s a highly sensitive topic for the user experience (and the actual bottom line!).

If I had to do it again, I would:

• Map the constraints and architecture of the current billing system, and design pricing iterations within the existing system (or change the billing system completely, but that’s at least a 1-year project)

• Carve out time to be the Billing Product Manager and Product Marketing Manager myself (or staff someone relevant if it’s an option), and mindfully check expected behaviors.
• Anticipate a switch (total or partial) to ‘consumption-based’ pricing: it’s a data engineering challenge, but the more you understand the concepts, the better you can influence the outcome. Hint: you want maximum flexibility, to experiment as much as needed.

The 'hack'

At Qonto, I initially used to think that, as my team owned ‘Revenue’, we ‘should’ be able to iterate on pricing, and that ‘should’ be prioritized in the engineering roadmap.

Of course I was wrong: too many ‘shoulds’ to be true!

Although it might make sense in theory, in reality, even for a well-funded startup with super ambitious revenue goals, life is a bit more complex than that: engineers are obviously scarce, and they usually don't fight to work on pricing implementations.

My team and I ended up developing a ‘hack’: changing the front-end pricing page (qonto.com/pricing), as we could do this on our own, without changing the back-end (and asking the Tech team).

For instance, on the pricing page, we’d say that if you choose the Solo plan, only one member could access the account. So if you had a team, or wanted your accountant to access your account, you had to choose the upper plan.

In reality, for a limited period of time, nothing was changed in the back-end. That still positively impacted buying decisions, and MRR, so it was a nice hack!

Beyond this anecdote, I think there is much better value and growth to be unlocked there.

3 key learnings

I’ve seen many teams struggle to iterate on pricing, and here are my 3 cents on what can be done differently:

1. Get out of your spreadsheet earlier and deep dive into the billing system

I spent too much time playing with pricing models on spreadsheets, projecting revenues and impact of potential changes, defining different scenarii and debating them internally. This is a common pitfall shared by analytical minds.

Although that was intellectually interesting, 80% of the work was useless, because if the new pricing is hard, long or expensive to implement, it’s not going to be implemented (or in many years, yet you want to hit your revenue goals for next quarter right?).

So, if had to do it again:

• I’d start by understanding the intricacies of the current billing system: how is it architectured, what the data objects are, why engineers built it that way
• I’d identify the dimensions I can play with
• And only then I’d design different pricing plans

For instance, some of the ‘most basic concepts’ we did not initially nail as a team:

• The different components of getting our users to pay us, what’s managed internally (and by which team), and externally. A typical breakdown is:
• (i) calculating how much the user needs to pay (billing),
• (ii) sending a normalized .pdf file that itemize what they should pay and why (invoicing),
• (iii) making users actually pay: via card, direct debit, transfers… (cash collection or payments),
• (iv) managing users who don’t pay or say they should not pay what you invoiced them (dispute and retries management).
• Our take on ‘grandfather’ plans. In short, grandfathering plans means that when you ‘kill’ a pricing plan: it disappears from the pricing page (a user cannot switch to this plan anymore), but users who are currently on this plan can stay on it. It has pros and cons, both for user experience, revenues, and product. Read more here.

By the end of this step, you should be able to map what pricing changes you can make with low, medium or high impact on the other teams within your company (engineering, product, operations).

2. Accept your unofficial role as the Billing Product Manager or Product Marketing Manager

Now that you’ve redesigned a new pricing grid that is more realistic from an ‘implementation’ point of view, there are ‘just a few’ implications you should consider as well:

• Do you want current users to be ‘grandfathered’ or not? What’s the user journey like for each case?
• Does the pricing change impact the upgrade or downgrade journey?
• Does it impact how vouchers are working today? (e.g., if you change the plan structure, but you partnered with Y Combinator to give their community free access to a plan that does not exist anymore)
• Does it impact payment and invoicing? Do you have enough engineering bandwidth to make the changes?
• Is there a chance to increase the ‘retries’ rates? i.e., because of the pricing change, will more payments fail or succeed?
• Will ‘revenue recognition’ be different? How is it going to impact the Finance team?
• Will it change the way Customer Success is handling requests?
• How will we measure the success of this change? Is there a ‘rollback’ possibility, or is it a ‘one way door’ change? Is there a way to test it on a small portion of the user base first? How?

This is not an exhaustive list. But if you own revenue, and no one else is officially in charge of billing, know that all these tasks are probably yours.
That’s why so many teams give up on iterating on pricing IMHO, and leave revenue on the table.

Don’t be one of them!

At the end of this step, you should have mapped out the implications of pricing changes, hold a cross-team roadmap, and make sure everything happens (nearly) as planned.

3. Sooner or later, your pricing will include ‘consumption-based’ dimensions, be prepared

In theory, the two main types of pricing in SaaS are:

• Subscription-based: you pay a fixed fee per month for a feature. Typically, €12/month for unlimited Netflix, or Spotify. You don’t pay each time you watch a new series, or listen to a song.
• Consumption-based or ‘you pay as you go’: Stripe is an example. You pay proportionally to the amount of payments you have to process. Or VOD with Amazon Prime Videos. It’s very popular for ‘product-led growth’ motions.

In reality, most pricing plans are hybrid, here are 2 examples:

Mailchimp bills based on ‘the number of contacts’ you have in your Mailchimp list (consumption) and the features you want to access (subscription).

Qonto is subscription- based (you need to pay a fixed fee/month to have an account), but you also need to pay what you consume outside your subscription (e.g., ordering a new card, paying in a non-euro currency).

Once you’ve identified ‘value metrics’ (metrics you think you can base a consumption pricing on: typically a number of requests for a product like Algolia), you should assess if your data infrastructure has been designed to be able to meter the usage of ‘value metrics’.

For instance at Qonto, one of the ‘value metric’ was the ‘number of active cards per month’.

Billing this metric, once again, appears simple, but was not trivial, it meant answering these type of questions:
How often do you measure the number of active cards during the month (everyday? At the beginning/end of the period?), what if you have 4 active cards that are included in your current plan (the ‘Business’ plan), and then decide to downgrade to a plan that only includes 2 active cards (the ‘Essential’ plan), how should we deal with the 2 cards that are now of ‘overage’?

My point is: the sooner you anticipate how you’re going to bill features or usage, the easier it will be.

For instance, if a new product launch is cooking, if you think you will want to bill ‘per usage’, sit with your engineering team to understand which metrics can and should be ‘billable’, i.e.: metered, aggregated, and sent at a specific frequency to other internal systems.

At the end of this step, you should be able to apply for a data engineering job. I’m only half kidding 🙃.

Final words

IMHO, if you own ‘Revenue’, you must know how your users are going to be billed and how cash is supposed to be collected. It might not appear as ‘glamourous’ but it’s key.
For what it’s worth, I genuinely think billing, payment and cash collection are fascinating and underrated topics, as there’s almost nothing closer to the ‘source of data truth’ of a company than their billing system and data.

If you want to share notes or discuss your pricing/billing strategy, happy to chat! Find me at @ByAnhTho!

NB: Interesting reads on this topic:

• Making Monetization your Superpower - @ElenaVerna
• Awesome Billing (open-source list of tools and ressources for engineers in charge of billing) - @kdeldycke
• A Structural Pricing Competitive Advantage in SaaS - The Three Part Tariff - @ttunguz
• The Usage Based Pricing Playbook - @openviewventure