Skip to main content
ClaudeWave
Skill1.3k estrellas del repoactualizado 2d ago

cold-start-problem

This Claude Code skill applies Andrew Chen's Cold Start Problem framework to launch and scale networked products like marketplaces, social apps, and collaboration tools that depend entirely on connections between users. Use it when designing go-to-market strategy for two-sided platforms, diagnosing why network growth has stalled, sequencing which user segments to acquire first, or deciding between broad market launches versus targeted atomic network seeding, particularly when facing the chicken-and-egg problem of initial liquidity.

Instalar en Claude Code
Copiar
git clone --depth 1 https://github.com/wondelai/skills /tmp/cold-start-problem && cp -r /tmp/cold-start-problem/cold-start-problem ~/.claude/skills/cold-start-problem
Después abre una sesión nueva de Claude Code; el skill carga automáticamente.

SKILL.md

# The Cold Start Problem

A framework for starting and scaling products that live or die by network effects — marketplaces, social apps, messaging, and collaboration tools — distilled from Andrew Chen's *The Cold Start Problem*. Use it to launch products that are worthless until other users show up, to sequence growth network by network, and to navigate the five stages: the cold start, the tipping point, escape velocity, hitting the ceiling, and the moat.

## Core Principle

**Network effects start as a liability, not an asset.** Value lives in connections between users, and on day one there are none — the same force that makes a dense network unstoppable makes an empty one useless. You don't escape by launching to a market; you escape by building one tiny, complete, self-sustaining network at a time, solving its hard side first, then tipping adjacent networks with a repeatable playbook until the market follows.

## Scoring

**Goal: 10/10.** Rate launch plans and growth strategies for networked products 0-10 against the principles below. Report the current score and the specific changes needed to reach 10/10.

- **9-10:** Named atomic network with an instrumented magic moment, hard side solved first, repeatable tipping playbook, density/liquidity metrics, explicit ceiling and moat plan
- **7-8:** Clear atomic network and hard-side focus, but tipping tactics are ad hoc or metrics still track totals over density
- **5-6:** Network effects acknowledged, but the launch targets a broad market and both sides are treated equally
- **3-4:** Generic user-acquisition plan; network thinking limited to "add invites and hope it spreads"
- **0-2:** Big-bang launch to everyone at once, vanity signups, no hard-side strategy, no liquidity measures

## Framework

### 1. Network Effects Fundamentals

**Core concept:** A networked product connects people with each other — buyers with sellers, creators with audiences, coworkers with coworkers — and becomes more valuable as the right people join. Network effects come in three distinct forms: the acquisition effect (the network pulls in its own new users), the engagement effect (more users make each session more valuable), and the economic effect (density improves monetization and unit economics). A product can be strong in one and weak in the others.

**Why it works:** Treating "network effects" as a single magic property hides where growth actually comes from and where it breaks. Metcalfe's law (value grows with n²) is an oversimplification — it counts nodes, not active, relevant connections, and a million scattered users can be worth less than five thousand in one dense community. Every large network is really a network of networks: Uber is hundreds of city-level markets, Slack is millions of team-sized networks. Density and quality of each sub-network beat raw user counts.

**Key insights:**
- The three effects decouple: viral acquisition can mask dead engagement — downloads up, rooms empty
- Metcalfe counts nodes; value lives in active connections — measure density, not totals
- Anti-network effects are real: the dynamics that compound growth in a dense network compound emptiness in a sparse one
- The network, not the feature set, is the moat — competitors can copy the product but not the people on it
- Aggregate metrics lie; cut every metric by sub-network (city, team, category) to see true health

**Applications:**

| Context | Application | Example |
|---------|-------------|---------|
| Metric design | Replace totals with density measures | Track weekly active networks, not registered users |
| Growth diagnosis | Attribute growth to the three effects separately | Viral factor vs. session frequency vs. conversion, each per network |
| Strategy review | Map the product as a network of networks | A marketplace is one network per city-category pair |

See: [references/case-studies.md](references/case-studies.md)

### 2. The Cold Start: Atomic Networks

**Core concept:** An atomic network is the smallest network that is stable and self-sustaining — just enough of the right people that the product delivers its core value and the group keeps returning on its own. Slack needs roughly three users inside one team, Zoom needs two, a marketplace may need a single zip code or category. Pick a network, not a market, and build the killer product for that tiny group — even when it looks unscalably niche.

**Why it works:** Networks succeed or fail one network at a time. A product that works completely for fifty people in one community proves the loop and can be replicated; one that half-works for fifty thousand scattered users proves nothing and dies of emptiness. Tiny complete networks also expose the magic moment — the experience that shows the network working (the car arrives, the teammate replies) — which becomes the activation bar for every network that follows.

