When customers build their own fix instead of waiting for yours, they have already run a product discovery experiment — and published the results where most teams never look. That is the core argument of a Harvard Business Review piece on what customer workarounds reveal about a business model, and it lands hardest for product managers who treat workarounds as noise to be trained away rather than signal to be decoded.

The framing matters. A workaround is not a user failing to understand your product. It is a user concluding that your product, as designed and monetized, cannot solve their problem at an acceptable cost — so they pay that cost themselves. They export your data into spreadsheets. They stitch two of your products together with scripts. They call the support line to trigger an action your UI refuses to expose. Every one of those behaviors is a customer spending their own time and money to compensate for a gap in your model, not merely your interface.

That distinction between interface and model is where the HBR argument earns its keep for practicing PMs. Most teams have a ritual for surfacing usability friction: session replays, support ticket taxonomies, funnel drop-off analysis. Almost none have a ritual for surfacing model friction — cases where the workaround exists because the way you charge, segment, bundle, or deliver value conflicts with the way the customer creates value for themselves. A user who screenshots your dashboard and pastes it into a weekly email thread is not confused by your export button. They are telling you that the unit at which they consume your product is the weekly summary, and you are selling the dashboard.

So how should a team act on this? Treat workarounds as a discovery channel with the same discipline you apply to win-loss interviews.

First, hunt for them where they accumulate. Workarounds leave residue: shared spreadsheets in your customer's drive, internal tools built against your API, manual processes documented in onboarding wikis, repeat support requests that always resolve the same way. Ask open-ended questions in customer conversations — "walk me through what you do right after you close our app" — rather than satisfaction-scored ones. Workarounds almost never appear when you ask users to evaluate your features. They appear when you ask users to narrate their process.

Second, classify what the workaround is compensating for. Three buckets cover most cases. A capability gap: the product genuinely cannot do the job, and the workaround is a feature request in disguise. A workflow gap: the product can do the job, but only through a path that costs the user more effort than the workaround does. A model gap: the product and its commercial structure deliver value in units that do not match how the customer wants to receive it. Only the first bucket belongs in your backlog by default. The second belongs in UX research. The third belongs in front of your leadership team, because fixing it changes packaging, pricing, or segmentation — decisions above a product team's pay grade.

Third, weigh the uncomfortable tradeoff. Some workarounds prop up your current economics. Customers who manually deduplicate records across two of your SKUs are, in effect, absorbing integration costs you would otherwise have to price in. Kill the workaround and you may have to absorb the cost yourself, or lose the customer. HBR's framing pushes you to see the workaround as diagnostic, but diagnosis does not obligate surgery. It obligates a decision — and an explicit one, documented, with an owner, rather than the default outcome where the workaround survives because nobody chose to examine it.

There are failure modes here worth naming. Survivorship bias is the big one: the workarounds you can observe belong to customers who stayed. The ones who hit the same model gap and churned left no spreadsheet behind, only a cancellation record your renewal team may have mislabeled as price sensitivity. Overcorrection is the second: a vocal enterprise account's elaborate workaround reflects one deployment's constraints, not a market pattern. One workaround is an anecdote. The same workaround recurring across segments, price tiers, and acquisition channels is a finding.

The conditions under which this lens works are specific. It requires enough customer proximity for process-level conversations, which means it is cheap for product-led companies with usage telemetry and expensive for enterprise teams that meet customers twice a year. It assumes your workarounds are observable, which fails when customers solve their problems in tools you cannot see.

The direction of travel in product practice favors this discipline anyway. As AI-assisted tooling makes it trivial for customers to generate their own fixes — scripts, agents, glue code — the volume of workarounds will rise, and the customers most willing to compensate for your model's gaps will be the ones quietly building their own alternatives to your roadmap. The PMs who read those improvisations as business model diagnostics, rather than support tickets, will be the ones whose roadmaps still match reality a year from now.