Por que tantos produtos digitais falham antes mesmo de serem lançados? A resposta pode estar na Lei de Gall.

Existe uma cena que se repete em empresas de todos os tamanhos.

Uma nova ideia surge. O entusiasmo é grande. Em poucas reuniões, o que começou como uma solução simples já se transformou em uma plataforma completa, repleta de funcionalidades, integrações, inteligência artificial, dashboards, automações, aplicativos mobile, múltiplos perfis de usuários e dezenas de requisitos considerados "essenciais".

Antes mesmo da primeira linha de código ser escrita, o produto já parece resolver todos os problemas imagináveis.

O problema é que, na maioria das vezes, ele nunca chega a resolver nenhum.

Não porque a equipe seja incompetente ou porque a tecnologia escolhida esteja errada. O fracasso costuma começar muito antes da implementação. Ele nasce quando tentamos construir um sistema complexo antes de compreender como ele realmente deveria evoluir.

Essa situação é tão comum que existe um princípio da engenharia capaz de explicá-la há mais de cinquenta anos.

Conhecido como Lei de Gall, ele afirma:

"Um sistema complexo que funciona invariavelmente evoluiu a partir de um sistema simples que funcionava. Um sistema complexo criado do zero nunca funciona e precisa ser reconstruído."

Apesar de ter sido formulada muito antes da computação em nuvem, da Inteligência Artificial ou dos microsserviços, essa ideia continua surpreendentemente atual.

Ela explica por que tantas startups desperdiçam tempo construindo funcionalidades que ninguém utiliza. Explica por que grandes projetos corporativos frequentemente atrasam ou nunca chegam a ser concluídos. E explica, principalmente, por que as empresas mais bem-sucedidas do mundo raramente tentam construir a versão definitiva de seus produtos logo na primeira tentativa.

Neste artigo, vamos explorar por que a Lei de Gall continua sendo uma das lições mais importantes para quem desenvolve produtos digitais e como ela pode mudar a forma como pensamos arquitetura, inovação e evolução de software.

O que a Lei de Gall realmente significa?

À primeira vista, a Lei de Gall parece apenas uma recomendação para começar pequeno. No entanto, sua mensagem é muito mais profunda.

Ela não fala sobre o tamanho de um projeto.

Ela fala sobre evolução.

Quando John Gall observou diferentes tipos de sistemas — tecnológicos, organizacionais e sociais — percebeu um padrão que se repetia constantemente: os sistemas que funcionavam raramente haviam sido planejados em sua forma final. Eles evoluíam gradualmente, aprendendo com erros, adaptações e necessidades reais.

Em outras palavras, sistemas complexos não nascem prontos.

Eles amadurecem.

Isso acontece porque, no início de qualquer projeto, existe uma limitação inevitável: ninguém conhece completamente o problema que está tentando resolver.

É comum imaginar que um produto precisará de dezenas de funcionalidades para gerar valor. No entanto, quando ele chega às mãos dos primeiros usuários, a realidade quase sempre é diferente. Algumas funcionalidades são ignoradas, outras precisam ser redesenhadas e novas necessidades surgem de forma completamente inesperada.

É justamente esse processo de aprendizado que torna a evolução tão importante.

Um sistema simples permite observar o comportamento dos usuários, validar hipóteses e compreender o que realmente faz sentido antes que a complexidade aumente.

Um sistema complexo, por outro lado, torna qualquer mudança muito mais cara. Corrigir uma decisão equivocada passa a exigir alterações em dezenas de componentes, equipes e processos que sequer deveriam existir naquele momento.

Talvez essa seja a principal lição da Lei de Gall.

Ela não diz que sistemas complexos são ruins.

Ela diz que a complexidade precisa ser conquistada.

Primeiro constrói-se algo simples que resolve um problema real. Depois, cada nova evolução passa a existir porque foi justificada pelo aprendizado adquirido ao longo do caminho.

Essa é exatamente a diferença entre projetar um produto e permitir que ele evolua.

O erro mais comum na construção de produtos digitais

Se a Lei de Gall ensina que sistemas complexos evoluem a partir de sistemas simples, por que tantas empresas continuam tentando fazer exatamente o contrário?

