ProdOps, agilidade e inovação na tecnologia

Sejam bem-vindos a mais um episódio do Mundo da Lua, o podcast fora da caixinha. Aqui vamos abordar os temas de empreendedorismo, inovação, tecnologia e muito mais do mundo dos negócios. Eu sou Armim Unter, idealizador desse projeto junto com esses lunáticos Tiago Scala e Thiago Rosa. Muito bom pra este episódio: mais uma vez, nós temos um convidado — Christiano Milfont, bem-vindo!

Christiano Milfont tem um currículo extenso e invejável: três anos na Accenture, 25 anos de experiência desenhando e criando software, e foi gestor de indústria, governo estadual, imobiliária, varejo e empresas de software. Participou de transformações digitais, é empreendedor, já foi consultor e mentor aplicando agilidade em vários segmentos. Há mais de 20 anos fomenta a comunidade de tecnologia no Brasil, lidando com startups. Conte um pouquinho pra gente sobre a sua jornada de vida.

Bom, pessoal, mais uma vez obrigado pelo convite. Eu sou um cearense morando em São Paulo agora — torço pro Vasco. Descobriram isso nos bastidores e ameaçaram me levar lá no Morumbi pra tentar mudar isso.

Comecei lá atrás como técnico agrícola — fui criado pra ser agrônomo no interior do Ceará, assim como meu pai, os 11 irmãos dele e minha tia, que também foi técnica agrícola. Era uma família grande. Em 1994 eu estava no segundo ano do segundo grau técnico agrícola quando a gente recebeu a visita de uns israelenses com notebook, fazendo um curso pra gente sobre agronomia. Acho que eu era o único da escola que já tinha visto um computador — o único que existia na cidade ficava no Banco do Nordeste, o BNB, um banco federal. Nem lembro direito como era aquele computador; se duvidar era só um terminal burro de mainframe. Mas aquilo chocou todo mundo, porque parecia tecnologia alienígena.

Me matriculei numa cidade vizinha, a 90 km de casa, pra fazer um curso de computação que já estava começando a ser falado. Eu não era tão novo assim — não tinha 12 anos, já estava terminando o segundo grau. Isso foi em 94; terminei o segundo grau em 95, fui estudar em Fortaleza, mas ainda não sabia se ia fazer Ciência da Computação. Entrei na faculdade em 99, quando começou o boom da internet aqui, lá pelos anos 2000.

Não tinha internet nessa época — foi quando começou a banda larga Velox, por volta de 2004, que a gente começou a falar de internet de verdade. Antes disso era uma vaga lembrança, a era dos robóticos, dos modeminhos de 56k. Tem um episódio nostálgico nosso relembrando os 20 anos do início do milênio, falando de inovação e tecnologia e da chegada da banda larga aqui no Brasil.

Foi depois que fui pra faculdade — eu conto a partir dali, 99 — que eu realmente virei profissional da área. E foi muito mais pra aprender: eu já fazia o trabalho que hoje a gente chama de sysadmin, mas naquele tempo, pelo menos lá, não tinha esse nome — era o rapaz da chave de fenda, fazia de tudo. A gente já começava a separar o que era desenvolvedor do que era infraestrutura, e eu queria aprender a programar. Naquela época você tinha que ir pra faculdade pra aprender de verdade, porque não tinha revista nem livro — muito raro, ainda mais no interior; eu já estava em Fortaleza, na capital, mas mesmo assim era difícil.

De lá pra cá fui construindo essa carreira na área de tecnologia. Comecei como engenheiro, fui trabalhar no governo do estado e em vários outros lugares, e comecei a empreender por volta de 2007. A gente montou uma empresa chamada Works, lá no Ceará. Depois eu saí — essa empresa durou até um tempo desses, com meus ex-sócios —, fui fazer outros empreendimentos, investi em startup, enfim. Comecei a empreender cedo, mas mesmo assim era muito difícil: você só empreendia depois de ver o fundo de investimento, e naquela época não existia isso, não tinha fomento, era você por você. Não tinha esse lance do digital de hoje — a gente queria ser o Yahoo.

Não tinha ecossistema de startup, era aprender na raça. Imagina essa primeira empresa que a gente abriu: eram três caras técnicos, com zero inteligência corporativa, sem entender de contabilidade ou finanças. A gente se conheceu na faculdade, ficou amigo e abriu a empresa — começou com três, o nome era Works, dos três, mas depois a empresa chegou a ter quatro, cinco sócios, todo mundo técnico.

Eu lembro quando percebi que a gente estava fazendo algo errado de verdade: foi numa licitação — hoje a gente chamaria de RFP —, numa grande empresa lá no Ceará. A gente tinha um produto bem azeitado pra época, em Java, bem construído, era nosso. Só que a gente tinha zero tato comercial. Faltava justamente isso: o comercial, a venda — que é a coisa mais importante, e a gente não sabia vender. Nessa licitação a gente nem sabia precificar: eu conhecia uma pessoa da empresa que vazou quanto os outros tinham dado de proposta, e a gente, super inocente, resolveu colocar metade do valor só pra entrar. Não fazia ideia de quanto cobrar nem de como precificar o produto.

A gente não estava preocupado com o usuário, como hoje se fala em data-driven, cliente em primeiro lugar — a gente estava preocupado se o produto tinha 100% de cobertura de coisas supertécnicas, que era o que a gente gostava.

