Produtos digitais

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

Dando continuidade à exploração do livro Continuous Discovery Habits, de Teresa Torres, os capítulos 9 e 10 trazem uma mudança de paradigma que, embora pareça subtil, é onde a maioria das equipas de produto falha. Às vezes, ou melhor na maioria das vezes, até falham porque nem há esse paradigma para mudar – testar.

Depois de termos o nosso Trio de Produto alinhado, as oportunidades mapeadas e algumas soluções promissoras no papel, a tentação é saltar logo para o desenvolvimento da solução ou, no passo intermédio, para o desenho dos protótipos de alta fidelidade. No entanto, o que este artigo tentar expor, em forma de resumos e após a leitura dos capítulos 9 e 10, é que testar uma ideia inteira é lento e caro; o segredo está em desconstruir essa ideia nos seus pressupostos mais arriscados.

User Story Mapping

Em vez de listar funcionalidades, desenhamos o passo-a-passo do utilizador. Para cada passo, o Trio pergunta: “O que tem de ser verdade para o utilizador avançar para o passo seguinte?”. Estes pressupostos devem cobrir cinco categorias de risco: Desejabilidade, Viabilidade, Exequibilidade, Usabilidade e Ética.

Os Pressupostos Escondidos debaixo da Solução

O Capítulo 9 foca-se na identificação de pressupostos. A Teresa argumenta que cada ideia que temos transporta consigo uma série de “verdades” que assumimos sem questionar. Para não sermos surpreendidos por falhas catastróficas no lançamento, precisamos de categorizar os riscos em cinco áreas críticas. Essa categorização dos riscos, nada mais é do que aquilo que Marty Cagan considera serem alguns dos riscos de produto:

• • Desejabilidade – Os consumidores querem esta solução?
  • Viabilidade – Esta solução adequa-se ao negócio?
  • Exequibilidade –Conseguimos desenvolver esta solução?
  • Usabilidade – Os utilizadores sabem ou saberão usar esta solução?
  • Ética – Esta solução causa algum tipo de dano ético, moral, legislativo…?

O Exemplo da MediFlow na Prática

Imaginemos que o nosso Trio decidiu avançar com a ideia 1:“Pagamento via Link SMS enviado automaticamente após a consulta” e Ideia 2 “Agente de IA para Negociação de Dívidas Antigas” . Para esta solução funcionar, estamos a assumir que:

Solução 1

• • Desejabilidade – Os pacientes preferem pagar por link do que pagar presencialmente e na receção
  • Usabilidade – Os administrativos da clínica sabem onde clicar para confirmar o envio? Os pacientes sabem o procedimento para pagar após, clicar no link enviado para pagamento?
  • Exequibilidade – Conseguimos integrar a API de SMS com o software de gestão da clínica e com o a API de diferentes bancos e sistemas de pagamento?
  • Viabilidade – O custo da SMS não “come” a margem da MediFlow?

A Teresa sugere que coloquemos todos estes pressupostos num eixo cartesianos em que temos num dos eixos a “Importância” e no outro a “Evidência”. Só devemos testar os pressupostos que são muito importantes, mas sobre os quais temos pouca evidência.

Testar Pressupostos, não Protótipos

No Capítulo 10, aprendemos a desenhar experiências para validar esses pressupostos específicos. O objetivo aqui não é recolher feedback sobre o design, mas sim observar o comportamento real.

Em vez de construirmos um protótipo funcional da MediFlow que demora duas semanas a desenhar, o Trio pode fazer um smoking test / fake door ou uma simulação em poucas horas.

Solução A: Links de Pagamento via SMS logo após a consulta

O que é: Um SMS automático enviado ao paciente mal o médico fecha o processo clínico.

Pressuposto de Desejabilidade

• • Os pacientes preferem e confiam num link recebido via SMS para introduzir dados de pagamento de saúde
  • Os administrativos acreditam na eficiência do seu trabalho e cumprimento de objetivos com o envio de link via SMS para pagamento

Pressuposto de Usabilidade

• • O administrativo da clínica consegue confirmar o envio do link num ambiente de receção agitado sem cometer erros
  • Os pacientes conseguem pagar, após clicarem no link

Pressuposto de Exequibilidade

