Durante este meu período de aperfeiçoamento e de transição de carreira para produto, uma das principais “chaves” que mudaram no meu pensamento foi a reflexão sobre essa frase famosa:
“Não me traga problemas. Me traga soluções”.
Acredito que todos nós já presenciamos ao menos uma vez uma destas situações que são tão rotineiras no ambiente corporativo. Quero desenvolver este tema muito importante que já abordei em alguns posts. Vamos voltar para a frase que é a base deste artigo?
"Não me traga problemas. Traga-me soluções”.
Vamos imaginar uma situação com alguém levando um problema para o seu líder. Essa pessoa conta a história deste problema e como ele está impactando o andamento natural de algum processo. Já presenciei casos onde as pessoas são interrompidas e já questionadas sobre qual seria a solução. Neste cenário de busca imediata pela solução, pode ocorrer uma movimentação de pessoas, ligações e reuniões com stakeholders para conseguirem chegar em uma solução satisfatória para resolver o problema. Sabemos que muitas vezes isto é necessário já que temos o cliente aguardando por uma resposta o mais rápido possível. Após este processo todos respiram com “Ufa!! Missão cumprida”. Resolvemos o problema e o cliente está satisfeito”. Ok, mas este é apenas um cliente, ou seja, se o fator gerador do problema é desconsiderado outros clientes podem sofrer impactos causados pelo mesmo problema. O que vai acontecer? Mais uma vez ligações, reuniões e o mesmo processo para encontrarmos a solução ou é tomada a mesma decisão do processo anterior já que é uma situação similar. Tratamos o caso praticamente como uma jurisprudência.
Com isso, percebemos que existe um certo gasto de energia para as soluções, mas não para o entendimento do problema. É incrível como muitas vezes estamos em ambientes como verdadeiros bombeiros que estão sempre correndo para lá e para cá apagando incêndios e a real origem do problema é desconsiderada.
Na maioria das vezes é alegada a falta de tempo para entendimento do problema, mas será que já pararam para refletir que é muito mais vantajoso fazer uma imersão neste problema, trocar figurinhas com todas as partes envolvidas e entender o processo pode fazer com que o problema seja identificado e não nos assombre novamente? É... parece que não.
Se apaixone pelo problema
Por este motivo que se apaixonar pelo problema é tão importante. Jamais vamos ter uma solução adequada capaz de resolver definitivamente o problema sem nos apaixonarmos por ele. Precisamos entendê-lo profundamente, fazer pesquisas, colher dados, conversar com os usuários/clientes e entender todo o processo. Quando estudamos a fundo a jornada do cliente/usuário na empresa, conseguimos entender em qual etapa do processo está o problema. Desta forma, conseguimos desenvolver uma solução adequada e somos muito mais assertivos na resolução.
Hoje eu percebo que a equipe "Resolvedora de Problemas" com a expertise desta análise (em equipe sempre já que ninguém faz nada sozinho) é muito mais importante do que a equipe "Fábrica de Soluções". Lembrando que o erro sempre é aprendizado. Deve existir um ciclo de melhoria contínua. Não devemos ter medo de errar, colher feedback e melhorar.
Observando o mundo dos produtos digitais, sempre devemos questionar qual será o problema a ser resolvido para não ficarmos apenas entregando uma quantidade imensa de features que não resolvem o problema completamente, ou seja, não entregam valor.
Vamos fazer uma pequena analogia. Se você vai ao médico se queixando de uma dor, qual é o primeiro pensamento? "Ora...vamos acabar com essa dor". Você sai de lá com uma receita de um analgésico, a dor passa e tudo certo para você voltar para a sua rotina normalmente. Entretanto, na próxima semana após alguns dias de alívio você retorna com a mesma dor. Desta vez o médico irá lhe solicitar alguns exames para que a origem do problema seja investigada. Percebem a diferença? Imaginem se a investigação profunda do problema fosse realizada desde a primeira consulta, você e o médico poupariam seus tempos, haveria um colhimento de dados para entendimento do problema e tudo seria resolvido de maneira definitiva.
Seja inovador, ou seja, olhe o problema de um ângulo diferente
O livro “Comece Pelo Porquê” do Simon Sinek que estou lendo atualmente (que é fantástico) traz uma ótima reflexão sobre termos o nosso desempenho cobrado com base em substantivos e não sobre verbos, por exemplo: Não podemos cobrar inovação das pessoas. Se tentarmos engajar a equipe com “vamos ser inovadores” é claro que todos vão pensar “hum bacana, mas como eu posso ser inovador?”.
O ideal é “olhe o problema de um ângulo diferente”. Isto é a verdadeira inovação. Com isso nós entendemos o problema, o porquê e onde ele ocorre. Deste modo podemos trabalhar em equipe de uma maneira mais estruturada para chegarmos em uma solução mais adequada.
Ferramenta para entendermos o problema
Uma das principais formas de entender o problema é se colocar no lugar daqueles que são impactados, ou seja, ter empatia. Para ajudar nós temos o Design Sprint criado pela Google Ventures em 2009 é uma forma imersiva do Design Thinking.
O que é o Design Sprint?
Design Sprint é uma metodologia focada no usuário através de iteração, prática (mão na massa) e colaboração. O objetivo é criar e prototipar soluções de maneira rápida e eficaz. O Design Sprint oferece uma maneira de elaborar e testar a hipótese em uma semana. A ideia é testar rapidamente, colher feedback e turbinar o aprendizado.
Vamos para a etapas de maneira bem resumida:
Segunda-feira (entender e definir):
Neste primeiro dia a equipe deve expor para o time tudo o que se sabe sobre a ideia ou problema. Lembrando ser crucial a participação dos stakeholders neste processo como negócios, atendimento, desenvolvimento, UX e produto. O objetivo aqui é definir qual problema será resolvido.
Terça-feira (divergir):
Este é o dia de todos rabiscarem suas ideias. Primeiramente, trabalhamos individualmente desenvolvendo as possíveis soluções para o determinado problema sem muita discussão em grupo no momento. Após o término desta etapa, todos devem discutir e “vender” suas ideias. No final, todos os trabalhos são debatidos sendo decidido de forma democrática quais são as melhores ideias.
Quarta-feira (decidir):
Agora temos que decidir entre as melhores ideias qual será escolhida. Afinal, não temos tempo hábil para prototipar e testar a meia dúzia de ideias que provavelmente o time idealizou. É hora de refletir, filtrar e refinar para escolher qual será a ideia a escolhida para seguirmos com as próximas etapas.
Quinta-feira (Prototipar):
Nesta etapa nós temos que tangibilizar o que foi definido pelo time. É importante termos no final do dia um protótipo de média/alta fidelidade para ser testado e validado no dia seguinte. É importante que o protótipo seja desta forma já que ele será testado com o usuário e precisamos receber feedbacks com reações francas. Portanto, muito planejamento já que este deverá ser um dia muito produtivo (cronograma de hora em hora das etapas é interessante).
Sexta-feira (Validar):
Esta é a hora que vamos saber se a ideia desenvolvida é realmente boa. Vamos testar! O produto deve ser apresentado ao usuário para ele interagir e fornecer feedback em tempo real. No final do dia, a equipe se reúne para discutir o feedback dos usuários para confirmar se a solução teve êxito ou não.
Lembrando que é incrível se tudo funcionar maravilhosamente bem, mas por mais que possa ser frustrante caso o teste não dê certo, ao menos erramos rápido e podemos aprender com isso. Termos evidência de que algo não deu certo também é uma validação, certo?
É sempre muito importante compartilhar o conhecimento já que vejo esta como a melhor forma de aprender.
Comente aqui suas análises, reflexões e percepções.
Um abraço e até a próxima.
