RFC-60: Marketplace Monetization Strategies

[SarahAllen]

Disclaimer: This is a proposal and is subject to changes. Its purpose is to gather feedback.

RFCs are a way for Atlassian to share what we’re working on with our valued developer community.

It’s a document for building shared understanding of a topic. It expresses a technical solution, but can also communicate how it should be built or even document standards. The most important aspect of an RFC is that a written specification facilitates feedback and drives consensus. It is not a tool for approving or committing to ideas, but more so a collaborative practice to shape an idea and to find serious flaws early.

Please respect our community guidelines: keep it welcoming and safe by commenting on the idea not the people (especially the author); keep it tidy by keeping on topic; empower the community by keeping comments constructive. Thanks!

• Publish: Aug 28, 2024
• Discuss: Sep 16, 2024
• Resolve: Sep 23, 2024

*The scope of this RFC does not cover implementation details and these will be shared in future RFCs.

Dear partners,

As you may know, we have been discussing how partners can better price and package their apps for both SMB and enterprise segments. To reach our shared business goals, the Marketplace needs to evolve and grow. We aim to fuel this growth by crafting a scalable and adaptable monetization strategy to empower Marketplace Partners to establish successful businesses while maintaining a fair and equitable Marketplace for existing and new partners.

Why is ‘now’ the right time to re-evaluate the cloud Marketplace monetization model?

1. We have successfully surpassed the $1B annual GMV milestone and are now aiming to identify opportunities for accelerated growth beyond our historical rate. To achieve this, a thorough reevaluation of the Marketplace monetization strategy is essential to unleash exponential growth for the Marketplace and our valued partners within the ecosystem.
2. To drive our future growth, we must boost app adoption among customers. This can be accomplished by streamlining the purchasing process and offering customers greater flexibility.
3. The new models would provide all partners with equal opportunities to develop, promote, and sell apps on the Marketplace, supporting various business models.
4. Additionally, technological advancements, such as AI and machine learning, offer new opportunities to optimize monetization strategies and enhance the customer experience. For example, apps built with AI as their primary use case could be priced based on the number of requests.

Current State

Licensing

Currently, the Marketplace only allows app licensing at the instance level. This means that customers must buy apps for the total number of users on the instance. Enterprise customers using Enterprise Confluence or Jira need to purchase the app separately for each instance. These practices may lead to potential challenges and limitations for customers based on the app’s functionality.

Another notable concern, particularly for Jira apps, is that app compatibility is determined for the entire Jira cloud, encompassing Jira, JSM, and JPD. As a result, customers cannot purchase the app solely for one product and must pay for the maximum number of users across any Jira product on the instance. This characteristic significantly hinders the growth of the JSM app ecosystem on Marketplace.

Packaging

Marketplace partners encounter significant challenges when customizing app features for different customer segments. This is primarily due to the constraint of having only a single edition with tiered pricing based on user count. Such limitations make it arduous to tailor apps to suit the distinct requirements of customers, leading to missed opportunities in offering premium features to high-demand clients and cost-effective options to price-conscious ones. Consequently, some apps might incorporate additional features at higher prices, potentially alienating customers with simpler needs. Conversely, partners focusing on affordability struggle to meet the advanced feature demands of Enterprise customers, hampering their adoption by larger customers. This underscores the pressing necessity for a more adaptable pricing and feature strategy to effectively address the diverse customer needs and enhance app adoption across various market segments.

Pricing

Apps available on the Marketplace are currently priced solely according to the number of users. This presents a significant challenge for partners aiming to fine-tune pricing for apps with diverse functionalities, irrespective of user quantity, thereby impeding their business expansion. Moreover, JSM apps are priced per user instead of per agent, establishing obstacles to the adoption of these apps. Consequently, this situation has led to an underinvestment in the JSM ecosystem.

What are we proposing?

Before we dive into specifics, we would like to clarify that all of the above proposals are going to be OPTIONAL for Marketplace partners to adopt based on their respective monetization strategies for their apps.

Licensing

In addition to instance based licensing, we are also introducing the following:

Multi-instance Licensing

• What is it? We are introducing a new option for Marketplace apps called multi-instance licensing, specifically designed for customers using Enterprise editions of our products. This innovative approach enables Enterprise edition customers to obtain apps based on the total number of unique users across different instances, rather than buying licenses individually for each instance. The opportunity to acquire apps at the Enterprise level will be offered as a licensing choice for every paid edition of the app. Additionally, customers will still have the option to purchase the app at the instance level. Initially, this feature will be accessible to high-touch customers who are acquiring the Cloud Enterprise edition.
• Partner Impact/Expectations: Partners are required to offer multi-instance licensing and will have the flexibility to set alternative pricing for customers who opt for this licensing model.

