[Music] [John McKiernan] All right. All right. Good morning, everybody. Thanks so much for having us in here. I know last night was probably a late night for many of you. My name is John McKiernan. I'm Principal Product Marketing Manager at Atlassian. And this is Mark Cruth. [Mark Cruth] Hi, everyone. My name is Mark Cruth. I'm a Modern Work Coach at Atlassian. I work with our customers and our teams to help them work a little bit better together with practices, which is where I'm going to come into play here with our story from John. Indeed. So I'm going to start at the end of the story here, which is always a nice place to start. So last year, I got to launch a brand-new product called Jira Product Discovery, which is fantastic. It's a prioritization and roadmapping tool for product managers. So if there's any PMs in the room, give it a crack. I think you'll love it, which was awesome. There we are in TechCrunch, so it must be a good thing. We went GA in May last year. It's been growing at an amazing clip ever since, which is awesome for our customers. They have this new tool that they love. It's great for Atlassian. We have this new revenue making product. Good for me personally, for my career. But I'm not up here to tell you about how great I am. Sadly, they wouldn't let me do that. So instead, what I'm going to do is share all of the mistakes that we made because we could have launched this quicker with a lot less personal stress if we just slowed down a little bit and thought about our practices before actually doing the work. So I promise I'm not going to go overboard on too many quotes for this talk. But this one from a guy called Abraham Lincoln makes a lot of sense to me. "Give me six hours to chop down a tree and I'll spend the first four sharpening the ax." So basically, no matter how strong a lumberjack you might be, if your ax is dull, you're just never going to chop down that tree. And this is something, personally, I've been culpable of in the past. I'm just from that startup background where you just dive in and just try to do things really, really quickly. But Mark is essentially a professional ax grinder. - So, yeah. - I do my best. I do my best. If you have an ax to grind, do so with him. And really, we need these sharp axes because launching products is very, very hard. It's messy. And luckily enough, it's not just me. In fact, out of 30,000 new products that are launched every year, only 5% actually succeed. This is according to Clayton Christensen, The Innovator's Dilemma.

And there's lots of reasons why a product can fail. You can run out of money, obviously, you can fall short of expectations and make promises you can fulfill. You might not find product market fit. Or sometimes, it might just be a brand thing as well. Like, you might not want to buy frozen lasagna made by a toothpaste company. Minty Fresh. Minty Fresh. I think it looks delicious, personally. But that's neither here nor there. But look, often the reasons are under our control. It's never going to be 100% strike rate for new products, but you can certainly get it better than 95% or 5%, I should say. And the reason product launches are hard is because they're really just complex projects with lots of different people. And people are very weird because we're all humans.

And I've never launched a lasagna product, yet, but I have launched products and features across startups and scaleups in my own solo business. This is the first time doing it in the enterprise, and I really thought this was going to be the easiest of all of them in my naivety. And in truth, it was the opposite because there's just so many cross-functional teams, and then there's the teams that you don't even know about. And you have to pull all of these various teams in to make sure that you actually get through what you need to get through. So using the right tools is obviously a big part of that, and we'll cover it. But really, it's a mixture of right tools, right practices, and that's where Mark comes. Right on, John. So a quick question for the audience. Who here has launched a product before? Awesome. Who here has failed at launching a product before? Anybody? There we go. See, we all, again, there is always those issues. But the thing is, is when we come down to it, we think about that 95% number. When we actually look at that, the reason why many of those issues come to pass is that when we think about, we might have the right tools, but do we actually have the right ways of working around how we approach that? And for us, what we think about is that combination of great software plus great practices. That's where you get the great product, the thing that meets what you're looking for. Now another... Actually, yeah, we'll do that. We have to figure out our clicker situation. The next thing we actually think about is that 95%, you can actually make an impact on that. There's actually studies out there that have been found that if you bring about good collaboration practices within your team, you're 30% more likely to launch a successful product. And again, this is something that's completely in our control when we're working as teams. It's figuring out how do we collaborate? How do we work together? And so for us, that's part of what we want to share with you today is we're going to share John's story. But along the way, we're going to share with you those practices that helped bring him through that experience in a way that allowed him to launch a successful product. Now for us, when I think about practices, the area that we do at Atlassian, we like to publish these in a place because for us, our whole mission is to unleash the potential of every team. And we do that by sharing how we work, not just our software. And we do that in a resource we call the Atlassian Team Playbook. Now this is a free resource that's online. Simply go Google it, go to atlassian.com/team-playbook. It will bring you to this. There's 52 different practices that we follow at Atlassian that you can use and learn for yourself. We're going to cover a couple of them today to help you see how you can change how you work with your teams as you're delivering products. So this is the thing to keep in mind as we're going through the story. So I figured it's a good time to let's actually start going through the story. And to John's point earlier, we started at the end. Let's go back to the beginning where John found himself in this idea of the trough of sorrow.

