MCP HubMCP Hub
SKILL·D09AD2

cold-start-problem

wondelai
Mis à jour 20 days ago
1,531
155
1,531
Voir sur GitHub
Designworddesign

À propos

Cette compétence fournit un cadre pour lancer et développer des produits en réseau en utilisant la méthodologie du "Problème du Démarrage à Froid" d'Andrew Chen. Elle aide les développeurs à résoudre les défis classiques des effets de réseau, tels que le problème de l'œuf et de la poule, la séquence des lancements et le diagnostic des stagnations de croissance. Utilisez-la lors de la création de places de marché, d'applications sociales ou de tout produit nécessitant une masse critique d'utilisateurs pour fournir de la valeur.

Installation rapide

Claude Code

Recommandé
Principal
npx skills add wondelai/skills -a claude-code
Commande PluginAlternatif
/plugin add https://github.com/wondelai/skills
Git CloneAlternatif
git clone https://github.com/wondelai/skills.git ~/.claude/skills/cold-start-problem

Copiez et collez cette commande dans Claude Code pour installer cette compétence

Documentation

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:

ContextApplicationExample
Metric designReplace totals with density measuresTrack weekly active networks, not registered users
Growth diagnosisAttribute growth to the three effects separatelyViral factor vs. session frequency vs. conversion, each per network
Strategy reviewMap the product as a network of networksA marketplace is one network per city-category pair

See: 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:

ContextApplicationExample
Launch scopingPick a network, not a market"Agents in one Austin brokerage," not "the US housing market"
ActivationDefine and instrument the magic momentTeam exchanges 2,000 messages → long-term retention bar
Empty sideFlintstone missing supply manuallyFounders personally fulfill the first 100 marketplace orders

Ethical boundary: Flintstoning means doing real work manually behind the scenes — never fabricating fake users, reviews, or activity that deceives the people on the network.

See: references/atomic-networks.md

3. Solve the Hard Side

Core concept: Every network has a hard side — a small minority who do disproportionate work and are disproportionately hard to attract and keep: sellers, creators, drivers, hosts, organizers. They have better alternatives and higher expectations, and without them the easy side finds an empty product. Understand their motivations — money, status, utility — and build the product and economics for them first.

Why it works: The easy side shows up when the hard side delivers value, not before. A content app without creators, a marketplace without supply, a collaboration tool without the organizer who sets it up — all are empty rooms. "Come for the tool, stay for the network" is the classic hard-side wedge: a single-player tool (Instagram's filters, OpenTable's reservation book) recruits the hard side one by one before any network exists, and then the network makes leaving unthinkable.

Key insights:

  • Identify the hard side by work done, not money paid: a few percent of users create most of the value on Wikipedia, YouTube, and most marketplaces
  • Map motivations explicitly: money (drivers, sellers), status (creators, top reviewers), utility (organizers who need the tool anyway) — each demands different product investments
  • Build pro workflows and economics for the hard side first; the easy side mostly needs a clean consumer experience
  • Subsidize the scarce side early — guarantees, bonuses, zero fees — and publish the taper so trust survives the rollback
  • Early hard-siders professionalize fast: plan power tools, analytics, and payout improvements for month three, not year three

Applications:

ContextApplicationExample
Marketplace seedingRecruit and subsidize supply before demandGuarantee cleaner earnings for eight weeks pre-launch
Social or content appCourt creators with status and reachEarly-follower advantage, featuring, creator funds
B2B collaborationGive the organizer single-player valueProject tracker useful alone; inviting the team makes it better

Ethical boundary: Hard-side economics must be honest — present launch subsidies as temporary incentives, and never build people's livelihoods on terms you plan to quietly degrade.

See: references/hard-side.md

4. Tipping Point and Escape Velocity

Core concept: Once the first atomic network works, growth becomes a repeatable playbook for tipping the next network, and the next — each launch cheaper than the last. The core tipping tools: invite-only mechanics (curation + scarcity + social proof), paying up for launch (subsidies, guarantees, pre-committed supply), and influencer or community seeding. After tipping, escape velocity is not a milestone but an operating model: continuously amplifying the acquisition, engagement, and economic effects.

Why it works: Invite-only launches look exclusionary but build density by design — every invitee arrives with at least one connection already inside, the network copies in along real social graphs, and scarcity manufactures the social proof that pulls the next cohort. Paying up converts money into density, the one asset rivals can't copy. Big-bang launches do the opposite: Google+ pushed hundreds of millions of signups into empty rooms, and the weak networks never retained.

