Hard-won lessons building 0 to 1 inside Atlassian | Tanguy Crusson (Head of Jira Product Discovery)

1. 0:00 – 2:30

   Tanguy’s background

   1. TCTanguy Crusson0:00

      Been in the product management team at Atlassian for roughly 10 years now. I worked on HipChat and Stride, and more recently I started Jira Product Discovery.

   2. LRLenny Rachitsky0:09

      Why is it so hard to start new products, go zero-to-one within large companies?

   3. TCTanguy Crusson0:13

      The company has a tendency to over-invest. Start-ups have the benefit of starving. And so you need to create scarcity. Like, what we try to do is remind everyone things are going to fail, let's not drag the rest of the company into it.

   4. LRLenny Rachitsky0:24

      Sounds like one of the biggest lessons is super silo sort of team.

   5. TCTanguy Crusson0:27

      I needed the rest of the company to go away so we could get the autonomy to test the things that we needed that is not going to scale, that is not going to respect our design guidelines.

   6. LRLenny Rachitsky0:35

      The biggest challenge I think a lot of companies have is just like, "It's been six months. No one wants this. We're gonna kill it." How do you protect that?

   7. TCTanguy Crusson0:40

      Be very clear about what we're testing, doing that with data, doing that with personal customer stories. Give people a sense of velocity and speed. No one wants to fuck with a high-speed train.

   8. LRLenny Rachitsky0:53

      (instrumental music) Today my guest is Tanguy Croussong. This is a really unique and important episode, because we get into something you don't hear much on podcasts like this, the real talk challenges of trying to innovate and build zero-to-one at a large company like Atlassian. Tanguy has been at Atlassian for over 10 years and has worked on a bunch of internal big bets, some that have worked and some that have not. Including products like HipChat, which I was a huge fan of back in the day. Also a product called Statuspage, and most recently, Jira Product Discovery, which is one of the fastest growing products in Atlassian history that Tanguy led from idea to launch. We go through each of these stories and Tanguy shares what went wrong, what went right, and everything that he's learned about creating space for innovation within a larger org, including how they structured their internal incubation program called Point A. There's a ton of gold in this episode, and a bunch of really interesting stories, which is part of the reason that it went this long. It's the longest episode I've done yet. If you're looking to create change in your organization and foster more innovation, this episode will be worth your time. If you enjoy this podcast, don't forget to subscribe and follow it in your favorite podcasting app or YouTube. It's the best way to avoid missing future episodes, and it helps the podcast tremendously. With that, I bring you Tanguy Croussong. Tanguy, thank you so much for being here. And welcome to the podcast.

   9. TCTanguy Crusson2:21

      Thank you very much for welcoming me here, uh, Lenny. I'm super, actually super proud to be, uh, on this podcast. I've been a huge fan. Whenever I get the chance, I listen to you when I drive somewhere. So,

2. 2:30 – 7:03

   Tanguy’s journey at Atlassian

   1. TCTanguy Crusson2:30

      yeah.

   2. LRLenny Rachitsky2:31

      What we're gonna be talking about in this episode is we're gonna be talking about building new products and going zero-to-one within larger companies, and in particular, the pain and the challenges that come along with that. But also the lessons that you've learned from doing this many times and seeing it done many times. You've seen a lot of this happening at Atlassian. You've been there for over 10 years at this point, and Atlassian has, I don't know, like, over a dozen different product lines at this point, something like that. And I know a lot of people come to you asking for advice on how to build zero-to-one within a large company. So let me just start with a general question of just could you just share a bit about your history of building zero-to-one and just seeing zero-to-one happening within Atlassian?

   3. TCTanguy Crusson3:14

      Yeah. So, so like you said, I've been in the product management team at Atlassian for roughly 10 years now, and I've been working mainly on bootstrapping new things. So it was initially I joined to start the cloud developer ecosystem so developers can get apps, uh, on top of the Atlassian platform and sell them on the Atlassian marketplace. I worked on HipChat and Stride. Uh, HipChat was well-known, Stride less so. Uh, we were trying to win the enterprise communications market, uh, before Slack and Microsoft Teams, uh, came about. I did lead a business case to invest more in IT operations, got nowhere with it. Then we acquired, uh, Statuspage, Opsgenie, uh, and something I tried to do with- didn't quite get off the ground. Uh, and more recently, I, uh, started Jira Product Discovery, which was part of our internal incubator for two to three years and came out of the incubator and generally available, uh, a year ago. So my track record at Atlassian has been, uh, 50/50, uh, at best-

   4. LRLenny Rachitsky4:17

      (laughs)

   5. TCTanguy Crusson4:17

      ... uh, so Jira Product Discovery's actually my first what I would call big success here. Uh, that one worked, but it was hard, and all the ones that I worked on before were really hard, too. And that's the kind of stuff that really bothered me for a super long time, and, uh, the good thing is working on a product for product managers I got to talk to a lot of product managers and, uh, across all sorts of industries in, uh, the past, uh, three to four years. And I realized that 50/50 is actually not that bad.

   6. LRLenny Rachitsky4:46

      Awesome. And I know there's gonna be a lot of real talk in this conversation. I'm excited to share and hear all these stories. This episode is brought to you by Vanta. When it comes to ensuring your company has top-notch security practices, things get complicated fast. Now you can assess risk, secure the trust of your customers, and automate compliance for SOC 2, ISO 27001, HIPAA, and more with a single platform, Vanta. Vanta's market-leading trust management platform helps you continuously monitor compliance alongside reporting and tracking risk. Plus you can save hours by completing security questionnaires with Vanta AI. Join thousands of global companies that use Vanta to automate evidence collection, unify risk management, and streamline security reviews. Get $1,000 off Vanta when you go to vanta.com/lenny. That's V-A-N-T-A dot com slash Lenny. This episode is brought to you by WorkOS. If you're building a SaaS app, at some point your customers will start asking for enterprise features like SAML authentication and SCIM provisioning. That's where WorkOS comes in, making it fast and painless to add enterprise features to your app. Their APIs are easy to understand so that you can ship quickly and get back to building other features. Today, hundreds of companies are already powered by WorkOS, including ones you probably know, like Vercel, Webflow, and Loom. WorkOS also recently acquired Warrant, the fine-grain authorization service. Warrant's product is based on a groundbreaking authorization system called Zanzibar, which was originally designed for Google to power Google Docs and YouTube. This enables fast authorization checks at enormous scale while maintaining a flexible model that can be adapted to even the most complex use cases. If you're currently looking to build role-based access control or other enterprise features like single sign-on, SCIM, or user management, you should consider WorkOS. It's a drop-in replacement for Auth0 and supports up to one million monthly active users for free. Check it out at workos.com to learn more. That's workos.com.

3. 7:03 – 10:42

   The challenges of innovating in large companies

   1. LRLenny Rachitsky7:04

      Just broadly, why is it so hard, in your experience, to start new products, go zero to one within large companies? What have you seen are kind of the biggest challenges and hurdles generally?

   2. TCTanguy Crusson7:14

      Yeah. So on, on the opportunity side, so Atlassian, uh, 300,000 customers. We play in a whole bunch of different markets, everything in the collaboration space. We have a lot of markets that we play in, which means that we've got a lot of competitors. But basically when we look at the areas we could go in, there's an endless list of areas that we could go in, play, and have a decent chance to win. Much harder to do if you're a startup. Like the breadth that we've got makes it easier to try and find areas where we could expand into. We're not starving like a smaller company, so we can actually afford to try to play somewhere, to do some bets, to have some- some of them fail and some of them succeed. So that's amazing. Now, our customers, I said 300,000. The- the good... The thing that I, um, admire the most about the Atlassian business model is it's very broad. It's across small and medium-sized companies, we have startups using our products, and we've got also enterprises and very large enterprises using the same products, which means that there's a lot of areas where we could find a niche and go after it and expand progressively into all these areas. So there's a massive distribution potential that comes with that. When I worked on Jira Product Discovery, I didn't start with, "Okay, I'm gonna need to start finding product managers and it's gonna be hard to find them." No, they were already all using Jira. Atlassian is a company that has a relatively deep organization hierarchy, uh, but relatively flat decision-making. So it's more like, um, imagine a- a network of key decision-makers across the organization. It doesn't really matter the job title or whether you are- are a manager of people or not. Like the decisions are made by people who- who- who drive change. So there's a lot of empowerment that comes from that. Uh, but also it's a mix of top-down, bottom-up happiness, I'd say. And so it can feel really chaotic at first, but once you know how to negagate it... Navigate it, it's actually pretty easy to go... Try to go after something that you care about. And of course, we're a big company, so there's lots of ways we can get help. Uh, corporate development, research, analysts that we can talk to whenever we want to explore something, thousands of customers that, you know... I just have to put something in the Atlassian community group and get hundreds of people replying to talk to me from one day to the next. So that's, like... That's amazing. Any startup would want that.

   3. LRLenny Rachitsky9:45

      This sounds like how can anything not work when you try... When you launch a new product. You have 300,000 potential customers to launch it to. You have all the resources to build it. It sounds like decision-making is- is efficient relatively. It's flat. You have all these different, uh, customer segments that use all these different version, product lines of Atlassian. It's just like all of the opportunity possible to launch new products and still many things do not work out. So I think this is a really important point. I think many big companies are in this like, "We have so much opportunity. We're... Everything we're gonna build is gonna have... Just go... It's gonna grow like crazy because we have everything we need." But still it doesn't work out, and that's why I think what we're gonna talk about is gonna be so important.

   4. TCTanguy Crusson10:27

      It's gonna be a bit of therapy for me. Uh-

   5. LRLenny Rachitsky10:30

      Perfect.

   6. TCTanguy Crusson10:30

      Hopefully some people out there could go, "Okay, it's not just me having a hard time." Like it's, uh... Can happen in, uh-

   7. LRLenny Rachitsky10:36

      Yeah.

   8. TCTanguy Crusson10:36

      ... in companies like Atlassian too.

   9. LRLenny Rachitsky10:38

      Amazing.

   10. TCTanguy Crusson10:38

       So yeah, let's talk about the challenges, um-

   11. LRLenny Rachitsky10:41

       Let's do it.

   12. TCTanguy Crusson10:41

       ... yeah, for that. Um,