So I don't know if maybe you've heard of the trough of sorrow. Yes, it looks like a lot of nodding heads. - A lot of nodding heads, right? - Yeah. So this is famously coined by Paul Graham of Y Combinator fame. And typically, they're talking about, you're a start up and you get your idea, you start working on it, everything's exciting, and then you hit one roadblock, and then another roadblock, and then another roadblock, and it just feels like trudgery. Everything's a little bit hard. And I feel like this works not just as a start up but launching a product in an enterprise and having a kid, if we're talking outside work worlds. And it was around this time when I entered Jira Product Discovery that's how good animation is in Google Slides, by the way. I just dropped my head in. Around two years ago when I joined JPD, I didn't really know it at the time, but we were actually a bit stuck.

And there was a few reasons for that. There was, like, what are your distribution channels going to be? The team weren't working it together, as well as we could have been. And in my experience, getting through the trough of sorrow, there's a few things you can do in the short-term. You can do you'd just be patient, more tenacious. You can just work harder. And we did all of those things. But really, if you want to go far, you have to look beyond the short-term. And I promise this is the last quote, but it reminds me of this old African proverb that says, "If you want to go fast, go alone. And if you want to go far, go together." This often makes me think of getting my kids into the car because it doesn't happen fast, and I don't want to go anywhere far with them. But in the case of this story, it works quite well for us. The three reasons that we were a bit stuck in this trough of sorrow. One, we had this distributed team, which I'll talk to now in a moment, and we're all very, very different people across. So we needed to find a way of working for us, of all that could help us. Second was a lack of visibility into the work that we were doing and also what everybody else was doing, and that was a big problem for us. And third was getting and keeping everybody aligned is bloody hard. So we're going to cover over that one as well. So let's start off with this first one. So Atlassian is a fully distributed company. I don't know how many are distributed in here or remote? Yeah. Nice. Okay. More than half. And probably a lot of your teams are actually distributed. You work in different offices even, you probably find yourself on calls, things like that, with others all of the time. It's a strange question to ask. - I know. Right. - How it is distributed? So Atlassian is fully distributed. We call it Team Anywhere, which is great. I get to do my laundry and I get to hang out with my kids and all of those things. But sometimes, there are challenges, obviously. So I'm based in Sydney. The team that I manage were in America. The product team I worked with are in Europe, which meant I was in a bit of a time zone sandwich. And this is a bit of an outlier. We try not to go past two time zones, so it's workable. But just circumstances let us here. And there's a lot of problems. So a few things a lot can get lost, I suppose, over these time zones. Slack messages with the little ellipsis at the end, and you're going, "Hang on, what did he mean by that one?" Or you're in a meeting and it's 9pm for you and 7am for someone else and you're both just not happy because it's so late and so hard. So what I did initially, I didn't sharpen my ax. I just did that work harder. I downloaded Slack to my phone again, as I promised I never would, checked it first thing in the morning, last thing at night. I booked in meetings late almost every night of the week. I got up earlier so I could collaborate better with the American teams. And it worked for a little while, but it was one step forward, one step backwards. And it wasn't a sustainable way of working. So let's talk about sharpening that ax. One thing I'll say is I like props. And so I came in with an ax, and for some reason, the Venetian folks wouldn't let me bring it in here. So I'm sorry you won't get that visual. But yes, sharpening your ax. This is where, again, we think about the practices. And for us, John mentioned a really important thing for how we work at Atlassian. And it's this concept of Team Anywhere. It's something we launched back when the pandemic hit. We made that decision that we said, "Hey, you know what? We're already distributed." Let's lean in on this and make sure we have the support structure for how our organizations do this. Because one of the biggest issues we saw back in the day was that we give you tools. Organizations would give you tools to work remotely, but they wouldn't teach you how to work in a distributed fashion with people around the world. And so for us, our Team Anywhere program at Atlassian is all about becoming intentional about how we do this. And they really have three core pillars that they focus on. They focus on this idea of making sure that we can hire talent from anywhere. We want the best talent from anywhere. It's not the best talent in a specific location. So we want to optimize for that. So Team Anywhere is there to help us ensure that we've got the right practices in place for that. We also want to make sure we do have that work flexibility. Do we have the right tools for the job? When I think about remote work, it's how do I work when I'm at home, when I'm trying to handle my kids and my laundry and can do the job at the same time. But then finally, the most important part I find that we really spend a lot of time in is how do we reimagine teamwork? Because that's what distributed work is. Distributed work is about how do we come together when we're not together? And so for us, reimagining teamwork became a big thing. We had to do it. We grew from an organization of about 2,000 people to about, now today, about 12,000 people. And for us, we had to figure out how we worked in a collective way. We did a lot of experiments internally to figure out how do we actually work in a distributed fashion? How do we fix our own teamwork? And so from this, we came up with a number of different practices to help us do this. And this is one that leans into this idea of how do we become intentional, especially when we're going across time zones. And the tool that I found that when I work with Teams on, and you'll hear a little bit of John's story with this, is that of a working agreement. Has anyone ever done something like a working agreement before? Awesome. They're one of my most favorite practices because I think they're the best way to become intentional around those things we need to be explicit about as a team. Like, we assume things when we work together. But many times, again, we take for granted that we think we know what's going on as a team. So within a working agreement, what we do is we encourage all of our teams to build these. When we actually think about a working agreement, we're focused on things like establishing any preferences we have. We're across three major time zones. How are we actually going to set up our core hours? Are we going to have core hours? Are we going to maybe have a specific practice we follow, say, "Hey, maybe every Tuesday we meet for one1 hour as a team." We also want to align on how we communicate, and specifically how we use tools to communicate. Do we use Slack? Do we use Teams? Do we use email? How do we use those? An important thing here is with meetings and rituals. This is the idea is like, all right, what are the core things that we do? Great example is my team is very similar to John's team in this example, where I've got someone in Sydney, I've got someone in Germany, I've got myself in the US. And so we've established a ritual where we send each other Loom videos every Monday to just see each other's faces 'cause we never get a chance to sync up together. So that's a ritual we purposely established. It's also talking about how do we escalate as a team. Again, it's all about how do we bring issues up faster? And actually, how do we resolve those? And then finally, again, one of the biggest things I see a lot of teams fail to do is they establish their patterns, but they don't think about how they want to get better. So how do you want to improve as a team? So for us, when we create a working agreement, this is all about how we want to become explicit about those implicit assumptions we always make. So let's find out how John tackled this in his journey with Jira Product Discovery. Thank you.

