When to Share Roadmap Details in Customer Support

Share roadmap details when the information is approved for customers, relevant to their immediate decision, and reliable enough to set a useful expectation. Describe the current status and level of uncertainty—not just the desired feature or release date.

Do not share tentative backlog items, confidential work, security-sensitive details, or dates that the team cannot reasonably defend. When the plan is uncertain, acknowledge the request, explain what is known, and offer a current workaround instead.

Why roadmap conversations require care

Customers usually ask about future features for a practical reason. They may need to choose a plan, complete an integration, renew a subscription, or decide whether your product can support an important workflow.

A useful reply therefore needs to answer more than “Is this on the roadmap?” It should help the customer understand:

• What the product supports today
• Whether a change is being considered or actively developed
• How confident the team is about its scope and timing
• What the customer can do in the meantime

Published roadmaps commonly distinguish between exploration, active development, preview, and general availability. The GitHub public roadmap, for example, labels work as “exploring,” “in design,” “preview,” or “GA.” It also warns that roadmap information is subject to change, particularly further into the future.

That distinction matters in support. “We are exploring this” and “This will launch next month” create very different expectations.

Share details when they help the customer make a decision

Roadmap information is most useful when it changes what the customer should do next.

Appropriate situations include:

• A planned improvement directly affects the customer’s workflow.
• The customer must decide whether to build a temporary integration.
• An upcoming change requires preparation, testing, or migration.
• A beta or early-access program is open to suitable customers.
• The information has already been approved for public or customer-facing use.
• A known product limitation is likely to change, and the team has reasonable confidence in the direction.

Even then, share only the level of detail needed for the decision. A customer deciding whether to postpone a small internal task may need only a broad timeframe. A customer planning a complex migration may need scope, compatibility, rollout, and testing information.

Check five things before replying

A small team can use the following questions as a lightweight approval process.

1. Is the information approved for external use?

Use a public roadmap, release plan, or internally approved support note as the source of truth. Do not copy details from engineering discussions merely because you can see them.

Internal plans often contain abandoned approaches, unresolved dependencies, customer names, commercial discussions, or technical risks. Their presence in a project tracker does not make them suitable for customers.

If you are the founder and product owner, approval may be informal—but the distinction should still exist. Mark roadmap entries as one of the following:

• Internal only
• Safe to share without dates
• Safe to share with a broad timeframe
• Public

2. What is the actual status?

Use the narrowest accurate status:

• Considering: The problem is being evaluated, but no decision has been made.
• Planned: The team intends to build it, but work may not have started.
• In progress: Implementation has started, although scope and timing can still change.
• Testing or beta: Some users can try it, subject to stated limitations.
• Rolling out: Release has begun but may not yet cover every customer.
• Available: The feature is released for the relevant customers, plans, and platforms.

Do not turn “requested,” “discussed,” or “designed” into “planned.” Intercom’s published feature-request process illustrates this separation by using different stages such as discussion, planned, and implemented in its Community Product Wishlist.

3. How confident are you about timing?

Precise dates imply high confidence. Use them only when engineering dependencies, testing, release operations, and customer communication have been considered.

Broader windows are usually safer earlier in development:

• “We are exploring this, but there is no timeframe yet.”
• “It is planned, although we have not committed to a release window.”
• “We are working toward this quarter, subject to testing.”
• “Rollout is scheduled to begin on September 8.”

Large software companies make similar qualifications. Atlassian describes its Forge roadmap as informational rather than a binding commitment and notes that early-access features may change or be cancelled. GitHub likewise states that its public roadmap is not a guarantee that a feature will arrive by a particular date.

A disclaimer does not repair an unrealistic promise. The status, confidence, and wording must agree.

4. Does the customer understand what the feature will solve?

Before discussing the roadmap, identify the underlying need. A customer asking for “custom exports” may actually need a weekly report for an accountant. An existing API, manual export, or different configuration might already solve the problem.

Intercom’s guidance on responding to feature requests recommends understanding the result the customer wants and providing a workaround instead of making an empty promise.

This approach also produces better product feedback. Record the desired outcome, current obstacle, urgency, and workaround—not only the requested feature name.

5. Could disclosure create harm?

Do not disclose:

• Unannounced pricing or packaging decisions
• Private negotiations or customer-specific commitments
• Personal or customer-identifying information
• Details covered by an NDA
• Acquisition, partnership, or vendor discussions
• Technical information that could expose an unresolved vulnerability
• Plans that depend on a third party that has not approved disclosure

Security issues need a separate disclosure process. CISA explains that uncoordinated vulnerability disclosure can allow exploitation before an organization has addressed the problem and recommends formal vulnerability disclosure policies and coordinated practices in Binding Operational Directive 20-01.