User Based Licensing

• What is it? In this licensing model, we offer Marketplace partners the option to sell their apps on Marketplace based on a subset of users rather than the total number of users on a instance.
• Partner Impact/Expectations: It is important to note that this licensing model is optional. Marketplace partners have the flexibility to switch from instance-based licensing to user-based licensing if they believe this model better aligns with their business growth strategy. This decision can be influenced by factors such as the app’s functionality, the target customer personas, and various other considerations and we will be providing the required data to help you evaluate these options.

JSM decoupled from Jira

• What is it? This adjustment primarily targets apps designed specifically for Jira Service Management (JSM) that have faced limited adoption by customers due to constraints in the current licensing model.
• Partner Impact/Expectations: Marketplace partners opting for this approach for their apps will define the compatibility of the app with a particular Jira product, such as JSM Cloud. Subsequently, customers will have the opportunity to acquire these apps tailored for JSM. This new model enables customers to pay for these apps based on the number of users on JSM, rather than the total user count across all Jira products, as per the existing billing framework. Now partners will have the opportunity to market their JSM-app to customers based on the number of users on JSM, which wasn’t available before. It will also be optional for Marketplace partners to implement.

Packaging

We are introducing App Editions which will allow Marketplace partners to segment customers and package features into apps across multiple editions. We will allow 3 editions for the apps i.e. free, standard and advanced. Initially, two editions, standard and advanced, will be available. More details can be found in the RFC-46: App Editions for Marketplace.

Pricing

While continuing with per user pricing, we are also introducing more avenues for Marketplace partners to price their apps.

• Per agent pricing - In our ongoing commitment to streamline JSM app processes, we are exploring the possibility of allowing Marketplace partners to set prices for their apps based on a per-agent model, aligning with JSM pricing structures.
• Usage based pricing - This new option we are introducing allows Marketplace partners to establish an app’s price using metrics other than per user or per agent. Potential metrics for defining prices include output-based metrics, consumption metrics, or actions. Initially, only one metric can be utilized to set the price, but in the future, we may enable hybrid pricing based on two metrics. In this setup, all instance users can access the app, with charges based on the actual app usage by the customer.

Example of customer footprint in future state

In the provided example, the customer has acquired the Jira Cloud Enterprise edition for 13,000 unique users and operates 3 instances of Jira with 5,000, 8,000, and 5,000 users on each respective instance. Additionally, the customer has JSM Premium for 1,000 agents on instance 3. This configuration results in the following potential app footprint:

• App 1: This app offers multiple editions with instance-based licensing, tied to the total number of users as the parent product. The customer has opted for the standard edition under a multi-instance license, requiring payment for unique users across all 3 instances where the app is installed. Since the app utilizes instance-based licensing, the number of users aligns with Jira Enterprise, leading to a purchase for 13,000 users.
• App 2: Offering various editions with user-based licensing, this app involves a subset of users. The customer has procured a license for 10,000 users under a multi-instance setup and deployed the app on 2 instances.
• App 3: This app operates on user-based licensing. The customer has obtained the app for a single instance with 2,000 users.
• App 4: Priced according to a usage-based metric, this app provides multiple editions under a multi-instance license. By installing the app across all 3 instances, the customer will be charged based on usage across the entire network.
• App 5: This app is priced based on a usage metric. The customer has acquired the app for a single instance and will be invoiced according to the usage on that specific instance.
• App 6: Exclusively compatible with JSM, this app is priced per agent and offers multiple editions with instance-based licensing. The customer has purchased the app solely for JSM and will be charged for the total number of agents on JSM, amounting to 1,000 agents.
• App 7: Installed on instance 3 alongside Jira and JSM, this Jira app requires payment for the maximum number of users across both Jira and JSM on instance 3, totaling 5,000 users.

Proposed sequence

Feedback

We value your feedback on the suggested modifications and appreciate your reactions to these changes. For this RFC, we are particularly interested in hearing your thoughts on the following:

• What are the key advantages you anticipate for your business with the implementation of these new monetization features?
• What is your primary concern? How can Atlassian assist in addressing this concern?
• Are you open to collaborating with us as early adopters of certain licensing and pricing adjustments?

[UlrichKuhnhardtIzym1]

This is a great initiative, especially decoupling JSM agent count from overall user count!

On a side note: We observe that Bitbucket Cloud is becoming more popular among enterprises, even in regulated industries such as fintech and pharma/medical device tech.
There is NO commercial licensing available for BBCloud apps for both ACE or Forge platforms.
Customers and Solution Partners have to jump through additional hoops to integrate their BBC workspaces with BBC apps.
Is there any motion to support BBC app licensing in MP? What is Atlassian doing to close this gap?

