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.
Engaged - Designing for Behaviour Change by Amy Bucher - Simples Review com exemplos do que Aprendi
Terminei de ler o livro “Engaged – Design for Behavior Change”, que aprofunda vários temas de Behaviour Change e que nos ajudam a entender o comportamento humano. Amy Butcher utiliza de forma plena a Teoria da Autodeterminação (SDT) para nos guiar pelo complexo mundo Behaviour Change, enfatizando particularmente o aspeto crucial de integrar o Behaviour Change no Design de produtos e serviços digitais.
Embora o livro não aborde explicitamente os exemplos que enumerarei a seguir, eles permanecem altamente relevantes no contexto atual em que vivemos, sendo muitas vezes negligenciados por profissionais da área.
- A E-Privacy e o GDPR – sendo, respetivamente, uma Diretiva Europeia e um Regulamento aplicado em Portugal, giram principal e logicamente em torno do panorama legal. No entanto, os mesmos foram criados porque não houve um respeito pelos utilizadores. Ou seja, a essência destes documentos está na necessidade de respeitar as escolhas das pessoas e estabelecer uma arquitetura de escolhas transparente. Os utilizadores têm o direito fundamental de compreender o propósito das tecnologias com as quais interagem, garantindo clareza e uma tomada de decisão informada.
- Imagens nos maços de cigarros – Outro exemplo é a utilização de imagens gráficas em maços de cigarros como meio de desencorajar o tabagismo. Apesar das boas intenções, o conceito ignora um fator crucial conhecido como “Present Bias“. A suposição de que os indivíduos que compram cigarros têm o objetivo imediato de parar de fumar ignora a realidade de que a sua intenção principal é fumar. Ao não se guiar, primeiramente, as pessoas para a mudança de comportamento, a abordagem/tática pode não alcançar o impacto pretendido.
Estes exemplos ilustram a importância de alinhar estratégias de design com uma compreensão profunda do comportamento humano. E não o contrário. Sendo que o contrário pode ser uma grande black-box.
Ao se considerar as motivações subjacentes e os preconceitos cognitivos, os profissionais da área podem criar intervenções que ressoem nas pessoas a um nível profundo, promovendo mudanças de comportamento significativas e tornando a utilização do produto/serviço claro, transparente, duradouro e não apenas num pico de utilização com objetivo único e exclusivo de crescimento instantâneo.
>Engaged – Designing for Behaviour Change by Amy Bucher – Simples review com exemplos do que aprendi
A Importância do UX na Criação de Eventos para Analytics
Introdução
Antes de começarmos, vamos só recordar uma definição importante e que é a definição de “Analytics”. Analytics é algo que podemos obter através de scripts instalados no código fonte dos websites ou apps. Ou seja, na realidade (e sem muito rigor técnico) são métricas que o computador, através de alguma ferramenta, consegue recolher através desses scripts, em resposta à ação do utilizador num do web browser ou aplicativo móvel.
Desenvolvimento
Portanto, antes de mergulharmos na escolha da ferramenta de analytics e na implementação de eventos, seja via datalayer ou via DOM scrapping é fundamental reconhecer a importância do trabalho de UX e, mais especificamente, da criação de fluxos de tarefas do utilizador.
Trabalhar o UX, significa trabalhar estrategicamente a experiência holística do utilizador, incluindo entender toda a sua jornada desde o início (que pode não ser online) até ao alcançar dos seus objetivos (que pode também não ocorrer online). Como vimos na introdução, ao criarmos eventos “para analytics” estamos, essencialmente, a capturar dados sobre como os utilizadores interagem com o website ou app. E para capturar esses dados da forma mais simples possível (ou seja sem workarounds porque causa do legacy code) e, possivelmente, também de forma o mais precisa e significativa possível (tendo em conta as várias circunstâncias do mundo online, como é o caso da privacidade), é crucial compreender a jornada, para desenharmos o fluxo de interações do utilizador o mais simples possível.
Estes fluxos de utilizador fornecem uma estrutura clara para entender como os utilizadores navegam e interagem com o produto. Ao mapear esses fluxos, podemos identificar pontos de fricção, pontos de abandono e áreas de oportunidade para otimização. Isso traduz-se diretamente na criação de eventos relevantes para analytics. Ao entender os caminhos que os usuários percorrem, podemos identificar os eventos-chave que queremos rastrear para entender melhor o comportamento do utilizador e suas intenções.
Exemplo
Ao analisarmos um website de e-commerce, podemos identificar o fluxo de um utilizador desde a entrada no e-commerce até a conclusão de uma compra. Ao entender cada etapa desse fluxo, podemos identificar os eventos que indicam o seu “engajement”; como visualização de produtos, adição do produto ao carrinho, checkout e finalização da compra. Ao mapear estes eventos numa fase de planeamento da expirência, mais tarde, rastrear esses eventos, podemos obter insights valiosos sobre o desempenho do site, taxas de conversão, comportamento do usuário e muito mais.
Além disso, a criação de eventos com base nos fluxos de utilizador também nos permite personalizar e segmentar as análises. Podemos criar segmentos de utilizadores com base nos seus padrões de interação, o que nos permite entender melhor diferentes grupos e, se possível, adaptar nossa estratégia de marketing e produto de acordo.
Ao implementar esses eventos na datalayer do website e ao configurá-los corretamente no GA4 ou Adobe Analytics ou noutra ferramenta para o efeito, podemos identificar áreas de melhoria, testar hipóteses e iterar continuamente para aprimorar a experiência do utilizador.
Conclusão
Em suma, o UX desempenha um papel fundamental na criação de eventos para analytics, pois nos ajuda a entender a jornada do usuário e a identificar os eventos-chave que queremos rastrear. Ao mapear os fluxos de usuários e criar eventos relevantes, podemos obter insights valiosos que impulsionam o crescimento e o sucesso de nossos negócios online.
Podes saber mais no artigo abaixo:
Redesenho de Websites e integração com Digital Analytics
“Para Quem Não Sabe Para Onde Vai, Qualquer Caminho Serve” by Lewis Caroll
O redesenho (redesign) de websites e/ou de outros aplicativos digitais são acontecimentos comuns de ocorrerem nas organizações. Este tipo de trabalho pode ser algo pequeno e simples como a mudanças na navegação numa única página, até mudanças mais complexas que interferem tanto no front-end como no back-end.
Em qualquer dos casos, muitas organizações não contam com as equipas de Digital Analytics. E o resultado é escandaloso. O website e/ou os aplicativos são redesenhados, obrigando a novos desenvolvimentos, é colocado em produção, e muitas implementações ou todas as implementações feitas ao nível da implementação de eventos falha,….e de quem é a culpa? Do Digital analytics.
E o tema não deve, não tem e não pode ser ou continuar a ser assim nas empresas. Isto porque existem vários key-points que devem ser acautelados no desenvolvimento destes trabalhos. Aliás, as equipas que trabalham ou que fornecem metodologias de trabalho ágeis, deveriam ter pessoas competentes nestas matérias e não só “puros e duros” software developers.
Estabelecimento dos novos Objetivos de Medição
O “primeiro ato” que as equipas, seja o PO, o SM ou alguém do negócio deve ter em conta e levantar o tema junto da equipa de Digital Analytics é a indicação do que, em termos de features, se pretende medir e monitorizar. Sim, porque parte-se do princípio (ainda que a maioria das empresas e equipas não o façam dessa forma) que uma feature é resultante de um trabalho de UX-Research e vai responder a um outcome para melhorar a vida das pessoas. E esse outcome pode ser medido ou não. E mesmo sendo medido, pode sê-lo de outra forma que não através do Analytics.
Desenvolvimento de Planos de Medição e Guias de Implementação
Em seguida, e tendo em conta o que se pretende medir e como; objetivos e KPIs definidos, passa-se à fase de desenvolvimento dos planos de medição e dos guias de implementação correspondentes a esses objetivos e KPIs. Integrar os requisitos de medição e de tracking na fase de planeamento garante que os data touch points necessários serão capturados com precisão após a entrada em produção do novo website ou aplicativos.
Partilha de Protótipos Hi-Fi
A visualização e partilha dos protótipos Hi-Fi com as pessoas de Digital Analytics vai permitir aos mesmos visualizarem os diferentes fluxos dos utilizadores, identificarem pontos de fricção, data touch points, e perceber se os KPIs definidos inicialmente estão presentes naquilo que foi desenhado. Além disso, e se o protótipo estiver bem especificado, é possível contribuir também com insights sobre como medir melhor as interações do utilizador.
Especificações dos Protótipos
- HTML, CSS e JS – O esqueleto de um website é o HTML e o CSS e depois a inteligência do website vem através da implementação do JS. Se estes elementos forem completamente mexidos e alterados, tudo aquilo que havia sido implementado, muito provavelmente deixa de existir. Assim, é preciso garantir que se algum destes elementos forem alterados essas mesmas alterações tenham em consideração o que já está implementado. Além disso, é necessário estar tudo especificado por exemplo ao nível dos use cases de um cliente autenticado ou não. Ou o que acontece quando um utilizador clica no botão/CTA; para que página vai? Ou não vai para nenhuma página? Se existe a possibilidade de refresh da página e a informação mantêm-se armazenada. Que tipo de estilos vão ser aplicados, por causa dos CSS Selectors e da facilidade ou complexidade da sua utilização no caso de ser necessário implementar um trigger com base nos mesmos.
- DataLayer – Se a DataLayer for alterada ou não for considerada vai ser difícil implementar qualquer tipo de eventos via DataLayer. Relembrando que a implementação via DataLayer dos eventos é a forma mais eficaz e com menos riscos de “quebrar” a medição, que existe.
- Estrutura de URL – Os URLs devem ser especificados e, preferencialmente devem ser o mais “amigáveis” possíveis, ajudando também a performance do website ao nível do SEO. A estrutura deve ser clara o que vai garantir que todas as páginas e ações relevantes sejam capturadas na configuração dos eventos. Criação de Single Page Applications – SPA – é uma complicação para implementar. Ou até mesmo a utilização dos iframes (completamente em desuso).
Estruturas de URLs mal especificadas e, posteriormente, mal configurada podem levar a discrepâncias nos relatórios. - Implementação dos Eventos e Custom Dimensions
Além dos KPIs definidos inicialmente e, consequente e muito provavelmente, dos eventos a implementar, as equipas de digital analytics necessitam de ver especificado o tema das custom dimensions. Para acrescentá-las no UI do GA4. Por exemplo, por algum motivo válido o negócio pode querer saber a hora do login. Lembrando que o GA4 free permite apenas a categorização de 25 custom dimensions. - Ativação (ambiente de desenvolvimento e produção)
Isso proporcionará a oportunidade de revisar os dados coletados, identificar discrepâncias ou anomalias e refinar a implementação do rastreamento conforme necessário.
Ao integrar esses pontos ao processo de redesenho do site, podemos aproveitar a experiência de nosso Analista Digital para garantir que nossa configuração de rastreamento esteja alinhada com os objetivos do projeto, as necessidades do usuário e os requisitos de análise de dados.
Conclusão
As empresas muitas vezes descuram o tema do digital analytics quando estão a implementar de raiz websites ou aplicativos ou apps. E ainda mais vezes, esquecem este tema quando estão a fazer o redesenho das mesmas.
É importante sublinhar que a comunicação entre as equipas (e não uma pessoa) de desenvolvimento, design e analytics….e na altura atual até acrescentaria de data, é crucial para garantir o sucesso do projeto de redesenho.
Podem saber mais sobre estes temas nos seguintes artigos:
1 – >Checklist de Atividades de Analytics para (Re)Lançamento de um Website – 11 Atividades a Considerar – PARTE 3
2 – >Checklist de Atividades de SEO para (Re)Lançamento de um Website – 13 Atividades a Considerar – PARTE 2
3 – >Checklist de Atividades de UX e de UI para (Re)Lançamento de um Website – 12 Atividades a Considerar – PARTE 1
Por fim, e acredito que este seja uma conclusão que todos que trabalhamos na área devamos ter é:
Medir apenas o que importa, e nunca medir tudo e mais alguma coisa, nomeadamente quando se utiliza ferramentas free.
O que são Produtos Digitais?
Introdução
Quando pensei escrever este artigo tinha imaginado um título do género “Como gerir projetos digitais (ou não) que são transversais à Empresa e/a determinado produto digital em ambiente agile”. Mas dediquei algum do meu tempo a pensar no assunto e percebi que o título não faz sentido algum.
E para não tornar o artigo demasiado longo dividi-o em 3 partes:
PARTE 1 – O que são Produtos Digitais
PARTE 2 – O que Envolve Criar um Produto Digital
PARTE 3 – Será Diferente Criar um Produto Digital em Ambiente Agile ou Waterfall?
O que são Produtos Digitais?
Um produto digital é todo o produto que pode ser utilizado e/ou comercializado online. Ou seja, podemos ter como produtos digitais aqueles que são passíveis de download e aqueles que não são passíveis de download:
Produtos Digitais Passíveis de Download
- Produtos que os utilizadores podem fazer o seu download e começam a utilizá-lo. Por exemplo uma App para afinar a guitarra como o Guitar Tuner.
Produtos Digitais Não Passíveis de Download – SAAS / Cloud Software
- Produtos em que os utilizadores não necessitam de fazer download dos mesmos e ainda assim utilizá-los na modalidade de free, paga ou freemium. Todos os Softwares As a Service são este tipo de produtos. Por exemplo, a Google Cloud Platform funciona como SAS.
Produtos Digitais como Extensão da Experiência de Cliente – Canal Online
Depois ainda existe uma categoria de produtos digitais que são um misto entre as duas categorias acima. E que eu caracterizo não como produtos digitais, mas sim como táticas ou canais de comunicação com os utilizadores. Por exemplo:
ebooks – livros; Webinars – Conferências; PodCasts – Entrevistas; Cursos online – aulas presenciais; Websites/Lojas Online – sede ou loja física
Conclusão
A criação de produtos digitais, não é desenhar e desenvolver o front-end desse desenho. Nem é desenvolver o back-end desse front-end.
Pensar em desenvolvimento de produtos digitais com foco apenas em design, front-end e back-end vai dar origem a:
1 – Potenciais MVPs mal definidos
2- Desenvolvimento de produtos com base em features (outputs) e não outcomes (mudança que queremos ver no mundo ou nas pessoas para que a vida delas se torne melhor)
3 – Dívida Técnica com uma enormidade de bugs e issues para corrigir
4 – Custos escondidos – de desenvolvimento ou de redesenvolvimento; horas-extra da equipa; possíveis custos no suporte ao cliente, entre outros
Será isto fácil de implementar nas empresas? Certamente que não o é! Mas é meio caminho se as pessoas envolvidas tiverem esta visão e a colocar em prática, mesmo que devagar este princípio.
O próximo artigo PARTE 2 – O que Envolve Criar um Produto Digital