Business Archives | João Carlos Matos

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.

by João Carlos Matos

Sistematizando os conhecimentos de Vibe Coding

Como Criei uma POC de Sistema de Recomendação com Vibe Coding no Replit - Parte 2

Sistematização da Experiência Vibe Coding utilizando o Replit

Introdução

Na Parte 1 escrevi sobre o que é o Vibe Coding, sobre os diferentes níveis de pensamento que o mesmo exige e como isso me ajudou no desenvolvimento do projeto final da Pós-graduação em Data Science for Business Strategy. Ainda dei alguns exemplos de como apliquei esses diferentes níveis de pensamento
Na PARTE 2 pretendo dar uma visão global daquilo que foi feito para o desenvolvimento do projeto e mostrar partes da aplicação prática para o desenvolvimento da POC.

CRISP-DM

A metodologia utilizada na elaboração do projeto foi a CRISP-DM - Cross Industry Standard Process - Data Mining.

Entendimento do problema e do negócio – Na escolha do projeto defini o Problem statement para justificar a escolha deste tipo de projeto e os benefícios que poderia trazer para o negócio. E com isso, escolher um dataset que fosse possível ser trabalhado (se bem que à partida um data scientist não sabe o que vai encontrar).
Entendimento dos dados – O dataset escolhido foi uma amostra representativa do Dataset da Amazon Reviews 2023 – Baby Products. Iniciou-se o trabalho inicial com 50 000 registos e depois 10 000.
Preparação dos dados – Limpeza, remoção de duplicados, tratamento de descrições vazias e criação de stopwords específicas tendo em conta o objetivo do projeto e as necessidades do negócio
Modelagem dos dados e Escolha do Modelo – Escolheu-se, com base nos estudos e em literatura a “Vetorização com TF-IDF (min_df=3, max_df=0.7, ~4 000 features) e cálculo de proximidade semântica através da Similaridade do Cosseno”
Avaliação do Modelo – Algumas métricas que nos revelou o modelo foram uma diversidade de 0.542 e uma similaridade robusta na ordem dos 0.453.
Deploy – Esta fase, por motivos óbvios, estava fora de âmbito. Mas como já sabem, houve a criação de um protótipo funcional Lo-Fi em Replit.

Cada uma das fases acima descritas correspondeu, grosso modo, a uma entrega/avaliação intermediária. Portanto, o que defini acima em cada uma das fases da CRISP-DM não revela metade do trabalho que foi produzido. Aliás, para terem uma ideia, que vale o que vale, o projeto final resultou numa entrega final de um PowerPoint com 108 slides, incluindo anexos.

Toda a parte referente aos diversos steps da metodologia foi desenvolvida e testada fora do Replit. Mas faltava, para proporcionar um momento mais UAU, uma interface funcional para explorar e mostrar resultados de forma simples.

O Ciclo Vibe Coding na prática com o Replit - App Builder

Ao longo do projeto, repeti o ciclo Prompt → Teste → Erro → Debug → Checkpoint dalgumas vezes. Neste artigo irei apenas frisar alguns dos desafios que me lembro que surgiram ao longo desse ciclo. Imagem retirada do website do Replit.

Ciclo de Vibe Coding

Exemplo de Prompt Inicla no Replit

Na realidade não me recordo exatamente de qual foi a prompt com que iniciei o projeto no Replit. Até porque não cheguei a optar pela versão paga. Mas, diria que foi um texto de prompt simples, claro, e do tipo Zero-shot prompt, uma vez que anexei os ficheiros .pkl gerados em Python no desenvolvimento do sistema de recomendação. A prompt inicial terá sido algo como:

"Cria uma interface de um sistema de recomendação com base em conteúdo, que permita ao utilizador escolher um produto (product_id + product_name), e vê devolvidos o TOP 5 produtos (product_id + product_name) mais similares, excluindo o próprio produto escolhido. Para o melhor output possível, analisa os ficheiros anexados referentes à função do sistema de recomendação (func_sist_rec.pkl) e ao dataset já limpo e trabalhado (dataset_clean_final.csv) que serve de base ao sistema."

Alguns Testes

Após a inserção da prompt, corria a aplicação no Replit. O Agente, e depois o Assistente do Replit faziam o seu trabalho e quando terminava lia e analisava (aquilo que conseguia perceber do código) o código gerado e visualizava o output. Ou seja, escolhia um product_id com o respetivo product_name associado no interface e via o resultado.

Os Erros

Obviamente que mesmo com a melhor prompt o sistema vai produzir erros. E temos de saber lidar com eles, corrigindo-os como mencionado na PARTE 1 do artigo. Alguns dos erros que me lembro do sistema ter produzido foram:

O produto escolhido pelo utilizador aparecia na lista de recomendações. O que até me deixada admirado ou frustrado, uma vez que há parâmetros no código que anexei onde se percebe claramente que o produto escolhido não pode ser recomendado. Ou seja, a lógica do threshold de similaridade por exemplo, foi ignorada. A tal importância dos diversos níveis de pensamento para se perceber o que o modelo está a implementar.

O HTML + CSS, ou seja a interface não saiu bem logo à primeira. Alguns dos problemas que me recordo foram:

- Muitos elementos presentes que não eram necessários
- Má conjugação de cores de texto e fundos das células da tabela
- O utilizador tinha que fazer roll-up/down e row-left/right na tabela para poder ver toda a informação

Debugging a little

Em termos de debug, o que ia fazendo era tentando melhorar o interface, analisando algumas coisas que percebia em termos do código, nomeadamente HTML + CSS e afinando as prompts. Por exemplo:

“Adiciona um filtro para excluir o produto atual do resultado. Ajusta as imagens para 150x150 px e centraliza o texto.”

"Filtra os resultados para remover o produto atual e só mostra produtos com score > 0.45. Ajusta o HTML+CSS tendo por base a seguinte paleta de cores: Color matching de 6 cores com #845EC2."

Os Checkpoints…só do Replit

Na realidade o Replit ao ser um App Builder ajuda-nos com o versionamento do código, na medida em que o agente que tem integrado cria frequentemente os checkpoints (pushes) na plataforma. E assim, podemos voltar ao código anterior, caso o output de atual ou da próxima prompt corra mal.

Como disse anteriormente, por ser uma POC e por ser um adicional ao projeto, não senti a necessidade de quando algo estava mesmo funcional, copiar o checkpoint do Replit para um ficheiro para salvaguardar o progresso. Até porque há muita coisa que pode ser melhorada, como verão mais adiante e recordando que estamos a falar da utilização de uma versão free.

Aquilo que aconteceu foi o ter de ir fazendo mais prompts de forma a que o assistente corrigisse alguns temas, como por exemplo:

Evitar a repetição de recomendações duplicadas e Diversificar as categorias – Filtragem explícita no código e garantir a variedade mínima nas recomendações. Isto através de prompts mais claros, com regras do negócio e com explícita indicação para análise da parte X do ficheiro respetivo onde essas regras estava implementadas.

Sistema de Recomendação - Content Based - Baby Products

O que poderiam ser os Próximos passos

Se considerarmos apenas este dataset, os próximos passos imediatos seriam:

Adaptar o interface para todo o dataset e não apenas para uma amostra de produtos

Criar uma Interface que cumpra melhor as best practices de usabilidade, de design, de responsavidade e de acessibilidade e pensar em como poderia ser mais atrativa e interativa. Por exemplo, integrando imagens ou clips dos produtos recomendados.

Conclusão

Como disse no PARTE 1 deste artigo, foi a primeira vez que “utilizei” o Vibe Coding. Embora conhecesse bem o termo, não tinha tido até então oportunidade de dar-lhe prática. E portanto teria tudo para correr mal, ou menos bem e levar a stresses e ansiedade desnecessária do que aquela que um projeto académico já acarreta.
Mas o facto de ter escolhido uma metodologia para elaborar o projeto académico revelou-se fundamental no processo de Vibe Coding. Isto porque obrigou-me a pensar no problema, no projeto mesmo antes de abrir qualquer ferramenta de Vibe Coding. Outra conclusão que retirei, em particular deste projeto é que uma prompt é importante, mas o contexto, que neste caso foi todo o trabalhado de desenvolver o modelo e o algoritmo, é fundamental.

Ou seja, dependendo do nosso objetivo, podemos ter diversos níveis de promtp e de “utilização” do Vibe Coding. E o nível que utilizei não sendo o avançado, também não foi nem de longe nem de perto o básico.

Portanto, Vibe Coding requer pensamento, metodologia e trabalho. Trabalho esse que é iterativo “Prompt → Teste → Erros → Debug → Checkpoint”, nomeadamente nas fases de Teste e de Checkpoint