[andreas.schmidt]

I really appreciate more pricing flexibility. This is a major missing gap and I think the analysis that this is slowing down app growth and adoption is spot on.

What are the key advantages you anticipate for your business with the implementation of these new monetization features?

Not a single aspect. I think it is an overall great direction that I can use the Atlassian marketplace with its billing capabilities to charge for my products and additional services like usage quotas.
Every option mentioned sounds useful!

Side note: an instance flat fee might also be an interesting option for some apps that is not bound to users at all.

What is your primary concern? How can Atlassian assist in addressing this concern?

My primary concern is that new and small apps will greatly benefit of the new pricings - but what about existing large apps? Change the overall licensing for a multi-million marketplace app seems risky. What will be the impact to change to JSM pricing? How do I find a new price?

I do not think I will gamble with the success of my app, if license changes needs to be all or nothing. I’d love to see options to test new licensing somehow, e.g. by offering the new licenses only to new customers. Or only in certain regions. Or allow multiple licensing options for an app.

However that is not really different to the current system: changing prices is incredible risky as there is no way to test it in a specific market segment.

Are you open to collaborating with us as early adopters of certain licensing and pricing adjustments?

Yes sure!

[attila.bordas]

What is not clear to me yet, and I hope you can clarify it is what aspects of these models/options are mutually exclusive, or the other way around, in how many different models, pricing, etc. can one application be distributed?
Can we configure our app with all of the licensing model (and different pricing)?

[marc]

My take is that these are too many pricing options. I think it would be beneficial if addon pricing mirrors the pricing options which Atlassian offers for their products.

However I think the option to base JSM on agents is really needed, as is an option to actually buy bitbucket addons through the marketplace.

[OstapZaishlyi]

Thank you for sharing your plans!

I may be an outlier here, but I have some concerns as a developer of larger apps with thousands of active paying customers.

From our experience before switching to Atlassian’s billing, we had a flexible licensing system. However, converting larger customers (e.g., even over 100 users) was much harder. Often, it took 2-3 months to convert a customer with 250-300 users, resulting in sales of only 20-30 licenses. This forced us to increase prices, which hindered growth among smaller companies with 30-50 users who wanted to use our tool for everyone. Predictable growth under that system was low, leading us to switch to Atlassian’s model, where companies pay for all users but benefit from progressive discounts and flexibility for those not ready to pay for all users immediately.

As Andreas pointed out, the proposed changes are unlikely to suit large, successful apps with thousands of paying customers, as such drastic shifts could severely impact their business. Smaller app vendors might be more willing to experiment with new pricing types, potentially causing confusion among customers as to why some apps have “flexible” pricing and others don’t.

Furthermore, these new pricing options could complicate expense tracking for customers. Even the provided screenshot illustrates how complex this could become. Customers would need to consider several factors:

• Whether the app is Standard or Advanced

• If pricing is flexible, and for how many users

• Whether billing is per user or usage metric, and how to track usage

• And more.

While Enterprise customers might appreciate this added flexibility, for SMB customers, it could be more of an overhead.

Finally, I disagree with the notion that these changes will increase overall Marketplace sales revenue. Perhaps for Enterprise customers, but for others, I doubt it. Our experience, and discussions with other large vendors, suggest that the percentage of prospects lost because they only need the app for a subset of users is minimal. Success depends on demonstrating the app’s value and pricing it correctly based on typical usage patterns.

I also like what Marc just mention with the pricing model for apps mirroring Atlassian pricing which is only logical in my opinion.

[craig.schwarze]

I can see the need for separating out JSM. And I can also see the need to give multi-instance customers a better option than buying a full license for each instance. If I understand the proposal, you will allow them to just total up the users and get a license based on that number. I think this is a fine solution.

However, I can’t see any benefit to us as a vendor to having the option of both “instance-based” and “usage-based” pricing. We have a large number of well-established customers, and we’ve adjusted our pricing over time to fit the “instance-based” model. Switching to “usage-based” would require us to massively increase the cost per user (probably) to maintain profitability.

Customers occasionally ask us about this, and we are able to explain how we’ve discounted our pricing to take this into account. Most seem happy with the explanation. All experienced Atlassian admins understand the system.

Now, granted this proposal will be optional, but I don’t look forward to having conversations with customers justifying the pricing model decisions. At the moment, it is simple and easy to understand. The new models will create some confusion. Imagine you are a customer comparing apps, and one uses instance-based pricing, another uses usage-based pricing based on active users, and yet another use usage-based pricing based on throughput. How do you compare these apps in terms of pricing?

