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

Question

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!

Arkadiusz Wroblewski · Answer

@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.

Alex Gerulaitis_9or28t · Answer

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.

Alex Gerulaitis_9or28t · Answer

“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.) 🙏