Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Is Jira One Product Or Several?

Haddon Fisher
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
Oct 11, 2023

Question for y'all:

Do you consider Jira to be a single product with different "flavors" of projects to support different types of teams, or a set of distinct products which share a common (for lack of a better term) platform?

Why I am asking this somewhat pedantic question? Glad you asked (and sorry for how long this is about to be):

Since the end-of-life announcement for Server, I have noticed a dramatic uptick in feature development for Jira Cloud. However it feels like a majority of those new features are restricted by project type despite having pretty universal applicability. In a bunch of cases, it seems like more work to bake them into a particular project type than it would be to simply do it for all of them.

Off the top of my head, a list of big ones that have been rolled out this way might include:

  • The "forms" functionality, which was originally released only for Service Management projects; it since has been extended to Work Management, but is still absent in Software projects.
  • The baked-into-workflow "Approvals" logic, which is restricted to Service Management projects.
  • Kanban boards, which for WM and SM projects are severely deficient feature-wise compared to their SW cousin. While it is possible to use SW boards on non-SW projects, they have been slowly making this less and less friendly and I expect to lose this ability entirely at some point in the not-to-distant future.
  • Custom domains; while there is finally some movement on the venerable CLOUD-6999, it is initially only for SM projects. On the ticket they indicate that they are currently planning on bringing this to SW as well, but I see no mention of WM.

I've also noticed over the years a small but noticeable divergence in user interface and experience as well. The biggest is around WM, which recently switched the project navigation bar from the left rail to a horizontal mid-screen, but WM projects also include 'calendar', 'list' and 'timeline' displays not available in SW or SM.

Recently, I started playing around with Jira Product Discovery and was immediately surprised by the custom field interface and "views". These are concepts that exist in Jira already, but JPD has come up with entirely new UX patterns to address them.

I submitted some feedback about it and ended up getting into a conversation with someone over in Atlassian's JPD Product group. In that conversation, they said:

Building a new product, we’ve tried to cherry pick specific parts of Jira to bring across to JPD and generally speaking customers have been happy with the differences, I appreciate that it has created a steeper learning curve for you as you get started with the product.

I've been lucky enough to be able to speak with a bunch of Atlassian folks over the years, and a lot of them have said variations of the same thing, namely:

These are different products, and so you should expect them to have distinct feature-sets and engage with them differently.

The issue I have is that, aside from Atlassian's assertions, I've never really seen any evidence to back this up:

  • In the beginning, Jira was a single product. The key features of both Software (the Agile board) and Service Management (the customer portal) originally started out as add-ons to this Jira, and the entire concept of project "type" is not that old.
  • I can't say I've ever encountered many end users who understood that there were differences between projects, let alone what the differences were. In my current environment we have a lot of team-managed JSM projects because, back when users were allowed to make their own projects, the only thing they were thinking about was the customer portal.
    • I mentioned above the WM switch to a horizontal navigation par; I actually did not see this initially, and someone brought it to my attention because they jump between SW and WM frequently and found the difference jarring.
  • From the perspective of someone who has to administer an instance with all three, all it seems to do is make my life harder by forcing me to remember which features exist for what project types and whether their particular implementation of it is worth using.
  • While there are some UX\UI differences as I mentioned above, the majority of the look\feel\experience is the same, so there's very little to indicate that these are supposed to be different experiences. This is in addition to the fact that all projects live "within" the overarching Jira UI, which also includes features that naturally span projects (like search or dashboards).
  • I've been doing some version of "Jira Solutions Architecting" for a while now, including a stint as an actual contractor, so I've seen a wild variety of use-cases for Jira. I cannot think of a time when I've not come up with a reason to use some feature in project type A that only exists in project type B or C.

However Atlassian keeps on doing this and when I ask why they say "everyone seems to be OK with it" so at this point I'm genuinely wondering if I am the crazy person here who just needs to get with the times.

Is anyone else frustrated by this or should I start testing out straightjackets?



Log in or Sign up to comment

similarly, I'm confused with say something like company managed v team managed projects, these definitely seem to be separate products with different features which can be frustrating, so I stopped using team managed altogether.

It seems like it would have been easier to have a single project platform with the advanced functionality in company projects, and then restrict features by authorisation levels (admin v user) than force different development paths for what are basically simple v advanced projects functionality.

Likely a symptom of legacy features and organic growth I guess which leaves us scratching our heads sometimes... 

Like # people like this

This one's easier, team managed projects are built on updated architecture, and company managed projects are slowly being moved to the new architecture. Though I agree, until this year team managed projects were so limited I would not recommend them. They're really starting to merge functionality, I wouldn't be surprised if the distinction goes away again. But when they came out the functionality was really limited, specifically because everything was being rebuilt.

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
Oct 11, 2023

The Jira product suite is a set of five things now, and it has been going that way since Jira 6.0 was released (Spring of 2013 if my memory is working for a change).  At that time, it was only two products, but a third one arrived in the autumn of 2013 and with Jira 7, it got explicitly built that way with the introduction of different project types defined by the (then three) products.  It's now five products because Atlassian have taken out Jira Work Management as a separate product, to be bought in the same way as the other three.  

The products are now effectively

  • The Jira platform (which you need to run any of the other four, and is automatically included with the first one of the other four you get)
  • Jira Work Management, previously Jira Core, and it used to be included automatically if you subscribed to one of the other three
  • Jira Software
  • Jira Service Management
  • Jira Product Discovery

