Hi and welcome to Intercom and Product with myself, Des Treanor, co-founder of Intercom, and Paul Adams, who's our Senior Vice President of Product. Over the time we've worked together, Paul and I have had countless conversations about things like... how to run a product org at scale, how to balance customer feedback on your product roadmap, how to spread a product first mentality throughout a company, how to maintain design excellence in a fast growing R&D team and so much more.
In this series, we're going to begin sharing some of these discussions with you on a regular basis, covering everything from industry trends, what's hot right now, all the way through to things like how are we embracing the rise of automation. So if you're a designer, product manager, engineer, researcher, or anything in between,
We think you'll find these conversations really valuable. You can subscribe to Intercom and product on iTunes, you can stream it on Spotify, or even just grab the RSS feed in your player of choice. Thanks for listening. Welcome to the 12th episode of Intercom on Product. Today, we're going to talk about the wonderful work of fiction that every product team has known as the roadmap.
I'm joined as ever by our Senior Vice President of Product, Mr. Paul Adams. Hey, Paul. Hey, Des. Today, we're going to talk entirely about roadmaps. Paul, I have loads of questions for you about roadmaps. Where do you want to start?
We have loads of thoughts on this. Obviously, we've changed how we run with Intercom time and again over the last, whatever, seven, eight, nine years. I think we should start at the beginning. I would love to hear... you know like almost like the founding story of road mapping and intercom if you like so you know prior to me joining so when i was like what age was intercom intercom was like about two years old when i joined and so like when i was first
You and the three other founders sitting on the desk. I'd love to hear a little bit about how you decided what to build. Yeah, it was every bit as scrappy as you'd expect.
There was like four of us and we had a long list of things to do. Curiously, when I look back at some of the photographs of the whiteboard, we used to just write down what we were doing every day on a whiteboard. That was like sort of V0. I'll talk through the iterations of that. We never bothered distinguishing like... company work.
from roadmap work if you know what i mean like the roadmap was kind of all the things that needed to get done in intercom so it would include like customer support along with like buying a domain name along with building a feature because it was just there was four of us and it was definitely that sort of chaotic sense
of everyone does everything the way we actually broke down our days was we had four founders myself own kieran and david and we would draw each of our names in a row and then we'd have a tree buckets of time every day morning noon and night effectively five days a week and we would literally allocate stuff to do in each of those periods so it would be like hey we're gonna add tagging this week so
Kieran's going to work on tagging on Wednesday, Thursday, Friday because Owen's designing it on Tuesday and David's going to work on it on Tuesday, Wednesday, Thursday or something like that. And it will be like kind of that ad hoc and that scrappy. And the next evolution of that...
was after our owners moved to San Francisco, we started getting into the habit of just mailing everyone what we were doing because obviously there was no central whiteboard anymore. I think we were also possibly in between offices. We were moving out of a university campus and into our sort of first real office.
So that the ritual was literally as you take your first sip of coffee, you send an email to the entire company of all four, five, six, seven of us. And you just literally list out, bullet out, what are you doing that day?
And it was a good, you know, there was some sort of useful discipline there. Like it was, I guess, akin to like what, you know, any of our current product teams do in their standup. But it was like, again, it would include everything. It wasn't just product specific. It was, you know, anything across the entire company.
And I think the main thing was, if there was any significant feature coming, unless it was something like a Rails upgrade or something like that, everyone knew about it and pretty much everyone worked on it together. It wasn't so much we had a roadmap. We had an agreement most weeks on what was the main feature we were adding to Intercom that week.
And that agreement would be like, one of us, usually me, would go and talk to customers and work out the bones of what the feature needed to be able to do. Owen would do visual design, Ciarán David, then later on, obviously, Dara would start to actually engineer it.
And then it would be live and we'd like kind of announce it via intercom and get the feedback and see if we got it right or not. You know, I think for early stage startups, I always worry when I see them being kind of quite over processed or over specced. I think that amount of agility, you could call it chaos, you could call it agility, depending on whether you're pitching or not. I think there's a lot of value in being able to turn on a sixpence and do the next thing.
in the early stages of product market fit you're still shipping stuff and you're looking to hit this sort of what i call like a vein of value in your customers you're like you're looking for something like we're like that's really powerful do more of that
And as a result, you can't really sign away too many future weeks because you don't know what you're going to learn this week. The other reason is the sort of the Lindy effect, this idea that the lifespan of anything is usually proportionate to how long it's lived already. And I think when you have a sense of a monthly burn and a limited amount of runway, like when you're staring at a nine-month maximum future lifespan of the company, unless good stuff happens.
The idea of coming up with a nine-month roadmap seems ridiculous because you should probably be trying to hit some sort of value in the next month or two. And that month kind of gets broken down to four weeks, which probably gets broken down to four features. And I can't say that this is like... Perfect. But what I would say is I would definitely err on the side of maximum agility and maximum capacity to act on learnings.
than I would on ruthless productivity by having a long-term future-facing roadmap that describes everything that everyone's going to do over the next year. Because as an early stage startup, you just don't have a clue.
So that's like the limited amount of structure we had until... the stars aligned and we brought on board one of silicon valley's most wanted product people mr paul adams and i think like when you joined we had just raised a series a and the idea of the future being like so uncertain was kind of de-risked a little bit we knew we just raised i think five and a half six million dollars so we knew we had at least a couple of years in us so
at that point it became more of like well there's going to be we're going to start hiring more people i think you know maybe were you like the 13th or 15th person or something yeah 13th yeah yeah that's a good memory does and like once you start obviously adding more heads you need to have a more structured way of getting
these people to work together also for the first time you're probably not all working on the exact same thing which means you have more than one thing landing in the product at the same time which means you need some amount of like some sort of grand central instructor who makes sure that you don't code across each other or add features that contradict each other.
And lo and behold, this means more than one person agreeing on what's happening and more than one thing happening, aka a roadmap. And that was probably one of the things you invested your time in earliest. So I guess I'd hand back to you and say like, What was your perspective on roadmapping coming in and what did you see that you needed to add in for, say, a 13 to, say, 30-person Series A startup? Yeah, it's fascinating listening to you talk about those early days.
because one thing that strikes me uh i'll get to your question in a second because i came from facebook where it was a completely different you know animal to intercom obviously at the time but it's interesting to hear that the life you led in the early days as you said, like wasn't road mapping explicitly, but actually like the tasks you did, your daily tasks, your calendar planning, everything was kind of like merged into one activity, you know?
And it's funny to think about that because I think, like you said, you know, you kind of get wary of early stage companies and startups who are over process oriented. You could probably read a lot into whether they are. from looking at their calendars and, and so on. But, um, yeah, it was fascinating to come in because I'd never worked in a startup before intercom. You know, I'd been at Facebook for a few years and before that I was at Google for a good few years. And so.
They were both big companies when I joined them. I think Google had about 8,000 people when I joined. Facebook was about a thousand from memory. I can't actually remember. It was about a thousand. So it was still relatively big and Intercom was like, as we said, whatever, 12 or 13 people. And I remember at Facebook, one of the things that I was really impressed by at the time, and we're going back now to like 2011 era. Good Facebook as it's known.
No comment. I was having a great time there for sure. Back in 2011. But I remember Doug used to talk about two timelines and... from memory it was roughly six months and 20 years which you know was kind of amazing to think about that that even back then you know the timelines that mattered were
the kind of epic change we want to bring about in the world over a period that will transcend like the reign of different governments and all sorts of stuff. Yeah. But then six months, it's like, okay, that's the dream. That's the vision. And what's the next six months going to look like? And I remember when I was a PM there, we used to do kind of six and 12 month roadmaps. So I'd make a roadmap for the next six months, every half.
And then you'd have to have a view on the second six months as well. And then actually from memory, it was annual planning. So we did it each year, I think. So obviously, that's completely different to Intercom. And I remember when we came in, yeah, we raised the Series A or what you guys raised the Series A and I inherited the success of that. We started hiring teams.
And I remember we hired four, we put in place a new structure because originally when I came in, we just had like all of us were still kind of in this amorphous kind of blob, you know, building and working together. But then we brought in like four teams, so four product managers, four designers.
etc etc so yeah we started looking at time and thinking about time and the question i think we debated back then was what's the right timeline for intercom so we've got to move beyond the like you know three kind of three four five yeah plan you had to something that wasn't facebook time it wasn't 20 years and even six months for intercom then was kind of a long period of time to look into the future
And so I remember we settled, I can't remember the exact time this happened, but I think it was about a year maybe after I joined, we settled on the 666 roadmap, where it was the next six weeks, the next six months. And then the next six years, we kind of said like, hey, six years is a timeline around which we could have a vision and a dream, but we need a six month plan.
But six months for us is still quite a long way into the future. Yeah, it's probably still like, you know, I'm going to guess like maybe a sixth of the lifespan of the company or something. Right, exactly. Exactly. Yeah, exactly. I guess the company was probably like three years old at the time. So six weeks was our kind of our version of the Facebook six months. Yeah. The pragmatic. All right. This is actually happening. So we need a view beyond this week.
But, you know, in week two and three and four, and then we were very goals oriented always. I think, you know, it sounds like before I joined you and the other founders were very goals oriented to daily, you know, sub-day goals. And so like, okay, six weeks, what are our goals? What does success look like? So even back then, I think we're quite outcome focused in terms of like a successful six weeks looks like X. Yeah.
I will say like, and it's rare for me to compliment you on this podcast, but I think one of the things you did that really helped land the, how would you say, like the specificity and maybe like introduction of a bit of rigor. of like say six weeks was you also brought in these uh how would i say like long-term vision statements like i remember we had posters in the office saying things like all businesses will become internet businesses or the future of
customer service will look more like the past than the present or like the internet is still younger or like i remember you you produced a lot of these there you probably remember they were like helvetica just black and white posters they were like in our canteen but i think like it kind of
And let people accept that like, hey, this might feel like pretty restrictive in the sense that like for the next six weeks, we're being quite rigid and making sure we ship tagging or something like pretty minimal like that.
But you gave us a kind of a broader perspective that let us join the dots between today's work and the work that we were doing on the sort of... the long-term horizon of the internet and i think that mattered because i think it let everyone buy into the idea that we need structure we need roadmap we need to be moving fast because like you know we had this sort of epic horizon where where we were making these kind of bigger, more visionary statements.
If ever you were bored by like working on merge users, you could look up at a poster and remember like, well, merge users is one step of a million steps that we're going to make towards this epic change we're going to make on the internet, which we obviously still hope to make. But I do think for like, I guess the repurposable advice.
there is like for early stage startups who are who are maybe feeling any sort of resistance about moving to a bit of rigor and a bit of like let's say efficiency it helps If there's a big, meaty, long-term mission with like strong statements attached to it, that can kind of help the roadmap resonate. End of compliment. Yeah, thanks, I'll take it. I have to say, I learned that at Facebook, I think.
You know, the idea that being that you have to balance the pragmatic, work hard, execute nature, like Facebook were excellent at executing. I remember that from the culture back then too, like really phenomenally efficient organization. really excellent executing and they had this exceptionally good balance of like selling the future with the like just kind of more mundane tasks you might have to do day to day but i think one of the big things for me then too was
I think some of these statements that Facebook had at the time, and then, you know, that we started to create an intercom, they're kind of beliefs, you know, there are things like things we believe about the future. And it's like, okay, well, if we believe these things are going to happen.
we may play an important role in making them come to pass or might benefit from them if we set ourselves up well, you know? So like the idea that you need both, I think is really, really important, especially in the earliest days. Well, actually... I think it's still true today. And I think if anything, a few of us perhaps take it too much for granted that everyone knows. As you know, recently we started talking about like within our most recent all hands for our product org, we started...
revisiting the company mission because you kind of realize you can accidentally slip away from it and like especially when you start celebrating the efficiency and productivity of your org you can definitely forget that all of that only matters because it serves this this greater purpose or this longer term timeline
Just before we continue with today's show, you might have heard that Intercom hosted an AI customer service summit called Pioneer recently, where visionary customer service leaders explored the impact and opportunity of AI. You decided to test out AI. How's it been going? Has it helped? It's been great. We're seeing a reduction in our handling rates as well, so it's been very beneficial all around. Customer support.
will always in my opinion exist. The way in which it exists will start becoming different. Well, now you can watch all of the conversations that took place. Just go to events.intercom.com. That's events.intercom.com to learn how you can benefit from this technology today. Okay, back to the show.
Tell me this, as it gets, like, how would I say, more complicated, roadmapping gets hard. And by more complicated, usually it means that there are, you know, in the early days, roadmapping is something that you do just to make sure that everyone knows what's going on. In most product-led startups or product-led growth startups, everyone is basically the product team or the R&D team, designers, engineers, PMs, et cetera.
once everyone else shows up by everyone else let's just say sales marketing finance support you know you name it there are now lots of people who care a lot about what the hell is going on within the product org because they're all downstream of it and they all
either benefit from it, succeed from it or suffer from it or struggle with it. Like, you know, I don't think we got this right in the early days, but how would you sort of advise younger companies to think about roadmapping once there are non... how would you say, non-R&D, non-engineering functions showing up with a curious eye on what's going on? It definitely gets complicated, that's for sure. So, you know, the kind of era we were talking about there, the 666 era.
I think that might have lasted for maybe two years or so. But I remember I wrote a blog post back then. And even then, when we were executing that, we knew it wasn't perfect. And even the six year stuff was quite hand wavy. You know, like we believe this will happen in the future and therefore blah, blah, blah. So it is quite hand wavy. And I think back then, like I remember writing a blog post about it. It's on the blog still somewhere.
And at the end of the post, it says, hey, if you're reading this, it's probably changed by now. You know, because this thing was in a constant state of evolution. And like you kind of touched on there. different things change. So one thing that changes is the product and engineering team just got bigger. And so with that bigger team, you get more diversity of thought, which is often a great thing.
but just more opinions and more people and different backgrounds as well, different styles of producing software. Yeah, exactly. Yeah, exactly. And so the diversity of thought there is generally beneficial to the company. But still the company has a mission and a vision and a plan to kind of keep everyone aligned, keep them together and so on. So that was kind of one, that's one challenge, just the internal product engineering teams themselves. And then you have like the...
Other functions, you know, so when I joined Intercom, we'd know sales team and we started a sales team at one point and it was small and then it grew. And it changed and its culture changed over the years too. And now it's much bigger than it was back then. And so if sales represents the voice of the prospective customer in a road mapping process.
The voice of sales will completely change over the years. I don't want to say like it'll get better or get worse or that can completely depend on the company and the sales team and the product engineering teams and their relationship. But it definitely changes. And what was really important for us, I think we learned this the hard way, was that you need to build a really strong partnership between these functions.
Because they all kind of represent an important voice, you know, like sales is the prospective customer. You might have your customer support team who it could be the voice of the existing customer and sometimes people closest to it. You've got marketing representing the voice of the market.
And so there's a lot going on and a lot of different stakeholders now. And so it's absolutely the case that it gets more complicated. And I think the thing we did well was... put in place process around this you know like like not too much process again going back to you that you can have too much process for your for your stage but just enough to kind of keep these different voices of different
constituents in the folds when roadblocks were created. I think there's a key thing there which is all of these forces are both inputs to what you should build and we can talk more about that in a little bit. And they're also on the receiving end of the roadmap. So on one hand, you want to hear from sales about why they can't close deals. And on the other hand, sales need a roadmap to close deals. So they're going to receive the output.
Marketing can provide voice of the market or the landscape or competitive analysis, but also they need to market the hell out of the stuff that's coming down the line. Finance allocates your costs, but finance also model the impact of what you do.
support tell you what's broken and then they need to know what's going to get fixed and then like we even like you know amongst all those as you bring in all these maybe audiences isn't the right word like partners is probably a better word because it is a give and take it's tempting then to forget about the actual the product team themselves who both have ideas about what should be built
otherwise you wouldn't want them here but then on the flip side they're also they need to be inspired by whatever's on the roadmap as well like they need to look at the roadmap and they just can't see like 78 iterations of our Salesforce plugin. There needs to be something there that has them able to join the dots between the visionary statements on the posters on the wall and the work that they're doing today. And if there's nothing there that helps them kind of...
build that bridge it's a tough road map to like to get people excited by so i think like the lesson for me is you know i think we were probably slow to do it i think certainly in my mind Like there was nearly a novelty to having more than one group to tell about the roadmap.
Today, I think it's much more we need to get out there and make sure that everyone knows, hey, roadmapping's coming up. Here's the things we'd love to hear. Here's the areas we think you need to be experts. Here's what we'd love to get from you in whatever form you can share. And then we're going to bake all this in.
And then we're going to come back to you and tell you what the roadmap is. And if it doesn't look exactly like you hoped, we're going to explain why that is. So do you know, so that you can still buy into it. The one area where I think most people start to get a extreme fear. is when you end up with public roadmaps or rather customer facing roadmaps. What's your thoughts on those? Before we get into that for a second, just on the prior point there.
I think the word partnership is the best word. At least that's my kind of current thinking on this stuff. You know, just last week, for example, we had a leaders offsite here in the company. and we were the kind of workshops we ran one was like better partnerships between product engineering and sales another one was like better partnerships in product engineering and marketing we've always had a good one with support actually and maybe that's because you know part of our
product lineup is actually the software for support teams but the yeah so that evolution has been interesting and i think like you said it has been slow we are we have been slow on the product engineering side and i suspect like a lot for lots of people listening to the podcast. They, like us, are probably a product-focused company, a product engineering-founded company. The product and engineering team are kind of the earliest employees and a lot of the gravity.
an influence might sit with the with those folks um they might have different people listening where the company was founded by salespeople or marketing folks, and they may have a different kind of gravity and influence. They're not listening to our podcast. Yeah, maybe not. Thanks for the reality check. If you are out there, hello, welcome. I'm thrilled that we've attracted such a diverse audience, but I suspect it might not be true. That's true, yeah.
So the partnership thing is something I really encourage people to embrace as early as possible. Even almost like when you think it's almost too early, that's probably the right time because you're kind of counteracting your biases. But it also...
for me brings up ownership too. And we can kind of come back to this in a sec. Like the ownership piece matters because I think in the early days with the sales partnership, for example, it wasn't really a partnership. It was like, we listened to sales and we said, Hey, all right, thanks for the feedback.
We'll think about it. See it. You know, I don't think paid anywhere near enough respect, maybe or whatever, you know, attention certainly to the idea that the sales team actually need to go, like you said, sell this. And so it should actually be a full two-way street. And so the ownership piece comes up because if you want your sales team, for example, to really help you with really great inputs into your roadmap and really understand customers.
That's a load of work for them. And they've other things to do, like actually sell. Yeah, it's also work they're not incentivized to do. Like, I think one of the things that people don't understand is like, generally speaking, people do what you pay them to do. And in the general...
Like no one talks to the sales org in most companies and says one of your jobs is to improve the quality of the product by making sure that we all understand what the needs of our customers are. But it's a huge, like it's hugely important. just possibly not discussed enough and it's especially we even feel this tension like when it comes to like end of quarter and you're like hey i'm looking for a reference customer to try out the new series beta on
They're very justifiably saying, not right now, Des. And it makes a lot of sense. But you need to make sure that you're aligned with sales leadership. This is a thing that will really, really matter long term. but it will look a little bit like expensive or a time suck in the short term. Yeah. And to go back to the ownership piece, I think this matters too. The sales team need to feel like they're part owners and co-owners of the roadmap.
And same for the support team, marketing team, like the design team, engineering team, because the PM, the product management team are typically the people who drive the creation of the roadmap. And I think in the worst versions of that world. They think they are the owner and it's their job to create this great roadmap. And they must, you know, mostly do it themselves. And honestly, some cultures, you know, kind of propagate that idea.
It's a kind of like PM, a CEO type thing. Yeah. Whereas we are not at all like that. And I would advocate that companies should not set themselves up that way. And instead, the PM who absolutely should be opinionated, very opinionated about their product and really in tune with what their customers of their part of the product need, but that they're also an excellent facilitator and collaborator.
And so all these functions feel co-ownership or at least part ownership of the roadmap. Why is it so hard or why is there so much anxiety about bringing a roadmap out to customers and saying, here is what we are going to build in the future? Yeah. So, you know, one big thing is that you're committing your future resources. And so you're kind of removing optionality. That's a huge piece of it for me.
But by the way, I think it's, I think it's good. Like we have a kind of a customer version of a roadmap. Our sales team kind of talk customers through and so on. And actually, and then that becomes a much deeper partnership with our customers and our sales team. And that's a better world too, especially if you're like us and you're a B2B company. But obviously the minute you say to a customer, we will deliver X, well, you better. And so now you're suddenly...
Committed, sometimes committed to dates. You know, sometimes you might say publicly, we will deliver X by Y. Sometimes that's in response to customer demand. Like, hey, if you don't build X by Y, we're not renewing or whatever. Yeah. So there's real pressure here, but it just removes optionality and then commits you. And so back to the kind of vision stuff, back to the posters on the wall and what you believe in.
things you wanted to change, you want to create in the world that you just believe in. If you, the more you commit publicly, the more optionality you remove to do that stuff. I think the one piece of advice I've given to other companies who are like probably, you know, series BC like stage where like they have real customers and real customers accounting for like.
non-trivial amounts of their revenue such that they actually do take it quite seriously. It's just you can't give away the... the majority of the capacity in your org because otherwise you'll be executing a strategy and hoping to god you don't find anything that contradicts what you believed when you set it in motion
So, you know, so a big fear I would always have is, and I've seen this happen with like large companies, large successful companies, is that you write up a sort of like one year or like one and a half years worth of road mapping, or you write up this like... epic feature release and maybe you go and announce it you pre-announce it you see that you like i remember being at a at a conference where the ceo was like literally showcasing this thing that had not had a line of code written in it yet
They'd actually hired a graphic design agency to build a mock-up UI to show off what it might look like. And I think if you're basically hard committing that much resources with that little visibility ahead... You're hoping that nothing changes. Your competitors don't change. Your customers don't change. Demand doesn't change.
The norm doesn't change. Stuff like browser technology, iPhone versions, like there are so many things you literally don't know about. And yet here you are throwing away the majority, potentially throwing away the majority of your R&D or your product design engineering resources. all on one thing that may or may not be a hit. And in the case of that example, I think it was two years later that the feature was finally released to the public. Obviously...
The worst part was, what do you think they did at all their events in between? They just promised more shit. So you kind of have like a product team relegated to working on yesterday's promises tomorrow, which is a really scary place to be. Okay, let's try and wrap up on a few different sort of more grounded and tactical things. One for me is...
If you're trying to think about getting your roadmap right, or if I dropped you into a different product org tomorrow and you were to have a quick look at the roadmap itself, generally, I'm sure you'd take your usual framework of inputs, outputs, and outcomes.
and you'd analyze like what's going right and what's going wrong here talk to us about like how do you think about the inputs what are the right teams to have involved and what are you looking out for as you kind of evaluate the roadmap system Yeah, so we do have a system and it's evolved over the years. So this thing, and it's changed, it looks a lot different to how it did, you know, five, six years ago when we kind of first started doing this in earnest.
And it's kind of funny, you know, as a side note, if you, if you show, I think if you showed us, you and I, Des, if you showed us five years ago at the intercom of today. we'd be like oh my god what happened you know so much has changed uh and the inputs and stuff has changed and the relationship with different functions has changed you know we i remember i remember
saying like we will never have any kind of customer facing roadmap. That's a really bad idea. You know, and now we do that in different kind of small ways. So back to the kind of the piece about balance. you know, like I'm back to the Facebook idea of the 20 years and six months and back to the 666 idea that we had a few years ago. There's definitely a really important balance between
reserving space for the stuff you want to build, you know? So, you know, I hope most companies listening know what their kind of mission for the company is. That is the reason the company exists other than to make money. and have a vision for the future that looks better than today and is a reason that people would buy your product in the future because you're differentiated in some interesting new important way and then that's kind of one side of it and then on the other side
These days, we have a pretty rigorous process, which always needs improving, but it's relatively rigorous. You know, if you look back over the years, we've developed a kind of comparing this to ourselves around like pulling in feedback from customers. putting in feedback from prospective customers, things like surveys, NPS, churn, customers churn, you know, what happens there? What do they say? Why did they quit? Can we remove those reasons for people to quit in the future?
uh product satisfaction we do outcome reports for all projects these days which kind of looks at the metrics that we set success metrics and so there's there's kind of two halves to this or two sides certainly it's not really 50 50. One half is the kind of your strategy, the things you want to build, making sure you've protected roadmap time or, you know, developer time really to go and build the stuff that you believe in and have conviction in.
I want to take some bets on because you have a vision for the future. And then all the kind of stuff that you just know is going to help you drive revenue, keep the company healthy, give you that future, that longer term future that you can kind of invest in.
yeah i think the the tension there is like the balancing of like sure shots and big bets like the some stuff you just know will work but it's usually not going to be like there's like generally tends to not be any like multi-billion dollar i know this will work type ideas they generally tend to be
come in the form of high risk, high reward. That kind of brings me to the last topic that maybe we'll close out on, which is just road mapping is a process ultimately. And all process exists to try and find common standards. common quality in terms of output. But the risk I think you run into the more specific and highly instrumented you get is that you maximize productivity or throughput or delivery in this case.
at the expense of creativity like creativity is in a sense inherently inefficient because you have to try things and not all things work which means you need to accept that like you'll build some stuff that you'll throw away And that needs to be accounted for in how you think. So a question I often come to when I see any process in Intercom or in fact in any company is just what's the downside of this process? Because I think...
A real fear I have is when most people look at this sort of, when they introduce a process, it's usually a reaction to a cut. Like it's a reaction to, oh, we got this wrong or hey, Johnny shipped this and he shouldn't have shipped it or whatever.
And so they're like, all right, we'll add a step called should Johnny ship this to the process. And next thing you know, you've got like 27 checkpoints before something can go live, which ultimately hurts efficiency, which ultimately hurts leverage. And because of all that, I think the risk is... you guarantee a minimal standard at the cost of a high standard. And it's a dangerous place to be for any company, frankly. But I'd say especially a startup that's claiming to disrupt the status quo.
by building faster and making more cool stuff people wouldn't have seen coming. If you have this meat grinder process that beats the shit out of any creative idea and guarantees that everything comes out pretty vanilla.
but at the same time, every hour was spent effectively. I think that's like, it's classic small company behaving like a big company, but it's also, I think it sows the seed of your own disruption because you're no longer capable of coming up with new ideas because it's not safe to do so.
thoughts yeah i agree with that i think it's really important it's actually just as you were talking there i was reminded that we here at intercom completely redesigned our roadmap process over the last six months well six to 12 months maybe but we kind of started rolling it out a few months ago and we kind of had a ground up rethink just as a exercise and making sure we weren't falling into that trap ourselves and the number one thing we did we made a whole bunch of changes but
The number one thing we did was we removed loads and loads of detail, you know, loads of specificity we took out. And so the, you know, the roadmap process we have is based on principles we believe in.
And so over the years, we've kind of added in, based on those mistakes, like you mentioned, kind of added in stuff because we're trying to manage risk. We're trying to avoid making the same mistakes again. We're trying to make sure that like... you know we're an efficient org and so on but teams you know we're hearing a lot of feedback that it was just too too prescriptive too narrow and not giving people enough autonomy or independence to really kind of
form their own path for the parts of the product that they own. So the biggest change you made was removing all of that detail. So I guess like, you know, the kind of point there is... the if you're kind of talking the talk there we did actually walk the walk over the last kind of six months i think the interesting inflection point is uh early early on you or me or any of the product leadership
was so close to the customers and so close to the actual customer support team and the actual words that are being written in about the features we release that you have this kind of tacit knowledge on tap. And then as like the layers arrive, as in, you know, you go from being a manager, you know, from being like a manager of managers to a manager of directors of managers and groups and the distance between product leadership and the actual front line.
gets ridiculous to the point that the best ideas are going to come from the group level or the PMs themselves. And a process that's designed that assumes that Paul has some superpower in a world where Paul isn't in touch with customers anywhere near as frequently as, say, the actual frontline PMs. It's just a broken process. And I think that was the thing for me.
that really twigged it for me was just seeing that I actually haven't a clue how half of our platform integrations work and I don't know who uses them and why. And so even the idea that my opinion should matter on what we do there.
is kind of ridiculous at this stage. I definitely know who our big customers are and I definitely invest my time with them. But when you actually get into the specifics of what's important in a product, you're much better off delegating the creativity to the frontline, which basically means giving them enough.
rope to do what they want to do versus thinking that like everything still needs to filter through your hands because you just don't have that knowledge that the process assumes you would have yeah yeah 100% Anyway, that is everything on roadmaps. There is a lot to it. It's probably like it is the sort of the fundamental art form of a PM because like it's funny, like designers can post shots to Dribbble and developers can post stuff to...
github or they can open source their code pms are really not left with an awful lot of like artifacts that they can point to proudly because in a sense they all kind of disappear and get turned into into like real things like actual software but i think the one thing every pm
badly needs to like have a strong grip on is how where when and why they roadmap how it works who's involved what goes in what goes out how do they follow up how do they make sure that the outcomes become inputs all of that sort of stuff
And that's what we've been talking through today and in fact, over the last few episodes. But I think we'll leave it there for today. Thank you as ever, Mr. Paul Adams. Thank you, Des. And I've been Des Treynor and this has been Intercom and Product. Thanks for listening. Take care. Thanks for listening to the Intercom on Product podcast. For more content, go to our blog at intercom.com slash blog or subscribe to the podcast on iTunes, Spotify, SoundCloud, or Stitcher.