How to share your Jira roadmap with customers and stakeholders
Share selected Jira work through a public roadmap, control what customers see, and keep updates manageable without maintaining a separate website.
On this page
Share a Jira roadmap by choosing a view for your audience, selecting the work and fields they should see, and publishing it somewhere they can access. A Jira link suits teammates with project access. Jira Product Discovery can publish selected views externally. Released Hub adds a customer-facing portal for selected Jira work, roadmaps, feedback and release notes.
The first decision is who needs the information. A customer asking whether an improvement is planned usually needs its purpose and progress, not the engineering backlog, assignees or internal discussion.
Choose a sharing method for your audience
| Audience and task | Practical option | What to check |
|---|---|---|
| Teammates already working in Jira | Share the Jira Timeline or Plan link | Recipients need access to the relevant plan and underlying work. |
| Stakeholders reviewing Jira Product Discovery ideas | Publish a JPD view | An administrator must enable publishing; check the available fields, plan requirements and public-link policy. |
| Customers following selected Jira work and providing feedback | Publish a roadmap in Released Hub | Configure the work, fields and portal access for that audience. Hub is for Jira Cloud. |
| A one-off presentation or report | Export an image | An export is a snapshot that needs replacing when plans change. |
Jira Product Discovery’s published views are a native option for people outside your Jira space. They are different from copying an internal view link. Atlassian explains how to enable publishing, preview a view and share it externally.
For an internal Confluence page, embedding Jira information can put the roadmap beside its context. Check the recipient’s permissions in both products; an embed should not be assumed to grant access to the underlying Jira work.
Share a Jira timeline or Plan with your team
A direct Jira link is useful when recipients already work in the same Jira environment and need the delivery detail behind the roadmap. Start by setting the view to the relevant work and timeframe. Give the recipient a short explanation of what to look at: the next release, dependencies between teams, or a decision that needs their input.
Jira’s project timeline and its advanced Plans are different features. A project timeline focuses on that project’s work; Plans support broader planning across teams and projects. Advanced planning is available in Jira Cloud Premium and Enterprise. Check which feature your team uses before following instructions for sharing or exporting it. Atlassian’s planning overview explains the distinction.
For a Plan, use its sharing controls to obtain a link. Sending the link does not grant permission to the Plan or its underlying Jira work. If a recipient cannot see the expected information, check their Plan access and the permissions on the relevant work. See the Plan permission levels.
A filtered view also has a different purpose from an access restriction. Use filters to focus a conversation, but use permissions to control access. For example, a view showing only this quarter’s priorities is convenient for a stakeholder; it does not establish which other Jira information they are permitted to open.
Embed a Jira Plan in Confluence
Confluence is useful when the roadmap needs an accompanying explanation: goals, assumptions, open questions and decisions. A roadmap beside that context gives reviewers more to work with than a link in a chat message.
For a supported Jira Cloud Plan embed:
- Open the Plan and choose the view you want to discuss.
- Copy its sharing link and paste it into a Confluence page.
- Choose the supported Smart Link display or embed option.
- Add the purpose of the roadmap, its owner and any decisions readers need to make.
- Check the page with a recipient who has the intended access.
The Confluence page and the embedded Jira content have their own access requirements. Giving someone access to the page does not automatically make the Plan available. If the surrounding text is visible but the roadmap is not, check Jira access as well as Confluence page restrictions. Atlassian documents Plan sharing and embedding here.
This works well for internal reviews when the audience already has the necessary access. For customers who need a standalone view of selected product plans, consider a published JPD view or a customer portal instead of assuming a Confluence embed makes Jira content public.
Export a roadmap for a presentation or spreadsheet
Exports remain useful for a board meeting, a dated report or offline analysis. Decide whether the audience needs a picture of the plan or the underlying rows of data.
Use a PNG for a visual snapshot
Prepare the view before exporting: choose the timeframe, focus on the relevant work and check that labels are readable. Jira timelines support image export, and Plans have their own image export workflow. Follow the instructions for a project timeline or a Plan.
Add the capture date and a link to the maintained roadmap when placing the image in a presentation. For a large plan, several focused images can be easier to read than one dense overview. The image will not change when Jira changes, so identify who will replace it before the next review.
Use CSV when readers need the data
A CSV is appropriate for spreadsheet analysis or a report that needs rows and columns rather than a roadmap visual. In a Plan, use the CSV export workflow and check the export configuration before downloading. Exporting requires the appropriate Plan permissions. Atlassian’s CSV instructions cover this advanced planning feature.
Inspect the resulting file before sharing it. Confirm that it includes the fields the recipient needs and that dates and relationships are understandable outside Jira. A spreadsheet may need additional explanation to convey the hierarchy or dependencies that were clear in the original view.
Both formats are copies. Recipients may forward them, and changing Jira permissions later does not retrieve an already downloaded file. Include only information appropriate for the audience and use a maintained destination when people need ongoing progress updates.
Check Cloud and Data Center instructions separately
The examples above use Jira Cloud. Data Center sharing and embedding depend on the Jira and Confluence versions involved; do not assume the Cloud Smart Link steps apply. Use Atlassian’s Data Center sharing documentation for the relevant version. Released Hub is a Jira Cloud option.
Create a public roadmap from Jira issues with Hub
Use this workflow when your team already plans in Jira or Jira Product Discovery and wants to communicate selected work through a customer portal.
1. Choose work customers should see
Create a roadmap in Hub and include the relevant Jira projects. Use the basic filters or JQL to select the work you intend to communicate. Focus on customer outcomes or improvements rather than every subtask.
For example, you might share an epic about dashboard filtering while keeping its implementation tasks internal. A filter decides which items appear; field configuration decides what information appears about each item. You need both.
2. Give the roadmap a useful structure
Choose a board when priorities and progress matter more than precise dates. Map your Jira statuses or supported field values to the columns that make sense to your audience. A timeline is useful when timing is part of the conversation, but avoid suggesting firm dates where the team has not committed to them.
Different audiences can have different views of the same work. Customers might need a simple planned/in-progress/shipped view, while an internal stakeholder needs more delivery detail. See Hub’s view configuration for the supported mappings.
3. Separate public information from internal detail
Select the fields shown on both the compact card and the expanded detail view. Hiding a field on the card alone is not enough if opening the card reveals it.
Hub uses the Jira summary as the title by default. If it is too technical, configure a suitable text field as the title. Write a public description that explains the improvement without copying internal notes. Hub’s field configuration documentation explains these controls.
Here is an illustrative example of the information to separate:
| Internal planning information | Customer-facing information |
|---|---|
| Dashboard query refactor and role predicate support | Filter your dashboard by role |
| Implementation tasks, estimates and internal discussion | Each team can focus on the work relevant to them |
| Detailed engineering workflow | A clear progress column |
Before publishing, inspect the card and its expanded view as the intended reader. Check titles, descriptions, links and visible fields. Keep private work out of the selection altogether. For an item-level filtering example, see how to hide cards on a public roadmap.
4. Choose portal access and publish
Choose whether the portal is public, internal or restricted. A public portal is accessible to anyone with its link. An unlisted portal is simply absent from the hub listing; it is not automatically private. Use the actual access settings when information is intended for selected customers.
Publish the roadmap, then open the portal as a reader to check what is available. Hub’s access documentation covers the distinction between workspace access, portal visibility and reader access.
Share plans without maintaining another website
A hosted Hub portal gives customers a destination for your published roadmap, release notes and feedback. Share that portal URL from your product navigation, support replies or customer communications. You do not need to build and maintain a separate roadmap website.
If you already have a suitable website or product page, you can embed Hub instead. Choose the hosted portal for a straightforward destination or an embed when customers should see the information in an existing workflow. In either case, decide who can access the portal and what work belongs there.
Keep the public roadmap up to date
Keep planning information in Jira and make reviewing the customer view part of your release or planning routine. This avoids recreating the same roadmap in a spreadsheet or slide deck.
Distinguish the underlying Jira work from the published customer view. Hub’s documented workflow lets you update and re-publish a roadmap. Treat publishing as a deliberate step: review the selected items and public descriptions, publish the update, and check the portal. Do not assume that every internal edit is immediately customer-visible. See the roadmap publishing workflow.
Give one person responsibility for that check. Review the roadmap when priorities change and when work ships, rather than waiting for customers to report stale information. When an item is delivered, explain the outcome in your release notes and follow up with people who asked for it.
Which sharing method fits your situation?
Keep an internal delivery team aligned
Your product manager, engineers and designer already work in Jira. They need to inspect the work behind a milestone, understand dependencies and discuss changes to the plan.
Share the Jira timeline or Plan with the relevant view selected. Add a Confluence embed when the team also needs the goals, assumptions and decisions beside it. Check that everyone has access to the underlying work. A separate customer portal may be unnecessary for this delivery conversation.
Review priorities with management
Leadership needs to understand what is planned, what changed and where a decision is needed. A detailed engineering timeline can obscure those questions.
For managers with Jira access, share a focused Plan view and provide a short explanation of the major trade-offs. For a board meeting or a dated report, a PNG export can be appropriate: label it with the capture date and link to the maintained plan. Use CSV when someone needs to analyse the data rather than review the visual roadmap.
Share with internal stakeholders who do not use Jira
Sales, support or another business team may need product progress without needing the engineering workspace. First establish whether they need a one-off update or a destination they can revisit.
For an occasional briefing, a reviewed image and written explanation may be sufficient. For ongoing visibility, consider a published Jira Product Discovery view when the work is managed there, or a Hub portal for selected Jira work. Configure access for the intended internal audience; an internal audience does not mean the link should be public. A Confluence page alone does not resolve access to an embedded Jira Plan.
Give a key customer or partner a focused view
A customer wants to follow the improvements relevant to their rollout. They need an explanation of the outcome and progress, while your team may have other customer commitments or internal details that should remain private.
Use a tailored Hub roadmap with the appropriate portal access settings. Select the relevant work, review the card and detail fields, and write descriptions for that audience. Confirm what the recipient can actually open before sharing. Make someone responsible for reviewing updates and responding when plans change; a filtered view and a restricted portal solve different parts of this task.
Publish a roadmap for all customers
A SaaS company wants prospective and existing customers to see its direction, express interest and find out what shipped, without maintaining another website.
A public Hub portal provides a hosted destination for the roadmap, release notes and feedback. Share the link from your product or website, or use an embed where it fits the customer journey. Publish only work and descriptions suitable for anyone to read, and distinguish plans from firm commitments. If the requirement is simply to publish a selected JPD view, evaluate that native option too.
Whichever method you choose, tell readers where to find the current version, how often you review it and how they can ask a question. Those expectations make the roadmap useful after the first time you share it.
Make the roadmap a conversation
Publishing a plan is the start of communication. Give readers a way to ask questions or explain why an item matters. Connect customer feedback to Jira work so the team can refer back to the original request and respond when there is meaningful progress.
For the delivery work behind that shared view, BetterBoard gives Jira teams a configurable board for grouping, filtering and moving issues through their workflow.