pick a featurePublic Feedback Board: What It Is and How to Set One Up
Building a product without hearing from users is a guessing game. You ship features based on assumptions, miss the problems your users actually have, and wonder why retention stalls. A public feedback board solves this by giving users a place to tell you exactly what they want, and letting the community sort the most important requests to the top.
The phrase "public feedback board" shows up in a lot of product conversations, but teams often confuse it with support ticketing or NPS surveys. It's a specific tool with a specific function, and understanding how it works makes the difference between a cluttered inbox and a clean, prioritized feature backlog.
A public feedback board is a shared space where users submit feature requests, vote on ideas from others, and track each request's status. Your team uses the vote count to prioritize what gets built next, then updates statuses so users see what's happening. Every approved request is visible to all users, creating a shared prioritization layer across your entire product community.
What a Public Feedback Board Is
A public feedback board is a web page or embedded widget where your users can suggest features, upvote each other's ideas, and leave comments. The "public" part matters: every user sees every approved request. That shared visibility is what turns individual asks into prioritized demand signals.
It's different from a support inbox. A support ticket is a one-to-one conversation between you and one user. A public feedback board is many-to-one: dozens or hundreds of users vote on the same idea, turning "one person wants dark mode" into "847 people want dark mode," which is information a support queue can't give you.
Public feedback boards also differ from NPS surveys, CSAT scores, and in-app microsurveys. Those tools capture sentiment at a point in time. A feedback board captures intent over time: what users want built next, ranked by demand.
Public feedback boards occupy a distinct category within product management tooling. The category grew out of a gap that emerged as SaaS products scaled past their initial user base: support tickets captured one-off complaints, product analytics showed behavior, but neither captured what users actually wanted built next. Boards like Canny, Frill, and Nolt formalized the model: a user-facing URL or embeddable widget where any user can suggest a feature, vote on ideas from others, and track status changes. Most tools in this category support the same workflow: a submission flows into a moderation queue, the product team approves or merges duplicates, and approved requests enter a status pipeline (pending, under review, planned, in progress, completed). Pricing varies from free tiers with usage limits to enterprise plans above $100/month. The hosted-board model, where the board runs on the vendor's domain and teams share a link, typically costs less than fully embedded native SDK tools and works across mobile and web platforms without requiring a separate SDK.
How a Public Feedback Board Works
The mechanics are straightforward. A user visits your board via a direct link or embedded widget, types a request, and submits it. Other users see that request and can upvote it (one vote per user, per request) or leave a comment.
Your team reviews submissions in a dashboard. You approve relevant requests, reject duplicates, and can merge two similar requests into one so their votes combine. Once approved, a request moves through a status workflow: pending, under review, approved, in progress, planned, and completed, with users following status changes along the way.
The moderation step is what separates a well-run public board from a chaotic one. Without it, boards fill up with duplicates, bug reports, support questions, and vague asks. With active moderation, the board becomes a clean signal: the top-voted requests reflect what your actual users care about most.
On the collection side, you can accept submissions from three surfaces: a hosted board URL you share in your footer, an embeddable web widget on your site, and an in-app SDK widget for mobile apps. Each path varies in setup complexity and submission rate.
Public Board vs Private Board
Some feedback tools offer private boards: only your team can see submissions. Private boards work for internal product planning, beta feedback from a small group, or early-stage teams that aren't ready to show the public what's being requested.
Public boards serve a different purpose. When users can see each other's requests, duplicate submissions drop because users search before submitting, the community self-curates (a request with zero votes after 60 days tells you something), and users feel heard even when you decline a request because they can see you're tracking it.
For most consumer apps and SaaS products with more than a handful of active users, a public board is the right default. The transparency builds trust. Users know their feedback doesn't disappear into a ticket queue that nobody reads.
Private boards make more sense for enterprise tools where customers have contracts and roadmap visibility is commercially sensitive, or for very early-stage products where the team wants to control what appears publicly before launch.
Setting Up a Public Feedback Board
Three setup paths cover most use cases.
Hosted board link. Every tool in this category gives you a public URL for your board. Share that link in your app's settings page, website footer, or changelog. Users click it, it opens in a browser, and they can submit and vote immediately. This path works for any platform, including iOS, Android, React Native, and web apps. No SDK required.
Web widget. For websites and web apps, drop in a JavaScript snippet that renders a floating feedback button or an inline board on your page. The widget typically runs in a Shadow DOM overlay to avoid CSS conflicts. Setup takes about five minutes on any HTML, React, Next.js, or Vue project.
In-app SDK. Flutter developers can add a full-screen widget, dialog, or bottom sheet directly inside the app using a native SDK. The widget handles anonymous device identity, theming, and error states. Users never leave the app to submit a request.
The hosted link approach is the fastest path to a working board. For higher submission rates, bringing the board inside your app or site rather than linking out tends to drive more completions.
How pick a feature Handles This
pick a feature is a feedback board built for Flutter developers and indie teams. Every project gets a hosted public board at pickafeature.com/b/your-slug that you can link to from any platform via in-app browser, including iOS (SFSafariViewController), Android (Chrome Custom Tabs), and React Native (expo-web-browser). For web apps, a one-script-tag widget adds a floating feedback button or inline embed to any page.
The dashboard shows every submission with its vote count, status, and author. You approve or reject requests before they appear publicly, merge duplicates with a drag-and-drop interface with votes carrying over, and move requests through a six-step status workflow. Per-platform analytics break down submissions by iOS, Android, web, and macOS, so you can see which platforms your most active requesters are using.
Pricing starts at free: 1 project, 10 requests, no credit card. The Starter plan is $5/month for 3 projects and unlimited requests. The Unlimited plan is $15/month for unlimited everything.
For teams comparing options, see how hosted feedback boards compare across tools and check the full feedback tool pricing breakdown for exact cost-at-scale numbers.
Frequently Asked Questions
What's the difference between a public feedback board and a feature request form?
A feedback form is one-way: the user submits and has no idea what happens next. A public board is two-way: submissions are visible to all users, who can vote and comment, and your team communicates status changes back to the community. The shared visibility is what makes a board useful for prioritization rather than just collection.
Do users need an account to submit on a public board?
Most boards, including pick a feature, support anonymous submission. Users without accounts get identified by a device UUID so their votes persist across sessions. If you've built sign-in into your app, you can attach a name, email, and user ID to each submission for richer context in the dashboard.
How do you prevent a public board from filling up with duplicate requests?
Two practices help. First, enable a search-before-submit prompt so users see existing requests as they type. Second, use the merge-duplicates feature in your dashboard: merge two cards and the votes combine into one. Over time, a well-maintained board surfaces a clean top-10 list rather than 40 variations of the same ask. The full workflow is in how to merge duplicate feature requests.
Can a public feedback board replace a dedicated public roadmap?
Partially. A public board shows users what's being requested and the current status of each item (planned, in progress, completed), which gives a partial view of your priorities. A dedicated roadmap tool adds a timeline view with milestones, release notes, and changelog pages. If you need those features, you'll want a separate tool. If showing request statuses is enough for your users, a board alone works fine.
Is a public feedback board suitable for mobile apps?
Yes. You don't need a native SDK for mobile. The hosted board URL opens in an in-app browser (SFSafariViewController on iOS, Chrome Custom Tabs on Android) and works like any mobile-optimized web page. Flutter developers can also use the native SDK for a fully embedded in-app experience. React Native and Kotlin Multiplatform apps use the hosted board URL approach.
If you're ready to collect feature requests from your users, pick a feature gets you a live public board in about five minutes. The free tier covers 1 project and 10 requests with no card required.