Key insights:

  • Invite-only does three jobs at once: curates early culture, creates scarcity buzz, and imports each user's social graph
  • Subsidies are network CAC: spend to manufacture liquidity, measure cost per active network, taper on a published schedule
  • Big-bang launch is the canonical anti-pattern — fast fill, weak networks; press spikes land on emptiness and never return
  • After tipping, run the three forces as named workstreams: acquisition (viral loops, referrals), engagement (reinforcing loops, re-engagement), economic (conversion, subsidy rollback, pricing)
  • Each tipped network lowers the cost of the next: spillover awareness, a portable playbook, reusable supply relationships

Applications:

ContextApplicationExample
Consumer launchInvite-only with a referral treeWaitlist plus five invites per active user; track invite-graph density
Marketplace city #2Pay up to manufacture liquidityNinety-day driver earnings guarantee, tapered as fill rate rises
Post-tip growthStaff the three forces as workstreamsReferral loop, digest re-engagement, take-rate optimization

Ethical boundary: Scarcity and exclusivity must be real — fake waitlists and manufactured "limited spots" are deception, not strategy.

See: references/tipping-playbooks.md

5. The Ceiling and the Moat

Core concept: Growth always stalls. Rocketship curves are a sequence of S-curves, and each flattens against a ceiling: market saturation, channel degradation (CAC creep, banner blindness, viral fatigue), hard-side revolts, and quality collapse at scale — spam, overcrowding, context collapse. The moat is the network itself: defend the hard side, expect rivals to cherry-pick your densest segments, and remember that bundling fills the easy side but rarely wins the hard side.

Why it works: Every acquisition channel decays as audiences habituate and competitors pile in — the first banner ads clicked through at double-digit rates; today's average is a fraction of a percent. Networks also degrade from within: scale attracts spam and collapses the intimate contexts that made early networks valuable, so quality work becomes growth work. And competition between networks is asymmetric: challengers win by applying atomic-network discipline to one underserved niche — which is exactly how incumbents get unbundled.

Key insights:

  • Plot growth as stacked S-curves; start the next curve (geography, segment, use case, product) before the current one flattens
  • CAC creep and viral fatigue are laws, not failures — plan the next channel while the current one still works
  • Watch for hard-side revolt signals: take-rate complaints, multi-homing, organized protest — the hard side leaves first and takes the network with it
  • Quality interventions — curation, ranking, verification, spam fighting, sub-grouping — are growth investments at scale, not cost centers
  • Defend against cherry-picking by over-serving your densest niches; that is precisely where a David will attack your Goliath
  • Bundling buys distribution, not devotion — it fills seats on the easy side, while depth of engagement stays with whoever holds the hard side

Applications:

ContextApplicationExample
Stalled growthDiagnose which ceiling hit firstSeparate saturation, CAC creep, and quality-decay churn per network
Quality at scaleFund trust and curation loopsRatings, verification tiers, spam filters as a growth workstream
Competitive defenseHold the hard side in dense nichesMatch a rival's subsidies for top sellers before they multi-home

Ethical boundary: Fixing revolts and spam means addressing root causes for users — not silencing legitimate hard-side grievances with PR.

See: references/scale-ceiling-moat.md

Common Mistakes

MistakeWhy It FailsFix
Launching to a market instead of a networkUsers arrive scattered; nobody finds anybodyPick one atomic network and saturate it
Counting signups instead of densityVanity totals mask empty roomsMeasure weekly active networks, fill rate, time-to-match
Treating both sides equallyThe hard side is the bottleneck and the flight riskBuild product and economics for the hard side first
Big-bang launchFast fill, weak networks; hype lands on emptinessTip network by network with a repeatable playbook
Faking scarcity or activityUsers discover the deception; trust collapsesFlintstone with real work; keep invite scarcity real
Cloning network #2 before #1 is stableReplicating a broken loop multiplies failureGate expansion on magic-moment and retention bars
Assuming network effects strengthen foreverSpam, overcrowding, and context collapse compound tooFund quality, trust, and curation as growth work
Ignoring cherry-picking rivalsNiche players peel off your densest segmentsOver-serve dense niches; defend hard-side economics

Quick Diagnostic