So that's what we did. And I know this might sound quite simple. It's like just sit down and talk about how you want to work. And it really is when you actually just take that step, that little breath, you sharpen your ax, and you go for it. So what we did very first thing was we got rid of all status update meetings, which were just taking up time. It wasn't a good use, especially when we're staying up late at night or early in the morning. Gone, that all moved to Slack, daily stand ups, just automated. Things became so much easier. We also batched all of our meetings into just one night. So we had our Tuesday night of hell, as we called it, or Tuesday morning of hell for the Europeans. Tongue in cheek, kind of. But we were able to just go through and get everything that we needed done there so we could do deep work for the rest of the week in a way that we weren't going to burn out. And we also made better use of the tools that we have as well. So Atlassian, I was supposed to say obviously, but if you don't know, Atlassian makes collaboration tools like Trello and Confluence, Jira, and now Loom, my favorite tool of all. We used these tools a lot beforehand, but we really wanted to sharpen our ax and get better use and use them to their full potential. So for example, Confluence is an awesome tool for documenting and sharing knowledge across the company. It's open by default, so it's perfect for distributed teams. But we realized we weren't really using this properly. So what we did was we dived in, we had a look at some of the practices that Mark recommended, and we started to use it. A quick note here before I go on. I'm not going to go get into demo land, where I go deep into the products, but I'd encourage you to come over to our booth at 1349 later on if you are keen to learn a little bit more. But I'll talk about Confluence here. So in the old world, when we wanted to make a decision with me and the product team and my team in America, we would go back and forth on Slack. We would have a Confluence page, but it would lack structure. What we did is we moved everything to the DACI. So this is one of the templates in Confluence. It's a decision... One of those are plays in our playbook, right? One of the plays. It really is. It will change your work life if you download and go through this. So this just stands for Driver, Approver, Contributor, and Informed, and it just makes things so much easier. You have a clear timeline of who's doing what. Everybody knows what they're doing, and a decision goes to somebody on a certain time. And decisions just became so much more fluid. There was less arguing. There was less debating. Or it was healthier debating, I should say, and everything just moved along a lot faster. One other quick example of how we used the plays along with the tools was with the message house in Confluence. So what we found was as more and more customers were discovering the tool and talking to the sales teams, they would go in, and people were building decks to talk to customers or updating websites. And the messaging and positioning was all over the place. It was inconsistent and becoming a bit of a Frankenstein. So instead, what we did was we put all our messaging into the message house, locked it up, and said, "Any messaging that goes out has to come from here." And again, all of our reviews and consistency of our messaging just improved immensely. So and so that pink flashing lights came up in everybody's head. Want to make sure you're awake. - Yeah. - We're not. It's a 10-minute warning. And then there was Loom, which is my favorite tool. Atlassian has since acquired Loom, actually, even though I used it so much. As you can see there, on the left-hand side, I'm in the top 3% All Star for sending Loom videos, which half puts me in stalker territory, I think. - Power user. - Yeah. I think I was joking around yesterday to send my wife Looms, while I'm working as well to other people, and I don't think she enjoys that very much. And again, I'd always use Looms. It's a super if you don't know what it is, it's just an async video recording so you can record yourself talking through something or whatever it might be. But now I really over index. So every other day, I would send messages to my team in America, and I'd say, "Hey, this is what's top of mind, or this is what's a blocker, or this feature has moved or whatever it might be." Same thing with the product side. Often, it was just a social thing. It was like, "Hey, there's not much going on. Everything's the same as yesterday, but hope you're good. I went swimming today." And really, it was great because it tied us together, but it also renewed that human connection that we had, which was really, really important. Because once you have that, you find you're able to move forward much more fluidly as a team. And that's exactly what happened. It's not like we got this perfect overnight, but it was all just a trajectory, like a hockey stick going up for us. And we were able to push forward much better. So there's my little head. The animation didn't work this time. And it was good that we were working together as a team because we were about to hit our next big problem, which is a lack of visibility and transparency.