A resposta, muitas vezes, está na forma como imaginamos o futuro.

Quando uma nova ideia surge, é natural visualizar o produto já em sua versão mais completa. Pensamos em todas as funcionalidades que gostaríamos de oferecer, nos diferentes perfis de usuários, nas integrações, nos dashboards, nos relatórios, nos aplicativos móveis e em todas as possibilidades que aquele produto poderá ter um dia.

O problema é que começamos a construir o futuro antes de validar o presente.

É comum encontrar projetos que passam meses — ou até anos — sendo desenvolvidos sem que um único usuário tenha utilizado a primeira versão. Durante esse período, decisões importantes são tomadas com base em hipóteses, e não em comportamento real.

Cada nova funcionalidade adiciona mais código, mais regras de negócio, mais testes, mais dependências e mais pontos de manutenção. A complexidade cresce rapidamente, enquanto o aprendizado sobre o usuário continua praticamente o mesmo.

É um paradoxo interessante.

Na tentativa de criar um produto mais completo, acabamos reduzindo nossa capacidade de aprender com quem realmente importa: o usuário.

As empresas que evoluem mais rapidamente costumam seguir uma lógica diferente.

Elas não tentam responder todas as perguntas antes de lançar o produto.

Elas constroem a menor solução capaz de resolver um problema real, observam como as pessoas interagem com ela e utilizam esse aprendizado para decidir qual deve ser o próximo passo.

Essa mudança de perspectiva parece simples, mas altera completamente a forma de construir produtos digitais.

O objetivo deixa de ser lançar um sistema perfeito.

Passa a ser criar um sistema capaz de evoluir continuamente.

E talvez essa seja a maior aplicação da Lei de Gall no desenvolvimento de software: entender que, em vez de tentar acertar tudo na primeira tentativa, devemos criar as condições para aprender rapidamente e evoluir com segurança.

O que as maiores empresas de tecnologia têm em comum?

Quando observamos empresas como Spotify, Netflix, Uber, Airbnb, Stripe, Meta ou Google, é fácil imaginar que elas nasceram com as arquiteturas sofisticadas que conhecemos hoje.

A realidade foi exatamente o oposto.

Nenhuma delas começou operando centenas de microsserviços. Nenhuma possuía uma plataforma de engenharia completa, um Design System maduro ou uma infraestrutura preparada para milhões de usuários desde o primeiro dia.

Essas estruturas surgiram como consequência do crescimento, não como ponto de partida.

O Spotify só criou o Backstage quando sua engenharia atingiu um nível de complexidade que tornava difícil localizar serviços, documentações e responsáveis por cada sistema. A Netflix investiu fortemente em observabilidade porque sua plataforma distribuída exigia uma capacidade cada vez maior de compreender e responder rapidamente a incidentes. O Google desenvolveu o Material Design quando percebeu que precisava unificar a experiência de dezenas de produtos construídos por centenas de equipes.

Em todos esses casos, a arquitetura evoluiu para responder a problemas que já existiam.

Essa talvez seja a principal diferença entre empresas que constroem produtos sustentáveis e aquelas que acumulam complexidade desnecessária.

As primeiras permitem que o produto revele quais desafios realmente precisam ser resolvidos. As segundas tentam antecipar todos os problemas possíveis, criando soluções para cenários que talvez nunca aconteçam.

A Lei de Gall nos lembra justamente disso.

Complexidade faz sentido quando responde a uma necessidade concreta.

Quando é construída apenas por precaução, ela costuma gerar mais custo do que valor.

Talvez o maior aprendizado das Big Techs não seja a tecnologia que utilizam, mas a disciplina de deixar seus sistemas evoluírem no ritmo dos problemas que realmente precisam resolver.

Arquitetura madura não nasce de grandes planos.

Ela nasce de pequenas decisões tomadas continuamente, sempre apoiadas pelo aprendizado adquirido ao longo da evolução do produto.

MVP não significa construir pouco. Significa aprender rápido.

Um dos conceitos mais mal interpretados no desenvolvimento de produtos digitais é o de MVP (Minimum Viable Product).

