Full stack builder é má ideia, argumenta produto

O problema do construtor full-stack

Ravi Mehta e Matthew Mamet argumentam que a ideia do "full-stack builder" - um profissional de produto capaz de executar sozinho todas as etapas, de protótipo a código - é prejudicial quando adotada sem salvaguardas. A premissa central é que a IA tornou opcional uma etapa que antes era obrigatória: a colaboração forçada entre produto, design e engenharia. Os handoffs lentos funcionavam também como mecanismos de verificação e equilíbrio.

O texto parte de um episódio concreto: Mamet ajudava uma grande organização sem fins lucrativos a substituir sua plataforma de membros e captação de recursos. Em dois dias, com auxílio de IA, produziu um documento de visão e um wireframe aproximado - trabalho que antes exigiria um designer e pelo menos uma semana. Ao apresentar o resultado a quinze pessoas, uma líder de operações de membros identificou que uma das funcionalidades já estava em produção e outra não poderia ser construída. A IA havia inventado detalhes que passaram despercebidos na pressa. A sala perdeu confiança no wireframe e, com isso, em todo o processo.

Por que "ship it and see" não basta

Os autores reconhecem o argumento a favor de experimentar mais e deixar os dados decidirem, comum em software de consumo e SaaS. Mas apontam que mais experimentos não produzem automaticamente mais verdade. Com um limiar de significância de 95%, aceita-se um falso positivo em cada vinte testes; a 90%, um em cada dez. Dashboards registram comportamento após o lançamento, mas a qualidade do trabalho foi decidida antes. Especialistas de domínio enxergam o que "bom o suficiente" esconde: o PM vê hipótese fraca, o designer vê interação confusa, o engenheiro vê premissa técnica que quebra sob carga real.

De orquestra a banda de jazz

Mehta e Mamet propõem uma analogia: o time de produto antigo funcionava como orquestra, com partitura (OKRs) e condução centralizada. O time AI-native se assemelha mais a uma banda de jazz, onde a liderança passa de um instrumento a outro e a música emerge da troca. Mas o jazz funciona porque os músicos compartilham um standard - um repertório conhecido antes da improvisação. Sem um padrão compartilhado que defina o que é bom o suficiente para lançar, a sala se enche de solos concorrentes.

Curadoria em vez de criação

Quando construir era escasso, times de produto se organizavam em torno da priorização: escolher cuidadosamente o que construir. Agora que construir é abundante, os autores defendem que a organização deve girar em torno da curadoria: escolher cuidadosamente o que lançar. O filtro mais eficaz que observaram é explícito: cada release deve avançar materialmente um resultado para o cliente; caso contrário, continua sendo refinado ou não é lançado.

Solução prática

Após o episódio na organização sem fins lucrativos, a equipe de Mamet instituiu uma regra simples: toda versão passaria primeiro por uma reunião de revisão de produto com grupo interno pequeno e leads técnicos, sem stakeholders de negócio. Apenas o que sobrevivesse a essa revisão avançaria. A correção levou dez minutos e restaurou a colaboração que o processo antigo fornecia gratuitamente. Os autores recomendam que times cuja velocidade de construção ultrapassou o processo de revisão adotem regra semelhante.