Bloco F · Semana 15 Tempo estimado: 22 min de leitura + ~2-3h de prática (preparação de reuniões reais) Output prático: você sai de uma reunião técnica com cliente avaliado como par técnico, não como vendedor

TL;DR

Semana 14 te deu pricing transparente. Agora a hora da verdade: a reunião onde TI corporativo decide se Team Studio passa ou trava. Reunião técnica em empresa média/grande tem regras diferentes de reunião comercial. Quem trata as duas igual perde nas duas.

Você vai sair desta semana sabendo:

  1. O perfil do TI corporativo em 2026 - quem realmente senta na mesa
  2. Roteiro de primeira reunião - estrutura comprovada (preparação + 50 min de execução)
  3. Vocabulário pra usar vs evitar - termos que mostram repertório vs buzzwords que afastam
  4. Sinais de TI hostil vs aliado - 5+5 indicadores e como reagir a cada
  5. Como pedir acessos sem parecer ameaça - princípio do menor privilégio aplicado a você
  6. Prova técnica que convence - por que demo bate slide, com failover plan
  7. 6 armadilhas comuns em reunião técnica
  8. Como Team Studio se prepara hoje - checklist + artefatos prontos
  9. 5 perguntas que destravam reunião
  10. Exercício prático - primeira reunião com CTO de fintech

1. O perfil do TI corporativo em 2026

Antes de entrar em táticas, entender quem está do outro lado.

1.1 Cargos típicos em empresa média/grande brasileira

Empresa média (50-200 funcionários, R$ 5-50M ARR): - 1 CTO (frequentemente sócio-fundador técnico) - 1-2 Tech Leads - 5-15 desenvolvedores - 1 DevOps/SRE (às vezes terceirizado) - Sem CISO formal (segurança é responsabilidade do CTO)

Empresa grande (200-2.000 funcionários, R$ 50M-1B ARR): - 1 CIO (estratégia de TI, mais visão de negócio) - 1 CTO (tecnologia de produto) - 1 CISO (segurança formal) - 3-8 Engineering Managers - 20-100 desenvolvedores em squads - Time SRE/DevOps dedicado - Time Data dedicado - Arquiteto Sênior ou Staff Engineer

Enterprise (2.000+ funcionários, R$ 1B+ ARR): - CIO + CTO + CISO + CDO (Data) + CPO (Product) - VP Engineering - Diretores por área (Platform, Product Eng, Infrastructure, Security) - Principal Engineers - 100-1000+ devs

1.2 Quem realmente decide

Mito: "fala com o CTO, ele decide".

Realidade: - CTO pode aprovar ou vetar, mas raramente avalia técnico-a-técnico em primeira reunião - Tech Lead / Staff Engineer / Arquiteto geralmente faz a avaliação técnica real - CISO veta em segurança/compliance - Engineering Manager influencia se o time interno topa integrar

A reunião que importa não é com o C-level. É com quem vai trabalhar com você no dia-a-dia. Esse decide se vai facilitar ou criar fricção infinita.

1.3 O viés técnico em 2026

TI corporativo brasileiro em 2026 tem características fortes:

  1. Cansado de hype: "AI vai resolver tudo" não funciona mais. Cansaram de NFT, crypto, no-code que ia substituir programador. Querem prova, não promessa.
  2. Conservador com fornecedor: cada SaaS contratado vira ponto de operação. Resistem a adicionar fornecedor sem motivo forte.
  3. Sensível à dependência: viram OpenAI mudar preço/política várias vezes. Querem fornecedor que não vire vendor lock-in.
  4. Cuidadoso com dado: LGPD pegou todos. Subprocessadores estrangeiros geram desconfiança.
  5. Quer integrar com stack atual: cliente já tem CRM, ERP, BI. Não quer substituir, quer complementar.

Postura Team Studio: respeita esse perfil. Vai pra reunião sabendo que precisa derrotar ceticismo, não vender entusiasmo.

2. Roteiro de primeira reunião com TI corporativo

Estrutura testada em ~10 reuniões reais. Não é receita rígida, é esqueleto.

2.1 Antes da reunião (preparação - 1-2h)

