Video Thumbnail

Lessons from Atlassian | Megan Cook (Head of Product, Jira)

What we put into place is something we call fight club. I'l probably get in trouble for talking about fight club. The first rule is you don't talk about fight club. But it's 30 minutes every week, and it's just for myself, my engineering, and my design leader; and we get together, and we know that we're going there to have a conflict. I think often when there's difficult conversations, or those conflicts come up, you can put them off until they become much bigger. Or if somebody is conflict adverse, they can try to avoid having it at all. But by having a specific slot of time in your week for something like that, then you're sort of in that mindset. You know you're going in there to solve a hard problem. You know that there's going to be a disagreement. And it makes it much better. I think the relationship we all have is so much better because we get on top of these things early.

Today, my guest is megan cook. Megan is head of product for jira, which is used by 75% of fortune 500 companies, 125,000 customers globally, and is by far the most popular project management tool in the world. Megan has been at atlassian for just under 1 years. Prior to atlassian, megan was an analyst, a developer, and an agile coach. In our conversation, we discuss what atlassian has done so right in being able to offer 15 different product lines, which many companies dream of, how they continue to stay ahead of the market in spite of the many competitors in the space, why megan considers play so essential to building great teams and great products, a bunch of tactical advice for getting buy-in for your ideas, tips for being a successful pm in a remote environment. Also, a great story of failure, and so much more; including surfing tips. With that, i bring you megan cook after a short word from our sponsors. This time of year is prime for career reflection and setting goals for professional growth. I always like to spend this time reflecting on what i accomplished the previous year, what i hope to accomplish the next year, and whether this is the year i look for a new opportunity.

That's where today's sponsor, teal, comes in. Teal provides you with the tools to run an amazing job search. With an ai-powered resume builder, job tracker, cover letter generator, and chrome extension that integrates with over 40 job boards, teal is the all-in-one platform you need to run a more streamlined and efficient job search and stand out in this competitive market. There's a reason nearly 1 million people have trusted teal to run their job search. If you're thinking of making a change in the new year, leverage teal to grow your career on your own terms. Get started for free at That's Let me tell you about a product called sprig. Nextgen product teams like figma and notion rely on sprig to build products that people love. Sprig is an ai-powered platform that enables you to collect relevant product experience insights from the right users so you can make product decisions quickly and confidently. Here's how it works: it all starts with sprig's precise targeting, which allows you to trigger in-app studies based on users' characteristics and actions taken in product. Then, sprig's ai is layered on top of all studies to instantly surface your product's biggest learnings. Sprig's surveys enables you to target specific users to get relevant and timely feedback. Sprig replays enables you to capture targeted session clips to see your product experience firsthand. Sprig's ai is a game changer for product teams. They're the only platform with product level ai, meaning it analyzes data across all of your studies to centralize the most important product opportunities, trends, and correlations, in one realtime feed. Visit to learn more and get 10% off. That' Megan, thank you so much for being here, and welcome to the podcast. Thanks so much, lenny.

I am a big fan of your podcast, and i am excited to be here. I have a lot of things i want to chat about. I've heard about many things that you're extremely good at as a leader, as a product leader, and so i'm just going to poke around a bunch of different areas. I wanted to start with something that i hear you're just a big advocate of and really good at, which is creating space for play on teams and also just creating a lot of psychological safety, something that you find really important that helps your teams be as successful as they are. Can you just talk about why this is important to you, why creating play and psychological safety are so important to you, and then just how you do this, maybe an example or two of how you actually apply this on your teams? Yeah, absolutely. I think especially recently in the tech industry, it almost feels like we're going through a bit of a wake-up call at the moment. We were in this time of plenty, and everyone was hiring like crazy, and then covid hit and suddenly people's behaviors had to really change. People couldn't travel; they had to work from home. There's a whole bunch of industries that got highly impacted by that, and it created this time of high ambiguity.

Before that, or to the start of that, i was noticing within my team just some little indicators where people weren't all comfortable to speak up when we'd had really open discussions with the most junior person, where the most senior person were happy to talk about anything. There was more anonymity in feedback. Every time things were coming to leadership to give feedback on, it was just sort of painfully polished. And i think once it gets to that level, that's a really bad time to give feedback, because it probably means that a whole ton of work has gone into it, and you might waste a whole bunch of work if you have to correct direction or make significant changes. And so, i was looking at my team and thinking, "yeah, something doesn't feel quite right here.". And then i went to this leadership outside, and one of the speakers there was ben crowe. He's an expert in having the right mindset. So he works with olympic gold medalists, and ash barty is another one, who's a tennis player. She's the number one tennis player in the entire world. So these athletes who have to really perform under a lot of pressure, in front of a lot of people. And he talked about how to be in that state of flow, where everything is going really well and new ideas are coming and you're making progress, you've got great momentum. And he talked about how to be in that flow state. There needs to be this sense of play and that things are fun. Your mind's open to new ideas, you feel really present. You're not stressing out and thinking about a ton of other different things. And it's funny because when i thought about play where my mind went to the opposite of play is work.

