A pop-up survey could appear while you're here --curious what it's for? Click here to learn more!
×Community resources
Community resources
Community resources
Jira's success: A construction kit, not a rigid system
TL;DR: Jira became successful because it was a flexible construction kit. Splitting it into rigid apps removes that flexibility - and with it, the main reason to use Jira as a unified platform.
Jira used to have a very clear strength.
At its core, Jira revolved around a simple idea: the issue. Jira originated as a bug tracker, but quickly evolved into something much more flexible. Through issue types, properties, workflows, and permissions, Jira provided a toolkit - a construction kit - that allowed organizations to shape work to their needs.
Jira was a construction kit.
You could model almost anything as a variation of an issue. Well, that’s why Atlassian renamed it work item in the first place.
What made this work was straightforward: the same properties, views and actions could be used wherever they made sense. Admins and teams decided what fields matter, how workflows behave, how work is visualized. Templates exist - but they are optional. Teams can use them or build their own.
That flexibility is what made Jira scale beyond software management.
That clarity is eroding.
What used to be variations of work items is now split into separate constructs:
- In Product Discovery, an Idea represents an early state of a work item
- In Jira Software, a Work item represents any form of work
- In Goals, a Goal represents an outcome - a result created by multiple work items, a shared milestone
- In Projects, a Project represents structure - effectively a work item type at the highest level
These are not fundamentally different or new concepts. They describe different aspects of the same system: state, execution, outcome and structure - all of which used to be expressed within a single, flexible model. But Atlassian is moving away from a construction kit towards predefined blueprints, packaged within apps (as they now call them).
Do not get me wrong: Atlassian can provide opinionated setups - suggested properties, recommended structures, predefined views. But these should be built with the same construction kit and not replace it.
Everything introduced as a separate concept today can be expressed using the same building blocks. That approach would likely require less effort on Atlassian’s side as well. Not every Jira variant (Jira Software, Jira Business, Goals/Project, Jira Advanced Roadmaps, etc.) needs to reinvent the wheel: a new view should be available everywhere, new property options should be available everywhere. And, of course, not everything has to be free. Advanced capabilities can sit behind Premium or Enterprise plans, but they should extend the construction kit.
When that flexibility disappears, something else disappears with it: composability.
Users do not adapt to the new models in the way Atlassian might expect. Teams fall back to what works. Jira core remains in use, but areas like Goals, Projects, or Ideas are not adopted consistently across the organization. For those use cases, teams might rather turn to specialized tools that are better suited to the task. Why use Atlassian apps if they're only loosely connected - just like tools outside the ecosystem?
What’s next?
If this direction continues, the pattern is predictable: risks, decisions, milestones - each introduced as separate apps, each with its own rigid system. Wanna make some extra money?
Because once new capabilities of the construction kit no longer drive value, the apps carry the price. But many organizations will not pay that price, because the feature set of those apps does not fit their needs as the configuration options are limited.
And that leads to a strategic problem.
Jira loses both sides of its strength: Jira is no longer the most consistent system and no longer the most flexible one. At that point, specialized tools win.
The alternative is clear.
Forget apps. Evolve the construction kit. Shared properties, shared views, shared actions - applied everywhere, combined freely, without artificial boundaries.
This does not mean giving up on monetization. It means shifting it. Instead of selling apps, sell features that are available across the system.
Organizations do not buy “apps” (well, they aren't smartphone users). Organizations ask:
- Does this support how we work?
- Does this reduce effort and costs?
- Does this improve quality?
- Does this help us deliver faster?
A flexible construction kit answers these questions across all contexts.
Jira did not become successful because Jira defined the perfect issue. Jira became successful because Jira gave users a system they could shape. That is the core to preserve. The data center gave more freedom. Don't mess up the cloud version.
Maybe Jira is no longer the priority. Maybe the future revenue comes from interaction layers like Rovo? Even then, one thing should not be forgotten: an object - whether a work item, goal, project, idea or decision - with a tightly predefined and constrained feature-set holds little value for most customers. For example, if we need more levels between projects and epics, we simply won't include our data in your "project" object. Teamwork Graph or not.
What might work for Atlassian, does not necessarily work for its customers. We all organize work differently.
Was this helpful?
Thanks!
Wurm Peter
0 comments