Não, as pessoas não querem um buraco na parede

O que importa são as necessidades. O seu usuário não é responsável pela solução.

Não, as pessoas não querem um buraco na parede
Photo by Jane Utochkina / Unsplash
As pessoas não querem uma broca de 6mm, elas querem um buraco de 6mm.

Essa citação, do economista Theodore Levitt, é bastante conhecida no mundo de produtos e sempre utilizada para falar sobre resolver problemas reais das pessoas usuárias. Quem somos nós, meros mortais, para questionar, certo? Errado.

Embora parta de um raciocínio correto, a frase comete um erro comum na gestão de produtos, a falta de profundidade. O problema da pessoa que compra a broca não é a falta de um buraco na parede, por isso é preciso continuar questionando.

Ninguém acorda um dia e simplesmente decide: “Essa parede está muito lisa, preciso fazer um buraco nela”. Se você quer realmente resolver o problema, você precisa perguntar “Por que você quer um buraco na parede?”

Vamos imaginar algumas respostas possíveis para essa pergunta:

Cenário 1: Eu quero um buraco de 6mm para pendurar um quadro grande na parede do quarto.

Perfeito. Essa pessoa sabe o que resolve o seu problema (uma broca de 6mm), sabe como resolve (criando um buraco na parede) e sabe por que precisa disso (para pendurar um quadro).

Nem todos os usuários do seu produto serão assim tão assertivos.

Cenário 2: Eu quero um buraco de 6mm para observar as pessoas do apartamento vizinho.

Pronto, você não perguntou o motivo e agora é cúmplice de um crime. Nesse caso, a solução não é uma broca de 6mm, é uma ligação para a polícia ou, no mínimo, uma consulta psiquiátrica.

Exagerei? O próximo exemplo é mais realista.

Eu quero um buraco de 6mm para instalar a minha TV de 75 polegadas na parede da sala.

Razoável, uma broca pode ser uma opção. Mas será que buracos de 6mm são suficientes para suportar o peso da TV? Será que a pessoa comprou o suporte certo?

No caso mais comum, a pessoa quer pendurar um quadro na sala, instalar cortinas no quarto ou apenas um gancho para pendurar panos de prato na cozinha. Ok, mas em qual parede ela quer pendurar o quadro? Se for na que separa a sala do banheiro, talvez não seja seguro furar. Qual o tamanho do quadro? Se for um quadro pequeno, 6mm é muito, um martelo e prego resolveriam. E precisa mesmo furar a parede para pendurar panos de prato, quando já existem ganchos adesivos?

As furadeiras dos produtos digitais

Se você já trabalha com produtos há algum tempo, provavelmente já leu - ou escreveu - uma história como os exemplos a seguir.

Como usuário, eu quero preencher o formulário de cadastro para fazer meu cadastro no site.

Como usuário cadastrado, eu quero informar meu login e senha para acessar o site.

Essas histórias são como as brocas de 6mm de Levitt, pois “fazer meu cadastro” e “acessar o site” não são os problemas que precisam ser resolvidos, são soluções que podem ou não resolver um problema real - mas você não sabe, porque você não continuou perguntando.

Embora sejam necessárias, funcionalidades de cadastro e login têm pouco valor percebido pelas pessoas que as utilizam. Ninguém gosta de se cadastrar ou fazer login, tanto que o login social está cada vez mais comum. Ao se logar em um produto, a pessoa tem objetivos específicos que não estão relacionados com o login e que talvez possam ser atendidos de outra forma.

A história pode ser reescrita da seguinte forma:

Como aluno, eu quero acessar a área interna no aplicativo da escola para utilizar todos os recursos disponíveis para meu aprendizado.

Colocada dessa forma, a história se compromete com o resultado obtido por quem vai utilizá-la, não com uma solução específica. O login pode ser a ferramenta utilizada para alcançar o objetivo, mas outras soluções melhores podem surgir.