**Key insights:**
- Smaller is better: find the minimum size at which the product works, then over-deliver for exactly that group
- Constrain the first network hard — one company, one campus, one neighborhood, one collector niche — so density is achievable with founder-level effort
- Define the magic moment precisely and instrument it; gate all expansion on networks reaching it
- Killer products for tiny networks look like toys (Facebook at Harvard, eBay's collectibles) — niche optics are the cost of density
- Flintstone the empty side: founders manually supply content, inventory, or matchmaking until the network stands alone

**Applications:**

| Context | Application | Example |
|---------|-------------|---------|
| Launch scoping | Pick a network, not a market | "Agents in one Austin brokerage," not "the US housing market" |
| Activation | Define and instrument the magic moment | Team exchanges 2,000 messages → long-term retention bar |
| Empty side | Flintstone missing supply manually | Founders personally fulfill the first 100 marketplace orders |

**Ethical boundary:** Flintstoning means doing re
37signals-waySkill

Build lean, opinionated products using the 37signals philosophy from Getting Real, Rework, and Shape Up. Use when the user mentions "Getting Real", "Rework", "Shape Up", "37signals", "Basecamp method", "six-week cycles", "fixed time variable scope", "appetite vs estimates", "betting table", "breadboarding", "fat marker sketch", "build less", "underdo the competition", or "opinionated software". Also trigger when cutting scope to ship faster, running small teams, avoiding long-term roadmaps, or eliminating meetings. Covers shaping, betting, building, and the art of saying no. For MVP validation, see lean-startup. For design sprints, see design-sprint.

blue-ocean-strategySkill

Create uncontested market space using value innovation instead of competing head-to-head. Use when the user mentions "blue ocean", "red ocean", "strategy canvas", "ERRC framework", "value innovation", "non-customers", "buyer utility map", "eliminate-reduce-raise-create", or "uncontested market". Also trigger when comparing pricing strategies, exploring new market categories, finding underserved customer segments, or asking how to stop competing on price. Covers the Four Actions Framework, buyer utility map, and value-cost trade-offs. For tech adoption strategy, see crossing-the-chasm. For product positioning, see obviously-awesome.

clean-architectureSkill

Structure software around the Dependency Rule: source code dependencies point inward from frameworks to use cases to entities. Use when the user mentions "architecture layers", "dependency rule", "ports and adapters", "hexagonal architecture", "use case boundary", "onion architecture", "screaming architecture", or "framework independence". Also trigger when decoupling business logic from databases or frameworks, defining module boundaries, or debating where to put business rules. Covers component principles, boundaries, and SOLID. For code quality, see clean-code. For domain modeling, see domain-driven-design.

clean-codeSkill

Write readable, maintainable code through disciplined naming, small functions, and clean error handling. Use when the user mentions "code review", "naming conventions", "function too long", "code smells", "readable code", "boy scout rule", "single responsibility", or "unit test quality". Also trigger when reviewing pull requests for readability, refactoring messy functions, debating comment styles, or improving error handling patterns. Covers SRP, comment discipline, formatting, and unit testing. For refactoring techniques, see refactoring-patterns. For architecture, see clean-architecture.

contagiousSkill

Engineer word-of-mouth and virality using the STEPPS framework (Social Currency, Triggers, Emotion, Public, Practical Value, Stories). Use when the user mentions "go viral", "word of mouth", "shareable content", "social currency", "why people share", "viral loop", "referral program", or "organic growth". Also trigger when designing shareable features, crafting social media campaigns, or building products that spread through peer recommendation. Covers environmental triggers and high-arousal emotional content. For sticky messaging, see made-to-stick. For persuasion tactics, see influence-psychology.

continuous-discoverySkill

Build a weekly cadence of customer touchpoints using Opportunity Solution Trees, assumption mapping, and interview snapshots. Use when the user mentions "continuous discovery", "opportunity solution tree", "weekly interviews", "assumption testing", "discovery habits", "product trio", or "outcome-based roadmap". Also trigger when setting up regular customer feedback loops, prioritizing which experiments to run, or connecting discovery insights to delivery work. Covers experience mapping, co-creation, and prioritizing opportunities. For interview technique, see mom-test. For team structure, see inspired-product.

cro-methodologySkill

Audit websites and landing pages for conversion issues and design evidence-based A/B tests. Use when the user mentions "landing page isnt converting", "conversion rate", "A/B test", "why visitors leave", "objection handling", "bounce rate", "split testing", or "conversion funnel". Also trigger when diagnosing why signups are low, designing experiment hypotheses, or auditing checkout flows for friction points. Covers funnel mapping, persuasion assets, and objection/counter-objection frameworks. For overall marketing strategy, see one-page-marketing. For usability issues, see ux-heuristics.

crossing-the-chasmSkill

Navigate the technology adoption lifecycle from early adopters to mainstream market. Use when the user mentions "crossing the chasm", "beachhead segment", "whole product", "early adopters vs. mainstream", "tech go-to-market", "bowling pin strategy", "technology adoption lifecycle", or "pragmatist buyers". Also trigger when a startup has early traction but struggles to grow beyond initial users, or when planning go-to-market for technical products. Covers D-Day analogy, bowling-pin strategy, and positioning against incumbents. For product positioning, see obviously-awesome. For new market creation, see blue-ocean-strategy.