Paul Adams

[Amy Jo Kim] Welcome, Paul, to the Getting2Alpha Podcast.

[Paul Adams] Hey, very nice to be here. Thanks for having me.

I’m really thrilled to get to interview you today, and share your wonderful background and insights in what you’re doing now. Let’s get started with a whirlwind tour of your background for people who aren’t familiar with you. Tell us how did you get started in design and tech? Then how did you decide what to pursue along the way that led you to where you are today?

I’ve had a very varied journey. Actually, originally, I studied industrial design in university. That was actually my first foray into the world of design. When I graduated from that, I designed car interiors and retail interiors for about a year. This was around 2000, which kind of ages me, 2001. The web was taking off. I was really excited about that as a new medium, so I went back to university to study interactive media and graduated during the dot bomb, which some people may or may not remember. It was a period where wanting to work on the internet as a designer wasn’t easy because there’s no jobs. Thankfully, like all great communication technologies, it picked back up shortly after.

In the meantime, I actually joined Dyson. I was working there as an industrial designer for a few years, which is actually a great experience. It gave me lots of lessons that I still hold today, but I got back into interactive design. I worked at an agency in UK, in London for a few years as a researcher and then an interaction designer.

Then I went to Google and I worked in the UX team in Google. Most of the time I was doing research. Some of the time I was doing design. I worked on lots of early mobile work at Google, mobile apps like Gmail and YouTube. I worked on a lot of social initiatives like Google Buzz and Google+.

I then left for Facebook kind of midway through Google+. Through a whole bunch of circumstances I’ll get into, left, joined Facebook. I actually worked as a project manager there for the first half of my time, and then worked as a designer for the second half of my time.

Then about three years ago, I left Facebook and joined Intercom, which at the time was a tiny fledgling startup, huge potential and very early. I joined to kind of take over product design from Eoghan and Des, two of the co-founders. Since then, I built out our team. In the early days, I was actually designing myself and some version of product management, I guess. I was the only one person in that world. Since then, I built a big team. I now run four disciplines here: product management, product design, research and content strategy. We’re growing. It’s like 30 people on my team at the moment.

Wow, you’ve really taken on different challenges throughout your career, different roles.

Yeah, I’m potentially your world’s worst nightmare because I know a little about a lot depending on who you ask.

Well, then you’re probably in a really good position right now to oversee all those different areas because you have empathy for the people that are in that.

I really would like to dig in a little bit to Job Stories and Jobs-to-be-Done, and how that’s infiltrated your culture and the way in which you do design and product management. As we have discussed, I knew about you. I first was impacted by you when you wrote years ago, what three years ago now? Four years ago? Something like that. An article on Job Stories, using Job Stories in product development and product design. That opened my eyes to that tool. How did you come to write that article? Now, how has your use of that tool evolved?

It’s been fascinating. I had never heard of Jobs-to-be-Done before I joined Intercom. Eoghan, who’s our CEO and co-founder, and Des, who’s our chief strategy officer and co-founder, Eoghan and Des actually taught me about it. It was a framework that not a lot of people knew about. There’s a bunch of people like Bob Moesta and Clay Christensen who talked publicly about it, and they were pioneering a bunch of things there and popularizing the idea. Jobs-to-be-Done was really inspirational. We took a lot out of it. We’ve used it pretty heavily here at Intercom, not just for product, but for marketing and a whole bunch of things.

Honestly, the Job Stories thing happened by accident. We were looking at this theory. It really is theory. There’s some great examples that Clay uses in his writing about Jobs-to-be-Done, but it is a theory. We’re just applying the Jobs-to-be-Done framework to our work. As a result, we kind of came up with this formula to describe the way we wanted something to work, or how we wanted somebody to feel through something we designed. It didn’t have a name. It was just this format. The basic format was when something happens. It’s basically “when I want to…” which is like a motivation. Then “so I can…” which is expected outcome. A really simple example is when a user signs up, I want to personally introduce myself so I can ensure that they feel like we care or something that’s really rudimentary.

We have this framework and it didn’t have a name. I wrote this blog post called The Dribbblisation of Design. It was actually just this big giant rant about that over emphasis on visual design without any kind of more foundational design thinking and a lot of work on Dribble and other places. The Job Stories was almost like this addendum to the end of that post. That post got a lot of exposure. People kind of saw the Job Stories thing at the end and actually kind of jumped on in as this really pragmatic, practical tool to take out of this big rant that I had written. It kind of took off by accident. It sort of started by accident and it took off.

