Episode 67: Leading a Product Organization with Paul Adams
Melissa Perri welcomes Paul Adams, Chief Product Officer at Intercom, to this episode of the Product Thinking Podcast. At Intercom since the days when they only had only 13 employees, Paul has helped shape the Product department from the ground up. Paul joins Melissa to talk through his approach to product leadership, what his day to day is like as CPO and why he hasn’t been in a product review in years, how to build trust within your organization, and embracing the “messy middle” when it comes to product strategy.
Subscribe via your favorite platform:
Here are some key points you’ll hear Melissa and Paul talk about:
Paul talks about his introduction to the field of product management, and how he became the Chief Product Officer at Intercom. [1:55]
To have a successful product organization, three teams – product management, product design and research and data science – must work together harmoniously. [4:55]
Paul believes that the best way to oversee all the different groups within a product organization is by appointing a trustworthy leader to each group and allowing them to have autonomy over their decisions. [6:51]
Paul cautions that the downfall of most organizations is the lack of trust from team leaders. Paul suggests that the teams have open conversations about “Why are they here? What do they not trust?” in order to build trust in the team. [15:03]
When choosing a new team leader or product manager, you have to build a relationship with them so they can trust you and vice versa. [16:12]
For your organization to work in unison, the strategy must be clearly, concisely and accurately translated to the execution level, acknowledging the ever-changing trends. [ 20:25]
When the company is reviewing the strategy in Google Docs, they urge employees to label their comments “major, minor or curious” in order of urgency. This creates a smooth running system that maintains discipline. [25:46]
The lines between the sales, support, marketing, product and project management need to be blurred. These teams should deeply collaborate in order to achieve collective success for the company. [27:50]
For a company like Intercom to work harmoniously, a feedback loop for each team should be set up, where the problems to be solved for each group are shared so that the service can run as smoothly as possible. This only works if there is a strong relationship in the company. [34:05]
Paul believes that surveys would be most beneficial to project managers as they collect and track first party data, which allows them to send targeted ads/messages. [38:31]
Resources
Paul Adams on LinkedIn | Twitter
Transcript:
Melissa:
Hello, and welcome to another episode of a product thinking podcast. Today we're joined by Paul Adams, who is the chief product officer of Intercom. Welcome Paul.
Paul:
Thanks melissa. Nice to be here.
Melissa:
So Intercom is definitely one of, I feel like the darling products that we all love as product managers, it helps us do our job better. Uh how'd you end up at Intercom and you know, what was your experience before there? Where'd you work?
Paul:
Yeah. Uh, so I was at Facebook before Intercom, uh, working in the, uh, work actually in the marketing or technically when I left Facebook, but I started in the design team, like the UX team and made my way over to product management of Facebook. Uh, before that I was at Google in the UX team at Google, uh, before that I was in UX consultancy. So my background is mostly in the kinda UX world design research. And, uh, I found my over to product management along the way.
Melissa:
I feel like a lot of us did that too. I was also a hybrid UX designer, product manager. And I didn't know, there was a difference for a very long time yeah. And somebody was like, oh, this isn't your job anymore. And I was very upset about that.
Paul:
Yeah. Yeah. It's funny. It's funny. Actually, when I, when I, um, I was on Facebook and I was very, very happy there, honestly. And, uh, I knew two of the founders of Intercom Owen and, and, uh, they, uh, I basically started helping them out and one thing to another and they were like, Hey, why don't you just come join? But when I originally joined the job wasn't, um, product management, even though I'd done that with Facebook, it was, uh, to kind of to over from Owen and Des to like design the product and in the very, very early days, uh, we believed that we could do it without product managers and the designers were gonna be, uh, the product managers. We're gonna have this hybrid role. And it'll be like, you know, this next gen cutting edge discipline. But, uh, that didn't work out. That probably lasted like six months. And then it's time to hire PMs.
Melissa:
That's so funny too, because we like, think of Intercom like between you and Des you're at all the product conferences, you guys are really like promoting product management out there. But I love that we started with, uh, we don't need these people.
Paul:
Yeah. I guess it was less, we don't need the people. It was more like we thought we had this new hybrid role, uh, you know, PM and design together. Like one person could do both was the, and I guess like in the early start of days, you, we were like, um, 14 people in the company and it actually did kind of work, you know, for a while. That's kind of what Dell did, honestly, before I joined you was like PM and UX together, business strategy, the whole thing, marketing all wrapped up in one. And so, um, it kind of works when you're tiny, but obviously once you have any sort of scale, you need to like break it out.
Melissa:
Yeah. That was kind of my experience too. When we were really tiny, I did both. And then we had to, we had to keep, you know, keep the company moving. So I couldn't do it all at the end of the day, but that's, that's really interesting. So you were there at the early days of Intercom, you know, what did it look like when you walked in and, and where are you at now?
Paul:
Yeah, uh, they're like worlds apart, like different planets. Um, when we, when I joined, like I said, I was 14 people. And so here in Dublin where I'm still based, the team here, uh, was 10 people and we're just all in one room. And it was, um, myself Des uh, Dar who's my peer in engineering who runs around org, who still, uh, runs it. And still my peer we've been together all this time. And, uh, it was just like one big room. And we're kind of like all in it together in a kind of classic startup mode, you know, fighting for survival, fighting for usage, trying to understand if we product market fit, all, all the classic things. Uh, today, if you fast forward to today, it's rapidly, rapidly change over the years. We've nearly a thousand people now, you know, with five offices around the world, uh, the product org is nearly a hundred people. So we're, uh, at a completely different scale.
Melissa:
Yeah. A hundred people. That's a huge difference and a pretty good size product org. So what does your product organization look like now? What kind of role you have? What do people do? How are you organizing them?
Paul:
Yeah, so there's, there's, uh, the simplest way is think about it's three functions, we've product management, product design, and what we call rad, which is research and data science. And, uh, they're the three like sub teams within the product org. They work very closely together and we worked very closely with engineering. And so in the early days, I remember when Dar and I first got to work together, you know, we kind of said we were gonna succeed or fail together. And that was like a big lesson I had in my career, the successful, uh, product teams I'd seen at Facebook and Google were like in it together, they didn't really care what disciplines was doing. It was just like, Hey, we're here together as a team. And to build a thing for, for people and make it better and, you know, improve their lives in some way.
And, uh, the other ones were like, you know, all caught up in like, who's, who's doing what and what role and all this kind of stuff. And so Darren and I were said, Hey, we're gonna succeed or fail together. And we still still think that honestly, uh, all these years later, uh, but we instill that in the teams too. So as we grew, uh, you know, we, we, we first went from that amorphous blob of people to like four product teams. We hired like four PMs, four designers, uh, and then those four engineering managers and they form a triad and that triad, uh, we basically think about that triad as like their first team. So, you know, they're, that's the people that they, uh, talk to all day, wake up thinking about and go to sleep thinking about probably too much. Uh, and it's worked really well for us, honestly, you know, the, the triads, uh, have a lot of autonomy. Um, we set a high level strategy and they have a lot of autonomy to execute it and it's, it's scaled really well.
Melissa:
That's awesome. So one question I get from a lot of new chief product officers is how do I think about, you know, standing up functions or different divisions underneath the product org or overseeing those people when I haven't had experience in that role. So, you know, whether they haven't been a designer, I know you've been a designer before, but, you know, overseeing data science, overseeing the research functions. Um, how did you think about bringing that under your purview and having everybody work together and what have you learned about actually running those teams that are not just product?
Paul:
Yeah. Uh, for me, it's kind of been a blessing in a curse because I'm a, a Jack of all trades master of none is maybe one way to think about it. Uh, in that I worked as a designer for a few years. I worked as a researcher for a few years. Uh, I, at Facebook, I was a PM for a while for like a while there, uh, most of my time there, um, at Intercom, I kind of started off doing PM and design and research opt in one. And, and so for me, I've been lucky in that. Um, I can, I've done the job. So like, as we hire designers, hired PMs and then even hired managers for those disciplines, I've done the jobs. I, I understand what they, they need to do. That's a curse too, because, you know, it's hard to extract yourself away when you think you can help.
And so like getting out the details and the weeds took me a few years to master. I dunno if I've still mastered it, dunno, dunno if anyone does, but I I'm better at it. Um, but data science for example, is an area where I, I was very weak. I, you know, uh, didn't know much at all. And, uh, what I to do over the years, uh, I did take years to get this right. Was hire a leadership team below me that I just, you know, fully trust and we're in it together. Uh, and that's where we are today. Like I have, uh, directors and senior directors and VPs who report to me who run these orgs and run them very independently. And so, um, the, I, I think the biggest, uh, or the, the biggest kind of thing I would say to people who find themselves in that position is that they need to find a leader who reports to them to run the function or run the area that they, that they trust and, and can empower to, you know, take it on themselves and then use them as, as a guide and a manager and a mentor. Uh, but then don't need the domain feedback. Like, they're all they're already there.
Melissa:
So if you were weaker in data science and you had to hire somebody to lead that what you do to get up to speed, to make sure that you got the right person in there,
Paul:
Um, in yeah, in the early days, uh, I, I, I got it wrong probably is probably the best way to describe it, you know? Um, I didn't really know. Uh, but I, but I, I was kind of aware enough to know, to know, like, I didn't know what I didn't know or sorry. I knew what I didn't know. Uh, and so, um, in the, you know, and the org changed honestly, O over time at intercom we've gone through like different phases. Like at one stage we had, uh, um, product analytics, uh, which was, was what data sites call back then in the product org, or is it actually an R and D and it reported to engineering at one stage, then it got centralized in the company. And so the, the, the data science and analytics functions centralized. So it was like a service to all the different orgs of finance and product and engineering and so on.
And then, and then we broke it up again. So now, uh, product analytics and data sciences back in my org, um, uh, and you know, I, what I did was lean on my peers, like other execs, for example, or like other leaders across the company to help me like, find the right people, interview people. Uh, I, I leaned a lot on other people in the company who did have domain expertise and, you know, people who, who knew what I was looking for maybe had worked at me for a bit and tried to find that kind of like nice, uh, overlap in, they understood the role of what we need, but understood the domain better than I did.
Melissa:
Yeah. I think that's really good advice for people like step back and let, let some experts in to help you, um, help you figure out what you need. So if you've got this great team underneath you or are running all these different domains, uh, what have you found your job has transitioned to now as a chief product officer? Like what's your day to day? Like, what are you responsible for versus what you delegate down to your leaders?
Paul:
Yeah. Uh, I delegate a lot, um, almost everything , uh, and I'm still busy every day. So, uh, I was still working on that one. Um, I think from the early days, like Dar and I, um, believed in given our teams a lot of autonomy. And, and so, and this has changed over the years. So in the beginning, it was just like myself and Dar were teams reporting to us directly. And then it became like we hired in managers and leaders to lead those teams. Then we formed into groups. And so the, you know, once we got to a certain scale, we had to like group the teams into different areas. So we have our engage product, our support product, and they were split into two. They had a leader, you know, for different functions and then they reported to Dar and I, and then we've scaled again.
So now we kind of have like multi theirs, but at every step of the way, uh, we've tried to a set strategy, was what, you know, we saw our job as, as basically setting the strategy and building the team. And, and I think that's still, basically our job, like set the strategy. Uh, these days it's a cross functional strategy. And I work a lot with our CMO, Anna and our chief revenue officer, uh, with Des to, and, and so I'm working like very horizontally across the company. And I'm, my head is often in other orgs as much as it is in my own org. Um, but we try to set it up over the years so that people have a lot of autonomy. Uh, and then we would hope they give their teams a lot of autonomy. And so our job is setting strategy and then try to make sure things are on track.
Uh, the one thing often when I talk to other product leaders, you know, I'll often chat to different people who are CPOs or like on the journey there. And one thing. So I'm never in product reviews. I haven't been in a product review in years, uh, where I like we're looking at the product we're building and like critiquing it and giving feedback. I've not been one of those for honestly years. And when people hear that they're like amazed and surprised. They're like, oh my God, how like, you're this product leader? Why are you not like in the product meetings? And I'm like, like that just does not scale, you know? And it doesn't work and it's disempowering. Uh, and yes, I, I could help people and sometimes they'll pull me in and say, Hey, Paul, what do you think of this? Like, or oftentimes it's like, if we're, they have a dilemma they're stuck, there's a trade off, they're vacant and they're not quite sure. Um, or I can share contacts from contacts, from our exec team. Like I might know more what's going on in the other parts of the business, but for the most part, um, they do it and they do an extremely good job. And, and so I don't need to be, uh, down there and I'd encourage all people who are leading product teams, not to be down there cause it's fun down there, but it's not actually your job.
Melissa:
Yeah, that's so true. I, I find so many new product, uh, leaders just get way too in the weeds. They're Iike I wanna know every little feature you're putting out every little story you write and then they don't have time to set the strategy. And the things that you're talking about, I'm curious. So this is kind of a flip question too, right? This is all really good advice for chief product officers. Um, on the other side, I hear a lot of product managers who are like, my leaders are in the weeds. And sometimes I find that it, because they're not doing a good job communicating up to the chief product officer or like getting ahead of the questions or showing their work or diving into that. So, you know, as a chief product officer, you've got this massive team of a hundred people below you, right. What types of information do you wanna know if you're not, you don't care about the product reviews as much? Like what should people be bringing to you to get your feedback or show you that everybody's on track? What do you look for?
Paul:
Yeah. Um, it's an interesting question. As you started asking the question and it actually reminded me of a couple of things that I think are important context to try to answer the question. So one is that when I, when I was joining in, uh, Intercom or thinking about joining into com, I was actually still on the fence cause I, yeah, I worked in Facebook at like 2010, I dunno, like more the golden year maybe than like it's much bigger giant global corporation today. Uh, so it was a very different place. Like I think Facebook, when was here was like maybe a few, couple of thousand employees. It was actually quite small, but, um, I remember, uh, you know, Owen and as we were sitting down, uh, having a drink, we were chatting about whether I's gotta join. And so on Owen said to me, um, Hey look, the, the pitch, you know, the best pitch I could make to you is, um, yes, you can design the product at Intercom and you can design the product anywhere you go, but here you can design the company.
And that really struck me because, uh, I had worked in a lot of teams, uh, especially, you know, at Google at the time. Uh, you know, my experience was one where there was a lot of leaders in the weeds. Like it was a daily occurrence. Like all the leaders, multiple levels of leaders would be in the weeds and it wasn't helping things. It was slow, slowing people down. It was confusing. Sometimes leaders didn't even agree with each other, you have some kind of product review and one VP disagrees with another VP and then they leave the room and you're all like, what are we supposed to do with that? Um, so, so I, you know, we kind of designed Intercom to, to, to like, again, be the company that I would've liked to work in and do, did want to work in. So, so I don't think we had that problem, um, on mass now, the, the, what, what has happened though, and has happened many times over is that there are leaders in the weeds and usually what's going on there is that they don't trust what's going on.
And so, uh, trust is a thing that come up here and something that I've talked to people about many times over the years and different people have different perceptions on, or like different kind of, you know, ideas of trust for me, like trust is earned. I deeply believe that trust is earned. Uh, other people don't, they believe that you should implicitly trust and then see what happens, uh, in my experience, uh, better for worse for me, trust is earned. And so, you know, when someone new joins, for example, a new leader will onboard them as best we can and then slowly but surely they'll find their feet. And then off they go. And so typically when I see leaders in, in Intercom or in other companies in the weeds, it's because they don't trust something. Uh, and I think the first thing that, that like the teams, the teams themselves doing the work need to figure out is why, why are they here?
Who, you know, what do they not trust? Do they not trust us, the team, the people, the someone's role, or is it that they don't trust, uh, something else? Um, you know, and so I think the conversation that people need to have, which is hard, cause it requires a lot of vulnerability is to ask, you know, you know, why are you here? Or like, why is there like multiple levels of management involved? Um, and, and I think that's the only way to start to open up a conversation that can progress to, okay, like let's build a relationship and then I'll give you all the space and time you need, uh, to execute the strategy and we'll be checking in and we'll see how it goes. And if it goes well, you won't see me unless you want to. And if not, well, we'll have to have a harder conversation.
Melissa:
So when you are onboarding a new product manager or a new leader, right. And trying to earn that trust, what are some signs that, you know, they're on the right path for you, right? Like what are they doing? What are they acting with so that you go, okay. I, I think we're, we're starting to build that bond. Right? Like what, what do you recommend people do basically?
Paul:
Yeah, I think, uh, for me like the, the biggest thing that probably the most important thing is to build the relationships around them. Uh, and so, you know, a mistake I've seen many people make, uh, and I've made it at different times in my career, not an Intercom, but I certainly made this mistake at Google many times over, uh, I thought, I thought that people would trust me if I was smart. If I was like saying smart things and like, oh wow, Paul really knows about research or wow. Paul really knows about social software. We should listen to him, you know? And oftentimes I'd do that in a way that like at times was antagonistic, you know, borderline like, like really big debates. And the Google was a environment where people love big intellectual debates and I kinda like fell into that and got into it.
And, uh, and I don't think that really works. You, you know, like, cuz that's not, that's not a kind of trust based relationship. And so the first thing that the is the relationship with their peers, uh, and especially if they're in that triad of like PM design and engineering, uh, for me like the, the, when that triad works really well, uh, the team just thrive. You know, they, they know what they're doing. They feel like they're in it together. It's easier to like, uh, it's easier to work on, um, you know, trade offs and like make decisions faster. It's easier to like delegate to one another. Like if one person goes on holidays, or vacation. They don't wait till they come back. They're like, Hey look, pause off. We're not gonna wait for him to come back from holidays till I talk about the decision.
We're just gonna, we're gonna make this call and go with it. Cause we know he'll be fine. And he'll, we'll talk about it when he gets back. And, and it's because they have that relationship. And so I think for the, the early signs for me are that the relationship is good. The relationship's working and people are, uh, being openminded and, um, investing the time to get to know one another and get to know the space. And they're not coming in with like all their new ideas. Uh, and by the way, all the new ideas are, are fantastic a little bit later. Uh, but first it's kind of like, Hey, understand the company underst and then just get to know each other and build those relationships because you're gonna need that when the harder stuff comes around. Uh, so that's kind of what I've seen to work.
Melissa:
Yeah. That's really well said. I I've been in similar situations too. When you talk about how you failed with it, I I've also gone in there and been like, well they hired me as a product manager. So they should just trust me to do the work. And that is not true. , it's just not how things get done anywhere in the world. So, um, I think that's fantastic advice for anybody who's trying to consider product or even be a product leader, um, across the board. Yeah. So we talked about, you know, when you have trust, we, you to go execute on the strategy, how do you communicate the strategy to your team, right? Like what are you putting together? What's the right level of direction that you've been giving people. And do you have a process at Intercom for like setting the strategy, deploying it, monitoring all that stuff? Cause in my experience, I come into these organizations, they go, oh, I want autonomous teams. I wanna like let all my product managers go execute, but they give them no direction whatsoever. Or they give them too much direction and it pigeonholes them into a product. So I'm really curious how, you know, as you've been building, building this team, what you found works for actually deploying strategy like that.
Paul:
Yeah. Um, you know, honestly, you know, like right across my career, I've worked in, um, honestly some of the most dysfunctional product teams and products you've ever seen, uh, uh, you know, some of Google's biggest failures. I was on that, all those teams, uh, but I was also lucky enough to join, uh, other teams in Google, for example, that were highly performant. They were like, like Google maps, um, Gmail at the time, you know, parts of YouTube, they were like phenomenally good. And in all cases, uh, some I'm kind of lucky enough to have seen both sides of both extremes in all cases, the strategy side was messy, just messy. And I think the first thing people have to like appreciate is it's messy, it's messy. There's no, you know, we're all striving for like this beautiful world where the strategy is clear and concise and it cascades down.
Everyone's like, I know what I need to do. Like an off we go. Um, one of the challenges is that, you know, we all work in internet software. I'm guessing to some degree and the internet changes rapidly. It just, and it's changing. Like I think the rate of change is, is increasing so that there's more and more companies, more and more startups, more and more new things. Um, and your operating in a world where any kind of strategy, uh, that's like 12 months out, you know, 18 months out is, is gonna have to evolve within that timeframe. And we see this all the time with Intercom, you know, we're trying to set our strategy and I, and I think for the most part, we've a really strong strategy at the highest level. So like we know what we want to be. We know we, we need to do, uh, we do a pretty good job of communicating it down, but when you get into, and then at the execution level, I think we do phenomenally well, it's one of our strengths, you know, we've built this machine and this process, uh, it's all principles based.
So, you know, the process these days is relatively light versus what used to be, but we're very principle based organization. Um, it's the middle, that's messy. It's like the messy middle trying to translate the strategy, uh, down into the execution as it evolves. And as the world evolves and as things change, uh, all around us, like the shape of our customers change or business numbers change or whatever our competitors comes out with something that's really compelling. Like this is all moving around us. And so what we've tried to do, and you know, I don't think we do this necessarily brilliantly at times, um, is to just to try and keep everyone aligned. We use the word aligned and alignment a lot at Intercom. I'm sure people would laugh there. Talk about it here again. But we have diagrams and pictures showing like, like Dez is a picture that's like just a load, a, a big arrow made up of lows and arrows and then versions where the arrows are slightly misaligned.
It's like, Hey, we're trying to get all the arrows going in the same direction just generally. And then I have another one where I have like two lines up and down, up and down and like staying within the lines and staying within the strategy. And then as new people join, they get tow the strategy and they're on the kind of edge of the line and they, they understand the strategy, but then not only new person joins and they're onboarded by the first new person and the strategy drifts as it's communicated. And then it drift and drifts and drifts. And so strategy hasn't even changed. But the, but the understanding of it has because newer people told other new people what the strategy was. And that just is a, a, a byproduct of being a really fast growing company. So, um, at time, you know, we've done good and bad here at times.
Uh, but what we're, what we've tried to do is embrace the messy middle and say, look, this is just how, how it is. And, and actually in a key skill that I look for in people, uh, mostly because I've seen, uh, people with this trait do phenomenally well in their career, in, in product is that they kind of thrive in ambiguity, you know, and people who, uh, people who really struggle with ambiguity, uh, like Intercom's not for them, you know, you know, and other fast growing companies might not be for them. And they would thrive in like a more stable, slower moving bigger company, which by the way is a totally fine thing to do too. Like the teams I used to work on, like Gmail, I'm sure Gmail is a fairly stable, slow moving team these days in a good way, cuz they can't break the thing that's operating on such scale. Uh, but an Intercom for sure, like, um, thriving and ambiguity and being really comfortable with the idea that this thing is like 70% baked. And as we get it to like fully baked, it's gonna change again. You know that, I think that's a, a skill that people need to try and master.
Melissa:
Yeah. I try to tell my students that too, a lot of them are, are thinking about, do I wanna go startup or growth stage or really large company as a product manager? And I'd say like, if you, if you don't like mess and you do not like ambiguity, you really wanna go large company. This is just not gonna be for you especially early stage. Right. Like if you are the only product manager with the founder or anything like that, that's where it gets really ambiguous.
Paul:
Right? Yeah, absolutely.
Melissa:
So when you're, when you're deploying the strategy and communicating it too have you found, like what ways of communication have you found really work? I know you're talking about new people coming in. Other people relaying the strategy for them. Do you guys write memos? Do you have like town halls about it? Like what's what have you found work for communicating and explaining?
Paul:
Yeah, we we've honestly been on a bit of a journey here. Um, in, in the early days, early days being honestly the first eight years, uh, pre pandemic, uh, we were a face to face culture, uh, like deep, like really like locked into this idea. And uh, we set up the office for the very earliest days. Once we had teams, we set up the office so that there a bank of desks, which was the team and that's like the cross-functional team. So the PM designer, engineers, engineering manager, the researcher, like the data science, they're all sitting together in this one bank and our team sizes are, are, have stayed the same size more or less, which is like 1 PM, one designer, one em engineering manager and then roughly about five engineers. And then, uh, we don't have like backend front end engineers or we don't have a QA team either.
So like it's a kind of a full stack, uh, product engineer and they all sit together and the idea is like, they talk to each other like, Hey, the designer and the engineer should get over each other's shoulder and go like, Hey, how's that working as you're building it and so on. Um, but the key thing we did was alongside that bank of desks, there was a room called our team room and every single team had a bank of desks in a team room and in the team room was kind of where the magic happened. And like over the years we got bigger, you know, and our real estate became a thing like a cost that mattered. You know, we were often asked like, you really like, I walk past those rooms and they're empty. Like, do you really? And I'm like, well, they're, you know, yeah, the empty for half the day, but the other half or even third of the day is like, or the magic happens.
And so a lot of our culture was, or it was, um, passed on, you know, word of mouth, all hands. So we'd have big all hands and we'd share everything verbally. Um, and then the pandemic happened. And by the way, we also had Google docs. Like we do a lot of, we do a lot of writing and Google docs, uh, and then the pandemic happened and it still went sideways. Uh, and then we realized that actually teams are working great without all that stuff. Um, and so these days, uh, Google, we use Google docs. We use Google, the Google suite, uh, and Google docs is probably our most is the most, um, commonly used thing to share our strategy we're doing. Uh, and then we have a lot of collaboration of the doc. So we'll encourage people to get in the doc and comment, but we've, we've, we've designed a specific system over the years, which is, uh, before you, before every comment you have to label it as major, minor or curious, uh, and the idea there is like major means we need to talk like seriously, need to talk here.
This is, you know, major feedback minor is, um, Hey, I think we need to talk, but not now. So it's like, you know, major's like important and urgent, minor is like, you know, important, not urgent and curious is, Hey, I just, I'm curious, like, is I have a question what's going on? Like, you know, have you thought about X thought about why? And if we'd never get to curious comments, no big deal. Uh, and that's where phenomenally well for us, because it gave us discipline and gave people discipline that like, okay, we're in a meeting or we're gonna review this doc. We, we do a lot of, kind of pre-reads in a meeting. So we're like start a meeting. Okay. Here's a doc let's pre-read 10 minutes comment and let's spend the next whatever 50 minutes discussing the comments. But people have learned to be quite diligent in how they tag them, knowing that we're not gonna waste loads of time on something. That's like some rabbit hole that doesn't actually matter. Um, so these days, a lot of the, a lot of it is a lot of the strategy, almost all the strategy is in a Google doc. Uh, and we, and then we use other tools by the way, for other things like code has used heavily for operation, like operationalizing strategy. And then we'll use Google slides for like all hands and talks like that. But Google docs are the bread and butter.
Melissa:
Cool. I love Google docs too. It's just so flexible.
Paul:
Yeah, it helps.
Melissa:
A lot of, uh, so you've just grown this company over, you know, the past 10 now it's gonna be 11. I hear right. Uh, pretty soon years. Yeah. You've watched it all scale. Um, in the last decade, I also feel like product management has finally become a thing that we're all recognizing is, is important into companies. What have you observed, you know, especially building a product for product managers, right. And what have you observed change in product management over the last decade? And what do you think product managers need to know or get better at as they start looking at, you know, careers from now into the next decade? Like what's, what's different.
Paul:
Yeah. Uh, it's a great question because I do think things have changed substantially. Um, and I do think there are things, you know, for 2020s. I think one of the biggest patterns I've seen is, um, that the orgs orgs within companies are blurring. So I think like in, in the, you know, like the olden days, which is probably like last decade, uh, like sales and marketing, wouldn't talk to each other or like, you know, sales job marketing job give sales leads and then sales would do whatever they do. And then meanwhile, the product org is over here, not really talking to marketing or sales, they're doing their thing and engineering is doing their thing. And then support is like way over there. Not even talk to it's a cost center to manage and, uh, are, are like two huge lessons. Two of the biggest lessons in my career, honestly, over the last kind of decade, one is the orgs are blurring.
So I think the Internet's driving this and like tools like slack, for example, where orgs can just talk to each other. Uh, but the orgs are blurring and they're starting to have to collaborate more. And a lot of that is down to changing business models too. So the rise of subscription businesses on the internet and the idea that like the customer relationship matters and loyalty matters means that you've gotta care about your existing customers a lot more than you used to have to. And so a product org might also always have thought about that, but a sales org didn't really, you know, and marketing didn't really, but the now they have to. And so you see the rise of like growth teams, success teams, uh, that are like in, on the boundaries and in the middle of these bigger traditional orgs and the orgs are all blur together.
And, um, that matters tremendously because it means that the, the PM team in particular, uh, the product org generally, but the PM particular in particular needs to be in the middle of that. And so what, you know, when I hear of PM teams who don't talk to sales regularly, or don't talk to customer support regularly, or don't talk, I'm like you're missing, you're not missing a trick you're missing, like I dunno a huge component of, of insight and value. Um, and you just need to get out there and get talking to all of these orgs because, uh, they, um, you know, they need you and you need them much more than you realize. And so that, that the kind of orgs blurring and we've built the whole integral product around the site idea that the orgs are blurring. Uh, and so when we look at, like, for example, Intercom is, is designed and built for like sales, marketing and support teams.
If you, on a website, you'll see sales, marketing, and support as our kind of primary customer, and yet product teams use Intercom, heavily growth teams do success teams do. And it's all, cuz these orgs are like blurring together and need to work and collaborate and far more than they used to. So that's, that's one thing. And you know, I, I remember in years gone by, I was a bit like I wouldn't describe myself as a shy person, but like I, I just didn't wanna go talk to people over there, you know? Um, and I forced myself to and realized, well I've spent years just blind, you know? So I was like the, org together is one massive thing. Uh, the other thing which is kind of connected is, um, the people who who know most about your customer or user, uh, is typically not the product org, it's typically the sales team or the support team.
And, and this was like a huge, especially for the U like I gave a talk at, um, I think it was UX London a few years ago and you know, my main message there was, Hey, the designer and the design, the UX team says like we are the custodian of the user. Like we are the central place of insight on our customer. We know the customer better than anyone. And it's like, you don't, you don't the sales team do cuz they talk to them day in, day out and they hear all the, and all the, you know, noise and all the pain and your support team similarly here, all like, and, and so they're actually the, the teams and people that you need to be learning from, uh, as much as learning from customers and each other. Uh, and so the, the, the, I think the PM role, um, is, uh, is a, needs to be way more collaborative and like, I mean actually deeply collaborative than it might have had to have been in the past.
Um, and, and I think, you know, there, there's obviously like people have all these debates on Twitter about product owner versus product manager, which, oh, I hate that and like what, like why you waste and your energy on such like rubbish, but, um, like what are you, you're either a product builder, like a manager of the product or you're not. And if you are, you need to be talking to all of these people in all of these other orgs in your company, uh, because you'll just be a way better. One thing we talk about a lot about I intercom is judgment and conviction. We want people to build judgment and then have conviction, which actually is related to the trust thing earlier. Um, you know, when I kind of sense out that people don't have conviction in what they're saying to me that like erodes tr I'm like, well, wait a minute, wait a minute. Like we gotta, I need to dig in now cuz I'm not sure you believe what you're saying. And if you don't believe what you're saying, I need to help you get to a place where you do believe what you're saying. And so, um, uh, so judgment and conviction are really important, I think, to the product role. Uh, and you can build it really fast by getting in these other orgs and talk, welcome to the people you learn so much so fast. You just get much better at making decisions.
Melissa:
I love that. I feel like this is a, a hill I've been dying on recently. oh yeah. Um, I, I, you know, I was just tweeting something out the other day. Cause I, I was having, um, one of our, our CPO experience CPOs or a mentor for CPO accelerator and they were telling people like, um, he, it was Oji, um, he was the chief product officer at calendly and now he's at Twitter doing VP of, uh, conversations over everything about tweeting. Uh, and he said, you know, one of the things that he's switching back to is trying to get research out of B2C customers now instead of B2B. Yeah. Uh, and he said, B2B is kind of, you get to go to the sales team, you talk to the account team. I had a great relationship with them. I learned all of this stuff and I tweeted about it because I've heard so many B2B product managers complaining that, oh, there's no way you can do user research in a B2B company.
And I was like, you've got customers right there. Like you've got, you've got teams that talk to customers. And then they go after the account managers and the sales people and say like, well, they just come over and wanna make a sale. So I'm, I'm curious like how, when, you know, to me, I think chief product officers can solve a lot of this, but I'm, I'm curious if you've had that friction with the account team or the sales team, when it comes to being able to do research with them. Uh, what would you recommend for these product managers who are, you know, feeling like they can't just go work with sales, can't just work with account executives and they're kind of blocking them from talking to customers.
Paul:
Yeah, it's a great point, honestly, because, uh, you know, here at Intercom, we don't have that culture and environment and, and, and because we've cur like curated a, a very specific culture and environment, um, uh, but I can appreciate other companies don't have that. So like here, for example, the relationship to myself and Liandra, who's our chief revenue officer and runs our sales and support team is really important because you, you know, we need to, like, we're kind like again in it together that we'll kind of succeed or fail together as an exec team in the company. And then we try and like, you know, bring that down where it's for, like my directors and her directors, you know, again, we're trying to collaborate, build much deeper collaborative relationships, um, the way, the way that we've done our Intercom, uh, which is a half an answer to your question, I'll try and answer property in sec is we've up, uh, a, basically a kind of a awesome feedback loop.
And again, it took us a few years to kind of try and refine this, but the way it works is, um, our sales team put all of their feedback in Salesforce and tag it. And we like a very kind of specific tagging system like, Hey, this is an in, this is like about the inbox and it's about this thing. And then, okay. Then the PM for like that part of the inbox can look up Salesforce and see all the tags and see all the, say all the feedback from the sales team. So we're like consistently trying to tell the sales team, add the feedback, add the feedback, high quality feedback. And what we do is we've built a system that ranks all of the content that goes in, uh, and then we build lists build like top 10 lists basically. And then, we call this problems to be solved and we've, uh, and the sales team like PTSB and the, and the sales team say problems to be solved all the time.
Like, Hey, I put that in the problems to be solved, you know? So it goes into Salesforce and then, and the support team, by the way, do this in Intercom. So they do exact same thing in, in Intercom. They tied the conversation in Intercom. They obviously use Intercom as our support tool exact, and then we can build a list. And so we have like our support top 10, our sales, top 10, and this is like a massive input into our roadmap. And then we obsess about shipping and shipping a lot fast. And, uh, and, and one of the reasons is because we have this virtuous, uh, like feedback loop where the sales team see like literally weeks after, oh, there's the thing. Awesome. I'm gonna go back to my customers and tell them that the thing I tell I is here, it's hit shipped.
And, uh, and so this's like was a work in progress and we can us get better at it. And the quality of the feedback we get from sales, you know, can be a very different types in, in terms of quality. Uh, but they know because we've just told them over and over again, if you tell us about it and it's real, and we can validate it, we'll build it. Like we wanna build what our customers need. Um, and like, we'll do our due diligence to try and understand the problem, make sure that the sales team's representation of it is accurate and all sorts of things like that. Um, but that's how we do it. And so, um, in, in a world where the sales team like that you're not set up in that environment. I think you need to start building bridges between and building connections so that the sales team can see, Hey, Hey, if I talk to you, it helps me, uh, you know, and it can start simple, like get on customer calls with them.
Uh, customers in B2B customers love talking to the product team, love it. And they don't love talking to the sales team. So if, you know, a salesperson is always saying, Hey, PM, get on the call with me, get on the call with me purely because it's gonna make them look good. And the customer's like, delighted that the PM is there. And so there's like lots of ways in like that simple ways to build again, build relationships, build trust, and then say, Hey, get your feedback to me in a structured way. And I will build, I'll build the stuff for you. And like, we're all win. Um, and so I think just the relationships need to be kind of built, uh, and they can be built from the ground up. And then if you're a leader, uh, I'd encourage people to do the same thing at the leadership level and, and try and build this like nice virtuous kind of feedback loop.
Melissa:
I think that's great advice for everyone. And, you know, the moral of the story I heard from you the whole way through this too, is just build those relationships, right. Start working together. And I I've seen this too. It's like be one team don't be sales and products. Like be Intercom, be the company we're all here for the same reason.
Paul:
Yeah. There's actually, um, I'll give you like the flip side. I, I, I believe like every strength has a shadow and like to do, you know, to be fair to our here listeners, uh, and, and not say this is like a perfect world. Like every strength is a shadow. And so at Intercom, I think, uh, because we've invested so much in, in, in this culture of collaboration and like true honest collaboration and this idea that like, Hey, we're in it together, we'll succeed or fail to together. Um, the, the shadow is that you can get, um, designed by committee. Uh, you can get, uh, procrastination, you know, it's like, and you can get, like, people are very kind. So people will say, Hey, people need to come very kind and nice to each other. And I would say there's sometimes too nice, you know? And so it's like, Hey, we just need to get on with things and make a decision here. And like, we can't, everyone can't get an opinion all the time. Um, so there is a shadow there, and, you know, I wanna say that to give this conversation the balance it needs. Uh, but there's that, that's exactly it, the balance. Uh, and if you have the relationships, it's also then easier to say, Hey, thanks for your opinion. I'm there choosing to ignore it and make this decision. And we'll still be friends five minutes later, you know?
Melissa:
Yeah. And at the end of the day, too, it is the product manager's decision. Whether or not those things go on the roadmap or you build it, it's not just take everything that comes your way and go, right. It's make a decision about what's best for our goals and our company and our customers.
Paul:
Yeah. Yeah, exactly.
Melissa:
So thank you so much for being on the podcast, Paul. Uh, so tell us about, a little bit about what's next for intercom. Um, you just released a new product, where can we go find out more about it?
Paul:
Yeah. Uh, so we, uh, had one of our biggest launches in years, uh, a few weeks ago, uh, we launched a brand new inbox. Uh, we launched a new product called switch and we, we, uh, released a new product called surveys. And, uh, the surveys product actually is, uh, I think, a great for PMs. Uh, one of the things actually I didn't get to talk about today in much detail was, um, first party data. Uh, and so like actually a big trend. You asked me earlier about trends for the next kind of decade. A big trend is the disappearance of cookies and people go, oh yeah, cookies are going away. I heard that Crow are going out of cookies anymore. As of 20, 24 20, something like that. It's like, no, it's real, it's actually happening. And so you would not have access to all the, not all lows of the data that you have today will just disappear in the blink of an eye.
And so, um, we've been saying you need to build first party data, which is data collected from your customers and users directly with their permission and survey. We've built a survey product, and it's a great way to do that. Actually, you know, we're using surveys, um, and it's connected into all of the customer record and Intercom. And so, uh, people are collecting first party data and then using it to like send targeted messages and try our support and all sorts of that. Um, so that's actually a huge trend I forgot to mention earlier. Uh, and that's also connected to what we're doing next. Uh, we're thinking about this theme of first party data. Uh, and other than that, uh, we're kind of continuing to build the product. Um, you know, we're building next generation versions of a lot of what we do our messenger, uh, with a new version coming, um, in that messaging with a brand new inbox. Uh, and so, yeah, lots, lots going on.
Melissa:
Great. That sounds like so much fun. And I can't wait to go check out all the new stuff that you guys are building. Yeah. Thanks. Well, thanks again for being on the podcast. Um, if people wanna learn more about you, where can they reach out to you or follow you?
Paul:
Yeah, the best place is on Twitter. Uh, my, my, uh, Twitter username is, at padday, which is basically paddy, but an extra a it's P a D D a Y. Uh, I've. I used to be very active there. I'm less active these days, but I love hearing from people and love hearing people's questions. And anytime they mention me, uh, with questions, I always try and respond properly. So I'd love to hear from people.
Melissa:
Yeah. I had to keep remembering that your name is Paul and not Paddy.
Paul:
I know all my friends actually call me Patty I, everybody
Melissa:
By their Twitter handles .
Paul:
Yeah. Yeah. I, all my friends call me Patty. So it's, it can be quite confusing in my own personal life, to be honest.
Melissa:
That's awesome. Well, thank you so much again for being on and thank you for listening to the thinking podcast. If you like this episode, please remember to subscribe so that you get a new episode every Wednesday.