Atlassian's Transformational Change Playbook for Exponential Growth with Anu Bharadwaj

Thank you, Lloyd. It's wonderful to be here. Thank you for having me.

Even in the 80s, when it used to be known more for its gardens and trees than for being the Silicon Capital of India as it is now, back in the 80s it was really easy to go out and play and not worry about traffic. Now when I go back to Bangalore, it feels like an entirely different country now, almost not just city. But one thing that happened while growing up was I'm the youngest of three siblings, so I kind of learned to always be the youngest in the room and be okay with asking questions that felt basic, that felt fundamental, but being comfortable with asking those questions, which has served me well I think through my career as well.

I worked on the .NET SDK. So when Microsoft offered me the job, I couldn't believe it. I was like, you're going to pay me for this thing I would do for free. This is so much fun. Who doesn't want to do gaming? So that was a really exciting start for me in technology. And when I went to Microsoft, I had the good fortune of being able to try out different roles. Microsoft has a program through which they facilitate rotation of high performers across different teams. So I was able to work on different problem sets, not just on the gaming SDK but also building compilers with JSharp.

I distinctly remember when I went to a user conference as an engineering lead, I met a customer who said, 'Hey, you know this product you guys are building? It was called Team Build, it was a build management piece of software. He said, 'This helps me get my job done way faster, so I can go home quicker in the evenings and I get to spend time with my three-year-old son.' And for me, that was very striking. I thought, wow, okay, the work that we're doing really has an impact on somebody's life so meaningfully that it's changing what they can do with their time. And so I naturally found my way to product management. I'm also a little bit of a science nerd, so one of my favorite things is that we do not take equations and numbers seriously enough, because all of the equations and numbers that we're working on, we don't quite understand how they explain the entire universe we live in. And I think so is the case with software development sometimes. When you're in the weeds, you kind of be like, 'Oh, this is cool technology, I'm building this game, I'm building this compiler, amazing fun,' but you don't quite get how much impact it has on a user's life. So eventually I started building more products and businesses at Microsoft, built developer tools in Visual Studio, part of Team Foundation Server, and after about 10 years there, I found my way to Atlassian. I have to confess, when Atlassian called me, I said, 'What's Atlassian?' I had no idea what this company was. But back in 2014, I met the founders, Mike and Scott, and I realized they were really there to solve customer problems. They weren't in it to just put the next big technology brand on the resume and move on, or to make a big IPO and then primarily look at it from a financial lens. They were really there to solve customer problems, and they really clicked together as a community. So I felt like I belong here. I want to come here and be part of this. And so I joined as the head of product at Atlassian, built out the product management team, did a couple of worldwide tours convincing people to move continents to Australia to come join my team for a company they had never heard of. We're pretty low-key, we are very Australian that way. And for the first two years, I led the platformization of Atlassian.

At the end of 12 years in the tech industry, I felt like, okay, I really want to do something else. I want to do something different. So I went to my boss at the time. We have two co-CEOs at Atlassian. I reported to one of them. I went to my boss and I said, 'I have 12 years in the tech industry. I really want to go off and do something different. I think I'm going to quit my job.' And he said, 'No, no, don't quit the job. Just go do whatever you want and then think about what you want to do after a significant period of time.' And I said, 'Well, I don't know how long I'm going to take off. I might need like a year.' He said, 'That's okay. Take us a miracle of a year and we will think about what to do after that.'

