Forçaram todos os engenheiros a participar de calls de vendas e, em 2 semanas, a plataforma foi totalmente reescrita

• 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

[meteorizer]

No fim, é uma questão de eficiência.
Há realmente muitas vantagens em alinhar diretamente com o cliente, mas, por causa da comunicação frequente como reuniões e ligações, a continuidade do trabalho é interrompida com frequência e o tempo que pode ser investido no desenvolvimento acaba diminuindo.
Nesse caso, a empresa provavelmente terá de planejar contratações para lidar com a queda de produtividade.
O problema é que, na maioria das vezes, ela não tem essa intenção.
No fim, pela falta de tempo, é muito provável que a qualidade se deteriore com o passar do tempo.
Acho que é preciso considerar bem os prós e os contras.

[laeyoung]

Não sei por que deixaram isso como um link do old reddit no Hacker News, mas o caminho para a interface atual do reddit está aqui.

[xguru]

No Hacker News, parece que a maioria posta URLs do Reddit usando o old reddit. Acho que é porque ele é mais leve.

[cnaa97]

Se a meta de uma organização é elevar o piso, reconheço que faz sentido uma estrutura organizacional por função, como uma equipe formada apenas por desenvolvedores de frontend web ou uma equipe de desenvolvedores de apps.

Mas, em equipes ou organizações que buscam elevar o teto, estruturar-se por funções inevitavelmente tem limitações.
Como no texto principal, surge a dúvida: será mesmo necessário que planejadores, designers, PMs e engenheiros assumam cada um a sua parte e trabalhem como uma esteira de fábrica? Em vez do trabalho típico de "responsável por X", em que cada um cuida apenas de algumas tarefas específicas, o ideal é que pessoas com especialidades em diferentes áreas se reúnam, definam juntas um objetivo comum e que todos os membros deem suporte.

Muitas empresas montam organizações no formato de task force, com spin-offs ou formação de equipes, mas, como isso também acaba agrupando apenas pessoas (funções), surge o reforço negativo ineficaz — padrões como "estou tentando fazer algo, mas a empresa não me ajuda; então melhor desistir". Por isso, para não acabar perdendo apenas talentos importantes, como membros-chave, organizações orientadas por propósito também precisam necessariamente do suporte ativo de organizações por função.

[GN⁺]

Opinião do Hacker News

• No fim, eles conceberam uma arquitetura totalmente nova sem o meu “PMing”. O motivo foi que finalmente passaram a entender de verdade quem realmente usa o nosso produto. Olhando para a experiência como um todo, a conclusão é: “quando colocamos engenheiros para fazer calls de vendas, no fim o problema era que os PMs não estavam conseguindo comunicar direito entre clientes e engenharia, e o engenheiro de DevOps acabou sendo a pessoa que transformava mais rápido as necessidades do cliente em uma solução funcional”
  • Às vezes o engenheiro está tão confiante que acha que o usuário está usando o produto errado. A lógica é: isso aconteceu porque “o usuário agiu como idiota”, não porque haja algo errado no design complexo que eu criei. Só o pessoal do Desktop Linux já poderia escrever um livro sobre experiências de ignorar reclamações de usuários. Quando um engenheiro teimoso acha que é melhor do que o PM e do que o usuário, nada anda. Mas, quando você joga esse engenheiro para lidar diretamente com usuários, em vez do PM amigável de sempre, os usuários de verdade, irritados, detonam “essa criação maravilhosa” como se fosse um hamster cheio de problemas. Esse processo assusta, mas também destrói o ego do engenheiro. Do meu ponto de vista, isso não é para provar que o PM é burro, e sim para tornar o engenheiro mais humilde. Com o tempo, a arrogância do engenheiro volta, então esse processo precisa ser repetido periodicamente
  • Eu sou a única pessoa de uma equipe de engenharia mecânica numa grande empresa que sabe programar. A equipe interna de TI cria vários softwares, mas a maioria é vista como ruim pelo time. Então eu mesmo penso em refazer isso do zero, ou em criar ferramentas que complementem programas “ruins” que são impossíveis de substituir, para facilitar o trabalho. Não é tanto que eu desenvolva melhor do que a equipe interna de TI, mas sim que, por enxergar como usuário real, eu entendo melhor o que eu mesmo, ou seja, a nossa equipe, realmente precisa. E como sou eu quem usa esse software, naturalmente também tenho mais motivação. Por isso o título do texto falou comigo. Dito isso, também acho que o que o texto descreve pode acontecer tranquilamente no mundo real. Eu não tenho familiaridade com processos formais de desenvolvimento de software/gestão de projetos
  • Eu administro uma pequena startup de tecnologia com receita anual de 2 milhões de dólares. Às vezes, quando faltava gente no suporte, eu mesmo cuidava do atendimento ao cliente por alguns dias. E, toda vez, eu descobria um monte de reclamações de clientes que curiosamente nunca chegavam à equipe de engenharia. O pessoal de suporte tende a focar em “resolver” os problemas por conta própria, então melhorias estruturais acabam não chegando até a engenharia
  • Chama atenção que ninguém parece se perguntar por que o software estava tão ruim para começo de conversa. Na minha visão, não dá para colocar toda a culpa em um único PM. Na verdade, é um problema sistêmico de Agile/Scrum e afins, em que a responsabilidade fica difusa e os desenvolvedores ficam processando tickets mal definidos em ciclos rápidos demais, o que acaba gerando esse tipo de software meia-boca. É um resultado comum quando organizações de software “modernas” ficam inchadas
  • O primeiro pensamento que tive ao ler isso foi: “era assim que software era feito antes de os PMs se meterem em tudo”. Quando você coloca o engenheiro sentado ao lado de quem realmente opera a coisa, muitas vezes descobre que nem precisa de PM, e todo mundo fica muito mais feliz. Claro, existem PMs excelentes, mas, na minha experiência, PMs tendem a ser obcecados por disputa de território e, surpreendentemente, às vezes entendem pouco tanto de engenharia quanto do lado do cliente
