Intercom on Product: Keeping the momentum going as you scale

This month, Intercom turns 10 – a number that feels simultaneously too big and too small. We’ve come from a few founders with an aha moment to over 700 people working towards a clear mission. We’ve shipped countless features, invented and reinvented our Messenger, and then reinvented it some more. We’ve gone from lots of processes to no process to, finally, a sweet spot in the middle.

As we reflect on the lessons we’ve learned along the way, we keep coming back to speed. At Intercom, for as long as I can remember, we’ve been obsessed with moving fast and shipping fast, with being quick on our feet and in our decision-making. Speed is your one advantage against bigger, more established companies with plenty of resources at their disposal. And, as I like to say, fast gets good quicker than good will ever get fast.

But alas, as startups scale, as more people join and those people turn into teams, which then turn into teams of teams and into orgs, you’re adding a lot of complexity to the mix. And that is guaranteed to slow you down.

For the past 10 years, we’ve been actively fighting against this natural decay of momentum. And so, on this very special episode of Intercom on Product, Paul Adams, our SVP of Product, and I look at the past 10 years of Intercom’s journey and reflect about speed – how to increase it, how to recognize what gets in the way and how to get rid of all the necessary fillers.

If you’re short on time, here are a few quick takeaways:

• As a startup grows, things like more teams, processes, and cross-collaboration are unavoidable. But the one thing you should never sacrifice is the company’s speed — it’s a lot harder to increase momentum once you’ve slow down.
• While processes are necessary to reduce risk and uncertainty, any step you add to a process is a guaranteed slowdown and a potential improvement. So, be mindful of the steps you’re adding.
• Making quick decisions doesn’t mean you should be hasty. It’s ok to think things through or wait for more data before making a call. But sometimes, it’s better to just launch the feature and work out the kinks later. After all, you’re never going to be 100% sure of anything.
• A good way to reduce the complexity of your operational cadence is to just kill that extra meeting, that extra step you’re thinking about. Feel whatever pain that absence brings and regroup a few weeks later with a better, lighter way of addressing it.

If you enjoy our discussion, check out more episodes of our podcast. You can subscribe on iTunes, stream on Spotify or grab the RSS feed in your player of choice. What follows is a lightly edited transcript of the episode.

10 years of Intercom

Des Traynor: Welcome to the latest episode of Intercom on Product. Today is a slightly special one in that it’s the 10th birthday of Intercom. We have been from four people to over 700. We’ve gone from no revenue to whatever the publicly available figure for our revenue is. We’ve been from no offices to five offices, and now we’re back to no offices again, and we’ve been from no process to lots of processes, to no process, to somewhere in the middle. We’re going to talk about what’s changed and what’s stayed the same. As always, I am joined by our SVP of product, Mr. Paul Adams. How are you, Paul?

Paul Adams: Not too bad, Des. Thank you.

Des: Wonderful. I guess we’ll just start with this idea of the evolution of the company. Every startup goes from being just a few founders or whatever to being some teams, to being teams of teams, to groups and orgs. And before you know it, people start talking about cross-functional collaboration and socializing ideas around the org and all of that bollocks that no one really wants to do. What’s it been like for you, Paul?

“The product, I think, went from ‘Just build the thing. What are you talking to me for?’ to ‘Listen to customers and then build the thing'”

Paul: Basically that, now that you mention it. When I joined over eight years ago, it was just an amorphous blob of people. We were all in one room. I guess we did have job titles, kind of, and we were just trying to build a product that people valued, loved, evolved, and then, like you said, trying to build a company. I think we started building actual product teams maybe six months after I joined, and we actually hired a PM and a designer and an engineering manager, and so on so forth.