So I should call out at this point that we had purposely kept ourselves a little bit separate. Because it was a start up within an enterprise, the best way for us to stay agile and move fast was to keep ourselves as disconnected as we could for as long as possible because you have to keep pivoting and changing and the easiest way for us to do that was to stand back a little bit. But the time had come where we needed to plug in more into the mothership. And what was happening was we didn't really have enough visibility over what was happening on the product and engineering side, so we needed to plug into what they were doing and vice versa. Everybody needed to know more about what we were doing. They wanted to see what was working, what wasn't, what work is actually laddering up to a goal, whether it's having an impact that we want it to. And to do that, we had to make a few changes. And again, that's something that Mark knows a lot. Let's sharpen that ax, right, John? - Sharpen the ax. - So it's interesting. When we think about alignment, we get put stuff in a tool to say, all right, this is what's going on. But a lot of alignment is the human element. Work's a human sport. And so for us, when we think about sharpening the ax here, it's acknowledging the fact that, to John's point, early on you might start out in your own bubble, but work is far too complex today. Work requires multiple teams. But the problem is that when we look at most organizational structures, they look like this. They work look like silos, right? Anyone feel the silos in your organization, right? Oh, yeah. The thing is silos provide some value at some level. They give you functional excellence. They give you the ability to figure out how we want to become masters of a craft. But the problem is, is that when we need to work across that because that's usually how work then, we struggle with it. So what we have to do is we have to think about work as not changing our organization, but acknowledging the fact that we actually work in a network. We have to work across the organization. We have to figure out how we actually connect with each other. And what this comes down to, really, if I think about it, it's the relationships we have with those parts of the organization. It's less about throwing a dependency on somebody and saying, "I need this next week," and more about saying, "Hey, John, I need your team's help. Let's talk about this." And actually having that conversation. And for us a really important thing, especially as I mentioned, is it's like even at Atlassian as we've grown. Many of you have seen your companies grow over the last few years. The biggest issue we saw is that those relationships we used to have, have changed. And so all of a sudden, we have to start recognizing what's the health of our current relationships. Are we in a good spot? Are we green? I always think about it. These are the relationships where we know those people. We have a good rapport. Maybe if we're in the same area, we'll go out for a happy hour together. It's great. Then have those cordial relationships, the ones that each other your process, how you work together. And then there's those red ones. Those are the ones where you say, "How do we work around that team?" Anyone try to work around a team in the past, right? Yeah, yeah, I see some noddings, you're like, "Yeah, I did that." But the thing is, at the end of the day, that's not effective, right? That's not efficient. The problem is, again, we have to figure out how we connect together as people. And so one of the things that as Atlassian of the last few years as we've acknowledged this, as we've grown, we started again experimenting internally. And we says we have to acknowledge that we work within this network. And we say every team then has what we call a network of teams.