Isso tocou num ponto: boa parte desse pessoal que trabalha com tecnologia hoje começou ali no final dos anos 90, começo dos anos 2000, época da bolha do ponto-com — essa galera que estava na faculdade tinha acabado de se formar no técnico, estava todo mundo começando a se engajar, a estruturar sua própria empresa. E em determinado momento faltou muito isso: a capacidade comercial, porque ninguém sabia fazer o comercial. E você mistura isso com uma própria infantilidade de desenvolvimento de produto — era o nascimento da agilidade.

Quando a gente olha pra trás, o Manifesto Ágil — desculpa quem ainda é fã — é uma coisa muito infantil. Foi muito importante naquele período, mas é um retrato do tempo, como olhar um vídeo dos anos 70, calça boca de sino: você vê que é um retrato daquilo. A gente era tudo garoto ainda, idealista, achando que ia mudar o mundo com aquilo — e zero comercial, zero relacionamento. Não existia marketing nessa época, não tinha literatura, não tinha nada. Deu tudo errado, e deu errado essa primeira empresa.

Mas depois eu fui aprender muito trabalhando em outras startups, pra aprender esse traquejo que hoje já tem uma literatura muito forte — o que eu aprendi mesmo foi apanhando, na raça. Invejo muito quem está começando agora, porque já tem toda uma literatura pronta, já tem os playbooks, pra quem já sai pensando em empreender e não segue o caminho que a maior parte das pessoas faz, que é trabalhar pra alguém, ser CLT. Eu também fui — hoje estou no mercado, então já fui pros dois lados do balcão várias vezes. Sofri demais no caminho, e ganhei um bom dinheiro também; não vou cuspir no prato que comi.

Como aprendi na raça, apanhando, a gente demorava muito. Começamos com uma empresa de produto e eu percebi que não entendia nada de contabilidade, misturava finança pessoal com a da empresa. Resolvi sair da sociedade e abrir uma empresa de consultoria — porque eu tinha vindo de uma consultoria, então pelo menos sabia como precificar, fazer a cobrança, montar estratégia, era mais cômodo. Saí da empresa de produto, montei a consultoria, passei uns anos nela e depois voltei pra produto, já com uma certa experiência.

E o que fiz pra adquirir o tino comercial que faltava na primeira empresa: quando abri a consultoria, fui prestar serviço pra outras empresas de produto — e fui aprendendo como essas empresas faziam. Aprendi muito por observação e tive grandes mentores, porque eu observava como elas precificavam, como montavam a equipe de vendas, que é totalmente diferente de consultoria (consultoria é um dinheiro que entra, um caixa a zero). E o que eu aprendi ao longo do tempo: produto é longo, produto é uma jornada de 5 a 7 anos pra dar certo. Pode olhar qualquer unicórnio que deu certo — foi 7, 8 anos; todo mundo acha que foi da noite pro dia.

Há um tema polêmico: a gente, ao longo do tempo, vai se reinventando na forma de fazer as coisas. Sobre a agilidade — ela retardou ou de fato agilizou a construção de produtos digitais? Isso vem de reflexões postadas no LinkedIn, inclusive um post que perguntava se aquele modelo já chegou ao fim.

O movimento ágil começou no início dos anos 90, o Scrum em 95. Quando a gente olha Brasil e mundo — principalmente Estados Unidos, porque os Estados Unidos lideram, a gente sempre olha pro rico —, o Brasil sempre está uns 10 anos atrás; hoje, mesmo com toda a evolução da internet, a gente continua atrás. Quando a agilidade começou, ela estava desbancando uma série de convenções corporativas já existentes, e pra eles foi muito bom, porque surgem os primeiros Google ali em 97, 98 — nascem zerados, com a cabeça limpa digital, muito inspirados por aqueles movimentos que depois a gente chamou de agilidade.

Agilidade não é nada mais do que juntar vários grupos que estão fazendo um trabalho diferente, cada um com seu modelo, pra tentar ver o que dá pra extrair em conjunto. No fim das contas não deu em nada, ficou só o nome, porque cada um continuou fazendo do seu jeito — mas pra eles foi muito bom, mudou. Veja o nascimento do Google, depois o Facebook e os grandes que existem hoje; renovou a Microsoft e uma série de empresas. Pega a IBM: ela patrocinava os dois movimentos, só pra ver qual ia dar certo — tinha o pessoal dos Três Amigos, que foi o pai do RUP, numa linha mais tradicional, e tinha um outro grupo, do qual inclusive alguns foram signatários do Manifesto Ágil, também funcionários da IBM, trabalhando em linhas diferentes. Isso renovou todas essas grandes empresas.

Como o Brasil está muito atrás, essa galera, já por volta de 2006, 2007, já não tinha mais esse apego ao passado — o Facebook, que hoje é a Meta, tem o seu próprio modelo; o Google criou o SRE.

Há um movimento forte quando a gente fala de agilidade a partir dos primeiros cinco anos da virada do milênio, que foi o surgimento do Spotify. O Spotify carregou, no seu histórico de desenvolvimento, aquelas características ágeis — times multidisciplinares — e virou exemplo para diversas empresas. Tanto que, geralmente, quando a gente fala de agilidade, relaciona direto com o modelo Spotify de desenvolver produtos.