Des: The product, I think, went from “Just ship it,” as in, “Just build the thing. What are you talking to me for?” to “Listen to customers and then build the thing.” Then it goes all the way up to, “You should arrange cross-functional things with sales, marketing support, and legal,” and then before you know it, you’re sitting in annual planning FY24. At the extreme end of this, and I believe we have enough DNA to fight against this, but the extreme end of that is you become one of those companies that pay for glossy high-res video demos of products that don’t exist just so the CEO can announce something at a conference, and then, four years later, the product team is still trying to catch up with what they pre-announced in 2018. That’s the extreme fail state that you just have to consistently fight against. What happens there, Paul?

Paul: Not good things.

Des: This is your fault, by the way.

Paul: When we reflect back over the last eight-plus years for me, 10 years for you, there are definitely two things that dominate. One is a load of ideas that years ago I would have said, “We will never do that. We will never be that kind of company. That’s a stupid big-company thing.” Things like, “Hey, maybe we should have an annual roadmap.” I’m like, “Annual? What? Next year? We don’t know what we’re doing next year. That’s way too far away into the future. Take care of the present, and the future will take care of itself,” or whatever.

“There are lots of things we do now that we would have thought in the past weren’t going to be good things to do”

Then you have customers signing multi-year deals, and they ask you, “Hey, what’s coming in that multi-year deal?” And your answer can’t be, “We’re not that kind of company.” There are lots of things we do now that are good things to do that we would have thought in the past weren’t going to be good things to do. The other side of it, of course, is all of the crap that isn’t a good thing to do, but comes with scale and complexity and growth, and lots of people talking to lots of people, and suddenly you’re just this big, slow-moving company with lots of things that are just unnecessary byproducts of something else, and then people are like, “That’s just the way it is around here, I’m not going to rock the boat.”

Des: Exactly. Every team has their own TPS reports and all that sort of stuff. The events of scale just conspire to slow you down, and there is this gravitational pull as you grow. It’s like the world wants you to slow down, and if you don’t fight maniacally against it, you will slow down. Then once you do slow down, you’re no longer what you set out to be because your execution capacity has gone, the whole cadence of the company shifts. Next thing you know, you talk only in quarters and not in days or hours or whatever, and then you lose your grip on what actually made you good in the first place.

The need for speed

Des: I will just say, to counterpoint, I think a lot of the things you talked about, as you said, whether it’s annual roadmaps or having a team, they’re all necessary things. As your product grows and becomes mission-critical, you start to realize, “Wow, it’s beneficial to have one team thinking about the inbox full-time,” the inbox being a mission-critical part of Intercom. And so, you decide to establish long-term technical ownership in the form of a team. Then you have another area of say, our product, the messenger, and that’s also a mission-critical piece, and so you put a team there. Before you know it, you’ve got two teams and you need cross-functional collaboration because if we want to make a change in the messenger, it affects the inbox, and so these teams need to work together.

I guess I’m just saying that, in defense of scale, some of this stuff is the result of ambition. If you are ambitious about what the product will offer, about what your product can achieve, and how big your business can get, there are some invariants of scale that are unavoidable. Things like management, collaboration, product working in tandem with sales, marketing, support, et cetera. They’re all going to happen to you.

“The one big, big, big thing that you just can’t sacrifice is the speed of the company, the operational cadence”

The one big, big, big thing that you just can’t sacrifice is the speed of the company, the operational cadence. I think that’s what we’re going to talk about mostly today is how to diagnose speed problems. Why speed is important, how to get speed, and just ultimately, I’ve been on record many times saying speed is the only thing you have in your back pocket as a startup when you’re trying to compete. I’ve also said that the reason I think speed’s important is because fast gets good quicker than good will ever get fast. We’ll just take a bit of time today to get into it. So, Paul, I’ll start with you. Over your eight years, which is functionally the entire time of Intercom’s product life, in a sense, what happens to companies as they grow?

Paul: One distinction that I want to make, and I’m going to get into this in a minute, is the distinction between speed and momentum because I think momentum is actually a very powerful thing to think about and something we’ve been talking about recently, but it’s often come up over the years. You said an interesting thing there, Des, a minute ago, about being a big company and ambition. I think, for us, one of the things we’ve often said to each other and internally to people is that we are not trying to be a big company, but our ambition requires us to be a big company. That gets into the idea of mass. How big do you need to be to get done what you need to get done?

