{"id":7622,"date":"2015-06-17T17:00:00","date_gmt":"2015-06-18T00:00:00","guid":{"rendered":"http:\/\/intercom.com\/blog\/?p=7622"},"modified":"2025-01-07T16:37:12","modified_gmt":"2025-01-07T16:37:12","slug":"where-do-product-roadmaps-come-from","status":"publish","type":"post","link":"https:\/\/www.intercom.com\/blog\/where-do-product-roadmaps-come-from\/","title":{"rendered":"Where do product roadmaps come from?"},"content":{"rendered":"

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.<\/p>\n

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\u2019t all that interesting. What\u2019s interesting is what<\/i> is on the roadmap, and most interestingly, why it is there<\/i>.<\/p>\n

Ask any good product manager and they\u2019ll 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.<\/p>\n

When you ask any good product manager to walk you through their ideas, you\u2019ll quickly see they aren\u2019t 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.<\/p>\n

I\u2019ve 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:<\/p>\n

<\/p>\n

1. New ideas we have<\/h2>\n

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.<\/p>\n

<\/div>\n

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 :)<\/p>\n

2. Iterate recently shipped products<\/h2>\n

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.<\/p>\n

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

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.<\/p>\n

3. Our most common customer problems<\/h2>\n

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.<\/p>\n

<\/p>\n

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 \u201chit list\u201d 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.<\/p>\n

4. Improving quality<\/h2>\n

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:<\/p>\n