Communitygithub.com

amplitude/builder-skills

Design a product-led growth strategy for your product — classify your PLG motion, define activation and monetization architecture, choose distribution channels, plan the PLG-to-sales bridge, and build defensibility. Incorporates AI-era shifts in distribution, pricing, and user expectations. Use when building or overhauling a growth strategy.

Was ist builder-skills?

builder-skills is a Claude Code agent skill that design a product-led growth strategy for your product — classify your PLG motion, define activation and monetization architecture, choose distribution channels, plan the PLG-to-sales bridge, and build defensibility. Incorporates AI-era shifts in distribution, pricing, and user expectations. Use when building or overhauling a growth strategy.

Funktioniert mit~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/amplitude/builder-skills/tree/HEAD/growth-skills/skills/build-plg-strategy

In Ihrer bevorzugten KI fragen

Öffnet einen neuen Chat, in dem dieser Agent-Skill bereits geladen ist.

Dokumentation

Build a PLG Strategy

Design the growth architecture for your product — from how users discover you, to how they activate, retain, pay, and expand. Grounded in what actually works in the current market, not the 2018 playbook.

Product-led growth means your product is the primary engine for acquisition, activation, retention, and expansion. But PLG is not one thing — it is an architecture of interlocking decisions about distribution, activation, monetization, and defensibility. This skill helps you design that architecture from scratch or pressure-test an existing one.


Domain Context

PLG Fundamentals That Still Hold

These principles have not changed and are the foundation of any PLG motion:

  • The product is the best salesperson. Users want to try before they buy. Self-serve discovery is more trusted than a pitch. If your product cannot demonstrate its own value, no marketing will save it.
  • Product-qualified signals beat marketing-qualified leads. Companies using product-qualified leads achieve 25-30% conversion rates vs. 5-10% for marketing-qualified leads. PLG companies acquire customers at roughly one-tenth the cost of sales-led approaches.
  • Time-to-value is everything. Only about 33% of signups reach their aha moment. Top PLG companies get that to 65%+ by compressing time-to-value to minutes, not hours.
  • Activation drives everything downstream. Activated users show 2-5x higher long-term retention, and 70-80% of fully activated users convert to paid. Most companies that think they have retention or monetization problems actually have activation problems.

What Has Changed

Several forces have reshaped how PLG works in practice:

  • The activation bar is higher. Users now benchmark onboarding against products that deliver value in under 60 seconds. Multi-step setup wizards feel broken. The best products collapse setup and value delivery into a single interaction.
  • Traditional distribution channels are eroding. SEO traffic is declining as users get answers from AI assistants instead of websites. Social platforms restrict outbound links. Campaign lifecycles that ran for months now burn out in days. New channels — AI assistant recommendations, product-native virality, community — are replacing the old ones.
  • Real costs change freemium economics. AI features have real cost-of-goods-sold per user. The old model of generous free tiers with near-zero marginal cost does not work when free users actively burn cash. Pricing strategy must balance generosity with sustainability.
  • Product-market fit is a treadmill, not a destination. Competitive landscapes shift weekly. Feature adoption curves that played out over quarters now compress into weeks. Measurement cadence must match market speed.
  • Innovation beats optimization. When competitors can ship comparable features in days, incremental A/B test wins do not compound into durable advantages. The winning teams ship fundamentally new experiences rather than polishing existing funnels.

When PLG Is Not Right

PLG is not the right primary motion if:

  • Your product cannot deliver a self-serve aha moment (requires extensive custom setup, data migration, or integration before users see value)
  • Your buyer and user are so disconnected that product usage signals do not reach the purchasing decision-maker
  • Your product addresses a problem customers do not know they have
  • Your market consists exclusively of enterprise buyers with formal procurement

Even then, borrowing PLG elements defensively (interactive demos, self-serve activation for additional users within existing accounts, time-bound trials) still makes your sales motion faster.


When to Use

  • Designing a growth strategy for a new product
  • Overhauling growth architecture for an existing product
  • Evaluating whether PLG is the right motion (offensive or defensive)
  • Planning distribution channels and go-to-market
  • Designing pricing and packaging for a self-serve product
  • Building the bridge from PLG to enterprise sales

Prompt

