Web3 B2B Positioning Skill

For: Web3 founders, protocol marketing leads, blockchain solution sellers, security product marketers
Philosophy: Enterprises don't buy technology — they buy reduced risk, increased efficiency, and competitive advantage. Speak their language, not yours.

How to Use This Skill

MODULE 1 — Positioning Framework

Trigger: User needs to define how to position a Web3 product for enterprise buyers.

Step 1: Product & Market Intake

Ask if not provided:

• Product/service name and what it does (technical description OK here)
• Category (security audit / infrastructure / DeFi tooling / compliance / payments / identity / other)
• Target buyer (CTO / CISO / CFO / CMO / Legal / Procurement / Board)
• Industry vertical (fintech / banking / supply chain / gaming / government / media)
• Competitors (other solutions buyers are considering, including non-crypto options)
• One customer success story if available

Step 2: Value Translation Matrix

For every technical feature, translate into business language:

FEATURE → BENEFIT → BUSINESS VALUE → PROOF

[Technical Feature]     → [What it does for the user]     → [Business outcome]         → [Metric or example]
─────────────────────────────────────────────────────────────────────────────────────────────────────────────
Smart contract audit    → Finds vulnerabilities before     → Prevents financial loss     → "Average DeFi exploit
                          deployment                         and reputational damage        costs $8.7M"

On-chain transparency   → All transactions publicly        → Reduces audit costs and     → "35% reduction in
                          verifiable                         accelerates compliance         compliance overhead"

Decentralized ID        → Users control their own          → Reduces KYC fraud and       → "65% reduction in
                          credentials                        liability exposure             identity fraud claims"

Step 3: Positioning Statement (3 versions)

Version A — Problem-led (for risk-averse buyers):

"[Company] helps [BUYER ROLE] at [INDUSTRY] companies [ELIMINATE SPECIFIC RISK] so they can [BUSINESS OUTCOME] without [COMMON FEAR]."

Version B — Opportunity-led (for growth-oriented buyers):

"[Company] enables [BUYER ROLE] to [CAPTURE SPECIFIC OPPORTUNITY] in [MARKET] by [HOW], giving them [COMPETITIVE ADVANTAGE] that [ALTERNATIVES] can't match."

Version C — Category-led (for buyers who understand Web3):

"[Company] is the [CATEGORY LEADER] for [PROTOCOL/ECOSYSTEM/SECTOR] — trusted by [CREDIBILITY MARKER] to [CORE CAPABILITY]."

Security product example (B2B):

• A: "We help CTOs and security teams at DeFi protocols eliminate smart contract vulnerabilities before deployment — so they can launch with confidence without betting their treasury on an incomplete audit."
• B: "We enable protocol teams to move faster without increasing risk — our continuous security monitoring means your team ships new features without waiting for quarterly audits."

Step 4: Messaging Hierarchy

MESSAGING HIERARCHY — [Product Name]
──────────────────────────────────────
HEADLINE MESSAGE (1 sentence — memorable, jargon-free):
[The single most important thing an enterprise buyer should understand]

SUPPORTING MESSAGES (3, one per key buyer concern):
1. [Risk/Security message — for CISO, Legal, Compliance]
2. [Efficiency/ROI message — for CFO, Operations]
3. [Innovation/Competitive message — for CEO, CTO, Product]

PROOF POINTS (evidence for each message):
1. [Statistic, case study, or third-party validation]
2. [Metric or outcome achieved with existing client]
3. [Industry recognition, audit, certification]

DIFFERENTIATORS vs. ALTERNATIVES:
[Us] does [X] that [Alt 1] and [Alt 2] cannot, because [specific reason]

MODULE 2 — Sales Collateral

Trigger: User needs to create pitch materials for enterprise buyers.

One-Pager Structure

[COMPANY LOGO]

HEADLINE: [Single sentence — problem solved or value delivered]