Agradeço à Maria Antónia Marques que fez parte do grupo de trabalho

by João Carlos Matos

Como Criei uma POC de Sistema de Recomendação com Vibe Coding no Replit - Parte 1

Introdução

O principal objetivo deste artigo é o de sistematizar algum do meu conhecimento sobre Vibe Coding adquirido na pesquisa e estudo de matérias relacionadas e no desenvolvimento do projeto final de Pós-graduação em Data Science for Business Strategy.

Importante, ou curioso dizer que o projeto foi feito sem qualquer tipo de conhecimento sobre as Best Practices de Vibe Coding. Acima de tudo foi “utilizado” o senso comum e os mais de 12 anos de experiência académica e profissional em ambiente digital em agências, multinacionais e clientes.

Esta é a PARTE 1 onde se resume aquilo que é o Vibe Coding. Na PARTE 2 pretendo dar uma visão global daquilo que foi feito para o desenvolvimento do projeto e considerando que é uma POC e que tem/teria ou terá próximos passos no seu desenvolvimento.

O que é Vibe Coding

O meu entendimento de Vibe Coding é o seguinte: são as ações e as interações que um utilizador tem, através de prompts, com uma ferramenta de Inteligência Artificial Generativa, ou seja uma ferramenta que tem na sua base algum tipo de Modelo LLM (Large Language Model). E o objetivo é que essa ferramenta o auxilie na produção de “código fonte” para o desenvolvimento de um website, aplicativo, mobile app ou sistema.

Agora a definição ou de onde surgiu este “termo” de Vibe Coding.

“There's a new kind of coding I call "vibe coding", where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. It's possible because the LLMs (e.g. Cursor Composer w Sonnet) are getting too good. Also I just talk to Composer with SuperWhisper so I barely even touch the keyboard. I ask for the dumbest things like "decrease the padding on the sidebar by half" because I'm too lazy to find it. I "Accept All" always, I don't read the diffs anymore. When I get error messages I just copy paste them in with no comment, usually that fixes it. The code grows beyond my usual comprehension, I'd have to really read through it for a while. Sometimes the LLMs can't fix a bug so I just work around it or ask for random changes until it goes away. It's not too bad for throwaway weekend projects, but still quite amusing. I'm building a project or webapp, but it's not really coding - I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works”. Por Andrej Karapathy no Twitter em 2 de Fevereiro de 2025. Ou seja, não se pode dizer que seja algo novo.

O Benefício e a Consequência do Vibe Coding

Para mim só existe um benefício na utilização do Vibe Coding, e quando o mesmo é minimamente bem “desenvolvido”: o Aumento da Produtividade das equipas e o encurtamento do tempo do time-to-market. Ou em linguagem de Product Management, redução do tempo do “Product Market-Fit”.

Tudo o resto serão consequências desse benefício, como por exemplo:

- Possibilidade de irmos da “Ideia” ao “MVP” em muito menos tempo e, provavelmente sem qualquer ajuda de programadores ou de engenheiros de software.
- Possibilidade da redução dos custos, pelo menos na fase inicial de MVP e Product Market Fit.

Ou seja e se repararem, o Vibe Coding poderá possibilitar ganhos de produtividade na fase inicial. Porque no desenvolvimento concreto e final talvez os ganhos de produtividade não sejam assim tão significativos. De forma global, e é a minha opinião, não sei se será assim tão significativo os ganhos de produtividade. Porque Vibe Coding como vamos ver não é escrever um “prompt” na ferramenta com um modelo de LLM. E isto leva-me a…

Uma consequência menos positiva é que, e apesar de tudo, o Vibe Coding pode estar limitado pela “experiência dos developers”. Ou seja, ainda que não precisemos de conhecer, tecnicamente, (eu acredito que os ganhos de produtividade se dão se efetivamente se saiba alguns conceitos mais técnicos da engenharia de software e programação), temos de saber pensar e estruturar o nosso pensamento.

As Soft-Skills Necessárias ou Recomendas para Vibe Coding

Não existem requisitos mínimos para se começar a ter as “vibes” dentro de uma ferramenta de vice Coding. Qualquer pessoa por menos experiente que seja na área Digital ou de Tecnologia, pode desenvolver um aplicativo utilizando o “Vibe Coding”, como vimos acima. Mas, para quem trabalha na área Digital e da Tecnologia, ter-se o mínimo de Product Sense e de Atenção ao Detalhe e mais dois ou três aspetos fará toda a diferença e, efetivamente, aumentará a produtividade.

Mas em que é que isso se traduz? Traduz-se em conseguir:

- Ser Preciso - Se tivermos Product Sense e/ou Conhecimento do Negócio será mais fácil e produtivo visualizar um projeto, uma aplicação, sistema o que seja e quebrá-lo em várias fases que se revelarão várias atividades de interação com a ferramenta de LLM
- Ser Específico - Precisamos de saber fazer prompts
- Ser Organizado e Estruturado - Precisamos de organizar e estruturar o nosso projeto (mais à frente falarei sobre o Pensamento Crítico).
- Ser Paciente - Muitas vezes as coisas não vão acontecer bem logo com a primeira “vibe”. Mas se formos pacientes, tivermos minimamente uma visão daquilo que queremos desenvolver, soubermos fazer os prompts ou corrigi-los e soubermos fazer o debug ou “perguntar” como se faz esse debug e aceitar as correç\oes do debug, a “coisa dá-se ou dar-se-á”.As Hard Skills Necessárias ou Recomendadas para Vibe Coding

As Hard-Skills Necessárias ou Recomendas para Vibe Coding

Pensamento Lógico

O pensamento lógico é a base de tudo. Está relacionado com a capacidade de tirar conclusões válidas a partir de premissas. Em programação, é o que nos permite fazer perguntas como "se isto for verdadeiro, o que acontece?" ou "como garantir que determinada condição seja respeitada?”. Os If, then.

Na POC, usei pensamento lógico, por exemplo, ao decidir que o sistema só deveria recomendar conteúdos que não fossem o produto que estivesse a ser visualizado pelo utilizador. A lógica por trás desta decisão é simples: se um utilizador está a ver um produto A, seria estranho o sistema recomendar esse produto A (100% similar) e pouco valioso para o negócio.

Pensamento Analítico

Este tipo de pensamento é útil quando precisamos “quebrar” o tal projeto ou problema em partes/atividades menores para compreendê-lo melhor, e tornar mais fácil a nossa vida e a vida da IA.

No contexto da minha POC, utilizei pensamento analítico ao dividir o desafio geral de “criar um sistema de recomendação” em subproblemas: obter dados de entrada, definir uma estratégia de recomendação simples (por exemplo, baseada em similaridade), apresentar os resultados, etc..

Pensamento Computacional

O pensamento computacional é o que permite transformar ideias em soluções automatizadas. Vai além da lógica e da análise: trata-se de pensar como uma máquina, estruturando os dados e as ações de forma que o computador consiga executar.

Na prática, apliquei este tipo de pensamento ao desenhar um algoritmo simples que percorre a base de dados e encontra itens similares com base em características em comum. Também pensei computacionalmente ao decidir como representar os dados dos utilizadores e dos itens — listas, dicionários, arrays, etc.

Pensamento Procedimental

Por fim, o pensamento procedimental foca-se na criação de uma sequência de passos claros e reutilizáveis. É a base para construir funções, loops e fluxos organizados de execução.

Durante o desenvolvimento da POC, criei funções como generate_recommendations() ou filter_items() para encapsular lógicas reutilizáveis e tornar o código mais limpo e modular. Isso não só facilita a leitura e manutenção, como também me permitiu testar partes do sistema isoladamente.

Os Diferentes Níveis de Desenvolvimento no Vibe Coding

Existem 3 níveis de desenvolvimento no Vibe Coding:

Planeamento - Antes de começar a "enviar vibes", é fundamental ter uma ideia estruturada do que queremos desenvolver. Este é o momento de esclarecer o problema, definir funcionalidades básicas e imaginar o fluxo do utilizador. Por exemplo, na POC do Sistema de Recomendação, comecei por perceber o que era um sistema de recomendação com base em conteúdo e a trabalhar os dados nesses sentido, mesmo antes de abrir o Replit. Aliás, só houve decisão de utilizar o Replit para tornar a apresentação final mais real e menos monótona.