We often hear work and play as opposites together, but his point was actually that the opposite of play is fear. And i realized i think that's what i was seeing a lot of in my team and that's why the ideas were getting more incremental. So took that decision and went, okay, we need to look at psychological safety in that team or we're never going to get to some of these bigger, bolder, more innovative ideas. And so brought my group, product managers together, and we sat around and discussed it and all together came up with some ideas that we've implemented since then, which has had a really good impact. So i'l give you a couple. Yeah, please. One of the first ones was my team of pms is big enough now where not everyone necessarily gets to know everyone else, and when you don't have that relationship, it can feel a little scary. You don't have that trust that you understand how people are going to respond to you and you're not sure about reaching out. So we divided the team into these smaller groups for peer feedback groups and the idea is that they meet every two weeks or so, somebody brings something that's in a pretty rough draft that they want to get reviewed and then everyone's expected to give feedback. And because we've got people in there who are different leadership levels, it's a really good opportunity to model the kind of feedback that's helpful and the culture there is one of everyone lifting that person up to make their work stronger. So people can get in there, they can show that you can show work that's really in the early stages and feel comfortable with that. They can see that getting feedback can actually be really positive and they can see how all of these people together, they can rely on them and forge those relationships so they can rely on more people to help them out. This is so interesting and it's such a good idea and it's such a simple and good idea and i'm surprised i haven't heard of people doing this before. Basically you pair up pms, ic pms and maybe managers too, to give each other feedback. And is the feedback on one-pagers and prds and strategy docs and things like that? What sort of documents are they giving feedback on? So really, it can be anything.

It can be here's a new experience, launching, here's a new strategy. I've taken my own strategies in there and gotten excellent feedback, surprising feedback from the team. Can be a new experiment that people think of running and anything to do with the craft. And i think as you kind of implied, one of the powers of this approach is it's a small team, so it's less stressful and there's no. You're not in the room often too. I guess you are sometimes as you just said, but usually it's like peers and they could be a little more open and less worried about looking back.

Yeah, absolutely. And i think a lot of it is just building that muscle. You might go through an experience once every quarter or once every six months and that can feel really stressful, but if you're doing it again and again, you get used to it. You get used to what to expect, you get a bit more practice, it can feel much more comfortable. That's awesome. So it's just simple and powerful idea. It's kind of like everyone's always suggesting getting a mentor, getting a coach as a pm and those are hard to find. And this is just a little informal. It's almost like a little peer group board of directors for your work. We talk about that on the podcast sometimes. So anyway, that's awesome. Really good idea and something anyone can do. Yeah, thank you. Great. Okay, you have a second idea? Yeah. One of the other things we do is we get everyone together just like every six months. So all of the product managers get together in the same place and the idea is to have a bit of an onsite. Now we start off with just doing something fun because everybody as you might know, atlassian is a remote organization, so everybody works remote all the time. They can work from anywhere. And so people often, they're not used to necessarily being all together in the same place. It can take a little while to warm up.

And then after that we talk about strategy. We do workshops on different elements of craft boosting that craft together. And so a similar kind of thing. People get to build relationships together. They get to see all these different ideas bouncing around which can help uplift their own ideas and help them be more innovative. In this last one, i actually had some senior leaders from all over the organization come and share their stories of failure. So just to get everyone used to that idea that it's okay to fail and actually if the learnings are really good, maybe it should even be celebrated and it's not something to be scared of. And taking the big swing isn't a bad thing. It can be a really powerful way to learn as well. I love that. We've been talking about failure a lot on this podcast, so we're super aligned with the power of that.

And so just to be clear, so what you do there, is it the entire product team of atlassian or is it just your team in this every six month? It's just my team. And then we pull in other product managers that we work closely with as well. And then you fly them all to australia, i imagine? Yeah, all to sydney to sydney. Amazing. Okay. And i think, so the key there is it's not just like go meet each other, it's training almost on different skill sets, helping people level up in say craft or i don't know, communication or writing or something like that. And then who teaches these things? Is it like individual team members or you bring someone in? We have a real mix actually. So yeah,. We'l bring in outside experts or we'l get there's a lot of knowledge and a lot of skill within the team itself. So you'l have different product managers who have different strengths. We have totally different teams. So someone on a growth team, for example, might want to teach everyone about how to create great hypotheses or we'l get someone external from the team, but internal to atlassian who has those skills who can come in. I love that also gives those pms a chance to, one, learn the skill better themselves because they're teaching it, and also just teach and present in public speaking and all that stuff.