We still use it today. We still use it a lot in our work. We use it very early often. We’ll use it at the high level at an early stage in a project. We write Job Stories as part of the brief basically. Then we’ll use it as a check in along the way. It’s very easy to go off-script through something as intangible as design. We’ll use it to kind of keep ourselves honest.

Got it. Do you ever find that you use it to translate user research into design-ready form? That’s one of the main ways I use it.

Yeah.

There’s that moment where you’ve done a bunch of user research and you’ve done it well, especially early research like qualitative, needs analysis, customer discovery. Then you’ve got the research and you say, “Okay. We have 50 features on the board, and we could only do three. How do we put all that together?” That’s part of where I found Job Stories so useful.

Yeah, we definitely use it that way as well. I think for us most of the jobs we write are based on research, sometimes they’re not. That’s obviously not ideal. It depends on what we plan to do research on. They’re usually in some form of cluster communication just through the nature of Intercom, the product that we design and build. We actually use it for ourselves. We just have hundreds of conversations of customers all the time. It’s actually most of them even if we don’t go and do research are informed by some customer conversation.

How do you decide who to pay attention to in those conversations and who to sort of filter or contextualize?

It really depends. We have this interesting phenomenon. We’re somewhat unique in this way. Then I think if any company use Intercom at scale, they’ll have similar scenario. For people who aren’t familiar, you can use Intercom … Intercom is a customer communication tool. You can use it for customer support. Through the customer support lens, we have hundreds of conversations a day, if not more, sometimes thousands a day with customers. We tag all of those conversations. We may tag them like “feature request”, or “bug”, or whatever else.

Then our research team aggregates them. Every now and again, they’ll go in and they analyze all of the different conversations that we have. We’re actually not really filtering by … Sometimes we are, but we’re generally not filtering by customer type. We’re actually most of the time filtering by something else. It’s probably the Job-to-be-Done.

Again, if people aren’t familiar with Jobs-to-be-Done, one of the key distinctions between Jobs-to-be-Done versus other things you might use like personas is that I arguably would say the personas are very limiting. These archetypes of customers are extremely limiting and they make you focus far too narrowly early on. The market for a job is actually way bigger. That is concrete, by the way. A bit of a tangent.

When I was working with Facebook, one of the amazing things that I observed with the data set at Facebook was that most people all over the world were trying to do the same things. You could have built personas on Facebook like all the classics like teenager, active teenager, or like soccer mom, or like all these kind of archetypes. If you actually look at what they do in the product, they’re all doing the same thing. They go to an event. They take loads of photos, and then they want to share those photos with people who were and were not there. Then they want to reminisce. If you’re like a 17-year-old kid in Korea or a soccer mom archetype in the United States, you actually have the exact same workflow. That’s the lens we apply. We don’t try and build personas or archetypes. We actually look at all the feedback and look for jobs in that feedback.

That is so exciting. To me as a game designer, and especially applying game design to product design, it solves so many problems. As I mentioned earlier, you really opened my eyes with your writings. I’ve used personas for many years and you probably did, too, in your own work.

Yeah.

I’ve struggled to communicate to people why I no longer really use them because everybody loves them. What I think is that they’re actually great for marketing segmentation. I think that if you look at the history of personas, it actually came out of advertising and marketing originally. Then user interface people adopted them and I used them for years.

What I found now is that job stories do what, in gaming, we used to call psychographics versus demographics. They’re closer to psychographics. When I use Job Stories … I’ve extended them to talk about the experience over time. You have you discovery job story, and your onboarding job story, and your habit building job story and your mastery job story. If you write those, if you have somebody write those, all the personas just go out the window.

Yeah, very much so. I think that the job is just the superset. The Facebook example I use is a good one because if you are the designer for a photo sharing experience in Facebook and you go about it in one of two ways, you can write the job story, which is something like when people attend an event and take photos, they want to share them easily with friends so that they can reminisce there or in the future. I’m literally making this up. That job story is really powerful. It makes you think about a whole bunch of things like memories, and permanence, and things like that. It’s totally agnostic of the person. They could be old or young. They could be in any culture. Whereas if you build a persona, this archetype, you’re already narrowing your thinking. If there’s a persona, it’s a teenager and some other persona, you’re already, I don’t know, taking onboard a whole bunch of biases that shouldn’t necessarily exist.