Also, at the moment a client has a predictable bill based on their instance. With usage based pricing, they will presumably have different bills each month. Are we going to be having customers contact us with “bill shock” because someone used the app more often than usual this month?

It’s not clear what problem this is trying to solve. I suspect Atlassian has a use case in mind, but they are not willing to share it explicitly at this stage. I think we need you to give us some examples of where this could be of benefit to us as marketplace partners.

kind regards,
Craig

[BenRomberg]

Like @andreas.schmidt, I’m also wondering if it will be feasible to switch the pricing model for a large existing app. We either need multiple concurrent pricing models for a single app, or a way to test it out with a subset of customers.

Also wondering how it would work to completely switch existing customers to a new pricing model, e.g. usage based. Would they need to confirm the pricing model, or have an admin manually update the app? What if they don’t update, do they stay on the old pricing model?

[BenRomberg]

Regarding usage based pricing, will it be possible to have usage tiers, just like with user based pricing today? For example, if an app is cloning issues, we might want to have a different price per clone for cloning 10 issues than for cloning 10000 issues, it should not necessarily cost 1000 times (10000/10) as much.

[AaronMorris1]

@SarahAllen

• What are the key advantages you anticipate for your business with the implementation of these new monetization features?

For usage-based pricing: The ability to base usage on the number of Jira projects where an app is “activated” or “enabled” could be beneficial. (Even if it’s implemented through a custom-usage tracking feature, where the app developer is responsible for tracking it.)

This could make it easier to sell specialized apps in larger Jira instances. Much like the challenge of selling JSM apps.

@SarahAllen

• What is your primary concern? How can Atlassian assist in addressing this concern?

I’m concerned about how complex billing might become from a customer perspective. First, customers will want to estimate an app’s cost before and during the evaluation phase. (The Marketplace currently provides this estimation.)

And later, they’ll need to understand the breakdown of their bill.

But as long as Atlassian tracks this usability, I’m sure it will turn out fine.

[Wizmur]

Thanks for sharing!
My primary concern is how to approach a scenario, where we have a big company having an instance of let’s say 10,000 users. They need an app for just a few teams, let’s say 100 users.
As a big enterprise, they have corresponding expectations - long decision process requiring plenty of calls, procurement process, premium support, security checks and so on.
In our current case the fact that they need to buy the app for the whole instances reflects the need to spend more time on an Enterprise customer. If now, the Enterprise customer would like to pay for the real users keeping the benefits of an Enterprise one it can be a challenge. They would pay as a small company, demanding an Enterprise treatment - it would be good to be able to offer then Premium Support packages, and other ones on top of the license fee

[Prabhu_Palanisamy]

@SarahAllen

• What are the key advantages you anticipate for your business with the implementation of these new monetization features?

Our apps are used primarily by HR users. Typically its not required for the entire instance. Having flexibility to price based on Usage and Agent based will be valuable to us.

@SarahAllen

What is your primary concern? How can Atlassian assist in addressing this concern?these new monetization features?

This will make billing complex. Once this takes effect, license cost will be drastically different e.g our license cost starts at $1.5/user considering for the entire organization. When we price for subset of users we may increase the price significantly e.g if customers wants for only 10 users. How would existing customers perceive the change? Is there a way to A/B test to get customer feedback?

@SarahAllen

• Are you open to collaborating with us as early adopters of certain licensing and pricing adjustments?

Absolutely, this is something all our customers are asking for. Please sign us up.

[MattDoar]

I am concerned that these changes will add another level of complexity to Atlassian licensing, and that the complexity will overwhelm some potential customers (and some vendors too). Have you considered having a tool in the website to allow potential customers to select products and then guide them with choices and costs? Unless there is a desire to have more in-person contact with potential customers, which is one approach to monetization.
My thoughts, not my employer

[BorisBerenberg]

I am not aware of ever losing a deal over instance vs actual user pricing
Yes we do sometimes lose opportunities over price, but the goal isn’t for everyone to afford the app, the goal is to run a profitable business
Having an offering for enterprise customers with multiple sites does seem beneficial to me
Being able to offer usage pricing on top of a base price does make sense to me

Assuming this goes live as is described here, I would guess that:

• Market leading apps will stick with existing pricing models
• Competitors who have no product differentiation will offer cheaper per seat apps
• The marketplace will strike some middle ground equilibrium
• Marketplace vendors will have to spend significantly more time (money) arguing with customers why a given app isn’t on a given pricing model the customer wants
• Solution partners will have to spend significantly more time (money) explaining why a bill is the way it is.
• Time for deals to close will increase due to the two above points
• The rate of revenue growth and net profits will drop for vendors

