RFC-68 Action Items in Jira - Checklist Apps Ecosystem Impact

General Request for Comments (RFC)
,
1

Summary of Project:

We are running an experiment to introduce Action items in Jira’s issue view similar to Action items in Confluence and Jira Product Discovery. This new functionality allows users to manage simple tasks without relying on subtasks or the issue hierarchy, making Jira more accessible for ad-hoc work.

We understand there is a large number of Checklist Apps that could be impacted by this change. We want to be transparent and open in our communication.

  • Publish: 15th October 2024
  • Discuss: 25th of October 2024
  • Resolve: 1st of November 2024

Problem

Users need a way to manage simple tasks within issues without using the admin of issue create flow or the restrictions of the issue hierarchy, as they do not want to create and manage separate tickets for every small task.

We understand that this change could have an impact on our broader ecosystem, especially for those of you who have developed Checklist Apps that provide similar functionalities. Our goal with this communication is to ensure transparency, foster an open dialogue, and work together to manage any potential challenges that may arise from this new development.

Proposed Solution

We will be bringing this checklist functionality to Jira. This new feature will allow users to manage simple tasks in a more seamless manner without needing to rely on subtasks or navigate the complexities of Jira’s issue hierarchy. Our ultimate goal is to enhance the accessibility of Jira for managing ad-hoc work, making it easier for users to stay organized with minimal friction.

The functionality of the feature is:

  • Users can create an Action item by “/ action Item” in any rich text field (description, comment, long text fields etc)
  • Users can create an Action item by “ ”
  • Action items are present in the description and comment fields

b9ff640b-de90-4355-809d-ac7ca2955e91
b9ff640b-de90-4355-809d-ac7ca2955e911126×494 36.9 KB

Future Enhancements

While our first milestone focuses on introducing basic checkbox functionality, we envision building upon this feature in the future to include:

  • Task Lists: Aggregate Action Items per user, providing a centralised view of all Action Items, similar to the Task List feature in Confluence.
  • Due Dates and Reminders: Allow users to assign due dates and set reminders for their Action Items.
  • Action Item Templates: Pre-built templates for common or repetitive tasks, streamlining the process even further.

Impact

Ecosystem Impact:

We recognise that a number of vendors have developed Checklist Apps that add significant value to Jira’s ecosystem, helping users manage their workflows effectively. While our goal with this new feature is to address common pain points for our users, we are committed to ensuring that we don’t unintentionally disrupt the value that your apps provide.

We are commited to being fully transparent throughout this process. We invite you to participate in an open discussion about this feature on October 10th, 2024, where we’ll provide more detailed information and answer any questions you may have.

2 Likes
2

This specific RFC doesn’t impact us, but if Atlassian continues down this path, where should the funding for us to build new solutions come from?

Should we start cloning Premium and Enterprise features and undercutting Atlassian pricing as Atlassian is doing to vendors?

Edit: Given that Atlassian is competing directly and intentionally with vendors, and has been accelerating their cannibalisation initiatives, I wouldn’t be surprised if European vendors start calling for the European Commission to designated Atlassian a Gatekeeper under DMA. The EC even have a handy FAQ on the topic for people in the vendors position:

Google Chrome 2024-10-15 at 14.58.20@2x
Google Chrome 2024-10-15 at 14.58.20@2x1596×332 48.1 KB

47 Likes
3

Indeed, it’s a little bit hard to conceive that you won’t “unintentionally disrupt” other apps. I don’t think that you will disrupt but instead kill many apps while severely impacting others, and consequently Atlassian will also lose revenues from this.

There are many apps that offer either a free version or free tier, so is there actually a strong need for this? Many years ago, Atlassian clearly stated to its Server/DC customers that it wouldn’t implement a better checklist because third party apps were offering this service. Why changing now?

I could understand that Jira’s competing products have better checklist capability and that you want to minimally improve what you offer. But you don’t want to limit this to simply having action items in rich text field, you want to improve it with: Task lists, Due Dates, Reminders, and templates. If you do these future enhancements, you are actually offering what customers want from our apps.

Keep the Checklist to a bare minimum (in Rich Text field) but leave the more attracting features for your Marketplace Partners! We have spent years developing these products and building businesses around this on the premise that you would not develop this feature.

22 Likes
4

I’ll provide honest feedback on this topic, even though we are not directly impacted.