And what we mean by a network of teams is that when you look at your circle that you work within, you're going to have teams that you work very closely with. You need they're critical to your success. You're also going to have others that you're working with that may be less important, but still needed. And it's taking time every six months or so to assess the health of those relationships. Do I need to build a bridge here? Or is there one already established? And what's the health of that bridge? Now when we go through a network of teams' exercise, we want to make sure, again, we identify the teams that we need. And I mentioned six months, work changes frequently. So again, six months is a good horizon. Because right now, like John's team, right off the bat, they might be saying, "All right, we need these teams' support in the very beginning." But then as they go closer to launching, those teams might change a little bit. And so it's going through and acknowledging this on a regular basis. And as we go through it, it's actually identifying which teams we need to spend time with, and which teams are less critical. So often I find that we have a good relationship with a team, but they're not actually critical to our success. Those are some of the relationships that we were like, "I love you guys, but we have to go and work on this relationship and this other team 'cause we won't be able to deliver without that." From there, what we actually try to do because we've only had so much time in a day, we only have so much mental capacity to actually focus on these relationships. We like to identify the five most critical teams for us. And that's where we spend the most amount of time. We'll actually assign relationship owners to those so that they can identify and work on the health of those teams. Actually, my team works very heavily with some of our other outward-facing teams, like our community and learning team, our PR team, others. And one of the great examples here is we identified from my organization that our community and learning team, that was a rough relationship. It was very reactive. We'd want something. Or like, why didn't you tell us that earlier? And so for us, what we ended up doing is I became the relationship owner. My goal wasn't to get work done between our teams. It was to build the bridge with the head of our community and learning group. It was to figure out how we want to collaborate and work. And now we've got a nice clean process because we focused on the people aspect of that to actually build that process. So let's find out how John focused on the people part of that in his story. Thank you.

So that's what we did. We did exactly that. We went out and we identified all the teams that we needed. We asked, "What do you need from us?" We laid out what we needed from them, and we started to build out those relationships. But to actually execute upon all of this, rather than booking in time and meetings with all of these people, there's also a quicker way to do it, if you sharpen your ax again. So this time, it's a little bit less. I see how many times I can throw that metaphor in. For us, it started with Atlas, which is another tool from Atlassian. It's free, by the way, if anybody wants to give it a go. It enables goal tracking and async project updates, so everybody knows where they are and why. And we started here because every piece of work that every team does should funnel up to a common goal. And I think I realized from speaking to a lot of people this week at the booth that goals and OKRs are something that are static, hung up on a wall. Some of these used to be on the back of the toilet doors in Atlassian when I joined four years ago. But now Atlassian makes it a living thing, something to constantly follow the north star.

So what you do is, on the left-hand side here, you can see that you set your goal in Atlas. So we went in there. We set our goal. We wanted to get to GA by May with X amount of sign ups from beta customers, which is great. Then what you do is you create a project or multiple projects that ladders up to this goal. And in here, you can define what you're doing, why you're doing it, who's involved, and what success looks like. And then this is the important part. When you talk about pulling in all of the teams and getting visibility into your work, you invite all of the people that you need to follow your Atlas project. And this meant that everybody was going in the same direction and contributing towards the same goal, and it all became pretty clear. And if there was any projects that were happening that weren't contributing to this goal, it was really easy for us to identify it and just cut before we put too much time into it. Now of course, just setting that goal and going for coffee is never going to work. You need to communicate this ad nauseam. That's the way it works. So every Friday, the project owner will create a short Twitter or X update like this showing progress or blockers. And you can see as well that you can include, smart links to a Confluence page with all of the documentation. You can include a link to Jira where the work's actually happening. And it really caters to all elevations of flight. So the CEO can quickly go in and say, "Yeah, the project's on track. Awesome." Or if you're a program manager and you need to know what time everything is going out, you can dig in and get to the granularity of the details as well.

