Tanguy Crusson, Product leader at Atlassian joins us on The Product Experience podcast this week to talk all about product launches. Tune in to find out his thoughts on why most products fail, and learn how he successfully launched a new product at Atlassian.

Key takeaways:

• Start with a clear goal: Before launching a new product, it’s important to have a clear goal in mind. The goal should be specific, measurable, and time-bound. This will help you stay focused and ensure that you are making progress towards your goal.
• Build a feedback loop: Getting feedback from your customers is essential to the success of your product. You should build a feedback loop that allows you to gather feedback from your customers and use it to improve your product.
• Embrace failure: Failure is a natural part of the product development process. Instead of being afraid of failure, you should embrace it and use it as an opportunity to learn and improve.
• Move fast and break things: To succeed in today’s fast-paced business environment, you need to move quickly. This means taking risks and being willing to break things in the pursuit of innovation.
• Iterate and improve: Launching a new product is just the beginning. You need to continue iterating and improving your product based on customer feedback and market demand.

Featured Links: Follow Tanguy on LinkedIn and Twitter | Atlassian Presents: Unleash – ‘How we created Jira Product Discovery’ video | Sean Ellis Test: ‘A successful method to figure out product/market fit’ piece

---

Episode transcript

Randy Silver (00:00):
Lily, I have a bad feeling about today’s conversation.

Lily Smith (00:05):
Oh, Randy, don’t tell our listeners that.

Randy Silver (00:08):
Okay. I confess. I don’t really have a bad feeling. I’m just using a technique that today’s guest talks about. He wants us to practise assuming failure for a product launch and he’s actually got a really good reason for it.

Lily Smith (00:22):
He really does. And you’ll have to stick around to hear all about it. But Tangu Crusson is here to tell us how he used this approach to help drive a successful product launch at Atlassian, where he’s a Head of Product.

Randy Silver (00:36):
Just one word of warning: make sure your team and your partners understand why you’re using this approach before you introduce it into a conversation.

Lily Smith (00:43):
Very good points, but let’s not waste any more time on the intro. Hit the music.

(00:50)
The Product Experience is brought to you by Mind the Product. Every week on the podcast, we talk to the best product people from around the globe. Visit mindtheproduct.com to catch up on past episodes and discover more.

Randy Silver (01:02):
Browse for free, or become a Mind the Product member to unlock premium content, discounts to our conferences around the world, and training opportunities. Mind the Product also offers free product tank meetups in more than 200 cities, and there’s probably one near you.

Lily Smith (01:29):
Bonjour, Tangu. How are you?

Tangu Crusson (01:29):
Good, thank you. Oui, merci [French 00:01:30].

Lily Smith (01:29):
Ça va bien?

Tangu Crusson (01:29):
Ça va très bien, merci.

Lily Smith (01:29):
See, now I’m practising my school French on you, if that’s okay?

Tangu Crusson (01:34):
Yeah, I think you’d go very far with that in France. You can survive the first 20 seconds.

Lily Smith (01:39):
Oh, brilliant. Okay, well now we’ve got that embarrassing intro out of the way. So we are talking today about how you launch things and move fast and break things and everything and do product better. But before we get stuck into this topic, it would be great if you could give our listeners a real quick intro into who you are and how you got into product.

Tangu Crusson (02:06):
Yep. So I’m Tangu. I’m a Head of Product at Atlassian. I’ve been there for about nine years. Got into product a bit by chance, mistake, however you want to call it. Like many people of my generation, when I started doing product, it was not really a well-defined thing. I mean, it was well-defined in Marty Kagan’s blogs, but other than that, in the industry, no one really knew that the job even existed, including myself. So I stumbled a little bit in my career, started in engineering, then because I could talk, I got pulled into pre-sales, and then I was really frustrated by that so I wanted to go into more post-sales and consulting.

