When I first got to Eventbrite, a lot of PM's were coming into Concept Reviews and putting a new feature in the base package.

But building more features for the same price just leads us to maintain more and more code for the same amount of money. So I wanted the team to start thinking about how we should monetize something more strategically and earlier in the process. That is where this diagram comes from.

These were a list of questions/rules to help the team decide how to monetize a new feature or product. With out them, I think teams make a lot of mistakes such as:

1) They try to give EVERYTHING away for free.
2) Don't understand the unit economics well or the cost to support a new feature/product.
3) Don't understand what activates a user.
4) They don't understand the actual willingness to pay. This is normal but I expect PMs to work with our research & marketing team to figure that part out.

Another famous example is Dropbox giving away free space. They gave enough free space to users until they had enough stored on Dropbox that they had clearly built a habit with Dropbox which increases willingness to pay when you do ask them to pay.

Another common example here are security features like SSO in SaaS software. SSO doesn't drive virality, activation, or LTV but enterprises have a high WTP for it.

If the feature does not map to other features that can be a separate package from the core package then it should be an add-on.

Email campaigns was a core feature allowing event creators to promote their events to their base. 

Casey Winters

When working on a pricing and packaging overhaul at Eventbrite, I used this guide to help the team discuss and decide where new features should fit in their pricing and packaging structure.

These are some perspectives that we’ll consider for our pricing and packaging overhaul and how we’ll decide where new features should go in pricing and packaging.  Deciding how we monetize a feature is a key part of how we want to build products at Eventbrite.  As a reminder, here is the 

How does the feature/product create value?

The first question to ask is - Does the feature or product create value?  This is more important than answering how we could monetize it.  A feature/product must be able to answer this question first.  If it does, then the next steps are how I roughly think about answering the monetization question.

If the feature or product drives virality, then we should give it away for free in order to drive acquisition.  An example is that we have a partnership with Facebook to embed Eventbrite events into Facebook events natively.  We give this away free to customers as this drive more ticket sales for the creator and more creator acquisition for Eventbrite.

If the feature drives activation, then we are incentivized to give it away until the customer has activated.  

 is Email Marketing for creators (see below for full example).

If the feature drives LTV, then compare LTV gains vs. willingness to pay to determine if we should charge for it.  An example would be embedded checkout on creators' website. Embeds increase retention by locking our code into creators' websites at some tradeoff with Eventbrite brand recognition. But creators also value it a lot.

If something does not drive virality, activation, or lifetime value, but people have willingness to pay then 

. An example is enabling creators to get payouts faster.

Does the value provided cover the cost to support?

What is the cost to support the feature/product (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.

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? Emily Simonin proposed a 2x2 framework on how to answer this question. (This breaks down features into four categories: 

, don't build, higher package, or core package.)

If we look at rule no. 6 above, we are incentivized to add scale discounts to this framework where appropriate. How do we do this without making pricing too complex to understand?

Let’s walk through each of these questions using an example like 

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

Yes. This helps creators directly drive ticket sales.


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

If we charged for emails separately, a lot less creators would try our email products. So likely it being free for certain amount of time or certain volume is important to maximizing usage.

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

Intuitively, the more of our products and features creators use, the stickier they are. So creators that start using Email Campaigns should have higher lifetime value because they are using more of our platform and because creators who leverage email are more likely to be successful. We have not done an analysis of willingness to pay for Email Campaigns, but know for it to be successful, it would need to be priced under a lot of competitors on the market.

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

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

There is a decent amount of engineering cost to support this feature. We also have unit economic costs because it requires specific pieces of infrastructure like Sparkpost and to a lesser extent AWS. It is unclear whether the virality or lifetime value make up for these costs today as we would likely still get the virality through creators using other email vendors outside of our ecosystem.

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

Our infrastructure costs for both Sparkpost and AWS likely go down with scale, so there is an opportunity to make the per unit cost of sending emails with Email Campaigns cheaper as specific creators send more emails through it.

Keep it free until certain usage of time-based triggers signal creators are activated with the product.

Determine willingness to pay based on competitive and creator-based research. Costs per email should scale down with usage.

From the 2x2, a high # of creators use, so determine which package based on WTP research.

Guide for pricing and packaging features at Eventbrite

Feature Monetization At Eventbrite

Overview

How To Decide On Feature Monetization

How does the feature/product create value?

Does it drive virality?

Does it drive activation?

Sign up to see more