10 resources from Intercom we point founders to, and the questions each answers.
✍️ Essay
✓ Link checkedFreeIntermediate
This is the cleanest answer we have found to your exact question: it names five buckets a roadmap actually pulls from (new ideas, iteration on what you shipped, customer problems, quality and bugs, and scale) and argues the whole job is balancing across them rather than picking one. It gives you honest language for why an all new features roadmap ships half finished buggy work, and why an all customer requests roadmap quietly stalls. Treat it as a starting point for a healthy mix, not a fixed percentage split.
The exciting new thing, paying down what you shipped, honouring customer promises, and fixing bugs are separate buckets, and a sane roadmap deliberately draws from each rather than letting one crowd the others out.
Over indexing on new features leaves you with half useless, half finished, buggy product, while over indexing on customer requests optimises locally and never moves the market.
A visible backlog with the honest admission that some items may never ship is part of the system, so saying no stays explicit instead of piling up silently.
This is the piece about the conversation itself, so the customer feels heard even when the answer is no. It walks through questioning the request, understanding the goal behind it, and closing the loop honestly rather than going silent. Use it for the exact wording that keeps the relationship intact.
This is the principle behind the first half of your answer: a request is a proposed solution, so back up to the problem before you accept or reject it. It shows how starting from the problem often reveals a better fix than the exact feature asked for. Handy for reframing a no as a redirect to the real need.
A hands on walkthrough of the unglamorous middle step, putting every piece of feedback in one place, tagging it, and rolling it up into themes. This is literally how you get from twenty scattered requests to three counted problems. Read it when you need a repeatable process, not just a philosophy.
Fried makes the case for saying no to most requests and letting them pile up, so only the ones that keep recurring earn attention. It is a useful counterbalance if you feel obligated to act on every piece of feedback. Listen for permission to not build most of what you are asked for.
This gives you the simple two-axis map (how many people use a feature, and how often) that turns a gut feeling into a picture of what is actually dead weight. Plotting your features this way makes the removal candidates obvious and the argument easy to share. A concrete tool to set the clear bar our short answer asks for.
Intercom's Jobs-to-be-Done writing shows how to ask what customers are hiring your product to do, which forces you to describe the problem in their words instead of yours. It is practical for teams that are past their first few interviews. A free collection of their best posts on the topic.
Intercom's own playbook for feature announcements is useful precisely because it treats every release as its own small campaign, with its own audience and its own reason to care, rather than a generic broadcast. It gives you a concrete way to make sure this announcement earns attention on its own terms instead of blending into the last one.
Traynor breaks down knowing your customer into two concrete questions, who they are and how they decide, instead of a vague persona exercise. Comes from a founder who spent a quarter of his week talking to customers directly, so the advice is grounded in practice rather than theory.
A practical look at how Intercom itself built customer segments across a growing team, useful because it shows the operational side, who owns the segmentation, how it is used day to day, that most ICP essays skip. Good reference once you are past the definition stage and into how do we actually use this.