As a result, they become better leaders. So I was very much involved in funding a bunch of wildlife conservation projects. So I took the year off and went and did field work. I spent time in South Africa working with lions, rehabilitating them, rescuing them from canned hunting operations, and rehabilitating them and trying to revive them. And also in the same year, I went to Namibia and you referred to that as the safari guide experience. I went and worked with cheetah conservation projects where we basically had to chase cheetahs across the desert and fit GPS collars on them and try to protect them from farmers. I had a working visa in Namibia. I also signed up as a safari guide, and that was really fulfilling. In many ways, it was so different than my day job, and it was very liberating to be out there in the wilderness with animals, telling people about how special they are and talking about their ecology and things like that. Finally, I went to Antarctica and worked with penguins on a penguin conservation project. It was really fascinating. I mean, we see pictures of Antarctica as like this icy continent, but nothing quite prepares you for the sheer scale of ice. I remember when we floated in, you just look at a 360-degree view of sheer ice everywhere. The penguins have not seen humans at all. They come really close and come super close to you and look up at you, and they're wondering who are these two-legged animals. We haven't seen too many of them around. So that was a very fascinating experience. And after a year of doing that, I remember Scott, my boss, called me and he said, 'I know the year's done. What are you doing?' And at the time, I was somewhere in the Takama Desert doing some stargazing sessions. I'm also a little bit of an amateur astronomer. And I thought, wow, this was really good. I'm raring to go back to tech. This year's experience was very nourishing. Also, I'd blown all my money. I needed a real job. So I thought, okay, I have to go back and see what I should be doing next. And I came back to Sydney and I was asked to lead the cloud shift at Atlassian.

The question at the time was how we can actually make that happen, and that was a big transformation for us at the time. Over 90% of our revenues came from on-premise products, and we wanted to shift to a world where we were completely SaaS, and that would take a good three to four years of transformation inside Atlassian across R&D teams, GTM teams, go-to-market teams, finance teams, how we communicate this to the street because we were already a public company. And so to do that, I moved to California about four years ago, three and a half years ago, started building out a team, led the building of a cloud-native platform. So over the last few years, I've mostly been doing that, and now as part of my COO role, I oversee the product and engineering teams.

Ah, that's a good one. As a person, I've always believed in values-based leadership, right? I mean, we talk about this a lot, and I remember when I interviewed at Atlassian, they told me a lot about values, and I thought, 'Oh, this is just some marketing. Every company says this. Who knows how true this is?' But when I met the team, I realized it was real. The things that have been constant are my core values that have kind of driven me through a lot of these changes, and those have remained constant. I would say the top three of those: one, courage. I have a tendency to lead with courage and go into situations which seem fairly unknown, but I enjoy that. I enjoy going into situations where I don't quite know what's going to happen. It's new, but I'm sure I will learn something interesting out of it, and being brave about trying out new things. The other one for me is integrity. Integrity is an interesting one. It's not just about honesty. For example, taking a year off, I knew in my heart that I did need a change of pace. I wanted to have a completely different set of experiences, and being able to synchronize what I'm doing with what I'm thinking, what I'm feeling, and being the same, vice versa, what you see is what you get in interactions with other people has been really important. So being open and having that integrity, and I also look for people like that when I hire them on my team because it really helps build strong bonds. And the last one for me is fairness. I am very much a person who cares deeply about fairness. The fairness circuits in my brain typically blow when I see situations of injustice. So when I was living in India, I was involved in a protest against a caste-based strike. And the thing that really drove me was a sense of fairness and justice. The world is not fair, but we've got to do everything we can to make it a better place. And that's what has helped me with wildlife conservation projects too. A lot of wildlife don't deserve the kind of treatment we mete out to them, and it's unfair, but I really feel strongly about being able to do something to help them. And that also leads to my role as the chairperson at Atlassian Foundation, where we invest in global education projects for underprivileged kids who have been born into an unfair situation.

Yeah, that's an interesting topic to think about. We're just starting from first principles when we talk about transformation. I mean, it's almost a buzzword now, with digital transformation being something everyone says. But just from fundamental first principles, when we talk about transformation, we're talking about change of a magnitude where what's on the other end of the change is fundamentally different from where you started. So if you look back at society at large, we've gone through many transformations over the last 100 years. But some of the more common, more popular transformations that we all draw inspiration from are transformations and movements like the Civil Rights Movement, or the Suffragette Movement, or the Indian Independence Movement, which is special for me because I was born and brought up in India, so I read about that a lot. More recently, the climate change movement, where a lot of our younger generation are really seeking to transform the way we think about climate change and what we can do to address it. A movement is really a vehicle to bring about a transformation. Movements are needed for any major transformation to happen. A series of movements are needed, and typically there are leaders who can start those movements and sustain those movements and attract a large following to be able to see that the new normal is actually the place we should be in, and who can combat the fear of change and uncertainty and really lead people into a new future. So that's why transformations are important. If you think about tech transformations, it happens a lot in our industry in technology because transformations happen at a speed and frequency that's a lot higher than most other industries. Many common transformations that we all know about are Microsoft, because I've worked there for 10 years. It's amazing what Satya Nadella has done in terms of transforming Microsoft into the company that it is right now, from a Windows-centric world to more of an Azure and multi-product world. And Apple, from hardware to hardware plus software plus services business. So plenty of transformation stories abound in software and technology. The key theme here is the ability to transform is a muscle that everyone needs to develop if they want to last, and building this movement is that first step.