(02:50)
I tried that. I did some architecture, I did some consulting. I kept going back and forth, tried to create my own startup, which went great for three years and then failed miserably. And at some point, I was just like, “There has to be a better way. There has to be companies out there that know how to ship product.” And I worked really, really hard to try and get into Atlassian, which was an up-and-coming company in Australia, 900 staff at the time. The brand name was not really there, but people were known for the craft of actually shipping products. And so I think I did 15 interviews to get there and I learned the craft on the spot there.

(03:32)
So I’m not making it look very sexy, but that’s how I got started.

Lily Smith (03:38):
And one of the themes of our chat today is about products and how they fail. And I think you have quoted that about half of all products fail. So where does this number come from, and why do you think this is?

Tangu Crusson (03:57):
So at some point, I sat down and I was trying to prepare for an internal conference at Atlassian, to try and talk to my junior PMs about what they should expect when trying to ship new things. Exploring things that no one else was doing before, exploring new products, or train brand-new features that were radically different to everything else that Atlassian was doing and felt was safe bets.

(04:26)
And I actually sat down to try and figure out which projects worked well and which ones didn’t. And I realised that the track record I had was not that great. When I say 50%, it’s an optimistic view. I’m trying to make it look good. But in effect, more than half of the projects I worked on really didn’t succeed. It’s either because either there were massive failures and I worked on a few. For example, I worked on HipChat for a while, which worked great, and then we completely got destroyed by Slack. But also, things that we had started with amazing goals in mind. But in effect, when we look back on the actual success, it was used in Atlassian, for example, by 50,000 users, and 50,000 users for Atlassian is nothing, right? It’s basically a trigger to kill a product or kill a feature.

(05:17)
And more than half of the things I worked on landed there. And for a while, it really, really bothered me. I was like, “There has to be a better way. There has to be a recipe that can take me to a better track record.” And I realised, after talking to more people and reading back those blog from Marty Kagan from 2007, that actually, I was about in the industry benchmark. And what bothered me was more that I wish I knew that was the case and I wish I could plan with that in mind. So there’s a point after which I started more doing that, which is, “Well, things are going to fail. That’s the most likely outcome. Where to now?”

(05:57)
And so I started to become a lot more comfortable with this and trying to coach teams around that because I think we generally underestimate the impact of trying to make everything work.

Randy Silver (06:07):
Have you seen executives at Atlassian, or executives at companies that you talk to, do they know this? Do they recognise this? Or is this something when you mentioned they’re all like, “Oh yeah, I guess I kind of knew that, but I don’t…” No one ever goes into a project saying, “Yeah, there’s a 50/50 chance of this working.”

Tangu Crusson (06:26):
So since I joined Atlassian, I think we’ve been through waves of this epiphany where sometimes we fully recognised it, but then we realised that it was really not institutional knowledge that this was how things work.

(06:43)
Why? Because Atlassian is a successful company, and with success, comes a lot of bias. And there’s this somehow built-in, really strongly held belief that what took us here is going to take us there.

(07:01)
And you mentioned stakeholders, and so stakeholders and leadership is interesting because I see that’s often a disconnection between how the founders view the things at Atlassian and how the rest of the company operates. The founders are very well aware of that, and they always try to push us in that direction: try things, and then if things don’t succeed, we’ll focus on something else. But in the rest of the company, we built and shipped Jira, which is a very, very successful product. And the processes that we have or that we had in the company back when I started working on new products were very much optimised around that. It’s working for Jira, so that’s the money maker Atlassian, so all the processes were built to support that and not built to support the more fast-paced, let’s try, but the likelihood is that it’ll fail.

(07:53)
So about three years ago, I worked with our CPO and the Head of Product for one area at Atlassian to go, “Hey, we have to change that and bring back this innovation bit where it’s safe and okay to fail,” which is why we started this thing called Point A, which is, you can think of it kind of like an internal incubator to go, “Hey, we haven’t really used the muscle of building new products for a long time, so let’s do that and we’ll design the process with failure in mind.”

(08:24)
So it’s expected that things will fail, and we want a track record of if we can launch three new products out of it, we’ll be happy and we know we’ll have more than 100 pitching into this process. And that started to bring back this culture of, no, no, no, actually it’s going to fail. Think about it this way. And so how are you going to make sure that it doesn’t for the next few months?

