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.
Será Diferente Criar um Produto Digital em Ambiente Agile ou Waterfall?
Introdução
Já vimos na PARTE 1 – O que são Produtos Digitais. E na PARTE 2 – O que Envolve Criar Produtos Digitais? E como o Tema está Relacionado com o Scrum.
Vamos agora ver na PARTE 3 – se Será Diferente Criar um Produto Digital em Ambiente Agile ou Waterfall?
Ambiente Waterfall
Em ambiente waterfall significa, de forma não exaustiva, o seguinte:
- O tipo de projeto não envolve incertezas. Ou seja já se sabe o que se vai desenvolver/construir. Por exemplo, uma casa ou uma piscina.
- As as atividades desse projeto, por estar inserido num ambiente de certeza e não de incerteza, são desenvolvidas sequencialmente. Ou seja, após o términos de uma atividade, começa-se a segunda.
- Não existe um envolvimento direto do cliente e, por conseguinte, não é costume haver iterações à medida que as atividades vão sendo desenvolvidas
- Havendo possibilidade e vontade em fazer testes, estes são feitos em grande escala no final de todas as atividades estarem concluídas
Ambiente Agile
O ambiente agile significa, o contrário do ambiente waterfall. Ou seja, e de forma não exaustiva:
- Os projetos mais adequados para serem desenvolvidos neste tipo de ambiente são projetos complexos e que envolvem algum grau de incerteza. Por exemplo, o desenvolvimento de um produto digital, enquadra-se neste tipo de projetos.
- Todas as atividades que se consideram necessárias para produzir um incremento, são realizadas no sprint correspondente. E, portanto, daqui surgem duas grandes diferenças de projetos em ambiente waterfall e ambiente agile:
- As equipas devem ser multi-disiplinares e autónomas
- Os testes, devem ser considerados uma atividade que produz um incremento e, portanto, são realizados em cada sprint e não no final do projeto. Até porque, e passamos para o ponto 3…
- Tem de existir um envolvimento direto do cliente. Isto porque não sabemos a 100% como vai ser o produto final. E o cliente também não sabe. E, portanto o cliente tem de estar envolvido no desenrolar do projeto. Por exemplo, criando atividades de UX Research na fase em que Visão do Produto está a ser desenvolvida. E com isso, valorizamos e muito o início do projeto, porque a Visão do Produto incorpora findings e insights daquilo que são as necessidades, frustrações e motivações dos cliente.
- Outra altura onde o cliente pode estar presente será nas cerimónias de review para recolha direta de feedback. e, por conseguinte, não é costume haver iterações à medida que as atividades vão sendo desenvolvidas. Ou seja, e vamos para o ponto 4…
- Há iterações entre as equipas, clientes e stakeholders. Iterações essas que nos vão permitindo afinar o produto final. Como? Redefinindo e refinando o backlog prioridades de produto e, posteriormente, o backlog da sprint.
Conclusão
Poder-se-ia dizer que se as metodologias, ou melhor, se os ambientes ou frameworks são diferentes, então, obrigatoriamente, será diferente criar um produto digital em ambiente agile do ambiente waterfall. E dizer isto não está errado. Afinal é uma verdade de La Palice.
O problema é que não basta dizer que estamos ou adotamos uma metodologia agiela e o desenvolvimento do produto digital, per si, será diferente.
Quem faz os ambientes serem waterfall ou agile ou de outro tipo são as pessoas. E, portanto, se não houver vontade, motivação, aprendizagem e um step-up, sem medos e com compreensão 100% da hierarquia de quais são os papéis de cada um e o que isso implica, para mudar a cultura da Empresa e assim efetivamente implementar o ambiente agile, o que vai acontecer é que estaremos a desenvolver um produto digital em ambiente “pseudo-agile”; ou seja na realidade o ambiente é waterfall.
Há várias de formas de perceber isso, elenco apenas quatro:
- O cliente não é envolvido de início e ao longo do desenvolvimento
- As equipas não são multi-disciplinares nem autónomas
- A priorização das atividades ou a re-priorização das mesmas ou de algumas delas, não é feita pelo PO, mas está dependente do cargo da pessoa que faz um pedido.
- Os testes são feitos “em barda” dias antes do lançamento do produto para o mercado
Espero que tenham gostado e aprendido alguma coisa neste conjunto de 3 artigos sobre produtos digitais.
O que Envolve Criar Produtos Digitais? E como o Tema está Relacionado com o Scrum
Introdução
Já vimos na PARTE 1 – O que são Produtos Digitais. Vamos agora ver o que envolve, em termos de negócio e de equipas, criar um produto digital.
A PARTE 3 – Será Diferente Criar um Produto Digital em Ambiente Agile ou Waterfall? Será publicada no final do mês de Agosto.
O que Envolve Criar um Produto Digital?
Criar um produto digital não é pensar o design e depois bater código. Desenvolver um produto digital envolve muito mais do que design e desenvolvimento. Tal como a construção de uma casa não envolve apenas um desenho do arquiteto. Ainda que a construção de uma casa seja um projeto fechado e um projeto que decorre em ambiente certo.
Existem diferentes temas que são essenciais para descobrir, posicionar, desenvolver, monitorar, comunicar e impulsionar a adoção deste tipo de produtos.
Visão do Produto – Envolve identificar os diferenciais do produto, definir a proposta de valor única e criar mensagens de marketing que comuniquem esses aspectos de maneira convincente.
User Experience Research – Antes de se criar um produto digital, é crucial realizar perceber quais as necessidades, motivações, frustrações, expectativas e emoções dos clientes ou potenciais clientes.
O trabalho de desenvolvimento de um produto digital deve ser feito com base em Outcomes e não em Outputs.
As atividades de UX Research fornecem uma base sólida para as decisões de design, permitindo que as equipas validem hipóteses, identifiquem problemas de usabilidade e iterem rapidamente com base no feedback dos utilizadores. Além disso, o foco contínuo nas atividades de UX Research possibilita a adaptação às mudanças ao longo do projeto, tornando o Scrum ainda mais eficiente e eficaz na entrega de soluções inovadoras e centradas no usuário.
User Interface Design – Aspeto fundamental do processo de desenvolvimento de produtos, dedicado a criar interfaces visualmente atraentes e user friendly que melhoram a experiência geral dos utilizadores. Estas atividades de desenho do user interface concentram-se em temas que permitam desenvolver interações entre os utilizadores e esses produtos digitais, garantindo que cada interação seja fluida e intuitiva
O User Interface Design não é só algo estético; deve haver um esforço para se encontrar o equilíbrio entre forma e função. Um interface bem pensado (UX Research) guiará os utilizadores ao longo do produto de forma suave e sem atritos, ajudando-os a realizar as suas atividades de forma eficiente e com o mínimo de frustração.
Podem saber mais sobre o tema Como Definir os Princípios de Design.
UX Writing ou Marketing de Conteúdo – A criação de conteúdo relevante e valioso é fundamental para a atração e retenção de potenciais utilizadores dos nossos produtos. O UX Writing não se restringe só à escrita de textos para blogues. Todo o conteúdo de um website ou loja online ou de outro produto digital deve ter uma estratégia de UX Writing. Além dos de vídeos, animações, white papers ……
E é preciso saber como escrevê-los; onde colocá-los no nosso produto e quando colocá-los.
SEO – A otimização para os motores de pesquisa é fundamental para garantir que o produto digital seja encontrado online, quando os utilizadores pesquisarem por keywords relevantes. Isso envolve a criação pensada e estruturada da arquitetura de Informação desse produto digital, a inserção/utilização adequada de keywords de forma a otimizar o conteúdo e a criação de backlinks.
O UX Writing ou Marketing de Conteúdo e o SEO são disciplinas que têm muita interligação entre si.
Acessibilidade – A acessibilidade no contexto do design, dentro de uma equipa que utiliza o Scrum, refere-se às atividades e práticas implementadas para garantir que o produto desenvolvido seja inclusivo e facilmente utilizado por todas as pessoas, independentemente de suas capacidades e/ou necessidades específicas. Este tema, tal como os anteriores e os a seguir devem ser considerados pelas equipas desde o início das atividades do projeto, incorporando-a em todas as etapas do ciclo Scrum.
Este tema, deverá ser também tido em conta aquando das atividades de UX Research. Podem ler mais sobre Empathy as a Service.
Analytics — Desempenha um papel fundamental no desenvolvimento de produtos dentro de um ambiente ágil. Ao aproveitar o poder dos dados e os insights que se obtêm a partir deles, as equipas podem tomar decisões informadas em cada etapa do processo de desenvolvimento.
Análises qualitativas — A incorporação de análises qualitativas capacita as equipas a adaptar estratégias com base no feedback dos clientes e em tempo real, garantindo que as suas necessidades, motivações, frustrações são tidas em conta no desenvolvimento do produto.
Análises quantitativas — Essas análises permitem compreensão profunda dos comportamentos, preferências e pontos problemáticos dos usuários, o que influencia significativamente o aperfeiçoamento e a otimização de produtos digitais. Podemos utilizar ferramentas de web analytics e/ou de user behaviour analytics.
Desenvolvimento – As atividades de desenvolvimento é tudo aquilo que engloba colocar em prática todo o trabalho desenvolvido nas atividades anteriormente descritas. O trabalho de desenvolvimento não é só olhar para o “design” e começar a programar. Algumas atividades que devem ser tidas em conta antes do desenvolvimento front-end e back-end apresentam-se abaixo.
-
- Arquitetura funcional
- Arquitetura técnica
- From-end development
- Back-end development e Gestão de Base de Dados
- Integração de sistemas e desenvolvimento de infra-estruturas
Testes – Em ambiente agile todas as user stories devem ser testadas pelo membro da squad para o efeito. Desenganem-se aqueles que acreditam que os testes são feitos pelas pessoas das organizações ou que se podem fazer depois testes de usabilidade com os clientes. Deixarmos a realização dos testes, com as funcionalidades já em produção, para outras pessoas e/ou para os clientes fazerem é meio caminho andado para que a dívida técnica/UX aumente. Além de que não cumpre com aquilo que a framework do scrum apregoa.
-
- Testes de Carga do Servidor
- Testes das Funcionalidades
- Produção de quick reports com as respetivas conclusões/correções a fazer
Depois numa fase já mais estabilizada do produto, podemos desenvolver então os testes com os utilizadores.
Gestão da Release – A gestão da release no contexto do Scrum refere-se ao processo de planeamento, coordenação e entrega dos outputs, sempre baseados em outcomes (o que defendo) desenvolvidas ao longo das várias sprints pronto para ser disponibilizado aos utilizadores.
Muito importante na gestão da release, nomeadamente se for uma gestão da release já com o produto “fechado” (se bem que o produto nunca estará fechado) é a definição da estratégia de lançamento.
Estratégia de Lançamento – A estratégia de lançamento engloba as atividades que têm como objetivo informar os utilizadores sobre as diversas vertentes do produto. A estratégia de lançamento focam-se, na sua maioria, em temas de comunicação como:
- Campanhas offline (TV, rádio, jornais, revistas, outro tipo de publicações)
- Organização de Eventos
- Campanhas online (e-mail, ppc, social media, afiliados, ….)
- Redes Sociais
- Influenciadores
Conclusão
É fundamental ter em atenção a todos estes temas quando se desenvolve um produto digital, seja em ambiente agile ou ambiente waterfall. Nomeadamente, é imperativo considerar estes temas em cada uma das fases dos ambientes agile:
- visão do negócio/produto
- Desenvolvimento do backlog do produto
- Desenvolvimento do backlog da sprint (Priorização de acordo com aquilo que é a visão do negocio)
- Cerimónias de Planeamento
- Cerimónias de Review
- Cerimónias de Retrospective
Além disso, fica bem patente, tal como o Scrum advoga, que um desenvolvimento de um produto digital não é só desenhar e programar o desenhado.
Sabe mais sobre Scrum neste artigo – Scrum for Dummies”: Papéis e Eventos – Comparação com o Futebol
O que são Produtos Digitais?
Introdução
Quando pensei escrever este artigo tinha imaginado um título do género “Como gerir projetos digitais (ou não) que são transversais à Empresa e/a determinado produto digital em ambiente agile”. Mas dediquei algum do meu tempo a pensar no assunto e percebi que o título não faz sentido algum.
E para não tornar o artigo demasiado longo dividi-o em 3 partes:
PARTE 1 – O que são Produtos Digitais
PARTE 2 – O que Envolve Criar um Produto Digital
PARTE 3 – Será Diferente Criar um Produto Digital em Ambiente Agile ou Waterfall?
O que são Produtos Digitais?
Um produto digital é todo o produto que pode ser utilizado e/ou comercializado online. Ou seja, podemos ter como produtos digitais aqueles que são passíveis de download e aqueles que não são passíveis de download:
Produtos Digitais Passíveis de Download
- Produtos que os utilizadores podem fazer o seu download e começam a utilizá-lo. Por exemplo uma App para afinar a guitarra como o Guitar Tuner.
Produtos Digitais Não Passíveis de Download – SAAS / Cloud Software
- Produtos em que os utilizadores não necessitam de fazer download dos mesmos e ainda assim utilizá-los na modalidade de free, paga ou freemium. Todos os Softwares As a Service são este tipo de produtos. Por exemplo, a Google Cloud Platform funciona como SAS.
Produtos Digitais como Extensão da Experiência de Cliente – Canal Online
Depois ainda existe uma categoria de produtos digitais que são um misto entre as duas categorias acima. E que eu caracterizo não como produtos digitais, mas sim como táticas ou canais de comunicação com os utilizadores. Por exemplo:
ebooks – livros; Webinars – Conferências; PodCasts – Entrevistas; Cursos online – aulas presenciais; Websites/Lojas Online – sede ou loja física
Conclusão
A criação de produtos digitais, não é desenhar e desenvolver o front-end desse desenho. Nem é desenvolver o back-end desse front-end.
Pensar em desenvolvimento de produtos digitais com foco apenas em design, front-end e back-end vai dar origem a:
1 – Potenciais MVPs mal definidos
2- Desenvolvimento de produtos com base em features (outputs) e não outcomes (mudança que queremos ver no mundo ou nas pessoas para que a vida delas se torne melhor)
3 – Dívida Técnica com uma enormidade de bugs e issues para corrigir
4 – Custos escondidos – de desenvolvimento ou de redesenvolvimento; horas-extra da equipa; possíveis custos no suporte ao cliente, entre outros
Será isto fácil de implementar nas empresas? Certamente que não o é! Mas é meio caminho se as pessoas envolvidas tiverem esta visão e a colocar em prática, mesmo que devagar este princípio.
O próximo artigo PARTE 2 – O que Envolve Criar um Produto Digital
Mas Afinal o que é um MVP - Minimum Viable Product
Introdução
Este artigo será de leitura curta, mas contém informações sobre o que é um MVP, ilustrado com alguns exemplos paradigmáticos que suportarão a própria conclusão do artigo.
Definição de MVP – Minimum Viable Product
O termo MVP – Minimum Viable Product foi popularizado pelo autor Eric Ries, autor do best-seller “The Lean Startup”. Sua definição diz que um MVP – Minimum Viable Product é uma versão do novo produto que nos permitirá recolher a máxima quantidade de aprendizagem validada sobre os consumidores, com o mínimo de esforço possível. Em suas próprias palavras: “The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about the customers with the least effort.”
Será que as empresas e as equipas estão definindo e entregando efetivamente um MVP?
Lendo e compreendendo a definição de MVP – Minimum Viable Product, uma questão surge nos dias de hoje:
1 – Será que precisamos desenvolver um produto com um número mínimo de recursos para termos um MVP? A resposta é NÃO.
No entanto, a maioria das empresas e equipes que trabalham nesses assuntos acredita e faz isso repetidamente, sprint após sprint. O objetivo é entregar algo novo em cada sprint/iteração e no prazo proposto, e depois avaliar o que os clientes acham. Isso piora quando não há essa iteração.
O próprio autor do livro, Eric Ries, dá o exemplo de como foi frustrante desenvolver o que ele pensava ser um MVP. Ou seja, um produto com um número mínimo de recursos, colocá-lo online e pedir às pessoas para fazerem o download. Ele dá esse exemplo porque o número de downloads desse suposto “MVP” foi zero. Isso aconteceu apesar de todo o esforço e investimento feito em campanhas Adwords.
Se esse simples exemplo não for suficiente, analisemos os exemplos de empresas reais no próximo ponto.
Os Custos de uma Má Definição de MVP
Os produtos que não funcionam, ou seja, que não proporcionam uma experiência excepcional aos clientes, têm custos associados, refletindo-se em:
- Dívida técnica e dívida de UX.
- Custos de reputação de marca. A primeira impressão é sempre a que fica, e se a impressão for ruim, isso se traduzirá em custos.
- Custos de suporte e treinamento. Se o produto MVP for ruim, será necessário explicar aos clientes como utilizá-lo.
Exemplos de MVP que não envolvem necessariamente o desenvolvimento de software
Os exemplos apresentados são de Empresas que oferecem uma boa experiência de cliente e tudo partiu de um MVP bem pensado. Lançar um MVP não é uma atividade fácil. É preciso saber muito bem o que se pretende com o produto que estamos a desenvolver; perceber as necessidades dos potenciais clientes e a partir dai pensar no que pode mesmo ser o seu MVP e não a versão 1.0 ou versão beta. Vejamos os exemplos abaixo.
Exemplo 1 – DropBox
O exemplo da DropBox é flagrante e paradigmático de que para se desenvolver um MVP não é preciso desenvolver features para um produto. No caso da DropBox o seu MVP foi um video onde se apresentava aquilo que seria o produto e era disponibilizado um endereço de e-mail para as pessoas se inscreverem. A lista de espera beta para o serviço saltou de 5.000 para 75.000 potenciais utilizadores quase da noite para o dia.
Veja o video do MVP da Dropbox
Exemplo 2 – Amazon
Outro exemplo interessante é o da Amazon. O MVP da Amazon baseou-se numa abordagem simples de desenvolvimento de um aplicativo com um back-end manual que os utilizadores não conhecem.
E mais, era o próprio Jeff Bezos a comprar os livros nas livrarias e despachá-los para os clientes pelo correio.
Foi uma abordagem inicial de baixo custo, como se pretende num MVP, mas funcionou. Em dois meses, a Amazon estava a ganhar perto de US$ 20.000 / semana.
Exemplo 3 – Instacart
O exemplo da Instacart é muito semelhante ao exemplo da Amazon.
O seu fundador teve a brilhante ideia de desenvolver um serviço móvel de entregas ao domicílio de supermercado. No entanto, na época, ele não tinha recursos para construir o extenso e complexo back-end do aplicativo.
A solução (MVP) foi o de criar, tal como a Amazon, um back-end manual, ou seja, sempre que uma pessoa encomendava algo do Instacart MVP, os fundadores tinham que comprar esses produtos e entregá-los aos clientes. Tudo manualmente.
MVP vs Versão 1.0 ou Versão beta
As diferenças entre um MVP e uma versão 1.0 ou versão beta de um produto está na sua definição, nomeadamente nos pontos:
- “aprendizagem validada sobre os consumidores”
- “Mínimo esforço possível”
Ou seja, a versão 1.0 ou versão beta de um produto pressupõe um lançamento. E havendo um lançamento, logicamente há ou terá de haver bastante esforço envolvido. Por outro lado, ao lançarmos uma versão 1.0 ou beta, em princípio, estamos cientes já daquilo que iremos lançar e o nosso propósito não é o de recolher findings e insights, ou seja termos uma aprendizagem validada por parte dos consumidores. Não que eles não nos possam dar feedback, mas esse feedback não fará parte do ciclo de iterações que um MVP terá. À partida, uma versão 1.0 de um produto já passou por ser um MVP. Mas um MVP não passa por ser uma versão 1.0 ou beta do produto. A não ser que o que esteja em causa na definição dessa versão 1.0 ou versão beta é a definição correta do MVP.
Mas Como nos focamos em Entregar um MVP na Realidade
O foco das empresas e das equipas em entregar um MVP depende primeiramente na correta compreensão do que é um MVP como visto acima. E tudo isto tem a ver com a cultura. Se a empresa tiver uma forte cultura de research e é madura o suficiente em termos de UX, o foco no que é na realidade um MVP torna-se fácil.
Por outro lado, se a cultura é a do “agile” de sprints a cada 2 semanas, entregar depressa e dentro destes prazos de forma inflexível e sem recorrer a várias iterações em cada ciclo de entrega, então o foco é a entrega de features em detrimento de entrega de outcomes que tem pro base o MVP definido à priori.
Conclusão
Antes de chegarmos a alguma conclusão sobre o que é definitivamente um MVP na prática, convêm perceber porque razão as empresas desenvolvem produtos ou serviços.
Eu diria que existem 2 tipos de razões. Um primeiro tipo de razões são aquelas em que o foco está no Outcome proporcionado. E um segundo tipo de razões são aquelas em que o foco está no output. Vejamos cada uma dessas razões:
Razões para desenvolver produtos/serviços em que as empresas estão focadas no Outcome
- Provocar uma mudança no mundo e/ou nos comportamento do cliente que torne a sua vida melhor, mais fácil e vice-versa.
- Surpreender e/ou Deliciar os clientes (relacionada com a primeira razão)
Razões para desenvolver produtos/serviços em que as empresas estão focadas no Output
- Atrair cada vez mais clientes
- Gerar mais receitas (relacionada com a primeira razão)
Desenvolver um determinado produto com uma série de features (mínimas ou que achamos mínimas), pode não ser o nosso MVP e, consequentemente, podemos não estar a entregar valor aos clientes, e não entregamos valor ao nosso negócio. Mas acima de tudo, não conseguimos iterar com os clientes de forma ideal para que possamos realmente apresentarmos um produto que seja “valioso” para os clientes e nos traga valor para o negócio. Isto porque não temos as iterações suficientes em termos de research.