I think Atlassian has recently been heading in an unfortunate direction by “taking inspiration” from what works in the marketplace and introducing it as a native feature in Jira/Confluence.

This is just the latest in a series of announcements over the past few months, during which several features have been released, affecting different segments of the marketplace.

Some examples:

This direction will become a problem because it will drastically reduce investments in the marketplace. Who would invest time and resources knowing that Atlassian could add similar features to their product, effectively undermining all your efforts?

In my opinion, the biggest issue is not so much that Atlassian “takes inspiration” and releases new features similar to those developed by third-party vendors but the unfair competition that results. Atlassian has access to data, resources, and contacts that a third-party vendor cannot obtain.
Furthermore, what’s even more problematic is the native integration of features that third parties cannot achieve due to numerous limitations on APIs and available extension points.

These limitations make it impossible to compete on a level playing field, as first-party features will always be superior to third-party ones. This leads to ongoing friction with customers who don’t understand why certain features cannot be delivered.

If Atlassian wants to continue in this direction, the only solution that could save the marketplace is providing vendors with the same APIs that Atlassian uses for its products. This way, truly integrated features can be created on par with those developed by Atlassian, fostering an ecosystem of fair competition.

I’ll close with a provocation: why does Atlassian continue to invest so many resources in developing unfairly competitive features while doing so little to address the thousands of open reports on ECO? There are issues that have been open for decades, features that vendors have been requesting for years, and bugs that are often reclassified as “suggestions” so they can be ignored indefinitely. If the goal is to build a fair ecosystem, that’s where it should start.

42 Likes
5

@AhmudAuleear

we are committed to ensuring that we don’t unintentionally disrupt the value that your apps provide

With the features you mentioned, you are going to cover at least 60% of use cases, that our customers use most frequently.
You will not only disrupt the value of our app, but you will also shrink our business by half or more and put it at the verge of extinction.

We’ve been trying to reach out Atlassian PM responsibile for this change for weeks (through our TPM) but it turned to be impossible. Do you reallly want to get a feedback or you just post information here to satisfy internal procedures?

Simple checkbox in rich text fields in Jira (just like in Confluence) is one thing. But most of the features you mention in Enhancements section don’t exist in Confluence or JPD. If you go this road, you will change the relations between vendors and Atlassian for good by telling the world that you can intentionally kill any app by implementing its functionality directly in your products.

There are several highly voted feature requests for Jira that cannot be implemented by apps. If you put effort there rather than cloning apps’ functionality, both Atlassian and vendor businesses will thank you (as well as customers).
Example: https://jira.atlassian.com/browse/JRACLOUD-9091

26 Likes
6

Maybe don’t hot-link into an internal system for your screenshot, so non-Atlassians can see what it looks like too.

Am I surprised about this? No.

It’s just the big dog killing the competitor’s puppies. It’s in it’s nature.

4 Likes
7

Hello @AhmudAuleear,

  1. What is the current status of this project? Have you already started development?
  2. Before initiating this project, did you conduct an assessment of the apps available in the Atlassian Marketplace that already address this need? If so, what were your findings?
  3. What are the rationales behind the decision to bring this feature natively, given that the need appears to be covered by existing apps?
19 Likes
8

I assume you mean November 10th?

2 Likes
9

Will this checklist feature available on all subscription levels, or only on Premium and Enterprise like almost everything nowadays?
In the latter case the impact could be smaller for the vendors with existing checklist apps.

3 Likes
10

This is no the first instance of Atlassian implementing a feature natively that was previously delivered only by apps. Is it quantitively proven that this effectively shrunk any businesses (except those who raised a white flag)?

2 Likes
11

Installs-wise - yes, the impact can be smaller.
Money-wise - no, Enterprise business is the main revenue generator for Marketplace Vendors.

4 Likes
12

Sad to see Atlassian destroying businesses of Vendors after years of successful collaboration where apps complemented the product functionality and worked together. All time and investments seem wasted. Why Vendors would share any new ideas with Atlassian being under the risk of getting cannibalized in the future?

13 Likes
13

“Only for the time it serves you” should be added I think.

I had the same experience in early 2019 when Atlassian reached out that they wanted to implement there own Jenkins integration app. The PM at the time did have the decency to reach out and we talked multiple times, now the two apps could co-exist and how there app would be unsupported and customers could move to me to get support.