Pensamento Lógico e Estruturado - Mesmo que a ferramenta de LLM nos ajude a gerar o código, somos nós que devemos guiar a lógica do projeto. Isto implica saber raciocinar em termos de condições, estruturas, inputs e outputs. Foi aqui que apliquei a lógica de "não recomendar o produto que o utilizador já está a ver", por exemplo.

Comunicação com o LLM - Asim, estamos a falar das condições mínimas para se fazer prompts, a tal “Engenharia de Prompt”: saber como explicar ao modelo o que queremos, testar, adaptar e iterar. Percebi que quanto mais específico e organizado for o meu pedido, mais eficiente e preciso é o resultado. E mesmo assim houve coisas que falharam por falta de tempo, nomeadamente ao nível da User Interface Design. Mas como era uma POC, não me preocupei, mas sei o que está mal ou o que está menos bem, porquê e como melhorar.

O Conhecimento Mínimo das Frameworks

Existem inúmeras frameworks utilizadas para desenvolver ativos digitais. Por exemplo existe a Laravel para desenvolver em PHP, existe o React para desenvolver em JavaScript e por ai forma.

Mas mais importante do que perceber as ferramentas é entender como é que os websites, as apps, os aplicativos, os SaaS ou os sistemas funcionam? Existe uma base mínima para o seu funcionamento. Por exemplo, os websites têm um front-end, um Back-end e dependendo do website podem ter uma ou várias bases de dados. Entender estes conceitos vai-nos ajudar na altura de começar a produzir as “vibes” junto do LLM presente na ferramenta que escolhemos. Se entendermos isto, sabemos o que a ferramenta vai conseguir ou deve desenvolver e aquilo que não consegue ou não pode porque não faz sentido. No caso da POC a framework seria o modelo ou os modelos estatísticos e de NPL a serem utilizados.
Não vamos pedir a um construtor automóvel para na sua plataforma de automóveis ligeiros, construir um motociclo e colocar-lhe portas.

Afinal o que são os Checkpoints

Por várias razões, por exemplo como veremos mais à frente o código pode não funcionar da forma como pretendemos. E para isso é preciso criar checkpoints. Checkpoints nada mais são do que versões do código que fazemos ou devemos fazer

Na engenharia de software ou na programação, os checkpoints são o versionamento do código feito no GitHub ou no BitBucket (ferramentas de código mais comuns para versionamento de código) vi “pushes”, “pulls” e “forks”.

A Importância do Debugging e do QA

OK, estamos a ter as nossas “vibes” com a ferramenta que por trás corre um Modelo de LLM. Mas como sabemos se aquilo que está a ser desenvolvido está a funcionar. Sabemo-lo através do debugging/QA. E o que é importante perceber ou analisar: como é que o código está a funcionar? Temos todas as dependências instaladas e a funcionar? Onde é que o erro está a acontecer? Porque o erro está a acontecer? Podemos responder a esta pergunta recorrendo à AI.

Além disso, é importante que tal como se deve quebrar o projeto em atividades, devemos fazer o debugging e/ou o QA por atividade. É quase como se estivéssemos a fazer testes unitários. Qualquer pessoa por menos experiente que seja na área Digital ou de Tecnologia, pode desenvolver um aplicativo utilizando o “Vibe Coding”, como vimos acima. Mas, para quem trabalha na área Digital e da Tecnologia, ter-se o mínimo de Product Sense e de Atenção ao Detalhe e mais dois ou três aspetos fará toda a diferença e, efetivamente, aumentará a produtividade.

Entender o Contexto e Como Evitar Alucinações

Fundamental!!! 100% Relacionado com o Product Sense e/ou Business Sense. Além disso, consoante as nossas “vibes” vão tornando a nossa interação com o modelo LLM mais longa, mais difícil fica para o Modelo entender o que se pretende (Memória do modelo) e mais a probabilidade do Modelo começar a ter alucinações. Isto porque existe um limite máximo de informações que o modelo consegue processar por unidade de tempo. É como se nós explicássemos algo a alguém no primeiro dia de trabalho e passados 1 ou 2 anos se a pessoa não pegar nisso porque não tem o contexto para tal, certamente que se vai esquecer.

Conclusão

O Vibe Coding não é apenas prompts e até talvez não seja um “hype”. É uma nova forma de pensar o desenvolvimento produtos digitais — mais acessível, mais rápida e, quando bem aplicada, extremamente poderosa. E quer queiramos ou não, os engenheiros de software, programadores e quem se interessa pela parte técnica, sai na frente, na minha opinião.

Até porque o Vibe Coding não resolve tudo. A produtividade que se alcança depende diretamente da nossa capacidade de estruturar ideias, comunicar com clareza, raciocinar logicamente e utilizar o “Systems Thinking”, tão importante na Experiência do Clientes e na Transformação Digital das Empresas. Se tivermos estas bases — e mesmo que não sejamos programadores profissionais — podemos construir soluções surpreendentes.

Esta foi apenas a primeira parte do meu processo. E já ficaram com alguns exemplos de como fiz isso na prática. Mas na PARTE 2, vou tentar partilhar como utilizei estes princípios na prática no desenvolvimento da POC Sistema de Recomendação onde utilizei o Replit e o seu modelo LLM.

Alguns dos conceitos foram aprendidos através da Deeplearning.ai

by João Carlos Matos

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):

1. 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
2. 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
3. Sempre trabalhei nas áreas mais técnicas e sempre desenvolvi as minhas competências tendo em conta isso
4. 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
5. 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:

1. 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…
2. Os profissionais com o meu perfil, estão suficientemente preparados para assumir uma função como Product Owner ou como Product Manager, por exemplo.
3. 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.

by João Carlos Matos

O que os algoritmos não veem como a análise superficial de CVs prejudica a identificação de talento multidisciplinar em produto

O que os Algoritmos não Veem: Como a "Nova" Análise de CVs Prejudica a Identificação de Talento Multidisciplinar

Introdução

A nova era da velocidade, mas potencial perda de profundidade

Vivemos na era da eficiência digital. A tecnologia trouxe agilidade às empresas, mas também uma pressa desmedida nos processos humanos. No recrutamento, isso traduz-se na automatização da triagem de currícula, muitas vezes via algoritmos de machine learning, filtros semânticos e sistemas de ATS (Applicant Tracking Systems).

A promessa é boa: filtrar o ruído e identificar o talento. Mas a prática revela um paradoxo cruel: estamos a descartar perfis com competências relevantes, apenas porque não usam a semântica esperada.

Este artigo é uma análise crítica e profissional sobre como a leitura superficial de CVs está a falhar na identificação de talento com experiências transferíveis para áreas como Product Management, Product Analytics e UX Research, através de um exemplo real: o meu.

O novo modelo de análise de CVs

Das heurísticas humanas a inferências automáticas

Historicamente, a análise de currículos era feita com base em julgamento humano, com a possibilidade de vários tipos de interpretações sobre o que se estaria a ler (ou seria analisar?). Hoje, com a pressão por escalar processos de recrutamento, passámos para sistemas automatizados de triagem, denominados de ATS – Automatic Tracking Systems.

Dada Science por detrás dos ATS

Nuances como contexto e transferência de competências

Esses sistemas utilizam técnicas estatísticas aplicadas em contexto de NLP (Natural Processing Language), para modelar features em dimensões categóricas como são os textos, extraindo entidades e vetorizadores de texto para identificar “match semântico” entre a descrição da vaga e o CV do candidato. A ideia é nobre, mas as limitações são técnicas e conceptuais:

Os algoritmos baseiam-se em features como função, hard skills, keywords, anos de experiência e por ai fora. Mas falham em captar, entre outras coisas, as ”soft features” como: pensamento crítico, transferência de conhecimento, contexto de atuação.

Ignoram as experiências que não seguem o padrão semântico estrito do cargo.

Na prática, o ATS clusteriza os candidatos e, como é expectável, com um número (elevado ou não, não está em questão a quantidade, mas a qualidade) de falsos negativos. Ou seja, de perfis que têm à partida as competências certas, mas que são excluídos pela ausência de padrão que o algoritmo necessita.

Isto para não mencionar que não sabemos a forma como o algoritmo foi construído, porque há muitas formas de vetorizar textos e há muitas formas de clusterizar informação. A utilização dessas formas, depende do objetivo que se pretende atingir, do formato e estrutura de dados que o sistema reconhece e por quem faz a manutenção ao sistema.

A transferência de competências: quando o cargo esconde a função real

Look behind the Obvious

Nas áreas digitais, muitas vezes as funções, responsabilidade e atividades inerentes ultrapassam o âmbito formal do cargo. Até diria mais, mesmo em áreas fora do mundo digital, as competências podem perfeitamente ser transferíveis. Por exemplo, um chef de cozinha pode perfeitamente assumir uma função de Product Owner.

