Buy or build? Focus on the core product or innovate? Zendesk CTO Adrian McDermott's advice for scaling

Brett Berson: Well, thanks so much for joining us. I'm super excited for our conversation.

Adrian McDermott: Hi, thanks for having me excited to be here. 

Brett Berson: Um, one of the areas that I thought that might be interesting to start the conversation is sort of on the topic of when to change something when you're operating a business and sort of when to, to leave it alone. And, and I'm particularly interested in exploring the, the idea because you joined Zen desk when it was something like 50 employees over a decade ago.

And now the company is something like 5,000 plus employees. And so I assume there's always this, uh, strain between. keeping things the same or doing the thing that you think made you successful in kind of reassessing priors and sort of changing your mind or changing something in the business.

And so curious to hear what you've learned about that.

Adrian McDermott: Yeah. Yeah. I think the, you know, the truism you always hear is what got you to 10 million, what get you to a hundred million? What got you to a hundred million, won't get you to a billion and you're like, oh yeah, heard that before. Um, but as you look in the rear view mirror, I it's rare that you don't think about decisions and, and safety yourself.

Oh, I should have done that earlier. We should have done that earlier. Um, why did I let that go on for so long? Um, and some of that learning it's about, uh, too much stem, you know, sentimentality too much. Desire for stability in the organization, you know, in rapidly growing startups, everything has changed.

Like it's constantly changed in terms of the scale of the application, the scale of new customers, the complexity of new customers. And I think it's easy to want to, it's also, you know, somewhat healthy to want to stabilize the team. But, you know, as an example, those moments when you go from, you know, bespoke curation of customers or bespoke curation of your organization into a more farming of those efforts, right.

More industrial scale. Right. You know, I've heard people talk about it, how you, as a leader, you have to move from being an individual psychiatrists to associated. Like we used to hand deliver cakes to customers when they hit a million tickets in the Zendesk platform, And you know, as we've shifted, now, we have customers doing a million tickets a day and all those things that is not practical anymore. And you have to let these things go. You have to move from people to process. And I think in the, in your own organization, um, that becomes very clear. there is a step function moments where, you know, you're going to add another a hundred people and it's important to add the kind of leaders who can bring those people on and motivate them and drive them and, ready for the next scale of the organization.

You try and grow people to do that. But if you're growing too fast, that's a really hard thing to do. And you have to bring people in from outside. Another example would be something that was like really tough for us to do is, and that's cause we were thinking about our IPO, which was take the mascot that we'd had as a company and the branding, right?

Zendesk was the highly green website company with a laughing monk image and the sort of playful whimsical love your help desk branding. And it, you know, it really worked for our early startup customers. The head of customer support for Twitter. I actually met her during my interview process was in desk.

And she was like, yeah, the thing that really attracted me was sort of the green color on the website. And you guys look like fun. Um, when you're sort of, you know, pitching an enterprise story and going for an IPO, you have to, you have to, um, think about is that where we're going to be for the next five for the next 10 years.

And I think, you know, your branding is super important and ours was restrictive. So we killed off that character and we made a change and we built a new brand platform. And that was, that.

was sort of hard to do because it was so familiar and dear to the employees, you know, I had a wardrobe full of Patagonia fleece that represented that and t-shirts, but for the long-term, it was the right thing to do. 

Brett Berson: From a system level. How do you identify when to change something particularly? I think it's difficult when it's served a purpose and maybe was a tool that helped you get to 10 million or helped you hire great people or what have you, do you think about it at the system level or have a set of frameworks such that you're not constantly sort of wrestling with these things and then looking back and saying, wow, I wish we did that earlier.

Adrian McDermott: what one of the disciplines, I think that's helped. I wasn't a discipline we had early on, but something that's really helped me is thinking about sort of being a little more formal and deliberate as we think about return on investment. I think when you, when a company gets to a certain size, you get to be very familiar with this because you know, you go through.

Headcount rituals and headcount allocation is, and budget allocation is sort of this annual ritual that actually reminds me of sort of a truism about British soccer. Right. You know, football is a game played by 22 players who run around and, you know, tactically adept formations against each other for 90 minutes.

And then at the end of 90 minutes, you should out and penalties in the Germany. Right. That's football. I think head count allocation and using ROI, justification is the same way. You know, you go through this theater of spreadsheet, comparisons and, you know, slide deck competitions or whatever, which is basically what they are.

And at the end of it, you know, the CFO gives all the money to sales because they proved that if you add five more feet on the street, you'll get X more revenue. And that's the thing that we should. I think that's because when we lose in that battle, in some ways we're failing, because we're not thinking about benchmarks against other companies, you know, having the CFO look at where, where other people are spending and thinking about what kind of company we want to be.

And then also thinking about in your own organization, you know, in the product organization, right. What it is that is driving value. And as you, as you understand more and be more deliberate about the investments, you're making the ongoing, you know, the sort of zero-based budgeting, thinking about those investments and the new investments as you deliberate, you can, you can make clear choices and it's a little easier to then say, well, something has to change.

We have to go make an acquisition. We have to invest heavily in this area. Or, you know, this product is failing and we the need to do something about it or wind it down. 

Brett Berson: So, what does the process look like for you all now in terms of looking at investments, getting better at seeing what's working and what's not, and making new bats then, and maybe kind of, what do you do to avoid the, the problem where the, the thing, oftentimes with the clearest and or shortest term ROI?

Generally gets capital allocated to it versus things that are more speculative speculative, but that if they do work, they have the chance of, of providing some sort of outsized outcome.

Adrian McDermott: Yeah, there are tools out there to help you. Right. And we S we definitely started thinking about our investments and strategy in terms of, horizons, you know, one horizon, one horizon, two horizon, three investments, right. Things that are making you money today, horizon one things that will make you money next year, horizon two, and, you know, longish term bets, horizon three, and then you allocate, you know, 80 15, 5.

Percent of your revenue to each of the horizons. I think about it in different ways, depending on the stage of your company that was useful for us. But I think it's also as a framework, it doesn't help you with some of the details. And so lately, um, we've been using the Jeffrey Moses zone to win framework, right?

