Public boards like Canny work well for consumer products with huge user bases where raw vote counts are statistically meaningful. For B2B SaaS products — where you have hundreds or thousands of customers rather than millions, and where one customer might represent 30% of your ARR — they create more problems than they solve.

This post walks through a better system for managing feature requests in B2B products: one that's private, weighted by business impact, and actually connected to your planning process.

The Problem with Public Voting Boards

Before building an alternative, it's worth understanding exactly what breaks with public voting.

✕They count votes, not value. A feature requested 200 times by free-tier users may be far less important than a feature requested 5 times by enterprise customers. Raw vote counts don't capture business impact.
✕They create expectations you can't fulfill. When customers see their request at #3 on the board, they expect you to build it next. When you don't — because #3 doesn't align with your strategy — you've created disappointment you didn't need to create.
✕They surface solutions, not problems. "Add a dark mode" is a request for a specific solution. The underlying problem — eye strain during long sessions — might have better solutions. Voting on solutions locks you into the wrong level of abstraction.
✕They make your roadmap public. Even when boards are vote-only (not publicly visible), sophisticated customers infer strategic direction from what you're tracking. Competitors can too.
✕They attract gaming. Salespeople tell prospects to vote up features they need. Power users coordinate votes. The data gets corrupted fast.

None of this means you should stop collecting feature requests. It means you should stop collecting them in a public, unweighted system.

The Better System: Private, Weighted, Connected

A good feature request management system has three properties that public voting boards lack:

1
Private — Customers submit feedback directly to you, not to each other. You capture everything without customers managing your roadmap or seeing what you're tracking.
2
Weighted — Every request is associated with a customer tier, ARR, and severity. Priorities are calculated by weighted impact, not raw counts.
3
Connected — When a request gets prioritized, it flows directly into your engineering tracker (Linear or Jira). You're not managing a separate system — it's part of your existing workflow.

Where Feature Requests Actually Come From

In most B2B products, feature requests arrive through at least five channels — and most teams only systematically track one or two of them:

Support tickets — Often the highest-volume source. A request phrased as a question ("Is there a way to export to Excel?") is still a feature request.
Sales calls — Features that are "deal blockers" or would have accelerated close. Sales teams hear these but rarely have a good way to get them to product.
Customer success check-ins — What customers bring up during QBRs, onboarding, and health reviews. These are often the most nuanced and strategic requests.
Slack and internal channels — Your team forwards customer messages or discusses what customers are asking for. This data is real but unstructured.
Direct emails — Customers who email the founder or PM directly, often with high-priority requests.

A system that only captures support tickets is missing at least four channels. The first step is connecting all of them to a single intake point.

How to Structure Incoming Requests

When a feature request comes in, don't just log the request verbatim. Transform it into a problem statement:

From Request to Problem Statement

Raw request:

"Can you add a CSV export for the reports section?"

Problem statement:

"Users who work in Excel-based workflows can't get their data out of the product, requiring manual re-entry and creating a barrier to regular use."

Why it matters:

The problem statement opens up solution space. Maybe CSV export is the right answer. Maybe it's a Google Sheets integration. Maybe it's a scheduled email report. You don't know until you understand the problem.

This reframing takes practice but becomes second nature quickly. The key question to ask: "What are they trying to accomplish that they can't do right now?"

Prioritizing Without Votes

Without vote counts, how do you decide what to build? You calculate a weighted priority score. Here's a simple formula:

Priority Score Formula

Score = Σ (customer_weight × severity_weight) for all affected customers

Customer weight: Enterprise = 5, Paid = 3, Trial = 1, Free = 0.5

Severity weight: Blocker = 3, Major friction = 2, Minor = 1

Example:

2 enterprise customers (blockers) + 5 paid customers (major friction) + 8 free users (minor)

(2×5×3) + (5×3×2) + (8×0.5×1) = 30 + 30 + 4 = 64

This gives you a ranked list that reflects business impact rather than request volume. The feature with 8 free-user votes (score: 4) gets deprioritized against the feature 2 enterprise customers can't work without (score: 30).

Closing the Loop with Customers

The most important thing you give up when you move away from a public board is the customer's ability to see their request's status. You need to replace that with something better: proactive communication.

→When you log a request: Acknowledge it. A one-sentence reply ("Thanks — we've logged this and it'll inform our planning") sets expectations without committing to timelines.
→When you ship something related: Tell the customers who asked for it. "You mentioned needing CSV export back in February — we just shipped it" is a powerful retention moment.
→When you decide not to build something: You don't have to announce it, but if a customer follows up, give them a real answer. "We decided to solve this a different way — here's how" respects their time.

This approach requires more individual effort than a board where customers can just check a status page. But it produces dramatically better customer relationships and is far more honest about how roadmap decisions actually get made.

When Public Boards Do Make Sense

Public voting boards aren't universally wrong — they're wrong for most B2B SaaS products. They do make sense when:

•Your customer base is large enough that raw vote counts are statistically meaningful (think thousands of active users, not hundreds)
•Customer ARR is relatively uniform — nobody is "10x" more important than anyone else
•You want to build community and transparency as a strategic differentiator
•You have the bandwidth to manage customer expectations actively

If your product doesn't fit all four of these, a private weighted system will give you better information and better customer relationships.

Track feature requests the right way

Distil captures feature requests from every channel — support tickets, Slack, email — structures them by business impact, and pushes the top priorities directly to Linear or Jira. No public board required.

Try Distil free

How to Manage Feature Requests Without a Public Voting Board