Outro exemplo, também muito comum.

Como gerente, eu quero fazer download de uma planilha de vendas para ter acesso aos dados.

Será que “ter acesso aos dados” é realmente o objetivo dessa pessoa?

Se você perguntar por que ela quer ter esse acesso, pode descobrir que a solução para a necessidade dela é muito maior ou muito menor do que um botão de download.

Pode ser que ela queira os dados para montar um relatório que será enviado para o CEO. Com que frequência ela faz isso? Como esse relatório é organizado? Há informações de outras bases de dados ou só das vendas?

Será que não seria melhor desenvolver uma automação que enviará o relatório pronto para o e-mail do CEO toda segunda-feira? Você só saberá se perguntar.

Os 5 porquês

Criada nos anos 70 por Taiichi Ohno, o pai do Sistema Toyota que virou referência para o desenvolvimento ágil, o método dos 5 porquês nos ajuda a detectar a causa raiz de um problema ao perguntar “Por quê?” quantas vezes forem necessárias. O 5 é um número de referência, mas pode variar com a complexidade.

No exemplo da furadeira, uma segunda pergunta já seria suficiente. Em outros casos, pode ser necessário insistir.

Quer um exemplo?

Problema: Ocorreu um erro ao tentar fazer download dos documentos.

Por que ocorreu um erro ao fazer o download? Porque os documentos não foram cadastrados.

Por que os documentos não foram cadastrados? Porque ocorreu um erro ao cadastrar.

Por que ocorreu um erro ao cadastrar? Porque o arquivo estava muito pesado.

Por que o arquivo estava muito pesado? Porque são vários documentos, mas a funcionalidade só me permite cadastrar 1, então eu precisei compactar em um arquivo único.

Por que a funcionalidade só permite cadastrar 1 arquivo? Porque o banco de dados foi modelado de forma a só permitir um arquivo por pessoa.

Solução: Alterar a modelagem do banco de dados para permitir que sejam cadastrados vários arquivos para a mesma pessoa.

Nesse caso, foram exatamente 5 porquês, mas eu poderia ter parado no quarto e deixado o último para a parte técnica. Por outro lado, se eu parasse no terceiro, a solução seria “aumentar o limite de tamanho do arquivo”, o que eliminaria um sintoma, não a causa raiz.

Pior, também poderia não perguntar nada e só mudar a mensagem de erro para ser mais informativa. Nesse caso, a pessoa precisaria buscar seus documentos de outra forma. Resolveria o erro, mas não o problema.

Quando parar?

O segredo e, talvez, a parte mais difícil, é saber quando parar. Se eu continuar perguntando, encontrarei alguma informação relevante? É melhor implementar uma solução “boa o bastante” ou pecar pelo excesso e continuar até ter certeza?

A regra dos 40-70, de Colin Powell, pode ajudar nessa decisão. Ela diz que você precisa ter, pelo menos, 40% de certeza sobre a decisão que irá tomar (ou seja, de que seus porquês foram respondidos). Por outro lado, se passar dos 70%, você estará perdendo tempo.

O livro “O teste da mãe” traz uma abordagem complementar ao dizer que quando as respostas são iguais, não há motivos para continuar a perguntar.

O seu ponto de parada também deve considerar seus prazos, orçamento e tolerância a riscos. Quanto mais baixa a tolerância e/ou quanto mais alto o impacto, mais perto dos 70% você deve chegar.

Conclusão

O “Por quê?” é a pergunta mais importante para uma pessoa de produto. A pessoa usuária não é responsável por nos dar a profundidade que desejamos logo na primeira resposta, nós é que somos responsáveis por procurar mais fundo. Cuidado com as soluções intermediárias que se disfarçam de problemas. Para criar soluções eficazes, não basta oferecer um buraco, você precisa conhecer as motivações das pessoas que utilizarão seu produto e ajudá-las a ter uma casa mais bonita.