(08:50)
And this was then, because of some successes that came out of it, which is always the fucked up part, which is people look at successes to understand that failure is necessary, because of some successes that came out of it, we were able then to go back and explain, this is the process that we took that we believe should be taken in other parts of Atlassian, including in some that is successful because otherwise, we build a lot of weight in all our products for things that are not used that we should really should be killing.

(09:21)
And so I think it’s not a zero-one type of answer, it’s more like it’s a culture thing and having the understanding and the knowledge that it’s okay to fail and having seen teams fail and be okay and get back on their feet and seeing the result of that in actual successes is changing our culture on that front.

Lily Smith (09:44):
So you’ve recently launched Jira’s Product Discovery tool. How did kind of embracing this notion that you would fail help your team with this, and how did you make that part of the, I guess, the sort of principles of how you’re working?

Tangu Crusson (10:05):
Right, yeah. There was a playbook for how we built product at Atlassian that was trying to go as fast as possible to show me that a lot of users are using this. Most of the features or products that I worked on before, really the goal at Atlassian was get us to this path that goes from zero to millions of users, and if you can justify that, then you are good and you can keep getting funded and so on and so forth. I’m simplifying of course a little bit, but that was more or less the essence of how we were working.

(10:46)
And so when I approached this, I was like, “Well, if we assume that things will fail, then that’s probably a bad way to approach this.” That’s a bad way to approach this because if we ship a half-baked solution in Jira that’s used by millions of users today and we don’t get it right enough, then they would come in, they’ll try it, they probably wouldn’t understand it, they would see no value in it, they’d churn quickly. It would be an uphill battle to bring them back whenever we’re ready to accept them. And in the end, we would probably fail faster if we assumed that it was successful from the get-go.

(11:30)
So instead, the processes that we designed when starting this product were more around what do we need to learn at which stage so that we can address those questions head on, and actually be as crafty as we can to try and do that as quickly as possible, and either make a case for, “No, no, no, no, look, we actually overcame these hurdles, we should continue,” or, “Well, you know what? It’s really not working. We should stop.” And it’s much, much harder to stop something that’s got a lot of investment behind it and where there’s already a belief that the thing will work.

(12:05)
So we started from, “No, no, it’s not going to work,” and, “No, we don’t want a big funding, we just want three people to work on this to unpack a bunch of assumptions that we’ve made.” And then whenever we got to the stage where we’re like, “We can actually start testing this with users,” we’re like, “Well, for a while, we’ll just work with 10 companies and we’ll show that it actually gives value to them.” And then when we got there, we’re like, “No, no. We’re not bringing it to everyone yet. We don’t know whether we can get from 10 to 100, and then from 100 to 1,000 companies, and then from 1,000 to 10,000.”

(12:39)
The process was designed so that we can right-size the questions and the answers to be able to get us to the next stage of this product that made the most sense without getting the whole company to want to overinvest because again, Atlassian, millions of users, we could funnel something to Jira users, millions of Jira users overnight. And we were like, “No, no, no. Let’s not do that because you know what? We don’t know if it’s going to be successful. Remember that.”

(13:09)
Well, that helped us a lot as well to have to speak about it this way is remember, we’re a big company, which means that there are a lot of teams and there’s a lot of typically dependencies when we ship stuff, and there’s nothing that slows you down as much as having dependencies.

Randy Silver (13:24):
Is this an approach that you would use with a smaller company where you didn’t already have access to this many customers or is this something you think makes sense where you already have people in the ecosystem, in the environment, and you’re trying to expand the tools that they use?

Tangu Crusson (13:42):
What I’m talking about here is very, very contextual to the situation that we’re in, which is the latter. If I’m a startup, I have no choice. I don’t have these millions of users I can tap into, right? So for me, best to start and drum up interest from the get-go, focus a lot more on distribution from the get-go because that’s going to be the start. That’s going to be the hardest to get to. You may have the great solution. If no one hears about it, no one knows about it, you don’t have a solution. You have something that’s just a pipe dream. So it’s very contextual to that big company thing.

