Product development often follows a predictable pattern: A team identifies a customer need and builds a feature to address it. Rinse and repeat. It’s a straightforward approach that works well — until it doesn’t.
As Atlassian grew from Jira to Confluence to an entire suite of products, building features this way led us to have products that worked well in isolation but not in conjunction. Our customers struggled to navigate between products, and finding work emerged as a constant pain point in our feedback. We’d built great individual products, but not a cohesive system.
At the same time, we wanted to unleash the potential of every team, not just software development teams. Teams in marketing, HR, finance, and countless other business functions also need to manage and organize their work. When we spoke to these teams, however, we learned they saw our products a little differently. While technical teams considered our products’ complexity to be powerful, business teams found it too overwhelming for their organizations.
So how do we build a cohesive system that works for everyone?
Step one: One navigation for all products.

This blog shares how we aligned teams behind a single vision, found a balance between speed and quality in delivery, and took the first step forward to weaving our products into one seamless experience.
A system of work for everyone
When we first announced plans to create one navigation for all products, many believed it to be a risky undertaking. This wasn’t just another small feature — we wanted to fundamentally change how people interact with our products. Navigation forms the structure behind a user experience, and we knew from previous navigation rollouts that users would naturally resist changes to this foundational structure.
This time, we weren’t talking about one product. We wanted to change the navigation for all products, meaning we needed a cultural change in how we approach product development. No more individual teams shipping their own features. This project required collaboration across 12 teams, 61 stakeholder groups, and 4 timezones.
As you might expect, there were challenges.
Many teams had carefully planned roadmaps with features their customers were eagerly awaiting. The idea of pausing these plans to work on navigation, something that wasn’t an immediate ‘product need’, was naturally met with scepticism. Why should they put their plans on hold to work on something that seemed peripheral to their core mission?
To bridge this gap, we went all-in on communication and collaboration: weekly timezone-friendly meetings, craft-specific sparring, open Slack channels with frequent updates, transparency in our decision-making process, and vision workshops between product managers and designers. We treated communication not as a box to check, but as the foundation for our project.
Finding common ground
Our breakthrough came when we connected the system-wide navigation change with team and product goals. When business teams find our product more intuitive, it creates a domino effect. More team members adopt the tools, and naturally, their organization will expand their Atlassian footprint, whether it’s through purchasing more licences, upgrading to premium, or adopting more products. This shift in perspective changed what could be seen as a distracting initiative into a driver of customer growth and revenue expansion, all the while improving the user experience of our products.
Instead of measuring success within each individual product, we started thinking about the multiplicative effect of cross-product experiences. Teams began to understand that even if they built the perfect feature, its value would be diminished if users couldn’t navigate to it or understand how it connected with everything else.
More importantly, if a product added navigation elements that weren’t aligned with other products, they’d be forcing their users to switch mental models between products. This would actively work against the multiplicative benefits we were aiming for. The message became clear: either we all play within the same system or we risk undermining the entire user experience and revenue growth it enables.
Balancing speed and quality
Getting teams aligned was just the first step. As we dug deeper into what it would take to succeed, we realised we had to raise our design quality standards. In today’s crowded market, simply having functionality isn’t enough; we also have to win on user experience. This means we have to make a good first impression — and nothing shapes first impressions more than navigation.
Navigation isn’t just another feature that users occasionally encounter. It’s the digital storefront, the first thing users see and interact with. For business teams who’ve historically viewed Atlassian products as complex and technical, the new navigation serves as a powerful statement: we’re transforming our product experience to be more intuitive and accessible. If these users experience friction in their first few interactions, it would only reinforce their hesitation. If, on the other hand, we get it right, we can show them that Atlassian products aren’t just powerful — they’re thoughtfully designed for everyone.
At the same time, we couldn’t perfect the navigation forever. Balancing risk with strategic bets, our plan was to get it into customers’ hands as soon as possible to get user feedback. Otherwise, we’d use our resources on something we weren’t sure worked for real customers. If we didn’t maintain high standards, our feedback would get stuck at the basic level of ‘it doesn’t work’. But if we tried to perfect the navigation before testing it with real customers, we’d never move forward.
To find this balance, we set quality thresholds and risk acceptance levels for each stage of our rollout. These guidelines helped teams understand what quality was needed before moving forward while acknowledging that some issues could wait for later stages. These were our guidelines for proceeding between phases:
- Dogfooding: We might proceed despite known usability issues.
- Early Access Program: We might accept some workflow disruptions if they provide valuable insights.
- Open Beta: We’re less tolerant of performance issues but might accept minor UI inconsistencies.
- General Availability: We have a very low tolerance for any issues that could negatively impact user experience or productivity.
With our quality thresholds and risk acceptance levels defined, we needed a systematic approach to gathering and interpreting feedback that would tell us whether we were meeting these standards.
Gathering feedback that matters
We started by identifying the questions we wanted to answer. How often would customers customize their sidebar? Was it a problem that each product had a slightly different sidebar? We put anything we weren’t sure of on the list. Then we chose a customer cohort that would help us answer those questions.
For our Early Access Program (EAP), we hand-picked 100 customers based on these criteria: high monthly active users, product engagement, diverse representation across products, tenure, and editions. We wanted feedback from both power users who knew our products well and new users without preconceptions.
Surprisingly, our EAP attracted more Premium and Enterprise customers than expected, despite these organizations typically being risk averse. Their willingness to participate signalled a strong interest in the navigation’s potential value. We also included a separate track with 30 developers to learn how the new navigation would impact apps and integrations.
With customers finally using the new navigation, we faced another challenge: making sense of the feedback.
Distilling signal from noise
Knowing no single metric could tell us everything, we took a holistic approach, looking at everything from qualitative user feedback to performance metrics to business KPIs. With a change this significant, we knew we’d face resistance from users. If we stared at that feedback for too long, we’d forget what were trying to do. We had to be confident and clear about how we interpreted feedback. Instead of just tallying positive versus negative responses, we looked at who was giving the feedback and what patterns emerged across different roles.
This focused approach to feedback helped us uncover deeper insights about user behaviour during our EAP. Most notably, we discovered that customizing the sidebar wasn’t just a feature addition; it was a paradigm shift in how people use our products. Previously, only admins could control these types of settings; now, each user could personalize it for themselves. This feature, while powerful, wasn’t immediately intuitive to users and admins, who were accustomed to our previous approach. It taught us that we needed to better help our users embrace a new way of using our products.
Another key insight emerged from our app developers. When we initially reduced the screen size of apps to accommodate navigation tabs, developers pushed back on us. Rather than simply reverting the change, however, we found an opportunity to address their needs while strengthening our system. The result: making full-screen mode more available by allowing all Jira tabs, including Marketplace apps, to have the full-screen button available. This was our general approach to feedback: instead of implementing changes blindly, we wanted to balance user needs with the broader goals of the system.
These are just two of the many transformative insights that emerged in our EAP. Every time we encountered constructive feedback, we paid extra close attention, each one pushing us to further improve the new navigation as we continued rolling it out.
Moving forward with confidence
We’re in Open Beta right now and the data is giving us good reason to be optimistic. One key metric we’re watching closely is the opt-out rate, which many had predicted would be massive for a change of this size. The data, however, tells a different story. With over 30,000 users across 250 organizations using the new navigation, only 2.7% have switched back to the old navigation — far better than the 5% typically expected for changes of this scale. Put another way, 97.3% of users are choosing to stay with the new navigation.
What gives us even more confidence is how new and free users starting trials are responding. The data shows these cohorts engaging with the product faster and more often with navigation. The timing of these positive signals is crucial — typically, the first few weeks of any major change reveal whether metrics will decline, even with small exposure groups. Instead we’re seeing direct evidence that our navigation improvements are making our products more usable. If this continues to be the case, we’ll be driving our expansion to business teams and helping fulfil our mission of unlocking the potential of every team.
While we’re still early in our journey and monitoring the data closely, these initial signals validate our approach. As we prepare for a General Availability that will reach millions of users, these numbers give us confidence that we’re on the right track. This first step has shown us what’s possible when we think beyond individual products and see our product suite as one integrated experience.
Read about how we designed the new navigation or try the new navigation today.