A pergunta é se esse modelo ainda vale, ou se é hora de uma virada de chave, de uma forma diferente de desenvolver produto nesta década. Quando você pega o Spotify, já é 2012, 2013 — totalmente diferente do que se falava antes, já era diferente do próprio Manifesto Ágil. E o próprio Spotify abandonou aquilo que a gente chama de modelo Spotify há muito tempo, lá por 2017, 2018 — bem na época em que o Brasil estava começando a adotá-lo, eles já estavam indo para outra coisa. A gente sempre começa muito atrás.

Uma startup leva de 7, 8 anos até engrenar e virar uma unicórnio — quais são as etapas até esse produto vingar, e o que determina o sucesso ou o fracasso nesse caminho? E esse tempo parece estar cada vez mais achatado: será impressão, ou está acontecendo de verdade?

Hoje existe uma literatura grande sobre isso — antigamente era tudo por observação. A empresa tem duas fronteiras: startup e scale-up. Dentro da sobrevivência como startup você tem a incubação, depois a operação — quando ela começa a ter cliente pagando, dinheiro entrando —, e só depois a escala de verdade, antes de virar scale-up. Existe a tração; tem quem quebre isso em operação, tração e depois escala. Hoje já existe literatura completa cobrindo esses três primeiros núcleos antes da escala.

A escala pode ser feita de forma artificial — um fundo coloca um bilhão ali, e não tem como não escalar. O problema é se aquilo sustenta: a gente viu que não é tão fácil, na maior parte dos casos, 80/20, só colocar dinheiro não funcionou, porque foi feito de forma artificial, sem ter criado algo de verdade. Quando falo de cinco a sete anos, são métricas de fundos de mercado que mostram que, pelo menos nos três, quatro primeiros anos, você ainda está formulando o produto — muitas vezes abandona a ideia e parte pra outra, validando hipóteses. E isso não é jogar dinheiro fora.

Na construção de um produto, é preciso sempre refletir em curto, médio e longo prazo. No curto prazo, você tenta prototipar alguma coisa pra entregar valor o mais rápido possível, porque hoje o mundo é muito dinâmico — uma crise na China afeta um porto, e a gente sente o reflexo na operação de todos os mercados do outro lado do globo; tem uma guerra na Rússia com a Ucrânia, e a gente para de fazer importação.

O grande problema é que todo especialista de negócio acha que sabe como criar o produto pro seu próprio negócio, e é por isso que a grande maioria quebra essas métricas. Você não consegue encurtar isso pra um ano, é quase impossível; com menos de 24 meses você nem tem a hipótese macro validada ainda — o segmento que está atacando, o tipo de cliente. Conheço o cenário de uma empresa que chegou a unicórnio em um ano e faliu bem rápido — faliu, faliu, faliu.

Quando você está numa multinacional bilionária, que coloca uma área de desenvolvimento de produto testando quatro, cinco, seis linhas diferentes, validando seis, oito produtos — dois se salvam, cinco, seis são descartados —, você consegue ter resposta rápida porque tem muito investimento. Agora, quando você está pensando com a cabeça do microempreendedor, que tem ali cem mil reais pra pôr no negócio, que é todo o dinheiro que ele tem, é muito mais difícil ter retorno. A gente tem que separar esses dois grupos: quem tem muito dinheiro e já tem cliente, e quem não tem nenhum dos dois.

Pega um varejo pra todo mundo entender — vamos usar o GPA, dono do Pão de Açúcar, como exemplo hipotético, não necessariamente é ele. O GPA quer inovar: o que uma empresa desse tamanho geralmente faz? Monta uma área que ela chama de Lab, já contratando uma grande consultoria que diz: você vai criar dez iniciativas, só uma vai vingar, mas essa vai ter um múltiplo de 20 a 30 vezes, que tira todo o investimento de volta, recupera tudo e ainda mantém você líder da sua área — o primeiro digital do comércio de alimentos, por exemplo. Alimento está sempre atrás porque é difícil: trabalhei na TI do GPA por oito anos, e a gente costumava dizer que é difícil porque a empresa vendia tomate — a margem é pequena, não tem muita gordura pra inovação.

O grande problema do scale-up é que todos os processos dele já são de scale-up: não existe mais hipótese ali dentro, tem que ser tese. Você vai pedir vinte milhões num Business Case — se coloca no lugar de um investidor do GPA, está pedindo vinte milhões que podem simplesmente queimar. O cara prefere comprar de caminhão. Então o que sobra é algum capex, às vezes algum opex mapeado, e você dedica um Lab dizendo: esse Lab é pra inovar internamente, na esperança de que saia um produto dali. Não sai — porque todos os processos da empresa são construídos pra scale-up, só aceitam tese.

O sucesso que eu vejo de verdade é quando a empresa compra uma startup e só vira sócia — não mexe na direção. Porque, quando fracassa, geralmente é porque colocaram os diretores da própria empresa lá dentro; se os diretores soubessem, já teriam feito isso em casa. Fora que os processos daquela empresa comprada não são auditados, não têm as mesmas leis internacionais, a pressão de bolsa de valores etc. — é uma limitada, você é sócio, investiu capital, tem que dar satisfação aos acionistas, mas aquela investida pode falir. Só que geralmente dá certo.

Será que isso é só porque as empresas não sabem qual é o caminho correto de inovação dentro das próprias áreas? Muitas empresas estão criando o Lab, ou o 'cubo', justamente porque estão retirando o compromisso da inovação de dentro do core, do grupo, e gerando esse tipo de iniciativa — uma startup, um cubo, um Lab, que é provavelmente um outro CNPJ.

