- Produtos que ficaram complexos podem melhorar mais com a remoção de elementos desnecessários do que com mais explicações, como mostra o caso da calculadora de preços da Pinecone
- A calculadora de preços era um mecanismo para estimar previamente custos baseados em uso, mas pequenos erros de entrada podiam inflar o custo estimado em até 1.000 vezes, impedindo cadastros
- Internamente, tentou-se corrigir o problema adicionando explicações e valores padrão, mas cada ajuste gerava outra confusão, acumulando mais de 550 mensagens em um canal dedicado no Slack
- Em um teste A/B que removeu a calculadora, visitantes que não a viram tinham 16% mais probabilidade de se cadastrar e 90% mais probabilidade de entrar em contato, sem aumento nos tickets de suporte relacionados a preços
- Elementos adicionados uma vez tendem a permanecer mesmo quando seu valor diminui; por isso, é preciso avaliar conscientemente decisões de retirar grandes blocos de produtos, projetos e processos
Caso da remoção da calculadora de preços da Pinecone
- Como, em um modelo de preços baseado em uso, é difícil para usuários saberem com precisão o custo real de antemão, a Pinecone colocou uma calculadora de custos na página de preços
- Ao conversar com usuários em potencial, a empresa descobriu que alguns estavam desistindo de se cadastrar depois de ver estimativas de custo muito altas na calculadora
- O caso de uso em questão era relativamente pequeno para os padrões da Pinecone
- A calculadora era muito mais confusa e sensível do que se esperava
- Um pequeno mal-entendido ou uma entrada incorreta podia exagerar o custo estimado em até 1.000 vezes
- A calculadora dava uma falsa sensação de certeza aos usuários, que aceitavam o valor como se fosse o custo real, sem verificar a documentação, consultar a equipe ou validar por uso direto
- Como resposta rápida, foram adicionadas explicações, avisos de isenção, detalhes e valores padrão, mas a tentativa de reduzir uma confusão acabava criando outra
- A discussão interna também cresceu, acumulando mais de 550 mensagens em um canal dedicado no Slack, além de muito tempo gasto em reuniões e documentação
- Uma pessoa perguntou “a calculadora é realmente necessária?”, mas, no início, a pergunta ficou soterrada pela opinião da maioria
- Depois, foi realizado um teste A/B para verificar se o valor desapareceria ao remover a calculadora e os problemas causados por ela
- Visitantes que não viram a calculadora tinham 16% mais probabilidade de se cadastrar do que os que a viram
- A probabilidade de entrar em contato era 90% maior
- Não houve aumento nos tickets de suporte relacionados a preços
- Em uma pesquisa interna, 7 de cada 10 pessoas da empresa previam que a versão com a calculadora seria melhor, mas o resultado do teste mostrou o contrário
Por que remover é difícil
- Muitas organizações, ao resolver problemas, pensam primeiro em adicionar, não em subtrair
- Mesmo quando a remoção pode trazer grandes ganhos, ela dificilmente aparece como a escolha intuitiva
- Como pesquisa relacionada, é citado People systematically overlook subtractive changes
- Os sistemas de recompensa também costumam favorecer a adição de algo, enquanto incentivos para remoção são raros
- Como exemplo de que a remoção também deveria ser recompensada, é apresentado Negative 2000 Lines Of Code
- Quem defendeu fortemente a adição de algum elemento pode ter dificuldade em admitir que ele não agrega valor
- Tentar remover um elemento que outra pessoa defendeu pode parecer um ataque ao julgamento ou ao trabalho dela, então é fácil deixá-lo como está
- Muitas vezes se presume que algo já existente existe por um bom motivo, sem reavaliá-lo
- Quando as pessoas se acostumam ao estado atual, passam a resistir à própria mudança antes mesmo de considerar suficientemente a remoção
- A simplificação que corta elementos não essenciais com coragem pode levar a melhores taxas de resposta dos clientes, sistemas mais confiáveis, crescimento mais rápido e mais receita
- Em vez de pequenos cortes, é necessário escolher remover grandes blocos de projetos, produtos e processos; quanto maior a resistência da equipe à remoção, maior pode ser o ganho escondido
1 comentários
Opiniões do Hacker News
Não sei se essa calculadora era boa ou ruim, mas a justificativa parece, à primeira vista, bem sem sentido
É óbvio que as inscrições aumentam se você esconde dos usuários o fato de que o custo do produto pode ser alto. Se eles de fato ficaram em melhor situação depende de receberem ou não uma fatura desagradável depois, e isso não dá para descobrir com um breve teste A/B na página de inscrição
Também vejo com frequência casos do tipo: removeram informações do snippet dos resultados de busca e a taxa de cliques subiu. É claro que os cliques aumentam, já que agora é preciso clicar para ver as informações que antes estavam no snippet, mas acaba se esquecendo qual dos dois é realmente melhor
O dilema era “como corrigir esses casos?”, e a solução foi “vamos eliminar a calculadora bagunçada”. Não foi esconder um custo 1000 vezes maior, e sim evitar perder usuários por causa de uma estimativa errada 1000 vezes maior
Um exemplo são concessionárias de carros que dificultam verificar preços online e empurram as pessoas para e-mail ou visitas presenciais. Calculadoras facilitam a comparação de compras, e muitas empresas não gostam disso. Consciente ou não, é uma motivação a ser considerada
Ser transparente com o usuário inevitavelmente pode deixá-lo mais confuso. O próprio critério de comparação trata o usuário como gado estúpido que pode ser conduzido ao matadouro. Segundo esse critério, qualquer funcionalidade que trate o usuário como alguém que pensa acaba gerando confusão e prejudicando a conversão
Claro que a página de preços ficou horrível, mas isso deixou de importar porque “as inscrições estão aumentando”. Nesse caso, a calculadora podia ser intimidadora para quem não conhecia a terminologia, mas a decisão intuitiva deveria ter sido primeiro “como simplificá-la?”. Não gosto da cultura de testes A/B em que tudo precisa ser analisado e provado estatisticamente
Se o usuário nem fica por ali desde o começo, como testar depois se ele está satisfeito ou insatisfeito? Ao fechar o ciclo e aumentar o engajamento, também cresce a chance de educar corretamente o cliente e satisfazê-lo nas interações posteriores
Recomendei porque queria espalhar a grande sabedoria do texto, mas os limites podem ficar turvos rapidamente
A mentalidade de “se removermos esta parte, algo valioso desaparecerá?” às vezes saiu pela culatra em projetos iniciais. Especialmente porque é difícil estimar o valor futuro de código e dados
Certa vez, em um projeto novo, criei um schema SQL inicial com colunas extras de metadados para tags de posts, mas na semana seguinte um engenheiro sênior removeu tudo citando o princípio YAGNI. Como isso não estava no roadmap da época, tecnicamente ele estava certo, mas o trabalho original tinha levado cerca de uma hora, e o custo de manter os dados era praticamente zero
Um ano depois, quem acabou criando a funcionalidade que precisava daquelas colunas fui eu, e agora precisei refazer o mesmo trabalho, incluindo uma migração de banco de dados em produção com usuários. Por isso também é preciso pensar no inverso: “se removermos esta parte, algo valioso surgirá?”. No texto, a resposta era clara, mas no meu caso não foi
Lembro que a SpaceX tem uma métrica que captura um conceito parecido: a proporção de funcionalidades removidas que são adicionadas de volta pela segunda vez. Se todas as funcionalidades removidas forem adicionadas de volta, isso é uma taxa de reincidência de funcionalidades de 100%, então você está cortando coisas com frequência demais; 70% também é alto, e 30% também é alto
Mas 0% também é ruim. Se você não tenta remover funcionalidades desnecessárias o suficiente, acaba ficando inchado. No início do produto, parece bom que essa proporção seja mais alta e, conforme ele amadurece, caia para uma proporção baixa, mas não zero
Como não é possível saber, no momento atual, o conjunto exato de funcionalidades necessárias para o melhor produto, tudo bem adotar uma abordagem probabilística para cortar o que é desnecessário. Se precisar, adiciona de volta, e enquanto isso não acontecer com frequência demais, não há motivo para questionar a decisão inicial de remoção
Ou então, em vez de fazer os dois na prática e ver os resultados, dá para passar seis meses em reuniões discutindo métricas substitutas para hipóteses e crenças prévias não verbalizadas
Vira “posso usar? posso apagar?”, e alguém se lembra da Knight Capital, que reutilizou um campo antigo e causou um grande desastre. Então manter campos existentes passa a ser sempre a opção mais segura, e no fim aparecem
metadataemetadata_1. No ano seguinte, ninguém sabe por que há dois campos de metadados, e a confusão aumentaA pior base de código que já vi foi uma projetada com usos futuros complexos em mente. Mesmo neste exemplo, a base de código só precisou da coluna um ano depois. Por isso acho correto o precedente de remover todos os trechos de código que antecipam necessidades futuras. Mesmo que, no fim, voltem a ser necessários
Para uma pessoa, é otimização prematura; para outra, é “já vi um padrão parecido antes e vou adicionar algo que eu gostaria que existisse naquela vez”. Não parece haver uma forma confiável de distinguir qual lado está certo
A situação descrita tem, em linhas gerais, três resultados. Primeiro, o campo se torna útil exatamente do jeito que foi implementado inicialmente. Segundo, a funcionalidade é implementada, mas com outro campo ou outra implementação. Terceiro, a funcionalidade não é implementada
Mesmo atribuindo probabilidades iguais às três opções, ter construído isso desde o começo só é uma vitória em um terço dos casos. Se não tivesse sido removido, também é preciso considerar quanto custo cognitivo teria sido gasto nesse meio-tempo verificando se outras funcionalidades implementadas funcionavam corretamente com a coluna de metadados
Desta vez, isso significa que seu julgamento estava certo e que você tinha um ótimo entendimento do projeto, mas se a decisão foi correta deve ser avaliado com base nas informações disponíveis na época, não sabendo tudo em retrospectiva
O trecho “em uma votação interna da empresa, 7 em cada 10 pessoas acharam que a versão com a calculadora seria melhor” é interessante e mostra uma dinâmica típica.
No geral, o texto era bom, mas esse ponto merecia mais ênfase. Se 30% das pessoas envolvidas viam a calculadora como algo ruim, isso é um sinal de um problema potencialmente grande, mesmo que a maioria achasse tudo bem.
É preciso tomar cuidado com a política aqui. As pessoas normalmente não querem criticar outras equipes quando não há ganho político nisso. Então, se você pergunta à empresa “isso que a nossa equipe criou tem efeito líquido positivo?”, a resposta padrão tende a ser “sim”, para evitar criar confusão à toa.
Nesse contexto, se 30% apontaram a possibilidade de destruição de valor, isso é muito mais importante do que parece. É preciso investigar com bastante profundidade por que pensavam assim. Neste caso, essa preocupação de fato foi levada em conta e houve um bom desfecho, mas o resultado dessa votação já era evidência de um problema sério desde o início.
Quando há interesses envolvidos, fica ainda mais complicado. Vendas quer ativar todo tipo de dark pattern, enquanto o suporte ao cliente pode estar cansado de processar reembolsos porque uma garantia estendida foi adicionada automaticamente ao carrinho.
Achei engraçado o trecho do texto dizendo que remover a calculadora poderia ser melhor para o usuário porque mais vendas seriam concluídas. Talvez a escolha correta fosse o usuário levar o devido choque de preço e ir embora, mas isso foi ignorado.
Imagine que o código da calculadora seja uma bagunça em comparação com o restante do projeto, use bibliotecas antigas, quebre quando é atualizado, tenha vulnerabilidades de segurança, consuma recursos de forma anormal e estrague o sistema de build. Ninguém quer lidar com isso.
Se você pergunta nessa situação se é uma boa ideia, a maioria responderia “não” e gostaria que aquela bagunça fosse eliminada. Nesse caso, 70% é um número muito bom. Por outro lado, se for um recurso em que as pessoas gostam de trabalhar, 70% é um número realmente ruim.
Claro que eles podem ter pensado isso, mas é um salto bem grande. Talvez achassem que não faria muita diferença, ou supusessem que o desempenho era pior por causa de casos em que a calculadora dava respostas erradas.
A mensagem geral é interessante, mas essa parte me fez parar um pouco.
Quando diz que “com um pequeno mal-entendido ou uma entrada incorreta, a estimativa podia ser exagerada em até 1000 vezes”, isso significa que, no uso real, se você entender um pouco errado as métricas ou avaliá-las mal, acaba pagando 1000 vezes o custo planejado?
Em sistemas de cobrança online, isso é perfeitamente realista. Uma vez configurei mal um protótipo no GCP, achei que custaria uns 2 ou 3 dólares, e depois de alguns dias sem prestar atenção recebi uma fatura de mais de 100 dólares.
Quando você vê o preço estimado aumentar de forma absurda só por mudar um pouco um slider, dá para entender por que clientes desistem. Remover a ferramenta ajuda no cadastro, mas não ajuda clientes que vão se deparar com esse problema depois.
Um usuário achava que consultas por segundo eram calculadas como número de buscas × top-k de cada busca. top-k é o número de resultados que você quer receber de volta. Supondo top-k igual a 10, ele inseria em consultas por segundo um valor 10 vezes maior que o real e via uma estimativa cerca de 10 vezes maior que a cobrança real.
Outro usuário achava que o número de vetores era calculado como número de embeddings × número de dimensões do embedding. 1.536 é um número comum de dimensões, então o valor de entrada ficava literalmente 1.536 vezes maior. O uso real é calculado corretamente pela Pinecone, portanto a cobrança não ficaria tão alta.
O número de dimensões de vetores é um conceito básico para engenheiros de IA, e QPS é uma métrica básica para administradores de banco de dados, mas a Pinecone tem muitos usuários que são novos em IA, ou novos em administração de banco de dados, ou ambos.
O autor deveria seguir o próprio conselho. Deveria remover o “Psst... Get the next post in your inbox” que aparece no meio do texto e também o botão idiota que acompanha a rolagem.
Contei cinco formas de assinar naquela página. Será que precisam mesmo de cinco? Precisa enfiar isso na cara da pessoa no meio do conteúdo? Acham que interromper e irritar as pessoas aumenta o número de assinantes? É esse tipo de assinante que querem?
Remover algo geralmente é claro. Basta sair daquela mentalidade de buraco do tipo “mais, mais, mais; ganhar dinheiro; fisgar clientes” e pensar: “o que é correto para respeitar o usuário, e como posso ajudar tratando-o como ser humano, não como algo de onde extrair dinheiro?”.
É preciso lembrar que a maioria das empresas existe para ganhar dinheiro, não para proporcionar conforto aos leitores do HN.
O que significa respeitar o usuário é uma pergunta separada, embora não totalmente sem relação.
O fato de terem criado um canal dedicado no Slack, acumulado mais de 550 mensagens com opiniões de toda a empresa e gasto dezenas de horas em reuniões e milhares de palavras discutindo o que adicionar para consertar a calculadora é um sintoma de contratação excessiva.
Quando há gente demais, a iniciativa desaparece. Se vocês esquecem o que realmente importa e sentem que precisam chegar a um consenso por comitê, é porque há gente demais.
Design por comitê também fica limitado ao comitê.
Não seria melhor remover o próprio modelo de preços, já que ele é complexo demais para os clientes modelarem de forma útil?
Ou seja, quando a opção A custa x dólares e a opção B custa 10x dólares, se a maioria dos usuários acha por engano que precisa da B, a calculadora vira uma ferramenta que induz ao erro.
Eu até gosto bastante do modelo “preço sob consulta”. É irritante para usuários que querem ter rapidamente uma noção aproximada da faixa de preço, mas ajuda a identificar casos em que o preço-padrão, ou um preço difícil de explicar online, pode ser negociado. Também pode capturar situações em que o usuário simplesmente teria passado reto. Claro que não é adequado para a maioria dos casos de e-commerce.
Na nossa empresa há cerca de 250 produtos, e 5 deles respondem por 80% da receita.
As equipes de desenvolvimento desses 5 produtos mal conseguem acompanhar as correções de bugs e têm dificuldade para adicionar funcionalidades importantes e novas. Independentemente de quem peça, colocar algo no roadmap já é uma batalha impossível.
A empresa tem milhares de desenvolvedores, mas a maioria está alocada em produtos que contribuem muito pouco para a receita.
Para avançar, parece óbvio que o certo seria cortar a maioria dos produtos e reorganizar as equipes para impulsionar os principais produtos geradores de receita restantes. Mas isso não aconteceu, e não há sinais nem rumores de que vá acontecer. A política interna da empresa é realmente pesada.
Tenho uma experiência parecida. Em um site com vários produtos que pareciam bastante semelhantes, eu me preocupava que as pessoas tivessem dificuldade para decidir o que comprar e, por isso, acabassem não comprando.
Então criamos um applet de recomendação de produtos que, depois de o usuário responder a algumas perguntas, recomendava um ou dois produtos mais adequados. Deu um certo trabalho fazer direito, mas, depois de pronto, funcionava bem.
Colocamos no site e a taxa de conversão despencou. Um teste A/B mostrou claramente que ele prejudicava a conversão. Ainda não sei por que prejudicava, mas prejudicava de fato. Então o movemos da página inicial para a seção de FAQ, e quase ninguém passou a usá-lo.
Talvez as pessoas estivessem indecisas, e ele as poupou do trabalho de experimentar por conta própria e descobrir.
Se fosse um serviço, talvez funcionasse uma estratégia ao estilo Amazon Prime: a pessoa se cadastraria primeiro por não ter certeza e, depois, a empresa exploraria a falácia do custo irrecuperável. Ou, sem o applet, ela talvez se cadastrasse esperando que a versão mais barata fosse suficiente, mas o applet acabava com essa esperança imediatamente.
Se fosse um produto físico, talvez ele tivesse ajudado a evitar uma compra ruim.
Eu não esperaria que alguém procurasse isso no FAQ. Talvez no rodapé, mas não no FAQ.
É um estudo de caso interessante, mas sou cético quanto às implicações mais amplas. A Pinecone é conhecida por ser cara em comparação com outros serviços de banco de dados vetorial. Em uma comparação horizontal de preços, há várias opções melhores no mercado.
Remover a calculadora não resolve o problema central. Isso apenas torna os custos menos claros e dificulta que o usuário compare alternativas desde o início. Do meu ponto de vista, ao reduzir a etapa de comparação, aumenta-se a chance de que mais usuários com pouca informação façam upload de seus dados sem entender plenamente o impacto no preço.
Há casos em que simplificar tem valor, mas, neste caso, parece beneficiar mais a empresa do que o usuário. Em vez de eliminar totalmente a calculadora, talvez fosse melhor melhorar sua precisão e usabilidade. Especialmente em serviços B2B nos quais os custos podem crescer rapidamente, a transparência de preços é importante.