(14:14)
Same with discussion of dependencies. If you are a startup, you don’t have dependencies, you control your own fate. For us, we’re building something in Jira, and when we want to improve an experience that already exists, there’s two questions. One is do we work with that team to improve it? Or two is do we do it ourselves and diverge from what is currently status quo in the experience?

(14:35)
And the starting from failure actually made us go with, well, let’s remove dependencies because we don’t know if it’s going to work, so we don’t want to have even more of Atlassian investing in it. And two, it gave us the autonomy to be able to test stuff in that big company because we clearly articulated we don’t know if it’s going to work, we’re testing on experience, we are not engaging with your team, we’re not using your components, we’re not asking you to make changes to it. Nothing against you, it’s just that it’s likely that in six months, we don’t exist anymore as a product.

(15:07)
So that helped us a lot, and drumming that beat inside Atlassian for that long, probably about two years, created a space where we could actually run a startup in a big company, which is something I kept hearing about. I never believed in being a startup in a big company because you kind of have the benefits of one without the struggles, but at the same time, you’ve got all the drawbacks of a big company.

(15:35)
So anyway, that’s how really embracing failure has so many ramifications that makes that usually a good bet.

Lily Smith (15:44):
And you have your five phases that you kind of came up with or went through during this process, so what are those five phases and do you think that they flex or change depending on what you’re going through or are they kind of fixed?

Tangu Crusson (16:02):
Yeah. So these five stages are wonder, explore, make, impact, and scale, and they come from something we’ve been using internally at Atlassian, which we used to call, “The Atlassian Way,” which was a bit pompous at the time, but we were trying to formalise as a company, how do we create products? And those five stages came out of that.

(16:30)
You can think of it as a framework to approach new things, to ask the right questions at the right moments. And it’s not specific to creating a product from scratch or a feature. It applies, really, for any type of problem, solution exploration.

(16:47)
I recently had a good long chat with John Cutler who’s, as you know, super influential in the product space, and he said something that really resonated with me, which is product work is like a fractal. So you can look at it for a feature, but then you can have the same type of considerations, same process for a product or for collection of products, the portfolio, and so on and so forth. And at each level, you can pretty much apply the same principles.

(17:14)
This is the same here. So wonder is about… And it’s called wonder for a reason. It’s about unpacking problems/opportunities/really, really just trying to figure out where the hell you want to go. And often, it’s chaotic in that it’s not a straight line. For example, the speech for creating this product, I created it after doing explorations and research in the field that’s completely separate. And at some point, I opened the door by reading an article and then found some research from internally at Atlassian and went, “Whoa, there’s something there.” And as I was wondering, I started to find something that I was like, “Okay, that’s an itch I need to scratch. And so let’s keep unpacking that. Let’s pull that string and see where it leads.”

(17:59)
That’s wonder. And I often find that in product teams, we don’t leave enough time for things like this. Everything needs to be a assigned to a strategy or a goal. Very, very early on, at least for a lot of the product managers I talk to, there needs to be space for wondering because that’s actually how we often unpack the biggest opportunities.

Lily Smith (18:30):
Hey folks, are you looking for an opportunity to learn from the best, connect with other PMs, and sharpen your skills?

Randy Silver (18:36):
Then you won’t want to miss MTP Con in San Francisco on June 14th. This year’s lineup of incredible speakers includes Christian Idiodi, a Partner at Silicon Valley Product Group; Yi-Wei Ang, a Chief Product Officer at Talabat; Natalia Williams, Chief Product Officer at Hootsuite and many more.

Lily Smith (18:54):
Also, check out the schedule On June 13th. The team have arranged a bunch of in-person interactive workshops led by experienced product managers who will share their secrets and demonstrate their tips for success. These workshops are designed to be for everyone, total newbies and seasoned pros alike. Go learn some stuff and make some new product friends.

