The Monetization Playbook We Used at Eventbrite

One of the problems we faced when I joined Eventbrite was that Eventbrite had a pretty low take rate, meaning when event creators sold paid tickets on our platform, we took a very low percentage. And when creators sold free tickets on the platform, which are the majority of tickets, we didn’t make any money. You need an incredible amount of volume to make profits with low take rates, like say Paypal or Stripe, and even though Eventbrite has tremendous scale, it wasn’t enough to make material profits. We needed a way to make more money for the value we created if we wanted to be a successful company i.e. a new monetization playbook. I’ll discuss below the playbook we built, and some of the process to get there.

A tweet I made when I was working through this at Eventbrite.

At the most abstract, there are two ways to grow profitable revenue for a network business:

• Make more revenue per customer

• Increase network volume

Eventbrite had tried to improve its revenue per customer before I arrived as Chief Product Officer. The company did what most SaaS companies do in this position: hire a consulting firm, work closely with them for a period of time, and decide which of their recommendations to implement. This created the first packaging model for Eventbrite. Instead of one package, there were now three that had different features for paid event creators. This all sounds very non-controversial, but the impact was pretty negative for Eventbrite. While revenue initially went up, over time, growth slowed as event creators eventually churned due to the new prices, which doesn’t just impact retention, but also acquisition, as the marketing they do for their events is the main driver of new creators. Revenue per customer went up but network volume slowed. Not a great tradeoff. In addition, no one chose the first plan, and free creators still paid Eventbrite nothing.

Eventbrite was pretty constrained on how to adjust levers in the pricing model. As a transactional business with payment processing costs, you tend to have both fixed and variable fees. As you drop one or the other, you basically decide whether you’re hurting pricing for event creators with smaller or higher priced tickets. Companies like Orb have since come along to make bigger changes in pricing more manageable, but our system at the time was very brittle and rigid.

So the company tried to re-ignite the network volume growth the pricing change hampered, but with a pricing model where two thirds of creators still don’t pay and a sub-10% charge for paid tickets that made many forms of paid growth unviable. 

The product team rushed in to create new value for event creators, but this just put more pressure on the take rate as you’re now trying to maintain more software for the same amount of revenue. Everything the product team recommended default shipped to all pricing plans as well, which meant we weren’t improving the value of more expensive plans over time. The baseline reasoning for this is to maintain pace with competition, which, if you hear it in your company, might mean we’re not investing in the right features that can’t create differentiation. But also I think this default practice reflected a lack of comfort with pricing recommendations and becoming more business oriented in our approach to product development. Or maybe just laziness.

This laziness extended beyond pricing the new features, but also marketing them. Many features lacked awareness with our creator base, creating a deadly loop of product development.

We needed to shift into a new model that forced product teams to think about both pricing and marketing features as a core part of their job, and it was of course my job to teach them how to do it. The model needed to look more like the below:

Obviously, you cannot charge for every feature. Sometimes, we do need to keep up with competition, but changing the default is important to getting a team to help the company actually become a sustainable business. 

If we get in the habit of charging for the value we create, the main question is how to do so at both a feature / product level and an overall offering level. The first question to actually ask is does the feature or product create value that is more important than how much we could monetize it. How we thought about answering this question is:

1. Does it drive virality? If so, we’re incentivized to give it away.

2. Does it drive activation to long term retention? If so, we’re incentivized to give it away until activation is achieved.

3. Does it drive lifetime value? If so, compare lifetime value gains vs. willingness to pay to determine if we should charge for it.

4. If something does not drive virality, activation, or lifetime value, but people have willingness to pay, we should charge for it.

5. What is the cost to support this (eng costs, unit economics)? Does the value provided in the above questions cover for that cost? If not, don’t build it or sunset it. 

6. Do the costs have economies of scale? If so, can sharing these economies improve lifetime value? If so, refer back to rule no. 3.

If we decide to charge for something based on answering the above questions, the next question is how. We used the following 2x2:

What creates low willingness to pay for things that a lot of creators will use is that they are available elsewhere in the market. While you of course need to build some of those, that is not where enterprise value is created. Enterprise value is created in the top row where there is differentiation and therefore higher willingness to pay. Answering these questions while working on the initial concept of a product vs. at the end when it’s already been built is a good prioritization element in and of itself.

The reason the 2x2 defaults to packages is that if you apply a willingness to pay framework too literally, monetization can become too complex. Pricing ever feature a la carte quickly turns into something approaching the toothpaste aisle at a drug store. In theory, there is a reason for why there are a hundred plus varieties with different features and price points, but no customer will go through the work to understand all of that. So there is still a bundling art form that product collaborates with marketing on to make the packages viable and digestible at perhaps the sacrifice of some individual feature willingness to pay. Frameworks are great for 80%, but I always preach that product folks can’t let the framework absolve themselves of responsibility for using their brain to make the company successful. 

If you want to learn more about pricing and packaging frameworks and how to measure willingness to pay, I highly recommend Reforge’s Monetization & Pricing program. If you’re not sick of me, the Pricing Strategy and Advanced Growth Strategy programs I helped create are also starting again soon.

Currently listening to my Dune: Part Two playlist.