Like you said, I was a huge, huge proponent of personas. I made dozens, if not hundreds of personas over the years. I was a big fan of Cooper. I actually still love the book About Face. I actually tell our design team here that we should study About Face, the book, but they should skip the personas chapter because we don’t really believe that anymore. That’s a very similar story.

Do you know if the folks at Facebook use Job Stories in their work? Did you try and infuse them with that? I guess you learned it from Intercom after you left Facebook.

Yeah, I don’t know if they do. When I worked at Facebook, there wasn’t a huge use of personas. They definitely existed here and there.

For me, the biggest benefit of personas is in a culture where organizationally, people aren’t directly connected to customers. That’s not part of their belief system. What personas do is they open people’s eyes to the idea that their assumptions may not actually be true in the real world.

For me, personas were a really valuable tool over the years for getting people to stop thinking about themselves as the user, as their user. Honestly, looking back, there’s probably a whole bunch of other ways to do that, too. Just actually have people show up to research, the primary research themselves, watch videos, talk to people and so on.

Right. Well, different tools for different situations. You mentioned that you use Jobs-to-be-Done and Job Stories a lot in the early phases of work. What is your internal process at Intercom for deciding which ideas to pursue and which ones to filter out? That’s always a challenge I know for everybody, especially with a mature product where you have lots of stakeholders asking for lots of different features.

There’s a bunch of things. I guess I can break it down into two main things. One is, we, as a company, have a really clear mission, really, really clear mission. From before I started Intercom just talking to the founders, that mission is very clear. It hasn’t changed. Being very mission-driven, it’s easy to evaluate ideas against that mission. People internally here have had many, many, many great ideas that are great ideas for other companies.

I worked in a bunch of scenarios in my past prior to Intercom where there wasn’t a clear mission, or the mission was competitively driven. In that environment, it’s actually very hard to evaluate one feature over another because it all sound good. If they all sound good, and you don’t have a mission to focus them, and get rid of some, you end up building a lot of them and end up with a very confusing product. Being incredibly mission-driven is one big, big, big component.

The second is that when we build our roadmap, which is basically our plan for what we’re going to decide to do and not do, we have five inputs. This basically keeps us honest. I’ll go through them very quickly. One of the inputs is iterating recent product. Again, it’s easy to ship something and then move on to the next shiny thing. One input is iterating recent product.

One input is new ideas we have. We’re incredibly research-driven here. This is our roadmap track to just invent new cool things we just want to do and put time aside to do them. They’re not based on research. It’s just based on intuition.

We have a track for customers like customer requests, feature requests and so on. You don’t obviously necessary build what they ask for, but we listen to what they ask for. Then go and ask them why they want that thing. The way that I describe this to people is that our customers are experts in their problem, but they’re not experts in the solution, the best solution. They’ll always describe things in terms of solution they want. We need to dig back and ask them, “What’s the actual problem you’ve got here?”

Then we got a track for bigger companies using Intercom. As we grow as a company, we need to … Most startups who are successful will face this challenge, too, where as you get bigger and have more companies trying to use your product if you’re selling to companies, then these bigger companies have different needs because they have more people in the company using the product and so on. We have a track for that.

Then the last one is quality which is bugs, speed, latency, all of those things. Basically the aggregation of those five really, really helps us prioritize what we do. My guidance to my team is that there should be a balance of all five but it doesn’t have to be equal. We can oscillate. One team of our product teams is a hundred percent working on iteration because that’s what they need to do. Then they’ll move and they’ll work on something else for a while. That’s kind of how we decide basically.

Do you integrate Sprints into your process in terms of focusing? Like you say somebody is focused on iteration. Are they using a Sprint to keep them focused? Do you have other structures that you use?

Yeah. We kind of work in Sprints. We don’t have a formal process. We don’t subscribe to any one system. I actually have a couple of other strong opinion at those things, but that’s another story.

Could you tell us the really short version of the story about your really strong opinion about it?

Yeah. I think anyone who subscribes to anything dogmatically, it’s kind of like a religion, and it’s like a cult, and it’s probably not healthy. If people do Scrum and buy a book called How to do Scrum, and follow the book, they’re probably doing something bad and terrible. If someone uses Kanban and obsess about that, that’s all they do, it’s probably bad because every company is different. Every team is different. Every product is different. There’s ways in which these things would work and ways in which they won’t.

Here, at Intercom we do things that look a bit like Scrum and generally everything we do looks more less like Agile. We have versions of boards that look kind of like Kanban boards but not quite. It’s because we just keep evolving our own process. We’re not following any religion, dogma. That’s kind of the short version.

