Intercom on Product: One for the roadmap

On this episode of Intercom on Product myself and Paul Adams, our SVP of Product, take a look at roadmapping. We discuss how we’ve approached it historically at Intercom and how this process has evolved with us to make room for a wider audience.

If you’re setting out on your roadmap journey it’s important that it reflect the point of the journey that you’re on – having everyone in a startup of 5 or 6 sharing daily tasks each morning makes sense as they work together to build a feature but in a larger company it’s a recipe for chaos. Knowing how and when to define a roadmap, who to include and how long to plan for are key elements to finding the balanced approach that you need.

If you’re short on time, here’s a few quick takeaways:

• The time horizon for your roadmap should be proportional to the age of your company. Intercom’s earlier roadmaps were reflective of where we were at the time – taking each week as it came.
• As you grow functions, the audience for your roadmap widens. Sales, marketing, finance, support, and R&D all use the roadmap for different thing. Sales want to sell it, marketing needs to plan for it, finance needs to model it, support needs to be able to explain it, and R&D needs to be excited about it.
• Once you start talking to customers and they start buying your product on the basis of what’s coming around the corner, you’re starting to lose a lot of agility. It’s tricky to successfully coordinate a customer-facing roadmap.
• Balance is a key element to navigating a roadmap – between customer-facing and internal, creativity and productivity, between different functions. Getting this right allows your teams to work in lockstep together.

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: 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.

Paul: Hey Des, glad to be here.

Des: Today, we’re going to talk entirely about roadmaps. Paul, I’ve loads of questions for you about roadmaps. Where do you want to start?

Paul: We have loads of thoughts on this, obviously, we’ve changed how we roadmap Intercom time and again over the last seven, eight, nine years. We should start at the beginning. I would love to hear almost like the founding story of roadmapping at Intercom prior to me joining. Intercom was something like two years old when I joined. So when it was first you and the three other founders sitting on a desk, I would love to hear a little bit about how you decided what to build.

Intercom’s early roadmap

Des: It was every bit of scrappy as you’d expect, there was like four of us, 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 write down what we were doing every day on a whiteboard. That was V0, and I’ll talk through the iterations at that. We never bothered distinguishing company work from roadmap work – the roadmap was all the things that needed to get done at Intercom. It would include customer support, along with buying a domain name, along with building a peak feature, because there were four of us and there was that sort of chaotic sense of everyone does everything.

The way we broke down our days was: we had four founders, myself, Eoghan, Ciaran, and David, and we would draw each of our names in a row and then we’d have three buckets of time every day, morning, noon, and night, 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 going to add tagging this week. So Ciaran is going to work on tagging on Wednesday, Thursday, Friday, because Eoghan is designing it Tuesday, and David is going to work on it Tuesday, Wednesday, Thursday,” or something like that.

And it would be that ad hoc and that scrappy. The next evolution of that was after Eoghan had moved to San Francisco, we started getting into the habit of just mailing everyone what we were doing because there was no central whiteboard anymore. I think we were also possibly in-between offices – we were moving out of the university campus and into our first real office. So the ritual was: 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 literally list out, bullet out, what are you doing that day.

“I think for early-stage start-ups, I always worry when I see them being quite over-processed or over-specced”

And it was some useful discipline there. It would include everything – it wasn’t just product-specific, it was anything across the entire company. And I think the main thing was: if there was any significant feature coming, unless it was a Rails upgrade or something like that, everyone knew about it, and pretty much everyone worked on it together. So it wasn’t so much that 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 that 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. Eoghan would do visual design; Ciaran, David, and then later on, Darragh, would start to engineer it. And then it would be live, and we’d announce it via Intercom and get the feedback and see if we got it right or not.

I think for early-stage start-ups, I always worry when I see them being quite over-processed or over-specced. That amount of agility – you could call it chaos, you could call it agility, depending on what you are pitching –, I think there’s a lot of volume being able to turn on a sixpence and do the next thing. Because 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 a vein of value in your customers. You’re looking for something like, “Shit that’s really powerful, do more of that.” And as a result, you can’t sign away too many future weeks because you don’t know what you’re going to learn this week.

