VoteWant provides a feedback board that a product owner can put on a website, app, or game. A VoteWant property has a generated widget snippet. VoteWant presents one board for each product property. VoteWant's product page describes customer feature requests, bug reports, and votes as feedback inputs for an owner's product decisions. The board belongs to the product property named in VoteWant, while the widget supplies the feedback entry point on the product's own interface.
Private, depublished, and otherwise non-public VoteWant boards return 404 from the public board API, which follows the same publication rules as rendered board pages.
VoteWant documents public board reads through its API and a read-only public TypeScript client; owner and agent write access remains separately gated.
A VoteWant property stays private while its owner prepares it, and its installed feedback button becomes available to visitors after public activation.
VoteWant renders public board visitors as anonymous until they authenticate, while public request submission and voting require a verified human identity; a verified human can vote once per request.
Start by naming the decision you need to make. Write a narrow request title, describe the observed problem, and separate the requested outcome from a proposed implementation. This keeps your review focused on customer need instead of locking your team into the first solution someone suggests.
Ask contributors to include concrete context from the moment the problem occurred. Record the task they were attempting, the result they expected, and what happened instead. Avoid collecting sensitive information. Clear context helps you compare requests without treating every submission as equally urgent.
Review related requests together before you prioritize them. Compare the underlying need, the affected workflow, and the evidence attached to each item. Keep distinct problems separate even when they share vocabulary. Combine records only when they describe the same decision and would lead to the same product response.
Use votes as one signal rather than an automatic roadmap. Look at who is affected, how often the problem occurs, and whether the request supports the direction you have chosen. Consider whether a smaller group with a severe recurring problem deserves attention before a larger group expressing casual interest.
Record your decision after review. State whether you will investigate, defer, decline, or build the request, and explain the evidence that mattered. Use a visible rationale to help contributors understand the tradeoff and give your team a durable record when similar feedback appears later.
Revisit open requests on a regular schedule. Close items that no longer describe the current product, update requests when new evidence changes the decision, and note what shipped. Keep a consistent review habit so your board does not become an unowned list of old suggestions.
Keep the submission path easy to find where the customer experiences the product. Test it on both desktop and mobile layouts, confirm that it can be closed without losing the current task, and make the label clear enough that visitors know they are sharing product feedback.
Define a simple status vocabulary before submissions arrive. Choose labels that reflect decisions your team actually makes, and document when an item moves from one state to another. Avoid statuses that imply a delivery promise unless the work has been scheduled and the expectation is clear.
Separate evidence from interpretation during review. Preserve the contributor's description, then add your own notes about scope, risk, and possible solutions. Use this distinction to help another reviewer understand what the customer reported without confusing it with assumptions introduced during triage.
Check whether the request affects one workflow or several. Break broad submissions into smaller decisions when independent parts could ship at different times. Keep links between the related items so contributors and reviewers can follow the larger problem without forcing everything into one oversized record.