Discovery: A forma de descobrir da Alice

Café Legal

Certo dia fui surpreendida por um evento na minha agenda: “Café Legal.”

Era um convite de duas pessoas do Time de Legal da Alice para um café. Dentre outras coisas, elas queriam entender mais sobre a Área de Produto e como elas poderiam contribuir de forma ativa com as nossas tomadas de decisão.

Falamos sobre amenidades, eu expliquei um pouco sobre as Áreas de Produto e Tecnologia e quando me questionaram sobre como poderiam ser mais participativas nos nossos processos, eu inconscientemente respondi: “precisamos inserir vocês nos nossos discoveries.”

Falei isso com certa naturalidade e fiz uma pausa. Elas me olharam com cara de “quê?”. E então perguntei: vocês sabem o que é discovery?

Elas não sabiam. E isso, de forma alguma, é um demérito. Nós, que trabalhamos com produtos digitais, estamos muito acostumados com determinados termos, que acabamos utilizando com pessoas que não lidam diretamente com o nosso universo.

Expliquei para elas o que vou resumir aqui:

Discovery, como o nome já indica, é um processo de descoberta: existe um problema, existem hipóteses de como resolver esse problema e, baseado nessas hipóteses, existem as possíveis soluções.

No discovery, buscamos encontrar a melhor solução para um problema sob três pilares: usuário (UX), tecnologia (viabilidade) e negócios (alinhamento estratégico).

E, embora o discovery seja, muitas vezes, liderado por uma pessoa de produto (PM), ele é executado em conjunto com Product Designers e pessoas de desenvolvimento (tech), que têm papel fundamental para se obter um bom resultado.

Como estamos descobrindo a melhor forma de “descobrir” na Alice

Somos uma empresa early stage e sempre estamos descobrindo a melhor forma de fazer alguma coisa.

Uma das nossas virtudes é: “Subimos a barra, evoluímos todos os dias”. E para o processo de discovery não é diferente.

Iniciamos no melhor modelo free style.

Cada PM, com sua experiência e bagagem de aprendizados, iniciou e concluiu diversos processos de discovery. E os resultados, naturalmente, tiveram méritos, falhas e novos aprendizados.

Decidimos nos reunir para unificar esse processo, juntar nossas forças para preencher as lacunas de cada processo individualizado.

E chegamos a um framework que vou detalhar a seguir.

Framework de Discovery da Alice

Para apresentar o framework, vamos usar um suposto problema como exemplo:

Muitas pessoas do Time de Saúde estão reportando baixa adesão dos membros ao plano de ação.

Plano de ação é uma lista de tarefas que o Time de Saúde estabelece com o membro com o objetivo de tornar sua vida mais saudável. As tarefas podem variar entre: iniciar uma atividade física, realizar um exame, se consultar com um especialista, tomar um medicamento, fazer acompanhamento com Nutricionista, entre outras coisas.

Esse framework está dividido em 2 grandes etapas:

1. Entendimento do problema e levantamento de hipóteses;
2. Validação ou redução do grau de incerteza das hipóteses e proposta de solução;

Cada uma dessas etapas é marcada por um evento que reúne as pessoas envolvidas com o tema central do discovery.

1ª Etapa: entendimento do problema e levantamento de hipóteses

Ser PM é fazer escolhas, sempre — ser humano é fazer escolhas, sempre!

Como PM precisamos escolher qual problema resolver primeiro. Isso porque existem recursos limitados para desenvolver soluções. Essa etapa tem dois objetivos principais:

1. Responder se o problema é relevante (qual é o impacto dele) e se existe alinhamento estratégico para priorizar a solução desse problema;
2. Levantar hipóteses para solucionar esse problema;

É sempre importante frisar que hipóteses não são soluções. As hipóteses estão mais relacionadas a “o que deve ser feito” para se obter determinado resultado, enquanto as soluções estão relacionadas a “como isso deve ser feito”.

Eu sugiro escrever as hipóteses utilizando esse modelo: se [variável], então [resultado], porque [racional].

Utilizando o problema de exemplo: se [as pessoas tivessem uma maneira mais fácil de agendar seus exames], então [o engajamento delas com o plano iria aumentar], porque [verificamos que + de 45% das pessoas demoram mais de 15 dias para agendar seus exames e aproximadamente 25% das pessoas não realizam o agendamento].

A hipótese aqui: as pessoas têm dificuldades para agendar exames.

A solução a gente deixa para a segunda etapa.

Nessa primeira etapa vamos a fundo no entendimento do problema. Entre outras coisas, fazemos entrevistas com as pessoas envolvidas, shadowings (passar um tempo acompanhando a rotina dessas pessoas ou, até mesmo, assumir esses papéis), análise de dados, análise da evolução do produto, etc…

Como resultado dessas ações, temos um documento contendo:

