Intercom on Product: Speeding back up when momentum drops

In the race to win a customer’s business, it’s not really about how good your product is – it’s how fast you keep innovating. After all, almost any product or service can be replicated by a competitor. Speed, the ability to move and improve, to iterate and innovate, is paramount, and if you listen to Intercom on Product regularly, this probably sounds familiar. Not too long ago, when Intercom turned 10, we dedicated an entire episode to speed, or why startups should always strive to keep momentum as they scale.

Since then, in anticipation of Intercom’s R&D plan for 2022, we started looking at our internal cadence of productivity and kicked off a project to evaluate each process from ideation to shipping. We surveyed and interviewed key people in our teams to understand how they worked and how they saw Intercom’s internal operations. And sure enough, the feedback was that things were starting to slow down. That, just as we had mentioned a few months before, momentum was undergoing its natural process of decay. So, naturally, we hatched a plan to hit the gas.

In today’s episode of Intercom on Product, Paul Adams, our SVP of Product, and I reflect on our own shortcomings as we scale – and the makings of a much-needed course correction.

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

• A company’s differentiator, or the reason their customers choose them over others, only lasts as long as their ability to improve faster than others can copy.
• Honest feedback can be hard to take, but it’s essential to develop the type of culture that encourages people to constructively criticize processes, leadership styles, or approaches.
• When people detect a bottleneck in the system, the operational cadence of the company starts slowing down. And once momentum decreases, it’s a lot harder to speed up.
• Questions such as “Why isn’t this live yet?” or “Who’s making the decision?” don’t just help test the team’s momentum, they also help point out where the bottlenecks are.
• The people you’ve spent so long hiring and setting up for success will likely know where the company can improve if you’re humble enough to listen.

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.

A full R&D workup

Des: Welcome to Intercom on Product episode 16. I’m joined once again by Mr. Paul Adams. Paul, how are you?

Paul: I’m good, Des. Thanks. How are you?

Des: Very well, thank you. This is our first episode of 2022. A quick apology to all of our listeners. We know that we should have a better cadence for this. The actual problem is that we also have jobs, and that’s what kind of gets in our way, or at least it gets in my way. What’s your excuse, Paul?

Paul: Mine’s the same as yours. I just work on my job most of the time.

Des: I guess one of the reasons folks perhaps find the podcast interesting at times is we often just talk about what we’ve been working on. One of the things we sat down to do at the very end of last year was plan out 2022. An area we paid a lot of attention to was our own internal rate of productivity and efficiency, and we kicked off a project to evaluate everything, every process, every step, every part of how software goes from idea through to live production. We learned a lot. Paul, what did we exactly do? And how could people learn from it?

“When you hear from some of your best people you’re moving slower than you used to, that’s not good news”

Paul: Yeah. What we did was, for us, massively insightful, maybe more insightful than we ever realized going into it. It probably started around October last year, where myself and Darragh – I run a product team, Darragh runs an engineering team – were looking at how we work, and we’re hearing a lot of feedback bubbling up from some of our people that we were getting slower. And both Darragh and I have, as you have, Des, an obsession with moving fast and speed and efficiency. And so, when you hear from some of your best people you’re moving slower than you used to, that’s not good news. And we believe that if you become satisfied with how fast you’re moving in terms of shipping high-quality products to customers, you’re entering the world of complacency, and you’re just going to kind of spiral downwards.

We surveyed some of our best people and different managers and leaders in the product and engineering org, and they gave us amazing feedback. Then, we talked to them directly, one to one, to follow up and understand the nuances and the details, and pulled all those things into themes. We did this very fast, by the way – we did all this in a small number of weeks end-to-end. We pulled it all into a small number of themes, understood where and how we could change, looked at our process, looked at our culture, made some really sharp, incisive changes to how we work, and it’s been received really well. People were just fully energized by the whole thing. It was only last October that we started this, and we’re into the new year, but so far, so good.

Being open to feedback

Des: Just to modulate one piece out, the stuff we heard, it wasn’t like work-from-home, it wasn’t the pandemic. It was stuff that would’ve been true if everyone was in the same room, let alone the same office or whatever, right?

