Continuous Discovery Habits de Teresa Torres: A Ciência da Medição e a Gestão dos Ciclos de Descoberta — Key Points da Leitura dos Capítulos 11 e 12

Niloy T. — Unsplash

Introdução

Este artigo vem na sequência dos artigos anteriores: 1 — Continuous Discovery Habits de Teresa Torres: O que Significa Realmente Descobrir Produtos — Key Points da Leitura dos Capítulos 1 e 2 2 — 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 3 — Continuous Discovery Habits de Teresa Torres: Histórias das Pessoas que se Traduzem em Mapeamento de Oportunidades — Key Points da Leitura dos Capítulos 5 e 6 4 — Continuous Discovery Habits de Teresa Torres: Priorizar Oportunidades e Brainstoriming de Soluções — Key Points da Leitura dos Capítulos 7 e 8 5 — Continuous Discovery Habits de Teresa Torres: Testemos Pressupostos em Vez de Ideias — Key Points da Leitura dos Capítulos 9 e 10

Continuando a partilhar a minha jornada de leitura de Continuous Discovery Habits, de Teresa Torres, chegámos aos capítulos que dão sentido a todo o esforço anterior. Se os capítulos passados foram sobre estruturar o pensamento e desenhar testes, os capítulos 11 e 12 são sobre dados e medição daquilo que pensámos e desenhámos.

Como alguém que vive diariamente rodeado de métricas e visualização de dados, estes capítulos ressoaram particularmente comigo. Teresa Torres recorda-nos que a descoberta não é um salto de fé ou um ato opinativo; é um ato que deve ser o mais objetivo possível e onde a medição tem um papel fundamental.

Medir o Impacto: A Hierarquia dos Sinais

Muitas equipas de produto sofrem de “miopia de medição”: lançam algo e olham apenas para o Business Outcome e esquecem-se dos Product Outcomes. O Capítulo 11 ensina-nos que, em descoberta contínua, a medição deve ser feita em camadas, focando-nos primeiro nos leading indicators e só depois nos lagging indicators.

O Sinal do Pressuposto

Antes de medirmos se o produto é um sucesso, medimos se o comportamento que previmos aconteceu. A Teresa Torres enfatiza que devemos definir critérios de sucesso claros e antecipadamente. Se não o fizermos, seremos vítimas do enviesamento de confirmação, interpretando qualquer dado como uma vitória.

No exemplo da MediFlow: Ao testarmos o Link de Pagamento via SMS, não medimos logo a faturação mensal — Business Outcome. O nosso sinal de impacto imediato é: “Em 10 SMS enviados, quantos pacientes clicaram no link nos primeiros 30 minutos?”. Se este sinal for zero, a arquitetura da solução está errada e não vale a pena olhar para métricas macro.

Do Sinal ao Product Outcome

Para conseguirmos uma boa medição, a equipa de produto tem de dominar a distinção entre o que o negócio quer e o que o utilizador faz.

Business Outcome (Lagging Indicator): São métricas financeiras ou de saúde organizacional (ex: receita, retenção, quota de mercado). São chamadas de lagging porque, quando os dados chegam, o comportamento que os gerou já aconteceu há semanas ou meses. Se gerirmos o produto apenas por aqui, estamos a reagir tarde demais.

Product Outcome (Leading Indicator): São comportamentos mensuráveis dos utilizadores dentro do produto (ex: completar uma tarefa, frequência de uso). São leading porque prevêem o sucesso do negócio e estão sob o controlo direto da equipa de produto.

Traction Metrics: (São referentes à utilização de funcionalidades em específico. Por exemplo, “Quantos links SMS foram enviados”.

Aprofundando com o caso MediFlow:

Cenário A: Combater a perda de receita por faltas às consultas

As clínicas perdem margem quando os pacientes não aparecem. O Business Outcome seria “Reduzir perdas financeiras por faltas em 15%”. Mas a equipa não controla a carteira do paciente. O Product Outcome que a equipa deve medir é: “Garantir que 90% dos pacientes confirmam ou desmarcam a consulta via plataforma até 24h antes”. Ao mudar este comportamento, o resultado financeiro surge como consequência.

Cenário B: Eficiência no processamento de seguros

A demora nos reembolsos é crítica. O Business Outcome é “Reduzir o ciclo médio de recebimento de 45 para 30 dias”. O Product Outcome, onde atuamos é: “Reduzir para menos de 3% a taxa de faturas submetidas com erros de preenchimento na interface”. Se a usabilidade impedir o erro, o pagamento acelera.

A Armadilha dos Lagging Indicators

A receita ou o churn são resultados de decisões que tomámos há meses. Teresa argumenta que gerir um produto por lagging indicators é como conduzir um carro a olhar apenas pelo espelho retrovisor. A nossa função em Discovery é encontrar os comportamentos humanos que preveem esses resultados financeiros.

A grande mudança de mentalidade é que a equipa de produto não deve ser avaliada e/ou responsabilidade por “salvar a receita” (algo abstrato), mas sim por mudar um comportamento específico. Na MediFlow, se focarmos em fazer com que o administrativo cometa menos erros ou o paciente confirme mais cedo, estamos a criar valor previsível.

Como especialistas em dados, o nosso papel é garantir que esta correlação entre o comportamento (Leading) e a receita (Lagging) é estatisticamente sólida

Gerir os Ciclos: Navegar com a Bússola da “Surpresa”

O Capítulo 12 aborda a gestão prática deste fluxo. Penso que já percebemos que o processo de Continuous Discoverynão não é uma linha reta; é um processo dinâmico onde gerimos ciclos de descoberta e entrega em paralelo — dual track.

A Surpresa como Gatilho de Aprendizagem

Um dos conceitos mais interessantes é como reagimos aos dados. Teresa sugere que devemos procurar ativamente pela “surpresa”.

Se um teste corre exatamente como previmos, apenas confirmámos o que já sabíamos. Se o teste falha ou dá um resultado inesperado, é aí que a verdadeira aprendizagem e, consequente descoberta acontece.

Na MediFlow, se os pacientes não clicam no link SMS (falha), isso obriga a equipa a repensar e refocar-se: será que o remetente parece spam? Será que o momento do envio (mal saem da consulta) é demasiado cedo? Esta capacidade de retroceder no mapa de oportunidades com base em evidências é o que garante que não construímos “lixo” tecnológico.

Conclusão

Como marketer com foco MarTech e dados, este foco na validade do sinal faz todo o sentido. No digital, é fácil cairmos no erro de medir tudo e não compreender nada! A medição em Discovery e mesmo nas outras fases do processo de Design Thinking e de Desenvolvimento de Produto serve para reduzir a incerteza, não para gerar relatórios bonitos (muitos dos quais nem são lidos).

Um dashboard com a métrica “# de links enviados” para pagamento, no exemplo da MediFlow é irrelevante se não houver um teste de pressuposto que nos diga que as pessoas confiam e, consequentemente, utilizam esses links. A medição deve servir para matar teorias falhadas o mais cedo possível, mantendo-nos “vivos” para tentar a próxima ideia.

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

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 dois últimos Capítulos 13 e 14