Category-of-one positioning

Use this when the user's business is compared against a shelf of near-identical options and the conversation keeps collapsing to price. Look interchangeable and you get price shopped — it becomes a war on rates. The output is a positioning package with three parts: a new way to frame the problem, category-defining language the market ties to the user, and their expertise packaged as IP. Position comes first — run it before building content engines or outbound on top of it.

1. Diagnose the interchangeability

Research how the user and their closest competitors describe themselves — websites, LinkedIn headlines, service pages. List the words everyone shares ("we help X do Y with Z"). Anything on that list is banned from the final positioning: if the user looks like the other 1,000 options on the shelf, buyers stroll past the shop window. Then narrow the ICP until the buyer is concrete — named buyer types with a specific sweet spot (industry, stage, revenue band), not "B2B founders." Positioning built for everyone lands with no one.

2. Frame the problem: old way vs new way

Define the contrast between the outdated approach the market accepts and the innovative approach the user represents. Draft it as a sharp two-column contrast: what the old way is, why it quietly fails, what the new way replaces it with. The reframe should change what the buyer thinks their problem is — not claim the user does the old thing better. Example of the move: reframing lead generation from "a service you rent" to "infrastructure you own." Test each candidate reframe: would the ICP recognize their situation in the old way, and does the new way make every interchangeable competitor look like the old way?

3. Build category-defining language

Turn the reframe into named language the market ties to the user — a name for the problem, the mechanism, and the outcome that doesn't previously exist in their market's feed. Draft 5–10 candidate phrases; keep the ones that are short, concrete, and repeatable in a LinkedIn post, a DM, and a sales call without explanation. The goal is that when the buyer hits this problem, the user's name is attached to the words they think in.

4. Package expertise as IP

Organize the user's expertise into a named, proprietary system — steps, framework, or method — that reads as the only way to solve the reframed problem. Pull from what's actually proprietary: lived experience, client results, patterns from real engagements. The stack is generic; the data feeding it is proprietary — IP built from the user's real inputs is what competitors can't replicate. Name the system, define its steps, and attach one real proof point per step where evidence exists.

5. Assemble and pressure-test

Deliver the package: problem reframe (old way vs new way), category language glossary, named IP with steps, and a rewritten one-liner + LinkedIn headline built from them. Pressure-test before shipping: read it against the competitor language list from step 1 — zero shared phrases; check every claim traces to something true about the user's track record; confirm the ICP from step 1 would feel seen, not addressed generically.

What good looks like

A great output makes the user the only option, not a better option — a buyer reading it thinks "this is a different thing," not "this one seems good too." The problem reframe is the load-bearing part; weak outputs skip it and jump straight to a clever tagline, which is just the old positioning in new words. Category language is tight enough to repeat unprompted; if a phrase needs a paragraph of explanation, cut it. The IP feels inevitable — its steps map to how the user actually gets results, not an invented acronym. Average outputs describe the user's services differently; great outputs change what the buyer believes their problem is, so competing on rates stops being possible.

Rules

• MUST ground every claim, proof point, and case reference in real results the user confirms. NEVER fabricate metrics, client names, or credentials.
• MUST get the user's approval on the reframe before building language and IP on top of it — everything downstream inherits it.
• NEVER reuse phrases from the competitor language list in the final package.
• NEVER position against a named competitor directly; position against the old way.