A little bit of that, Daniel. So key traits of movements: fundamentally, movements are vehicles that help organizations or societies transform. For example, the Civil Rights Movement as a movement was effective in helping people change perspective about what was acceptable, what was fair, what was just. So a movement overall should really have one common uniting purpose, right? So one key trait that's required is a shared understanding of why. Same thing in technical industries. In the technology industries, for transformations, the key thing is for everyone in the company to understand why that transformation is required. So closer to home for us at Atlassian, the cloud shift was a big transformation. Why were we doing it? Because we believed that better software would be built in the cloud. That's a key thing. So every good movement should have a powerful why, and one that is shared across a large group of people. And as a leader of a movement, and through personal experience, I love this Jeff Weiner quote where he says, 'When you get tired of saying something, that's when they start listening.' So it's important to keep repeating the why. Why are we in this movement? What's the shared purpose that unites us? Successful movements have that as a key trait. A second one would really be the ability to be nimble and change as needed, right? Anything worth doing takes a long time. Anything worth doing is more or less a long-term situation of multiple years at least. So you need to be able to retain interest and energy and enthusiasm for the movement and adapt to any kind of change that happens because multiple years is a long time, and there will definitely be setbacks. So all successful movements have the ability to adapt and react to changes that happen to sustain themselves over the long term.

Continually communicating it. So tactically, for example, what we do at Atlassian is we have regular all-hands. We embody the transformation purpose and metrics on how we are progressing on that transformation, and what we call OKRs, or Objectives and Key Results. And there is constant communication cadence about that because as we have more and more new people join, for instance, we have over 3,000 Atlassians that have joined over the last two years. For them to come in and understand, okay, this is the key central tenet around which this company is organized, this is why this transformation is important. Asynchronous communication is very important. So this is part of their onboarding material where we explain, here's the transformation we're going through, this is why it matters, and here's how it matters to your life. Great companies don't just cascade goals, they cascade purpose. And for a transformation, that's very important. How you cascade purpose all the way from the very top to every leaf node at the company in terms of why this is the purpose around which this transformation is organized. A second one that was a good learning was it's important to lead with courage when you're undertaking a transformation because this is typically met with fear and uncertainty. When people look at an uncertain situation, the first instinct typically is fear. But the only antidote to fear is love. So you lead with courage, but it's also important to show love and be understanding when your team members are sitting right next to you in a pandemic-ridden world, and especially as we accelerate into more and more distributed work, plus as you scale as a company like you said, at 8,000 people, I don't know this person that's sitting out there in the finance team. I've never met them. It's hard for me to lead with love with the person that I don't know very well. But the thing with transformations is it confronts you with such a magnitude of change that typically people react with, 'Oh my god, I don't know what this means to my life.' So for example, in the cloud shift transformation, what happened was a lot of our partners, the way they ran their businesses changed entirely. They could no longer rely on configuration of on-premise products. Normally, when people don't quite understand what's going on or fear what's going on, their first reaction is conspiracy theories. So you very much hear things like, 'Oh, the sales team doesn't understand what to do,' or 'The R&D team is just way too slow and lazy,' or 'They're trying to fire this whole department. I'm going to lose my job.' Exactly, exactly. It's easy to assume the worst intent and come up with worst-case scenarios. In those times, as a leader, you have to hold emotional space for the other person because really what they're playing out is an emotional reaction to the change. And it's important to stay with the team, with the person in that situation, create that space, and help them see the other side. So building transformation requires not only for the leader to lead with courage, to show from the front line that they're out there risking a lot even for themselves in terms of driving this change, but also leading with love where you show empathy and you understand that this is hard. We know this is hard, but we're in this together.