Paul: Yeah. And you have to be very open-minded, especially Darragh and me, as leaders and as our direct team of senior leaders. Some of this cut deep. It hurt to read it, knowing that we’re in charge and accountable for how the product and engineering team work at Intercom. Things like people being afraid to make some decisions, afraid to fail. There’s an aversion to taking risks. And so, people were doing things in a safer way, and there was some cultural component to that. And that’s not what we want at all. We also have a highly collaborative culture, people tend to be very thoughtful of one another and empathetic and kind, and that can lead to design by committee at the worst times. Everyone’s opinion needs to be included, and that’s not necessarily what anyone wants.

Other stuff where people were following our process kind of blindly and so they were reading the kind of principles we have and understanding what they are, and some of our people mention cargo culting, this idea that you follow the process blindly without really thinking critically about whether or not it’s the best way to work or the fastest way to work. Things like road-mapping were taking too long, too much work. There was actually a desire for more top-down leadership – at Intercom, we kind of operate with a very autonomous model of teams and groups of teams, but they were looking for a bit more direction from some leaders like myself and yourself on high-level strategy.

“It was definitely bruising to hear pieces of this, but you’d much rather take those bruises and not have everyone either afraid to say it or saying it to each other but just not saying it to you”

Des: Obviously, I read the reports as well. For me, two thoughts occurred. Could we have noticed this earlier? Or to some degree, let’s say that some of these things like, for example, people blindly following a process, culturally they don’t grow out of a vacuum. That was probably your reaction to a project that went wrong, and somebody came into the room, you or me, and said something along the lines of, “We didn’t follow the process. That’s why this didn’t work out.” And that got translated into, “If you don’t follow the process, that’ll be thought of as the reason why the project didn’t work or why things didn’t work well.” Has it made you more reflective? It certainly has for me. Has it made you more reflective on how or why you engage in things such that we don’t start new on-ramps onto new problems in the future?

Paul: Yeah, it definitely did. One thing it brought into sharp focus for us was that we are a very principle-based company and we have principles in the product and engineering team. We’ve three principles (as an end result of this project, we added a fourth), and then below that, we have a process, and the process is basically a bunch of things to do to enact the principles. And principles, by definition, are guidelines. Principles are not rules. I think that, because of the way we’ve evolved the company – we’re growing fast, adding people, the principles are quite strong and people like them a lot –, it led to people assuming they were rules versus guidelines, and people didn’t want to skip steps in the process. As a result, I think we’ve managed to say to people, “Hey, it’s the principles that matter, but they’re guidelines, not rules. And hey, after that, it’s outcomes, you know, efficiently shipping a great, high-quality product and our customers valuing it. All that good stuff.”

Des: The other thing that I was, I guess I wanted to say proud of, is that one of our core beliefs, and a national Intercom-wide value, is that we are confident yet humble. And I think this podcast might be an example of it. On the one hand, we are saying, “Here’s something you should all do,” and on the other hand, we’re humble enough to say, “Here are a lot of absolute mistakes we made that were clarified to us.”

“The two-way vulnerability and the transparency led to a symbiotic positivity and better ways of working”

The piece I was happy with was that we actually got the sharp end of the stick handed back to us from the team, which was really valuable. I think you have to have the right type of culture that lets people openly criticize a process or a person or a leadership style and say, “Hey, Paul, hey, Des, you need to take a stronger opinion here. You can’t just leave that up to us.” Or, “Hey, this process you’ve designed has turned into a box-checking TPS report that everyone does and no one understands,” or whatever. It was definitely bruising to hear pieces of this, but you’d much rather take those bruises and not have everyone either afraid to say it or saying it to each other but just not saying it to you.

Paul: Yeah, very much so. One of the things that was not necessarily surprising, but definitely in a moment of reflection was that going into this, we shipped 150 customer-facing changes. It’s not like productivity has ground to a halt and it’s just decision making, circular conversation after circular conversation. We’re actually good, I think. 150 things in a calendar year is obviously something to be proud of. But we were hearing it from the people on the teams themselves, the people working directly on the projects at the front line, especially people who’ve been here a long time, “Hey, things are creeping in as we scale.”