4. 10:42 – 12:58

   Atlassian's high bar for excellence

   1. TCTanguy Crusson10:42

      so you want to start a new thing. This thing is gonna take time. And you... It's... You need to be able to have that time for the time it takes until you can prove whether there is a thing or not. The thing inside Atlassian is that the path of success is super high for a new bet. Like if you come in and you create a product and it's got 100 customers, it's gonna be... It's gonna look cute, right? So remember, we... You know, we serve startups and enterprises. We have self-service and saves. We've got... Like, we've got all these motions that are in place for our bigger products. A $100 million business is a good start, basically. In most companies out there like $100 million business is a home run. For us, it's not like that. It's... We're- we're trying to build businesses that- that grow really big and- and keep growing big over time. Now, evaluating success can look very different between early stage and established products. And so for a long time at Atlassian, we were treating everything a little bit equally, in that the metrics for success for the same. So for example, things like monthly active users is- is the way that you... For- for a long time we looked at, you go, "Is that product being successful or not?" And well, if you're a...... building an, quote unquote, "internal startup." Your monthly active user number should look very low for quite some time up until you know that your product is ready to serve the vast majority of the customers that you want to put it in front of, so that they don't just look at it and go, "It's not ready for me." They're gonna try it and then they're gonna churn, and it's gonna be... Take forever to claim them back. So that makes it pretty challenging to try and start new things, u- unless we've got the, the right metrics and processes and everything internally that can give room and breathing space for the bets to succeed internally. And for many years, we were not there. We, we started getting there more recently with the start of Point A, which was our internal incubator program, which is where my latest bet was successful. The ones before didn't have that, and I s- really struggled, uh, from that. And I see many companies struggling with that exact aspect.

5. 12:58 – 20:47

   The HipChat story: successes, failures, and lessons learned

   1. TCTanguy Crusson12:58

   2. LRLenny Rachitsky12:58

      Amazing. So let's dive into an actual story. There's three that I wanna talk about. There's HipChat, which you mentioned, there's Statuspage, and then there's the product you're working on now, Jira Product Discovery. Uh, so with HipChat, funny story, I loved HipChat. I was a huge user of HipChat at my startup back in the day. I can never forget the billboard that y'all put out, uh, promoting HipChat, where there's this, like, r- little car- like, stick figure meme guy, and it just said, "Y U no use HipChat?" And I thought that was the funniest thing. And, uh, the product was so delightful. There's just all these little emojis in there. And, and the idea with HipChat for Atlassian was basically to become the Slack killer, right? That was the vision.

   3. TCTanguy Crusson13:37

      Oh, ah, you just... You just killed me.

   4. LRLenny Rachitsky13:40

      (laughs)

   5. TCTanguy Crusson13:40

      We were here way before Slack. (laughs)

   6. LRLenny Rachitsky13:42

      Okay. You s- your first mover advantage, amazing product-

   7. TCTanguy Crusson13:46

      It worked.

   8. LRLenny Rachitsky13:46

      And it was an ac- it was an acquisition for Atlassian, sorry.

   9. TCTanguy Crusson13:49

      It was an acquisition.

   10. LRLenny Rachitsky13:49

       Awesome.

   11. TCTanguy Crusson13:50

       Yeah.

   12. LRLenny Rachitsky13:50

       So let's talk about what went wrong with HipChat? What did you learn?

   13. TCTanguy Crusson13:52

       Oh, no. Yeah. When I was CEO of the company as the tool that could almost have a, a okay-

   14. LRLenny Rachitsky13:58

       Yeah. That's-

   15. TCTanguy Crusson13:59

       ... run against the, uh, against Slack. Okay.

   16. LRLenny Rachitsky13:59

       This is the therapy. The therapy session begins.

   17. TCTanguy Crusson14:01

       Yeah. All right. No, it's gonna stop right there.

   18. LRLenny Rachitsky14:03

       (laughs)

   19. TCTanguy Crusson14:03

       Uh, me and everyone else from the HipChat team, I can tell you. Okay. So yes, uh, HipChat was an acquisition, uh, team of 20 people or so. It was Slack before Slack was there. Great traction and lots of. It was a darling with startups. It was a new way to collaborate back then. There were a few of these smaller apps that were trying to, uh, to, to do this thing. I, I remember actually joining Atlassian, and I came from... Before that, I was working with financial services, banks and, and stuff like that. And, uh, we were basically meeting to talk about stuff or, you know, going to someone's desk to talk about stuff. And I joined this company where my colleagues who sit on the same floor as me and on the same table, we, we talk over the computer via chat, and I often felt weird at first, like, looking over my shoulder to the person I'm currently talking to-

   20. LRLenny Rachitsky14:53

       Hmm.

   21. TCTanguy Crusson14:53

       ... and we're having an argument, but we're doing it over text. You know, it might s- seem a bit cute to the people who have been, uh, born in the Slack world, uh, but it was a major change back then-

   22. LRLenny Rachitsky15:02

       Yeah, I remember that.

   23. TCTanguy Crusson15:03

       ... and, and what, um-

   24. LRLenny Rachitsky15:03

       I remember that. Like, I was in the same office with my team and we're using HipChat to chat, and it felt strange. Now, now it's, like, completely normal.

   25. TCTanguy Crusson15:10

       It's just normal. And, um, uh, it... HipChat was one of the first, uh, to move there. Slack came out of nowhere. Company actually initially was focused more on gaming, and they really took the market by storm. Uh, their n- their growth numbers were dizzying when we were looking at them. And so at some point, like the... HipChat was left relatively alone for a while inside Atlassian to, you know, "You're doing something good so keep d- keep going. Keep going after it." Uh, but with Slack, we now had to try to go bigger. So we started this thing called HipChat Go Big. The team grew 3D-

   26. LRLenny Rachitsky15:44

       That was the name of the project, HipChat Go Big? (laughs)

   27. TCTanguy Crusson15:46

       Yeah, HipChat Go Big. Um-

   28. LRLenny Rachitsky15:48

       I love that.

   29. TCTanguy Crusson15:48

       And then it was HipChat Next Gen. There was a few different...

   30. LRLenny Rachitsky15:51

       Hmm.
