Perguntar aos clientes o que eles querem não funciona

• Em discussões sobre roadmap de produto, vendas, marketing, P&D e os responsáveis pelo negócio falam todos sobre o cliente, mas, se deixam passar o trabalho (job) para o qual o cliente “contratou” o produto, o critério de decisão fica confuso
• A Intuit caiu em uma corrida por funcionalidades ao seguir 150 pedidos de recursos vindos de pesquisas, e não tinha uma bússola para distinguir quais recursos realmente importavam
• No caso do milk-shake, perguntas sobre sabor, preço e textura não aumentaram as vendas, mas, ao observar a situação de compra, ficou claro que o job central era o trajeto longo até o trabalho e a fome dos passageiros da manhã
• Mesmo sendo o mesmo milk-shake, de manhã ele compete com bagels, barras de proteína e suco; à tarde, compete com opções de lanche para dar à criança, então os critérios de avaliação e os produtos concorrentes mudam
• Para encontrar o Job to be done, é preciso observar problemas próximos, a escolha de não fazer nada, comportamentos de contorno, tarefas que as pessoas querem evitar e usos anormais

---

Por que pedidos de clientes não conseguem ser a bússola do roadmap

• Em reuniões de roadmap, chegam entradas sobre o cliente diferentes em cada departamento
  • Vendas acha que conhece as demandas mais urgentes porque conversa o tempo todo com os clientes
  • Marketing acha que pode criar novas versões, novos sabores, novas cores e ofertas especiais aproveitando a marca existente
  • P&D foca em funcionalidades e benefícios vindos de novas tecnologias ou aplicações
  • Os responsáveis pelo negócio querem lançamentos que ajudem o P&L até o fim do ano
• Cada abordagem tem certa validade, mas pode cair no viés de confirmação, vendo apenas as informações que sustentam sua própria perspectiva
• O problema maior é que nenhum desses modelos reflete diretamente o job do cliente

A perseguição por funcionalidades em que a Intuit caiu

• A Intuit realizou amplamente pesquisas perguntando quais novas funcionalidades os clientes queriam, e os clientes apresentaram longas listas de desejos
• Segundo Cook, então CEO da Intuit, os clientes pediam “150 funcionalidades”, e a equipe de desenvolvimento passou semanas discutindo quais eram mais importantes
• Todos no time acreditavam estar fazendo a escolha certa para os clientes, mas, na prática, não tinham critério de decisão
• Se você não sabe para qual trabalho o cliente “contrata” o produto, fica difícil separar as funcionalidades certas, e Cook comparou isso a navegar sem bússola

Por que as vendas de milk-shake não aumentavam

• Para vender mais milk-shakes, uma rede de fast-food chamou clientes que se encaixavam no perfil ideal de consumidor e fez perguntas
  • Se deveria ser mais barato
  • Se deveria ter mais pedaços
  • Se deveria ser mais mastigável
  • Se deveria ter mais sabor de chocolate
• Os clientes disseram o que queriam, mas não estava claro o que deveria ser feito com base nisso
• A rede tentou várias mudanças seguindo o feedback dos clientes, mas, meses depois, não houve mudança nas vendas da categoria de milk-shake

O job do milk-shake da manhã revelado pela observação

• A pergunta mudou para: “Para resolver que tipo de trabalho as pessoas vêm a este restaurante e contratam um milk-shake?”
• A equipe observou os clientes na loja durante 18 horas por dia
  • Quando compravam milk-shake
  • Que roupas usavam
  • Se vinham sozinhos
  • Se compravam outros alimentos junto
  • Se bebiam na loja ou saíam de carro
• Antes das 9 da manhã, vendia-se muito milk-shake, e os compradores normalmente vinham sozinhos, compravam apenas o milk-shake e iam embora de carro
• O job em comum dos clientes da manhã era aguentar um trajeto longo e tedioso até o trabalho e evitar a fome no meio da manhã
• Havia alternativas concorrentes, mas nenhuma era perfeita
  • A banana é consumida rápido demais e a fome volta no meio da manhã
  • O donut solta migalhas e deixa os dedos pegajosos, sujando a roupa e o volante
  • O bagel costuma ser seco e sem graça, além de exigir passar cream cheese ou geleia enquanto se dirige
