Logo da Amazon contra fundo laranja.

A máquina Amazon


14/12/17 às 12h16

Quando você olha as grandes empresas de manufatura, fica claro que a máquina que faz a máquina é tão importante quanto a própria máquina. Há muito trabalho no iPhone, mas também há muito trabalho na máquina que pode fabricar mais de 200 milhões de iPhone em um ano. Da mesma forma, há um trabalho no Tesla Model 3, mas a Tesla ainda não construiu uma máquina que possa fabricar Model 3 de forma eficiente, confiável, rápida e com qualidade na escala da indústria automobilística.

Mais do que qualquer outra das grandes empresas de plataforma tecnológica, a Amazon é uma máquina que faz a máquina. As pessoas tendem a falar do famoso círculo virtuoso — mais volume, custos menores, preços mais baixos, mais clientes e, portanto, mais volume. No entanto, acho que a estrutura operacional da Amazon — a máquina — é tão importante e, talvez, menos frequentemente debatida.

A Amazon, em essência, é duas plataformas — a plataforma de logística física e a plataforma de comércio eletrônico. Acima disso, há uma descentralização radical. A Amazon é centenas de equipes pequenas, descentralizadas e atomizadas, que se escoram em sistemas internos comuns padronizados. Se a Amazon decidir que vai vender, digamos… sapatos na Alemanha, ela contrata meia dúzia de pessoas com diferentes bagagens, talvez nenhuma delas com experiência em sapatos ou comércio eletrônico, e lhes dá essas plataformas, com transparência interna das métricas de todas as outras equipes e, claro, outras pessoas (e Jeff Bezos) têm transparência interna das suas métricas.

Estas são as famosas “times de duas pizzas”. A vantagem óbvia de uma equipe pequena é que você pode fazer coisas rapidamente dentro da equipe, mas a vantagem estrutural delas, na Amazon (e em tese), pelo menos, é que você pode multiplicá-las. Você pode adicionar novas linhas de produtos sem acrescentar novas estruturas internas ou relatórios diretos, e você pode acrescentá-las sem reuniões, projetos e processos nas plataformas de logística e comércio eletrônico. Você não precisa (em tese!) voar para Seattle e agendar um monte de reuniões para levar as pessoas a implementar suporte para o lançamento de produtos de maquiagem na Itália, ou persuadir qualquer um a colocar mais coisas em seus cronogramas.

Isso significa tanto que os produtos na Amazon são commodities (isso é meio que evidente), mas mais que as categorias de produtos na Amazon são commodities.

Esse modelo tem duas consequências óbvias para a Amazon. A primeira é que ela pode escalar quase indefinidamente — se você pode iniciar x em y sem uma reunião ou uma nova estrutura organizacional, a velocidade de expansão em novas categorias é limitada principalmente pela sua capacidade de contratar e procurar (e, também, pela vontade dos consumidores em comprar uma nova categoria online, é claro). O segundo é que a experiência de compra para qualquer categoria de produto, em última análise, precisa se ajustar a um modelo de denominador comum mais baixo. As equipes da plataforma não conseguem criar facilmente experiências personalizadas para cada nova categoria. Você pode ver isso às vezes como uma fraqueza se você está às voltas com várias categorias. A Amazon pode se ampliar quase que indefinidamente, mas não ser necessariamente profunda — portanto, há questões sobre quais categorias talvez *precisem* de uma experiência mais aprofundada; a mais óbvia, no momento, é a alta moda.

No entanto, há uma terceira consequência: as equipes atomizadas na verdade não precisam trabalhar para a Amazon. Esta é a visão da AWS, que no seu coração oferece a equipes externas acesso total à plataforma de comércio eletrônico, e o marketplace, que faz o mesmo com a plataforma de logística. A AWS já representa 10% da receita da Amazon, e as taxas cobradas aos fornecedores de terceiros usando o marketplace são próximas de 20%. A AWS é muito mais do que o acesso por atacado à tecnologia interna da Amazon, mas o desdobramento direto das capacidades internas é bastante direto no marketplace, que já responde por metade do volume total de mercadorias vendidas pela Amazon.

A Amazon não inclui o total de fundos pagos pelos consumidores para as compras no marketplace em seus relatórios de faturamento e também não divulga o número — em vez disso, ela registra e reporta como receita apenas as taxas de serviço que cobra dos vendedores. As estimativas do valor total dos produtos vendidos tanto pela própria Amazon e pelos vendedores do marketplace (em conjunto, isso é designado como valor bruto do mercado, ou GMV na sigla em inglês) são geralmente sobre a receita reportada da Amazon. Em outras palavras, o marketplace significa que a Amazon lida (mas, incidentalmente, não define os preços) com o dobro da fatia de comércio eletrônico que ela divulga como receita.

Se o limitador ao crescimento do modelo é a rapidez com que você pode contratar equipes de produtos e assinar acordos de fornecedores, deixar outras pessoas fazê-lo por você e cobrando uma margem (e, claro, as equipes internas também têm metas de margens), você pode escalar isso mais rápido e com risco menor.

