When Does a Spreadsheet Stop Working for Tracking Feature Requests?
Somewhere between ten and twenty people touching the same sheet, or a few dozen new requests a month, is roughly where a spreadsheet or an ad hoc Notion doc stops working for tracking feature requests. That range is a rough guide, not a hard limit, because the actual trigger isn't headcount or row count. It's whether anyone can currently answer "how many customers asked for this, and did we ever tell them it shipped" in under a minute. Once that answer requires scrolling through rows or pinging whoever "owns" the sheet, tracking has already stopped working; the team just hasn't admitted it yet.
The next step isn't "buy a tool." It's figuring out which specific thing broke, because a spreadsheet fails in a handful of predictable ways, and the fix for each one is different. Sometimes the fix is a better sheet. Sometimes it's a real system.
An Ask HN thread titled "How do you deal with customer feedback?" asked this exact question in 2019 and got zero replies. That's telling on its own: people who bother to ask in public about tracking feature requests mostly don't have a clean answer either, which is why "buy a tool" isn't a real starting point.
The signals, not the size
Four things go wrong as a manual tracker degrades, and any one of them on its own is a fair warning:
- Duplicate rows. The same request gets logged twice under different wording because nobody searches before adding a new line, so counts undercount real demand.
- A priority column that reflects who filled it out last. Without a rule for ranking, "priority" quietly becomes "most recently discussed in Slack."
- Nobody closes the loop. Rows get marked "shipped" and nothing tells the six people who asked for it, because that step depends on someone remembering to filter the sheet and reply.
- Two editing habits collide. One person adds new rows at the bottom, another edits existing ones in place, and within a quarter the sheet has two competing definitions of "open."
None of these require a specific team size to show up. A five-person team can hit the duplicate-rows problem in month two if requests come in fast and nobody assigns an owner to the sheet. A twenty-person team can run a clean spreadsheet for years if exactly one disciplined person maintains it and volume stays low. Size is a proxy for what actually matters: how many people are touching the tracker, and how much of it depends on one person's memory.
Where a Foundry Metrics tracker actually broke
Foundry Metrics is a fourteen-person observability startup, and its feature-request history lives in a Google Sheet titled Feature Requests (DO NOT DELETE), inherited by product lead Kendra Voss from the company's second hire. Four columns: requester, request, source, and a priority field that was just a date.
For the first year, it worked because Kendra was the only one adding to it. Then Foundry hired two more support reps, and the sheet started drifting within a month.
Kendra: I opened it in October and there were three separate rows for "let us schedule the weekly digest email." One came from a support ticket, one from a sales call note, one from someone pasting a Slack thread. Nobody had checked if it was already in there.
Support rep Farrukh: I didn't know there was a rule about checking first. I just added what I heard.
The sheet wasn't badly built. It failed because three different people were now feeding it from three different channels, and the thing a spreadsheet can't do on its own is notice that two rows describe the same request. Kendra spent an afternoon a month manually merging duplicates by eyeballing the text, which is the same manual-dedupe tax every ad hoc tracker eventually charges once more than one person is entering data.
What the sheet still gets right
For a small team with low request volume, a shared sheet or a simple Notion database is genuinely enough, and replacing it early is wasted effort. Notion's relation property can link a request row to a person or company entry in a separate database, which gets you real structure, a requester history, and a rollup count, without leaving Notion. If your total feature-request volume is under a dozen a month and one person owns triage, that setup will hold for a long time. The mistake is assuming a schema upgrade fixes a capture problem, which is a different failure than the one a relation property solves.
“we need SSO before rollout”
“any update on single sign-on?”
“SSO came up twice on this call”
Linear issue, quotes attached
insight report in NotionThe actual next step
Before replacing anything, do this in order:
- Pick the one number that matters and try to produce it right now. For your top five open requests, how many distinct people or companies asked for each one? If getting that number means rereading a month of rows, that's the specific thing to fix, not the sheet's layout.
- Decide if the failure is structure or capture. If the sheet has good columns but people forget to check for duplicates, a relation-based Notion database with one canonical row per request and a strict "search before you add" habit will hold for a while longer. If the real problem is that requests are arriving in Slack, support tickets, sales calls, and GitHub issues, and someone has to personally notice each one and remember to log it, no schema change fixes that.
- If it's a capture problem, that's the actual signal to look at an extraction layer, not a bigger spreadsheet. This is the same conclusion the best feature request tracking tools guide lands on from the vendor-comparison side: tools split into a portal customers come fill out, or extraction from conversations that are already happening, and manual tracking is extraction done by hand.
Where manual tracking stops working, period
Even a well-run Notion database with relations has a ceiling, because every version of "manual" carries the same weak point. A human has to notice the request and log it correctly, every time, forever. That holds until the person who does it takes a vacation, changes roles, or the volume outpaces one person's attention. Foundry Metrics didn't have a bad sheet. It had a sheet that depended on Kendra being the only one who touched it, and that stopped being true the day the team grew.
One caveat here: Modem is ours, so read what follows as a vendor pitch rather than neutral advice, and judge it against the manual process described above. Modem's feature request tracking reads support conversations, chat, and code activity directly, merges duplicate mentions into one counted request instead of leaving that to whoever notices, and ranks by how many distinct accounts actually asked rather than who talked about it most recently. For a team still living partly in Notion, the Notion integration lets the agent search your existing workspace as a knowledge source and write updates back to it with approval, so the migration off the old tracker doesn't mean losing what's already documented there. The broader practice of pulling scattered feedback into one place before trying to rank any of it is covered in how to centralize customer feedback.
Run the two-week test before switching anything
If you're not ready to change tools, run the cheap version of the fix first. Pick one canonical Notion database (or one sheet, if that's what you have), add a relation to a people or company table, and post a one-line rule where the team will see it: "search before you add a new row." Give it two weeks, then check the same question this guide opened with. If you can now answer it in under a minute, the schema fix held. If the honest answer is still "we can't tell who asked for what," that's the signal to look at extraction instead of another column.
