Falamos muito sobre métricas em gerenciamento de produto. Taxas de ativação. Funis de conversão. Duração das sessões. Mas há algo que ninguém gosta de admitir: a maioria das nossas métricas para na borda do aplicativo. Assumimos que o que acontece depois que uma funcionalidade é lançada é problema de outra pessoa. O suporte vai lidar com isso. A TI vai solucionar. A infraestrutura vai levar a culpa.
Mas se você já esteve em uma reunião em que alguém diz: “os usuários ainda estão reclamando” e você verifica seus painéis mostrando que tudo está funcionando como esperado, sabe exatamente do que estou falando. Algo está errado, e a equipe de produto não tem ideia do porquê.
É hora de aceitar que a experiência do usuário não termina com o que construímos. E se não encontrarmos maneiras melhores de ver o que realmente está acontecendo, não estamos realmente assumindo a experiência do produto. Só estamos otimizando a ilusão de uma.
A fricção invisível que ninguém assume
Existe uma dor específica quando um usuário clica em um botão e nada acontece. Não porque seu código está quebrado, mas porque o VPN dele está com problemas. Ou a extensão do navegador está bloqueando um script. Ou a rede está sobrecarregada durante uma videochamada. Você não verá isso nas suas análises de produto. Não perceberá no feedback do usuário a menos que ele seja muito paciente. Mas ainda assim é o seu produto que leva a culpa.
Essa é a fricção invisível. São questões que caem nas lacunas entre TI, design e produto. Não é um bug, mas parece um. Não é tecnicamente sua culpa, mas impacta suas taxas de adoção, NPS e credibilidade geral. E, na maioria das vezes, ninguém está acompanhando isso de uma forma que permita aos gerentes de produto agir.
Se os usuários sentem que algo está lento, dirão que a plataforma é lenta. Não a internet. Não o dispositivo deles. Sua plataforma. É isso que eles vão culpar. E de certa forma, eles não estão errados. Porque do ponto de vista deles, é tudo uma coisa só.
Por que gerentes de produto devem se importar com a observabilidade
Quando ouvimos “observabilidade”, geralmente pensamos em logs e tempo de atividade e no que as equipes de operações ficam de olho o dia todo. Mas há uma necessidade crescente de observabilidade no nível da experiência, e as equipes de produto estão perdendo isso.
Imagine poder ver:
Quais fluxos travam regularmente devido a navegadores desatualizados
Onde a latência está fazendo os usuários abandonarem os fluxos no meio do caminho
Com que frequência os funcionários alternam entre abas para buscar como usar sua ferramenta
Que tipo de problemas locais de dispositivo ou rede estão realmente impactando o uso
Esse é o tipo de insight que vai além das análises típicas de produto. Não se trata apenas do que os usuários fazem. Trata-se das condições em que estão fazendo.
E isso importa. Porque se sua funcionalidade está sendo usada em um estado degradado 30% do tempo, todos os seus dados de uso estão basicamente distorcidos. Você pode pensar que as pessoas não gostam dela. Talvez elas na verdade amem, mas só para alguns funciona corretamente.
A experiência do funcionário é a experiência do produto
Digamos que você trabalhe em uma plataforma interna. Você acabou de lançar um painel elegante que ajuda as equipes de vendas a rastrearem leads mais rápido. Passou semanas em revisões de design, testes A/B, até alguns workshops com partes interessadas. Tudo parece bom. Mas a adoção está mais lenta do que o esperado.
Você analisa o feedback e ouve coisas vagas como “é meio confuso” ou “eu geralmente só abro a versão antiga”. O que está acontecendo?
Acontece que, em alguns locais do escritório, o carregamento da página leva 9 segundos devido a um problema no proxy da rede. Ou talvez uma atualização recente de segurança esteja quebrando algum JavaScript. Ninguém te contou. Você não viu isso no seu Painel de Indicadores. E os usuários simplesmente voltaram silenciosamente ao que funcionava antes.
Aqui está a questão: seu trabalho não parou no lançamento. Ele termina quando os usuários têm sucesso. E se eles estão falhando por motivos que você não pode ver, você não está gerenciando um produto. Você está gerenciando uma caixa preta.
Movendo-se de feedback para insights em tempo real
Pesquisas e entrevistas com usuários são úteis. Assim como os tickets de suporte. Mas eles só contam parte da história. Os usuários nem sempre relatam os problemas. Às vezes acham que é só eles. Às vezes já desistiram.
Por isso, dados de experiência em tempo real são importantes. Eles fecham a lacuna entre percepção e realidade. Ajudam a entender não só o que os usuários dizem, mas o que eles estão realmente experimentando no momento.
Pense nisso como ter um pulso ao vivo em seu produto. Você não operaria uma máquina de alto desempenho sem um painel mostrando RPM, combustível, temperatura. Então por que estamos voando às cegas com ferramentas que as pessoas usam todos os dias para fazer seu trabalho?
O que as equipes de produto deveriam acompanhar (mas geralmente não fazem)
Somos bons em acompanhar coisas como:
- Adoção de funcionalidades
- Conclusão de tarefas
- Retenção
- Profundidade de sessões
Mas aqui estão algumas coisas que importam tanto quanto:
- Tempo para completar uma tarefa em condições reais (não em testes de laboratório)
- Frequência de erros ou tentativas causadas por problemas locais
- Número de soluções de suporte usadas por fluxo de trabalho
- Tempo perdido esperando páginas, aplicativos ou aprovações para carregar
Essas são as métricas que afetam diretamente a produtividade, a satisfação dos funcionários e a confiança nas ferramentas que construímos. E muitas vezes são invisíveis para a equipe de produto.
Liderança proativa de produtos
Quando algo quebra e os usuários reclamam, isso é reativo. Quando algo quebra e os usuários não reclamam — eles simplesmente param de usar — isso é perigoso.
Grandes equipes de produto não esperam pessoas reclamarem. Elas procuram fricções cedo. Constróem observabilidade em seu fluxo de trabalho. Trabalham com TI, UX e suporte para ver o quadro completo.
Gerenciamento proativo de produto não é apenas sobre visão e roteiro. É sobre reduzir a distância entre o que você acha que está acontecendo e o que realmente está.
Colaboração com TI é a peça que falta
Muito disso se resume a uma melhor colaboração entre produto e TI. Essas equipes geralmente estão em organizações diferentes. Usam ferramentas diferentes. Têm objetivos diferentes. Mas os usuários não se importam com essas linhas.
Se o aplicativo é lento por causa de uma configuração de rede, a TI pode ver isso. Mas a menos que o produto saiba, ninguém conecta os pontos a essa recente queda no engajamento.
Ao fazer parcerias mais estreitas, as equipes de produto podem ter acesso a ferramentas que medem condições reais. Coisas como saúde do dispositivo, erros de login, velocidades de conexão ou loops de falhas. Com esses dados, podemos fazer escolhas mais inteligentes, defender priorizações com evidências e lançar com mais confiança.
Resumo
Gostamos de pensar que estamos construindo experiências. Mas na maioria das vezes, estamos construindo funcionalidades e esperando que sejam bem recebidas. Essa esperança não é mais suficiente.
Se realmente queremos assumir a experiência do produto, precisamos vê-la — completamente. Isso significa ir além dos cliques e funis e mergulhar na experiência vivida das pessoas que usam nossas ferramentas.
Observabilidade não é apenas para TI. É a próxima fronteira da posse do produto. E quanto mais cedo abraçarmos isso, mais perto estaremos de construir software que não apenas funcione, mas de fato trabalhe para as pessoas no mundo real.