Experiência como Chef	Competência Transferível	Equivalência no Product Management
Planeamento de menus	Planeamento estratégico e visão de produto	Definição de roadmap, funcionalidades
Gestão de equipa de cozinha	Liderança de equipas multidisciplinares	Alinhamento com design, tech, marketing
Execução sob pressão	Gestão de dependências e prazos	Gestão de sprints e releases
Controlo de qualidade	Foco na experiência do cliente	Garantia da qualidade do produto
Feedback dos clientes	Empatia e escuta ativa	Product discovery
Otimização de processos	Eficácia operacional	Priorização baseada em impacto/esforço

Voltando ao campo Digital, os profissionais de marketing podem exercer funções de análise de produto. UX researchers podem liderar ciclos completos de Product Discovery. Analistas de dados podem estar envolvidos em decisões estratégicas de produto sem nunca serem chamados de Product Managers ou de Product Analysts, ou Business Analysts.

O problema é que os modelos de análise de CV funcionam com base em cargos e rótulos. Se o termo “Product Manager” não aparece, o sistema assume que o candidato não tem experiência. Isto ignora a realidade do mundo digital moderno, onde as fronteiras entre funções são fluidas e interdependentes. Vivemos num mundo diferente, mas está-se a utilizar a IA, no caso dos ATS, como se vivêssemos há 30 ou 40 anos atrás, em que existia uma profissão para a vida e como tal perfis pouco fluídos e interdependentes.

Caso prático: 12 anos de experiência digital and counting, vistos pela lente errada

Antes de enveredar pelo mundo digital, tive responsabilidade de co-liderança durante 3 anos e depois de liderança durante mais 2 anos na implementação e manutenção de Sistemas de Gestão da Qualidade numa Empresa B2B, setor químico-industrial onde a interdependência entre áreas é enorme: áreas de produção, área de investigação e desenvolvimento, área de produção, área de compras, área de expedição, área de controlo de qualidade, área de manutenção. E a tecnicidade dos temas é diária e deve ser constantemente aprofundada.

Será que um ATS é capaz de analisar estas competências transferíveis para as áreas de Produto ou de Web Analytics? Tenho muitas dúvidas mesmo.

No decurso do meu percurso profissional, trabalhei ao longo de mais de uma década em Digital Marketing, Web Analytics, UX Research e, mais recentemente, como Product Owner com foco em Product Analytics. Assumi funções e responsabilidades e executei atividades centrais em qualquer função relacionada com product management:

Mapeamento de jornadas de utilizador com impacto direto em roadmap
Implementação de tracking e medição de eventos com GTM e GA4
Construção de dashboards com Looker Studio e Power BI
Liderança de discovery qualitativo e quantitativo com utilizadores reais
Interação direta com equipas de tecnologia, design, desenvolvimento e marketing
Escrita de documentação funcional e proposta de melhoria de produto

Experiência como Digital Marketing	Competência Transferível	Equivalência em Product Manager
Product Owner Digital Analytics	Visão estratégica de produto	Definição de roadmap e funcionalidades
Criação de measurement plans	Documentação técnica	Product Requirements Documentation (PRDs)
Mapeamento de customer journeys	User journey mapping	User story creation e journey optimization
Subject-matter expert multidisciplinar	Conhecimento cross- functional	Stakeholder management
Análise de campanhas e insights	Data-driven decision making	Product analytics e KPI management
Desenvolvimento de dashboards	Data visualization	Product performance monitoring
Coordenação de projetos de transformação	Project leadership	Product development leadership
Gestão de equipas de consultores	Team management	Agile team leadership
Criação de Go-To-Market offers	Go-to-market strategy	Product launch strategy
UX-Reseearch e Usability Tests	User research	Product discovery e validation

Tabela de Matriz de Competências desenvolvida com ajuda da AI-Generativa

Esta experiências, apesar de distribuídas por diferentes job titles, são funcionalmente equivalentes àquilo que Empresas com cultura e de produto esperam de um Product Manager ou Product Analyst. Mas essa equivalência é invisível para algoritmos e muitas vezes também para recrutadores com filtros excessivamente formais.

O que empresas de produto procuram (e como isso colide com os filtros de seleção)

Empresas com verdadeira cultura de produto valorizam:
Colaboração multidisciplinar e systems thinking
Capacidade analítica e orientação a dados
Compreensão profunda do utilizador
Mentalidade de discovery e experimentação
Capacidade de priorizar e comunicar com stakeholders

Estas são competências que se desenvolvem em várias funções digitais. Só que os ATS estão orientados com outro paradigma: um check de palavras-chave e um matching linear entre cargo anterior e cargo desejado.

UX Research, Digital Analytics e Product Thinking: a combinação invisível

A integração entre UX-research, Analytics e decisão é a tríade competitiva no digital, nomeadamente em desenvolvimento e gestão de produtos digitais. Mas poucos recrutadores (e responsáveis de áreas, talvez) reconheçam que esta combinação pode surgir de forma orgânica, “líquida” e não formalizada.

A experiência em UX Research permite entender o comportamento humano, levantar problemas reais e validar soluções com base em evidência. A experiência em Digital Analytics permite medir o impacto de cada decisão e orientar equipas de design e de desenvolvimento. E atualmente, com a IA até pode permitir, dependendo da profundidade de conhecimento do tema de Analytics, conversar e compreender o que fazem os algoritmos ou que algoritmo poderá funcionar. Mais uma vez, esta tríade é fundamental para qualquer produto que queira crescer de forma sustentada.

Quando estas experiências coexistem num mesmo profissional, o valor entregue é substancial. Mas essa intersecção não aparece num campo específico do CV e é raramente indexada por algoritmos de triagem.

O desafio do matching semântico em NLP aplicado a recrutamento

No mundo de NLP, o matching semântico entre dois textos envolve técnicas como word embeddings, transformers e modelos de similaridade. Mas aplicar estas técnicas a CVs exige um entendimento contextual que raramente é alcançado por sistemas ATS.

Um bom modelo de NLP precisaria de:

Captar relações não-lineares entre funções
Incorporar conhecimento do mundo real sobre transferência de competências
Contextualizar a experiência em função do impacto, não apenas do cargo

Na prática, os sistemas operam com vetores simplificados e regras de business logic rígidas. Isso perpetua enviesamentos estruturais: candidatos com títulos não convencionais, formação híbrida ou percursos não lineares são penalizados.

O futuro do recrutamento em produto exige inteligência contextual

Se quisermos construir equipas de produto verdadeiramente eficazes, precisamos de abandonar o paradigma da equivalência semântica e adotar uma leitura mais profunda, baseada em inteligência contextual.

Isso implica:

Reformular os sistemas de ATS para permitir análise narrativa
Treinar recrutadores para reconhecer competências transferíveis
Promover o pensamento de produto também no recrutamento
Incorporar métricas de impacto, e não apenas histórico de cargo

Conclusão

Talento não é uma palavra-chave, é um conjunto de evidências

A experiência profissional é multifacetada. Um CV é uma síntese limitada. E um sistema de análise automatizada, por mais avançado que seja, não pode substituir a capacidade humana de interpretar contexto, transferência e potencial. E porque não dizer mesmo“empatia”. Acredito que muitas das passagens da primeira entrevista para a segunda fase aconteça por empatia entre entrevistador-candidato.

Como profissionais da área digital, devemos ser os primeiros a aplicar o pensamento de produto também ao talento: analisar o problema real (a necessidade da equipa), entender o utilizador (o candidato) e validar soluções com base em dados e experiência, não em atalhos semânticos.

O talento não se define por uma função e atividades. Define-se intrinsecamente pela pessoa pela vontade de crescer, pela motivação do desafio, pela capacidade trabalhar em prol e com os outros, pela capacidade de se entregar, pela vontade de investir em si valor em contexto. E manifesta-se extrinsecamente pelas restantes pessoas a outros níveis que não são o objeto deste artigo.

E isto, muitas vezes, não está contemplado onde o algoritmo procura.

NOTA:

Este artigo não é uma queixa, nem um crítica. É uma reflexão e um convite.

Um convite a todos, todos, todos (profissionais de RH, digital marketers, product managers, managers, c-levels…): olhem para além do cargo atual e anteriores. Não leiam, sim analisei com atenção os verbos, os resultados, os contextos. Perguntem-se e perguntem aos v/ seniores, managers, clientes:

