De Scrum Master a Product Owner:
o que mudou na minha visão de produto
A transição de SM para PO foi a virada de chave na minha carreira. Compartilho com vocês agora o que “aprendi” e o que tive que “reaprender” nessa mudança.
Product Owner · Senior Sistemas
Em janeiro de 2020, fui promovido a Scrum Master na GKO Informática. Foi uma conquista importante — e uma grande virada de chave.
Nesse momento, eu deixava de atuar como suporte/analista de negócios e entrava oficialmente no mundo de produto e tecnologia.
(Se bem que um Analista de Negócios tem muito de PO… mas isso é papo para outro post 😅)
Dois anos e meio depois, quando assumi meu primeiro papel como Product Owner na Senior Sistemas, percebi algo que me pegou de surpresa:
eu precisei “reaprender” quase tudo que tinha construído sobre o que significa entregar valor.
Esse artigo é sobre essa virada.
Não é um guia teórico sobre as diferenças entre Scrum Master e Product Owner — isso você encontra em qualquer blog.
Aqui, quero compartilhar o que mudou na prática, no meu dia a dia, na forma como eu penso sobre produto — e tudo isso a partir da minha experiência real, que espero que ajude você também.
O que o Scrum Master me ensinou
Como SM, meu trabalho era garantir que o time funcionasse. Remover impedimentos, facilitar cerimônias, proteger o time de interferências externas. Eu era o guardião do processo. (às vezes eu burlava o sistema 😅 mas era bem alinhado com o time rsrs)
E nisso aprendi coisas valiosas que carrego até hoje:
- Escuta ativa. Facilitar boas retrospectivas exige ouvir o que não está sendo dito e criar espaço para as pessoas falarem o que nem sempre conseguem falar. Isso me tornou um profissional mais empático.
- Visibilidade. Kanban, burndown, velocity — aprendi a deixar o trabalho visível para todos, não só para quem faz. E isso faz uma diferença real e brutal para o seu time.
- Confiança no time. SM te ensina a não resolver — e sim a ajudar o time a resolver. Isso é mais difícil do que parece.
O Scrum Master protege o time do mundo externo.
O Product Owner conecta o time ao mundo externo.— Uma distinção simples que levei um tempo para internalizar de verdade
O que tive que reaprender
Aqui começa a parte mais honesta do texto.
Como SM, eu aprendia a não tomar decisões de produto. “Isso é com o PO” era uma frase que eu usava com frequência. O processo era meu território; o backlog, não.
Quando virei PO, essa separação precisou desaparecer. De repente, eu era responsável pelo quê e pelo por quê — e isso gerou um desconforto real.
Nas primeiras sprint reviews como PO, o time em algumas issues não entregava ou apresentava algo que estava esperando como resultado final, e não resolvia o problema do usuário. Eu havia escrito a história mal. Nenhum processo do mundo resolveria isso — era uma falha de discovery, minha, que eu precisava resolver, e foi se resolvendo com o tempo.
- Parei de pensar em velocidade e comecei a pensar em impacto.
- Parei de perguntar “o time vai conseguir entregar?” e comecei a perguntar “isso realmente precisa ser entregue?”
- Aprendi que backlog refinado não é backlog priorizado. São coisas diferentes.
- Entendi que stakeholder management não é sobre agradar — é sobre alinhar expectativas com dados.
A mudança de perspectiva mais importante
Como SM, o sucesso era medido pela saúde do time e pela aderência ao processo. Uma retrospectiva bem facilitada, um planning com histórias claras — isso era vitória.
Como PO, aprendi que processo perfeito com produto errado é desperdício. A pergunta que passei a me fazer toda semana é:
O que construímos nas últimas duas semanas que gerou valor real para alguém?
Essa pergunta muda tudo. Ela reorienta o que você prioriza, como você escreve histórias, como você conduz o discovery, como você se relaciona com os stakeholders.
O que eu diria para quem está nessa transição
Se você é SM pensando em virar PO — ou se acabou de fazer a transição — aqui vai o que aprendi na prática:
- Invista em discovery antes de qualquer outra coisa. Entender o problema é mais valioso do que escrever a solução perfeita.
- Aprenda a dizer não com dados. PO não é despachante de demandas. Sua função é priorizar — e priorizar significa descartar.
- Métricas de produto são diferentes de métricas de time. Velocity é do time. Adoção, retenção, NPS — são do produto. Aprenda a medir o que importa.
- O backlog conta uma história. Se alguém ler seu backlog e não entender qual problema você está resolvendo, reescreva.
- A transição demora. Eu levei pelo menos 6 meses para parar de pensar como SM. Seja paciente consigo mesmo.
- SM e PO têm perspectivas opostas: um protege o processo, o outro protege o valor
- A transição exige reaprender a decidir — e assumir responsabilidade pelo produto
- Backlog refinado ≠ backlog priorizado: aprenda a diferença cedo
- Discovery é mais importante do que qualquer cerimônia ágil
- A pergunta certa é: o que entregamos que gerou valor real para alguém?
Onde estou agora? Ainda aprendendo. A pós-graduação em Product Management que concluí em 2025 aprofundou e refinou processos e ideias que fui descobrindo na prática. E este site é parte dessa jornada — um espaço para registrar o que aprendo enquanto trilho o caminho de PO para PM.
Se você passou por algo parecido ou está vivendo essa transição agora, manda uma mensagem — adoro trocar ideia sobre isso.
Luiz Lima