Where you think about, you know, there is the performance zone, whether the things that are making you money today, and you're going to put all of your effort in the transformation zone, which are ready to go into the performance, zone and build for you, uh, the incubation zone where you're trying things out and the optimizations on what you bet you'll be trying to make, the way that you run your business better.

What I like about that framework is it forces you to think about the metrics in each of those. Uh, and the objectives of the initiatives in those zones differently, it recommends that you put very few things in the transformation zone. So you're not just throwing a bunch of spaghetti at the wall. You know, when that, when you go from one product to multi-product, right, you have this, this transition, which is really interesting.

And you have to learn to do more than one thing at once. And I think if you judge your second product by the, by the metrics and outcomes of the first one, it'll never get any love. It'll never get any coverage, right. You'll never be able to build it. If you try and do too many things at once and transform the company in too many ways at once, you're just going to be peanut buttering.

You know, peanut buttering is the enemy of growth, right? It's, it's just a way that you never get good at anything. And so as a one product company, it's really important then to figure out what are the initiatives we have that aren't our main thing and how are we going to measure them? And what does success look like and how are we going to treat them differently?

And I think you need to have one thing, which is your transformation thing, which is like, everyone's going to care about that this year, we're going to really work hard on it. And we're going to make it a main motion. Like last year for us, that was messaging. We, we felt like the transition to messaging channels in customer service and in people's lives in general was real and what's significant.

And so we went out and we acquired a Canadian company smooch, which was a SeaPass platform because we needed to inject. Um, DNA and that thinking into the company, we also got amazing technology, but it was, it was so much more than that. And that's sort of, you know, a successful transformation, an unsuccessful transformation is really where you launch a product and you know, you're like, oh, well, isn't. Our main product, you know, the support product in our case is generating X amount and growing X fast, right?

This thing is a distraction and a pain, you know, and these people want what marketing help and they want, you know, finance help to model everything and blah, blah, blah. Like, why are we doing this? And I think if, you know, making it a big thing, because it isn't generating the same revenue or using these unrealistic metrics and goals to measure it, you're going to fail.

So right now, and our stage, I like zone two, one, I think horizon 1, 2, 3 is a good way to think about strategy. And then, you know, um, if not either of those things, just writing it down and saying it out loud to each other and making sure you all agree, which is maybe what Zandesk earliest stage of it was, is incredibly important.

Brett Berson: You gave one example, um, of, of these different parts of zone to win. Can you share a little bit more about some of the past examples that fell into each one of those buckets that.

Adrian McDermott: Sure. Yeah.

I think, you know, we talked about the transformation zone, I think incubation, um, you know, we, we launched a product a long time ago, um, called, uh, talk, which is a, you know, voice-based context sensor. And that product came very much from the incubation zone. we took the Twilio API APIs.

We figured out what the core things we wanted to do, and we built those things. And over the years we've built a team around that product. You know, that team is now best in Dublin. We've built sort of, uh, up a content farm on the website. We've built up expertise in the area. We've rolled our international numbers.

And we've slowly, you know, marched from basically an incubated effort that was also sold on the website and wrote along into something which is part of the cause and a suite, you know, through transformation. And now I would consider to be part of our performance zone and sold in that way. We put a decade into it and it's, you know, it's made money all along.

It's great. But, and have that, uh, have people who care about it and run it. I think you can be successful in that way, incubating a product, other things we've acquired. And that's what different things from a, from a performance point of view, if I were to go back in time and have a word with myself a few years ago, um, it would be about investments in the performance zone where, you know, a lot of the attention from the board, a lot of the attention in your marketing, a lot of the intention, you know, and, and glory is on the new and interesting.

And, uh, that pulls attention away from your core product. And it's your core product that, you know, in a SAS business, your customers are paying you to operate every day in our case Zehnder support. And, you know, there were, there were, I don't want to say LOLs and investment, but there were times when the, you know, the noisy neighbors at the edge, uh, of the suite were getting more love and more attention, certainly more of my attention than the core.

And I think for me, that's one of my mistakes and refocusing on the core and reinvesting in that I think has really helped the business. And it also, um, thinking about it in terms of being in the performance zone has been incredibly important. And then, um, You know, the, the efficiencies zone. Um, not a plus.

I live very comfortably to be honest with you. Um, but I think again, as you grow and you look at, you look at your CAC which is a great way to think about the efficiencies zone. You know, I'm not getting too involved in accounts payable and how many people we have doing that.

But, uh, if we look at the cost of acquisition, one of the things we learned in the efficiencies. Was, um, that we spend too much time adding the next agent for one of our existing customers, right? There was a, there was a theory that an early revenue officer had that it was whenever a customer wants, you know, to add one seat, even if for a thousand seat customer, right.

A relatively skilled customer. And they want to add one seat, but we should have a conversation with them. And it's a good opportunity to engage. And that's how we keep the motion of sales going. Actually, you know, for most of those things, they just want to hit a button and get that seat. When they want to have a conversation, they want to have a conversation.

Mostly, you know, that's about operational efficiency, you know, And we had this project actually to take, you know, um, the price for next agent, with all of the discounts that have been applied and everything else out of, um, our Salesforce automation system. And, you know, out of the way it was obscured in that process and out of compensations into, well, the client just presses a button.

And if we, even, if we have to figure it out manually, we'll figure it out on the backside. You know, we have a revenue team, whatever, whatever, and it will work, but we'll, we can drive a ton of efficiency into that. Time back to our salespeople to go talk to new customers and, you know, sell new deals. Yes.

You still need to do success with your existing accounts. You still need to engage with them. But I think that was a, that was a great learning. And, um, you know, from a revenue point of view, like if you look at the revenue attributed to just being able to hit the button and upgrade, hit the button and add agents, you know, it's huge.

It's like, you know, probably one of the most successful, you know, individual development projects we undertook in the last year. And so when you, when you think about efficiency in that way, it's just, it's just really important and it can be, it can be transformative for your revenue. 

Brett Berson: Given, we're talking a little bit about, um, product strategy. I'm interested in, how do you think about the role of competition? You know, when everyone says, oh, you know, just focus on your customer, build what they need, or I'd say more Silicon valley sort of YC and. Um, and at the T at the same time, you operate in an intensely competitive category, both upmarket and downmarket.