What was really good for me was that when we replayed this back to the org and said, “Hey, we’ve surveyed people. We’ve done interviews. Here’s what we’ve heard,” and the message was, “Look, momentum is really important. Momentum builds momentum, and we are simply less efficient than we used to be and we think we can improve here,” most of them loved that. They were like, “Yes, more of this.” It was like, “Oh, thank you. I shouldn’t have all these meetings that I think aren’t very useful anyway, I should skip all these steps that I thought I had to do.” People loved that message. I think the two-way vulnerability and the transparency led to a symbiotic positivity and better ways of working.

“That’s where any company can tap into extra energy or engagement from their team”

Des: It’s obviously useful for employee engagement. People want to believe in the process and how they’re building software. They want to believe that what they’re doing dramatically affects the outcome of the business. And I think that’s something that large companies, and I’m talking tens of thousands or hundreds of thousand employee companies feel, especially ones where they have a market monopoly. It’s hard to feel it if you’re working on a feature upon a feature upon a feature, and it doesn’t really matter whether it ships or not. It’s really, really hard to stay engaged and believe the work matters.

With companies our size, everything you do, when you’re doing it well, actually moves figures in our balance sheet. We’re either increasing upsell or decreasing churn or increasing the attractiveness of the project or whatever. People know that the work can have an impact. That’s what makes it more frustrating when you feel that you’re being in some way chained down or encumbered or that there are obstacles to you having the most impact. I think that’s where any company can tap into extra energy or engagement from their team. To simply say, “Hey, we want everyone here to be as effective as they can be.” And then having an honest conversation with everyone saying like, “How are we messing this up for you? What would make you better? What would make this job more enjoyable for you?”

It’s something I think every startup can always learn more from, just understanding that most of the time, these engineers, designers, and PMs you spent so long hiring and empowering and setting up will always see the opportunity where your company can improve, where you can get better at producing better software faster, and you just need to make sure that you’re relentless about listening to them and learning from them. I think every company can benefit from that.

The race we’re in

Des: For us, a core driver for this was a sense of speed. I think both myself and you, Paul, at the very least, and I’d argue all 300 folks in R&D would all agree, speed is a huge ingredient of a successful startup. It’s a huge reason why people like working at Intercom. It’s important beyond the product team – the speed of R&D is, at the very least, affected by the speed of our surrounding functions, whether that’s finance for giving us headcount or marketing for bringing us to market. Speed is a first-class citizen at Intercom, but it should be in every single company. You need to understand that most of the time, the ability to move and improve, to iterate and innovate is a core asset of a company. And if you can outperform your competitors, it becomes a core competitive asset, something you can actually win on. How do you think it affects us? Or how do you think it affects just SaaS companies in general?

Paul: Yeah. I often say internally that we are in a race. And I mean that very literally. We are literally in a race, and I think almost every single person listening to this who’s in a product or engineering team or any kind of technology company is almost certainly in a race, too. And what I mean by that is technology evolves and changes and moves and we see speed of execution as a critical, indirect competitive advantage, but it is a very clear competitive advantage.

“If you have any kind of good product-market fit, you will get copied, and once you get copied, there’s no reason to pick you over other companies”

Unless you have some kind of big data moat, or maybe a breadth of a product that it’s going to take literally years to copy, your current differentiation, why you’re different and better, why customers should choose you over some other computing tool or product, is only as durable and sustainable as your ability to improve it faster than others can copy it. If you have any kind of good product-market fit, you will get copied, and once you get copied, there’s no reason to pick you over other companies. You’re in this race of who’s going to be able to move the fastest. Hence the speed of execution we think is a competitive advantage or, if we get it wrong, a disadvantage.

Des: Let’s say me and you start a new startup and let’s say we do employee performance management software or something. I’m just picking some random SaaS tool we might use. And let’s say we have a beautiful UI. We have some sort of fancy command K style action menu switcher, we have a mobile app, we integrate beautifully with Slack, blah, blah, blah. You’re saying that, and I agree with you, I’m just reframing it so that it can be understood by all the listeners, I guess. No matter how cool this is, you can still basically right-click view source and work out what we’re doing. It’s basically data going into a database and coming back out in a different form with some different transposition happening to it. If somebody really likes it, they can do it. And if, right after launch, our ability to move and improve is slower than our competitor, whatever our advantage is, let’s say we’re 10X better than the next HR performance conversation tool, it doesn’t really matter the road because they’re going to outpace us. Even if they’re 10 miles behind us, if they’re moving twice as fast, they’ll overtake us at some point.