Yeah, sure. Actually, maybe two examples because you asked about love and empathy. One is the remote transformation that we went through at Atlassian. We were doing this for a pandemic-ridden world, but we're doing this because we believe that better software will be built by fully distributed teams. So early last year, we said as a company we will switch to being fully remote. What that means is any employee can work out of virtually anywhere. We have a few constraints logistically, but you don't have to come into the office ever, not just for 2020 or 2021, but over the long run. What that did is it helped us open up our ability to hire people in different locations, hire people in different stages of life with different constraints, and create overall a more diverse pool of people that can work at the company. And when I was telling you the story of when I went to Australia, I hired a bunch of people, convinced them to move to Australia. They were all in the same boat as they joined the company, people new to the country looking for schools, looking for homes, so it was easy to form a well-knit, tight community. And a lot of that was fostered through in-person interaction. So as a company, we were very strongly aligned around in-person interaction, having a social fabric, meeting other Atlassians socially outside work, etc. So the remote transformation took a few of us by surprise, and through inevitable phases of rejection, instant rejection, people were like, 'Oh my god, I joined Atlassian because I wanted to be in an office. Now you're telling me I'm going to be remote. How do I build my social circle? Are the people that I'm going to be working with also the ones that are working on Atlassian? Should I think of my social circle as completely different than my office circle?' All valid questions to ask. But leading with love basically means taking the time to sit down and listen to what employees are worried about, offering potential suggestions to mitigate, and also accepting that yes, certain things are going to be harder in this new world, but we are making an informed trade-off because it enables us to bring more Atlassians into the fold, people who would have never had a chance to be in a classroom before. So holding that space takes much longer instead of just doing top-down mandates to say, 'No, we made the switch, too bad, this is how it's going to be.' It takes longer, but it's worth the results. On the empathy side, I guess you said you had another example. Yeah, so leading with empathy, I want to share a personal example, something that I learned too, which is a lesson for me. Through the cloud transformation again, for example, I have an engineering pedigree and a product pedigree, and like I've shared, an animal nerd and a bit of a science nerd, so very geeky personality, right? So I had to go to a sales kickoff a few years ago and explain to our sales team, 'You've got to stop selling on-premise products and start selling cloud products.' And I'm the product team person who has this vision of the future, and I'm about to stand up on stage and tell all of these folks whose day-to-day livelihood depends on selling these on-prem products, 'Stop what you're doing now and do this other thing instead,' which is definitely riskier because I'm still building out my team, still building out those SaaS products. I'm asking them to fundamentally change their lens of the world. So I went to dinner the previous night with a bunch of sales folks and some external channel partners and external sales people from other companies that had come in. And I was at dinner, and the dinner topic was new acquisitions that you made, what are the newest things that people have bought? And I was excited about it. I said, 'Oh, I bought this textbook on the evolutionary history of slime molds.' And that instantly killed the conversation at the dinner table. They were like, 'Wow, this is really strange.' And so I went back to my hotel room and I called up one of my favorite mentors, Jay Simons, who happened to be the president at Atlassian at the time, and he spoke at our live conference three years ago in Vancouver. He's an amazing guy, such a good human being, I love him. And I told him, 'Jay, this is what happened. I was definitely the most unpopular person at the dinner table, and tomorrow I have to stand up and tell them to do this thing that's clearly the unpopular choice.' And he said, 'Anu, you're not asking them to do this because it's the popular choice. You're asking them to do this because it's the right thing to do. And you need to explain to them why this shift is important to customers and why you're asking them to do this, because all of you remember, you want to do the right thing by Atlassian customers.' And that was sage advice that really helped to create empathy for what our sales teams are going through, and using that lens helped our sales people create empathy for me to see where I'm coming from. So the next day, I went up on stage and I said, 'Look, in terms of our company values, we're an Australian company, we have a lot of swear words in our values, which is don't do bad things by the customer, which is don't screw over the customer. We are really in a situation where we've invested heavily in the cloud. We believe that's the right place for our customers to be. And if we keep selling them on-premise products, we're going to have to migrate them later, which is going to be painful for them. So we need to make the switch, which is painful in the short term but is very beneficial in the long term, which is why I'm asking you to help land our customers in the right place to start with, instead of put them through a long, painful migration process.' And that instantly clicked with the team. They understood where I was coming from and why this would be the right thing to do by customers, and helped create empathy across two groups of seemingly very dissimilar people.