• • O software de gestão da clínica permite a integração via API para disparar o SMS em tempo real
  • O software de gestão da clínica permite a integração via API para receber a notificação ou confirmação de pagamento por parte do cliente e/ou dos diferentes meios de pagamento
  • O software de gestão da clínica permite a integração via API para receber a notificação ou confirmação de pagamento por parte do cliente e/ou dos diferentes bancos (exemplo para transferência bancária)

Pressuposto de Ética

• • Os pacientes estão confortáveis e aceitam a troca de informações de dados pessoais entre diferentes entidades
  • As clínicas respeitam os diferentes regulamento de proteção de dados
  • As clínicas possuem mecanismos concretos e eficientes para coleta, disponibilização e eliminação de dados sensíveis de PII dos pacientes

Solução B: Agente de IA para Negociação de Dívidas Antigas

O que é: Um chatbot inteligente que contacta pacientes com dívidas há mais de 30 dias para oferecer planos de pagamento.

Pressuposto de Viabilidade

• • O custo de processamento da API de IA é inferior à margem recuperada nas dívidas de baixo valor

Pressuposto Ético

• • Os pacientes não se sentem “assediados” ou desumanizados ao negociar uma dívida de saúde com uma máquina

Aqui reside a grande lição: o objetivo de um teste não é recolher feedback sobre se o botão é bonito, mas observar o comportamento dos utilizadores em contexto minimamente real. A Teresa Torres prefere experiências rápidas que simulem apenas o momento de maior risco.

Se o maior risco da Solução A é a confiança no SMS, não precisamos de programar a integração. Podemos fazer um “Teste Concierge”:

A Experiência – Na próxima terça-feira, o administrativo envia manualmente um SMS (sem sistema automático) a 10 pacientes.

Critérios de Sucesso (Definidos previamente) – Quantos pacientes clicaram e iniciaram o pagamento? Se ninguém clicou, o problema não é o código, é a confiança no canal – Product Market Fit.

Validamos (ou invalidamos) a desejabilidade em 1 dia, não em 2 semanas de um sprint para as equipas que trabalham em regime Agile.

Para a Solução B (IA), podemos usar um “Smoke Test”:

A Experiência: Colocar um banner na área de cliente: “Deseja negociar o seu saldo em atraso com o nosso assistente virtual?”.

Critérios de Sucesso (Definidos previamente) – Se houver um número significativo de cliques, por exemplo X cliques, ou melhor, se o CTR desse banner for superior a Y%, sabemos que há interesse antes sequer de pensarmos num modelo de IA ou de IA generativa que nos auxilie nesse processo.

Esta abordagem de simular cenários reais permite-nos falhar rápido e barato antes de comprometermos uma única linha de código.

Conclusão

O User Story Mapping é uma ferramenta visual importante para desenvolvermos os nossos pressupostos e que estão adstritos a determinadas oportunidades: Desenhar o passo-a-passo daquilo que é o caminho dos utilizadores na nova solução, ajuda-nos a visualizar mais claramente o que tem de ser verdade em cada etapa.

Além disso, também nos obriga a fugir do”Sim ou Não”: Não devemos perguntar se gostam da ideia; devemos antes observar na prática se os utilizadores fazem a ação pretendida com o teste que “preparámos” para verificar isso.

O sucesso tem de ser definido upfront. Ou seja, antes de colocarmos o teste em prática, temos de concordar com a métrica de sucesso que consideramos ser um resultado positivo para evitar enviesamentos de confirmação.

Portanto, as equipas quando têm uma ideia nova, antes de abrirem o Figma ou o Jira devem pensar, refletir em pressupostos, seja primeiro individualmente e depois em equipa ou logo em equipa: “O que é que tem de ser verdade para isto não ser um desastre?”

Este exercício de humildade intelectual — reconhecer o que não sabemos, (o que sabemos – Certezas, e o que achamos que sabemos) — é o que separa as equipas que entregam outputs daquelas que geram outcomes reais.

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

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 11 e 12

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

Nestes capítulos a Teresa torres aborda o tema de o que fazemos com todas as oportunidades que mapeámos? Se nos capítulos anteriores aprendemos a estruturar o caos na Opportunity Solution Tree (OST), os capítulos 7 e 8 focam-se em tomar decisões e em não deixar a criatividade morrer no “brainstorming” tradicional.