6. 20:47 – 33:49

   Lessons learned from building HipChat

   1. TCTanguy Crusson20:47

      scarred by it, basically.

   2. LRLenny Rachitsky20:48

      Hmm. So what are some lessons from that experience?

   3. TCTanguy Crusson20:51

      Yeah. So the, the main one that, um, I personally got from this, and it's back to the hypothesis that you talked about, which we have all these successful products, we can expand into this one. Which is, uh... And I call it, but it's just myself, right? Don't eat your own bullshit.

   4. LRLenny Rachitsky21:07

      (laughs)

   5. TCTanguy Crusson21:08

      Which is, uh, a mix of two things. Uh, uh, we've got a company value that says, "Open company, no bullshit." So we need to be able to talk about the things like they are. And we don't try to make things sound smarter than they are. We don't try to hide the truth. We go after the- that truth. And we don't hide stuff from each other. We share with everyone. We are open by default. So that's one of the values. And we do a lot of dogfooding. So eat your own dog food. So we do test our own software a lot. And I- I've noticed that, uh, sometimes there are things that we do where we tend to believe stuff because it's worked for us before. And we kind of have this assumption that it's gonna keep working for us forever. And the founders keep telling us, like, "What took us here won't take us there." That's, uh, kind of a, a thing we keep hearing over and over again. But it's very easy for teams, when they see success of something, to think that it's successful because of X, but X is not validated. So th- that's why we go back to this, the topic we've got today, which is, why is doing this in a successful company harder sometimes? Well, Atlassian was successful with a playbook. And the playbook was, we've got people in... Like developers, or tech, or IT. They choose Atlassian apps. They love them. They start to recommend them to people in the business. And we start to see adoption, like bottom-up adoption across the company before people decide to standardize on Atlassian. And we made the bet that we can apply this playbook to this market, which is basically, we can form people to use Jira, introduce HipChat, and then people would go into HipChat, first in, in tech teams, and then it will expand into business teams, and it will go wall-to-wall, basically, from that. The thing is, we didn't, in my opinion, do enough to validate that assumption early enough. And we did a lot of work, a lot of work, even on other things, even when faced with signals that this might not work. I do remember talking with a lot of customers who were like, "Well, we've got the... The, the, the, the IT is on, is on HipChat, but the business prefers Slack." And then we started to see those businesses choosing Slack. Which is the... Initially, it was like the developers try things, and they like it, and then everyone starts to adopt. In that case, the... Slack managed to create a very strong fan base in roles that were not tech and IT.

   6. LRLenny Rachitsky23:48

      Hmm.

   7. TCTanguy Crusson23:48

      It was the moment where the consumerization of apps, that trend was starting to get really high. Slack really rode that. And they focused everything in their experience to catch that. They gamified onboarding. They focused a lot more on the look and feel. They, they tried to make it pleasant, more than functional to use. Uh, there's a lot of stuff that we, uh, that we learned since then from, from what they did. We had missed that, that path. And the, the part that...... that, that I took personally from that is that there's a lot of assumptions in what made it successful, it doesn't mean that it's gonna work.

   8. LRLenny Rachitsky24:23

      Just so I understand what you're saying, which i- is really interesting that Atlassian was really successful selling basically to the buyer within the org, like the IT team for... because they had everything they need, they k- checked, checked all the checkboxes. But it turned out in the Slack case, it was the users that ended up having the most influence over what tool they adopted.

   9. TCTanguy Crusson24:42

      So I'd actually phrase it more as both were going after the users. Atlassian was going after the users in tech teams. Slack was going after the users in business teams and in both cases what happened was a bottom-up adoption, and, uh, the people on the other side, the business were like, "Oh, we prefer Sl- like, uh, the developers, they prefer the HipChat." Like, we did a lot of work, uh, at... In the streams I was, I was working on, we're integrating with every developer tooling out there to make sure that every t- every tool that they use goes into HipChat and from HipChat back to those tools, and basically they can do a lot of work by seeing an activity stream in HipChat. Business, eh, not so, you know, excited by this. Emojis, a lot of other things that may... at, at some point, uh, remember we were thinking those things were trivial. No, they were not trivial. It was just, like, a different, uh, approach for using the tool, uh, by a different set of users that we did not talk enough to.

   10. LRLenny Rachitsky25:35

       So is the lesson here don't underestimate the challenge you'll have, uh, convincing a new segment to buy your thing? You may think they're close or similar but they m- they're probably not.

   11. TCTanguy Crusson25:46

       Yeah. The, that's, uh, that's one of them. The other one is, what took, what took you here is not going to take you there.

   12. LRLenny Rachitsky25:52

       Mm-hmm.

   13. TCTanguy Crusson25:53

       And so go back and try to explain why you are successful today and then if you try... if you think you can use the same thing on the next thing, find ways to validate it, find ways to test it. Don't just go and build on those assumptions. That's, that's the main thing I, I, I got out of this whole deal, basically, um, um, uh, yeah, for the stuff I did after.

   14. LRLenny Rachitsky26:15

       Well, how would you do that? How would you go about and test it? Is it user research? Is it the PMs talking to potential users? What do you th- what would you have done there?

   15. TCTanguy Crusson26:22

       For example, when we started Jira Product Discovery, which is, um... so maybe I should introduce this for a second. It's, uh, it's, it's a product for product managers, uh, which is mainly used for prioritization and roadmapping. So, uh, people use Jira to plan and track work when it's committed. We wanted to create a space before that so people can debate priorities between... with everyone that should be involved in that prioritization process, whether it be the developers, designers, uh, so people in the product team or people outside of it, customer success, uh, salespeople, support, leadership, and so on and so forth. So, when we started that, we thought, "Okay, the product managers are already in Jira. You know what? We can reach them, right?" So we create the tool and then we'll distribute it from Jira. We could have gone down the path of building that and then started to, started to distribute it. Instead, we did things like, before we wrote a single line of code, put an ad inside, um, a Jira newsletter going, "Hey, we've got this thing for product managers coming up." And then we had a, a, a, a website that before we had in- any line of code written that said, "Hey, product managers, your job is hard. We want to help. Put your name here if you want to join us on the journey," that kind of thing. And we... that's when we s- we saw, I think it was in two weeks, we got more than 3,000 signups to that wait list. So we're like, "Okay, cool. Validation of demand. So we are talking to people who are interested and we can reach them." That's one examples of the things that I tried later just to make sure that, uh, we are... we validate the hypothesis that we've got much earlier on in the game basically, and not after and not when it... once it's too late.

   16. LRLenny Rachitsky28:06

       Awesome. That's an awesome, very tactical example.

   17. TCTanguy Crusson28:09

       Yeah, most of those are like... No- none of what I'm going to talk about today is revolutionary. A lot of it is just, uh, trying to apply, like, asking the right question at the right time and trying to go by whatever means to answer it, really.

   18. LRLenny Rachitsky28:21

       Any other lessons from, uh, the HipChat experience before we shift to a different product?

   19. TCTanguy Crusson28:26

       I've got two. I'm gonna do them, um, uh, quickly. The first one is competitive myopia, don't fall for it. Uh, the, the... at some point, you know, the... Slack was really gaining ground and gaining ground and capturing more of the mind share and everyone on Twitter was always loving them. Even when they had outages, they were getting (laughs) congratulated. I was like, "This is fucking mad." But, like, the love was so strong, and the way we tended to revert back is to a functional side of the brain going, "Okay, we just need this one more feature. We just need this one more feature. We just need this one more feature." And we ended up reacting to whatever the, um, uh, competitor was doing, which I think is really, really bad because that's when we lost basically our... what made HipChat successful so far, which is to serve some users really well, and instead we, we ended up not f- fast following based on what the competitor was doing, which is super bad 'cause your competitor, like, if you think of what they do as an iceberg, like the, the, the top side, what comes out of the water is what they've, they've shipped in terms of features, but it's based on all this stuff that they've built in terms of research and understanding of their customer base and, and everything else. And so you're just seeing the manifestation of what they were thinking maybe a year ago-

   20. LRLenny Rachitsky29:41

       Mm-hmm.

   21. TCTanguy Crusson29:41

       ... based on what they're shipping now. So, but we, we got there and, uh, now I... whenever I work, I, I tend to try and ignore competition other than watching key... like, every three months or so seeing what came out, if there's anything we should be worried about, afraid of, stuff like that, but really just try to disconnect all the creative process and the research process from what competitors do 'cause it, it just... you, you can't compare. The market is huge. There are hundreds of thousands of companies out there. Not everyone has the same needs. We serve a particular set of segments.... we would do better learning from them, to then expand to the others than what your most competition is, is doing.

   22. LRLenny Rachitsky30:20

       And this is advice you give to your teams, just like, "Ignore the competition. Maybe pay attention at big announcements and things like that"?

   23. TCTanguy Crusson30:26

       We always see in the Slack channels, um, teams sharing, "Okay. They just did this with AI. They just did that." So it, it keeps coming up and I... and, and so we often have discussions to go back, okay, to get, "Let's watch again what the, the, the user interviews that we did over the past, uh, three weeks. Let's watch them all together now, and remember who we're building this for." So there's a lot of, uh, trying to anchor back on what we know and, and how... basically, building our own journey on it, and I think it's much richer for everyone to be involved.

   24. LRLenny Rachitsky30:58

       I love that. So you finding that when there's a big announcement and everyone's like, "Oh, my God. Look what Slack's doing," or, "Look what this company's doing," it's like, "Okay. Now let's spend a little time, uh, reminding ourselves what our customers have been asking us to do, and let's watch a couple user interviews."

   25. TCTanguy Crusson31:11

       And even when there is something that competitors do that is right, remember, we're playing the long run, and we don't always need to be first and shinier. We, we need to make sure that people have a problem, we solve this problem, they tell us we solved this problem for them, they are delighted when we solve these problems for them. And so we, we... that's the, that's the stuff we should be obsessing about.

   26. LRLenny Rachitsky31:32

       I love that. And you said you had one more lesson from this experience?

   27. TCTanguy Crusson31:37

       Yeah, the last one, uh, startups have the benefit of starving.

   28. LRLenny Rachitsky31:40

       Hmm.

   29. TCTanguy Crusson31:41

       (laughs) Right? We're a big company. We can throw a lot of resources at something that we're excited about. So this notion of where we'll rebuild Heapchat was coupled with, "We'll rebuild Heapchat and we'll do this on a new platform," which is micro-services, and everything that we build can be reused across all the other products. So the chat textbox that you've got, it's an editor that can be opened full screen and it's a Confluence editor with everything that you can do there. The... It's built as a platform component, which is amazing when the platform is there when you start building the product. Where it's really difficult is when you try to do the two at the same time. So I think that part, if I were to work on Heapchat again and say I was leading that thing, I would have... that's the part I would go, "Okay. Let's, um... we need to win this f-... the, the, the problem space first, and if the platform is there, let's use it. If it's not there, we'll hack it, test it, iterate on it with customers, and then whatever is good there, let's platformize it later." But that's, that's where you see the, the, the, the... what makes us super powerful as a, as a bigger company can also slow us down and make us focus on the wrong assumptions. So in that case, I think we thought we would win. Interestingly, I think w- we were, were convinced that we could actually... we had a, a, a great shot at this market. And at the same time, we thought that we could tackle the, the rewrite and we could tackle the, the, the platformization. All these things were necessary, but all of them at the same time was, um, probably a bit too much to bite. Now, I'm saying that, but today, the editor you see in Confluence started with what we did in Heapchat back then. So I would say that in terms of code, purely in terms of code, 70% of what we wrote for Heapchat is, is, is probably still in the Atlassian platform today. But for a new bet, Localoptima, that was really bad. (laughs)

   30. LRLenny Rachitsky33:37

       Yeah. Just thinking about the fact that Atlassian could have had this $30 billion business if this worked out, and I could see why people would be frustrated that it didn't work out. So thank you for sharing that story.

