Finish the review in one place
A good feature request explains who is blocked, what they are trying to do, and how they cope today. Those details make a review more useful than a bare vote count.
- Open the incoming idea and identify the underlying problem. Keep customer-sensitive source material out of the public summary.
- Search for an existing request with the same outcome. Compare both cards before merging; similar wording alone is not enough.
- Approve a useful request, ask for clarification, or record a Not planned decision with an explanation.
- Move work you intend to pursue to Planned. Keep undecided ideas in Considering rather than implying a promise.
Find the set you actually need to work on
Search and combine filters to narrow your request list. Sort by the question you are answering, then select the filtered set for supported bulk actions. Available actions follow the cards’ current state.
For duplicates, choose a canonical idea deliberately. Overlapping votes are counted once, follower opt-outs survive, and the source retains its connection to the destination. Merging does not send a release email and cannot be undone from the dashboard. Read the merge checklist before combining ambiguous requests.
Let evidence inform the decision
Use support, comments, and the underlying customer problem as inputs. A popular card does not automatically move to Planned. Consider your product direction, the affected audience, confidence in the problem, and the cost of delivering and maintaining the solution.
AI assistance can suggest ways to organize incoming feedback and help draft announcements. Your team reviews the output and decides what to apply. BuildCaster does not independently commit your roadmap. AI is disabled in the public demo.
For a separate prioritization exercise, try the free RICE calculator. It is a manual planning tool, not an automatic score stored on your BuildCaster cards.
Close a request without losing the explanation
Not planned is a product decision; removing spam is moderation. Cancelled explains why previously planned or started work will not continue. An archive hides a card from default browsing while preserving its underlying status and history.
Shipped cards close new voting, but shipping alone does not publish an announcement. When you link a card to a published update, the team can see it has been announced. You can enable automatic archiving of announced cards to keep completed work from accumulating.
Use the decision templates when you need to say no clearly. A smaller, honest roadmap is more useful than a long list of implied commitments.