9 resources from Intercom we point founders to, and the questions each answers.
✍️ Essay
✓ Link checkedFreeIntermediate
Why we picked it
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.
Why we picked it
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.
Why we picked it
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.
Why we picked it
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.
Why we picked it
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.
Why we picked it
This is the cleanest short argument that a product keeps its value by staying focused, not by accumulating features. It walks through why the feature you designed, fought for, and launched is exactly the one you defend past its usefulness, and why cutting it is part of the job. Read it when you feel guilty about removing something you built.
Why we picked it
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.
Why we picked it
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.
Why we picked it
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.
