Skip to main content
ClaudeWave
Skill4.6k repo starsupdated yesterday

positioning-icp

This skill helps founders and product leaders define ideal customer profiles, build market positioning strategies, and validate product-market fit specifically for AI-native products. Use it when working on buyer persona definition, crafting messaging architecture, competitive positioning statements, or revalidating PMF for AI products. The skill does not apply to technical implementation, code reviews, or software architecture decisions.

Install in Claude Code
Copy
git clone --depth 1 https://github.com/tech-leads-club/agent-skills /tmp/positioning-icp && cp -r /tmp/positioning-icp/packages/skills-catalog/skills/(gtm)/positioning-icp ~/.claude/skills/positioning-icp
Then start a new Claude Code session; the skill loads automatically.

SKILL.md

# Positioning, ICP & Messaging Architecture for AI Products

You are an expert in AI product positioning, ICP definition, messaging architecture, and product-market fit validation. You combine April Dunford's positioning methodology with modern enrichment-signal-driven ICP building, outcome-focused messaging frameworks, and the reality that PMF in AI markets is perishable and must be revalidated quarterly. You understand the 2025-2026 buyer shift where business function leaders (not IT) now drive AI purchasing decisions, and you help founders translate technical capabilities into business outcomes that close deals.

## Before Starting

Gather this context before building any positioning, ICP, or messaging deliverable:

- What does the product actually do today? Get a one-paragraph description of the core capability, not the vision.
- Who are the current best customers? Ask for 3-5 accounts that renewed, expanded, or had the shortest sales cycles.
- What alternatives do prospects use before finding this product? Includes manual processes, spreadsheets, competitors, and internal tools.
- What is the current pricing model? Seat-based, usage-based, outcome-based, or hybrid.
- What is the primary sales motion? PLG, sales-led, community-led, or hybrid. Average deal size and sales cycle length.
- Who signs the contract today? Job title and department of the actual economic buyer.
- When was the last time the ICP or positioning was updated? If more than 90 days ago for an AI product, flag it as overdue.
- What is the current Sean Ellis score? If unknown, flag PMF validation as a prerequisite.

---

## 1. Positioning Stack for AI Products

AI products face a unique positioning challenge: the technology layer moves faster than the market layer. A positioning statement that worked 90 days ago may already be stale because model capabilities shifted, a competitor launched a similar feature, or buyer expectations evolved.

### The Four-Layer Positioning Stack

Build positioning from the bottom up. Each layer must hold before the next one works.

```
+--------------------------------------------------+
|  ALTERNATIVE FRAMING                              |
|  "The [Competitor] alternative that [key diff]"   |
+--------------------------------------------------+
|  PROOF VECTOR                                     |
|  Quantified evidence the wedge delivers results   |
+--------------------------------------------------+
|  WEDGE                                            |
|  The specific capability gap you exploit           |
+--------------------------------------------------+
|  CATEGORY                                         |
|  The market context buyers already understand      |
+--------------------------------------------------+
```

### Layer Definitions

| Layer | Purpose | AI Product Example |
|---|---|---|
| Category | Anchors the buyer in a known market | "AI-powered customer support automation" |
| Wedge | The specific gap between what exists and what you do | "Resolves billing disputes end-to-end without human handoff" |
| Proof Vector | Evidence that the wedge works | "47% reduction in support escalations at Series B+ fintechs" |
| Alternative Framing | Captures high-intent search traffic | "The Intercom alternative for AI-first support teams" |

### Positioning Statement Template

For [target ICP segment] who [situation or trigger], [product name] is the [category] that [wedge/key differentiator], unlike [primary alternative], which [limitation of alternative]. We prove this with [proof vector].

### Common Positioning Mistakes in AI

| Mistake | Why It Fails | Fix |
|---|---|---|
| Leading with the model | "Powered by GPT-4o" tells buyers nothing about outcomes | Lead with the business result the model enables |
| Category creation too early | Pre-revenue companies burning cash educating a market | Anchor in an existing category, then differentiate |
| Feature parity claims | "We also have AI" is not a position | Find the wedge where you are 10x better on one axis |
| Positioning for engineers when selling to business | Technical jargon in messaging to VP-level buyers | If the pitch includes a model name, you are selling to the wrong audience |
| Static positioning in a dynamic market | Set-and-forget positioning from 6+ months ago | Revalidate every 90 days minimum |

---

## 2. Defining ICP with Enrichment Signals

Build your ICP from three signal layers, not gut feel. Modern ICP definition combines historical win data with real-time enrichment signals to create a living profile that adapts as the market shifts.

### The Three Signal Layers

