Jira is trying to unify work - but 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 in Product Discovery, and real work lives 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 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
• Jira Service Management
• Jira Business
• Product Discovery
• Goals / Projects / Home
• 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.