RFC-60: Marketplace Monetization Strategies

General Request for Comments (RFC)
,
21

Thanks for publishing the RFC @SarahAllen, great to have a broader conversation around this before too many decisions are made (thinking about one-way vs two-way door decisions).

Before we get in to Easy Agile’s current thinking here are a few items I believe are worth clarifying for the Marketplace Partner audience just so we’re on the same page:

  • Is ‘site based’ and ‘multi-instance’ used interchangeably? i.e. are sites = instances in this RFC?
  • Shall we standardise on ‘subscriptions’ and drop ‘license’? License feels like a hangover from Server days.
  • The USD1bn Marketplace GMV cited is total (i.e. Server, DC, Cloud). Are you able to share Cloud GMV for context?
  • Is it possible to get a diagram showing what combinations of subscription and pricing are possible? As a few folks have noted it is complicated, and if we are struggling to understand how will Atlassian present this to customers?
  • Should ‘multi-instance licensing’ be called ‘Organisation wide subscription’ to align with the language Atlassian Admin uses (i.e. Organisation/Site/Product)?

Here is Easy Agile’s current thinking on the RFC itself:

  1. This is a massive change to the whole operating model of the Atlassian Marketplace.
  • How do we model this?
  • How is Atlassian modelling this?
  • Essentially, how is this NOT revenue negative in the short term and how do Marketplace Partners bridge the gap?
  1. Customers will not benefit from lower costs as:
  • decoupling adds complexity to the sales cycle and ongoing application user and usage management,
  • if customers want Marketplace Partners to meet the demands of ISO27k, SOC 2, custom legals, etc then they must pay an Enterprise price,
  • Marketplace Partners can not sustain a decimation in their revenue, so will have to increase the per user pricing to make up the shortfall, or otherwise we’ll go out of business and that will leave the customer without any solution, and
  • as a result this leads to more complexity for customers, and they will ultimately pay around the same as they do today.
  1. This will add a significant administration burden for customers with multiple apps:
  • Admins currently do not have to choose who has access to an app.
  • Assuming they don’t set and forget this becomes an ongoing job increasing hours spent on non value add tasks for them.
  • With every app having a different way of administering users this impact will be multiplied.
  • In large complex organisations this could amount to a cost increase beyond anything they would potentially save. Not to mention the headache with the new complexity.

  1. Solution Partners are currently trying to get up to speed on selling solutions, and this is just yet another distraction on the journey towards more solution selling in the Marketplace.

  2. Putting in place mechanisms for these options in our own accounting and business management systems is non-trivial, all of our dashboards and historical business metrics would suddenly become harder to draw trends and insight from. That would leave many of us blind to what is occurring and slow decision making.

At Easy Agile we believe every member of a Product & Engineering group will get value from the Easy Agile product suite, and as an agile solution we believe visibility and transparency brings the best outcomes and leads to the most effective communication and alignment across a company. For this reason I believe we would continue to couple the Easy Agile user tier with the Jira user tier.

Easy Agile believes Atlassian needs to consider an option 4 - status quo - and focus energy on educating customers on the value prop that exists with Apps today, and avoiding adding a ton of complexity to sales during a difficult phase of the macroeconomic cycle.

Thank you Atlassian, and thank you Marketplace Partners for your thoughtful insight as well.

Regards,
Nick Muldoon, CEO, Easy Agile

30 Likes
22

Well put, Nick

23

The proposal will require partners to develop and implement monetization strategies which are completely different from what they have had for years. The proposed tiers are new for many of us, and we will have to try, error and correct fast, depending on the reaction of customers to the proposed pricing. In order for this to be possible, we will need from the immediate start the reports available on the Atlassian Marketplace partner page to be extended in such a way that we can see sales and evaluations per licensing, per packaging and per pricing type.

I would like to stress a point: such monitoring features will need to be there from the very beginning. If the new Marketplace monetization strategies were launched without such visibility into the commercial data, it is likely that some partners will not be able to correct their initially imperfect pricing stance early enough, and this may damage irretrievably their products.