Randy Silver (19:15):
So what are you waiting for? Grab your tickets now at mindtheproduct.com/sanfrancisco and we’ll see you there.

(19:28)
Before we go into the next phase, I’m just curious, is this a discreet phase? Do you treat this as almost waterfall, you complete wonder than you go to explore? Or is this more of just a guideline and a checkpoint and say, “Okay, we’re kind of at this place. We don’t want to commit more resources until we have defined something, and we may come back to this, but we’ve defined the objective of the wonder state”?

Tangu Crusson (19:53):
Yeah. So wonder is about problems, explore is about solutions, make is about building it for real. If you think about them as phases, you are already looking at it through the wrong lens, so it’s more what you describe. Often, you don’t understand the problem enough until you’ve actually tried to explore solutions, go through them with customers, and then you go, “Oh, I understand better about the problem now because they actually gave me an example for how this would help them. But then as we were unpacking this, we realised that that solution, yes, would help, but it’s not that important to them,” for example.

(20:26)
So, wonder and explore go hand in hand. It’s more like a checkpoint for questions to answer. And those questions for wonder, do we have the right problems? Do we know who’s got this problem? Is it a pervasive problem? And related to all the other problems people have, is that really something that we believe we should go after and do we have legitimacy in doing so?

(20:49)
A big part of this is, why Atlassian? So in this product that I’m currently working on, we are doing this for product managers. Why Atlassian is very simple because most product managers spend their days in Jira and lot of them are trying to structure product conversations and they currently can’t do that in Jira because Jira is poorly designed for that and it’s a huge pain point that they’ve got. So legitimacy for why Atlassian, it’s a collaboration product. That’s what we focus on. Jira is used by all these product managers already. They’re asking us for this all the time. So those are kind of the questions that we’re trying to answer in wonder.

(21:25)
When in explore, it’s really more into solutions, but the solutions often inform the problem. And then make is about building, but when you explore, you often need to create quick prototypes and the throwaway. So it doesn’t mean first, you do the designs, and then you do the implementation. It’s more like trying to answer the right questions so that you have a certain amount of certainty that it’s okay to commit more resources.

(21:50)
So for us, wonder was committing a team of three, two PMs and a designer. Explore was a commitment to have a bit bigger team with engineers to be able to spike stuff, like five. And make was a commitment to try to get to 1,000 customers, and so we actually need a bigger team to be able to do that. But right-sizing the investments helps us, even though at every point in time, you can work in any one of these stages.

(22:23)
Today, for example, we’re unpacking things around how product managers work with their stakeholders, with them on their feedback. And people keep asking us about specific features because they come from competing apps or they’ve got a view in their head onto how that should work. And so we could build that, but as you know, it’s not the right thing to do for product managers. So that’s where we’re back in wonder here where we’re like, “So who do you work with? Why are things done this way? Why do you currently present roadmaps this way with your stakeholders which leads to feedback coming this way? And is that working for you? Is that working for them? What’s your motivation for giving feedback? What’s your motivation for receiving feedback? And are those matching? Is there the right expect expectations and alignment on that side on both sides?”

(23:14)
And so we are now a product, we’re exploring potentially new features. Who knows? That’s the wonder phase that we have for one part of the product today where we might expend more on its value, but it’s both for the product and for each of the product areas.

Lily Smith (23:32):
And when you are working with these kind of potential customers, as a big brand, what does that relationship look like? Because I imagine they’re probably Atlassian customers and other purchases of Jira or Confluence. Is there a level of expectation that they come with of how you’re going to be working with them? Would they expect then to have the product for free or would they expect to be compensated in some way because you’re not a startup? Well, you are a startup within, but you’re within a much bigger organisation.

(24:15)
I’m just curious as to how you recruited those initial customers and what that sort of relationship looked like.

Tangu Crusson (24:22):
Yeah, it’s very interesting because Atlassian is many things and many phases and it’s different things to different people. And so we have fast-paced things, we’ve got new products, we’ve got very established products all at once, and we actually do have great ways to recruit customers to work with.

