Validação de Hipóteses e Experimentos

Hipótese deve ser uma das palavras mais faladas em publicações e cursos sobre Produto e, de fato, não tem como fugir: tem que gostar de hipótese e validação. O trabalho do time de produto gira em torno de gerenciar o desenvolvimento de soluções da maneira mais certeira possível e no momento mais certeiro possível. Assim, as hipóteses alinhadas à sua estratégia surgem como opções para tomada de decisão de qual funcionalidade deve ser implementada para que sejamos mais precisos na busca pelos nossos resultados naquele momento. E como vamos ser mais certeiros e evitar menos erros com funcionalidades que falham após lançamento? Validando-as.

A partir de um resultado almejado e uma oportunidade identificada, são inúmeras as ideias que podem surgir do que deve ser implementado para “turbinar” nosso produto. Algumas dessas ideias podem surgir como hipóteses e outras como funcionalidades já bem definidas por já serem validadas e terem um nível de confiança alto. Mas, como posso identificar que uma ideia já poderia ser considerada uma funcionalidade? Com dados. Sejam quantitativos ou qualitativos, os dados são o que norteiam a validação de hipóteses para decidir ou não pelo desenvolvimento de algo e nos ajudam a sair dos “achismos”. Mesmo que seja óbvio, procure ter base para definir as coisas. Além de conseguir acertar em cheio quando se tem base, perguntas vão surgir e você estará pronto para justificar as decisões tomadas. Nessa hora, um “a gente achou que…” já não funciona.

São várias as formas de se validar hipóteses no contexto de Produto e algumas das mais comuns são: Análise de dados, benchmarking, entrevistas e pesquisas com usuários e experimentos. Os famosos experimentos são os que mais causam dúvidas. Então vamos lá: quem são? onde vivem? o que comem? Vamos aprofundar mais neste assunto nos próximos tópicos.

O que são e o que não são experimentos?

Quando você possui uma hipótese e não possui dados para validá-la, os experimentos surgem como uma oportunidade para obtenção desses dados. Assim como as entrevistas/pesquisas com usuários, experimentos servem para ocasiões em que não existe uma base mínima para justificar uma implementação. Então, nem tudo requer experimentos? Isso mesmo! Eles são apenas um instrumento no processo de validação de hipóteses, mas existem outras formas de se trabalhar essas validações como uma simples análise de dados, por exemplo. Sendo assim, não é necessário “forçar a barra” para experimentar tudo, mas é necessário validar ao máximo aquilo que você pretende implementar.

Experimentos possuem data de início e data de finalização e devem ser formalizados com um objetivo claro. São vários os tipos que podem ser criados e, para construir um bom experimento, não fique preso às suas considerações. Procure seu squad, o time de design ou mesmo o time de negócio para ajudar você a pensar.

E por que devo optar por um experimento frente a possibilidade de apenas validar com o cliente por meio de pesquisa? O experimento simula a situação real que a funcionalidade iria gerar muitas vezes e pode trazer dados bem concretos com relação a isso, sendo uma evidência muito forte para validar suas hipóteses. Não que as pesquisas e entrevistas também não sejam, mas você poderá enfrentar riscos de compreensão errada por parte do usuário ou pode estar realizando contatos em excesso com ele.

Etapas do Experimento

Agora que sabemos que o experimento surge quando não possuímos dados para validação, quais etapas devem ser realizadas para formular ele?

1) Defina bem a hipótese que deseja validar

Compartilhe com o time a hipótese e verifique se está claro e se é isso mesmo que desejam validar.

2) Defina o que é necessário para validar essa hipótese

Uma boa maneira de definir o que é necessário é estruturar perguntas para depois definir quais dados seriam precisos:

a) O usuário está optando por ativar seu produto?

b) Em quais casos o usuário tem mais propensão a realizar a ativação?

É possível validar mais de uma informação por meio de um mesmo teste, mas pode ser que outro tipo de validação seja necessário. Por exemplo, se para o contexto também fosse necessário validar a satisfação do usuário:

c) O usuário que converte fica satisfeito ao optar pelo produto?

Partindo dessas três questões, agora vamos definir quais dados vamos utilizar:

