Estratégia & Carreira

Por que pensar como um product manager pode mudar a forma como você trabalha

O problema: fomos treinados para executar, não para questionar.

PHPriscila HolandaCEO · Sofira ·8 min

O problema: fomos treinados para executar, não para questionar

A faculdade de direito e os escritórios te treinaram para ser reativo. Chega uma demanda, você executa. Chega um contrato, você revisa. Chega uma pergunta, você responde.

Isso não é culpa sua. É como o sistema funciona. Mas esse modelo é quebrado.

As empresas não precisam mais de advogados que apenas "fazem o que pedem". Elas precisam de pessoas que entendam o objetivo final antes de sair executando. Que questionem se a tarefa faz sentido. Que proponham caminhos que ninguém pensou.

Esse é exatamente o trabalho de um Product Manager (PM).

O que um PM faz (e por que isso importa pra você)

Product Manager não é programador. PM é a pessoa que define problemas, prioriza o que resolver primeiro, testa hipóteses e mede impacto.

Pensa comigo: você não está fazendo exatamente isso (ou deveria estar) quando desenha um fluxo de compliance? Quando prioriza quais contratos automatizar? Quando decide qual reclamação de consumidor atacar primeiro?

A diferença é que PMs são treinados para questionar tudo antes de executar.

Advogados são treinados para executar sem questionar.

A mudança de mentalidade: de executor para solucionador

Deixa eu te dar um exemplo real.

O diretor comercial chega no jurídico e diz: "Precisamos cortar o contrato comercial do produto X pela metade"

O advogado executor pega o contrato e começa a cortar cláusulas.

O advogado com mentalidade de PM para e pergunta: "Qual é o objetivo final aqui? É fechar mais rápido? É reduzir objeções do cliente? É simplificar a leitura?"

E aí vem a pergunta mágica: "Será que a gente sequer precisa do contrato?"

Talvez um termo de aceite digital resolva. Talvez um clique no checkout seja suficiente. Talvez o problema não seja o tamanho do contrato, mas o momento em que ele aparece na jornada de compra.

Você só consegue enxergar essas possibilidades se souber o objetivo final. E você só sabe o objetivo final se perguntar antes de executar.

Parece simples. Mas pare e pense qual foi a última vez que você tentou entender o contexto e o objetivo final de um projeto ou demanda na qual estava inserido.

Pare de tratar mil reclamações como mil casos isolados

Os agentes da Sofira automatizam o fluxo de Procon e canais de consumidor — da captura ao protocolo, com causa-raiz marcada.

Agende uma demo

O Playbook: como desenvolver essa mentalidade

Passo 1: Nunca comece pela tarefa

Toda vez que alguém te pedir algo, sua primeira reação deve ser perguntar: "Qual problema estamos tentando resolver?"

Não é ser chato. É ser estratégico. A pessoa que está pedindo muitas vezes não sabe que existem outros caminhos possíveis.

O erro que todos nós cometemos:

Quando recebemos uma demanda específica, nosso cérebro assume: "Se me pediram a opção B, é porque essa pessoa já avaliou A, B e C e escolheu B." Raramente consideramos a hipótese de que a pessoa desconhece que A e C existem. Ela pediu B porque era a única que conhecia.

Exemplo real:

Quando eu trabalhava com fundos de investimento, tínhamos uma estrutura complexa de empresas em Delaware e em Cayman.

Um dia meu CEO chegou pedindo pra criar uma LLC em Delaware. É muito simples e rápido criar uma LLC. Mas tem um custo anual alto de manutenção. Será que a gente precisava mesmo de uma empresa adicional?

Perguntei: "Ok. Pra que precisamos de mais uma LLC? Qual o objetivo aqui?"

CEO: "Temos um ativo novo e precisamos segregar a participação dele apenas para alguns investidores".

Propus usarmos uma empresa que já estava aberta e apenas alterar o contrato social com regras de segregação de ativos. Cumpria o mesmo objetivo, custava menos, e era mais rápido. Meu CEO não sabia que essa opção existia.

Se eu tivesse só executado, teríamos mais uma empresa pra manter, mais custo, mais complexidade. Tudo desnecessário.

Seu papel é descobrir o objetivo final e garantir que a pessoa saiba que existem outras opções antes de você começar a executar.

Passo 2: Use o mini-framework do PM

Uma grande parte do trabalho de um Product Manager é testar hipóteses para descobrir a melhor forma de chegar em um objetivo. PM não é a pessoa que já sabe a resposta — é a pessoa que sabe como descobrir a resposta.

E o método é sempre o mesmo ciclo:

PROBLEMA → HIPÓTESE → TESTE → APRENDIZADO

Parece simples, mas muda tudo. Porque te obriga a admitir que você não sabe a solução de cara — e que precisa validar antes de sair executando.

