Before a product exists, people find ways to do the thing anyway.

They string together three tools. They write a script. They do it manually with a lot of copy-paste. They figure out the ten-step process that mostly works if you know the right incantations. And if they’re the type of person who writes, sometimes they publish it.

When a practitioner publishes their manual workaround, something important happens: they’ve done your customer development for you.

What the Published Workaround Contains

A published workaround tells you several things at once.

First, it confirms the demand is real. Someone needed this badly enough to figure out a manual process, and then cared enough about others who might have the same problem to write it up. The demand isn’t theoretical — it’s activated enough to produce behavior.

Second, it tells you what the output looks like. The practitioner had to describe what they were trying to produce. They made it concrete: “I got a pro forma, a red flag report, and a checklist.” That’s your feature list. Not the feature list you imagined — the feature list the customer actually needed, described in their own language, by someone who did the work.

Third, it shows you the friction. The workaround is usually complicated. There are prerequisites — tools you have to have installed, skills you have to have, steps you have to do in the right order. The practitioner can navigate this friction because they’re motivated and technical. The average member of their audience cannot. The product opportunity is to absorb that friction so users with lower technical tolerance can get the same output.

Fourth, it identifies the caveat. Published workarounds almost always include a warning: “don’t use this without review,” “this is a starting point not a finished output,” “you need domain expertise to evaluate this.” The caveat tells you what quality bar the product needs to clear before users trust it professionally. It’s the standard the product has to meet, stated explicitly by a domain expert.

The Workaround as a Product Spec

Most product discovery processes try to get to this kind of specificity through interviews and surveys and prototype testing. The published workaround delivers it in a single document.

You know what the user was trying to accomplish (the goal). You know what they produced (the output). You know what tools they used (the tech stack). You know what was hard (the friction to absorb). You know what they were worried about (the quality bar). You know who their audience is (your target market).

This is more specific than most product requirements documents. It’s also validated — not by a survey, but by someone who actually did the work and found it valuable enough to share.

The Distance Between the Workaround and the Product

The workaround exists because the product doesn’t. What separates them is usually not the core mechanism — the workaround proves the mechanism works — but the delivery. The workaround requires technical setup, manual orchestration, domain knowledge of which tools to use in which order. The product absorbs all of that. The user gets the output without navigating the process.

This is a specific and tractable engineering problem. You’re not inventing the mechanism — someone already proved it works. You’re packaging it. You’re handling the setup, the orchestration, the error cases, the edge inputs. You’re making it available to people who can’t or won’t run the manual process.

This is often easier to scope than building from scratch, because the workaround tells you what “working” looks like. You don’t have to define success — the practitioner already defined it.

The Signal Hierarchy

Not all published workarounds are equal. The signal is stronger when:

  • The author is a credible practitioner, not a hobbyist exploring. If someone with professional stakes is using the workaround, the demand is higher quality.
  • The publication venue reaches your target market. A workaround published on a niche professional newsletter reaches people who have the problem; a workaround published on a general tech blog might not.
  • The caveats are domain-specific. Generic caveats (“verify the output”) are weak. Domain-specific caveats (“don’t send this to LPs without checking the assumptions”) tell you the output is close enough to professional use to generate professional scrutiny.
  • The comments or responses show others trying it. If readers are saying “I tried this too” or “what did you use to generate the pro forma,” the demand extends beyond one practitioner.

When all four of these are present, you’re not looking at a curiosity. You’re looking at a market gap documented in real time by its customers.

What to Do With It

Read the workaround carefully. Understand exactly what was hard. Build the product that does the same thing, minus the friction. Price it at what the time savings are worth to a professional, not at what it costs to run.

You don’t need more customer development. The workaround is the customer development. You need to build.