Como transformei meu processo de discovery através da árvore de oportunidades
Neste artigo apresento como aplicamos aqui na OLX Brasil, o que aprendemos e os impactos nos resultados até aqui.
Todos nós, designers ou pessoas de produto, já nos perguntamos ao chegar em um novo contexto ou ao início de uma nova demanda: “Tá, por onde eu começo? Eu preciso de um discovery? Por onde começo esse discovery?”. Mesmo para designers experientes, com conhecimentos maduros de UX e de agilidade, pode ser um desafio conectar sua disciplina às necessidades do produto e do negócio, até porque, a gente entende de usuário e é treinado para resolver os problemas deles, né?
Cabo de guerra
Muitas vezes, nossa tendência como designers é tentar mapear todos os problemas de experiência que encontramos pela frente em nossos contextos e brigar para resolvê-los, um a um ou todos de uma vez. Com a mesma frequência, porém, acontece do Product Manager enxergar outras prioridades e as pessoas de Engenharia ainda outras e isso acaba resultando num cabo de guerra danado.
Discovery é um recurso limitado
Outra ponta desta discussão é que mapear problemas de experiência leva tempo (algumas coisas são visíveis, mas outras só se descobrem através de pesquisas e análises). Mapear todos levaria ainda mais tempo e uma vez que você tem muitos problemas mapeados, qual deles é o mais importante? Qual precisa ser resolvido primeiro? Seria sempre o que dói mais no usuário?
Você também talvez já tenha ouvido frases como: queremos fazer um discovery pra entender qual é a melhor experiência para “tal fluxo”, mas melhor com foco em quê? Como mediremos isso? Melhor com foco em conversão ou satisfação? Que impacto queremos trazer? E muitas vezes essas perguntas ficam sem resposta ou na esperança de que o próprio discovery as responda.
Fazer discovery sem um foco pode ser como procurar um brinco no meio do oceano, você pode nadar pra qualquer lado e não sabe por onde começar. E é observando os cenários citados que a árvore de oportunidades começa a ser útil.
Como conheci a árvore de oportunidades
Ao longo da minha carreira, sempre tive certa fixação em construir um processo meu de trabalho que fosse replicável, quase como um checklist para que eu não viesse a esquecer de nenhuma etapa. Eu sempre ouvia dos mais experientes que não havia receita de bolo, mas sabia que era possível construir um processo bem definido.
Depois de certo tempo, mais maduro, eu já dominava certos conceitos que me ajudavam nessa minha missão de evoluir meu processo, como “Design Thinking”, “OKRs” e bons conceitos de “metodologias ágeis”, mas eu ainda pensava muito sobre estratégia de produto e em como conectar melhor negócio, discovery e delivery, enxergando o tema ainda de forma bem complexa.
É preciso esforço para transformar coisas complexas em coisas simples e foi exatamente isso uma produteira de respeito chamada Teresa Torres fez. Descobri isso quando um amigo meu me mandou um vídeo chamado “Introduction to modern Product Discovery”, onde ela abordava temas como “continuous discovery” e a “Opportunity Solution Tree (OST)” ou somente “Árvore de oportunidades”, para os brazucas.
A árvore caiu como uma luva para mim pois ela simplificava e colocava nas caixas certos conceitos complexos que eu já carregava no meu cinto de utilidades.
Apresentando a árvore
Dito isto, a árvore tem a seguinte estrutura:
Resultado desejado
Tudo começa a partir de um resultado desejado.
Seu resultado precisa ser uma métrica, algo que você consiga medir o impacto de forma objetiva. Usar OKRs é uma boa nesse caso (Seu resultado desejado será um dos Key results).
Como estamos falando de ambientes corporativos, precisamos gerar resultados para o produto/negócio. Priorizar problemas sem considerar o impacto pro negócio seria apenas “filantropia”. Produtos digitais sempre têm uma proposta e uma captura de valor, por isso esta é nossa primeira ferramenta de alinhamento.
Lembram que falamos sobre o discovery ter um foco? O resultado desejado ajudará a criar os limites certos para o que você precisa descobrir e irá direcionar todo o esforço do time em um mesmo sentido. A primeira pergunta que eu costumo fazer na hora de planejar a estratégia é: “que resultado queremos alcançar?” e a segunda, que vai pautar seus discoveries é: “quais oportunidades podem impactar no meu resultado desejado?”.
Seguem dois exemplos de resultados desejados que estipulamos em dois times diferentes que atuei na OLX Brasil:
Oportunidades
As oportunidades são dores, desejos ou necessidades dos usuários que se forem solucionadas, nos levarão a atingir, total ou parcialmente, o resultado desejado.
Elas podem ter relações de irmãs ou filhas. As irmãs são problemas totalmente independentes, que podem impactar no mesmo resultado esperado, já as filhas são partes menores de um mesmo problema.
Veja que interessante: qualquer processo de design/discovery que você usar (jobs to be done, design thinking, design sprint, pesquisas com usuários…), será sempre sobre encontrar oportunidades ou validar hipóteses de solução para elas.
É importante que cada oportunidade tenha uma fonte real de dados (quanti ou quali) para que não se tornem apenas hipóteses de problemas. Eu costumo sempre colar o link da fonte no card da oportunidade na árvore, isso geralmente é útil depois.
Uma vez que você tem oportunidades suficientes, o ideal é que você priorize uma para solucionar (Caso precise pode procurar por técnicas de priorização), ao invés de tentar atacar a todas de uma vez (Veremos um dos motivos um pouco mais à frente). Sempre existem exceções/adaptações, mas priorizar problemas é uma prática importante na estratégia de produto.
Segue um exemplo de uma oportunidade que encontramos na OLX Brasil quando buscávamos reduzir tickets de atendimento sobre um fluxo de verificação de telefone:
Outro exemplo, com oportunidades filhas:
Hipóteses de solução
Para cada oportunidade você pode ter mais de uma hipótese de solução
Esta etapa você pode preencher com sessões de ideação, brainstormings e afins. Hoje eu costumo preferir apresentar a oportunidade e dar algum tempo (pode ser um ou mais dias) para as pessoas construírem nas suas hipóteses individualmente antes de se reunirem novamente, mas esse é assunto para um outro artigo.
Um template bem interessante para hipóteses é o seguinte:
Segue um exemplo de uma hipótese que montamos na OLX quando buscávamos reduzir tickets sobre verificação de telefone:
Experimentos
Para cada hipótese, você terá um ou mais experimentos para (in)validá-la
Experimentos podem ser testes de usabilidade, testes A/B, entrevistas ou qualquer método que coloque sua hipótese à prova o mais rápido possível pra gerar aprendizado. Se sua hipótese não funcionar, você pode escolher outra para a mesma oportunidade ou mudar de oportunidade se fizer sentido.
Um dos casos de aplicação na OLX Brasil
O que deu certo e o que nem tanto?
Segue um exemplo de uma árvore completa que montamos na OLX quando buscávamos reduzir tickets sobre verificação de telefone:
Montamos esta árvore analisando dados de funil, tickets de CX, montando um painel CSD, mapeando a jornada, entre outras coisas. Seus insumos podem vir de diversos tipos de fontes.
No caso desta iniciativa, escolhemos atacar algumas oportunidades de uma vez pois estávamos num momento de adoção do Design System o que propiciou um redesign do fluxo, porém essa abordagem é perigosa (apesar de ter sido um risco calculado). Se você trabalha com mais de uma solução ao mesmo tempo, você fica sem saber qual foi o impacto isolado de cada uma no seu resultado desejado. Pensamos em alguns mecanismos para isolar as hipóteses, mas na prática não foi possível aplicá-los.
Ainda assim os resultados que observamos no teste A/B da última entrega foram os seguintes:
- Aumento da taxa de sucesso em aproximadamente 1,5%
- Aumento da taxa de contatos dos anúncios de aproximadamente 2% (para fazer um contato, as pessoas precisam ter seus telefones validados)
- Ainda não vimos mudança relevante no índice de tickets. É possível que isso se dê pelo fato do novo fluxo ter sido testado apenas na web no primeiro momento, sendo que os apps são responsáveis por nosso maior volume de usuários.
Mais dicas de uso
- Você não precisa, nem deve, preencher a árvore toda de uma vez com hipóteses e experimentos. Você pode e deve priorizar uma oportunidade para solucionar por vez (sempre existem exceções).
- Durante o processo você pode mudar a oportunidade priorizada sempre que perceber que ela não vai funcionar como você esperava.
Conclusão
A árvore de oportunidades não é uma bala de prata, mas ela definitivamente pode te ajudar a estruturar seu modelo mental dentro de um cenário de estratégia de produto, a priorizar problemas e a direcionar o esforço do time em prol de um único objetivo. Ela é uma ferramenta de alinhamento fenomenal e um documento vivo da estratégia do time. Tenho certeza que ela pode ajudar a organizar diversos conceitos que você já tem aí na sua cabeça, assim como foi comigo.
Fontes
E pra não ficar só nas minhas palavras, deixo aqui alguns conteúdos dos quais eu bebi para amadurecer estes conceitos discutidos aqui:
Vídeo: “Introduction to modern product discovery” de Teresa Torres
Livro: “Continuous Discovery Habits” de Teresa Torres
Vídeo: “Why the secret to success is setting the right goals” TED de John Doerr
Minha Bio
Me resumindo, sou um designer carioca, na área desde 2013, apaixonado por produtos digitais, músico, amo humor, comida, tecnologia, praia, futebol e meu MENGÃO, Prazer, Kaio Sant’Anna. Você pode saber um pouco mais de mim no meu linkedin.