That's a great question and one that in fact the majority of people in an organization face, because typically most orgs are structured in some shape or form of a pyramid, but the middle layer is the most powerful layer in the company. Because execs can say whatever the hell we want, but people doing the real work are going to listen to their managers, which is really the middle layer. So middle management is really the glue that binds purpose to the actual engine of the company, to the actual set of people who get work done. So it's important for middle management to deeply understand why we are following this particular strategy. For example, at Microsoft, I was in a role where I wasn't entirely sure why we were embarking on a particular project, and I remember standing up at an all-hands meeting and asking that question of the CEO. And he welcomed it and he answered it. And I think that's key because I'd rather have questions I can't answer than answers I can't question, right? So it's important for middle management to really deeply understand and agree with what the top-level company purpose and the transformation, in this case if the company is going through a transformation, why we're doing what we're doing. So the question said, 'I have a deep understanding of it.' It's always worthwhile testing that and internalizing it so you feel it. The constant communication that I referred to can only work if middle management is participating in it, right? The future will not arrive without our participation. So the middle management really are the people who have to repeatedly do this communication to their teams, because the communication coming from the leader of the transformation or from the CEO or the CTO happens at infrequent cadences, but your team really relies on you. People don't leave companies, they leave managers, because managers are the ones that have the most impact on an employee's well-being, on an employee's autonomy, drive, etc. So much of the communication burden really falls on middle management. So it's worthwhile to think about the lattice, the framework through which you cascade purpose. One of my favorite stories is from NASA, where the president at the time apparently was walking through the halls. I don't know if this is an urban myth or an actual story, but I love the story nonetheless. He was walking through the halls of NASA and he met a janitor and he said, 'Oh, I didn't know you were still working. What do you do here?' And the janitor said, you would expect the janitor to describe his job, but the janitor said, 'Well, I'm putting a man on the moon, sir.' Because he believed so strongly in NASA's mission and he was able to connect his work to the purpose rather than to say, 'Oh, I'm cleaning out this closet over here.' So cascading purpose, as David is talking about, middle management is the one that's able to cascade that. So think about how can you do that through your one-on-ones with your people, through your own team meetings, through communicating with new hires that are being onboarded, as well as upwards so execs have an understanding of how transformation is being perceived and what are the roadblocks that we are running into. It's important to keep talking about the hurdles we are running into and how we solve them too, because like I said, sustenance over a long-term period is a challenge. So how do you equip your teams for the marathon becomes your key responsibility.