“Slowness happens bit by bit, small thing by small thing. It’s a bit like you’re a frog being boiled – you wake up one day, and ‘oh, shit'”

Becoming bigger doesn’t have to be a bad thing at all. But when companies get bigger, they get more complex. More teams, more orders, more people to talk to, and the default is that they get slow. That becomes a competitive disadvantage. But I think the tricky thing about this is that slowness happens bit by bit, small thing by small thing. It’s a bit like you’re a frog being boiled – you wake up one day, and “oh, shit.” Maybe you’re not dead, but you’re not in a good place. The longer it took and the slower it was, the more you might not have noticed it. And then, it’s so hard to unwind everything. And it reinforces itself because the company is growing and you’re adding more people…

Des: It leaks into your culture. Your culture becomes slow, and then people join. It doesn’t matter how many fucking Google Docs you produce – the culture is what sets the fucking momentum, right?

Paul: Exactly. We have this obsession with moving fast for all the obvious reasons, and I’m sure lots of people out there do as well. But the new people join typically from slower companies, and they’re like, “Shit, Intercom is fast.” But if we’re getting slower and slower and slower, they’ll just adapt to what they’re more familiar with. Then, it becomes okay to move at that slower pace, and as you said, that’s the new culture, that’s the new norm. And it’s very hard to increase your momentum when it’s slowed down.

Let’s get physical

Des: We talk about speed at Intercom, or momentum. What are the outputs of that? Are we talking about the rate of product change, the rate of decisions made? Is it all of those things? What makes a fast company?

Paul: Personally, there’s only one true thing that actually matters, and that is delivering customer value. Delivering product that solves problems for customers that aren’t solved well today improves the product for them. It’s delivering things customers care about, want to use, want to buy.

Des: I totally get that. How would you measure that? Obviously, it’s not kilometers per hour, but what is it? Is it meaningful improvements to the product released in time period?

“The way we’ve always thought about this at Intercom is product changes shipped”

Paul: Yeah. The way we’ve always thought about this at Intercom is product changes shipped. So, how many product changes did we ship? That’s become more complicated. It’s not as simple as just counting the number of changes because, for a start, changes are different sizes. You can have really big releases or small releases. They’re not equal. One took a lot longer than the other. Then, once you get down into some of the nitty-gritty, fixing a bug isn’t really a product change, and there’s a gray zone between, “Well, we’re technically just fixing something that’s broken, but actually we’re also making the product better.” Some companies might count it as a change, others wouldn’t.

Des: But there’s some sense in your head, how much does this change weigh on the scales? Brand new feature, brand new product, that’s big. It might only be one thing, but it’s one big thing. So our team might do 10 little things, and you probably have some rough, “Yeah, that seems like a decent cycle’s work or a decent quarter’s work.” Right?

Paul: Yeah, exactly. You can measure this in lots of different ways. Teams can retrospect and think, “Hey, did we have a good quarter? Did we have a good week? Did we have a good day? Did we have a good year?” You can look at teams, compare teams to each other and say, “Hey,” and obviously, there are lots of other mitigating circumstances, like people leaving teams, joining teams, all sorts of stuff.

“Momentum is velocity times mass. Velocity is how fast you’re moving. The second thing is mass, which is, “How many people do we have?”

Des: If you quit Intercom tomorrow and joined Quasi-corp, which is doing a fantastic expense-tracking platform, how would you get a sense of whether it’s a fast company or not? What would you be looking for?

Paul: I’d love to get into thinking about momentum, and this might get a bit like physics-y in a minute, but this is what I’d go in and look at. Momentum is velocity times mass. Velocity is how fast you’re moving. For us in building software, that’s how fast we’re executing. That’s maybe product changes made. And then, it’s not just speed, it’s speed in a specific direction of the strategy. So you look at how fast we’re executing – is everyone moving in the same direction? Are we just executing blindly all over the place?