Um, there's a zillion other things that people can use. And so when you think about what to build or how to build it, how do you think about, uh, competition as, uh, as kind of a stakeholder or, or, um, constituent.

Adrian McDermott: I, I mean, focus on what you're doing is really great advice. It's the same as my focus on the core focus on the core focus on the core, right? Because that's, what's paying the bills, but at the same time, looking at the competition is actually another way of looking at your customers, right? You, you, you know, in our market, we have bigger competition who are really having the conversations in some cases that we want to have, and they're having more of them all the time.

And we have smaller competitors that are more agile and more aggressive and, you know, potentially moving faster. And I think I look at them as. Incredibly important research organizations, right weather, you know, distilling all of the input they get.

And you can see the hypothesis that they've built around that in the features they're releasing and then the products they release. And then you will hear from your own customers and, you know, your own prospects, what is getting traction with them in terms of the messaging or the capabilities or things that are important.

Um, and so. Uh, I think competition is extremely important because you were generally in, in our business putting choice in front of customers that comes from, you know, uh, Zendesk or one of the others. And, um, each one of those, in the longterm is an existential conversation presenter.

So we have to understand those dynamics. I think, overly, focusing on your competitors, tactics, or their position or the market or other things like that can be destructive to the organization, right. That's not, that's not using that information to create. it's a distraction.

And I think, you know, understanding what is a distraction as you look at them, which is, you know, how are they speaking about themselves? You know, what is, what is that take down competitive page in SEO for you? It's like, yeah, blah, blah, blah. Um, those things aren't helping, right. But if they are launching new capabilities or shifting direction in the market, I think you have to sort of think about what your response is going to be.

Do we want to follow, do we think it's important or is that unique to them and the way that they think about the market and the business. 

Brett Berson: One of the things we touched on, um, a little bit ago is, is this really interesting topic of mano versus multiproduct and when a company shifts from one to another and when to do it and how to do it. And so I'm interested both kind of how you approach this over the last decade at Zen desk, and maybe what you think you got right or wrong when it comes down to the idea of executing on a multiproduct stress.

Adrian McDermott: yeah. I, you know, transitioning from single to multi or just adding another one, those are difficult decisions and it's, it's really difficult if you have one scaled product to get the others moving and get them evolved. Um, you know, all software innovation is ultimately the joke is bundling and unbundling your packages.

And I think bundling second products into what you're doing is a great way to increase, you know, your share of wallet, uh, and get that product moving and get it into. I think there are build partner buy discussions that you have to have, and you have to understand long-term what the, what the strategy is going to be.

Um, and then there are organizational questions, um, for us, we had three or four products and actually what had happened was we'd set a goal of getting to a billion in revenue in, uh, three or four years. And we did an analysis of our market and we said, okay, you know, if we run a thousand Monte Carlo simulations of, of trajectories of each of the products that we have, um, we need a couple of them to get to a hundred million to get to a billion.

And So, we invested heavily in independent motions for those products as a result. And, um, each one got a GM, a general manager to run it who had some control over the go to market and the business, et cetera. Um, although we had kind of a monolithic Salesforce and play to get some overlays and we tried to run the business in that way, but step back now with the benefit of hindsight and look at that effort, I think where you have a different channel or a different economic buyer for a product that actually makes a ton of sense because you have to invent and stimulate a new motion for go-to market.

And. Um, you may have product market fit, but you have to really think about the, how is this go to market different? How do we navigate in New York versus if you have a single economic buyer and the second products are helping with new use cases, new instances, or, um, just increasing the share and taking it from, you know, another partner that they were using for that solution.

I think in that case, uh, GM is possibly a destructive way to run the business and we collapsed our GM's, where they were kind of running, um, independent units that just became noise in the organization more than it. Um, because, you know, persona wise, who is the buyer, you know, what are they paying you for?

 we have to understand that we have a core asset that is the money printing machine. Ad-ons that go with it and think about, multi-product strategy in that way and where it's not like that, where we have a different entry point into an organization. Uh, and we're trying to build up our reputation, the entry point.

Adrian McDermott: We have to think about what are the cross sell motions? What are the ways that we can find those use cases in customers, and then adapt the York to be able to build for that?

Brett Berson: So, can you talk a little bit about the story behind the different products that you've launched over the last decade? Um, and maybe kind of how you thought about sort of that idea of attaching other products that do different jobs to be done for the same buyer versus the decisions around additional products that maybe had a different buyer or user inside the organization.

Adrian McDermott: Yeah, I, so the first one I already mentioned was talk, we built on top of, uh, other API APIs created the contact center. And if you think about it, right? certainly at the time, most of our customers were small medium-sized businesses, maybe lower mid market. Um, we were their sole customer service or internal help desk, and it was natural for them to want to put a voice extension on that product.

And I think so there it's like, SaneBox. Um, something which has probably already attached to Zen Desco, which they would like to have. And so our philosophy was, well, we need to make it super simple to just go into the product and click a button, choose the phone number and you're up and running with a contact center.

And it, you know, you don't have to put in, um, desk phones or anything else you couldn't, you know, Bish basically have it ring your cell phone and do all these other things. I think when we, when we hit that sweet spot, it just basically worked right. The idea of I can turn on a cloud contact center, um, in 30 seconds.

And I think I actually went to the first Twilio signal conference, which was not the high production value it is now. And I created a context center in front of the audience in 60 seconds and had them all call it. And the first call, I answered it through them as an index t-shirt um, And, you know, that, that, that actually was a great way to go as it's scaled out.

It turns out that, you know, you can't, um, support a hundred agents on a DSL line, um, in Argentina, uh, you actually have to get into the basics of your network and all these other things in the selling process becomes more difficult. Um, but that was a great way to start that business.

And we've grown it since and developed expertise chat we actually built. Um, so, you know, session-based chat that goes on the website with a widget. We had a widget for help already on the website. It was a natural extension, same buyer. Um, and so we built. A, uh, nascent chat product in 2011, um, uh, basically looked at what other people were building the chat products with, had an engineer or to kind of come up with something and built it.

And we then, as we unpacked it, we just realized just how big and complicated it was, uh, as a process and that we were behind. Um, and we had three or four partners doing great business in the Zendesk ecosystem, selling to our customers through our app store. And, um, we looked at them and evaluated them and we bought a company called Zeppelin that was based in Singapore, uh, just before IPO came with a bunch of expertise, a lot of new customers because they had their own motion, their own self-serve business.