“I can’t say that this is perfect, but what I would say is I would definitely err on the side of maximum agility and capacity to act on learnings”

The other reason is the Lindy effect, this idea that the life span of anything is usually proportionate to how long it’s already lived. When you have a sense of monthly burn and a limited amount of runway, when you’re staring at a nine-month maximum future life span 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 value in the next month or two. And that month gets broken into four weeks, which probably gets broken into four features. I can’t say that this is perfect, but what I would say is I would definitely err on the side of maximum agility and capacity to act on learnings than I would on ruthless productivity by having a long term future-facing roadmap that describes everything that everyone is going to do over the next year. Because as an early-stage start-up, you don’t have a clue.

That’s 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 that when you joined, we had just raised a Series A, and the idea of the future being so uncertain was de-risked a little bit. We had just raised five and a half, $6 million, so we knew we had at least a couple of years in us. So at that point, it became more of, “Well, we’re going to start hiring more people.” Were you like the 13th or 15th person?

Paul: 13th, yeah.

Finding the time(line)

Des: That’s a good memory. Once you start 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 sort of grand central instructor who makes sure that you don’t code across each other, or add features to 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. What was your perspective on roadmapping coming in and what did you see that you needed to add? For like a 13 to, say, 30-person, Series A start-up.

Paul: It’s fascinating listening to you talking about those early days. As you said, it wasn’t roadmapping explicitly, but your daily tasks, your calendar, planning – everything was merged into one activity. I’d never worked in a start-up before Intercom. Being at Facebook for a few years, and before that, I was at Google for a few years, and they were both big companies when I joined them – I think Google had about 8,000 people when I joined, and I think Facebook was about 1,000, so still relatively big. And Intercom was, as we said, 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 the 2011 era…

“I remember Zuck used to talk about two timelines, roughly six months and 20 years. That’s the dream, that’s the vision. But then, what are the next six months going to look like?”

Des: Good Facebook, as it’s known.

Paul: No comments. I was having a great time there, back in 2011. I remember Zuck used to talk about two timelines, roughly six months and 20 years. It was kind of amazing to think that, even back then, the timelines that mattered were the kind of epic changes you want to bring about in the world, over a period that will transcend the reign of different governments and all sorts of stuff. That’s the dream, that’s the vision. But then, what are the next six months going to look like? And I remember that when I was a PM there, we used to do six and 12-month roadmaps. So I’d make a roadmap for the next six months, and then you’d have to have a view on the second six months as well.

So obviously, that’s completely different from Intercom. And I remember when we came in, we’d raised the Series A, or you guys raised the Series A and I inherited the success of that, we started hiring teams. And I remember we put in place a new structure, because when I came in, all of us were still in this amorphous blob, building and working together. But then we brought in four teams – four product managers, four designers, et cetera.

So we started looking at time and thinking about time. And the question we debated back then was, “What’s the right timeline for Intercom?” We needed to move beyond the three, four, five plan you had to something that wasn’t Facebook time, it wasn’t 20 years. And even six months, for Intercom, was a long period of time to look into the future. And so, I think it was about a year after I joined, we settled on the six, six, six roadmap, where it was the next six weeks, the next six months, and then the next six years. We kind of said, “Hey, six years is a timeline around which we could have a vision and a dream, and we need a six-month plan, but six months for us is still quite a long way into the future.”

Des: It’s still probably, I’m going to guess, maybe a sixth of the lifespan of the company.

Paul: Right, exactly. I guess the company was three years old at the time?

Des: Yeah.

“Six weeks was our version of the Facebook six months. So we need to view beyond this week, and week two, and three, and four”

Paul: Six weeks was our version of the Facebook six months. So we need to view beyond this week, and week two, and three, and four. We were very goal-oriented, always, and before I joined you and the other founders were very goal-oriented too. And so, it was like, “In six weeks, what are our goals? What does success look like?” So even back then I think we were quite outcome-focused.

