Intercom on Product: The most valuable meetings for building product

The process of building product in an R&D organization of any size involves making lots and lots of informed choices between various options. It might sound obvious, but translating product strategy into actual products requires lengthy discussions followed by confident product decisions, and if you don’t put care and thought into what those discussions and decision-making processes look like, you will struggle to consistently ship high-quality product.

Therefore, it’s crucial that you foster the right environment to make those discussions as efficient and impactful as possible. We’ve put a lot of thought into those processes, and have settled on two meetings in particular when we’re preparing to ship a new product or major feature – Product Forums and End-to-End Reviews.

In the third episode of Intercom on Product, SVP of Product Paul Adams and I dive into how we make these product decisions, how those meetings came to be and how they work.

You can listen to our full conversation above, or read some highlights of our conversation below.

If you enjoy the conversation and don’t want to miss the rest of the series, you can subscribe on iTunes or Google Podcasts, stream on Spotify or Stitcher, or you can grab the RSS feed in your player of choice.

Devising the Product Forum

Des: Today, we’re going to talk about how it is that we meet and congregate to review stuff that we’re just about to ship and how we make decisions around it. We do it though the medium we call a Product Forum. Paul, what the hell is a Product Forum?

Paul: Glad you asked. It’s a meeting that we have, which doesn’t sound very exciting, but it’s a meeting where we make decision. I’ll give you the back story of where this came from. We have design critiques, like most other companies out there.

“People obviously need to feel safe to share all their work and have it critiqued”

Des: Design crit is where someone shows off their work and gets feedback from other designers?

Paul: In Intercom it’s typically the design team only. Other people show up sometimes too – engineers and PMs might show up. But generally it’s the designers giving peer feedback or manager feedback on work.

Design crits here work pretty well. They’re very positive and constructive. People obviously need to feel safe to share all their work and have it critiqued. Sometimes you’ve got to show some vulnerability to just open up for, “Hey, all right, give it to me straight.”

So Product Forum is something that came about 18 months ago when we were redesigning our messenger. It was a project called Messenger Four, the fourth version of our Messenger. It was a pretty big project for us at the time – there was a lot of different stakeholders. What was also happening at that time was the company had grown quite fast, and so there was people like me who was running the Product org, then you have product directors, PM director, design director, and then below that you had design managers or a group product manager, potentially. Then below that you have the individual contributors, the PM, the designer.

The Product Forum came about because there was confusion about who was approving what, or who was making the decision about what.

Des: It’s fair to say this is something of a slightly larger company problem, right?

Paul: Well, I don’t know. I actually think it’s an amazing meeting for any company to have, because even if you’re a company of 10 people, there’s hierarchy there. You’re striving for clarity – who do I need to show this to? Who needs to give feedback? What are the different roles people are playing? Are they just contributing? Is it like a design crit where you can just generally ignore the feedback if you think that’s best? Or do you actually have to take onboard what’s said?

“The only time we run a Product Forum is when there are decisions to be made”

The biggest thing on Product Forum was that this is going to be a decision-making meeting – the only time we run a Product Forum is when there are decisions to be made. Which, of course is all the time, but for Messenger Four, for example, and some other projects, we had it every week. I should say, it worked amazingly well most of the time.

Des: Is part of the value that it means no decision can be postponed longer than a week? I presume the idea isn’t freeze the team until forum time, right?

Paul: Absolutely not – these are for big decisions.

Des: Right, decisions usually made at a senior level because it impacts massive amounts of investment, scope, whatever.

Paul: Exactly. The team make decisions every day, as you might imagine. All local, smaller decisions. The teams at Intercom have a lot of independence. As you know yourself, both you and I these days are quite hands-off in terms of product and design decisions. We’re not involved in the day-to-day work at all, which is, I think, exactly how it should be. Which, by the way, is a surprise to many people I talk about externally. Neither you nor I do product reviews or a lot of the time.

Des: I think it’s because we still talk such a good game.

Paul: Exactly. Whatever you do, don’t walk the walk, just talk the talk. It’s grand. No one will ever know. Hence this podcast.

Prioritizing decisions