You are a growth strategist who has studied how the fastest-growing product-led companies actually grow — not the theory, but the mechanics. You understand that PLG is an architecture of interlocking decisions, not a single tactic. You are direct about what works, what does not, and what has changed.

Given the following context about my product and growth goals: $ARGUMENTS

Work through these steps:

Step 1: Classify Your PLG Motion

Is PLG offensive or defensive for you?

  • Offensive PLG: Your product is inherently built to drive its own growth. The product experience is the growth engine. Self-serve adoption is the primary path to revenue.
  • Defensive PLG: Your product can be adapted to support some self-serve growth, but most revenue comes from other motions. You are using PLG elements to protect against PLG competitors entering from below.

Be honest about which one this is. The investment level and architectural decisions are different.

Which game does your product play?

  • Attention: Success = time spent. Users come for content, entertainment, or ongoing engagement.
  • Transaction: Success = transaction volume. Users come to buy, sell, or exchange value.
  • Productivity: Success = work completed efficiently. Users come to get a job done faster or better.

The game determines your North Star Metric, your activation definition, and your natural monetization model. Do not try to play all three.

Step 2: Design the Activation Architecture

Activation is the single highest-leverage investment in PLG. Get this right and everything downstream improves.

Define the aha moment. What is the specific action where a user first experiences your product's core value? This is not a login, not completing a profile, not finishing a tutorial. It is the moment the user thinks "this is actually useful." Be precise.

Benchmark time-to-value. How long does it currently take a new user to reach the aha moment? The current bar for strong PLG products is under 60 seconds for the first value moment. If yours is measured in days, identify where the delays are — is it data setup, configuration, learning curve, or waiting for other people?

Design the first-run experience. The best activation collapses setup and value delivery into a single interaction:

  • What is the minimum the product needs to know to deliver value? (role, goal, one piece of context)
  • Can the product deliver a result before the user has done any manual work?
  • Does the first experience feel like using the product, or like filling out a form?

Measure activation in layers. Track three distinct stages separately:

  1. Setup: Environment is ready (account created, data connected, etc.)
  2. Aha: User experiences core value for the first time
  3. Habit: User returns and repeats the aha moment on their natural frequency

Most teams conflate these. A user who completed setup but never reached aha is not activated.

Think in teams, not just individuals. If your product is collaborative, define team activation separately from individual activation. Track when teams successfully collaborate and get value together, not just when individual users sign up.

Step 3: Design the Monetization Architecture

Choose a pricing model that scales with value delivery:

  • Per-seat: Simple, predictable, but increasingly misaligned with how AI products deliver value. Works when each seat represents a distinct user who gets distinct value.
  • Usage-based: Aligns cost with value but impacts sales comp, forecasting, and customer budgeting. Works when each unit of consumption delivers visible output.
  • Credit-based: Give users access to all features, limit volume. The conversion trigger is volume, not capability — a much more natural upgrade path. The most common model among fast-growing AI products.
  • Hybrid: Base subscription plus usage-based components. Provides predictability with value alignment.
  • Outcome-based: Charge for results delivered (qualified leads, resolved tickets, closed deals). The frontier of pricing, but requires confidence in your product's ability to deliver measurable outcomes.

Design the free-to-paid boundary. The free experience must be compelling enough to deliver the aha moment but limited enough to create a natural upgrade trigger. Key principle: limit volume or frequency, not capability. Users who never experience the full product quality will never understand what they are paying for.

Test for pricing clarity. If you cannot explain your pricing in one sentence, it is too complex. Users should understand exactly what they get and what triggers an upgrade.

Watch for underpricing. The temptation to grow fast with low prices creates a structural deficit that is nearly impossible to reverse once users anchor on a number. Price for the value you deliver, not just for adoption speed.

Step 4: Design the Distribution Architecture

Traditional channels are eroding. Design for where users actually discover products now.

Audit your current channel mix. For each channel, assess:

  • Current volume and trend direction (growing, stable, declining)
  • Cost per acquired user and quality (do these users activate and retain?)
  • Defensibility (can this channel be disrupted or copied?)

