A founder or expertise-led business looks interchangeable

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. It is built from the user's own words, not your paraphrase — so the flow front-loads a real interview before any reframing. 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.

As you research, capture how the user and the market phrase things word for word — headlines, service-page sentences, the exact language they reach for. You're building two banks at once: the banned shared-language list, and a store of the user's own raw phrasing to reuse in steps 5 and 6. Do not sand their words into cleaner marketing copy — the rough, specific way they say it is the asset.

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. If you can't find the ICP from their website, LinkedIn, materials, or the vault, ask the user directly and wait for the answer before continuing — never invent it. Keep pushing until the buyer is a named type with a sweet spot, not a vague segment.

2. Download the brokenness (interview, in their own words)

Before you frame anything, interview the user to get the raw material in their language. This is the deepest data-collection step — don't rush it, and don't answer for them. Work through their industry's pain points one at a time. For each and every pain point, ask these three questions and capture the answers verbatim:

1. What is broken about your industry right now? Push for depth — the specific thing everyone in the market tolerates, with real examples, not a headline.
2. Why do you think it's broken? Get their view of the real cause underneath the symptom.
3. What do you think the solution is? Their fix, in their words.

Loop this for every pain point they raise — one triad per pain point. Keep their exact phrasing; these sentences feed the old-way/new-way reframe and the category language directly, so paraphrasing here quietly waters down everything downstream. If you're working async or the answers aren't already captured (vault, transcripts, prior notes), ask and wait — do not proceed to step 3 on assumptions.

3. Frame the problem: old way vs new way

Build this directly from the brokenness download in step 2. 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 (their "why it's broken" from step 2), what the new way replaces it with (their "solution" from step 2). 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?

4. Architect the new way

Before you talk about the result, map how the new way is actually built. Have the user walk you through their real process — the concrete, step-by-step mechanism they use to get the result — and lay it out in order. Process before result: document how it works first, then the outcome it produces, not the other way round. Source this from how they genuinely operate (the interview plus real cases), not an idealized or invented version. This architecture is the backbone of the IP in the next step — a new way with no visible mechanism is just a claim.

5. Package expertise as IP

Take the architected process from step 4 and organize it 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 (map them to the process from step 4), and attach one real proof point per step where evidence exists.

6. 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. Start from the user's own phrasing captured in steps 1–2: where they already say it sharply, keep their words rather than inventing new ones — the market should hear them. 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.

7. Assemble and pressure-test

Deliver the package: problem reframe (old way vs new way), the architected new way (process before result), 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 language traces back to the user's own words from steps 1–2; confirm the new way leads with its mechanism before its result; 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." It sounds like the founder — built from their own words in the interview, not generic marketing language pasted over their business. The problem reframe is the load-bearing part; weak outputs skip the interview and jump straight to a clever tagline, which is just the old positioning in new words. The new way shows its mechanism before its result — you can see how it's built, not just what it promises. 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 interview the user for the brokenness — what's broken, why, and their solution — for each pain point (step 2) before building the old way vs new way. NEVER skip the interview and jump to the reframe.
• MUST ask the user for the ICP if you can't find it, and wait for the answer. NEVER invent the ICP.
• MUST capture and reuse the user's own phrasing throughout. NEVER sand their words into generic marketing language.
• MUST map the actual process that produces the result before presenting the result (process before result).
• 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.