Rezee vs Canny and Productboard - where should customer feedback live?
Canny and Productboard are good at hearing customers. The issue, the code and the release that answer them live somewhere else. An honest comparison with Rezee's model, where feedback sits in the same workspace as the work.
Oct 20, 2026 · 6 min read · Kash Gohil · LinkedIn · X
Most software teams that take feedback seriously use a dedicated tool for it. Canny and Productboard are two of the best known. Rezee now has customer feedback as part of Plan, in the same workspace as the issues, pull requests and releases that answer it. This comparison is about which model serves a product team, not about which form looks nicer.
Short version: Canny and Productboard are mature products with years of work in them. Rezee's feedback module shipped in October 2026. They do several things Rezee does not do at all, and we list them below. The case for Rezee is narrow: the seam between the feedback tool and the tracker is where the reply to the customer gets lost, and Rezee does not have that seam.
What do Canny and Productboard do well?
Canny made feedback public and simple. Customers post an idea, other customers vote on it, and the team sees a ranked list that it did not have to build. A public roadmap and a changelog sit beside it. People who voted can hear when the status changes. For a company that wants its users to see what is planned, that openness is the product, and it works.
Productboard is a tool for product managers. Feedback from many places becomes notes, notes link to features, and features get prioritised and placed on roadmaps for different audiences. It is built for the person who has to explain to a leadership team why this quarter holds what it holds. Its depth in that job is real.
Both connect to the trackers that engineering uses, and both have added AI that helps group and summarise feedback. Neither is the problem. The problem is what sits between them and the work.
Where is the seam?
The link is an integration. A request in the feedback tool links to an issue in Jira, Linear or GitHub. The two records are in two products, and a sync keeps them in step. When the sync works, it carries a status field. When an issue is split, moved or closed as a duplicate, the link points at something, but not always the thing it meant.
"Done" is a status somebody set. The feedback tool learns that work is finished from the tracker's status. It cannot see the pull request or the release. So the reply to the customer depends on a field that a person or a mapping keeps correct.
The demand is on the wrong side. Engineers work in the tracker. The number of customers who asked, and what their accounts pay, sits in the feedback tool. It reaches the tracker as a field that an integration copies, or as a link that somebody must open.
Two places hold customer data. Feedback carries names, addresses and the customer's own words. In a two-tool setup they live in the feedback tool, and in the tracker too whenever an integration copies them there. That can mean two places to keep, two retention rules and two lists of who can read it.
None of this is a defect in either product. It is the shape of two products that meet at an API.
What Rezee does differently
One workspace underneath. A piece of feedback is a row beside the issue it asks for. Everything below is verified in the product today.
Demand is on the issue. An issue with linked feedback shows "Customer demand": customers, accounts and what those accounts pay in a month, with each piece of feedback under it. Views can filter and sort by demand. No field is copied. The numbers come from the links.
Themes become issues through the same queue as everything else. A model reads each piece for what it asks, groups the phrases into themes, and gives each theme a trend and a severity. From a theme, "Draft an issue" or "Draft a spec" puts a draft into Intake. A person accepts it, and Rezee files one issue linked to every piece in the theme. Nothing becomes work without that person.
The reply follows the work. With notices on, each customer linked to an issue gets one email when the issue reaches Done or ships in a release or a deployment. The email quotes what the customer said, never the internal issue title. It links to a status page and has a one-click unsubscribe. The release notes get a "Customer requests answered" section that counts who asked and never names them. The release, the issue and the feedback are rows that one query joins, so there is no mapping to keep correct.
Feedback has its own permission. The body and the customer stay behind feedback:read, which owners and admins hold by default. The Intake item that everybody triages carries only a short title, with addresses and phone numbers replaced. An admin sets how long feedback is kept, and can export or delete one customer's record.
Agents work on it through the same tools. An agent can file feedback with feedback_file, and the theme drafts go through Intake like any other agent proposal. If you already use agents in Rezee, feedback is more context they can read with the same permissions, not another integration to give a token to.
Whether this matters depends on one question: are your issues and code in Rezee? If they are not, most of this list does not apply to you.
Where Canny wins, plainly
- Public boards and voting. Rezee has no public board, no votes and no public roadmap. Feedback is private to the workspace. If you want customers to see each other's requests, Canny does that and Rezee does not.
- Help desk connectors. Rezee has no Zendesk, Intercom or Help Scout connector yet. A help desk can file tickets through Rezee's API, but somebody must write that script.
- It works with the tracker you already have. Canny connects to several trackers. Rezee's feedback connects to Rezee's issues only.
Where Productboard wins
- Product management depth. Prioritisation models, a feature hierarchy, roadmaps for different audiences. Rezee can sort issues by customer demand, and that is a much smaller thing.
- People outside engineering. Product, sales and leadership can work in Productboard without touching the tracker. Rezee is a workspace for the people who build the product, and its feedback is shaped by that.
- Maturity. Years of use by large product organisations. Our feedback module landed in October 2026, and its theme thresholds come from another analysis project, agnost, rather than from tuning on feedback.
Who should not switch
Be honest about this one. If your engineering lives in Jira or GitHub and is going to stay there, Rezee's feedback gives you a form, a widget and themes, but the loop it closes runs through Rezee's issues. You would get less than you have now.
The same is true if public voting is how you talk to customers, if your product managers present roadmaps from Productboard every month, or if your support team needs tickets to flow from a help desk today without a script.
Who this is for
Teams where the same few people read what customers say, decide what to build, write the code and ship it. For them, a feedback tool is a second place to look, and the reply to the customer is a task that needs somebody to remember it.
Teams already in Rezee for issues and code, for whom feedback is one more layer on the workspace they use, not another product with its own sync to watch.
For those teams the question is not "does it have voting". It is "how many customers asked for something we shipped, and never heard back". In most teams nobody measures that number, because two tools hold its two halves.