Pesquisa do cliente (30 min): - Site da empresa (entender produto/serviço) - LinkedIn dos participantes (background técnico, anos de empresa) - Glassdoor (clima interno, sinais de cultura técnica) - GitHub público se houver (stack visível) - Stack Share / BuiltWith (tecnologias detectadas)

Hipóteses iniciais (15 min): - Que stack provavelmente usam (cloud, banco, linguagem) - Que dor de negócio Team Studio resolve pra eles - Que objeções esperar (vendor lock-in, custo LLM, LGPD, integração com legado)

Artefatos prontos pra mostrar (15 min): - 1 slide de 1 minuto explicando Team Studio (caso precise contexto rápido pra técnico que não viu apresentação) - ADR-001 (Supabase vs Postgres) disponível pra mostrar maturidade arquitetural - Lista de subprocessadores publicada - DPA padrão pronto - 2-3 cases similares (mesmo porte ou setor) com referência de contato se possível

Preparação técnica (15 min): - Notebook com Mission Control aberto (demo pronta) - Backup de demo: vídeo de 60 segundos caso internet falhe - 5 perguntas que você vai fazer (vamos ver na seção 9)

2.2 Primeiros 5 minutos: estabelecer respeito técnico

O que NÃO fazer: - Começar com pitch comercial ("Team Studio é a solução perfeita pra...") - Falar de preço - Demonstrar superioridade técnica - Citar tecnologia que você não domina

O que fazer: - Apresentação curta (30 segundos): "Sou George, Team Studio. Implantei agentes de IA em ~20 empresas em 2025-2026, principalmente do setor X e Y." - Pergunta de calibração técnica: "Antes de eu apresentar nada, me ajuda a entender vocês: hoje o time tem quantas pessoas em engenharia? Stack principal? Como vocês operam (squad, time único, etc)?" - Escutar 3-5 minutos. Tomar notas visíveis (mostra que está escutando).

Reunião técnica que começa com escuta vence reunião que começa com fala.

2.3 Próximos 30 minutos: descoberta de stack e dor

Sequência de perguntas que mapeia tecnicamente o cliente sem virar interrogatório:

Bloco 1 - Stack atual (10 min): 1. "Qual cloud principal? Por que escolheram?" 2. "Banco de dados primário? Algum NoSQL ou warehouse?" 3. "CI/CD: onde, como? Frequência de deploy?" 4. "Observabilidade: que ferramentas?"

Bloco 2 - Dor de negócio (10 min): 1. "O que motivou vocês a olhar pra IA agora? Era prioridade no roadmap, demanda comercial, ou algo específico aconteceu?" 2. "Onde hoje vocês mais perdem tempo operacional?" 3. "Que iniciativa de IA já tentaram internamente? Como foi?"

Bloco 3 - Restrições (10 min): 1. "Qual seu processo de aprovação de fornecedor novo? Compliance, segurança, jurídico?" 2. "Têm requisitos de compliance específicos (LGPD, SOC 2, ISO 27001, setoriais como BACEN ou ANS)?" 3. "Qual posicionamento de vocês sobre dados em LLM? Anonimização obrigatória? Restrição de modelo?"

2.4 Últimos 15 minutos: proposta inicial + próximo passo

Proposta inicial em 2 partes:

Parte 1 - traduzir o que você ouviu: "Pelo que você me contou, vejo que prioridades de vocês são X e Y. Restrições principais são A e B. Dor mais aguda é Z."

(Confirma com cliente. Se ele corrige, você ajusta. Se ele valida, você ganha credibilidade.)

Parte 2 - propor caminho concreto: "Faz sentido a gente começar com Z (a dor mais aguda) num piloto de 30-45 dias. Escopo: [X]. Investimento: [faixa]. Sucesso medido por: [métrica]. Sem comprometimento de continuar depois se não der valor."

Próximo passo definido (5 min): - Quem do lado deles vai avaliar tecnicamente? Marcar reunião com essa pessoa. - Que documentos eles precisam revisar antes? Mandar pacote padrão (DPA, subprocessadores, política de segurança). - Próximo encontro: marcar data antes de sair da sala. "Próxima quinta às 14h funciona pros dois?"