The only sort of reasonable counterargument is, “Well, what if we’re always the people with better ideas?” I think that argument kind of turns into what I would call the Oreo argument, “Well, we had the better idea. Sure, we were number two forever, and it ultimately didn’t work out, but we had the better idea.” I think you become one of those taste setters, but you can never actually commercially capitalize on anything you’ve actually contributed, which is the dangerous thing.

“When you have momentum, you can feel it. It’s visceral”

I’m going to name two companies, and I’ll just say, as a side note, I know both of these companies obsess about speed, even though I’m about to say they don’t have to as much. Say, for example, it’s hard to right-click and copy Stripe because they have agreements with banks and all sorts of behind-the-scenes people. You can’t just sit down with a Rails install and a bit of fancy UI and start charging credit cards. You have to put on a suit and go talk to some banks. Something you can do entirely with a text editor and a browser is, say, Figma, where yes, everything they do is possible to understand, but there’s so much of it, and it’s done to such a high degree of execution – it’s a very complicated, massive piece of fantastic software – that even if you decided to copy it, you could be a long time working on that before you actually catch up with them.

And then, as I said separately, in both cases, I know they both manically improve their product at pace anyway. Even the folks who you might argue don’t need to worry about it too much seem to worry about it, too. No matter what the industry is, speed is the thing. There are a couple of cases, as you said, if you have some insane data moat, or if you have a massive community that’s going to go to your place like, say, Reddit or something like that, where everyone’s there because everyone’s there, you don’t need to worry about the next Reddit, it won’t be based around better technology, in a sense. But I think for the rest of us, building B2B or B2C SaaS tools, speed actually matters a whole bunch. It’s a huge competitive advantage.

Slowness is viral

Des: You’ve worked, I’m not going to name names for once, even though I’ve definitely criticized your former employers previously, but you worked in a breadth of organizations, but more importantly, you’ve worked in lots of different teams and areas within. You’ve worked in the fast parts of Facebook or Google, and you’ve probably worked in parts that weren’t so fast, as well. What does it feel like when speed isn’t there?

“When you have it, it’s easier to maintain it. It’s like a car going up to a set of traffic lights. It’s green lights all the way, and you keep going – green, green, green”

Paul: What I go back to is this idea that momentum builds momentum. Just to dig into that for a second, momentum is velocity times mass. Velocity is how fast a company can execute their product roadmap and then in a specific direction i.e. their strategy. Momentum is velocity, how fast we execute the actual strategy in a certain direction. It’s not randomly shipping loads of random stuff. Some of my former employers tended to do a little bit of that. And mass is how big the team is. This really applies to small teams as much as it does to big teams. Whether you’re a five-person team or a 50 person team or a 500 person team, it’s the same stuff.

When you have momentum, you can feel it. It’s visceral. Decisions get made fast and progress gets made, and you can literally feel it, in my experience. When you have it, it’s easier to maintain it. It’s like a car going up to a set of traffic lights. It’s green lights all the way, and you keep going – green, green, green. And if the light goes amber, it turns red, you slow down. Well shit, now it’s harder to actually get going again.

That’s why we obsess about it, too, because we know that if the momentum slows down, it’s harder to speed up again. And then, the other orgs in the company feel it too. Our sales team’s momentum, to some degree, is dependent on our R&D momentum. In other words, if we keep shipping product updates and things that customers value and want and need, the sales team can increase their momentum off the back of that, too. You get these nice feedback loops with the rest of the company that reinforce the feeling that you’re making progress fast.

And then, obviously, the opposite can happen. To make this maybe a bit more practical for people, one of the things we’ve said to people internally is to do things like asking momentum-building questions. This is one way you can test whether or not you have speed: Why are we waiting for this person to come back from holidays before we make this decision? We could make it now and fill them in when they get back. Why are we blocked? What are we going to do to unblock ourselves? Why are we waiting? Who’s going to make this decision? When are they going to make it? What’s the minimum we should do to learn to unblock progress, et cetera? When people ask these questions in meetings and working sessions and one-to-ones, you just feel it.

“You don’t accelerate for a red light – what’s the point of getting there quickly? You’re just going to end up waiting anyway”