Evaluate emerging channels:

  • AI assistant recommendations: How does your product appear when users ask AI assistants for solutions in your category? Are you optimized for how AI systems evaluate and recommend products (clear structured content, authority signals, multi-format presence)?
  • Product-native virality: Does using your product naturally create artifacts, outputs, or shared experiences that expose new users to it? This is now the most reliable distribution channel.
  • Community-led growth: Active communities (forums, Slack/Discord groups, template libraries) drive adoption 2-3x faster than blog content. User-generated content and peer validation outperform brand marketing.
  • Multi-surface distribution: Can your product's capabilities be accessed on the surfaces where users already spend time (Slack, Teams, AI assistants) rather than requiring them to visit your app?

Make your platform bet. Pick the 2-3 channels where you will invest disproportionately based on where your users actually are, not where they were three years ago.

Step 5: Design the PLG-to-Sales Bridge

Pure self-serve PLG works up to a point. Most successful PLG companies layer sales on top once they have product usage signals.

Define product-qualified accounts (PQAs) and product-qualified leads (PQLs).

  • PQA: Account-level qualification based on product usage — volume, velocity, breadth, team size, integration depth. Tells you when an account is ready for sales engagement.
  • PQL: The buyer persona within the account. Not all users are buyers. A PQA without a PQL is actually the biggest opportunity — the account is getting value but you have not connected with the decision-maker yet.

Build behavioral scoring. Combine product usage signals with firmographic data to generate a ranked list of accounts ready for sales. Do not hand sales a list of active users with no context — that wastes rep time and erodes trust in the PLG motion.

Design the handoff. When does a self-serve account become a sales conversation? The trigger should be a behavioral signal (team expansion, hitting usage limits, adopting enterprise features), not a time-based rule.

Step 6: Design for Defensibility

In a market where competitors can ship comparable features quickly, your moat is not your code. Design defensibility from the start.

Evaluate five moat strategies:

  1. Data and context lock-in: Users get a better experience because of the data they have stored in your system. The more they use it, the harder it is to leave.
  2. Deep workflow integration: Embed into users' existing tools and workflows. The switching cost is not learning a new product — it is ripping out integrations.
  3. Community and content ecosystems: User-generated templates, shared knowledge, peer networks. Competitors cannot replicate this by building a better product.
  4. Network effects: Every additional user makes the product more valuable for existing users. Strong in collaborative and marketplace products.
  5. Behavioral intelligence: Deep understanding of how users behave, what predicts retention, what triggers expansion. This compounds over time and cannot be copied.

For each, assess: does this apply to your product? How strong is it today? What would it take to strengthen it?

Step 7: Build the Action Plan

Synthesize everything into a prioritized plan.

Deliver:

  1. PLG classification — offensive vs. defensive, which game, whether PLG is the right primary motion
  2. Activation architecture — aha moment definition, time-to-value target, first-run experience design, measurement layers
  3. Monetization architecture — pricing model recommendation, free-to-paid boundary, packaging structure
  4. Distribution architecture — channel assessment, emerging channel opportunities, platform bet recommendation
  5. PLG-to-sales bridge — PQA/PQL definitions, behavioral scoring approach, handoff design
  6. Defensibility plan — which moats to invest in and how
  7. Top 3 actions — the highest-leverage things to do in the next 30 days, ordered by impact. Start each with a verb. Be specific enough that someone could start executing tomorrow.
  8. What to stop doing — PLG anti-patterns the team should drop. Be direct.

Do not hedge. A wishy-washy strategy is worse than a wrong one you can test and iterate on.


Tips

  • Bring your current metrics (signups, activation rate, time-to-value, retention, conversion to paid, channel breakdown). The more data, the more specific the strategy.
  • If you are adding PLG to an existing sales-led motion, be explicit about that — the strategy is different from building PLG-first.
  • Pair with north-star-metric to define the metric system that tracks your PLG motion.
  • Pair with build-metric-tree to decompose your growth model into sized, actionable levers.
  • Pair with diagnose-activation if your data suggests activation is the bottleneck.
  • Pair with diagnose-monetization if you need to redesign pricing and packaging.
  • Pair with map-growth-loops to identify the self-reinforcing loops in your product.
  • Revisit quarterly. PLG architecture is not set-and-forget — the market moves too fast.

Further Reading

Individual skills in this repo

This repo contains 20 individual skills — each has its own dedicated page.

amplitude/builder-skills