a) O usuário está optando por ativar seu produto? % conversão

b) Em quais casos o usuário tem mais propensão a realizar a ativação? % conversão segundo características do usuário e/ou processo

c) O usuário que converte fica satisfeito ao optar pelo produto ao invés do original? NPS dos usuários que passariam pelo fluxo

Pode ocorrer que nem todos os dados sejam possíveis de serem obtidos por meio de um só experimento. Você pode necessitar, por exemplo, de um experimento para as perguntas a) e b) e outro para a pergunta c). É possível também que não seja possível obter todos os dados, mas não precisa entrar em pânico, alinhe com sua equipe se os dados que consegue obter são satisfatórios para gerar confiança na validação.

3) Crie o teste! Ou seja, elabore a forma que utilizará para conseguir colher esses dados

Agora creio que enfrentamos o maior desafio: como vou colher esses dados se isso não existe? Existem diversos estilos de experimentos já conhecidos no mercado que podem te ajudar a elaborar seu teste e iremos explorar um pouco deles em breve, mas não se apegue aos nomes. Assim como mencionado anteriormente, explore a criatividade e, junto de uma equipe, procure estruturar a melhor forma de testar a hipótese sempre focando em minimizar esforços.

4) O experimento pode impactar alguém? Alinhe o máximo possível!

Dependendo do experimento que está executando pode ser que ocorram impactos para outras entidades e alinhamento é fundamental para que não surjam atritos. Procure mapear o que pode ocorrer durante o experimento e entre em contato com aqueles que podem sofrer impacto.

5) Defina o período de testes e uma dinâmica para sua conclusão

O período depende muito da velocidade com que os dados tendem a ser gerados. Pode ser que um experimento possa ser validado em um dia com um contato com clientes reais, mas pode ser também que ele demore duas semanas de uma funcionalidade falsa obtendo informações organicamente. Porém, é importante definir seu fim até para que se consiga planejar próximos passos.

6) Pronto! Execute o experimento e acompanhe sua evolução

É importante verificar a evolução do experimento para identificar possíveis anomalias que não havia mapeado. Acompanhando o andamento do teste você consegue verificar isso e até mesmo expor o impacto posteriormente ao elaborar a conclusão dele.

Como você utiliza os testes de hipóteses?

Assim como qualquer outra dinâmica no mundo de Produto, devemos executar a validação seguindo uma ordem de prioridade. Não faz sentido sair fazendo validação para tudo que cair no seu colo, priorize as hipóteses que façam mais sentido e execute a validação para elas. Você pode executá-las priorizando principalmente impacto e noções de esforço para experimentação.

Quais os tipos de testes de hipóteses?

Existem diversos modelos de experimentos já formalizados no mercado que podem nos dar ideias de como encaixar algo na nossa realidade, mas uma dica é não se prender aos nomes. O que importa é conseguir os dados para realizar sua análise, se você vai implementar um experimento no modelo Mágico de Oz ou uma forma diferente de obtê-los que foi criada por você pouco fará diferença se ambos irão gerar as informações que você precisa.

a) Landing Page

O que acha de validar se o conceito da sua solução de fato parece gerar valor ao usuário? Por meio de uma landing page você pode apresentar seu produto e colher o interesse do usuário nele através das interações com a página.

b) Fake Door/Feature Fake

Como o próprio nome diz: trata-se de uma funcionalidade falsa com o intuito de apenas captar o interesse do usuário em utilizá-la. Deve-se tomar muito cuidado ao implementar um experimento como esse para que não cause muita frustração nas entidades que terão acesso a ele.

c) Testes A/B

A aplicação de testes A/B é muito diversa, não se prenda apenas ao cenário de se testar 2 páginas com aspectos diferentes. O que acha de testar a precificação por meio de testes A/B? Ou então a compreensão dos usuários com relação à uma nova proposta de onboarding frente à antiga? Existem diversas formas de se utilizar esses experimentos e é possível inclusive realizar validações sem necessidade de implementação mostrando as versões para diferentes amostras manualmente e colhendo feedbacks.

d) Concierge