Este perfil já viveu algum ou todos os ciclos de vida de um produto?
Já resolveu problemas com equipas interdisciplinares?
Já usou dados para tomar decisões?
Já ouviu utilizadores, testou hipóteses, documentou processos?
Já esteve em empresas com cultura ou com metodologias agile adotadas em desenvolvimento de produtos?
Já investiu em conhecimento sobre a função a que se candidata?

Se a resposta for “sim”, talvez tenham à vossa frente o próximo talento de produto — mesmo que o CV diga “Digital Marketing” e a “máquina” confirme-o.

by João Carlos Matos

Data Science - Tipos de Análise de Dados

Data Science - Tipos de Análise de Dados

Introdução

Todas as análises depende da pergunta de quem precisa dessa análise, da interpretação dessa necessidade e esclarecimentos da pergunta e noção ou descoberta de bloqueios. E só após isso é que se percebe qual o tipo de análise de dados vai ser necessária fazer e se é possível fazer na sua integridade ou não.

O QUÊ?

Análise Descritiva – Dados para tomar uma decisão, entender uma ação realizada ou antecipar um comportamento.

Esta análise tem como principal objetivo descrever o que aconteceu ou o que está a acontecer num determinado momento. Deve estar sempre limitada ao âmbito do projeto, utilizando técnicas estatísticas para resumir os dados brutos.

Principais características:

Medidas de Tendência Central: média, moda, mediana
Medidas de Dispersão: variância, desvio padrão, quartis
Visualizações: gráficos de colunas, barras, linhas, dispersão, correlação
Identificação de tendências e padrões nos dados
Exploração inicial dos dados, permitindo detectar problemas e entender a distribuição

Exemplo:
Vendas do produto X nos últimos 3 anos.
Objetivo: entender o estado da métrica e o comportamento dos atores que influenciam essa métrica.

A análise pode ser encerrada aqui, ou pode seguir para uma análise mais aprofundada – análise de diagnóstico.

PORQUÊ

Análise Diagnóstica – Dados para entender as causas por trás do que foi identificado na análise descritiva.

Esta análise tenta responder ao “porquê” de um fenómeno acontecer, identificando relações e padrões que ajudam a explicar as variações observadas.

Principais características:

Investigativa por natureza
Baseada em hipóteses, priorizando aquelas que devem ser testadas primeiro
Utiliza dados históricos para compreender comportamentos
Multivariada, já que normalmente não há uma única causa para um fenómeno
Requer interpretação cuidadosa e um conhecimento mais avançado de estatística
Evolui naturalmente a partir da Análise Descritiva
Técnicas utilizadas: regressão, correlação, análise de clusters (clusterização), entre outras

Exemplo:
O número de conversões diminuiu no último mês.
Objetivo: identificar as causas possíveis para essa diminuição, como mudanças no comportamento do consumidor, campanhas de marketing ou fatores externos.

A análise pode ser encerrada aqui, ou seguir para prever o que poderá acontecer no futuro.

QUANDO?

Análise Preditiva – Esta análise procura antecipar eventos futuros com base em dados históricos e técnicas de modelagem estatística.

Principais características:

Criação de modelos para prever comportamentos futuros
Baseada em dados históricos, com ajustes e simulações
Utiliza análises multivariadas
Insere-se no campo da Ciência de Dados
Emprega Machine Learning e modelos estatísticos
Reduz a dependência de suposições baseadas apenas em experiência
Fornece orientações às equipas de negócio sobre o que pode vir a acontecer

Exemplo:
Com base nos dados dos últimos 3 anos, é possível prever as vendas do produto X para o próximo trimestre, considerando fatores como sazonalidade, comportamento de clientes e campanhas previstas.

A análise pode ser encerrada aqui, ou pode avançar para uma análise prescritiva, indicando o que deve ser feito com base nas previsões.

COMO?

Análise Preescritiva – Dados para recomendar ações futuras.

É o nível mais avançado de análise, oferecendo recomendações específicas sobre o que fazer após as análises anteriores.

Principais características:

Suporte à tomada de decisão baseada em dados (data-driven)
Redução de riscos nas decisões
Baseia-se em simulação de múltiplos cenários
Considera diferentes variáveis e restrições
Pode utilizar técnicas de otimização, modelagem matemática e sistemas de apoio à decisão

Exemplo:
Com base na previsão de queda nas vendas do produto X, a análise preescritiva pode recomendar o melhor mix de canais de marketing, distribuição de orçamento e ações promocionais para mitigar essa tendência.

Conclusão

As diferentes análises – Descritiva, Diagnóstica, Preditiva e Preescritiva – formam um ciclo contínuo de melhoria e aprendizado a partir dos dados.
Cada uma tem seu momento e valor dentro de uma estratégia de análise mais ampla e, quando combinadas, ajudam as organizações a compreender melhor o presente, explicar o passado e moldar o futuro com decisões mais informadas.

by João Carlos Matos

Data Science for Business Strategy

Introdução

O objetivo deste artigo e dos possíveis artigos seguintes é o de acompanhar os estudos que estou a fazer na Pós-Graduação em Data Science for Business Strategy da Universidade Nova – Faculdade de Ciência e Tecnologia.

É também uma forma de estudar a tentar assimilar melhor os conteúdos ministrados.

O que é Data Science

Data Science, em português, é a Ciência de Dados. OK. Mas o que significa Ciência de Dados? Se formos traduzir DataScience é a Ciência de trabalhar os dados.

Vamos analisar uma definição mais conceptual de Data Science.

Data Science é uma área interdisciplinar que utiliza métodos científicos, processos, sistemas, ferramentas e algoritmos para extrair insights e inteligência dos dados, com o objetivo de descobrir padrões, gerar novos insights para informar o processo de decisão.

Conceitos importantes a reter:

Interdisciplinaridade – É uma disciplina que envolve 3 disciplinas: estatística, ciências da computação, conhecimento de negócio
Método Científicos, Processos, Algoritmos e Sistemas – Métodos científicos porque um projeto de Data Science envolve a constatação de um problema, uma declaração de hipóteses e a execução de testes para não rejeitar ou rejeitar a hipótese inicial.
Processos – Envolve seguir um procedimento, ou seja e por exemplo…não se deve começar a trabalhar os dados sem antes termos feito: 1) o entendimento dos dados, 2) o tratamento dos dados e 3) a análise exploratória dos mesmos.
Algoritmos – Os algoritmos nada mais são do que um conjunto de procedimentos que levam à criação de um processo. Quando, por exemplo somamos 1 + 1 isso é o algoritmo da soma. Ou quando o fazemos tendo a expressão 1 + 1 * 3.
Ferramentas – As ferramentas, nomeadamente as tecnológicas auxiliam-nos na execução das disciplinas que compõe a disciplina maior de Data Science: Matemática e Estatística, Ciências da Computação e (Conhecimento do Negócio.

Depois desta definição mais teórica, a minha definição de Data Science é simples: Em termos de conteúdo eu diria que Data Science é o estudo dos dados de modo a conseguir responder a perguntas sobre um ou mais problemas que têm o seu enquadramento no contexto atual e que, concumitantemente ou não, nos permite também descobrir e aturar no naquilo que poderá ser o contexto futuro. Relativamente à forma eu diria, que todo o conteúdo da definição pode e deve ser feito através de pergunta críticas e curiosidade, análises quantitativas e qualitativas, visualizações de dados e comunicação.

As Disciplinas que Compõe Data Science

Então, Data Science envolve três disciplinas: Matemática/Estatística, Ciências da Computação e Conhecimento de Negócios. E estas 3 disciplinas embora possam sejam áreas distintas e devem sê-lo também a nível empresarial e de constituição de equipas e departamentos de Data Science, elas intersectam-se.

Os Papéis em Data Science

A disciplina de Data Science é colaborativa, como tantas outras disciplinas técnicas (e Data Science não é só parte técnica) como Digital Marketing, Product Management, UX-Research. E por serem colaboravas as Empresas devem ter papéis e responsabilidades bem definidas para o efeito…mas sobre este tema talvez faça um publicação só sobre isso – “A Falta de Conhecimento Real sobre o que as Empresas necessitam”. Normalmente o que as Empresas Portuguesas querem para todas as áreas são “Full-Stack Unicorns”.

Portanto, num mundo real e ideal, ou seja, no mundo onde as Empresas querem a serio criar e desenvolver equipas dentro da áreas de Dados e Data Science motivada, interdisciplinar e que cresça, terá na sua génese as funções e responsabilidades seguintes:

NÃO EXAUSTIVO

Data Engineers (Database Administradores de Bases de Dados e Desenvolvedores de Software) – Têm o seu foco no back-end: desenho e concepção das estrutura dos servidores, desenho, arquitetura e administração das bases de dados, desenvolvimento particular de software específico, servidores e nas bases de dados. É quem fornece a base para que todo o restante trabalho possa ser desenvolvido.
Big Data Specialists (Machine Learning Engineers, Computer Science Engineers) – Têm o seu foco no desenvolvimento de algoritmos de Machine Learning por forma a que se consiga processar e analisar grandes quantidades de dados, e responsáveis também, se necessário, pela criação de “Produtos de Dados”. Um produto de Dados pode ser um dashboard, mas a este nível estamos a falar mais de produtos de dados que ajudam as pessoas por exemplo qual o melhor produto que ela pode comprar se já comprou os produtos a, b,c,d.
Database Administradores de Bases de Dados e Desenvolvedores de Software) – Têm o seu foco no back-end: desenho e concepção das estrutura dos servidores, desenho, arquitetura e administração das bases de dados, desenvolvimento particular de software específico, servidores e nas bases de dados.
Data Analysts – Têm o seu foco no dia a dia do negócio e na análise dos respectivos dados. Podem ser por exemplo análises de dados web, análises de dados de produto, análises de dados de RH e por ai fora. Importante ter conhecimento de SQL, consoante o volume de dados
Business Analysts – Têm o seu foco nas perguntas importantes para o negócio (tal como os Data Analysts) e gerem ou podem gerir projetos relacionados com dados.