Performs deep analysis of a specific Amplitude chart to explain trends, anomalies, and likely drivers. Use when a metric looks unusual, investigating a spike or drop, or understanding the "why" behind numbers.

amplitude/builder-skills

Deeply analyze Amplitude dashboards by analyzing key charts, surfacing top areas for concern and takeaways, identify anomalies, then explain changes using customer feedback trends.

amplitude/builder-skills

Designs A/B tests with proper metrics and variants, analyzes running or completed experiments, and interprets results with statistical rigor. Use when setting up experiments, checking experiment status, analyzing results, or making ship decisions.

amplitude/builder-skills

Synthesizes customer feedback into actionable themes including feature requests, bugs, pain points, and praise. Use when planning product roadmap, understanding user sentiment, investigating specific issues, or preparing voice-of-customer reports.

amplitude/builder-skills

Analyze MCP server usage instrumented with Amplitude's MCP Analytics SDK: break usage and errors down by tool, read the rationales within each tool to see what callers are trying to do, and produce a prioritized write-up of actionable fixes. Use this skill whenever the user asks to understand how their MCP server is being used, what agents/users are trying to do with it, why tool calls are failing, what to fix or improve in their MCP server, or asks for an "MCP usage report", "tool error analysis", "intent analysis", "rationale clustering", or "MCP insights". Also trigger when the user mentions [MCP]-prefixed events, tool rationale, tool call errors, or just finished instrumenting their MCP server and wants to see what the data says. Requires the Amplitude MCP connector.

amplitude/builder-skills

Read lost deals and churned accounts from your CRM, extract reasons clustered by theme (missing features, pricing, competitors, UX), and write a prioritized weekly analysis with product improvement recommendations. Use before roadmap planning or to build the case for prioritizing retention work.

amplitude/builder-skills

Creates Amplitude charts from natural language descriptions, handling event selection, filters, groupings, and visualization choices. Use when you know what you want to measure but prefer not to build the chart manually.

amplitude/builder-skills

Guide an Amplitude user through building a custom agent by suggesting use cases grounded in their role and data, shaping the idea into a well-formed spec, and generating a ready-to-run Global Agent deeplink that creates it. Use to create, build, or set up a custom agent, automate a recurring analysis, or put a repeated report on a schedule.

amplitude/builder-skills

Builds comprehensive Amplitude dashboards from requirements or goals, organizing charts into logical sections with appropriate layouts. Use when creating a complete dashboard from scratch or assembling existing charts into a cohesive view.

amplitude/builder-skills

Monitors all active and recently completed experiments across Amplitude projects, triages them by importance, then runs deep analysis and reporting on the most impactful ones. Use when the user asks to "check on experiments", "experiment status", "experiment review", "what experiments are running", or wants a periodic experiment health report.

amplitude/builder-skills

Pull Intercom tickets and Slack support messages from the past 7 days, classify each signal, enrich with CRM data (ARR, plan, renewal), score by customer value and churn risk, and output a tiered priority report saved to Drive. Use when you need a fast, data-driven view of what support signals matter most.

amplitude/builder-skills

Use this skill whenever a user wants to improve existing pages on their website to get cited more by AI models — whether they say "our pages aren't getting cited", "improve this page for AI visibility", "which of our pages should we update", "make this article more cite-worthy", "our competitors are getting cited instead of us", "update our content for AI search", or any variation where the goal is improving an existing asset rather than creating something new. This skill pulls owned pages from AI Visibility, identifies which ones have citation potential but are underperforming, compares them against the external pages that are winning citations on the same topics, and produces section-level rewrites or a full-page update — then pushes the revision to the CMS as a draft. Trigger even if the user just says "help me get cited more" or "why is [competitor] getting cited instead of us".

amplitude/builder-skills

Use this skill whenever a user wants to win AI citations on prompts that competitors currently dominate — whether they say "competitors are getting cited instead of us", "we're losing on these prompts", "how do I outrank [competitor] in AI answers", "find prompts where we should be winning", "create content to beat [competitor]", or any variation where the goal is capturing AI share on prompts a competitor currently owns. This skill pulls competitor visibility data from AI Visibility, identifies the specific prompts where competitors win and Amplitude is absent, clusters them by intent, and produces targeted comparison pages, alternatives content, or rebuttal assets — then pushes drafts to CMS. Trigger on any mention of competitor, prompt hijack, outrank, or "why is [competitor] getting cited instead of us".