(24:42)
One, for example, that they use all the time is the Atlassian Community, community.atlassian.com. Users go there and they support each other, and often, product teams chime in there as well.

(24:51)
My hypothesis when starting this was well, we could probably recruit our users from there and we could work with them directly there and let’s figure out the quickest way that we can get something to them so that they can test it and iterate with us on that. And so we found customers. We clearly set the expectation with them from the beginning like, “We are looking for people who can help us unpack these problems.”

(25:15)
We had people coming in, we started to have discussions with them, and in there, we identified 10 that we would call Lighthouse Customers. So they’re facing the problem in a very acute way. They’re very clear communicators, they’ve got agency to change things in their setup. They’ve tried many ways to do this before and failed and they’re not using any competitor app. So if we could find people that were ticking these boxes, then we were trying to convince them to work with us so that we could actually co-design the app together.

(25:48)
Which is why, although Atlassian is like there’s all these support channels where you can do things at scale and so on and so forth, that’s not the approach that we took as a young product. Instead, we created a Slack group, we invited all the customers there. We were in Zoom with them every day, exactly like a startup would do, except it was much easier for us to recruit people because there were already all these channels where our customers were very active in giving feedback and trying to support each other there as well.

(26:20)
So it’s kind of the benefits of a big company, but with a lot of freedom to work with customers in a very different way, much more hands-on. And for that, we just had to go through the hoops of checking that things were fine with the Ts and Cs, and privacy, and this and that to go, “This is a better programme. It’s not part of our terms and conditions when you sign up to our cloud products.” We say, “That’s an early access programme and here’s everything that’s specific to that, which means that the software itself can be decommissioned from one day to the next,” and people know that we actually had created… We set their expectation there and we had plans to move them out if it failed. “We’ll contact you, we’ll talk to you on Slack, we’ll talk to you on Zoom, we’ll send you emails. You agree to share a bunch of data with us and stuff like that,” which meant that we could really be in a more startup mode there, what you would typically expect in a startup.

Randy Silver (27:13):
So at this point, you’re testing things like feasibility, can you solve the problem, or is it usable? Is it desirable? And you’re getting good results, but you’re also focusing on product managers. And we have no budget, so how do you prove viability for something like this?

Tangu Crusson (27:27):
Well, the good thing is Atlassian’s existing pricing model works pretty well for things like this already. So in the list of risks that we had assessed for this project from the beginning, the hardest part would not be what you get to budget, but the willingness to pay for the value, which is also why we designed the pricing in a way that would make it attractive, seeing this as kind of an add-on to your existing Jira, so it could roll up in the same budget.

(28:00)
We put the price really low compared to the baseline that you see on the market because that’s our business model as well, which is high-volume, low-cost, low-touch. So let’s just say that Atlassian’s current business model where we’re trying to fit in, the low cost that we were able to afford because we saw pervasive problems that would be faced by product teams, but also engineering who also need to prioritise things with their teams, and generally that combined, low price, high volume, meant that it fits the Atlassian model and it could roll up into existing budgets. You already pay for Jira, if you pay 15% more, you get this value on top, for example. That’s about how we designed this whole thing.

(28:40)
It’s not as scientific as I would love it to be, but we probably spent close to six months in interviews and around willingness to pay and trying to talk to the buyers as well as the product managers and so on and so forth.

(28:57)
Anyway, we did the math, it all checks out in a spreadsheet. We are launching this product, making it paid super soon in a couple of weeks, so we’ll know for sure then whether it was the right… Yeah, whether it was enough.

Lily Smith (29:14):
And so there’s, I guess, there’s two kind of phases as well that we haven’t really gone into, which was the impact and scale. And I think impact was going into beta and then scale is that full launch that you just talked about. But just thinking about the beta sort of side of things, there’s that classic quote, I can’t remember who said it, but of if you launched your product and you weren’t embarrassed about it, then you’ve launched it too late.

