Arquitetura vs. Feature Requests: O equilíbrio do PM de Plataforma
Uma feature nova pode criar um novo caos.
Fala galera! 👋
Já se pegou naquela situação clássica de reunião onde o time de projetos cross chega empolgadão com uma iniciativa nova que vai ter um ganho de negócio ABSURDO? Então, e você, ali, suando frio, imaginando o caos arquitetural que aquilo vai causar na sua plataforma? Pois é, eu também. todo. santo. trimestre.
Equilibrismo profissional
Ser PM de plataforma em uma grande empresa é basicamente correr o risco de ser um equilibrista de circo, só que sem rede de proteção e com o todo o board executivo assistindo. De um lado, você tem equipes de produto implorando por APIs novas e integrações para ontem. Do outro, engenheiros de plataforma olhando para o código legado como quem olha para um castelo de cartas prestes a desmoronar.
Sabe aquela feature aparentemente simples? "É só adicionar um endpoint novo, vai demorar tipo... 2 dias?" Aham, claro. Falei um pouco disso aqui:
E ignoramos completamente que isso pode comprometer todo o design da API, criar dependências circulares (ééé tem gente estudando Arquitetura Limpa) ou até mesmo violar regulamentações de segurança que custam milhões em multas.
Casos Reais
Vamos então, para dois casos reais que encontrei que ajudam a exemplificar o cenário:
A dupla sertaneja Stripe e Spotify
Caso Stripe: Compatibilidade vs. Inovação
A Stripe é conhecida por suas APIs extremamente bem documentadas e estáveis. Mas você sabia que eles enfrentaram uma crise existencial quando precisaram evoluir sua API principal?
Nos bastidores, PMs de plataforma da Stripe tiveram que decidir entre manter compatibilidade retroativa para centenas de milhares de integrações ou quebrar a experiência com um redesign completo para suportar os novos modelos de negócio. A solução? Eles criaram um sistema de versionamento robusto que permitia manter múltiplas versões da API simultaneamente, com um plano de migração gradual.
O resultado foi um equilíbrio perfeito: inovação constante sem quebrar integrações existentes. Mas por trás dessa decisão aparentemente simples, existiram meses de planejamento e dezenas de reuniões tensas onde PMs de plataforma tiveram que defender a importância de investir em arquitetura.
Caso Spotify: microserviços que viraram grandes dores
O Spotify é famoso por seu modelo de squads autônomos e microserviços. Parecia/parece até perfeito porque cada squad desenvolvia e mantinha seus próprios serviços. Porém, após alguns anos, chegaram a ter mais de 800 microserviços rodando em produção. O resultado?
Times gastando mais tempo com infraestrutura do que desenvolvendo features
Dificuldade para rastrear bugs que cruzavam múltiplos serviços
Aumento exponencial de custos de infraestrutura
Os PMs de plataforma do Spotify tiveram que bater na mesa e defender a consolidação de serviços e criação de padrões mais rígidos. Isso significou dizer "não" para algumas features que quebrariam esses padrões. Uma decisão impopular no curto prazo, mas que salvou milhões no longo prazo.
A arte de dizer "Não"
Como dizer "não" para aquela feature urgente que AQUELE PESSOA ou HIPPO está pedindo? Aqui vão algumas possibilidades que uso no meu dia a dia:
1. Tradução Técnica-Negócio
"Se implementarmos essa feature como solicitado, teremos aproximadamente 30% mais latência em todas as chamadas de API, o que significa que nossos clientes verão suas transações demorando 2 segundos a mais para concluir. Isso representa potencialmente uma perda de conversão de 15%, conforme nossos dados históricos."
Tão objetivo e simples quanto isso, traduzir consequências técnicas em impacto de negócio é uma habilidade fundamental. Quando você fala de débito técnico, a galera do business até revira os olhos. Quando você fala de conversão e receita, todos prestam atenção.
2. Ofereça alternativas, não problemas
Em vez de simplesmente recusar uma feature, venha preparado com alternativas: "Podemos implementar 80% da funcionalidade solicitada usando nossa arquitetura atual, garantindo lançamento em 3 semanas. A versão completa exigiria uma refatoração que levaria 3 meses. Qual delas oferece melhor ROI para vocês agora?". Vamos crer que nosso stakeholder sabe o que é ROI e também qual possibilidade tem mais retorno pra ele.
3. A Técnica do "Sim, e..."
"Sim, podemos adicionar essa feature, E vamos precisar de 2 sprints adicionais para refatorar a camada de autenticação que será impactada. Podemos começar ambos os trabalhos em paralelo."
A Plataforma como Produto
Uma mudança fundamental na minha carreira foi quando parei de ver a plataforma como um "centro de atendimento de tickets técnicos" e comecei a tratá-la como um produto estratégico.
Na Nubank (ou seria nO Nubank?), por exemplo, os PMs de plataforma não respondem a todas as solicitações de API. Em vez disso, eles definem claramente um conjunto de capacidades fundamentais da plataforma e avaliam as solicitações com base em como elas se alinham com essa visão de produto. É um pouco parecido com a ideia de Business Capabilities Model que fiz aqui na Stone, mapeando o core capabilities e support capabilities.
Alguns critérios que adotei:
Esta solicitação beneficia múltiplos times ou apenas um caso específico?
A implementação melhora ou degrada nossa arquitetura geral?
Isso resolve a causa raiz ou apenas um sintoma?
Como essa mudança se alinha com nossa estratégia de longo prazo?
O Roadmap Equilibrado: 60-30-10
Na minha experiência, a proporção mágica para roadmaps de plataforma é:
60% Features estratégicas alinhadas com direção da plataforma
30% Melhorias arquiteturais e redução de débito técnico
10% Flexibilidade para necessidades urgentes
Sempre dá pra fazer esse separação? Não. Eu tento? Demais. Quando consigo, faço nessas mesmas proporções? Nem sempre.
A AWS usa um modelo semelhante, onde eles separam explicitamente o tempo entre desenvolvimento de novos serviços e o que chamam de "undifferentiated heavy lifting" — o trabalho invisível mas crucial de manter a infraestrutura confiável.
Como vender Arquitetura para Stakeholders
Vamos ser sinceros: ninguém acorda empolgado com uma reunião sobre "melhoria de arquitetura de microsserviços". A não ser a gente, né? 😅
As vezes nem a gente mesmo. Confessa ai.
Para conseguir comprar tempo para melhorias arquiteturais, tento "embrulhar" essas iniciativas de formas que ressoem com diferentes stakeholders:
Para o CEO: "Esta melhoria nos permitirá lançar features 40% mais rápido no próximo ano"
Para o CFO: "Reduziremos custos de infraestrutura em 25% com esta refatoração"
Para o CTO: "Isso reduzirá nosso tempo médio de resolução de incidentes pela metade"
Quando trabalhei no Portobello América, conseguimos aprovar uma refatoração massiva da arquitetura de ecommerce não vendendo-a como "refatoração" mas como "habilitador de crescimento" — argumentando que a arquitetura atual não suportaria a escala planejada para o próximo ano.
Você é um PM, não criador de tickets
No final do dia, o verdadeiro valor de um PM de plataforma não está em atender todas as solicitações, mas em direcionar a evolução da plataforma de forma sustentável e estratégica.
Lembre-se: cada "não" bem fundamentado é tão valioso quanto um "sim" estratégico. E aquela refatoração que ninguém vê? Pode ser o que impede sua empresa de aparecer no site da Globo por um vazamento de dados catastrófico.
A próxima vez que alguém aparecer com aquele olhar de "é só um endpointzinho...", respire fundo e lembre-se: você é o guardião da arquitetura.
Ihhh Guardião? pô errei, fui moleque
Mas é do seu total interesse que a plataforma/produto seja escalável e altamente disponível. E isso é tão importante quanto qualquer feature brilhante que eles possam imaginar.