[x] Descrição do problema
[x] Descrição do impacto do problema
[x] Evidências (quali/quanti) do problema a ser resolvido
[x] Impacto no OKR
[x] Proposta de hipóteses

Essa etapa é marcada pelo evento Discovery Kick-off, onde reunimos os principais stakeholders para apresentar o problema e as hipóteses de solução. Nesse evento buscamos o buy-in dos envolvidos para seguir para próxima etapa.

Ou seja, baseado no que sabemos até aqui: podemos afirmar que o problema é relevante, e o desenvolvimento de uma solução — agora — está alinhado estrategicamente com a empresa?

Se sim, next (se não, re-prioriza)

2ª Etapa: validação das hipóteses e proposta de solução

Ótimo. Já conhecemos a fundo o problema e já temos em mãos algumas hipóteses de como solucioná-lo. Mas como saber se essas são hipóteses válidas? Existem algumas formas.

Vamos usar como exemplo a hipótese descrita na primeira etapa: se [as pessoas tivessem uma maneira mais fácil de agendar seus exames], então [o engajamento delas com o plano iria aumentar], porque [verificamos que + de 45% das pessoas demoram mais de 15 dias para agendar seus exames, e aproximadamente 25% das pessoas não realizam o agendamento].

Aqui o problema é o baixo engajamento ao plano e a hipótese é que isso se deve à dificuldade de agendamento de exames.

Uma das formas de validar as hipóteses é entrevistar as pessoas que possuem baixa adesão ao plano. Nessas entrevistas, perguntamos a elas se aumentaria a probabilidade de adesão ao plano se houvesse uma forma mais fácil de agendar os exames.

Perguntamos também sobre outras hipóteses de solução a fim de entender quais são mais aderentes.

Outra forma complementar a essa, é simular um cenário onde enviamos um formulário para o membro para coletar informações sobre o melhor dia/horário de realização de exames e fazemos o agendamento pela pessoa.

Ao final desta simulação, comparamos se o engajamento ao plano dessas pessoas aumentou em comparação às demais.

Sim? Sinal de que estamos no caminho certo!
Entrevistas, cenários simulados e benchmarks são algumas formas de reduzir incertezas em relação às hipóteses.

Nesse momento algumas hipóteses serão validadas, outras terão seu grau de incerteza reduzido, e outras cairão.

Com base nas hipóteses validadas, partimos para o desenho da solução.

Utilizando o mesmo exemplo, o que fazemos aqui é propor qual é a melhor forma de facilitar o agendamento de exames.

Podemos ter como solução, uma funcionalidade de agendamento de exames no app da Alice. Sendo assim, criamos um protótipo dessa funcionalidade e selecionamos pessoas para testarem a solução.

Minha sugestão é, se possível, desenvolver protótipos navegáveis de alta fidelidade.

Isso ajuda muito a ter resultados de testes mais assertivos, e, não menos importante, é uma documentação bastante robusta para posterior alinhamento com todos os envolvidos.

Com o protótipo em mãos, partimos para os testes, e inicia-se o famoso ciclo — teste > feedback > iteração — até chegarmos à solução final.

Aqui na Alice usamos e abusamos do Maze para testes de usabilidade. É uma ferramenta incrível, que nos ajuda a ter mais alcance, e resultados mais estruturados.

Ah, e sabe o Time de Legal?

Então, esse é um ótimo momento para envolvê-lo se você entender que a solução proposta pode ter algum impacto jurídico.

Ou apenas para pegar a opinião deles, porque eles são “legal” — (tudumtss).

Ao final dessa etapa complementamos nosso documento de discovery com mais esse checklist preenchido.

[x] Descrição da solução (fluxograma, protótipo, casos de uso, etc.)
[x] Evidências de validação / invalidação das hipóteses
[x] Validação da solução com users
[x] Roadmap
[x] Métricas de sucesso
[ ] Alinhamento com stakeholders

Para coroar, convidamos os stakeholders envolvidos para um evento que chamamos de Discovery Sign-off, apresentamos a solução final e nos alinhamos sobre os próximos passos.

[x] Alinhamento com stakeholders

Para finalizar…

Todo esse framework pode dar, à primeira vista, a impressão de excesso de burocracia. Mas ele é só uma trilha, e não um trilho — parafraseando o Time de Saúde da Alice em relação aos protocolos de saúde. Cumprir todas essas etapas, ou apenas parte delas, depende da complexidade e impacto do problema e do grau de incerteza em relação às hipóteses.

O discovery ajuda a validar hipóteses, mas dificilmente será possível reduzir a zero o grau de incerteza em relação a elas.

Muitas vezes é importante arriscar. A verdade é que uma hipótese somente será 100% validada quando a solução derivada dela estiver em uso.

Muito embora o discovery seja uma importante ferramenta para evitar custos que são evitáveis com a implementação de uma solução que tem grandes chances de não funcionar, ele é, também, um processo que custa caro. É preciso escolher quais batalhas lutar!