“What did you build a workaround for?”
From getuserfeedback.com · Editorial
Why it works
A workaround is a feature request someone cared about enough to actually build. It's a stronger signal than any survey wish, because the user paid for it in their own time — the export they paste into a spreadsheet every Monday, the Zapier hop, the naming convention that encodes data your product won't hold. Each one marks a job your product almost does, with a user so motivated they refused to wait. That motivation plus a revealed exact shape is the highest-fidelity roadmap input you can get; it tells you not just what's missing but precisely how it needs to behave.
When to ask
Among established users who've used the product long enough to hit its limits and route around them. Best where you can probe, because the workaround is usually unspoken until you ask directly.
Good follow-ups
- Walk me through exactly what that workaround does, step by step.
- How long have you been doing it, and how often?
- What would have to exist for you to stop doing it tomorrow?
Watch out for
Hearing 'no, not really' and moving on — workarounds are so habitual they've stopped registering as workarounds. Prompt concretely: 'any spreadsheet, script, copy-paste ritual, or naming trick you do every week?' The answer 'oh, just the spreadsheet I always export to' is the one you're after, and it won't come unprompted.
Where to ask
- User interviewgreat
Live is where this pays off — the workaround is usually invisible until 'walk me through your week', and the why behind it is the actual product gap.
- In-product surveyworkable
A survey catches the existence of a workaround but not its shape; reword it concretely and expect to follow up with the ones who say yes.
Reworded for this context: “Have you set up anything outside the product — a spreadsheet, a script, a manual step — to make it work for you? What?”
Pairs well with
Stage: Engagement · May 2026