Este artigo pode vir a ser adaptado e complementado ao longo de 2025

by João Carlos Matos

Como Fazer e Interpretar uma Análise de Cohort: Exemplo Prático

O exemplo de construção e análise de Cohort apresentado no artigo faz parte do portfólio de trabalhos que fiz durante a formação em Análise de Dados da Comunidade DS.

O que é a Análise Cohort

A Análise de Cohort é uma técnica de analítica cujo objetivo é caracterizar pessoas ou eventos que tenham em comum uma determinada característica durante um determinado período de tempo, e com isso observar o seu comportamento ao longo desse período temporal.

Dando um exemplo simples do nosso quotidiano e depois passando para o ambiente online de desenvolvimento de produtos digitais.

Exemplo offline: Imaginando que vais almoçar fora com os teus pais, mais com os teus 2 irmãos e com os teus avós ao restaurante “Almoça Aqui”. E imagina que esse almoço foi o almoço do primeiro dia do ano – 1 Janeiro de 2025.

Ou seja, e considerando apenas a tua família, o restaurante “Almoça Aqui” recebeu no dia 1 Janeiro de 2025, 7 pessoas, nesse dia, mês e ano. E tu e a tua família, partilham uma característica em comum: foram almoçar a esse restaurante simultaneamente nesse dia.

Soubeste que os teus pais foram jantar ao restaurante no dia seguinte com mais um casal de amigos e o seu filho de 7 anos (considera novamente apenas os teus pais e o casal de amigos como únicos clientes nesse restaurante ao jantar).

E tu foste no dia 3 de janeiro, com a tua namorada e fechaste o restaurante só para vocês e fizeste-lhe uma surpresa :).
Soubeste mais tarde pelos teus pais que o casal de amigos dos teus pais foi ao restaurante no mesmo dia que foste com a tua namorada, mas almoçar.

Ou seja e em termos de Análise de Cohort, teríamos que se representa na tabela abaixo:

Primeira visita / Atividade	Dia 1.1.25	Dia 2.1.25	Dia 3.1.25
Dia 1.1.25	7	2	1
Dia 2.1.25	–	3	2
Dia 3.1.25	–	–	1

Exemplo de E-commerce: O exemplo de e-commerce segue exatamente, mesma lógica, sendo que desta vez estamos a analisar meses.

First-purchase / Atividade	Jan 25	Fev 25	Mar 25
Jan 2025	1000	700	300
Fev 2025	–	600	400
Mar 2025	–	–	500

Notas Importantes

A característica comum às pessoas, não precisa de ser obrigatoriamente a primeira visita, ou a primeira compra. Pode ser, por exemplo e para o caso do restaurante o “prato” escolhido. E para o caso de e-commerce a categoria de produto comprado “sapatos”. A característica escolhida para a análise depende da própria análise que se pretende fazer.
Mais à frente veremos melhor a interpretação dos dados da tabela de Análise de Cohort. Aqui quero apenas deixar a nota que, por exemplo para o dia 2 de Janeiro de 2025 (que será a data de cohort) a célula 1 de Janeiro de 2025, porque esse cohort/safra não existia (logicamente) nesse dia. O mesmo raciocínio aplica-se para os meses na loja online

Para que serve a Análise Cohort

O objetivo principal de uma Análise Cohort é para medir o comportamento das pessoas na utilização de um determinado produto ou serviço. Agora esse comportamento traduz-se nalguma métrica que pode variar, consoante as características dos grupo que foi selecionada:

Retenção
Life-Time Value
Melhores Produtos

Que Dimensões e Métricas Precisamos para fazer uma Análise Cohort

As dimensões estarão relacionadas com o tempo ou inteligência de tempo. No exemplo do Restaurante estaríamos a falar da dimensão de tempo em dias. Já no caso do E-commerce a dimensão de inteligência de tempo seria o mês.

Outra dimensão que vamos precisar e que, de certa forma está relacionada com o tempo é, no exemplo do restaurante da data da “primeira visita”. E no caso do E-commerca da data da “primeira compra”.

As métricas que vamos precisar seria o Nº de primeiras visita ao restaurante e para o E-commerce, o Nº primeiras Compras.

No exemplo prático, temos de pensar no binómio “Facto-Dimensão”.

Exemplo de uma Análise Cohort feita em Excel

Enquadramento rápido:

Um Grupo de Beleza com várias lojas físicas espalhadas por Portugal, com o objetivo fazer acreditar no poder transformador da beleza e comercializar diferentes categorias de produtos de beleza.

Recentemente, foi identificado um desafio crescente: a retenção de clientes. A empresa percebeu que, embora as vendas continuem ocorrendo, a frequência de compras de clientes recorrentes tem diminuído.

O objetivo é criar indicadores que mostrem como os clientes interagem com o Grupo de Beleza ao longo de um determinado período de tempo.

Procedimento

Para não tornar o artigo longo e exaustivo, admite que todos os dados que seriam precisos estão na base de dados em Excel denominada de Customers. E nela temos as seguintes dimensões: Customer_Id, Order_Id, Order_Date.

1 – Que dimensões, métricas e factos vamos precisar

Facto:

- Customer_ID

Dimensões:

- Order_Date (Recorrência de compras) e precisamos de fazer a análise mensal

Dimensões de tempo derivadas da Order_Date:

- Order_Date (da primeira compra) e precisamos de fazer a análise mensal

Customer_ID	Order_Date (first-purchase)	Order_date (Recorrência)
AA123	1.1.23	1.1.23
BB321	1.2.23	1.2.23
AA123	1.1.23	2.3.23
BB321	1.2.23	1.2.24
AC123	2.2.23	2.2.23
AC123	2.2.23	5.5.23
CA321	4.8.23	4.4.24
CD123	4.6.24	4.6.24
CD123	4.6.24	1.3.25
EF123	8.7.24	8.8.24

2 – Como vamos construir a Análise Cohort em Excel

2.1 Criar uma tabela com 3 colunas:

Coluna 1 – Customer_ID

- Não precisamos de fazer nenhum cálculo

Coluna 2 – Order_Date (data da primeira compra, em mês)

- Utilizando duas fórmulas:
  - Formatar os valores de “Date” da coluna Order_Date (first_purchase) em formato custom do tipo “MM-YYYY”
  - Utilizar a fórmula: =MINIFS[min_range;criteria_range1;criteria]

Coluna 3 – Order_Date (recorrência de compras)

- Utilizando três fórmulas:
  - Formatar os valores de “Date” da coluna Order_Date (Recorrência) em formato custom do tipo “MM-YYYY”
  - Utilizar, por exemplo a fórmula =DATEDIF[initial_date;final_date;format], neste caso meses

Ou seja, vamos ter uma tabela similar a esta:

Customer_ID	Order_Date (first-purchase)	Order_date (Recorrência)	Recorrência calculada (meses)
AA123	1.23	1.23	0
BB321	2.23	2.23	0
AA123	1.23	3.23	2
BB321	2.23	2.24	12
AC123	2.23	2.23	0
AC123	2.23	5.23	3
CA321	8.23	4.24	8
CD123	6.24	6.24	0
CD123	6.24	3.25	9
EF123	7.24	8.24	1

