Should Support and Sales See the Internal Product Roadmap?
Give customer-facing teams visibility into the status of what their own customers asked for, not a seat in the tool where the whole roadmap lives. A sales rep on a call needs to know whether the thing a prospect keeps bringing up is committed, still being explored, or already turned down. A support agent on a ticket needs to know whether the bug a customer keeps mentioning is fixed, scheduled, or untouched. Neither of those is "show me the roadmap." Both are "show me the status of this one thing," which is a much narrower question, and a much safer one to answer.
Full access answers a different question than the one being asked, and answers it badly. Handing sales or support a login to Linear, Jira, or whatever tool product plans in puts draft priorities that get rewritten twice before a quarter starts, tickets nobody has committed to, and open debate about whether something is worth building at all in the same list as work that's actually scheduled. Nothing in most roadmap tools marks that difference clearly enough for someone outside product to read it correctly under call pressure. The failure runs both directions. Give raw access and a rep quotes an unscheduled idea as a date on a renewal call. Withhold access entirely and support tells a customer "no plans" about something that shipped two sprints ago, because nobody told them either.
Two tools, the same all-or-nothing switch
The instinct to solve this with permissions runs into a real limit: most roadmap tools don't have a setting between seeing everything and seeing nothing. Linear's documentation on Customer Requests draws that same hard line. Admins and Members can see Customer Requests in both Linear and Slack, while Guests see nothing tied to Customer Requests at all, including any view that filters by customer. A support lead added as a Member to check on one request doesn't get a view scoped to that request. They get the same access to every issue's real workflow state, priority, and internal comments as the engineer who filed it. A Guest seat, the other option, sees nothing at all, not even the request they came to look up.
Productboard, a tool built specifically to communicate roadmap status outward, has the same gap running the other way. Its guide on sharing roadmaps with external stakeholders is direct that publishing a board makes everything on it visible: "anyone who accesses a published roadmap externally...will be able to see the following data for all items on that published board: item names, item descriptions, status values, card attributes." There's no per-card toggle. The controls on offer are a passcode, hiding the board's name, or not publishing at all. A curated version means building a second board by hand and keeping every item on it current, which is its own ongoing job.
The read that goes wrong on a call
That same binary plays out badly the moment someone with full access is on a live call. Nothing in Linear or Jira marks a ticket as speculative versus committed for someone outside product's daily workflow. A rep pulls up a ticket titled "barcode scan input, mobile," sitting in an Explore-stage project, no priority set, no assignee, opened after someone floated the idea in a planning meeting three months earlier.
The rep, mid-call: "Actually, I'm looking at it right now. Looks like it's in the pipeline. I'd expect something on that in the next release or two."
Nothing on the ticket said otherwise, so the rep read an idea as a plan. The customer holds sales to that specific, and it's support who inherits the walk-back once someone checks in and finds no scheduled date behind it. That's the failure mode regardless of who's on the call: an unscheduled idea and a committed date look identical inside the tool, and only product actually knows which is which.
What actually holds up: status on the request, not a login to the tool
The version that holds up narrows what's shared along two axes: scope and category. Scope means a customer-facing person sees the status of the specific things their own customers asked for, not the full list of everything in flight. Category means the status they see is a small, deliberately blunt set, something like not planned, in progress, or shipped, with no date attached to anything short of shipped, because a category with a date attached is a promise again.
One version of this that works: three columns visible to support and sales, fed by a weekly export from Linear that a PM curates by hand, filtered down to items with at least one paying customer's name attached. Anything sitting in an Explore-stage project, anything without a customer on it, and anything carrying an internal-only label stays out of the export entirely. That internal-only filter is what keeps a leak from becoming a strategic one: a comment thread debating whether to sunset a product line has no business reaching a customer-facing view. Support and sales get an answer to "is this coming" without a login to the tool where the real prioritization argument happens.
The gap a manual export leaves
The curated export works until the person maintaining it misses a week, or the company doubles its customer count and the export takes an afternoon instead of twenty minutes. The gap it leaves is quiet. An item ships, the export doesn't get regenerated until Friday, and a support agent tells a customer "still in progress" about something that went out Tuesday. Nothing breaks loudly. The list is just stale in whichever direction nobody happened to check.
The other honest option sits at the opposite extreme from curation. FusionAuth's public GitHub issue tracker uses version milestones as the roadmap itself, visible to anyone, support team included. That works because FusionAuth's customers are developers who read a milestone list the same way an engineer does, and the audience filing issues and the audience buying the product overlap closely enough that no translation layer sits between them. It's a poor fit for a company where sales and support are explaining status to buyers who've never opened a tracker. For those teams, a curated layer, kept current, is doing real work that shouldn't be skipped rather than a chore to eliminate.
Where Modem fits
The bottleneck in the call above wasn't visibility into the roadmap. It was that the connection between one customer and one piece of work lived in a person's head, or a weekly export, and both of those go stale. Modem is what we build, and it's built around exactly that gap, so read what follows with that in mind. Modem tracks which customers asked for what across Slack, support tools, and calls, links each request to the Linear issue or GitHub pull request that resolves it, and keeps that link current as the work moves and ships. A support or sales person looks up their own customer and sees a plain status for the specific thing that customer asked for, not planned, in progress, or shipped, not the ticket's raw workflow state, priority, or which project it happens to be sitting in. No Linear seat, no waiting on someone else's export. The Linear integration is what keeps that status current on Modem's side once a request is linked to an issue.
This doesn't replace the judgment call about how much of product's actual thinking to share outward. That's the same discipline covered in who should own a feature request at each stage, and it's what keeps a rep from turning an unscheduled idea into a promise the company later has to walk back. What Modem removes is the manual export step in the middle, the one most teams eventually stop maintaining.
One owner, three columns, updated weekly
Pick three categories and attach a date to none of them but the last: not planned, in progress, shipped. Have one person filter this week's customer-linked requests into those three buckets and share just that list with support and sales, nothing else out of the roadmap tool. Measure it by what stops happening: no more renewal calls where a rep guesses a date off an unscheduled ticket, no more support replies that lowball something that already shipped last sprint.