• O milk-shake, por outro lado, por ser grosso e tomado com um canudo fino, leva mais tempo para ser consumido, ajuda a passar o tempo, mantém a saciedade ao longo da manhã e cabe no porta-copos

O mesmo produto compete de forma diferente dependendo do horário

• As pessoas contratam milk-shakes em dois momentos diferentes do dia, para jobs diferentes
• O milk-shake da manhã compete com bagels, barras de proteína e garrafas de suco fresco
• O milk-shake da tarde compete com a escolha de passar em uma loja de brinquedos para a criança ou ir para casa mais cedo jogar basquete
• Mesmo sendo o mesmo produto, quando o job muda, os produtos concorrentes e os critérios de avaliação também mudam

Cinco pistas para encontrar o Job to be done

• 1. Encontrar jobs perto de você

  • Mesmo em um mundo centrado em dados, parte das grandes inovações começa com uma intuição sobre o Job to be done
  • A Khan Academy começou porque Sal Khan queria ajudar a prima a aprender matemática sem estresse, e havia muitas pessoas com a mesma dor

• 2. Competir com a escolha de não fazer nada

  • Se o consumidor não encontra uma solução que satisfaça seu job, ele pode escolher não fazer nada
  • As empresas não devem olhar apenas para como tirar participação dos concorrentes existentes, mas também para onde está a demanda invisível
  • Segundo Chip Conley, responsável global de hospitalidade e estratégia da Airbnb, 40% dos “hóspedes” da Airbnb responderam que, se a Airbnb não existisse, não teriam viajado ou teriam ficado com familiares

• 3. Observar comportamentos de contorno e de compensação

  • O OpenTable surgiu de um antigo comportamento de contorno em torno de reservas de restaurante
  • Depois de alinhar horários possíveis com os amigos, a pessoa ligava para o restaurante; se não houvesse mesa, precisava repetir o processo de falar com os amigos e procurar outro restaurante
  • O OpenTable resolveu esse job de reserva

• 4. Encontrar tarefas que as pessoas não querem fazer

  • Clayton Christensen chamou isso de negative jobs, e jobs negativos podem ser uma boa oportunidade de inovação
  • O ex-aluno da Harvard Business School Rick Krieger e seus sócios criaram a QuickMedx depois de esperar horas no pronto-socorro para examinar a dor de garganta do filho, e ela se tornou a antecessora da CVS MinuteClinics
  • A CVS MinuteClinic atende imediatamente pacientes sem agendamento, e enfermeiros especializados podem prescrever medicamentos para doenças comuns, como conjuntivite, infecção de ouvido e dor de garganta
  • Como muita gente não quer ir ao médico se não for realmente necessário, a MinuteClinic se expandiu para mais de 1.000 unidades em lojas da CVS Pharmacy em 33 estados

• 5. Observar usos anormais

  • Se as pessoas criam por conta própria comportamentos de contorno ou compensação para concluir alguma tarefa, isso pode ser um sinal de que aquele job é importante e de que a frustração com as soluções existentes é grande
  • Esse tipo de situação pode levar a oportunidades de inovação de alto potencial

Perguntas melhores

• W. Edwards Deming disse: “Se você não souber fazer a pergunta certa, não descobrirá nada”
• A pergunta melhor não é perguntar ao cliente o que ele quer, mas sim: “Para que tipo de trabalho ele contratou aquele produto?”

[GN⁺]

Opiniões no Hacker News