Des: I will say, 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 specificity and the introduction of that rigor of six weeks was that you also brought in these long-term vision statements. 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 “The internet is still young.” I remember you produced a lot of these, you probably remember, they were Helvetica, just black and white posters in our canteen. But I think it let people accept that “Hey, this might feel pretty restrictive, in the sense that, for next six weeks, we’re being quite rigid on making sure we ship tagging or something pretty minimal like that,” but you gave us a broader perspective that let us join the dots between today’s work and the work that we were doing on the long-term horizon of the internet.

And I think that mattered because it let everyone buy into the idea that we need structure, we need a roadmap, we need to be moving fast. Because we had this epic horizon where we were making these bigger, more visionary statements, that if you were ever bored by working on merge users, you could look up at a poster and remember, “Well, merge users is one step of a million steps that we’re going to make towards this epic change on the internet.” For early-stage start-ups who are maybe feeling any sort of resistance about moving to a bit of rigor and a bit of efficiency, it helps if there’s a big meaty long-term mission with strong statements that can help the roadmap resonate. End of compliment.

“Facebook was excellent at executing, they had this exceptionally good balance at selling the future with the more mundane tasks you had to do day-to-day”

Paul: Thanks, Des, I’ll take it. I have to say, I learned that at Facebook, I think, the idea that you have to balance the pragmatic, work hard, execute nature. Facebook was excellent at executing, I remember that from the culture back then too, a phenomenally efficient organization. But they had this exceptionally good balance at selling the future with the more mundane tasks you had to do day-to-day. Some of these statements that Facebook had at the time, and that we started to create at Intercom, they’re kind of beliefs, they’re things we believe about the future. And it’s like, “Okay, 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.” The idea that you need both, I think, is really, really important. Especially in the earliest days. Well, actually…

Des: I think it’s still true today. As you know, we’ve recently started revisiting the company mission. Because you realize you can accidentally slip away from it. And especially when you start celebrating the efficiency and productivity of your org, you can forget that all of that only matters because it serves this greater purpose or this long-term timeline.

Tell me this: As it gets more complicated, roadmapping gets hard. In the early days, roadmapping is something that you do to make sure that everyone knows what’s going on. And everyone, in most product-led start-ups, everyone is basically the product team, or the R&D team – designers, engineers, PMs, et cetera. Once everyone else shows up, and by everyone else, I’ll say sales, marketing, finance, support, 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, suffer from it, or struggle with it. I don’t think we got this right in the early days, but how would you advise younger companies to think about roadmapping once there are non-R&D, non-engineering functions showing up with a curious eye on what’s going on.

Allowing for greater footfall on your roadmap

Paul: It gets complicated, for sure. The kind of era we were talking about there, the six, six, six era, I think that might have lasted for maybe two years. 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. We believed this will happen in the future and therefore blah blah blah. And I remember writing a blog post about it, and at the end of the post, it said “If you’re reading this, it’s probably changed by now.” Because this thing was in a constant state of evolution. Different things change. One thing that changes is that the product and engineering teams get bigger, and with a bigger team, you get more diversity of thought, which is often a great thing, but just more opinions and more people and…

Des: Different backgrounds as well, different styles of producing software.

“Diversity of thought is generally beneficial to the company, but the company still has a mission, a vision, and a plan to keep everyone aligned”

Paul: Exactly. Diversity of thought is generally beneficial to the company, but the company still has a mission, a vision, and a plan then to keep everyone aligned, keep them together, and so on. So that’s one challenge, just the internal product engineering teams themselves. And then you have the other functions. When I joined Intercom, we had no sales team, and then we started a sales team, and it was small. Then it grew, and it changed, and it’s culture changed over the years too. And now it’s much bigger than it was back then. Sales represents the voice of the prospective customer in a roadmapping process, and the voice of sales will completely change over the years.

What was really important for us, and I think we learned this the hard way, was that you need to build a really strong partnership between these functions, because they all represent an important voice. Sales as the prospective customer, you might have your customer support team who could be the voice of the existing customer, you’ve got marketing representing the voice of the market…There’s a lot going on, and a lot of different stakeholders now.