There's all these other benefits to doing that sort of thing. Yeah, absolutely. And i think as a product leader, it's really important to model the behavior you want to see from your teams, whether that's getting out there teaching, presenting, explaining different concepts, explaining the business or just being vulnerable and talking about when things haven't worked out. When we started this question, you talked about how there was kind of the shift at atlassian where things started to feel more formal and people started to feel less open to sharing, being criticized in meetings. Just in case people might feel that might be happening in their company, do you remember roughly what size that started to happen at or signs of like, "i'm noticing people are sharing less or being more worried about talking in big meetings"? Probably when we got into really different streams of work that were happening where people didn't have as much of a reason to interact with each other.

So i think that was probably around, even around 15 we started to see a little bit of that. 15 product managers? Yeah. Got it. Cool. That's a good stat. Yeah, you know what, i'l give one more thing that we do. So we've just started trying something new called the $10 game for priorities. And so that's where i think people might have played the $10 game for your priorities when it comes to a strategy or something like that. We started trying it out with your individual priorities. So you and your manager might come in and you can list out all of your priorities and then show you through just dividing up $10 where you're spending all of your time. And i've done this with people and we've sort of gotten down to like, "i'm putting 10 cents here this week.". And i'm like, "oh, what is that? 20 minutes, 30 minutes spending.

I didn't think that's actually moving right.". And so it's been great to see where people are overloaded and alignment on do my priorities stack up, but also am i spending the time on the most important things that could be moving the business forward? Awesome. Okay. So you mentioned that y'all are remote. Has it been remote from the beginning? No, not from the beginning. Actually when covid hit, i think that was the big one. Okay, got it. That makes sense. So a lot of companies are moving to remote work, trying to figure out how to work remotely. It seems like it's working really well for atlassian, at least from what i can see. Is there any advice or any big lessons or tips or tricks you've learned that you could share for how to be effective working remotely, especially as a product manager? It feels like as a pm, the job has gotten so much harder having to be remote, and. So. Yeah,. I'm curious if you just have any advice you could share for people trying to make this work for their company or for themselves? Yeah, absolutely. It's a really good question because it's not easy and we definitely went through a whole bunch of pitfalls at the beginning, but we're really firm believers that you don't need to be in the office to build world-class products. So we call our product team anywhere, and this means that anyone atlassian can choose where they want to work every day. We think it's a bit more human, that flexibility shouldn't be a perk, that it fundamentally can change people's lives depending on what else they have on outside of work. And so we think less about where do you work and we think more about how to be productive and effective in your work. To your point, we started doing this right when covid hit, so it's been about three years and actually we just released a guide with our key learnings from that. It's all about a thousand days of remote work, which folks can go and find on our work life blog under if they want to dive in there more. But i can give you a couple of tips from that and what we found from some of our research. Yeah. And we'l link to that doc in the show notes. Okay, great.

The first one is just making time for connection. So that human connection is definitely built in person, but what we found is that it doesn't have to be something that happens every single day. So we found the connection and productivity, they both get boosted by about 30% when you bring people together but intentionally, and it lasts them months. So we found that you can do it on average like three times a year. And so that's why my pm team are getting together every six months. But in addition to that, we get the entire team together every other six months. So we end up all getting together every four times a year. So every other six months, what we do is we get all of the engineers, designers, everybody who's working together. We book out entire floors in the office and then for an entire week we're just there. And for some of it we're just working together as you normally would, but at desks and just having those little water cooler type conversations. It builds the relationships again. Other times we're doing workshops, an important piece of work where it's easier to do when you're all in person and sometimes we're just having fun together. We call that a bit of a festival. You mentioned that you measured some kind of productivity improvement. Do you happen to know how they measure that because that is really interesting? Oh, that's a good question. I don't, but i can get that for you. That'd be cool to know. So i think we'l keep this in the podcast episode. And then if there's anything in the show notes that we link to that talks about how they measure that'd be really interesting because that's just a cool stat to have anyway, for all kinds of other things. I'm curious how they measure that. Yeah, absolutely. Okay, cool. Any other tips? I think the second one is to be really intentional. I mentioned that we went through a few stumbling blocks at the start.

One of those was immediately, everyone sort of filled up everybody's calendar with all of these meetings straight away. It was almost as if lenny, if you and i were working together, i used to be able to just poke my head around my monitor and ask you something. And people were afraid that now that i can't do that, how do i get those answers? So i need more time with everybody and that definitely does not help productivity at all. And so as pms, we need time for creative work. We need that deep work time, and that doesn't happen when you've got all of these meetings with 30 minutes in between each of them. You need three to four hours to get that going, to get into that flow state. So my leadership team and i, we actually sync up our calendars, so we end up having these long stretches twice a week all at the same time. And so we all get a chance to do this deep work. It means we get less time for meetings, but it also means that if something comes up that's unexpected that we all need to work on together, then we've got that time there so we can be a bit more relaxed about it. We know we can get to it. What time of the day is that meeting? They're both at different times. So the first one's taking up one afternoon and the second one's taking up all of the time in the morning. Depending on what kind of person you are, one is going to see you better than the others. So we just went for one each. I actually had the same thing just personally where i had these deep worked blocked times on monday, wednesday, and friday.

