---
title: "The workaround is often the requirement"
description: "The workarounds people build around a product can reveal requirements they would never think to ask for. The useful question is what those workarounds are doing for them."
date: "2026-09-17T00:00:00.000Z"
canonical: "https://www.antonsten.com/articles/the-workaround-is-often-the-requirement/"
---

I’ve been noticing the same thing across a few different products lately: some of the most useful product requirements are hiding in the workarounds.

Not necessarily in what people ask for, but in what they keep open in another tab, what they copy into a note, what they re-enter because the system forgets it, or what they cross-reference before making a decision. Once someone has done that enough times, the workaround starts to feel normal. It becomes part of the job rather than something they would think to describe as a problem.

That makes it easy to miss in research.

If you ask someone what frustrates them, they’ll usually tell you about the things that still feel unresolved. They may not mention the awkward process they’ve already learned to live with because they’ve already found a way around it.

This is similar to something I’ve [written about stakeholder interviews before](/articles/stakeholder/): the useful insight is often not in the direct answer, but in what gets repeated, avoided, overstated, or only surfaces after a follow-up question. Vitaly Friedman recently picked up on that in [a piece about stakeholder interviews](https://www.linkedin.com/pulse/useful-questions-stakeholder-interviews-vitaly-friedman-tbajf/), quoting my point that the meaningful insight is often in the follow-up rather than the first answer.

Workarounds are another version of that. They’re behavior around the edges of the stated problem, and often more revealing than the answer you get when you ask someone what they need.

I think the useful question is not “how do we remove this workaround?” but “what is the workaround doing for them?”

I saw a version of this years ago while doing research with pediatricians. A few of them mentioned they had a WhatsApp group where doctors shared workarounds for common EHR systems. That stuck with me because the interesting part wasn’t that the software was frustrating. It was that the clinicians had built their own parallel knowledge system around it: which shortcuts worked, where the traps were, and how to get around things the product itself didn’t handle well.

Someone might keep two views open because comparison matters more than navigation. They might copy information into a document because the act of reshaping it is part of how they make sense of it. They might maintain their own status field because the official one doesn’t reflect how they actually think about the work.

Those are different problems from “too many clicks” or “too much manual work.”

And if you jump straight to automation, you can easily remove the useful part along with the friction. What looks inefficient from the outside may be helping someone build confidence, preserve context, or think through a decision. A repeated behavior is not automatically something to eliminate.

This is becoming more important as it gets easier to automate almost anything. An agent can watch what someone does repeatedly and offer to take it over, but that only helps if you understand why the behavior exists in the first place.

I’ve started paying more attention to workarounds because they are often closer to evidence than feature requests are.

A feature request is already a proposed solution. A workaround is behavior. If someone repeatedly leaves your product to do something elsewhere, carries the same information manually from one step to another, or keeps inventing the same little process around your system, there’s usually a reason worth understanding.

That doesn’t mean every workaround deserves a feature. Some are edge cases. Some are personal preference. But when the same underlying behavior shows up repeatedly, especially across different people or contexts, it starts to look less like noise and more like a requirement the product hasn’t named yet.

The useful part is often underneath the visible behavior.

Why are they keeping those two things side by side? What context are they afraid of losing? Why do they rewrite that information rather than just copying it? What decision becomes easier because of the workaround?

Once you understand that, you can decide whether the right product move is automation, a new interaction, better information architecture, or simply leaving the behavior alone.

The workaround is rarely the requirement itself. But it’s often where the requirement becomes visible.