They also did chat for sales on the website, not just chat for support, which was important to us at the time we thought that would be, uh, a really good asset to have in a business to grow. And we, uh, Wanting to diversify where we were hiring developers and not develop a centers and establish a presence in Asia.

So it, ticked a bunch of boxes. Um, and we brought that product in, it was a great product. We've scaled it. You know, I think it, as an acquisition at two years in, it was, we were probably from a book of business, point of view making every year, what we'd paid for the whole. Which is great, you know, that's when acquisitions to work like that, it's tremendous.

And, um, I think with that one killing our internal product and acquiring was the right move. it's always interesting to think about the mistakes, right? I wish we'd integrated the technology stacks earlier. Um, but we were more interested in sort of running the business and not putting any kind of headwinds into the growth of that business, um, that, You know, shifting feature developers from new stuff that customers were asking for our stuff for ever larger and larger customers and use cases that were coming in versus stabilizing and putting on our platform.

Um, hindsight's 20, 20. I wish we'd done that. Um, and then from, uh, those, you know, those are the two cool other products. The other product that we have guide, which is our self service knowledge base, FAQ, and community, that product was completely homegrown and has continued to be homegrown. It's developed in Copenhagen by a great and incredibly tenured to.

Um, and we've just built on that. those, I think are the core extension products. And what we've changed though really is the, the way that we think about pricing. And I mentioned you know, are they independent things that we sell that are independent motions?

Or are they, part of a suite? Cause our customers that's that economic buyer we talked about is, uh, trying to buy a single contact center that salts has, you know, his or her chat cell service, uh, and voice needs as well as being a ticketing engine in the CRM. And, um, as we've gone from, you know, sweet emphasis to individual emphasis, each of which have their, their advantages, we've seen those products kind of grow and shrink.

Brett Berson: You know, you mentioned a couple, a couple of the examples of the new products, uh, or business lines that have worked really well. You've chosen to acquire integrate, and then scale is ease there. Anything that you, um, you deter or have become opinionated about to make those acquisitions exceptionally successful?

Because I think in general attends, it tends to be more likely that a company acquires a new product or adjacency and it doesn't work or it doesn't get to the scale that they had hoped. And so it sounds like in a couple of the instances that it worked just exceptionally well. And so I'm curious what you, what you did or how you approached 

Adrian McDermott: Yeah, I, I conveniently forgot to mention the ones where it.

didn't, um, naturally, uh, yeah, I think, we actually bought, uh, for a bunch of different reasons, uh, uh, a YC graduate company in San Francisco, And one of the mistakes that it was really easy to make in a cooperative process is say, you know, I like, you know, we like this company because we want the tech and the team, and we're gonna integrate it into our offering, whatever it is into chat, support something, some stuff we want to do around messaging, we're going to integrate it.

And then, um, we're going to keep the business going. Right. But, you know, the way that we described that is like, Yeah.

you know, we, we acquired a, um, A BI tool, for example, based in Montpellier in the south of France. And it had a, you know, it was a going concern with an ongoing business, you know, a lot of French customers that are European customers, but basically, you know, for a cloud BI implementation.

And we were going to use it as our, and it is now desk explore, use it as a, uh, implementation for BI. And it was an expensive acquisition for us at the time, but it was really, really important. Right? What is more important than the data about your customers and how you report them on them and how you analyze the operation that you run.

And I think, In that, uh, Corp dev justification deck, um, talks about where we can keep the existing business going, right. It comes with a sales team. We can apply some Zendesk juice to the marketing. It'll be great, It turns out that that wasn't our DNA, right? And, um, that independent product, wasn't what we were going to sell. We were going to sell customer analytics on top of your CX implementation, where, or, you know, the majority of the data initially was first party.

It came from Zendesk, and then you eventually could bring in second party and Marriott through extensions to one of the products or directly importing that data and build, you know, really powerful customer dashboards. Should have focused on that because you got to stick to your knitting, that's our business.

And that's what we wanted to do. We didn't really want to be in the BI business, but it's easy to make that calculation. We made a similar mistake when we acquired, um, Uh, the YC company, the market, our mission company, uh, outbound IO, where we got, uh, basically, uh, CDP stack, you know, customer data platform stack, and the ability to talk to segment and target and trigger customers.

And, you know, I still am a passionate believer in the need for, uh, Proactive views and your customer experience, right. Be able to say, okay, this is Adrian. He owns these products. He recently bought this one. He's probably calling about that. Let's trigger him on that and ask that question and, you know, not have him go through the 70 steps to get to the point where we figure out what it's calling about.

Those kinds of things I think are really important. And there's still a ton of, uh, work to be done in that space to, to build great and simple implementations that are understandable. And I think we're still passionate about working on it, but again, you know, for that acquisition, uh, we, we were running two stacks, one in Amazon, one.

It was too expensive. You know, the transfer costs between the two for all of our data was, was, you know, going to cripple as we, we didn't have all of the expertise we needed. It didn't come with a big enough team to be the kind of asset that we wanted it to be that wouldn't shrivel and die-ins and desk.

And again, it wasn't our expertise or it was too early for it to be our expertise in terms of selling. And from a framework, point of view, as you look back, right, if you're making a second team and you don't really, really want to be in that business, uh, you've got to kill the product.

You know, you've got to, you can't read that. Uh, you have to take it out the back and shoot it in the back of the head and disappoint the customers. We recently acquired cleverly.ai, the best in pro primarily in Lisbon Portugal. Um, and almost all of their customers was end as customers, right?

They, they provide just some fantastic, um, intent identification to ticket classification, calls, tools for customer service, super important in the customer service AI. To be able to take any kind of input, decorate it with, you know, intent extract the core concepts from it. And then they have a taxonomy which basically would take, take a question from a customer down a series of flows, you know, basically using a machine learning model that would be like, okay, this person wants to do a return.

This person is calling about billing. This person is, you know, yada yada yada, and you know, great asset, but they had sold products based on that to eight to 10 customers, we've made it our goal. You know, we, I think which is right based on our learnings to basically discontinue those products, but replace them eventually with Zendesk implementations and the first, you know, we got, we acquired it in the summer and the first reimplementation, that's a Zendesk implementation.

