Define your feedback strategy

Before you create a single board or invite a single user, answer one question: what do you want feedback to help you decide?

Every successful feedback program starts with intent. Without it, you'll collect a pile of requests that nobody acts on, and users will notice. This lesson helps you set a foundation that makes every other decision easier.

Who is your feedback for?

Your audience shapes every configuration choice. Be specific about who you want to hear from:

Internal team only. You're collecting feedback from colleagues - support tickets, sales requests, internal ideas. Keep the portal private, use SSO for authentication, and don't worry about branding. The priority is low friction for your team to log what they're hearing.

Power users and beta testers. You want signal from your most engaged users. Keep the portal invite-only or behind authentication. These users give detailed, high-quality feedback, but remember they don't represent your average user.

All customers. You want broad input. Make the portal public, keep sign-up simple, and invest in branding so it feels like part of your product. You'll get higher volume but more noise - that's a tradeoff you manage with triage.

A mix. Most teams land here eventually. Start with one audience and expand. Trying to serve everyone on day one leads to a portal that serves nobody well.

What decisions will feedback inform?

"Collect feedback" is not a goal. Define 2-3 specific questions you want feedback to answer:

• Roadmap prioritization. "Which features should we build next quarter?" This is the most common use case. You need boards for feature requests, good tagging, and a voting system your users actually use.
• Bug triage. "Which bugs are affecting the most users?" You need a separate Bug Reports board with clear status workflows and fast response times.
• Customer retention. "Why are users churning?" You need private feedback channels, segment data to correlate feedback with customer health, and integrations with your CRM.
• Product-market fit. "Are we building the right product?" You need open-ended feedback, not just feature requests. Consider a General Feedback board where users can share anything.

Write your 2-3 questions down. You'll reference them when deciding what boards to create, what statuses to use, and how to prioritize.

What does success look like?

Set concrete goals so you can measure whether your feedback program is working. Vague goals lead to abandoned feedback portals.

Bad goals:

• "Collect more feedback"
• "Engage with our users"
• "Be more user-driven"

Good goals:

• "Ship 3 user-requested features this quarter"
• "Respond to every piece of feedback within 48 hours"
• "Reduce duplicate feature requests by merging related posts"
• "Use feedback data in every sprint planning meeting"

Pick one primary goal and one secondary goal. You can always add more later, but starting focused keeps the program manageable.

Common mistakes to avoid

Collecting without acting. The fastest way to kill a feedback program is to collect 200 posts and act on none of them. Users check back. When nothing changes, they stop contributing. If you're not ready to act on feedback, you're not ready to collect it.

Making everything public too early. A public portal means users can see each other's feedback, your responses, and your lack of responses. If you're not confident you can maintain a response cadence, start with a private portal and open it up when your process is solid.

Over-engineering from day one. You don't need 10 boards, custom statuses, a tag taxonomy, and Slack integration before you launch. You need one board and a commitment to check it regularly. Add complexity when the pain is real, not when it's hypothetical.

Copying another company's setup. Canny's public board works for Canny because they have a dedicated team managing it. Your feedback program should match your team's capacity. A simple setup you actually use beats an elaborate one you abandon.

Your strategy checklist

Before moving to the next lesson, you should be able to answer:

1. Who will submit feedback? (Internal, power users, all customers, or a mix)
2. What 2-3 questions will feedback answer?
3. What does success look like in the first quarter?
4. Will the portal be public or private to start?

You don't need to write a document. Just have clear answers. They'll guide every decision in the lessons ahead.

What's next

Now that you have a strategy, it's time to configure Quackback to match it. Next up: Structure your workspace.

For a refresher on Quackback's building blocks, see Core Concepts.