The best feature request is a workaround.

Feature requests are cheap. Someone types “you should add tags” into a form, and it costs them four seconds and no conviction. They might use tags; they might have seen tags somewhere else and assumed the word applies here. A request is a hypothesis a user is offering you for free, and free hypotheses are worth roughly what you pay for them.

A workaround is different. A workaround is a user spending real effort — exporting your data into a spreadsheet, keeping a second app open beside yours, inventing a naming convention like “zzz-archive” so your sort order does something you need, copying text out to reformat it and pasting it back. Nobody does that for fun. A workaround is a user who wanted an outcome badly enough that, when your product wouldn’t give it to them, they built the missing piece themselves, by hand, every time. That’s not a hypothesis. That’s demand with a receipt.

The reason this matters is that effort is the most honest signal a user emits. Interviews are full of guesses and politeness; analytics tell you what people did but not why; but a workaround sits exactly at the seam where your product’s model of the job diverges from the user’s real one. They didn’t leave for a competitor and they didn’t churn — they stayed, and they routed around the wall. Every one of those detours is a labeled map of a gap, drawn by the only people who actually feel it.

City planners have a name for this. When a paved walkway ignores where people actually want to go, they wear a dirt track across the grass — a desire line. The smart move isn’t to fence the grass; it’s to notice where the dirt is and pave that. Your product has desire lines too. They show up as the copy-paste that happens at the same boundary every session, the power user with a ritual nobody taught them, the flow people abandon and then return to from a different direction. Each is grass worn to dirt by feet that knew where they were going.

So the practical discipline is to hunt workarounds the way you’d hunt bugs. Watch real sessions and flag every moment a user leaves your product to accomplish something and comes back. Read support tickets not for the request but for the sentence that starts “so what I do is…”. When you interview, don’t ask what they want — ask them to show you how they get this done today, and pay attention to the ugly, manual, embarrassing steps. Those are the load-bearing ones.

There’s one trap. Paving a cowpath is not the same as understanding where it leads. If you build the literal workaround — “they use a spreadsheet, so I’ll add a spreadsheet” — you can end up automating a bad path instead of removing the need for it. The workaround tells you the job, reliably; it doesn’t always tell you the best solution. Sometimes the right build makes the entire detour unnecessary rather than faster. So treat a workaround as the highest-signal problem statement you’ll ever get, and then do the real work: figure out what job that detour was quietly getting done, and ask whether the honest answer is to pave it, shorten it, or make it pointless.

The requests in your inbox are what users think they want. The workarounds on their screens are what they’re willing to work for. When those two disagree, believe the effort.