Com frequência, ele é associado a um produto incompleto, simples demais ou desenvolvido apenas para "colocar algo no ar". Essa interpretação faz com que muitas empresas enxerguem o MVP como uma versão provisória, quando, na realidade, ele representa uma estratégia de aprendizado.

Um bom MVP não é aquele que possui poucas funcionalidades.

É aquele que resolve um problema real com o menor nível possível de complexidade.

Essa diferença muda completamente a forma de construir produtos.

Imagine uma plataforma de gestão financeira. Em vez de começar com controle de despesas, receitas, relatórios, gráficos, integrações bancárias, emissão de notas fiscais e aplicativos para diferentes dispositivos, talvez o maior valor esteja em resolver uma única necessidade de forma excepcional.

Se essa solução realmente fizer sentido para os usuários, o próprio uso do produto mostrará quais funcionalidades devem ser desenvolvidas em seguida.

Cada nova evolução deixa de ser uma aposta.

Passa a ser uma resposta ao comportamento dos usuários.

É exatamente isso que a Lei de Gall propõe.

Em vez de tentar imaginar tudo o que um produto poderá ser no futuro, começamos resolvendo um problema específico e permitimos que o aprendizado adquirido conduza as próximas decisões.

Essa abordagem reduz desperdícios, acelera validações e evita que equipes invistam meses desenvolvendo funcionalidades que talvez nunca gerem valor.

No fim, o objetivo de um MVP nunca foi lançar um produto pequeno.

Foi criar um produto capaz de ensinar qual deve ser o próximo passo.

Porque, em desenvolvimento de software, aprender rapidamente costuma ser muito mais valioso do que tentar acertar tudo na primeira versão.

A Lei de Gall também se aplica à Inteligência Artificial

A popularização da Inteligência Artificial trouxe uma nova onda de inovação para o desenvolvimento de produtos. Ao mesmo tempo, trouxe um comportamento que lembra exatamente os problemas descritos pela Lei de Gall.

É cada vez mais comum encontrar projetos que começam tentando integrar múltiplos modelos de IA, agentes especializados, RAG, memória de longo prazo, automações complexas, integrações com dezenas de ferramentas e fluxos altamente sofisticados.

Tudo isso antes mesmo de validar se a solução realmente resolve um problema importante para o usuário.

Na prática, muitos produtos estão tentando nascer na sua "versão final".

O resultado costuma ser previsível.

Projetos difíceis de manter, caros para evoluir e, muitas vezes, incapazes de demonstrar valor de forma clara.

A abordagem mais eficiente costuma seguir o caminho oposto.

Primeiro, valida-se o problema.

Depois, a solução.

Só então faz sentido aumentar o nível de complexidade da arquitetura.

Esse processo pode começar com um único modelo de linguagem, uma única funcionalidade ou um fluxo bastante simples. Se a proposta realmente gerar valor, novas capacidades poderão ser incorporadas gradualmente, sempre orientadas pelo comportamento dos usuários e pelas necessidades identificadas ao longo da evolução do produto.

A Inteligência Artificial amplia enormemente as possibilidades de construção.

Mas ela não elimina um princípio que continua válido para qualquer tecnologia: complexidade sem necessidade dificilmente gera inovação.

Talvez a maior contribuição da Lei de Gall para esta nova era seja justamente lembrar que o sucesso de um produto não depende da quantidade de tecnologias utilizadas, mas da capacidade de evoluir continuamente a partir de uma base simples, funcional e validada.

Porque a tecnologia muda.

Os princípios que sustentam bons produtos continuam os mesmos.

A verdadeira lição da Lei de Gall

É comum interpretar a Lei de Gall como uma recomendação para "começar pequeno". Depois de refletir sobre sua aplicação em produtos digitais, acredito que sua mensagem seja ainda mais profunda.

Ela nos lembra que não é possível projetar toda a complexidade de um sistema antes de colocá-lo em contato com a realidade.

Por melhor que seja uma equipe, por mais detalhado que seja um planejamento ou por mais avançada que seja a tecnologia utilizada, sempre existirão fatores que só serão descobertos quando pessoas reais começarem a utilizar o produto.

É nesse momento que o software deixa de ser uma ideia e passa a ser uma experiência.

As hipóteses são validadas.

As prioridades mudam.

