The valley of Jira


Hypothesis: Jira is good enough.

I don’t know anyone who likes Jira. At best it is “It’s not as bad as you think”. Yet despite products like Asana or Linear being better designed or more responsive, it’s unclear whether either are eating Jira’s lunch or simply slicing a separate piece off a growing pie. It reminds me of Salesforce. Both are expensive, no-code databases that are tracking and reporting tools more than they are true productivity tools. Why do these tools continue to not only succeed, but dominate their markets?

I got interested in this question when I spent a few months obsessing over the idea of building a Jira competitor. I designed my perfect version of a project management software, but that the end of it, I stood back and wondered, “Why the hell would anyone use this?”

It’s “easy” to point out flaws in someone else’s product. It’s even possible to imagine building a better product. It’s much harder to build an enduring product whose customer base remains loyal for a decade.

Jira started in 2002. That’s before Gmail. Gmail. Yes, it wasn’t a “Web 2.0” app back then, but it gives you some idea of how long the near-eponymous product has been kicking around. Jira wasn’t built on some technical innovation or flashy sales pitch. It was built on decades of seeding and converting a freemium customer base before Dropbox termed the word freemium that gradually upgraded. It was built on the innovation of the Internet and the realization that because distribution costs had dropped to zero, self-service revenue could create unheard-of “sales efficiency” but more importantly, allow the company and product to evolve very differently than other B2B software firms1. Gmail wasn’t a better application than Outlook, but distributing it to consumers as a webapp gave it (and webapps in general) massive adoption that Google later converted to Google Apps customers.

The same stickiness makes it hard for Jira to evolve their product, because the nature of certain product spaces is all solutions build towards accomodation of an increasingly diverse use case and therefore towards compromise. It does not necessarily mean there is a space open for new entrants.

Jira’s entrenchment is both a strength and weakness. Yes, it’s slow. Yes, the design of some workflows are painfully outdated. But the fact that it is used despite these flaws speaks to its momentum. Part of that momentum is just how “full-featured” it is, but products with lots of surface area and code bases spanning decades and thousands of engineers are immensely difficult to change. A single feature is leveraged by dozens of intersecting workflows that your average customer isn’t aware of but I’m sure Jira’s many product managers are too aware of. Jira isn’t just used to track issues, it’s used to track IT support tickets, security approvals, and just about any other internal process you can imagine. It is the back-of-the-house database. There is no replacing Jira, unless you can simultaneously get buy-in from an entire company and wholesome replicate Jira’s feature-set.

When migration of a single customer can take a year, it means migration of a market will take decades. Those decades mean time for the incumbent to turn the ship around and worse yet, very few founders have the patience to spend decades wearing down an incumbent’s position.

Is it intuitive or familiar?

What’s the line between intuitive and familiar? Is using a mouse to control a pointer on the screen to click icons intuitive? Yes, once you’ve become familiar with it. Jira benefits from the same thing. Once you’ve learned how to do something in Jira (most likely because you were forced to learn to do it at a previous job), there’s little point in finding another tool. Yes, in the realm of personal productivity tools, intuitiveness makes a huge difference because it relieves cognitive load. However, tracking and reporting tools always require you to map your work to management’s data needs. When management needs to you backfill label your tasks as P1, P2, or P3 so they can generate reports on team prioritization and productivity, intuitiveness matters a lot less. Performance can matter and Jira is slow, but few people would claim “building a faster Jira” was a great startup idea.

While incumbents are often unseated by better, more intuitively designed products, it’s often more a product of the incumbent being so desperately out-of-date that any upstart will be better designed than them. However, that doesn’t mean the upstart won because of its superior product design because more often than not, it was because the upstart had an unbeatable distributional or economic advantage. Chrome, for instance, didn’t beat IE because it was a better browser. It beat them because Web 2.0 was a massive trend and IE6 was so far behind that it could hardly even be considered in the same category of browser in supporting the latest standards. Because Google’s ad-based model could endlessly fund development and even partnership distribution deals with OEMs without generating direct revenue. Because Google could wait a decade to wear down the competition.

Valley of Jira

Betting against the success of new upstarts is a sure way to look stupid or be wrong. I write this mostly to try to squelch my own dreams of building a task management tool. So much of what has allowed B2B startups to succeed in the face of incumbents in this last decade has been a moment in history when companies migrated en-masse from their own servers and datacenters to the cloud. Success usually comes from either catching a new wave or finding a niche and it seems likely you’d find either trying to replace Jira.

  1. Give Softwar a read if you’re curious how enterprise software companies tend to evolve. Over-promising on expensive but secretly discounted prices ending with delayed buggy launches. Symptoms of massive, sudden success.