Disrupção está na moda, todo mundo fala de disrupção e toda empresa quer ser disruptiva. Diferentemente da inovação, a disrupção consiste basicamente em criar um novo mercado ou dominar um mercado existente, agregando um valor diferenciado em termos de tecnologia, serviço ou produto. Isso significa que quem detém algum tipo de monopólio poderá ser de uma forma ou de outra, be disrupted, traduzido livremente para o português, “disruptado”.
De acordo com Ray Wang da Constellation Research, nos últimos 15 anos, 52% das empresas da Fortune 500 desapareceram. A disrupção está ocorrendo em todos os setores de forma tão acelerada que a expectativa média de vida destas empresas em 1955 era de 75 anos e hoje é de apenas 15, ou seja, em pouco mais de uma década teremos praticamente todos os tipos de negócios e serviços abalados por alguma solução disruptiva.
Um negócio disruptivo nasce quando a visão encontra a tecnologia, isso acontece desde quando o telefone substituiu o telégrafo e a câmera digital substituiu a analógica, até hoje quando a maioria dos serviços de software que você utiliza está na nuvem.
As grandes corporações estão sempre buscando maneiras de serem disruptivas, seja trabalhando em melhorar o que já existe ou entrando em novos mercados. Acredito que uma das melhores formas de prever o futuro é olhar os padrões do passado, e é justamente neste ponto, “entrando em novos mercados", que a coisa geralmente sai dos trilhos.
Em janeiro deste ano, o investidor Anshu Sharma publicou um artigo falando sobre as falhas de algumas grandes empresas de tecnologia e criou o termo “stack fallacy” que em seguida foi teorizado pelo colunista do Wall Street Journal, Christopher Mims e pelo investidor Steven Sinofsky. Segundo o próprio Anshu Sharma, “stack fallacy” é a crença equivocada de que é trivial construir uma camada acima da sua. Existem várias camadas ou pilhas de tecnologia entre a concepção de uma solução e a sua entrega ao consumidor final.
Dessa forma, a base de dados seria uma camada; o servidor web, outra camada; a distribuição, outra camada; e assim por diante conforme exemplo abaixo.
Portanto, a falácia está justamente no fato de uma empresa supervalorizar o conhecimento da sua pilha de tecnologia e subestimar o esforço e a dificuldade de construir uma solução utilizando uma pilha acima. No âmbito das grandes empresas de tecnologia, é comum o pensamento girar em torno de "mas isso é apenas um app” e essa mentalidade as tem levado a caírem repetidas vezes nessa falácia.
Um grande exemplo é a Oracle, na década de 90, quando vendo o sucesso da SAP construindo um sistema de gestão utilizando-se de sua plataforma, decidiu entrar no mercado de ERP. O desfecho foi, além de perder a SAP como principal cliente - uma vez que ela migrou para DB2 - o novo produto ainda foi inicialmente um desastre, pois era complexo demais e não atendia o que os clientes realmente buscavam.
A Oracle só conseguiu finalmente sucesso no mercado de ERP após as aquisições bilionárias da PeopleSoft e da Sibel. Vários anos depois, novamente a Oracle entrou na stack fallacy ao concluir que a Salesforce era "apenas um app" e investiu milhões na construção de um CRM SaaS e ainda assim não conseguiu bater a Salesforce em software CRM. A história está cheia de exemplos, são empresas de armazenamento entrando no ramo de big data, empresas de infraestrutura construindo aplicativos de mensagens, empresas de sistemas corporativos construindo redes sociais e assim por diante. Eu gosto muito do que o Peter Thiel diz no seu livro Zero a Um, que o Bing é a Microsoft tentando ser o Google e o ChromeOS é o Google tentando ser a Microsoft.
"o problema está no fato de uma empresa supervalorizar o conhecimento da sua pilha e subestimar o esforço e a dificuldade de construir uma solução uma pilha acima"
Um fato interessante sobre a stack fallacy é que, quando aplicada inversamente ou seja, avançando para camadas abaixo do negócio principal, geralmente dá certo. Por exemplo, uma fornecedora de software, que possui sólidos conhecimentos da camada de banco de dados, ao construir uma solução de banco de dados, geralmente é bem sucedida, pois ela compreende e vive as necessidades para a nova solução.
Alguns bons exemplos disso são a Google ao entrar no mercado de cloud computing - pois ela já possuía conhecimento e experiência na construção dos próprios datacenter e servidores, a Amazon criar o AWS, a Tesla ao construir as próprias baterias para seus carros e a SAP ao construir o seu próprio motor de banco de dados em memória.
Mas por que grandes corporações continuam falhando e caindo repetidas vezes na stack fallacy? É da natureza humana supervalorizar o próprio conhecimento e, segundo o próprio Anshu Sharma “o principal gargalo para o sucesso, muitas vezes não é o conhecimento das ferramentas, mas a falta de compreensão das necessidades dos clientes".
Além de concordar totalmente com Anshu, acredito que a recorrência na stack fallacy ocorre porque as grandes empresas de tecnologia estão em uma corrida pela disrupção para apresentar a sua solução para algum “trend topic" do momento (big data, IoT, transformação digital, etc.) enquanto que, na maioria das vezes, esses trends são totalmente incompatíveis com o core business; em seguida porque a complexidade da pilha superior é sempre subestimada e aliada a verbas gigantescas que garantem instantaneamente o ato de “se eu não sei, é só eu contratar quem saiba"; e por fim, talvez o motivo mais batido de todos é que grandes empresas são navios, ou seja, seus movimentos são lentos, experimentar qualquer coisa demora muito e colher os bons resultados - ou prejuízos - também.
Para finalizar, fica a afirmação de Anshu Sharma, “A questão fundamental é e sempre será: quem entende melhor o usuário?".