7 Likes
24

Will limits be imposed on pricing? For example, can the price be $1 per site user, or $5000 per agent as is usually the case in requirement management software?

Atlassian has often imposed limits, such as Cloud-vs-DC pricing, minimum per-user pricing, etc.

1 Like
25

Thank you for sharing the details of the proposed app monetisation changes. While we appreciate the added flexibility these changes offer to customers, we are concerned about the increased complexity they introduce. The various pricing models and permutations in a complex customer landscape will require extensive explanation and may confuse customers.

For ScriptRunner, most of the proposed changes appear manageable, provided they remain optional as suggested. However, we foresee potential challenges with the user-based pricing model. For apps designed for Jira/Confluence end-users, a per-user pricing model is logical. However, for apps like ScriptRunner, which are intended for Jira/Confluence administrators, this model poses significant challenges.

Although only a small number of users (administrators) interact with the app directly, the automations and customisations they enable benefit all users of the Atlassian product. A per-user pricing model does not accurately reflect the value these apps provide to the entire user base, even if not all users interact with them directly.

Moreover, this approach is susceptible to misuse in the case of admin apps, where companies might license the app for a single, shared administration account utilised by multiple users. To reflect the value these apps deliver to the entire user base and maintain viable revenue for developers, each seat would likely need to be priced very high. This introduces new friction and messaging challenges, as it becomes difficult to explain to customers why admin apps have a significantly higher per-user cost compared to end-user apps.

Lastly, while adopting these new pricing models is not currently mandatory, vendors may find themselves with no other choice but to adopt them due to future market pressures, with significant impact on app revenue and business viability.

Thank you for considering our feedback.

7 Likes
26

Hi @SarahAllen / @ibuchanan,

Considering that this topic might contain sensitive information about running your business on the Atlassian Marketplace, I think a lot of partners would feel more comfortable discussing this more openly if the RFC was moved to a private channel that falls under NDA.

I understand that traditionally RFCs are meant to be available to the wider Atlassian Developer Community, but I feel that this RFC is specifically targeting Marketplace Partners that wish to monetise their apps on the Atlassian Marketplace. As such, full transparency might not be a requirement here.

There is a great category in which this discussion would fit right in:
https://community.developer.atlassian.com/c/marketplace/running-your-business

Alternatively, it would also be an option to add an additional category for RFC’s that are considered confidential.

For those marketplace partners that do not have access to this category, you can request it here: Jira Service Management

Looking forward to hearing your thoughts.

Cheers,

Remie

3 Likes
27

@remie,

With 20+ comments already, I don’t see a reason to move this RFC or to change its permissions. Across the extensibility standards I’ve helped build, we have made an explicit choice to keep consistent practices for the sake of simplicity. DX is not staffed to support case by case variations.

That said, I do understand why this is a special case. I believe that @SarahAllen and the Marketplace team are motivated to hear feedback, without having to be constrained by rigid rules. I’ll discuss with @SarahAllen to have her start a “side bar” channel. In general, I think RFCs have some “form” here in the community forums, but feedback is welcome through other channels, as long as it reaches the right people.

28

Hi @SarahAllen,
Thank you for the RFC and letting us peek into Atlassian’s thinking here.

As others have already said, separating JSM sounds like a great idea. Also, having paid app options for Compass and Bitbucket would be very welcome.

The current model is pretty easy to understand and while some customers do not look like it (“Why do I have to pay for X users if only Y admins use the app?”), it’s pretty predictable. But as far as all the other options are concerned, I have mixed feelings. Flexibility is generally good, but having too many options is going to be a nightmare for vendors, solution partners and customers. I’m just thinking of how any Solution Partner is going to create a quote that has multiple apps with different pricing models, especially when (as I understand it) apps will be able to offer multiple pricing options.

