Lessons from Atlassian: Launching new products, getting buy-in, and staying ahead of the competition | Megan Cook (head of product, Jira)
4 Feb 2024 · 81 min
Megan Cook, head of product for Jira at Atlassian, talks through launching new products, building psychological safety on teams, and getting executive buy-in. She covers how Atlassian stays ahead of competition and what metrics like CSAT actually tell you about your product.
What we put into place is something we called Fight Club. We'll 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 in 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, you know, like 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. And 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 11 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, 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 tealhq.com/lenny. That's tealhq.com/lenny. Let me tell you about a product called Sprig. Next-gen 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 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 real-time feed. Visit sprig.com/lenny to learn more and get 10% off. That's S-P-R-I-G.com/lenny. 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. Could 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, like maybe an example or two of how you actually apply this on your teams?
Yeah, absolutely. So 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 or 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 offsite and one of the speakers there was Ben Crowe. and he's an expert in having the right mindset. So he works with Olympic gold medalists and Ash Barty is another one. He's a tennis player. She's the number one tennis player in the entire world. So these athletes, you have to really perform under a lot of pressure, you know, in front of a lot of people. And he talked about how to be in that state of flow, you know, where everything is going really well and new ideas are coming and you're making progress, you've got great momentum. And you talked about how to be in that flow state, there needs to be this sense of play. And that's, you know, 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, right? 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 I 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 I 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'll give you a couple.
Yeah, please.
Yeah, 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 I'm, it's like 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 like one pagers and PRDs and strategy docs and things like that? What sort of documents are they giving feedback on? So it's really open ended.
It can be anything. It can be here's a new experience, Grillo Kiefer 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 in your experiment that people think of running and anything to do with the crop.
And I think what's, 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, like, you're not in the room often too. Like, 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 bad.
Yeah, absolutely. And I think it's just 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.
Such a 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 like 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. 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 sort of see all these different ideas bouncing around which can help uplift their own ideas and help them be more innovative. And this last one, I actually had some senior leaders from all over the organization come in 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 when 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, right, we're super aligned with the power of that. And so just to be clear, so what you do there is, is it the entire product team of Atlassian or is it just your team in the six, every six months?
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'll bring in outside experts or we'll get, there's a lot of knowledge and a lot of skill within the team itself. So, you know, you'll 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. Well, we'll get someone external from the team, but internal to Lassi, he has those skills who can come in.
I love that it also gives those PMs a chance to one, learn the skill better themselves because they're teaching it, and also just teach and present and public speaking and all that stuff. There's all these other benefits to doing that sort of thing.
Yeah, absolutely. And I think, you know, as a product leader, it's really important to model the behavior you want to see from your team. whether that's getting out there and 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 and being criticized in meetings. Just in case people might feel that might be happening in their company. Do you remember roughly when 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 sort of 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'll 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 down 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, is that, what is that? 20 minutes, 30 minutes, I think spending. I don't think that's actually moving, right? And so it's been great to see where people are revolting and alignment on, you know, 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 and has it been remote from the beginning?
No, not from the beginning. Actually, when COVID hit, I think that was the big move.
Okay. 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 cuz it's not easy and I, 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 approach team anywhere, and this means that anywhere at Atlassian, anyone at 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? Can we think more about how to be productive and effective in your work? To your point, you know, we started doing this right when COVID hit. So it's been about three years. And actually we just released a guide on with our key learnings from that. It's all about, you know, a thousand days of remote work, which folks can go and find on our work life blog under research@atlassian.com 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 research.
Yeah, and we'll link to that doc in the show notes.
Okay, great. So 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 that connection and productivity, they both get boosted by about 30% when you bring people together, but then intentionally. And it lasts for 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. For some of it, we're just working together as you normally would, but at desks and just having those little, you know, 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. So 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? Cause that is really interesting.
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'll keep this in the podcast episode, and then if there's anything in the show notes that we link to that talks about how you measure that, that'd be really interesting. Because that's just like 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. So I mentioned that we went through sort of a bit of 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, like straight away. It was almost as if, you know, Lenny, if you and I are working together, I used to be able to just like poke my head around my monitor and ask you something. And people are 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, right? And so, you know, 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 sort of, you know, 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 age.
I actually had the same thing just personally where I had these deep worked and blocked times on Monday, Wednesday, and Friday. The title of the invite was, if you book time during this, I will 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? Ask an designer, oh, let me, where are you at? Let me, you know, I just take a peek at where you're working on. Like 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 like, end manager and like, hey, how's it going?
And 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 relationships. 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, right? 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 all know that they can ping me for more time and I'll 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, but 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. We 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'll 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 for new starters. Or even if you're, you know, 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. And I think the last thing is, yeah, 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 well for an Aussie, an American, and a European to get together. You know, someone's waking up at 3:00 AM or something. So what's become a big part of how we work is actually audio and video recordings. So I actually had someone recording 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, you know, 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 has 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 gonna say that. It all makes sense.
Yeah, because it was just becoming such a big part of our life, right? 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 know, 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'll start with just general buy-in. Most of the time when people come to me and they want to ask how to get buy-in, they've got a date in mind, they've got a particular meeting, and they have this idea where they're going to cross 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 by. And it's a more of a journey. So I'll 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 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 feedback on board. And so I think creating those partnerships is really important. And I will say 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, you know, 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, right? 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, you know, 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'll 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, what you've shared, one is just basically it's lue 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, right? 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 there you see like, I see this all the time. People think they're listening, but they're not. You should change.
I think one way to be, to sort of 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, you know, 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 know, 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 backs 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 in 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, right? 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 expose your thinking and where you could use some help on perspective, 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 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 be like, 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, really keen on it because it would mean adding a whole bunch of much needed capability really quickly to the product. And I just love that momentum. And I didn't see any other way that we could do this. So 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, you know, 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 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, you know, 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 were solving 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 know, 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's, that you're going to talk about. So just really brief, like, 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, an opportunity that we can go after. and the last thing is just making sure you've got your data. And the people, there's executives, there's people in the meeting, you know, they usually across a whole ton of stuff just hearing about maybe they've got 10 proposals a day, right? 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 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, or 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 rules. 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, lenny.swag.com, 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 Vanta front and center. Yeah, I just need that.
It's 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, Calm, 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 vanta.com/lenny. That's V-A-N-T-A.com/lenny to learn more and to claim your discounts. Get started today. Okay, so 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 sort of impact that sort of had, and then just like 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 customers aren't satisfied with what you built, or in our case, we found that one of the core reasons was the usability 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 you know, the shiny, exciting new thing. It's, you know, 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 maybe, you know, briefly explain CSAT real quick, because some people may not be familiar with that term.
Oh, yeah, yeah, absolutely, of course. So 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 where, with Judd, where we talked 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 a little replacement for NPS in a lot of cases. And then, sorry, pushed you off track.
Keep going. Yeah, no worries. Yeah, 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. So first of all, I mentioned we had that survey, and so we had really rich feedback. So it's not just a rating for 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, 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, right? 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 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. dependent on many, many teams around Atlassian. They all had different goals, right, and other products that they had to serve too. I don't know if you've ever tried to align, you know, 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 in 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 put forward, like we called 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 were 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 like a low-cost, very cheap way to have some impactful change early on. I think that was really, really important. And so we put together 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 a customer trying to use it and what they thought of it. And that just really brought that emotional aspect to it. It helped get people on board. And then you show the new experience, which is just far and away more's better, you know, might cut out like 20 clicks or whatever. and so that 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 was quite 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 up 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, you know, the feedback that we got as well really helps with that. So I 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, just the way that's phrased even, you know, that gets you excited about the impact that you're having on that person.
And this was the CSET work or the dark mode?
This was CSET work. This was improving one of the processors.
Okay, cool. That's amazing. There's a lot of stuff I love about the 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 they'll light 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 like a scrappy project that you're kind 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. Like, 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 could probably get from it. Here's how much work it'll take, like show actual data. And then keep it scrappy. It feels like a lot of this 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 that that gives you the opportunity to really prove 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. So 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 right at Last.fm has 15 products. Is that an accurate number?
Yeah, that's right. Yeah, we are up to 15 million. Yes.
Jesus Christ. Amazing. So this is like 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 of this. So I might talk about two examples. So I think the first one, if I think about Jira software, it started just as a really humble bug tracker. that was it. There was, 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, like just to date this, the mobile phone that was most popular at the time was the Nokia 6100. I don't, 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 brick. It was a 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, right? 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, like 80% developers that are using it. that actually it's more like 50% or maybe just shy of 50% are developers. And the rest is this huge mix of support and operations and 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, you know, years ago was, well, Software teams aren't just developers anymore. And we saw this in our own teams as well. But we saw that these other teams, the finance, the marketing teams, even design teams were cobbling together their own solutions. And Jira software is incredibly flexible, which is a massive pro of it. But 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, you know, 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, to go ahead and solve. So that was a really great way to discover the need for a new product where these really strong signals from within our customers in that same area of business that we're really well set up to help them.
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 like that insight of like, oh, interesting. There might be an opportunity here. to launching it. I don't know the first version. I don't know if you were actually involved in this, but whatever you can share would be awesome. Were there design partners they all chose and let's work with Salesforce and Microsoft and make sure they love it? How long was that process? Because I think that's the part people are so curious about. How do we validate and discover and then actually launch something that's going to work?
Yeah, I wasn't as close to that one, but I can give you a a second example.
Oh, great.
Yeah, for sure. So the second example actually came from our product and channel innovation program and that we let anyone pitch an idea for a new product in the company if they want to. So we had this wonderful product manager, Tanya Kristin, who saw demand for a solution for product managers to build their roadmaps a bit better before ideas get committed. So as you know, there's all of this, there's this fuzzy area, right, 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 we tried things like this before in new products at Atlassian, and they've been successful, but have 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, so yes it could, and we should invest more in this. And so with each stage there would be, you know, 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, you know, 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, you know, a full team is, it's 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. So 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 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 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. Imagine.
CB: yeah, that's right. It might be someone who's looking after that particular market. Yeah, 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. 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? Like 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, you know, I can be self-sufficient in the revenue that I'm generating, and scale is just like really launching it to take off.
Yeah, it goes on the website. Okay, so wonder is like a PM and an engineer, maybe at hackathon, we have an idea. explorers. They maybe get a little bit of resourcing and they start exploring the idea, build the prototype, maybe find a design partner to think about this. Is that roughly right? Yeah. Okay. Yeah.
Make sure you've got a clear roadmap. Yeah.
And then, okay, got it. And then make, is that where they expand it to a few more customers and make it more fully featured?
Yeah. So make is where you'd actually build it. So the prototype Pretty simple, could be a bit cobbled together. Make is actually building the product and see if you can get more and more customers. That's where you'd start to make it with those customers. This is really interesting because again, I.
Think Atlassian is one of the very few companies that has done this so well. And I don't know, this number is absurd. I've never heard of another company that has 15 successful products. I don't know how successful they are, but they're out there and people seem to be, they're being promoted. I guess is there any other advice to share along the lines of if someone is thinking about launching a second product? anything you would suggest they do or think about that may not be thinking about?
Yeah. And I think my advice is sort of skewed towards the Atlassian case, right? Which is where you're in a 12,000 strong employee company and how do you seed something that you want to run with more of a startup kind of mindset? So when you get to this size, you've got like quarterly planning and business reviews and all of these different processes and you you don't necessarily want to put your seed startup through that. It's not quite ready for that kind of thing. So I think the key things here that make it really successful is starting really small with the idea and the solution to be proved and don't add too many people. Don't feel pressured to add too many people. I think it's easy to get really excited about the potential and just want to throw four or five teams at it, but that can like we were talking about this stuff, that can make things run slower. And so you want to protect them. And the second thing is just give them freedom to move really fast and solve those problems in a different way. So there are different expectations. They don't necessarily need to be a part of that process that I was talking about before. This team should just be running hard to prove whether or not the idea is going to work, whether this product market fit. and for different approaches, you know, if I, if I want to add something to DurosoftwAre, we're talking millions and millions of users there, you know, that thing has to be resilient, it's got a scale, there are all these things that users inherently expect from something like that. But for something small like this, we are proving product market fit. You don't need to think about that initially. So you've got to hold this to a different standard. Otherwise, you're just going to slow them down way too much. and actually we found that by letting them tackle problems a little differently, we found innovative way of looking at things that we can pull back into our other products. So for example, if you look at our Jira product discovery, just the way that it gives more of a spreadsheet kind of view of a list of ideas and things like that. Some of the experience there is definitely something that we'll be pulling into Jira software.
You mentioned that over the years, Jira has weathered many storms. From my perspective, it feels like it continues to weather many storms incredibly well. One, because there's just endless startups always coming at Jira trying to become the new project management tool that everyone uses. And two, it just feels like people are always dissing on Jira. Like, Jira sucks. I want to use something else. On the other hand, it continues to dominate. Many people love it. I'm curious what you believe Atlassian generally has done and your team has done to keep Jira ahead of everyone. And I know you're probably going to say, We listen to customers better than anyone. So if that's a big part of the answer, definitely share that. But I'm curious, is there anything else people may not be recognizing of just like why Jira has been so successful for so long?
Yeah, so I think the number of startups that enter this space just shows how important the problem is that we solve and that problem of teamwork and collaboration. We've got more than 125,000 customers around the world who start their day in Jira, you know, millions of users. and the kinds of companies that use it, I just love hearing about what they do with it. They really blame me away, like NASA landing the Mars rover, right? Or Canva building this design platform for 40 million people. It's just massive.
I don't think you can beat that Mars rover story, right? That's a good one. I think when you follow it up with the Canva story, that one's less interesting now, but it's also amazing. Okay, sorry, keep going.
I'm sorry. yeah, they're, like he said, they are integral to our success, right? We do obsessive over them. We think if we do right by them, then we're going to be going in the right direction. I don't think we've ever had this sense of, you know, arrogance of just no matter how big we are, we've always got this healthy dose of paranoia that we, we need to keep working on improving things and being better. So we, you know, to your point about customer feedback, that is a big part of it. We bake in these rituals just to make it super easy for everyone to do that. So the, you know, the whole company gets an email every week and it's just got a random selection of feedback from our customers. It's got, you know, how they rate us and just a quote as well. And so everyone's sort of getting this dose of feedback all the time. We have regular share outs of all of the research that everyone gets. We get in product feedback. We make it super easy to talk to our customers through social media or, you know, LinkedIn or X now. And then we also have a whole Community space where customers can have longer conversations with us about different ideas that we're coming up with or feedback that they have for us. So I think, I think that is massively important for keeping Jira ahead of the pack. I think how we stay ahead in other areas is just that the culture is super, super open to innovation, kind of invites innovation. So we have these hackathons, we call them ShipIt. Everyone, the whole company stops and everyone can play with new ideas of technologies. It's a competition. So the best ideas get visibility, it can get people working with other people that they wouldn't normally. And also the visibility of the ideas helps generate more ideas all over the place. Like I said before, innovation can come from anywhere, so anyone can pitch new ideas or products. And when we see new technologies emerging that we think are going to be really foundational and interesting, we'll carve off a team to go and look at that. So I think, you know, we've had an AI team central to Atlassian for a long time, but with the advent of ChatGPT, there's sort of like this huge move forward, right? There's this leap that's happening. And so in my team, I just carved off a small team to go and explore that and see what interesting things that we could do there. I think we don't shy away from tackling sort of subsets of the market that we're seeing that need a bit more love. So, you know, that like the Jira product discovery story that we were just talking about a second ago. And we also use our products a lot, and that helps us find all of those little problems and makes it really real. We get really excited about the different things that the whole team is working on. And we send lots of feedback to each other. I think that's also a really important part of it. Another area is when we look at how we're investing, you know, there's always this pressure to invest in the core business, of course, but we also make sure that we invest in seeding future businesses. And like we're talking about, they might not always work out. So we had that the compass in the Alice example of ones that have worked out. But we also see things through at last inventions. So if there are interesting ideas or technologies, these might support the product later on. That's something that we'll go and see it out there in the market. And that's led to a few acquisitions as well, which has been really useful. And the last thing is, I think I'm just really impressed at the way that we stay agile to move towards these different shifts that come up. It always surprises me just how agile we can be. So, for example, in 2020, we decided to double down on our mission to deliver a world-class cloud experience. And it was just, it was like hundreds of people just moved around in Atlanta to make that happen, which was in a very short period of time, which was impressive. And we're not shy about killing things off with OKL. So I'll give you another example of one of those products that was going through that we ended up killing off. So we had a whiteboard product that we thought would be its own product, sort of like a Jira product discovery. And when we came to one of those gates with the team, we realized actually, you know, this is more like a really useful document type. And so now you'll see that it's a feature in Confluence, but it was very quick to make that decision.
I have this new segment, not that new anymore, called Failure Corner. I'm curious if you have any interesting story of a big failure in your career. And if you do, what you learned from that experience.
I think I'll give you a bit of a different one because I think this one is harder to spot. And I think that's really interesting. It's something that I think about all the time, though. So I missed a really big opportunity to move atlassian forward when back in the day. And Yeah, like I said, I think about it every time I review a new idea or look at an opportunity that we're thinking about. So I was on this team and I was improving the way that our products help developers get their work done. And so typically we saw them start in Jira software, they pick up a piece of work, and then they'd switch tools. They create a branch, they'd start writing code, and we noticed that they would forget to come back and update the status of their work. And this could create a lot of confusion in the team, right? Another developer could pick up that work, think it was wasn't started and then there was a lot of wasted time. Or if you're trying to track metrics, like how long does it take for a piece of work to get started to through to done? That'll totally skew things. So this was causing a lot of problems. But we didn't want to make developers come back into the tool. That was obviously something that was getting in the way of their work. So we decided to build automation so they didn't have to. They didn't have to leave their or the command line to do that, they can just keep working. So an example is Jira would detect that a new commit had been created, and then it could automatically move your piece of work to in progress because there's code being written against it. And there are a whole bunch of these examples that parties integrated into it. And I made the decision to put into Jira as a user was editing their workflow. and it, and we shipped it and it performed just fine. People discovered it, they used it, it seemed to give a lot of value to people liked it, which doesn't really sound like a fail. I don't think that where I dropped the ball was more about what I should have realized about that feature. So automation, it's super useful. It can be used by a whole slew of people who aren't just developers. It could be used in every single product. it's more than just moving things to a new status. And so I should have realized that we could have built this amazing service that every product could have moved themselves forward with. And years later, Atlassian actually acquired a company that did exactly that, this advanced automation. And it's in every product now. And so you can imagine how much it costs to acquire a company. That was a really expensive mistake on my part. So when I see a new idea, I'm always asking myself, how do we push this further? Is there something there that we can 10x? Can we apply it more broadly to more types of users, more products? Is there some bigger opportunity that we can really take advantage of?
That's an awesome story. So the lesson there is just think bigger with the products that you, like you almost need to wait for it to first be successful, right? For you just to be like, oh, but can we do something more with this? Would you think you should have been thinking about that as you were building it or would that have been too early?
No, I think I should have caught that as we were building it because even when I think about the experience, so it was a really good proving ground for it for sure, but even when I think about the experience, just where that experience was designed and product limited its functionality, which is a real shame.
I guess the takeaway there is just If you're committing to some idea, ask yourself, what would it look like if this was 10 times bigger? If this was a bigger deal, can this apply to other things we're doing? Is that right? Yeah.
Where could this go in three years, five years? And should that change the way that you think about it now?
Great advice. Megan, is there anything else that you wanted to share or is there anything you wanted to leave listeners with before we get to our very exciting lightning round?
I will leave you with something. And it's just this practice that I found really useful for my squad that we've implemented pretty recently. So I think, and especially with remote work and all of that. So like I said, we have limited time together, but what we put into place is something we called Fight Club. I'll probably get in trouble for talking about Fight Club. The first rule is you don't talk about Fight Club. Everyone. But it's a 30 minute. 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 in 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 in that mindset. You know you're going in there to solve a hard problem, that there's going to be a disagreement, and it makes it much better. And I think the relationship we all have is so much better because we get on top of these things early.
This is super cool. It's like couples therapy or something where you're just like, what issues do we have? Work through them right now. I love that. I love that. Because it forces, yeah, and it makes it okay to bring up things that are bothering you and things that you think need to change. And with that, we've reached our very exciting lightning round. Are you ready?
Yes, Kyle Wade, let's do it.
First question, what are two or three books that you've recommended most to other people?
Oh, look, I, you know, and I have a habit of sending books to everyone who reports to me every year just on a school they're working on. so I've got a huge list that I actually send out. But the one that I send out the most to new PMs especially is just inspired by Marty Cagan. It holds up really well. It was recommended to me by my first boss and it's just got a bunch of great tips in there. Just great foundational knowledge. More recently, what I've been sending out for my managers is scaling people by Claire Hughes Johnson. I think that just came out within the last year, actually, but it's just got an incredible amount of really useful tactical things, templates, all sorts of things that you can put into practice.
CB: Great choices. We have both in the bookshelf behind me. Both of them have been on the podcast. I wish I could see the whole list of books that you recommend to people. You don't have this written out anywhere. You should publish some kind of blog or newsletter post of here's the skill.
And here's the book you recommend. Oh, that's a great idea.
Yeah, I'm going to do that. Thank you. We have a homework assignment. Okay, next question.
What is a favorite recent movie or TV show you've really enjoyed? I am so late to TV, but Foundation is the one that I've been binging lately. And I think it's just this huge world. And I'm not usually one that gets super into sci-fi, but the way that it brings forward some of these ideas, like what new technologies could mean. If you haven't seen it, and this isn't really spoiling it, one of the main characters, or three of the main characters, are actually clones of this emperor who rules the universe and decided to clone himself at three different stages of his life so that those people could continue ruling. And I think even that idea just invites the idea you know, what if we stretched out human life? What are the impact? How do things advance when you've got that same mindset and same people continue on? And it's super compelling.
Foundation, the show got ruined for me by reading the books many, many years ago. It was one of my favorite sci-fi trilogy of all time. And then I was so excited for the show and it just has nothing to do with the books. Basically, it's like the storyline is completely different. Just like the core idea is the same as the only real. So I just can't, I just got tired of it and stopped. But if you haven't read the books, I think you would love it. It's beautiful. Are the books better? Somewhat like, yeah, yeah, the books are better. The books are always better, I think.
Is a good rule of thumb. Yeah.
That is a good rule. I think they picked that up. Yeah, I was like a teenager when I read them, so I don't know, maybe they suck, but I think people love them. Highly recommend the books if you liked the show especially. Next question. Do you have a favorite interview question that you like to ask candidates?
I think it's an old one, but a great one, you know, on the subject of failure. I love to ask people about their biggest failure. And I think it's a good way to get to know somebody because you can see how introspective they are, how much they think about what's happened and what they learned from it. It shows whether or not they can be vulnerable with you. You can see what they consider to be a a big failure. You know, some people will list something that's not really a failure. And also you can see about whether they've got that growth mindset. So have they learned something from that? Have they applied it moving forward? I've found, you know, a weird, weird rule that I found is that a lot of the best hires that I've had have had big failure stories that they've worked through and learned from. and so I think that's great to see what they consider there, what the learnings are, but also in the solution you can also see how they tackle something like that. So are they the type of person who wants to go and forge something or by themselves? Are they the type of person who will pull together a community to figure something out? So you get that insight into their values and their approach from that question too, which is hugely useful.
Is there a favorite product you've recently discovered that you really love?
Yeah, you might have to stop me from going on and on about this, but I recently got a Traeger smoker for smoking meat. And just the unboxing experience was incredible. So you get this huge box, cardboard box, you open it up, if you reverse the cardboard box, it becomes a, like a, play saloon that your kid can jump into and just mess around in, which, you know, rather than destroy it, you know, just throwing it out, it becomes something really cool and useful. The set of instructions has a six-pack of beer at the top. Just helps you understand, like, how far through you should be through your six-pack as you're constructing it. You get some tools with it, and they're really good, actually. They're not like the usual kind of throwaway tools that you get. something to put together something like this. And then there's, you know, in addition to that sort of like playful delightfulness in there, as you build it, you discover things along the way. So I opened up the the hopper where you put in your wood pellets and there was a baseball cap, a baseball cap in there, which is was unexpected and really cool. And then the whole experience of actually using it, you know, once you've set it up is amazing. So it's all connected to my phone. I can just head to the beach and have some brisket going and come home and it's beautifully done. It just works. It's integrated. It's got integrated recipes. Yeah, I love it.
I'm sold. I need this. This is, that sounds so delightful. Such a great product experience. I'm gonna have to get one, I think. I think we're gonna sell some trigger smokers. Next question. Do you have a favorite life motto that you often come back to, share with friends, either in work or in life?
It's around maximizing joy. And what I mean by that is it's about finding what's important and leaning into it or finding what's annoying and turning it into something I enjoy. So to give you like a super small example is I, I'm terrible with keys. I will leave that thing all over the place. You'll find it in my cutlery drawer or whatever, and I'll never find it again. And I think, you know, an obvious solution to that could be to put a hook on the wall or something where you can just leave them and you go back to that and it's easy to find. But what gives me joy is not actually having to have keys at all, right? And so now I have a fingerprint reader on my front door and I feel a little bit like James Bond every time I enter my house and I can let people in, you know, if somebody needs to leave a package or something, that's easy to do. So it was turning something annoying into something more joyful. And I think the other thing there is just I really value keeping great relationships and increasing those relationships. And so I always make time for these amazing friends that I have that live in London. And we have this pact where every time either one of us goes to the other's continent, we'll go meet them there. So every time they go to Europe, last year I was in Berlin at one point and Amsterdam another point. They came over and we just hung out and had a great time. And so it's making sure that you make time for those important things.
Along the same lines, final question related to creating more joy. I noticed a beautiful surfboard behind you. For somebody that's trying to surf and maybe not being successful, what's one tip you could share with listeners to improve their success with surfing.
Isn't surfing the most humbling sport that you've ever tried?
Yeah, I've tried a few times and yeah, I would say so.
I think surfing's really interesting. I've never done a sport like it in that it's something that you have to really feel. So I find every time you learn a new thing about surfing, you sort of feel it before you know how to do it. So even just being able to catch a wave, a green first wave, right? You're paddling, you're paddling, you don't quite know where to be, you don't quite know how much to paddle for that wave, and you just have to sort of be successful a couple of times before you get the feel for it. And it's the same with trying to find the right wave. When I looked at the ocean the first time to try and pick the wave and pick where to be, I couldn't even see the shape of it to Find that right place. It took me, you know, just seeing a hundred waves to be able to do that. Uh, so my, my best tip for surfing is get out there, keep doing it, do it over and over and over again. You will get better. You'll start to see all of these things that you've never noticed before, and get some friends, get some friends out there, get a, an surfing accountability buddy to make sure that you're getting out there.
That's the best buddy. Amazing. Megan, we've talked about play and safety and buy-in and fighting the good fight and adding new product lines. Uh, two final questions. Also surfing. Two final questions. Where can folks find you online if they wanna reach out and maybe follow up on some stuff? And how can listeners be useful to you?
Yeah, so the best place to find me is on LinkedIn. I'm Megan Cook on LinkedIn. You can also find me if you're a customer in the Atlassian community. If you wanna have a chat. and also on social media. So on X, you can find me there as well. And it'd be useful to me with any feedback. Absolutely any feedback on your software, we're always hungry for that. Also really keen if you want to just chat about how people's ways of working are evolving and shifting and changing and how do you think that's going to turn out? Hey, you see your goals for your team changing? I would love to talk about that. Please get in touch.
Awesome. Megan, thank you so much for being here.
Thank you, Lenny.
It's been fun. Same. Bye, everyone. Thank you so much for listening. If you found this valuable, you can subscribe to the show on Apple Podcasts, Spotify, or your favorite podcast app. Also, please consider giving us a rating or leaving a review, as that really helps other listeners find the podcast. You can find all past episodes or learn more about the show at lenniespodcast.com See you in the next episode.
More from Lenny


How Meta designed Muse: an AI agent people actually want to talk to | Alex Cornell (Design Director)


Why every company now needs to think and operate like a lab team | Josh Woodward (Google Labs, Gemini, AI Studio)


Jev: 8 real use cases for the fastest, cheapest model I’ve ever used | John Lindquist


The grief, loneliness, and burnout sweeping through the tech industry right now | Molly Graham






