Where do product roadmaps come from?

Building a great product is an art as much as a science. It requires making hard decisions and trade-offs, in circumstances ranging from being overwhelmed with data to having no data.

Great product teams have a plan, usually in the form of a product roadmap. This is simply a chronological list of what they plan to build next. That part isn’t all that interesting. What’s interesting is what is on the roadmap, and most interestingly, why it is there.

Ask any good product manager and they’ll say that they are never at a loss for ideas. There is always more to build than they have resources for. But what distinguishes the great from the good is knowing which ones to build. Deciding what goes on the roadmap and what does not.

When you ask any good product manager to walk you through their ideas, you’ll quickly see they aren’t all equal. Some things are new ideas, some are iterative, some are quick and simple to build, some are slower and harder. Some ideas are enticing and feel contemporary, some sound a bit boring and less interesting. The key to nailing a great roadmap is to have a balance between these types of ideas.

I’ve worked in teams that had little balance. In most cases they over resourced the new product and under resourced iteration on existing product. At Intercom we work really hard to ensure we have a balanced set of priorities. To aid this, we bucket all the ideas we have into five categories:

1. New ideas we have

This is based on our opinion rather than research. This includes trends we see and ideas we have. This is not data driven, it comes from looking around us and seeing what excites us most.

For example we knew we wanted emoji and stickers throughout Intercom. We knew it was an important part of modern messaging. No customers were asking for it. But we built it because we believed in it, and people <3 it :)

2. Iterate recently shipped products

A common mistake of most software companies is that they ship something and then move on to the next shiny thing. But one of the truths of building software is that you never fully get it right the first time. This is universally true, no matter how hard you try, no matter how much research you do.

When we ship something and have it working with real data in a real environment, we learn what works well and what doesn’t work well, really, really fast. So we commit to making sure shipping is just the beginning and then we iterate and make things better. This takes deliberate planning and perseverance.

This is made much easier by knowing what your success criteria are prior to shipping. So we set success criteria (often metrics), measure them post launch, and where necessary we follow up with customers for qualitative feedback.

3. Our most common customer problems

Every week, our product management team read hundreds of customer conversations. Our four Product Managers read dozens and sometimes hundreds each. The way we do this is that as our customers talk with our Customer Success team, they diligently tag every conversation with the type of conversation e.g. is it a usability issue, a feature request, a bug, etc. and they also tag the team that owns that area of the product.

Once a week, our PMs trawl through these conversations and in many cases, get talking to the customers directly to learn more. On top of this, every few months our research team pull out all the conversations, analyse them systematically, and code them. This generates a “hit list” of the most common customer problems. Using the PMs weekly pulse, and the researchers systematic analyses, we can easily decide which ones to address first.

4. Improving quality

All software has bugs. Aiming for zero bugs is unrealistic, impractical, and certainly overly optimistic for something that gives you fast diminishing returns. So for a start all issues need to be graded on a scale so you know which ones are most important. At Intercom, we use two main measures for grading:

• How severe is the problem?
• How many of our customers does it affect?

Most customers will forgive you for one or two serious bugs, but no more. There is more flexibility in the obscure bugs that only affect people with specific browsers, or are only experienced through an uncommon set of sequential actions. You need to fiercely protect your commitment to software that maintains a high bar for speed, latency, and efficiency. It’s not a glamorous job, but much of what we ship is simply addressing bugs. We aspire to deliver world class quality, knowing that absolute perfection is not achievable by anyone.

5. Features to help you scale

Finally, if you’re a fast growing company like Intercom, you’re likely seeing new problems with your product as your company grows. You’re getting customers that are bigger than you’ve seen before. You’re getting customers from industries that you haven’t seen before.

We’ve recently started to build out our sales team. As a product person, I love this new team. Our sales strategy is all built around understanding how Intercom might be able to help a prospective buyer succeed. This is modern sales, even when it means no sale. Sales is a critical source of research into these new types of potential customers.

Whilst we will never build a feature to close a deal (that signals the beginning of the end of your product – a post for another time), the conversations our sales team have are a final critical input into our roadmap.

Finding the right balance

So with our five inputs, the art is balancing items from each of them. How can we build exciting new product, whilst iterating our existing product, delivering against commonly requested features from existing customers, with new features needed by prospective customers, whilst keeping everything high quality, bug free, fast and performant?

Enter the world of hard trade-offs. If you just developed items from the “New Ideas” list you’d have an app that was half useless, half finished, buggy, and slow. Likewise if you just addressed the “Most Common Customer Problems” you’d be on a never-ending local maximum and never be a disruptive force for good or a market leader.

The sixth category: everything else

Our roadmap is planned out roughly 3 – 6 months ahead at all times. So as we add things to the roadmap and reassess existing items, we also keep a giant backlog of everything else. This is all the other ideas we have that are not on our roadmap. Most people like to call this our backlog, but I prefer to call it “the list of things we’ve no plans to build”. This keeps us honest to ourselves and avoids the “oh yeah but it’s on our backlog so it’ll get done”. Nope. As you move forward things change, and so there will be items on your backlog that rightfully stay there forever.

Hopefully this insight into how we categorise and sense check ourselves helped. If you want to learn more we wrote a huge exposé into our full building process including lessons learned as we scaled, and if you really want to learn more you could consider joining us :)