Reunião que termina sem próximo passo agendado morre. Não confie em "te ligo na semana que vem".

3. Vocabulário pra usar vs vocabulário pra evitar

Linguagem em reunião técnica é peneira. Cada termo te coloca em uma categoria.

3.1 Termos que mostram repertório (use com confiança)

Termo Quando usar
"TCO em 24 meses" Discutindo preço
"Vendor lock-in" Discutindo dependência
"SLA composto" Discutindo confiabilidade
"Eventual consistency" Discutindo banco
"Princípio do menor privilégio" Discutindo permissões
"Latency budget" Discutindo performance
"Distributed monolith" Discutindo arquitetura ruim
"Token budget" Discutindo custo LLM
"Prompt caching" Discutindo otimização LLM
"Postmortem blameless" Discutindo cultura SRE
"ADR" Discutindo documentação técnica
"Backpressure" Discutindo sistemas async
"Idempotência" Discutindo APIs

Esses termos sinalizam que você convive com TI corporativo. Cliente que ouve "TCO em 24 meses" entende imediatamente.

3.2 Buzzwords que afastam (evite)

Buzzword Por que evitar
"Disruption" Sinal de marqueteiro sem repertório
"Game changer" Idem
"Solução AI-first" Vazio, todos dizem
"Sinergia" Corporativo morto
"Holístico" Pretensão sem substância
"Best-in-class" Cliente quer prova, não rótulo
"Best practices" Genérico demais
"Lo-code/No-code revoluciona" Cliente sofisticado já desconfia
"Democratizar IA" Vazio em B2B
"Tudo conectado, tudo integrado" Sem substância técnica

Esses termos sinalizam vendedor que treinou pitch sem entender produto. Custa credibilidade.

3.3 Quando dizer "não sei" e como dizer

Mito: admitir desconhecimento perde credibilidade.

Realidade: improvisar sem base perde MUITO mais credibilidade. Técnico identifica improviso em segundos.

Como dizer "não sei" com elegância:

  1. Reconhecer + propor descoberta: "Não tenho profundidade técnica nisso. Posso pesquisar e te trazer resposta documentada em 48h."

  2. Reconhecer + redirecionar: "Boa pergunta. Não é minha especialidade direta. Quem em Team Studio domina isso é [pessoa], posso colocar vocês em contato."

  3. Reconhecer + perguntar mais: "Não conheço esse caso específico. Pode me contar mais o contexto pra eu entender melhor antes de opinar?"

O que NÃO fazer: inventar resposta. Cliente lembra disso e vai testar de novo.

4. Como identificar sinais de TI hostil vs aliado

Em primeira reunião você pode identificar postura do TI nos primeiros 15 minutos.

4.1 5 sinais de TI hostil (quer barrar projeto)

  1. Foco em "vocês não têm X": pergunta atrás de pergunta procurando o gap. "Vocês têm SOC 2? Não. ISO 27001? Não. Multi-region? Não."

  2. Comparação desfavorável com concorrente: "OpenAI faz isso direto pela API, por que precisamos de Team Studio?"

  3. Escalation desnecessária: pequena dúvida vira "preciso discutir com diretoria antes de continuar".

  4. Promessa de avaliação que não vem: "Vou levar pra avaliação interna" sem prazo, sem próximo passo, sem participantes.

  5. Postura corporal/voz fechada: braços cruzados, voz baixa, pouco contato visual. Linguagem corporal honesta.

Como reagir a TI hostil: - Não confronte: vai piorar - Identifique o motivo real: medo de perder controle? Vendor anterior que decepcionou? Preferência por construir interno? Pergunte com curiosidade genuína. - Endereça motivo, não sintoma: se for medo de vendor lock-in, mostre exit strategy real. Se for "podemos construir interno", mostre TCO comparado. - Saiba sair: se hostil persistir, encerre com elegância. Cliente errado custa mais que perder venda. "Vejo que pode não ser o momento certo. Posso reabrir conversa em 6 meses?"