Em um experimento de concierge simulamos a experiência que o usuário teria com o produto ou funcionalidade de forma manual e, nesse caso, o usuário sabe que humanos estão atuando para construir esse processo. O teste é utilizado para validar a construção da jornada que o usuário terá com o produto e se de fato a proposta de valor está bem construída.

e) Mágico de Oz

Assim como o experimento de concierge, trata-se de simulação da experiência do usuário criada de forma manual. A diferença aqui está com relação à percepção do usuário quanto a presença de pessoas na construção do processo: não deve ser perceptível. Basicamente, aos olhos do usuário ele enxergaria a funcionalidade funcionando como se todo o processo fosse super bem construído e automático. Mas, na verdade, estaríamos criando a interação através de envios de e-mail manualmente, alterações e registros realizados à mão em bancos, entre outros.

f) Card Sorting

Está com problemas para organizar hierarquia de informações e menus em seus produtos? O que acha de experimentar utilizando card sorting? Apresente aos usuários cartões com as mais variadas informações que você precisa organizar e deixe que ele defina o que de fato faz mais sentido ser agrupado, por exemplo.

Por meio desse experimento, conseguimos dados que podem fomentar um produto com uma melhor usabilidade e que faça mais sentido para o usuário com relação à sua organização.

g) Testes de usabilidade moderado e não moderado

Testes de usabilidade são experimentos propostos de forma a colher do usuário dados com relação ao seu comportamento frente os protótipos ou fluxos já criados. Ou seja, são disponibilizados ao usuário protótipos para que ele interaja e com isso possamos colher informações sobre fluxos que não estejam claros ou não façam sentido. É comum que tarefas sejam organizadas anteriormente e propostas aos usuários durante o teste, de forma a extrair as percepções desejadas. Nos testes moderados acompanhamos de perto a interação e conseguimos extrair mais informações por estarmos juntos das pessoas. Porém, um teste não moderado, apesar de não ter o mesmo benefício, pode requerer um esforço menor de mobilização e alcance maior de pessoas.

Boas práticas e aprendizados

Creio que o que mais vem à tona ao trabalhar com validações de hipóteses são aprendizados. Elas por si só geram aprendizados: é comum que uma hipótese gere outra por termos aprendido algo sobre o processo que não havíamos aprendido antes. É também muito comum vermos que erramos ao, por exemplo, executar um processo de validação que não deveria ser prioritário naquele momento ou mesmo executar um teste que não trouxe os dados que precisávamos devido à forma como foi construído. Mas, isso é normal! Vamos errar muito mesmo até conseguirmos construir o melhor processo de validação, e só com o tempo e erros é que vamos aos poucos melhorando nosso trabalho e adaptando ao nosso contexto o uso desses métodos que tendem a tornar nosso gerenciamento de produto cada vez melhor.

Tendo em vista a vivência com validações e o trabalho de colegas, creio que as melhores práticas que posso citar e que podem ajudar são:

a) Comece, não tenha medo: Tudo tem que ter um começo, pode não ocorrer da melhor forma no início, mas vamos ajustando.

b) Priorize: Não traga hipóteses que não fazem sentido e requerem esforço para seu fluxo de validação.

c) Organize o processo: Tenha claro aquilo que se deseja validar e planeje o processo antes de executá-lo. Tendo claro o que se deseja validar é que será possível definir o formato do experimento.

d) Envolva outras pessoas: Não deixe de ficar bem colado na equipe de design que é seu braço direito no processo e no seu squad e stakeholders internos, eles trarão perspectivas diferentes que tendem a enriquecer muito as validações.

e) O melhor para o fim: ERRE

O melhor de hipóteses é mostrar que podemos estar errados com ideias que surgiram e isso é ótimo! Imagina se aquela ideia fosse direto para desenvolvimento? Teríamos implementado algo que não surtiria o efeito desejado e teríamos gasto esforço para isso. Temos que dar mais valor ao erro no nosso dia a dia, pois muitas vezes ele é um aprendizado e não um problema.

Leia, procure cursos, converse com colegas e, principalmente, execute para se desenvolver! Conhecimento pode ser adquirido de várias formas e considero a prática como a melhor delas.