sinapse-ai 9.2.0 → 9.4.0

package/squads/squad-product/knowledge-base/experimentation-framework.md

@@ -0,0 +1,196 @@
+# Experimentation Framework
+
+## Purpose
+Framework completo para design, execucao e analise de experimentos em produto — desde hipoteses ate decisoes baseadas em evidencia estatistica.
+
+## Principios de uma Cultura de Experimentacao
+
+1. **Velocidade importa** — Numero de experimentos/tempo correlaciona diretamente com growth
+2. **Maioria falha e normal** — 70-80% dos experimentos nao tem resultado positivo; falha = aprendizado
+3. **Hipotese antes do teste** — Todo experimento precisa de hipotese falsificavel escrita antes
+4. **Dados vencem HiPPO** — HiPPO = Highest Paid Person's Opinion. Evidencia sempre supera opinio
+5. **Guardrails sao obrigatorios** — Todo experimento tem metricas que nao podem degradar
+6. **Aprender > Ganhar** — Experimento que ensina algo sem resultado positivo ainda tem valor
+
+## Template de Hipotese (obrigatorio)
+
+```
+SE [mudanca especifica no produto/experiencia],
+ENTAO [resultado esperado com base em insight],
+PORQUE [logica/mecanismo subjacente].
+
+Mediremos: [metrica primaria]
+Esperamos: [X% de mudanca] em [periodo]
+Guardrails: [metricas que NAO podem degradar — ex: NPS, revenue, error rate]
+Segmentos a analisar: [new users / power users / mobile / etc.]
+```
+
+**Exemplo concreto:**
+```
+SE reduzirmos os campos do formulario de signup de 6 para 3,
+ENTAO a taxa de ativacao aumentara 15%,
+PORQUE menos friccao no ponto critico de entrada reduz abandono.
+
+Mediremos: Activation Rate (% que completa onboarding em D7)
+Esperamos: 15% de aumento relativo em 14 dias de experimento
+Guardrails: Taxa de email valido nao pode cair abaixo de 90%, NPS D30 nao pode cair
+Segmentos: new signups — todos os canais
+```
+
+## Ciclo Completo de Experimentacao
+
+```
+1. Ideacao → gerar hipoteses a partir de dados, entrevistas, analytics
+2. Priorizacao → ICE ou RICE scoring (ver pm-frameworks-reference.md)
+3. Design → definir variantes, metricas primarias, guardrails, sample size
+4. Implementacao → feature flags, tracking events, QA
+5. Execucao → rodar ate significancia estatistica (sem peeking!)
+6. Analise → avaliar resultados + segmentar por cohort, device, plan
+7. Decisao → Ship / Iterate / Kill
+8. Documentacao → registrar hipotese, resultado, aprendizado no repositorio
+```
+
+## Estatistica para A/B Testing
+
+### Frequentist vs. Bayesian
+
+| Aspecto | Frequentist | Bayesian |
+|---------|-------------|----------|
+| Pergunta | "Qual a prob de ver esses dados se H0 e verdadeira?" | "Qual a prob de A ser melhor que B?" |
+| Resultado | p-value + intervalo de confianca | Probabilidade posterior |
+| Sample size | Fixo (calculado antes) | Pode parar cedo |
+| Interpretacao | Tecnica (mal interpretada frequentemente) | Intuitiva ("90% chance de A ser melhor") |
+| Peeking | Proibido — infla falsos positivos | Permitido com cuidado |
+| Ferramentas | VWO, Growthbook | Optimizely STATS Engine, Statsig |
+
+**Recomendacao:** Para times iniciantes, abordagem Bayesian e mais segura por ser mais intuitiva. Para times maduros com volume, frequentist rigoroso ou Bayesian sequencial.
+
+### Parametros Fundamentais
+
+```
+Alpha (α) = 0.05 → 5% de chance de falso positivo (padrao da industria)
+Power (1-β) = 0.80 → 80% de chance de detectar efeito real (minimo aceitavel)
+MDE = Minimum Detectable Effect → menor efeito que vale detectar
+
+Regra pratica: quanto menor o MDE, mais amostra voce precisa
+```
+
+### Formula de Sample Size
+
+```
+n = (Zα/2 + Zβ)² × 2 × p × (1-p) / d²
+
+onde:
+p = taxa de conversao baseline (controle)
+d = MDE em termos absolutos (ex: 0.02 para 2pp de aumento)
+Zα/2 = 1.96 (para α = 0.05, two-tailed)
+Zβ = 0.84 (para power = 0.80)
+
+Exemplo:
+p = 0.05 (5% de conversao baseline)
+MDE = 20% relativo → d = 0.01 (5% × 20% = 1pp)
+n ≈ 7.680 usuarios por variante
+```
+
+**Calculadoras gratuitas:** Evan Miller A/B Test Calculator, Optimizely Sample Size Calculator
+
+### Erros Comuns
+
+| Erro | Consequencia | Como Evitar |
+|------|-------------|-------------|
+| Peeking (olhar antes do fim) | Infla falsos positivos | Definir duração antes de rodar |
+| Parar cedo quando positivo | Falso positivo | Rodar ate sample size calculado |
+| Testar multiplas metricas sem correcao | Aumenta chance de falso positivo | Bonferroni: α_adj = 0.05 / n_tests |
+| Segmentos pos-hoc sem ajuste | Findings espurios | Pre-registrar segmentos de interesse |
+| Novidade Effect (Hawthorne) | Resultado nao sustentavel | Rodar experimento 2+ semanas |
+| Sample Ratio Mismatch (SRM) | Invalida experimento | Verificar distribuicao 50/50 apos inicio |
+
+## Multi-Armed Bandit (MAB)
+
+Alternativa ao A/B teste classico que otimiza durante o experimento. Aloca trafego progressivamente para a variante com melhor performance.
+
+**Quando usar MAB:**
+- Otimizacoes continuas (ex: qual subject line de email funciona melhor)
+- Contextos onde o "regret" (perda durante teste) e caro
+- Experimentos de curto prazo sem necessidade de inferencia causal rigorosa
+
+**Quando NAO usar MAB:**
+- Quando precisa de conclusao estatistica precisa sobre magnitude de efeito
+- Quando o experimento tem implicacoes causais importantes
+- Quando ha sazonalidade (MAB pode convergir em variante por razoes de timing)
+
+**Algoritmos:**
+- **Epsilon-greedy:** Explora X% do trafego, explota (1-X)%
+- **UCB (Upper Confidence Bound):** Balanceia incerteza e performance historica
+- **Thompson Sampling:** Amostra de distribuicao posterior (Bayesian — recomendado)
+
+## Ferramentas de Experimentacao
+
+| Ferramenta | Tipo | Diferencial | Quando usar |
+|-----------|------|-------------|-------------|
+| **Statsig** | Full-stack | Feature flags + experiments + analytics | Times de tech com infra propria |
+| **Optimizely** | Enterprise | STATS Engine (Bayesian sequencial) | Enterprise com budget |
+| **PostHog** | Open-source | Flags + experiments + session replay | Startups, self-hosted |
+| **Growthbook** | Open-source | Bayesian, warehouse-native | Times que usam BigQuery/Snowflake |
+| **LaunchDarkly** | Feature flags | Feature management primeiro | Times que precisam de flag mgmt robusto |
+| **VWO** | CRO-focused | Visual editor, heatmaps | Times nao-tecnico, CRO de site |
+| **AB Tasty** | Enterprise | Forte no Brasil e Europa | Times Brasil com budget medio |
+
+## Experimentation Velocity — Metricas
+
+| Metrica | Definicao | Benchmark |
+|---------|-----------|-----------|
+| Tests/month | Experimentos iniciados | >10 para times maduros |
+| Time to launch | Ideia → lancamento do experimento | < 1 semana (ideal) |
+| Win rate | % de testes com resultado positivo | 15-30% (normal) |
+| Test coverage | % de features/pages com tests ativos | >50% para lideres |
+| Cycle time | Duracao media de um experimento | 2-4 semanas |
+
+## Repositorio de Experimentos — Template
+
+Cada experimento deve ser documentado com:
+
+```yaml
+experiment_id: EXP-{numero}
+name: "Nome descritivo"
+hypothesis: "SE... ENTAO... PORQUE..."
+primary_metric: ""
+guardrail_metrics: []
+start_date: ""
+end_date: ""
+sample_size_per_variant: 0
+actual_sample: 0
+result:
+  control: ""
+  variant: ""
+  lift: ""
+  p_value: ""
+  confidence: ""
+decision: "ship | iterate | kill"
+learnings: |
+  O que aprendemos independente do resultado
+next_steps: ""
+```
+
+## Anti-Patterns de Experimentacao
+
+| Anti-Pattern | Por que e problema |
+|-------------|-------------------|
+| "Sabemos que vai funcionar, e so confirmar" | Confirmation bias — experimentos devem poder falsificar hipoteses |
+| Rodar experimento por 2 dias | Nao capta sazonalidade semanal, amostra insuficiente |
+| 10 metricas primarias | Aumenta chance de falso positivo — 1 metrica primaria por experimento |
+| Rodar em 5% do trafego "para ser seguro" | Demora muito para alcancar significancia — calcule sample size corretamente |
+| Nao documentar hipotese antes | Permite racionalizacao post-hoc de qualquer resultado |
+| Esconder resultados negativos | Cria cultura de fear of failure — compartilhe aprendizados de falhas |
+
+## Integracao com Discovery
+
+Experimentos fecham o loop do Continuous Discovery:
+```
+Interview → Identify Opportunity → OST Mapping
+→ Assumption Mapping → Design Experiment
+→ Run Experiment → Validate/Invalidate Assumption
+→ Ship ou pivot → Next Interview Cycle
+```
+
+Ver `discovery-methodology-playbook.md` para a conexao com OST.

