Board template
Start with a board people can understand
A useful feature-request board needs a small public vocabulary, a good prompt, and visible moderation rules. Copy these six blocks, then change the nouns to match how your team actually works.
Field guide
FeatureJet
Published and verified July 29, 2026
Suggested statuses
Keep the public promise legible. Every status should tell a visitor what happens next.
Open — Valid request; no commitment yet.
Planned — We chose to pursue it; timing may still change.
In progress — Active implementation is underway.
Shipped — Available to users now.
Declined — We made a decision not to pursue it; explain why.Suggested tags
Use one area tag and, when useful, one request-type tag. Avoid a taxonomy nobody will maintain.
AREA
Onboarding
Billing
Dashboard
Integrations
Mobile
TYPE
Feature
Bug
Documentation
AccessibilitySubmission prompt
Ask for the decision-making context, not a miniature product specification.
What are you trying to accomplish?
Tell us what you do today, where it gets difficult, and what a good outcome would look like. Please avoid passwords, API keys, customer data, or other private information.Moderation rules
Publish the rules before the first disagreement so moderation feels consistent rather than personal.
1. Combine duplicates and preserve the combined demand signal.
2. Remove secrets, personal data, spam, harassment, and unrelated promotion.
3. Clarify vague titles without changing the request's meaning.
4. Decline requests with a short, specific reason.
5. Never mark a request Shipped until users can actually use it.
6. Treat votes as input, not an automatic promise or priority order.Example seed requests
These are examples only. Replace or delete them; they do not imply users, votes, or customer activity.
EXAMPLE — Invite teammates to help triage requests
Show how a concrete feature request should be titled and explained.
EXAMPLE — Improve the empty state on the analytics page
Demonstrate a focused UX request with a clear location.
EXAMPLE — Document webhook signature verification
Show that documentation requests belong on the same board.Launch checklist
A board becomes useful when people know where it is and what your team will do with it.
□ Name the board for the product, not the feedback tool.
□ Add a welcome message and the submission prompt.
□ Confirm statuses and tags match your actual workflow.
□ Replace or delete every example request.
□ Submit one real internal request and test the full flow.
□ Test voting and email verification in a private browser window.
□ Link the board from your product, support surface, and changelog.
□ Decide who reviews new requests and how often.
□ Explain that votes inform decisions but do not guarantee delivery.
□ Close the loop when a request ships.Use the template
Make the rules real before you invite voters.
The feature-request board guide explains how intake, voting, decisions, statuses, and shipped notifications fit together. This template gives you the words to start with.