There is also one pricing model that especially did pique my interest and that’s usage based pricing. Of course, this type of pricing does away with all the predictability that customers enjoyed so far.
But if an app ran on a pay-per-use platform – something like AWS Lambda or maybe based on that – a vendor would be extremely tempted to use a pricing model that scales with the costs of that underlying platform.

2 Likes
29

@ibuchanan thank you for considering a separate, more private thread.

Please note that my comment was triggered because of concerns raised by multiple vendors in separate communications channels. I’m simply making those concerns public.

With regard to the number of comments: yes, of course this is getting traction as this is an important topic for vendors. But it is not the quantity of the comments that should count for (any) RFC, but the quality. If vendors are holding back because they do not want to discuss their pricing strategy in public, we will end up with a sub-optimal solution.

Finally: although I’m not a securities lawyer, it feels odd to be publicly discussing pricing strategies between competitors in a marketplace.

2 Likes
31

Adding my thoughts to the conversation.

First off, it’s great to see this area getting some well-deserved attention.

The introduction of advanced tiers, multi-instance licensing, usage-based, and agent-specific pricing are solid steps that I believe will really benefit customers, vendors, and solution partners alike.

That said, the shift to user-based licensing feels like it could bring some challenges. Since the marketplace has always been centered around instance-based pricing, this is a pretty big change.

I’m guessing part of the reason behind this move is the combination of Jira Work Management and Jira Software. From a customer’s perspective, it might feel off to pay for an app that primarily benefits engineering teams when legal or HR teams are also being charged under a per-user model.

Here are a couple of challenges I see:

Friction

It’s not entirely clear who will be responsible for managing access to user-based licensed apps. If this falls on administrators, it could add a lot of friction and administrative overhead, which might end up discouraging adoption. While solutions like spending limits exist, multiplying that complexity across multiple apps could have a real impact on usage and adoption.

Optionality

Even though it’s positioned as optional, in reality, customers are likely going to push for user-based pricing. They’ll naturally gravitate toward only paying for the people who actually use the app, which might create challenges for larger vendors. A pricing shift of this scale could have a significant impact on their business, especially without an easy way to test different pricing models.

Optics

Another thing to consider is how pricing might look to customers. For some apps, the cost could jump to $30 or more per user. When that gets compared to the price of Jira itself (even if the user counts don’t match up), it might create some hesitation around app adoption. Customers could start questioning why they’re paying more for an app than the platform itself, which could slow down overall adoption.

4 Likes
32

Thanks for sharing this and updating us on your plans. I had a few discussions with different internal teams about this RFC and would like to share our perspective:

  • we like the idea of multi-instance licensing, it will be useful for enterprise customers
  • JSM decoupled from Jira makes sense, together with a per agent pricing for JSM
  • per user pricing - while we do have customers ask for that, none of our teams recall a situation where they lost a customer over user-based vs instance-based pricing. Even for niche products, we could always work out a solution with our customers. Changing to this model would require a massive overhaul of everyone’s pricing structure, especially for established products
  • Would per user pricing change the app evaluation experience for customers? Could individual users trial apps and purchase them for just a single team or part of the company instead of the admin?
  • Have in mind that usage based pricing will complicate the purchasing process for customers and solution partners. It will lead to an unforeseeable amount of additional administrative work for all license teams, as now all customers could receive additional monthly invoices for xx amount of additional workflows and checklists billed at 0.03 USD
  • Adding on to the previous point: the selling process will already get more complicated for Solution Partners with the new packaging options; partners will need to know or look up with how many workflows* (*or any other usage-based feature) an app comes that now offer standard and advanced pricing and compare it with apps not using the different packaging plans but usage based pricing and ones that do both. The Marketplace will become less transparent and it will be harder to compare apps for customers.

Thanks for taking our feedback into account!

4 Likes
33

Who from Atlassian is going to respond on this thread?
It’s been 12 days with no response, and it looks like SaraAllen is no longer a user on this forum? (At least the account is suspended)

1 Like
34

I will ask around to find a replacement.