Ep. 82 - O que Product Owners e Product Managers fazem no dia a dia: produtos por trás das cenas

O episódio nasce de uma pergunta que um desenvolvedor fez a Lula na vida real: "mas L, o que que um PO faz de verdade?". Não uma pergunta sobre papel ou responsabilidade (isso o mercado já discute bastante, inclusive o Guia do Scrum descreve isso), mas sobre o que efetivamente ocupa o dia a dia de quem trabalha com produto. Lula, que veio do desenvolvimento de software, lembra que há dez anos sua resposta seria simples ("eu estava sentado escrevendo código"), mas hoje, atuando com produto, não tem uma resposta igualmente concreta e cotidiana para dar. Para explorar isso, ele chama Zé (Rodrigo Martins), que também veio do desenvolvimento e hoje atua como Product Owner, e Clara (Maria Clara), que trabalha como Product Manager numa squad multidisciplinar. Os três deixam claro que não querem falar de um departamento ou empresa específica, mas de produto de forma ampla, digital (Instagram, Zoom) ou físico (mouse, celular).

Zé abre com a resposta que já tinha dado à pessoa que fez a pergunta original: não existe entrega de pessoa PO, de pessoa dev ou de pessoa designer isoladamente; existe apenas a entrega do produto final, como um filme, em que teasers e trailers provocam, mas o que importa é a obra completa. Por trás disso, quem cuida de produto entende o valor do todo, a curva de maturidade (nascimento, crescimento, maturidade, declínio ou até o momento de matar o produto), e transforma problemas em itens de backlog, ora com pessoas desenvolvedoras, ora com designers, sempre em função de um objetivo único, o que inclui alinhar com stakeholders, entendidos simplesmente como qualquer pessoa interessada em resolver o problema do cliente.

Clara complementa contando que seu dia a dia é entender e resolver problemas de cliente e de negócio com autonomia, sendo também responsável pelo resultado da solução escolhida, mas reconhece que nem sempre é assim: às vezes a solução já chega pronta, encaixada num backlog ou roadmap definido por outra área. Lula percebe, ao ouvir os dois, que vinha tentando encaixar o trabalho de produto num padrão industrial e operacional ("o que você aperta na tecla"), quando na verdade trabalhadores do conhecimento são pagos para pensar, não para executar tarefas; os alinhamentos do dia a dia não são status report, são pensamento coletivo com pessoas de outras competências e perspectivas.

Daí surge a ideia central do bloco seguinte: o padrão discover/delivery, comum na cadência dos times, também descreve o dia a dia individual de quem trabalha com produto. Discover é investigar quais opções valem a pena perseguir; delivery é se comprometer e entregar uma opção, lidando com prazos e trade-offs. Lula conecta isso a um episódio anterior com a Auri, em que uma pessoa desenvolvedora perguntou o que fazer enquanto espera o discovery, e a melhor resposta que ele recebeu depois, de outra pessoa desenvolvedora, foi "faz discovery junto". O ponto é que quem desenvolve também consome o produto e tem repertório para melhorá-lo; se o processo de descoberta não inclui, ainda que de forma leve, todas as pessoas responsáveis pela construção do produto, o trabalho vira cascateado, reproduzindo exatamente o padrão top-down que todo mundo reclama receber de uma diretoria. Clara concorda e nota que o discovery costuma ficar restrito a produto e design, quando deveria envolver o time todo, o que gera autonomia por eliminar dependências futuras. Zé reforça que, como trabalhador criativo, ao receber uma especificação pronta ele primeiro avalia se faz sentido, e muda se não fizer, e lança a hipótese (não uma regra) de que devs talvez vivam uma proporção de 80% delivery e 20% discovery, enquanto quem é de produto viveria o inverso.

Para tornar isso concreto, Lula pede que Clara reconstitua sua semana anterior: ela relata ter levantado um volume grande de problemas e entrado na arte de priorizar qual resolver primeiro, trabalho que ela vê como parte da estratégia de produto, e não apenas uma decisão isolada de quem é de produto. Como está montando um time novo, o foco foi deixar os problemas internalizados por todo mundo antes de partir para a solução, porque pular essa etapa ("só faz, é isso mesmo") costuma terminar mal. Lula resume: se você não leva os problemas até o time, os problemas chegam até você de outro jeito. Ele liga isso a um desequilíbrio comum entre as disciplinas que compõem produto, negócio, tecnologia e experiência: quando uma disciplina está mais fraca que as outras, o time tende a puxar para o lado da disciplina mais forte, gerando conflito entre lideranças. Manter essa paridade, com técnicas de priorização e um plano com métricas, objetivos e desafios, é o que sustenta a entrega.