Paul: The great part of forums is people come in and say, “We have three decision to make today.” And if we don’t walk out of there with those three decisions, the meeting’s failed.

The decision might be, do more work on X, we’ve got to make a decision, and so there will be like, okay, three things. We need a decision on X, a decision on Y, a decision on Z, and we’re going to spend 20 minutes here, 20 minutes there, 20 minutes there. It’s very structured.

And in the best cases, people present the decisions they need to make. “Hey, here’s a design problem we have. There’s option A and option B and option C.” Then usually they’d make a recommendation. They’d go through pros and cons of each of the options, which is how our design team works. I think, by the way, it’s just good practice. All options in any kind of decision like this have pros and cons. They represent that as neutrally as possible. They do usually make a recommendation. “Hey, we want to go with option B.”

Des: And that recommendation will be from the entire team. It would have engineering input, design input, PM input, etc.

The secret sauce – program management

Paul: Which raises an interesting question around who goes to Product Forum. The team go. Everyone goes. Not everyone necessarily on the team, but all the stakeholders will be there. The engineers who are going to build this thing will be there. The directors will be there.

“The program manager would run the Product Forum typically, and they’d record the decisions that are made and then disseminate them”

The people who run the Product Forum is typically the program manager for that project. We have program managers in Intercom to help coordinate and make sure that we’re running things very well across functionally and mapping to our goals.

Des: Keeping sales and marketing in the loop about what’s happening etc.

Paul: Exactly. Keeping things running smoothly right across the company. It’s a bit of a secret sauce for us, I think. The program manager would run the Product Forum typically, and they’d record the decisions that are made and then disseminate them.

Usually the full team will be there. The engineers that are going to build the thing, designer, the PM, usually the PM would present, sometimes the designer would. That’s basically how it worked.

Mistakes to avoid

Paul: Then the cases where it didn’t work well, which happened, then we learned and iterated the thing along the way. We had bad Product Forums too. Usually they were in the form of no clear decision, ambles into chat, suddenly we’re critiquing whatever we want, suddenly it’s UI level polish feedback.

Des: Right, and we’re ripping up the decisions from two weeks ago and circling back.

Paul: Exactly, that’s absolute worst case scenario.

Des: There may be a different audience this time and they disagree with the last decisions being made, yeah.

Paul: The great things that you want to hear in a Product Forum are, “We don’t want feedback on that today.” “We’re not talking about X today.” “It’s too early for talk about Y.” Or, “Hey everyone, reminder, we decided two weeks ago to not do that. So we can either A: Put on a new agenda for a new Product Forum to talk about revisiting that decision. Or B: move on. Guess what? No one ever wants to revisit the decision. Nor should we, really, if we want to make progress unless something new has come to light.

End-to-End Reviews – holistic perspective

Des: As we get closer to launch, we move into the End-to-End Review, right? For us it’s both sides – it’s the go-to-market side, looking at everything from the advert a user clicks, through to the blog post, through to the landing page, to the podcast, the signup flow, the purchase experience, landing in a product for the first time, all the way through.

That’s like a Product Forum on steroids, but at the same time it’s mostly around what are the most important things that we need to change before this goes outside. You’re kind of sort of saying, “If you can live with it, you’re living with it, but if you literally think this is a stop-ship moment, raise an alarm.”

Paul: And to make sure that we don’t have gaps. By the way, we learned this the hard way.

“Your customer doesn’t experience the org structure, they experience the product”

Des: Every product company, I think, has gaps somewhere. There’s always a crack in the org chart somewhere.

Paul: As you well know, we’ve had a few corkers over the years, of missing key parts of this end-to-end experience.

Des: I remember we launched Acquire, as it was known at the time, and it was really well received by all of our new customers who signed up for it that day, but then all of our current customers were like, “How do I sign up?” And we’re like … “We forgot.”

We actually literally forgot how to let our current customers sign up. That’s an example of just being too deep in one area without taking the step out. That’s Intercom of four or five years ago. It’s a different company now, but I think these gaps exist everywhere.