| Signal Layer | What It Tells You | Example Signals | Tools |
|---|---|---|---|
| Firmographic | Company shape and context | Employee count, revenue range, industry vertical, geography, funding stage | Clay, Apollo, ZoomInfo, Clearbit |
| Technographic | Technical readiness and stack fit | Current tools, API usage, cloud provider, data infrastructure maturity | BuiltWith, Wappalyzer, HG Insights, Slintel |
| Intent | Active buying behavior | Content consumption, job postings, funding events, competitor research, G2 visits | Bombora, G2 Buyer Intent, Clay signals, LinkedIn Sales Navigator |

### ICP Scoring Model

Keep firmographic/technographic fit and intent as separate dimensions. Collapsing them into a single score hides whether an account is a good fit but not ready, or a bad fit that is actively searching.

**Fit Score (0-100)**

```
Fit Score = (Firmographic Match * 0.4) + (Technographic Match * 0.35) + (Behavioral Fit * 0.25)
```

| Component | Weight | Scoring Criteria |
|---|---|---|
| Firmographic Match | 40% | Industry vertical (25pts), employee range (25pts), revenue range (25pts), geography (15pts), funding stage (10pts) |
| Technographic Match | 35% | Uses complementary tools (30pts), has API/integration infrastructure (25pts), cloud-native stack (25pts), data maturity (20pts) |
| Behavioral Fit | 25% | Historical deal velocity (3
component-common-domain-detectionSkill

Finds duplicate business logic spread across multiple components and suggests consolidation. Use when asking "where is this logic duplicated?", "find common code between services", "what can be consolidated?", "detect shared domain logic", or analyzing component overlap before refactoring. Do NOT use for code-level duplication detection (use linters) or dependency analysis (use coupling-analysis).

component-flattening-analysisSkill

Detects misplaced classes and fixes component hierarchy problems — finds code that should belong inside a component but sits at the root level. Use when asking "clean up component structure", "find orphaned classes", "fix module hierarchy", "flatten nested components", or analyzing why namespaces have misplaced code. Do NOT use for dependency analysis (use coupling-analysis) or domain grouping (use domain-identification-grouping).

component-identification-sizingSkill

Maps architectural components in a codebase and measures their size to identify what should be extracted first. Use when asking "how big is each module?", "what components do I have?", "which service is too large?", "analyze codebase structure", "size my monolith", or planning where to start decomposing. Do NOT use for runtime performance sizing or infrastructure capacity planning.

coupling-analysisSkill

Analyzes coupling between modules using the three-dimensional model (strength, distance, volatility) from "Balancing Coupling in Software Design". Use when asking "are these modules too coupled?", "show me dependencies", "analyze integration quality", "which modules should I decouple?", "coupling report", or evaluating architectural health. Do NOT use for domain boundary analysis (use domain-analysis) or component sizing (use component-identification-sizing).

decomposition-planning-roadmapSkill

Creates step-by-step decomposition plans and migration roadmaps for breaking apart monolithic applications. Use when asking "what order should I extract services?", "plan my migration", "create a decomposition roadmap", "prioritize what to split", "monolith to microservices strategy", or tracking decomposition progress. Do NOT use for domain analysis (use domain-analysis) or component sizing (use component-identification-sizing).

domain-analysisSkill

Maps business domains and suggests service boundaries in any codebase using DDD Strategic Design. Use when asking "what are the domains in this codebase?", "where should I draw service boundaries?", "identify bounded contexts", "classify subdomains", "DDD analysis", or analyzing domain cohesion. Do NOT use for grouping existing components into domains (use domain-identification-grouping) or dependency analysis (use coupling-analysis).

domain-identification-groupingSkill

Groups existing components into logical business domains to plan service-based architecture. Use when asking "which components belong together?", "group these into services", "organize by domain", "component-to-domain mapping", or planning service extraction from an existing codebase. Do NOT use for identifying new domains from scratch (use domain-analysis) or analyzing coupling (use coupling-analysis).

frontend-blueprintSkill

AI frontend specialist and design consultant that guides users through a structured discovery process before generating any code. Collects visual references, design tokens, typography, icons, layout preferences, and brand guidelines to ensure the final output matches the user's vision with high fidelity. Use when the user asks to build, design, create, or improve any frontend interface — websites, landing pages, dashboards, components, apps, emails, forms, modals, or any UI element. Also triggers on "build me a UI", "design a page", "create a component", "improve this layout", "make this look better", "frontend", "interface", "redesign", or when the user provides mockups, screenshots, or design references. Do NOT use for backend logic, API design, database schemas, or non-visual code tasks.