THE PROBLEM
[2–3 sentences: the real pain enterprises face WITHOUT getting technical about Web3]

HOW [COMPANY] SOLVES IT
[3 bullet points: specific capabilities, in business language]
• [Capability 1] → [Business outcome]
• [Capability 2] → [Business outcome]
• [Capability 3] → [Business outcome]

RESULTS
[3 metrics or outcomes, ideally from real clients]
• "[Client type] reduced [X] by [Y%]"
• "[Client] prevented [$X] in potential losses"
• "[Client] achieved [compliance/certification] in [X weeks]"

WHO WE WORK WITH
[3–5 client logos or client descriptions if logos can't be shown]

HOW TO GET STARTED
[Simple 3-step process: Step 1 → Step 2 → Step 3]

CONTACT
[Name] | [Email] | [Website] | [LinkedIn]

Executive Summary / Pitch Deck Flow

SLIDE 1: The problem (in enterprise terms — no blockchain jargon)
SLIDE 2: Why existing solutions fail
SLIDE 3: Our solution (1 sentence + diagram)
SLIDE 4: How it works (simplified — 3 steps)
SLIDE 5: What you get (outcomes, not features)
SLIDE 6: Proof (clients, case studies, metrics)
SLIDE 7: Security & compliance (the "is this legit?" slide)
SLIDE 8: Pricing / engagement model
SLIDE 9: Team (credibility markers — past companies, credentials)
SLIDE 10: Next step (specific CTA — pilot, call, assessment)

Deck quality rules for enterprise Web3:

• Never use "revolutionary" or "paradigm shift" — enterprise buyers hear this from every startup
• Lead with the business problem, not the technology
• Include a compliance/security slide even if not asked — every enterprise buyer is thinking it
• Logos > words. If you have clients, show them. If you have certifications, show them.

MODULE 3 — Translation Layer

Trigger: User needs to explain Web3 concepts to a non-crypto audience without losing meaning.

Web3 → Business Language Dictionary

The "Explain it to a CFO" Test

Before sending any enterprise material, ask:

1. Does it mention any Web3 jargon not in the dictionary above without defining it?
2. Is the primary message about the technology or the business outcome?
3. Does it answer "so what?" from a financial or risk perspective?
4. Does it explain how this is different from what they already have?
5. Does it tell them exactly what the next step is?

If any answer is "no" — revise before sending.

MODULE 4 — Objection Handling

Trigger: Enterprise buyer has raised concerns or the sales process has stalled.

Common Enterprise Objections to Web3 Products

"This is too risky / unproven technology"

Response: "That's a fair concern, and it's why we built [SPECIFIC TRUST MARKER — independent audit, certifications, existing enterprise clients]. Our clients at [CLIENT TYPE] had the same concern before working with us — we can walk you through how they evaluated and mitigated that risk. Would a technical assessment help you get comfortable with the security model?"

"We have regulatory compliance concerns"

Response: "Compliance is the first thing we address with every enterprise client. [PRODUCT] was designed to work within [specific regulatory frameworks — GDPR, SOC2, MiCA, etc.]. We can connect you with our legal team to walk through the compliance documentation — this typically resolves concerns in one call."

"Our IT/security team won't approve this"

Response: "That's exactly who we want in the conversation. We have a technical package specifically for security teams that covers [architecture, audit reports, penetration testing results]. Most IT approvals happen within [X weeks] once they see the documentation. Should I send it directly to your security lead?"

"We don't have the internal expertise to manage this"

Response: "You don't need to. [PRODUCT] is designed to integrate with [existing systems] with [X hours] of implementation time. We handle [WHAT] and you own [WHAT]. Ongoing management takes [X hours/month] from your team."

"We're already working with [competitor] / We built something internal"

Response: "That's common. The question isn't whether you have [general capability] but whether it covers [specific gap your product addresses]. Our clients often use us alongside [competitor] for exactly [this specific case]. Can I show you what that looks like in practice?"

"The price is too high"

Response: "I understand — let me reframe the cost. The average [relevant incident — exploit, breach, audit failure] for a company at your scale costs [$X]. Our annual engagement is [$Y]. That's [math]. But more importantly — what would it cost your team's time and your customers' trust if [specific bad outcome] happened on your watch?"

MODULE 5 — ICP & Buyer Personas

Trigger: User needs to define who their ideal enterprise customer is.

ICP Framework for Web3 B2B

IDEAL CUSTOMER PROFILE — [Company Name]
────────────────────────────────────────
COMPANY CHARACTERISTICS
├── Industry vertical: [fintech / banking / gaming / DeFi / enterprise tech / other]
├── Company size: [employees / revenue / AUM / TVL]
├── Technology maturity: [already in Web3 / exploring / traditional]
├── Geography: [North America / LATAM / Europe / Asia / global]
└── Regulatory environment: [heavily regulated / moderate / light]

TRIGGER EVENTS (companies actively looking for what you sell)
├── [Event 1: e.g., "recently launched a tokenization initiative"]
├── [Event 2: e.g., "had a security incident or near-miss"]
├── [Event 3: e.g., "competitor announced blockchain adoption"]
└── [Event 4: e.g., "hired a Chief Blockchain Officer or Web3 lead"]

DISQUALIFIERS (do not sell to)
├── [e.g., "company with no digital assets or blockchain initiative"]
├── [e.g., "company in a country with crypto ban"]
└── [e.g., "companies with <$X budget"]

Buyer Persona Map

Rule: Never pitch to one persona only. The CISO kills deals the CEO loves if they're not addressed. Map your message to all 5.

MODULE 6 — Trust & Credibility

Trigger: User needs to build credibility with enterprise buyers who are skeptical of crypto.

Trust-Building Asset Stack

Tier 1 — Must Have:

• Security audit report (third-party) — publish it or offer under NDA
• SOC2 / ISO 27001 certification (or roadmap to get it)
• Client references (even 1–2 named clients changes enterprise perception dramatically)
• LinkedIn-polished team profiles (enterprise buyers Google your team)

Tier 2 — Strongly Recommended:

• Case studies with quantified outcomes (not just "worked with X")
• Explainer video (non-technical — under 3 minutes)
• Press coverage in trade publications (not just crypto-native media)
• Integration partnerships with known enterprise vendors

Tier 3 — Differentiating:

• Academic or government partnerships
• Published research or security reports
• Speaking at enterprise (not just crypto) conferences
• Regulatory body relationships or consultations

Case Study Template

CASE STUDY — [Client Name or "Major [Industry] Company"]
──────────────────────────────────────────────────────────
CHALLENGE:
[2–3 sentences: what specific problem they had before working with you]

SOLUTION:
[2–3 sentences: what you built or provided, in business language]

RESULTS:
• [Metric 1: quantified outcome]
• [Metric 2: quantified outcome]
• [Metric 3: time/cost/risk-based outcome]

QUOTE (if available):
"[Client quote about the experience or results]"
— [Name, Title, Company]

WHAT THIS MEANS:
[1 sentence connecting their success to your product's promise]

General Quality Rules

1. Lead with the problem, not the product. Enterprise buyers have a hundred solutions in front of them — the one that starts with their pain wins the meeting.
2. Never assume crypto literacy. Even "blockchain" needs a one-line definition in the first meeting.
3. Security and compliance are features, not footnotes. For enterprise Web3, trust is the product.
4. One champion inside the company is worth a hundred cold emails. Find and enable your internal advocate.
5. Price in risk. The conversation shifts when buyers compare your cost to the cost of not buying.
6. Reduce friction at every step. The harder it is to evaluate, the longer the sales cycle. Free assessments, pilots, and POCs convert skeptics.

Web3 B2B Positioning Skill v1.0
Built for Web3 founders and marketing leads bridging crypto-native products with traditional enterprise buyers.