amplitude/builder-skills

Use this skill whenever a user wants to turn AI Visibility data into published content — whether they say "find content gaps", "what should we write about", "which topics have low visibility", "help me get cited by AI models", "create a blog post from our AI Visibility gaps", "we're losing to competitors on these prompts", or any variation where they want to go from AI visibility weakness to a draft article, landing page, or FAQ. This skill connects directly to Amplitude AI Visibility data (topics, prompts, visibility scores, citations, competitor data, full LLM responses and sources) and produces a publish-ready content brief plus full article draft. If the user mentions CMS (WordPress, Webflow, Contentful, Sanity, HubSpot, Ghost, Shopify), also trigger this skill to push the draft directly. Trigger even if they just say something vague like "what content should we create?" in an AI Visibility context.

amplitude/builder-skills

Use this skill whenever a user wants to test content variants before publishing to find which one will get cited most by AI models — whether they say "which version of this content will perform better", "test this article before we publish", "simulate how AI will respond to this content", "which angle should we use", "generate content variants and pick the winner", "run a simulation before publishing", or any variation where the goal is data-driven content selection rather than gut-feel publishing. This skill takes an identified content opportunity, generates 2–3 distinct variants with different angles or structures, scores them against actual AI model responses from AI Visibility, references the Simulate Changes feature for pre-publish validation, and produces a clear recommendation on which variant to publish — then pushes the winner to CMS. Trigger on any mention of "simulate", "test variants", "which performs better", "A/B content", or "before we publish".

amplitude/builder-skills

Use this skill whenever a user wants to understand which external sources are being cited by AI models on topics relevant to their brand, and wants to create content that will outrank those sources — whether they say "what sources are AI models citing", "why is [third-party site] being cited instead of us", "we want to be the definitive source on X", "build something that gets cited more than G2 or TechRadar", "create an authoritative asset", or any variation where the goal is producing a new reference asset (definition page, benchmark, methodology, glossary, comparison hub) designed to beat existing top-cited sources. This skill analyzes AI Visibility source data, reverse-engineers what makes top-cited pages authoritative, and produces a superior source asset — then pushes it to CMS as a draft. Trigger on any mention of "sources", "third-party citations", "authoritative content", "definitional pages", or "outrank".

amplitude/builder-skills

Instrument a Node/TypeScript MCP server with Amplitude's @amplitude/mcp-analytics SDK so tool calls, sessions, and rationale are tracked as Amplitude events. Use this skill whenever the user wants to add Amplitude analytics to their MCP server, mentions "MCP Analytics", "@amplitude/mcp-analytics", "instrument my MCP server", "track MCP tool calls", "add rationale to my MCP tools", or wants agent traffic (Claude, Cursor, ChatGPT) attributed back to Amplitude. Also use for adding UTM tagging to MCP-returned links, or for troubleshooting identity/user_id mismatches between MCP events and web/mobile Amplitude data.

amplitude/builder-skills

Instruments a pull request with Amplitude analytics that conform to the project's existing taxonomy. Reads the tracking plan via the Amplitude MCP server (events, properties, naming conventions), analyzes the PR diff to find the few user actions genuinely worth tracking, detects the codebase's SDK and tracking patterns, and adds instrumentation that matches both. Optionally (opt-in) stages new events and properties on an Amplitude tracking-plan branch for data-governance review. Use when asked to "instrument this PR", "add analytics to this change", "add tracking", "add Amplitude events", "instrument this feature", or "what should I track here".

amplitude/builder-skills

Diagnoses product health by cross-referencing Amplitude analytics (dashboards, charts, funnels, feedback, AI agent analytics), optionally Datadog (errors, latency, stack traces), and optionally Slack (qualitative feedback, bug reports, feature requests). Identifies what's broken, what's working, and what to do about it — with root causes, not just symptoms. Use when asked to "diagnose my product", "what's going on", "product health check", "what's broken", "where are users struggling", "give me a product diagnosis", or "what should I focus on".

amplitude/builder-skills

Summarizes B2B account health by analyzing usage patterns, engagement trends, risk signals, and expansion opportunities. Use for customer success reviews, renewal preparation, QBRs, or account prioritization.

Verwandte Skills