That’s one thing, velocity as a company. And then, the second thing is mass, which is, “How many people do we have? How many teams do we have?” You can dig into both of those areas and ask, on the mass side, how big are the teams? Are they efficient? What are people doing? How are they making decisions? On the execution side, what are people’s expectations of what good looks like? Shipping product changes and not shipping product changes – do they all add up to a strategy? So there are specific things we can drill into.

Async vs sync culture

Paul: And the other thing, I often say to people momentum is infectious, and when a company is a high-momentum company, you just know. You walk in the door and you can feel it. The first time I ever walked into the Facebook office, the HQ in Palo Alto circa 2010, I was driving from the Google offices into the Facebook offices, and holy shit, the difference. In the Facebook office, the momentum was infectious. It was in the air. You could just feel.

Des: Just buzzing. The noise, the pace, people storming from desk to desk getting stuff done.

Paul: Yeah. People were just like, “We are on it. We’re on a mission here.” And it was just amazing and brilliant to be a part of. So it’s really infectious. A lot of the things that create that atmosphere are happening in the discussions people are having and how fast they’re making decisions. It might really just boil down to that simple thing of how fast people make decisions.

If you’re walking into a room and it’s like, “Here’s what we’re going to do. We’ve got to do this, we’ve got to do that. What do we know? Who’s deciding? Are we deciding now? Are we deciding today, tomorrow?” and we’re shipping and getting customer feedback, and it’s a whole beautiful virtuous loop. That’s just a very different feeling to a company where you walk in and there’s a lot more procrastination: “Hmm, interesting. Let’s think about that.”

“People don’t realize that the reason things end up quarters late is because you lose a quarter in days and half days, you don’t actually lose it in one-quarter decisions”

Des: There’s a meeting on Thursday that we’re going to go to where we’re going to learn what we’re doing.

Paul: Some versions of this have some validity, of course, like, “Hey, we need more data. We’re not sure. How sure are we? We’re 60% sure. We want to get to 80% sure.” Then the worst versions of this are things like, “We can’t decide today. We’re going to decide that next week.” I’m like, “Why are you deciding next week?” And it’s like, “Ah, Des is on holidays.” “All right. Who’s Des?” “He’s our designer.” “All right.” “It’s a kind of design decision.” “Well, it’s not really a design decision, it’s a PM decision.” “I don’t really want to upset Des, he’s on his holidays. When he comes back, we’ll have a chat. Actually, our team meeting’s scheduled for a week after he comes back, we’ll probably talk about it then.” And I’m like, “Uh oh.”

Des: People don’t realize that the reason things end up quarters late is because you lose a quarter in days and half days, you don’t actually lose it in one-quarter decisions. No one’s like, “Let’s push this whole thing out a quarter.” It’s just the consistent aggregation of those.

Some amount of this has got to do with the companies who insist on a synchronous culture, as in everything has to happen in meetings, and therefore everyone needs to be around at the same time, and therefore it needs to get scheduled, and therefore it needs to get pushed out a week, versus Slack threads, Basecamp, Gmail. Whatever the tool is, many decisions can be made async. Is it fair to say an async culture can be a lot faster because you just don’t have this calendar collision problem?

Paul: It’s a good question. We were a very synchronous, face-to-face company and culture for all of our early years up until the pandemic forced us not to be, in a way. I think you can have an insanely fast culture, high-momentum culture. Facebook was like that, too, back in those days. It was all face-to-face. Nothing was even written down. So I think you can have it in a synchronous live culture if that’s how people operate and behave.

“When you have a free calendar in a synchronous culture, you just walk down the hall, ask Des to make a design decision, and that’s an actual easy thing to do”

Des: I think you’re correct, and simply being async doesn’t mean you’re moving fast either. You used the phrase work work earlier, and when I hear work work, usually what my mind jumps to is the worst form of yak shaving – something that’s indirectly, potentially associated with something that might help something that might help us ship software.