4 – A Tabela de Cohort no Excel – Exemplificativa

A tabela de cohort resulta de uma pivot table em que utilizamos os facto-dimensões trabalhadas anteriormente. Ou seja, o facto será o “customer_Id” colocado em valores. E as dimensões serão em colunas e linhas respetivamente,“order_date” e “first_purchase”. Para termos os valores em %, temos de dividir o número de clientes em cada um dos meses pelo total de clientes no mês em que aconteceu a Order_Date – first_purchase.

cohort-exemplo-pratico

5 – Interpretação dos Resultados

Em linha:

Conseguimos analisar a retenção dos clientes ao longo dos meses que estamos a analisar. Por exemplo, analisando a primeira linha, percebemos que dos clientes que fizeram a primeira compra no mês 0, só cerca de 10% voltaram a comprar no mês seguinte e nenhum comprou no 3º mês.

Podes analisar a média de cohorts, tendo em atenção o período de maturação do cohort. Por exemplo, considerando um mês

Em coluna:

Conseguimos analisar a retenção de novos clientes, e em relação aos níveis de retenção do mesmo mês. Considerando o exemplo de cima, verificamos que na 2ª linha e no mês 1, ao invés dos 9,9% de retenção, foi conseguida uma retenção de cerca de 17% e no mês seguinte de 8%.

O melhor cohort foi o mês de Novembro, analisando a retenção para um mês, e teve cerca de 24% de retenção de clientes.

Este tipo de análise, certamente que poderá ser feito recorrendo a outras ferramentas, como SQL, Python ou até mesmo em ferramentas já “prontas” como o GA4 que nos proporciona uma análise de cohort para o número de visitas. Tudo depende do conhecimento do problema e do conhecimento e da disponibilidade das ferramentas disponíveis.

by João Carlos Matos

Os Diferentes tipos de Valores do Produto associados aos seus Riscos de Desenvolvimento

Acredito que os quatro tipos de valor do produto – valor financeiro, valor social, valor psicológico e valor funcional – podem ser associados aos cinco riscos no desenvolvimento de produtos, definidos por Marty Cagan no seu livro Inspired e que estou a ler.

Ora vejamos:

1. Risco de Usabilidade e Valor Psicológico

Valor Psicológico – Este valor está relacionado mais ao campo interno e subjetivo da satisfação e do significado que o produto nos pode proporcionar. Produtos que oferecem valor psicológico vão além do seu valor funcional, do valor financeiro.

Na minha opinião este Valor está relacionado com o Risco de Valor de Negócio e/ou com o Risco Financeiro.

Quando se define uma estratégia financeira para o preço deve-se ter o valor psicológico em conta e o mesmo deve ser comunicado em ações de product marketing e/ou product growth.

#MVP #UXResearch #ProductManagement

2. Risco de Exequibilidade Técnica e Valor Funcional

Valor Funcional – Este valor do produto deve questionar ou melhor, responder à questão: “O produto satisfaz uma necessidade específica ou resolve um problema particular?”.

É o valor mais tangível do produto, fundamentado na utilidade e no pragmatismo. Compreender este valor do produto é compreender o seu propósito — o resultado concreto e prático que o produto oferece aos utilizadores.

O Valor Funcional, na minha opinião, é afetado diretamente pelo Risco de Viabilidade Técnica (Execução) já que se não houver capacidade interna para desenvolver o produto ou partes do produto, tal vai comprometer as expectativas já possivelmente cridas.

O risco de viabilidade técnica surge, ou melhor analisa-se e mitiga-se trabalhando em conjunto com as equipas de engenheiros e desenvolvimento. Ou seja, vamos avaliar se a solução proposta é exequível.

#POC #UXResearch #SolutionArchitects #DevelopmentEngineers #ProductManagement

3. Risco de Viabilidade de Negócio e Valor Financeiro

Valor Financeiro – É o valor que equilibra o custo e o benefício (valor psicológico), do produto. É o preço de venda com que o produto sai para o mercado e deve refletir não apenas os recursos materiais investidos, mas também o valor intrínseco que o produto possui. É uma medida de justiça, de quanto pedimos em troca do que entregamos e se essa troca parece justa e razoável.

O Risco de Viabilidade do Negócio está relacionado com o Valor Financeiro do Produto, porque o produto tem de ser rentável e só o é se for “saudavelmente financeiro” para a Empresa. Se o valor financeiro (ou melhor, o valor monetário) percebido pelos utilizadores não se traduzir num Modelo de Negócio viável, este risco vai aumentar.

4. Risco de Valor que se relaciona com todos os Tipos de Valor do Produto

Valor Financeiro – Se o produto não oferece benefícios financeiros claros para as pessoas e, simultaneamente, se não estiver assente no Modelo de Negócio e de pricing correto, os utilizadores poderão não comprá-lo, aumentando o risco de valor.

Valor Psicológico – Sem benefícios emocionais ou mentais (como tranquilidade ou satisfação), o produto pode não ser percebido como valioso em termos psicológicos.

Valor Funcional – Se o produto não resolve um problema importante ou não cumpre a sua função, o risco de valor funcional aumenta significativamente.

E o Risco Legal…

Por último, existe um risco que o Marty Cagan não fala, mas eu vou falar que é o risco legal. Um produto que não cumpra as requisitos legais, mesmo que tal seja difícil de compreender, de implementar ou até mesmo interfira na forma como as equipas trabalham, é um produto que mais tarde ou mais cedo vai estar condenado.

by João Carlos Matos

Tudo (ou quase tudo) sobre Product Market Fit

Introdução

Começo por citar Paul Graham: “O erro mais comum de startups e das empresas em geral é resolver um problema que ninguém tem.”

E porquê? Por várias razões, todas elas relacionadas com falta de estratégia e entendimento das necessidade, motivações, frustrações dos clientes.

Product Market Fit

O Product Market Fit é o estágio em que o produto já colmata as necessidades reais (ou latentes) dos clientes, atraindo aqueles com disposição para fornecer algum tipo de valor, essencialmente monetário. Os clientes demonstram isso de forma consistente, o que sinaliza o potencial efeito de escala do produto. De forma simples, o estágio de Product Market Fit significa perceber se o Produto tem/terá mercado ou não.

Portanto, o Product Market Fit é uma interseção entre o Valor para a Empresa/Clientes, Necessidades dos Clientes e Exequibilidade Técnica.

Economic Market Fit

Já o Economic Market Fit é diferente. Significa perceber se o Produto retorna valor económico para a Empresa no decorrer do tempo. E existem 2 estratégias para o atingir, manter o Economic Market Fit.

- Estratégias de Preço – As estratégias de preço são, essencialmente, duas:
  - Penetração – Em que a Empresa assume um preço baixo para o produto para penetrar no mercado
  - Desnatação – Em que a Empresa assume um preço alto para o seu produto ir “desnatando” à medida que tenciona ou vai entrando em novos mercados.
- Estratégias de Diferenciação – Em que a Empresa se foca em tornar o produto único em comparação com o dos seus concorrentes, de forma que os consumidores estejam dispostos a pagar um preço premium por ele.

Independentemente da estratégia escolhida para o produto, é preciso conseguir responder às perguntas seguintes:

As operações funcionam de forma eficiente e eficaz e são capazes de geram os proveitos suficientes para cobrir os custos que existem atualmente?
E vamos conseguir manter este nível de performance nas operações se o volume de clientes aumentar em 20%, 40%, 60%…?
A Empresa vai conseguir manter o preço do seu produto competitivo de forma consistente – no caso da estratégia escolhida for a de preço – no caso da concorrência aumentar?

Ou seja, Pode haver Market Fit e não haver, seja no curto no médio ou no longo prazo, Economic Fit

Matematicamente, o Economic Fit ocorre quando o CAC < LTV do cliente. Se CAC=LTV podemos dizer que a Empresa está a atingir o break-even-point com esse Produto.

Problem Solution Fit

O Problem Solution Fit é o estágio em que o produto se encontra fornecendo uma solução que resolve um problema específico do cliente ou de um segmento de clientes.

Ou seja, as Empresas cujos Produtos atingem o estágio de Product Market Fit, atingirão também o estágio de Problem Solution Fit. Mas o inverso não é verdadeiro, até porque a Solution Fit pode não ser 100% viável tecnicamente ou financeiramente.

Business Model Canvas Fit e Proposta de Valor

O Business Model Canvas é uma ferramenta estratégica que nos auxilia a mapear todos os intervenientes de um Negócio/Produto.

