Users invent the product
Ship anything and people will use it wrong. Not wrong as in broken — wrong as in for something you never wrote down.
The instinct is to correct them. Better onboarding, clearer empty states, a tooltip explaining what the feature is for. Sometimes that’s right. Often you are arguing with a customer about what your product does, and losing on the merits.
Misuse is a signal with a direction
A workaround is a request that has already been prototyped. Someone wanted an outcome badly enough to build it out of the wrong parts, on their own time, without asking. That’s stronger evidence than anything a survey returns, because it cost them something.
The spreadsheet exported and re-imported daily. The field used as a status because there is no status field. The API called at ten times the intended rate because it’s the only endpoint that returns what they need. Each is a spec, written in the only language available.
Design for affordances
You cannot enumerate use-cases faster than users invent them, so stop trying. What you can do is build parts that combine: stable primitives, real export, webhooks that fire on the events people care about, names that describe capability rather than intent. A product built as a set of affordances gets extended by its users. One built as a set of flows gets abandoned at the edge of the flow.
The hashtag is the canonical case. It wasn’t a feature — someone used a # because Twitter had no way to group a conversation, other people copied it, and years later it was built into the product and then into every product like it. No roadmap would have produced it. What made it worth institutionalising wasn’t that one person did it; it was that thousands independently arrived at the same workaround.
Where it breaks
Emergent use is not automatically valuable, and “listen to how people really use it” is how products lose their shape.
Most appropriation is one customer, once, for a reason that will not generalise. Institutionalise it and you have added a permanent maintenance burden to serve a single account — and you will do it again next quarter, and the quarter after, until the product is a pile of accommodations with no opinion. The teams that followed emergent behaviour most faithfully are not the ones with the clearest products.
There’s also a category that genuinely is misuse: people routing around a constraint that exists for a reason — a rate limit, a consent step, an audit boundary. In a voice product especially, a clever workaround is sometimes a customer quietly moving the compliance risk onto you.
The test I’d apply: does the workaround point at a job several customers have, or at one customer’s process? Enable the first. Support the second without building for it. And when the workaround exists to skip a safeguard, the answer is to fix the friction that made skipping attractive — not to pave the path.
Takeaway: design for affordances, not just use-cases.