Des: And I think part of that is making it culturally okay to ask those questions. You’ve picked pretty easy questions there but there are other momentum-building questions that can come across a bit thornier, like, “Why isn’t this live yet?”, “Why didn’t we look at this?”, “Why is that taking so long?” The extreme end of that will start to sound pretty manic or harsh, but when everyone in the group understands what the desired outcome is, then people know that when you’re asking a question, you’re not trying to point fingers or play blame games – you’re trying to preserve or build momentum. And I think it’s important that people understand that in the culture. It’s like, “Hey, something we care about a lot here is our ability to move fast, and any of these questions are just designed to try and protect or amplify that.”

You’re correct in saying the absence of momentum builds the absence of momentum. Slowness is viral, too. For the same reason, you don’t accelerate for a red light – what’s the point of getting there quickly? You’re just going to end up waiting anyway. When people detect a bottleneck in the system, they slow down as they approach it. And when they slow down, the car behind them slows down too, which means everyone starts to slow down once they realize that the operational cadence of the company is stepping back a bit. There’s no point in being the one moving fast. There’s literally no point. In fact, if anything, you’re more likely to create problems by being the only fast cog in the system.

“By the end of the year, the vast majority of your company will be new, your R&D org will be new, and they’ll bring with them the cadence of the last place”

The easiest way that goes wrong, in my opinion, is if you take, say, the last year with the near trillion dollars of funding that’s gone into startups and start blowing up headcounts. They’re going to hire 20, 30, 40 more people into a 20, 30, 40 person startup, or put it another way, I’m seeing a lot of headcount plans that assume 100 or 200% headcount expansion. This means that, by the end of the year, the vast majority of your company will be new, your R&D org will be new, and they’ll bring with them the cadence of the last place. This means that if you go to some larger, established company and you get all of their senior talents for all of the right reasons, they’ll be working on a slower cadence. It’s just a fact that if you’re coming from a very large, monopoly serving primarily governments, speed isn’t the same thing there.

Now, relative to your peers, you might still be really fast, but relative to an early-stage startup, you might be quite, quite slow. And if you come in and there’s no discussion of speed and prioritization of speed, you’ll bring in the best of your expertise, and say like, “Hey, we should slow down a bit here and we should be really rigorous in our documentation and we should be making sure we do full requirements gathering before we kick off a project,” and before you know it, you’ll see things starting to slow down, which would be a fine strategy in a different company, but not for an early-stage startup still kind of trying to enter a market or grow a market.

Warning signs

Des: Aside from the feeling, the culture, the lack of accelerating questions in meetings, are there figures you look to? Do you have a dashboard on the far side of all this that says, “Here’s how I know if we’re slowing down again?”

Paul: I don’t have a dashboard, but Darragh and I will look at key things, for sure. And by the way, all of these are proxies, there’s no one perfect measurement. But there are two that come to mind straight away. One is product changes. We have a webpage, intercom.com/changes, and that is literally the product changes that are going out to our customers. And that’s one. It’s like, “Hey, are we shipping good products?” And obviously quality matters here. You could ramp up output to a very poor standard, but that’s not going to help either. The product changes are one because that kind of tells us at the end of the day, all that matters is that our customers are getting a better product. And if there’s any gap in the changes, if a few weeks go by and we haven’t pushed a change live, we might start to ask, “Hey, just checking in. Is there something awry here?”

“If that goes quiet for a while, you’re like, ‘Oh, why is Show and Tell quiet? Why are we not seeing much stuff?’”

Des: Or is there something big coming or whatever. There are reasons, but we just need to know.

Paul: A good example, actually, and here’s a little shameless plug while we’re at it, we have an event in Q1, in a month or two or so.

Des: March 23, you said, is it?

Paul: That’s what I said, exactly. We’re going to launch multiple new products. And like I said, 150 changes last year, and yet we want to go more, faster, better. We’ve got multiple new products coming, but that might mean that those teams have been working on them for a few months, so they won’t be pushing things to the changes page. And that’s totally fine, of course. Again, these things are a proxy, none of them are perfect.

