Skip to main content
SignalBoard

Roadmap & changelog

Changelog

Publish customer-facing release notes tagged New, Improved, or Fixed, and notify voters who asked for the change.

SignalBoard includes a product changelog on every plan. Publish release notes when you ship, tag them so users can scan quickly, and keep the people who requested a feature in the loop. The same board that collects votes can announce what shipped — no second tool required.

What a changelog entry looks like

Each entry is a short, customer-facing note. Write in plain language your users understand, not commit messages. Typical fields:

  • Title — one line, e.g. “Dark mode for the dashboard”
  • Body — optional detail: what changed, who it helps, and any action users should take
  • Tag — New, Improved, or Fixed (see below)
  • Published state — draft until you are ready to go live; published entries appear on the public changelog page

Tags

  • New for net-new features
  • Improved for upgrades to existing behavior
  • Fixed for bug fixes

Tags help readers skim a long release history. Use them consistently so your changelog stays scannable as it grows.

How to publish

  1. Open the board in the dashboard and go to Changelog.
  2. Create an entry with a clear title and optional description.
  3. Pick a tag (New, Improved, or Fixed).
  4. Publish when ready. The public page at /b/…/changelog updates immediately.

Share the public changelog URL from the board’s Share page, or link it from your product footer and release emails. See Public board links.

Connected loop

Voting, roadmap, and changelog are one loop. Collect ideas on the board, move them through roadmap statuses, ship the work, then publish a changelog entry. Voters and commenters who asked for the change can be notified when it ships — the feedback loop closes without a separate announcement tool.

Availability

Public roadmap and changelog are included on Free and Pro. They are not paywalled into higher tiers. Unlimited voters apply on every plan; you are not charged per person who reads the changelog.

Tips

  • Ship in batches when it helps readers, but prefer smaller, frequent notes over rare walls of text.
  • Link back to the original request when you can — users trust changelogs that clearly connect to votes they cast.
  • Keep internal jargon out of titles; product and support teams will share these links externally.

Related