How to prioritize customer feedback when you have no PM

You do not have a feedback problem. You have a deciding problem.

The feedback arrives fine: board posts, emails, support threads, that one customer who writes paragraphs at 4am. The pile grows. Every tool you have tried organizes the pile and hands it back. Organizing was never the hard part.

At companies with product managers, a human absorbs this. They read everything, merge duplicates, weigh the requests against revenue and strategy, and walk into planning with a short list. You do not have that human. You have twenty minutes between a support ticket and a deploy, and the honest answer to "what should I build next" is usually "whatever was loudest this morning."

This is the complete system for fixing that as one person. Every step works in a spreadsheet. (Or you can let Thumbsum run the mechanical parts — but learn the system first; the system is the value.)

Why the usual methods fail solo founders

Before the system, a quick autopsy of what you have probably tried:

Vote counts. Votes measure loudness, and loudness correlates with free users who have time to campaign. Your quietest customers are often your largest. A board sorted by votes is a popularity contest your revenue did not vote in.

Frameworks like RICE. Reach, impact, confidence, effort — four numbers you invent, multiplied together to produce false precision. Scoring twenty requests takes an evening; keeping scores current is a part-time job. RICE was built for PM teams with time to maintain it.

"I keep it in my head." You do, for about eleven requests. Then a crunch week arrives, the head empties, and the March requests are gone by June. Human memory is the wrong database for this.

Reading everything weekly. The noble failure. It works for exactly as long as your discipline holds, which is until the first production incident. Systems that depend on your best week fail on your worst one, and your worst weeks are when prioritization matters most.

The common flaw: all four make prioritization a recurring manual tax. The fix is to make the expensive parts mechanical and keep only the deciding for yourself.

Step 1: Collapse duplicates by intent, not by words

"Add SSO", "sso when??", and "SAML support for enterprise please" are one request wearing three outfits. Before anything else, group by what people mean. A group of five is a signal; five scattered posts are noise, and worse, they let you undercount your most demanded work.

Two traps here:

The wording trap. Nobody phrases a request the same way twice. Grouping by keyword misses "the search ignores hyphens" and "wi-fi returns nothing but wifi works" being the same bug. Read for the concrete ask underneath.

The topic trap — the opposite failure. "Jira integration" that pushes your data INTO Jira and "Jira integration" that pulls Jira data into your product are two different builds with two different audiences. Same topic, different asks. Group by the ask.

In a spreadsheet: one row per request, a column for "what they actually want" written in ten words or fewer, then sort by that column and merge. The ten-word discipline matters — if you cannot state the ask in ten words, you have not understood it yet.

Step 2: Put money next to every group

This is the step almost everyone skips, and it is the entire system.

For each group, answer three questions:

1. How much monthly revenue is behind it? Sum the subscriptions of everyone who asked. Not weighted scores, not t-shirt sizes — dollars per month, from your billing dashboard.
2. What is the single biggest account in the group? One $400/mo customer asking quietly outweighs six free users asking loudly. The max matters separately from the sum.
3. How many distinct paying accounts? Breadth is its own signal — $500 from one account and $500 from ten accounts are different bets.

A spreadsheet with real MRR per request group will change your roadmap in one afternoon. Expect discomfort: the feature you have been excited about probably has $0 behind it, and something boring — an export button, a permissions tweak — has $800. You do not have to obey the number every time. You do have to know it every time. Deciding against the money is a strategy; not knowing the money is a gamble.

One rule while you do this: count people, not posts. A customer who filed three duplicates is one customer. Summing their subscription three times is how boards quietly lie to you.

Step 3: Separate the four decisions

Every group falls into exactly one of four buckets, and each bucket has a different correct move. Mixing them is why generic "priority scores" feel wrong — a churn risk and a feature request are not the same kind of urgent.

Someone unhappy is waiting. A paying customer reported a problem and nobody answered. This outranks everything on the list, because it is the only bucket with a countdown attached: every silent day is a renewal decision forming without you. The move is not "build the fix this sprint." The move is reply today — acknowledge, give honest status, buy the time to fix it properly. Churn is usually caused by silence, not by bugs.

Demand crossed a line. Enough money or enough distinct people behind one ask. Pick your own thresholds and write them down — for example, $200/mo combined or four paying accounts — so the decision is a rule, not a mood. When a group crosses, it becomes a build candidate: estimate the effort roughly (small/medium/large is plenty) and give it a date.

You shipped it and never told anyone. The quiet killer. People asked, you built it, they never found out. Scan your resolved work against your request groups; every match with un-notified requesters is ten minutes of email that outperforms any marketing you will run this month. More on this in closing the loop properly.

You promised and slipped. You said March; it is April; the thing has not started. The move is either start it or move the date and tell the people waiting — anything except silence. A public roadmap with stale dates is worse than no roadmap; it documents your promises breaking in real time.

Step 4: Cap the queue at five

Not fifty prioritized rows. Five things, ranked by the money math from step 2, reviewed once or twice a week, each tagged with its bucket from step 3 so you know the kind of move it needs.

Five is not arbitrary. It is roughly what one person can hold with real intention — enough to always have a next action, few enough that every item has actually been considered. Everything below the top five does not exist until it earns its way in by accumulating money, people, or age. This sounds brutal and is the opposite: a backlog you never read is not a plan, it is guilt with a scrollbar. The cap converts an infinite obligation into a finite decision.

The weekly review is fifteen minutes: has anything crossed a threshold, has anyone gone unanswered, did anything ship without its loop closed, is any promise slipping. Four questions, five cards, done.

Step 5: Close every loop

When you ship something people asked for: tell them, by name, before you tell anyone else — then put it in a public changelog crediting "the 6 people who asked."

This step compounds in a way none of the others do. Customers who see their requests shipped file better requests: more specific, more honest, earlier in their frustration curve. Six months of consistent loop-closing turns your feedback channel from a complaint box into a research pipeline. Skipping it teaches the opposite lesson — that feedback here is a donation — and your best signal source dries up so quietly you will blame the market.

What this costs, honestly

Run manually, the system is one to two hours a week: half for grouping and money-matching new feedback, half for the queue review and loop emails. That is a real cost, and there is a second, worse one — the discipline itself. This system, like every manual system, will collapse during your first crunch week. That is not a character flaw. It is the reason the PM role exists at bigger companies: prioritization is a job, and jobs need someone whose calendar defends them.

If the manual version keeps collapsing, that is the exact gap Thumbsum was built for: the grouping by intent, the money math per group, the four buckets, the queue of five, and the loop-closing all run themselves — each decision arrives with its arithmetic shown, and you keep only the part that requires you. Whether you automate it or grind it, run the system. The pile on your desk already knows what to build next. The only question is whether you can hear it.

---

Further reading: Closing the feedback loop, properly · Canny alternatives compared · Feature request management, end to end