Gestão de produto não é sobre construir mais. É sobre resolver o que importa.

Por que produto começa com escuta

Conversa com Jonathan Coll

Gerente de Produto Principal 

Uma conversa com o Jonathan mudou a forma como penso sobre produto. Jonathan é Product Manager na Avalo, ajudando a moldar a plataforma Ionfi by Avalo. Visto de fora, produto pode parecer decidir o que construir e entregar à engenharia uma lista de requisitos. Visto de dentro, é algo mais discreto e mais difícil: garantir que o que construímos está realmente resolvendo o problema certo, pelo motivo certo. 

Quando pedi para ele descrever o trabalho em termos simples, a resposta me surpreendeu. 

"Eu diria que é 75% escuta e 25% construção", ele me disse. "Meu papel é dar ao design e à engenharia contexto suficiente para que eles mesmos resolvam o problema." 

Esse contexto vem de todos os lados: clientes, suporte ao cliente, operações, conformidade e tecnologia. Cada um enxerga uma parte diferente do quadro. O papel de produto não é decidir qual pedido vence. É encontrar os padrões, entender o impacto para o negócio, e garantir que toda a equipe esteja resolvendo o mesmo problema, pelo mesmo motivo. 

"Meu trabalho não é construir uma funcionalidade para você", disse Jonathan. "Meu trabalho é resolver o seu problema." 

Às vezes isso significa fazer mais uma pergunta. Um cliente pode dizer: só coloque esse widget bem ali. Em vez de dizer sim imediatamente, Jonathan pergunta por quê. 

"Quando um cliente vem até mim com uma ideia de funcionalidade, tento entender um pouco mais a fundo o que ele realmente está tentando resolver", ele explicou. "Às vezes, o que estão nos pedindo para construir não é a melhor solução, ou existe uma forma mais simples de resolver o problema." 

Por trás do pedido geralmente existe um objetivo maior: um fluxo de trabalho mais fluido, maior adoção, ou uma experiência melhor para o cliente. Entender esse objetivo é o que permite à equipe construir algo útil, em vez de simplesmente adicionar mais uma funcionalidade. 

Uma história em especial ficou comigo. Clientes criavam transferências, anexavam documentos de suporte a um perfil e então enviavam a transação para aprovação. Da perspectiva do cliente, os documentos já estavam na plataforma. Mas os arquivos relevantes podiam estar entre dezenas de documentos no perfil, gerando uma solicitação de acompanhamento evitável para algo que o cliente acreditava já ter fornecido. 

Jonathan ouviu versões do mesmo problema de vários clientes 

"Isso apareceu umas cinco vezes quando entrevistei clientes diferentes", ele disse. 

Em vez de tratar cada caso como um pedido isolado, a equipe identificou a lacuna subjacente. Essa percepção se tornou a base de uma funcionalidade que permite aos clientes anexar os documentos relevantes do perfil diretamente a uma transferência. O contexto pode viajar junto com a transação, ajudando a reduzir idas e vindas e agilizando a revisão. 

"A maioria dos grandes projetos é, na verdade, sobre conectar os pontos", explicou Jonathan. "Você observa as coisas recorrentes que continuam aparecendo. É isso que nos ajuda a decidir o que priorizar." 

Duas coisas ficaram comigo depois da nossa conversa. 

Primeiro, produto é onde diferentes perspectivas se encontram. O suporte ao cliente ouve a voz do cliente em primeira mão. Conformidade e operações entendem o que é necessário para fazer uma transação avançar. Engenharia sabe o que pode ser construído e como construir em escala. Design torna a experiência intuitiva. Jonathan ajuda essas equipes a compartilhar uma linguagem comum e se alinhar em torno do mesmo resultado. 

"Conformidade e engenharia nem sempre falam a mesma língua", ele explicou. 

Parte do trabalho dele é garantir que o requisito, o motivo por trás dele e o resultado pretendido sejam compreendidos por todos. 

Segundo, progresso não precisa significar disrupção. À medida que continuamos aprimorando a plataforma, Jonathan se concentra em proteger os fluxos de trabalho nos quais os clientes já confiam, enquanto deixa claro o valor de cada mudança. 

"Se simplesmente migrarmos as pessoas sem explicar os benefícios, elas vão perguntar: por que estou mudando afinal?", ele disse. "Precisamos mostrar a elas: isto é o que vocês nos disseram que era difícil, e é assim que resolvemos isso para vocês." 

Ajudar os clientes a reconhecer o próprio feedback no produto, eu disse. Ele concordou — é exatamente isso. 

Boa liderança de produto, na visão dele, não é sobre lançar o maior número de funcionalidades ou correr atrás da ideia mais nova. É sobre fazer perguntas melhores, ouvir além das fronteiras internas, e ajudar a equipe a concentrar seu tempo e energia no que mais importa. 

Jonathan descreveu produto como uma função de "pau para toda obra". Essa amplitude talvez seja sua força oculta. O trabalho dele não é substituir os especialistas de cada área. É entender o suficiente de cada perspectiva para conectá-las, conquistar confiança ao longo do tempo, e manter todos avançando na mesma direção. 

Bons produtos raramente são resultado de um único avanço decisivo. Mais frequentemente, eles crescem a partir de dezenas de pequenos momentos em que alguém escuta com atenção, identifica um padrão, e transforma uma frustração recorrente em uma forma melhor de trabalhar. 

Jonathan ajuda a fazer isso acontecer — de forma ponderada, colaborativa, um problema de cada vez.