I think we have been pretty good at fighting against anything, whether it’s process steps or reports or whatever, where people can lose hours or potentially weeks or let their calendar get filled up on these empty carbohydrates that ultimately don’t really matter. When you have a free calendar in a synchronous culture, you just walk down the hall, ask Des to make a design decision, and that’s an actual easy thing to do. Whereas if he’s busy, like dotting I’s and crossing T’s on a dozen different outcome reports or whatever, then you can genuinely feel that delay of, “We’re a synchronous culture, but the person I need to talk to is fully booked.”

Paul: Yeah. In all of the things we’re talking about today, there’s obviously a sweet spot. For example, in a fully live synchronous culture, maybe people feel like everyone needs to be part of the decision, and that’s not necessarily the case. That’s only a problem if the expectation is set within the culture that everyone should be part of the decision. Then you get the worst versions of this, which is some kind of democracy or something.

There are other extremes where people are just left out of the loop. You have an alpha culture where people are just deciding, irrespective of other people’s opinions. But there is certainly a sweet spot, and I think, again, it’s often just the boiling of the frog. Little bit by little bit, the culture starts to naturally gravitate towards trying to include everyone or get more data. It becomes a little bit more conservative as you grow, and it’s something you have to actively fight and think about.

How much process is too much?

Des: You talk about decisions as being the core ingredient of speed or possibly the cause of delay, in a sense. If execution is primarily about rapid decision-making, how do you design an org that makes sure we can make fast decisions consistently? You hinted at some of it there. Maybe it’s the right amount of autocracy or the right amount of a dictatorship. Maybe it’s the style of decision-making. How do you make sure that decisions happen quickly? As I’m saying this, I realize product folks are often the owners of the process, the owners of the decisions, the roadmap, and all that sort of stuff. Potentially, Product is the single biggest inhibitor or enabler of speed.

Paul: I’m going to get to that in a second. One caveat or a disclaimer is something that I often push back against, this idea of more haste, less speed. Other cultures and teams I’ve worked in in the past, and it’s happened at Intercom a few times too, is we’re over-optimizing for speed and it’s haste – we’re not making good decisions, we’re just making hasty decisions. You can over-egg this thing for sure.

“Any step you add to a process is a guaranteed slowdown and a potential improvement. You should be picky about what gets in and what gets out”

Paul: A good way to think about this, for me, to make this more practical, is a process that we’ve iterated over the years. Processes exist for things like we try things, we learn lessons, then we encode the lessons so we don’t make the same mistakes in the future. The process is important, and people follow the process. But you can also become…

Des: A slave to it.

Paul: A slave to the process. One thing you’ve talked about in the past is the Iron Law of Bureaucracy.

Des: Pournelle’s Iron Law of Bureaucracy. That’s the idea that in any organization, there’ll be two kinds of people. The first are the people who you want. These are people who are devoted to the goals of the organization. In Intercom, these will be the people who are dedicated to making sure that we build good product fast, that our rate of customer experience of our product is improving really, really fast.

The second type of person would be somebody who’s dedicated to the organization, independent of the goals, which is, “There’s an Intercom way of doing things, and we’re going to do it the Intercom way,” independent of whether or not it achieves the goals. These people will love processes, and they’ll happily inject 25 more steps, five more docs, and three more meetings into anything they touch.

“Any startup, at any stage, honestly, should be really wary about any move to expand or grow its own process”

The law says that, basically, the second group will always overpower the first group – the people who care more about the process and organizational discipline will overpower the first group, they’ll gain control of the organization, they’ll write in more rules, they’ll control everything about what actually happens.