Another one is that every Friday here in the company, at the end of the day, we do a thing called Show and Tell where teams get up and demo their latest work. It’s really informal and they just go, “Hey, here’s the latest for project X. We’ve built it this week.” We’ve done this since the very, very early days, as you know, and it’s an awesome tradition. And if that goes quiet for a while, you’re like, “Oh, why is Show and Tell quiet? Why are we not seeing much stuff?”

Des: Yeah, if nothing’s gone publicly out and nothing’s gone privately out, we’re bottlenecked on something.

“There’s a reasonable set of proxy metrics that any one of them is excusable, but collectively, if they all start to go red, chances are something’s gone wrong”

Paul: Yeah. And so, we tend to do those things. Now, on the engineering side, we obviously measure the output of the engineering team. But you have to take a lot of those things with a grain of salt. They’re not necessarily the right measurements. More lines of code aren’t necessarily better than fewer lines of code.

Des: Yeah. And lastly, we’ve what we call high-performing teams, on a cycle basis, evaluate their own ability. They ask questions like, “Are we clear on mission?”, “Are we clear on strategy?”, “Are we staffed properly?”, “Do we have all the right people?” And I think you’re right in saying there’s a reasonable set of proxy metrics that any one of them is excusable, but collectively, if they all start to go red, chances are something’s gone wrong. And honestly, in my experience over this decade at Intercom, it’s very rarely because the team has just decided to slow down. Something happened to slow them down. And that something could be that they’re working on too many different priorities, they’re not staffed adequately, they have a really unclear vision, or we’ve given them a really vague direction.

In our experience, most people want to move fast. It’s liberating. It’s freeing. You feel, as a designer, as a PM, as an engineer, that you’re actually having an impact and that your work matters. No one really wants to go and read Google Docs all day. They want to do the work and see their stuff go live and they want to see customers use it and be delighted by it. That’s the buzz. That’s why people want to work in software companies, and specifically in startups because the actual time between idea and customer delight is a lot shorter than it might be if you’re working on the next version of Microsoft Word or something. When you start with that assumption, what that means is you turn the inquisition internal almost immediately: what have we not done to set this team up for success? Because we do believe they want success.

On the right side of the internet speed

Des: We’ve bounced around quite a bit, but if we were to try and conclude, I think a parting idea for listeners in R&D, which is how the financiers refer to the org that builds the software (you can tell we’ve grown up as a company), or product orgs, let’s just say, product design engineering orgs, if you’re in one of those orgs, something that’s worth doing is asking everyone, “What is the biggest obstacle to speed in the company?” And if you’ll be humble enough to accept that they’re probably right and it’s probably your fault, especially if you’re a leader of the org, I think, inevitably, you’ll see changes that make sense.

“The hallmark of all the great startups that I’m aware of is their ability to move fast. And it’s what we aspire to be”

These might be changes to your process, such as the removal of steps. These might be changes in terms of culture, like “Hey, it should be okay to ask the following or to push for the following,” or, “Hey, if your leader’s not giving you enough clarity, it should be okay to request it.” But there’ll be cultural changes, process changes. Sometimes there might be staffing changes in the sense of, “Hey, we always bottleneck on design, and until you get us more designers, we can’t get things through.” Or it could be, “We’re stuck on tech debt,” or “we’re still paying off the work we did last year, and as a result, we can’t build new stuff. We’re still maintaining the old stuff.” You might have changes there as well.

And I think the higher-level message is that the hallmark of all the great startups that I’m aware of is their ability to move fast. And it’s what we aspire to be. I’m not at all saying that we’re there. But when we look at who we want to be when we grow up, the answer generally tends to be the startups that have moved the fastest and have made the most amount of changes to the ecosystem of tech. Talking about speed as a first-class citizen in the company is a huge part of making that clear to everyone and actually making it happen. What would you add, Paul?

Paul: I think that’s all good stuff. A couple of things come to mind. One thing we didn’t touch on earlier or didn’t specifically mention is that, in the company and in the product and engineering teams, we sometimes talk about internet speed. The internet itself, as this revolutionary technology and one of the most transformational technologies and inventions ever created, moves at speed. It evolves and develops and changes. If you look back at how young it is, relatively speaking, it’s evolved and changed so much. And if you’re not operating at internet speed, in other words, the companies around you in your space are innovating and developing stuff and improving stuff faster than you are, you’re losing the race. I think the idea that we’re all in a race together is very, very important to internalize and to talk to your team about and have them internalize and embrace. As you said, it’s way more fun and engaging if you’re shipping stuff in the race.