4.2 5 sinais de TI aliado (quer destravar)

  1. Perguntas construtivas: "Como vocês integrariam com nosso ERP?" "Que time de vocês ficaria disponível pra dúvidas operacionais?"

  2. Propõe próximos passos: "Posso te apresentar nosso head de operações na quinta?"

  3. Compartilha contexto interno: "Tem 3 meses que a diretoria tá querendo IA mas ninguém topou liderar. Vocês podem ser nosso jeito de testar."

  4. Pede artefatos específicos: "Manda o DPA pra eu revisar com jurídico. Subprocessadores também."

  5. Postura aberta: braços abertos, voz ativa, contato visual, faz anotações.

Como reagir a TI aliado: - Acelere ritmo: mandar artefatos em horas, não dias - Conecte ele com sua estrutura: WhatsApp direto, não pelo comercial - Reconheça publicamente: "O Marcos é quem destravou esse projeto pelo lado de vocês" - Cuide do relacionamento: cliente assim vira referência pra próximas vendas

4.3 Posição mais comum: ambivalente

70-80% dos TIs em primeira reunião não são hostis nem aliados. Estão avaliando. Sua função: dar pra eles material concreto pra avaliar e tempo pra decidir.

5. Como pedir acessos sem parecer ameaça à segurança

Quando Team Studio vai operar dentro da empresa, precisa de acesso a sistemas. Cliente novo treme com esse pedido.

5.1 Princípio aplicado a você mesmo

Princípio do menor privilégio: peça SÓ o que precisa pro escopo atual. Nada além.

Anti-padrão: "Pra começar, preciso de acesso admin no ERP, root no banco, todas as integrações."

Padrão correto: "Pra essa primeira semana, preciso ler 2 tabelas específicas (orders, customers) em modo read-only. Se ampliar escopo, peço novo acesso."

5.2 Roteiro de pedido de acesso

Estrutura em 4 partes:

  1. Escopo claro: "Preciso de acesso a X."
  2. Justificativa concreta: "Pra fazer Y."
  3. Limitação proposta: "Read-only, IP restrito ao nosso VPS, expira em 30 dias."
  4. Auditabilidade: "Toda ação minha fica logada. Posso te mandar logs semanalmente."

Exemplo concreto:

"Pra implantar agente de atendimento, preciso: 1. Webhook do WhatsApp Business apontando pro nosso endpoint específico (URL HTTPS com HMAC) 2. Read-only em orders e customers no Postgres (ou view dedicada se preferir) 3. Conta SMTP pra mandar email de fallback (limitada a 100/dia)

Sem acesso ao ERP completo, sem write em produção, sem secrets gerais. Todo acesso loga ação + timestamp + IP. Posso revisar semanalmente contigo."

Cliente reage diferente a esse pedido vs "preciso de admin".

5.3 O que NÃO pedir (red flags)

  • "Acesso completo pra investigar": vendor pedindo acesso amplo soa amador
  • "Senha do CEO/diretor": nunca
  • "Acesso por VPN ao escritório": complica, sinaliza falta de planejamento
  • "Compartilhar chave SSH com outro fornecedor": rede de fornecedores acessando entre si é pesadelo de auditoria
  • "Acesso ao GitHub completo": pede só repo específico
  • "Banco completo via cliente DBeaver": pede via API ou view dedicada

5.4 Quando você é quem cede acesso

Inverso também acontece. Cliente quer integrar com Team Studio.

Princípio: cliente recebe SÓ o necessário também. API key escopada, webhook assinado, rate limit por cliente.

Anti-padrão: cliente vira "admin" do Team Studio dele. Pode acessar dados de outros clientes (multi-tenant quebrado).

6. Prova técnica que convence (demo vs slide)

6.1 Por que slide perde reunião técnica

Slide funciona em reunião comercial porque comprova narrativa. Em reunião técnica, comprova vaporware.

Técnico vê slide bonito e pensa: "ok, mas funciona mesmo?"

Slide só serve em reunião técnica pra: - Contextualizar quem você é (30 segundos) - Mostrar arquitetura geral (1 minuto) - Detalhar pricing depois de demo passar (no fim)

6.2 Como preparar demo ao vivo