The solution to that is to really, really, really fight back against anyone who is in the second category, and that’s often not popular. And this will happen. We’ve employed over 1000 people over the years, people have joined us from large companies, and they’ve brought the big bag of spreadsheets and flow charts and processes they want to roll out. When you assess these things, what you see is, “This will definitely slow us down and maybe improve us,” I guarantee you, the definites will happen. Any step you add to a process is a guaranteed slowdown and a potential improvement. You should be picky about what gets in and what gets out because otherwise, you are going to walk into this Iron Law of Bureaucracy.

The extreme end of this, and I’ve sat in on board meetings for companies, I’ve advised companies where this has happened, where people celebrate a good product launch or a good product project entirely based on its adherence to the process. And they say, “It came in on time. It had all the features…” And I’m pulling my hair out going, “But no one’s using it. How are we celebrating this? This has been an absolute dismal failure in reality. The only place this is all green lights is in that spreadsheet. And P.S., if we wanted to produce an all-green spreadsheet, I can make one pretty quickly, but we’re actually trying to build fucking software.” Any startup, at any stage, honestly, should be really wary about any move to expand or grow its own process, which is why I fight with you so often, Paul.

Paul: I’m going to give process some positive airtime here in a sec. But you’re right, process grows. The natural, default path as a company grows is that the process will grow. But the process also exists for a reason, and when we have people joining Intercom, we do want them to learn our process for building software.

“I love it when people are executing on the edge of the process. Yes, they’re following the process, but at the same time, they’re also asking, ‘Can we reduce this?'”

Like I said earlier, the process is just all the lessons we’ve learned encoded into some rules that we think will help people avoid mistakes that we’ve made in the past. Those do good things. It reduces risk, it removes uncertainty. If people follow the process, they aren’t questioning, “What am I supposed to do now?” And it’s especially important for newer people. Standardizing things helps people not question them. It’s faster for them to decide. The thing for me, though, is that I love it when people are executing on the edge of the process. Do you know what I mean?

Des: Right.

Paul: Yes, they’re following the process, but at the same time, they’re also asking, “Can we reduce this? Can we remove this thing? Can we make the process shorter, smaller, faster?” I love when people are both simultaneously executing the process, that’s there for a good reason, and it’s coming from a good place and a place of evidence, and yet continuing to try and make it better and better and better. That, to me, is the sweet spot.

How to build momentum

Des: Those types of questions are the ones that accelerate a company. Where people are looking not to cut corners but to skip unnecessary steps or do the minimum amount of work work to move forward. What are those? How do those come up, and what is it you like about them?

Paul: I think there are momentum-building questions people can ask. Again, these can fit into any kind of process, really. They range from things like, “Why are we blocked? And how do we unblock ourselves?” Or, “Hey, we’re procrastinating. Why can’t we decide now? Why are we waiting? Why aren’t we just chasing this down, finding a new, different, better, faster way to decide? Who’s going to make this decision?” And then, what’s the minimum we need to do to learn to unblock progress? “Okay, the process is we need to do 10 units of work. Do we need to do those 10 units, or could we do it in six units? What’s the minimum we need?” Those momentum-building questions are really important.

“Why wait to be 90% sure or 95% sure? God knows we’ll ship the thing and our customers will sure as hell tell us we’ve got it wrong”

Then, there are just some momentum-building actions you can take. Things like let’s meet and debate now. Don’t wait until the meeting next week, do it now. Decide, “Let’s make the decision with who we have now.” Don’t wait until the other person gets back from holidays. Then lastly, “Let’s decide what we know now. We’re 80% sure.” That’s good enough. Why wait to be 90% sure, 95% sure? God knows we’ll ship the thing and our customers will sure as hell tell us we got it wrong. So let’s get out earlier with less confidence, knowing that we’re going to learn and get faster and better.

Des: For the folks who work in product orgs, what is a good thing for them to identify how to speed up causes of slowness? Where would these momentum-building questions and actions be most powerful? What would you advise them to do?