Muitas equipas saltam logo para o desenvolvimento, ou seja focam-se na solução de imediato e isso por vezes pode prejudicar-nos porque ao sermos rápidos, podemos não entregar com o valor que o cliente espera e, consequentemente, prejudicar o negócio no curto, médio ou longo prazo.

Então, com tantas Oportunidades que emergiram da OPS, é exigido algum discernimento de parte das equipas e pensar na melhor forma de priorizá-las e não desenvolver de imediato a solução para a Oportunidade Alvo mais simples ou a solução mais complexa ou apenas a solução que achamos que vai ser melhor, por nossa opinião.

Mas o facto de termos de priorizar não invalida nem deve mesmo invalidar que só nos devemos concentrar numa única Oportunidade Alvo. Significa que nos devemos concentrar numa Oportunidade alvo (não solução) Oportunidade Alvo de cada vez. Assim, garantimos que o processo seja mesmo progressivo e iterativo.

Existem imensas frameworks para priorização, por exemplo através da Matriz de Impacto x Esforço. Aquele que a Teresa Torres menciona no seu livro avalia quatro fatores:

Tamanho da Oportunidade: Quantos utilizadores são afetados e com que frequência?

• • Fatores de Mercado: Como é que isto nos diferencia da concorrência?
  • Fatores da Empresa: Como é que isto se alinha com a nossa visão?
  • Fatores do Cliente: Qual é a importância desta dor para o utilizador?

Exemplo prático na MediFlow

Temos várias oportunidades no mapa, como “Os pacientes esquecem-se de pagar” ou “O administrativo tem receio de cobrar”. Em vez de tentarmos resolver tudo, o Trio de Produto avalia que “Pacientes que saem apressados para evitar filas” afeta 70% das clínicas. Esta torna-se a nossa oportunidade alvo.

Ideação: Quantidade gera Qualidade

No Capítulo 8, entramos no espaço das Soluções. O Key Point a reter é que é que as nossas primeiras ideias são raramente as melhores. Portanto, a recomendação é ao iniciarmos uma sessão de brainstorming, fugirmos do brainstorming de grupo tradicional, que muitas vezes leva ao “pensamento de grupo” e à censura de ideias originais. Em vez disso, o Trio e/ou os membros envolvidos devem:

• Gerar ideias individualmente: Cada membro cria as suas soluções sozinho primeiro
• Partilhar e combinar: Só depois se cruzam as visões para criar soluções mais robustas em grupo
• Evitar a fixação: Não nos devemos apaixonar por uma solução antes de a testarmos contra outras

Exemplo prático na MediFlow

Na MediFlow, por exemplo e para a oportunidade de evitar filas, o Trio poderia ter não desenhado apenas um “botão de SMS”. Podem surgir ideias como: QR codes nos gabinetes médicos, quiosques de self-checkout ou pagamentos automáticos via geofencing quando o paciente sai da clínica.

Conclusão

Tantas e tantas vezes que acontece, e já assisti e assisto a equipas a perderem meses em soluções (às vezes até mesmo no desenvolvimento do produto final) “fantásticas” para problemas que, no final, eram insignificantes ou não eram de tudo o problema do cliente.

Na prática, o Capítulo 7 dá-nos a permissão para dizer “não” a 90% dos problemas para podermos ser excelentes nos 10% que realmente importam.

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

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 9 e 10

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

Introdução

No final do ano de 2025, decidi iniciar o desafio de ler 15 minutos por dia livros que tenho a meio e outros que queria ler. É o caso do Continuous Discovery Habits da Teresa Torres. E estava longe de imaginar que o livro celebra este ano o seu quinto aniversário e que nesse âmbito a autora iria lançar a iniciativa “Let’s Read Continuous Discovery Habits Together”, decidi partilhar aquilo que para mim serão os pontos-chave dos dois primeiros capítulos.

Para tentar tornar o artigo mais prático, ao longo desta série de artigos, acrescentei um exemplo: a MediFlow, uma plataforma para clínicas de saúde. O desafio deles? As clínicas perdem muito dinheiro com faltas de pacientes e demora nos reembolsos das seguradoras.

O Que é (e o que não é) Discovery?