Paul: Again, an often-quoted thing people say of course is that your customer doesn’t experience the org structure, they experience the product. If they do experience your org structure, that’s a bad thing. This End-to-End Review is designed to take that holistic, consistent, coherent view. “Does this thing seamlessly hold together?” Is the copy and positioning and language on the marketing site carried through at sign-up and onboarding and in the product? Does the product nav say the same thing as the marketing site?

Advocating for the user

Des: The one question I ask in End-to-End Reviews, and it never fails to yield some insight, is some version of, “What did the users say when we showed this to them?”

I remember with Product Tours, we were talking about the new user experience, and we were really, really happy with it. I was like, “Okay cool, it’s good that we’re all happy with it. But unfortunately, we are all the people who are literally the least capable people on the planet of independently evaluating this, because we all know what this is. Have we shown it to anyone who does not know what this is?”

And they’re like, grumbling, “Actually, we have two weeks left to go and we really … It’s an inconvenience to do so.”

I was like, “Well, the good news is we have a few hundred Intercomrades who probably don’t have a clue what this is. Can we start with them?”

The other thing, and maybe this is a slightly unique Intercom thing, is we really have two sets of users at all times. For something like Product Tours, we have the people who need to create Tours and put them live, and then separate to that, we have the people who experience Tours, which are our customer’s customers. We need to make sure we’re designing for both sides of the equation, otherwise we don’t get value, which means a lot of the research and the testing that we do to evaluate whether we are doing the right thing is two-sided. Sometimes those two sides can be at odds with each other. One person can say, “This is really interruptive,” and the business can say, “That’s great, because I really want to interrupt them.”

Avoiding silos

Des: When you’re sitting through the End-to-End Review, what are you most attuned to? What do you look for most?

Paul: I think the thing that I look for most is a thing that we historically do least well, which is obviously very specific to us. I imagine for other companies out there, your answer to this might be different to mine, but the thing that we’ve struggled with the most over the years is the jump from marketing to product. We have our website, which is owned by our marketing team and our brand design team, and then we have our product, owned by our product team. Our product team is in Dublin, London, and San Francisco. Our marketing team is in Dublin and San Francisco, but very often you have a team in San Francisco in marketing working with a team in product in Dublin or London, which exacerbates this problem in a sense.

“The easiest thing in the world when you’re all guns blazing, getting the thing out the door, it’s very easy to be siloed”

It’s a little bit harder to collaborate and work in a fluid way day-to-day, hour-to-hour, especially coming up close to a launch when you’re joining all these pieces together.

So the thing that we’ve struggled the most with is ensuring that the first use experience of Intercom, or of this new feature in Intercom, is really well thought through, very deliberately and thoughtfully designed in how it connects to both sides, on one end to the purchase experience or the positioning experience of the website; on the other end to the actual product itself, because different teams literally do those two different things.

The easiest thing in the world when you’re all guns blazing, getting the thing out the door, it’s very easy to be siloed. It’s faster to not have to really deeply think about the other pieces.

Des: In engineering terms, this is unit testing versus integration testing. It’s easier to just assume that a customer has dropped in your lap. The phrase that, I think it was Jakob Nielsen pioneered this idea of the scent of information. It’s the thing that I’m always most conscious can get dropped.

“The path to growing a successful company, of course, is repeat your successes and don’t repeat your mistakes”

The ad might have said one thing, and the landing page might indeed have said that same thing, but then after that it’s just totally gone, and you’re like, “Hang on. I signed up for this onboarding tool and now you’re talking to me about messages? What’s going on?”

It’s a recurring pain, but it’s something that I’m nearly hardwired to watch for. Ideally you want to see the same phrase, icon, or something in every single screen all the way along. That’s what tells you that your customers aren’t going to get lost.

Paul: For us these days, again, it’s a thing we’ve historically been not as good at as other things we’ve worked on, but the path to growing a successful company, of course, is repeat your successes and don’t repeat your mistakes. Sounds easy. If only. But we have made enough mistakes over the years to now really be attuned to it.

Des: Those are the two key meetings that we use to bring every single thing we release to light, which is the Product Forum for decision making, and then End-to-End for the final ‘holy shit, did we forget to do something here?’

That’s it for this week’s episode. Tune in again soon.