QuestionIf NoAction
Can you name your first atomic network (who, where, how many)?You're launching to a market, not a networkConstrain by geography, org, or interest until self-sustaining
Is the magic moment defined and instrumented?You can't tell live networks from dead onesDefine it, measure it per network, gate expansion on it
Do you know who your hard side is and why they stay?Supply churns and the easy side follows it outMap money/status/utility motivations; build for them first
Does the product deliver value to its very first user?Pure chicken-and-egg with no wedgeAdd come-for-the-tool value or flintstone the gap
Is there a written playbook for tipping the next network?Every launch is an expensive one-off betCodify invites, subsidies, and seeding from launch #1
Are you measuring liquidity (fill rate, time-to-match)?Growth optics hide network healthAdd per-network density metrics to the core dashboard
Do you know which ceiling will hit first?The stall will arrive as a mysteryModel saturation, CAC creep, and quality decay now
Is anything defending the hard side from rivals?Cherry-pickers will peel off your best segmentsDeepen hard-side economics and pro tooling

Reference Files

  • references/atomic-networks.md — Choosing and launching the smallest viable network: constraints, minimum-size logic, magic-moment instrumentation, flintstoning, single-player fallbacks, sequencing networks #2..N
  • references/hard-side.md — Identifying the hard side, motivation mapping (money/status/utility), acquisition playbooks (tools-first, content-first, subsidies), pro-feature design, balancing both sides
  • references/tipping-playbooks.md — Invite-only mechanics, waitlists and referral trees, paid launches, supply pre-commitment, market selection, anti-patterns, liquidity metrics
  • references/scale-ceiling-moat.md — The three forces as growth workstreams, diagnosing ceilings, quality interventions at scale, moat and cherry-picking defense
  • references/case-studies.md — Three scenarios: a B2B tool finds its atomic network, a services marketplace seeds one city, a social app recovers from a big-bang launch

Further Reading

About the Author

Andrew Chen is a general partner at Andreessen Horowitz, where he invests in consumer technology, and previously led the rider growth team at Uber. His long-running essay series on growth, metrics, and network effects — read across the tech industry — became the foundation for The Cold Start Problem.

Dépôt GitHub

wondelai/skills
Chemin: cold-start-problem
0
agent-skillsai-skillsclaude-codeclaude-code-marketplaceclaude-code-pluginclaude-code-skills
FAQ

Frequently asked questions

What is the cold-start-problem skill?

cold-start-problem is a Claude Skill by wondelai. Skills package instructions and resources that Claude loads on demand, so Claude can perform cold-start-problem-related tasks without extra prompting.

How do I install cold-start-problem?

Use the install commands on this page: add cold-start-problem to Claude Code as a plugin, or clone its repository into your skills directory, then restart Claude so it picks up the skill.

What category does cold-start-problem belong to?

cold-start-problem is in the Design category, tagged word and design.

Is cold-start-problem free to use?

Yes. cold-start-problem is listed on AIMCP and free to install. It runs inside Claude, so no separate service account is required to use the skill itself.

Compétences associées

executing-plans
Design

Utilisez la compétence executing-plans lorsque vous disposez d'un plan de mise en œuvre complet à exécuter par lots contrôlés avec des points de contrôle de revue. Elle charge et examine le plan de manière critique, puis exécute les tâches par petits lots (3 tâches par défaut) tout en rapportant la progression entre chaque lot pour une revue par l'architecte. Cela garantit une mise en œuvre systématique avec des points de contrôle de qualité intégrés.

Voir la compétence
requesting-code-review
Design

Cette compétence délègue un sous-agent réviseur de code pour analyser les modifications apportées au code par rapport aux exigences avant de poursuivre. Elle doit être utilisée après avoir terminé des tâches, implémenté des fonctionnalités majeures, ou avant une fusion vers la branche principale. La revue aide à détecter précocement les problèmes en comparant l'implémentation actuelle avec le plan initial.

Voir la compétence
connect-mcp-server
Design

Cette compétence fournit un guide complet permettant aux développeurs de connecter des serveurs MCP à Claude Code via les transports HTTP, stdio ou SSE. Elle couvre l'installation, la configuration, l'authentification et la sécurité pour intégrer des services externes tels que GitHub, Notion et des API personnalisées. Utilisez-la lors de la configuration d'intégrations MCP, de la configuration d'outils externes ou du travail avec le Protocole de Contexte de Modèle de Claude.

Voir la compétence
web-cli-teleport
Design

Cette compétence aide les développeurs à choisir entre les interfaces Web et CLI de Claude Code en fonction de l'analyse des tâches, puis permet une téléportation transparente des sessions entre ces environnements. Elle optimise le flux de travail en gérant l'état et le contexte de la session lors du passage entre le web, la CLI ou le mobile. Utilisez-la pour des projets complexes nécessitant différents outils à diverses étapes.

Voir la compétence