“You’re either ahead of or at the curve, always showing up on time with new stuff that people expect, demand, love, or you’re one of the companies that are just behind the pack”

Des: And I think to some degree, internet speed is, yes, you’re genuinely racing against your direct competitors because customers are going to make a choice about not just who’s got the better product today but who generally tends to have more stuff that makes their product better over time. Separate from that, though, the standards of the internet change pretty quickly, as well. 10 years ago, you wouldn’t expect every single B2B SaaS app to have features like liking, commenting, emoji, et cetera. And now you can’t imagine shipping stuff without it. That’s just an example of how the default feature set is expanding. If you’re trying to build an email product today, and I’m just picking email because it’s something everyone will get, I can tell you what your first year and a half worth of roadmap is – it’s going to be the Android app, the iOS app, the iPad app, the Windows app, the Mac OSX app. Then it’s going to be all the basics of email. And then, after all that, you get to decide where you want to differentiate.

I think we are seeing this relentless growth of the standard expectations of customers. And that is a part of internet speed too. Let’s say you’re in the project management space. You’re looking at height and linear and all of those, and you see that they all have dark modes and command K switchers, and they have all that fancy shit. And you’re thinking, “Okay, we can’t get that done,” or, “By the time we get that done, it’ll be 2024”, and you’ll just find yourself relegated to being yesterday’s technology tomorrow. And basically, you’re coming in behind the internet. Stuff happens to the net, it becomes standard, becomes best practice, and then, a year later, you roll it out with it. And whether you like it or not, that becomes a part of your brand. You’re the people who show up last with the thing everyone wants. And that’s dangerous too.

That’s the other side of internet speed – you’re either ahead of or at the curve, always showing up on time with new stuff that people expect, demand, love, or you’re one of the companies that are just behind the pack. And generally speaking, you’ll notice that in the product first, you’ll notice it in marketing second, you’ll notice in sales third, and before you know it, it’ll show up in stock price or valuation or whatever the thing that represents the existential success of the company is. They will all lag your ability to be relevant in software, which is the scarier side of internet speed if it starts working against you.

“Assuming you are at your minimum standard of quality, are you moving as fast as you can and making the right decisions?”

And on that happy note, please do talk about speed and feel free to make it an easy conversation that everyone can contribute to because it really, really matters, in our opinion. And be very open to pushback on this, as well. I know the obvious pushback to speed will be something about quality. Quality and speed are not either/or, for starters. People often will question whether or not you can have speed and quality. The only thing I’ll say is that if you ship shit, actual relentless amount of buggy stuff, it will slow you down very quickly because your roadmap will be faced with a choice of fixing the stuff to keep the customers or losing all of your customers and keep output cadence high. Once you’re faced with that choice, you generally tend to sacrifice one for the other. Quality has to be a core assumption that you’re not going to sacrifice. But assuming you are at your minimum standard of quality, are you moving as fast as you can and making the right decisions?

Paul: I think the art of the questions you ask is really important. We’ve touched on this a lot in this podcast, but the cultural component’s really important, especially from the leadership team. People should feel that you’re open enough for them to feel comfortable giving you the truth. But the questions you ask and the framing of them matters. For example, I think a bad question to ask is something like, “We need to move faster. How are we going to do that?” That’s a “Whoa, hang on a minute, I’m already working 10 hours a day.” On the other hand, if you ask, “Hey, what are the things that most slow us down? Let’s figure that out. What are they? What’s getting in the way?”, that’s a way more open-ended conversation. And it’s like, “Okay, we’ve asked a whole bunch of people and it’s clear that this thing here is slowing us all down, and no one wants the thing. Let’s get rid of it. Let’s figure out a different thing.”

Des: Yep, absolutely. By getting those questions right, we can zone in on the areas where we’re doing undifferentiated work, and learn how to maximize the amount of time we can spend doing the work we all signed up for.

Okay, we can keep going around in circles, and I suspect we’ll probably end revisiting it over the year, but for now, for 2022, we hope you have had great road mapping sessions, have great features specced up, and we will see you all again in four to six weeks. Thank you very much, Paul, and we’ll see you all soon.