# Where's Your Wall? — Website Audit *A diagnostic skill for reading your own website through a demand-side lens.* --- ## Attribution (read this first, keep this block if you share or copy this file) This framework, supply-side vs. demand-side, "the Wall," the Segway/Bird comparison, is Bob Moesta and The Re-Wired Group's own published work, not something invented for this tool. Source: "What do we mean by demand-side and supply-side?" — The Re-Wired Group https://therewiredgroup.com/learn/what-do-we-mean-by-demand-side-and-supply-side/ This skill applies their framework to a specific, narrow use case, reading a company's own website copy for supply-side vs. demand-side language, and pairs it with a companion self-report quiz built for the Open Folders newsletter (jdprater.com). If you use, adapt, or share this file, keep this attribution block intact. --- ## What this skill can and can't tell you **What it can do:** read the words on a website and say, plainly, whether they default to describing what the product does (supply-side) or the circumstance a buyer was in before they needed it (demand-side). **What it can't do:** diagnose your internal research process, prove your team lacks customer insight, or produce a scientifically precise score. Website copy reflects whoever wrote it, sometimes a founder in year one, sometimes an agency, sometimes a PMM working from research nobody else on the team has seen. A supply-side-heavy website does not prove the insight doesn't exist internally. It proves the insight, if it exists, hasn't reached the page yet. Do not output a percentage score (e.g., "73% supply-side"). It implies a precision this kind of qualitative read cannot support. Cite actual passages and reason about them instead. --- ## Instructions for the assistant running this skill You will be given a URL (or a few URLs, e.g., homepage, product page, pricing page). Do the following: 1. **Fetch and read the page(s).** Prioritize the homepage, then any product/solution pages, then pricing if available. Skip footer boilerplate, legal, and navigation text. 2. **Identify who the page is actually written for, before judging the language.** A page selling software to a business buyer (B2B SaaS) is a different genre than a page selling to the end consumer who will actually use or feel the result. Feature lists, stat blocks, and capability bullets are conventional, expected furniture on a B2B sales page, their presence alone is a weaker signal there than it would be on a consumer-facing page. State plainly in the output which kind of page was audited, since that shapes how much weight the finding should carry. 3. **If the page references or links to a separate end-customer experience** (a demo of what the actual end user sees, an embedded product flow, a "see an example" link), that page is usually the more meaningful one to test, since it's closer to the actual buyer with the actual struggling moment. Attempt to fetch it if the link is present in the page content. If it can't be reached directly, name it explicitly as a page that should be tested separately rather than silently skipping it. 4. **Pull direct quotes into three buckets, verbatim, not paraphrased:** - **Supply-side language:** sentences describing what the product does, its features, its capabilities. Listen for constructions like "our platform lets you...", "built for...", "the only tool that...". - **Demand-side language:** sentences naming an actual circumstance, struggle, or before/after moment the buyer was in. Listen for constructions like "when you're stuck trying to...", "most teams find themselves...", a named trigger or trade-off. - **Gestural language:** phrases that hint at a real struggle without naming it as a scene, close to demand-side but not quite there. This is often the most useful bucket, it's usually one edit away from being genuinely demand-side. Don't collapse it into either of the other two buckets. 5. **Do not force balance.** If a site is 90% supply-side language, say so and show it with the actual quotes. If you can't find any genuine demand-side language after a real search, say that plainly rather than stretching a feature description into a false positive. 6. **Check specifically for the Segway pattern**, language that's aspirational rather than circumstantial. "Imagine a world where..." or "revolutionary" framing without a named, specific buyer situation underneath it is a signal, not a neutral stylistic choice. Note it if present. 7. **Look for a gap between pages**, not just within one page. A common pattern: the homepage opens demand-side (a scene, a struggle) and then the product or pricing page drops entirely into supply-side spec language with no bridge back to the original struggle. This gap is itself a finding, name it explicitly if you see it. If only one page was available to test, say so rather than implying a multi-page check was done. --- ## Output format Structure the response as follows: ### Who this page is written for One sentence: B2B business-buyer page, consumer-facing page, or mixed. Name it before the findings, since it changes how much weight the supply-side finding should carry. ### Supply-side language found [3–5 direct quotes, with page/section noted] ### Demand-side language found [3–5 direct quotes, with page/section noted, or state clearly if none were found] ### Gestural language found [Phrases that hint at a real struggle without naming it as a scene, or state clearly if none were found. Flag these as the most actionable finding, closest to being fixed with a single rewrite.] ### Where the copy leans One paragraph, plain language, no score. State honestly which direction the balance falls and why, citing back to the quotes above, and note explicitly if the audience type identified above (B2B vs. consumer) should temper how surprising or meaningful that lean actually is. If it's mixed or inconsistent between pages, say that specifically rather than averaging it into a false middle. ### The gap, if there is one If demand-side language exists on one page but disappears on another (commonly: homepage vs. product/pricing pages), name exactly where the drop-off happens. ### One rewritten passage Pick the single weakest supply-side passage found. Rewrite it in demand-side language, using their own product, not a generic example, showing what it would sound like if it opened with the buyer's circumstance instead of the feature. ### Caveat, always include this A one-line reminder that this reflects the copy as written, not necessarily the team's internal research maturity, and that the companion self-report quiz (Open Folders, "Where's Your Wall?") is the way to check the internal-process side of the same question. --- ## Example prompt for the user to paste, along with their URL > Run the "Where's Your Wall?" skill against [URL]. Follow the instructions in this file exactly, including the attribution block and the caveat in the output.