The title of the invite was, "if you book time during this, i'l slap you.". And it really worked well. But i think you're talking about this other missing piece of remote work for pms where you can't just walk by and ask an engineer, "hey, how's it going?". Or ask a designer, "oh, where are you at? Let me just take a peek at what you're working on.". That stuff i think is really hard to replicate. And if your suggestion is block out this time for your leadership team to be able to check in with each other, is the idea there it's deep work time and don't bother anyone on the team or is it you can also just ping your end manager and like, "hey, how's it going?". The idea is that it's deep work time and it's your time to be protected to do that work. What i found that works really well, i think in the manager and report kind of relationship, so i have these really quick punchy one-on-ones with my reports every week. And then i make sure that i've got space in my calendar because something will come up where even if we had a longer one-on-one that might not cover it. They might just need an hour to run through something, there might be a really difficult strategy problem they've run into. And so they'l know that they can ping me for more time and i'l have that flex in my calendar for that. Awesome. Any other tips along those lines? Well, you probably noticed about blocking a bunch of deep work time is that you don't have as much time for meetings. So that meeting time becomes really precious. And what we do there is i personally hate having status updates as a meeting. So i make it really clear that if we're having a meeting, this is to solve a problem. And if it's just a status update, that's fine, then i can read that asynchronously at a time that works for me. And so can everybody else in the team if they want to do that. Actually we use our own tool for this, which makes it really easy. So it's called atlas and it lets you or the team put in status updates for a goal or a project regularly. And then it'l bundle it all up into an email so you can quickly get across everything that you're interested in, which has been really helpful. And then that just makes the documentation rigorous as well. So you document things and we use confluence, but all of our decisions, strategies, kickoffs for projects, that's all really well documented piny starters. Or even if you're a year down the line and you're thinking, "why didn't we come to that decision in the first place? What were our assumptions? What were our hypotheses?".

It's easy to go back and take a look at that and be able to reflect. I think the last thing is i work with people who are in the us, they're in europe, they're all over the world. It's really hard to find a time that works for an aussie, an american and a european to get together. Someone's waking up at 3:0 am or something. So what's become a big part of how we work is actually audio and video recordings. I actually had someone reporting to me for a while who was in france and what we would do was record videos back and forth and they're quick. You can just use colloquial language, they're really casual, you don't have to wonder about someone's tone that comes across.

So that's becoming almost like a completely new document type for us and it's been really important in remote work. You can put at the top of a document and explain the document, which is really nice. It's a big part of why we bought loom. I was just going to say that. It all makes sense. Yeah, because it was just becoming such a big part of our life and it's just massively helpful. Kind of along the same lines, being fully remote, it is harder to get buy-in on things you're working on i imagine. And something i hear you're great at is getting buy-in, especially getting buy-in on ideas and projects from executives. So i think things that make it extra challenging at atlassian, there's two ceos which i didn't know until recently. You're also all very remote and so maybe those two reasons make it extra hard. Plus it's just generally hard to get buy-in on projects that you're working on. What advice do you share with product leaders, pms that come to you asking for advice on how to get better at getting buy-in for your ideas? Yeah, this can be really hard to get right. I watch a lot of people struggle with this, and you're right, being fully remote can make it a bit more challenging.

And then i think also you've got your cross-functional partners that you're working with as this tight-knit team and how do you form that relationship? But i'l start with just general buy-in. Most of the time when people come to me and they want to ask how to get by-in, they've got a date in mind, they've got a particular meeting and they have this idea where they're going to crop this perfect proposal, they're going to present it, everyone's going to give them thumbs up and they win. And that's the wrong attitude i think even to start with to getting buy-in. It's more of a journey. I'l give you an example where i was looking at how do people start their day in jira and how do people get started in jira? And we had this idea of we could craft more templates so that we could give people a better way to start with very different use cases when they came into the product. And this could change everything from even just the front homepage where they started all the way to what's happening in product. It would create this really nice flow. Jira is also a platform as well as just jira software the product. There's actually four different products built on top of it. So when you want to go and change something like that, you're actually changing it for all of these different products.

It's not just the one. And so what was really important there was partnering with a whole bunch of different stakeholders. So every product that this could potentially negatively or positively impact, we went to very early with the idea and the proposal and we got their feedback. And then we came to them and again and again as we developed it further. So as we got designs, as we got more data, as we tested things out with users, we kept coming back and we take their feedback on board. And so i think creating those partnerships is really important. And also the same can be true at the executive level. So often you go into these meetings where you're giving a proposal and you're trying to get that final. Yes on the decision. You've got a lot of people in there with a lot of different angles that they can look at that problem and so much good experience to draw on. So your cto is going to have a totally different way of looking at something and different concerns from your chief marketing officer to your head of design.

