The 200-Feature-Request Problem (And How I Stopped Drowning In It)

The doc I stopped opening

For about 14 months, I had a Notion page called "Feature Requests."

By the time I admitted it was broken, it had 247 entries. Some were one-liners I'd typed on my phone after a Zoom call. Some were entire customer emails, pasted in with no context. Some were tagged. Most weren't. A few had dates. A handful had the customer's name. There were duplicates I knew about, and I'm sure many I didn't.

I stopped opening it sometime around entry 180. I didn't make a conscious decision. I just noticed, one Tuesday, that when a customer asked "are you going to build X?" I no longer searched the doc. I searched my memory, which was worse but faster.

That's the actual failure mode of a feature request backlog. It's not that it gets long. It's that it gets long in a way that punishes you for opening it. Every visit costs more than it pays back, so you stop visiting. And then you're flying blind while sitting on top of a goldmine of user research.

Why backlog tools didn't fix it

I tried the usual rotation. A Trello board. Then Linear. Then a Canny instance for about three weeks. Then back to Notion, because the friction of moving a half-formed thought from "customer just said something" to "structured backlog item with type, priority, and component tags" was too high to sustain.

Here's the thing nobody admits about feature request backlog management tools: they assume the bottleneck is storage and voting. It isn't. The bottleneck is synthesis.

A vote count tells you 12 people upvoted "better Slack integration." It does not tell you:

• Whether those 12 people meant the same thing (they didn't).
• Whether 30 other people described the same underlying need without using the word "Slack."
• Whether the people who voted are the ones paying you, or the ones on a trial that already churned.
• Whether the request, once you actually solve it, would prevent the next 50 requests like it.

So the doc kept growing, the tool kept tallying, and I kept making roadmap decisions based on whichever conversation I'd had most recently. Recency bias dressed up as customer obsession.

What I actually wanted from the doc

When I forced myself to articulate it, I wanted four things, and none of them were "a sorted list."

1. Themes, not items. Twenty requests about "exporting data" are one problem, not twenty.
2. Who said what. A request from a $400/mo customer is different from a request in a Reddit comment. I needed the source attached, always.
3. What I've already decided. Half the requests in my doc had been implicitly rejected months ago. I just had no record of it, so the same conversation kept restarting.
4. A re-readable summary. Something I could open on a Sunday with coffee and actually finish reading in 20 minutes.

The doc gave me none of these. It gave me a chronological wall of text.

The synthesis habit that actually worked

What finally moved me out of the swamp wasn't a new tool. It was a weekly habit, then later, automation. Here's the manual version, which you can start doing this week:

Step 1: Stop sorting. Start clustering. Once a week, open the doc and group entries by underlying job, not surface feature. "Add CSV export," "let me download my data," and "API for reports" are one cluster. Name the cluster. Don't worry about the perfect taxonomy.

Step 2: Attach a source tag to everything. At minimum: customer name (or "anon"), plan tier, and date. If you can't remember, write "unknown." Unknown is data too — it tells you the request came in via a channel you weren't capturing.

Step 3: Write a one-paragraph summary per cluster. Not bullets. Prose. Something like: "Six customers across the Pro tier asked for some form of bulk export between Jan and March. Three of them specifically wanted it for monthly reporting. Two churned before we shipped anything. The workaround (manual CSV) was mentioned as 'painful' by four of them."

That paragraph is the thing you re-read. Not the 247 entries underneath.

Step 4: Keep a "decided against" list. When you reject a cluster, write down why and when. Future-you will thank present-you when the same idea comes back in six months and you can answer in 30 seconds instead of re-litigating.

Step 5: Delete nothing, but archive aggressively. Move old, resolved, or clearly-dead clusters into an archive section. The doc should reflect the current state of your product's pressure points, not its entire history.

What changed when I did this

The doc became 9 clusters instead of 247 entries. Two of those clusters were responsible for most of the volume. One I shipped in a month. One I deliberately rejected and wrote a public note about, which I now link customers to. The other seven informed my roadmap for the rest of the year.

I'm not claiming this is revolutionary. It's just that "synthesize weekly" is the move, and every tool I tried was helping me with the wrong step.

Where I am now

The manual habit is the foundation. But the part that always slipped was step 3 — writing the synthesis paragraph. On busy weeks, I'd cluster but not summarize, and the doc would start drifting back toward unreadable.

That's the part I now offload. I built Omentoo partly to scratch this itch: it reads through raw feedback — support threads, sales call notes, the messy Notion doc — and produces the re-readable synthesis layer. Clusters, source attribution, the one-paragraph summary per theme. The stuff I kept failing to do on Fridays at 5pm.

If your own feature request doc has crossed the threshold where you've stopped opening it, you can poke at Omentoo here: https://omentoo.com. And if you'd rather just steal the weekly habit above and never click anything, that's a fine outcome too. The doc is the problem. The synthesis is the fix. The tool is optional.