Improving Atlassian Web Platform Efficiency
Background
With the creation of a dedicated Growth org within Atlassian, my team's scope increased to cover the entirety of the "Growth Platform." Our remit was to find opportunities to improve the productivity of the larger Growth org while also looking to improve cohesion, experience quality, and speed with which we could scale learnings across all of Atlassian's web properties (including Atlassian.com, Community, Support, and University)
This was an opportunity to step back from the more tactical work we had done in recent months and look more strategically for where we might have the most impact. As my cross-functional peers were in the process of being hired, I initiated a collaborative listening tour of our partners, stakeholders, and executive leadership to better understand what kept them up at night.
Findings and Share-outs
One of the most significant opportunities identified was that Atlassian.com was a series of "one-off" pages with a complex intake process that often confused the requestor and could allow for duplicate workstreams.
This resulted in numerous consequences, including:
-
It took an average of 5 months to publish a page on atlassian.com. In that time, requests to build or edit a single page passed through up to 5 service desks and 9 departments.
Much of this time was spent "dreaming up" new pages instead of choosing from proven page types that were ready to go. -
Similar pages were being created in silos, independent of each other. This led to a lack of cohesion and complicated future experimentation and optimization initiatives.
Partnering with the Head of Performance Marketing, we presented an approach to executive leadership for wide-sweeping changes to the process of getting pages updated/created. The most notable concept was that all work would no longer be bespoke. Rather, for work that was low-complexity/high rate of change, we would create templates and a new authoring experience that allowed subject matter experts to get their work out quickly (at the cost of some flexibility). These templates would be optimized via experimentation to be best-in-class.
All work would be triaged through a single point of entry and then routed according to its complexity. Work that was more complex, required, or presented an opportunity for improvement via experimentation and directly correlated to revenue would continue to be delivered via the cross-functional scrum teams.
Spinning up the core team
With our new remit, we needed to bring more folks onto the team and spin up a new squad for the Templates/Improved Authoring experience. This cross-functional squad was immediately tasked with identifying the opportunities that aligned with the upcoming Brand Refresh for Team 24 (Our Annual User Conference), giving us a six-month runway. Led by a dedicated Lead Designer, they classified all 5000 pages into cardinal page types and then concentrated on the 400 most trafficked pages (which constituted the bulk of the site traffic).
We brought the team together nationwide in Austin, Texas, from various remote locations for a kickoff with our cross-functional peers. Teams worked together to understand high-level strategy, help frame and scope the work for the next two quarters, and have some fun together in person.
What we did
The Team 24 site re-design and Brand Refresh, coupled with a migration to a new tech stack and CMS provided a unique opportunity to show measurable impact at a time when traffic to our sites would be at an annual high. We chose 4 major areas of concentration for a move to templated work.
Homepage
While we would not get efficiencies of scale, it did allow us to change the authoring process to allow for same day edits to key areas of the page including updating statistics, editing case studies and updating the "Alert Banner" for time sensitive messaging.
Pricing Pages
These pages were one of the areas with the highest potential impact for the following reasons:
Multi-team handoffs: Despite having a generalized page structure, creating new pricing pages took roughly 2 months to complete due to complex coordination with multiple teams and roles
Content update bottleneck: Rigid intake processes led to weeks-long implementation for seemingly straightforward content changes on existing pages
Focus on existing content: Half of the pricing requests were edits to existing pages, highlighting the need for a simplified workflow that enabled faster content updates.
Limited access: 25% of pricing pages are inaccessible to Producers, consuming engineering resources that could be utilized elsewhere.
Inefficiencies: Designers found themselves recreating their own source of truth because of the absence of a Figma template. Similarly, developers were forced to hardcode individual pricing pages due to the lack of a CMS and central template, leading to duplicated efforts for both roles.
Impact on revenue: Pricing pages are the second highest-trafficked pages on the site, with visitors who have high purchase intent.
We made significant changes to the authoring process, reducing the time to create or edit a page from approximately 2 months to less than a week. Additionally, we eliminated design and engineering dependencies, enabling those roles to focus on other projects.
Old Process
New Process
Lastly, after a design sprint and a successful experiment, we were able to implement several key improvements across all pricing pages with just a single change.
"Customer Stories"
We followed a similar process for our case studies (Customer Stories), where we could not only help migrate 135 individual pages from the old tech stack to the new one faster, using templates but also improve the authoring experience in a similar fashion. PMMs with subject matter expertise could now make edits or create new pages without requiring Design or Engineering through a minimally configurable template for case studies.
The time it now takes to publish a new case study has been reduced from months to a single week (no longer requiring design or developer resources who can concentrate their efforts elsewhere.)
Impact and Next Steps
The pages we've migrated to the new template structure are more performant (due to the new tech stack), more consistent, and require an order of magnitude less time to author or edit (up to a 90% reduction in time).
Experimentation wins can now be rolled out across entire classes of templates rather than requiring one-off changes for each page (imagine the time saving for the "Customer Stories" alone!)
In partnership with Engineering and Product Management, we've prioritized which of the remaining high-traffic pages should be templatized and are working our way through them a sprint at a time. We're also in the process of creating a semi-WYSIWYG editor for SMEs to be able to publish key pages and are targeting same-day updates as our stretch goal.
Lastly, and not inconsequentially, people are happier and more productive. With the creation of templates, people are doing the work they are best at! Design and Engineering can concentrate on pages with higher complexity that drive revenue. At the same time, subject matter experts (PMs and PMMs) can work with producers to make quick changes in our new CMS and get their content out in a fraction of the time.