Intercom on Product: Meet your marketer
This month we're exploring why it's important to "get together and partner" with your marketing team.
On this episode of Intercom on Product myself and Paul (Adams, our SVP of Product) delve into how product teams can and should partner with their marketing team peers. Typically on this podcast we’ve focussed on how the product org is structured in a contained way but just as “no person is an island” – no discipline can operate in a vacuum once the company starts to scale. To this end we’ll be broadening our scope in future episodes, to look at the various intersections that a product team meets in a typical SaaS organisation.
The collaboration between those charged with creating a product and those tasked with sharing it with the wider world is a symbiotic one that relies on early and honest communication. Isolated iteration by either side can result in confused messaging and a product that doesn’t deliver on what the customer wants or expects. By ensuring the external messaging is in sync with the internal product planning your opportunity for success and customer satisfaction is greatly increased.
If you’re short on time, here’s a few quick takeaways:
- As your company evolves so too do your product marketing needs – you’ll be selling to a wider range of use cases and a lot more customers.
- Product people need to think end to end. Ideally anyone who’s building the product should have a vested interest in how it is spoken about externally and how you sell it to end users.
- The democratization of software adoption doesn’t necessarily work at scale. You need to speak the language of results so that you’re appealing at director level, manager level and to the frontline user.
- The left hand needs to know what the right hand is doing. Collaborate early with your marketing team to allow for implicit understanding of where you’re both headed.
- Get together and partner – use each other’s toolkits, embrace collaborative workshops, and cooperate at peer level between teams.
You can listen to our full conversation above, or read a lightly edited transcript of our conversation below.
If you enjoy our discussion, check out more episodes of our podcast. You can subscribe on iTunes, stream on Spotify or grab the RSS feed in your player of choice. What follows is a lightly edited transcript of the episode.
Des Traynor: Welcome to Episode 11 of Intercom on Product. Unlike previous episodes, where we’ve been pretty firmly focused downward within product orgs, today we’re going to talk about how product partners other functions. Today’s episode is actually about marketing. This is the age-old product-meets-marketing challenge. As a company starts, it generally tends to have this simple product on a flat team of like three, four, five people: all working on a very simple message to a simple group of people. And everything seems so easy, such that you’d barely wonder what on earth you need marketing for – or rather, why is it so hard for companies who are larger.
Today, as always, I’m joined by our SVP of product, Mr. Paul Adams. Hello, Paul.
Paul Adams: Hey, Des.
What is product marketing?
Des: And we’re going to have a chat about this, because it’s definitely been an area we’ve learned a lot about over the years. As I said, things get complicated as you attract more diverse customers, diverse use cases, different types of advertising campaigns, more and more people in the mix. And we know a lot of companies that have struggled to get this product and marketing relationship right, ourselves included. So that’s today’s topic. Paul, what the hell is product marketing to you?
Paul: There are many ways to answer that question. Maybe I can start by throwing out a few of them. I often say to people that it’s some version of people and products. Some version of: if you build your product, and you’ve put it out into the world, and no one has heard about it, was it even worth putting it out there? One big thing that product marketing does is to help bring that product to the world, to help explain it to people, to help people become aware of it. And so in many ways, this will be the crux of the discussion today.
Product marketing is almost a part of product. It’s very hard to actually draw firm lines between where a product manager’s job starts and ends and where a product marketing manager’s job starts and ends. Both of those sides need to be thinking about the other person’s side just as much.
Des: Right. I know a lot of our listeners are pretty early stage startups. And for me, generally speaking, an early stage template looks something like this. Like you have a better mousetrap or a better time tracker or a better task manager or whatever. And the gist of product marketing is: get the tagline, which usually involves reinventing things, things you’ve never imagined or forgetting everything you know about time tracking or whatever. And you have a big-ass screenshot on the homepage and a signup button, and you sit back, and you’re like, “Job done.” Why does it get harder as things go further?
“Product marketing is almost a part of product. It’s very hard to actually draw firm lines between where a product manager’s job starts and ends and where a product marketing manager’s job starts and ends”
Paul: There are a lot of reasons. One simple one is competition. Usually, startups that have come to market with a good product from the very beginning have identified some need in the world and some customer problem that isn’t solved or some opportunities to do something better. So in a sense, they have very little direct competition. They’re just new in the market. They’re doing something different, you would hope.
And as you get older, you become mature. If you see success, then you start to attract competition. Maybe that’s like incumbent companies. It’s hard for new startups to start to do some of the stuff that you’re doing. So it becomes much more important to have a really clear idea of the unique position you hold in the market. What is different about your company and is that difference really easy to explain, really easy to understand? And that’s an internal and external thing: externally in the market, you want prospective customers to understand the differences. But internally, too, it needs to be really clear right through the product org, the marketing org, the sales org. That difference, again, needs to be really clear, really simple for people to understand. And that’s not actually as easy to do in practice.
Des: The other thing that comes to mind here for me is that Jared Spool once somewhat jokingly said, “If you want to increase your conversion rates, just turn off all your advertising.” And he was right in the sense that if we turned off literally every way that people would normally hear about Intercom, literally the only people who would come to Intercom would be people who already know and already want it. And the inverse of that statement is there for that: your conversion rate will logically decrease as you scale your advertising because you’re effectively attracting people with weaker and weaker intent.
It doesn’t mean that that’s a bad thing. It just means that like there’s a world of difference between somebody who’s, say, shopping for, “I want to install Intercom on this new product,” versus, “Is there a good tool for talking with visitors on your landing page,” right? Both of those roads point to Intercom, but one of them is ready to rock and is going to click the signup button on arrival. And the other one is definitely going to shop around and compare us with some of the other incumbents.
“The job of product marketing is to explain the value that’s locked up in the product and make sure that the target customers understand it“
In my opinion, that’s the first point at which it becomes necessary to have more than one thing to say to a customer. So that’s why the big-ass screenshot starts to not work in a sense, because for the person who just wants to install Intercom, fine: they’re clicking the signup button eight days a week. But for the person who is shopping around, I’ve always said that people don’t buy the solution until they’ve bought the problem. You need to sell them on the idea that they need this thing, and then you need to sell them on the idea that this thing is the best version of the thing that they’re going to get – which in blunt terms just means more marketing pages, right?
This is where you end up with use cases and where you end up with customer testimonials and all of those extra things that you need to say in your marketing. Like, “Yes, this is a great time-tracking app, but did you realize it also works for dentists or whatever?” You start to get into having to pitch it in different ways. And as a company scales out its marketing offerings, the first thing most startups add is usually product marketing. And that usually makes sense because the job of product marketing is, as you said, to explain the value that’s locked up in the product and make sure that the target customers understand it.
Once you add demand generation – and that is the folks who try to get out into the customer’s natural habitat and put ads in front of them or billboards or podcasts or blog posts or books or whatever your chosen weapon is – you’re going to attract people who are looking for maybe something like your product but not necessarily [the product itself]. And this is where you have to proliferate your messaging. In Intercom’s case, we have a lot of power companies that use Intercom. We could therefore say that Intercom is great for power companies, but that means for that message to resonate, our demand generation team can’t just put out a message saying, “Intercom: the communication platform for power companies,” right? Because they’re going to click through. And they’re going to see our homepage doesn’t mention power companies. And you’re back to this Jakob Nielsen idea of the scent of information which is, “Let me follow this message all the way down the funnel.”
“Anyone who’s building the product needs to have a very deep, vested interest in how we sell it”
So that inherently means you’re going to have to have a product marketing page that isn’t a big-ass screenshot, but instead is, “Here are five reference customers from great power companies who have had great results using Intercom.” Ideally, you’ll have an onboarding flow for power companies. Ideally when they land in a product, you’ll say: “Welcome power company. Intercom is the tool for power companies.” But to do all of that, you end up massively splitting your funnel in loads of different ways. And that is what causes the complexity. And if product marketing is doing all this in conjunction with demand generation – but they’re not telling the product manager – shit’s going to go wrong fast, right? Because they’re going to be launching features that would make no sense for power companies. And they won’t be able to feature-gate them or block them or exclude them or whatever. Things will unbundle really quickly. And yet, all the metrics will look positive while that’s all happening.
Thinking end-to-end
Des: That to me is probably one of the biggest dangers here. If I was to zoom out and ask a bigger question: Paul, you manage 20 product people or so. Do you ask them to care about marketing? And if so, why?
Paul: Oh, yeah, 100%. Product people care deeply about go-to-market, marketing and sales. How is the product being marketed? How has it been sold? It’s critical that the product management team in particular – but anyone who’s building the product and cares about usage and delivering value to customers and solving their real problems – needs to have a very deep, vested interest in how we talk about it externally, how we sell it, how our sales team talks about it.
“In an ideal world, the whole thing is beautifully consistent, and it all makes sense. Now in reality, it’s messy”
One of the things that we talk a lot about internally here – and this is a hard problem we still haven’t cracked – is what I call end-to-end thinking. In an ideal world, maybe someone unfamiliar with the product first hears about it from an ad, and that ad copy resonates with a problem they have or a thing they’re trying to look for. And then from the ad, it runs all the way through from the landing page; then they sign up for the product; they enter the product; they’ve got some onboarding messages, the product copy and the UI experience.
In an ideal world, the whole thing is beautifully consistent, and it all makes sense. Now in reality, it’s messy. And we, especially the designers amongst us and the design thinkers out there, tend to design these things in such a way that they naturally flow from one state to another. So someone clicks the ad, and then they get to this landing page in the marketing, and then they scroll, and then they see this thing, and then they click this button. And then they fill in this form or whatever. In reality, it’s really messy.
“People often visit a marketing site many times before they click the button”
For example, time is a big component. People often visit a marketing site many times before they click the button. And again, it depends on the complexity of the product that they’re buying. It’s one thing to buy a time-tracking app, and it’s another thing to buy a complex piece of software that’s expensive. So people come back often with different states of knowledge. They come back in different states in terms of readiness to buy or even their mood. If they’re feeling good about it, they’re going to try it out. Or maybe they’re feeling a bit negative, or it’s not how to work out for them. So time is a thing.
And then another piece of the messiness is just people. So often in a company, it’s not a single person’s purchase. We often get trapped in this tune when we design these systems thinking: “Hey, here’s the buyer persona. It’s Sally, and here’s what she does. This happens, and she does this, and she’s looking for X.” But in reality, Sally has a manager, and Sally has a team, and Sally has peers and colleagues. They all have an opinion too, and they all want to get involved.
And then all these people often care about different things. Some people just want to see the ROI. They’re like: “Show me the numbers. Does it increase our revenue? Does it decrease our support costs?” They just want to see the numbers. They want social proof. They’re like, “I want to see other companies like us who do this.”
But some people don’t care about any of that. They just are excited to try out a new product. They’re excited about the features. They buy into the vision. So there are a whole bunch of internal viewpoints.
Democratizing the adoption of software
Des: There are two different conversations I want to have spring out of this. The second one, which we’ll come back to, will be a little bit about the end-to-end review process that you usually run in advance of any big launch. Because that’s been a powerful thing for us to, frankly, get our stuff straight.
But the former point is really interesting as well. Here’s something I’ve been accepting over the last five years: this idea of the democratization of software adoption. Like the Dropbox model where it turns out everyone at the bottom of the org started using it, and now the CIO is in some sense compromised and just has to go with it.
I don’t really believe that works. I believe, at the very least in our domain, for most B2B spaces, you want to charge appropriate amounts of money. You’re not a $9-a-seat purchase. You end up being a significant line item. And it’s an important shift for B2B companies to get out of the idea that there is one user who is in your funnel that’s going to make a decision that impacts an entire org’s support team or marketing team or sales team. The idea that one person is going to make that decision – and not only make that decision but also be the only end user on the far side of all this – is kind of batshit, right?
And as a result, this idea of bottoms-up adoption is true in the case of the tiny, four-person startup. Simple product, simple offering: it makes sense there. But for any degree of complex software or any degree of powerful or perhaps expensive software, there are more people involved in the purchase. And the forgotten voices and opinions here tend to be all of the people. Now, by the way, do you know who gets this right? Sales orgs. Because they notice stuff inside out. Product people generally tend to be naive here.
“As the product scales, the adoption path gets complex, and we need to allow for that”
These purchases are made with many opinions, and whether we like it or not, there are people whose opinion matters who are not the end user. They might be the people who approve the cost. And bear in mind, cost isn’t just the dollars. It’s also the, “Hey, do we want to have a four-day offsite to learn how to use this new tool?” All those extra costs people don’t think about. And then there are people who aren’t end users, but will be infrequent users. They need to see: “Am I going to get the right dashboards out of this? Am I going to get the right metrics out of this?”
So the point you make is really important, which is as your product scales in power, you need to get your head out of this mindset of, “I have one end customer who is somehow also a frontline rep and the VP of Sales and is going to be the person who authorizes the purchase and will also be the only end user I have to think about.” And you need to realize your funnel on your marketing needs to appeal to everyone. It needs to speak the language of results, of social proof. It needs to speak the language of what a manager wants to see, what a director wants to see, what a frontline user wants to see. And it needs to sell them all on the idea.
Then the onboarding process needs to do that, too. It needs to be easy to go from “Hey, I’m just tipping around here trying to get this product,” to “Let me invite my team,” to “Let me prepare my first dashboard so I can show it to my boss.” And all that stuff generally tends to get forgotten in the transition from a small company to a big company. So that’s all I wanted to rant on.
But I do think it’s important to note that, as the product scales, the adoption path gets complex, and we need to allow for that. And that’s why marketing and demand gen and all that stuff gets more complicated. Because, again, the demand generation generally tends to move further up the org chart. So the messaging starts to target directors and VPs and CMOs and CTOs – whoever’s top of the list. And as a result, the marketing needs to also follow that. Which basically means the signup path and what product people have to think about also changes.
The end-to-end review
Des: Then to come back to the other point, we had a launch a couple of weeks ago, and we actually have another spoiler for all of our exclusive podcast listeners. We have another huge launch coming in about three to four weeks. We’re going to be deep next week or the week after in what we call end-to-end review. Could you talk a little bit about what that process is? What are you looking for? What’s the scope for those meetings? What are we trying to fix? What are we trying to catch?
Paul: I’ll start by sharing how we got it all wrong for years, because that’s the most useful, pragmatic takeaway for people listening. If you go back a few years at Intercom, we had three teams that would have been involved in any product launch. One is the product team: obviously an engineering team building the product, building the software. Then there’s the marketing team: the product marketing manager in particular but also the brand team and other people involved with creating assets and storytelling and demand gen and creating ads. Then we had the growth team: looking after things like the signup process, some of the pricing work, pay walling, onboarding, the masters you look at and so on.
So we had three teams working on the launch. And there’s a funny, famous (or infamous) story from Intercom a few years ago where we launched a new product, and the three teams all did an excellent job in their own silos. The product engineering team designed and built this great product, and the marketing team did a great job marketing it, and the growth team got all the bits and pieces required. But they hadn’t collaborated, and because they hadn’t collaborated, no one actually designed and built the scenes between these things: moving from finding out about the product to being able to sign up for it, then moving to actually getting it. And as a result, we didn’t actually build some of the things that were required.
Des: If I remember correctly, I think we made a big splash. It’s ancient history now, and the people who we’d blame are no longer here, but they’re probably still listening to the podcast. Of course, I actually did blame you. I do remember getting the most horrifying message where we did this big external splash about how Intercom now works on your marketing side and how all the things you love about Intercom are now available for talking to website visitors.
“This idea of an end-to-end review brings everyone together into the same room so we can avoid this stuff”
And it got a tremendous response from the external world. And all of our existing customers were like: “Hey, I’ve been a user now for two years. How do I sign up for this thing?” And that was the piece we had forgotten. We’d forgotten to let our current customers sign up. It was the classic case of everyone thought it was somebody else’s job, right?
Paul: Yeah, exactly. We got it wrong a couple of times – never as bad as that one. That’s the infamous example. But there are a couple of times we got paywalls wrong. Again, journeys that people hadn’t thought about like: “Oh. These customers are on this plan, and this new thing is on this other plan. What happens? Do they click a thing?”
Des: Go back to the meeting. Do you identify these journeys now and walk through them each flow by flow?
Paul: Yeah. There are two problems that we encountered. And then I’m going to talk about how we do it. One is that there are people working in silos. This idea of an end-to-end review brings everyone together into the same room so we can avoid this stuff. And we start to go through all these customer journeys to make sure they’re all mapped out well. So we solved that problem by getting everyone to send end-to-end reviews.
But we also look at things like copy. We look at messaging, consistency of message, tone. Are we explaining things in the same way? Have we accidentally drifted in language? And now people are explaining two things, saying the same thing in two different ways. So, we look at all that stuff.
But we then realized we had done this wrong in a second way, which was that we were doing this way too late in the process. We were having an end-to-end review for a new product a week before the launch. And then we discover all this stuff that’s wrong. And you’re like: “What are we going to do now? We have a week to go. We’re in QA mode. We’re in the final mile here.”
“This is the chicken-and-the egg problem. How can you do an end-to-end review of something that isn’t complete?”
Des: And we’re too big a company at this point to say: “You know what? Just skip this. Push the release date back for another couple of weeks or whatever.” Because we probably would have had planned press launches and all sorts of shit, right?
Paul: All sorts of stuff. Yeah. You could have press with embargoes that were going to go off. Launch events. A whole bunch of events that we would have done over the years. It was just too late. And then we end up just going through with the launch needing to scramble post-launch to fix all the stuff that we’d missed.
So now we have these end-to-end reviews much earlier in the process. But to be honest, we’re still not doing as well as we can, because it is hard. The end-to-end reviews are still a little bit too late. Everyone would agree, I think. We still don’t do them early enough. And we’re still trying to figure this out. The challenge is that, in order to do a full end-to-end review, you have to have everything done, you know? This is the chicken-and-the egg problem. How can you do an end-to-end review of something that isn’t complete?
Des: Yeah, because you don’t want to have one of those reviews where you’re like: “Hey, we know this is all shit, but trust us it’ll get better. But please review it.” Because you’re like, “Well, do you want feedback or not?”
Paul: Yeah. We ended up with loads of those types of things, where the review is at the right time in the calendar, only for people to go: ”Yeah, we haven’t figured that out yet. That’s a bit crap. We’re going to fix that and change that.” So that’s why I’m saying this is very hard. And there’s a balance that we are still trying to find between stuff being finished enough that we can review it, but it’s early enough so we can change it.
The key thing, then, is stating the obvious: you just need a very good partnership between the different functions. The more the functions talk – the more the PM and the PMM are talking, and the more the PMM is talking to the brand designers or to the demand gen folks – the easier this is. Because you end up with this implicit understanding of where each other is headed. So by the time the thing does fully get fleshed out, we generally knew how it was going to work anyway. So the mistakes we’ve made tend to be smaller than they might have been otherwise.
Des: That makes sense. And then just to change the area of discussion for a second, a lot of what we’ve been saying of late has just been about what happens when you have, effectively, a big-bang launch, right? As in: “On July 5th, everything’s going live. We’re going to tell our customers and send this email, blah, blah, blah.”
Isolated iteration breaks systems
Des: The other area where product marketing can easily diverge is in what I would just call the day-to-day iteration of your product, and your marketing, and your demand generation. A danger I observe here is that iteration that happens in isolation effectively breaks the whole system. To give you an example: a product team iterating without talking to the marketing – and by iterating, I mean dealing with the voice of the customer. That’s like standard feature requests, shipping them, adding on things, improving things, updating screenshots, et cetera. Just normal product teams tipping away on their normal product stuff.
Outside of the context of a big-bang type of launch, they will naturally move the product along in terms of making it more powerful, closing off more gaps, changing aesthetics, changing screenshots, changing key flows, et cetera. And as a result, the product will start to look less and less like it does on the website. And it will have more things than that are listed on the website. And it will basically have more use cases and more power and probably better results than the marketing says.
“The demand gen team always needs to know what the hell the product is doing way in advance”
Product marketing, doing the same thing, will start to produce marketing for a product. If they’re iterating on their own work in absence of that product, they won’t know where the product’s going. So they won’t know where to take the messaging. And they’ll oftentimes end up refining and A/B testing their way towards the most efficient way of marketing the product as it stood a year ago, even though the product team has moved on.
Lastly, and perhaps most dangerously, it was our Head of Demand Generation and Growth Marketing, Brian Kotlyar, who made this point to me really clearly. He’s a firm believer that the demand gen team always needs to know what the hell the product is doing way in advance, because if you iterate on advertising independent of your product team – and therefore not touching base with reality of what the product actually does – your only input mechanism will be whether ads got clicked. Did they produce an MQL? Did the MQL go on to be a lead? All that usual stuff.
You can really easily fool yourself by producing a really effective advertising campaign for a product that literally doesn’t exist. And this is the bit in the podcast where I should be taking potshots at competitors, or something like that, but I won’t. Iterating on advertising independent of what the product actually does will get you great ads, great hype, great buzz. The only thing that’s missing is the product’s not there.
So how do we solve for the reality where you have product marketing and demand gen all within their own worlds doing their own day-to-day maintenance of their own properties, which usually improves them and takes new inputs? How do we make sure they don’t diverge?
“To cut to the chase, the answer is partnership”
Paul: It’s a great question. And similarly to earlier, I’m not going to pretend we’ve solved this, because we haven’t. But I can highlight, at least, where we’ve been and where we might be going. To cut to the chase, the answer is partnership. We had this interesting thing over the years at Intercom where we’ve a big office in Dublin, we have a big office in San Francisco, and we have offices elsewhere now, like London, too. But for years, we built the product in Dublin, so our product managers are all in Dublin.
And then the product marketing managers earn the marketing work, which was all in San Francisco. So the PMM and the PM are in different offices, and they’re separated by eight hours in timezone. And the debate that came up here and there about whether they should be co-located. Surely that’s a better world.
And for companies who have one office, one HQ, they often are co-located. But I even go a step further and say should they not just be sitting together? In the same way that a designer and an engineer, I would hope, basically sit together in a team so that they can just quickly chat with each other and make sure that the intent of the designer is coming through in code, and that the engineer can give feedback to the designer on what’s feasible, and not working well, and so on. In the same way that they just collaborate in real time. The theory is that the PM and the PMM, sitting beside each other in a team can collaborate in real time. And then the idea is that the PMM is the conduit for marketing.
The PMM is the one who’s talking to demand gen, talking to the brand team. They represent marketing both in and out of product. And that’s the answer, which obviously means that the PMM has a critical job to do. It’s interesting now with a lot of companies going remote, and it’s going to increasingly be the case that they’re not sitting beside each other and not in the same time zone. So it’s going to be something that we’ll probably have to overcompensate for: the idea that we don’t have the card or chats to just get back on the same page and so on.
Output vs. outcomes
Des: That makes a lot of sense. A lot of it is best solved by, as you said, the PMM joining the standup for the product team and vice versa – to make sure that there’s no obvious massive gaps. If you take last week’s launch, where we made a huge improvement to our support product: it’s a different type of launch than say Resolution Bot or Product Tours or any of our signature standalone products where we’re like: “Hey, this thing didn’t exist yesterday. Now it does. Have at it.” Yet, this other type of launch is, “The thing you’ve been using for the last few years is now dramatically better.”
We’ve got a lot of questions internally and externally about the messaging here. Internally, at least, a lot of questions have been like: “We told our customers we shipped over 20 features. Why did we say that?” And we’re still teasing this apart. The dilemma we face is that we have genuinely improved 20 different areas of the support process – everything from reporting to ticketing to you name it, right?
And all of those things got better, but there was a need to launch a lot of these things together because of the overlap in functionality. How do you best package up these things and communicate them both to customers and prospects? How do you market this bundle of features versus the single big bang?
“We are on a very strong path internally to move to a much more outcome-based way of working and thinking”
Paul: It’s a fascinating question and not a simple one. Internally, at least, there are two things I like debating and reflecting on the launch and having a think about. One is this idea of output versus outcomes. The question that was raised to us in different ways was like, “Hey, why are we celebrating output externally?” (Output being like, “Hey, we’ve got 21 features.”) It doesn’t speak to the value that those features deliver. And the reason that’s a question internally is because we are on a very strong path internally to move to a much more outcome-based way of working and thinking.
The second was bundling: when should you bundle features together? How big is a bundle? When is a bundle too big? Is 21 too big? Is that too much bundling? Because then it gets harder to tease them out apart, explain them all, et cetera. It is definitely something we’re still trying to think through, like you said.
The things that I have a fairly strong conviction about at the moment are: if you do decide to bundle a lot of things together – and there’s good reason for doing that – a product team and an engineering team will always want to ship stuff earlier and faster and get that learning and value out into the world for customers, which is their key priority. They get the lessons learned faster, but it’s harder for go-to-market teams.
If you’re shipping at the pace that Intercom does, and you’re shipping stuff every week, it’s really hard for the customers trying to consume all this stuff every week: more changes, another update. The marketing team is like: “Oh my God, I’ve got to update more pages. Are you serious? We just did that last week.” The sales team is like: “Well, more stuff. Wow, I’m just still trying to talk to the customers about the other stuff.”
Des: There’s an inherent bundling, and sales usually does a quarterly business review. They want to sit down, and they’re going to introduce seven things in that chat where it can be quite confusing to the customer if these things are being drip-fed out. Every time I log into the inbox there’s something new here, and I don’t know what it is.
And then the customer experience can get a little bit trashed as well, in that every PM – for all the right reasons when they launch something new – wants to do a big banner. They want to do a big update. They want to do a product, or they want to do a big CTA to say, “Check out the new blah, blah, blah.” But of course you’ve got 20 PMs and you’ve got one customer, the danger is you end up with this large amount of relatively small messaging, which is actually harder to digest down every now and then.
“The succinct answer is get together and partner”
Paul: And again, there are pros and cons to this approach, but that’s one of the benefits of the bundling. If we go to the market and say, “Hey everyone, hey customers and prospective customers. Today, we have 21 new features.” To me, that does two things, you would hope, if you do it well. One, they sit up and take notice. They’re like: “Wow, 21 new features. Intercom got a major upgrade today. I am going to pay attention to that. Maybe some of the stuff I’ve been asking for is in this release, and I’m excited.”
And then the second piece is that I’m going to also take the time to do it properly. Twenty-one features are significant, so what I’m actually going to do is set aside an hour of my day later to properly read through this, properly understand it, be able to explain it to my other teammates who use Intercom and have an informed chat internally about it.
You hope that it sets in motion both of those things. People pay attention, first of all, and then take the time to understand the updates. But again, there’s a balance here and depending on the nature of the release, if it’s lots of small changes. If it’s something bigger, maybe you want to do it a different way.
When to partner
Des: That makes total sense. Okay, and then lastly, and we need a succinct answer here, so really do your best.
Paul: I’ll try. That’s not really my specialty.
Des: I know, exactly. The answer to this question will be the entirety of the next podcast. Now, so it’s basically, if I transplanted you into a different company, let’s call them Quizzy Corp, because they don’t exist. And Quizzy Corp has all the problems we’ve discussed today: the product team is a little upset with the marketing team because they’re not getting all of their marketing right; they’re using different language. The marketing team hates product because they’re just throwing shit at them every other day, and they’re not communicating well. Sales are mystified as to where all this stuff is coming from. Without using just the vagueness of things, like get together and partner; what are some tangible things you think help here?
Paul: The succinct answer is get together and partner.
Des: Right, okay. What would be some high-order, high-impact things you’d introduce?
Paul: The first thing is that all the people who are at the appropriate team level should talk to each other. For example, with the recent big support launch, here’s what happened on the ground: I’m running product and talking to Shane, who’s running marketing. And we’re talking about the highest level things like medium term strategy bundling, “Hey, is bundling right? What’s the pros and cons? How should we do it in the future? What are we learning?”
“Don’t mix the zoom levels. The VPs shouldn’t be down editing the copy, and equally, the teams need to get their hands dirty – get in each other’s tools – and start functionally collaborating in the tools”
We’re talking at that level, and then you go a level down, and you have Ali, who runs the product marketing team. You have Jane in London running our product team over for support, and they’re talking about more specifics of the launch itself, but again at a strategic level. And then you get down into the teams and you have Annie, who’s our product marketing manager. And she’s talking with our group PMs and our engineering managers, and so on about the details of the launch. But all of these levels are deeply collaborating.
There are a lot of meetings like the end-to-end review. A lot of the meetings take the form of a working session. One of the things we joke about internally is something I’m sure is not unique to Intercom. The marketing team likes to use decks like Google Slides, for example. And the R&D team – the product engineering team – like to use Google Docs. So we have decks and we have docs, and we all know decks and docs don’t work together.
We have these working sessions where we just get in each other’s tools. We embrace each other’s process, and we thrash it out and it can be painful and it can be really hard at times. But it’s the only way, you got to get your hands dirty. So to recap, don’t mix the zoom levels. The VPs shouldn’t be down editing the copy, and equally, the teams need to get their hands dirty – get in each other’s tools – and start functionally collaborating in the tools.
Des: Yeah. And to conclude, you’ll know you’re getting it right when you’re pushing out a launch or an iteration, and the single message from the demand-gen campaign through to the product marketing page – regardless of use case, regardless of the vertical you’re going after – is the same single, simple message that the customer needs to hear it, and it will motivate the upgrade to purchase the engagement in any way, shape or form. That’s the sign you’re getting it right.
And the sign you’re getting it right is if any of those deviates, so you’re attracting customers for whom you have no product. Or when they sign up, they’re seeing the wrong things, or there’s overlap, or customers arrive to your product marketing page, and they just don’t understand what’s going on, or they do understand what’s going on, but the product isn’t there once they sign in. Any deviations there. And that’s probably the best thing you can investigate: make sure that you’ve got a healthy relationship between product and marketing.
Thank you very much for your time today, Paul. This is the end of Intercom on Product, episode 11. In future episodes, we’ll talk about product and sales, product and finance, and we might even bring on some guests to help us through. Thanks very much for listening, folks.
