Decide what the roadmap is for
Choose the audience first. An open portal can help prospects and customers understand direction. An invitation-only portal can support a restricted customer group. Neither choice means every internal request belongs on the board.
Publish work that customers can understand as an outcome. “Make invoice exports easier to reconcile” is useful to a customer; an internal database refactor may not be. Keep private customer details, security-sensitive discussion, and individual account commitments out of public summaries.
Use the portal launch checklist to test the audience and permissions before sharing an address.
Write a status policy before adding cards
In BuildCaster, these are the four roadmap columns. Pending submissions stay out until reviewed. Not planned and Cancelled are explicit outcomes outside the default board, so a declined request does not sit in Considering indefinitely.
If a customer asks for a date you cannot support, explain what must become clearer before you can provide one. A narrow but true answer is more useful than “soon.”
Give every planned card enough context
Do not turn a roadmap card into a detailed sprint ticket. The public reader needs to know whether this addresses their problem and what the current decision means. Developers still need their own implementation detail.
- Name the outcome and the audience affected.
- Explain the current problem in language a customer would use.
- Keep discussion and supporting requests connected to the same card.
- Identify the team member responsible for reviewing its status in your internal process.
- State availability limits when work ships: plan, role, platform, or rollout stage.
When plans change, change the explanation too
Review Planned and Building cards on a regular team cadence. Ask whether work is still intended, actively underway, or waiting on a dependency. A board is only current if someone is accountable for those distinctions.
If previously committed work will not continue, mark it Cancelled and explain why. If it needs reconsideration, move it back with a reason. Do not archive a card merely to make a changed promise disappear. The decline and cancellation guide includes wording for both situations.
Make Shipped the start of the handoff
Confirm the change is available before marking it Shipped. Then write a linked update explaining where to find it and who can use it. A status alone rarely teaches a customer how to benefit from a release.
BuildCaster keeps roadmap cards connected to release updates. Publishing and emailing are explicit actions. Once work is announced, optional archiving keeps the board readable while the update remains the release record.