O primeiro passo para se criar um novo produto de software é entender o problema. É bastante tentador, à medida que se vai entendendo o problema, já ir buscando soluções. É da natureza humana solucionar problemas.

Todo desenvolvedor de software tem alguma história para contar sobre demandas mais ou menos assim: “Então, eu preciso de um sistema que faça isso e aquilo, preciso ter um campo para eu digitar essas informações e ele deve ter um relatório que mostre isso aqui”. Aí, quando esse sistema é entregue, a pessoa fala: “Bem, já ajuda, mas agora eu preciso também de um campo para inserir esse outro dado, e preciso que o sistema exporte um arquivo .txt separado por vírgulas”. Em outras palavras, as demandas já vêm em forma de soluções e sequer mencionam qual o problema a ser resolvido.

Existem algumas técnicas para focar no problema:

Entrevista

É uma ótima forma de entender mais sobre o cliente, o problema que ele tem, o contexto onde esse problema acontece, e o que o motiva a ter esse problema resolvido. Contudo, é preciso ter cuidado, pois o entrevistado vai tentar dar a solução que ele já pensou para o problema. Você deve ser cuidadoso para não menosprezar a sua sugestão, mas deve sempre manter a conversa focada no problema.

A entrevista, na qual você conversa diretamente com seu cliente, é considerada um método qualitativo, ou seja, você faz algumas poucas perguntas, mas tem a oportunidade de se aprofundar nas respostas.

A seguir, está um conjunto de perguntas para ajudar a manter a conversa focada no problema:

• Conte-me sobre seu problema.
• Qual é a maior dificuldade que você tem em relação a esse problema?
• O que o motiva a querer ter esse problema resolvido?
• Onde esse problema costuma acontecer?
• Quando aconteceu pela última vez? O que aconteceu?
• Por que foi difícil / complicado / ruim?
• Você conseguiu achar uma solução? Qual(is)?
• O que você não gostou das soluções que achou?

Por exemplo, voltando à questão do carro e da carroça do Henry Ford, imagine um diálogo imaginário entre Henry Ford e um hipotético Sr. Smith, um possível comprador de seu futuro produto:

– Sr. Smith, o que mais o aflige?

– Sr. Ford, o que mais me aflige é que passo pouco tempo com minha família.

– E por quê?

– Porque passo tempo demais na carroça indo de um lado para o outro. Se eu pudesse colocar mais um cavalo puxando minha carroça, ela andaria mais rápido e eu passaria mais tempo com minha família.

– Ah, entendi seu problema, e tenho uma solução ainda melhor para você, chama-se automóvel.

Será mesmo que Henry Ford entendeu o problema? Ou ele entendeu a solução que o Sr. Smith apresentou para ele, e desenvolveu uma solução baseada na solução dada pelo Sr. Smith? Será que o problema real do Sr. Smith não era que ele passava pouco tempo com a família?

Vamos experimentar usar as perguntas mostradas anteriormente para ver se conseguimos entender melhor o problema:

– Sr. Smith, o que mais o aflige?
– Sr. Ford, o que mais me aflige é que passo pouco tempo com minha família.
– E qual é a maior dificuldade que o Sr. tem em relação a esse problema?
– Passo muitas horas no trabalho, indo de um lugar para outro, sem falar com as pessoas.
– O que o motiva a querer ter esse problema resolvido?
– Tenho crianças pequenas e, por causa do trabalho, passo muito tempo fora de casa. Quando chego em casa, meus filhos já estão dormindo.
– Onde esse problema costuma acontecer?
– No trabalho.
– Quando aconteceu pela última vez? O que aconteceu?
– Praticamente todos os dias. Aconteceu ontem. Acho que eu consigo chegar em casa a tempo de ver meus filhos acordados uma vez por semana…
– Por que foi difícil / complicado / ruim?
– Porque me deixou longe das crianças.
– Você conseguiu achar uma solução? Qual(is)?
– Saí mais cedo do trabalho.
– O que você não gostou das soluções que achou?
– O trabalho acumulou nos outros dias.

Note que essa conversa pode gerar como solução a invenção do carro para ajudar o Sr. Smith a chegar mais rápido em casa. Entretanto, poderia também ter sido a motivação para a criação de um processo mais eficiente de trabalho, ou de uma máquina que fizesse o trabalho pelo Sr. Smith.

Você pode ter uma solução em mente. Mas considere fazer uma entrevista real, concentrando-se nas perguntas para realmente entender o problema do cliente.

Pesquisa