Demo certa = simulação real do uso.

Estrutura de demo de 5-10 minutos:

  1. Setup do cenário (30s): "Vou mostrar Mission Control operando pra cliente X (ou conta de teste). Vamos simular [cenário relevante pro cliente]."

  2. Caminho feliz (3-4 min): execute a tarefa típica. Mostre que funciona. Sem narração excessiva.

  3. Caso interessante (2-3 min): mostre algo não-óbvio. Como sistema lida com edge case. Como debugger funciona quando dá problema.

  4. Bastidores técnicos (1-2 min): abra log, abra dashboard, mostre métricas reais. "Aqui vê que custo desse cliente em LLM foi USD X no mês passado, latência p95 foi Y."

  5. Q&A da demo (resto do tempo): pergunta livre.

6.3 Failover plan (se demo quebrar)

Lei de Murphy garante que demo vai falhar na pior hora possível.

Failover plan: - Backup 1: vídeo de 60-90 segundos pré-gravado com demo funcionando (Loom, YouTube unlisted) - Backup 2: screenshots da execução típica em PDF/Notion - Backup 3: ambiente de staging em paralelo (se produção quebrar, mude pra staging) - Plano "wifi do cliente quebrou": hotspot do celular pronto - Plano "esqueci notebook": nunca, mas se acontecer, marca de novo

Como reagir se demo quebrar ao vivo: - NÃO entre em pânico: técnico do cliente também passa por isso - Reconheça: "Olha, deu erro aqui. Vou debugar contigo pra você ver como isso funciona em produção real" - Investigue na frente: mostre logs, hipóteses, próximos passos - Reverta pro plano B: "Enquanto isso, deixa eu te mostrar pelo vídeo" - Followup: depois da reunião, mande email explicando root cause + fix. Aumenta credibilidade.

Demo que falha mas tem failover bom AUMENTA credibilidade vs demo que funciona perfeitamente (que parece teatro).

7. 6 armadilhas comuns em reunião técnica

7.1 Comparativos baixos com concorrentes

Armadilha: cliente pergunta "como vocês são melhores que X?" e você cai em comparação direta enumerando defeitos do X.

Por que ruim: parece inseguro. Cliente lembra defeitos do concorrente, não suas qualidades.

Reação certa: "X é boa solução pra caso Y. Team Studio é boa pra caso Z. Vamos olhar qual seu caso e ver qual encaixa melhor."

7.2 "Vocês têm vs não têm"

Armadilha: cliente faz lista de features e checa quem tem mais.

Por que ruim: feature checklist nunca termina. Sempre vai faltar algo. Você perde.

Reação certa: "Lista de feature isolada não conta toda a história. Posso mostrar com seu caso de uso específico se isso resolve [problema concreto]?"

7.3 FUD reverso (Fear, Uncertainty, Doubt)

Armadilha: cliente joga incerteza ("e se vocês falirem? E se LGPD mudar?") esperando você desabar.

Por que ruim: você fica defensivo, responde de medo.

Reação certa: reconheça risco e mostre mitigação. "Risco de fornecedor falir existe. Aqui está nossa exit strategy: contrato garante export de dados em 7 dias + 60 dias de aviso prévio + documentação técnica completa. Vocês não ficam reféns."

7.4 Demonstração de superioridade técnica

Armadilha: técnico do cliente pergunta algo complexo pra te derrubar.

Por que ruim: você cai em modo "provar que sei tudo". Vira concurso de quem é mais inteligente.

Reação certa: não engaje. "Pergunta legal. Tá testando até onde vai meu repertório, e isso é justo. Real é que eu não domino tudo. Domino o suficiente pra entender problemas como o de vocês e propor solução adequada. O que você quer destravar com essa pergunta especificamente?"

Honestidade desativa o jogo. Técnico que estava testando, agora coopera.

7.5 Comprometimento prematuro

Armadilha: cliente pede comprometimento ("você consegue fazer X em 2 semanas?") antes de você ter escopo claro.

Por que ruim: você diz sim sem saber, queima reputação no primeiro mês.