Mais uma vez, o Brasil está sempre atrasado. O mercado americano profissionalizou o 'startupismo' — os chineses também. O que acontece lá fora: existe hoje a figura de um CEO digital, ou CEO de inovação, que não responde ao CEO tradicional, responde ao conselho. Ele faz um 'shadow' com o CEO, onde ele não interfere nos processos do CEO, e o CEO também não interfere nos processos de inovação dele.

Lá fora já está muito avançado: um fundo investe na empresa — de novo, pegando o GPA só como exemplo — e coloca um shadow no CEO. Você continua tocando as lojas, todo o processo analógico como ele existe hoje, e esse outro cara vai pensar só em como melhorar e inovar. São naturezas realmente diferentes, tempos diferentes — abre um novo CNPJ, que não tem as obrigações que a empresa original tem.

A Amazon compra muitas cadeias e nem sempre é reconhecida por fazer isso bem — porque a natureza é diferente, ela estraga algumas cadeias justamente porque compra e quer colocar o modo de pensar digital dela dentro da cadeia, e isso não funciona. Por que trazer essa reflexão: a gente discute muito como trazer transformação digital, e como manter essa transformação viva — é um ritual, um evento, as áreas precisam fomentar isso, deveria existir uma área responsável, sem podar as pessoas de dar ideias inovadoras dentro das empresas, trazendo também coisas de fora pra fomentar o negócio.

Será que precisa existir uma área que seja o carro-chefe da empresa pra fazer isso acontecer? Acredito que não — área, não. O que eu tenho visto de sucesso é olhar como as empresas que hoje a gente chama de FANG — que agora virou MANGA, porque o Meta mudou de nome — deixaram de ser startups fazendo o que fizeram ao longo do tempo: trouxeram executivos tradicionais do mercado pra dar mais profissionalismo ao formato que tinham.

Pega uma empresa recente chamada HashiCorp, dona das ferramentas queridinhas do mundo dev — Vault, Consul, Terraform. O fundador, que era CEO, trouxe um CEO profissional do mercado pra sentar na cadeira dele. Que maturidade o cara teve: ele levou a empresa até a bolsa de valores, capital aberto, e aí olhou pros tubarões grandes — você tem que lidar com banco, com contábil, com nível de investigação — e percebeu que ele era um cara de criatividade, de inovação, não de gestão. Ele criou o Terraform, não precisava mais daquilo. Contratou um CEO pra sentar na cadeira dele e voltou pra engenharia: 'eu sou dono disso aqui, não preciso mais desse ego.' Trouxe um desses tubarões de mercado pra dar o profissionalismo que a empresa precisava.

O que eu vejo de sucesso, pegando de novo o pobre GPA como exemplo: em vez de trazer pessoas inovadoras pra dentro do GPA, pra dentro das áreas — onde elas vão ser mortas de burocracia —, é muito melhor pegar os executivos e trabalhar num spin-off que a empresa compra, ou vira sócia.

Já vi situações em que uma empresa compra várias empresas menores, tenta agregar tudo dentro do seu fluxo interno, e mata as empresas — transforma a empresa nova num departamento, numa unidade de negócio dentro do fluxo operacional que já existia. Um exemplo: a empresa tem o core dela de vendas e compra uma empresa de tecnologia pra prestar outro tipo de serviço; na hora que coloca ela dentro do fluxo operacional, dentro do fluxo de vendas, mata a empresa. As pessoas vão embora — porque eram de uma startup, estavam habituadas a outra forma de trabalho, e quando entram numa multinacional começam a sofrer a pressão, muda a cultura, e você começa a perder pessoas.

O principal ativo de uma empresa de serviço é a expertise, é como ela transforma o que pensa num produto — e as pessoas são o capital ativo desse tipo de empresa. Você começa a perder pessoas, e naturalmente aquela empresa que foi agregada morre.

Sobre a HashiCorp: sabe quem comprou a HashiCorp? Faz umas duas, três semanas que anunciaram a venda, o que significa que já estava um ano de negociação. Foi a IBM. Ninguém está olhando pra IBM, mas foi ela que, há uns 6, 7 anos, comprou a Red Hat — uma das maiores empresas open source do mundo, construindo produto em cima do Kubernetes, tecnologia de gestão de cloud —, e a Red Hat é independente até hoje. Agora comprou a HashiCorp; nos últimos cinco anos, mais ou menos, comprou várias outras empresas. A IBM vai ser a dona de um ecossistema de cloud sem que ninguém perceba, e mantém a independência de cada uma.

A IBM está visionária: o mundo devops fala de Ansible — a Red Hat comprou o Ansible lá por 2015. Numa timeline, dá pra ver a movimentação: a AWS entrou em cloud em 2006, o GCP mais ou menos em 2008, a IBM só em 2011, bem depois. Só que ela não tenta competir direto com esses caras, que são muito rápidos — ela olha o que está bombando no mundo, quem está fazendo melhor. Falou de Kubernetes: quem está fazendo melhor é a Red Hat, com o OpenShift. Compra a empresa e não mexe nela, deixa fazer o que já faz bem — e assim vai virando um monopólio sem que ninguém perceba. É uma empresa centenária: fortalece as fraquezas comprando quem já tem a competência que falta, olha pras tendências e vai lá comprar o time, sem avacalhar com ele — deixa funcionando do jeito que já funciona bem.