(29:48)
Were you slightly embarrassed when you went into your beta phase and how did you decide, what kind of criteria did you have for going into that beta phase, and did you also go into that beta phase still with this view of this still might fail?

Tangu Crusson (30:06):
Good question. So wonder, explore, make, impact, and scale. Wonder, problem exploration. Everything is basically in spreadsheets and Miros and stuff like that. Explore, most of it is done in Figma. We have a prototype, we play with it with 10 users. Make, we try to go from 10 companies that use it to 100, which means that we need to polish a lot of the experience because, well, the 10 companies that we started with might not have the same appetite for things being unpolished and scrappy and the quality being half-baked and things looking really bad. So we had to go to one level of [inaudible 00:30:52], but just enough to get to this 100.

(30:54)
Impact is when we have, okay, the alpha was successful with 100 customers, we now want to grow to 1,000. And so growing to 1000, again, doesn’t happen overnight, means that we need to build enough demand for it. Like a website so that people could sign up to the product means that we need to be able to onboard these people so they understand the value because now we can talk to everyone face to face to onboard them into the product, which is what we were doing in the beginning, a one-hour session, let us get you started. Now the product needed to be able to do that.

(31:26)
That’s also where we needed to make sure that we didn’t have high churn, so we focused on that. So first, really focused on making sure people understand, making sure that they stay, and then start to trickle more people in, see how that works, that type of thing. So that whenever we got to the end of beta is when we had high confidence that this could actually work as a business and we could get to the next stage.

(31:50)
The end of beta was meant to be at 1,000 customers, except that we tried to send emails to our user base to tease our demand and poof! It skyrocketed. And so we’ve got into the thousands of teams before we even hit GA, which got us into more questions and problems like, “Hey, from a compliance standpoint, we’re not there. From a reliability standpoint, we’re not there. We’re not ready for this and so on.” That all happened during the beta, where we kind of went from, “Wow, this is amazing. People really want this,” to freaking out because the thing would fall over and we’d get a major incidence or something in terms of compliance, or we’d lose a lot of data. By the time we needed to go to GA, it was already too late, but it was also the right moment because if we had tried to do that before and the product was not getting this traction, there would’ve been little point in doing all this work.

(32:42)
So, we were embarrassed. Fucking hell. I was embarrassed by this thing. I’m still embarrassed every day by how little it’s supposed to do if we claim that we’re doing this for product managers. We get product managers singing the praises, but I’m looking at this going, “It’s just not enough.” And it’s been like that since day one. That’s the reality of it.

(33:03)
Yeah, I wish there was some magic recipe. I guess mainly the way I’d like to think about this is there’s important moments, like entering an alpha, exiting it, going into a beta. And so we clearly laid out what it meant and where the quality level needed to be at these stages, and then we also changed all the rituals we used in the team to be able to match that. So for example, when we went from, say, 100 companies to 1,000 companies, that’s when we realised, well, the bugs we’ve got fairly frequently, we can’t have those anymore because the churn will go way up, and then there’s no point in telling more people about this product. And so we need to rethink how we work. We’re not a prototype team anymore, we’re now a product team. And so what are the best practises to do that?

(33:53)
Well, what we landed on was there’s this pyramid of liabilities at the base, usabilities in the middle, and new features at the very top, and we reorganise the teams to focus on that. So instead of just being embarrassed, it was like, “Well, okay. What’s important is first and foremost, the app is up, it’s performing, it’s reliable. Meaning that when people try to do something, it does the thing or it tells them how to do the thing if they can’t do the thing.” All of that needs to be spot on. Then we’ll stop adding new features every week, and instead, we’ll focus on improving the current experiences that work, stop the experiences that don’t work, retire a bunch of features, focus and rewrite the ones that work really well. And then there’s a sliver on top where we’ll build new features where we still do stuff the scrappy way.

(34:43)
So, that helped us in trying to stay on top of this. It grows, it grows, it grows, and then it quickly becomes unmanageable in a bunch of different aspects. And I’ve seen many teams crumbling under the success of something. So yeah, I can’t tell you how many times I’ve been embarrassed. Yeah, I guess that’s just the grind.

