Entender de maneira profunda os problemas dos usuários e suas causas é uma das principais responsabilidades de um Product Manager. No artigo de hoje compartilho uma ferramenta clássica para se aprofundar nas causas de um problema.

Declarando o problema

Pode parecer até bobo, mas o primeiro passo é definir bem o problema. E um dos erros mais cometidos nessa etapa é embutir no seu “problem statement" umastatement uma possível solução. Exemplo: o elevador é lento.

A lentidão do elevador, só pode ser resolvida tornando-o mais rápido, o que envolve alterações mecânicas que podem custar uma nota. Enquadrar incorretamente o problema restringe as possíveis soluções. O problema, no caso citado acima, não é a lentidão, mas sim a espera. E isso muda tudo.

A definição que mais gosto de problema, é a necessidade de ir de A para B, ou seja, sair de um estado/situação A para um estado/situação B.

Olhando para diferentes aspectos

Com o problema declarado corretamente, “A espera pelo elevador é desagradável”, o próximo passo é recortar possíveis causas para esse problema considerando diferentes aspectos.

Podemos pensar, por exemplo, no equipamento, que aí, sim, envolveria o elevador em si. Então uma possível causa poderia ser a velocidade daquele modelo específicoespecifico de elevador.

Mas também podemos pensar no ambiente, já que, no nosso exemplo, não existe nada na sala de espera que diminua a sensação de que o tempo não passa (estou abstraindo o uso do celular aqui).

O elevador fica colado com a recepção, que nem sempre está ocupada, será que a equipe não poderia puxar um papo e aproveitar para conhecer mais o pessoal que frequenta o prédio?

Acho que já deu para entender onde quero chegar, certo? A ideia é fazer um exercício de olhar para diferentes contextos do mesmo problema.

Lembre-se, que aqui estamos falando de possíveis causas. Validar se essas causas são de fato as chamadas “causa raiz” exigem experimentação de hipóteses, teste e erro, etc. É outra história para outro artigo.

Diagrama de Ishikawa

O que acabei de apresentar para vocês nada mais é do que o Diagrama de Ishikawa, também conhecido como Espinha de peixe ou ainda Diagrama de Causa e efeito.

Por padrão, o Ishikawa é visualizada a partir do 6M:

• Máquina - são os equipamentos/ferramentas envolvidos
• Materiais - são os materiais utilizados
• Mão de obra - são as pessoas
• Meio ambiente - é o ambiente onde acontece o problema
• Método - são os processos envolvidos
• Medidas - são os indicadores

Ou seja, esses são 6 contextos “padrão”, prescritos pela ferramenta, mas uma dica valiosa é que nada impede você de utilizar outros aspectos. Se você tem um problema técnico, poderia separar em FrontEnd, BackEnd, infraestrutura, etc.

Aqui na empresafirma, usamos os 6M mesmo e tratamos muitasmuita vezes a “Máquina”o Máquina como sendo o produto. Como nosso produto envolve implantação e etc, faz sentido o produto ser apenas uma das possíveis causas, mas sinta-se livre para usar os contextos que quiser, o importante é usar mais do que um. O que importa é que usamos essa ferramenta para mapear possíveis causas dos problemas identificados e planejar ações a partir daí, sempre considerando múltiplos contextos.

Então, em resumo, o que você precisa fazer é gastar uma boa dose de tempo definindo seu problema, depois, recortar possíveis causas considerando diferentes contextos e partir para a exploração de cada uma dessas possíveis causas, ou pelo menos, das que parecerem mais promissoras.