A conversa então passa por métricas, tema que os três reconhecem ser frequentemente negligenciado por organizações, e, por consequência, pelas pessoas de produto dentro delas. Lula ilustra com a história de quando conheceu Zé, em 2016, numa semana de Evidence da K21 (o programa descrito em evdnc.org, em que a K21 acompanha um time fazendo sprints diários de segunda a sexta). Zé era o PO do time apelidado "Istambul" e passava a maior parte do tempo priorizando e fatiando problemas; já no primeiro dia, imprimiu as principais métricas em folhas A4 e colou na parede, mostrando na review quanto dinheiro e quantos usuários a fatia priorizada impactaria. Clara amplia o ponto: métricas não servem só para validar o sucesso de uma entrega, servem também para invalidar hipóteses com peso real, em vez de dizer "não" apenas por opinião, o que ajuda a manter foco e a de fato terminar as coisas, não só começá-las. Lula compara esse trabalho ao de uma Marie Kondo do produto: revisar cada problema, perguntar se ele ainda faz sentido, descartar o que não traz valor, e manter a casa organizada, porque ideias e problemas bagunçados raramente viram um bom produto.

Zé retoma com uma forma de enxergar os componentes do trabalho: design, implementação e delivery, que se distribuem de modo diferente conforme a disciplina (dev mais em implementação e delivery, design mais em design e implementação, PO transitando por todos), reforçando que não existe uma proporção certa e universal: o que importa é resolver problemas em time, não sozinho. Retomando a analogia do filme, é tecnicamente possível uma pessoa fazer tudo sozinha, mas praticamente impossível alcançar qualidade, alcance e penetração de mercado sem um time por trás. O cliente não se importa com o que acontece nos bastidores, só quer o produto com qualidade, o que remete a um episódio anterior do Love the Problem sobre pensamento sistêmico: o todo não é a soma das partes, é dado pela interação entre elas, então o que mais importa é como o trabalho de cada pessoa de produto interage com o resto do time.

Nesse ponto, Zé faz uma revelação inédita no podcast: além do trabalho na K21, ele integra a equipe do Slice (slice.wbrain.me), produto digital da WBrain, empresa do grupo K21 mas distinta da consultoria. Ele entrou no time de duas pessoas por ter se apaixonado pela ferramenta, criada originalmente por outra pessoa que concebeu, "escreveu o roteiro" e construiu o produto sozinha no início. Mesmo tendo habilidade com código, Zé conta que a maior parte do tempo da dupla é dedicada a produto, não a desenvolvimento: olhar métricas de uso, entender quem usa a ferramenta e para resolver qual problema, e decidir o próximo passo a priorizar; só depois vem o momento de colocar a mão no código, que toma menos tempo do que "acertar a mira". Para Zé, essa é a conclusão central do episódio: por trás das cenas, o trabalho de produto é, em grande parte, ajustar a mira, porque o alvo só se revela de fato quando alguém usa o que foi construído: é o uso que define o produto. Clara confirma que a analogia representa bem sua própria experiência.

O episódio fecha na sigla que dá nome à conclusão: o "FDP do produto", Fatiar, Descartar, Priorizar, o núcleo do trabalho de quem se apaixona pelo problema (o tema do próprio podcast). Fatiar o problema em partes menores e mais tangíveis, descartar o que não deveria nem estar sendo feito (ideias são baratas; descartar bem costuma exigir mais trabalho do que priorizar, já que priorizar escolhe uma coisa entre poucas, e descartar lida com centenas de ideias), e priorizar usando inteligência coletiva e alinhamento com o time, sempre a partir de problemas sustentados por métricas reais, não de opinião. Zé compara isso a um triátlon: fatiar, descartar e priorizar dependem uns dos outros, assim como nadar, pedalar e correr: de nada adianta fatiar bem se a priorização estiver errada, ou priorizar bem sem ter descartado o que não deveria estar no backlog.

Nas recomendações finais, Clara resgata um conselho recebido no início da carreira, de um gestor: "você não está sozinha": construir produto é colaboração entre times, com gestores que ajudam, ensinam e trazem aprendizado. Zé complementa que existe muito conteúdo bom disponível (leitura, cursos, treinamentos), mas conhecimento não aplicado vira desperdício, como comida estocada; a recomendação é sempre puxar um pedaço do que se aprendeu e praticar, assim como ninguém vira um bom triatleta só lendo sobre natação, ciclismo e corrida.