Do falhar ao aprender
O Nascimento de uma cultura de experimentos em time de produto
Por: Elisa Zanoni e Matheus de Lima Gonçalves Leite, do time da Sensorama Design
Disclaimer
Antes de começar, gostaríamos de sinalizar primeiro que todos os processos e abordagens que iremos destacar ao longo deste artigo NÃO É uma verdade absoluta que faz sentido em todos os cenários. Então, tenha muita maturidade para entender e reconhecer em qual contexto o seu time, produto ou empresa está inserida antes de ir implementando algo que possa vir descobrir aqui.
E claro, por outro lado este artigo É SOBRE os nossos aprendizados ao longo da tentativa de construir uma cultura de experimentos para assegurar que no final do dia possamos entregar um produto que gere valor para os usuários e negócios. É sempre sobre isso.
Sabendo disso, podemos começar. :)
Contexto
Junto ao squad de produto, somos responsáveis por projetar uma nova solução do sistema de gestão de promoção comercial, ou trade promotion management (TPM), para uma grande empresa de bebidas, de forma ágil, seguindo as necessidades de negócio e de engenharia.
O resultado esperado ao final do projeto é a entrega de uma ferramenta mais adequada para todos que gerenciam as promoções dos produtos que ocorreram ou irão ocorrer nas redes de supermercados em todo Brasil através deste sistema, tornando possível uma rotina mais eficiente e eficaz.
É justamente esse resultado esperado, que nos levou ao seguinte questionamento: como podemos mitigar ao máximo os riscos e validar a solução ideal para atingir os OKRs do negócio e facilitar o dia a dia do usuário?
Para respondermos esse e inúmeros outros questionamentos que surgiram ao longo do projeto, utilizamos a Opportunity Solution Tree, método criado por Teresa Torres que iremos detalhar na sequência.
Árvore de Oportunidades
Apresentada ao mundo na Productized Conference de 2016 por Teresa, é uma ferramenta para auxiliar times de produto a projetarem soluções que entregam resultados de maior valor para o negócio, organizar o discovery e facilitar o entendimento de todos os envolvidos no projeto sobre os objetivos e qual caminho será percorrido para chegar ao resultado desejado.
A árvore é composta pelos seguintes tópicos: objetivo, resultado chave, oportunidade, hipóteses de solução, solução, feature. Abaixo descrevemos em passos como essa ferramenta funciona.
Passo 1: Para começar a construir nossa árvore, auxiliamos o time de Business a definir qual seria o objetivo, aquilo que de fato eles querem alcançar como companhia.
Passo 2: Definimos o KR para compor o topo da nossa árvore (destacado em azul forte). É essencial ter métricas que possam medir e entender se o objetivo foi realmente alcançado.
Passo 3: Depois que tínhamos de forma clara o norte, definimos as nossas oportunidades com base em dores e necessidades levantadas em entrevistas, dinâmicas realizadas em workshops, dados do time de suporte. Ou seja, algo que nos traga benefício e nos ajude a atingir o objetivo. Neste momento em um nível mais macro, não necessariamente a oportunidade precisa estar relacionada com o time, produto ou empresa.
Passo 4: A partir do entendimento das oportunidades, realizamos um workshop de cocriação com time de negócio, engenharia, design e usuários tendo como objetivo gerar o maior número possível de hipóteses de soluções e continuar alimentando a nossa árvore. Neste momento, estávamos buscando quantidade e encorajarmos ideias diversas para desconstruir ao máximo os viesses sobre como atingir tal objetivo, para isso, recorremos ao “What If…”, um método que estimula a criatividade e permite visualizar diversas maneiras diferentes de possivelmente solucionar um problema.
Alguns dados sobre o nosso workshop: foram mais de 25 participantes ao longo de 2 encontros, realizamos 1 por KR, e mais de 80 hipóteses de solução.
Logo após esse momento de ideação, priorizamos as hipóteses mediante o método DVF (desejável, viável, factível), para posteriormente serem validadas ou invalidadas por meio de experimentos, como veremos a seguir.
Experimentos
São testes de conceito que devem ser realizados de forma simples, rápida e com o menor custo possível para validar ou invalidar algo. Neste caso estamos nos referindo a uma hipótese de solução, e eles nos permitem aprender e investigar a desejabilidade e viabilidade antes de investirmos qualquer esforço considerável, seja dinheiro ou tempo, por exemplo.
Existem diversos métodos para realizar esta investigação, e cada um deles poderiam facilmente ser um único artigo, não iremos abordar todos por aqui. Entretanto, independente de qual método, antes mesmo de começar a viabilizar o experimento, é importante definir e alinhar com todo o time quais serão os parâmetros definidos para validar ou invalidar a hipótese. Ou seja, o que seria sucesso para este experimento e faz com que deixe de ser uma hipótese e possa vir a ser uma solução para atingirmos o objetivo estabelecido.
Agora que demos um contexto macro sobre os experimentos, vamos aos que nós realizamos e adaptamos diferentes métodos para validar ou invalidar nossa hipótese de acordo com o nosso contexto*:
*Todo o nosso time de engenharia estava comprometido com uma outra grande entrega que tínhamos atuado anteriormente, não envolver a engenharia era um dos requisitos.
A hipótese: “E se…através da leitura do sell-out permitíssemos que os usuários aprovassem uma promoção executada pela rede de supermercado? Caso aprovada, essa promoção seria automaticamente cadastrada.”
Nossa primeira tentativa de validação: Fake door
É basicamente a criação de um banner ou botão, exibindo uma chamada para uma nova funcionalidade, sem que a funcionalidade esteja pronta de fato. Ao clicar o usuário comprova o interesse naquela feature.
Enviamos um e-mail para a base dos usuários indicando um resumo semanal de todas as promoções executadas pelas as redes que não estavam cadastradas no sistema e que caso ele reconhecesse aquela promoção, ela seria cadastrada automaticamente no sistema. Para saber mais, ele deveria clicar em “ver todas as promoções” que o redirecionaria para um formulário informando que ainda estávamos trabalhando naquela funcionalidade e um campo para deixar o e-mail se tivesse interesse na funcionalidade.
A nossa métrica: 70% dos nossos usuários irão deixar o e-mail para receber o aviso quando a funcionalidade estiver pronta.
No decorrer do experimento, identificamos que não estávamos aprendendo como deveria, e rapidamente pensamos em outra forma de experimentar.
Segunda tentativa de validação: Mágico de OZ
São utilizadas ferramentas para dar a impressão ao usuário de que ele está realizando uma tarefa automatizada, mas por trás existe uma pessoa operando sem seu conhecimento.
Enviamos uma mensagem via WhatsApp para a base dos usuários como se fosse um chatbot da empresa, indicando que tínhamos identificado algumas promoções nas redes de supermercado que não estavam cadastradas no sistema, e caso o usuário reconhecesse aquela promoção, ela seria cadastrada automaticamente no sistema. Para saber mais, ele deveria clicar no link que enviamos ao fim da mensagem que o redirecionaria para um formulário informando que ainda estávamos trabalhando naquela funcionalidade e um campo para deixar o e-mail se tivesse interesse na funcionalidade.
A nossa métrica: 70% dos nossos usuários irão reconhecer as ações e optar por cadastrar as promoções de forma automática no sistema.
Esse é um experimento que nos dá mais autonomia e agilidade para criar e colocar para rodar. Mas por ser um experimento que exige esforço manual, acaba ocupando um tempo maior para executar. Foi um experimento com maior engajamento que o anterior, acreditamos que talvez por ter sido em uma plataforma que faz parte do dia a dia dos usuários, além de ser uma notificação via celular. Mas ainda assim, não conseguimos cumprir o número mínimo de participantes para validar ou invalidar a nossa hipótese.
Terceira tentativa de validação: Survey
É um tipo de investigação quantitativa que pode ser definida como uma forma de coletar dados por meio de opiniões de grupos de indivíduos.
Conforme nossos experimentos isolados (até então falamos de dois aqui mas estávamos rodando outros em paralelo) não estavam cumprindo com o seu principal objetivo — aprender e nos apoiar na tomada de decisão se de fato aquela hipótese de solução contribui para o atingimento do nosso objetivo, optamos por consolidar todas as hipóteses priorizadas, e enviamos um formulário através do Typeform, com perguntas abertas e fechadas, para validação ou não de forma única.
A nossa métrica: 70% dos nossos usuários irão responder B na questão número 3 (obs: tínhamos diferentes métricas para cada grupo de questões do formulário).
Foi o experimento com maior número de engajamento, mas também não alcançamos o número mínimo de respostas que nos apoiaria na tomada de decisão de forma assertiva.
Conclusão
O principal aprendizado que fica é que de fato, se vamos atuar com uma cultura de experimentação, temos que contar com um ambiente seguro para erros. E isso passa muito por ter todo o time alinhado e comprometido com o objetivo principal, aquele em que começamos a trabalhar no topo da nossa árvore.
Como diria Peter Drucker: “A cultura come a estratégia no café da manhã”.
A verdade é que este foi o nosso real experimento, contendo outros pequenos experimentos para validar ou invalidar hipóteses de solução ao longo do caminho, fazer nascer uma cultura de experimentação no produto em que atuamos. Afinal, quando se trata de design de produto precisamos entender que nosso propósito não é somente facilitar a vida do usuário, mas também tão importante quanto, é gerar valor para o negócio.
A árvore é viva e foi construída com diversas pessoas e times, por isso, não poderíamos deixar de agradecer aqui a todo mundo que se disponibilizou e contribuiu de alguma forma.
Em especial (em ordem alfabética): Daniel, Fernanda, Heitor, Katherine, Larissa, Nana, Otavio e Sergio por co-criarem com a gente um produto mais eficiente e eficaz para gerenciar as promoções nas redes de supermercados em todo Brasil!
