antonio leandro

comentarioprodutoen

SVPG (Marty Cagan)

Blog da Silicon Valley Product Group, de Marty Cagan e sócios: a consultoria americana que treina empresas a trocar roadmaps de features por times que respondem por resultado. No acervo como a defesa mais organizada (e mais insistente) do chamado modelo de produto.

15 textos no acervo · publica a cada ~23 dias · último em

escrito por pipeline de llm, revisado por antonio leandro antes de publicar

o que esta fonte defende

Os quinze textos giram em torno de uma distinção só, repetida com pouca variação: entregar features não é a mesma coisa que resolver problemas. De um lado, o que Cagan chama de modelo de projeto — executivos e stakeholders definem uma lista priorizada, os times constroem, e o sucesso é ter construído. Do outro, o modelo de produto: o time recebe um problema de cliente ou de negócio e responde pelo resultado. Praticamente todo texto do arquivo é essa mesma distinção aplicada a um caso novo — inteligência artificial, produto interno, protótipo, contratação de engenheiro, política interna de transformação.

A segunda camada é mais interessante que a primeira: o obstáculo quase nunca é o time, é a empresa. “Stakeholders and the Product Model”, escrito com Chris Jones, argumenta que a mudança não cabe dentro da área de produto — se quem pede continua pedindo funcionalidade com prazo, o time volta a ser executor em poucos meses. “The Politics of Pilot Teams” descreve o padrão em que a transformação começa por um time-modelo e morre ali, isolada por quem tem a perder com ela, enquanto conselhos de administração pressionam CEOs pelo tema de olho em valuation. E “Great Products, Bad Companies” é uma concessão grande vinda de quem passou duas décadas dizendo que produto bom faz empresa boa: produto bom é necessário e não é suficiente.

O arquivo tem duas mudanças de posição declaradas, e as duas têm a mesma causa. “Product Coaching and AI” abre avisando que contraria o que a SVPG defendeu por vinte anos. A série “product creator” é escrita explicitamente para quem nunca teve formação em produto, design ou engenharia — o que afrouxa a premissa anterior de que isto é ofício de profissionais em papéis bem definidos. O motor comum é o custo de construir despencando: se construir deixa de ser o gargalo, a pergunta que sobra é o que vale a pena construir. Daí a fórmula que organiza os textos de 2026, build to learn contra build to earn, e daí também a necessidade de redefinir o papel de produto em agosto de 2026, depois de admitir ter visto umas cem definições diferentes circulando.

Vale ler sabendo de onde vem. A SVPG vende treinamento e coaching do modelo que descreve, e o diagnóstico converge sempre para a mesma prescrição. Os textos quase não trazem número, e os estudos de caso — Google, Amazon, Spotify — descrevem empresas que já deram certo, evidência que confirma mais do que testa. Ainda assim, é o corpo de argumento mais organizado disponível sobre o assunto, e a franqueza de admitir os dois recuos acima sugere uma posição que se move quando o mundo se move.

por tema

o modelo de produto contra o modelo de projeto (4 textos)

É a tese-mãe do arquivo. No modelo de projeto, alguém acima decide a lista de funcionalidades e o time entrega dentro do prazo; o resultado medido é a entrega em si. No modelo de produto, o time recebe um problema e é cobrado pelo efeito no cliente e no negócio. “Build to Learn vs Build to Earn” é o texto que enuncia isso com mais clareza, e observa que o modelo de projeto continua sendo o mais comum mesmo agora.

Os outros três tratam de por que a troca é difícil. O texto sobre stakeholders, com Chris Jones, insiste que a mudança tem de alcançar quem está fora da área de produto — executivos, jurídico, vendas, operações — ou ela se desfaz sozinha. O texto sobre times-piloto é o mais político do conjunto: descreve a transformação como disputa de poder, não como projeto de mudança de processo. E o retrato do modelo de produto dentro do Google, com Elias Lieberich, é parte de uma série com Amazon e Spotify que serve para mostrar que a coisa existe fora do slide.

ia acelerou a entrega, não o resultado (3 textos)