Outra forma de se obter informações dos clientes é pela pesquisa. Esse método é considerado quantitativo, pois procura-se pesquisar uma quantidade considerável de pessoas para poder obter o que é conhecido como relevância estatística. Ou seja, para se poder confiar que o resultado obtido não tenha acontecido por acaso.

Por exemplo, caso você pergunte em uma pesquisa se uma pessoa tem iPhone ou Android, e só consiga duas pessoas para respondê-la, isto é, só duas respostas – quer sejam as duas iPhone, as duas Android, ou uma iPhone e a outra Android –, é muito difícil concluir qualquer coisa. Já se você tiver mais respostas, maiores as chances de o resultado de sua pesquisa refletir a realidade.

Existem ótimas ferramentas para se fazer pesquisa online, como o Google Form e o Survey Monkey. Existe também uma ferramenta brasileira chamada OpinionBox que, além de ajudar a construir seu questionário e coletar respostas, permite também que você selecione pessoas para respondê-lo baseando-se em critérios de definição de perfil que você especifica.

Pesquisas não precisam necessariamente ser feitas online. Pode-se também fazer uma por telefone ou ao vivo. Existem empresas que podem ajudá-lo a coletar as respostas.

Decidir fazer uma pesquisa é fácil, já fazer o questionário é difícil. O primeiro passo é ter bem claro qual é o seu objetivo com a pesquisa. Em seguida, crie suas perguntas tendo em mente duas regras principais:

1. Seja breve. Quanto menor o seu questionário, maiores são as chances de obter um bom número de respostas e garantir maior relevância estatística.
2. Seja claro. Principalmente em questionários online, quando você não interage com o respondente do questionário, são grandes as chances de a pessoa interpretar sua pergunta de forma diferente da qual você havia originalmente pensado. Uma boa forma de você testar seu questionário antes de disponibilizá-lo para obter um grande número de respostas é testá-lo com algumas pessoas ao vivo. Verifique o que as pessoas entenderam de cada pergunta, ou se tiveram dificuldade em compreender alguma parte dele.

Veja alguns exemplos de perguntas ruins que podem gerar interpretações equivocadas ou atrapalhar a qualidade das respostas obtidas, e sugestões de como essas perguntas podem ser melhoradas:

Pergunta original: Quão baixo era Napoleão?

Versão melhorada: Qual era a altura de Napoleão?

Pergunta original: Pais preocupados devem usar cadeirinhas infantis no carro?

Versão melhorada: Você acha que o uso de cadeiras especiais para crianças no carro deve ser obrigatório?

Pergunta original: Onde você gosta de beber cerveja?

Versão melhorada: Quebrar em duas perguntas: Você gosta de beber cerveja? Se sim, onde você gosta de beber cerveja?

Pergunta original: No seu trabalho atual, qual é seu nível de satisfação ou insatisfação com o salário e benefícios?

Versão melhorada: Quebrar em duas perguntas: Qual é seu nível de satisfação com seu salário em seu trabalho atual? Qual é seu nível de satisfação com seus benefícios em seu trabalho atual?

Pergunta original: Você sempre toma café da manhã? Respostas possíveis: Sim / Não.

Versão melhorada: Em quantos dias por semana você costuma tomar café da manhã? Respostas possíveis: Todos os dias / 5-6 dias / 3-4 dias / 1-2 dias / Não tomo café da manhã.

Observação

Uma outra técnica bem útil para entender o problema é a observação. Ver o cliente enfrentando o problema ou tendo uma necessidade, no contexto em que isso ocorre, pode ser inspirador!

A observação é uma forma qualitativa de se entender um problema. Para fazer uma boa observação, se prepare; tenha em mão um conjunto de hipóteses. A cada rodada de observação, reavalie as suas hipóteses e ajuste-as, se necessário. Normalmente, após umas 6 ou 8 observações, você já começará a encontrar um padrão.

A observação pode ou não ter a interferência do observador. Por exemplo, se você estiver observando hábitos de consumo em uma farmácia, você pode fazer isso sem que as pessoas notem que você as está observando. Já em um teste de usabilidade, no qual você convida pessoas a testarem seu software, as pessoas saberão que você as está observando. As observações podem ser complementadas com entrevistas, o que pode ajudar a melhorar a qualidade dos achados.

Uma técnica muito útil para descobrir problemas no uso do software é observar o que o seu usuário faz 10 minutos antes e depois de usá-lo. Por exemplo, se ele pegar informações em algum outro sistema para inserir no seu software. Talvez haja aí uma oportunidade para você já trazer essas informações do outro sistema de forma automática. E se, após usá-lo, ele copia informações para uma planilha para gerar algum gráfico, eventualmente seu software poderia poupar esse trabalho e já gerar esse gráfico para ele.

