How to launch a feedback board: your first 30 days

Feedback boards are great. They can massively improve your relationship with your customers. They’ll inform your development plans and help keep people in the loop.

But you know what stops them getting off the ground? Launching empty, without a proper plan. They’ll stay empty and become a forgotten side-project.

To stop this happening, there’s a few good decisions you can make before launch. With these, you’ll nurture a vibrant and useful feedback board where people make meaningful contributions.

Here's what to decide before you open the doors, and how to tell by day 30 whether it's working. This guide is for solo founders or small teams launching their first customer feedback board. It might be for a SaaS product, a game, or an open-source tool.

What a feedback board is (and what it isn't)

A feedback board is a public page where your users post feature requests and vote on the ones they care about. Your team reads the posts and replies to each one with a status: planned, started, completed, or declined.

The votes show you what people want (a quick way to validate feature ideas before you build them), and the statuses show your users that their feedback makes a difference.

You'll also see it called a product feedback board, a feature request board, or a feature voting board; all the same thing.

But you also need to know what it isn't:

• It's not a suggestion box. A suggestion box takes ideas in, and that's it. A board answers every idea with a status.
• It's not a forum. A forum is for open conversation, and nothing gets ranked or resolved. Ranking and resolving is exactly what a board does.
• It's not a roadmap. A roadmap is your team telling users what to expect next. A board is your users telling you what they want.
• It's not a changelog. A changelog records what was already shipped. A board is about what hasn't shipped yet.

Before launch: six decisions that decide whether anyone uses it

You can create a feedback board in an afternoon with any dedicated feedback board software. But make these six decisions first, because they affect whether anyone uses it or not.

1. Where does it live?

You don’t want a board nobody can find. Can a user reach it at the moment they think "I wish this did X"? That usually means a link in the product itself, like a help menu, a settings page, or footer. Plus the places people already go when something's missing: your help center or onboarding emails. Even at mention at the end of a support conversation.

Pick a permanent address and stick to it. A subdomain like feedback.yourproduct.com is the common choice, because it's easy to say out loud and easy to link from anywhere.

2. Do people sign in to post?

Yes, asking people to sign in means fewer posts and votes. But it also means every vote belongs to a real person and nobody can stuff the ballot. And when a request ships, you can go back and tell the person who asked. Anonymous boards trade all of that for volume, and then spend their time on spam and moderation.

One founder on r/SaaS went through this the hard way in 2026. He'd launched with open, anonymous voting, then realized he only knew what got easy clicks rather than what people wanted. So he switched to requiring a login. He reset every vote to zero in the process. Notice the detail that makes it sting less: his own users had upvoted the request to add the login requirement before he did it.

Our view is that sign-in is the right default for a board you intend to act on. Keep it to one click (Google, GitHub, or an email link) and the people with something to say will still say it. (Fider works this way: posting and voting need a sign-in, and you can offer whichever providers suit your users.)

3. Does it use tags?

Nearly every tool organizes posts with tags (some call them categories; in Fider they're tags, and we'll use that word from here). A handful is enough to start: "Integrations," "Mobile," "Reporting," whatever the three to six areas of your product are that users talk about. You can always add more once you see what people post.

Starting with 20 tags means the majority sit empty, and empty tags make a board look abandoned before it's begun. If a tag isn't useful to you when you triage, don't create it.

4. What does it launch with?

Seed your feedback board before anyone sees it. Don’t launch it empty.

This is a frequent piece of advice from people who've run boards. An empty board gives a first visitor no reason to think their input matters. They can’t see examples of what a good request looks like. They leave, and the board stays empty.

But it doesn’t have to be this way.

You already collect feature requests, even if nothing's written down: they're in your support inbox, your sales notes, your churn emails, and your own backlog. Before you tell anyone the board exists, pull out the things people have asked for the most. Write each one the way a user would, then post it.

Then the rules: seed only from real requests. Don't invent demand. Don't vote for your own posts to make the board look busier.

The first visitors should see a board that reflects what real users have said, because that's what makes them add to it.

If you have a beta or early-access group, open the board privately to them first. Let them post and vote for a few weeks, then make it public. Your public launch then starts with a board that's already active. (Fider has a private-site mode for exactly this; you can open it up later without losing anything.)

5. Who owns it?

Name one person.

A board needs someone for whom reading new posts and replying with a status is routine work, not a favor they do when they remember. If that person doesn't exist, the board won't get answered, and an unanswered board is a silent one within a month.

For a solo founder or a small team, the time commitment is small: 30 minutes a week covers it. What matters is that the 30 minutes is in the calendar and belongs to someone. We've written about what that weekly rhythm looks like once a board is running.

6. What does success look like?

There's no official benchmark for a healthy feedback board. So pick your own yardstick before launch, and make it modest.

Something like: by day 30, every post has a status and at least one request has gone from posted to shipped. Better still if a few of the votes came from people who never file support tickets. You'll refine it later. The point is to have a definition of success that doesn't depend on a number someone made up.

Launch week: opening the board

Once the board is seeded and someone owns it, launch is about telling the right people in the right order.

Start with the people whose requests you seeded. Before any broader announcement, email or message each person whose request is now on the board. Tell them it's there and ask them to vote. They already care, and they'll bring votes to posts that would otherwise sit at zero.

Announce it where your users already are. Not just a blog post. Put it in the product (an in-app message or a banner). Or in your next release notes, in your newsletter, in your Discord or Slack community.

Make the links permanent. The announcement gets people there once. The in-app link, the footer link, and the help-center link get them back. Put those in place during launch week, not afterwards.

Reply the same day. Every post in week one should get a response within hours, even if it's just "Thanks, we're looking at this" with a status set. Launch week will set the tone. People who post and hear back quickly will post again.

Days 2 to 30: proving the board is alive

After launch week, the job is to demonstrate, visibly and repeatedly, that posting leads somewhere. Five short habits for this are:

Every post gets a status. A post with no status looks unread, even if you've read it three times. Planned, started, completed, or declined: pick one and set it.

Say no early. If you need to decline, do it with a short, plain reason. You'll show that the board is a place where decisions get made, not just collected. Leaving a request in limbo because you're afraid of the reaction is worse than a clear “no”.

Merge duplicates as they appear. Two posts asking for the same thing split the votes. Link or merge them early.

Log requests on users' behalf. When someone asks for something in a support ticket, a call, or a Discord thread, add it to the board yourself and tell them you did. Now they have a reason to visit..

Mark the first "completed" as soon as anything ships. Even something small. The first time a request moves from posted to completed is a milestone. (In Fider, everyone subscribed to a post is notified when its status changes.) That's closing the loop, and the sooner it happens in public, the sooner the board starts to feel real.

Day 30: how to tell if it worked

Go back to the goal you set before launch and check it.

Since there's no industry benchmark to compare against, look for signs of behavior changing:

• Repeat posters. Someone who posts twice has decided the board is worth their time.
• Votes from people who never file tickets. This is the board reaching users your support inbox doesn't.
• Questions you now answer with a link. Someone asks "is feature X planned?" and you reply with a link to the post. That's an explanation you don’t have to write from scratch.
• Zero unanswered posts. Nobody’s left hanging for an update.

If the signals are weak, go back to the six decisions above. Fix the one that's off. If the board has been live longer and gone properly silent, the revival steps might take a different approach.

And once the requests are flowing, the next problem is a better one to have: deciding which of them to build.

The one thing to do today

Before you set up anything, decide what you'll check on day 30. Write it down and put a reminder in the calendar.

Everything else in this guide follows from that. If you know what "working" looks like, you'll seed the board properly and make someone own it. You'll reply to the first posts within the day, because those are the things that get you there.

‍