That's our technology. That's not in our app store. Um, has gone live as a beta and the rest will follow. And I think that. That's a good use of learning for us, like, and a good model. Um, we didn't want to be in that separate ML tool business. We wanted to be in the Zendesk business, but we wanted to have it cover those features and that functions.

Brett Berson: On your point about the story, when you acquire the company to help you build the chat part of your product, you know, you mentioned that you had a small team and you started to work on it and it quickly became clear that it was a much more complicated product and, or problem. And I was, I was interested in kind of exploring that a bit because it feels like one of those things that, you know, you're in a meeting and you're like, ah, customers, you know, want to chat with their customers.

And then it would intuitively feel like, oh, we, you know, have a few people go build it for a month or two and we'll be good to go. And it sounds like then you start to poke at some of these problems and you realize the amount of detail and complexity. So I was, I was interested in what, what you sort of found in, in sort of maybe that example or how that informs how you think about how complicated or hard it might be to, build anything across the product suite.

Adrian McDermott: yeah. It's good question. I think the key thing that changed in chat rate was email is asynchronous. Um, voice is synchronous, but, we were using API APIs that manage those channels pretty well, but it also exposed a bunch of, you know, latency in our product that we took a long time and have done a lot of work to fix.

 And then chat is a highly synchronous thing where you're maintaining these connections. It's not like rendering. Uh, uh, a rich app and then, you know, someone asks for something and you go through the refresh cycle. It's like, you have to be online the entire time using web sockets and push information to uses and have typing indicators.

Adrian McDermott: And, how complete your product is, is measured against the giants of the consumer internet and the things that they've put in that products. Right? And That's a high bar for three engineers learning what each episode is. Um, and so we realized pretty, pretty soon that someone who had, you know, put the 10,000 hours in to build this real time system that could scale to, you know, 3000 agents in a ride sharing company online at once in China.

 you're not gonna grow that overnight. Um, and, uh, organizations can only grow so fast. creating a new product. I do think takes time. It takes time to learn, you know, where the bodies have going to be buried and where they are buried, what the con, what the wrinkles are.

Adrian McDermott: And I, and I could see that for a real time chat at scale. Um, there was a lot to that problem and it, we didn't want to experiment on our customers. Right. Cause if you will. A thousand person helped us for someone, And then you go, Hey, we've got a chat product and they turn it on.

And, you know, um, suddenly our servers start melting or there's all these things that we haven't thought about. Right. You know, you're damaging the value of your core asset. You're damaging the value of the Zen desk support licenses that they're paying for. Cause it's reputationally. It really hurts.

And so it was important. to get people who are experts in this field who have built this thing who have scaled this thing and dealt with customers and apply that DNA and that thinking to it, you know, we could have built it. Absolutely. You know, you can, you can hire engineers to do anything.

Right. Um, I was, I asked, I remember having a conversation with a great engineer, um, A guy called Michael Smith about something. And he's like, obviously I could do that. And I could build that, but that might not be the most efficient way. It's like, if you asked me to translate the website into Chinese, I could absolutely learn the Chinese language and translate it, but it could be better that you find someone else to do that who natively speaks Chinese.

Um, and I think about Michael's example sometimes when I'm asking people to do something, which it's not just outside of their comfort zone. And it's like, there are people who do this for a living and they'd be doing it for a living for a long time. You might want to girl, you know, buy or rent some of that expertise. 

Brett Berson: Something that's sort of popped into my head that we haven't really talked about is how you define or think about what it means to build or have a truly great product. And, um, kind of maybe how that definition changes as the company scales. And, you know, I'm constantly thinking about, uh, products that I think a lot of people don't think are great.

Um, but the companies are at extraordinary scale and in a certain definition, I actually do think the products are great. So like classic examples would be people complain about Salesforce. People complain about Atlassian products, um, and on and on and on. Um, but at the same time, I actually think that they, they are actually truly.

In, in a particular definition, LinkedIn, there are many, many examples of these products. so like, how do you think about what a great product is or in what ways does that matter?

Adrian McDermott: Yeah, I cisgender the Zendesk, the product was three years old and they'd just hired 10 engineers to augment the two technical co-founders. And, um, the perspective I didn't have at the time that I've thought a lot about sensors, what made that product successful and what made it great. And, um, I think it is also true in some of your examples of quote unquote bad products, right?

Where Zendesk at the time, you know, when you, you know, basically hit start trial, you know, unboxed it as it were, it showed you how to do, uh, digital customer support. The product came with eight triggers and two automations that laid out the flow of a customer service conversation. You send me an email, you will get a response back through the trigger right away.

Um, saying we're looking at it. I look at it, we'll assign it to me. I look at it, I respond to it. We'll send something to you. If I solve it, it will sit there in a solid state for three days and then it will be closed. Or if you respond, it will be reopened. Those things were codified in the product. And there were tons of examples of things that had built up over time.

And we built up more, which were like, this is how you do digital customer service. We have taken a position on it. We have an opinion, this is what you do. And I think, you know, um, I see those things very much encoded into JIRA. This is how you run, a trouble ticket system, you know, which is really, really useful for engineers, right?

I mean, yes, there are, there are quirks of those UIs and of the UI of all those products and usability issues. But, but I think the power has come from, you know, really taking an opinion on how it's done and then, you know, doubling down on it until it almost becomes the lingua franca of its category until it becomes, you know, the thing against which other things are mentioned and judged, or you do it differently to some desk.

Oh, that's interesting. Why don't you do that? You know, That's that's a composition that you have to have with the customer, because if the point of friction, because we are the model about how you do that for digital customer service. So I think great products at their core are opinionated on how they should be used.

And that's okay. Maybe it's different for platform products, but I think for the SAS products we were talking about, I think that is fundamentally important. And then, so everything that you build, you, I think have to have an opinion on how it should be used. It doesn't have to be an in your face opinion.

It doesn't have to be that strong, but you should know, you should know what that purpose is. Um, it's, you know, it's allied to the jobs to be done framework in some ways, but it is a little bit different in that it is leading. Um, and I think if you can do that, you're taking a lot of, uh, thought processes and decision processes out of using the product, figuring out how it works, doing all these other things.