And so, it’s absolutely the case that gets more complicated. And I think the thing we did well was putting process in place process. Not too much process, going back to the idea that you can’t have too much process for your stage, but just enough to keep these different voices of different constituents in the fold when roadmaps were created.

Des: All of these forces are about inputs to what you should build, and they’re also on the receiving end of the roadmap. So on the one hand, you want to hear from sales about why they can’t close deals, and on the other hand, sales needs a roadmap to close deals, so they’re going to receive the output. Similarly, marketing can provide the voice of the market, or landscape, or competitive analysis, but they also need to market the hell out of the stuff that’s coming down the line. Finance allocates your cost, but finance also models the impact of what you do. Support tells you what’s broken, and then they need to know what’s going to get fixed.

“They need to look at the roadmap and they can’t see 70 or 80 iterations of our salesforce plug-in, there needs to be something there that has them joining the dots between the visionary statements on the posters on the wall and the work that you’re doing today”

But as you bring in all of these partners, it’s tempting then to forget about the actual 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 need to be inspired by whatever is on the roadmap as well. They need to look at the roadmap and they can’t see 70 or 80 iterations of our salesforce plug-in, there needs to be something there that has them joining the dots between the visionary statements on the posters on the wall and the work that you’re doing today. And if there’s nothing there to help build that bridge, it’s a tough roadmap to get people excited by it.

So the lesson for me is, and I think we were probably slow to do it because, in my mind, it was nearly a novelty having more than one group to tell about the roadmap, but we need to get out there and make sure that everyone knows, “Roadmapping is coming up, here are the things we’d love to hear, here are 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 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 that you can still buy into it.” The one area where, I think, most people start to get extreme fear is when you end up with public roadmaps, or rather customer-facing roadmaps. What are your thoughts on those?

Paul: Just on the prior point there, I think the word partnership is the best word, at least that’s my current thinking on this stuff. Just last week, for example, we had a leaders’ off-site here in the company, and one of the workshops we ran was better partnerships between product, engineering, and sales, the other one was better partnerships between product, engineering, and marketing. We’ve always had a good one with support, actually, and maybe it’s because part of our product line-up is software for support teams. So that evolution has been interesting. Like you said, we have been slow on the product and engineering side, and I suspect that for a lot of people listening to the podcast, they, like us, are probably a product-focused company, a product and engineering-founded company, where the product and engineering team are the earliest employees and a lot of the gravity and influence might sit with those folks. And we might have different people listening where the company was founded by salespeople or marketing folks, and they might have a different kind of gravity and influence…

Des: They’re not listening to our podcast.

Paul: Maybe not, thanks for the reality check. If you are out there, hello, welcome!

Des: I’m thrilled that we’ve attracted such a diverse audience, but I suspect it might not be true.

“The partnership thing is something that I encourage people to embrace as early as possible. Even when you think it’s almost too early, that’s probably the right time”

Paul: So the partnership thing is something that I encourage people to embrace as early as possible. Even when you think it’s almost too early, that’s probably the right time, because you’re contracting your biases. But for me, it brings up ownership too. And the ownership piece matters because in the early days, for example, the sales partnership wasn’t really a partnership. We listened to sales and we said, “Alright, thanks for the feedback, we’ll think about it, see you.” I don’t think we paid anywhere near enough respect or attention to the idea that the sales team needs to go and sell this. It should be a two-way street. If you want your sales team to really help you, to put great inputs into your roadmap and really understand customers, that’s a lot of work. And they have other things to do, like actually sell.

Des: It’s also work that they’re not incentivized to do. One of the things I think people don’t understand is, generally speaking, people do what you pay them to do. And 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 hugely important, just possibly not discussed enough. We even feel this tension when it comes to the end of the 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 the sales leadership. This will really matter long-term.