• O erro clássico em gestão de produto geralmente começa ao presumir que o usuário sabe do que precisa. Na prática, isso é raro; descobrir a necessidade real é trabalho da área de produto.
  Até as pessoas realmente usarem o que está sendo construído, não há prova de que aquilo é o que elas querem, e também não se deve tratar o que o usuário pediu como se fosse necessariamente sua necessidade.
  Mesmo que a equipe de vendas diga “se não criarmos X, não vamos fechar o contrato”, depois de criar X pode não haver diferença nenhuma. A causa é que a análise de vendas estava errada.
  Especialmente em produtos novos, os usuários não os pedem primeiro; é preciso explicar e mostrar. O exemplo de que “quando o automóvel surgiu, os clientes queriam cavalos mais rápidos” se aplica aqui.

  • O problema é que ninguém investigou de verdade, e por isso acho que 80% dos responsáveis por produto têm efeito líquido negativo.
    Quando alguém pede alguma coisa, é preciso investigar o motivo. Se você vai a uma oficina e pede para trocar o alternador, e eles simplesmente trocam, você pode continuar insatisfeito; mas, ao perguntarem “por que precisa trocar?”, descobrem que o problema era o solenoide, e consertá-lo resolve o objetivo real: deslocamento.
    Por isso, muitas vezes um desenvolvedor sênior demonstra um senso de produto melhor do que alguém de produto. É difícil alguém que passou 1 ou 2 anos desenvolvendo, tirou uma certificação e migrou para produto superar a profundidade de um veterano.
    Seja qual for a premissa, se você não conversar e não investigar, vai acabar tomando uma decisão subótima.
  • Como contraexemplo da analogia dos “cavalos mais rápidos”, vejo o Segway. As pessoas talvez quisessem mesmo uma forma mais rápida de se locomover a pé pela cidade.
    Sou totalmente a favor de usar pesquisa com usuários para entender o espaço do problema e o espaço de funcionalidades, mas, na prática, vi muito mais gente criando Segways do que inventores de automóveis.
    É comum criarem algo com base na intuição do fundador ou em uma pesquisa de usuários péssima, e depois descartarem levianamente pedidos de clientes como “cavalos mais rápidos”. Não tenho tempo, energia nem vontade de me adaptar a um fluxo de trabalho personalizado acrescentado sob a premissa de que eu não conheço minha própria área de atuação.
    Deve haver uma diferença entre B2C e B2B, mas quase nunca vejo essa distinção quando esse tipo de conselho é aplicado. Sei que a intenção não é dizer para ignorar o feedback dos usuários, mas já vi essa interpretação tantas vezes que precisamos de uma nova metáfora.
  • Em resumo, é mais próximo de “não escute o que o cliente diz; observe o cliente”.
    Claro que não se deve aceitar isso literalmente, mas observar o comportamento costuma trazer mais insights do que perguntar ao usuário o que ele quer. Ainda assim, é preciso desenhar bem o ambiente de observação para saber o que se quer aprender.
  • Videogames também são um bom exemplo. Jogadores, especialmente em jogos de simulação, costumam sugerir muitas ideias que parecem legais no começo, mas não são divertidas.
    Por exemplo, algo como “deveria ser possível andar por dentro da nave espacial e fazer uma caminhada espacial para consertar o casco depois de uma colisão com micrometeoritos”.
    Por outro lado, também é comum empresas ou desenvolvedores aplicarem esse raciocínio em excesso e culparem jogadores que não se divertem com o jogo deles, como se estivessem errados.
  • O problema de acreditar sem filtro nas necessidades de clientes relatadas por vendedores é muito comum e difícil de impedir em nível organizacional.
    Como vendas é quem tem mais contato com os usuários, o gerente de produto normalmente tende a seguir o que eles dizem.

• Quando se trabalha muito com suporte por e-mail, é comum ver o problema XY disfarçado de pedido de funcionalidade. https://en.m.wikipedia.org/wiki/XY_problem
  Alguém pede uma funcionalidade e, em geral, ela até é fácil de acrescentar, mas antes tento entender o problema fundamental. Clientes muitas vezes não falam do problema; falam da própria solução, e essa solução pode ser uma abordagem ruim ou até totalmente errada.
  Para adicionar a funcionalidade de forma elegante, documentá-la e torná-la útil para outras pessoas, é preciso entender a dor real que ela resolve.
  “Encontre a dor e elimine-a” também é uma técnica de vendas poderosa. Às vezes, uma funcionalidade é adicionada por causa da dor interna da equipe de vendas, não do cliente, e acabam entrando recursos que clientes reais não usarão só porque um tomador de decisão acha importante e porque funcionam bem em uma demonstração.

  • Entre demandas vindas de dentro da organização, há algumas em que nem o lado de negócios consegue explicar direito por que quer aquilo, ficando no nível de “estamos marcando porque parece que precisa ser marcado”.
    Especialmente em substituições de software legado, sempre há pressão para migrar até um monte de tralhas que provavelmente já não são mais usadas e cujo custo de implementação é maior que o valor.
    Por exemplo, há pessoas do negócio que não conseguem abrir mão de gerar relatórios que ninguém de fato lê.