7. 33:49 – 39:48

   Statuspage: a journey of perseverance

   1. LRLenny Rachitsky33:50

      Let's talk about Statuspage, another, uh, journey that you were a part of that also didn't quite work out the way folks had hoped.

   2. TCTanguy Crusson33:57

      (laughs)

   3. LRLenny Rachitsky33:59

      (laughs) Our therapy session continues. Talk about what that product was and, and what happened there?

   4. TCTanguy Crusson34:03

      Yeah. So this one is actually a success story, uh, but became a success story after I was gone.

   5. LRLenny Rachitsky34:08

      Okay. Okay. (laughs)

   6. TCTanguy Crusson34:09

      (laughs) So it's more, it's more the... that's more like a story of, uh, big companies can play the long run, uh, and for you individually inside that process, it might look like a loss and you might feel like you're going around, going nowhere. Yet, the company stays on the opportunity for long enough to make it happen. So what we're gonna talk about here are my own challenges working through it, uh, for something that ended up being very successful in the end. So... but I felt as a failure personally back then. So, uh, Statuspage. At some point... So Jira is used by developers, right? And back then, it was... I think it was back in 2016 or even before that, 2015, everyone was moving to the cloud. Everyone was adopting DevOps. You build it, you run it. So basically, developers would implement the software and then they would put it to production. And after they put it to production, they don't throw it over the wall to operations people. It's the same developers who operate the software in production. They go on-call, yada yada. So back then, I did market research and... to, to see whether Atlassian should play there. Whether we had a, a crack at going after all the jobs around IT operations. So Jira was basically just software to build software. Could we have Jira for operations, so for operating this software? And so I did market research, found a few companies that were doing super interesting things there, like PagerDuty, Opsgenie, New Relic. Big Panda was a small startup doing lots of, uh, cool stuff there, and Statuspage. Now, I discovered Statuspage and found their, uh, offering super interesting in that Atlassian is, uh, not an operations. Like, we don't really build, like, super deep operations tooling. What we focus on a lot is the collaborative aspects around, around everything. And when I was watching teams in incidents, I realized that there's a lot of, um, chicken without a head syndrome. Headless chicken? Yeah. Uh, people running around like a bunch of headless chicken. Shit hits the fan, um, and then what you see is teams just scrambling and they're... everything gets mixed up altogether in, uh, trying to fix the problem straight away.... uh, but at the same time questioning what happened, arguing over why we got there. The... Your, your boss is pinging you to go, "Hey, what's going on? I've been hearing that the app is down. We're losing money." Customers are emailing you, and, and asking you what's going... And your, your support channels get blown up. Sales people are worried because their customers are calling them. So basically it ends up being, like, a super stressful experience for everyone. And what StatusPage was offering is something seemingly super simple, which is, well, what you should have is a status page. Work for your services and you tell your customers about it, and you can subscribe to your status page. Over there you've got your services, and for those services, you can publish an incident whenever there is one. And your customers will be notified, which means that they're not going to get in touch with support because they know you're on it. It's going to build trust with them because, uh, basically you are honest in your... open in your communication with them. They are more likely to empathize with your position and be supportive, as opposed to, you know, "Oh, that stuff is down again." So there was just, there was just so many benefits o- of that.

   7. LRLenny Rachitsky37:31

      I'm gonna say-

   8. TCTanguy Crusson37:32

      And so-

   9. LRLenny Rachitsky37:32

      ... a quick... share a quick story while you're on this topic.

   10. TCTanguy Crusson37:34

       Yeah, of course.

   11. LRLenny Rachitsky37:35

       Uh, funny enough, back a decade, a decade ago I used to work at a website performance monitoring company, and I started a blog called Transparent Uptime. And my whole blog was about the power of being transparent about being down, telling people the status of, "Things are broken right now, here's when things are gonna return." It was, like, a whole thing I was really obsessed with. And, uh, I was deep into the space. So, uh, when I saw StatusPage back in the day and that last seen working, I was like, "I love this." And I actually chatted with the founders a bit 'cause they were fans of that work I was doing back in the day. Completely unrelated to anything else I've done in my life, uh, but I was really passionate about this very strange topic. And, uh, and I love that companies are embracing it.

   12. TCTanguy Crusson38:19

       It's an amazing... Like, I really loved diving deep into it for a few years. Like, it's, it's an amazing topic. And so anyway, there, there's so many fascinating things about this, uh, this particular domain. But back then... So found StatusPage and I, uh... We invited a few of those companies to work with us for a week to go, "Hey, so we are Atlassian, we're, um, basically the collaboration hub for everything that happens for development teams. What would an experience look like that takes... that puts everything together and where Jira could actually help you get the right information to the right team so they can act on it?" And so we did a week of, uh, hackathon in, uh, San Francisco all together. So people from New Relic, StatusPage, and, and a few... and a few other companies. Uh, and out of that came really interesting concepts, and there, there was really something there and I was like, "Okay, we should... I should start to work on a business case for Atlassian for basically IT teams/operations." Now, big companies like Atlassian, they... we've got money. So in every strategy, strategy that we've got, so we've got cash in the bank, we always look at, "Should we build? Should we buy? Should we partner?" Acquisitions can be really powerful to accelerate you. Uh, we've got quite a few success stories that we... Can't remember how many we did, but, uh, Trello is one of the... of the, of the good examples of that, for example. So we decided to buy, um, StatusPage, and I was running the integration of the StatusPage business inside the Atlassian

