"business" vs. "software" (vs. other) projects: what's the story?

[Alex Gerulaitis]

While struggling with seemingly inherent limitations of "business" projects vs. "software" ones, where one absolutely cannot do things in a "business" project that are readily available in a "software" one, can't help but think:

What's the story here?

Why did Atlassian design it this way? If the goal of their software is to enable customer success via better management of business workflows regardless of business or project type - what "success" are they enabling by designing their software this way? What are their reasons?

(All software is business, most business is running on software - so while how business is run is indeed different from how software is developed - how do those differences justify the hard-coded limitations?)

Usually, in most other project management software and frameworks, "business", "software" and other labels are just that - labels. That - and an assortment of templates designed to fit the needed workflows and functions, but not hard-coded insurmountable limitations we're seeing here. Sure, things like releases, versioning, sprints are rarely seen outside of software development and devops - yet do they explain the hard-coded limitations?

Honest question. Not looking to ruffle anyone's feathers - just really curious what's happening here. Well, and wishing there was a giant red flag - not 5 pages of fine print and TOS - when creating projects explaining those limitations and the reasoning behind them.

Thanks!

[Bill Sheboy]

Hi @Alex Gerulaitis 

First thing, I am just another Jira user and thus have no specific knowledge of the internal decision-making of Atlassian.  With that out of the way...

In my opinion, this boils down to: personas, experimentation, and license levels...relative to what problem / purpose a customer team is trying to solve with Jira "work management".

Atlassian product managers likely created personas for certain audiences of customers, and thus experiments led to features such as newer project / space types.  For example:

• The original company-managed projects / spaces (CMP) helped with site-level controls and coordinated work between multiple teams' spaces.  When one needed even more, one could add Advanced Planning (i.e., roadmap) products, or stuff from the marketplace.
• Team-managed projects / spaces (TMP) were meant to help teams rapidly set up a backlog and board, without the help of the Site Admin, and with a limited set of features spanning only their team.  And, in my opinion, doing so created a whole host of compatibility problems with lots of Jira features.  (e.g., Who the heck thought it was a good idea to create two different fields for Story Points in Jira!)
• Jira Work Management, which had business projects of both CMP and TMP types, seemed to target domain-specific teams, such as an HR team versus a software development team.  This seemed to also be where the UX was more rapidly evolving to experiment with new features in the tabbed-view metaphor.
• Then we get to Jira Product Discovery (JPD) for portfolio and product management
• etc.

Add to this, some features are only present (or behave differently) at different license levels.  One then wonders if the way some features were added / evolved was using criteria other than fit and function to support a persona or an actual community of customers identified need.

Kind regards,
Bill

[Alex Gerulaitis]

Thanks Bill, having an idea of "why" (something was done) is helpful to get an idea of the reason for seemingly insurmountable limitations or dumbfounding lack of functionality.

[Arkadiusz Wroblewski]

Hello @Alex Gerulaitis 

From my view, this is mostly a result of how Atlassian evolved the products over time.

“Business” and “Software” were not just labels. They were built for different personas/use cases, and Atlassian put some features only into software projects, especially agile/dev-focused ones like boards, backlog, sprints, and releases.

That said, I agree the distinction has often felt artificial from an admin/user perspective.

[Alex Gerulaitis]

“Business” and “Software” were not just labels. They were built for different personas/use cases, and Atlassian put some features only into software projects, especially agile/dev-focused ones like boards, backlog, sprints, and releases.

Different products then?

Products built for different use cases and with different functionality, some of which cannot be adjusted, qualify as different products?

I.e. someone trying to figure out what project type to use ("business" or "software") and for whom an important factor is the ability to create and share boards for a variety of uses - should be told they're looking at different products with non-overlapping functionality rather just a different flavor of the same thing?

Don't get me wrong, I love the free tier in Jira, and am grateful for it, and love and am grateful for Jira as a product as well - have used it quite a bit over the last 10+ years.

From my view, this is mostly a result of how Atlassian evolved the products over time.

Of course, the existential challenge of how to scale and adapt the products to changing demands and different use cases w/o turning said product(s) into hellscapes of insurmountable complexity we're all too familiar with, from Windows OS and MS Office products, to Splunk and ServiceNow. I am wishing a bit for Atlassian to acknowledge it's a present and persistent problem with their products and outline their vision of what to do with it.

P.S.

• Boards (in their general sense as representations of business or other workflows with distinct elements with common properties allowing to get a "bird's view" of the project state - such as drawings depicting hunting scenes) likely precede written word.
• Kanban has nothing to do with software - at least not originally. Restricting customization of kanban boards to certain projects types - perhaps less-than-wise on Atlassian's part - especially that the differences in functionality are not obvious or well presented from the get go?
• Thanks for the response and your perspective! (I may sound like a cantankerous old man I am - yet I do really appreciate the input and the perspective.) 🙏

[Arkadiusz Wroblewski]

@Alex Gerulaitis 

I think your point is actually quite reasonable.

From a user decision perspective, they can definitely behave like different products. If someone needs things like boards/backlog/sprints, the practical guidance really is to choose a software project, because those capabilities are still tied to that project type.

Technically though it’s still the same Jira platform, just exposing different feature sets depending on the project type. A lot of that comes from the way Atlassian evolved Jira over time (Core → Software → Work Management) and then later tried to consolidate things again.

Your Kanban point is also fair. Boards are not inherently a “software” concept, which is why the separation has often felt a bit artificial from an admin perspective.

Coming to conclusion for architecture it’s one platform, but for practical usage and feature availability, the project types can absolutely feel like different products.