• O texto é bom, mas eu detesto o título. É preciso perguntar muitas coisas aos clientes, mas há muito pouco que se deve aceitar pelo valor de face.
  Implementar exatamente a funcionalidade que o cliente pediu é o caminho mais curto para o fracasso; é preciso continuar perguntando e investigando além de “me permita fazer X”.
  Para ser justo, o texto basicamente diz isso, mas estou cansado desse título batido.
  Concordo com as recomendações de Christensen e Deming, e gostaria de acrescentar Sidney Dekker. Em especial, "Field Guide to Human Error" é muito bom, e os outros livros dele também devem ser interessantes.

  • É preciso ouvir muito os clientes, mas quase nunca aceitar o que dizem pelo valor de face. A exceção são perguntas como “você vai assinar o pedido de compra agora?”.
    Uma das melhores maneiras de validar se a solução é real e se será vendida ao cliente é perguntar “você compraria isto agora?”. Se a resposta for “sim, envie a fatura e vamos processar o pedido”, algo foi validado.
    Por outro lado, se a reação for algo como “hmm, talvez, vou conversar com o comitê de compras”, você ainda está tateando.
    Mesmo que o produto ainda não esteja pronto e não seja possível chegar a uma venda real, como disse Steve Blank, dá para seguir com perguntas como “você pagaria um milhão de dólares agora?”, “então quanto pagaria?” e “se déssemos de graça, você adotaria imediatamente?”. Essas respostas mostram qual é a posição real disso aos olhos do cliente.
    https://www.amazon.com/Four-Steps-Epiphany-Steve-Blank/dp/09...
  • É preciso ouvir os clientes, aprender sobre o negócio deles e ajudá-los a melhorar. Perguntar e construir exatamente o que foi pedido é diferente de ouvir e sintetizar.
  • O título não me satisfaz muito. É difícil encontrar um título que chame atenção e, ao mesmo tempo, fique próximo da verdade; fico curioso para saber qual título seria bom.

• Pela minha experiência, os clientes não sabem o que querem. Por isso há um motivo para o fundador querer criar algo que resolva melhor aquele problema
  Eu detesto o conselho de “não construa antes de validar”. Para mim, literalmente nunca funcionou, e é como fazer perguntas indutivas enquanto dá um tiro no próprio pé
  É preciso ter convicção sobre por que você está fazendo isso. Se você é alguém que está entrando em um setor do qual não sabe nada, a probabilidade de fracasso é de 99%. Se você sabe o que está fazendo, a probabilidade de sucesso deveria ser de mais de 60%
  Produtos em que as pessoas entendem à primeira vista que o problema foi resolvido são fáceis de vender. Porque você já passou pelo mesmo problema e se propôs a resolvê-lo

  • Depende do que se quer dizer com “validação”. Para mim, validação é a existência do problema e quantas pessoas estão procurando algum tipo de solução
    Por isso acho que muitos sites que priorizam validação deixam a explicação da solução deliberadamente vaga
  • Você diz que “não construa antes de validar” não funcionou, mas, se você era alguém que sofreu o mesmo problema e estava tentando resolvê-lo, talvez isso já não fosse uma validação?
    Você era, em essência, o cliente arquetípico

• A citação batida de que “se Henry Ford tivesse perguntado às pessoas o que elas queriam, teriam dito que queriam cavalos mais rápidos” não virou clichê à toa. A maioria das pessoas não sabe o que quer, e é por isso que bons designers de produto recebem tanto
  O que é preciso distinguir é visão de produto de saber ouvir feedback
  Projetar um novo produto que resolva os problemas das pessoas não tem fórmula mágica; é uma habilidade que mistura experiência, intuição, compreensão técnica, observação das alternativas existentes e previsão de mudanças tecnológicas/econômicas/sociais
  Já ouvir feedback é verificar se aquilo que foi projetado funciona como pretendido, o que confunde os usuários e quais são os obstáculos. Aqui, métodos clássicos como observação de usuários, testes e pesquisas são úteis
  Parece fácil, mas não é nem um pouco. Já vi muitos designers que não cedem em seus princípios mesmo quando a realidade entra em choque com a ideologia, e empresas que inexplicably não corrigem bugs que afetam a maioria dos usuários e geram revolta em fóruns de suporte e redes sociais
  As duas habilidades são muito diferentes; já é difícil ser bom em uma, e ser bom nas duas é ainda mais difícil. O texto usa a Intuit como exemplo, mas deixa ao leitor a dinâmica de fazer um trabalho realmente excelente em um negócio que faz lobby junto ao governo para manter o veneno enquanto vende o antídoto

  • Ainda assim, a indústria global de criar cavalos mais rápidos continua bem grande. É muito menor que a indústria automobilística, mas é um nicho lucrativo