Each one of these works differently because their projects are intended for different purposes.  Yes, it can be overwhelming, as an admin, but one thing I've always said about Jira is "admin is complex for Jira because there's just so much you can use it for"

You're right in that Jira was originally a single product.  It was an issue tracker, focussed on what most of us would guess software developers would work (mostly in unproductive waterfall projects).  But Atlassian found it being used for all sorts of other things - it was flexible enough to support some Agile ways of working, do helpdesk type stuff, and organise all sorts of other things that you wouldn't recognise as development.  

I was one of the people asking Atlassian to add functions that could support Agile processes, and give me SLAs for projects used for support.

I actually rather appreciate having the different products work very differently - the obvious example is that my Agile teams don't need SLAs, and my support people have no use for sprints  So using the right project type for the right purpose is good - it reduces the complexity of use and admin if nothing else!

So, no, the opposite of frustration for me - the project types make it easier for me, as an admin, to see what people are using it for.

Like # people like this

When delivering training, we always refer to them as 3 separate products in the Jira Platform.  JWM generally comes bundled with either JSW or JSM and looks like it will now continue to do so.  JSW and JSM have different features and thus require different licences so for a user to get the full feature set they would need both JSW & JSM licences however in most cases one or the other will suffice.

I have always assumed that (aside from the licensing differences) it was to do with having different teams work on different products which is why some UI changes occur in one product and not the others. 

Like Nic Brough -Adaptavist- likes this

I have the same view: Jira platform with enhanced products running on the platform. It would be nice to have a feature like Approvals available in JSW but I can see how that might cost Atlassian some revenue since JSW licenses are less expensive than JSM licenses.

Like Nic Brough -Adaptavist- likes this
Haddon Fisher
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
Oct 17, 2023 • edited

I definitely agree with the sentiment that "admin is complex for Jira because there's just so much you can use it for" - hard to make something easy and powerful.

I guess what I am finding is...

...the things they're differentiating on don't seem to match with what I am seeing people do in the application, so we're having to introduce more complexity in order to meet their needs. As example, we actually do have service teams that (for reasons I don't quiiiiite understand) use Scrum, and rather than give that up they have chosen to work out of two projects and use Automation to glue things up.

...different products work just differently enough to fall into something like an uncanny valley. I might actually like this better if they made the UI/UX more distinct at this point.

If it is purely about revenue, then thats pretty crappy. All well and good to pay for things that change how the product is used (like JSM's ability to interface with unlicenced customers) or massively extends functionality (like Assets), but if they can afford to drop $1b on Loom, they don't need to squeeze me on workflow approvals.

Like Nic Brough -Adaptavist- likes this

What about Jira Align (never understood what is this all about), Atlas (Goals), Compass and so on?

Haddon Fisher
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
Oct 17, 2023

Can't really speak to the others yet, but Align attempts to manage the top portions of scaling Agile for organizations with lots of teams and big interconnected work-projects; stuff like roadmaps, planning scenarios and dependencies. If you have heard of or remember Portfolio, Align is like that but "more".

Wholeheartedly agree with the OP. It's one thing to have projects having different features, but it's not just that. It's user licensing as well, we need double/triple licenses for what's effectively 80% the same product.
If you are a developer, working mainly in Jira SW, but you want to just VIEW a Service Management dashboard of a SM project in the same JIRA instance, that has SLA reports on it, you need to have also JIRA SW license just to be able to view the SLA reports.
Our Platform Engineering team is running 2 projects, one SM project, because they need a "helpdesk" interface (internal use), another SW project, because they are working in sprints. Absolutely no reason why those could not be combined, but nope. Jira.
90% of our JIRA SM users also have a JIRA SW license...

I have a feeling this is purely a commercial decision to separate the functionalities, as this way Atlassian can sell "different products" to the same customer multiple times. Of course in the end of the day they want to get their money, so if they would only sell "JIRA-do-it-all" product, the price would be higher than current individual products and then again somebody else would not be happy, because they maybe only need SW or WM. Impossible to satisfy everybody all the time :) 

Like # people like this

@Haddon Fisher 

I had the same issue when it was decided to allow users to create own board which never had the functionality required to support the way our projects run. 

I ended up having to sort out as the person insisted this type of project was best. 

I quickly changed settings so nobody could create these boards again and now the project in question ended, no longer have this issue. 

I have to manage licences closely as my workplace only budget for a certain number. 

Like # people like this

I liked the move to having the base project and then have switches for the different features. I have JSM projects that I want the JSM intake UX, but would prefer to have a board view instead of queues, or both (eg queues for incidents and boards for problems).

I agree that a calendar view would be useful for JSW, not just JWM. Back when I was still working with on prem instances I used to use Team Calendars to get around the lack of calendar features for software teams.

JPD has some cool new field types and I'm miffed that they're only in JPD. One of Jira's strengths to me was that you could wield it however you want. Restricting things like field types, vs whole UX features, sucks.

Is the "Platform" a product?  Can it be used independently?  

I view each type of project as just a variation/customization of the other.  They all have the same structure with some key UI differences.  All the differences should be available to each project type.  

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
Oct 29, 2023

Yes, and no.  The "platform" is always part of one of the other applications.  As I said, it provides the basic structures that all the others need.  But it can't do that without at least one of the applications doing the front-end work.

AUG Leaders

Atlassian Community Events