And it becomes, you know, comforting to turn on, and that is sort of culturally, like simplify, simplify, simplify, have a great first seven second experience, make it blindingly obvious how it works, why it works that way and why it should work that way. And then if you can keep doing those things, then you have a great product.

Um, just my opinion. 

 It's, it's really interesting framing this idea about being opinionated and how that leads to kind of these magic moments. I guess I wonder how that maps as your company grows and scales its customer base. Because the story I tell myself about companies probably like Salesforce at LaSeon and other just extraordinary companies is they often start out quite narrowly focused on a specific customer and tend to be more opinionated.

Brett Berson: And then as they want to go up market or expand, they end up, um, losing it. It ends up becoming harder and harder to become opinionated because everyone wants to do slightly different things. And that's when you like get into an admin page that has like 72 settings, um, that slowly kind of get built up over time.

And then you get to some scale and it's so complicated. And so overbuilt because you're effectively trying to do all of these things for all these different customers, a thousand percent customers different than the 150 person customer, et cetera, et cetera. And so how do you maintain that kind of idea of bringing some point of view or being opinionated about the way in which the product should be used with the tension of wanting to get more and more, probably different customers over time.

Adrian McDermott: Yeah, I think that is the challenge of. Any company, you know, there, there are two trajectories for increasing your term. You know, two main ones as a, as a SAS company, right? One is to go up, market wants to go down market. Uh, Zendesk is a go up market company. And so we start with this opinionated product.

And when we get into, you know, tough conversations with larger customers, or even just more sophisticated, tiny customers, which is, you know, where you first noticed this, actually you have this challenge of flexibility. And, I'm not going to tell you where they are, but there are some horrendous admin pages in Zendesk that make my eyes bleed.

And, um, that that's, oh, you know, we're going to fix it. You know, it's okay. But at the same time, I think it's important to realize that what are one of the words we're using a lot more internally is flexibility. Like I still am passionate about the discipline of shit works out the box. You turn it on.

Never seen it before it works and you can figure it out because it makes sense. I strongly believe that and a significant portion of our businesses self-service right. Even our expansion inside of enterprises to multiple instances is effectively self-service in some ways, although it could be assisted.

So that's just fundamental to what we do, uh, and will remain. But that shouldn't be a straight jacket for your, um, most sophisticated quote, unquote, larger customers and people who just need flexibility. Right. That flexibility should be there. You don't actually have to spoonfeed people necessarily who are looking for flexibility.

Like if the answer for one of our customers is API, uh, you better make sure those APIs like that is always, should always be your get out of jail card. Right. You can write an app for that and deploy it on the sidebar. You can use this API and do that. Right. They might, you know, roll their eyes, whereas their eyebrows and say, well, I have to work on that.

Okay. But at the same time.

you have obstacles that complexity from the rest of the users, because it is an edge case, right. Where it is not an edge case, start building that flexibility into the product so that it can be a low-code implementation, right.

So that the citizen developer Can access it, not just the functioning of. And if you're enabling for citizen developers who can click and have some sophistication, then progressive disclosure is what you need. And, you know, you can even keep that you can use plans to keep that out of certain packages so that not everyone has to see it, but it's there if you need it and you can go find it right.

When you know, this is sort of the classic problem of permissions and security and roles and management and these kinds of things. And I think it's, you know, you have to put that stuff into your product. And when you do a good job with progressive disclosure, with a good zero state that can be transformed flexibly, I think you can serve the bifurcated customer classes of op market debt market of smaller, big, or a sophisticated, not as sophisticated of develop a first low-code first.

Um, and all those personas are important when you have 170,000 customers.

Brett Berson: Can you explain in a little bit more detail? What do you mean by progressive disclosure?

 What is that, uh, admin page that wounds my inner child. Why does it look like that? And what is the mistake being made? I think the mistake been made is that all of those settings and functions and behaviors are treated as peers in terms of importance when they are not right.

Adrian McDermott: And they we've, whoever made them, you know, took craft and time in some ways to make that radio button, the rate of the language, you know, they used a content strategist to make that radio button tag as understandable as possible, et cetera, et cetera. I think that, um, core admin could have just been a set of, you know, configure defaults for all of those settings that you could have chosen.

 I want this type of admin, please make all the settings work for that type of admin. Right. You know, in a security example, um, you know, show me what groups should look like and I'll take them. Uh, I, you know, I want to click a button and this is a feature we just added.

Adrian McDermott: Right. Which, you know, I want an admin that can just handle billing, uh, usage and agent addition problems, but doesn't have access to the rest of the core sort of admin keys to the kingdom and can open the admin tabernacle and do all of the core settings don't want to do that. Just want them to do billing.

And, you know, you can put, give that to your finance people and it's fine. Um, I think that that's the sort of, uh, clever defaulting, progressive disclosure?

that you have, but then you give someone the, the ability to crack open the box and drag a few things around to make, make those setting changes or create new roles, but you create those new rules off in a different place and you kind of, you know, have a custom rules thing.

And yes, it's probably more steps to do the up to seconds. But that's okay. As long as it's long as it remains clear. And it's understandable 

Brett Berson: One of the things that kind of overlays this topic. That's been interesting, I think in kind of looking at your background and your story at Zendesk is that it, at times you've led all of product at times you've led engineering at times. I think you've led both under sort of one combined title.

And I I'm interested in how each role has informed the way that you think about the other. So like wearing the product hat, in what way does that inform. The way that you think about your role and job as an engineering leader and as an engineering leader, in what ways does it inform your, your job as a product leader?

Because in most scaled organizations, you tend to have some sort of product lead and or product function, and then a separate engineering lead in engineering function, And most of those people have only done that role.

Right? A product person came up on the product side and engineering person, engineering leader, CTO, et cetera, VPN came up under the engineering side. And so I was curious in, in what, what ways have they informed the way that you think about the respect of.

Adrian McDermott: Yeah, so I started as the VP of engineering and then after a few months, I shifted the VP of product in the Zehnder showers and took over product. Um, and I ran it then for 10 years, uh, both of them, absolutely. But, um, I do I'd run product before I actually was a GM and ran a sales unit in a startup that I worked for, whereas busy, uh, losing money for first round.