And it becomes really, really easy to become a new ritual because once leadership are brought in, and they easily are, it becomes a must. You get an update an email like this in your inbox every Monday with an update of what's going on. And you can also see that it doesn't just happen in isolation as well. So all of the related projects are in there, all of the work happening in Confluence and also in Jira, which was the last step for us. So I know you might be shocked for the company that makes Jira, that we weren't using Jira at this stage because we were a team of two, and then three as we moved from alpha to beta. So Trello served our purposes really well. But it was time to get ready for scale and plug into the mothership. So we moved all our work into Jira. And I know, again, talking to a lot of people in the booth, there's this perception that it's just for developers, which is why we built Jira Work Management, which is built for people made more visual. You've got your list views, your board views, your timelines. You can assign work, track report really easily.

And the calendar was probably the biggest change that we had because it gave us this visibility across teams so we could see what work was coming up for us and when. But better again, we could pull in the release dates from the software team so we could see what they were working on. And what I realized at this stage, and this, again, is probably fairly obvious but I think when we talked about better collaboration with product and engineering teams, you have this idea of us going for picnics together and going to the arcade and cuddling and whatever else. But the reality is well, maybe not... I can't say I've ever cuddled with somebody. No. No. But maybe not. I was an engineer. May be an engineer. But it's actually the opposite. So it just means you stop interrupting each other all of the time. I'm not asking them, "Hey, is that feature date still on time? Are we still going to get the premium edition by this time?" Or whatever it might be. And they're not going to be asking me about campaigns. We just have the shared calendar where we end up having visibility over each other's work. Yeah, trust and shared understanding, right? Trust and shared understanding. So it really made a massive, massive change for us. So again, just the practices, the people, the tools. And all of a sudden, we were looking in good place. We had our ax getting a little bit sharper now. How many more metaphors could I fit into this talk? We had our rituals. We had our ways of working. We had transparency in the right tools. We were feeling good. So naturally, we should've just been able to go off to execute and then go drinking cheap champagne. But of course, life isn't that easy. We still had the biggest problem, which was getting alignment across the organization. So even though we had made progress through the trough of sorrow, my head had bobbled along a little bit, we still had to overcome this problem.

Everybody needs to get aligned. So Jira Product Discovery, when I came across it had huge potential. It still has huge potential for that matter.

