- Uma startup fez com que os próprios engenheiros participassem das calls de vendas, o que acabou mudando de forma fundamental a maneira como o produto era desenvolvido
- Durante as calls de vendas, eles perceberam que os produtos concorrentes eram complexos demais para usuários não técnicos e que os clientes, mais do que logs e métricas, queriam apenas uma confirmação visual (um check verde) de que o monitoramento estava funcionando, além de perguntarem simplesmente se “alguém não poderia fazer isso por eles”
- Com isso, uma equipe antes centrada no backend passou a entender a perspectiva do usuário e começou a conceber por conta própria uma nova arquitetura, sem intervenção de PM
- Em apenas 2 semanas, a plataforma teve 60% das funcionalidades removidas, ganhou uma barra de progresso, integração com Slack e um recurso de fluxo de trabalho feito para o cliente, resultando em 70% menos tickets de suporte
- A lição tirada dessa experiência foi que os usuários só querem que o problema seja resolvido e não se importam com código elegante, e que funcionalidades geram custo não em linhas de código, mas em confusão para o usuário
Contexto e experimento
- Um engenheiro sênior de DevOps era contra participar de calls de vendas, mas concordou com a condição de testar pelo menos 5 calls
- O fundador julgou que o design do produto só mudaria de verdade se os engenheiros ouvissem diretamente a linguagem e os problemas dos clientes
Insights obtidos nas calls de vendas
- Diziam que os produtos concorrentes eram complexos demais para usuários não técnicos
- Os clientes queriam algo intuitivo, como um simples check verde, em vez de métricas complexas
- Muitos clientes pediam um “serviço feito por nós”, querendo terceirizar a resolução do problema em si, e não apenas usar a ferramenta
Resultado da reescrita do produto
- A equipe removeu 60% das funcionalidades existentes e focou no essencial
- Adicionou uma barra de progresso simples para melhorar a experiência de uso
- Simplificou o fluxo de atendimento com integração com Slack
- Passou a oferecer um workflow done-for-you, refletindo diretamente a demanda dos clientes
- No fim, houve 70% menos tickets de suporte, com grande melhora na usabilidade e na satisfação com o produto
Principais lições
- Os usuários querem a solução do problema, não uma solução técnica elegante
- Entender o usuário é mais importante do que precisão técnica
- Toda funcionalidade traz um custo, não em código, mas em confusão para o usuário
Mudança na cultura da equipe
- Depois disso, a empresa tornou obrigatório que todos os engenheiros participem de 5 calls de vendas por trimestre
- Virou parte da cultura fazer com que os engenheiros ouçam diretamente o cansaço dos clientes e entrem em contato com a demanda de que “basta funcionar bem”, desenvolvendo assim melhor intuição de produto
Principais pontos dos comentários no Reddit
- Debate sobre o papel de PM
- Alguns apontaram que o problema era a falta de um bom Product Manager e argumentaram que fazer engenheiros participarem também de conversas com clientes é ineficiente
- Em contrapartida, houve quem respondesse que “PM acaba sendo só um tradutor, e os melhores resultados aparecem quando o engenheiro assume diretamente os problemas do cliente”
- O valor do contato com o cliente
- Vários comentários reforçaram que a experiência de o engenheiro ouvir diretamente a voz do usuário gera insights muito poderosos
- Também houve a opinião de que, em startups em estágio inicial ou em equipes pequenas, é comum que o engenheiro também assuma parte do papel de PM
- Visão crítica
- Houve críticas de que isso foi simplesmente empurrar para os engenheiros um fracasso de liderança/cultura
- Também apareceu a objeção de que “cortar funcionalidades e simplificar” talvez não seja necessariamente uma melhoria real, com alerta de que, no longo prazo, isso pode ignorar power users e demandas por recursos avançados
- Compartilhamento de casos positivos
- Muitas pessoas compartilharam experiências semelhantes em setores como banco e dispositivos médicos, onde havia políticas para que todos os funcionários vivenciassem suporte ao cliente e vendas
- Houve concordância de que “Dogfooding” e a experiência de estar diretamente diante do cliente ajudam a melhorar a qualidade do produto e a cultura da empresa
- Síntese das implicações
- Fazer as pessoas sentirem diretamente o problema do cliente é uma ferramenta de aprendizado poderosa,
- mas, ao mesmo tempo, o ponto central do debate foi que, no longo prazo, isso precisa ser combinado com competências profissionais de PM, UX e design para construir uma estratégia de produto equilibrada
Ainda não há comentários.