O primeiro grande takeaway é fazer a distinção entre Discovery e Delivery:

• Discovery: Ações que desenvolvemos para o que vamos desenvolver.

• Delivery: Ações que desenvolvemos para construir, lançar e fazer crescer o  produto.

O erro comum é tratar o Discovery como uma fase inicial de um projeto (fazer 10 entrevistas e nunca mais falar com clientes). Segundo a Teresa Torres, o Discovery Contínuo exige:

• Pontos de contacto semanais com clientes

• Realizados pela equipa que constrói o produto (o Trio)

• Foco num Outcome (resultado) desejado e não num Output (Feature)

Na MediFlow, em vez de apenas “lançar um sistema de faturação”, a equipa fala semanalmente com gestores de clínicas para perceber por que razão os pagamentos atrasam.

O Trio de Produto: A Base de Tudo

O Discovery é liderado por aquilo que a Teresa Torres e outros autores como Marty Cagan designam de Trio de Produto (Product Manager, Product Designer e Engenheiro de Desenvolvimento). Talvez não necessariamente com esta nomenclatura, mas a ideia é que nesse trio exista um Product Manager, alguém de Design, e alguém de Desenvolvimento. Particularmente, não concordo com esta estrutura e até acho que a mesma possa estar desatualizada em 2026. Pelo menos em termos de competências de cada uma deles está certamente, com o crescimento que a IA tem tido.

Bom, mas a ideia é que estas três funções tenham responsabilidades, entre outras, de colaborem desde o início para avaliar os riscos de qualquer ideia:

1. Desejabilidade: Os pacientes querem pagar online?

2. Viabilidade: O modelo de negócio da clínica suporta taxas de transação?

3. Exequibilidade: Conseguimos integrar com o software das seguradoras?

4. Usabilidade: O administrativo da clínica consegue usar a interface sem erros?

5. Ética: Os dados de saúde estão protegidos?

Pensando no exemplo da MediFlow (a plataforma SaaS para clínicas) às funções e responsabilidades do Trio de Produto, precisamos de alinhar as competências técnicas de cada um dos membros do Trio com os desafios reais de uma clínica.

No nosso exemplo da MediFlow, as responsabilidades podem dividir-se da seguinte forma:

• O PM (Product Manager): Garante que o modelo de gestão de reembolsos e cobranças é viável para o negócio da MediFlow e gera valor financeiro real para as clínicas

• O Designer: Testa se os diferentes tipos de clientes, como os administrativos das clínicas consegue utilizar a interface de pagamentos de forma intuitiva, mesmo num ambiente de recepção agitado e com constantes interrupções (usabilidade)

• O Engenheiro: Avalia se a integração técnica com os sistemas das diferentes seguradoras para permitir o processamento imediato de faturas é exequível e segura

A Opportunity Solution Tree (OST)

No Capítulo 2, a Teresa Torres apresenta-nos o seu modelo OST – Opportunity Solution Tree, uma ferramenta visual para alinhar o “o quê” com o “porquê”.

Exemplo prático na MediFlow:

• Outcome (Negócio): Reduzir em 20% o tempo médio de recebimento de pagamentos por parte das clínicas

• Opportunity Space (Necessidades): “Os pacientes esquecem-se de pagar a fatura após a consulta”

• Solution Space (Ideias): Pagamento automático via Apple Pay/Google Pay ou links de pagamento por SMS

• Assumption Tests: Antes de programar, o trio testa se os pacientes clicariam num link de SMS enviado logo após a consulta

Mentalidades Necessárias nas Pessoas e Consequentemente nas Empresas

Para que estes hábitos funcionem, precisamos de cultivar mentalidades como o Foco no Resultado, a Colaboração (este é dos mos motivos pelos quais acredito que as equipas não podem ser só o Trio, mas também não devem ser 8, 9 ou 10 elementos) e a Experimentação (estar preparado para estar errado. Ou melhor estar preparado para aprender algo, mesmo que dê errado).

Próximos Capítulos

O próximo artigo, vai apresentar aquilo que reti da leitura do livro sobre como podemos definir os Outcomes sem cair na armadilha de focarmo-nos apenas em funcionalidades. Mas podem já dar uma vista de olhos nalguns artigos que escrevi sobre Outcomes

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

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 3 e 4