A observação geralmente é descrita como um método qualitativo. Mas você pode e deve tratá-la como uma observação quantitativa. Para isso, observe o usuário e algumas métricas importantes, como estatísticas de acesso e de uso, engajamento, NPS, receita, novos clientes, churn etc. Em outras palavras, é uma forma de observar o comportamento do seu usuário enquanto ele se relaciona com seu software.

Foco no problema vs foco na solução

Quando nos apressamos em lançar um MVP, estamos criando uma solução para um problema. No entanto, um passo muito importante para criar uma boa solução é o entendimento do problema.

É da natureza humana entrar no modo de solução quando aprendemos sobre um problema. Quando ouvimos sobre um problema, imediatamente começamos a pensar em soluções. No entanto, quanto mais tempo gastamos aprendendo sobre o problema, mais fácil será encontrar uma solução e há boas chances de que essa solução seja mais simples e rápida de implementar do que a primeira solução em que pensamos.

Aqui está uma ótima citação de Albert Einstein:

“Se eu tivesse uma hora para resolver um problema, passaria 55 minutos pensando no problema e cinco minutos pensando em soluções.”

Einstein acreditava que a qualidade da solução gerada é diretamente proporcional à sua capacidade de identificar e entender o problema que você espera resolver.

Deixe-me contar uma pequena história para ilustrar isso.

Durante a corrida espacial, os cientistas se depararam com a questão de escrever no espaço, onde não há gravidade para fazer a tinta cair em uma caneta esferográfica. Os americanos iniciaram seus esforços de P&D e, após algum tempo e alguns milhões de dólares, construíram uma caneta com um pequeno motor que bombeia tinta para o papel, mesmo sem gravidade. Enquanto isso, os russos decidiram usar lápis, que podem fazer o trabalho de escrever em ambientes sem gravidade.

Esse foco nas soluções, sem uma boa compreensão do problema e a motivação para resolvê-lo, pode ser bastante prejudicial. Isso pode nos fazer gastar tempo e dinheiro desnecessários para chegar a soluções abaixo do ideal. Essa é uma questão cultural, ou seja, um comportamento que podemos e devemos mudar. O primeiro passo para mudar um comportamento é reconhecê-lo quando isso acontecer. Quando você, como gerente de produto ou membro da equipe de desenvolvimento de produto, recebe uma solicitação para implementar algo, pergunta à pessoa que a solicitou qual é o problema que esse “algo” deve resolver e por que é necessário resolvê-lo.

Aqui estão alguns exemplos das empresas em que trabalhei.

Na Locaweb, um provedor de hospedagem de sites, os serviços de hospedagem e email podem parar de funcionar devido a fatores externos, como o domínio associado à hospedagem e ao email, não serem renovados.

Primeira solução: o Registro.br, o registrador brasileiro de domínios .br, lançou uma API para permitir à Locaweb cobrar o domínio do cliente em nome do Registro.br. No início, a ideia parecia boa, já que a Locaweb faturava o domínio como a maneira mais fácil de garantir que o cliente soubesse que precisava pagar pelo registro do domínio para manter os serviços de hospedagem e email funcionando corretamente. No entanto, quando analisamos mais profundamente, vimos que essa solução poderia gerar alguns problemas. O cliente seria cobrado duas vezes pelo mesmo registro de domínio porque o Registro.br continuaria cobrando o domínio. O que aconteceria se o cliente pagasse as duas contas? E se ela pagasse apenas o Registro.br? E se ela pagasse apenas Locaweb? Além disso, implementar um novo tipo de cobrança em que se cobra por um serviço de terceiros era algo novo para a equipe da Locaweb. Novos processos teriam que ser cuidadosamente projetados.

Solução implementada: começamos a pensar se haveria maneiras mais simples de resolver o problema de ajudar nosso cliente a não esquecer de que precisa pagar pelo registro de domínio no Registro.br. Como seria possível cobrar pelos serviços do Registro.br, foi possível acessar as informações sobre o domínio prestes a expirar. Decidimos criar uma solução mais simples: implementar uma sequência de comunicação com esse cliente, aconselhando- o sobre a importância de pagar o Registro.br para garantir que os serviços de email e hospedagem continuem funcionando normalmente. Essa é uma solução muito mais simples do que implementar um processo de cobrança dupla. Se o Registro.br nos fornecer o URL de cobrança, podemos enviar essas informações para o cliente e as chances de resolver o problema aumentarão ainda mais. E uma sequência de comunicação é muito mais simples e rápida de implementar do que um processo de cobrança duplicado.