Randy Silver (35:04):
That’s a great answer. Okay, we’ve got time for just one more question and we can’t go deeper into all of these things right now, but you did a really good talk on the topic and we’ll put the link in the show notes for anyone who wants to go into that.

(35:19)
I’m curious, after you’ve done this talk, as people have learned this from you, have people come up to you and asked, “How do I apply this to my company?” Is there some advice that you would give about that starting stage of how do you introduce the concept of starting with failure and doing it successfully? With the assumption of failure, that is.

Tangu Crusson (35:41):
Yeah, it’s really interesting. I feel for product managers, honestly. We’ve got a really tough job and where I feel like the job itself is ill-defined and that a lot of pressure is put on product managers without the ability to make the changes that would make them successful. And I’ve seen that a lot after the talk where a lot of people felt inspired to talk to me about things where they failed, for example, or that their organisation was absolutely not fine with this concept where half of their things might not work. And so there is a cultural problem overall, and I think it’s not just product managers. It’s the way businesses work and trying to make everything predictable and create processes that would always try to make things predictable.

(36:29)
So what I see as the biggest challenge for us now is actually trying to address that. And at this stage, I’ll be honest, we have no clue how to do it. We’re exploring a bunch of different options, but to really help product managers and for them to actually be successful in the tool, we need to help them a bit to be able to create these pockets, this space where they can actually do their work. And we need to be able to do that in a way that doesn’t create another safe, this illusion that you can enforce a process across the whole company and things will suddenly become predictable and fine.

(37:08)
So instead, how do we do it in a way that clearly explains and guides people towards… Not only give teams autonomy really, and this is what it means in reality, not just the concepts, but this is how you do it, this is how you say no to dependencies or this or that. This is how you should ask people for roadmaps that actually tell that story and clearly explains how they’re going after the hard questions and stuff like that.

(37:31)
But yeah, it’s an area. We are ourselves are discovering how to do that for ourselves, so I won’t have the pretension that we can just explain to the whole market how to do it, but we’ll certainly try to lead by example there and keep doing our product, get it out in the open, which is why we have this community where we talk very openly, we share the roadmaps, we discuss features, we do all of that openly in this community because we’ve heard people say, “Hey, that really helps me understand a bit more how you meant to use the app because I didn’t understand the ways of working behind it.”

(38:05)
So yeah, let’s just say that we’re at the dawn of a new era overall where product management is either going to make it as a craft, or like other crafts before, will disappear to be replaced by the next iteration, which I think is possible. We used to have business analysts, project managers now… Let’s try, product managers, we’ll do absolutely everything. Maybe at some point, it’s going to be specialised in more different crafts. I don’t think anything is settled there yet, which is why it’s so exciting to be in product. Really.

Randy Silver (38:32):
Oh, God. Then we’ll have to iterate on the podcast and do something else.

(38:38)
Tangu, it’s been fantastic. Thank you so much for joining us today. We really enjoyed the conversation.

Tangu Crusson (38:43):
Thanks. I really enjoyed it as well. I wish my answers were more coherent at times, but I hope it was entertaining at least.

Lily Smith (38:50):
Thank you so much.

(38:50)
The Product Experience is the first…

Randy Silver (39:04):
And the best…

Lily Smith (39:05):
Podcast from Mine the Product. Our hosts are me, Lily Smith.

Randy Silver (39:10):
And me, Randy Silver.

Lily Smith (39:13):
Louron Pratt is our producer and Luke Smith is our editor.

Randy Silver (39:16):
Our theme music is from Hamburg-based band Pau. That’s P-A-U. Thanks to Arne Kitler who curates both Product Tank and MTP Engage in Hamburg and who also plays bass in the band for letting us use their music.

(39:30)
You can connect with your local product community via Product Tank, regular free meetups in over 200 cities worldwide.

Lily Smith (39:37):
If there’s not one near you, maybe you should think about starting one. To find out more, go to mindtheproduct.com/producttank.