When you build software, users will happily tell you what they want. "Make it faster." "Add a dashboard." "Make it more like [competitor]." Most of it is noise. People are great at describing pain and terrible at prescribing solutions — and the solution they ask for is rarely the one that fixes the pain.
The real signal isn't in what users request. It's in what they've already cobbled together to survive without you.
Two products, one habit
I've built two SaaS products, and both came from staring at a workaround instead of a feature request.
FillTheTimesheet. Freelancers and agencies don't say "I need time-tracking software." They say tracking is annoying and they'll deal with it later. So I watched what "later" actually looked like: the last day of the month, a blank spreadsheet, and someone reconstructing three weeks of work from calendar invites, Slack scrollback, and memory. That monthly guessing ritual was the spec. It said: capture has to happen in the moment, with near-zero friction, or it won't happen at all. Nobody requested that. The workaround screamed it.
PromptShip. Teams using ChatGPT, Claude, or Gemini don't ask for a "prompt library." But watch them work and the same artifact shows up everywhere: a chaotic Google Doc, a pinned chat message, a personal notes file full of prompts that worked once. Someone writes a genuinely good prompt, shares it, and a month later everyone has lost it and rebuilt it from scratch. That messy doc is a feature request written in frustration. It said: these prompts are reusable assets the team keeps re-earning, so they need one shared home and one-click reuse — not better documentation discipline.
Why workarounds beat feedback
A workaround is a revealed preference. It already passed the only test that matters: someone was annoyed enough to do extra work to get around the gap. That's a person voting with effort, not opinion.
Feature requests are the opposite. They're cheap to say and easy to abandon. "I'd use that" predicts nothing. "I built a fragile spreadsheet to do that every Friday" predicts a real need.
So when I sit with a user now, I've stopped asking "what do you want?" I ask:
- What do you do right before and after using the tool? (the manual glue)
- Where's the spreadsheet, doc, or notes file you've built on the side?
- What do you redo every week that you wish you didn't?
The answers map almost directly onto a roadmap.
The trap
The catch is that workarounds are a little embarrassing, so people hide them. Nobody volunteers "I reconstruct my hours from memory" or "our prompts live in a doc called final_FINAL_v3." You have to make it safe to admit the hacky thing. Once you do, they'll hand you the spec for free.
Takeaways
- Treat feature requests as symptoms, not specs.
- Hunt for the workaround: the spreadsheet, the doc, the pinned message, the manual ritual.
- A workaround is effort someone already spent — the strongest signal you'll get.
- Build the thing that makes the workaround unnecessary, then get out of the way.
The two products I'm proudest of weren't ideas. They were someone's ugly workaround, made a little less ugly.
FillTheTimesheet and PromptShip both started as someone's workaround. If you're running an ugly one right now, I'd genuinely love to hear it.
Top comments (0)