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.
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.
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
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
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 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
Da Gestão da Qualidade ao Product Management: Uma Jornada Através de Analytics, UX Research e Implementação Técnica
Introdução
Como processo, dados e utilizadores convergem numa abordagem holística ao product management
Quando as pessoas ouvem o termos "Marketing Digital", associam-no, frequentemente, em conteúdos para websites, ou para as redes sociais e algumas vezes fazem a associação a campanhas ppc. Mas “Marketing Digital”, e após 12+ anos de experiência na área digital ou na área tecnológica, como preferirem, concluo algumas coisas interessantes (não conclui hoje ao escrever este artigo):
-
- O marketing digital pode ser mais ou menos técnico. E atualmente tenderá a ser cada vez mais técnico, não só por causa dos avanços da tecnologia e da Inteligência Artificial - IA, mas também pelas várias Leis, Regulamentos e Diretivas sobre temas como Privacidade de Dados ou sobre IA
- Marketing Digital pode ser muito mais do que Marketing Digital, tal como menciona o Simo Ahava no Capítulo 1, ponto 2 do seu Technical Marketing Handbook
- Sempre trabalhei nas áreas mais técnicas e sempre desenvolvi as minhas competências tendo em conta isso
- Quem trabalha em áreas técnicas do Digital e dentro de equipas ou dando suporte a equipas que funcionam com metodologias Agile, está a trabalhar e desenvolver produto
- Aliás, o Scrum Guide revisto este ano, com o Scrum Guide Extension Pack, uma das coisas que reforça é o ponto 4. Se por um lado existe um novo papel denominado de “supporters”, fala-se em entregar não só o output (definition-of-done), mas também o outcome - que valor traz para a Empresa aquilo que foi criado
E nisto resultam três coisas:
-
- As competências centrais que fazem um bom profissional de marketing digital são extraordinariamente semelhantes aquelas que fazem um excelente product manager e por isso…
- Os profissionais com o meu perfil, estão suficientemente preparados para assumir uma função como Product Owner ou como Product Manager, por exemplo.
- Ainda que ou até porque, o título é só um título, se não o virmos contextualizado com: cultura da empresa, organização da empresa, visão da empresa, objetivos da empresa, políticas da empresa, equipas a que vais pertencer, pessoas com quem vais colaborar, metodologias utilizadas (não apregoadas), entre uma série de outros temas que fazem uma organização.
Explicando Melhor a minha Jornada Profissional
Podem sempre consultar o meu Curriculum, mas permitam-me explicar, tentando ser breve, porque é que a minha jornada dentro do Marketing Digital e em Customer Experience, para funções de Produto não é uma mudança de carreira—é uma evolução natural.
Marketing Digital
Como explicado acima, Marketing Digital é muito mais do que conteúdos, redes sociais e clicar em botões para colocar online campanhas ppc. Marketing Digital como eu o vejo, como eu o faço é sobre:
-
- Empatia, ao termos de compreender o comportamento do utilizador através das suas customer journeys, users flows, análise de dados qualitativos e quantitativos
- Identificar pain points nessas mesmas customer journeys
- Testar hipóteses através de Testes A/B
- Construir frameworks de medição para acompanhar o sucesso
- Colaborar com equipas técnicas para implementar soluções
- Comunicar insights para stakeholders em toda a organização
Hum….Aposto que vos soa familiar? Pois é, estas são também as competências que product managers, product analysts ou utilizam diariamente.
A Minha Experiência Real em Produto
Embora os meus títulos pudessem dizer "Marketing Digital" ou "UX Research", o meu trabalho real tem sido profundamente focado em produto:
Por ordem decrescente de funções:
Engenharia e Gestão da Qualidade
Os 6 anos que trabalhei na área da engenharia e Gestão da Qualidade ensinaram-me a pensar em processos, compliance e melhoria contínua - competências que se revelaram fundamentais quando finalmente comecei a trabalhar na minha área de formação - Marketing de Produto, esta experiência se tornou valiosa.
Nos CTT, liderei a a construção da framework e a implementação de um projeto de Digital analytics, com base na ferramenta Google Analytics 4 - GA4 em todos os ativos digitais da Empresa (Website + aplicações móveis). Isto não foi apenas um projeto de marketing—foi uma iniciativa de produto que:
Exigiu alinhamento de vários stakeholders de várias equipas (entre equipas de IT, Marketing, UX e Jurídico ) e até de parceiros externos que nos auxiliaram nesse projeto
Envolveu product discovery para compreender necessidades dos utilizadores internos das diferentes equipas, por exemplo em requisitos de negócio e em termos de eventos e de métricas que deveriam ser implementados.
Necessitou coordenação de implementação técnica com equipas de engenharia
Criou frameworks de medição que agora impulsionam decisões de produto em toda a organização
Na EY, conduzi estudos de user research em +10 projetos de transformação digital, traduzindo insights de clientes em requisitos de produto e prioridades de design e de desenvolvimento.
A Gestão de Campanhas PPC - Pensar “Produto” ou parte Dele
Durante alguns anos, geri campanhas com orçamentos significativos, mas o que realmente estava a fazer era **product management em micro-escala**.
Cada campanha PPC é, essencialmente, um produto com:
-
- Estudo de Hipóteses a testar (diferentes mensagens, audiences, criativos)
- Estabelecimento de Métricas de sucesso claras (CPC, CPL, ROAS, conversion rate)
- Iteração constante baseada em performance data
Na StepValue, e depois na EY, geri campanhas que resultaram num **aumento de 30% em hot leads**, mas mais importante que o resultado foi a metodologia que elas envolvem, bem como a necessidade de interação com várias áreas e stakeholders.
Esta experiência traduziu-se diretamente em **competências de product analytics**:
-
- Análise de Funis - compreender onde os utilizadores abandonam
- Análise de Cohort - agrupar utilizadores por comportamento
- Attribution modeling - entender o impacto de diferentes touchpoints
- Previsão de Performance - prever impacto de mudanças, por exemplo no budget
O pensamento PPC também é, em parte ou na sua totalidade, Product Thinking: optimizar continuamente a experience do utilizador para maximizar conversões, sempre com objetivo em números.
O resultado disto tudo? Tenho estado a fazer trabalho de produto sem ter o título.
A Sobreposição de Competências: Duas Matrizes Simples
Deixem-me decompor como o meu background em Marketing Digital se traduz em funções de produto, através das “Competências Transferíveis”:
COMPETÊNCIA CENTRAL - PRODUCT MANAGER
|
Competência Central |
Nível de Experiência |
Formação |
Como Apliquei |
|
User Research |
4/5 |
Sim |
User interviews, análise de findings e insights, Customer Journey mapping, User flows, Information Architecture, escrita de artigos sobre UX |
|
Decisões Data-Drivem |
4/5 |
Sim |
Otimização de campanhas, Reporting de resultados campanhas PPC, Implementação de GA4, dashboard, escrita de artigos sobre analytics |
|
Gestão de stakeholders |
3/5 |
Não |
Coordenação cross-funcional, apresentações executivas, papel de subject-matter expert |
|
Estratégia de Produto |
4/5 |
Sim |
Desenvolvimento de roadmaps para iniciativas de analytics, alinhamento com objetivos de negócio |
|
Colaboração Técnica |
4/5 |
Não |
Coordenação com engenharia para implementação de tracking, integrações API, documentação técnica |
|
Metodologias Ágeis |
3/5 |
Sim |
Ainda não apliquei com um papel definido a 100%, mas tenho: Product Owner certificado (CSPO) e Scrum Master (PSM I) |
|
Competência Central |
Nível de Experiência |
Formação |
Como Apliquei |
|
Visão Estratégica |
4/5 |
Sim |
Desenvolvimento de estratégias digitais alinhadas com objetivos de negócio, roadmaps de longo prazo |
|
Capacidade de Prioritização |
4/5 |
Sim |
Desenvolvimento do projeto de Analytics, de gestão de budget em campanhas, de gestão de clientes em consultora e obtenção de perto de 90% dos OKRs, |
|
Comunicação |
3/5 |
Não |
Apresentações para stakeholders, documentação técnica, role de subject-matter expert |
|
Liderança |
4/5 |
Não |
Gestão de equipas consultoras, coordenação de projetos de transformação digital |
|
Resolução de Problemas |
4/5 |
Não |
Identificação de pain points em customer experience, soluções para problemas complexos de negócio |
|
Tomada de Decisão |
3/5 |
Não |
Decisões data-informed, otimização baseada em performance metrics, implementações técnicas |
|
Adaptação à Mudança |
5/5 |
Não |
Projetos de transformação digital, continuous learning (Data Science, AI), pivoting strategies, iniciei funções na área de Engenharia |
COMPETÊNCIA CENTRAL - PRODUCT ANALYTICS
|
Competência Central |
Nível de Experiência |
Formação |
Como Apliquei |
|
Analytics e Gestão de Projeto |
4/5 |
Sim |
Setup completo GA4, event tracking, configuração data layer Visualização de Dados |
|
Entendimento do Negócio e Frameworks de Medição |
4/5 |
Sim |
Definição de KPIs, criação de planos de medição, tracking de métricas de sucesso |
|
Visualização de Dados |
4/5 |
Não |
Dashboards Looker Studio, reporting executivo, apresentação de insights SQL & Consulta de Dados |
|
User Behavior Analysis |
4/5 |
Sim |
Análise de customer journey, otimização de conversão, insights comportamentais |
|
Otimização de Resultados |
4/5 |
Não |
Otimização de campanhas, testing de conversion rate, análise estatística |
A Vantagem Única do Background em Marketing
Isto é o que os ATS não conseguem ver e muito menos analisar. E nalguns casos, atrever-me-ia a dizer que muitas pessoas de de RH também não percebem: os profissionais de marketing têm frequentemente uma visão mais holística do ciclo de vida do cliente do que as pessoas tradicionais de produto ou de que outras profissionais focados numa área específica do digital.
Deixem-me que vos diga uma coisa, que provavelmente já perceberam (ou já sabiam) ao ler este artigo.
Quem trabalha na área digital, nomeadamente nas áreas de suporte ao produto, e no meu caso específico trabalhei em várias dessas áreas, faz produto
Como Valorizo a Minha Profissão e Como Me Mantenho Atualizado em Produto
Fazendo formações relevantes e reconhecidas na área, como o curso de Product Management, o curso de Product Discovery ou o Curso de Product Analytics da PM3. Ou obtendo a certificação de Product Owner e de Scrum Master pela Scrum Alliance e pela Scrum.org, respetivamente.
Talvez, ainda não decidi, aposte também em Escolas Portuguesas de Produto e7ou na Certificação de Projetos PMI.
Como Valorizo a Minha Profissão e Como Me Mantenho Atualizado em Dados
A evolução constante é fundamental na nossa área. Por isso, invisto continuamente no meu desenvolvimento profissional:
Terminei na passada 4ªf a Pós-Graduação em Data Science for Business Strategy na Universidade Nova - Faculdade de Ciências e Tecnologia, que me tem deu uma base sólida em modelação estatística e machine learning aplicado a contextos empresariais. E este não é o único curso que fiz sobre Dados. Estou a fazer mais duas formações nessa área. Porquê? Por dois motivos:
-
- Hoje em dia fala-se muito em IA, mas IA sem dados bem limpos e processados não funciona
- Trabalhar em produto é também saber medir e apresentar resultados
- Pode dar-me, e não me importar-me-ia na área de Product Analytics
Como Valorizo a Minha Profissão e Como Me Mantenho Atualizado em IA
Confesso que é uma disciplina onde não tenho dedicado o tempo que gostaria. Mas além de acompanhar alguns canais de YouTube sobre o tema, o projeto final que fiz na Pós-Graduação em Data Science for Business Strategy teve por base um protótipo que fiz no Replit, através de Vibe Coding. E muitos, se não todos os scripts de Python foram gerados utilizando a IA Generativa, através da ferramenta Claude.
Paralelamente, tenho estado a explorar Agentic AI e as suas aplicações em product management e analytics. Estou particularmente interessado em como os AI agents podem automatizar tasks de research e análise de dados, traduzindo menores custos para as Empresas. Mas na altura em que estou a escrever este artigo, ainda estou numa fase muito embrionária.
E isto são só algumas das apostas que tenho feito. Tendo uma oportunidade na área, irei muito mais fundo nos temas, ou nm tema específico que veja ser útil para ambos
Auto-aprendizagem contínua faz parte da minha rotina
Acredito muito no investimento em conhecimento. Para mim é algo mais do que pessoal, é estratégico. E no caso da IA, seja como product owner, como product Manager, como digital marketer, ou até mesmo noutras funções fora do mundo digital, o futuro será profundamente influenciado por AI e automation, e quero estar no sítio onde a “bola” de hóquei vai parar.
Acredito que a curiosidade e a capacidade de aprender continuamente são as competências mais importantes num profissional de produto ou de outra área. E as empresas deveriam estar atentas a isso. Ao fim e ao cabo, se o colaborador investe por ele na sua evolução, quer dizer alguma coisa em termos empresariais.
O Caminho em Frente
Não estou a abandonar a minha expertise em marketing; estou a expandi-la para product management e/ou analytics onde pode ter ainda maior impacto. As competências transferem-se perfeitamente:
A minha experiência em otimização de campanhas torna-se otimização de features de produto. O meu conhecimento de aquisição de clientes torna-se expertise em onboarding de utilizadores. As minhas competências de implementação de analytics tornam-se frameworks de medição de produto. A minha experiência em gestão de stakeholders torna-se liderança cross-funcional de produto. A minha aprendizagem em AI torna-se product innovation com tecnologias emergentes
Conclusão
Como já viram, tenho competências valiosas e transferíveis que muitos profissionais tradicionais de produto não possuem, pelo menos aqueles menos experientes. Do que vejo do mercado, nomeadamente de parceiros com quem contacto, há muita falta de conhecimento nesta área. Sabe-se tudo pela rama ou porque alguém ouviu falar.
Se são hiring managers à procura de talento, considerem profissionais de marketing como eu que tenho estado a fazer o trabalho, mesmo sem o título de Product Manager. Trago uma perspetiva que pode fortalecer a vossa equipa de produto. E saibam que não estou a começar do zero e por isso não considero que esteja a fazer uma migração de carreira stricto senso.
E finalizando,…
acima de tudo, não me interessa o título, interessa-me a Empresa, a cultura, as pessoas, e obviamente todas as condições que tenho para desempenhar as funções.
João Carlos Matos é um profissional de marketing digital com 12+ anos de experiência em analytics, user research e otimização de produtos. Está atualmente em migração de Empresa e transição para funções de Product Management, AI Product Management ou Product Analytics onde pode aplicar as suas skills numa combinação de expertise em Marketing e Pensamento de Produto.
Se quiserem saber mais, contactem-no no LinkedIn ou visitem o seu Website.
Fundamentos de Product Management - Aspetos relativos ao Product Manager
Introdução
Este artigo é a parte 2 do artigo publicado em Agosto Fundamentos de Product Management – Aspetos Relacionados com o Produto | João Carlos Matos (joaomatosdigital.pt)
O que é ou o que envolve a função de Product Management
O Product Management – PM – é o enabler/connector entre a estratégia da Empresa e os problemas e necessidades dos clientes. Ou seja, deve perceber na Visão do Produto como o mesmo vai ou pode impactar positivamente a vida das pessoas e, simultaneamente, os objetivos estratégicos da empresa. Ou seja, a função de Product Management envolve equilibrar e entregar valor e viabilidade ao longo de todo o ciclo de vida do produto.
Gestão de Projetos e Gestão de Produtos
Se um projeto é diferente de um produto, obrigatoriamente, a gestão de projetos é diferente da gestão de produtos. E a este respeito aconselho a leitura do artigo que publiquei sobre este tema: “Produtos e Projetos – Product Management e Project Management”.
Product Management vs Product Owner – PO
Pois é, ao contrário daquilo que muitas Empresas pensam, a julgar pelos anúncios publicados para a “função” de PO, um PO não é um PM. Indo direto ao ponto, um PO não é uma função. É uma papel desenvolvido pelos responsáveis pela criação do Scrum Guide. O papel do PO é focado na criação da meta da sprint, priorização do backlog e na garantia dos deliveries dentro dos prazos acordados. Ou seja, é um papel muito mais tático, enquanto o papel do Product Management é uma função e muito mais estratégica.
Cultura de Produto
Uma empresa não tem uma cultura de produto por inerência à sua constituição. A cultura de produto, tal como a cultura de um país ou de uma pessoa, constrói-se e vai-se desenvolvendo.
Alguns princípios para uma cultura de produto ser desenvolvida podem traduzir-se em:
- Aprendizagem acima de Culpa – O indivíduo, as equipas, as pessoas e o produto só se desenvolvem se se cometerem erros. Sejam eles calculados ou não. Na psicologia há um princípio que é o “Condicionamento Operante”. Muito utilizado no treino canino. Mas cães, ao contrário daquilo que as pessoas possam pensar, não aprendem através de punição, mas sim através do reforço positivo. E com as pessoas e as suas funções dentro da empresa este princípio deve ser aplicado. Mesmo que a cultura não seja de produto. Acredito que este é um princípio universal empresarial
- Colaboração acima do Individualismo – A É sempre melhor trabalharmos em equipa do que individualmente. “Nenhum Homem é uma Ilha”. E o desenvolvimento carece de várias disciplinas empresariais para o seu desenvolvimento. E ainda, trabalhando em equipa quando há vontade, motivação, conhecimento, multidisciplineriedade e não reconhecimento de culpa, a probabilidade de acontecerem erros forçados é menor.
- Propósito de negócio acima de Receita – O propósito de um negócio não pode ser a receita. NA receita é algo que está subjacente a um negócio que não tem fins lucrativos. A Receita deve ser vista como uma métrica Q.B., mas como uma métrica. E mesmo sendo vista como uma métrica, não deve ser vista como a North Star. Daí ter dito que é uma métrica Q.B.
- Transparência e Contexto acima de Opacidade – Sem contexto não há aprendizagem. Sem contexto não há trabalho individual e muito menos em equipa. Sem contexto o negócio não tem um propósito, porque não conhece as suas circunstâncias internas e externas.
- Inovação acima de Estagnação – Se as empresas não evoluírem, as pessoas não evoluem, o produto não evoluem e a empresa mais cedo ou mais tarde, ou pelo menos o produto entra em declínio.
Liderança de Produto
- Contexto – Um dos Princípios da Cultura de Empresa é o Contexto acima da Opacidade. E além daquilo que escrevi sobre este Princípio, o Contexto significa que todas as pessoas conhecem qual é a Visão, a Missão e os Valores da Empresa (e se os clientes também souberem melhor).
- O Propósito deve responder à pergunta: Por que?
- A Visão responde à pergunta: O quê?
- A Missão: Como?
- Remover Impedimentos – Mais uma vez: a liderança deve estar presente, mas sem microgerir as equipas. A liderança deve deixar claro para todos qual a Visão de Futuro, e gerir excessos de trabalho, gerir expectativas e ansiedades, e ter a responsabilidade e independência total para que possa auxiliar a equipa a sentir-se parte integrante de “uma gestão” de produto.
- Desenvolver as Pessoas – Numa cultura de produto, o desenvolvimento deve ser feito tendo em conta o seguinte:
- As Pessoas são a prioridade número 1 da Empresa, só assim conseguimos que elas consigam estar focadas no seu trabalho. E por isto, é importante que a liderança saiba, entre outros temas, balancear pressão, ainda que não exista ttrabalho sem pressão.
- A aprendizagem, tal como visto no parágrafo sobre a Cultura de Produto é uma constante e deve ser fornecida a todas as pessoas e todas as pessoas são vasos e veículos de aprendizagem, inclusivamente o Product Manager
- Avaliações e Feedbacks – As avaliações são um “número” ou um “tier” em que a pessoa fica após ser avaliada. O feedback dá o contexto e responde aos possíveis porquês que os avaliados possam ter. Fazer uma avaliação sem dar contexto (até mesmo sem contexto prévio de quais serão os fatores a serem avaliados) é algo de uma Empresa sem cultura não só de produto, mas sem cultura de Pessoas.
- Promoções e Aumentos – Duas ideias sobre este tema:
- 1 – As promoções e os aumentos não devem estar atreladas ao ciclo de avaliação. A própria metodologia de OKR – Objectives & Key Results transpira este princípio.
- 2 – As promoções podem ser feitas de duas formas: Assumir atividades relacionadas com essa função ainda não ter atingido a mesma – push promotion e assumir as funções apenas quando se chega à função – push promotion.
Carreira de Produto
A carreira de produto pode ser biforcada. Num dos caminhos temos uma carreira mais vocacionada para a Liderança de Pessoas e no outro caminho temos uma carreira mais de especialista.
- Ramo comum – As funções comuns à carreira de Product Manager, antes de “se optar” por um dos caminhos da bifurcação são: Associate Product Manager, Product Manager e Sénior Product Manager
- Se se optar pelo caminho de Gestão de Pessoas temos as seguintes funções – Group Product Manager, Head of Product e VP of Product
- Se se optar pela carreira de Especialista temos como funções – Product Specialist e Principal Product Manager
Conclusão
Acredito que este segundo artigo sobre Fundamentos de Produto possa ajudar muitos aspirantes a Product Managers a entender melhor este mundo e a fazer escolhas acertadas quando optarem por ir para uma Empresa. Porque tal como disse no primeiro artigo, há muito falta de cultura de produto dentro das Empresa, infelizmente. E isto não é necessariamente mau, a partir do momento que as empresas o reconhecem e fazem tudo para que essa cultura seja implementada. Vai ser fácil? Não. É o CEO que a implementa? Não. Temos de ter autonomia total e responsabilidade enquanto PM? Sim.
E puxando a brasa, dentro do possível à minha sardinha e mais uma vez: não tenho o título de Product Management, mas tenho mais de 11 anos de experiência a trabalhar em produtos digitais dentro de várias culturas empresariais e interagindo com diversas equipas e adoraria assumir uma função dentro desta área associada ou não aos dados.
Fundamentos de Product Management - Aspetos relativos ao Produto
Introdução
Este artigo é um resumo daquilo que foi a minha aprendizagem do Módulo 1 do curso de Product Management, mas direcionado ao tema do Produto. No próximo artigo escreverei sobre os “Aspetos relativos à Função de Product Management”.
O que são Produtos Digitais e que Tipos de Produtos Digitais Existem
Neste artigo podem obter informação sobre O que são Produtos Digitais? | João Carlos Matos (joaomatosdigital.pt). Escrevi este artigos antes de iniciar este curso, o que comprova que todo o investimento feito em formação e experiência profissional adquirida me permitem atuar como um Product Manager.
Mas vamos fazer então um breve resumo sobre este tópico. Um produto digital é qualquer tipo de software e/ou tecnologia que tenha utilizadores.
Os tipos de produtos digitais que existem são:
- Produto Digital (software propriamente dito) – É um produto comprado ou subscrito online pelos utilizadores. Por exemplo, uma assinatura do serviço da Google (SaaS). Ou a utilização de uma app de Homebanking.
- Marketplaces (de troca) – São plataformas que reunem num único lugar fornecedores, vendedores e clientes. Por exemplo, Airbnb.
Visão e Estratégia de Produto
A Visão de Produto é aquilo que queremos que ele seja no futuro. A Visão de Produto é das maiores responsabilidades do Product Management, pois é a “estrela guia” de tudo o resto. Mas atenção, não é o Product Management que estabelece a Visão do Produto sozinho. Assim como não é o CEO que a estabelece essa visão sozinho. Ambos estabelecem essa Visão e com base em vários elementos e artefactos que veremos de seguida.
Elementos da Visão
Os eleitos da visão serão os Objetivos Estratégicos da Empresa e os Problemas e as Necessidades das Pessoas.
Artefactos da Visão dos Objetivos Estratégicos da Empresa
- Análise SWOT – A Matriz SWOT vai permitir-nos identificar as Forças (Strengths) do negócio, as Fraquezas do negócio (Weakness) as Oportunidades do Mercado (Opportunities) e as Ameaças do Mercado (Threats).
- Análise de Mercado – Os vários tipos de análise de mercado vai permitir-nos identificar: Concorrentes, Potencial de crescimento nesse mercado, possíveis disrupções…Este tipo de análise advém não só da SWOT, mas também, por exemplo, de Benchmarks.
Artefactos da Visão Problemas e as Necessidades das Pessoas
- Jornada do Cliente – Representação visual, mas com base na realidade, dos passos, interações, motivações e frustrações dos clientes com uma Empresa/Produto ao longo de toda a sua experiência.
- Personas – Perfis fictícios baseados em dados reais que representam os diferentes tipos de clientes de um produto ou serviço.
- Mapa de Empatia – Ferramenta que ajuda a entender melhor as emoções, desejos, preocupações e comportamentos de um cliente, colocando-se no lugar dele.
- Quais são as Etapas do Ciclo de Vida do Produto
Este tema ainda o estudei na universidade, ainda nada se falava sobre Product Management, falava-se em Gestão de Produto (mais físico). Mas em metodologias de trabalho agile nada, mesmo nada se falava. Vejam bem!!!
O Ciclo de Vida do Produto tem 4 fases:
- Entrada/Inovação – A primeira fase chamo-a de entrada para aquelas produtos que não trazem nada de inovador ao mercado e, portanto em princípio não vão trazer grande valor para as pessoas (a não ser provavelmente o preço mais baixo), e consequentemente para o negócio. E se o benefício for o preço, entra-se numa luta para o fundo. Para aqueles produtos que são inovadores, os benefícios deverão ser valorosos para as pessoas e para o negócio. Partindo do princípio que o Produto foi pensado tendo em conta essas premissas, mas também, as metodologias de desenvolvimento.
- Crescimento – Nesta fase é onde percebemos para os produtos que não trazem nada de valor ao mercado se o preço é suficientemente algo que gera valor para as pessoas e para o negócio ou se pelo contrário, o produto entrará em declínio. No caso dos produtos inovadores esta é a fase em que o Produto tem de encontrar o seu “Product Market Fit”.
- Maturidade – Nesta fase os produtos começam a gerar receita para o negócio – Product Economic Fit.
- Declínio/Relançamento – Fase em que o Produto chegará ou não ao Product Market Fit, mas por nunca encontrar um bom Economic Fit, é descontinuado e7ou tem de ser repensado.
Estas 4 fases em a sua correspondência na Matriz BCG, que é um dos artefactos de um Product Management e/ou negócio:
- Quadrante da Matriz BCG dos Pontos de Interrogação – Corresponde à fase de Entrada do CVP
- Quadrante da Matriz BCG Vacas Leiteiras – Corresponde à fase de Maturidade do CVP
- Quadrante das Estrelas da Matriz BCG – Corresponde à fase de Crescimento do CVP
- Quadrante dos Abacaxis da Matriz BCG – Corresponde à fase de Declínio do CVP
Quais são as Fases de Desenvolvimento de um Produto
O desenvolvimento de um produto digital faz-se, ou deve-se fazer, de forma iterativa. Porque os produtos digitais são complexos e em que o problema das pessoas (utilizadores) vai sendo descoberto à medida em que o produto se vai desenvolvendo. A este respeito podem ler também o artigo sobre a Metodologia Agile vs Waterfall na criação de produtos digitais | João Carlos Matos (joaomatosdigital.pt)
Então, existem, essencialmente 3 fases no desenvolvimento de um produto:
- Problem Discovery – Fase em que se está a tentar identificar da melhor forma e detalhe possível o problema que as pessoas estão a enfrentar e que podem gerar valor para o negócio, de acordo com aquilo que é a visão da Empresa. Esse problema pode ser uma necessidade real ou uma necessidade latente. Nesta fase, existe uma maior participação da gestão de produtos e UX (80%-90%), mas a participação das equipas de desenvolvimento e engenharia também é bem vinda, se possível e viável (20%-10%).
- Solution Discovery – Fase em que se está a desenvolver uma possível solução (teste) para o problema descoberto. Ou seja, além de se descobrir as (possíveis) melhores oportunidades, é importante criar e validar essas hipóteses de solução.
Nesta fase, todas as pessoas da equipa devem participar. - Delivery – Fase em que se desenvolve a solução, mas e novamente testando-a de forma rápida e analisando resultados/métricas para se voltar a iterar.
- Nesta fase, existe uma maior participação da equipa de desenvolvimento e engenharia (80%-90%) e uma participação mais residual das equipas de gestão de produtos e UX (20%-10%).
Mas vamos fazer então um breve resumo sobre este tópico. Um produto digital é qualquer tipo de software e/ou tecnologia que tenha utilizadores.
Conclusão
Este curso, comprova, por mais uma vez, a minha forma de estar comigo, enquanto profissional responsável e que se interessa bastante pela área digital/Martech onde trabalho e a minha forma de olhar para o trabalho.
Como se costuma dizer, “no papel” não sou um Product Management, nem Product Owner – e tenho também a Certificação CSPO da Scrum Alliance. Mas tenho mais de 11 anos de experiência a trabalhar em produtos digitais interagindo com diversas equipas e em várias empresas; agência full service, agência de web intelligence, clientes B2C, clientes B2B, consultoras.
Produtos e Projetos - Product Management e Project Management
Introdução
Já escrevi três artigos a falar sobre Produtos Digitais e que podes lê-los nos links abaixo.
O que são Produtos Digitais? | João Carlos Matos (joaomatosdigital.pt)
Hoje o artigo foca-se mais naquilo que são projetos e como geri-los. Tenho duas ideias fortes sobre o tema:
1 – A gestão de produto e a gestão de projetos, ainda que diferentes, sobrepõe-se.
2 – A gestão de projetos torna-se mais fácil para quem tem conhecimentos e/ou prática na gestão de produtos, nomeadamente produtos digitais. Isto porque, é mais difícil gerir algo com menos informação do que com toda a informação. Além disso, Além disso, os Project Managers utilizam combinações de metodologias ágeis e tradicionais, para garantir que os projetos são concluídos conforme o plano estabelecido inicialmente.
Projetos e Produtos, nomeadamente digitais, são conceitos diferentes.
As principais características de um projeto são:
- Foco, essencialmente, no cumprimento do prazo de entrega e na própria entrega
- Tanto o cenário como o contexto é conhecido na sua plenitude e por isso…
- Âmbito negociado inicialmente e fechado
- Timing de início e de finalização previsto
- Budget definido inicialmente e sem necessidade de revisão (previsivelmente)
- Terminado o projeto, o trabalho do Project Manager nesse projeto, geralmente termina
As principias características de um produto são:
- Foco, essencialmente, na entrega de resultados e valor para pessoas e empresas
- Os cenários e os contextos não são totalmente conhecidos à partida, por serem voláteis às necessidades das pessoas
- O âmbito não é fechado e vai-se negociando durante o desenvolvimento do produto
- Timing de início definido, mas sem um timing de finalização uma vez que o produto está (ou deve estar) em constante adaptação
- Budget definido, mas com necessidade de revisões periódicas e com base nas várias conclusões emergentes dos ciclos de iteração
- Em princípio um produto está em constante desenvolvimento (a não ser que seja descontinuado) e, portanto enquanto o produto estiver a evoluir o trabalho do Product Manager não termina
Se são conceitos e realidades diferentes, será que a gestão de projetos e de produto é também ela diferente? Diria que obrigatoriamente terá de ser. Podes ver o artigo sobre esta temática intitulado:
Será Diferente Criar um Produto Digital em Ambiente Agile ou Waterfall? | João Carlos Matos (joaomatosdigital.pt)
Aliás, quem está no meio sabe que existem certificações em Gestão de Projetos. Por exemplo a certificação em Project Management Professional do Project Management Institute – PMI. Mas também existem certificações em Product Owner. Por exemplo a certificação CSPO da Scrum Alliance ou a certificação PSPO da Scrum.org. Eu tenho a primeira.
Então, o que é assim tão diferente entre a gestão de produto (Product Management) e a gestão de projetos (Project Management).
Gestão de Projetos
A gestão de projetos foca-se na realização de algo específico e com objetivos, âmbito, prazos e alocação de recursos bem definidos. Isto porque um projeto tem uma data de início e de fim e o Project Manager tem a responsabilidade de garantir que todo o Ciclo PDCA – Planeamento, Desenvolvimento, Controlar e Atuar é executado dentro dos timings, budget e âmbito estabelecidos inicialmente.
A gestão de projetos tem uma componente de risco associada e que deve ser também gerida pelo Project Manager. Essa componente é inerente ao facto das características de um projeto, onde tudo fica definido inicialmente (âmbito, budget, prazos, requisitos, recursos, ferramentas…).
Existe também a necessidade de gestão de das pessoas, comunicações e stakeholders ao longo do mesmo, mas que é algo semelhante ao que acontece com a gestão do produto (digital).
Gestão de Produtos
A gestão de produto (Product Management) e a gestão de projetos (Project Management) são disciplinas distintas que, embora possam se sobrepor em algumas áreas, têm objetivos, responsabilidades e focos diferentes. A gestão de produto concentra-se no ciclo de vida completo de um produto, desde a concepção até a descontinuação, garantindo que o produto atenda às necessidades do mercado e dos clientes. O gestor de produto (Product Manager) é responsável por definir a visão do produto, planejar a estratégia de desenvolvimento, priorizar funcionalidades e trabalhar em estreita colaboração com equipes de desenvolvimento, marketing e vendas para garantir o sucesso contínuo do produto.
Conclusão
Ou seja, enquanto a gestão de produto é uma função estratégica e contínua, a gestão de projetos é uma função tática e finita, cada uma essencial para o sucesso organizacional nas suas respectivas áreas.
Scrum - Eficiência vs Eficácia
Para melhor leitura e compreensão deste post, aconselho a leitura do último post publicado no blog intitulado Scrum para “Dummies”: Papéis e Eventos – Comparação com o Futebol
Há muitos anos, antes da popularização da framework Scrum e das metodologias ágeis, aprendi (com muita ajuda do meu avô) sobre a importância da melhoria contínua com base nas Normas ISO, destacando a diferença entre eficácia e eficiência. A distinção é simples: eficácia significa fazer as coisas certas, enquanto eficiência envolve fazer as coisas bem.
Comparando isso ao futebol, a eficácia seria a equipa marcar golos, enquanto a eficiência seria jogar bem. Assim como no futebol, a beleza artística das equipas a jogar não garante vitórias, mas certamente que poderá aumentar a probabilidade que a eficácia – golos – aconteça.
No contexto do Scrum, essa distinção também se aplica. Podemos ser eficientes sabendo trabalhar muito bem com ferramentas de gestão de backlog, organizar o sprint backlog, ou agendar todas as cerimónias regularmente no mesmo local e horário, demonstrando eficiência.
No entanto, é crucial questionar se somos eficazes. Estamos a fazer as coisas certas? Estamos a cumprir com as metas da sprint? Estamos a entregar outcomes em vez de features? Estamos a entregar valor?
Uma nota de rodapé e recordando minha experiência na implementação de Sistemas de Gestão da Qualidade, lembro-me do Ciclo PDCA – Planear, Executar, Controlar e Agir. Ao observar de perto, percebo que o Scrum segue um padrão semelhante. Temos o Sprint Planning, a execução dos trabalhos durante a sprint, o controlo (no Scrum chama-se de inspeção) nas cerimónias e a ação, evidenciada na Retrospective e na Review.
Scrum para “Dummies”: Papéis e Eventos - Comparação com o Futebol
Introdução
Escrevi este artigo para consolidar conhecimentos na framework Scrum e preparar-me para o exame de certificação de Professional Scrum Master.
A comparação com o futebol visa tornar mais claro o que é e como funciona esta framework. Muitas pessoas de diversos setores desconhecem esta metodologia ágil. Para aqueles que a conhecem, mas não a aplicam corretamente, espero que esta comparação seja esclarecedora e produza os efeitos desejados.
Naturalmente, esta é uma comparação “bruta” e superficial e por isso deve ser interpretada com um “grain of salt”.
Vamos então…
Os Papéis
Scrum Master
O Scrum Master é a pessoa na equipa Scrum que deve compreender melhor a framework Scrum e uma das suas responsabilidades é disseminar esse conhecimento pela organização e, por conseguinte, pela equipa Scrum.
Assim, pode-se dizer que os árbitros, por compreenderem melhor as regras do futebol, desempenham no futebol o papel equivalente ao do do Scrum Master.
Product Owner
Considerando que o Dono do Produto tem como função principal gerar retorno do investimento do produto para a empresa, o papel semelhante no futebol poderá ser o treinador principal.
O equivalente a uma equipa de futebol pode ser o treinador principal. Contudo, é importante notar que enquanto o treinador principal de uma equipa de futebol é o líder desta equipa, o Product Owner não lidera ninguém na Equipa Scrum.
Developers
Os developers são as pessoas responsáveis por gerir/auto-gerir os trabalhos da sprint para que, no final desta, se atinja a meta e se produza um incremento com a qualidade e valor esperados.
No futebol, os developers são os jogadores de futebol.
Os Eventos de uma Sprint
Sprint Planning
O Sprint Planning é o evento que dá origem à sprint. Neste evento, o Product Owner, em conjunto com a equipa de developers, define a meta da sprint. Após definida a meta, é necessário determinar quais os itens do product backlog que serão incluídos no sprint backlog (assumindo que todos estão prontos). Por último, os developers “quebrarão” essas histórias em atividades a desenvolver ao longo da sprint.
No futebol, o treinador, juntamente com os membros da equipa, define o plano de jogo para o próximo encontro. Decide quais jogadores irão participar e como deverão jogar para cumprir o plano. Pode haver substituições durante o jogo e, da mesma forma, ao longo da sprint, através da inspeção e adaptação, podem ocorrer ajustes, sempre em concordância com o Product Owner.
Daily
A Daily é um evento do Scrum com uma timebox de 15 minutos, destinado aos developers realizarem a inspeção e adaptação. Não é necessário que o Scrum Master ou o Product Owner estejam presentes, a menos que estejam a trabalhar num item.
Para o futebol, com as devidas exceções de timebox, a Daily é o treino diário físico. Dado que a equipa já conhece as atividades físicas a realizar e, mesmo no treino tático, o treinador principal não intervém muito. Pelo menos, quando se trata de uma equipa experiente com automatismos para diferentes tipos e planos de jogo. A inspeção nas cerimónias ocorre, evidenciada na Retrospective e na Review.
Quem nunca reparou nos treinos (dailies) da Seleção Portuguesa de Futebol o selecionador a andar de um lado para o outro do campo, com as mãos atrás das costas, cabeça baixa e pensativa?
Sprint Review
O evento Sprint Review é o momento em que os stakeholders e a Equipa Scrum inspecionam e adaptam o que foi feito, para perceber se a equipa está a cumprir a meta do produto.
Considero que o evento da Sprint Review é o próprio jogo de futebol. Aqui, os jogadores apresentam (jogam) perante os sócios e outras pessoas (stakeholders) o que estiveram a trabalhar ao longo da sprint (uma semana entre jogos para o campeonato nacional), onde ocorreram as diferentes “dailies”.
A inspeção do plano de treino (meta da sprint) e das atividades em desenvolvimento (itens do backlog) está a ser realizada e adaptada. Inclusive, no futebol, esta inspeção e adaptação ocorrem frequentemente ao intervalo.
Sprint Retrospective
O evento Sprint Retrospective é o momento em que se planeia a qualidade e a eficácia.
No futebol, é o momento em que se analisa o que correu bem e mal, avalia a performance dos jogadores (não aplicável no Scrum), verifica-se o estado físico e psicológico dos jogadores, e vice-versa. Com toda essa informação, devem surgir melhorias para o próximo jogo.
A Meta da Sprint
Não é nem um papel, nem um evento, mas acredito que faça sentido mencioná-la. E falo da Meta da Sprint. É aquilo que queremos entregar como incremento e com valor. Ou seja, a Meta da Sprint deve responder à questão: Porque esta sprint é valiosa.
Na linguagem do futebol, a Meta da Sprint seria o Plano de Jogo da equipa para enfrentar a equipa adversária na próxima jornada. E esse plano de jogo tem subentendido o porquê daquela sprint (semana do campeonato) ser importante para a equipa.
Espero que tenham gostado do artigo. A área de dados, nomeadamente a área de MarTech é uma área na qual me estou a debruçar devagarinho.
Want to read this article in English? Please click here
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