When I joined Atlassian, it was a 400-person company, and my team was saying, 'Oh my god, we're experiencing problems of scale. We're a big company.' And I'd come from Microsoft, and I thought, 'Oh, that's cute. 400 people and you think you're a big company.' But now we're 8,000 people, and we still act like a startup, but we are actually a big company. So the communication templates and formats and channels have had to change. But one big thing for me that I experienced personally as I moved from Microsoft to Atlassian was the use of Confluence. Confluence is a cultural beacon at Atlassian. Confluence is basically this somewhat of an internet wiki sort of tool where this is the heartbeat of Atlassian. We write everything down. So when I joined, I was told, 'Write everything down.' And it was a bit of a shock coming from a large company where you would get several cycles to clean up and polish up your work and then do an ultimate presentation, to just throwing your work out there to collaborate with people, and it's visible to everybody in the company. It felt a little bit like, 'Oh my god, I'm walking out like naked. This is very vulnerable.' But what it did was it really fostered a quick collaboration, instant collaboration, and people that had common overlapping interests could create conjoined projects very fast. So it accelerated and fast-forwarded a lot of friction that you would see typically. So Confluence has definitely been the gold bar for us in terms of communication across Atlassian. And I see it as a push model rather than a pull model. So it no longer becomes the employee's responsibility to go query out of a document store, 'Let me see what the CEO is up to today.' But because in Confluence everything is available and it shows up in the feed, if I want to see what Anu is up to, all I have to do is follow her feed, and they can see what I'm working on right now, what problems am I facing. So just that openness in communication where you reduce friction and reduce burden on employees to be more of a push rather than them having to pull is an important key in it. Other things that have typically worked are normal channels like keynotes, presentations, meetings, etc. But in the new distributed world, asynchronous communication becomes much more natural, and it's also fairer because when you're working with multiple geos, they don't all have time in terms of time zones to connect to one synchronous big meeting. But when you have a writing culture, people can then consume that content on their own time. So we do a lot of recorded videos. I just sent a holiday video to my team, and it was a good 24-hour cadence by the time everyone saw the video, commented, but they could all do it on their own time and in a format that works for them. So some people do audio only, they don't want to see the video. Some people convert the video to text and read the transcript. So it really opens up a lot of surface area in terms of communication.

Organizationally, the product team is structured as a single function. We have a separate product management function. I remember starting the APM program, the Associate PM program, at Atlassian early on when I joined Atlassian, because we are a heavily product-driven company. We're a product-centric company. We have a product-led growth model. We pioneered that model in the industry. So PMs have a very key role inside of Atlassian, and we believe that the craft of product management is best developed as a single function. And across the CPO and COO, we basically have all of the product managers reporting into them. In terms of what does a good product team look like, several traits define a good product team. But fundamentally, all product teams come in different flavors depending on the kind of product, depending on the kind of team you're working on. For instance, we have separate product and platform teams, very common pattern in multi-product companies. So skills you look for in a platform PM might look a little different than skills in the product PM. But overarchingly, commonly, one, they really have to be the customer voice. And for companies like Atlassian, we have a very large customer base. We have over 200,000 customers. So you can't spend like a good year understanding their work and customizing features for them. So when you have a large surface area, you really have to be smart about identifying how to bring customer voice inside your decisions, but you have to voice the customer's interest fundamentally as a team. Second, as a product manager, you don't own all the decisions on the team, but you own the velocity of decision making. So the buck stops with you. Whether a team is doing well or not, ultimately is the responsibility of the product manager. That's the way we build product teams at Atlassian. So what product managers have to do is really make the best idea shine. They don't always have to have the best idea, but they have to make the best idea shine. And last but not the least, product managers are really the heart of a company. So really they have to model the values of the company and really be cultural and values role models. Ultimately, they own the business outcome. They're responsible for customers, they're responsible for the well-being of their individual teams, and they're responsible for business outcomes. So how they manage those three separate, often initiatives that pull them in different directions, while building with heart and balance, is really a key trait that we look for.

This is a great question. I mean, I've been in the tech industry long enough that I've seen a lot of these various different silver bullets fly through. I don't think I have a best practice that I can confidently say this is the size your team should be. But there are a few guiding principles to think about when you form your own team that should help you determine the size of the team. So one key thing to think about is, Daniel Pink puts this well: what are all employees driven by? Purpose, autonomy, and mastery. And for individuals to be able to have purpose, autonomy, and mastery, it is very much a function of the size of the team. If the team is too big, it's hard to have that. So just out of human constraints, the span of control typically tends to be four to eight, right? So when you're structuring a team in terms of an organizational structure, I would say don't make the span of control more than eight or less than four. So four to eight is somewhat of a good spectrum to think about. A second thing is when forming a cross-functional team, not just an organizational structure, then it's helpful to construct the team at a size where those people can autonomously make progress and each of them knows the other person reasonably well. And you can only do that if the team size is somewhere between 7 to 14, I would say. Anything more than that, it tends to break off into sub-teams. So that's a good proxy for how big of a team you can sustain.

