Eu já tinha cortado o Scrum Master. Já tinha cortado front e back separados anos antes da IA existir. Agora cortei o product owner — e não é porque o trabalho dele sumiu, é porque quem manda no produto é o cliente que paga, e a parte pesada da pesquisa hoje chega mastigada.
Resposta rápida: eu não contrataria hoje um PO — uma pessoa dedicada a definir o produto, fazer a interlocução com os departamentos e entregar a definição pronta pra equipe de desenvolvimento. O trabalho não desapareceu: o que desapareceu foi o custo de carregar informação de um lado pro outro. Pesquisa de mercado, o que o concorrente faz, ajuste de produto, margem e pesquisa de interface com foco em experiência do usuário — tudo isso, com uma IA bem estruturada, com as skills e as tools certas, chega na mesa mastigado. O dono do produto de verdade é o cliente que paga a assinatura, e a demanda dele entra pela equipe de suporte. O que sobra pro desenvolvedor é ser dono do produto no aspecto técnico, multidisciplinar, falando direto com quem está no cliente. E a medida muda de "a squad gerou valor" pra uma pergunta que paga conta: a feature que ele entregou gerou dinheiro na ponta? O que não sai de cena é o feeling do dono do negócio e o peso extra que cai em atendimento, venda e suporte.
Gravei esses 13 minutos no canal @josimarjmv em 26 de setembro de 2026, reto, sem corte e sem teleprompter, do jeito que eu gravo. Assista e leia junto: aqui embaixo eu fui atrás da letra do Scrum Guide pra mostrar o que o papel de PO é no papel — e achei um detalhe que ajuda o meu argumento mais do que eu esperava.
🎧 PREFERE OUVIR? · 13 min
Este artigo também é um episódio do podcast Josimar JMV | Em Produção — o mesmo vídeo, só o áudio, normalizado pra fone.
Vou dar a minha carteirada antes de falar mal de papel de ninguém, porque esse assunto virou terreno de palpite de quem nunca montou equipe. Eu tenho empresa de tecnologia e cuido desses setores há anos. Eu contrato, eu pago a conta, eu gravo o vídeo nessa câmera sem corte e ainda boto a mão na massa: cuido e gerencio infraestrutura pesada, data center próprio, milhões de views todos os dias no Brasil e nos Estados Unidos.
E tem um detalhe que muda tudo na hora de decidir cargo: a minha empresa não recebeu aporte financeiro. Meu dinheiro é contado. Eu tenho dó de dinheiro — e quando eu digo isso, é no sentido de dinheiro mal investido, não de não gastar. Quem vive de aporte pode contratar uma camada inteira pra descobrir depois se ela era necessária. Aqui não: se eu abro uma vaga que não gera dinheiro, a conta do quinto dia útil não fecha.
A gente fez um teste com Scrum aqui dentro, e foi uma experiência não muito boa pra gente. Eu já contei essa parte em detalhe quando escrevi que larguei a sprint e story point não faz sentido com IA. Este texto é o capítulo seguinte da mesma decisão: depois do Scrum Master, o PO.
Relembrando o desenho que a gente tinha, que é o desenho que a maioria das empresas ainda tem: Scrum Master, PO, e ali dentro o tech lead e a squad. Dentro da squad, um cara de infra, um DevOps, um de back, um de front, talvez um de mobile. Dependendo da complexidade, dois de back, um de front e um de mobile — porque um botão no front pode gastar um mês pra fazer no back. E a função daquele botão vinha do PO.
Esse fatiamento fazia sentido, e eu não vou reescrever a história dizendo que sempre foi bobagem. Ele fazia sentido porque, com equipe grande de desenvolvimento, colocar na cabeça de um desenvolvedor o que é um produto e como ele tem que funcionar é um negócio difícil. O desenvolvedor sempre foi um cara meio estrelinha: "eu só quero ser front", "eu só sou back", isso ou aquilo. É até um dos motivos de ser uma classe que a gente sempre considerou difícil de lidar. São todos assim? Não, não são todos. Mas o traço existe, e quem contrata sabe do que eu estou falando — vou gravar um vídeo só sobre isso.
Só que o PO, na prática, criava muito atrito — igual o Scrum Master — e sugava tempo e energia da equipe. E sugava porque o trabalho dele é grande de verdade: conversar, vistoriar cliente, suporte, chamado, ver como está funcionando, pesquisar mercado, conversar com a equipe de desenvolvimento, conversar com o dono da empresa, com o financeiro. Fazer a organização disso tudo pra botar na frente do desenvolvimento o que vai fazer, como vai fazer e quando vai fazer.
Apuração minha, feita em 27/09/2026, porque na gravação eu falei de cabeça e aqui eu quero te dar a letra. O Scrum Guide, na versão de novembro de 2020, define o time em três responsabilidades: "the Developers, the Product Owner, and the Scrum Master", e diz que o time é "typically 10 or fewer people". Sobre o PO, a frase é esta: "The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team". E ainda: "The Product Owner is one person, not a committee".
Agora o detalhe que me interessa, e que está escrito lá, preto no branco: "The Product Owner may do the above work or may delegate the responsibility to others" — e mesmo assim segue responsável ("Regardless, the Product Owner remains accountable"). Ou seja: o próprio guia admite que o trabalho pode ser delegado; o que não se delega é a responsabilidade.
Isso encaixa exatamente no que eu faço hoje. Eu não aboli a responsabilidade pelo produto — ela ficou comigo e com quem está no cliente. O que eu deixei de pagar é a execução do garimpo, que era o que consumia o dia do PO. Quando o guia diz "pode delegar", ele não imaginava que o "outros" seria uma IA com skill e tool — mas é aí que a gente está.
Na era da inteligência artificial, uma IA tipo Claude Code bem estruturada, bem tunada, com as skills e as tools corretas, faz o seguinte: você levanta uma grande pesquisa de mercado, traz o que todos os concorrentes fazem, ajusta o seu produto dentro disso, melhora performance e melhora margem. Manda uma busca profunda, refina, compara, e você lê. Isso chega pra gente muito mastigado. Depois eu faço uma nova pesquisa de UI, lembrando que pesquisa de UI tem que ser com foco na UX — a experiência do usuário. Também tem skill e tool pra isso.
Então eu tenho, na mesa: parte financeira, concorrência, e layout de como aquilo deve ficar. E na ponta eu tenho o cliente — que, na minha opinião, é o dono do produto de verdade. No meu caso, que eu sou SaaS, é o meu cliente que paga R$ 100 por mês, R$ 200, R$ 10.000: tanto faz o valor. O que importa é que o meu produto é feito pra atender a necessidade dele. Então quando a demanda dele chega na minha equipe de suporte, aquilo ali é o que mais importa. Esse é o grupo do product owner pra mim.
Na prática vira um fluxo curto: o cliente falou, pediu, sugeriu, criticou. Você está no suporte, já tem equipe de suporte no seu negócio, já está maiorzinho. Você filtra: "ó, o cliente pediu a feature tal, o que vocês acham?". Joga nas skills — elas trazem preço, trazem o X e o Y, trazem tudo. Chega no dev com layout, ajuste, o que tem que ser feito. Repare que não tem ninguém no meio traduzindo o cliente pra quem programa.
O que cabe ao dev hoje é ser o dono do produto no aspecto técnico. Isso é o que eu venho pregando há muito tempo, e não é novidade de agora: a gente tinha front, back e mobile e eu cortei front e back separados anos atrás, antes de inteligência artificial na minha empresa. Não fazia nenhum sentido eu ter um cara dedicado só pra front e outro só pra back. Eu via muito atraso e muito problema por causa disso. Eu queria o full stack, por custo-benefício.
E não me venha com a desculpa da demanda. Talvez eu não tivesse demanda suficiente só pra front? Ah, eu tinha — pode ter certeza que eu tinha, e tinha muita. Mesmo assim não fazia sentido pra mim. Contei essa briga inteira, com o caso do dev que passou um mês tentando atualizar o Vue, quando escrevi sobre o erro do front separado que mata o seu SaaS, e o desdobramento de contratação está em por que eu só contrato full stack.
Agora, na era da inteligência artificial: esqueça o cara que é só front. Esqueça. Nenhuma empresa do mundo precisa de uma pessoa só de frontend — eu te afirmo, independente do tamanho da empresa. Por quê? Porque não faz sentido. Frontend hoje, com a estrutura bem definida, um Fable faz maravilhosamente bem. Pode ser que eu tenha pegado pesado, mas faz muito bem — melhor do que a maioria dos devs júnior e pleno, no sentido de custo-benefício, sem sombra de dúvida. E isso já contando o loop de ajuste, ler código e revisar. Eu não estou comparando gênio com máquina: estou comparando conta de empresa.
Então o que as empresas estão buscando? O que eu estou buscando? Pessoas que entendam de negócio. E aí vem a objeção de sempre: "ah, mas esse cara não vai trabalhar na empresa, quem tem perfil de pegar as coisas e ir pra frente vai montar o próprio negócio".
Será? Eu conheço várias pessoas com perfil de empreendedor que não querem a responsabilidade de empreendedor. Será que essa pessoa não quer trabalhar numa empresa que dá liberdade pra ela fazer as coisas, com a grana ou a comissão dela garantida, mas que tira dela a responsabilidade jurídica? Porque responsabilidade, aqui, não é palavra bonita de vaga. É isto:
Então: não é porque a pessoa tem perfil proativo que ela vai querer montar empresa e se responsabilizar por tudo isso. Talvez ela monte um canal do YouTube, uma coisa em que ela não precisa aparecer, uma revenda, um afiliado. São perfis de segmentos diferentes. O empreendedor vai montar um SaaS; a pessoa que eu procuro pode ser excelente dona do produto dentro da minha empresa sem querer nada disso.
Eu gosto dessa responsabilidade — e é honesto dizer que eu sou o caso raro, não o padrão. Eu tenho empresa desde os meus 18 anos de idade. Eu gosto desse monte de coisa paralela ao mesmo tempo, essa fuzuê de cuidar de tudo num dia só. Me dou bem com isso. Só que a maioria das pessoas que me conhecem me chama de louco: eu trabalho às vezes das 5h20, 5h30, 6h da manhã até 10h, 11h da noite, dependendo das responsabilidades do dia — até a minha mulher me chamar, e quando ela chama não tem jeito. E eu não abro mão de filho e esposa: isso também é trabalho, trabalho familiar, e tem que estar na agenda. Quem não se dá bem com esse tipo de rotina não é pior profissional — é outra escolha, e ela é legítima.
A gente filtra no SaaS a necessidade do cliente, usa IA pra buscar aquilo que o PO buscava e trazia mastigado, e chega no desenvolvedor — que cada vez mais vai ser o dono do produto no aspecto técnico, com entendimento do negócio e comunicação direta com a diretoria ou com quem está no cliente. E aí eu preciso medir esse desenvolvedor, porque ele está fazendo o trabalho de uns quatro, cinco, e isso a gente já sabe. Eu mostrei essa conta na prática quando contei como eu produzo o trabalho de dez pessoas com IA e quando substituí um dev júnior por IA no meu pipeline.
Como é que eu meço? A feature que ele implementou, que chegou lá na ponta, gerou dinheiro. É isso que importa. Não mais "a squad gerou valor para a empresa". Gerou dinheiro mesmo. Aquela mudança que o desenvolvedor fez no produto, aquilo que foi solicitado, gerou dinheiro pra empresa lá na ponta? Porque hoje está muito fácil metrificar tudo: dá pra ter dado de analytics gigantesco. Antigamente essa pergunta morria em reunião; hoje ela tem resposta numérica.
Eu sei que essa frase soa dura e eu vou deixar ela dura de propósito, porque é assim que eu decido contratação. Mas ela tem um lado bom pro dev, e é bom dizer: quando a medida é dinheiro na ponta, ninguém precisa mais de política interna pra provar que trabalhou. O número não depende de quem gostou de você na reunião.
Pra não passar a ideia de que eu demiti a camada de gestão e fui pescar: vai cair mais coisa no colo do dev. Vai cair, sim, porque o desenvolvedor hoje vai ter que ser multidisciplinar com inteligência artificial, com absoluta certeza. E um pouco cai no colo da galera do atendimento, venda e suporte ao cliente. A gestão fica cuidando de ambos os lados, pra ter o feeling — porque cada empresa tem o seu feeling, o seu segredo da Coca-Cola. O dono, o gestor, o CEO é quem tem o feeling de pra onde a empresa vai. Então ele tem que sair botando o dedinho nesses fluxos de feature, melhoria, bug, conversa com o cliente. O que não precisa mais é daquela escada gigante pra chegar no dev.
Eu cortei Scrum Master e agora PO é a mesma coisa: é um fluxo que não faz mais sentido aqui no meu negócio. E, de novo, pode ser que me critiquem — eu não ligo. O que eu acho é que isso vai virar tendência daqui pra frente nas empresas, conforme os gestores forem tomando essa consciência que eu ganhei ali atrás, botando a mão na massa e vendo o que dá pra fazer com inteligência artificial de fato: gerar dinheiro e gerar valor.
Eu gravei em 26/09/2026 e escrevi este texto em 27/09/2026 — a apuração no Scrum Guide é de 27/09/2026, na versão de novembro de 2020, que é a vigente quando eu escrevo. Duas honestidades: primeiro, o que eu conto aqui é a decisão da minha empresa, com o meu tamanho, o meu produto e o meu bolso sem aporte — não é receita pra empresa de mil pessoas com contrato amarrado, e essas vão levar mais tempo, com razão. Segundo, a comparação de custo-benefício entre modelo e dev júnior é minha avaliação prática na minha operação, não um teste controlado com número publicado; onde eu tenho número, eu mostro o número. O método é o que eu deixo: olhe a sua escada, conte quantas mãos a demanda do cliente atravessa até virar código, e pergunte quanto dinheiro cada degrau gerou.
TODA SEGUNDA · MEIO-DIA · AO VIVO
Discorda? Concorda? Tem um caso parecido? Aqui não tem caixa de comentário de propósito: segunda-feira, ao meio-dia, eu faço live no canal e a gente conversa sobre isso ao vivo — sem corte, como sempre.
Resumindo o que eu levaria disso pra dentro da sua operação: vale a pena o PO? Não. Vale a pena o Scrum? Não — aqui dentro, com o meu tamanho e o meu bolso. Antes de cortar cargo, faça o dever de casa que eu fiz: bote a mão na massa na IA, veja o que ela realmente entrega de pesquisa, de concorrência, de margem e de interface, e só então mexa na estrutura. Se você quer aprender a cuidar e gerenciar essa coisa toda na era da inteligência artificial — criar agência de sites e vender site, chatbot de WhatsApp agora que o WhatsApp está cobrando mais, infraestrutura, ou botar um SaaS em produção do zero sem quebrar no caminho —, é disso que eu trato nas minhas imersões, e valor, data e condição ficam na página de cada uma, que é onde essa informação está certa. Eu também expliquei o que cada uma resolve e pra quem cada uma não serve. Um abraço, e até a próxima.
Baseado na gravação do canal @josimarjmv publicada em 26/09/2026 (13min20), com transcrição própria das legendas do próprio vídeo. São da minha vivência e foram ditos na gravação: ter empresa de tecnologia e cuidar desses setores há anos; contratar, pagar a conta, gravar sem corte, pôr a mão na massa e gerenciar infraestrutura pesada, data center próprio e milhões de views todos os dias no Brasil e nos Estados Unidos; a empresa não ter recebido aporte financeiro e o dinheiro ser contado, com dó de dinheiro no sentido de mal investido; ter feito um teste com Scrum que não foi uma boa experiência; o desenho com Scrum Master, PO, tech lead e squad com infra, DevOps, back, front e mobile, e o botão do front que podia custar um mês no back; a função do botão vir do PO; o fatiamento ter feito sentido com equipe grande porque era difícil colocar visão de produto na cabeça do desenvolvedor; a observação de que o desenvolvedor sempre foi meio estrelinha, que é uma classe considerada difícil de lidar e que não são todos, com a intenção de gravar um vídeo sobre isso; o PO criar atrito como o Scrum Master e sugar tempo e energia, por ter que conversar com cliente, suporte, chamado, mercado, desenvolvimento, dono da empresa e financeiro para definir o que, como e quando; a IA tipo Claude Code bem estruturada e tunada, com skills e tools, fazer pesquisa de mercado, trazer o que os concorrentes fazem, ajustar o produto, melhorar performance e margem, com busca profunda, refino e comparação chegando mastigada; a pesquisa de UI com foco na UX; o cliente na ponta ser o dono do produto de verdade, no caso de SaaS o cliente que paga cem, duzentos ou dez mil reais por mês, com a demanda entrando pela equipe de suporte e o filtro sendo feito ali antes de jogar nas skills e chegar no dev; ter cortado front e back separados anos antes da IA por causa de atraso e problema, querendo full stack por custo-benefício, com demanda existindo mesmo assim; a afirmação de que hoje nenhuma empresa do mundo precisa de alguém só de frontend, que um Fable faz frontend muito bem, melhor que a maioria dos devs júnior e pleno em custo-benefício, contando o loop de ajuste e a leitura de código; buscar pessoas que entendam de negócio; conhecer pessoas com perfil de empreendedor que não querem a responsabilidade de empreendedor e a hipótese da empresa que dá liberdade sem a responsabilidade jurídica; a lista de processo, Procon, negociação com cliente, atendimento a governo, suporte 24 por 7, responder por back, front e mobile, pagar infraestrutura, VM caída, ataque DDoS, backup que não deu certo e migration que derrubou o banco; a alternativa do canal do YouTube, da revenda e do afiliado como segmentos diferentes; ter empresa desde os 18 anos, gostar da responsabilidade e do monte de coisa paralela, ser chamado de louco, trabalhar das 5h20 ou 6h da manhã até 10h ou 11h da noite dependendo do dia, e não abrir mão de filho e esposa porque isso também é trabalho e tem que estar na agenda; o desenvolvedor ser cada vez mais dono do produto no aspecto técnico, com entendimento de negócio e comunicação direta com a diretoria ou com quem está no cliente, fazendo o trabalho de uns quatro ou cinco; a medida ser a feature ter gerado dinheiro na ponta em vez de a squad ter gerado valor, com metrificação por analytics; o PO hoje não valer a pena e não contratar alguém só para isso; mais coisa cair no colo do dev multidisciplinar e um pouco no colo de atendimento, venda e suporte, com a gestão cuidando de ambos por causa do feeling e do segredo da Coca-Cola de cada empresa, o dono botando o dedinho nos fluxos de feature, melhoria, bug e conversa com cliente, sem a escada gigante até o dev; ter cortado Scrum Master e agora o PO; não ligar para crítica e achar que isso vira tendência conforme os gestores puserem a mão na massa; e o convite para as imersões de agência de sites, chatbot de WhatsApp com o WhatsApp cobrando mais, infraestrutura presencial e SaaS do zero à produção. É apuração minha, feita em 27/09/2026, e não estava na gravação: a letra do Scrum Guide na versão de novembro de 2020, com as três responsabilidades "the Developers, the Product Owner, and the Scrum Master", o time "typically 10 or fewer people", a frase "The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team", o "The Product Owner is one person, not a committee" e, principalmente, o "The Product Owner may do the above work or may delegate the responsibility to others" seguido de "Regardless, the Product Owner remains accountable". A comparação de custo-benefício entre modelo e dev júnior ou pleno é avaliação prática minha na minha operação, não teste controlado com número publicado, e está marcada como tal no texto. Sobre as minhas imersões eu não repito preço, data nem condição aqui: essa informação é final e fica na página de cada imersão.