They're all going to look at things differently and be thinking about it differently. And so if you know that you're going to be having a big impact in someone's space and you want to hear from them, it's good to set that meeting up early when you've got some clarity but it's not fully fleshed out and so that you can fold in some of their concerns because they'l have this much broader view. And that also creates people who will be an advocate for you once you get into that room, that final meeting. So i think all of those in the lead up, there's a lot of lead up work to getting buy-in that makes sure that you have a good time in that meeting. Just to maybe summarize so far, which you've shared, one is just basically it's lieu people in early, especially the person that it's going to impact most.

I think in addition to that is having that mindset of being open to not necessarily coming up with the right solution, it's more about solving for the problem or the opportunity. So you want to be clear about your hypotheses and what are your facts and what are the principles you're using to make a decision and just be open to not necessarily ending up with the solution you thought would be best. I imagine most people think they are always in that state, "i am very open to feedback. I am totally open-minded, but really they're not.". Is there anything that you think would either convince someone you're actually not as open-minded as you seem or any advice for how to come across as more open-minded? Or is there anything that you see i see this all the time. People think they're listening, but they're not. You should change. I think one way to force yourself into that situation is to be clear about the hypotheses you have and the facts. So i think often people can present as, "this is absolutely the case. This is what i know, and this is obviously the correct response to the situation.". Where most of the time you've got a good set of data, you've got a good understanding with your knowledge of the space, but what is actually going to happen is a hypothesis. There's always going to be something you don't know and oftentimes you don't know until you ship it. That is absolutely the best test of whether or not what you thought was going to happen will actually happen.

And so i think when you come to the meeting going, okay, here's the top-back so we actually know, and here's the hypotheses and here's my plan to prove or disprove them, then you're exposing your idea for people to go, oh, here's more that i know about that hypotheses, or here's some data that you don't have or here's another way to think about it. I think people can feel like they're not going to be credible. That you have to come in, you have to come in confident, you have to come in knowing exactly what that solution is going to be. But i usually find that if you come in there open and you're exposed, you're thinking and where you could use some help on perspectives, that actually that builds more credibility because everyone knows that you are not going to have all the answers and you're not going to be able to see the future. And so that can really help in building people's trust in you and that you know what you're doing. Is there an example of that comes to mind to make it even more real of either someone on your team doing that or you doing that? Because i think it's still going to be hard for people to realize, "hey, i'm not actually paying attention to anyone and i just want to convince them this idea is right.

This is what we're doing. Just come on, get out of my way. Give me the okay.". An example from my past is there was this potential acquisition that we could have made, and i was really keen on it because it would mean adding a whole bunch of much needed capability really quickly to the product. And i just loved that momentum and i didn't see any other way that we could do this. I'd looked at a bunch of other options about building it in-house and it just didn't seem possible. And there were a few people that i needed to convince, my boss, but also the head of engineering for the area. And when i took it to them, what i learned was the head of engineering was able to pull a bunch of people from other areas within the company to come and bolster this effort and who had all of the knowledge that we needed. So what seemed like the impossible task, he actually had this extra knowledge to make possible. And in the end, acquisition or not, that doesn't really matter.

It's more about being able to get that value back to our customers. That's what we're solving for. And so it was really about coming back, not falling in love with that solution and that other company, it was just taking a step back and going, "okay, well, really it's just what are we here to do? What's the real goal at the end of the day?". Awesome. Okay. Is there anything else you wanted to share along these lines before i move on to a different topic? The other thing i would say is that setting up the meeting when you finally get there can be really important as well. I often see people go in there and they've got a big document or a presentation or something and they just launch into it. They're really excited. But actually you want to take a step back and you want to be really clear on what are you looking for from that group. You can ask for the decision, you can ask for feedback, you can ask for you can expose where you're not quite sure about something and you want them to be thinking about that angle in particular and helping test that hypothesis with what they know. And so setting that early, you can put that in people's heads as they read through your document or listen to the rest of the proposal. Then i find it's really useful to have a narrative that just encompasses everything that you're going to talk about. So just really brief, what's the current situation, what has changed and what are the implications that you now want to we mean we have a problem to solve and an opportunity that we can go after.