Reação certa: "Antes de cravar 2 semanas, preciso entender [variáveis X, Y, Z]. Posso te dar estimativa preliminar agora baseada em casos similares (faixa de 2-4 semanas), e cravar prazo final depois de discovery de 3 dias."

7.6 Escopo creep na própria reunião

Armadilha: durante reunião, cliente vai adicionando coisas ao escopo. "Ah, e tem aquilo. E também aquilo outro."

Por que ruim: você sai com escopo dobrado mas preço original.

Reação certa: anote tudo separadamente. "Isso é interessante, vou anotar como fase 2. Pra fase 1 vamos manter foco em [escopo original] pra entregar valor rápido. Combinado?"

8. Como Team Studio se prepara hoje

Estado atual do processo de preparação:

8.1 Checklist pré-reunião (vai virar template)

  1. [ ] Pesquisa do cliente (site, LinkedIn participantes, glassdoor, GitHub público)
  2. [ ] Hipótese de stack provável
  3. [ ] Hipótese de dor de negócio
  4. [ ] Hipótese de 3 objeções esperadas
  5. [ ] Artefatos prontos no laptop (1 slide, ADR-001, lista subprocessadores, DPA padrão)
  6. [ ] Demo testada nas últimas 24h
  7. [ ] Vídeo backup atualizado
  8. [ ] Conta de demo populada com dados relevantes pro setor
  9. [ ] 5 perguntas escritas (calibração + descoberta + restrições)
  10. [ ] Próximo passo desejável definido (qual é a vitória desta reunião)

8.2 Artefatos prontos do Team Studio

Construídos ao longo das semanas 1-14 e disponíveis pra qualquer reunião:

  • Posicionamento institucional: site teamstudio.com.br com cases, catálogo, FAQ
  • Postura de segurança: subprocessadores listados, política de privacidade, política de cookies, procedimento de incidente
  • Contratos: DPA padrão, contrato de serviço, lista de subprocessadores formal
  • Trilha educacional: 16 semanas de fundamentos (essa que você tá lendo), 4 artigos da trilha George
  • Glossário Vibecoder: 200+ termos em 16 categorias
  • ADRs publicados: ADR-001 (Supabase vs Postgres self-hosted), próximos sendo escritos
  • Mission Control demo: ambiente de staging com dados reais simulados
  • Cases em produção: Terapeuta Multimídia, DSN, Hair Festival, escola de inglês infantil, etc.

Cliente que pede "manda material pra eu revisar com meu time" recebe link pra pasta organizada com tudo isso. Não precisa montar pacote cada reunião.

8.3 Pós-reunião (followup em 24h)

Email padrão pós-reunião:

Assunto: Próximos passos - Team Studio + [Empresa]

Oi [Nome],

Obrigado pela conversa hoje. Resumo do que conversamos:

CONTEXTO QUE VOCÊ COMPARTILHOU:
- [3-5 bullets do que ouvi]

DOR PRINCIPAL IDENTIFICADA:
- [1-2 frases sobre dor priorizada]

PROPOSTA PRELIMINAR:
- Escopo: [X]
- Investimento: [faixa, com TCO 12 meses]
- Sucesso medido por: [métrica]
- Prazo de piloto: [Y dias/semanas]

PRÓXIMOS PASSOS:
1. [Quinta 14h] Reunião técnica com [pessoa avaliando]
2. [Anexo] DPA padrão Team Studio + lista de subprocessadores
3. [Link] Pasta com material adicional (ADRs, cases, política de segurança)

ABERTO:
- [Pergunta que ficou sem resposta]
- [Decisão pendente do lado deles]

Algo que ficou faltando ou que mudei o entendimento?

Abraço,
George

Email assim mantém momentum. Cliente vê profissionalismo. E você documenta acordos pra evitar "eu não falei isso" 30 dias depois.

9. 5 perguntas que destravam reunião técnica

9.1 "Qual é o sucesso desse projeto pra vocês? Como vocês vão medir?"

Por que: força cliente a definir métrica. Métrica vaga = projeto que nunca termina bem. Métrica clara = projeto avaliável.

9.2 "Que iniciativa de IA vocês já tentaram internamente ou com outros fornecedores? Como foi?"