• Os clientes querem reduzir a dor de declarar impostos, enquanto a Intuit faz lobby junto ao governo para que essa dor continue forte

• A história do nosso produto atravessou todo esse espectro
  No começo, os bancos que eram nossos clientes só se interessavam por como viam o próprio negócio e por como nosso produto poderia melhorá-lo. Acumulamos ideias rapidamente sem nem saber o que estávamos fazendo e nos atrapalhávamos tentando atender até os caprichos mais triviais dos clientes. Sentíamos que não merecíamos o negócio deles
  Lá pelo meio do caminho, começamos a ter resultados e percebemos que, se criássemos o produto tentando satisfazer mais de dez clientes, cada um do jeito que queria, no fim não sobraria nada
  Hoje, nosso produto se parece mais com um pacote de consultoria turnkey do que com um software ou uma tecnologia específica. Agora os clientes nos procuram para orientar como devem operar seus negócios. Quando você passa a dirigir esse ônibus, consegue padronizar a stack de software com muito mais confiança. Recentemente, a palavra “tédio” entrou no nosso vocabulário
  O interessante sobre nossa base de clientes é que ela tem uma forte tendência a se mover em grupo. Se você consegue fazer apenas alguns deles se moverem em certa direção, o restante acompanha quase sem esforço. Não acho que isso se aplique apenas a banqueiros avessos a risco

• Uma armadilha comum que faltou no texto é dar ouvidos à minoria barulhenta de clientes
  Se você lesse apenas o Hacker News ou outras plataformas simpáticas à tecnologia, não seria estranho achar que havia uma demanda enorme por um iPhone pequeno e de alto desempenho
  Na prática, as vendas do iPhone mini foram decepcionantes. Isso significa que pessoas que passam muito tempo escrevendo online sobre hardware de tecnologia não representam a base total de clientes do iPhone

  • Não sei pelo critério de quem as vendas do iPhone mini foram decepcionantes. Ele vendeu mais que a maioria dos celulares Android e muito mais que as primeiras gerações do iPhone. O iPhone 3G, 3GS e 4 também foram decepcionantes?
    Uma participação baixa não significa que o número de unidades enviadas tenha sido baixo
    Realisticamente, qualquer empresa que você crie provavelmente venderá muito menos unidades que o iPhone Mini. Então, por serem vendas decepcionantes segundo os critérios da Apple, ela deveria demitir todo mundo e ir à falência? Todas as empresas que vendem menos de 20 milhões de unidades deveriam ser liquidadas? Empresas voltadas a uma base de clientes menor que os envios do iPhone pequeno não deveriam existir e deveriam ser substituídas por produtos medianos para pessoas medianas? O Mac Studio, o XDR Display e o MacBook de 15 polegadas de US$ 4.000 também deveriam desaparecer?
  • Quer dizer que foram decepcionantes pelos critérios da Apple, ou seja, apenas na casa das dezenas de milhões de unidades
    Conheço algumas pessoas muito satisfeitas com o iPhone mini, e agora elas não têm para o que fazer upgrade. Ainda assim, este lado é mais barato

• Se as pessoas soubessem resolver seus próprios problemas, não pagariam por isso
  Para fazer certas coisas no computador é preciso algum nível de habilidade técnica, mas a maioria pode ser resolvida seguindo regras e usando o Excel de forma criativa
  O valor vem de dar às pessoas um framework para resolver problemas, pensar por elas considerando até casos excepcionais nos quais elas não haviam pensado e então compilar esse sistema de regras em um programa

• Curiosamente, perguntar aos clientes o que eles não querem funciona de fato muito bem
  Perguntar aos clientes o que eles querem se parece com design por comitê. O que as pessoas querem é uma visão bem organizada e autoconsistente criada por um único artista, só que com algumas coisas removidas