A Microsoft vem fazendo um movimento parecido, mas integrado. Ela também entrou atrasada em cloud, começou a comprar alguns ativos, mas pensa nela como um b2b corporativo que te dá o Office, o Windows. A Microsoft entrou depois só que integrou tão bem — o Office junto com o Azure, junto com as ferramentas — que chega a te vender um pacote sem concorrente, uma assinatura integrada; pega o seu ambiente on-premise e diz: se você renovar as licenças, consome tudo em cloud. Um modelo comercial interessante: 'eu vou ganhar cloud de graça, então continuo aqui, faço a transição com calma.'

Depois ela pluga o LinkedIn — que ela comprou —, integrado com o Office, com o RH. Compra o GitHub, investe no VS Code, no Copilot. Hoje um desenvolvedor, mesmo usando Mac, olha pras ferramentas de tecnologia e é tudo Microsoft: VS Code conectado no GitHub. Essas empresas vão entendendo: quando a Microsoft comprou o GitHub, ele continuou totalmente independente, do mesmo jeito que a empresa já funcionava. Quando você compra pra agregar, pra colocar dentro, mata tudo — mata a cultura da outra empresa. É preciso trazer o que funciona do outro lado.

Muitas dessas compras são só pra pegar aquele market share — a empresa não está preocupada com o produto, só não quer um concorrente (é a lógica por trás da compra do Guaraná Jesus: comprar pra tirar de circulação). Mas se você está comprando porque quer agregar aquela expertise, tem que deixar independente — é uma estratégia de ecossistema. Tem empresa que cria essa plataforma de geração de valor, com cada peça independente mas bem integrada — é o famoso efeito porco-espinho: o concorrente tenta te atacar, mas você tem um ecossistema inteiro e ninguém consegue.

As clouds perceberam isso: a AWS, principalmente, está com uma estratégia muito forte, olhando pro inventário que até dois, três anos atrás era 70% cloud, só 30% ainda on-premise; agora empatou, o on-premise passou um pouquinho, mas ainda é um mercado gigante — hoje é mais ou menos 50% on-premise, ou seja, data center, mainframe pra migrar. Existe agora um movimento muito forte de migração, e a AWS está investindo muito nisso.

No longo prazo, quando você bota muita coisa na nuvem — independente de qual delas — começa a ficar muito mais caro, principalmente na questão de armazenamento, e tem cada vez mais empresa falando em voltar pra dentro.

Na verdade é no curto prazo que o problema aparece. Quando você vai migrar, tem várias estratégias — a mais fácil é o velho lift and shift mais grosseiro, que pega e joga de qualquer jeito. Quando você tem um data center, ele não tem escalabilidade: você compra a máquina, ela ocupa tudo e para. Em cloud não, é 'infinito' — e aí, como você não tem uma boa gestão, faz essa migração de qualquer jeito. Hoje está bastante comum o termo FinOps, crescendo bastante, todas as empresas já estão com área de FinOps, porque é desgovernado, é fácil gastar.

Você tem uma conta que cresce infinitamente, entre aspas, e quanto mais cresce, mais caro fica — não é progressivo o formato. Como você pode crescer pra qualquer lado, é muito fácil fazer besteira e queimar um orçamento rápido, o que o data center nem permite, porque a limitação ali é física.

As empresas que estão voltando pro próprio parque geralmente começaram esse movimento há dez, quinze anos, e hoje têm um parque caro, mas sabem exatamente quanto gastariam — e estão certas, entre aspas, nesse sentido. Pega a empresa do criador do Rails, por exemplo, a Basecamp: ele tem algumas empresas voltando pro data center. Mas é porque o produto tem mais de vinte anos, é estável, não avança tanto quanto avançava antes, não é tão dinâmico, tem uma previsibilidade muito alta — aí ele fez um post dizendo que cloud é cara. É por causa da natureza do caso dele; ele não precisa mais daquilo.

Vamos tentar explicar ProdOps 'num tweet': existe esse mundo do nativo digital, o FANG, empresas que nasceram sem qualquer amarra com legado — não tinha lógica antiga, nada. Criando um negócio totalmente digital, sem precisar se amarrar ao modelo de administração clássico, fazendo do jeito que quiser, influenciado pelos movimentos de agilidade. São empresas que nasceram diferentes.

Essas empresas ajudaram a criar o modelo de produto digital — a literatura dos últimos vinte anos foi criada com base nesses cases: um pouco de empírico que vira literatura, essa literatura retroalimenta as outras empresas, que vão copiando, e aquilo vai se espalhando. Só que é uma literatura de nativo digital, escrita para nativos digitais.

Vou usar o GPA de novo: pega uma empresa de sessenta anos, tipo o antigo Pão de Açúcar — ela tem sua essência, sua forma de trabalhar, vem do mundo físico. Vou chamar de cultura analógica, sem demérito no termo — é um bicho diferente, que nasceu numa era diferente, num formato diferente, pra um segmento que entrega diferente. Passou por fax e BlackBerry — isso já é analógico. Empresas que nasceram antes da virada do milênio viveram isso, e poucas se transformaram bem, como a Microsoft e a IBM, que foram ganhando a essência dessa nova era aos poucos.

Essas empresas precisam entender que existe uma tradução pro mundo delas — não dá pra pegar a literatura de produto digital e querer ser o Netflix; não vai funcionar, pelo menos não pelo modelo. Pega o Netflix como exemplo: até o ano passado — esse ano eles mudaram um pouco a estrutura, inventaram o tal do co-CEO — era um CEO, um VP de Produto que respondia a ele, e um VP de Engenharia. Os três com base em engenharia de software, os três especialistas em produto, formados fazendo isso dentro da própria profissão.