Por que: revela histórico de falha (que você precisa evitar repetir) e expectativa atual (calibra realismo). Cliente que diz "nunca testei nada" é diferente de "tentei com fornecedor X, deu errado por Y".

9.3 "Qual seu processo de aprovação de fornecedor novo? Quem aprova, em quantas etapas, em quanto tempo?"

Por que: dimensiona ciclo de venda real. Empresa onde CTO aprova sozinho fecha em 2-4 semanas. Empresa com VSR + jurídico + DPO + diretoria leva 3-6 meses. Saber isso muda como você executa.

9.4 "Que time de vocês fica responsável por operar e evoluir a integração no dia-a-dia? Como vocês acham que vai funcionar a parceria?"

Por que: identifica pessoa-chave do lado deles. Se ninguém vai operar do lado deles, projeto fica órfão e morre.

9.5 "Se vocês não fechassem com nenhum fornecedor de IA esse ano, o que aconteceria? Qual o custo de não fazer nada?"

Por que: força cálculo de custo de oportunidade. Se "não acontece nada", projeto não é prioridade. Se "perdemos R$ 500k/ano em produtividade", projeto é prioridade.

10. Exercício prático: primeira reunião com CTO de fintech

Cenário: Fintech de empréstimo PJ (CreditoSimples, 80 funcionários, R$ 30M ARR), 4 anos no mercado. CTO João pede reunião pra avaliar Team Studio. Marcou Wagner (Tech Lead) e Marina (CISO contratada part-time) pra participar.

Contexto que você descobriu na pesquisa: - Stack: AWS sa-east-1, Postgres RDS, Node.js + React, GitHub Actions, Datadog - 12 desenvolvedores em 2 squads - Acabaram de passar SOC 2 Type I (Marina liderou) - Crescendo 80% ano-ano - Dor pública: atendimento de cliente PJ tomando 40% do tempo do time comercial

Tarefa: estruturar a reunião de 45 minutos.

Reposta esperada (passo a passo)

Preparação pré-reunião

Hipóteses de stack: confirmadas pela pesquisa. Vou perguntar pra calibrar, não testar.

Hipóteses de dor: atendimento manual escala mal. 80% crescimento = mais clientes = mais atendimento. Bottleneck claro.

Hipóteses de objeção: 1. Marina (CISO) vai querer saber sobre LGPD + onde dado de cliente PJ é processado 2. Wagner (Tech Lead) vai querer entender integração técnica (webhook? API? Banco?) 3. João (CTO) vai querer entender ROI e prazo de implantação

Artefatos prioritários pra essa reunião: - DPA padrão (Marina vai pedir) - Lista de subprocessadores (Marina) - ADR-001 + visão arquitetural Team Studio (Wagner) - Caso similar: outra fintech ou SaaS B2B se houver (João) - Demo: atendimento WhatsApp com agente respondendo perguntas típicas de fintech PJ

Estrutura da reunião (45 min)

5 min - Apertura: "Oi pessoal. Sou George, Team Studio. Implantei agentes em ~20 empresas em 2025-2026, várias do setor financeiro e SaaS B2B. Vi no LinkedIn que vocês fecharam SOC 2 Type I recente, parabéns, sei o esforço. Antes de eu apresentar, me ajuda a calibrar: hoje o time tem 12 devs em 2 squads, certo? Stack principalmente AWS + Postgres + Node? Como é a operação do atendimento comercial hoje?"

10 min - Escuta de contexto: Deixa os 3 falarem. Tomar notas visíveis. Reformular pra confirmar entendimento.

5 min - Contextualizar Team Studio: "Beleza. Resumindo o que ouvi: vocês têm gargalo no atendimento PJ que escala mal com crescimento, e querem manter qualidade de resposta sem dobrar o time comercial. Vou contar em 3 minutos o que Team Studio faz, sem slide longo."

Apresenta em 3 minutos: catálogo de agentes + diferencial (custom, em uma tarde, dados do cliente, infra do cliente).

10 min - Demo focada: Mostra Mission Control operando atendimento WhatsApp de SaaS B2B similar. Foca em: como agente recebe pergunta, consulta knowledge base, responde, escala pra humano quando não sabe.