8. 39:48 – 47:22

   Acquisition challenges and lessons

   1. TCTanguy Crusson39:48

      business.

   2. LRLenny Rachitsky39:49

      Thanks for sharing all that context. What are some of the things that you learned from going through this experience? Sounds like basically it was really painful when you were a part of it, and then it ended up being really successful. What are some lessons from the pain?

   3. TCTanguy Crusson40:02

      My, uh, learnings from it were on the, uh, acquisition side. So big company, we've got cash, we can buy a company, it will make us go faster. It's not always the case. In my case, there were quite a few things that didn't... uh, were not as easy as I would have thought. The first one is the culture shock of a startup that joins your company. So imagine you're a startup, you've got, I don't know, 20, 30 staff or something and things are going well and you are in full control of your destiny, and then a company buys you to accelerate you. But then you stop owning all the decisions. So the CEO, maybe you become a product person. The person who was running GTM but was also doing a bunch of product stuff and was also doing a bunch of maybe engineering stuff all of a sudden is just working in marketing. There are decisions that are made above your head. For example, portfolio feed, which should be part of your product, which is things that we should re-use from the platform that we've got. So there's a lot of decisions that you're able to make on a day-to-day basis that, uh, escape you. Start to escape you. Big companies look much further out in the future. So Atlassian would look at, uh, the long game. And so I remember with StatusPage, when they first joined, we were asked about the roadmaps and they were like, "Well, for the next three months we're working on that, and for the following three months we're thinking about potentially X or Y or Z." And so when we're like, "Okay, so what's the three-year plan?" (laughs) They're like, "What the... What do you mean the three-year plan?" Like, "I don't know. We'll survive, I guess?" Which is the... you know, what startups do. And, uh, they were, like, very, uh, penciled ideas about the future, but not to the extent of what a, a big company would expect. And so that's a... that's a really big, uh, cu- culture shock. And w- what you end up with as well, and that's, um, for companies who are looking to get acquired out there or buying other companies, before you had a startup and everyone was one team, depending on how your... the buying company is organized, you might land with silos from within your team. So the way Atlassian is organized is, like many Atlassian companies, we've got a product organization, we've got an engineering organization, we've got a marketing organization, design organization, and they each roll up to a different leader, which may then roll up to the same person, but still...... like, by and large, different organizations that are then assembled into squads, and those squads operate together. But there are rituals that are part of the- the- the- the squad, and there are rituals that- that ladder up to, uh, where you are in terms of craft. So I do remember, uh, how daunting it was for the StatusPage team when they joined too, understand how to navigate that. If I want to hire a new designer, I'm not talking to the StatusPage CEO anymore. I need to talk to the head of design for this area, which has pretty much nothing to do with the StatusPage business up until the acquisition. So that's, um, that is the- the things that people told me when I started working on the integration, which is, "Hey, remember, you... I mean, you don't know yet, but integrations are mostly about people. They're not about technology as much or product vision," or like all of that stuff is the easy stuff. The hard part is the people. And I didn't quite understand at first (laughs) and then I- I really got it, uh, by- by the end of it. So because what we tell those companies is we, um, can accelerate by buying, but in reality they are going to be faced with more internal processes around like how they manage staff, performance reviews, this concept of engineering allocation, revenue forecasts, OKRs, long-term roadmaps. All that stuff comes in very new to them. So one part of the company top down says, "We bought you because you are successful. Keep doing what you're doing," while many other teams without meaning to basically end up like c- constantly interrupting so that the right processes are followed-

   4. LRLenny Rachitsky44:02

      Mm-hmm.

   5. TCTanguy Crusson44:02

      ... so that the right things are done.

   6. LRLenny Rachitsky44:03

      That's a really interesting point that like one group is, "Keep doing what you're doing. We don't wanna... We won't leave you alone. You're the experts," and then other people that are like on the ground actually building it like, "Hey, build with this component. Hey, we need this process. We need this document."

   7. TCTanguy Crusson44:15

      And it's- and it's, um, it's the- the things that you used to be able to- to focus 90% of your time working on your product and all of a sudden like all of that stuff may seem parasitical but comes in and interrupts you all the time. And the... often, the new joiners they- they don't know that they've basically, uh, not only been hired- uh, been acquired, they've been hired by the company. So they basically are joining a different company with different sets of rituals, with a different culture, with... All of that is very different basically. It's not going to be the same for every acquisition. Like I said, we had some acquisitions that worked great. StatusPage ended up being a huge success inside Atlassian, but the... when I was there, I basically worked through the difficult parts of it where I was like, "It's not as simple as people may think." So word of warning, if you're planning to do acquisitions, like make sure you factor all of that in and think about the inte- uh, integration plans to- to- to- to compensate for these aspects. So you don't expect a business to join and keep running at exactly the same pace 'cause there's going to be a big slowdown before it accelerates again.

   8. LRLenny Rachitsky45:17

      So maybe as a last question here is just say you were to do an acquisition again, and I don't know if you've gone through more, what's one thing you would change? What's one thing you'd recommend of like let's make sure to do this thing very differently?

   9. TCTanguy Crusson45:27

      One aspect that I'm going to talk about to then- then go there, but one aspect we didn't talk about which is we bought a product, how does that product fit with the rest? And so for... we had different types of- of acquisitions that we did. One is we buy the company and we keep the product running and then we try to integrate it with our sta- tech stack. And then the other acquisition is we buy the company and then we kind of rebuild on our platform, or we- we buy with this huge synergy with our platform. And w- so I... we call that the Frankenstack otherwise, which is you- you get one tech stack here, one tech stack there and they can't quite talk to each other, identity is different, integrating is different, and so it looks like a patchwork of products and that's not what our customers want from us. So the- the next time I try personally, it's I would treat it like hiring over treating it like buying a business only. So there would be a huge component which is to both educate and tease out what it means to actually hire a team inside the company. At the same time, I'm saying that because I don't want to do a big one, right? The next one I want to do is relatively small, find a company that has amazing product that we can bring in as a tuck-in, shut down the product, rebuild it on our platform. And so it's basically the equivalent of an acqui-hire and what... because basically what we are buying is the acceleration of our roadmap. We could try and fo- form a team to do what they did, but they've been successful so they know what they're doing. We could probably get there one year faster. What does that mean for our revenue at the scale of Atlassian? If we can like enter a market one year earlier, it's probably going to pay the acquisition back on its own. So that's the... m- my learnings from it were basically, uh, that, yeah, it's... it needs to be treated like hiring. And what I would like to do next time is more doing it like that basically.

9. 47:22 – 48:17

   Strategic decisions: build, buy, or partner?

   1. TCTanguy Crusson47:22

   2. LRLenny Rachitsky47:22

      Hmm. What about in the case of, um, HipChat where it feels like that was... (clears throat) it was... sounds like a mistake to rebuild the thing? Is there like, for this kind of startup, don't rebuild for this kind of startup, start again? Do you ever thought of like how you separate those two?

   3. TCTanguy Crusson47:36

      There- there's actually a big difference. Okay. There's a big difference which is in one case what you try to do is, uh, so when you rebuild, you've got a successful business. You've got hundreds of thousands of customers, for example, and you're trying to rebuild the same thing or a different thing but for the same customers th- that have got expectations about your current product. In the other one, is you buy a company that's got some traction, not too much, so you can shut down the business, right? And then rebuild on your platform to reach your customer base. So it's not the same as trying to rebuild the plane mid-flight. It's delaying takeoff. Like it's like, "Yeah. We did a trial run, the plane landed. Okay, cool. Switch to another plane, take off again."