And the last thing is just making sure you've got your data. There's executives, there's people in the meeting. They're usually across a whole ton of stuff just hearing about maybe they've got 10 proposals a day and they're across all different areas in the business, and so they're not going to have the detail that you do. So being really thoughtful about what you bring, what are the key points that are going to help them understand the situation as clearly as possible. But then really knowing your data so that you can dive in more detail where they need it. And that also helps build your credibility and builds people's confidence in the plan to go ahead. Would you mind just quickly summarizing these pieces of advice. And then i was going to move on to another area of strength of yours that i hear? Yeah, sure. So the first one is to find people who are affected negatively or positively or might have a really good point of view and partner with them as you develop the solution or the response to the current situation. And the second one is to come at it with this mindset of being open, of being really key on what is the core problem or the value that you want to deliver, and just being open to how you get there and things that you don't know which might adjust along the way. And the last one is just setting up the meeting walls. So coming in, making sure that it's very clear what you need. Do you need a decision or something like that? And making sure that you've got very good supporting data to build that credibility with your audience. Love it. This is where the term or the cliche of product managers asking, "but what problem are we trying to solve," comes from. But it comes from a really important place of always focusing on let's all align on here's the problem we're solving. Because oftentimes as you chatted about, the biggest disagreements come from people just thinking they're solving different problems. And on that note, i have a swag store now,, and we have stickers on there, a bunch of cliche pm terms including, "but what problem are we trying to solve?". And so i think that's. But it's rooted in, that's actually a really important question to ask. Sometimes you get annoying. Yeah, that's such a good sticker to have front and center.

Just need that as a big sign. Maybe the sticker needs to be bigger. Exactly. This episode is brought to you by vanta, helping you streamline your security compliance to accelerate your growth. Thousands of fast-growing companies like gusto, qom, quora, and modern treasury trust vanta to help build, scale, manage, and demonstrate their security and compliance programs and get ready for audits in weeks, not months. By offering the most in-demand security and privacy frameworks such as soc 2, iso 27001, gdpr, hipaa, and many more, vanta helps companies obtain the reports they need to accelerate growth, build efficient compliance processes, mitigate risks to their businesses, and build trust with external stakeholders. Over 5,000 fast-growing companies use vanta to automate up to 90% of the work involved with soc 2 and these other frameworks. For a limited time, lenny's podcast listeners get $1,000 off vanta.

Go to, that's, to learn more and to claim your discounts. Get started today. Okay, something else that i hear you're incredibly good at, and it's actually related to all of these things we've been talking about, is the way someone described you is you're really good at fighting the good fight, which essentially is just doing the things that need to be done that aren't necessarily popular or that people are prioritizing right now. I hear that you led to a big investment in csat at atlassian because you just felt like this was the right way of doing it. And there's a few other projects that came out of just like, "i'm just going to do the thing that needs to be done.". Can you just talk about why that's important to you, what impact that sort of had, and then just how you actually successfully do that? Obviously it ties into this skill of getting buy-in on stuff. I think that's a really good example actually, the csat example, because sometimes you can get caught up in let's add value, add value, add value to the product, but if the customer aren't satisfied with what you built, or in our case we found that one of the core reasons was the usability, it wasn't where it needed to be. Then we can't access that value anyway. It doesn't matter. And sometimes it can be hard to get investment for things like that because it's not like the shiny, exciting new thing.

It's no, i want to work on the features we already have and improve those. So it was about two years ago, our chief experience officer, he cared really deeply about improving our csat scores and asked me to look into it. And this-. Briefly explain csat real quick. Some people may not be familiar with that term. Oh yeah, absolutely. Of course. Csat means customer satisfaction. So for us, we actually have a survey so that we can measure csat and it just asks customers to rate how satisfied they are with the product and then different aspects so we can see for different tasks that they need to perform or different aspects of it, like the reliability or the speed or the usability. How do customers feel about that? We actually had a podcast episode recently judd, where we talking about nps and how much there's data showing it's not actually a great predictor of anything, and he's a big fan of csat instead. So you could almost think of it as little replacement for nps in a lot of cases. And i'm sorry, pushed you off track. Keep going. Yeah, no worries. So he cared really deeply about this, asked me to look into it. Even though this request was coming from the top, that doesn't mean that it gets any sort of funding. So we went through a couple of different steps to see what was worth investing in here.

First of all, i mentioned we had that survey and so we had really rich feedback. So it's not just a rating, what we get, we get people talking about why they gave that rating and that can really help us zero in on what are the key aspects that's bringing this down. And we also had great conversations with our customers. It was the kinds of conversations that are really rich and really helpful, but so painful to listen to and go through because you're seeing somebody really struggle with something that you thought was going to bring them so much value. And then we had a look at, well, what is this going to impact? And so logically it's what we found was that usability was one of the key reasons, like i said. And logically, if your product is hard to use in places, if some of the core actions are hard for people to do, then a new user to that product or a new customer is going to have a longer ramp up time. You've got a harder time showing them that there's value. And even for an existing customer that's using your product really well, when they bring on a new user, that user might have a really hard time getting up to speed and using it and it just completely slows them down. So from a business point of view, it can impact your new customer acquisition as well as your ability to expand. So there was some good revenue connections in there as well.