And at this stage, everybody could see the progress that we were making. They could see our work, which was great. But we needed to go a few steps further. We needed to get our vision across to them because it wasn't good enough that we were excited about the product. It wasn't good enough that we could see the total addressable market and what we could go after. We needed to get leadership brought in as well, which would make our life so much easier. But Atlassian as he said has what, 12,000 people? Nearly 12,000 people, though. 12,000 people, 14 products, I don't know how many initiatives. So leadership have a lot on their minds. So how do you actually get this across without constantly booking them to meetings? And that was one of the things that we really had to do to share our vision. We needed to do a bit of internal storytelling. Oh, I love that term, internal storytelling. And I think that really goes into our last area that we're going to sharpen this ax with. And for us, it goes back to this idea that you need to know where you're going. You need to know the work. But the reason we do the work is incredibly important. Why? What's the thing we're going towards? And so for us at Atlassian, one of the things that we actually hold very dear, we actually put against all of our work, it's how we hire, all of those elements. It goes back to our core values. We've got five core values that what we use is we use these as north stars. Are we aligned to what we're trying to do when we're doing Jira product discovery? How are we honoring our values here? What are we doing in terms of how we work? Now the thing is, as many organizations have like maybe a corporate vision or something like that to guide them, we use this. But then from there, you still need to have some form of vision, some soty of story of where we want to be in the future. And for us, that's been an incredibly important thing as we've gotten larger. How do we help teams think about where they want to go and why that's a great destination to be at? And so for us, I want to introduce another one of our practice ideas. And it's this idea of creating vision. For us, one of the most important things is actually helping teams see where they're going. And a great example of this actually just so happens to be Jira Product Discovery. It was something that serendipitously, I would talk about vision. And I'd use JPD as an example. And then John and I were going to do this. It was like, "Do I have a treat for you?" I talk about this all of the time. With this idea that we want to establish a statement of where something is going so people know why. And so I actually want to point it out here. So let's take a look at this statement. This is on the front of the homepage on that Confluence homepage for the JPD team. What I love about this is it's definitive about where they want to be and who they want to be. That's what a vision is about. They say JPD is the tool for product teams. Definitive statement. End statement right there. Cool. That's where we want to be. And the reason we're going to be like that is we believe that we're going to make teams better. We're going to actually incorporate customer feedback. We're going to champion the build, measure, learn mentality. It's through things like that, that's what their future they want to look at. That's what they want to experience. And so for them, they use this at that north star from the beginning all the way to now to be able to understand here's who we're trying to honor. Here's who we want to be when we grow up. And so if you're looking at your organization, you're trying to figure out, "How do I establish a vision in my team?" As you'd imagine, this is something that we've established as a process, as a play in our organization. And that's through our vision creation play. It's one of our newest plays because we found that this internal storytelling is so critical to how, whether it be an individual team or a whole piece of your organization works. Because again, it paints the picture of where you're going. It's that hill that we need to take versus saying just do this task. And so when we think about creating a vision, a couple of things I want to plant the seeds for with you on this. And that is when you create a vision, of course, the goal of that vision is to be thinking about what you're trying to create in future. The goal is to be future thinking. It's not how you're going to get there. It's where is that destination at? Where are you at the end of the day? I always like to start, if I have, with something like a company vision, or some core values. What is this serving in your organization? There is something in your company that you can ladder up to with this. Use that as that initial spark to then build your vision and say, "Hey, how are we going in that same direction?" One thing I like to consider when I'm building a vision is I want to make sure I'm considering any goals or timeline horizons when I build it. Because guess what? I can create a kick ass vision that's like 10 years out. But in like John's case, he needs to get something delivered in two years. My vision isn't realistic. It's not going to actually inspire the action I want. So you have to keep those guardrails in mind. One thing that can help connect to people 'cause again, we're talking about storytelling, is you need your protagonist. You need the hero. And that hero is going to be a persona in your story. Who is this helping? How are they experiencing whatever it is you're building? And then finally, I love adding details. Details are the frosting on the cake of a good vision. It's the thing that you'll love. Because what it does is it builds empathy. It launches that oxytocin in your brain where all of a sudden, you're feeling like, "Oh, I could buy into this." So I'm going to pass it back to John so we can show you how he got people bought in to what he's trying to do with Jira Product Discovery. Thank you. So that it's the third piece of the puzzle. We've talked a lot about the practices and the tools. But really, in my experience, the best way to get buy in is to wrap your strategy and your vision up in a story. And I don't mean Cinderella, Lord of the Rings style here. Just any vehicle that will help all stakeholders quickly grok what you're trying to do and get brought in. So I went on the hunt looking for a good framework or a good metaphor and I came across this race car growth framework, which is stolen from Lenny's Podcast or Lenny's Newsletter. Does anybody know Lenny's Newsletter? No hands at all. It's incredible. Now they all know about it. Now they can go look it up, right? I should have claimed it for myself if I'd known that. It was just in case you all knew it. So this is just a race car growth rate. This is used, again, typically for startups, and it's a way of helping to explain how you're going to grow. And this really just changed everything for us because I was spending a lot of my time trying to convince people to build these integrations between Jira Software, where all of the developers live, and Jira Product Discovery, where all of the product managers live. And we needed to build these intelligent doorways between the two products. But there's always this pressure to get more sign ups, more sign ups as quickly as possible, just keep growing, keep growing so the product can get sustained resources and we keep getting people bought in. But when you do it in isolation like that, it does sound fluffy. It does sound like, well, why should we be focusing on integrations? We should just be focusing on going to events, and so on. Here, it became somewhat simpler for me. So I'll show you. I'll start at the top left corner with the growth engine. So this became me talking about the integration, the two-way doorway, which would create a sustainable flywheel, essentially, for us, where product managers would discover it at the right time in the right place and start using it. On the right-hand side, you see turbo boosts. And that's typically what people would expect from marketers. It'd be emails and ads and events and sponsorships. And now it was easier for me to say it's not like we're going to stop doing turbo boosts. It's quite the opposite. We're going to keep those going as much as we can, but to buy us time while we build a sustainable engine over here. I'm going to skip over kickstarts because we're past that and move on to lubricants, which is an awful word but perfect in the case of our story here. Because I'll give one example. When I came into JPD, to Jira Product Discovery, and I tested out the funnel, we discovered that we were dropping a lot of customers through the funnel. And at first, that comes across and looks like a complaint to the teams that build these things. So you just get added to a backlog. It's like, yeah, we'll take care of that when we get to it. But when you reframe it here and you're like, "Hey, we've got this race car which is ready to fly." It's ready to go around the racetrack, and we just need a little extra lubricant to help us get fast. And they feel like more part of a solution and less part of the problem, which is awesome. And then fuel itself, for us, this is going to be different for everybody. For us, this was practices. It was the need to uplevel PMs in the craft of product discovery. And again, you can imagine if I'm doing these in updates to leadership and talking about the need to do practices and how we want to build in education within the product. All of these things can stand a little bit fluffy in isolation, but when you see it as a holistic picture in a car, everything became so much easier. It was one of the greatest things that we ever did. And after that, life became so much easier for us. I just love the visual you use because again, that's a great way to tell a story, is having that visual cue. It is. It is. But having the visual cue is one thing, but then it's like everything else is distribution. It's like a brand, right? So you have to just keep repeating yourself over and over again. And I talked a little bit earlier about Atlas and how we use that, and we pull in all of the teams. So here, we had a common vocabulary in Atlas, and this gave us the ability to actually use the race car growth framework and distribute it.