And, um, as I've done both of those things, I've, I think that the empathy and the customer insight that you get from being in product and being out on the front lines and channeling that and communicating that, right. Like, you know, I think the, the head of X job in so many ways, like definitely the head of product and head of engineering is really about being a highly paid router.

It's about, you know, being a filtering amplifier for the things that you see. And the insights that you get from them and then repeating them over and over again in your organization and getting people to understand them and have the same level of empathy. And that's, you know, as basic as what does it mean, you know, to that guy, a group.

When, um, when the, when the site is down, like, what does it mean for him to have a thousand people who's paying in a room in Berlin, um, who were sitting there idle it's Korea hurting for him in terms of, he will not progress in his job or in that company.

And, you know, people have to hear those stories and hear about the true cost of things that they do or why. Um, our customers are so passionate about certain features or how things are going to be used or the way that people are, you know, getting people excited about the new initial string ways that you see startups or existing companies using our product.

And it, you know, being able to personalize the stories of importance and being able to communicate, I think is key to. Running engineering. So if you're not the engineering person running product, um, you, you need to be talking to customers and you need to be thinking about the business in that way.

You need to be going out on sales calls. You need to be going out our customer. Successful's not just. To apologize, right? I mean, um, you know, the acts of contrition and, and fall lock talking after an outage is maybe sometimes the only time that you were head of engineering or service talks to customers, and that's a mistake, right?

They need to be all of your engineers need to be seeing and experiencing what the product people should be seeing, experiencing too. Right. They should be speaking to customers everyday and doing that, but in a, you know, an, product growth led business, or an enterprise business with assisted selling, I think you, um, are in danger of, of sitting in your bunker and developing.

And I think that is a very hard thing to do. Well, you have to be getting out there. And then if you were leader, you have to be communicating and over-communicating your experiences until people are bored of. hearing you, frankly, 

 you touched on this a little bit, but what about the inverse? What is the, your role, um, as an engineering leader, in what way has that informed your role as a product leader?

Adrian McDermott: I think, um, engineering leaders, uh, good ones, which I may not be. Um, I think what they do is they inject a level of realism into the ambition, right. Um, you know, uh, uh, product development organizations reach that exceed its grasp, but not by too much, right. People want dependability and they want delivery.

And I think, having the ability to understand what is hard and what is not. And that could be, you know, um, Calling kind of bullshit on something the CEO is asking for. Cause it's actually really difficult and you know, it's one of those, I'm like if we build that, it will be a face tattoo, it will be there in front of us forever and we'll never be able to get rid of it.

Right. And being able to sort of say that with the, with the confidence, because you know, all of the decisions that all the way down and what they're going to impact is really important. And then, um, you know, a core problem, I think in most organizations with separated engineering and protocol is the amount of time that goes into, um, You know, keeping, keeping your internals clean, keeping them under control, housekeeping, uh, refactoring, 

If you need to take a time out because got, you know, we moved from, uh, we were in engineered the Ruby on rails hosting company. And we, we were asked for more capacity in the database because, you know, we were hitting the limit every Monday morning when Twitter users came online and they were like, yeah, I know that's the biggest machine we have.

And so we, you know, we moved data center and did that, and that was like everyone down tools. What you're doing is less important than this we're moving. And then we did the same thing actually, when we moved into AWS a couple of years later and, been able to make those code decisions of everyone down tools, this is what we're going to do.

It's incredibly important. And respecting the ongoing investment. I think w I think where I've succeeded, I've been sensitive to that and kept it moving because nothing is more important in some ways than the health of your application. You know, your book of business is paying you to run that service.

They're not paying you for the quality of the spreadsheets or the beauty of your designs. They're paying you to run that service, make sure that you're fixing bugs in it, and they're paying you for upgrades and new features. That's that SAS, uh, and you, whatever the function you need to remember that. And I think, um, having been on the engineering side, it gives me a little perspective on the cost of things and the importance of those investments. 

Brett Berson: I wanted to switch gears and talk in a little bit more detail around some of the things that you figured out around go-to-market and maybe the intersection of, of product and, and go to market. Um, I guess at a high level, in the last decade of bringing Zendesk to market. Have there been, um, step function changes in the way that you've thought about that or changes that you've made that have had a surprising impact.

You gave one very small example of, uh, the difference between, um, having a human involved in adding seats versus allowing people to do itself serve. you've built a really interesting market engine, um, and interested in kind of what are their crystallized insights that may be useful to others that are starting to bring products to market.

 one of the key insights that I learned the hard way early on is just how difficult it is to, um, change or influence the behavior of that cohort, right over the people who are out there selling, right. You know, they get a number. The number is basically sort of a, a 90 day challenge to your existence at the company is one way that you could think about it.

Adrian McDermott: And they internalize that work towards it. Take it super seriously. That is the, you know, metric for success is how they self-actualize. It's really important to them. It's how they are admired by their peers. Right. And, then they apportion their time. So new things are generally not seen as, oh, great new stuff in my experience.

They're more likely seen as, oh, great distraction. Uh, I'm going to ignore that until it has traction and then I'll start selling it. Right. And so, um, there was a program that the, the general manager of voice put in place, which I thought was really good, where he noticed that, um, of our total Salesforce, 

Some small single digit percentage of the account executives were responsible for the majority of voice sales. Right. And it's like, everyone else, if they've never done one, they aren't going to do one. So he invented the voice virgins program where he took a couple of his experts on his staff. And he's like, ring the bell, When you have a voice prospect and we will SWAT team in and to help you get through this first sale.

And they basically dedicated a ton of effort to this to get, um, as many people as possible, and I think there was a spiff attached as well, because, you know, there's always a spiff to get everyone to the point where they had sold voice wants. Right. And so the voice Virginia program, as I remember was tremendously successful because the people who sold it once, you know, the fear was taken out of it, they realized it wasn't that much effort.

They realized that there were people they could call. If the questions were too technical or they didn't know the answers. They found out where the competitive info was in the internal systems and yada yada, yada. And then they went out and they did it again and they did it again and they did it again.

And, um, I think from an enablement point of view, when, you know, you'll go to market is set up, you found product market fit. It runs like a flywheel, but it's very much running, um, on repetition, right? It's running on familiarity and you know, those, those salespeople, uh, you don't see it, but the, you know, self qualifying out of things that are too much work, you know, I, as the head of product might be like, you know, we should totally win that deal.

