Ep. 30 - Produtos, Produteiras e Produteiros

Este episódio recebe Andressa Chiara e Fernando, criador do Love the Problem, para discutir o que acontece quando não existe alguém com competências reais de produto dentro de um time. O ponto de partida de Andressa é direto: se você não tem um bom PO, ou uma boa estratégia, ou alguém com tempo dedicado a cuidar do produto, o trabalho de estratégia de produto está sendo feito de qualquer forma, só que provavelmente por alguém que não entende bem disso, ou de forma improvisada. É citado o conceito de HIPPO (Highest Paid Person's Opinion, a opinião da pessoa mais bem paga da sala): sem alguém validando hipóteses de produto de verdade, o time acaba apenas executando uma lista de requisitos ditada por quem tem mais poder na sala, não por evidência real. A frase que resume essa ideia: produto abomina o vácuo. Sempre vai ter alguém preenchendo esse espaço de decisão, seja você quem entende do assunto, seja não.

O apresentador abre com uma confissão pessoal: como desenvolvedor, nunca teve ao seu lado alguém com competências de produto, e por isso, com frequência, fazia muito bem feito algo que talvez nem devesse ser feito. Essa é a cagada central discutida no episódio: times técnicos entregando código de qualidade, mas sem ninguém questionando se aquilo resolve o problema certo.

Antes de aprofundar nos erros, é discutida a própria definição de produto. Fernando propõe que produto é algo que resolve o problema de alguém, ou que faz algo que as pessoas não faziam antes, ou faziam de forma ruim, e que melhora a vida delas. Ele argumenta que a fronteira entre produto e serviço praticamente não existe: mesmo entregando um produto digital, você está entregando uma experiência de serviço completa, e ignorar isso, cuidando só da interface, é uma ilusão perigosa. É citado o exemplo de uma entrevista de emprego em uma fintech em que o candidato perguntou 'mas o produto já não está pronto? Por que estão contratando desenvolvedor?', revelando a crença equivocada de que um produto é algo que se termina, em vez de algo perene que precisa evoluir continuamente.

Andressa conecta essa ideia à Comunicação Não Violenta: qualquer problema de cliente que um produto resolve pode, no fundo, ser reduzido a necessidades humanas universais, conexão, informação, cuidado, relaxamento. Um produto que não atende a nenhuma necessidade real está fadado a não gerar receita, o que ela chama de 'conceito da tarifação'. Essa é a diferença central entre mindset de projeto e mindset de produto: sucesso de projeto é entregar dentro de escopo, prazo e custo prometidos; sucesso de produto não está vinculado a escopo, só a prazo e custo como restrições. Se um escopo diferente resolve o mesmo problema de forma mais rápida ou barata, isso também é sucesso. Alguém com competência de produto é, por definição, alguém orientado a testar hipóteses e métricas reais, não a apenas cumprir uma lista de tarefas, e isso vale tanto para quem lidera o produto quanto para quem está codificando: o valor real que um desenvolvedor entrega não é código, é criar soluções simples para problemas complexos.

Fernando descreve a cagada mais comum que já viu: estratégias puramente 'copy-paste', como empresas copiando visualmente o aplicativo de um banco digital de sucesso sem entender que por trás daquela interface existe todo um serviço de atendimento, logística e cultura orientada ao cliente, elementos muito mais difíceis de copiar do que uma tela bonita. Esse comportamento é descrito como 'mindset de follower': quando uma empresa só copia concorrentes em vez de se diferenciar genuinamente, ela acaba competindo por preço, um processo destrutivo para o mercado inteiro (ilustrado pelo exemplo da guerra de taxas entre maquininhas de cartão). Clientes fiéis a um produto genuinamente bom não trocam de fornecedor por poucos centavos de diferença, só o fazem quando não há diferenciação real além do preço, e reter um cliente é sempre mais barato do que adquirir um novo (o efeito de perda de clientes é chamado de 'churn').

A conversa então percorre os quatro domínios da agilidade para mapear o impacto de não ter competência de produto no time. No domínio cultural, o resultado é um 'antro de tarefeiros': pessoas trabalhando sem saber por quê, o que reduz motivação, é citado Marty Kagan, autor de referência em produto no Vale do Silício, que estima que usar um time de desenvolvimento apenas para codificar desperdiça pelo menos 50% da capacidade real desse time. No domínio organizacional, é citada a lei de Larman: organizações estão estruturadas para resistir a qualquer mudança e preservar o status quo, então simplesmente contratar um PO e esperar que ele 'salve' o produto, sem mudar a estrutura ao redor dele, tende a esmagar essa pessoa. É contado um experimento real feito pela K21, tanto internamente quanto com clientes, usando o framework Fit for Purpose para reorganizar estruturas em torno dos propósitos reais do cliente em vez da estrutura tradicional voltada a maximizar lucro, com resultados descritos como fenomenais em foco, métricas e resultado.

No domínio técnico, a consequência é código insustentável: sem propósito de cliente claro guiando as decisões, emergem arquiteturas estranhas e classes sem sentido, porque a estrutura organizacional está voltada a maximizar lucro por segmento, não a garantir a confiabilidade que o cliente realmente precisa (é dado o exemplo de um app bancário, que não pode simplesmente parar de funcionar, ao contrário de um app cuja falha é tolerável). Profissionais técnicos bons evitam trabalhar em ambientes tecnicamente precarizados, gerando alto turnover e dependência de poucos profissionais seniores sobrecarregados, fechando um ciclo vicioso entre os quatro domínios.

É discutido como a própria definição de sucesso dentro das empresas reforça esse problema: se bônus, metas e promoções recompensam apenas entregar no prazo e no escopo, a organização inteira se estrutura para otimizar isso, não para pensar de fato no cliente, um ciclo que se retroalimenta e que, em última análise, penaliza o cliente (ilustrado por serviços em que é impossível encontrar o botão de cancelamento, por exemplo).

É apresentado o framework Fit for Purpose, com foco especial na distinção entre KPI e métrica de saúde: KPI, nesse framework, é uma métrica que faz o cliente escolher você, como o prazo de entrega ao comprar um presente de aniversário online, algo visível e decisivo para o cliente. Métrica de saúde é o que o próprio negócio acompanha (faturamento, margem), igualmente necessária para a sustentabilidade financeira, mas sem relação direta com a decisão do cliente. Um erro muito comum, revelado logo no primeiro dia de treinamentos sobre o tema, é perceber que a maioria das empresas tem uma proporção de 80% de métricas de saúde e 20% ou menos de KPIs reais, muitas vezes nem tendo KPIs de fato, apesar de chamarem tudo de KPI.

É usado o exemplo cotidiano do botão de travessia de pedestres: perguntados sobre por que esse botão existe, cada convidado responde a partir do próprio viés de domínio, um vendo sincronização de semáforos para fluxo de tráfego (domínio organizacional), outra questionando se as pessoas realmente usam aquele semáforo (domínio de produto/cliente). O ponto é que a maioria dos profissionais que constroem qualquer sistema não sabe exatamente qual problema do usuário aquilo resolve, inclusive é levantada a hipótese de que a ausência de feedback tátil ou sonoro nesses botões (o que faz as pessoas apertarem repetidamente, desgastando o mecanismo) é um problema clássico de usabilidade nunca resolvido.

Para encerrar, cada participante deixa uma recomendação prática. Fernando recomenda o treinamento Fit for Purpose como ponto de partida mais transformador do que certificações tradicionais de Product Owner. Andressa recomenda buscar, dentro da própria empresa, pessoas incomodadas com a situação atual e dispostas a mudar, os 'promotores' de mudança, e recorrer a conteúdo, comunidades e experimentos pequenos junto com elas. O apresentador complementa sugerindo conversar com pessoas de produto dentro da própria empresa e verificar se existem métricas reais de cliente, não apenas indicadores internos. É desmistificado o glamour associado ao trabalho de Product Owner: na prática, é um trabalho intenso, quase sempre acima de doze horas diárias até se aprender a manter um ritmo sustentável, com responsabilidade constante sobre o custo de cada aposta errada de produto. O episódio fecha com um insight final: se você acha que a pessoa de produto do seu time 'não trabalha', isso é sinal de que o processo anterior ao compromisso com qualquer item de trabalho, o chamado upstream, está quebrado, e vale voltar e investigar onde exatamente está esse ponto cego.