Paul: Going back to the ownership piece, this matters because the sales team needs to feel like they’re co-owners of the roadmap. And the same goes for the support team, the marketing team, the design team, the engineering team. Because the product management team are typically the people who drive the creations of roadmap, and 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 mostly do it themselves. And honestly, some cultures propagate that idea, a “PM is CEO” kind of thing. We are not at all like that, and I would advocate that companies should not set themselves up that way. Instead, the PM, who absolutely should be very opinionated about their product and really in tune with what the customers of their part of the product need, is also an excellent facilitator and collaborator. So that all of these functions feel a co-ownership or at least part ownership of the roadmap.

The pitfalls of a customer facing roadmap

Des: 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”?

Paul: One big thing is that you’re committing your future resources, so you’re kind of removing optionality, and that’s a huge piece of it for me. By the way, I think it’s good. We have a customer version of a roadmap so our sales team can talk customers through, 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. Sometimes you might say publicly, “We will deliver X by Y.” And sometimes, that’s in response to a customer demand like, “Hey, if don’t build X by Y, we…”

Des: Yeah, we’re not renewing or whatever.

Paul: Yeah, so there’s real pressure here. But it just removes optionality and it commits you. And so, back to the kind of vision stuff, back to the posters on the wall and what you believe in and change you want to create in the world – the more you commit publicly, the more optionality you remove to do that stuff.

“I think if you’re hard-committing that many 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”

Des: The one piece of advice I’ve given to other companies who are probably Series B/C stage, where they have real customers accounting for non-trivial events with their revenue, is that you can’t give away the majority of the capacity in your work. 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 a big fear I would always have, and I’ve seen this happen with large successful companies, is that you write up a sort of one year or one and a half year’s worth of roadmapping, or you write up this epic feature release and maybe you go on and announce it, you pre-announce it, you seed it… I remember being at a conference where the CEO was literally showcasing this thing that had not had a line of code written in it yet, they had hired a graphic design agency to build up a mock-up UI to show off what it might look like. And I think if you’re hard-committing that many 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… There are so many things you don’t know about, and yet here you are 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, two years later, the feature was finally released. And what do you think they did at all their events in between? They just promised more shit. So, you have a product team relegated to working on yesterday’s promises tomorrow, which is a really scary place to be.

How to evaluate your roadmap infrastructure

Let’s try and wrap up on a few different, more grounded and tactical things. 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, I’m sure you’d take your usual framework of inputs, outputs, and outcomes, and you’d analyze what’s going right and what’s going wrong. About the inputs, what are the right teams to have involved and what are you looking out for as you evaluate the roadmap system?

Paul: We do have a system, and it has evolved over the years, it has changed, it looks a lot different to how it did five, six years ago when we first started doing this. It’s kind of funny, as a side note, if you showed us the Intercom of today five years ago, we’d be like, “Oh, my God.” So much has changed. The inputs have changed and the relationship with different functions has changed. I remember saying, “We will never have any customer-facing roadmap, that’s a really bad idea.” And now we do that in different small ways.

“I hope most companies listening know what their mission for the company is, the reason the company exists other than to make money, and have a vision for the future that looks better than today”

Back to the piece about balance, and back to the Facebook idea of the 20 years and six months, and back to the six, six, six idea that we had a few years ago – there’s a really important balance between reserving space for the stuff you want to build. I hope most companies listening know what their mission for the company is, the reason the company exists other than to make money, and have a vision for the future that looks better than today and there’s a reason that people would buy your product in the future because you’re differentiating in some interesting, important way. That’s one side of it.

And then on the other side, we have a pretty rigorous process these days which always needs improving, but it’s relatively rigorous. If you look back over the years, we’ve developed around pulling in feedback from customers, pulling in feedback from prospective customers, things like surveys, NPS, churn, “What happened there? What did they say? Why did they quit? Can we remove those reasons for people to quit in the future?” We do outcome reports for all projects these days, which looks at the success metrics that we’ve set, the success metrics. And so there’s kind of two halves to this, or two sides, because it’s not really 50-50. One side is your strategy, the things you want to build, making sure you’ve protected roadmap time or developer time to go and build the stuff that you believe in because you have a vision for the future. And then all the stuff that you know is going to help you drive revenue, keep the company healthy, give you that long-term future that you can invest in.