package/squads/squad-product/knowledge-base/pm-frameworks-reference.md

@@ -65,22 +65,73 @@ Effort: person-months
 
 ## Goal-Setting Frameworks
 
-### OKRs (Doerr)
+### OKRs (Doerr) — Deep Reference
+
+OKRs (Objectives and Key Results) foram popularizados por John Doerr no livro "Measure What Matters" (2018), baseado no sistema criado por Andy Grove na Intel e adotado pelo Google desde 1999.
+
+**Estrutura Completa:**
 ```
-Objective: Qualitative, inspirational
-  KR 1: [metric] from [X] to [Y]
-  KR 2: [metric] from [X] to [Y]
-  KR 3: [metric] from [X] to [Y]
+Objective: Qualitativo, inspiracional, time-bound (trimestral geralmente)
+  KR 1: [metrica] from [X] to [Y] by [data]
+  KR 2: [metrica] from [X] to [Y] by [data]
+  KR 3: [metrica] from [X] to [Y] by [data]
+  KR 4: (opcional, max 5 KRs por Objective)
 
 Scoring: 0.0-1.0
-  0.7 = target hit (aspirational)
+  0.7 = target hit (aspiracional — se sempre 1.0, nao e ambicioso)
   0.6-0.7 = healthy average
-  >0.8 = not ambitious enough
-  <0.4 = execution or target issues
+  >0.8 = not ambitious enough (subestimou)
+  <0.4 = execution or target issues (investigar)
+
+Mix: 60-70% committed OKRs, 30-40% aspirational OKRs
+```
+
+**Criterios de bons Key Results:**
+1. Quantitativos e mensuraveis (sem "melhorar", "aumentar" sem numero)
+2. Outcomes, nao outputs ("Atingir NRR de 110%", nao "Lançar feature X")
+3. Leading indicators preferidos a lagging quando possivel
+4. Max 5 KRs por Objective (foco)
+5. Geralmente 3-5 Objectives por trimestre por time
+
+**Exemplo para squad-product:**
+```
+Objective: Tornar o onboarding o mais rapido do mercado
+
+  KR1: Reduzir Time-to-First-Value de 12 minutos para 4 minutos
+  KR2: Aumentar Activation Rate de 28% para 45%
+  KR3: Melhorar D7 Retention de cohorts com onboarding completo de 40% para 55%
+  KR4: Atingir NPS de onboarding >= 45 (hoje: 28)
+```
+
+**Cadencia:**
+- Trimestral: definir OKRs, alignment com liderança
+- Semanal: check-in de progresso (15-30 min)
+- Mid-quarter: health check — ajustar se necessario
+- Final do trimestre: scoring + retrospectiva
 
