Jira is trying to unify work - but Atlassian keeps fragmenting it

[#1]

Jira had a perfectly good foundation: the issue.

Now it’s called a work item, and the idea behind that rename is obvious: Jira should model all kinds of work, not just tickets.

So far, that’s a logical evolution. But then Atlassian introduced Ideas from Product Discovery, Goals and Projects as separate entities.

And with that, they broke their own direction.

The work item concept points towards a unified model where everything is just work, differentiated by the work item type. But Ideas, Projects and Goals reintroduce parallel objects for the same thing.

Instead of one model, we now have several. And they have to be linked manually!

The consequences are predictable:

• duplicated structures
• unclear ownership of data
• inconsistent feature sets
• continuous synchronization effort

---

1. Ideas are not a new type of work

An idea is not a fundamentally different object. It is simply work that has not yet been committed. That’s a state, not a new entity.

This could have been easily solved with a small extension to the workflow:

Idea → To Do → In Progress → Done

Jira already had all the necessary building blocks:

• statuses
• workflows
• views
• filters
• permissions
• automation

There was no need for a second system.

Instead, ideas live now in Product Discovery, and ideas being implemented live in Jira. So the same thing exists twice, just in different forms - and has to be synchronized. Ouch.

---

2. Projects are just the top work items in a hierarchy

A project is not a special object. It is simply the top element of a structured set of work - the same work item that started as an “idea” and is now being implemented and broken down into child items.

Project
  → Initiatives
    → Epics
      → Tasks
         → Subtasks

(which everyone can fine-tune via their own work item hierarchy)

Jira already supports this kind of structure.

So the consistent approach would have been simple: a project is just another work item type and has no parent.

That would automatically give you:

• consistent permissions
• consistent reporting
• consistent structure

And once projects exist in this way, everything required to track outcomes is already present. Managers, just follow this work item.

---

3. Goals require manual updates

Goals are treated as separate objects with their own lifecycle, ownership and updates.

But in reality, progress of a goal is already defined by the work behind it.

If you track your work items properly, you already know how far you are - because goals are fulfilled through that work.

Requiring manual updates like:

• “Goal is 60% complete”
• “Goal is at risk”

just duplicates information the system already has.

For KPIs this becomes especially weak. Jira has all the underlying data, but instead of deriving status, it asks users to report it manually.

The system doesn’t compute reality - it asks users to describe it again.

Goals could have been fields attached to work items, with their status derived automatically. The contributions achieved within individual work items roll up through the work item hierarchy so that the top level work item offers the complete picture.

---

4. Weak integration creates unnecessary work

But the real weakness is not that these apps exist.

Each of them introduces its own perspective, which is fine, but also its own set of data. And that is where the problem starts.

Now we have:

• Product Discovery
• Jira Business
• Jira Software
• Service Management
• Goals / Projects / Home
• Advanced Roadmaps

All of them describe perspectives on the same work, but not based on the same data.

So users have to:

• link objects manually
• maintain structures in multiple places
• decide what the “source of truth” actually is

This leads to situations where:

• goals are updated manually although the underlying work is tracked
• ideas and epics are maintained in parallel
• progress is reported multiple times

The system doesn’t reduce work. It creates additional work to manage the system itself.

---

5. The missed opportunity

None of this required a new architecture.

Jira already had everything:

• a flexible work item (called issue)
• workflows
• custom fields (which could have been extended)
• hierarchical relationships
• permissions
• automation
• different views

The logical next step would have been to extend this model consistently. 

They either wanted to generate revenue through clearly separated products or keep teams working in silos - ironically, coming from Atlassian, which strongly criticizes siloed work.

Now they are recreating similar features (permissions, automation, etc.) across multiple products — a direct result of not building on a shared (data) model in the first place.

---

6. What they should have done

A consistent approach would have been:

• one unified work item
• an extended workflow including an “idea” status category
• goals as fields and their options
• different UIs for discovery, planning, delivery and controlling

The guiding principle should have been:

Use the existing data structure, extend it globally, and create different perspectives.

Not new entities. Not parallel systems.

---

7. Where this leaves us

Today, Jira feels less like one system and more like a set of loosely connected apps.

The main problem is not missing features. It is the amount of manual work required because the model is split.

Instead of deriving information automatically, the system requires users to:

• maintain additional objects
• keep multiple representations in sync
• manually interpret the same data

---

Conclusion

Jira is evolving towards a “system of work”.

But that only works if the definition of work is consistent.

Before you merge Jira with Confluence, Loom and others, better unify

• Jira Software Management
• Jira Service Management
• Jira Business Management
• Product Discovery
• Goals / Projects / Home
• (Advanced) Roadmaps

These should not just be connected. They should operate on the same underlying data model. One structure. One source of truth. One representation of work.

One system where all teams work on the same model - not in parallel silos.

[Daniel Bagiński]

Hello,

This article gets straight to the point! Do you have any best practices for handling this in your company? How do you utilize work item hierarchy (Initiative, Epic, Task, Sub-task)? Do you use Goals and Projects? If so, how? Additionally, how did you standardize your workflow for new projects? I would love to hear your thoughts from the community.

[Josh]

@Wurm Peter thanks for the insightful article. I agree with 95%+ of it. I have some quibbles about "Project" being above "Initiative" in the hierarchy, but I get where you're coming from there with Atlassian's concept of the "Projects" feature.

Your article makes me wonder if the fragmented results are due to internal organizational silos at Atlassian where product teams are given a bit too much autonomy to dictate core constructs. For example, Jira and JSM teams have been diverging a lot more of late now that there has been some conscious uncoupling between the teams and architectures.

To "win" in this AI world, Atlassian would be best positioned for success if they standardized their system of work definitions (and underlying data models / architectures) as you suggested here.

[Josh]

Also - quick article title suggestion:

"Jira is trying to unify work - but Atlassian keeps fragmenting it"

[Anastasiya Golendukhina]

Oh and there's still vastly different feature sets (and not just permissions and centralization controls) between Team- and Company- managed Projects...which are also now renamed to Spaces, something that nobody asked for. 

[James Rickards _SN_]

Most of this article resonates with me as a 20+ year user of Atlassian products. I do see fragmentation, and this is a dangerous slope that killed off big complex and inflexable products like IBM/Rational Suite, and the HP products. 

However, I think you've misrepresneted the situation somewhat. Jira Business and Jira Software were unified last year, so are not separate products anymore. Advanced Roadmaps is built into Jira, so is not a separate product, but instead sits behind paywall.

Secondly, you don't need to use all the different Products such as Projects/Goals/Product Discovery. You can still setup your users with pure Jira and keep thing simple. I love the rename of issue to work becaise if you create a worktype of "project" or "issue" you don't end up with conversations like "do you mean a real issue, or a jira issue".

Where you may want to use the new products is where their more targeted User Interfaces help. For example, Product Discovery has UI's that make it much easier to ingest, sort, and prioritise customer feedback.  Something that is much needed by Product Owners and BAs when operating at scale, but would clutter Jira if baked into Jira and made available to everyone for every workspace.  Ditto for all the Service Managment features.

I do miss the ability to have a single workspace/project for both support queues and software delivery processes for devops teams, but I have grown to like the separation as their vision has matured.  I expect we'll see similar improvements with less manual updates to Goals/Projects.