Lessons in product management with Intercom's Colin Bentley and Brian Donohue

Jump three-plus years forward to today, and we’ve more than 300 team members, 17,000 customers and 100,000 monthly active users. Meanwhile, Colin and Brian are now group product managers, who have been instrumental in shaping everything from our Platform and Messenger to our full suite of products (Engage, Educate and Resolve).

In my chat with Colin and Brian, we reflect on what’s changed in product management during their journey, what has and hasn’t gone to plan, how they’ve managed to stay close to customers while rising up the management ranks, learning to work with marketing, and much more. If you like what you hear check out more episodes of our podcast. You can subscribe on iTunes or grab the RSS feed.

What follows is a lightly edited transcript of the interview, but if you’re short on time, here are five key takeaways:

1. One of the biggest challenges at scale for a PM is maintaining a connection to customers. You’ll get more and more user reports and research studies, and must avoid overemphasizing second-hand feedback.
2. Any PM will be enthusiastic to share what features are coming down the line, but it’s a temptation you must learn to resist. You won’t actually know if your solution solves a user’s problem until it’s released.
3. Scope is a major challenge, particularly as you scale. Find the smallest definition of your idea, get it into your customers’ hands and learn from it.
4. There’s no such thing as a successful product without users, and that’s where marketing comes in. Scope a product down, but be weary of removing features that are part of your product’s core marketing story.
5. Brian and Colin are both strong advocates of the 6-week product development cycle. Why? It couples low-effort planning with realistic expectations and full team buy-in.

Des Traynor: Today I’m joined by Colin Bentley and Brian Donohue, two of our group product managers. Can you each explain what you do at Intercom?

Colin Bentley: I look after two main areas of Intercom. First the Engage product, which is all about messaging customers – from one-to-one messaging right up to full newsletters you’re sending to thousands of people. I’ve also recently taken over our free product, which is primarily about the users you have inside your customer base and also looks after some of the more horizontal parts of the application, such as settings, navigations, etc.

Brian Donohue: I’m the group PM for our support products. One is Educate, which is our product for helping customers help themselves and actually just launched in December – it’s been really fun to work on a product in its infancy. The other is Resolve, which is our help desk. It’s been exciting to work on that recently because we’ve really doubled-down on that product over the past few months. Prior to that, I spent a lot of my time working on the Messenger, so that’s where my headspace had been for a while.

The evolution of product management at scale

Des: You’re some of the earliest hires – we were 20-30 people when you both joined. Today, we’re more than 300 people, and we’ve gone from hundreds of customers when you joined to 17,000. What’s changed?

Colin: This is an obvious answer but I feel like the biggest thing is the structure and the rigor that we apply to how we run the product development process. When you’re unsure what stage any product is at and you’re taking on different projects in lots of different ways, the amount that you have to hold in your head any one time is huge. By getting a common way the projects are run and knowing roughly where those projects are at allows you to shed a whole bunch of complexity in your head at one time. Everyone has this shared understanding that if something is at a single point in time or a certain phase, you don’t need to explain anything else, because that context is there.

Brian: Colin and I started close to the same time, and we actually collaborated very infrequently over the first couple of years because we were so independently focused on our parts of the product. That wasn’t a good thing. Recently we have actually gotten to collaborate a lot more on process. You can’t simultaneously be thinking strategically and executionally, but yet we actually asked that of ourselves. There’s this constant melding of the two things and that’s really hard to do. We’ve gotten way better at that part of it, particularly recently.

Don’t stay on top of customer feedback and you can easily over-emphasize requests you’ve heard recently or frequently.

The other thing is the scale of the feedback that you get. The number of customers that you impact is way different. Trying to stay on top of feedback feels like an impossible challenge. So that’s something that we’ve had to work at – how do you stay close to your customers? Particularly as a PM, you really want to feel you’re tight with your customers and you really understand what their perspective is. You need to feel like you’re at the coalface of your product, and the natural extension as you scale is you just drift further and further away from that coalface.

Des: We have 100,000 monthly active users. That number was probably in the single thousands when you started. Say you want to change something in the inbox, which is like the core part of the Resolve product. Do you think, “Oh my God, there’s 100,000 people who use this thing every day for their job and I’m about to move it”?

The challenge of scale is being able to keep some sort of connection with customers.