Des: I think the tension there is the balancing of sure shots and big bets. Some stuff you know will work, but there aren’t generally any multibillion-dollar “I know this will work” type ideas. They tend to come in the form of “high risk, high reward”.

Balancing productivity and creativity

That brings me to the last topic, and then maybe we’ll close out, which is that roadmapping is a process, ultimately, and all processes exist to try to find common standards and 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 delivery, in this case, at the expense of creativity. 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 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 at any company is, “What’s the downside of this process?”

“If you have this meat-grinder process that beats the shit out of any creative idea, guarantees that everything comes out pretty vanilla, but at the same time every hour was spent effectively, that’s a small company behaving like a big company, and it sows the seed of your own disruption”

A real fear I have is that when most people introduce a process, it’s usually a reaction to, “Oh we got this wrong” or, “Johnny shipped this and he shouldn’t have shipped it.” And so they’re like, “All right, we’ll add a step called ‘should Johnny ship this?’ to the process.” And the next thing you know, you’ve got like 27 checkpoints before something can go live, which ultimately hurts efficiency, which ultimately hurts leverage. The risk is that you guarantee a minimal standard at the cost of a higher standard, and it’s a dangerous place to be for any company, frankly. But I’d say, especially like a start-up 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, guarantees that everything comes out pretty vanilla, but at the same time every hour was spent effectively, that’s a small company behaving like a big company, and 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?

Paul: I agree with that. Just as you were talking, I was reminded that here at Intercom, we completely redesigned our roadmap process over the last six to 12 months. We had a ground re-think just as an exercise in making sure we weren’t falling into that trap ourselves. We made a whole bunch of changes, but the number one thing we did was we removed loads and loads of details. We took out loads of specificity. The roadmap process we have is based on principles we believe in. But over the years, based on mistakes like you mentioned, we added in stuff because we were trying to manage risk, we were trying to avoid making the same mistakes again, we were trying to make sure that we were an efficient org. But we were hearing a lot of feedback that was just too prescriptive, too narrow, and not giving people enough autonomy or independence to form their own path for the parts of the product they own. So the biggest change we made was removing all of that detail. So I guess the point is: you’re talking the talk there, and we did actually walk the walk over the last six months.

“That is everything on roadmaps. There is a lot to it – it is the fundamental art form of a PM”

Des: The interesting inflection point is that early on, you and I and any of the product leadership were so close to the customers, so close to the actual customer support team and the words that were being written about the features we released, that you had this kind of tacit knowledge on top. And then, as the layers arrive, as you go from being a manager of managers to a manager of directors of managers of groups, the distance between product leadership and the actual frontline 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 assumes that Paul has some superpower, in a world where Paul isn’t in touch with customers anywhere near as frequently as the actual frontline PMs, it’s just a broken process.

And that was the thing that triggered it for me, seeing that I don’t have a clue how half of our platform integrations work. And I don’t know who uses them or why. So, the idea that my opinion should matter on what we do there is kind of ridiculous at this stage. I know who our big customers are, and I definitely invest my time with them, but when you get into the specifics of what’s important in a product, you’re much better off delegating the creativity to the frontline, which means giving them enough rope to do what they want to do versus thinking that everything still needs to filter through your hands because you just don’t have that knowledge that the process assumes you would have.

Paul: Yeah, 100%.

Des: That is everything on roadmaps. There is a lot to it – it is the fundamental art form of a PM. Designers can post shots to Dribbble, developers can post stuff to GitHub, or they can open-source their code, but PMs are not left with an awful lot of artifacts that they can point to proudly, because they all disappear and get turned into real things, like actual software. But the one thing every PM badly needs to have a strong grip on is, how, where, when, and why they roadmap – how it works, who is involved, what goes in, what goes out, how do they follow up, how do they make sure that the outcomes become inputs, all that sort of stuff. And that’s what we’ve been talking through today, and over the last two episodes. But I think we’ll leave it there for today. Thank you as ever, Mr. Paul Adams.

Paul: Thank you, Des.