How Commure prioritizes thousands of customer requests

At any meaningful scale, you start to get a lot of feedback from customers. Some of it is things they’d like to see in your product, some of it is points of friction, and all of it is worth something.

The trouble is that collecting it and pushing it through some kind of filtering and sorting process is hard to do without it feeling really manual, so at most companies it just piles up. And when feedback piles up, the loudest voice wins, which is usually the biggest customer or the most recent call rather than the thing your product actually needs.

Even when they’re asking for the same thing, not every customer is equal. A bug affecting a hundred smaller accounts might matter less than a rough edge for a single enterprise customer, or it might matter more. Without a deliberate way of weighing this, you end up building exactly what customers asked for, which is not always what they actually need, or sometimes, nothing at all.

Commure, the AI-native enterprise RCM platform for health systems, had reached this point. When the company was smaller, working through customer requests one at a time was fine. The team could hold the whole customer base in their heads, and move quickly from one thing to the next. But as they grew, the weight of each decision started to increase, and the question they asked themselves evolved from “what does this customer want” to “what does the shape of all our feedback tell us about where the product should be going.”

Commure’s answer is what Myles Baumann, a product manager at the company, describes as a bicameral system. One view tracks customer requests by count, treating every customer equally. Another weighs them by the size of the customer. He calls them the House of Representatives and the Senate.

A request that shows up across fifty smaller customers tells them about breadth, a friction point the product creates for a lot of people. A request from one large enterprise customer carries a different kind of weight, since the consequences of ignoring it are different. Looking at both together gives the team far more precision than either one alone.

Every week the product team reviews these views together, looking at which requests come up most often and what themes emerge across them. Individual requests are, as Myles puts it, “faster horses”. Customers describe the pain they can see in the terms available to them, and the team’s job is to read across enough of them to work out what they’re all pointing at, then build the car.

Prioritisation is only half of it, though. Once the work ships, someone has to tell the customers who asked. Commure keeps a dedicated Slack channel for each of its customers, run by customer success managers who aren’t necessarily in Linear every day to keep tabs on the work.

So Commure connected a Linear view for each customer to their Slack channel. When an issue in the view is completed, a notification lands in the channel automatically. The CSM is alerted, and lets the customer know that the thing they requested is now live in the product.

Myles reckons that telling a customer you heard them, and that the thing they asked about has been done, is worth twice as much as actually doing it.