-Mix: 60-70% committed, 30-40% aspirational
+**CFRs — o complemento dos OKRs:**
+Doerr adiciona CFRs (Conversations, Feedback, Recognition) como o lado humano dos OKRs:
+- Conversations regulares (1:1s) sobre progresso
+- Feedback contínuo sobre comportamento e resultados
+- Recognition quando KRs sao atingidos
+
+**KPI Tree — decompondo o Objective em metricas acionaveis:**
+```
+North Star Metric (ex: MRR)
+├── New MRR
+│   ├── Organic traffic × Conversion rate
+│   ├── Paid traffic × Conversion rate
+│   └── Referrals × Conversion rate
+├── Expansion MRR
+│   ├── Upgrade rate (PQL → Paid)
+│   └── Cross-sell rate
+└── Churned MRR (negativo)
+    ├── Logo churn rate
+    └── Downgrade rate
 ```
 
+Cada folha pode ser atribuida a um sub-time ou individuo — accountability clara.
+
 ## Discovery Frameworks
 
 ### Continuous Discovery Habits (Teresa Torres)
@@ -135,6 +186,71 @@ Bands: 80-100 GREEN | 60-79 YELLOW | 40-59 ORANGE | 0-39 RED
 - Survey: "How would you feel if you could no longer use [product]?"
 - >40% "Very Disappointed" = PMF achieved
 