“The AI Productivity Paradox” é o texto mais citável do arquivo e o mais direto: times estão claramente entregando mais rápido com IA, e os resultados de negócio não melhoram. O diagnóstico é o esperado, dada a tese da casa — se o problema era estar construindo a coisa errada, construir mais rápido não conserta nada, só antecipa o erro. O texto se apoia em reconhecimento externo do fenômeno, incluindo uma edição recente da McKinsey Quarterly, para argumentar que não é implicância de consultor.

O FAQ que acompanha a divisão entre construir para aprender e construir para faturar responde às objeções práticas de quem tentou aplicar a distinção. E “Build vs Buy in the Age of AI” mexe numa conta antiga da indústria: se boa parte da decisão de comprar em vez de construir vinha do custo de construir, a queda desse custo desloca a linha — sem que isso vire, no argumento, licença para construir tudo.

protótipo serve para aprender, não para impressionar (3 textos)

Três textos da série voltada a quem cria produto sem ter passado por formação em produto, design ou engenharia. “The Purpose of Prototypes” define protótipo pela pergunta que ele responde: existe para testar uma dúvida barato e rápido, não para ser uma versão pequena do produto final. “Prototypes vs Products” cobre a distância entre as duas coisas — o que demonstra bem numa reunião costuma não sobreviver a usuários reais, escala, confiabilidade e manutenção — e o alerta ganha peso justamente porque IA tornou trivial produzir protótipo convincente.

O texto sobre forward deployed engineers trata do arranjo em que engenheiros trabalham colados ao cliente, prática que ficou conhecida pela Palantir e voltou à moda entre startups de IA. Aqui ele aparece como forma de encurtar a distância entre quem constrói e quem usa — a mesma preocupação por outro caminho.

o papel de produto e quem forma quem (3 textos)

“A Fresh Definition of The Product Role” começa admitindo o tamanho da bagunça: são tantas definições de product manager e product owner circulando que o termo perdeu utilidade. A explicação oferecida é que modelos operacionais diferentes exigem responsabilidades diferentes, e que discutir a definição sem dizer de qual modelo se está falando não leva a lugar nenhum. O texto sobre arquétipos de liderança, puxado de uma conversa entre o sócio Christian Idiodi e Shreyas Doshi, faz o mesmo exercício um nível acima, para quem lidera.

“Product Coaching and AI” é o texto que mais destoa do resto: abre dizendo que contraria o que a SVPG defendeu por duas décadas. O pano de fundo é um alerta repetido há tempos sobre profissionais em papéis de product owner e de time de features, cuja função — recolher requisitos e traduzi-los em tarefas — é justamente a mais exposta à automação. A resposta proposta passa por usar IA no próprio trabalho de formação dessas pessoas.

quando o produto bom não basta (2 textos)

Dois textos que testam os limites da própria tese. “Great Products, Bad Companies” desfaz uma equação que Cagan defendeu por anos: produto excelente continua sendo condição necessária para empresa excelente, mas não garante nada — e há casos, admite o texto, em que produto muito bom convive com empresa ruim, ou até a sustenta.

“Commercial vs Internal Products” defende que ferramentas e serviços usados pelos próprios funcionários merecem o mesmo cuidado dado ao produto que o cliente paga, contra o hábito de tratá-las como TI de segunda classe. A inversão que dá título à abertura é boa: produto interno é difícil, produto comercial é mais difícil ainda — o interno tem usuários cativos, o comercial precisa conquistar cada um.

onde ela discorda de outras fontes do acervo

Dentro do próprio arquivo, a discordância mais clara é com o consenso de que o ganho da IA em produto é velocidade de entrega: “The AI Productivity Paradox” trata isso como armadilha, e não como conquista. Fora dele, a SVPG é conhecida por bater de frente com a escola ágil de certificação — o papel de product owner como definido pelo Scrum e frameworks de escala como o SAFe aparecem, no argumento da casa, como exatamente o que produz times executores em vez de times responsáveis por resultado. Também contraria a leitura corrente de que IA torna o papel de produto dispensável: no arquivo, o que fica obsoleto é a versão do papel que só traduzia pedido em tarefa.

linha do tempo