I get. I get it. Basically, it’s continuous learning.

Yeah, exactly. We actually do a process that I can explain in a second. The process keeps changing. We’re constantly evaluating it everyday. Everyday there’s conversations about doing retrospectives here and there. What could be better and different? We’re not obsessive of any one thing. We’re totally changing it all the time.

That sounds really healthy. On that note, you probably have had exposure to a number of entrepreneurs in the Dublin scene, in San Francisco in your time at Google and Facebook. What are some of the most common mistakes that you see first-time entrepreneurs make, especially when they’re in the early stages of bringing their ideas to life?

I guess there’s a bunch of things. I referenced one earlier which is assuming too much or thinking that your users are like you. This is stating the obvious, honestly, but it’s still rife. At some level, there are times when designing for yourselves is fantastic. There’s sometimes when it’s terrible. That’s one big thing.

Another big thing I see is that, especially in design teams, you’ll see people not prototyping early enough. I often say here that we need to design and code. That doesn’t mean designers should code. I don’t actually think designers need to code. I think they need to know how code works. They don’t necessarily need to be able to write production code. They need to embrace process whereby you’re designing in code.

What I mean by that is because of the nature of the internet as a medium, a lot of things are hard to feel and know if they’ll work when they’re in sketch, or frame or choose your tool of choice. You actually need real code, actual working code to really evaluate if this thing feels right, if it’s feasible. I try and get engineers and designers to sit beside each other, work together, collaborate. As you start writing code, the designers are giving feedback on how the thing feels. I don’t see that nearly enough. I see the opposite still which feels actually kind of a lot more waterfall where designers get to some version of complete, and then give that to an engineering team. I still see that.

I guess they are the big things: assuming too much, not getting feedback or not prototyping enough, not designing in code.

That reminds me of the William Gibson quote, “The future is here — it’s just not evenly distributed.”

Yeah, yeah, yeah. Why does it remind you of that?

So many places people don’t do that anymore. Yet, it’s still so pervasive to see what you’re talking about. I see it, too. I was actually fired from a gig about two years ago because I wouldn’t deliver complete Photoshop-ready production documents that didn’t need any tuning, or testing, or tweaking. I was having a what year is this experience.

I see the same thing. It’s really interesting because this podcast has a lot of game designers and they say the same thing for what they see first-time game designers making the mistake. They don’t prototype soon enough. Too much time on design. The more time you spend on design upfront before prototyping in any way, the more attached you are to your design.

Yeah, yeah. Absolutely. It’s basically sunk costs fallacy. I see it all the time I think as a much higher level trend as well. People read the books like Lean Startup, or Lean UX, or whatever, again, pick your book of choice. People read the books. In reality, revert back to old habits. Old habits die hard. We have it here. We’re not innocent to this. I do it sometimes. Other people do it sometimes.

I struggle with it. You can catch yourself. That’s part of where just like an Agile and Scrum approach where you reflect on, hey, what could we do better? You don’t have to follow it to the letter. If you build that into your rituals, then you’re basically practicing the spirit of Agile and Scrum, which I think was your point which is to practice the spirit in a way that’s contextual to what you’re doing.

Yeah. It’s slightly different for everyone.

Looking back on your career and the different roles you’ve played and now what you’re doing, and where you’re heading, what do you feel is your super power, your sweet spot as a designer and a creator? Another way to ask that is what lights you up the most?

Over the years, the only role that we haven’t had that’s common in technology teams is engineer. God help anyone who would try and use code that I write. I’ve been a product manager, and a designer, and a researcher. Through that lens, I’ve learned what I’m good at, and bad at. It’s really clear to me. The thing that I’m probably worst at is all the details of product management. Someone once said to me when I was a product manager of Facebook they said that I was great at the product bit and bad at the manager bit. What I’m better at is product strategy. That’s kind of my sweet spot. Helping create a vision for something, how people are understanding what that means, plotting the future to some degree.

One of the things that we do here at the company is create these product strategy boards. We have this mission but the mission goes out years. It’s going to take us years, and years, and years to fulfill that mission. Yet, at the day-to-day level we kind of work to …

Back to your question earlier, actually we work on a kind of six-week cadence. We have kind of a six week Sprint for want of a better way to describe it. Then we think about six months. There’s a big gap between six months and many years. These strategy boards fill in that gap. The strategy boards, they’re not a project. They’re themes for all teams to think about. That’s some of the stuff that I work on or try and find as much time to work on as possible, as building out these strategic themes that are actionable enough for our product teams to take on and fold into the work they do everyday.