Algumas funcionalidades se mostram indispensáveis. Outras, cuidadosamente planejadas, simplesmente deixam de fazer sentido.

Em outras palavras, os usuários passam a participar da arquitetura do produto.

Talvez esse seja o maior aprendizado da Lei de Gall.

Ela nos convida a abandonar a ideia de que grandes produtos são resultado de grandes planejamentos.

Na prática, eles costumam ser resultado de um ciclo contínuo de observação, aprendizado e evolução.

Isso exige humildade para reconhecer que a primeira versão dificilmente será a melhor.

Exige disciplina para evitar adicionar complexidade antes da hora.

E exige coragem para evoluir o produto conforme a realidade, mesmo quando ela contradiz as expectativas iniciais.

Quanto mais cedo uma equipe aprende, mais cedo ela toma melhores decisões.

E quanto melhores forem essas decisões, mais naturalmente a arquitetura evoluirá.

Talvez seja por isso que os produtos mais bem-sucedidos não sejam aqueles que nasceram completos.

São aqueles que nunca deixaram de evoluir.

Conclusão

A Lei de Gall foi formulada há mais de cinco décadas, mas continua descrevendo com precisão um dos maiores desafios da engenharia moderna.

Vivemos em uma época em que novas tecnologias surgem em um ritmo acelerado. Inteligência Artificial, computação em nuvem, microsserviços, plataformas distribuídas e inúmeras outras inovações ampliaram nossa capacidade de construir produtos cada vez mais sofisticados.

Ao mesmo tempo, elas também aumentaram a tentação de começar pela complexidade.

Queremos lançar plataformas completas, arquiteturas altamente escaláveis e soluções preparadas para cenários que talvez nunca aconteçam. Esquecemos que nenhum produto nasce conhecendo seus usuários tão bem quanto imagina.

É justamente por isso que a Lei de Gall permanece tão atual.

Ela nos lembra que a evolução não é um sinal de improviso. É parte fundamental da construção de qualquer sistema bem-sucedido.

Os produtos que admiramos hoje não chegaram ao estágio atual porque acertaram tudo desde o primeiro dia. Eles evoluíram continuamente, aprendendo com seus usuários, corrigindo decisões, simplificando processos e adicionando complexidade apenas quando ela passou a fazer sentido.

Talvez essa seja a maior lição para qualquer equipe que desenvolve produtos digitais.

A arquitetura não deve ser construída para impressionar.

Ela deve ser construída para evoluir.

Cada nova funcionalidade, cada nova integração e cada nova tecnologia deveria responder a uma pergunta simples:

Ela resolve um problema real ou apenas aumenta a complexidade do sistema?

Se a resposta for a segunda opção, talvez ainda não seja o momento certo.

No fim, a Lei de Gall não fala apenas sobre software.

Ela fala sobre a forma como aprendemos, inovamos e evoluímos.

Porque grandes produtos não nascem grandes.

Eles começam resolvendo um problema real, aprendem com a realidade e evoluem continuamente até se tornarem aquilo que, um dia, parecerá óbvio.

E talvez essa seja a maior responsabilidade de quem constrói tecnologia: não tentar prever toda a complexidade do futuro, mas criar as condições para que ela evolua de forma sustentável quando o futuro finalmente chegar.

Quer participar do Open Knowledge Lab?

Acreditamos que o conhecimento não pertence às profissões. Ele pertence à humanidade.

As melhores ideias surgem quando diferentes áreas conseguem conversar, compartilhar perspectivas e construir soluções em conjunto. A Inteligência Artificial não deve substituir especialistas; ela deve aproximá-los, tornando o conhecimento mais acessível e conectando pessoas que antes falavam linguagens diferentes.

Mais do que acumular informação, acreditamos que aprender é conectar.

O Open Knowledge Lab nasce com esse propósito: criar uma comunidade aberta para pessoas curiosas, que desejam explorar como tecnologia, ciência, design, negócios, educação e tantas outras áreas podem aprender umas com as outras.

Se ainda não existe um caminho definido para essa ideia, podemos construí-lo juntos.

Participe gratuitamente e ajude a criar essa comunidade:

Quero participar do Open Knowledge Lab