Continuous Discovery Habits de Teresa Torres: Testemos Pressupostos em Vez de Ideias - Key Points da Leitura dos 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
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
Continuous Discovery Habits de Teresa Torres: Priorizar Oportunidades e Brainstoriming de Soluções - Key Points da Leitura dos Capítulos 7 e 8
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
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
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
Outcome: Reduzir em 20% o tempo médio de recebimento de pagamentos por parte das clínicas
Espaço de Oportunidades:
Os pacientes esquecem-se de fazer o pagamento após saírem da consulta
O paciente sai apressado para evitar filas na receção.
O processo manual de cobrança é ineficiente e gera stress
O administrativo tem receio de conflitos presenciais e mesmo ao contactá-lo telefonicamente para cobrar a dívida
Os métodos de pagamento são limitados (físicos/locais)
Os pacientes querem pagar de forma digital ou remota
Soluções:
- Pagamento automático via Apple Pay/Google Pay
Links de pagamento enviados por SMS - IA (Inovação): Agente de IA (Chatbot) para negociação automática de dívidas, reduzindo a carga emocional do administrativo
- IA (Inovação): Modelo preditivo que identifica pacientes com maior risco de atrasarem o pagamento e envio notificações via SMS
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
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
Continuous Discovery Habits de Teresa Torres: O Que Significa Realmente Descobrir Produtos - Key Points da Leitura dos Capítulos 1 e 2
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
Como Transformar a Experiência Digital em Resultados Reais - CRO
Introdução
Os ativos digitais, nomeadamente, websites e aplicativos móveis têm diferentes objetivos. Pensando em websites e aplicativos móveis mais orientados a conversão seu verdadeiro valor não está apenas em atrair visitas, mas sim em transformar essas visitas em ações concretas — seja uma compra, um pedido de contacto ou uma subscrição. E é nestes casos particulares, ou concretos em que a aplicação de processos, técnicas e ferramentas para otimização da taxa de conversão (CRO) pode ajudar.
Neste artigo abordarei temas relacionados com a metodologia CRO que conjuga dados, psicologia e design de experiência para reduzir fricções, aumentar a confiança e alinhar o produto digital com o comportamento real dos utilizadores.
Desenvolvimento
A CRO é um processo que deve ser estratégico e por isso contínuo e mensurável. Não se pode tratar de um processo tático onde simplesmente se ajusta as cores ou se muda o texto de um botão — é uma prática estruturada que procura compreender o utilizador, formular hipóteses baseadas em dados e validar essas hipóteses por meio de experimentação.
É importante distinguir aqui dois conceitos muitas vezes confundidos: CRO e Testes A/B. Enquanto a CRO é a abordagem estratégica global, que inclui a recolha de dados qualitativos e quantitativos, o desenvolvimento de hipóteses, a execução de testes e a análise dos resultados, os Testes A/B são apenas uma ferramenta dentro desse processo. Um teste A/B aplica-se quando se pretende comparar duas versões de uma página ou elemento, mas sem uma base estratégica e uma leitura interpretativa dos resultados, o teste em si não garante qualquer otimização real.
O sucesso em CRO reside precisamente na combinação de análise, interpretação e aprendizagem contínua. É um ciclo em que cada iteração — mesmo as que “falham” — gera conhecimento e orienta as próximas ações.
A base de qualquer otimização é a análise do comportamento do utilizador. Esta análise pode ser feita sob três perspectivas complementares.
- A análise quantitativa, suportada por ferramentas como o Google Analytics, Hotjar, VWO, entre outras, que quando implementadas de acordo com a estratégia da Empresa, e não adhoc, fornecem dados concretos sobre o que os utilizadores fazem.
- A análise qualitativa, por sua vez, revela o “porquê” por detrás desses comportamentos: inquéritos, entrevistas e gravações de sessão ajudam a perceber o que causa atrito ou frustração.
- O benchmarking que permite comparar o desempenho do website com o website dos concorrentes ou com referências de mercado escolhidos, revelando oportunidades de melhoria que de outro modo passariam despercebidas. Mas é preciso ter muita atenção ao benchmarking, por dois grandes motivos, um deles cultural.
O cruzamento destas três dimensões permite identificar os chamados “pontos de fricção” — elementos que travam o fluxo do utilizador nos ativos digitais — e formular hipóteses de otimização. Por exemplo, se uma percentagem elevada de utilizadores abandona o carrinho de compras ao ver os custos de envio, a formulação das hipóteses válidas, poderia ser:
H₀ (Hipótese nula): Oferecer portes gratuitos acima de determinado valor não altera significativamente a taxa de conversão em comparação com o website atual.
H₁ (Hipótese alternativa): Oferecer portes gratuitos acima de determinado valor aumenta significativamente a taxa de conversão em comparação com o website atual.
Estas hipóteses são então testadas através de experimentação controlada (teste A/B), permitindo validar com rigor estatístico se a mudança deve ser implementada.
Todas as hipóteses levantadas, após o entendimento do comportamento dos utilizadores e do mercado, poderão formar um backlog de testes, que deve ser priorizado com base no impacto potencial para os utilizadores e, consequentemente para o negócio e no esforço de implementação.
A cada ciclo de experimentação, as novas descobertas alimentam o processo, criando uma cultura de melhoria contínua.
Mas a otimização da taxa de conversão não é apenas uma questão técnica — é também profundamente psicológica, não estivéssemos nós a falar de comportamento dos utilizadores online.
O que se pretende é entender o equilíbrio entre motivar e tranquilizar o utilizador, reduzir a fricção e tornar o processo de decisão simples e confiante.
A motivação de um utilizador explica-se por que alguém age e nisso tem particular importância:
- A definição clara e comunicação da proposta de valor da Empresa/Produto;
- A existência de potenciais incentivos como sejam promoções, urgência, prova social;
- A ausência ou a minimizarão da fricção como sejam formulários longos, interfaces confusas, lentidão);
- A ausência ou a minimizarão da ansiedade do utilizador após a realização da ação.
Nota: Baseado no modelo MECLABS
Para identificar e corrigir esses fatores, entram em cena as heurísticas de usabilidade — princípios que orientam a criação de interfaces intuitivas e seguras.
As Heurísticas de Nielsen-Molich, criadas nos anos 90, continuam a ser uma das referências mais sólidas em termos de análise comportamental online dos utilizadores. Entre elas, destacam-se:
- Visibilidade do estado do sistema - o utilizador deve sempre saber o que está a acontecer (exemplo: uma barra de progresso durante o checkout).
- Correspondência com o mundo real - o conteúdo deve falar a linguagem do utilizador, não do sistema (exemplo: “Adicionar ao carrinho” em vez de “Submeter item”).
- Controlo e liberdade - permitir desfazer ações com facilidade (exemplo: botão “Voltar” ou “Remover do carrinho”).
- Consistência e padrões - manter elementos familiares e previsíveis (exemplo: o carrinho no canto superior direito).
- Prevenção de erros - o melhor erro é o que nunca acontece (exemplo: validação automática de campos de formulário).
- Reconhecimento em vez de memorização - facilitar a navegação com ícones e menus claros.
- Flexibilidade e eficiência - atalhos e funcionalidades rápidas para utilizadores experientes.
- Design estético e minimalista menos ruído visual, mais foco no essencial.
- Ajudar a reconhecer e corrigir erros - mensagens claras e construtivas, e não códigos técnicos.
- Ajuda e documentação acessível - FAQs e apoio visível quando necessário.
No contexto do e-commerce, estas heurísticas foram adaptadas e aprofundadas, dando origem às chamadas Heurísticas de E-commerce, que aplicam os mesmos princípios ao comportamento de compra online.
Exemplos práticos incluem:
- Exibir provas sociais (avaliações, testemunhos, número de vendas).
- Garantir transparência de custos logo no início do processo.
- Simplificar o checkout em passos curtos e visíveis.
- Criar descrições de produto ricas e credíveis, com fotografias de qualidade.
- Assegurar otimização mobile, carregamento rápido e segurança de dados.
- Destacar políticas de devolução claras e informações de contacto acessíveis.
Estas boas práticas não são apenas técnicas de design — são ferramentas de confiança e persuasão. Um utilizador que se sente orientado e seguro é um utilizador que converte.
Além da usabilidade e da psicologia, a CRO também tem impacto direto na performance global do marketing digital. Ao melhorar a experiência do utilizador e ao aumentar a taxa de conversão, reduz-se naturalmente o custo de aquisição de cliente (CAC), maximiza-se o ROAS (Return on Ad Spend), melhorando-se a eficiência de todo o funil.
Nota minha: Se bem que hoje em dia já não se fala em funil, mas sim em flywheel, mas quando se trata de adquirir clientes através da experiência e do boca-a-boca, mesmo no digital
Um website otimizado é, acima de tudo, um website competitivo e adaptável. À medida que o comportamento do utilizadores muda, as tendências de design evoluem, a experimentação contínua permite que a marca se mantenha relevante — e isso é talvez o maior ativo do CRO: a sua capacidade de evolução constante.
Conclusão
A CRO é, acima de tudo, uma mentalidade. É a escolha de olhar para cada interação digital como uma oportunidade de compreender melhor o utilizador e de criar uma experiência mais eficaz, confiável e agradável.
Num ecossistema digital em que captar tráfego se torna cada vez mais difícil e cada vez mais caro, investir em CRO significa investir em eficiência e sustentabilidade — é transformar o mesmo número de visitantes em mais resultados.
Da Gestão da Qualidade ao Product Management: Uma Jornada Através de Analytics, UX Research e Implementação Técnica
Introdução
Como processo, dados e utilizadores convergem numa abordagem holística ao product management
Quando as pessoas ouvem o termos "Marketing Digital", associam-no, frequentemente, em conteúdos para websites, ou para as redes sociais e algumas vezes fazem a associação a campanhas ppc. Mas “Marketing Digital”, e após 12+ anos de experiência na área digital ou na área tecnológica, como preferirem, concluo algumas coisas interessantes (não conclui hoje ao escrever este artigo):
-
- O marketing digital pode ser mais ou menos técnico. E atualmente tenderá a ser cada vez mais técnico, não só por causa dos avanços da tecnologia e da Inteligência Artificial - IA, mas também pelas várias Leis, Regulamentos e Diretivas sobre temas como Privacidade de Dados ou sobre IA
- Marketing Digital pode ser muito mais do que Marketing Digital, tal como menciona o Simo Ahava no Capítulo 1, ponto 2 do seu Technical Marketing Handbook
- Sempre trabalhei nas áreas mais técnicas e sempre desenvolvi as minhas competências tendo em conta isso
- Quem trabalha em áreas técnicas do Digital e dentro de equipas ou dando suporte a equipas que funcionam com metodologias Agile, está a trabalhar e desenvolver produto
- Aliás, o Scrum Guide revisto este ano, com o Scrum Guide Extension Pack, uma das coisas que reforça é o ponto 4. Se por um lado existe um novo papel denominado de “supporters”, fala-se em entregar não só o output (definition-of-done), mas também o outcome - que valor traz para a Empresa aquilo que foi criado
E nisto resultam três coisas:
-
- As competências centrais que fazem um bom profissional de marketing digital são extraordinariamente semelhantes aquelas que fazem um excelente product manager e por isso…
- Os profissionais com o meu perfil, estão suficientemente preparados para assumir uma função como Product Owner ou como Product Manager, por exemplo.
- Ainda que ou até porque, o título é só um título, se não o virmos contextualizado com: cultura da empresa, organização da empresa, visão da empresa, objetivos da empresa, políticas da empresa, equipas a que vais pertencer, pessoas com quem vais colaborar, metodologias utilizadas (não apregoadas), entre uma série de outros temas que fazem uma organização.
Explicando Melhor a minha Jornada Profissional
Podem sempre consultar o meu Curriculum, mas permitam-me explicar, tentando ser breve, porque é que a minha jornada dentro do Marketing Digital e em Customer Experience, para funções de Produto não é uma mudança de carreira—é uma evolução natural.
Marketing Digital
Como explicado acima, Marketing Digital é muito mais do que conteúdos, redes sociais e clicar em botões para colocar online campanhas ppc. Marketing Digital como eu o vejo, como eu o faço é sobre:
-
- Empatia, ao termos de compreender o comportamento do utilizador através das suas customer journeys, users flows, análise de dados qualitativos e quantitativos
- Identificar pain points nessas mesmas customer journeys
- Testar hipóteses através de Testes A/B
- Construir frameworks de medição para acompanhar o sucesso
- Colaborar com equipas técnicas para implementar soluções
- Comunicar insights para stakeholders em toda a organização
Hum….Aposto que vos soa familiar? Pois é, estas são também as competências que product managers, product analysts ou utilizam diariamente.
A Minha Experiência Real em Produto
Embora os meus títulos pudessem dizer "Marketing Digital" ou "UX Research", o meu trabalho real tem sido profundamente focado em produto:
Por ordem decrescente de funções:
Engenharia e Gestão da Qualidade
Os 6 anos que trabalhei na área da engenharia e Gestão da Qualidade ensinaram-me a pensar em processos, compliance e melhoria contínua - competências que se revelaram fundamentais quando finalmente comecei a trabalhar na minha área de formação - Marketing de Produto, esta experiência se tornou valiosa.
Nos CTT, liderei a a construção da framework e a implementação de um projeto de Digital analytics, com base na ferramenta Google Analytics 4 - GA4 em todos os ativos digitais da Empresa (Website + aplicações móveis). Isto não foi apenas um projeto de marketing—foi uma iniciativa de produto que:
Exigiu alinhamento de vários stakeholders de várias equipas (entre equipas de IT, Marketing, UX e Jurídico ) e até de parceiros externos que nos auxiliaram nesse projeto
Envolveu product discovery para compreender necessidades dos utilizadores internos das diferentes equipas, por exemplo em requisitos de negócio e em termos de eventos e de métricas que deveriam ser implementados.
Necessitou coordenação de implementação técnica com equipas de engenharia
Criou frameworks de medição que agora impulsionam decisões de produto em toda a organização
Na EY, conduzi estudos de user research em +10 projetos de transformação digital, traduzindo insights de clientes em requisitos de produto e prioridades de design e de desenvolvimento.
A Gestão de Campanhas PPC - Pensar “Produto” ou parte Dele
Durante alguns anos, geri campanhas com orçamentos significativos, mas o que realmente estava a fazer era **product management em micro-escala**.
Cada campanha PPC é, essencialmente, um produto com:
-
- Estudo de Hipóteses a testar (diferentes mensagens, audiences, criativos)
- Estabelecimento de Métricas de sucesso claras (CPC, CPL, ROAS, conversion rate)
- Iteração constante baseada em performance data
Na StepValue, e depois na EY, geri campanhas que resultaram num **aumento de 30% em hot leads**, mas mais importante que o resultado foi a metodologia que elas envolvem, bem como a necessidade de interação com várias áreas e stakeholders.
Esta experiência traduziu-se diretamente em **competências de product analytics**:
-
- Análise de Funis - compreender onde os utilizadores abandonam
- Análise de Cohort - agrupar utilizadores por comportamento
- Attribution modeling - entender o impacto de diferentes touchpoints
- Previsão de Performance - prever impacto de mudanças, por exemplo no budget
O pensamento PPC também é, em parte ou na sua totalidade, Product Thinking: optimizar continuamente a experience do utilizador para maximizar conversões, sempre com objetivo em números.
O resultado disto tudo? Tenho estado a fazer trabalho de produto sem ter o título.
A Sobreposição de Competências: Duas Matrizes Simples
Deixem-me decompor como o meu background em Marketing Digital se traduz em funções de produto, através das “Competências Transferíveis”:
COMPETÊNCIA CENTRAL - PRODUCT MANAGER
|
Competência Central |
Nível de Experiência |
Formação |
Como Apliquei |
|
User Research |
4/5 |
Sim |
User interviews, análise de findings e insights, Customer Journey mapping, User flows, Information Architecture, escrita de artigos sobre UX |
|
Decisões Data-Drivem |
4/5 |
Sim |
Otimização de campanhas, Reporting de resultados campanhas PPC, Implementação de GA4, dashboard, escrita de artigos sobre analytics |
|
Gestão de stakeholders |
3/5 |
Não |
Coordenação cross-funcional, apresentações executivas, papel de subject-matter expert |
|
Estratégia de Produto |
4/5 |
Sim |
Desenvolvimento de roadmaps para iniciativas de analytics, alinhamento com objetivos de negócio |
|
Colaboração Técnica |
4/5 |
Não |
Coordenação com engenharia para implementação de tracking, integrações API, documentação técnica |
|
Metodologias Ágeis |
3/5 |
Sim |
Ainda não apliquei com um papel definido a 100%, mas tenho: Product Owner certificado (CSPO) e Scrum Master (PSM I) |
|
Competência Central |
Nível de Experiência |
Formação |
Como Apliquei |
|
Visão Estratégica |
4/5 |
Sim |
Desenvolvimento de estratégias digitais alinhadas com objetivos de negócio, roadmaps de longo prazo |
|
Capacidade de Prioritização |
4/5 |
Sim |
Desenvolvimento do projeto de Analytics, de gestão de budget em campanhas, de gestão de clientes em consultora e obtenção de perto de 90% dos OKRs, |
|
Comunicação |
3/5 |
Não |
Apresentações para stakeholders, documentação técnica, role de subject-matter expert |
|
Liderança |
4/5 |
Não |
Gestão de equipas consultoras, coordenação de projetos de transformação digital |
|
Resolução de Problemas |
4/5 |
Não |
Identificação de pain points em customer experience, soluções para problemas complexos de negócio |
|
Tomada de Decisão |
3/5 |
Não |
Decisões data-informed, otimização baseada em performance metrics, implementações técnicas |
|
Adaptação à Mudança |
5/5 |
Não |
Projetos de transformação digital, continuous learning (Data Science, AI), pivoting strategies, iniciei funções na área de Engenharia |
COMPETÊNCIA CENTRAL - PRODUCT ANALYTICS
|
Competência Central |
Nível de Experiência |
Formação |
Como Apliquei |
|
Analytics e Gestão de Projeto |
4/5 |
Sim |
Setup completo GA4, event tracking, configuração data layer Visualização de Dados |
|
Entendimento do Negócio e Frameworks de Medição |
4/5 |
Sim |
Definição de KPIs, criação de planos de medição, tracking de métricas de sucesso |
|
Visualização de Dados |
4/5 |
Não |
Dashboards Looker Studio, reporting executivo, apresentação de insights SQL & Consulta de Dados |
|
User Behavior Analysis |
4/5 |
Sim |
Análise de customer journey, otimização de conversão, insights comportamentais |
|
Otimização de Resultados |
4/5 |
Não |
Otimização de campanhas, testing de conversion rate, análise estatística |
A Vantagem Única do Background em Marketing
Isto é o que os ATS não conseguem ver e muito menos analisar. E nalguns casos, atrever-me-ia a dizer que muitas pessoas de de RH também não percebem: os profissionais de marketing têm frequentemente uma visão mais holística do ciclo de vida do cliente do que as pessoas tradicionais de produto ou de que outras profissionais focados numa área específica do digital.
Deixem-me que vos diga uma coisa, que provavelmente já perceberam (ou já sabiam) ao ler este artigo.
Quem trabalha na área digital, nomeadamente nas áreas de suporte ao produto, e no meu caso específico trabalhei em várias dessas áreas, faz produto
Como Valorizo a Minha Profissão e Como Me Mantenho Atualizado em Produto
Fazendo formações relevantes e reconhecidas na área, como o curso de Product Management, o curso de Product Discovery ou o Curso de Product Analytics da PM3. Ou obtendo a certificação de Product Owner e de Scrum Master pela Scrum Alliance e pela Scrum.org, respetivamente.
Talvez, ainda não decidi, aposte também em Escolas Portuguesas de Produto e7ou na Certificação de Projetos PMI.
Como Valorizo a Minha Profissão e Como Me Mantenho Atualizado em Dados
A evolução constante é fundamental na nossa área. Por isso, invisto continuamente no meu desenvolvimento profissional:
Terminei na passada 4ªf a Pós-Graduação em Data Science for Business Strategy na Universidade Nova - Faculdade de Ciências e Tecnologia, que me tem deu uma base sólida em modelação estatística e machine learning aplicado a contextos empresariais. E este não é o único curso que fiz sobre Dados. Estou a fazer mais duas formações nessa área. Porquê? Por dois motivos:
-
- Hoje em dia fala-se muito em IA, mas IA sem dados bem limpos e processados não funciona
- Trabalhar em produto é também saber medir e apresentar resultados
- Pode dar-me, e não me importar-me-ia na área de Product Analytics
Como Valorizo a Minha Profissão e Como Me Mantenho Atualizado em IA
Confesso que é uma disciplina onde não tenho dedicado o tempo que gostaria. Mas além de acompanhar alguns canais de YouTube sobre o tema, o projeto final que fiz na Pós-Graduação em Data Science for Business Strategy teve por base um protótipo que fiz no Replit, através de Vibe Coding. E muitos, se não todos os scripts de Python foram gerados utilizando a IA Generativa, através da ferramenta Claude.
Paralelamente, tenho estado a explorar Agentic AI e as suas aplicações em product management e analytics. Estou particularmente interessado em como os AI agents podem automatizar tasks de research e análise de dados, traduzindo menores custos para as Empresas. Mas na altura em que estou a escrever este artigo, ainda estou numa fase muito embrionária.
E isto são só algumas das apostas que tenho feito. Tendo uma oportunidade na área, irei muito mais fundo nos temas, ou nm tema específico que veja ser útil para ambos
Auto-aprendizagem contínua faz parte da minha rotina
Acredito muito no investimento em conhecimento. Para mim é algo mais do que pessoal, é estratégico. E no caso da IA, seja como product owner, como product Manager, como digital marketer, ou até mesmo noutras funções fora do mundo digital, o futuro será profundamente influenciado por AI e automation, e quero estar no sítio onde a “bola” de hóquei vai parar.
Acredito que a curiosidade e a capacidade de aprender continuamente são as competências mais importantes num profissional de produto ou de outra área. E as empresas deveriam estar atentas a isso. Ao fim e ao cabo, se o colaborador investe por ele na sua evolução, quer dizer alguma coisa em termos empresariais.
O Caminho em Frente
Não estou a abandonar a minha expertise em marketing; estou a expandi-la para product management e/ou analytics onde pode ter ainda maior impacto. As competências transferem-se perfeitamente:
A minha experiência em otimização de campanhas torna-se otimização de features de produto. O meu conhecimento de aquisição de clientes torna-se expertise em onboarding de utilizadores. As minhas competências de implementação de analytics tornam-se frameworks de medição de produto. A minha experiência em gestão de stakeholders torna-se liderança cross-funcional de produto. A minha aprendizagem em AI torna-se product innovation com tecnologias emergentes
Conclusão
Como já viram, tenho competências valiosas e transferíveis que muitos profissionais tradicionais de produto não possuem, pelo menos aqueles menos experientes. Do que vejo do mercado, nomeadamente de parceiros com quem contacto, há muita falta de conhecimento nesta área. Sabe-se tudo pela rama ou porque alguém ouviu falar.
Se são hiring managers à procura de talento, considerem profissionais de marketing como eu que tenho estado a fazer o trabalho, mesmo sem o título de Product Manager. Trago uma perspetiva que pode fortalecer a vossa equipa de produto. E saibam que não estou a começar do zero e por isso não considero que esteja a fazer uma migração de carreira stricto senso.
E finalizando,…
acima de tudo, não me interessa o título, interessa-me a Empresa, a cultura, as pessoas, e obviamente todas as condições que tenho para desempenhar as funções.
João Carlos Matos é um profissional de marketing digital com 12+ anos de experiência em analytics, user research e otimização de produtos. Está atualmente em migração de Empresa e transição para funções de Product Management, AI Product Management ou Product Analytics onde pode aplicar as suas skills numa combinação de expertise em Marketing e Pensamento de Produto.
Se quiserem saber mais, contactem-no no LinkedIn ou visitem o seu Website.
Engaged - Designing for Behaviour Change by Amy Bucher - Simples Review com exemplos do que Aprendi
Terminei de ler o livro “Engaged – Design for Behavior Change”, que aprofunda vários temas de Behaviour Change e que nos ajudam a entender o comportamento humano. Amy Butcher utiliza de forma plena a Teoria da Autodeterminação (SDT) para nos guiar pelo complexo mundo Behaviour Change, enfatizando particularmente o aspeto crucial de integrar o Behaviour Change no Design de produtos e serviços digitais.
Embora o livro não aborde explicitamente os exemplos que enumerarei a seguir, eles permanecem altamente relevantes no contexto atual em que vivemos, sendo muitas vezes negligenciados por profissionais da área.
- A E-Privacy e o GDPR – sendo, respetivamente, uma Diretiva Europeia e um Regulamento aplicado em Portugal, giram principal e logicamente em torno do panorama legal. No entanto, os mesmos foram criados porque não houve um respeito pelos utilizadores. Ou seja, a essência destes documentos está na necessidade de respeitar as escolhas das pessoas e estabelecer uma arquitetura de escolhas transparente. Os utilizadores têm o direito fundamental de compreender o propósito das tecnologias com as quais interagem, garantindo clareza e uma tomada de decisão informada.
- Imagens nos maços de cigarros – Outro exemplo é a utilização de imagens gráficas em maços de cigarros como meio de desencorajar o tabagismo. Apesar das boas intenções, o conceito ignora um fator crucial conhecido como “Present Bias“. A suposição de que os indivíduos que compram cigarros têm o objetivo imediato de parar de fumar ignora a realidade de que a sua intenção principal é fumar. Ao não se guiar, primeiramente, as pessoas para a mudança de comportamento, a abordagem/tática pode não alcançar o impacto pretendido.
Estes exemplos ilustram a importância de alinhar estratégias de design com uma compreensão profunda do comportamento humano. E não o contrário. Sendo que o contrário pode ser uma grande black-box.
Ao se considerar as motivações subjacentes e os preconceitos cognitivos, os profissionais da área podem criar intervenções que ressoem nas pessoas a um nível profundo, promovendo mudanças de comportamento significativas e tornando a utilização do produto/serviço claro, transparente, duradouro e não apenas num pico de utilização com objetivo único e exclusivo de crescimento instantâneo.
>Engaged – Designing for Behaviour Change by Amy Bucher – Simples review com exemplos do que aprendi
Outcomes over Outputs - Key points da Leitura do Livro de Joshua Seiden
Introdução
Recentemente, tive a oportunidade de ler o livro “Outcomes over Output” de Joshua Seiden. Trata-se de um livro técnico, mas de leitura acessível e agradável. Para os verdadeiros amantes da leitura, é possível concluí-lo em apenas 40 minutos. É um livro que todos aqueles que trabalham na área de gestão, especialmente em responsabilidades relacionadas à Experiência do Usuário (UX), Experiência do Cliente (CX), Pesquisa, Proprietários de Produtos e Profissionais de Marketing Digital, devem adquirir, ler e implementar nas empresas em que atuam.
Apresento aquilo que foi a meu entendimento dos Key Points do livro com algumas anotações a azul que julgo ajudarem a compreender, na minha perspetiva, aquilo que é a ideia do livro.
Podem encontrar o livro na Amazon.
Key Points da Leitura do Livro Outcomes Over Output
1. Outcomes podem ser definidos como mudanças no mundo que melhoram, simplificam ou facilitam a vida das pessoas. De acordo com a definição de Joshua, são mudanças no comportamento das pessoas que geram valor para o negócio. Em minha opinião, essa definição implica que tornar a vida das pessoas mais fácil resultará em mudanças em seu comportamento, inclusive emocionalmente, o que, por sua vez, gerará valor tanto para elas quanto para o negócio.
2. Existem três abordagens para a gestão de equipas: a gestão baseada em Outputs, em que todo o trabalho se concentra em funcionalidades (nesse caso, o trabalho de pesquisa geralmente é praticamente inexistente); a gestão baseada no Impacto, que estabelece um objetivo de alto nível, muitas vezes abstrato e que as equipes operacionais não compreendem completamente, como o crescimento do produto; por fim, a gestão baseada em Outcomes, em que a equipa se pergunta que mudanças no mundo ou no comportamento das pessoas podem criar para tornar suas vidas mais fáceis, gerando assim valor para o negócio.
3. Para realmente entender se nosso trabalho está a causar uma mudança no comportamento das pessoas, tornando as suas vidas melhores, mais fáceis e/ou mais simples, devemos criar checkpoints que sejam curtos, mensuráveis e relacionados ao trabalho que estamos a realizar.
Em UX, chamamos isso de UX Progessive Metrics, que se baseiam no Outcome = UX Success Metrics.
4. Pensar em Outcomes coloca efetivamente as pessoas no centro e torna as empresas verdadeiramente orientadas para o cliente – Customer Centric.
Infelizmente, na maioria dos casos em Portugal, esse jargão é usado, mas na prática o que está no centro é o negócio e as funcionalidades, e uma das razões para isso é a falta de trabalho estratégico de pesquisa. Adotar a metodologia de estabelecimento de objetivos por meio de OKR (Objectives and Key Results) facilita esse trabalho e alinha todas as equipes e direções da empresa.
5. O MVP (Produto Mínimo Viável) não é apenas a versão 1.0 do produto, mas sim uma experiência que representa a menor ou mais simples “coisa” que podemos e devemos fazer para testar as hipóteses iniciais.
6. Independentemente de realizarmos o trabalho de UX Research junto dos clientes, precisamos responder às seguintes perguntas para criar Outcomes eficazes: 1 – Que mudança no mundo (incluindo o comportamento das pessoas) devemos criar para tornar suas vidas melhores, mais fáceis, mais simples e proporcionar valor a elas, gerando valor para o negócio? 2 – O que podemos ou devemos fazer para que as pessoas percebam e adotem essa mudança? 3 – Como iremos medir nosso trabalho para avaliar se estamos no caminho certo?
Lembrem-se das UX Progressive Metrics, aquelas métricas que nos ajudam a monitorar o progresso ao longo do tempo.
7. Uma vez definidos os Outcomes, é crucial adotar uma abordagem iterativa de aprendizado, que envolve três etapas principais: pesquisa, criação de experiências e medição dos Outcomes.
Se repararem o descrito pelo Joshua no seu livro nada mais é do que: Definir o problema; definir hipóteses de como resolvê-lo – How Might We. E por fim, perceber se estamos no caminho certo: Are we solving people’s problems? Ou seja, Are We developing the right thing?
Definir o Problema com base em UX Research: É fundamental realizar pesquisas contínuas para compreender as necessidades, desejos e dores dos utilizadores. Este trabalho de UX research pode incluir métodos qualitativos, como entrevistas e observação, e métodos quantitativos, como análise de dados e testes A/B.
How Might We com base na Criação de Experiências/Hipótrses: Com base nas descobertas iniciais, devemos gerar hipóteses e ideias para resolver os problemas dos utilizadores. Utilizando a técnica “How Might We”, podemos definir hipóteses claras sobre como resolver esses problemas e criar experiências relevantes.
Are We Developing the right Thing – Medição de Outcomes: É crucial medir os resultados das experiências criadas para verificar se estamos resolvendo efetivamente os problemas dos utilizadores. Devemos perguntar-nos constantemente: “Estamos a resolver os problemas das pessoas? Estamos a desenvolver a coisa certa?”
8. Diferentemente dos roadmaps baseados em funcionalidades, os roadmaps centrados em Outcomes tornam o trabalho mais ágil e as equipes mais informadas e focadas. Em vez de simplesmente adivinhar quais funcionalidades devem ser desenvolvidas, baseamos nossas decisões em pesquisas e evidências.
9. Todo esse trabalho parte da compreensão da jornada do cliente, também conhecida como Experiência As-Is. Ao entender a jornada atual do cliente, podemos ter uma percepção clara de como será a experiência futura e a visão de negócio.
10. Isto porque obriga-nos a responder a questões vindas do Research e não partimos do “guessing” que desenvolver a feature A ou B vai ser estupendo, porque é digital e, portanto é melhor e porque a concorrência também tem.
Conclusão
No campo da Experiência do Cliente – CX, a perspectiva compartilhada por Joshua Seiden no livro “Outcomes over Output” traz insights valiosos para o trabalho das equipas envolvidas em projetos desse tipo. Acredito firmemente que essa abordagem será altamente produtiva, pois concentra-se em proporcionar valor para o cliente, o que, por sua vez, resultará em benefícios significativos para o negócio, a curto, médio e longo prazo.
Proporcionando Valor para o Cliente – Outcomes e não Outputs
Quando nos dedicamos a criar Outcomes que ofereçam valor real aos clientes, estamos construindo uma base sólida para o sucesso do negócio. Ao pensar estrategicamente sobre como podemos melhorar a vida das pessoas, tornando-a mais fácil, mais simples e mais satisfatória, estamos investindo na criação de relações duradouras e gerando valor sustentável.
Por outro lado, quando colocamos o foco apenas no valor para o negócio, concentrando-nos em outputs ou impactos, nem sempre conseguimos traduzir esse valor para o cliente de forma direta e eficaz. Podemos observar isso em setores como o de telecomunicações, em que, por exemplo, somos “fidelizados” por um contrato de dois anos, mas acabamos pagando mais mensalmente. Essa situação claramente beneficia o negócio, mas não agrega valor real ao cliente. Além disso, pode resultar em um mercado com pouca concorrência, prejudicando a inovação e a oferta de alternativas melhores.
A Importância dos Outcomes
Ao adotar uma abordagem centrada em Outcomes, colocamos o cliente no centro de nossas ações e decisões. Ao proporcionar valor para o cliente, estamos investindo em sua satisfação e fidelidade, o que se reflete diretamente nos resultados do negócio. Afinal, clientes satisfeitos são mais propensos a recomendar produtos ou serviços, gerando um impacto positivo no crescimento e na reputação da empresa.
Acredito firmemente na abordagem proposta por Joshua Seiden, em que o foco nos Outcomes é fundamental para o sucesso de projetos de UX. Ao proporcionar valor real para o cliente, estabelecemos uma base sólida para o crescimento e a rentabilidade do negócio. Portanto, devemos sempre buscar soluções que tornem a vida das pessoas melhor, mais fácil e mais simples, promovendo uma relação de confiança e benefícios mútuos a longo prazo. Lembremo-nos de que o verdadeiro sucesso empresarial está intrinsecamente ligado ao sucesso e à satisfação dos clientes.
O Maior Problema que os Profissionais de UX Research devem Resolver Junto das Organizações - Ser Estratégico
Introdução
Definindo Estratégia, de uma forma descomplicada, é um plano de alto nível, tipo “Eagles Eyes” que nos permite atingir determinados objetivos.
As organizações precisam de definir uma estratégia comum a todas a pessoas de todas as direções para que haja um conhecimento claro e comum de quais os objetivos a atingir.
Obviamente que as Organizações terão em cada direção uma estratégia diferente. Por exemplos, a Direção de Vendas pode ter como estratégia aumentar o volume de vendas do produto A; ou aumentar a penetração no mercado e a frequência de compra do serviço B.
A Direção de Marketing pode ter como estratégia aumentar o awareness de um produto; ou aumentar o volume de leads para o HubSpot.
Mas o que é que os profissionais de UX têm a ver com as estratégias dos diferentes direções das Empresas, perguntam? É que se os profissionais de UX, nomeadamente os UX researchers não conhecerem e/ou não forem envolvidos nessas estratégias, não poderão ajudar as diferentes direções a atingir os objetivos globais da Organização. E isso faz com que percamos o nosso espaço dentro da Organização, uma vez que não demonstramos e/ou o C-Level não entendem o valor que o nosso trabalho aporta Organização. E não é pouco!
Os Objetivos Globais das Organizações
isso faz com que percamos o nosso espaço dentro da Organização, uma vez que não demonstramos e/ou o C-Level não entendem o valor que o nosso trabalho aporta Organização. E não é pouco!
Todos os objetivos, prioridades, estratégias, vão afetar a experiência de cliente e portanto os profissionais de UX têm tudo a ver com isto 🙂 e, consequentemente, os profissionais de UX devem ser envolvidos no delineamento dos objetivos, prioridades e estratégias desde o momento zero.
A Importância do Trabalho dos Profissionais de UX nas Organizações
Atualmente, ou melhor dizendo, na maioria das Organizações o trabalho dos Profissionais de UX é um trabalho tático e não estratégico. E sendo visto como tático, somos vistos apenas como basicamente corresponde apenas a atividades quotidianas que fazemos no dia-a-dia: os famosos “deliverables” (wireframes, protótipos LOFI/HIFI, customer journeys…). Ou seja, podemos estar na Empresa A, a trabalhar o produto B que somos vistos da mesma forma, já que os deliverables são os mesmos, independentemente de Empresa ou do Produto.
Como visto acima, a Estratégia é um plano “Eagles Eyes” que traçamos para atingir os objetivos pretendidos. E para que isso aconteça, é preciso termos o maior e melhor conhecimento possível da situação interna e externa da Organização, porque é a esse plano (estratégia) que vai determinar como a Organização vai cumprir os objetivos. Portanto, a estratégia foca-se mais nos objetivos, prioridades, e nos recursos e skills necessárias para que o objetivo sejam cumpridos.
Então é fácil perceber o hiato que existe entre UX tático e UX estratégico. É que se os profissionais de UX não forem envolvidos no delineamento dos objetivos, priorização dos trabalhos e alocação de recursos e skills tudo isso vai influenciar a experiência final do cliente com a nossa Organização/Produto. Por exemplo, se priorizarmos algo que não traz valor para o cliente, se almoçarmos profissionais sem as skills certas ou mais desenvolvidas para a execução do trabalho. Tudo o que é estratégico vai influenciar a experiência de cliente.
Então, mas como é que o trabalho dos profissionais de UX pode influenciar o plano estratégico das Organizações? A questão é que o trabalho dos profissionais de UX como é visto pela maioria das Organizações é num trabalho que emerge das estratégia (como já visto) e portanto, não pode influenciar. Engano! Pode e deve influenciar através das atividades de UX Research que essas sim, podem e devem alimentar a estratégia das Organizações. Ou seja, deixamos de estar a adivinhar o que os clientes querem ou que os stakeholders querem. Isto é a mudança de Paradigma para as Organizações: o trabalho dos profissionais de UX está a montante (Research) e a jusante (Nova Experiência de cliente) da Estratégia das Organizações.
As Organizações focam-se nos Outputs e não nos Outcomes (próximo artigo que publicarei).
Os Diferentes Níveis de Maturidade de UX Research das Organizações
Já vimos a importância que as atividades de UX Research têm na prossecução da estratégia das Organizações. Mas será que as Organizações estão preparadas para isso? Diria que não, ou que estando preparadas não fazem uso dessa preparação/maturidade de UX Research.
Tudo se resume a:
1 – Definimos corretamente o problema que temos em mãos? Sim /(Não)
2 – E compreendemos bem esse problema para definirmos bem o que temos de desenhar/desenvolver? Sim /(Não)
3 – E desenhamos/desenvolvemos bem o que tínhamos a desenvolver? Sim /(Não)
E isto torna-se algo interativo e em loop de forma a que a experiência de cliente se torne melhor e produza valor para o negócio.
É neste trabalho de UX Research que o trabalho dos profissionais de UX se torna estratégico, mas por norma as Organizações ficam nos entregáveis de um “design melhor”. Os níveis de maturidade de UX Research nas Organizações são diferentes, ora vejamos:
- Estádio 0 – Inexistência de Atividades de UX Research
- Estádio 1 – Testes de Usabilidade básicos e Ad-Hoc > Testes de Usabilidade com base em criação de atividades da “nossa cabeça”
- Estádio 2 Testes de Usabilidade intermédios > Testes de Usabilidade com base em criação de atividades com base naquilo que são os findings da área de suporte ao cliente
- Estádio 3 Testes de Usabilidade Avançados > Testes de Usabilidade com base em criação de atividades já com base nalgumas atividades de UX research com clientes (entrevistas) ou seja, pode até ja ter havido alterações ao protótipo)
- Estádio 4 UX Research de Campo Básico> Presença esporádica nos ambientes em que vivem os clientes no sentido de adquirir conhecimentos sobre a utilização que os mesmos dão ao produto/serviço. Há pouca ou nenhuma interação com os clientes e mais observação, ainda que esporádica
- Estádio 5 – Research Focado no Campo > Teams seek out users and environments to fill in gaps in the team’s knowledge.
- Estádio 6 – Estudos de Campo Longitudinais > As equipas conduzem atividades de research já com algum nível de profundidade sobre a vida dos clientes, seja antes, durante e depois da utilização do produto/serviço
- Estádio 7 UX Research Estratégico > As atividades fazem parte da Organização/Projeto e em que realmente passamos tempo com os clientes em todas as fases da sua jornada e utilizando várias técnicas de UX Research para produzirmos findings e insights constantes e permanentes que alimentarão as atividades nossas e de outras direções da Organização
Adaptado do Modelo idealizado por Jared Spool
Conclusão
É fácil perceber que os profissionais de UX, sejam eles especialistas em Research, em Growth em Analytics (os de Research devem-no ser) ou tendo outra especialização, têm um papel preponderante na estratégia das Organizações e não devem ser vistos (e muitas vezes posicionam-se como tal) apenas como meros executores de wireframes, protótipos, user interfaces,…..As Organizações não se devem focar no “Construir Bem”a 100%, mas sim dar mais ou muito mais foco na “Definição correta do Problema”. Para que as Organizações (nomeadamente as presentes em Portugal) tenham cada vez mais sucesso precisam de ter maturidade no que ao estudo da envolvência e dos seus clientes diz respeito. Temos de melhorar a vida dos nossos clientes e o seu comportamento (estratégia) e não construir algo com base nas nossas necessidades e não das deles (tático). E acredito que isso seja um trabalho que deve ser mútuo e construído pelos profissionais e pelas Organizações.