What i also found was that we have a lot of dependencies. So we've got all of these platform teams and a lot of the improvements that would be really good to make to sort out this problem depended on many teams around atlassian. And they all had different goals and other products that they had to serve too. I don't know if you've ever tried to align three or four different roadmaps so that the timing is just right to get some improvement through, but it's basically impossible. There was no way that was going to happen. But we did find that they were really passionate about this area and improving usability. So we worked together to find a low cost way for those teams to help us make the changes that we need to, but they didn't have to bear the brunt of all the development costs. So each of those teams flipped forward, we call them a shepherd, so that as our developers came in and made changes in the code base that this shepherd would make sure that they weren't causing any issues and we're doing reviews and reviews of designs and things like that.

And so getting that buy-in, finding the data to support the reason why this was important. And then we constructed the roadmap so that we found this sort of a low cost, very cheap way to have some impactful change early on. I think that was really important. And so we put together just some of the designs for what the experiences were going to look like. So our head of design, charlie sutton at the moment has this great mantra of show don't tell. And in this case, it was just at the core of getting people excited because you could show the initial experience, you could show the pain, you could bring in a video of the customer trying to use it and what they thought of it. And that just really brought that emotional aspect to it helped get people on board on the issue, the new experience, which is just far and away molds better, might cut out like 20 clicks or whatever. And so all that worked together to get the investment that we needed. I think the last thing that was useful there actually is that we started pretty small too. So i think if you have a hypothesis and you can start small, you can get that investment more easily, you can show success, you can always build on that in the future to get more and more.

But in this case, we got about 40 people to come and join onto this. And then as we shipped things, we just made sure that it kept being quite small. And so we got that momentum really quickly. We kept with regular updates, we kept up the excitement about what the team was doing. At one stage, the team picked out something that was pretty impactful throughout the whole thing. So that was dark mode. That took a lot of coordination around the whole company to make that thing happen. But it was well overdue, we loved it. And then the feedback that we got as well really helps with that. Actually just yesterday, i saw some feedback on one of the changes we'd made recently, and this customer said it was the best quality of life improvement they've seen in a long time, which just the way that's phrased even, that gets you excited about the impact that you're having on that person. And this was the csat work or the dark mode? This was csat work. This was improving one of the processes. Okay, cool. That's amazing. There's a lot of stuff i love about this story.

One is just the power of just empowering yourself to do things that you believe need to be done. There's a lot of pms and just people in general that just assume they don't have any power and the square peg they're in is just all they're going to be able to do and nobody's going to allow them to do things that they believe are important and no one else agrees with. So i think there's just a lot of power in just understanding that you have more power and leverage and agency than you probably think you do, but then you also have to do it well. So i took a bunch of notes as you were talking of the things that i think are core to getting stuff like this done, just a scrappy project that you're kind of doing on your own without a lot of buy-in from the top initially. So i want to stay small. Two is make it visual and visceral. So you can like, "oh wow, i could see this being amazing," and getting people excited as you go. Making it really easy for people i think is a really interesting takeaway there. Just like, "we did all the work for you already for these other teams, it's going to be so easy. It's not going to be a lot of work for you.". And then showed the data like, "here's what we've gotten from csat so far, here's the impact you'l probably get from it.

Here's how much work it'l take.". Show actual data. And then keep it scrappy. It feels like a lot of this is just like stay small, keep it scrappy, don't ask for a lot of resources initially and just kind of show momentum. I think that's really important. When you keep it scrappy and small in the beginning, it doesn't feel like it's as big of a bet, but that gives you the opportunity to really prove that the direction that you're going in could pay off. And so it's sort of like this little inroad to getting more investment. Awesome. Okay. I want to move to a different topic around atlassian as a company, but is there anything else you wanted to share along those lines before we do that? No, let's go for it. Okay. One of the most interesting things about atlassian to me is it's a great example of a company that's been able to launch new product lines. This is the dream of every software company business in general is you start with one product that gets to a certain point and then you hit some kind of plateau, and then you add an additional business product line, and then you add more and more. Somewhere around atlassian's 15 products. Is that an accurate number? Yeah, that's right. Yeah, we are up to 15. Yes. Jesus christ. Amazing. So this is very rare and the dream of many companies. And so i'm just curious what it is you think atlassian has done so right to have so many successful individual products? You know what, it's not like we added the first product and got it just right way off the bat. So yeah, 15, we've had a lot of shots at this, so i might talk about two examples. I think the first one, if i think about jira software, it started just as a really humble bug tracker. That was it. There wasn't as much to it, and then it sort of weathered these massive changes in how people build software. So it launched in 2003. And if i remember correctly, just to date this, the mobile phone that was most popular at the time was the nokia 6100. I don't know if you ever had one of those. I don't remember what that specific one was, but i'm picturing a nokia phone. It's like a little small brick. Yeah, it was my mother-in-law's favorite phone. It took us forever to get her off that onto something better. But there's a lot that's changed since that time.