How did you come to six weeks?

It’s a good question. Trial and error. I wrote this post. It’s on our blog and on Medium as well called 666, which is obviously deliberately like the devil or something like that. It’s memorable at least; which is six years, six months, six weeks. The reason for those time frames is when I worked at Facebook, one of the timelines people used to think about was six months and 20 years. Facebook has this mission that’s going to take decades to fulfill and materialize but that’s not practical. They used to work up to six months like have kind of half year product cycles. Six months and 20 years.

I adopted that for Intercom. When I was adopting it, 20 years is way too long for us. We’re not Facebook. We’re still a startup. Us in 20 years, who knows? Six years feels closer to something that we could think about. When you go back from that, to me, time frames of two years, one year, 18 months, two years are actually terrible time frames for product teams because if you’re trying to predict what the world is going to be like in two years, you’re almost certainly going to get it wrong. Yet, you’re going to make plans around it.

Whereas for six years, you make no plans. It’s your mission. It’s agnostic of all the technologies, and trends, and themes, and design. Whereas two years, you’re like, “Oh, yeah. We could start making some plans and actually build a robot there.” In the next two years or two years from now, we’ll have seen two new versions of Android, and two new versions of iOS, and some new web frameworks, and a whole bunch of other things like bots. Bots is a thing, and bots wasn’t a thing two years ago.

We kind of went back to six months. Six months feel somewhat predictable. Then we moved back from there to something that can be really be concrete. From today, what feels like a good time frame to be extremely concrete? Six weeks felt about right. I honestly don’t have a better answer than about right. Eight weeks, 10 weeks is a bit too far in the future to really prescriptive for us. Three, four weeks doesn’t feel far enough. It feels like we’ve been chasing ourselves continually. In the next six weeks we could design, build and launch a whole bunch of things in that time frame in total. That’s the gist of it.

That’s really interesting. Thank you for describing that. What are you seeing on the landscape in design and tech that’s new and exciting to you these days? What trends are you following? What are you paying attention to?

There’s a bunch of things that I think are fascinating at a slightly abstract level. One of the big, big, big things I think, especially for designers is around the idea that in the foreseeable future and beyond, many designers won’t be designing apps, won’t be designing products in the same way as they do today. They’ll be designing systems. It’s going to be a core, core, core design skill to be extremely good at systematic thinking, be able to internalize a system, design a system that’s ever-changing.

If you look at a lot of the amazing fast-growing startups today, for example, they’re actually not apps. They’re ecosystems. Uber being an amazing example. Uber is a logistics ecosystem. Today, it’s focused on people and cars, but in the future it could be all sorts of other things. The designers of Uber aren’t designing the app. The app is the means to an end. The app has a tiny surface area. I’m sure if they could get that app down to one single button, they would. What they’re actually designing is a system. What happens when you hit that button? How can they insure that they’re matching drivers and passengers and taking all these signals from all these different devices and so on and network and all these things? There’s loads of other examples, obviously.

A lot of the things designers design today are merely apps. In the future, it’ll mostly be systems. That’s a big, big, big thing. It’s a big thing that I instill in our team here. Intercom isn’t an app. It’s a system. At Facebook, the design team there don’t talk about Facebook as being a monolithic app. It’s a system. I think that will be true for more and more people. That’s one big, big thing. It’s pretty high level.

Things that are exciting to me. These are things we’re working on, something I pay attention to. One is the messengers. The idea that these messengers like Facebook Messenger and so on are now big enough, and broad enough, and open enough such that they can become platforms. They can even be considered to be an operating system if you really want to go that far. Lots and lots of things can happen on these messengers. That’s pretty interesting.

I mentioned bots earlier. The whole world of bots is also fascinating to me. I think there’s actually bot frenzy right now, bot overdrive. I think it’s a real thing. Bots are good for some things, terrible for others. Computers are great for some things and humans are way better in others. I think are people are applying bots blindly to things that computers are terrible at.

Like what?

Like things that require empathy or things that require an emotional reading of a situation. Lots of people are excited about bots in customer service.

That’s in your end. That’s your area.

Yeah, yeah. Exactly. We’re building bots.

Of course you are.