+## Roadmap Frameworks
+
+### Now / Next / Later (Janna Bastow — ProdPad)
+
+O framework de roadmap mais adequado para contextos de agencia e quando ha incerteza. Evita falsas promessas de data.
+
+```
+NOW (este trimestre):
+  - Features em desenvolvimento ativo
+  - Commitment real com o time
+  - Alta confianca de delivery
+
+NEXT (proximo trimestre):
+  - Features planejadas e priorizadas
+  - Hipoteses validadas, detalhes ainda definindo
+  - Confianca media — pode mudar com nova informacao
+
+LATER (futuro, sem data):
+  - Ideias e direcoes estrategicas
+  - Dependem de validacao ou pre-requisitos
+  - Baixa confianca de timing
+```
+
+**Regras:**
+- Nunca mostrar datas para itens em NEXT ou LATER (promessa que nao pode cumprir)
+- Mover items de LATER → NEXT apenas quando houver evidencia de discovery
+- Items em NOW devem ter criterios de saida claros (Definition of Done)
+
+### Roadmap Formats por Audiencia
+
+| Audiencia | Formato | Nivel de Detalhe |
+|-----------|---------|-----------------|
+| Time de produto | NOW/NEXT/LATER interno com user stories | Alto |
+| Stakeholders internos | NOW/NEXT/LATER com themes e metricas | Medio |
+| Clientes / externos | NOW/NEXT/LATER com outcomes, sem datas | Baixo |
+| Board / investidores | Themes e metas estrategicas, sem features | Muito baixo |
+
+### Weighted Scoring — Priorizacao Avancada
+
+Para quando RICE simples nao captura todas as variaveis relevantes:
+
+```
+Score = (Business Value × W1) + (User Value × W2) + (Strategic Fit × W3)
+         - (Effort × W4) - (Risk × W5)
+
+Exemplo de pesos (ajustar para cada contexto):
+  W1 (Business Value): 30%
+  W2 (User Value): 25%
+  W3 (Strategic Fit): 20%
+  W4 (Effort — negativo): 15%
+  W5 (Risk — negativo): 10%
+
+Como pontuar (1-5 para cada criterio):
+  Business Value: ARR potential, retention impact, NRR impact
+  User Value: # users impacted, intensity of pain resolved
+  Strategic Fit: alignment with product vision e OKRs
+  Effort: story points estimate, complexity, unknowns
+  Risk: technical risk, market risk, dependency risk
+```
+
+**Quando usar:**
+- Portfolio de features com muitas dimensoes de valor
+- Quando stakeholders de diferentes areas precisam de transparencia na priorizacao
+- Para justificar decisoes de roadmap com evidencia numerica
+
 ## Client Management Frameworks
 
 ### Dual Roadmap System

package/squads/squad-product/knowledge-base/product-analytics-formulas.md

@@ -123,3 +123,75 @@ CES = Sum of Effort Scores / Total Responses (lower = better)
 | LTV/CAC | 3x | 5x+ | SaaS benchmarks |
 | Quick Ratio | 2-3 | 4+ | Mamoon Hamid |
 | Net Revenue Retention | 100-110% | 120%+ | KeyBanc |