• Já vivi várias vezes essa experiência de desalinhamento entre engenharia e produto. Já teve colega adicionando coisas sem avisar, deixando a UI confusa, ou conteúdo do site que não batia com o produto real. E também tem o loop longo de [produto -> PM -> sistema de rastreamento de bugs -> engenheiro -> correção -> QA -> produto], em que o importante até é corrigido, mas pequenos incômodos demoram uma eternidade para serem resolvidos. Se você deixar só [produto <-> engenheiro], dá para aumentar a produtividade de forma surpreendente. Muitos engenheiros sequer experimentaram de fato a experiência completa do produto, e muitas vezes nem sabem a diferença entre este ano e o ano passado
  • Também tive experiência parecida e, curiosamente, isso acontecia mais em lugares com muitos PMs. A pior experiência que tive foi numa empresa que tentou impor uma proporção fixa de PMs e “Product Designers” para igualar o número de engenheiros. Somando designers, produto, projeto e programa, havia mais gente nisso tudo do que engenheiros. No fim, só criou uma situação ainda pior. Também dava trabalho desviar da burocracia dos PMs e do medo que eles tinham de invasão do próprio papel. PMs excelentes são realmente valiosos, mas hoje em dia parece que o título de Product Management atraiu gente demais burocrática e obcecada por processo. Os influenciadores de Product Management também estão piorando o problema
  • Ainda assim, eu não acho que forçar engenheiros a entrar em calls de vendas seja a resposta certa. Conduzir uma ligação com sucesso exige várias soft skills, e engenheiros não são treinados para isso, nem isso costuma ser considerado na contratação. (Por “call de vendas”, quero dizer a conversa inicial antes de demo ou PoC. Em demos complexas de pré-vendas, o engenheiro pode até acompanhar, mas, em princípio, esse papel deveria ser de alguém de produto)
  • Existem muitas formas de isso dar errado, e eu já vi todas elas pessoalmente. Por exemplo, quando PM ou PO monopolizam toda a comunicação com o cliente, ou quando o cliente evita conversar com o desenvolvedor e só transmite interpretações das demandas do gerente de usuários, ou quando o próprio desenvolvedor quer apenas programar, ou quando se força toda a comunicação a acontecer apenas por PM e bug tracker, entre muitos outros casos. Além disso, ao usar plataformas comerciais de software, limitações técnicas podem tornar o workflow muito ruim. Sempre existe algum fator bloqueando a comunicação, e isso pode vir do cliente, da gerência intermediária ou do desenvolvedor. Há inclusive muitos casos em que a solução errada já foi decidida desde o começo e o desenvolvedor ou o usuário sequer conhecem os detalhes. Existem muitos caminhos para não conseguir construir um sistema realmente bom para o usuário
  • Acho realmente importante que engenheiros entendam profundamente o próprio produto. Fazer o lado do produto encaixar é mais difícil do que a engenharia básica. Como a maioria dos produtos que vivi acabou fracassando por razões ligadas a produto, faz mais sentido lógico concentrar a força da equipe nesse lado