Of course. Why wouldn’t we? It’s exciting. There’s just some things bots are bad at. One of the big things for me … It’s fascinating to see all this stuff with AI and the game Go and Google’s-

That was big. That was a moment.

I’ve no idea what that even means. For us, Facebook are experimenting with M. M is a bot or a computer. There’s people there, too. Facebook is deliberately blurring the lines. It’s unclear to you as a user whether you’re talking to a bot or a person. Neither is right or wrong. Just different.

Our philosophy is the opposite one which is you should always know when you’re talking to a bot because if you know you’re talking to a bot or a computer, then you know what to expect and what to expect of them. Don’t expect emotional intelligence or empathy because you can’t get it. That’s some of the things.

That’s a big issue in multiplayer game design and has been for years whether you blur that boundary or make it really, really clear. People fall in different camps. I’m more in your camp. When I came up through MMO design, we talked about that a lot. If you think about like World of Warcraft, do you know when you’re dealing with a bot and human? You do, don’t you? That’s a conscious decision they made.

That’s fascinating. Why is the matter an interest to you and are you in the same camp as me? Why is that?

Trust. Clarity. I am a systems designer. That’s the through line of everything I’ve done through engineering, and neuroscience, and all. I remember when I was in grad school studying neuroscience and computer science at the same time, it became very clear that humans are better at some things and computers are better at other. The history of AI is once you establish the right microdomain, AI works. It’s all about how narrow is your microdomain and what is the AI doing in it? As you said, humans are good at basically versions of lightning fast parallel pattern recognition like empathy. I’m a fan of using computers to augment humans, not pretend they are humans. That’s why I’m in your camp.

That makes sense. That makes sense. The flip side is true, too. Obviously which is that there are things that humans have to do that are insanely repetitive that computers are amazing at. I think one of the reasons that customer support or customer service, as an industry, has a lot of high churn and people leave is because they’re just constantly answering the same queries over and over and over and over again. It’s repetitive.

For example, if a customer got in touch and said, “Hey, I’m just wondering. When is my next bill due?” A computer can answer that in like less than a second whereas a person has to like, “Okay. Let me just look up your account.” Parse all the information on screen. “There’s the bill. All right. Cool. What day is it today?” Just way, way more inefficient and it’s really boring for them.

Is that leading into where you think it makes sense for Intercom to work on bots and where you think it makes sense to just get the human element even better than it was before?

I think so but I’m not sure. It’s really early days. We’re like dipping our toe in the water. One thing that’s been interesting … Again, this is in our new ideas we have tracked. No customers are asking for bots. This is just something we think is cool and fascinating and there’s value there. We should just experiment and play with some things. Build some things. Back to designing and code. Let’s just go build some bots and see how they feel like. Actually, feel being the word. Back to the empathy thing like what would they feel like?

One of the big lessons we’ve learned is that it’s really hard. It actually is really hard to design good bots. It’s sounds easy. How hard can it be? Once you get into any kind of working logic where if bot does this, then do that or even if you’re learning across the data set and using some kind of machine learning, there’s still all these workflows you have to design. It’s actually really hard to make a really good bot. That’s our lesson so far.

That is a great lesson. Tell us about what’s coming up for Intercom looking forward. Is there something on the horizon or something you’d like to tell us about?

Yeah. We’re working on … We’re pretty quiet externally in the last few weeks and months. We’re working on a whole bunch of new things, new product coming that unfortunately I can’t talk about yet that we designed from scratch.

One of our design principles here is actually to go back to first principles. Kind of taking a leaf at an Elon Musk’s book. With this product, we’re back to first principles about a problem that’s in our domain. Something coming out there soon.

We’re doing a lot of design work on our messenger and dabbling our toe in the water into bots and things like that. I very much see messengers as being this incredibly important strategic layer for lots and lots of different types of businesses. Going back to idea that people are designing systems. It’s entirely possible that companies will build on Intercom and build on our messenger. They’ll actually have no UI themselves. Their designers won’t design UI or apps. Their designers will just design the way their product interacts with Intercom or other places like Facebook, or Shopify, or Twitter, whatever. That’s what we’re doing.

I spend much of my time building our team which is, I’m sure you know from experience, extremely time-consuming. We’re trying to hire people and grow everybody and so on. That’s it.

Great. I’ll make sure that we share all those URLs on the episode page. Thank you so much, Paul, for sharing your time, and your experiences, and your insights with us today. It’s been awesome.

Yeah. Absolutely. I enjoyed it. It was a pleasure. Thanks for having me.