+
+## Product Analytics Tooling — Quando Usar Cada Um
+
+| Ferramenta | Tipo | Melhor Para |
+|-----------|------|-------------|
+| **Mixpanel** | Product analytics | Event-based, funnels, flows, queries ad hoc |
+| **Amplitude** | Product analytics | Behavioral cohorts, experimentation integrada, enterprise |
+| **Heap** | Auto-capture | Times com pouco engineering bandwidth; retroactive analysis |
+| **PostHog** | Open-source all-in-one | Product analytics + session replay + feature flags (self-hosted) |
+| **GA4** | Web analytics | Trafego web, sessoes, conversoes — events-based |
+| **Hotjar** | Session recording | Heatmaps, qualitative understanding |
+| **Segment** | CDP | Coleta e roteamento de dados para multiplas ferramentas |
+| **Metabase** | BI / dashboards | SQL nativo, facil de usar, open-source |
+| **Looker** | Enterprise BI | Semantic layer (LookML), governance de metricas |
+
+## Cohort Analysis — Como Ler
+
+Cohort analysis agrupa usuarios por data de entrada e mede comportamento ao longo do tempo. E a ferramenta mais poderosa para entender retencao real.
+
+```
+Leitura de tabela de cohorts:
+
+Cohort  | Week 0 | Week 1 | Week 2 | Week 3 | Week 4
+Jan-W1  | 100%   | 45%    | 35%    | 30%    | 28%  ← curva estabilizou? PMF signal
+Jan-W2  | 100%   | 50%    | 40%    | 35%    | 33%  ← melhorou vs Jan-W1? melhorias funcionando?
+Jan-W3  | 100%   | 55%    | 45%    | 38%    | 36%
+
+Sinais positivos:
+  - Cohorts mais recentes retêm melhor que mais antigos = melhorias no produto funcionam
+  - Curva flattens (estabiliza) = PMF encontrado — um nucleo usa sempre
+
+Sinais negativos:
+  - Curva vai a zero = sem PMF — nenhuma quantidade de aquisicao resolve isso
+  - Cohorts mais recentes piores que antigos = algo degradou (produto ou qualidade de aquisicao)
+```
+
+**Tipos de cohort:**
+- **Acquisition cohort:** Agrupados por data de signup (padrao)
+- **Behavioral cohort:** Agrupados por acao (ex: "usou feature X na primeira semana")
+- **Feature cohort:** Comparar retencao de usuarios que adotaram feature vs. nao adotaram
+
+## North Star Metric — Como Definir
+
+A North Star Metric (NSM) e a unica metrica que melhor captura o valor central entregue ao usuario.
+
+**Criterios de uma boa NSM:**
+1. Reflete entrega de valor ao usuario (nao so receita)
+2. E leading indicator de receita futura
+3. E mensuravel e acionavel
+4. Pode ser influenciada por multiplos times
+
+**Exemplos classicos:**
+| Empresa | North Star Metric | Logica |
+|---------|-------------------|--------|
+| Facebook | DAU | Engagement diario = valor para usuario e anunciantes |
+| Airbnb | Noites reservadas | Core value: hospedagem completada |
+| Spotify | Tempo de escuta | Mais escuta = mais valor = mais retencao |
+| Slack | Mensagens por equipe | Adocao dentro da organizacao |
+
+**Guardrail metrics:** NSM nao substitui metricas de guardrail. Se o Spotify otimizasse apenas tempo de escuta, poderia degradar qualidade. Guardrails como NPS, churn e receita evitam otimizacao perversa.
+
+## Vanity vs. Actionable Metrics
+
+| Vanity Metric | Metrica Acionavel | Por que muda |
+|---------------|-------------------|-------------|
+| Total usuarios registrados | MAU (usuarios ativos mensais) | Registrado sem usar nao tem valor |
+| Page views totais | Engagement rate, time on site | Views sem contexto nao informam decisao |
+| Downloads do app | DAU/MAU ratio | Download sem uso e custo, nao valor |
+| Seguidores em social | Engagement rate, click-through | Seguidor inativo nao gera negocio |
+| Total de receita bruta | MRR growth rate, NRR | Receita declinante pode mascarar crescimento pontual |
+
+**Teste de Eric Ries para vanity metric:** Se a metrica subiu, voce sabe exatamente o que fazer diferente? Se nao, provavelmente e vanity.

package/squads/squad-product/knowledge-base/product-led-growth-reference.md

@@ -6,6 +6,13 @@ Referencia para metricas e praticas de Product-Led Growth, para quando clientes
 ## PLG Fundamentals (Wes Bush)
 Product-Led Growth = using your product as the primary vehicle to acquire, activate, and retain customers.
 