This may all be beneficial in scenarios with larger customers who are price sensitive as making pricing more confusing has consistently been demonstrated to reduce customer price sensitivity as they can’t compare apples to apples.

[tbinna]

I am not convinced that all this is such a good idea. This RFC has some good elements, like multi-instance licensing, that make sense and are easy to understand.
I would have preferred a more nuanced approach. Packaging/app editions and multi-instance licensing alone would have been a good start.

I have always appreciated Atlassian’s straightforward, easy-to-understand pricing structure. Please don’t give up on that. I do not think it helps anyone other than the extra sales engineers we have to hire.

Our primary concern is explaining this to the customer and arguments about pricing. App pricing across the Marketplace will become much more opaque, less comparable, and challenging to understand.

While the main point of this RFC aims to address customer needs with “better” packaging/pricing solutions, I am not convinced all of what’s suggested will do the job (again, some elements are good):

• It will be much more difficult for customers to understand pricing
  → More time and $ spent on explaining pricing (today, this is close to $0 for us). It’s the same everywhere, and everyone understands it
• Marketplace partners do not want to make less money
  → stick to the existing model, or re-package it to make at least the same (additional $ spent explaining this to the customer, so maybe just stick with option 1)

[nathanwaters]

The Paradox of Choice.

[rlander]

One of the primary customer drivers is a perception that they should pay less for an app if a subset of users in an instance use the app. This is rational, however Atlassian’s pricing model never accounted for this.

Customers will push vendors for per-user pricing, but the only sensible way to do this as an established business is to jack up the pricing such that revenue remains mostly constant. This is not the outcome customers expect, they expect things to get cheaper.

Atlassian can say this is an opt-in for vendors, but customer demand will grow and push some vendors to adopt new licensing options.

Per agent pricing is a welcome addition, some vendors have been offering this outside of marketplace for a while.

Usage based pricing makes sense for a cohort of apps, but the usefulness will depend on the details of how this is implemented. For example could an app have a per-user price, with some included usage allowance, then bill for overage?

I think Atlassian should strongly consider the customer experience here, if customers are expecting one thing and then the marketplace ecosystem does the opposite (pricing remains constant or increases) there is going to be a lot of upset pushed on to app vendors.

Of course this leaves room for new players to differentiate with competitive licensing options.

[scott.dudley]

With the mandatory support of multi-instance licensing, can Atlassian please provide more clarity on what this “alternative pricing” model would look like? For example, will we simply populate a parallel set of values for the $/user price tiers that will apply to multi-instance licenses?

Also, can Atlassian commit to providing sufficient data to vendors that will allow us to calculate the expected pricing impact?

I understand that Atlassian is understandably trying to solve a pain point for customers, but from a vendor perspective, we want to ensure that being forcefully moved to a new pricing model does not have a material adverse impact on revenue.

To do that, we need more data than we currently have. What each vendor needs (before being forced to set prices for the new pricing model) is a personalized report showing a correlation between current app licenses and the underlying “master unique users” license of the host product, with the corresponding tiers.

For example:

App license E-1000 500 users → Host license E-9999 10,000 unique users
App license E-1001 250 users → Host license E-9999 10,000 unique users
App license E-1002 1,000 users → Host license E-9999 10,000 unique users

App license E-2001 700 users → Host license E-8888 5,000 unique users
App license E-2001 1000 users → Host license E-8888 5,000 unique users

There is a wide variety of customers using these types of site licenses. Some customers have 1-2 instances and other customers have 50 instances. Calculating a net-neutral pricing strategy for the ensemble of customers is not possible absent the above information.

[marc]

After thinking more about per user pricing, I think this will have significant impact on usability and will add much confusion.
Imagine part of the user have access to Confluence Cloud Standard, and some users have access to Premium. These users have different features, and it will be hard to explain that one user can do certain things, whereas another user can’t do these. Multiply this by the number of addons, and confusion will come.

[Chris_at_DigitalRose]

As with many of the replies above, it is unclear to us why Atlassian is proposing to so substantially change the licensing model and DIVERGE so much from the established and simple standard.

The standard is that app user licenses match the number of licenses for the instance. That is simple and consistent with the Atlassian model. As @marc said above, Atlassian doesn’t allow a mix of standard and premium users in the core products, so why should the apps?

We urge you to reconsider; please do not add “subset” user based licensing.

Regards
Chris C
Digital Rose

PS. If you do want to fix something that will actually improve the customer experience, allow them to uninstall trial licenses immediately. We continue to receive support requests and negative reviews from customers believing we as the vendor are preventing uninstall.