Corta a cena pras nossas empresas analógicas: você tem um engenheiro, um economista, um administrador clássico — é outra pegada, outro linguajar, outra abordagem. Uma empresa dessas não precisa dizer 'aqui todo mundo é Product Manager, do VP ao CEO' — não é só colocar as pessoas de produto. Você precisa ter essa cultura, essa forma de pensar como empacotar os serviços dentro de uma fronteira, pra evoluir como um produto, com versionamento.

Há alguns anos perceberam que é bem difícil criar uma cultura de produto, porque você está mexendo com a cultura, com a essência das pessoas. Começaram a falar: 'precisamos de uma operação aqui pra agilizar isso.' Foi aí que comecei a ouvir falar de ProdOps, em 2018 — é algo bem recente. Em 2019 fui trabalhar num grande varejista como gestor de produto — não só produto, minha cadeira era inovação e produtos digitais —, mas no fim das contas eu precisava ser um diretor de engenharia; era a necessidade do dia a dia. E aí percebi: preciso desse tal de ProdOps aqui, não tem cultura de produto — a tecnologia serve pra apoiar as pessoas fazendo o negócio.

Comecei a perceber a diferença pro Netflix: lá todo mundo constrói pras pessoas apoiarem o software. O Netflix é uma máquina onde você tem grandes especialistas em marketing, publicidade, que entendem como o produto funciona, e trabalham pra fazer o produto entregar valor — foco no produto, não em fazer o serviço chegar no cliente.

Parece que aquela camada que a gente chamava de Waterfall, ou cascata, de desenvolvimento de software, evoluiu para um modelo mais ágil, mas a área que sustentava, que operava, não evoluiu tanto — demorou um pouco pra acompanhar. Houve uma desconexão entre essas duas camadas: eu entregava mais rápido, tinha uma forma diferente de fazer o desenvolvimento, mas a minha área de operação, de sustentação, ficou um pouco atrasada. Isso aconteceu, e ainda acontece.

Existe esse mundo data-driven, de validação de hipótese, e existe esse mundo de projeto e sustentação — o ProdOps é o que cola esses dois. Não dá pra sair de uma cultura de projeto e sustentação — onde você define o capex do ano de um jeito — pra um modelo de validação de hipótese onde você só tem tese, porque tem que fazer um Business Case detalhado, injetando o capex, batendo com a contabilidade. No modelo em que as pessoas estão pensando em como fazer um produto entregar o serviço, a forma de montar esse Business Case é diferente — continuam controladas por capex, a contabilidade não mudou, mas o detalhe que aprendi com empresas digitais e consegui aplicar numa empresa de mentalidade analógica foi essa forma de olhar pro projeto: o projeto entrega um asset pra área de negócio operar o serviço dela.

Um exemplo bem simples: cloud sempre foi opex, você paga no opex. No digital, hoje, com FinOps, depende — se você está construindo o artefato pro produto, isso é capex, é uma licença. Faço uma analogia com a contabilidade tradicional: quando você está fazendo uma obra pra montar uma loja, o gerador que foi alugado pros caras trabalharem e erguer a planta é opex, mas a obra em si é capex. É que eu estou construindo, estou levantando os muros; quando ele entra em produção é que vira opex — e não existe mais 'projeto de sustentação' separado, porque hoje é sempre iterativo, incremental.

As áreas contábeis tradicionais não tinham nem a expertise pra fazer essa tradução, porque a vida delas toda foi montar projeto — que já nascia capex. Na estrutura atual, na cloud, já nasce opex. E essa é a dor de cabeça dos executivos hoje: você tem que avaliar um VPL pra fazer uma implantação, mas já precisa saber qual vai ser o ROI antes de colocar no ar — às vezes a solução é justamente tirar uma maquinaria antiga que está lá. Isso só vai ser avaliado, só vai ser comprovado a partir do momento que você faz o deploy e entende se a tese foi bem aceita, se a operabilidade está correta, se a sustentação vai funcionar até você desligar a chave. Tem muita cloud aí que ainda não foi desligada — coisa antiga —, ou até servidores on-premise mantidos justamente pra validar a tese, o que vai criando vários projetos simultâneos, paralelos. E todo ano vem aquele plano de ação: vamos ter que diminuir tudo que a gente tem de opex, o que dá pra melhorar no ROI.

Um fator interessante: quando comecei com ProdOps, estava numa empresa em transformação nesse modelo, e imaginei que empresa nativa digital não precisaria disso — que era uma coisa pra empresa que queria chegar lá. Só que comecei a observar que todas as empresas nativas digitais do Brasil também montaram área de ProdOps — e pensei: tem alguma coisa errada aí. Porque eu imaginava que, ganhando os skills digitais, ia chegar um momento em que não precisaria mais dessa área, porque a minha tecnologia, a minha TI, já ia ter times multidisciplinares — a pessoa de negócio, marketing, tecnologia e produto trabalhando no mesmo squad, sem precisar de ProdOps.

Percebi que, se o nativo digital também está montando ProdOps, tem uma consequência: toda empresa que cresce demais vira scale-up. E, virando scale-up, você tem uma complexidade interna muito grande, um ruído muito grande, as agendas começam a divergir — e mesmo tendo nascido digital você começa a ter silos, áreas que são governadas separadamente, porque você cresceu, e cresceu muito. Naturalmente toda empresa que vira scale-up vai perdendo a capacidade de ter um time focado em volta de um produto pra construir e entregar esse produto. Hoje, internamente, Meta, Netflix e companhia — mesmo não na mesma proporção de uma analógica — têm as mesmas dores de muito ruído, de não conseguir manter um roadmap unificado. E é aí que entra o ProdOps.