+**5 Principios Fundamentais do PLG:**
+1. O produto e o canal — usuario experimenta valor antes de falar com vendas
+2. Self-serve first — onboarding sem friccao, sem demo obrigatoria
+3. Time-to-value minimo — atingir "aha moment" o mais rapido possivel
+4. Bottom-up adoption — individuos adotam, organizacao compra depois
+5. Data-driven expansion — upsell baseado em comportamento, nao em pitch
+
 ### Three Growth Motions
 | Motion | Acquisition | Conversion | Best For |
 |--------|-----------|-----------|---------|
@@ -44,18 +51,140 @@ Firmographic Score (0-100) × 0.3:
 PQL = Score >= threshold
 ```
 
+**Sinais tipicos de PQL (OpenView):**
+- Atingiu limite do plano free
+- Convidou >= 5 colegas para o workspace
+- Usou feature premium durante trial
+- Excedeu volume de uso definido
+- Visitou pagina de pricing >= 2 vezes em 7 dias
+- Exportou dados (sinal de que o dado e valioso)
+
+## Modelos de Precificacao em PLG
+
+### Freemium vs. Free Trial vs. Reverse Trial
+
+| Modelo | Conversao Tipica | Ideal Para | Risco |
+|--------|-----------------|------------|-------|
+| **Freemium** | 2-5% para paid | Alto volume, low touch | "Free forever" consumers recursos sem converter |
+| **Free Trial** | 15-25% (maior urgencia) | Produtos complexos, demonstracao de valor | Pressao temporal pode frustrar |
+| **Reverse Trial** | 10-15% | Produtos onde valor premium e claro | Requer produto maduro com clear differentiation |
+| **Hybrid PLG + Sales** | Variavel | SMB self-serve + Enterprise sales-assist | Requer dois motores distintos |
+
+**Reverse Trial (modelo emergente):** Usuario comeca com funcionalidades premium → apos periodo faz downgrade para free. Funciona bem quando o valor do plano premium e obvio logo de cara.
+
 ## Growth Loops
 
-### Viral Loop
-User → Invites → New User → Activates → Invites → ...
-- K > 1 = viral growth
-- K 0.5-1.0 = supported growth
+### Acquisition Loops (como novos usuarios chegam)
+
+**1. Viral Loop**
+```
+User → Uses product → Invites/shares → New User → Activates → Invites → ...
+K > 1 = viral growth
+K 0.5-1.0 = supported growth (amplifica outros canais)
+```
+Exemplos: Slack, Zoom, Calendly
+
+**2. User-Generated Content Loop**
+```
+User creates content → Content indexed → New user discovers → Activates → Creates content → ...
+```
+Exemplos: Pinterest, Reddit, Notion templates
+
+**3. Paid Loop (funciona se LTV > CAC com margem)**
+```
+Revenue → Invest in ads → New users → Revenue → Reinvest → ...
+```
+
+**4. Sales Loop (B2B enterprise)**
+```
+Revenue → Hire sales → New clients → Revenue → Hire more → ...
+```
+
+### Engagement Loops (como usuarios continuam usando)
+
+**Personal Utility Loop:**
+```
+User creates/stores data → Data becomes more valuable → User returns → Creates more data → ...
+```
+Exemplos: Notion, Google Drive, Evernote
+
+**Social Loop:**
+```
+User posts → Gets feedback (likes, comments) → Motivated → Posts more → ...
+```
 
-### Content Loop
+**Notification Loop:**
+```
+Event happens → Push/email sent → User returns → Generates activity → Event happens → ...
+```
+
+### Monetization Loop
+```
+User uses more → Hits limits → Upgrades → Uses more → Expands further → ...
+```
+
+## Content Loop
 User creates content → Content indexed → New users discover → Activate → Create content → ...
 
-### Usage Loop
-More users → Product improves → More value → More users → ...
+## Usage Loop (Network Effects)
+More users → Product improves (data effects) → More value → More users → ...
+
+## Efeitos de Rede
+
+**Lei de Metcalfe:** Valor da rede proporcional ao quadrado de usuarios (n²)
+**Lei de Reed:** Para redes com grupos, valor cresce exponencialmente (2^n)
+
+| Tipo | Descricao | Exemplo |
+|------|-----------|---------|
+| **Direto** | Mais usuarios = mais valor para cada um | WhatsApp, telefone |
+| **Indireto (cross-side)** | Mais de um lado = mais valor para o outro | Uber (riders/drivers) |
+| **Data network effects** | Mais uso = produto melhor (via ML) | Waze, Google Search |
+| **Marketplace liquidity** | Mais vendedores e compradores = melhor mercado | Airbnb, Amazon |
+
+## Onboarding como Alavanca de PLG
+
+Samuel Hulick (UserOnboard.com) demonstrou que a maioria dos produtos perde 40-60% dos usuarios no primeiro uso.
+
+```
+Framework de Onboarding:
+  1. Sign-up Flow: minimo campos, social login, sem cartao de credito
+  2. Welcome Survey: 2-3 perguntas para personalizar (JTBD, role, objetivo)
+  3. Setup Checklist: passos claros com progresso visual
+  4. Quick Win: primeiro valor em < 5 minutos
+  5. Celebrate: reforco positivo ao atingir marcos
+  6. Ongoing Education: tooltips contextuais, emails educacionais
+
+Metricas criticas:
+  Time-to-First-Value (TTFV): mediana do tempo ate o "aha moment"
+  Activation Rate: % que completa setup critico em D7
+  Day 1 / Day 7 / Day 30 Retention por cohort de onboarding
+  Setup Completion Rate: % que completa cada etapa do checklist
+```
+
+## Product-Led Sales (PLS)
+
+PLS combina PLG com sales-assist: o produto gera leads qualificados pelo uso, e vendedores entram para converter/expandir. Modelo hibrido adotado por Slack, Atlassian, MongoDB, Twilio, Datadog.
+
+**Quando PLG precisa de Sales:**
+- Free tier atingiu limites → Sales ajuda no upgrade
+- Single user → Sales ajuda a expandir para team/company
+- PQL score alto → Sales faz outreach proativo
+- Enterprise features (SSO, admin controls, compliance) → Sales necessario
+- Negociacao de contrato anual / volume deal
+
+**PLS Workflow:**
+```
+User signs up → Uses product → PQL score threshold reached
+→ CS/Sales alert → Personalized outreach → Upgrade/expansion
+```
+
+**Segmentacao por motion:**
+| Segmento | Motion | Owner |
+|---------|--------|-------|
+| Individuos / solopreneurs | Full PLG | Produto |
+| SMB (<50 pessoas) | PLG + light-touch CS | CS + Produto |
+| Mid-market (50-500) | PLS — PQL alert + SDR | Sales + CS |
+| Enterprise (>500) | Sales-led com PLG assist | AE + CS |
 
 ## PLG Maturity Model
 | Score | Stage | Characteristics |
@@ -65,12 +194,25 @@ More users → Product improves → More value → More users → ...
 | 40-59 | PLG-Emerging | Self-serve exists but underperforms |
 | 0-39 | Sales-Led | Minimal product-led motion |
 
+## PLG Benchmarks (OpenView 2024)
+
+| Metrica | Median | Top Quartile |
+|---------|--------|-------------|
+| Signup → Activation Rate | 20-35% | 40-60% |
+| Activation → PQL Rate | 10-20% | 25-40% |
+| PQL → Paid Conversion | 15-25% | 30-50% |
+| Free-to-Paid (geral) | 2-5% | 8-15% |
+| Time-to-First-Value | 3-7 dias | <1 dia |
+| Viral Coefficient (K) | 0.1-0.3 | 0.5+ |
+
 ## Key PLG Authors
 | Author | Focus | Key Work |
 |--------|-------|---------|
-| Wes Bush | PLG strategy | Product-Led Growth (book) |
-| Elena Verna | Growth strategy | PLG frameworks |
-| Kyle Poyar | PLG metrics | OpenView PLG benchmarks |
-| Hiten Shah | Product analytics | FYI, KISSmetrics |
-| Chamath Palihapitiya | Growth | Facebook growth team |
-| Andrew Chen | Network effects | The Cold Start Problem |
+| Wes Bush | PLG strategy | Product-Led Growth (book, 2019) |
+| Elena Verna | Growth strategy, PLG advising | Miro, Amplitude, Dropbox, Malwarebytes |
+| Kyle Poyar | PLG metrics, pricing | OpenView PLG benchmarks |
+| Hiten Shah | Product analytics | FYI, KISSmetrics, Crazy Egg |
+| Chamath Palihapitiya | Growth, social | Facebook original growth team |
+| Andrew Chen | Network effects, cold start | The Cold Start Problem (a16z) |
+| Brian Balfour | Growth loops, RARRA | Reforge (ex-HubSpot VP Growth) |
+| Lenny Rachitsky | PLG metrics, benchmarks | Lenny's Newsletter (ex-Airbnb) |