Brian: I think it’s actually the inverse. We were almost more sensitive to the change earlier because you’re closer to it, where now it can be a little more abstracted, and that abstract is a risk. As the numbers go up, your brain just doesn’t adjust to it well. It’s 50,000, it’s 100,000, it’s a million. What’s the difference really? It’s just a huge number.

Des: You get feedback in the form of user reports and research studies at this point, not individual users.

Brian: That’s true and that’s also a risk if you just rely on that second-hand feedback. The challenge of scale is being able to keep some sort of connection with customers. It’s obviously going to be a small percentage, and that’s where a lot of your conviction can come from. You have to watch the user studies, you have to talk to customers, you have to feel their pain, and that’s where you get to make all the connections. If you’re relying exclusively on reports then it’s harder to actually get that conviction.

Learning from past mistakes

Des: As we’ve added more structure, we potentially got more process and probably shoot ourselves in the foot less. What are some of the more epic ways in which things haven’t gone to plan?

Colin: There are a few skeletons in our closet. When you have a smaller team, you can tend to yo-yo too much towards certain initiatives. So this month is all about fixing x, next month is all about fixing y, and the truth is probably somewhere in between. With a small team you tend to put a lot of resources one way or the other. For example, Project Awesome was an interesting experience where we felt the quality of our product wasn’t up to scratch and we took a 2-3 month period where we buttoned down and just worked on quality.

As a PM you should acutely feel the pain of saying no.

Brian: One of the funnier screw-ups I had, as PM on the Messenger team, was when I wrote a message for feedback in-app and the message was, “hey, I see you’ve been using this feature recently, I just wanted to hear more about how you’re using it and how well it’s working for you.” Our messenger had truncation, so it only showed the first few words of the message. Our customers saw this message with my face on it that said, “I see you…” and needless to say, that unsettled them a little bit. I had to tell Colin, “We’ve got to build that message preview for Engage.”

My first blog post for Intercom was about the demise of live chat and how it’s all moving to messengers and messaging that can transition between real time and asynchronous. We knew we were fighting against the model of live chat that was in customer’s heads, but even years later, we’re still building product to deliver on that promise. I very much feel the pain of when we’ve had to say no to continuing to build on that.

Video is another example of something that we half built. We actually talked about it at one of our Inside Intercom events and got it released to beta customers and then we had to push it off the table. We brought it back on, then we had to push it off the table again, and all of this was because we just wanted to prioritize other things. As a PM you should acutely feel the pain of saying no. If it doesn’t hurt to say no, then you’re probably not doing something right. Those are two examples where saying no to those products really makes your stomach tighten.

Des: There are also examples of the asymmetry between saying we’re going to do something and actually getting it done. I was at a user conference for a popular enterprise public software company, valued about $4.6 billion dollars. They announced in 2015 the most fancy live editing, multi-player collaboration, really cool stuff. They got a standing ovation at their conference from all their users who were like genuinely blown away by what was going to change their lives, and it was one of those products people use as part of their actual daily workflow. That stuff still hasn’t shipped and that’s despite seeing a beautiful demo. There is a real danger when you talk about something so long you almost cash in on all the reward except for you still haven’t done the work yet. It’s like telling your friends you’re going to do a marathon and everyone’s congratulating you. You’ve got four-fifths of the joy of doing the marathon already and you haven’t set a foot in your shoes.

Colin: The marathon is an interesting example in that in some ways when you’re trying to really tackle an idea, that’s the formulation of the thing that you’re building, and yet you don’t actually know if that’s going to solve it until it’s out in the world – almost after you’ve told everyone. So you’re committing yourself to actually doing it by telling your friends, “I’m in for the long haul.” The short things that you build initially that you think might solve the problem turn out not to and you’ve got 20 more miles to run.

Brian: It’s a human tendency to want to tell people about what’s coming. Sometimes you can say it’s deceptive, but it’s actually very human to say, “Look, we’ve got more stuff coming, I know it’s going to make you happy when you get this.” You actually have to resist that temptation because it’s so uncertain what you’re going to build, when you’re going to build it. Even when you’re half way through engineering, you can still get stuck.

Leaving your bias behind

Des: You were both UX designers and consultants before becoming product managers at Intercom. Is that a good skill set to have coming in the door?