Porque, numa startup pequena, todo mundo tem a mesma agenda — o roadmap é único. Quando você cresce, o roadmap naturalmente é afetado por dependências não mapeadas, por ações manuais que causam atrasos, por interesses de área, interesses de carreira também.

Na lata, pro executivo que está assistindo agora: qual é o principal benefício que o ProdOps traz pra mesa de quem está operando o produto? Na vertente em que eu trabalho, ele ataca dois grandes problemas: a agilidade na entrega — a entrega do produto na mão do cliente. E não estou falando de Scrum aqui; o Scrum nasceu pra isso também, há mais de vinte anos, e até hoje a gente não resolve isso em grandes empresas, porque naturalmente a grande empresa tem muito ruído. O ProdOps vem pra agilizar a entrega fazendo um roadmap integrado, com alinhamento entre TI e negócio.

Esse muito ruído acontece porque não sabem priorizar, ou porque não sabem pedir? Nenhuma das duas coisas — são interesses. Faço até uma analogia com a série Loki: são universos nascendo, são multiversos, ramificações, e você precisa de uma área que tente manter o único nível — como a TVA na série, que não deixa essas ramificações acontecerem.

O que acontece: quando somos só nós quatro trabalhando juntos, eu sei sua agenda, você sabe a minha. Na hora que cada um tem sua própria área, com mais dez cabeças, com interesses de carreira e objetivos diferentes, eu já não sei a agenda das pessoas que trabalham com você — alinho com você, mas quando desdobra pro seu time, são muitos interesses diferentes. É por isso que existe CEO, CTO, presidente — mesmo assim são pessoas. Uma empresa é composta de CPFs, e cada CPF tem seu próprio interesse.

Então isso não é falta de saber priorizar? Não é — todo mundo sabe priorizar, só que cada um prioriza uma coisa diferente. E é por isso que, se você simplesmente decide 'vou colocar OKR na minha empresa', provavelmente vai prejudicar sua própria empresa.

O problema é o seguinte: você faz a gestão da sua empresa com um Business Case clássico, e vai simplesmente abandonar isso e colocar OKR no lugar? Se a cabeça da turma não mudou, não vai acontecer nada — você vai matar a empresa. É sempre cultura. O OKR foi extraído da forma como o Google trabalhava naquele momento, naquele formato de gestão — quando você extrai um playbook assim, tem que olhar como a sua empresa funciona e como fazer a ponte.

O que era inspiracional no Google — porque o Google era inspiracional, não é meta — é que no OKR você não coloca uma meta, você dobra o objetivo, o famoso 'grow'. Isso é muito bom, porque, quando você faz o somatório dos resultados, atinge duas, três vezes mais do que a meta inicial que teria se proposto. Mas você tenta traduzir isso pra um modelo clássico e não funciona, porque o seu vendedor está ali estrangulado numa cultura de meta, com todas as malandragens: o cara não passa esse pedido porque já bateu a meta do mês, deixa pro próximo. Já existe toda uma cultura ali, e até você reeducar essa turma sobre como funciona, você já perdeu a meta.

Então qual é o futuro do ProdOps? Adoção. Praticamente todos os nativos digitais do Brasil já montaram sua área de ProdOps — e estão errando, porque ProdOps é muito novo, não existe ainda o 'Scrum do ProdOps'. É um termo que agora as primeiras literaturas estão colocando na rua, ainda não tem consenso. Todo mundo que fala de ProdOps está com a essência igual — o discurso é parecido com o do Manifesto Ágil no início —, só que agora é a hora de partir pra ação.

E o problema de partir pra ação é que o ProdOps não pode fazer a gestão de produto — ele tem que ser a ponte. De um lado você tem o Product-Led, com toda a cultura de como se faz esse produto; do outro, o tradicional, que naturalmente acaba indo pro modelo Waterfall, o modelo cheio de ruído, onde você quer colocar ordem montando um Excel, uma planilha, controlando traço a traço. É natural que o ser humano vá pro modelo cascata de microgerenciamento quando está descontrolado.

O ProdOps é manter essa essência de startup — todo mundo trabalhando na mesma meta, no mesmo objetivo final — sem fazer a gestão do produto em si; é completar o que falta. Como não existe o Scrum do ProdOps, cada empresa que montou sua área está fazendo o seu próprio ProdOps — o que tem seu lado bom, mas também o lado péssimo, que é ficar uma coisa abstrata: você sabe o que está sofrendo, sabe o que precisa, mas está inventando, não está aprendendo com os outros, não está vendo as experiências alheias.

Por isso tenho trabalhado nessa vertente pra, primeiro, trazer as experiências — o que já aconteceu até hoje, contar a história — e colocar um playbook mínimo, complementar: de um lado o Product-Led, que prega data-driven, validação frequente de hipótese; do outro, o modelo tradicional, Business Case com pesquisa de mercado e opinião de especialistas, tese montada pra atingir o ROI. O ProdOps fica no meio: nem totalmente data-driven, nem totalmente inflexível. Tenho trabalhado numa série de técnicas e modelos, um framework, pros dois lados, tentando levar um pro outro — levando uma empresa analógica de origem a se tornar uma empresa digital, permitindo uma evolução digital. Prefiro chamar de evolução, não de transformação.