Enquanto isso, quando a AWS foi lançada, o consenso era de que isso deveria estar queimando dinheiro e que seria outro exemplo da ideia de que a empresa opera comprando participação de mercado empatando ou no prejuízo. Em algum ponto, porém, a AWS tornou-se tão grande que fez com que os reguladores financeiros exigissem da Amazon a separação dos dados financeiros e, nessa, descobrimos que ela era lucrativa — hoje, possui uma margem operacional de 25%. Em seguida, a narrativa se inverteu — o dinheiro da AWS supostamente subsidiava a compra deficitária de participação de mercado em outras partes do negócio.

Na minha opinião, ambas as narrativas foram baseadas em uma premissa falsa. Como eu discuti em detalhes neste post alguns anos atrás (escrito antes da explosão da AWS), essas equipes atomizadas estão em estágios variáveis ​​de desenvolvimento — algumas são grandes e outras, pequenas; algumas antigas e muito lucrativas, algumas novas e perdendo dinheiro como se fossem startups. O lucro líquido e as linhas de FCA que você vê são o agregado de todas essas centenas de equipes, e, portanto, não nos dizem muita coisa — a Amazon investe dinheiro de unidades lucrativas para a criação de novas unidades não lucrativas e você não tem uma noção real de como essa distribuição se parece. Isso, penso eu, é como devemos ver a AWS e o negócio de marketplace: a Amazon é obrigada a divulgar a rentabilidade da AWS, mas ela não é a única parte lucrativa da empresa.

O Amazon Prime se encaixa nisso, aliás, como um terceiro pilar, ao lado da logística e do comércio eletrônico. Cada pedaço de valor percebido que a Amazon consegue agregar ao Prime faz com que seja mais provável que alguém o assine e dá menos argumentos para cancelamentos, e, uma vez que o tenha feito, como um custo irrecuperável, é muito mais provável que ele direcione a outras compras online (e cada vez mais offline). As melhores partes da Prime, do ponto de vista da Amazon, são coisas sem custo marginal, como a TV. A Amazon compra programas de TV para que você compre papel higiênico e sua mudança, ao deixar de comprar papel higiênico no mercado para fazê-lo na Amazon, tem um LTV (valor do tempo de vida do cliente) que dita o orçamento de aquisição de programas de TV.

A Amazon, então, é uma máquina de fazer máquina — é uma máquina para fazer mais Amazon. O extremo oposto talvez seja a Apple, que, em vez da descentralização radical, parece mais um ASIC (circuitos integrados para aplicações bem específicas), com tudo cuidadosamente estruturado e todos em seus compartimentos, o que permite que ela crie certos tipos de novos produtos com enorme eficiência, mas torna muito difícil adicionar novas linhas de produtos indefinidamente. Steve Jobs gostava de dizer “não” a novos projetos — essa não é uma virtude muito relevante para a Amazon.

Para a Amazon e a Apple (e o Google ou o Facebook), isso significa que existem certos tipos de projetos que podem entregar muito de forma repetida e previsível, mas, também, crucialmente, que existem certos tipos de projetos que são muito menos adequados para entregar. O Google não tende a ser melhor em plataformas em nuvem do que a Apple e pior em interfaces de usuário porque há pessoas melhores ou piores em cada equipe, mas porque cada empresa está configurada para fornecer certos tipos de coisas, e quanto mais próximo um projeto está dessa direção da máquina, mais confiável é o resultado. Se a máquina for projetada para fazer X, ela irá lutar contra Y, não importa o quão inteligente as pessoas. Muito da história da Amazon nos últimos 20 anos é de quantos Y acabaram por X — quantas categorias que as pessoas pensavam que não podiam ser vendidas online, nem vendidas como commodities, acabaram sendo ambas.


Publicado originalmente no blog do Benedict Evans em 12 de dezembro de 2017.

Imagem do topo: Canonicalized/Flickr.

Colabore
Assine o Manual

Privacidade online é possível e este blog prova: aqui, você não é monitorado. A cobertura de tecnologia mais crítica do Brasil precisa do seu apoio.

Assine
a partir de R$ 9/mês

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

2 comentários

  1. Muito bom os artigos do Benedict Evans, como sempre. Foi, aliás, através dele que conheci o Manual do Usuário. Explico: há mais ou menos 2 anos atrás eu li um livro do Ben Horowitz (The Hard Thing About Hard Things) e conheci a a16z. De lá, virei assinante da newsletter do Benedict Evans, e certo dia dando um Google atrás de uma notícia dele achei um artigo aqui do MDU (não me lembro qual) de um texto seu traduzido. O que mais me chamou a atenção nisso tudo foi de uma galera criticando pra caramba as opiniões dele, com comentários do tipo “mesmo sendo do Ben Evans, gostei”.

    Aproveitando o assunto, queria entender com a galera daqui: porque essa rejeição ao Benedict Evans? Acompanho bastante o trabalho dele e sempre o acho muito coerente e direto ao ponto, colocando fatos e estatísticas para embasar suas análises e previsões.

    1. Que história legal! Sempre tento trazer bons textos de blogs estrangeiros para o Manual do Usuário, então imagine como fiquei quando o Benedict autorizou traduzir os dele!

      Já levantei esse questionamento em um post livre passado aqui. Aparentemente, o tom que ele usa e algumas posições, principalmente em relação à Apple, parecem incomodar alguns leitores. Há certa rejeição, mas acho que, no geral, a maioria gosta dos textos.