Dave Meyer, the Head of Product for Jira at Atlassian, has spent 15 years with the company. In those 15 years he watched Jira evolve from a bug tracker into an enterprise platform used by every team from engineering to HR. However, AI, the biggest technology shift since mobile for Jira is now coming. What does that mean for Jira, and for Atlassian? We discuss these and other questions with Meyer.
When asked how significant AI is compared to other technology shifts he has witnessed, Meyer says that AI is the biggest change in technology since the introduction of mobile devices. He also says, however, that we shouldn’t overstate how ‘different’ AI is compared to earlier developments. “Is the way that it will change software development any different in fundamental impact to the software we deliver than DevOps or DVCS or Agile? No,” according to him. Atlassian has adapted Jira to every major wave of change in how teams work, Meyer says.
Specifically looking at Jira, what is different today is the platform beneath it. “The biggest change between Jira today and Jira 20 years ago is that we have the entire Atlassian platform underneath it,” Meyer says. When thinking about software developers, the conversation is no longer just about Jira in isolation. It is about Confluence, Atlassian Intelligence, and the full ecosystem working together.
Jira is for every team
Jira launched as a bug tracker and issue tracker, but even in its earliest days, its differentiation was that it was usable by people beyond engineers: product managers, business analysts, and other technical functions. Agile adoption expanded that further, and today Jira is used across IT, HR, marketing, legal, and service management teams through Jira Service Management.
The challenge for the team that builds Jira is building features that serve this breadth without creating something so complex it becomes unusable. It’s important to continue to realize that Jira can’t be everything to everyone. According to Meyer, the question of who a feature serves is top of mind during every product and design discussion at Atlassian.
Avoiding the feature factory trap
During our conversation, Meyer makes an interesting observation about how many companies operate as “feature factories”. That is, teams that are goaled and incentivized based purely on how many features they ship, without a coherent strategy driving what gets built.
Meyer argues this is where product management and design will derive their greatest value in the AI era. “In order for Atlassian’s business to work, we need customers to be able to adopt our features without having a salesperson with a briefcase to explain all of them,” according to him. The entire portfolio has to make sense as a system. That discipline, he suggests, is what separates products that scale from products that collapse under their own complexity.
The AI SDLC
One of the most practically useful frameworks we talk about with Meyer is Atlassian’s internal work taxonomy. The company classifies all engineering work into three types:
Change the business: Creating new business value and new customer value to grow the business.
Run the business: All the work required to maintain and serve existing software and existing customers.
Developer productivity: Investments that make the entire system run faster.
Atlassian sets a target of at least 75% of engineering time on “change the business” work. Meyer’s optimistic that AI will push that toward 90–95%. This frees up developers to work on what they find most meaningful. That is, building new things for customers.
Meyer doesn’t buy into the idea of a single “golden” AI SDLC process though. Instead, he describes it as a buffet of tactics: organizations need to identify each type of software engineering problem they face and apply the right set of approaches. The first step is simply having the vocabulary to delineate these types of work.
The biggest bottleneck is to the left of code
Despite all the attention on code generation and pull request volume, the biggest bottleneck at Atlassian is not reviewing or merging code, Meyer says. Deciding what to build and how to build it is. “We probably spend more time, too much time, debating what to build and how to build it right and rebuilding it because we didn’t like the first version,” he says.
This is why knowing what you are going to build before you start building it matters so much. It is also why organizations without a clear strategy or strong product management function are at increasing risk as AI accelerates the volume of code that can be produced.
Agentic AI for security is complex
Beyond human collaboration, Meyer sees agentic AI systems playing a significant role in security automation. The vision is straightforward. He sees a security team that builds tools that automatically detect a new vulnerability, create a ticket in the relevant team’s backlog, triage it automatically, implement a fix, and surface it for a developer to review.
However, taking a vision from theory to reality isn’t easy, Meyer admits: “Building that system properly is a little bit more complex than just setting up a few Jira automations.” It requires writing detailed, iterative instructions for agents.
The payoff, Meyer argues, is interesting. It gives leverage: invest the engineering capacity now to build these automated flows and they deliver returns for the next 12 months, until the next generation of technology arrives and the process improves further.
Confidence in the vision, but how to get it across?
All the way at the end of the conversation, Meyer talks with us about what he finds hardest about his role right now. It is not the technology, that’s for sure. He feels more confident in Jira’s vision than ever. The challenge is helping customers at every stage of AI maturity understand what Atlassian is building and where Jira is heading. That communication challenge, in a market moving as fast as AI is, may be the most human problem of all.
Also read/listen/watch: AI mandates don’t work: change the culture from the ground up