It became the brand for our launch, essentially. So we started using the language everywhere, every single Atlas update. I would say this week in turboboosts, we got an email out to this group. Or we, in our growth engine, we've done this experiment in products, and we've learned X, Y, and Z. And everything started to become a lot easier. We would embed our Loom videos in the Atlas updates so everybody could see it. We would include it in leadership updates. So for Atlassian, when you're doing an update to leadership, everybody sits there silently reading a Confluence page while you sweat profusely, wondering how bad it's going to go. Now what we were able to do was just talk about this race car growth framework. And eventually, you could see what alignment looks like. This is comments from the CEO, the CMO, and the Head of Accelerator leaving comments on the Atlas updates. You can see they're starting to use the language that we had brought in. They're like, "Hey, John. When's next turboboosts going on? When do you think we're going to have the growth engine ready by? How's the fuel coming along?" Their practice is going well. And they started speaking the language that we had invented back to us. We knew that was alignment, and we had gotten our three biggest problems and our three main hurdles that could have killed us, which was awesome because we managed to get all the way through the trough of sorrow. My little head bubbled all the way. We didn't get everything right. There were obviously more than three problems like that. But I don't have enough hours in the day to walk through all of the problems. So we were very happy to make it through. Well, I think that just is a great segue back to where we started. So you remember this slide. We talked about this aspect that in order to build a great product, yes, you need the right tools. They use the right tools to help them collaborate, connect together. But it was the practices. It was getting intentional with how they worked when they're distributed. It was thinking about how they wanted to align across teams. And then even getting to the point where we had the same shared vision, shared language. When someone starts using that race car example with you, you know you've hit a note at that point. You know you've got a shared understanding of that. So really that comes back to the idea that really good products come from that intersection. So one of the things we want to do before we wrap up is we think it's really important for us to think about how we apply this. Because for me, whatever we do, practice is everything, action is what speaks louder. And so we're ask, what I want to do is we're going to do a little exercise. What I want us to do is we're going to have you pair up. And I want you to think about the story we told you today. Think about the practices we talked about. And I want you to pick one of those techniques that you think would be valuable to run within your team. Where do you think that would help you if you're maybe in that trough of sorrow? What do you think could help turboboost? I'm going to use that word. I love that word. What's going to turboboost you into the next phase? So again, thinking about that, working agreements, network of teams, vision creation. So for me, this is where it comes down to, as you take these things, we've got to go and apply it. And I know John promised he was going to give me more quotes. But I didn't promise that. So but I don't know who this quote came from. I use it all the time. Unknown source. The quote goes, "Dysfunction is the gap between what we know and what you apply." The thing is right now you all identified a practice that you think would be valuable to run in your team, that you think could help you actually move forward. The thing is if you leave today, or maybe you leave tomorrow, you're going to spend an extra day in Vegas. You head back next week. You go to your teams. You're like, "All right, cool. I learned about this great practice. But then you don't do anything about it.

Is that a little dysfunctional?" So you're just sitting there expecting a different result by doing the same thing? For me, I want to encourage you, as you leave today, make a little commitment to yourself. Feel like, no, I want to experiment with this. Those plays that I showed you, they're all out there in the Team Playbook. There's 52 different plays. Those are just three of those. Go figure out how you want to incrementally improve. It goes back to that working agreement. There's that aspect of continuous improvement. We're not talking big rocks. We're talking little stones. Just try little things, something like running a working agreement with your team or doing a network of teams, things like that. So with that said, thank you all for joining us today. Truly appreciate you. [Music]