Já fiz muita transformação no passado e, olhando pra trás com o olhar de hoje, fiz tudo errado: querer transformar o GPA — de novo, coitado — em Netflix não vai funcionar, porque nem a Amazon conseguiu fazer isso. Não posso ser pretensioso a ponto de achar que teria esse poder se a Amazon não conseguiu. E olha que interessante: a Amazon está no Brasil desde 2010, 2011, e vai devagar, porque o Brasil é um bicho diferente dos Estados Unidos — ela não mata. Lembro quando a Amazon chegou aqui, todo mundo dizia que ela ia matar as Americanas; as Americanas morreram sozinhas depois. Isso acontece com um monte de empresa que vem de fora querendo implantar uma metodologia sem aprender o Brasil primeiro — e olha que já tem quase 15 anos aqui.

Quem tiver interesse em conhecer mais sobre ProdOps, o Christiano ministra um treinamento sobre o tema. Pra fechar, uma mensagem, um conselho pros empreendedores do Brasil que estão querendo se arriscar — pra quem já teve empresa, já iniciou projetos: o que você deixaria de mensagem pra essa galera?

Principalmente pra quem vai começar pequeno, montar a primeira startup: uma coisa que eu demorei muito, errei muito, é separar o que é inovação do que é invenção. A gente quer inventar. A partir disso, o ProdOps pode ajudar bastante — seja na invenção, seja na inovação. Inovação é fazer o que já existe de uma forma diferente.

Quando você olha pro QuintoAndar — pergunto isso no treinamento, qual é o principal concorrente do QuintoAndar, e vocês já sabem a resposta, vou ficar quieto —, todo mundo acha que são as imobiliárias, mas elas são parceiras de segmento; tanto que o QuintoAndar tem contrato, parceria com imobiliária. Se tivesse alguém com visão inovadora dentro de uma Porto Seguro, de uma SulAmérica, por exemplo, teria enxergado o que o QuintoAndar realmente resolve: não é o aluguel, é a facilidade financeira.

Quem já alugou antes sabe — eu moro de aluguel em São Paulo, tem a ver com isso: precisava pedir pro meu pai ser avalista, era um inferno de cartório, o famoso fiador. Era um inferno.

Eu trabalhei numa imobiliária grande no Nordeste há muito tempo, e a gente já pensava em como resolver isso — só que existe uma legislação muito forte em cima: qualquer contrato que você rescinde, leva uma multa grande, e a margem não é tão alta no setor porque tem muito prejuízo — quem sai, você tem que reformar tudo.

O que eles resolveram: olharam pro problema principal, que era a burocracia. 'Eu vou resolver a burocracia' — você entra no site, escolhe, assina o negócio ali, e eles inventaram um negócio sensacional. Seu nome está no SPC? Eles inventaram o 'inquilino amigo', pra não chamar de fiador e não cair na lei — na verdade, é como se as duas pessoas tivessem alugado juntas, só que quem paga é você mesmo; o outro é só o facilitador.

Isso é típico de quem tem o pensamento digital de resolver um problema, uma dor real. A Globo, esperta, foi lá e virou sócia — assim como virou sócia do QuintoAndar, da Petlove e de várias outras empresas. Foi a mesma coisa com o Uber: ele não era concorrente dos taxistas, entenderam errado. E o Airbnb, pior ainda: não é concorrente dos hotéis — que até gostaram, porque as estatísticas depois mostraram que aumentou a hospedagem em geral, por causa do Airbnb, que facilitou e fez as pessoas se acostumarem a viajar mais. Aumentou, enriqueceu o setor.

Antes do Uber era difícil parar um táxi na rua, pedir táxi — hoje se tornou muito comum, e até o taxista independente hoje usa o app pra ser chamado, pega o que vier na frente. Antes do Uber a galera ia de ônibus, metrô ou carro próprio — fomentou muito o setor. A gente não entende o movimento de cara; só depois que ele se consolida é que todo mundo vê o benefício: não era meu concorrente, pelo contrário, melhorou aquilo que a gente já fazia. Ele não inventou, só fez a mesma coisa de uma forma diferente.

Pra quem vai empreender agora: eu errava muito, eu queria inventar. Não é inventar — é fazer a mesma coisa de uma forma diferente.

Quais recursos, ferramentas, livros, comunidades você indicaria pra quem quer se aprofundar no tema? Hoje o tema é muito novo — no Brasil já existe uma comunidade de Product Operations, ainda bem pequena, porque o assunto é recente, mas lá fora já está explodindo. Estão saindo os primeiros livros — cito Marty Cagan e Melissa Perri, pessoas que já eram de produto e estão se aventurando em produto digital.

E principalmente o meu canal — procurem no YouTube por ProdOps, nome bem simples que escolhi justamente pra não errar. Tento trazer não só conteúdo sobre ProdOps, mas o que está em volta também, engenharia e produto. E vocês estão convidados a gravar comigo lá — é só combinar hora e local.

Pra você que acompanhou até aqui: essa foi a conversa com Christiano Milfont sobre inovação, empreendedorismo e tecnologia. Muito obrigado por ter vindo participar desse episódio com a gente. E, pra fechar, um convite em aberto: pode me chamar quantas vezes quiserem, estou sempre aqui — deu vontade de falar um pouco mais sobre alguns temas, acho que vale uma segunda rodada em algum momento.