• Por outro lado, também acontece de o engenheiro acabar sendo reduzido ao papel de equipe de suporte técnico. Quando você dá suporte direto a cada cliente, só vai acumulando hotfixes e soluções sob medida por cliente, nada disso é devidamente testado, a dívida técnica só cresce, e assim que aparece um concorrente grande, bem financiado, com um produto melhor, você fica para trás. Acho que isso é um fracasso clássico de gestão de produto. Quer dizer que o PM não consegue transmitir direito as necessidades do cliente para os engenheiros, ou também não consegue fazer pressão no sentido oposto. Colocar engenheiros em calls de vendas não escala quando a base de clientes cresce e amadurece. Se um gerente de produto realmente quer que o engenheiro faça calls de vendas, então esse engenheiro também deveria receber uma parte da comissão de cada conta. Eu jamais faria call de vendas sem comissão
• Em ambientes como startups, onde todos do time precisam ter empatia profunda com as necessidades do cliente, é uma estratégia excelente. A taxa de sucesso dos projetos foi muito maior quando eu participava da definição real dos requisitos do produto e entendia profundamente a operação. O resultado era muito melhor do que quando eu apenas “recebia” os requisitos e implementava como vinham
  • Você quer dizer que era mais fácil seguir porque você mesmo escreveu as diretrizes, ou que o UX saía melhor por você participar diretamente? Fiquei curioso
• “Rewrite concluído em 2 semanas, 60% das funcionalidades removidas, barra de progresso simples adicionada, integração com Slack construída, workflow ‘done-for-you’ oferecido -> 70% menos tickets de suporte”. Se isso for verdade, havia algo seriamente errado
  • O Reddit é famoso pela explosão de histórias inventadas, e este relato, seja inspirado em fatos reais ou totalmente fictício, está cheio daqueles elementos típicos de texto de Reddit com aquele tom de storytelling de negócios estilo LinkedIn
  • Eu vejo isso como um caso de B2B SaaS que passou por vários pivôs e ficou com pouca orientação relacionada ao produto. Claro, esse tipo de confusão acontece com muito mais frequência do que se imagina
  • Pelo tom de frases curtas estilo LinkedIn seguidas de desfechos dramáticos repetidos, dá para perceber facilmente que isso é ficção
  • É Reddit, então obviamente é ficção. Não entendo como esse tipo de post vira assunto desse jeito
• Se o resultado foi esse, então tem que demitir imediatamente PM, PO e toda a equipe de marketing. Duas coisas são claras: primeiro, essas pessoas ou não conseguiam entender o que os clientes realmente queriam, ou não conseguiam transmitir essas necessidades direito para a equipe de desenvolvimento, ou ambos. Segundo, elas estavam presas demais a um raciocínio sistemático, a ponto de talvez ser melhor eliminar todos os passos intermediários entre cliente e equipe de desenvolvimento
• No meu emprego anterior, os engenheiros também participavam regularmente de calls de vendas. Era interessante ver o que cada cliente queria e como o nosso produto era vendido, mas não foi algo revolucionário. As funcionalidades pedidas pelos clientes já estavam no roadmap, e havia uma funcionalidade confusa, mas ela havia sido desenhada assim por exigência específica do maior cliente. A equipe de desenvolvimento queria simplificar, mas, se fizesse isso, deixaria de atender a exigência desse grande cliente. No fim, foi criada uma versão “light” mais fácil de usar, e todos, exceto esse grande cliente, puderam usar essa versão. Mas essa mudança também não aconteceu por causa de acompanhar calls de vendas; todos já sabiam desde o começo que aquilo era difícil, só não podiam mudar até isso entrar no roadmap
• Me identifiquei muito com a parte de “finalmente passaram a entender quem são os usuários reais”. Costumam dizer que “o maior problema da maioria dos engenheiros é overengineering”, mas, na prática, muitas vezes o overengineering acontece porque eles não entendem bem os casos de uso do cliente. Esse é o problema mais essencial. Como engenheiro, a frustração que mais encontro é ver outros engenheiros nem tentarem descobrir qual é o produto que realmente vende. Seja por adequação ao trabalho, orgulho ou, na maioria das vezes, por cultura organizacional ou estrutura de incentivos
• Eu trabalhava numa empresa que fazia uma solução de robocall para CRM, e num evento off-site decidiram que todo mundo deveria fazer cold calls de verdade e seguir o script. Não havia nenhuma compreensão nem interesse pelo tipo de ansiedade que isso causava em quem não era de vendas. Depois disso, comecei a pensar em mudar de emprego
• Já vi uma situação parecida no passado. A equipe de monitoramento insistia que “todos os alertas deveriam ser registrados como tickets diretamente pelos engenheiros da linha de frente”. Só que eram mais de 10 mil alertas por hora. Como os incidentes importantes ficavam soterrados no “ruído”, a gerência também se cansou, e em certo momento foi imposto: “equipe de monitoramento, então vocês mesmos abram todos os tickets e resolvam”. No dia seguinte, ao excluir os alarmes de baixa prioridade, o número de alertas únicos caiu para algumas dezenas por hora, e o restante também foi sendo encerrado em sequência. Só então o “painel todo verde” passou a ser real (antes disso, era só um verde forçado para mostrar para a mídia e para o Gartner Group)