In the end it was an empty promise. Atlassian is fully supporting the app, and also making sure its more prominent in Jira then my app will ever be allowed to be. And every time I reached out to the PM to continue the discussion or get help on Compass and Forge, my mails where not responded on.

In the end I was lucky that Atlassian messed up a couple of times in their app that allowed me to keep about half of my customers. My install count on the marketplace dropped from 3000+ pre Atlassian app to 1600+ now.

So in the end it worked out for me being able to keep my app successful and I was able to find some Atlassians that keep to their word and where able to help me out with Compass and Forge.

But in this case I read it like Atlassian is not just taking inspiration and only taking on part of the app like they did with me, but instead taking on inspiration and becoming a full competitor of the existing apps. And in this case, no matter how good the existing app is going to be, Atlassian will have a leg up because they can place the app within the products for marketing and ease of getting started with them.

Please Atlassian Please do not rip the great out of this ecosystem and keep to your core so partners can also exist and have joy.

17 Likes
14

I’ll cut straight to it — your new checklist feature in Jira is a direct hit to our checklist app and others like it. We’ve built a solution that helps users manage tasks without creating a mess of subtasks, and now you’re releasing something that replicates a large portion of what we do. To be blunt, this move will hurt our business and others in the marketplace.

We’ve seen it coming for a while — Atlassian gradually rolling out features that overlap with marketplace apps. And now, with these checklist enhancements, it’s clear you’re not just solving user problems; you’re making vendors like us wonder why we should keep investing in your ecosystem at all. We’ve poured resources into building a solid product that’s valued by customers. But with one update, that value can be taken away.

Let’s not dance around the issue — vendors like us play a huge part in making Atlassian what it is. But if you’re going to keep pushing native features that mimic marketplace apps, the message is clear: Atlassian doesn’t care about the marketplace thriving, just its own growth. How is that a fair partnership?

Here’s the thing: we’re not against progress. But instead of reinventing what’s already being done, why not fix the gaps that are reported on ECO? That’s where your focus should be. Leave the solutions we’re building for customers alone — collaborate with us, don’t compete against us.

We want to keep contributing to Atlassian’s ecosystem, but this checklist feature is a warning shot, and we can’t just sit back quietly.

20 Likes
15

In my opinion, a basic checklist (in rich text fields) is what is really needed in Jira natively.

You could implement this without much affecting partners that have built advanced features (which would complicate the core checklist feature and took years for partners to get the advanced features right).

In fact, this feature is already available in Confluence and you could simply reuse it and have it available in Jira. Therefore, I would highly recommend limiting this to basic checklist like Confluence tasks.

8 Likes
16

I also think that a basic checklist would be sufficient for the simple use cases. No need to overcomplicate the basic Jira - there are already so many icons, buttons and options.

5 Likes
17

There should - at very least - be a clear and fair process to follow when Jira is natively adding functionality (at the same level) that is now provided by an app. So vendors know what we are up to. A fair process would foresee a buy-out offer with a simple multiplier on the ARR in exchange for existing customers and code. You can then include it in your business case.

Simply copy-pasting functionality from vendors is an abuse where you let

  • vendors take the risk and pay sweat money,
  • then copy well-functioning apps putting their apps out of business
16 Likes
18

Another example: Jira is now implementing the Program Board in the exact same way as partners are already providing it:

7 Likes
19

I understand that built-in checklists is a feature that many Jira customers expect out of box. And that there’s product rationale to implement it. But you guys have other stakeholders besides the end users, and deprioritizing marketplace vendors in such a manner puts our collaboration under many risks. Such moves are also very confusing strategy-wise. On the one hand you are motivating us to be aligned with your strategy, e.g. following the System of Work and complementing it, or being aligned with the idea of attracting more business teams into Jira. And we do our best to be on the same page and promote your concepts. On the other hand you make these moves that put our very existence at risk. This kills the trust that both your and our teams worked hard to establish. We are not sure now to which extent we should continue investing into our Atlassian products, e.g. should we stop migration to Forge? Should we launch a new app in the first place? I would appreciate an elaborated statement on the strategy of collaboration with the vendors.

13 Likes
20

Does this mean that this particular disruption is intentional by Atlassian? Why not instead improve some existing features with drawbacks that partners are unable to compensate for due to lacking APIs, rather than Sherlocking problems that have been solved by partners?

13 Likes