Exemplo real:

Imagine que você é advogada de uma empresa de e-commerce e as reclamações no Procon aumentaram 40% nos últimos 3 meses. Seu gestor pede pra "resolver isso".

O advogado executor começa a responder as reclamações mais rápido, tenta negociar melhor, talvez contrate mais gente pro time.

O advogado com mentalidade de PM para e aplica o framework:

[ Imagem do original — a migrar ]

Diagrama do framework PROBLEMA → HIPÓTESE → TESTE → APRENDIZADO aplicado ao aumento de 40% nas reclamações de Procon. Inserir aqui a imagem original do artigo.

Agora você tem munição pra uma conversa diferente. Não é mais "precisamos responder mais rápido". É "precisamos melhorar a resolução no primeiro contato do SAC, isso vai reduzir Procon na origem".

Por que isso importa:

Sem esse processo, você fica no escuro:

  • Pode gastar meses otimizando a coisa errada.
  • Pode contratar gente quando o problema é processo.
  • Pode automatizar uma etapa que nem deveria existir.

Passo 3: Pergunte "por quê" até chegar na raiz

Essa é uma técnica clássica de PM chamada "5 Whys". A ideia é simples: quando você aceita a primeira resposta, geralmente está tratando sintoma, não causa.

Exemplo real:

Sua empresa está tendo muitas reclamações no Procon sobre atraso na entrega. O diretor de operações pede pro jurídico "criar uma cláusula de prazo mais flexível no contrato".

Você poderia simplesmente redigir a cláusula. Mas resolve perguntar:

— "Por que precisamos de prazo mais flexível?"
— "Porque estamos levando mais tempo pra entregar do que o prometido."

— "Por que estamos demorando mais?"
— "Porque a transportadora está atrasando."

— "Por que a transportadora está atrasando?"
— "Porque a gente só despacha quando junta um lote mínimo pra baratear o frete."

— "Por que precisa de lote mínimo?"
— "Porque o contrato com a transportadora exige volume mínimo por envio."

Agora você chegou no problema real: o contrato com a transportadora. A solução pode ser renegociar esse contrato, trocar de transportadora, ou criar uma regra de despacho diferente pra pedidos urgentes.

Nenhuma cláusula de "prazo flexível" ia resolver isso. Ia só transferir o problema pro cliente e continuar gerando reclamação.

Na prática:

Você não precisa fazer exatamente cinco perguntas. Às vezes são três, às vezes são sete. O ponto é não parar na primeira resposta. Cada "por quê" te leva uma camada mais fundo.

Geralmente a solução real está duas ou três camadas abaixo do que te pediram.

Passo 4: Meça antes e depois

Você não precisa de dashboard sofisticado. Precisa de perguntas simples:

  • Quantas horas leva hoje? Quantas deveria levar?
  • Quantos contratos passam por mim por mês?
  • Qual % das reclamações é recorrente?
  • Quanto tempo entre a demanda chegar e eu entregar?

Se você não mede, não sabe se melhorou. E se não sabe se melhorou, não consegue mostrar valor.

Para se aprofundar: livros que recomendo

Se você quer ir mais fundo nessa mentalidade, esses livros são um bom começo:

  1. "The Mom Test" - Rob Fitzpatrick
    • Curtinho (120 páginas), super prático
    • Ensina a fazer as perguntas certas pra descobrir o que as pessoas realmente precisam (vs. o que elas dizem que precisam)
    • É exatamente sobre a mentalidade de questionar e validar antes de executar
    • Usado em Harvard, MIT, e em empresas como Shopify
  2. "Sprint" - Jake Knapp (Google Ventures)
    • Processo de 5 dias pra testar ideias antes de investir tempo e dinheiro
    • Passo a passo detalhado, fácil de seguir
    • Ensina a prototipar e validar rápido — exatamente o ciclo problema → hipótese → teste → aprendizado
    • Best-seller do NYT, testado em mais de 200 startups
  3. "Thinking in Bets" - Annie Duke
    • Leve, não é técnico, e ensina a tomar decisões melhores com informação incompleta
    • Escrito por uma jogadora de poker com background em psicologia cognitiva
    • Muito aplicável pro dia a dia de qualquer profissional
MATERIAL EXTRA · GRATUITO
Claude Code para Advogados: O Guia Completo

Material extra e 100% gratuito para você se aprofundar: aprenda a usar o agente de IA que lê seus processos, revisa contratos e organiza seu trabalho — sem virar programador. Leitura no navegador ou PDF pra baixar.

Baixar o guia grátis
NEWSLETTER · MENSAL
Receba os próximos artigos no seu e-mail

IA aplicada ao Direito, estratégia e gestão jurídica — direto da Priscila, sem ruído. Cancele quando quiser.

Mensal · Sem spam