Yeah, also a good question. Something I was talking about yesterday at another talk I was at. Different companies have different prioritization frameworks. So ultimately, what works for you is very much a function of your culture, of the kind of business you are in. Because for instance, in healthcare, prioritization might look very different than in a software company. At Atlassian, we follow the OKR model. It works really well for us in terms of saying, look, company-wide, there are three to five priorities we declare for the entire year. And those three to five priorities represent the key strategic important things company-wide. It doesn't mean that other than those three to five things, we're not doing anything else. It just means that those are the three to five key things that we're all paying attention to at a company-wide level. From there, from those three to five objectives, we then define key results for those objectives, and that gets cascaded over as team OKRs and sub-team OKRs, etc. How we prioritize which three to five objectives we pick is a function of the important and urgent, as well as the important and not urgent categories. Because fundamentally, we are a long-term company. We've always thought about Atlassian should be around for 100 years. That's really our dream, not just build a company and then exit and just think about the next quarter. There is tremendous pressure as a public company to think about short-term results in the next quarter. So often a common mistake is most people tend to get dragged in the direction of let's think about the important and urgent. But if you don't think about the important and not urgent, you're effectively sacrificing your future for your present. So in those three to five OKRs, we like to have a mix of both important urgent projects that yield results in the next year, and horizon 2 projects that yield results in two years, and horizon 3 projects that might yield results in three years. But there are things that will take long to build, like foundation examples are developer marketplaces. It doesn't yield revenue immediately as you start building it because it's a network effect, but you have to start building the network for it to show returns in three to five years. That's been a great success story for us as well. Marketplace is one of our biggest sources of revenue. Same thing with the platform. Continual investment in the platform allows us to now release products way faster. So we just put out five or six new products that we've released just this year because we have taken the time to invest in the long-term foundation of the platform.

Yeah, so just taking the time to define what product-led means, because also that's been a little bit of a buzzword in the recent past. One thing that is very unique about Atlassian that I love, which kind of aligns with my personal philosophy too, is we're a maverick of a company. We tend to do somewhat of the contrarian thing rather than prevailing wisdom. Which is why we don't really have any best practices so to speak, because we think we can always innovate on practices. We never quite believe something is the best just because it's working for somebody else. So product-led growth was invented at Atlassian. Our founders, Mike and Scott, back in 2002, they looked at the prevailing wisdom of the time, which was you need a sales team to sell enterprise software. That was the template that every company would follow in enterprise software. So they thought about it and they said, 'Well, the internet is taking off, and we're sitting here in Australia. We can't really hire sales teams everywhere. If we want to bootstrap our company, A, there's not much talent, and B, there isn't really VC funding that we can use to hire a whole lot of people. So how can we invent a product distribution mechanism through which we don't have to do that? We don't have to hire a large sales team.' And they came up with a way that is now defined as product-led growth, where essentially the product distributes itself. So on the internet, how can we build a product that people can just try and buy without having to talk to a salesperson? So they basically looked at the prevailing model of the time, which was you have to go negotiate with them, try to get a discount, and then haggle about a bunch of different details, and then create an invoice and all that stuff. They removed all that friction and said, 'Just click a button, use your credit card, and the software is delivered there.' Which was a radical idea at the time. And now we have pretty much most of the SaaS companies following that model where it's simple to land and then expand. So key traits of product-led growth, I would say, is one, clear, easy, transparent pricing where you don't have to put customers through hoops to understand how much they have to pay for your product. Second, I would say it's push rather than pull. So think about for your own product, for instance, if you're building a database, rather than somebody having to proactively go and push this into customers, with friction-free pricing, friction-free buying, and pricing for volume and consistency. So typically, a lot of enterprise software tends to cost a lot of money. Even now, Atlassian's prices, if you compare with a competitor set, tends to be priced such that the value is way higher than what we charge for. And that pricing model really helps product-led growth because when users look at your pricing, they don't get sticker shock and say, 'Oh my god, maybe I have to think hard.' It's easy to just fetch out a credit card and buy it and try it. So you can start small. MongoDB is another example of someone that does it well. And the last one is really how do you make the product itself the primary driver of customer acquisition, conversion, and expansion.