10. 48:17 – 54:08

    Learning to articulate "why now"

    1. TCTanguy Crusson48:17

    2. LRLenny Rachitsky48:17

       Got it. I love that. Any other key insights and lessons from this experience before we get to Jira Product Discovery?

    3. TCTanguy Crusson48:25

       One last one and then I'm gonna stop with the therapy session

    4. NANarrator48:28

       (laughs)

    5. LRLenny Rachitsky48:29

       (laughs)

    6. TCTanguy Crusson48:29

       ... because we're not

    7. LRLenny Rachitsky48:29

       Awesome. No.

    8. TCTanguy Crusson48:33

       Also (laughs) Which is, uh, remember I mentioned I was working on a business case for, uh, basically going bigger in IT operations, and so there was status page as part of it, but there was a lot of stuff that I wanted to be able to do inside Jira and, and a whole bunch of other products to, to basically go big in that area, IT operations. Before Jira service management, which is, uh, like the very successful product we've got around that, before it was, it, it was really entering that, that part of the market. Everyone was excited. It was before we had an incubator internally, uh, and so I was, I was trying to pitch it like, "Let's, let's build a new product that's centered around that thing. It's on Jira and it integrates with these tools that we discussed and we can put in spider screech there 　 ," and that, that's actually how we could, uh, accelerate them as well and, and so on and so forth. Everyone was excited, thought it made sense, lots of encouragement. I pitched it to every level of the organization from business leaders to the CTO that we had at the time to the CEOs. No one said no. No one said yes.

    9. LRLenny Rachitsky49:41

       Hmm.

    10. TCTanguy Crusson49:42

        For months. For months, I was in this limbo of, "I think everyone's excited about this. Everyone wants this to happen, but it's not happening." And so I remember talking, uh, by, with my boss at the time going, "What's going on? Like, when do I stop pushing? 'Cause at some point I'm sure I'm gonna start pissing people off." And he was like, "Well, basically when you lose the passion for it. Keep going up until you, (laughs) you feel like it's not worth pushing anymore." And I remember looking at this advice and going, "Wow, that was not helpful at all based on the situation that I was in." But basically, I, at some point, I, I basically gave up. What happens though, and I understood that aft- after because the company ended up going there just a year later, was that I misread the appetite and sense of urgency around that topic and the fact that Atlassian being Atlassian we invest in so many markets, we have many opportunities like this that sit on a shelf. Someone did the analysis. Someone created a business case. That thing makes sense. There may not be a trigger for the why now. So we need a very strong trigger for why now to go after it. And I did not do a good enough job at articulating this why now. Why, why do we have to do this now versus in a year's time, in two years' time? And the next team that came in afterwards did a much better job at that. But for me that's, that was, uh, a great learning, which is why great work can get barked and c'est la vie. And yeah, that's just what happens, which is we, because we have so many opportunities and there's many companies out there that are probably faced with that, doesn't mean that we have to go after all of them. And so... But it does make sense to explore them and then decide when to pull the trigger and the- that rationale for, the sense of urgency needs to be there and it needs to be built into the business case.

    11. LRLenny Rachitsky51:42

        This reminds me of my chat with Mahika who is, does similar work at Figma where she works in a lot of zero-to-one stuff, and she described it as your job is to keep the flame alive and help it spread throughout the entire business if you're trying to get everyone on board with a new idea. And I like this very tactical piece of advice you're sharing here of how to do that is make it clear why this is, uh, I, I think of it as why is it perishable? Why is this opportunity perishable? Why is it gonna disappear if we don't act on it now? And you could think of it as why do we have to do this now? It's not just like, "This is a huge opportunity." It's, "But we also need to do it right now to give people motivation."

    12. TCTanguy Crusson52:15

        Yeah. That was a, that was a huge learning for me. I wasted months on it, but, uh, like with every failure, learnings came out of it in the painful way. (laughs) So, you know, product managers are often biased towards action or at least that's my case. Like, I want to go and do stuff and build stuff and try stuff and, you know, wi- with customers. And so being idle, waiting for a confirmation is not a great spot to be, but sometimes you need to recognize when you're there and it's good to step back.

    13. LRLenny Rachitsky52:40

        This episode is brought to you by Coda, and I mean that literally. I use Coda every day to help me plan each episode of this very podcast. It's where I keep my content calendar, my guest research, and also the questions that I plan to ask each guest. Also, during the recording itself, I have a Coda page up to remind myself what I want to talk about. Coda is an all-in-one platform that combines the best of documents, spreadsheets, and apps to help you and your team get more done. Now is the perfect time to get started with Coda, especially its extensive planning capabilities. With Coda, you can stay aligned and ship faster by managing your planning cycles in one location. You can set and measure OKRs with full visibility across teams and stakeholders. You can map dependencies, create progress visualizations, and identify risk areas. Plus, you can access hundreds of pressure-tested templates for everything from roadmap strategy to final decision-making to PRDs. If you want a platform that empowers your team to strategize, plan, and track goals together, you can get started with Coda today for free. And if you want to see for yourself why product teams at high growth companies like Pinterest, Figma, and Qualtrics run on Coda, take advantage of the special limited time offer just for startups. Head over to coda.io/lenny to sign up and get $1,000 in credit. That's C-O-D-A dot I-O slash Lenny to sign up and get $1,000 in credit. Coda.io/lenny.

11. 54:08 – 55:40

    A quick summary of lessons in this episode

    1. LRLenny Rachitsky54:08

       Let's try to summarize some of the biggest lessons so far that you've shared before we get to broad discovery. So a few things I noted here, just like how to be successful building zero-to-one at a large company. One is be very clear, are the users you're gonna be building this new product to actually the same users you're already selling to? And it may feel like they are close enough, but in the case of HipChat, you learn m- maybe not and it's a lot harder than you expected. Two is, be careful when you rewrite. In some cases...... shut it down, rewrite it immediately, accelerate this new idea internally. In other cases, you shared, and so you could rewind if you want to get your- get the actual details of when it makes sense to go one or the other. Uh, sometimes doesn't make sense to rewrite, just- just keep what you're doing and focus on the user problems and- and don't slow down. Uh, another tip I wrote down is ignore the competition. Don't be obsessed with what they're doing. Focus on what your users are asking you for. And then this idea of paying attention to the why now, that's a really good one. Just like when you're trying to make a case, make it clear why it has to happen now. Is there anything else that comes to mind as I try to summarize some of the advice so far?

    2. TCTanguy Crusson55:11

       No. That seem- that seems like a good one. The main one I'm getting also out of- out of this is like the- or if you try to start new things, it's going to be coming from your drive and your passion, and- and- and- and that's what pushes stuff forward, so don't give up, uh, 'cause I- I- I, like, I tried really hard before getting to one that worked. So that's, uh, I guess that's probably a testament for it's possible.

    3. LRLenny Rachitsky55:36

       And a testament to your, uh, your grit (laughs)

12. 55:40 – 58:10

    The success and pain of launching Jira Product Discovery

    1. LRLenny Rachitsky55:40

       and- and, uh, desire to make something work. So on that note, let's talk about Jira Product Discovery. I know this is a success at this point. I know there was also a lot of pain that went into this and things that didn't work, so I'd love to hear both sides of it, just like what was hard about getting this off the ground, and then also just what worked. What allowed you to make this work? So start wherever you want to start.

    2. TCTanguy Crusson56:00

       Yeah. Cool. Uh, so one, uh, let's start through the good stuff, um, before we go back into therapy. Uh, the-

    3. LRLenny Rachitsky56:06

       (laughs)

    4. TCTanguy Crusson56:07

       ... some of the good stuff here is Atlassian, at that point, had, uh, recognized we are innovating, you know, big successful products, or by doing acquisitions, we have to correct that and start building new products ourselves as well. And so there was a huge push from the founders to go, "Hey, we need to- we need to restart that." Out of it came Point A, which was an internal incubator program that was meant to fix that. And the way they framed it was that innovation is like a muscle. Unless you exercise it, it becomes weak. And what we have to do now is to work on it again. And so out of that came Point A, and Jira Product Discovery was one of the... I think it was one of the 100 pitches that went through that in- innovation program. There were 100 pitches, and out of it came out three products that basically went through all the different stages of it. Uh, and so, uh, it started with the Jira Product Discovery was actually made possible because of that, and because we're inside Atlassian. So we started with a lot of... I could take time to focus on this stuff with nothing else to do. It- it- it was a full-time job because of this incubator. I was able to form a team easier because there was budget allocated. I was able to form a team that was not worried about losing their job because the program was made so that the... basically, technically speaking, you would borrow people from other departments. If that thing doesn't work out, they go back to your department. So there's no fear of loo- losing your job, basically. We were able to tap into all the research that was done by our research and insights team internally. We were able to have the corp- corporate development team working with us. I met with probably 20 companies that played in- in things around product management before forming a view that, "Hey, maybe we should play there." And all those teams are willing to talk to us because Atlassian is a big player in this market. And so there's always the opportunity of integrating, being bought, partnering, that kind of stuff. I was able to meet with analysts to say, "Hey, so what do you think about, you know, the product management

