Continuous Discovery Habits de Teresa Torres: Onde o Negócio e o Comportamento do Utilizador se Cruzam - Key Points da Leitura dos Capítulos 3 e 4

Introdução

Este artigo vem na sequência do artigo anterior – Continuous Discovery Habits de Teresa Torres: O que Realmente Significa Descobrir Produtos – Key Points da Leitura dos Capítulos 1 e 2 – e reflete novamente os meus key insights sobre e da leitura do livro Continuous Discovery Habits, de Teresa Torres. Desta vez os meus insights referem-se aos capítulos 3 e 4.

Se no artigo anterior os insights abordavam as temáticas do “Quem” e do “Quê”, neste artigo reflito sobre os temas dos “Porquê” e dos “Como” se pode estruturar o conhecimento inicial. Ou seja, como é que transformarmos, ou melhor, como é que desdobramos um Objetivo de Gestão (abstrato para o top-down) para um Objetivo de Produto que as equipas percebem, e que consigam trabalhar para alcançá-lo?

 

Business Outcomes vs. Product Outcomes

A principal ideia do Capítulo 3 é a necessidade de distinguirmos os Business Outcomes dos Product Outcomes.

Primeiro há que definir o que é um Outcome mais uma vez: uma mudança no comportamento humano que impulsiona resultados de negócio.

Muitas vezes, se não maioria das vezes, as equipas recebem um objetivo, por exemplo “aumentar a receita em 10%”. Existem 3 problemas com este objetivo:

1 – A receita é um objetivo e não tanto um outcome

2 – A receita é um objetivo 100% de negócio, ou seja as equipas de produto raramente têm controlo total sobre esse aspeto

3 – A receita é um lagging indicator, ou seja quando existem dados sobre a mesma torna-se tarde para as equipas de produto tomarem qualquer ação para correção de rumo

Ou seja, as equipas estão a medir funcionalidades e não comportamentos.

No seu livro, Teresa Torres propõe que foquemos em Product Outcomes: comportamentos mensuráveis dos utilizadores que acreditamos serem leading indicators do sucesso do produto e consequentemente do negócio.

 

Exemplo prático na MediFlow:

• Business Outcome: Aumentar a retenção de clínicas na plataforma

• Product Outcome: Garantir que 80% das clínicas enviam o seu primeiro link de pagamento por SMS nos primeiros 5 dias após a adesão

Esta distinção que a Teresa Torres propõe, na minha perspetiva muda tudo. As equipas deixam de tentar “salvar” ou “satisfazer” o negócio de forma abstrata e sem controlo e fica mais focada em mudar um comportamento específico que gera valor em primeiro lugar pas as pessoas e, consequentemente, para o negócio.

 

Visualizar o que sabemos: Experience Map

No Capítulo 4, a Teresa Torres propõe-nos desenhar. Antes de falarmos com clientes (para aquelas equipas que o fazem), será necessário externalizar o nosso conhecimento atual. E como podemos fazê-lo? A proposta é fazê-lo através dos “Experiencie Maps”.

O Experience Map é uma representação visual e externa daquilo que a equipa acredita ser a experiência atual dos utilizadores em relação a um determinado contexto ou resultado pretendido.

Para se desenhar um Experience Map que cumpra o seu objetivo será necessário:

1 – Cada membro da equipa de produto deve desenhar o seu mapa individualmente antes de o partilhar

2 – Partilhar os Experience Maps e em conjunto trocar impressões sobre as razões que levaram a definir aqueles Experience Maps

3 – Desenhar o Experience Map final

Desta forma e com este artefacto as equipas ficam mais “auxiliadas” ou entre-ajudam-se mais na identificação de onde estão desalinhadas ou onde simplesmente não sabem o que os utilizadores fazem ou devem fazer e porquê.

 

Exemplo Mediflow
Na MediFlow, isto significaria que o PM, o Designer e o Engenheiro desenhariam, cada um, o processo de um administrativo de clínica a lidar com um pagamento em atraso. Só depois combinariam as visões num mapa partilhado para identificar lacunas de conhecimento.

 

O Product Manager – A Voz do Negócio

O seu mapa focaria no fluxo de valor e nas regras de negócio:

Etapas do Fluxo:

Verificação da lista de faturas vencidas no sistema;

Cálculo do montante da dívida;

Verificação dos critérios de cobrança (ex: se o paciente tem seguro ativo);

Decisão de avançar para o contacto.

Foco Principal: O estado da fatura (pendente -> vencida -> cobrada) e o impacto financeiro dessa recuperação para a clínica,.

 

O Product Designer – A Voz dos Utilizadores

O seu mapa focaria na interação, na usabilidade e na carga emocional:

Etapas do Fluxo:

O administrativo a abrir o ecrã de “Contas a Receber”;

A frustração de procurar o contacto do paciente;

A redação da mensagem de cobrança;

A receção de uma reclamação do paciente por telefone.

Foco Principal: A experiência administrativa (facilidade de uso do ecrã), o stress de gerir conflitos e os pontos de dor na comunicação direta com o paciente,.

 

O Engenheiro de Desenvolvimento – A Voz da Tecnologia

O seu mapa focaria nos dados, sistemas e restrições técnicas:

Etapas do Fluxo:

O trigger do sistema que identifica o atraso;
A chamada de API ao banco para confirmar se o dinheiro entrou;

O serviço de envio de notificações (SMS/Email);

A atualização da base de dados quando o pagamento é finalmente processado.

Foco Principal: A integridade dos dados entre a MediFlow e as seguradoras/bancos, os possíveis erros de sincronização e a exequibilidade técnica das notificações automáticas,.

 

A Consolidação: O Mapa Partilhado

Após estes desenhos individuais, a equipa junta as visões num Experience Map partilhado. É neste momento que surgem as perguntas críticas: “Nós achamos que o administrativo liga ao paciente ou envia um SMS?” ou “Como é que o sistema sabe se o reembolso da seguradora já foi feito?”.

Estas dúvidas tornam-se as perguntas que a equipa levará para as entrevistas semanais com os clientes.

 

Conclusão

Quantos e quantos de nós, seja em produto ou noutras áreas, não aceitamos os famosos OKRs sem questionar? E isso acontece porque muitas vezes quem está a implementar e a liderar estes temas também não sabe muito bem como fazê-lo. E o resultado é que muitas vezes aceitamos as “vanity metrics” ou objetivos financeiros sem questionar que comportamento do utilizador vão influenciar.

Na prática, vejo equipas a ficarem frustradas pelo exposto acima e porque na prática têm como resultado o “ponteiro da receita” não mexer.

———————————————————–

Este artigo faz parte da minha jornada de leitura partilhada do livro Continuous Discovery Habits de Teresa Torres. O próximo artigo será sobre os Capítulos 5 e 6