Mostra logs e custo real (USD X/mês desse cliente).

10 min - Aprofundamento técnico (com Wagner): - "Como funcionaria a integração com vocês? 3 opções: webhook do WhatsApp Business apontando pro nosso endpoint, ou Team Studio chama vossa API pra puxar dado do cliente, ou um híbrido." - "Pra knowledge base, podemos consumir docs internos via Sharepoint/Notion/Confluence/Drive, ou via API se preferirem." - "Sobre dado de cliente: tudo fica no Supabase nosso por padrão (criptografado at rest), ou em conta dedicada de vocês se compliance exigir. Já temos cliente nessa segunda configuração."

5 min - Compliance (com Marina): - "Sobre LGPD: somos operadores. DPA padrão anexo, lista de subprocessadores publicada (OpenAI, Anthropic, Supabase, AWS sa-east-1). Comunicação de incidente em 24h pra vocês. Direitos de titular processados em 5 dias úteis." - "SOC 2: ainda não temos report formal. Roadmap de ~24 meses pra Type II dependendo de demanda. Honesto sobre isso: vocês podem exigir e a gente acelera, ou aceitar postura atual via questionário detalhado." - "Quer que eu já mande o DPA pra você revisar?"

Próximos passos (combinar antes de sair): - Quem do lado deles vai aprofundar próxima conversa? (Wagner provavelmente) - Data próxima reunião (1 semana, marcada na hora) - Documentos a mandar em 24h: DPA, subprocessadores, ADR-001, link pra material adicional - Quem aprova: João + Marina (técnico + segurança), depois decisão de João sozinho

Resultado esperado

  • João sai impressionado com vocabulário técnico + honestidade sobre SOC 2
  • Wagner sai com clareza de como integração funcionaria
  • Marina sai sem alarmes (postura LGPD sólida, faltando só SOC 2 que ela entende)
  • Próxima reunião agendada antes de sair da sala

Em 80% dos casos, isso vira piloto em 4-6 semanas.

Resumo de uma frase

Reunião com TI corporativo bom vence quem escuta mais que fala nos primeiros 30 minutos, fala em vocabulário técnico-correto sem buzzword, mostra demo real com failover plan honesto, admite o que não sabe sem improvisar, e sai com próximo passo agendado na hora - resto é refinamento.

Próxima semana

A Semana 16 fecha a trilha com Vendor lock-in, exit strategy e checklist do CTO maduro: sinais de lock-in em cloud, banco e integração; como Team Studio se posiciona pra minimizar lock-in dos clientes (e por que comunicar isso vira venda); exit strategy formal documentada; checklist do CTO maduro com 15 perguntas que cliente avançado faz; termo de saudação técnica com 5 frases que abrem confiança em 5 minutos. Fecha o Bloco F e fecha as 16 semanas.

Glossário rápido (termos novos desta semana)

  • VSR (Vendor Security Review): processo de avaliação técnica de fornecedor (vimos na Semana 11)
  • Discovery: fase inicial de projeto pra mapear escopo real antes de comprometer prazo
  • Escopo creep: expansão silenciosa de escopo durante projeto, sem revisão de prazo/preço
  • FUD (Fear, Uncertainty, Doubt): tática de instilar dúvida no interlocutor pra ganhar barganha
  • Failover plan: plano alternativo pra quando algo primário falha (demo, conexão, etc)
  • Postura corporal técnica: linguagem corporal de quem avalia (anota, olha nos olhos, posiciona-se aberto)
  • Calibração técnica: processo de estabelecer nível de profundidade pra usar em conversa
  • Champion interno: pessoa do lado do cliente que defende sua proposta dentro da empresa
  • Squad: time multidisciplinar pequeno (5-10 pessoas) trabalhando em domínio específico
  • Knowledge base: base de informação consultada por agentes pra responder com contexto
  • Conta dedicada: configuração onde infraestrutura do cliente fica em conta cloud separada (mais isolamento, mais custo)
  • Postmortem blameless: análise pós-incidente focada em sistema/processo, não em culpa pessoal