13. 58:10 – 1:00:13

    Incubating new products: the Point A program

    1. TCTanguy Crusson58:10

       market?"

    2. LRLenny Rachitsky58:11

       This was all part of the Point A, uh, structure.

    3. TCTanguy Crusson58:13

       So the Point A structure was basically, um... So not all of it was formalized in Point A. Remember, Point A back then was created alongside the bets, the first bets that went through it, and- and ours was one bet as part of that. So we kind of forged a path for all the ones that came afterwards. But basically, it gave us the- the creds to go in and ask for help from everyone, and everyone knew it was important 'cause everyone used the- knew the company priorities, and the new products were top company priority. And so Atlassian, playing the long game, had decided that it was okay to invest in these bets and to reassess them into every three to six months to understand whether we should put more- more- more chips in it, right? And so the psychological safety of everyone's job was safe, coupled with access to all the resources from the company, that part was just invaluable to the success of what JPD is today. So to give you a bit of context, J- Jira Product Discovery started four years ago with some research. I was alone back then, and then we were three. The first line of code was written, um, three years before we, um, launched officially as, uh, generally available, which means that for three years, we were in alpha, dogfooding alpha or beta, and able to do that with the full support of the company, right? So that's something which is like, when I mention the long game, I mean it. It's something that's very hard to get in most companies out there. And still the thing that I, when people ask me about how to start incubators, it's like, think about it with when you're going to get your dollars back, and forget about it for a while. What you need to see is how the teams are answering the right questions that they ask along the way and seeing whether you are still excited about the bets as they do that. So anyway, we... so we launched a year ago. Uh, fast forward, uh, to today, we've got 8,000 customers, amazing CSAT, great traction. It's one of the fastest growing products in Atlassian history, which is great. (laughs) So what was hard though, uh, the first one was, um,

14. 1:00:13 – 1:04:15

    Failure is the most likely outcome

    1. TCTanguy Crusson1:00:13

       reminding everyone that failure is the most likely outcome. And I will die on that hill to explain to people when they want to start things internally, frame it like that. Remind everyone there's a two- like, 70% chance, number completely pulled out of- pulled out of thin air, that whatever you're working on is not going to exist in six months. We are trying to launch a new product, enter a new market. Our goal is to get to $100 million businesses, right? So there's not that many of them out there.... we have tried and we have failed at a few of them at Atlassian, and so remember that. And it's super important to remember that, to remember that, because otherwise, the company has a tendency to tr- over-invest. Not the- not the company top down, parts of the company have the tendency to tr- come and try to help. So for example, here we want to build this, "Oh, if you want, we could change this service to be able to do X, Y, Z for you." No. We are a bet, which is seven people. Let's not drag the rest of the company into it. The appetite that the company has right now is those seven people. "We'll see what we can do with these seven people," was what I was telling everyone. The reason I was saying that is that otherwise, yes, you get the help, but the help always comes with condition, and the condition is usually things slow down, right? So what we try to do is remem- remind everyone, "Things are gonna fail," so that we could basically buy the opportunity to hack shit together that is not going to scale, that is not going to respect our design guidelines, that is not going to fit with the Jira target architecture. But we're going to test these with customers and see if the- the concepts make sense, if the prototypes make sense, whether they get value out of those, before we tell you, "Hey, you know what? That thing is a thing, and by the way, now we're a proper business. We should build that thing into the platform."

    2. LRLenny Rachitsky1:02:08

       This is really interesting because it's counterintuitive to think that you should position your new bets as, "This is most likely going to fail. This is just a thing we're trying. Don't worry. Don't commit too much to this yet. Don't worry about giving us all these resources." Why do you think that's so important? 'Cause that's- I don't think most companies position new incubations that way. Why- why do you think that's so effective and more effective?

    3. TCTanguy Crusson1:02:29

       Yeah. The- so the- the- the thing that we're trying to do when starting new products is to- to basically emulate a startup in an environment that is not hungry, like it's not starving. And so you need to create scarcity, like, we... What I wanted with my team is to make sure that they- they feel the urgency, that thing needs to move. I also needed the rest of the company to go away so we could get the autonomy to test the things that we needed to- to know whether this thing is even going to work on it. We could not go into a planning session for the next six months to negotiate something with a platform service so we can be on the future to then test with users. I was like, "No. We're rebuilding this component and we're testing this with customers next week." It's not perfect. It's not perfect. And so that- that helped us a lot, but otherwise there's always this tendency of the process that works for everything else is going to work for this, and we needed to keep reminding them, "Hey, we might not exist in six months. Do you really care that much about this process right now? The product might not exist anymore." The process goes away, usually.

    4. LRLenny Rachitsky1:03:29

       So it's basically a trick to, uh, keep everyone else within the org, uh, away and not, uh, worry about what you're building, 'cause they're l- you just tell 'em, "Don't worry, this is not gonna work out. We're just gonna try this thing just- just to see." So it's not like for your team to feel like this is probably not gonna work out. I imagine the team is like, "Oh, we gotta make this work. It's such a good idea." It's more to like, as a trick to keep the org from swallowing you up and pushing you around.

    5. TCTanguy Crusson1:03:52

       So there's- there's a part of that, but there's also, um, really a need from like if... We need to respect Atlassian's dollars here, and if we don't know whether this thing is going to work, I do not want to drag a team of 50 people into this. I want to know that this thing is worth the investment of a team of 50 people. So it's- it's a bit- it's a bit of both actually. Now it's- it's of course easier said than done and so that's where again point

15. 1:04:15 – 1:09:20

    Atlassian's four-phase approach to launching new products

    1. TCTanguy Crusson1:04:15

       A helped. We had four stages called wonder, explore, make, and impact, where in the first stage it was all about proving that there was a problem area we could go into, there was a market. We could answer very clearly, articulate why Atlassian should move there. We could articulate why now, that stuff that (laughs) struggled with before, and have enough data to validate all those claims. Explore was about exploring solutions, which doesn't mean build it and- and throw it out there and see what sticks. It's about if you get a bunch of customers raising a problem, can you get them to play back that the solution would address their problem? And so in the case of Jira Product Discovery, because we were not building, we didn't need any new technology, it was mainly new UX, uh, and new workflows, we basically validated all of that with Figma, with Figmas in- in like dozens of, um, uh, Zooms. But it's basically coming back saying, "Here's how those companies are framing it. Here's their problems. Here's how this thing would be solving it for them." So that's part of explore, which is validating that it's worth investing in, in terms of solution. We don't only have the right problem, we've got the right solutions. Then make is about making it happen in stages, starting with an alpha, then a beta, and then going out there. And impact is that stuff is actually ready to go GA, and now let's see the impact it has on Atlassian's business and keep, uh, monitoring it, uh, from there. And it- it turns into a real business from that point onwards. But everyone at Atlassian knew these four stages, wonder, explore, make, impact. Whenever we were talking with teams, we were telling them, "We're currently in explore." And we started doing that with the- the full bet itself, then we started doing that to talk about the different features that we were working on or problem areas we were going after, which means that now every time we go into conversation with other teams and we mention it's we're in wonder or we're in explore, they know what to expect. When we go to a, um, someone in the leadership team and we say, "We want to go from explore to make," they know they're going to ask for budget, right? Because they need developers now. So all that vocabulary and clear expectations set for every stage of the process really helped us to facilitate all the conversations that we had with everyone in the organization, and really protecting us- protected us again from, uh, all those basically teams that felt like they had to chime in. "No, we're in explore. We don't have anything ready to- that- that's been validated. Like, let's not have opinions about how the architecture is done before we have validated that customers want something."

    2. LRLenny Rachitsky1:06:52

       This is super cool. I feel like we could do a whole podcast just on the structure of Point A and how y'all do this. But just one question. What does the gate look like when you move from explore to make, make to impact? Is there, like, a group of people that sit in a room and decide thumbs up, thumbs down? How does that decision work? (laughs)

    3. TCTanguy Crusson1:07:08

       Yeah, so we basically write a, um, six-pager that, um-

    4. LRLenny Rachitsky1:07:12

       Hmm.

    5. TCTanguy Crusson1:07:12

       ... looks at all the different aspects of all the questions that we want to answer. And then, uh, we, uh, are in a meeting with the Point A stakeholders and the founders of Atlassian. And everyone reads that page for about 15 minutes, and then question, answers, comments and all of that. By the end of this meeting we know whether we are clear to go to the next stage. We got booted back, um, uh, one time when we were like, "Hey, we're ready to go into... anyway from alpha to beta as part of Make." And they were like, "No, you're not," and I was like, "No, we're not." And so we stayed and we basically got more time than what we had, was initially allocated to us. But basically the founders and the leadership of Point A, as well as heads from the different lines of businesses at Atlassian were participating, uh, in those, um, uh, sessions which-

    6. LRLenny Rachitsky1:08:01

       That is super cool.

    7. TCTanguy Crusson1:08:02

       ... basically visibility all the way up.

    8. LRLenny Rachitsky1:08:05

       And they might also just decide, "Let's kill this thing, it's not working," at one of these meetings?

    9. TCTanguy Crusson1:08:10

       So it might be, "Let's kill this thing," which happened to a number of bets, uh, that we did. Or it might be, "Let's, let's roll this thing into something else."

    10. LRLenny Rachitsky1:08:18

        Hmm.

    11. TCTanguy Crusson1:08:18

        So for example, our new whiteboards product, which, uh, I say product, whiteboards feature part of Confluence initially came out of Point A, uh, and was eventually rolled into Confluence instead because portfolio feed made more sense there.

    12. LRLenny Rachitsky1:08:33

        That's so interesting. So you said there's like a hundred projects that went through Point A, so there's kind of this funnel and there's these... Is there a meeting for all 100 of these that the founders go to for all these incubations, or is the... Or do they come join later down the funnel?

    13. TCTanguy Crusson1:08:45

        Uh, it's not, not the full hundred of them. Basically there's a first-

    14. LRLenny Rachitsky1:08:49

        Okay. Okay.

    15. TCTanguy Crusson1:08:49

        ... uh... I mean, when I'm saying a hundred-

    16. LRLenny Rachitsky1:08:50

        Yeah.

    17. TCTanguy Crusson1:08:50

        ... it's over a few different quarters of teams coming in and pitching.

    18. LRLenny Rachitsky1:08:53

        Yeah. Yeah. Yeah.

    19. TCTanguy Crusson1:08:54

        Uh, but no- ne- ne- not for the initial stage of entering Point A. It's usually when-

    20. LRLenny Rachitsky1:08:59

        I see.

    21. TCTanguy Crusson1:08:59

        ... uh, when they've been accepted. Yeah.

    22. LRLenny Rachitsky1:09:01

        I interrupted you and took us on a tangent. You were sharing centrally the things that went well and how this all came together.

    23. TCTanguy Crusson1:09:08

        So failure is the most likely outcome, is the one thing I would stand behind in, in everything because I've seen before what happens when we get too complacent with, "It's gonna work," right? Lessons from the previous things I was talking about. So