Colin: Particularly in the frame of Intercom it was super helpful. Intercom has this very rich designer-oriented DNA from its founders. Yourself and Eoghan come from that background and I found when I came in early, I was able to speak that language to intuitively know what was happening. That was just such a good head start to have, and if I’m ever hiring a PM at Intercom, it’s one real strength I’ll look for, because I know that that’s still how we primarily think about how we build product.

Brian: There’s so much you take for granted when you have a design background that’s really helpful as a PM. The ability to do research, particularly if you don’t have the luxury of a research team, well, efficiently and quickly is a huge advantage and problem definition, which we define very much as core to the PM role, is part of design. Any design thing starts with defining the problem. So we’re explicitly merging design and product management there, which absolutely it helps a lot.

The flip side is any PM comes with a bias from where their background is and you have to be aware of that bias and figure out where you’re drawing that line. When Sketch was coming around and a lot of people were switching to it, I explicitly said, “I’m not learning Sketch!” Part of this was laziness – I didn’t want to learn a new tool – but part of it was I don’t want the temptation to open up Sketch. I should just be writing on a whiteboard and taking a photo of it and sharing my idea that way. That’s as far as a PM should be designing.

Brian pictured in Intercom’s Dublin office.

We had a PM in the earlier days, Luke, who had a PhD in Computer Science, I remember being envious, because there were so many conversations he was able to be a part of to a much richer extent, and he said it hadn’t helped him that much. He said, “I can actually appreciate the elegance of a lot of the engineering solutions way better than you can, but that doesn’t really matter.” He has to pull back from his tendency of wanting to get in engineering conversations that aren’t productive for him.

Since that conversation, I’ve never wished I had a deeper engineering understanding. A PM needs to understand the structure and how things are built and how they’re working, but usually the strongest muscle on your team is the engineering muscle. You’ve got an engineering manager, you’ve got a handful of engineers, they’ve pretty much got that one cornered, well-cornered. All the other things are where the PM can bring perspective to the table and I think design captures a lot of those angles pretty well.

Moving from product manager to manager

Des: You’ve both moved from managing products to managing people who manage products. How do you then decide where you can add value in the process and jump into the details versus when you should take your hands off the wheel and see what happens?

Colin: There are two checkpoints that I focus on most specifically as to how I can add value as a Group Product Manager across a number of teams. The first one is the definition of the problem. We specifically write that before taking on any design work and we hone that problem, which is basically a one-page description of what we’re trying to solve and how we’re going to measure the success of it. That will go through a good few iterations with the PM, with the team, to make sure we have it right.

The second checkpoint where I try and add value is when we go a bit wider on the many possible solutions and then start to narrow in and decide what we’re actually going to build. I’ll really be thinking about the scope for the piece that we’re first going to build – what’s the smallest definition of the great idea that we’ve had that we can get out into customers hands and prove that it’s right or not right? And what do we need to learn from it?

The idea of “starting with a cupcake” is metaphor for how product managers at Intercom approach scope.

Brian: A huge challenge in any management role is how far involved to be or where to pull back. Having those milestones gives you the reassurance that you don’t constantly need to be making sure you’re not missing a critical meeting where it’s the right chance to try to influence the product. You could also frame it to the team as “Hey, pull me in when it’s useful to you to bring my perspective to it.” It’s actually earlier in the design concept stage where I’ll be more involved.

The short answer to this is it’s really been tricky. There was one point where I was thinking I’ll go in at the weekly planning meetings, tad the team says, “Hey, you gotta back off from this. Stay out of this part of it.” It’s important one to be sensitive to and try to get right, and it’s very much an ongoing thing to get that balance.

Des: Similarly, as a person who manages Product Managers and also indirectly manages the products that serve customers, the other people you serve are the customers of your products. How has your relationship with them changed as you’re no longer hands-on with the product but still help Project Managers connect with customers? How do you connect with customers these days?

Brian: We’re trying to systematize this because you can easily go a month and think, “Crap, I haven’t talked to any customers this month, that is horrific.” It’s shocking how quickly that can just fade to the background. Colin and I have talked before about saying, “Hey, you’ve got to do a customer day once a month,” so you’re actually sitting down and working the help desk and talking to customers. You also need to talk to current customers and prospective customers, so we’re trying to work a system with the sales team so they can actually bring everyone from the PM team into sales calls.

