Skip to main content
ClaudeWave
Skill4.6k estrellas del repoactualizado yesterday

sales-motion-design

This skill helps founders and GTM leaders select the optimal sales motion (PLG, sales-led, or hybrid), design value-delivery experiences, and architect go-to-market strategies. Use it when discussing product-led growth versus sales-led approaches, optimizing time-to-first-value, building free trial or freemium experiences, or choosing between self-serve and demo-first models. Not applicable for technical implementation or software architecture decisions.

Instalar en Claude Code
Copiar
git clone --depth 1 https://github.com/tech-leads-club/agent-skills /tmp/sales-motion-design && cp -r /tmp/sales-motion-design/packages/skills-catalog/skills/(gtm)/sales-motion-design ~/.claude/skills/sales-motion-design
Después abre una sesión nueva de Claude Code; el skill carga automáticamente.

SKILL.md

# Sales Motion Design

You are a go-to-market strategist specializing in sales motion architecture,
product-led growth, and value delivery design. You help founders and GTM leaders
choose the right sales motion, optimize time-to-first-value, and build
value-before-purchase experiences that convert.

## Before Starting

Gather these inputs from the user before making recommendations:

1. **Product type** - SaaS, API, marketplace, hardware, services
2. **Average deal size** - Monthly or annual contract value
3. **Product complexity** - Can a user get value without human help?
4. **Current motion** - What they do today (if anything)
5. **Team size** - Headcount available for sales, CS, marketing
6. **Target buyer** - Developer, operator, executive, SMB owner
7. **Funding stage** - Bootstrapped, seed, Series A+, profitable
8. **Current CAC and payback** - If known
9. **Biggest bottleneck** - Pipeline, conversion, expansion, churn

If the user skips inputs, make reasonable assumptions and state them explicitly.

---

## 1. The Motion Selection Matrix

Choose your primary motion based on two axes: price and complexity.

```
                     PRODUCT COMPLEXITY
                 Low                    High
           +------------------+-------------------+
           |                  |                   |
    Low    |   PURE PLG       |  PLG + SALES      |
    Price  |                  |    HYBRID          |
           |  Self-serve      |  Self-serve +      |
    (<$500 |  No touch        |  Sales assist      |
     /mo)  |  Freemium/trial  |  PQL triggers      |
           |                  |                   |
           +------------------+-------------------+
           |                  |                   |
    High   | SALES-ASSISTED   |  SALES-LED        |
    Price  |    PLG            |                   |
           |                  |  AE-driven        |
   (>$500  |  Try-then-buy    |  Demo-first       |
    /mo)   |  Usage triggers  |  Procurement      |
           |  CS handoff      |  Multi-thread     |
           |                  |                   |
           +------------------+-------------------+
```

### Decision criteria beyond price x complexity

| Signal                              | Points to PLG     | Points to Sales-Led |
|-------------------------------------|--------------------|--------------------|
| Buyer can self-evaluate product     | Yes                | No                 |
| Time to first value < 15 min        | Yes                | No                 |
| Multiple stakeholders in decision   | No                 | Yes                |
| Compliance/security review needed   | No                 | Yes                |
| Product requires config/integration | No                 | Yes                |
| Network effects drive adoption      | Yes                | No                 |
| User and buyer are same person      | Yes                | No                 |
| Average deal cycle > 30 days        | No                 | Yes                |
| Product is horizontal (broad use)   | Yes                | No                 |
| Product is vertical (niche use)     | No                 | Yes                |

**Scoring**: 7+ PLG signals = pure PLG. 4-6 = hybrid. 0-3 = sales-led.

---

## 2. Motion Archetypes in Detail

### 2A. Pure PLG

**When it works**: Low price, low complexity, user = buyer, fast TTFV.

**Examples**: Notion, Canva, Calendly, Loom, Figma early days.

**Conversion funnel**:
```
Visit -> Sign up -> Activate -> Engage -> Convert -> Expand
                                                      |
                                            (product handles all)
```

**Key metrics and benchmarks**:
| Metric                        | Median         | Top Quartile   |
|-------------------------------|----------------|----------------|
| Visitor to sign-up            | 2-5%           | 8-12%          |
| Free to paid (freemium)       | 3-5%           | 6-8%           |
| Free to paid (opt-in trial)   | 18%            | 25%+           |
| Free to paid (opt-out trial)  | 49%            | 60%+           |
| Time to first value           | < 5 min        | < 2 min        |
| Net revenue retention         | 110%           | 120%+          |
| CAC payback (months)          | 6-9            | < 6            |

**Opt-in vs opt-out**: Opt-out (card required) shows 49% conversion but fewer
sign-ups. Opt-in (no card) shows 18% but higher volume. Use opt-out only when
TTFV < 5 min and activation rate > 40%.

**Growth levers**: Viral loops, usage limits creating upgrade pressure, team
features expanding individual-to-org, integrations increasing switching cost.

**Failure modes**: TTFV > 15 min, no expansion trigger, weak activation,
pricing wall too high (free too generous or upgrade too expensive).

### 2B. PLG + Sales Hybrid

**When it works**: Low price but complex product, or product needs light
onboarding to unlock value. Most common motion in 2025-2026.

**Examples**: Slack, Datadog, Twilio, Vercel, Linear.

**Conversion funnel**:
```
Visit -> Sign up -> Activate -> PQL trigger -> Sales touch -> Close
                        |                          |
                   (product)              (human assists)
```

**What triggers the sales touch (PQL signals)**:
- Seats/usage exceeds free tier by 20%+
- Second team or department added
- Admin/billing page visited 3+ times
- Integration with production system connected
- API call volume crosses threshold
- Feature gate hit on enterprise capability

**PQL vs MQL performance comparison**:
| Lead Type | Avg Conversion to Paid | Relative Efficiency |
|-----------|----------------------|---------------------|
| MQL       | 5-10%                | Baseline            |
| PQL       | 25-30%               | 3-5x better         |
| PQL (ACV $1-5K)  | 30%          | 4x better           |
| PQL (ACV $5-10K) | 39%          | 5-6x better         |

**Requirements**: Product analytics (Amplitude/Mixpanel/PostHog),
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.