For a security-related ticket, support can acknowledge the report, explain the safe reporting channel, and provide approved mitigation guidance. It should not improvise release details or reveal the technical path to exploitation.

Match the answer to the confidence level

A practical roadmap reply contains four parts:

1. Acknowledge the customer’s goal.
2. State what is supported today.
3. Share the approved roadmap status and uncertainty.
4. Give the next useful step.

The following exchanges are hypothetical.

When the feature is only being considered

Thanks for explaining that you need separate export permissions for contractors. We do not support that permission level today. It is a problem we are evaluating, but it is not committed to the roadmap and I do not have a release date. For now, an account owner would need to create the export.

This answer is honest without dismissing the request or implying a promise.

When work is in progress but the date is uncertain

We are actively working on this. The current plan covers scheduled CSV exports, but the final scope and release timing may change during testing. I cannot give you a dependable date yet. If you need the data this month, the existing API is the safer option.

The workaround prevents the customer from building a plan around an uncertain release.

When a release window is approved

Team-level audit logs are planned for the fourth quarter. That is our current target rather than a guaranteed release date. The first version is expected to cover sign-ins and permission changes; export support is not yet confirmed.

This separates the target window from the confirmed scope.

When the feature is not planned

We do not currently plan to add on-premises hosting. Our focus remains on the hosted product, so I would not recommend waiting for that option. If data residency is the main concern, I can explain the regions available today.

A clear “not planned” answer can be more helpful than indefinite language such as “maybe later.”

Avoid these common roadmap replies

“It is on our roadmap”

This is too vague. It could mean anything from a backlog note to active development. Add the actual status and whether a timeframe exists.

“It should be ready soon”

“Soon” sounds reassuring but gives the customer no usable planning information. Use an approved window or say that timing is not yet confirmed.

“We will build this”

A support conversation should not create a new product commitment. Record the request and explain the current plan. If the feature would determine a purchase or renewal, escalate the conversation to whoever owns product commitments.

“I have passed this to the team”

This describes an internal action but does not answer the customer’s problem. Say whether the capability exists, provide a workaround if possible, and explain what submitting the feedback does—and does not—mean.

Sharing an internal screenshot

Screenshots can expose unrelated plans, names, comments, estimates, or commercial information. Restate the approved information in customer-facing language or link to a maintained public roadmap.

Create a small-team roadmap communication policy

Solo developers and small SaaS teams do not need an enterprise approval system. A short policy can still prevent contradictory replies.

Define:

• The source of truth for shareable roadmap information
• The statuses support may use
• Who can approve dates and customer commitments
• Which topics must never be discussed in ordinary support
• How feature requests are recorded
• How affected customers will receive updates
• How outdated roadmap replies are corrected

For each shareable item, keep a compact support note:

Feature:
Customer problem:
External status:
Approved description:
Timing language:
Known limitations:
Current workaround:
Last reviewed:
Owner:

Review these notes whenever priority, scope, or timing changes. GitLab’s published roadmap process assigns ownership and requires significant changes to committed work to be communicated to relevant stakeholders, illustrating why roadmap communication needs both an owner and an update process in its R&D Interlock documentation.

Treat AI-generated replies as drafts

An AI support assistant can help apply approved language consistently, but roadmap information is especially sensitive to stale context and accidental overstatement.

For a human-reviewed system such as SupportMe, the knowledge base should clearly separate:

• Public roadmap facts
• Approved customer-facing language
• Internal planning context
• Expired or superseded information
• Topics requiring manual escalation

The reviewer should check every roadmap draft for status, scope, timing, confidentiality, and the availability of a current workaround. Human approval is particularly important when a reply could influence a purchase, renewal, integration, or migration decision.

Keep the customer informed after the first reply

Sharing roadmap information creates an obligation to correct it when the plan materially changes. Record which customers depend on the feature and what expectation they received.

Send an update when:

• A target window moves significantly
• Important scope is removed
• A beta opens or closes
• The feature is cancelled
• Rollout begins
• The feature becomes available

The update should state what changed, what it means for the customer, and what options exist now. Do not wait for the customer to discover that an earlier expectation is obsolete.

References

• GitHub public roadmap and disclaimer
• Atlassian Forge release phases and roadmap disclaimer
• GitLab R&D Interlock and roadmap governance
• CISA Binding Operational Directive 20-01

Conclusion

Share roadmap details when they are approved, relevant, and expressed with the right level of confidence. State the current status, distinguish targets from commitments, and give customers a workable option for today. When information is tentative, confidential, or security-sensitive, a clear boundary is more useful than a hopeful promise.