Earlier this year the sales team organized ten customer sessions where you’d go on site and that was fantastic and really intensive. It’s hard to know, is it better to have an intensive customer immersion or to have it spread out? I have no idea which is better, but the intense part of it really sears more deeply into your brain at certain points, so sometimes that’s really valuable. The default is that you just get more abstracted and you’ve got to force yourself to occasionally be at that coalface.

Des: I’m tempted to picture the pointy-haired boss from a Dilbert cartoon saying, “I talked to four customers today so here’s the thing we have to build,” and you have to realize that you’re collecting antidotes at that point. When we’re dealing with the scale of hundreds of thousands of people, four conversations might not actually be that important. How do you dilute these conversations appropriately?

Colin: You use your subconscious. A lot of how I think about those customer calls is just pushing more personality and stories. They’ll connect with lots of the other things that are surfing around in the back of your head, and put a name and a face and an emotion and a feeling around those things that you felt you needed to do in the first place, but just didn’t quite have the conviction or the sense of who that person was and the pain that they were feeling. Throw it in there, let it mix around and when you next see a big data point come up – bang. It’s going to sync with it and you’ve got both the evidence and the visceral feel to make this happen.

Where product meets marketing

Des: Something we absolutely did not have when you both joined was any concept of Marketing. How has your relationship grown with marketing? I’m sure maybe you both started as cynical as the rest of us.

Colin: Our VP of Product, Paul Adams, has a great quote along the lines of “If you build a great product and no one uses it, have you built a great product?” That’s rung true to me more and more as I’ve worked at Intercom.

What I find really helpful on the marketing side is the very external view of what’s going on in the world. I can think very closely about my customers, the people who are using my product every day and what I see as important for them to build – and I’m looking out in the market as well – but the marketing team bring a whole different angle on that. They think about the purchasing decision and the other competitors that I really hadn’t considered in my mind, and between us we fuse that understanding of what are the most important things to build here that will satisfy our existing customers but also give us a new place and space in the market so we can talk about something different.

There’s a real naivete that product-first actually means product-only.

Brian: As a company, was say we’re product-first. We say that internally repeatedly. There’s a real naivete that says product-first actually means product-only, that all you need to do is build a great product and everything else will follow. That’s just foolish. The best product people are naturally good marketers, and vice versa. They’re not as separate as you initially think. In a company if they are very separate, that’s a real problem. If when the product team looks on the marketing page and thinks, “I don’t really know if they get what we’re building”, that’s a problem.

I remember 18 months ago I went to our own landing page and thought, actually this is a really coherent framing of what we’re offering. It was a real useful way to center where my brain was for something that I hadn’t thought about for a while. That’s a success when your marketing team can actually articulate things really well like that. That’s useful for the product team. It’s not just what you build, but it’s how you frame what you build in your customer’s heads, and if you ignore that, you’re just bad at building products. If you think about the naming in your UI, that’s not just about usability, that’s marketing. That’s how you’re positioning what you’ve just built in your customer’s heads so that it’s actually desirable and useful to them.

Des: A really nice example of this is in Basecamp 3, where they have a tool called Work Can Wait, which is how you disable interruptions. You turn off notifications when you’re not working basically. They could have called this “notifications preferences” or anything like that and it would have bored the shit out of the users, but still be understandable and doing its job. They actually took the opportunity to see these things as marketing opportunities. Basecamp has an opinion that work can wait and Asana or Trello doesn’t have that opinion – they have notification preferences, which is a totally different thing. The marketing voice when we’re labeling and discussing projects, even if just for internal use, is actually really important.

Brian: It’s something we’re still trying to get better at. The Product Marketing Manager and the Product Manager, we’ve tried to make that a really tight relationship. It’s been hard because we’re split between Dublin and San Francisco, but it’s critical. Another example of where we’re trying to get better at this is with our intermission, which is basically our problem statement, and we’re actually included the Inter-story, which is our own language for how we’re going to pitch this. As part of this central document and trying to get that inter-story written earlier up front to start framing this in people’s heads. We’re now explicitly saying, “Hey, make sure you’re really scoping down, scoping down, but if it’s part of the story, that’s legit. Don’t break the story.” We’re explicitly getting the marketing into the scoping, which we previously were not very good at.