This is the thing that we should do. It'd be great. If we could get that name, it'd be great. If we could get them using this product, blah, blah, blah, that person is like putting it in the too hard basket and moving on to something else. Like I could sell five agents down the street, I can, you know, do this other kind of smaller tactical thing.

My time is better spent there. And so you need to take a really empathetic view of how they're gold, uh, and the goals that they're given spiff. So not enough. Um, and I think you need to put the effort in to change behavior, but it's, it's changing those behaviors and incenting people differently that sort of moves the company along and eventually changes the growth trajectory. 

Brett Berson: Great. So I thought we could wrap up just by talking a little bit about team building and recruit. It's something we haven't spent that much time talking about. And do you have such an interesting lens over the past kind of 11 plus years from 50 to 5,000? And so I'm curious, um, what are the things that you've learned that other people might not know about, or maybe even disagree with in terms of hiring or interviewing or finding the right people for your company at a given point in time?

Adrian McDermott: Yeah, I mean, philosophically, I, I think, um, I often say this in interviews, or I certainly used to, when we were, we were definitely a start up like a startup for an employee and from an employer is basically a fallacy in bargain, right. Where you sell your labor to me, um, you know, you are the means of production for this business in engineering and in return.

Uh, you tell me what it is you want to do next, like what your next step in your career is. And I will make sure that I am preparing you for that. Right. And, um, to the extent that I can, right. And I think about, you know, your employees, labor is On loan to you. You don't own it. It's not your asset, it's theirs.

 it's a SAS product they're renting to you every month, basically. And I think making sure that, you know, as a management and development kind of thing, everyone understands that connection and that bargain and that people are being prepared for. the, next thing is extremely important.

Adrian McDermott: Um, secondly, you know, I, I interviewed a thousand engineers probably in the first few years of Zendesk. Um, and I went in and I asked them all the, exactly the same. Um, white blood question run. I think coding. And I realized after a while, maybe it was at number 300, maybe it was earlier than that. I realized that, um, I wasn't listening to the answer or looking at it.

I was, it was a ritual. Um, whereas just looking at, you know, uh, how they reacted to the question, how they held the pen, what their thought process was. You know, some days I would have had too much coffee, I'd be like, are you done yet eaten yet? What how's it going? Are you done yet? Um, cause you know, it can be incredibly annoying.

Uh, other days I was sorta like, you know, uh, do something else and be like, Hey, how's it going? You know, what are we going to do? I think, um, pattern recognition is really important, right? And I got to recognize patterns in terms of how people would cope with that and what they would do and other things.

And that's why I also think per hiring engineers, like there's nothing like. Pair coding. Some people refuse to do the exercise. Like, yeah, I don't really do well at whiteboards. So I'm like, all right, I respect that. Um, if you were going to do it, what would you do? Um, and sort of talking about method in that way.

Brett Berson: On the, point that you made about interviewing call it a thousand engineers. Um, you touched on this, uh, sort of what you learned about the, the white boarding exercise. I'd just be interested. Are there other parts of the way that you actually interviewed that you found gave you particularly high signal or things that you thought mattered that didn't because the great thing is you got to interview a thousand people hire a portion of those and then see who thrived in your company and who didn't.

And so are there any things when you go down to that sort of detail level that, that, that you found to be extremely effective or maybe not.

 mistakes wise, I always overemphasize background. Um, Probably one of the best engineers we have high ed had no degree had odd shoes on, went out for a smoke in the middle of the interview, but he was extraordinary and he was extraordinary cause he made other people better and because he really cared not.

Adrian McDermott: he wasn't.

You know, archetypical, antisocial genius, who brought everybody else down. Like he actually made everybody else better, which is for me, the quality I look for in a great people. 

So I got comfortable with not worrying too much about what they'd done before, whether it worked before, you know, where they went to school, um, these things in the longterm, aren't good predictors of outcome or success, frankly.

Um, they're reasonable, but they're not the best. Um, it's more about, you know, EEQ to a certain extent and care and passion. Um, and you know, I've always thought that people would. Uh, really diverse interests in terms of, you know, the DJs we've hired and the creators and the makers we've hired have brought something delightful to the culture.

And it was often indicative of the fact, certainly early on that they were going to make this outsized contribution to the way that the company operated and to the culture of the company,

Brett Berson: Great. So to, to wrap up my, my last question is one that I always like to ask, which is, you know, when you think about your role as a product leader, leader, engineering leader, company builder, who, or, or maybe what two or three other people have had kind of an outsized impact on you and your success, and maybe kind of, what, what did they teach you 

Or in what way did they make you better?

Adrian McDermott: um, I think one of my key early influences, the first startup I worked at was a company called plum tree. And I spent, um, I spent 10 years there actually it was through IPO and then acquisition by BA until the acquisition by Oracle. And I, I worked with a bunch of really brilliant people that I'm still friends with, including, Jay Simons, who you had on this podcast.

Um, at one point I was running engineering and he was running marketing, um, post acquisition. And I think they're the founder. One of the founders, Glenn Kelman, who's now the CEO of Redfin, um, was a big influence. it was on-prem, but it was an enterprise software company. And just the way that he.

Thought about customers and strategy and competition and the market and building product. Um, you know, that was where I learned my craft. Uh, I went from, you know, engineer to senior engineer, to manager, director, VP of engineering to running it at the BA acquisition. And, um, I think I, I took a lot from that experience in terms of what it takes to be a leader, how to show.

Um, you know, how to, uh, the term I use is, is shit umbrella, right? The people below you didn't, you don't need to know what's going on above you or what's going on in your life. That's for you and you alone. you know, they pay you to be a leader to project out. Um, not all, not all the good things, but, you know, keep some of the chaos from your employees.

Your job is to help them clear the way for them to do a better?

job and move forward. Um, not to involve them in, you know, your politics or the, the squabbles of the management, and I think, you know, that was formative for me. 

Brett Berson: Awesome. Well, thank you so much for joining us and sharing. This was an awesome conversation. Thanks, Adrian.

Adrian McDermott: Thanks so much. Appreciate it.