Paul: Two things. One, I’d go back to the physics description of momentum we described earlier and look at their org. It’s velocity times mass. So what’s giving us the velocity? How fast are we executing? Is everyone in the right direction? Then, times the mass: How big is the team? Do we need a bigger team? We might need a bigger team. Or is the team too big? Maybe we need a smaller team. Another thing I’d suggest is just going back to the history a little bit. You’re in a certain place today, where did that come from? How did it evolve? How did it grow? We said at the start, slowness comes in small pieces, bit by bit.

Des: Trace these things all the way through and see what happens.

Paul: Yeah, because sometimes things are made for good reason that not no longer exist. Things can change. We don’t need that thing anymore. Or we have gravitated culturally to some principle that we believe in, and we’ve taken it a little bit like religion, a bit like dogma, and it’s now become way greater and exaggerated than it actually needs to be, and we should dial it back again.

“We assume every project is working according to plan, and we assume that if that’s not the case, we’ll hear about it”

Des: Along with the operational cadence of a company, what are the core behaviors that enable speed? It never fails to impress me how many meetings we don’t have at Intercom because of some basic assumptions. We assume every project is working according to plan, and we assume that if that’s not the case, we’ll hear about it. We assume that people are unblocked and we don’t have a daily meeting to find out who’s blocked. We assume everyone’s unblocked and let people pop their heads up if they’re blocked.

Oftentimes, simply having a standard of, “We assume the positive case, so keep going and let us know if that’s not true,” is so much faster than, “Let’s do a weekly standup, or daily standup, or daily check-in, or weekly reports, or any of that sort of stuff.” I assume people are doing their job and that if they’re blocked, they’ll let me know, or if situations are preventing them from doing their job, they’ll let me know. As a result, I don’t pepper them with questions every day about what they got done. I leave them to do the work. I just think some of the operational assumptions of a company can actually make it fast too.

Letting yourself feel the pain

Des: As we’re wrapping up here, this whole thing reminds me of that famous Jedi bell curve, the low-IQ version of the bell curve, which is basically saying, “We need to build really fast,” and the top of the bell curve, the average people are saying, “What we need to do is consider requirements, identify scopes, deliverables, assess time, cost procurement, estimates…” And the Jedi end is saying, “Nah, mate. We just need to build really damn fast.” I feel like every startup goes on that journey of trying an overwhelming amount of processes and conclude, “Screw that. The thing that matters most more than anything else is just moving really fast,” and that seems to be where you’ve netted out, too.

Paul: I think so. The only way to get to that Jedi place on the bell curve is to actively reduce things, remove things, reverse things. We’re back to the same thing – process grows by default, and you’ve got to actively manage for that.

Des: And basically fight against it. I think there are enough people in companies saying, “Let’s kill the processes. Let’s kill these steps. Let’s merge these steps. Let’s move faster.” I think it’s always an attractive trade-in for any PM designer engineer when they’re telling you, “I need to move faster,” or, “I want to move faster, and here’s how you can help me do it.”

“You don’t inherit any assumptions of the old solution. You let the pain represent itself and design something that solves the new problem”

Paul: One good example that might help people is something we do here pretty well, which is to kill things and then feel the pain. For example, we will say, “Hey, we’re going to kill this meeting. It’s become a bit bureaucratic or not that useful. We could do this stuff in better ways. Async, written docs, Slack, whatever.” So we kill it. We know we’re going to probably feel some pain and then we’ll bring back a new version of it that’s lighter, better.

Des: But more designed to solve the new pain, in a sense, right?

Paul: Yeah. But you’ve got to feel the pain. What we don’t do is try and redesign the thing to be slightly lighter. You just delete and feel the pain for a few weeks. It just takes a few weeks or a month or two. You’ll feel the pain, and then you’ll go again.

Des: You don’t inherit any assumptions of the old solution. You let the pain represent itself and design something that solves the new problem.

Paul: Exactly.

Des: That’s a good tip, too. All right. Thank you very much today, Paul. I hope everyone’s enjoyed listening, and we’ll be back in a few weeks with another Intercom on Product. Take care, everyone.