Como escolher em que trabalhar quando tudo parece urgente
As 3 perguntas que uso para decidir em que trabalhar — e como elas me ajudaram a aumentar conversão em 26% em vez de desperdiçar meses em ajustes que ninguém pediu
Antes de começar qualquer tarefa hoje, responda três perguntas:
Quantas pessoas isso afeta e com que frequência?
Como vou saber se deu certo?
É a coisa mais importante agora?
Essas perguntas podem te salvar de desperdiçar o único recurso que não temos como recuperar: tempo.
Passei um tempo refatorando um componente de form na Brex. Era tecnicamente interessante, envolvia patterns legais, e quando terminei, estava orgulhoso do código limpo que havia escrito.
Resultado? Ninguém notou. Zero impacto mensurável. O componente continuou sendo usado da mesma forma.
Umas semanas depois, investiguei por que usuários abandonavam o fluxo de Bill Pay no meio do caminho. Minha hipótese: o formulário tinha campos desnecessários que criavam fricção. Removi alguns campos, ajustei a ordem de outros, e adicionei smart defaults com base no histórico para facilitar o preenchimento.
A conversão aumentou 26%.
Tempo de desenvolvimento parecido. Impacto drasticamente diferente.
A diferença? No segundo caso, eu escolhi trabalhar no problema certo.
✨ O que esperar do artigo
O framework de 3 perguntas que uso para decidir em que trabalhar
Como medir se estou trabalhando nas coisas certas (com exemplo real de 26% de melhoria)
Como balancear o que é urgente vs o que é importante
Como propor problemas para resolver vs só executar tickets
O artigo de hoje é patrocinado pela Contabilizei.
🧾 Consegui uma vaga PJ, e agora?
Se você trabalha ou quer trabalhar como PJ (especialmente para empresas internacionais), vai precisar de uma contabilidade confiável.
Desde 2020 uso a Contabilizei e nunca tive problema. O que faz diferença no dia a dia:
Rapidez para começar - CNPJ aberto em poucos dias. Essencial quando você precisa começar logo em uma vaga internacional.
Plataforma simples - Emitir nota fiscal leva 2 cliques. Consultar impostos é direto. Sem complicação.
Suporte eficiente - Quando surge dúvida (e vai surgir), eles respondem rápido e resolvem, com suporte até as 22h via whatsapp.
Para quem trabalha remoto, especialmente pra fora, ter uma contabilidade que funciona não é luxo - é necessidade básica. Você precisa emitir notas todo mês, pagar impostos corretos, e não ter surpresa da Receita Federal.
Conheça mais sobre os serviços deles aqui.
Por que engenheiros trabalham nas coisas erradas
A armadilha é sutil: você está trabalhando duro, entregando código, fechando tickets. Mas no final do ano, quando olha para trás, percebe que nada que fez realmente moveu a agulha.
Isso acontece por três razões principais:
Você escolhe pelo que é tecnicamente interessante - “Vou refatorar isso usando o novo pattern X” soa mais divertido que “vou investigar por que usuários abandonam esse fluxo”
Você trabalha no que grita mais alto - O bug que o CEO mencionou ganha prioridade sobre o problema que afeta mil usuários silenciosamente todo dia
Você não tem um framework de decisão - Sem critério claro, você escolhe pelo feeling ou pela última coisa que apareceu no Slack
Na Brex, eu via isso acontecer constantemente. Engenheiros excelentes tecnicamente trabalhando em coisas que não importavam. Não por falta de habilidade, mas por falta de clareza sobre o que priorizar.
A virada aconteceu quando comecei a fazer três perguntas antes de comprometer com qualquer trabalho.
O framework de 3 perguntas
Antes de começar qualquer tarefa, projeto ou refactor, responda:
1. “Quantas pessoas isso afeta e com que frequência?”
Escopo = Número de pessoas × Frequência do problema
Um bug que afeta 5 clientes enterprise todo dia é mais importante que um bug que afeta 500 usuários free uma vez por mês. Não porque os clientes enterprise importam mais, mas porque o impacto acumulado é maior.
Quando identifiquei o problema no Bill Pay, fiz as contas:
~1000 usuários iniciavam o fluxo por dia
~40% abandonavam no meio
Se eu aumentasse a conversão em 10%, seriam 100 usuários a mais completando o fluxo diariamente
Isso me deu clareza: valia a pena investigar.
Sinais de que você está trabalhando em algo de baixo escopo:
“Isso vai ajudar o time de X” (mas X é um time de 3 pessoas)
“Alguns usuários reclamaram” (mas você não consegue quantificar)
“Isso vai ficar mais limpo” (mas ninguém além de você vai mexer naquele código)
Um dos melhores jeitos de descobrir esses sinais é iterando rapidamente. Falo mais sobre isso aqui:
2. “Como vou saber se deu certo?”
Se você não consegue definir sucesso antes de começar, você está navegando no escuro.
Para o Bill Pay, minha métrica era cristalina: taxa de conversão do formulário. Eu tinha a baseline (métrica antes) e sabia exatamente o que medir depois.
Para o dashboard que criei quando entrei na Brex, as métricas eram:
Quantas pessoas do time acessam por semana?
As métricas estão sendo usadas em discussões de produto?
Conseguimos tomar decisões mais rápido?
Exemplos de boas métricas:
“Reduzir o tempo de X de 30s para 15s”
“Aumentar a adoção da feature de 20% para 35%”
“Eliminar 80% dos erros do tipo Y”
“5 pessoas do time usam isso semanalmente”
Red flags de métricas ruins:
“Melhorar a experiência” (vago demais)
“Deixar o código mais limpo” (não é outcome)
“Os usuários vão gostar mais” (como você mede “gostar”?)
3. “Isso é a coisa mais importante que posso fazer agora?”
Esta é a pergunta mais difícil porque força você a admitir o custo de oportunidade.
Quando você trabalha em A, você não está trabalhando em B. E talvez B seja mais importante.
Uso uma regra prática: se eu não consigo articular por que isso é mais importante que as outras 3 coisas no meu backlog, provavelmente não é.
Perguntas auxiliares:
“Se eu não fizer isso nas próximas 2 semanas, qual o impacto real?”
“Tem outra pessoa melhor posicionada para fazer isso?”
“Isso desbloqueia outros trabalhos importantes?”
Quando percebi que o refactor do formulário não desbloqueava nada e ninguém estava bloqueado por causa dele, ficou óbvio que não deveria ser prioridade.
Quando dizer sim (e quando dizer não)
Aplicar o framework é a parte fácil. A parte difícil é ter coragem de dizer não - especialmente quando a tarefa é interessante ou quando alguém importante pediu.
Diga SIM quando:
Alto impacto + mensurável + prioritário
Exemplo do Bill Pay:
✅ Afeta 1000 usuários/dia (escopo)
✅ Métrica clara: conversão do formulário (mensurável)
✅ Conversão era uma métrica-chave do time (prioritário)
Invisível mas estrutural
No PostHog, criei um arquivo CONTRIBUTING.md para o time de Surveys. Não era urgente, não tinha métrica sexy, mas:
Reduziria tempo de onboarding de novos membros
Centralizaria conhecimento tribal
Prevenção (melhor que remediação)
Trabalho invisível é legítimo quando tem impacto estrutural claro.
Diga NÃO quando:
Interessante mas irrelevante
“Vou reescrever isso usando o novo framework X” - a menos que o framework resolva um problema real (performance, manutenibilidade crítica), é distração.
Urgente para alguém, mas baixo impacto geral
O CEO mencionou um bug que afeta 0.1% dos usuários. É tentador priorizar porque veio do CEO. Mas se você tem coisas que afetam 50% dos usuários, essas vêm primeiro.
(Obviamente há exceções - se o CEO está numa demo importante amanhã, contexto importa. Mas a exceção não pode virar regra.)
Quando você não consegue medir sucesso
“Vamos melhorar a arquitetura do sistema” - ok, mas como? Se você não consegue definir sucesso antes de começar, adie até conseguir.
A regra dos 30%
Uma heurística que aprendi: se mais de 30% do seu tempo é apagando incêndios ou fazendo trabalho não planejado, tem algo estruturalmente errado.
Ou você está em um sistema frágil que precisa de investimento em resiliência, ou você está dizendo sim demais para coisas urgentes mas não importantes.
A solução não é ignorar incêndios. É perguntar: “por que esses incêndios continuam acontecendo?” e atacar a causa raiz.
Medindo sucesso: a história dos 26%
Deixa eu detalhar como foi a história do Bill Pay, porque exemplifica o ciclo completo.
O problema que identifiquei:
Olhando o dashboard que estava construindo (que eventualmente virou a ferramenta central do time), notei que ~40% dos usuários abandonavam o fluxo de Bill Pay no meio do caminho. Especificamente, começavam a preencher o formulário e desistiam.
A investigação:
Fiz três coisas:
Analisei em que campo as pessoas abandonavam mais
Comparei nosso formulário com competidores
Pedi para algumas pessoas do time tentarem usar (sim, dogfooding funciona)
Descobri: tínhamos campos desnecessários que criavam fricção. Perguntávamos informações que podíamos inferir ou buscar depois.
A hipótese:
“Se removermos os campos X, Y e Z, e ajustarmos a ordem dos campos restantes para criar um fluxo mais natural, a taxa de conversão vai aumentar.”
A implementação:
Removi 3 campos não essenciais
Mudei a ordem dos campos restantes
Implementei validação progressiva (mostrar erros mais cedo)
Usei feature flags para testar com 10% dos usuários primeiro
O resultado:
Taxa de conversão subiu de ~60% para 76%. Um aumento de 26%.
Isso significava ~160 usuários a mais por dia completando o fluxo. Em um mês, quase 5000 usuários a mais.
As lições:
Defini sucesso antes de começar - sabia exatamente o que medir
Comecei com dados, não com opinião - vi onde estava o problema real
Testei progressivamente - feature flags me deram confiança
Medi o impacto - números concretos que pude compartilhar
Isso virou uma história que contei em revisões de performance, em entrevistas, e que me deu credibilidade no time para propor outros projetos.
Como falei em outro artigo sobre medir impacto, números concretos transformam “eu trabalhei nessa feature” em “eu melhorei X em Y%, impactando Z usuários.”
Trabalhando com PM sem ser só executor
A grande virada na minha carreira foi quando parei de esperar tickets e comecei a propor problemas.
Modelo antigo (executor):
PM escreve spec detalhada
Você implementa exatamente como está escrito
PM valida e aprova
Você faz deploy
Modelo novo (product engineer):
Você nota um problema (ex: usuários abandonando fluxo)
Você traz dados e uma hipótese inicial
Você e PM discutem a melhor abordagem
Você implementa, mede, itera
Veja a diferença: no segundo modelo, você está resolvendo problemas, não executando soluções.
Como iniciar essa conversa
Script que funcionou para mim:
“Ei [nome do PM], notei que 40% dos usuários abandonam o Bill Pay no meio do fluxo. Analisei os dados e parece que temos campos desnecessários criando fricção. Posso investigar mais e propor algumas mudanças?”
Por que esse script funciona:
Traz um problema concreto (não uma solução)
Tem dados (não é feeling)
Pede permissão para investigar (não já chegou com a solução pronta)
Mostra ownership (você tomou iniciativa)
O PM pode responder:
“Sim, investiga” → você virou dono do problema
“Não, temos prioridades X, Y” → você entende o contexto maior
“Interessante, mas vamos focar em Z primeiro” → você aprende sobre priorização
Qualquer resposta é boa. Você saiu de “executor de tickets” para “pessoa que identifica e propõe soluções.”
O que PMs realmente querem
Conversando com PMs na Brex e PostHog, percebi um padrão: eles querem alguém que entende o problema, não alguém que apenas implementa a solução.
PMs não têm todas as respostas. Eles têm contexto de negócio e usuário. Você tem contexto técnico e de implementação.
A mágica acontece quando esses contextos se encontram.
Exemplos reais de colaboração:
PM diz: “Precisamos de relatórios customizáveis”
Você questiona: “Que problema os usuários estão tentando resolver? Talvez um template com 5 opções mais usadas resolva 80% dos casos”PM diz: “Precisamos melhorar performance”
Você pergunta: “Qual parte específica? Tempo de carregamento? Responsividade? Isso afeta qual fluxo?”PM diz: “Usuários reclamaram da busca”
Você propõe: “Posso adicionar tracking para ver exatamente onde eles travam? Assim sabemos se é relevância dos resultados ou velocidade”
Você não está sendo difícil. Está sendo um engenheiro de produto.
Quando você não tem um PM
Em times menores ou startups early-stage, talvez você não tenha um PM dedicado.
Nesse caso, você precisa desenvolver o músculo de product thinking sozinho:
Fale diretamente com usuários (ou leia feedback de suporte)
Entenda as métricas de negócio que importam
Faça as 3 perguntas do framework antes de cada decisão
Teste suas hipóteses em pequena escala primeiro
No PostHog, engenheiros são esperados a pensar como donos de produto. Isso não é sobrecarga - é liberdade para ter impacto real.
🌟 Resumo
Use o framework de 3 perguntas antes de qualquer trabalho: Quantas pessoas afeta? Como vou medir sucesso? É a coisa mais importante agora?
Defina métricas de sucesso ANTES de escrever código - se você não sabe como vai medir, não comece ainda
Seja proativo em propor problemas - não espere tickets aparecerem, identifique e traga problemas você mesmo
Diga não estrategicamente - se mais de 30% do tempo é apagando incêndios, tem algo estrutural errado
Trabalhe COM PM, não PARA PM - você tem contexto técnico que eles não têm, use isso
Seu desafio para essa semana
Pegue seu backlog atual (ou sua lista mental de “coisas para fazer”) e:
Liste todas as tarefas - tudo que você está considerando fazer
Aplique as 3 perguntas em cada uma:
Quantas pessoas isso afeta e com que frequência?
Como vou saber se deu certo?
É a coisa mais importante agora?
Escolha a top 1 baseado nas respostas
Descarte ou adie conscientemente as outras
Documente sua decisão. Na próxima revisão de performance, você terá clareza sobre por que trabalhou no que trabalhou.
E se você ainda não tem um sistema para medir o impacto do seu trabalho, comece simples: antes de começar qualquer coisa, anote “como vou saber se deu certo?”. Depois, volte e compare.
Como aprendi na prática: não é sobre trabalhar mais, é sobre trabalhar nas coisas certas.
Espero que tenha gostado do artigo de hoje!
Peço desculpas pelo sumiço nessas últimas semanas. Acabou que finalizar a tier list e mais outras coisas da vida me consumiram bastante tempo.
Espero estar de volta com o nosso cronograma regular semana que vem!
Ficou alguma dúvida? Pode responder esse email diretamente ou postar algum comentário no Substack! Eu leio todos.
Se esse artigo foi útil pra você, curta ou compartilhe ele com alguém. Me ajude muito. E se você indicar a newsletter para mais pessoas, você também ganha recompensas.