16. 1:09:20 – 1:16:16

    Breaking rules without breaking trust

    1. TCTanguy Crusson1:09:20

       this one, uh, really key. Second one, this one is much harder, uh, which is if you're starting something like this, your teams will need to break a lot of rules that are established, but they need to be able to do that without breaking the trust of everyone in the organization. The rules were created to support the business at the stage where it was successful and they just... it just so happens that they might not work for new bets. So you need... like the, the, the, the trick here is, for me has been to... okay, the way I pictured it is I've got a bunch of chips. Since I joined Atlassian, I've been accumulating chips. And those chips are like-

    2. LRLenny Rachitsky1:10:03

       Like social capital.

    3. TCTanguy Crusson1:10:04

       Yeah, it's like trust I've built with the founders, with, uh, different business leaders, with succeeding and stuff or failing and explaining why and trying to do better next time. And, like, all that stuff gave me a, like you say, capital. I've got these chips and I decided on this bet. You know what? I'm gonna go all in. Right? So I always said, "If I... if it works, it works. If it doesn't work, I'm probably out of here, but I'm going to go all in." See if I see something that's not gonna work, I'm gonna say it, we're not going to do it. And so I was... I knew I was going to put myself in, in tough conversations because people are here to protect things that need to be protected. They just don't make sense for the stuff I was working on. So one example, breaking rules without breaking trust, where it was tricky. We have a lot of rules in a company like Atlassian on this is what, um... this is how it works in engineering. I mean, engineers are the biggest part of our, our workforce, right? That's where, uh, all the, um, um... the... basically, shit gets done because engineers work on it. And what I needed was to be able to hire the right team, only principal levels, people who have a lot of internal creds so that they can commit to any team's repo, no questions asked. People who are not looking for the next promotion but they want, they want to make a splash. And when that's not possible, I wanted to be able to hire contractors to fill in the gaps and, and stuff like that. And I was like, "A lot of the rules that I need to be able to break is basically in engineering."

    4. LRLenny Rachitsky1:11:31

       Hmm.

    5. TCTanguy Crusson1:11:31

       So I decided not to have an engineering leader in the team and to do it myself. So I was the product leader and the engineering leader. I was technical enough to be able to have these conversations, but mainly I was just working with amazing engineers who just could self-drive themselves. So they were able to make changes in areas that were not owned by them, they were able to do changes that do not respect any of our standards, they were able to hack their way around rebuilding services and what, and whatnot. We are now not in the position where we need to do stuff like that, but at that time I needed to take a position like that, so, uh, we could actually go and move fast with basically the equivalent of being a startup inside Atlassian. That's not comfortable to do stuff like that. And I would not recommend that in, uh, many environments. Uh, Atlassian was very forgiving throughout the whole thing. It doesn't mean that it... I didn't grow gray hair, uh, on that. Uh, that was, uh, not, not simple. One of them rules, for example, was, uh... one of the rules is, at that time we didn't want to have a footprint in Europe back then for more engineering teams. It's different today, but back then it was like that. And I was like, "Shit, I'm based in France. I'm trying to start this stuff. I don't want to move to the US or move back to Australia just for this break now." So I hired contractors, lots of contractors when we started. Well, not lots because we're not a big team, but contractors to build this stuff. And again, contractors, they don't fall into the same roles as the rest of engineering staff. So-... basically all the, um, uh, rules around you need to contribute to... Uh, for example, the engineering team could say, for one day to the next, leadership could say, "You need to invest 15% of your time in reliability." And for us, it's like, "W- we're n- we're not there yet. We don't even have a prototype out." Yeah, but that's the company rule, all right? Again, no engineering manager and contractors when one of these rules applied. So it was, um... People who were looking at it from the outside were like, "Wow, dude, you're a... Are you sure you're okay with all this?" And it, it felt super uncomfortable, but we had the support of, of leadership from it. It's just a tough transition for Atlassian from the, "We only invest in the, the big ones or acquisitions," to, "Let's invest in, in, in making bets."

    6. LRLenny Rachitsky1:13:45

       This is a crazy story you're telling me. So you were, you were leading this team. You had... You hired a team of contractors to build this product. You were in a whole different, uh, country from the rest of Atlassian, basically. Uh, and the whole idea here was just to do stuff that wouldn't be necessarily allowed at Atlassian. They wouldn't let you work this way. And you found that to d- to make the thing you needed to make, uh, the thing that you were, like, betting your career on, it sounded like (laughs) , uh, I just had... You're just gonna be this pirate working on this thing in, uh, in France, and it worked out.

    7. TCTanguy Crusson1:14:18

       So the, um, the Point A f- uh, emoji in Atlassian is a pirate flag.

    8. LRLenny Rachitsky1:14:23

       (laughs)

    9. TCTanguy Crusson1:14:23

       I was not the only one. There were quite a few of us, uh, working on new bets, basically operating like that, each questioning different rules. The, the, the, the end goal was not to question the rules. The end goal was to get to the stuff that we needed to do, which is we just need to clean the space to work with users, to test prototypes up until it works, and, you know, progressively get to a, a sustain- to like to a, a product that's going to be enough to launch, right? So we never intended to break the, th- the rules. Which is the things that we were going to choose the ones that were going to work to support us in this mission and say no to the others. You mentioned Europe. At the time, a lot of other Point A founders were struggling with the fact that they were operating from the mothership in Sydney because they're still with everyone else, and so, uh, like, you talking about doing all this stuff, yeah, but remember that, like, we've got this, we've got this OKR thing, we've got this vision for Jira that we're building, like, you need to participate in all this. And so I was in Europe going, "Fine, schedule it in, at Europe time."

    10. LRLenny Rachitsky1:15:28

        (laughs)

    11. TCTanguy Crusson1:15:28

        And, uh, teams were like, "Oh, we..." Like, I don't... I, I, I think a lot of teams were like, "We, we don't care enough about this, plus they're telling us it's not going to exist in six months. I don't care enough about this to stay up late or wake up super early every day to disagree with them." And so there was a lot of the early success that we had in being able to move super fast that came from being so far that people just did not engage to stop us, and that's why we were initially the group with the fastest speed, then the other teams were able to like... then it was possible to institutionalize those things into Point A, to then make it possible to do it from within Atlassian, right? But at first, we just needed to blaze our way through, so that's, uh, that's what we did.

17. 1:16:16 – 1:17:22

    Early success and team autonomy

    1. TCTanguy Crusson1:16:16

       Uh-

Episode duration: 1:54:02