The Workaround Audit: Finding Where Your Product Stops Helping

Your users are building things next to your product. Spreadsheets. Docs. Slack threads. Manual checklists. Little systems they've assembled to patch the gaps your product leaves behind.

They're not doing this for fun. They're doing it because they need to make progress with the Job they hired you to do and your product stops helping partway through.

Every workaround is a flare fired from the exact spot where the product drops the user. And if you know how to read them, workarounds are the most honest product feedback you'll ever get — more honest than feature requests, churn surveys, or NPS scores. Because workarounds are behavior. They show you what people actually do when the product fails them, not what they say when you ask.

The Salesforce Spreadsheet

If you want to see workarounds at industrial scale, look at Salesforce.

Salesforce is a $35 billion revenue company. It's the dominant CRM. And a staggering number of its users maintain spreadsheets alongside it — tracking the same deals, the same contacts, the same pipeline data that Salesforce is supposed to be the system of record for.

Why? Not because Salesforce can't store the data. It can store anything. The workaround exists because the experience of getting the job done inside Salesforce doesn't match how the job actually unfolds.

A sales rep's job isn't "enter data into CRM." It's something closer to "know where every deal stands so I can prioritize my day and not get blindsided in the forecast meeting."

Salesforce can technically support that job. But doing it in Salesforce means navigating a complex interface, clicking through multiple screens, interpreting fields that were configured by an admin who optimized for reporting — not for the rep's daily workflow.

The spreadsheet is faster. The spreadsheet shows what the rep cares about in one view. The spreadsheet doesn't require three clicks to update a field. The spreadsheet doesn't ask for data the rep doesn't have yet.

The spreadsheet is the workaround. And the workaround is the map of everywhere Salesforce's experience fails the rep's actual job.

What Workarounds Actually Tell You

A workaround is behavioral evidence of a gap between what the product does and what the job requires. And the gap is rarely as simple as "missing features."

A rep who recomputes pipeline totals in a spreadsheet before the forecast meeting doesn't need a better calculator. They don't trust what the product is showing them. The data might be right. But the experience doesn't make that confidence visible — so they verify externally. That's a confidence problem.

A rep who DMs a colleague to confirm a deal's status before updating it isn't missing a collaboration feature. The product doesn't make it clear who owns what, what changed recently, or why a number shifted. The context that would let them act without asking isn't in the product. That's a visibility problem.

A rep who exports to Excel for bulk edits isn't asking for a spreadsheet view. They need to update twenty records in a way the product makes tedious — click into record, find field, edit, save, navigate back, repeat. Their old habit is faster. That's a friction problem.

A rep who keeps a separate doc with notes about key relationships and deal context isn't asking for a notes feature. Salesforce captures data — fields, stages, amounts — but not meaning. Why did this deal stall? What's the real objection? Who's the internal champion? The product tracks the what but not the why. That's an interpretation problem.

A rep who sends a stakeholder update via email instead of using the product's reporting tools isn't missing an email integration. The product's output doesn't match what the audience needs — the report is too granular, too product-shaped, too hard to turn into a narrative. So the rep rebuilds it in way that works for the reader. That's a format problem.

A team that runs a weekly pipeline review meeting alongside the product isn't asking for a meeting scheduler. They need alignment, accountability, and shared judgment calls that the product can't produce. The product tracks work. The meeting produces decisions. That's a judgment problem — the product handles data but not the sense-making that the job actually requires.

Each of these workarounds looks different, exists for a different reason, and points to a different fix. The point isn't to classify workarounds. It's to ask, for each one: what is the user trying to accomplish at this moment, what does the product fail to deliver, and what would have to change so the user didn't need to leave?

If you treat every workaround as a missing feature, you'll build the wrong thing.

Don't Copy the Workaround. Solve the Reason It Exists.

This is where teams consistently go wrong.

They see a spreadsheet workaround and think "let's add a spreadsheet view." They see a Slack workaround and think "let's add chat." They see a checklist workaround and think "let's add checklists."

Sometimes that's the right answer. Often it's a trap.

A spreadsheet workaround can mean four completely different things:

"I need bulk edits" — speed gap. "I need to reconcile data I don't trust" — trust gap. "I need a portable artifact to share with someone who doesn't have access" — coordination gap. "I need analysis the product can't express" — the product isn't completing the job at all.

Same workaround. Four different root causes. Four different next builds.

The workaround's form is not the need. The need is the job-completion gap underneath it. Copy the workaround and you'll build a feature that mimics the patch instead of closing the gap.

How to Find Workarounds

Users don't report workarounds. They've normalized them. They'll describe the spreadsheet as "just how we do it" without realizing it's evidence that the product is failing them.

So you don't ask "Do you have workarounds?" You go looking.

Watch the seams. In session recordings or observation sessions, don't just watch whether someone can complete a task. Watch for the moments they leave your product mid-flow.

A copy-paste burst — moving data out to somewhere else. A long pause before committing — the "I'm not sure this is safe" moment. A context switch to Slack or email right before finishing. You're not watching for confusion. You're watching for compensation.

Ask to see the artifacts. The fastest way to surface workarounds is to ask for the objects that live next to your product. "Can you show me the spreadsheet you use with this?" "What doc do you keep open while you're doing this?" "If you went on vacation tomorrow, what would someone need access to besides the product so the work doesn't fall apart?" People will show you the shadow system if you make it normal to ask.

Follow the side channels. If the job is social, it leaks into communication tools. Slack messages that function as approvals. Email threads that function as audit logs. Calendar events that function as reminders because the product's reminders aren't trusted. When users do job-critical work outside the product, they're showing you where the product stops being the thing they hired.

The JTBDUX Connection

In JTBDUX terms, workarounds are direct evidence of two things: solution completeness gaps and experience quality failures.

A solution completeness gap means the product doesn't get the user all the way to the outcome they hired it for. It drops them partway through and they have to finish the job with other tools. Every workaround is a visible marker of where that drop happens.

An experience quality gap means the product can technically do the job, but the path to getting it done is too slow, too confusing, too anxiety-producing, or too disconnected from how the job naturally unfolds. The user could do it inside the product. They choose not to — because the workaround is faster, safer, or more trustworthy.

JTBDUX evaluates experiences through a set of questions that connect each one back to the job. Does the product speak the language of the job — or does the user have to translate into a doc? Does it show progress toward the outcome — or does the user track progress in a spreadsheet because the product doesn't make it visible?

Does it reduce anxiety at the moment anxiety peaks — or does the user double-check manually because the product doesn't make confidence feel safe? Does it match the user's mental model of how the work flows — or does the user build a parallel system that does?

Every failure has a corresponding workaround. Find the workaround, and you've found where the experience is failing the job.

Workarounds Are Fantastic Feedback Signals

Feature requests are post-rationalized. Users ask for what they think they want, which is often a solution to a symptom rather than to the underlying gap.

Churn surveys are vague. "It didn't meet my needs" tells you nothing about where the product stopped helping.

Funnels show where people drop. Workarounds show where people persist.

That distinction matters. A user who churns might not have had a real job, or might have found a better hire. A user who builds a workaround is telling you: the job is real, I'm committed, your product is close — but I still need to do this part myself.

Workarounds are loyalty under strain. They're the clearest map you'll ever get of where the product stops being the thing someone hired and starts being one more thing they have to manage.