Month: February 2026

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

e reflete novamente os meus key insights sobre e da leitura do livro Continuous Discovery Habits, de Teresa Torres. Desta vez entramos agora na fase em que o Trio de Produto sai da sua bolha de pressupostos e vai confirmá-los (ou não) junto dos clientes. Se nos capítulos anteriores foi feita uma resenha de Key Points relativos à “Definição de Resultados” e ao “Mapeamento daquilo que julgamos saber”, os capítulos 5 e 6 ensinam-nos a escutar aquilo que são os paina points, motivações, frustrações e expectativas dos clientes e a “transformar essa sopa de dados” em informação estruturada estrategicamente.

Esta é uma fase importante e muitas vezes e na maior parte das organizações negligenciadas.

 

Aprofundar as Histórias das Pessoas através das Entrevistas

A grande lição do Capítulo 5 é que os seres humanos são péssimos a descrever o que fizeram, a prever o seu próprio comportamento ou a descrever as suas necessidades de forma abstrata. Todos nós conhecemos dois ditados portugueses que espelham bem esta realidade: 1 – “Faz o que eu digo, não faças o que eu faço” ou 2 – “Quem conta um conto acrescenta um ponto”.
É difícil para nós humanos respondermos a perguntas como: “O que é que precisas?”, Normalmente a resposta ou completamente fora ou dizemos que não precisamos de nada. Quando fazemos a mesma pergunta aos clientes e dentro deste contexto de produto o que muitos nos revelam é uma solução (potencial feature) — e muitas vezes enviesada pelo que ele acha que queremos ouvir.

A Teresa Torres propõe que o foco das nossas entrevistas semanais sejam as histórias. Em vez de grandes planeamentos, de grandes guiões, devemos fazer perguntas hipotéticas, usamos perguntas que ancoram o utilizador num momento específico do passado: “Conta-me a última vez que…”. E a partir daqui desenrolamos, ou é nossa obrigação desenrolar o novelo de dados.

 

Exemplo prático na MediFlow

Em vez de perguntar ao administrativo da clínica “Gostaria de ter um botão de SMS para cobranças?”, podemos reformular a pergunta como: “Consegue dizer-me quando foi a última vez que um paciente saiu da clínica sem pagar a consulta? E pode descrever-me a situação?”. É nesta história que vamos descobrir se o problema foi o esquecimento do paciente, a pressa do administrativo ou uma falha no sistema de pagamentos.

O objetivo aqui é iniciar parte do processo de co-criação e nesta altura diretamente com o cliente. Ou seja, exploramos juntos o contexto para identificar pain points, motivações, frustrações, expectativas, necessidades, que Teresa designa como Oportunidades.

 

Taming the Chaos: Mapear o Espaço de Oportunidade

No Capítulo 6, aprendemos a lidar com a “confusão” que as entrevistas geram. Depois de ouvirmos várias histórias, o Trio terá uma lista enorme de problemas. Mas como priroizar quais devemos trabalhar? A resposta está naquilo que a Teresa torres designa de Opportunity Solution Tree (OST).

As oportunidades não são apenas “problemas a resolver”; são lacunas no mercado onde podemos criar valor. A regra de ouro é que nunca devemos aceitar uma solução disfarçada de oportunidade. E isso vimos no parágrafo anterior. Mas exemplificando: Se o cliente diz: “Preciso de um relatório em Excel”, está a dar-nos uma solução. Ele não precisa de um relatório em Excel. A oportunidade real (real necessidade) poderá ser “Preciso de partilhar dados de faturação com o meu contabilista de forma rápida”.

A estrutura da OST ajuda-nos a organizar estas oportunidades em relações de “pai e filho”, garantindo que:

1. Trabalhamos numa oportunidade de cada vez, limitando o Work in Progress (WIP) da equipa.

2. Cada oportunidade é distinta, evitando sobreposições que geram indecisão.

3. Focamos no impacto, avaliando qual destas oportunidades, se resolvida, mais nos aproxima do nosso Product Outcome.

Exemplo de Opportunity Solution Tree para a MediFlow

 

Conclusão

Um dos hábitos que traduzem um “Continuous Discovery” é haver entrevistas (pontos de contacto, recolha de informação sobre clientes) pelo menos uma vez por semana. Porque estes pontos de contacto, considerando que estamos a desenvolver um novo produto, não servem para para validar ideias, servem sim para descobrir novas oportunidades todas as semanas.

Os resultados dessas entrevistas (aquilo que chamem de dados, que depois se devem transformar em informação estratégica) devem ser sintetizados no momento, por exemplo recorrendo àquilo que Teresa Torres denomina de “Interview Snapshots”. Desta forma, capturamos a essência de cada conversa mal ela acabe, evitando que nos esqueçamos dos findings (dados) e dificilmente consigamos transformá-los em insights (informação estratégica).

Por último, temos de ter a noção que uma OST é viva, tal como são todas as árvores reais que conhecemos :). Portanto, rever a OST a cada 3 ou 4 entrevistas e à medida que o Trio ganha mais conhecimento é fundamental.

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

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 7 e 8

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