Na Conta Azul, um ERP SaaS para MPEs (micro e pequenas empresas), usamos contadores como um de nossos canais de distribuição e queríamos aumentar as vendas por meio de contadores.

Primeira solução: compras em lote, onde os contadores adquiriam um número fixo de licenças da Conta Azul para revender aos seus clientes. Um sistema para gerenciar compras em lote levaria cerca de três meses para ser implementado, pois deveria permitir que os contadores comprassem licenças da Conta Azul em massa, mas só deveria começar a cobrar do cliente do contador quando ela realmente ativou a licença.

Solução implementada: os contadores não se importaram com as compras em lotes. O que eles queriam era oferecer um desconto a seus clientes para que eles pudessem assinar a Conta Azul com esse desconto exclusivo fornecido por suas contas. O custo para implementar isso foi zero, pois o sistema já tinha um recurso de gerenciamento de descontos.

Na Gympass, uma academia que estava ingressando em nossa rede de parceiros solicitou que apresentássemos seu termo de renúncia a todos os usuários que fizessem check-in em suas instalações.

Primeira solução: alterar nosso aplicativo para solicitar aos usuários finais que acessam este parceiro de fitness que leiam sua renúncia em nosso aplicativo e marque uma caixa informando que leem e estão de acordo.

Solução implementada: nenhuma alteração em nosso aplicativo. Use um campo de texto personalizável no ginásio configurado em nosso sistema que normalmente é apresentado aos usuários que fazem check-in nesse ginásio para apresentar o seguinte texto: “Ao fazer o check-in, você concorda com a renúncia localizada em http://fitnesspartner.com/termoderenuncia”.

Não me interprete mal, é muito bom que todos tragam soluções para a mesa sempre que quisermos discutir algo a ser feito pela equipe de desenvolvimento de produtos. Quanto mais ideias de soluções tivermos, melhor. No entanto, precisamos nos educar para termos uma compreensão mais profunda do problema por trás dessa solução, para que possamos encontrar soluções mais simples e rápidas para implementar. E, em última análise, é tarefa do gerente de produto e de todos os membros da equipe de desenvolvimento de produtos perguntar qual é o problema e por que precisamos resolvê-lo.

Concluindo

Para concluir este capítulo, vou fazer algumas considerações finais sobre essa fase de entendimento do problema, crucial para o sucesso do seu produto de software.

Deixei de lado, propositadamente, uma técnica chamada de focus group (ou grupo focal), em que reunimos um conjunto de pessoas (entre 6 a 15) para discutir sobre um determinado problema. É uma técnica tida como qualitativa, pois permite nos aprofundarmos nas questões que estão sendo discutidas.

Minha razão para deixar de lado é que, nesses grupos de discussão, existe um elemento forte de influência social, no qual pessoas mais assertivas e extrovertidas acabam dominando a discussão e polarizando a opinião do grupo. Na minha opinião, entrevistas individuais são de forma geral muito mais relevantes, a não ser em situações nas quais o que se queira pesquisar é exatamente a influência e a interação social do grupo.

Outro ponto importante a considerar durante sua descoberta do problema é quem são as pessoas que têm esse problema, e que características elas têm em comum. Além de entender muito bem sobre o problema, é muito importante conhecer para quem pretendemos resolvê-lo, e quais são suas motivações e seus anseios. Vamos falar sobre isso mais à frente; entretanto, é importante manter isso em mente durante o processo de descoberta do problema.

Uma pergunta que você pode estar se fazendo é “Por que é tão importante investir tanto tempo e esforço em entender bem o problema?”. A resposta é simples: desenvolver um produto de software é caro. Investir em ter uma boa compreensão do problema, das pessoas que o têm, do contexto onde ele ocorre e das motivações que as pessoas têm para vê-lo resolvido é essencial para não gastar tempo e dinheiro construindo a solução errada.

Por fim, como mencionei antes, os métodos não são excludentes, podem e devem ser usados em conjunto pois se complementam. Uma observação é bem complementada com uma entrevista. Os achados da observação e da entrevista podem ser confirmados (ou confrontados) com resultados de pesquisa e análise de métricas de uso.

Gestão de produtos digitais

Este artigo faz parte do meu livro Gestão de produtos: Como aumentar as chances de sucesso do seu software, onde falo sobre o que é gestão de produtos digitais, seu ciclo de vida, que ferramentas utilizar para aumentar suas chances de sucesso. Você também pode se interessar pelos meus outros dois livros:

• Liderança de produtos digitais: A ciência e a arte da gestão de times de produto
• Guia da Startup: Como startups e empresas estabelecidas podem criar produtos de software rentáveis