There's been agile, there's been cloud. And what we saw recently was more in the expansion of software teams. So they used to be extremely developer centric. And i think most people when they think about jira software, they think, oh, that must be, well, 80% developers that are using it. But actually it's more like 50% or maybe just shy of 50% are developers. And the rest is this huge mix of support in operations, in sales and marketing, finance, design, hr, legal, just this massive mix of everybody, all the roles you could think of in a company basically that get in there and make work happen.

And so what we saw years ago was, well, software teams aren't just developers anymore. And we saw this in our teams as well, but we saw that these other teams, the finance, the marketing teams, even design teams were sort of cobbling together their own solutions. So jira software is incredibly flexible, which is a massive pro of it. That these teams were seeing software teams get more effective at the way they were getting work done and collaborating better. And they wanted that same benefit and they started using jira, but we hadn't set it up well for them at all. So it was quite difficult for them to do that. But the positive was that there was this really good signal from our users that they were looking for more from us, and we knew that your marketing team is going to work differently from your developer team. That's how it should be. And so we started jira work management to be more focused on all of these other use cases outside of the software team that our users were asking us to go ahead and solve.

So that was a really great way to discover the need for a new product. Were these really strong signals from within our customers in that same area of business that we're really well set up to help them learn. What was that process like from noticing, "hey, designers are using jira and they're not having a good time. Pms are using jira, researchers, and here's the issues they're running.". So just that insight of like, "oh, interesting. There might be an opportunity here to launching.". I don't know the first version. I don't know if you're actually involved in this, but whatever you can share would be awesome. Where there design partners they all chose and like let's work with salesforce and microsoft and make sure they love it? How long was that process? Because i think that's the prop people are so curious about just how do we validate and discover and then actually launch something that's going to work. Yeah, i was just as close to that one, but i can give you a second example. Oh, great. Yeah, for sure. The second example actually came from our product internal innovation program and that we let anyone pitch an idea for new product in the company if they want to.

So we had this wonderful product manager, tammy carson, who saw a demand for a solution for product managers to build their roadmaps a bit better before ideas get committed. So as you know, this is fuzzy area before you actually start building something as a product manager where you're looking at lots of opportunities and ideas and you're prioritizing them. And it's not really confirmed real work yet. And nobody wanted to put that in jira because once it was in jira, then everyone just expected it to happen.

And so this is where jira product discovery came from. And in the past we'd tried things like this before in new products at atlassian and they've been successful, but it'd been really hard because large parts of the company process and those checks were optimizing for the success of the bigger products like jira software. And so we changed that to create really small groups with stage gates that we call wonder, explore, make, impact, and then getting to scale. And that meant to assess those bets at every stage. And the idea was to iterate really quickly, either to it not working out and proving that it couldn't be a business or iterate really quickly to yes. It could and we should invest more in this. And so with each stage there would be a little bit of investment. So you say that for a stage of wonder might just be the person with the idea. And then explore, you might add on a couple more people, like three people to go and really have a look at, here's a prototype, here are some customers that'd be interested in it and could help us think about this some more and put together what the roadmap looks like. And then when you get to make that's when you get a full team, but a full team is going to be 12 people or so, it's still not huge. And i think that's really important because at each stage you're getting validation, you're getting more customers who are interested and invested in helping you develop what that solution looks like. You asked about whether we went and partnered with a partner company like salesforce for something like this, for a new product. In this case it was just really partnering heavily with our customers where we saw that interest coming through in our other products like jira software and building something that really works for them before expanding it to more and more customers and finding that product market fit and then upping the investment. And so we've had a couple of new products recently that have gone through that sort of stage rollout. So there's jira product discovery, there's atlas that i mentioned before, and i think compass is the latest one.

So what i'm hearing here is essentially there's this step-by-step gated process that you put new product ideas through and they make it one step at a time. And i imagine there's a leader that can decide, "no, this one's not working out. Let's end it at the explorer phase and invest in other ideas.". I imagine yeah, that's right. It might be someone who's looking after that particular market. At each one of those stages, there's that check on whether or not we continue to go ahead. And the stages are wonder. I like that a lot. That's a great name. Explore, make, and then what were the other ones? Impact and scale. Got it. So impact is like is it showing any impact? We made it, is it working? And then scale. Got it. That makes sense. Just like let's go for it. Yeah. Impact could be i can be self-sufficient in the revenue that i'm generating, and scale is just really launching it to take off. Launch it. Yeah, it goes on the website. Okay. So wonder is like a pm and an engineer maybe at hackathon where we have an idea. Explore is they maybe get a little bit of resourcing and they start exploring the idea, build the prototype, maybe find a design partner too, to think about this. Is that roughly right? Yeah. Okay. Make sure you've got a clear roadmap. Yeah. Okay, got it. And then make, is that where they expand it to a few more customers and make it more fully featured?

👇 Give it a try