O Business Model Canvas, tal como por exemplo o Service Blueprint, mas para outros efeitos, é composto por duas partes: a Área que está mais visível para os clientes e a Área que está mais visível para a Empresa.

Área Mais Visível para os clientes é composta por:

- Segmentos de Utilizadores/Personas – Diferentes grupos de pessoas ou organizações que as Empresas têm como alvo.
- Canais – Detalha como a Empresa comunica com os seus potenciais clientes a sua proposta de valor.
- Relacionamento com os Clientes – Especifica o tipo de relacionamento que a Empresa estabelece com cada segmento de cliente, que pode ser pessoal, automatizado, entre outros. Este relacionamento visa a aquisição e retenção de clientes.

Área Mais Visível para a Empresa é composta por:

- Parceiros Chave – Inclui fornecedores, parceiros estratégicos e outras entidades com as quais as Empresas colaboram ou colaborarão para otimizar o modelo de negócio e reduzir riscos.
- Recursos Necessários para o Negócio – Define os ativos mais importantes que a Empresa precisa para operacionalizar o negócio, como recursos físicos, humanos, intelectuais (como patentes) e financeiros.
- Atividades Necessárias para o Negócio – Engloba as atividades essenciais que as Empresas precisam realizar para fornecer a sua proposta de valor, alcançar mercados, manter os relacionamentos com os clientes e gerar receita. Isso pode incluir produção, desenvolvimento, marketing e distribuição.
- Fluxo de Receitas – Descreve as fontes de receita das Empresas. Pode incluir vendas per si, subscrições, licenças, entre outros.
- Estrutura de Custos – Detalha os custos necessários para operacionalizar o modelo de negócio. Deve incluir os custos fixos e variáveis, como despesas com recursos humanos, custos com produção.

A “cola” que une estas duas áreas é a Proposta de Valor.

Proposta de Valor

A Proposta de Valor reflete a promessa de benefício que um Produto oferece aos seus clientes, destacando as razões pelas quais o mesmo se diferencia (parcial ou totalmente) dos produtos existentes. De forma simples, é o motivo pelo qual os clientes escolhem ou devem escolher um determinando produto em detrimento de outro(s) concorrente(s).

A proposta de valor responde claramente às perguntas:

- Qual problema específico o produto resolve? – Problem Solution Fit
- Quais os benefícios e/ou resultados os utilizadores obtêm ao utilizá-lo? – Product Market Fit
- O que diferencia o produto de outros concorrentes? – Product Market Fit

Componentes de uma Proposta de Valor:

Problema a ser resolvido – Define o problema ou necessidade que o produto resolve. Deve ter em consideração uma dor ou necessidade clara dos clientes.

Exemplo: “Facilitamos a comunicação rápida e eficiente entre equipas remotas.”

Benefícios Principais – Destaca os resultados positivos que o cliente obterá. Isso pode incluir economias de tempo, melhorias na eficiência, redução de custos ou aumento de conveniência.

Exemplo: “O nosso software reduz o tempo gasto em tarefas manuais em 50%.”

Diferenciação – Explica por que o produto é único ou melhor em relação à concorrência. Pode estar relacionado com a inovação, com a qualidade, com a facilidade de utilização, ou com uma combinação desses fatores.

Exemplo: “Somos a única plataforma que integra todas as ferramentas de produtividade num único interface simples de utilizar.”

Como Definir uma Boa Proposta de Valor

Uma boa proposta de valor está alinhada com um modelo de negócio sustentável, garantindo que o produto ou serviço oferece uma solução que não só atende às necessidades dos clientes, mas também gera receita suficiente para sustentar o crescimento e o negócio em termos operacionais. Os Product Managers, em conjunto com o CEO, devem garantir que a proposta de valor não só resolve um problema real, mas também que está inserida numa estrutura financeira viável.

Exemplo: O modelo de assinaturas do Spotify oferece valor para o cliente final (acesso ilimitado a música) e para o Spotify (uma receita contínua obtida através de uma subscrição para serviço premium).

Em mercados competitivos, a proposta de valor deve se concentrar no que realmente importa para os clientes. Deve resolver os problemas mais prementes ou ajudando-o a alcançar os seus objetivos. Foco relevância significa entender o que os clientes valorizam e o que os motiva/frustra, em vez de tentar resolver todos os problemas. A proposta deve ser percebida de forma clara, transparente para o cliente.

Exemplo: O Slack foca-se na eficiência da comunicação para as diferentes equipas empresariais, tornando-se a plataforma ideal para aumentar a produtividade em ambientes de trabalho remoto ou híbrido.

Uma proposta de valor eficaz seleciona apenas algumas tarefas essenciais ou dores dos clientes, focando nas que eles estão dispostos a pagar para resolver. Isso ajuda a manter o produto simples, mas poderoso, focando nas áreas que terão o maior impacto para os clientes.

Exemplo: A Dropbox oferece espaço de armazenagem na Cloud com sincronização automática e backup de arquivos, resolvendo o problema específico de armazenagem e segurança dos dados – algo que os clientes valorizam e que estão dispostos a pagar.

Para criar uma proposta de valor que realmente se identifique com os clientes. Mais uma vez, é fundamental compreender as motivações, frustrações e expectativas deles em relação ao produto. Isso permite que os product managers consigam criar uma oferta de produto/serviços que vá ao encontro dos desejos/necessidades emocionais e práticas dos clientes.

Exemplo: O Airbnb identificou que os viajantes procuravam experiências mais autênticas e acessíveis, frustrados com hotéis caros e impessoais. A sua proposta de valor foca-se em fornecer estadias únicas e personalizadas, respondendo a essas expectativas.

É importante entender como os clientes definem sucesso ao usar um produto. Isso pode ser medido em termos de economia de tempo, simplificação de tarefas, ou melhoria na performance. A proposta de valor deve refletir essa perceção de sucesso para criar uma ligação mais forte e autêntica com os clientes.

Exemplo: O sucesso para os clientes do Trello é medido pela organização e produtividade alcançadas pelos seus projetos.

Uma proposta de valor sólida deve destacar a diferenciação do produto, ou seja, aquilo que o torna único ou superior em relação às empresas concorrentes. Essa diferenciação competitiva é o que convencerá os clientes de que o produto tem mais valor ou resolve (melhor) o problema e de forma mais eficaz do que os outros existentes no mercado.

Exemplo: A Tesla diferencia-se no mercado de automóveis não só por fabricar veículos elétricos, mas também pela inovação em tecnologia de baterias e condução autónoma e por todos os produtos, tal como a Apple, fazerem parte de um ecossistema elétrico.

Uma proposta de valor ideal é aquela que é difícil de ser copiada a 100% pelos concorrentes. Seja por meio de tecnologias patenteadas, design exclusivo, ou um forte brand awareness. A dificuldade em replicar o produto, garante que o mesmo mantenha a vantagem competitiva ao longo do tempo ou por mais tempo.

Exemplo: A Apple tem uma proposta de valor difícil difícil de replicar, pois a mesma combina tecnologia high-tech, design icónico e centrado nas pessoas e um ecossistema integrado de hardware e software.

Podem saberes mais sobre Produtos Digitais e Gestão dos mesmos, podes consultar os artigos seguintes::

Fundamentos de Product Management – Aspetos Relacionados com o Produto | João Carlos Matos (joaomatosdigital.pt)

Fundamentos de Product Management – Aspetos relativos ao Product Manager | João Carlos Matos (joaomatosdigital.pt)

by João Carlos Matos

João Carlos Matos

Business

Introdução

A nova era da velocidade, mas potencial perda de profundidade

O novo modelo de análise de CVs

Das heurísticas humanas a inferências automáticas

Dada Science por detrás dos ATS

Nuances como contexto e transferência de competências

A transferência de competências: quando o cargo esconde a função real

Look behind the Obvious

Caso prático: 12 anos de experiência digital and counting, vistos pela lente errada

O que empresas de produto procuram (e como isso colide com os filtros de seleção)

UX Research, Digital Analytics e Product Thinking: a combinação invisível

O desafio do matching semântico em NLP aplicado a recrutamento

O futuro do recrutamento em produto exige inteligência contextual

Conclusão

Talento não é uma palavra-chave, é um conjunto de evidências

NOTA:

Introdução

Conclusão

Introdução

O que é Data Science

As Disciplinas que Compõe Data Science

Os Papéis em Data Science

Introdução

Product Market Fit

Economic Market Fit

Problem Solution Fit

Business Model Canvas Fit e Proposta de Valor

Proposta de Valor

Componentes de uma Proposta de Valor:

Como Definir uma Boa Proposta de Valor

Sobre mim

Explorar

Conversar