Perguntar aos clientes o que eles querem não funciona
Construtores de produtos argumentam que implementar diretamente os pedidos de funcionalidades dos clientes muitas vezes sai pela culatra, porque os usuários normalmente descrevem suas próprias soluções imaginadas em vez dos problemas subjacentes que precisam ser resolvidos. Em vez disso, os comentadores defendem abordagens como “jobs to be done”, observar o comportamento real, investigar as dores fundamentais e validar a disposição de pagar, ao mesmo tempo em que alertam contra dar peso excessivo a minorias vocais, política interna ou demandas pontuais movidas por vendas. A tensão central é entre respeitar a entrada dos usuários e exercer uma forte visão de produto para criar soluções que os clientes realmente adotarão e pagarão.
Limites de “Perguntar aos Clientes o que Eles Querem”
- Muitos argumentam que os clientes frequentemente descrevem soluções próximas ao que já têm, e não o que realmente ajudaria.
- Os pedidos são frequentemente contraditórios ou mutuamente exclusivos; as pessoas só percebem os trade-offs quando são pressionadas.
- Minorias vocais podem distorcer a demanda percebida (por exemplo, celulares pequenos, vestidos com bolsos).
- Alguns veem a ideia do título como algo usado em excesso como desculpa para ignorar necessidades legítimas dos usuários.
Foco em Problemas / Jobs-to-be-Done
- Há forte apoio para perguntar: “Que problema você está resolvendo?” ou “Para que trabalho você está contratando este produto?”
- Histórias do milkshake e do trajeto diário: melhorar o “produto” só fez sentido depois que o trabalho real foi entendido (café da manhã fácil enquanto dirige, trajeto mais curto).
- A mesma lente é aplicada a AirPods, Segway vs scooters, carros vs “cavalos mais rápidos”.
Observação vs. Questionamento Direto
- Observar usuários trabalhando (gravações de tela, acompanhá-los, reuniões de suporte) é visto como mais revelador do que desejos autorrelatados.
- Problema XY: os usuários descrevem a solução proposta por eles mesmos; você precisa aprofundar para descobrir a dor subjacente.
- No entanto, alguns reclamam que respostas excessivamente zelosas do tipo “você não quer X de verdade” podem ser irritantes quando X foi realmente bem pensado.
Visão de Produto vs. Feedback
- Faz-se uma distinção entre:
- Criação de produto visionária (intuição, pesquisa prévia, timing).
- Refinamento iterativo (testes de usabilidade, correções de bugs, fluxos confusos).
- Exemplos como telefones touchscreen mostram que ir contra preferências declaradas pode dar certo se a experiência geral for melhor, embora deslizes (sem apps/3G/copiar e colar) mostrem que a visão é falível.
Validação, MVPs e Experimentos
- Alguns insistem em “não construir antes de validar”; outros dizem que seu melhor trabalho veio de construir primeiro para seu próprio problema já conhecido.
- Validação pode significar: a presença de um problema doloroso, soluções improvisadas pelos próprios usuários, compromissos pagos ou experimentos rápidos e de baixo custo (fluxos manuais, alternâncias rápidas) antes da implementação completa.
Complicações Empresariais/B2B
- Comprador ≠ usuário: recursos podem existir apenas para satisfazer compras, conformidade ou checklists (por exemplo, SAML/SSO), mesmo que sejam raramente usados.
- Demandas de recursos impulsionadas por vendas (“não dá para fechar sem X”) são comuns; às vezes justificadas, muitas vezes erradas e caras na manutenção de longo prazo.
Conclusões Gerais
- Ouça amplamente, mas leve pouco ao pé da letra; sintetize em vez de implementar literalmente.
- Pergunte o que os usuários querem fazer, o que eles não querem e pelo que eles realmente pagariam.
- Ser um usuário real do próprio produto é citado repetidamente como uma bússola poderosa.