The evolution of Intercom’s product roadmap

Des: Last year we worked towards what was called the 666 roadmap, where we planned 6 weeks, 6 months, and 6 years ahead. We’ve recently killed the idea of 6 months timeline. What went wrong there?

Colin: There are two points that jump out to me when we talk about the 6-month aspect. One is that it became this uncomfortable mix of strategy in the things that we wanted to build over the medium term and then also around planning, which is like a promise to deliver something on a certain date. The 6-month had this really dangerous scenario of getting mixed up in that. Everyone external from the company would see that something’s on the 6-month roadmap, and assume they can plan that roughly in 6 month’s time we’re going to have this thing. Yet often the product teams were using it as a means to just map out what looks like the next most important things for us to build. There was this mixed translation that was happening.

The second problem was that we had a rolling scenario where essentially at any time anyone could open up a roadmap in the company and it was somewhat of an accurate representation of what we were working for in 6 months. That taken to intense degree means that you as a product manager have to come in and update that because guess what, it took a longer day yesterday. We never took it quite to that extreme, but because there’s no defined points at when this thing gets updated, you either never update it or you never think of all the planning activities to make it accurate.

Des: Brian, you’ve been an advocate of the 6-week cycle. What do you like about 6 weeks, and how do you prioritize within that time frame?

Brian: We’re really strong on the 6 weeks now, and we’ve doubled-down on it. We actually tried it a year ago, because the whole company works on quarterly goals, pretty standard, and we thought the product team should work the way the rest of the company’s working. We tried quarterly goals and it went bad. We gave it one go maybe two go’s, and we went back to the 6-week cycle. The reason it works so well is it just seems to strike this balance between the low effort planning that you need to do to think 6 weeks out. It requires some planning, but pretty low effort. The commitment you’re making is real and it’s a commitment the team buys into and will really fight for. You really have time to work at it, to get it wrong and to go back to regain ground. It’s working really well now and that’s one of the real foundations of our structure that I’d wouldn’t take away for anything.

Looking backward to look forward

Des: Last year you both were kind of key figures on two of our biggest product projects, which spanned nearly the entire year and is a rare thing for us. What lessons or scar tissue were you left with after that and how does that change how you’ll work on projects in the years ahead?

Colin: The key thing for me that we’ve learned is trying to bake in some of the principles of how we build product into our actual development process. We have a mantra around thinking big and starting small, and we now have that actually much more mapped out in our development process. We take the stage to think big, to go wide, to not consider scope at all, and then once we get a good agreement on what the the general “think big” is, we flip into asking, what’s the smallest definition, conceptualization of this really big thought that we can scope small and get out into the world and understand more?

We have a mantra around thinking big and starting small

Brian: The reality is it’s depressing how easily you can slip into bad habits. You forget what you did in the last project or what you did last year that worked really well, and you think you’re naturally going to repeat it again. That’s not the case. To a large extent, we forgot how to scope things well. And so we’ve really had to build that muscle back. We already feel good as a product team that this year has gone well for us. The lesson is actually making this repeatable. We need to be way more deliberate about it than we realize. The challenge will now be we’ve regained that ground, can we sustain it? Have we genuinely made it repeatable?

Des: If you walked back to Intercom when you joined, would you try to impose the process you’ve now come to love on the company or do you think the chaos is essential in those early days?

Colin: 2014 was figuring out what we were doing at all, 2015 was building a bunch of small projects – scoped really well, but not very inspiring – and 2016 was let’s go big, too big. We’ve had to go through that as a team to now know what the balance is between the two.

Brian: I would happily bring our process now back to when we started. The chaos and the messiness is inherent to what we’re doing, but it’s not something that should just be left with free reign and let dominate things. When we started it was like barely keeping your head above water, and structure can actually let you actually rise up and float a little higher above the water there and breathe more naturally. You don’t have to simultaneously feel like you’re doing everything.

Colin: In that hypothetical scenario where you can bring back the process that you have created back to an earlier point, that would be totally advantageous. But if I went into a new company in the morning, I don’t think I could apply this and suddenly it would work, because they’ll work in a different way and they will essentially have formed their own process in 2-3 years’ time.

Want to learn more about our thinking on building and scaling a product? Download your copy of our book, Intercom on Product Management.