Product & DesignFree
Prioritize Feature Requests by Account
Four exports go in and one table comes out, each row naming the accounts behind a request and the share revenue can reach.
River takes all four exports as they came out of the vendor, headers, blank columns and duplicate rows included. Each request is grouped by the problem behind it. A request for a dashboard and a complaint about not being able to see your numbers end up in one cluster. What comes back is a single table with a row per cluster, holding the request count, the distinct accounts behind it, and the revenue those accounts represent.
Guides to this all stop in the same place. Centralise the feedback, cluster it, weight it by revenue, and nothing about which file carries that number. A Canny posts export is thirteen columns and the last of them is Associated MRR. A Productboard feedback export is nineteen fields, twenty-two with features attached, and not one names revenue. The instruction is identical for both files and only one of them can follow it.
Built for the product manager holding four exports and a planning meeting on Monday, and for the founder who is also the whole product team. Reach for it when the pile has grown past the point of reading it end to end. It also earns its place when somebody senior asks why the roadmap does not match the top of the board. The same work on interview transcripts is research synthesis, the cluster that wins usually becomes a PRD, and the order you ship them in is a roadmap narrative.
Two of the four exports can carry revenue
The two feedback tools share exactly one field, and neither of them invented it. Canny calls it domain, and its API describes that field as used to match companies across data sources. Productboard calls it company_domain. Everything else is disjoint. Canny emits a post author, Productboard emits a user email and two UUIDs, and those two sets never meet. So the company domain is the join key by elimination, and it is how a Productboard note inherits a revenue figure Productboard never stored.
Revenue in Canny is an attribute of the company rather than of the request. Sum that column down a cluster and every account gets counted once per row it happened to file. In one real pile the single sign-on cluster had 82 revenue-bearing rows behind it, which came to $734,900 summed down the column and $219,700 summed across the 31 distinct accounts. The column overstates the cluster by 3.3 times, and $162,000 of that is one account paying $18,000 that filed nine separate requests.
The pile is also smaller than it looks. Of 1,204 exported rows, 520 carry no text at all. An Intercom conversations CSV ships reporting metadata without the message bodies, and Productboard blanks note_text on anything a helpdesk created. That leaves 684 rows with something to cluster on. An App Store review is six fields whose only identity is a nickname, so the mobile cluster's revenue coverage cannot pass 14 percent however well the CRM syncs.
How it works
Hand over the exports
All four if you have them, however each vendor formatted the file, headers and blank columns included.
Check what has text
Rows with no text are counted and set aside, because a metadata row is not evidence of demand.
Cluster by need
Requests grouped by the problem behind them, so a symptom and the fix somebody proposed land together.
Weight by account
Requests, accounts and revenue for every cluster, each number labelled with the coverage it rests on.
What you get
- One row per request, carrying the export it came from and the account behind it
- Clusters named for the need behind the request, not the words the requester used
- Each cluster counted three ways: requests, distinct accounts, and revenue behind them
- Revenue summed once per account, so an account that filed nine times counts once
- Coverage stated per cluster, with the sources that can never carry revenue named
- The rows that arrived with no text listed separately rather than quietly dropped
Common questions
Do I just build whatever has the most votes?
Only if votes are what you are optimising for. In the pile above, the top cluster by request count came third by revenue, and the cluster that climbed three places was fifth on requests. Both orderings come from the same 419 requests. The table reports requests, accounts and revenue next to each other, so the choice is one you make rather than one you inherit.
My support export came out with no message text. Now what?
That is the export working as documented. Intercom's own limitation note says a CSV carries reporting metadata rather than conversation content, and Productboard leaves note_text blank on any note a helpdesk created. Those rows are reported as unclustered instead of being counted as demand, and you are told how many of them there were.
Can I weight by revenue if we have no CRM connected?
No, and the column will not warn you. Canny does not calculate Associated MRR. It arrives from a Salesforce or HubSpot sync, the SDK, the API, or somebody typing it in, so a workspace with nothing connected exports that column full of blanks. Coverage is reported per cluster for exactly this reason, so a cluster resting on four matched accounts out of ninety says four.
How do I stop re-litigating requests we already closed?
By matching the new pile against the closed items, not only the open backlog. A request declined two years ago for a reason that no longer applies is a different decision from a duplicate, and in a vote count the two are indistinguishable. Anything matching a closed item is flagged as revived, with the original reason and its date attached.
Won't the most visible requests just collect the most votes?
They will, which is why the request count sits next to the account count rather than replacing it. The top item on a board is the one nobody has to scroll for, so part of its score is placement. Counting distinct accounts removes the cheapest version of that bias, and the coverage column shows how much of a score is anonymous review traffic.
Canny and Productboard disagree about how many people asked. Which is right?
Usually both, inside their own scope. One counts posts and the other counts notes, and the same person can appear in each. Joining on the company domain is what makes the two comparable at all, and whatever difference survives that join is a reconciliation problem rather than a tie to break. Tickets, reviews and sales calls disagree for the same reason, which is what voice of customer analysis covers.
Does this replace Canny or Productboard?
No. They collect and they merge, and Canny's automatic merging works on text similarity inside a single board. This runs after the export, across four differently shaped files at once, and keeps the source of every row it counted. When a cluster turns into a shipped change, the experiment readout is built from the same rows.
Prioritize Feature Requests by Account
Fill in the form and your workspace opens with the work already underway.