Como medir a maturidade digital de uma empresa?

No meu último artigo, abordei a maturidade digital de uma empresa, ou seja, o quanto a empresa vem investindo em produtos digitais para potencializar seus resultados e o quanto seus resultados foram realmente potencializados pelos esforços digitais.

Mesmo sendo uma definição clara, podemos ir um pouco mais fundo para entender e até quantificar a maturidade digital de uma empresa.

Maturidade digital e cultura do produto

Cultura de produto significa o conjunto de valores e comportamentos que permite que o produto digital gere os melhores resultados para a empresa enquanto resolve os problemas dos clientes.

Existem 4 valores/comportamentos principais que são obrigatórios para qualquer empresa que construa produtos digitais de sucesso:

1. Entregas antecipadas e frequentes

Quanto mais cedo apresentarmos o produto aos nossos usuários, melhor, pois poderemos receber feedback de usuários reais que poderão usar o produto em seu próprio contexto. Neste artigo, explico as 4 razões pelas quais é tão importante lançar cedo e com frequência: (i) este é o momento da verdade, (ii) para evitar o excesso de recursos, (iii) para acelerar o retorno do investimento e (iv) evitar os perigos do cone de incerteza.

Para medir se a equipe de desenvolvimento de produtos está lançando com antecedência e com frequência, precisamos medir o número e a frequência dos lançamentos. Uma empresa chamada DORA (DevOps Research and Assessment), adquirida pelo Google em 2018, vem pesquisando as práticas de DevOps e SRE utilizadas pelas empresas desde 2015 e conseguiu categorizar a entrega de software e o desempenho operacional das empresas com base em 4 fatores:

  • Frequência de deploy: com que frequência sua organização coloca código em produção e libera para usuários finais?
  • Lead time: qual é o seu lead time para mudanças (ou seja, quanto tempo leva para ir do código desenvolvido para o código sendo executado com sucesso em produção)?
  • Tempo para restaurar: quanto tempo geralmente leva para restaurar o serviço quando ocorre um incidente de serviço ou um defeito que afeta os usuários (por exemplo, interrupção não planejada, deficiência de serviço)?
  • Percentual de falha de alteração: qual porcentagem de alterações em produção ou lançamentos para usuários resulta em serviço degradado (por exemplo, tempo até a deficiência ou interrupção do serviço) e, posteriormente, exige correção (por exemplo, exigir um hotfix, rollback, fix forward, patch)?

Com base nas respostas, é possível ter uma métrica de desempenho de entrega de software, conforme detalhado abaixo:

Métrica de performance de entrega de software

A DORA conseguiu reunir durante os sete anos de pesquisa mais de 32.000 respostas de profissionais do setor e notou uma evolução interessante:

Evolução da métrica de desempenho de entrega de software ao longo dos anos

Você pode responder a essas perguntas diretamente no site deles para verificar como estão se saindo.

Quanto mais uma equipe de desenvolvimento de produto se aproxima do nível de elite descrito acima, mais a empresa está digitalmente madura nesse valor/comportamento.

2. Foco no problema

Conforme explicado neste artigo, um passo muito importante na criação de uma boa solução é entender o problema. Quando ouvimos falar de um problema, imediatamente começamos a pensar em soluções. No entanto, quanto mais tempo passamos aprendendo sobre o problema, mais fácil será encontrar uma solução, e as chances são boas de que essa solução seja mais simples e rápida de implementar do que a primeira solução que pensamos.

As equipes de implementação de soluções são equipes que trabalham na implementação de uma solução criada por outra pessoa. Equipes de resolução de problemas são equipes que trabalham para entender profundamente as causas do problema, o contexto e a motivação que as pessoas têm para resolvê-lo. Ao fazer isso, eles são capazes de implementar a melhor solução para o problema em questão.

Trabalho há algum tempo em empresas em transformação digital ou que possuem pessoas, inclusive C-level, não familiarizadas com métodos de desenvolvimento de produtos digitais. Um dos maiores desafios das empresas em transformação digital é passar de uma mentalidade de “negócios demanda => tecnologia implementa” para uma mentalidade de “negócio traz problemas/necessidades => tecnologia trabalha na compreensão desses problemas/necessidades com o usuário, testando hipóteses de solução e implementando uma hipótese de solução validada”.

Como podemos medir o quanto uma equipe de desenvolvimento de produto está focada em problemas? Minha sugestão é examinar as últimas 10 a 20 funcionalidades que a equipe implementou e verificar como a necessidade de cada uma das funcionalidades implementadas chegou à equipe de desenvolvimento do produto. Chegou como uma solicitação de funcionalidade, ou seja, uma solicitação de implementação de solução? Ou chegou como um problema a ser resolvido? Quanto mais coisas chegam à equipe de desenvolvimento de produtos como problemas a serem resolvidos, mais a empresa está digitalmente madura nesse valor/comportamento.

3. Entrega de resultados

Além de ser capaz de entregar com antecedência e com frequência e estar focado em problemas, a equipe de desenvolvimento de produto tem que entregar resultados. Resultados de negócios, bem como resultados para o cliente e usuário do produto. Discuti esse valor neste artigo, onde deixei claro que entregar funcionalidades não é um resultado. Todas as funcionalidades são um meio que serve a um fim, o atingimento de um objetivo de negócio. É muito importante que tenhamos objetivos de negócio bem claros. Idealmente, os objetivos de negócio devem estar conectados ao resultado final, ou seja, aumentar a receita e/ou diminuir os custos.

Como podemos medir o quanto uma equipe de desenvolvimento de produtos está entregando resultados? Minha recomendação é dar uma olhada nos OKRs desta equipe de desenvolvimento de produto. Os objetivos e os resultados-chave devem estar ligados aos resultados da empresa e aos resultados dos clientes. Se encontrarmos OKRs que são tarefas ou OKRs que são métricas, mas métricas que não estão ligadas aos resultados da empresa e dos clientes, fica claro que a equipe de desenvolvimento de produtos não está focada em entregar resultados. Normalmente, uma equipe de desenvolvimento de produto tem mais de um objetivo e mais de 3 resultados-chave. Podemos analisar todos os objetivos e resultados-chave para verificar sua conexão com os resultados da empresa e do cliente como um sim ou não. Quanto mais sim encontramos, ou seja, quanto mais objetivos e resultados-chave encontramos ligados aos resultados da empresa e do cliente, mais a empresa está digitalmente madura nesse valor/comportamento.

4. Mentalidade de ecossistema

Esse valor/comportamento significa tomar decisões que criem valor para todos os atores do ecossistema onde a empresa atua. Essas decisões não podem prejudicar nenhum dos participantes do ecossistema. Neste artigo eu expliquei detalhadamente com um exemplo do Gympass da aplicação da mentalidade de ecossistema na prática. Se a empresa for uma plataforma ou marketplace, esse valor/comportamento é bastante fácil de entender, mas também se aplica se o negócio não é plataforma nem marketplace. Se você é um negócio com um tipo único de cliente, o ecossistema é formado pelo cliente e pelo seu negócio, e esse valor/comportamento significa que você não pode tomar decisões que beneficiem o negócio mas prejudiquem o cliente ou vice-versa. Você pode tomar decisões que beneficiem esse negócio e não afetem o cliente, mas não pode tomar decisões que prejudicam o cliente. E vice-versa, você não pode prejudicar o negócio em benefício do cliente. Esse valor/comportamento se baseia no conceito centrado no cliente, mas o expande para incluir todos os diferentes clientes e o o próprio negócio nessa mentalidade.

Como podemos medir se a empresa tem uma mentalidade ecossistêmica? Minha sugestão neste caso é analisar as últimas 10 a 20 decisões tomadas e verificar para quem elas agregaram valor e se alguma delas gerou impacto negativo em algum dos participantes do ecossistema.

Como medir a maturidade digital de uma empresa?

Utilizando os valores e comportamentos acima, podemos avaliar o quão madura digitalmente é uma empresa e, mais importante, definir quais devem ser nossas áreas de foco para melhorar sua maturidade digital. Responda as 4 perguntas abaixo para auto-avaliar sua maturidade digital.

Entregas antecipadas e frequentes: depois de fazer a verificação rápida do DevOps da DORA nos 4 fatores (frequência de deploy, lead time, tempo para restaurar e percentual de falhas de alteração), como você se classifica?

(a) Elite

(b) Alta

(c) Médio

(d) Baixo

Foco no problema: quanto das entregas da equipe de desenvolvimento de produtos originou-se de solicitações de implementação de soluções?

(a) 0%

(b) Menos de 5%

(c) Entre 5% e 50%

(d) Mais de 50%

Entrega de resultados: quanto dos OKRs da equipe de desenvolvimento de produtos estão ligados aos objetivos da empresa?

(a) Todos!

(b) Mais de 90%

(c) Entre 50% e 90%

(d) Menos de 50%

Mentalidade de ecossistema: quanto das últimas decisões impactaram negativamente um dos atores do ecossistema?

(a) 0%

(b) Menos de 5%

(c) Entre 5% e 50%

(d) Mais de 50%

Agora, para cada (a) adicione 4 pontos, para cada (b) adicione 3 pontos, para cada (c) adicione 2 pontos e para cada (d) adicione 1 ponto. O total indica sua maturidade digital:

Maturidade digital
13 pontos ou maisAlta: Parabéns. Você tem alta maturidade digital. Isso significa que sua empresa vem investindo em produtos digitais para potencializar seus resultados e os resultados de sua empresa foram muito potencializados pelos esforços digitais. Seu foco agora deve estar em constante evolução de suas habilidades digitais.
Entre 12 e 6 pontosMédio: Você está no caminho certo. Sua empresa está começando a investir em produtos digitais para potencializar seus resultados e você está começando a ver os resultados da sua empresa sendo realmente potencializados pelos esforços digitais. Espero que, respondendo as perguntas acima, você tenha agora um bom entendimento sobre onde focar para aumentar sua maturidade digital e, consequentemente, melhorar seus resultados com seus produtos digitais.
5 pontos ou menosBaixo: Você está iniciando sua jornada digital. Sua empresa está investindo um pouco em produtos digitais para potencializar seus resultados e você ainda não viu muito dos resultados da sua empresa sendo realmente potencializados pelos esforços digitais. A recomendação para você é que continue investindo na construção de sua cultura de produto digital para que possa obter cada vez mais resultados com seu investimento.

Então aí está, uma maneira simples de avaliar sua maturidade digital.

Exemplos da vida real

Entrei no Gympass em meados de 2018 e, quando entrei, ficou claro que havia espaço para melhorias em nossa maturidade digital. O mesmo aconteceu quando me juntei à Lopes em meados de 2020. Em ambos os casos, focamos em melhorar os comportamentos que poderiam nos levar a uma crescente maturidade digital.

Alguns comentários finais importantes:

  • Os exemplos acima são do que me lembro da época em que trabalhei nessas empresas. O ideal é que esse tipo de avaliação seja feita considerando os comportamentos atuais com respostas dos líderes da empresa e da equipe de desenvolvimento de produtos. Essa avaliação deve ser feita periodicamente, a cada 6 meses ou a cada ano.
  • É possível ter empresas com o mesmo score de maturidade digital, mas com comportamentos diferentes para focar no que fazer para melhorar a maturidade digital, como são os casos de Gympass e Lopes nos exemplos acima.
  • Mais importante do que conhecer o estágio de maturidade digital de uma empresa ou a pontuação que ela possui, é saber quais são as principais áreas que a empresa e a equipe de desenvolvimento de produtos devem focar para melhorar sua maturidade digital.
  • Conhecer e melhorar a maturidade digital é apenas uma ferramenta, não um objetivo. É uma ferramenta para ajudar uma empresa a extrair mais seus esforços digitais. É uma ferramenta para ajudar uma empresa a atingir seus objetivos e resultados.

Resumindo

  • A maturidade digital de uma empresa significa o quanto a empresa vem investindo em produtos digitais para potencializar seus resultados e o quanto os resultados foram realmente potencializados pelos esforços digitais.
  • Para medir a maturidade digital, precisamos avaliar como a empresa está em cada um dos 4 valores e comportamentos de sua cultura de produto digital. Entrega antecipada e frequente. Foco no problema. Entrega de resultado. Mentalidade de ecossistema.
  • Conhecer e melhorar a maturidade digital é apenas uma ferramenta, não um objetivo. É uma ferramenta para ajudar uma empresa a extrair mais de seus esforços digitais. É uma ferramenta para ajudar uma empresa a atingir seus objetivos e resultados.

Educação, treinamento e aconselhamento em gestão de produtos digitais

Tenho conectado negócios e tecnologia por meio de educação, treinamento e aconselhamento em gestão e desenvolvimento de produtos digitais. Ajudo líderes de produto (CPOs, heads de produtos, CTOs, CEOs, tech founders, heads de transformação digital) a extrair mais valor e resultados de seus produtos digitais. Veja aqui como posso ajudar você e a sua empresa.

Newsletter

Escrevo reguIarmente sobre gestão de produtos, desenvolvimento de produtos, liderança de produtos digitais e transformação digital. Vc pode receber uma notificação por email sempre que eu publicar algo novo, sem depender dos algoritmos de notificação de redes sociais. Basta assinar minha newsletter.

Gestão de produtos digitais

Você trabalha com produtos digitais? Quer saber mais sobre como gerenciar um produto digital para aumentar suas chances de sucesso, resolver os problemas do usuário e atingir os objetivos da empresa? Confira meu pacote de gerenciamento de produto digital com meus 3 livros, onde compartilho o que aprendi durante meus mais de 30 anos de experiência na criação e gerenciamento de produtos digitais. Se preferir, pode comprar os livros individualmente:

Tipo de empresa x maturidade digital

Quando descrevi o que é um produto, descrevi também os 3 tipos de empresas que podem possuir produtos digitais e o impacto do tipo de empresa no papel da gestora de produto na organização que possui o produto:

  • Empresas digitais: o produto vendido pela empresa é o software ou tecnologia desenvolvida pela equipe de desenvolvimento do produto. A Gestão de Produtos é o core da empresa, responsável pela visão de futuro e pela estratégia da empresa. A gestão de produtos terá um papel central na definição e execução da estratégia da empresa. Exemplos: Google Search, AWS, Facebook, Locaweb, Conta Azul.
  • Empresas tradicionais: o produto ou serviço vendido pela empresa provavelmente já existe há muitos anos sem a tecnologia, mas a empresa está começando a entender como a tecnologia pode potencializar o produto. O Gerenciamento de Produto é um facilitador, mas não é o core. É vista como a “área digital”. A gestão de produtos terá que ganhar seu espaço, mostrando o que a tecnologia pode trazer para o negócio. Exemplos são quaisquer empresas tradicionais que conhecemos tais como supermercados, bancos, lojas, indústrias, companhias aéreas, etc.
  • Tradicional nascido-digital: o produto vendido pela empresa poderia existir sem a tecnologia, mas a tecnologia aprimora muito o produto. O negócio foi pensado considerando todos os benefícios que a tecnologia pode trazer. Por exemplo, um banco digital pode decidir realizar todas as suas relações com os clientes online, sem a necessidade de abrir agências para atender seus clientes. A gestão de produto é um facilitador, mas não também é o core. A gestão de produtos terá um papel muito importante na definição e execução da estratégia da empresa, mas não será central. As áreas de negócios provavelmente desempenharão um papel mais importante ou, idealmente, ambas as áreas terão importância semelhante. Exemplos: Amazon, que é uma loja nascida digital. Netflix, que é um serviço de visualização de vídeo nascido digital, qualquer banco nascido digital, etc.

Maturidade digital

Ao apresentar essa classificação para um cliente de coaching de liderança de produto durante um treinamento in company, eles apontaram que estavam investindo muito em sua transformação digital para se tornar uma empresa digital, mas, de acordo com essa classificação, nunca serão digitais, pois esta classificação não permite qualquer movimento entre categorias.

Isso é verdade, essa classificação fala sobre o tipo de empresa em termos de sua natureza, ou seja, como ela foi concebida e qual é o seu produto ou serviço primário. A única maneira de uma empresa ser mais digital nessa classificação é criando novos negócios. Por exemplo, a Amazon, uma loja nascida digital, criou a AWS (Amazon Web Services), um novo negócio para oferecer infraestrutura de tecnologia como produto, o que torna a AWS uma empresa digital. Por outro lado, a Amazon também constrói lojas físicas e isso não a tornou mais tradicional. A Amazon continua sendo uma loja digital. Outro exemplo interessante é o Itaú, que está investindo muito em sua transformação digital e lançou recentemente o iti by Itaú, seu banco digital e o íon by Itaú, sua plataforma digital de investimentos. São negócios recém-nascidos digitais, mas o Itaú ainda é o Itaú, um banco tradicional.

Então, além do tipo de empresa, também precisamos entender sua maturidade digital, o que significa o quanto a empresa vem investindo em produtos digitais para potencializar seus resultados e o quanto os resultados foram de fato potencializados por esses esforços digitais.

Por exemplo, o Itaú amadureceu muito no uso do digital para potencializar seus resultados. A criação do iti e do íon são bons exemplos, mas, além disso, sou cliente do Itaú desde que eles adquiriram as operações do BankBoston no Brasil em 2006 e faço tudo o que preciso de um banco usando seus canais digitais. Outro bom exemplo é a Lopes consultoria de Imóveis. A Lopes é a maior imobiliária do Brasil, empresa fundada em 1935 que fez uma oferta de follow-on na bolsa de valores no final de 2019 para arrecadar fundos para investir em sua transformação digital. Trabalhei na Lopes entre 2020 e 2022 liderando essa transformação digital e aprendendo muito nessa jornada. Nesse período conseguimos passar de 40% das vendas vindas do digital para mais de 55% das vendas totais. Conseguimos construir produtos digitais para resolver os problemas não só das pessoas que queriam comprar uma casa, mas também das pessoas que queriam vender uma casa como avaliação de imóveis baseada em data science e dos corretores, que receberam leads melhores, mais alinhados com sua experiência e conhecimento, aumentando sua taxa de conversão. Então podemos dizer que tanto o Itaú quanto a Lopes são empresas digitalmente maduras.

Maturidade digital é um conceito que se aplica apenas a empresas tradicionais?

Podemos pensar que discutir a maturidade digital da empresa só faz sentido quando estamos falando de empresas tradicionais. Afinal, empresas tradicionais nascidas digitais, bem como empresas puramente digitais, são digitais, certo?

Errado! Vou dar 3 exemplos que mostram que empresas tradicionais nascidas digitais e empresas digitais podem sim ter baixa maturidade digital:

  • Gympass: quando entrei no Gympass, em meados de 2018, a empresa já contava com 800 funcionários, e atuação em 14 países. No entanto, toda a sua equipe de desenvolvimento de produto, incluindo engenheiros, designers de produto e gestoras de produto, tinha apenas 30 pessoas, ou seja, menos de 4% da empresa estava focada desenvolvimento de produto. O impacto dessa equipe muito pequena em relação ao tamanho da empresa era que, naquela época, muitas das tarefas do dia a dia com clientes e parceiros tinham que ser realizadas manualmente. Por esse motivo o Gympass tinha uma equipe de operações enorme para dar conta de todas essas tarefas manuais. Quanto mais vendia, mais pessoas eram necessárias no time de operações. E o aplicativo ainda era uma versão webview. O C-level e o conselho reconheceram a necessidade de investir no digital para escalar a empresa, e essa equipe cresceu consideravelmente para cerca de 250 pessoas, que automatizaram muitas das tarefas de operações manuais e entregaram e evoluíram um aplicativo totalmente nativo. Este é um exemplo interessante de empresa tradicional nascida digital, que vende um benefício corporativo aos seus clientes para que eles possam oferecer aos seus funcionários acesso a uma rede de dezenas de milhares de academias e estúdios, e que possuíam uma maturidade digital baixa. Isso normalmente acontece quando os fundadores de uma empresa nascida digital que está usando o digital para melhorar um negócio tradicional têm pouca ou nenhuma experiência anterior com produtos digitais. Se não trouxerem algumas pessoas com essa experiência para a equipe de founders, há boas chances de que a maturidade digital dessa empresa seja baixa.
  • Locaweb: quando entrei na Locaweb em 2005, a empresa tinha cerca de 100 pessoas e a equipe de desenvolvimento de produto tinha cerca de 30 pessoas, o que é um bom tamanho. No entanto, o desenvolvimento de produto era feito de uma forma muito antiga, em cascata, com base em ideias de C-levels e de pedidos de vendas, sem conversa com o cliente. Lembro-me de preencher um PRD – Product Requirement Document – ​​com todos os requisitos para um novo produto que planejamos lançar com base nas ideias dos C-levels. Após preencher todos os detalhes, o que demorei 2 meses para fazer, entreguei para a engenharia que em 5 meses entregou o produto pronto. Fui testar o produto e descobri que uma funcionalidade esperada não estava lá. Verifiquei o PRD para ver se eu havia esquecido de incluir essa funcionalidade específica, mas não, não esqueci, estava lá. Então, conversando com os engenheiros, eles viram a documentação, não entenderam todos os detalhes da funcionalidade e, pela pressa de entregar, decidiram não incluir a funcionalidade. Então fica bem claro que nossa maturidade digital naquela época era bem baixa. Conseguimos evoluir e aumentar nossa maturidade digital ao longo dos anos, mas este é um bom exemplo de empresa digital, cujo produto vendido pela empresa é o software ou tecnologia desenvolvida pela equipe de desenvolvimento do produto, mas com baixíssima maturidade digital que foi melhorando ao longo dos anos.
  • Aurum: esta é a companhia de 2 bons amigos de faculdade. Formaram-se por volta de 1990 e, na época, criaram um produto para auxiliar os advogados no seu dia a dia. Como todo software da década de 1990, era um software on-premise, para ser instalado no computador de cada advogado. Mais tarde, lançaram uma versão cliente-servidor onde os advogados podiam trocar informações pelo sistema e o trabalho realizado por cada advogado era armazenado em um servidor local. Por volta de 2010 eles começaram a perceber a necessidade de migrar para a nuvem e eu os ajudei em um dos meus primeiros trabalhos de consultoria. Se você quiser se aprofundar na jornada de transformação digital deles, confira esta entrevista. A Aurum é outro bom exemplo de empresa digital, cujo produto vendido pela empresa é o software ou tecnologia desenvolvida pela equipe de desenvolvimento do produto, mas com baixa maturidade digital que melhorou ao longo do tempo.

Para melhorar sua maturidade digital, não importa se é uma empresa tradicional, digital ou tradicional nascida digital, essas empresas precisam:

  1. trazer pessoas com experiência digital, ou seja, experiência em trazer ao mercado produtos digitais que resolvam problemas dos clientes e alcancem os resultados esperados da empresa. Essas pessoas ajudarão a empresa a entender o potencial do uso de produtos digitais e ajudarão a desenhar uma estratégia para aproveitar plenamente esse potencial.
  2. ir atrás da educação para que pessoas sem a experiência adequada em produtos digitais possam aprender mais rápido. Podem ser livros, cursos, eventos, blogs, treinamentos in company. Este tema deve ser central, não só para as pessoas que trabalham diretamente na equipe de desenvolvimento de produtos, mas todas as outras áreas da empresa devem entender como o digital pode impactar positivamente a empresa e suas áreas.

Resumindo

  • Existem 3 tipos de empresas. Empresas digitais, onde o produto vendido pela empresa é o software ou tecnologia desenvolvida pela equipe de desenvolvimento do produto. Nas empresas tradicionais, o produto ou serviço vendido pela empresa provavelmente já existe há muitos anos sem a tecnologia. Empresas tradicionais nascidas digitais, onde o produto vendido pela empresa poderia existir sem a tecnologia, mas a tecnologia potencializa muito o produto. Esta é a natureza da empresa e não pode ser alterada.
  • Por outro lado, também podemos analisar uma empresa com base em sua maturidade digital, ou seja, sua capacidade de usar produtos digitais para entregar uma melhor experiência aos seus clientes e melhorar os resultados da empresa. Normalmente, as empresas tradicionais têm baixa maturidade digital, mas podem evoluir com o tempo. No entanto, mesmo as empresas tradicionais nascidas digitais e as empresas digitais também podem ter baixa maturidade digital como mostram os 3 exemplos: Gympass, Locaweb e Aurum.
  • Para melhorar sua maturidade digital, essas empresas precisam (1) trazer pessoas com experiência em desenvolvimento de produtos digitais e (2) buscar educação para que pessoas sem a experiência adequada em produtos digitais possam aprender mais rapidamente.

Advisor de líderes de produto

Tenho ajudado líderes de produto (CPOs, heads de produtos, CTOs, CEOs, tech founders, heads de transformação digital) a extrair mais valor e resultados de seus produtos digitais. Veja aqui como posso ajudar você e a sua empresa.

Newsletter

Escrevo reguIarmente sobre gestão de produtos, desenvolvimento de produtos, liderança de produtos digitais e transformação digital. Vc pode receber uma notificação por email sempre que eu publicar algo novo, sem depender dos algoritmos de notificação de redes sociais. Basta assinar minha newsletter.

Gestão de produtos digitais

Você trabalha com produtos digitais? Quer saber mais sobre como gerenciar um produto digital para aumentar suas chances de sucesso, resolver os problemas do usuário e atingir os objetivos da empresa? Confira meu pacote de gerenciamento de produto digital com meus 3 livros, onde compartilho o que aprendi durante meus mais de 30 anos de experiência na criação e gerenciamento de produtos digitais. Se preferir, pode comprar os livros individualmente:

Qual a diferença entre Gestão de Marketing de Produtos e Gestão de Produtos?

Fora da indústria de tecnologia e de software, é comum encontrar a função de marketing de produtos como uma das funções do gestor de produtos. Ou seja, a gestão de produtos é vista como parte do marketing. Tanto é assim, que o termo gestão de produtos na Wikipédia diz:

Gestão de Produtos na Wikipédia
Gestão de produtos é uma função do ciclo de vida organizacional de uma empresa que lida com planejar, orçar e divulgar um produto ou conjunto de produtos em todas as fases do ciclo de vida desse produto. Essa função é composta por duas funções, desenvolvimento de produtos e marketing de produtos, que são esforços diferentes mas complementares, com o objetivo de maximizar receita, participação de mercado e margens. O gestor de produtos é normalmente responsável por analisar as condições do mercado e por definir as funcionalidades de um produto.
Fonte: https://en.wikipedia.org/wiki/Product_management

Na indústria de tecnologia e de software, principalmente na indústria de produtos de software, essas funções, apesar de continuarem muito ligadas, são normalmente separadas. A gestão de produtos é responsável pela definição e desenvolvimento do produto, junto dos times de UX e de engenharia, enquanto a gestão de marketing de produtos é responsável por contar ao mundo sobre esse produto.

Gestão de Produtos

Para poder definir em detalhes o produto ou funcionalidade que vai ser desenvolvido, o gestor de produtos precisa conhecer muito bem os usuários de seu produto, seus problemas e necessidades. Com essa informação em mãos, ele pode dizer em detalhes como ele deve ser. Com a ajuda de um designer de interação, eles podem desenhar como ele será, e como vai resolver o problema ou atender à necessidade dos usuários.

Dá para imaginar que, ao longo do processo de definir e implementar a definição, muitas decisões terão de ser tomadas pelo gestor de produtos, que é responsável por fazê-lo pensando sempre no que é melhor para o seu usuário, para que ele atinja seus objetivos com aquele produto, e para a empresa que é dona do produto, que também tem seus objetivos. O produto é uma forma de a empresa atingir esses objetivos, como foi explicado no capítulo Crescimento: o que é um roadmap?.

Gestão de Marketing de Produtos

Para poder contar ao mundo sobre o produto, o gestor de marketing de produtos precisa também conhecer os seus usuários, seus problemas e necessidades. Esse conhecimento é fundamental para ajudar o gestor de marketing a definir o conteúdo e a forma de sua mensagem sobre o produto.

Outro elemento importante para ajudar a definir essa mensagem é o conhecimento do mercado onde o produto está inserido, ou seja, quais são os competidores que têm produtos similares, e quem tem produtos que, mesmo não sendo similar ao seu, podem substituí-lo. Quais os diferenciais do seu produto em relação a esses outros? Quais os diferenciais deles em relação ao seu? Por que seus usuários devem escolher o seu produto, e não os concorrentes? Essas são as questões com que o gestor de marketing de produtos tem de se preocupar.

Gestão de Marketing de Produtos e Gestão de Produtos

Apesar de as funções serem bem distintas, existem muitas áreas de contato e até mesmo muita sobreposição. Em 1960, Edmund Jerome McCarthy, um professor de marketing da Universidade do Estado de Michigan, propôs o conceito de Marketing Mix, popularizado por Philip Kotler, que é um conjunto de ferramentas usadas pela função de marketing, com os famosos 4 Ps:

  1. Produto (product): diz respeito ao produto em si e como ele resolve um problema ou atende a uma necessidade de um conjunto de pessoas.
  2. Preço (price): por qual preço esse produto será vendido. Aqui não estamos falando apenas do preço de tabela, mas também do preço de lançamento promocional, desconto para revendedores e assim por diante. Ou seja, todos os preços e condições de preços do produto.
  3. Promoção / divulgação (promotion): de que forma vamos contar ao mundo sobre esse produto, e como ele é capaz de resolver o problema ou atender à necessidade de um conjunto de pessoas. Quando pensamos em promoção, a primeira ferramenta que nos vem à mente é a propaganda. No entanto, existem muitas outras ferramentas, como webinars, eventos e até nomes. O nome do produto, ou funcionalidade, é uma ferramenta de promoção muito importante, especialmente ao considerarmos que as pessoas pesquisam produtos nos mecanismos de pesquisa.
  4. Praça/canal(place):ondeesseprodutoserádisponibilizado e vendido. Pela web? Somente através da equipe de vendas? Revendedores? Uma combinação das 3 opções? Incorporado ao produto de outra pessoa?

O produto é claramente de responsabilidade do gestor de produtos, mas isso não quer dizer que o gestor de marketing não possa acompanhar o processo do seu desenvolvimento. Aliás, acompanhar esse processo dará ao gestor de marketing de produtos muitos elementos importantes para ajudar a contar ao mundo sobre ele.

Em algumas empresas, o gestor de produtos é responsável pela definição de preço, mas normalmente essa definição, bem como a definição das condições comerciais, é de responsabilidade do gestor de marketing de produtos. Este deve trabalhar junto com o gestor nessas definições, uma vez que ele tem muita informação que pode ajudar nelas e que englobam não só definir o preço como também se haverá versões mais caras ou mais baratas, ou mesmo se haverá funcionalidades adicionais pagas. O conhecimento do cliente e de quanto ele valoriza a solução do seu problema, ou o atendimento de sua necessidade, são essenciais para a definição do preço e das condições comerciais.

A definição da forma e do conteúdo da divulgação do produto, que inclui também definir o nome, é de responsabilidade do marketing de produtos, assim como a definição dos canais de venda, isto é, por onde o produto vai ser vendido: pela web, pela força de vendas, por canais de vendas, ou uma combinação dessas 3 formas.

Assim, usando os 4 Ps do Marketing Mix, poderíamos ilustrar essa divisão de responsabilidades da seguinte forma:

4 Ps e a divisão de responsabilidades

Métricas Compartilhadas

Falei bastante sobre métricas desde o capítulo Crescimento: seja um “data geek” até o capítulo Crescimento: considerações sobre métricas. Todas as métricas discutidas nesses 4 capítulos serão compartilhadas entre o gestor de produtos e o gestor de marketing de produtos.

O gestor de produtos deve ter um foco grande nas métricas relacionadas ao uso do produto, tais como NPS, churn e engajamento. Já o de marketing terá um foco maior nas métricas de receita, como CAC, LTV, receita e novas vendas. O importante é saber que o gestor de produtos e o de marketing de produtos têm focos distintos, mas as métricas são compartilhadas. Isto é, o gestor de marketing também deve acompanhar e se preocupar com as métricas de engajamento, assim como o gestor de produtos deve acompanhar e se preocupar com as métricas de receita.

Concluindo

Como visto ao longo deste capítulo, gestão de marketing de produtos e gestão de produtos são funções bem distintas, sendo a primeira responsável por definir como o produto será comercialmente oferecido e contar ao mundo sobre ele, enquanto a segunda tem a responsabilidade de definir em detalhes como ele será. Apesar de serem bem distintas, elas devem trabalhar muito juntas, pois o trabalho de uma é o insumo do trabalho da outra (e vice-versa).

Como comentei ao longo do livro, o core team do produto é um time multidisciplinar, contendo o trio de funções gestor de produtos, pessoas de UX e engenheiros. Na Locaweb, inserimos um quarto elemento a esse time: as pessoas de marketing de produtos, para que elas participem do processo de seu desenvolvimento, dando seus inputs, e tirem daí mais alguns elementos que serão úteis para fazer sua função de comunicar ao mundo sobre ele.

Ao entrar na Conta Azul, percebi que, apesar de haver marketing, não havia marketing de produtos e foi fácil perceber a falta que essa função faz no desenvolvimento de produto. Certa vez, antes de termos pessoas fazendo o papel de marketing de produtos, havia a intenção de desenvolver um aplicativo para o pequeno empresário tirar fotos de seus documentos fiscais e enviar para seu contador poder guardar na contabilidade da empresa.

Cada pessoa com que eu falava se referia a esse software com um nome diferente. Gerenciador de Arquivos, Gerenciador de Documentos, Troca de Arquivos foram alguns dos nomes que encontrei. O nome é uma ferramenta de comunicação que o gestor de marketing de produtos tem para comunicar ao mundo sobre o seu produto. Um nome mais autoexplicativo ajuda o cliente a entender o novo produto e pode facilitar bastante o SEO.

No Gympass, sentimos a mesma necessidade e contratamos recentemente profissionais de marketing de produto, que se reúnem com os gestores de produto e ajudam a informar o mundo, externo e interno, sobre as novas funcionalidades.

Minha recomendação é que você mantenha essas funções separadas – tendo pessoas distintas cuidando dessas duas funções, mas as mantenha trabalhando perto, uma vez que a colaboração entre elas é muito benéfica para o produto, para o time que o desenvolve e para toda a empresa.

Advisor de líderes de produto

Tenho ajudado líderes de produto (CPOs, heads de produtos, CTOs, CEOs, tech founders, heads de transformação digital) a extrair mais valor e resultados de seus produtos digitais. Veja aqui como posso ajudar você e a sua empresa.

Newsletter

Escrevo reguIarmente sobre gestão de produtos, desenvolvimento de produtos, liderança de produtos digitais e transformação digital. Vc pode receber uma notificação por email sempre que eu publicar algo novo, sem depender dos algoritmos de notificação de redes sociais. Basta assinar minha newsletter.

Gestão de produtos digitais

Este artigo é mais um capítulo do meu livro Gestão de produtos: Como aumentar as chances de sucesso do seu software, onde falo sobre o que é gestão de produtos digitais, seu ciclo de vida, que ferramentas utilizar para aumentar suas chances de sucesso. Você também pode se interessar pelos meus outros dois livros:

UX e Gestão de Produtos

A próxima área que quero comentar é a área de UX que, junto com engenharia e gestão de produtos, forma o core team de desenvolvimento de produtos.

O que é UX?

Experiência do Usuário

A “experiência do usuário” engloba todos os aspectos da interação do usuário final com a empresa, seus serviços e seus produtos. Fonte: Nielsen Norman Group – The Dinifition of User Experience – 2015.

Essa é uma definição bastante simples, mas ela realmente contempla todos os aspectos de UX. Quem trabalha com software tem a tendência de achar que UX é a interface do software, tanto do ponto de vista do planejamento da interação do usuário com o software quanto do ponto de vista visual. Sim, UX é isso, mas não é só isso. UX também se preocupa com o que esse software causa para quem o usa.

De acordo com a ISO 9241-210, intitulada Ergonomia da interação humano-sistema, que fornece orientações sobre a interação humano-sistema durante todo o ciclo de vida de sistemas interativos:

Experiência do Usuário

Experiência do usuário são “as percepções de uma pessoa e as respostas que resultam do uso ou uso antecipado de um produto, sistema ou serviço.” De acordo com a definição ISO, experiência do usuário inclui todas as emoções dos usuários, crenças, preferências, percepções, respostas físicas e psicológicas, comportamentos e realizações que ocorrem antes, durante e após o uso. A ISO também lista três fatores que influenciam a experiência do usuário: o sistema, o usuário e o contexto de uso. Fonte: Wikipedia.

UX no Processo de Desenvolvimento de Produtos

No processo de desenvolvimento de produtos, UX é o responsável por entender a fundo o usuário e o problema que se deseja resolver para esse usuário. A figura a seguir ilustra bem o papel de UX bem como o de engenharia de produtos e o de gestão de produtos, no processo de desenvolvimento.

Gestão de produtos de software

Na fase de concepção do produto, UX tem um papel central. O primeiro passo é entender o usuário, a pessoa que vai usar o produto de software. Para isso, UX utiliza uma ferramenta chamada persona, que representa um grupo de usuários com padrões de comportamento, atitudes e motivações similares em termos de decisão de compra, de uso de tecnologias ou produtos, de estilo de vida etc.

As personas são usadas para:

  • Conhecer e entender clientes e usuários de produtos e serviços;
  • Trazer o usuário para o foco do projeto;
  • Tornar as decisões de design mais humanas e menos abstratas.

No capítulo Crescimento: o que é e como criar a visão e a estratégia do produto? descrevi o processo de criação das personas, por serem ferramentas muito úteis na criação de sua visão de produto. Lembra da Maria, a descolada e da Michelle, a ocupada?

Baseado em muita pesquisa para entender a fundo os problemas e necessidades dessas personas, o UX constrói o protótipo que começará a materializar a ideia do produto. Esse protótipo deverá ser usado nas conversas com clientes e usuários, para validar se a ideia faz sentido, como também nas conversas com o time de engenharia de produtos, para que eles já possam entender o que vem pela frente e se há tecnologia disponível para fazer.

É muito diferente ouvir a descrição de um produto ou funcionalidade com, por exemplo: “Você vai ver uma tela com login e senha, e um botão de entrar. Também verá um link caso você tenha esquecido sua senha”; e ver a tela onde essa funcionalidade acontece. A primeira versão pode ser um desenho em papel ou em quadro branco:

Exemplo de protótipo de papel
Exemplo de protótipo de papel
Exemplo de protótipo de papel

O protótipo também é muito importante como ferramenta de comunicação com a engenharia de produtos. Mostrando o protótipo, fica mais fácil para os engenheiros avaliarem a dificuldade de implementação de cada funcionalidade.

Quando fiz o ContaCal, como minhas habilidades de desenho não são as melhores, optei por usar o PowerPoint como minha ferramenta para desenhar o protótipo:

Protótipo do ContaCal
Protótipo do ContaCal
Protótipo do ContaCal
Protótipo do ContaCal

Depois de acordadas as funcionalidades básicas, esse protótipo pode ser feito em computador. A primeira versão do protótipo feita no computador é normalmente só em preto e branco, só com os contornos dos elementos. Essa versão é muitas vezes chamada de wireframe:

Exemplo de wireframe
Exemplo de wireframe

O próximo passo é o time de UX preparar um protótipo (ou wireframe) navegável, ou seja, um que já tenha o comportamento de interação para que vocês (gestor de produtos e analista de UX) possam mostrar para clientes e usuários, para que eles possam testar e interagir. Em seguida, o designer visual de UX começa a colocar cor e forma nessas telas, para transformá-las na versão que os usuários de fato verão.

Com um protótipo em mãos, é possível fazer testes de usabilidade para identificar problemas de usabilidade ou validar soluções de interface. Para fazer esse teste, convidam-se usuários para executar determinadas tarefas em seu protótipo. Durante o teste, é possível observar o comportamento do usuário ao realizar um conjunto de tarefas propostas, além de identificar as dificuldades e os motivos para algumas de suas decisões, ao interagir com o produto. O usuário é incentivado a verbalizar suas ações, opiniões e sensações para que, dessa forma, conheçamos o modelo mental criado por ele.

Esse protótipo servirá de guia para o time de engenharia desenvolver o produto. É a especificação do produto; mas lembre- se de que ela não é escrita em pedra. Por esse motivo, o time de UX não entrega o protótipo para você e para o time de engenharia, e depois vai fazer outra coisa. A pessoa de UX que desenhou o protótipo deve continuar junto com o gestor de produtos e com o time de engenharia enquanto ele estiver sendo desenvolvido para ajustar o protótipo (se necessário), descobrir melhorias e aproximar o time de engenharia das necessidades do usuário.

O que mais o pessoal de UX faz?

Outro ponto em que o pessoal de UX participa ativamente é na definição e acompanhamento das métricas. Como disse no capítulo Crescimento: o que é um roadmap?, todo item de um roadmap deve ter sua motivação e sua métrica. O designer de UX deve saber muito bem qual é essa motivação quando ele vai desenhar o protótipo, e deve trabalhar junto com o gestor de produtos e com o time de engenharia para definir qual(is) métrica(s) acompanhar para medir se a motivação foi atingida.

O profissional de UX também conversa muito com o usuário. Ele será seu principal companheiro nessas conversas e interações com o usuário, e vai estar sempre focado no que é melhor para o usuário. Seu papel será sempre colocar o resto do contexto, isto é, além de ser bom para o usuário, precisa ser bom para a empresa que é dona do software que vocês estão desenvolvendo.

Ele também deve criar padrões de interação. Não dá para, toda vez que for desenvolvida uma nova funcionalidade, desenhar do zero. É importante ter um padrão pronto. Na Locaweb, criamos o Locaweb Style, com nossos padrões de interação, e o publicamos como open source (http://opensource.locaweb.com.br/locawebstyle).

Qual é a relação entre UX e gestão de produtos?

Como comentei no capítulo anterior, o fato de o gestor de produtos ser responsável por definir o produto a ser feito, pode dar a impressão de que UX está subordinada à gestão. Essa é uma visão incorreta e, se as áreas entenderem como certa, as chances de o produto fracassar aumentam, pois pessoas que se sentem subordinadas têm menor comprometimento com o resultado. UX e gestão de produtos, assim como a engenharia de software, devem ser vistos como um time, sem relação de subordinação e funcionando como parceiros que colaboram para produzir o melhor produto possível.

O UX sempre “puxará a sardinha” para o lado do usuário, e sempre vai querer fazer o que for melhor para este tanto do ponto de vista de função (interação) quanto do ponto de vista de forma (visual). E isso é bom! Se o time de UX for um time bom, ele sempre estará “puxando essa sardinha”, da mesma forma que o time de engenharia estará “puxando a sardinha” para o lado técnico, propondo sempre o trabalho de reescrita. Caberá ao gestor de produtos defender os interesses da empresa, que é dona do software, e encontrar e propor um balanço entre essas necessidades.

Ah, e tem mais um ponto!

Assim como os engenheiros de produtos, alguns designers de UX acabam se tornando ótimos gestores de produtos. É importante ser capaz de perceber quando um designer está procurando “outra coisa para fazer” e dar a ele essa opção de carreira. Na Locaweb temos ótimos gestores de produtos que eram designer de UX. Em alguns casos acabaram se tornando gestor de produtos do próprio produto dos quais eram responsáveis por UX. Por outro lado, também existem alguns designers de UX que experimentam a gestão de produtos e não gostam.

Essa situação é menos comum de acontecer pois, diferentemente do engenheiro de produto, o designer de UX normalmente está acostumado a conversar bastante com o usuário e com as outras áreas relacionadas ao produto, por isso o trabalho de gestão de produtos não lhe é tão estranho. Mesmo assim, é preciso deixar a porta aberta para ele poder voltar a ser designer de UX, sem nenhum prejuízo para a sua carreira.

Product leadership advisor

I’ve been helping several product leaders (CPOs, heads of product, CTOs, CEOs, tech founders, and heads of digital transformation) extract more value and results from their digital products. Check here how I can help you and your company.

Gestão de produtos digitais

Este artigo é mais um capítulo do meu livro Gestão de produtos: Como aumentar as chances de sucesso do seu software, onde falo sobre o que é gestão de produtos digitais, seu ciclo de vida, que ferramentas utilizar para aumentar suas chances de sucesso. Você também pode se interessar pelos meus outros dois livros:

3 lições de transformação digital da Disney

Os resultados do segundo trimestre de 2022 da Netflix e da Disney mostraram a Disney com mais assinantes de streaming do que a Netflix. O gráfico abaixo mostra como os números evoluíram até esse incrível marco:

Número de assinantes da Disney e Netflix (fonte: EEAGLI)

Este é um caso interessante de uma empresa incumbente, a Disney, sendo capaz de enfrentar a concorrência de uma empresa de tecnologia disruptiva, a Netflix.

Durante minha carreira, e principalmente durante meus anos liderando iniciativas digitais no Gympass e na Lopes, tenho aprendido sobre o poder do digital para potencializar os resultados de uma empresa. Quando soube dos resultados da Disney em comparação com a Netflix, quis verificar se meus aprendizados se aplicam a essa situação, e parece que sim.

Lição 1: o produto digital não está no centro

Existem 3 tipos de empresas, como expliquei neste artigo, e resumo abaixo:

  • Digital: O produto vendido pela empresa é o software ou tecnologia desenvolvida pela equipe de desenvolvimento do produto. Locaweb, Conta Azul, AWS, Gmail, Instagram, etc.
  • Tradicional: O produto ou serviço vendido pela empresa provavelmente existe há muitos anos sem a tecnologia, mas a empresa está começando a entender como a tecnologia pode potencializar esse produto ou serviço que existe há vários anos. Bancos, companhias aéreas, empresas de mídia, etc.
  • Tradicional nascido digital: o produto vendido pela empresa poderia existir sem a tecnologia, mas a tecnologia aprimora muito o produto. Netflix, Youtube, Amazon, Nubank, etc.

Ao analisar Disney e Netflix estamos comparando empresas de 2 tipos diferentes, Disney como empresa tradicional e Netflix como tradicional nascida digital. Para esses tipos de empresas, a tecnologia e o produto digital não são o core business. São potencializadores do core business. Então, quando discutimos a transformação digital, precisamos ter especialistas em negócios junto com especialistas em tecnologia trabalhando juntos para descobrir como usar a tecnologia para potencializar o negócio. Não é tecnologia subordinada ao negócio, nem negócio subordinado à tecnologia. É uma colaboração.

Algumas empresas tradicionais erram ao querer colocar a TI subordinada ao negócio, o que já demonstrei em outro artigo que não funciona. Por outro lado, algumas empresas tradicionais nascidas digitais podem pensar que tecnologia é mais importante do que negócios, o que também é errado, e nos leva à lição 2.

Lição 2: a experiência do core business é tão importante quanto a experiência em tecnologia

A tecnologia é muito importante. Pode mudar a forma como fazemos negócios. Pode até “disruptar” a forma como fazemos negócios. A Blockbuster, que já foi líder em locação de vídeos, teve como uma das principais causas de sua falência a Netflix, uma empresa tradicional nascida digital.

Receita da Netflix e da Blockbuster entre 1998 e 2016

No entanto, a tecnologia por si só não é suficiente. Uma compreensão profunda do negócio também é necessária.

A Lopes é a maior imobiliária do Brasil, empresa fundada em 1935 que fez uma oferta de follow-on na bolsa de valores no final de 2019 para arrecadar fundos para investir em sua transformação digital. Trabalhei na Lopes entre 2020 e 2022 liderando essa transformação digital e aprendendo muito nessa jornada. A Lopes é uma empresa tradicional, e está enfrentando a concorrência de 2 empresas tradicionais nascidas digitais muito bem financiadas chamadas QuintoAndar e Loft. Lopes tem muita experiência no mercado imobiliário. Tanto o QuintoAndar quanto a Loft tiveram que adquirir essa experiência. Ambos adquiriram empresas imobiliárias muito tradicionais para ganhar essa experiência no mercado imobiliário.

A Disney foi fundada em 1923 e tem MUITA experiência no mercado de mídia e entretenimento. Ter a capacidade de combinar essa experiência de negócios com experiência em tecnologia é um caminho certo para bons resultados, como foi para a Disney em seus esforços de streaming.

Lição 3: investimento em tecnologia leva tempo (e custa muito)

O investimento em tecnologia leva tempo, devido à incerteza tecnológica, como expliquei neste artigo com exemplos da Amazon e Nubank. Tanto a Amazon quanto o Nubank são empresas tradicionais nascidas digitais e entendem que investir em tecnologia leva tempo.

Para as empresas tradicionais é um pouco mais difícil aguentar tanto tempo investindo sem ter resultados claros. Essa incerteza deixa as pessoas de empresas tradicionais desconfortáveis, o que é natural. Para lidar com essa incerteza, as pessoas das empresas tradicionais precisam de sinais de que o investimento em tecnologia – que não é baixo – vai gerar resultados no longo prazo.

A Disney parece estar investindo em tecnologia de internet há algum tempo. Desde seu primeiro site em 1996:

O primeiro site da Disney, de 1996 (fonte: webarchive)

Em 1999, a Disney adquiriu a Infoseek, uma ferramenta de busca, e a Starwave, uma produtora de conteúdo para web, e começou a adquirir algum conhecimento sobre internet. Em 2015, a Disney lançou um serviço de streaming no Reino Unido chamado DisneyLife para testar o mercado de streaming. Durante 2016 e 2017, adquiriu a BAMTech, uma empresa de tecnologia de streaming. A ESPN, empresa adquirida pela Disney em 1996, lançou o ESPN+, um serviço de streaming, em 2018. A Disney adquiriu o Hulu, outro serviço de streaming, em 2019. Então, em novembro de 2019, foi lançado o Disney+ e, 2,5 anos depois, a Disney foi capaz de ter mais assinantes do que a Netflix em seus 3 serviços de streaming (Disney+, Hulu e ESPN+). Pode parecer uma empreitada de 2,5 anos, mas se considerarmos que a Disney investe em digital e internet desde 1996, são mais de 25 anos!!! E custa muito, só a aquisição da BAMTech foi de US$ 2,58 bilhões, fora todas as outras aquisições, salários e investimentos em infra-estrutura e ferramentas.

Resumindo

  • O recente relatório de resultados da Disney mostrou um número de assinantes de streaming maior que o da Netflix. Um caso interessante de um incumbente ser capaz de enfrentar a concorrência de uma empresa de tecnologia disruptiva, o que nos mostra algumas lições interessantes sobre transformação digital:
  • Lição 1: o produto digital não está no centro.
  • Lição 2: a experiência do core business é tão importante quanto a experiência em tecnologia.
  • Lição 3: investimento em tecnologia leva tempo (e custa muito).

Mentoria de líderes de produto

Tenho ajudado líderes de produto (CPOs, heads de produtos, CTOs, CEOs, tech founders, heads de transformação digital) a extrair mais valor e resultados de seus produtos digitais. Veja aqui como posso ajudar você e a sua empresa.

Gestão de produtos digitais

Você trabalha com produtos digitais? Quer saber mais sobre como gerenciar um produto digital para aumentar suas chances de sucesso, resolver os problemas do usuário e atingir os objetivos da empresa? Confira meu pacote de gerenciamento de produto digital com meus 3 livros, onde compartilho o que aprendi durante meus mais de 30 anos de experiência na criação e gerenciamento de produtos digitais. Se preferir, pode comprar os livros individualmente:

Quando definir, revisar e comunicar sua visão e estratégia de produto?

Alguns de meus clientes vêm trazendo a necessidade de discutir os temas de visão de produto, estratégia, estrutura de equipe e OKRs. Não apenas sobre como defini-los, mas também quando defini-los, revisá-los e comunicá-los.

O que são e como defini-los?

Não vou descrever novamente o que são e como defini-los. Em vez disso, fornecerei links para artigos anteriores que fornecem essas informações:

Uma coisa que não deixei claro nesses artigos é a sequência que essas coisas devem ser construídas. Então aqui está, primeiro precisamos definir nossa visão de produto. Sem uma visão clara do produto, ou seja, o que imaginam os que o produto será no futuro, visão essa que todos concordam ser a correta, é muito difícil fazer todo o resto. Com a visão do produto em mãos, podemos trabalhar na definição tanto dos objetivos estratégicos quanto da estrutura da equipe. Essas definições podem ser feitas em paralelo, pois o andamento de uma dá o insumo para a definição da outra e vice-versa. Com os objetivos estratégicos e a estrutura da equipe definidos, é hora de definir os OKRs, que serão definidos pelas equipes que agora sabem quais são os objetivos estratégicos que precisam alcançar. Em uma imagem:

Processo para definir visão, estratégia, estrutura e OKRs.

Quando definir, revisar e comunicar?

A imagem acima já dá algumas pistas sobre quando revisar OKRs e objetivos estratégicos, mas na tabela abaixo eu entro em mais detalhes sobre quando definir, revisar e comunicar sua visão de produto, estratégia, estrutura de time e OKRs. Tenho refinado esse processo desde a Locaweb e tenho aconselhado meus clientes a adotar uma abordagem semelhante.

Quando definir, revisar e comunicar sua visão de produto, estratégia, estrutura de equipe e OKRs.

Esse é o processo que uso sempre que me junto a uma nova empresa, seja full-time, seja em um trabalho de advisoring.

Resumindo

  • Já falei bastante sobre visão de produto, estratégia, estrutura de equipe e OKRs, sobre o que são e como defini-los.
  • Uma coisa que não deixei claro nesses artigos anteriores é a sequência que essas coisas devem ser construídas. Então aqui está, primeiro precisamos definir nossa visão de produto. Com a visão do produto em mãos, podemos trabalhar na definição tanto dos objetivos estratégicos quanto da estrutura da equipe. Com os objetivos estratégicos e a estrutura da equipe definidos, é hora de definir os OKRs, que são definidos pelas equipes que agora sabem quais são os objetivos estratégicos que precisam alcançar. A imagem no artigo resume melhor do que este parágrafo.
  • A outra coisa que não deixei claro nesses artigos é quando definir, revisar e comunicar sua visão de produto, estratégia, estrutura de equipe e OKRs. Novamente, a imagem no artigo tem uma tabela que resume melhor do que qualquer parágrafo que eu pudesse escrever, então não vou fazer o resumo aqui. (=

Mentoria de líderes de produto

Tenho ajudado líderes de produto (CPOs, heads de produtos, CTOs, CEOs, tech founders, heads de transformação digital) a extrair mais valor e resultados de seus produtos digitais. Veja aqui como posso ajudar você e a sua empresa.

Gestão de produtos digitais

Você trabalha com produtos digitais? Quer saber mais sobre como gerenciar um produto digital para aumentar suas chances de sucesso, resolver os problemas do usuário e atingir os objetivos da empresa? Confira meu pacote de gerenciamento de produto digital com meus 3 livros, onde compartilho o que aprendi durante meus mais de 30 anos de experiência na criação e gerenciamento de produtos digitais. Se preferir, pode comprar os livros individualmente:

Engenharia e gestão de produtos

Como o gestor de produtos deve se relacionar com as diferentes áreas da empresa? Engenharia, UX, marketing de produtos, gestão de projetos, operações, vendas, jurídico, financeiro, atendimento, recursos humanos e administrativo.

Relembrando o que falei no capítulo Principais características de um gestor de produtos, a caraterística mais importante que todo gestor de produto precisa ter é a empatia, ou seja, a capacidade de se colocar no lugar de outra pessoa para compreender seus anseios, motivações, necessidades e problemas. Essa característica deve ser usada não somente com o cliente do produto como também com as pessoas das diferentes áreas da empresa.

Como dito, o gestor de produtos deve entender o impacto que seu produto tem no trabalho do jurídico: será que aumentaram os problemas jurídicos devido a alguma funcionalidade nova no produto? E quanto à equipe de vendas, suporte, operações, financeiro, marketing, será que o novo produto complicou muito a vida deles? E em relação ao time do produto, os engenheiros e os analistas de UX que fazem parte do core team do produto, como as suas decisões em relação ao produto, qual o impacto em suas funções?

É o que veremos neste e nos próximos artigos!

Engenharia e gestão de produtos

Vou começar falando sobre a relação entre engenharia de produto e gestão de produtos.

Definição

Engenharia de produto é responsável por desenvolver o produto e mantê-lo operando. Com a visão de negócios trazida pelo gestor de produto, mais o desenho de solução feito pelo pessoal de UX – baseado no entendimento da necessidade ou do problema do cliente –, a engenharia de produto “constrói” o produto.

Para construí-lo, ela deve não só fazer a programação como também definir sua arquitetura técnica. Ou seja, qual é a infraestrutura onde ele rodará, qual a linguagem de programação mais adequada, qual o banco de dados mais apropriado, como garantir os requisitos não funcionais desse produto (velocidade de resposta, disponibilidade, escalabilidade etc.). Deve também validar com o gestor de produtos se o custo dessa infraestrutura cabe no seu modelo de negócio.

Gestão de produtos de tecnologia

O fato de o gestor de produto ser responsável por definir o produto a ser feito pode dar a impressão de que a engenharia de produtos está subordinada à gestão de produtos. Entretanto, essa visão é incorreta e, se as áreas se comportarem dessa forma, a chance de fracasso do produto aumenta, pois quem se sente subordinado tem menos comprometimento com o resultado.

Engenharia de produtos, gestão de produtos e UX são um time, não há relação subordinação entre nenhum desses grupos. Eles devem funcionar como parceiros e sócios, cada um com sua especialidade e responsabilidade, colaborando para produzir o melhor produto possível.

Inovação

No diagrama anterior, a engenharia de produtos é quem traz a tecnologia disponível. Como expliquei no capítulo Inovação: o que é inovação?, inovar não é simplesmente conhecer a última tecnologia. É preciso conhecer não só esta como também todas as tecnologias disponíveis, e saber como usá-las. Esse é o papel da engenharia de produtos. A oportunidade e o potencial de produzir uma inovação estão em conhecer as tecnologias disponíveis e saber como utilizá-las para resolver um problema, ou atender a uma necessidade de um grupo de pessoas.

Dicas práticas para gestores de produto

Para facilitar o dia a dia com o time de engenharia de produto, aqui vão algumas dicas práticas:

  • Não se meta na solução técnica, a não ser que você tenha conquistado o direito de se meter. Um gestor de produto deve ter algum conhecimento técnico sobre seu produto, mas essa não é sua área de especialidade. Os especialistas estão na equipe de engenharia de produto. Por isso, evite apresentar soluções técnicas para o time de engenharia a não ser que esse time dê abertura para isso.
  • Leve engenheiros nas conversas com clientes e usuários. Como parte do seu cotidiano como gestor de produto, você deve conversar sempre com seus clientes e usuários para entender como seu produto resolve os seus problemas ou atende às suas necessidades, e como você pode fazê-lo ficar ainda melhor. Os engenheiros gostam muito de ir a essas conversas. Para eles, é uma experiência muito bacana ver pessoas reais usando um software que eles desenvolveram. Eles ficarão ainda mais engajados na missão de fazer um produto melhor.
  • Sempre tome decisões baseadas em dados. Quer seja dados de acesso e de uso do produto, ou dados de conversas com clientes e usuários, use dados para tomar suas decisões e apresente-os para o time. Isso dará maior consistência aos itens que você vai colocar no roadmap do seu produto.
  • Aprenda a tirar o excesso. Busque sempre o produto mínimo ou a funcionalidade mínima, ou seja, procure implementar o mínimo possível para atingir o seu objetivo de negócio.
  • Esteja presente. É fundamental estar junto com o time de engenharia de produto ou, pelo menos, acessível ao time o máximo de tempo possível. Durante o desenvolvimento do produto, inevitavelmente surgirão dúvidas e, se você não estiver presente, ou o time para, ou vai implementar como eles acham que deve ser, o que pode ser diferente do que você havia planejado.
  • Dê feedback para o time sobre o produto. Você, como gestor de produto, sabe como o seu produto está indo, quantos usuários tem, o que esses usuários estão achando dele, como esse produto está ajudando a empresa a atingir seus objetivos etc. Conte periodicamente sobre isso para o time de engenharia do produto. Como isso, você estará dando um contexto e um propósito para o time.
  • Negocie as histórias de reescrita e de manutenção. O time de engenharia, se for um time bom – antenado na evolução das boas práticas de engenharia de software e acompanhando sempre o que há de novo no desenvolvimento de sistemas –, sempre vai descobrir formas melhores de implementar cada pedaço do produto. Se depender do time de engenharia, o backlog do produto só terá histórias de melhoria técnica. Isso é bom, mostra que você está trabalhando com um ótimo time. Contudo, você deve usar o item anterior para dar o contexto do produto para o time, ou seja, mostrar que há determinados objetivos definidos para o produto, que vocês têm de atingir e que, por isso, vocês devem sempre colocar novas funcionalidades nele. Deve existir um balanço entre histórias de manutenção e reescrita e de novas funcionalidades. Já li em vários lugares algo como: defina X% do tempo para histórias de manutenção e reescrita. Eu não gosto de dar essa sugestão, pois acredito que cada momento do produto requer um equilíbrio diferente, e cabe ao gestor de produto e ao seu time de engenharia conversar e definir de comum acordo esse equilíbrio apropriado a cada fase. Vale lembrar da importância de encontrar um bom equilíbrio, pois isso evitará o famoso débito técnico que, à medida que cresce, fará com que o time de engenharia de produto fique cada vez mais lento.

Não dá mais, precisa reescrever tudo…

Já ouvi essa frase várias vezes ao longo da minha carreira. Quem trabalha com desenvolvimento de software sabe que invariavelmente chega um momento em que aparece essa discussão que normalmente tem frases como: está cada vez mais difícil mexer no código; se fosse fazer do zero, seria muito mais rápido; se não reescrevermos, vai ficar cada vez mais lento e perigoso mexer no código.

Na Locaweb, tínhamos o produto de Email Marketing, para envio e gerenciamento de campanhas de e-mail marketing, que usava como base de dados o MongoDB, uma base de dados não relacional conhecida por sua capacidade de armazenar grandes bases de dados. Contudo, provavelmente devido à nossa pouco experiência em desenvolvimento de software usando esse tipo de base de dados e em administrar bases de dados não relacionais, à medida que essa base crescia, o sistema ficava cada vez mais lento.

Por isso foi necessário reescrever o produto para usarmos PostgreSQL. Desenhamos essa reescrita de forma a ser transparente para os clientes. Isto é, o cliente não ia ser migrado de uma base de dados para outra, evitando assim passar por um período de indisponibilidade ou eventual perda de dados. A reescrita foi um sucesso. O processo todo de reescrita, incluindo colocar todos os clientes existentes (mais de 15.000) na nova base de dados, permitindo desligar a base de dados MongoDB, levou seis meses, um prazo razoável para uma iniciativa desse tamanho.

Entretanto, durante esses seis meses, o time não entregou nada novo para o cliente. Nenhuma nova funcionalidade. Para diminuir a frustração de nossos clientes, decidimos por contratar uma empresa terceirizada para construir aplicativos para iOS e Android em cima das APIs existentes do produto. Com isso, conseguimos entregar novas funcionalidades para nossos clientes enquanto o time de produto ficava focado na reescrita. Se essa opção não existisse, teríamos de encontrar outras formas de entregar valor para o usuário que não dependessem do time de engenharia.

Se você trabalha com desenvolvimento de software, tenha certeza de que, se ainda não passou por essa situação em sua carreira, certamente passará. O problema de reescrever software é que, ao reescrevê-lo, o time deixa de fazer coisas novas para o seu usuário, como mostrei no exemplo do produto de Email Marketing da Locaweb. Ou seja, do ponto de vista de negócio, o software não evolui, o cliente não vê evolução, e pode perder o interesse pelo seu produto passando a procurar opções melhores no mercado. Por isso gostaria de tecer algumas considerações sobre o tema:

  • Tecnologias novas e melhores vão aparecer sempre. Antigamente desenvolvia-se sistemas com tudo em um código só. Depois foi o conceito de MVC (model, view, controller) separando o código do software em camadas de acordo com sua função. Mais recentemente, foi criado o conceito de microsserviços, quebrando a aplicação em aplicações pequenas, conectadas com baixo acoplamento, feito preferencialmente via APIs e facilitando a manutenção. Se a cada nova tecnologia que aparecer formos reescrever o software, certamente não faremos outra coisa senão reescrever software.
  • Reescrever software tem de ter uma motivação clara de negócio, ou seja, de alguma forma deve atender aos objetivos estratégicos da empresa que é dona do software como deve atender às necessidades ou resolver um problema dos clientes. Se não houver uma motivação clara de negócio, a recomendação é não reescrever.
  • Se reescrever for inevitável (tem certeza?), é importante pensar nessa iniciativa de reescrita do ponto de vista de negócios, isto é, qual é o impacto dessa reescrita para os clientes e para o dono do software. Entender isso é responsabilidade do gestor de produtos. Algumas perguntas para te ajudar a refletir junto com o time sobre esse impacto:
    • Como será essa reescrita?
    • Enquanto a reescrita estiver acontecendo, vão ser entregues novas funcionalidades?
    • Como será a coexistência do sistema novo com o sistema velho?
    • Quando forem implementadas novas funcionalidades, serão implementadas no sistema novo e no sistema velho, ou só no sistema novo?
    • Quando novos clientes poderão ser instalados no sistema novo?
    • Quando os clientes existentes serão migrados para o sistema novo?
    • Se existir a proposta de fazer um sincronizador para que os dados dos clientes existam simultaneamente no sistema velho e no sistema novo, qual é o custo dessa proposta se comparado com a opção de não fazer esse sincronizador?
    • Se a diferença entre o sistema velho e o sistema novo puder ser percebida pelos clientes, como essa diferença será comunicada?

Pronto, aí estão algumas considerações sobre reescrita de software, um tema muito importante para qualquer gestor de produto.

Ah, e tem mais um ponto!

Alguns engenheiros de produto acabam se tornando ótimos gestores. É importante ser capaz de perceber quando um engenheiro está procurando “outra coisa para fazer”, e dar a ele essa opção de carreira.

Na Locaweb, temos (e tivemos) ótimos gestores de produto que eram engenheiros de produto. Em alguns casos, acabaram se tornando gestores do próprio produto em que era engenheiro. Por outro lado, existem alguns engenheiros de produto que experimentaram a gestão de produtos e não gostaram.

Para quem está acostumado a medir sua produtividade por funcionalidades entregues, pode ser estranho no começo perder essa referência de produtividade. Como já vimos, o dia a dia de um gestor de produto é composto de muita conversa com as várias pessoas envolvidas nele, e esse monte de conversa pode “assustar” o engenheiro que está acostumado a trabalhar focado no desenvolvimento de funcionalidade. Por isso, é preciso deixar a porta aberta para ele poder voltar a ser engenheiro de produto, sem nenhum prejuízo para a sua carreira.

Gestão de produtos digitais

Este artigo é mais um capítulo do meu livro Gestão de produtos: Como aumentar as chances de sucesso do seu software, onde falo sobre o que é gestão de produtos digitais, seu ciclo de vida, que ferramentas utilizar para aumentar suas chances de sucesso. Você também pode se interessar pelos meus outros dois livros:

Qual o tamanho ideal de time?

No capítulo sobre estrutura de time do meu livro Liderança de produtos digitais, dei alguns exemplos reais de tamanho de equipe do Gympass, Conta Azul e Locaweb. No entanto, uma coisa que não está nesse capítulo é como definimos o tamanho ideal do time. Então, aqui está um artigo focado neste tópico, que acredito pode ser útil não apenas em tempos regulares, mas também agora que o financiamento de VCs parece estar diminuindo e as avaliações das empresas estão mais baixas.

Benchmark

Quando entrei no Gympass em 2018, a empresa já tinha 800 pessoas, mas a equipe de desenvolvimento de produto, ou seja, gerentes de produto, designers, engenheiros e pessoas de dados, eram apenas 32 pessoas, ou seja, 4% da empresa, o que parece bastante baixo. Logo depois que entrei na empresa, tive que apresentar ao conselho meu plano de aumentar essa equipe e decidi incluir um slide com um benchmark de algumas empresas de tecnologia conhecidas.

Benchamrk de tamanho de times de produto

Usei o Linkedin para obter algumas estimativas do tamanho da equipe de desenvolvimento de produtos dessas empresas em comparação com o número total de funcionários. A maioria está tendo entre 24% a 40% de sua força de trabalho na equipe de desenvolvimento de produtos. A exceção é a Apple, com 20%, mas precisamos considerar que eles são donos de todas as suas lojas físicas, então todos os vendedores dessas lojas também são seus funcionários. Conta Azul, Locaweb e Lopes são de minhas experiências passadas. A Lopes, uma imobiliária tradicional que trabalha em sua transformação digital, tinha cerca de 11% de sua força de trabalho em desenvolvimento de produtos. No Gympass conseguimos trazer de 4% em meados de 2018 para 18% no final de 2019.

O que fazer vs quanto investir

No entanto, não podemos definir o tamanho ideal da equipe apenas pelo benchmarking. Precisamos considerar outros fatores, de dentro da empresa:

  • o que fazer: a partir do objetivo da empresa e do entendimento dos problemas do usuário, criamos nossa visão e estratégia de produto. Ter isso claro nos ajuda a definir o que precisamos fazer para executar essa estratégia, quais resultados e objetivos queremos atingir, e a equipe necessária para executar essa estratégia. Por exemplo, no Gympass, fazíamos produtos para academias, RHs de clientes e seus funcionários, então decidimos ter equipes dedicadas a cada um desses participantes de nosso marketplace. Além disso, precisávamos de ferramentas para gerenciar os pagamentos recebidos dos RHs e funcionários, e que tínhamos que fazer para as academias, então também tínhamos uma equipe focada nisso. Eram o que chamávamos de equipes de produto, que geravam resultados para o Gympass como mais usuários e menos trabalho operacional manual. Além das equipes de produto, tínhamos também equipes estruturais para cuidar de temas como SRE, ferramentas comuns a todos os times de produto, Dados e Segurança, conforme expliquei no artigo sobre estrutura de times. Esses times de produto e estruturais tinham suas próprias visões e estratégias alinhadas com a visão e estratégia global, e com base nisso propuseram suas próprias estruturas de time. Por exemplo, no Gympass, a equipe focada no funcionário de nossos clientes decidiu se dividir em duas equipes, uma focada em crescimento, ou seja, ajudar os funcionários a saberem que a empresa oferece o Gympass, fazendo com que os funcionários baixem o aplicativo, criem uma conta e se inscrevam no serviço. A outra equipe estava focada na experiência digital, ou seja, ajudar o funcionário a tirar o máximo proveito do Gympass, encontrando e usando academias, atividades e aplicativos de bem-estar adequados. O que fazer é um dos direcionadores para definir a estrutura e o tamanho do time.
  • quanto investir: por outro lado, precisamos saber quanto estamos planejando investir nessa equipe. Montar uma equipe de desenvolvimento de produtos custa dinheiro. Suponha que com base no que definimos que queremos fazer, criamos uma estrutura de time de desenvolvimento de produto que requer 15 pessoas. Vamos considerar R$ 6.000 como salário médio mensal das pessoas de sua equipe. Considerando todos os encargos, 13º salário e férias, isso custaria pra a empresa R$ 9.600 por mês. Então o custo mensal total dessa equipe é de R$ 144.000 ou R$ 1.728.000 por ano. É muito dinheiro. Essa equipe trará resultados para a empresa, mas às vezes os resultados podem demorar para serem gerados. Em todos os novos produtos que construímos e lançamos, enquanto não lançamos e começamos a receber alguma receita, essa equipe só vai gerar custos. Temos dinheiro para investir todo mês para pagar os salários e encargos trabalhistas dessa equipe, enquanto ela não gerar os resultados? Note que aqui estou considerando somente salário, sem bônus e stock options.

Por isso, precisamos saber quanto podemos investir e o que precisamos fazer para definir o tamanho ideal da nossa equipe de desenvolvimento de produtos.

Tamanho da equipe em uma crise

Há algum tempo atrás, passamos pela crise do COVID-19 e agora estamos enfrentando uma crise econômica que está fazendo com que os investimentos dos VCs diminuam e façam valuations mais baixos do que tínhamos antes de 2022. Muitas startups estão tendo que fazer demissões por causa dessa situação. Até empresas como Google, Meta e Apple mencionaram que vão desacelerar as contratações.

Então, qual deve ser o tamanho do time de desenvolvimento de produtos em uma crise? Bem, nessa situação quanto investir é o fator a ser considerado. Precisamos reduzir o quanto investimos em nossa equipe de desenvolvimento de produtos? Quanto de redução? Qual o impacto dessa redução no que temos que fazer e nos resultados que podem ser gerados por essa equipe? Ter menos pessoas fará com que a equipe deixe cair algumas bolas, ou seja, é preciso tomar uma decisão sobre o que parar de fazer. Alguns objetivos e resultados devem ser despriorizados, pois teremos que demitir algumas pessoas e teremos uma equipe menor. É simples assim. Menos dinheiro implica em equipe menor, o que implica em menos coisas que essa equipe poderá fazer e, consequentemente, menos objetivos e resultados podem ser priorizados.

Resumindo

  • O benchmarking é uma boa maneira de entender o tamanho da equipe de desenvolvimento de produtos. Através do Linkedin, podemos obter boas estimativas do número de pessoas nas equipes de desenvolvimento de produtos em comparação com o número de funcionários de muitas empresas.
  • No entanto, também devemos olhar para fatores internos para definir o tamanho ideal da equipe de desenvolvimento de produto. Quanto temos para investir e o que precisamos fazer são os dois fatores internos a serem considerados.
  • Em situações de crise, podemos precisar diminuir o investimento na equipe de desenvolvimento de produtos, o que pode fazer com que o tamanho da equipe diminua. Menos dinheiro implica em equipe menor, o que implica em menos coisas que essa equipe poderá fazer e, consequentemente, menos objetivos e resultados podem ser priorizados.

Mentoria de líderes de produto

Tenho ajudado líderes de produto (CPOs, heads de produtos, CTOs, CEOs, tech founders, heads de transformação digital) a extrair mais valor e resultados de seus produtos digitais. Veja aqui como posso ajudar você e a sua empresa.

Gestão de produtos digitais

Você trabalha com produtos digitais? Quer saber mais sobre como gerenciar um produto digital para aumentar suas chances de sucesso, resolver os problemas do usuário e atingir os objetivos da empresa? Confira meu pacote de gerenciamento de produto digital com meus 3 livros, onde compartilho o que aprendi durante meus mais de 30 anos de experiência na criação e gerenciamento de produtos digitais. Se preferir, pode comprar os livros individualmente:

Gestoras de produto precisam saber codar?

Esta é um tema um tanto controverso.

Tenho visto alguns debates interessantes sobre este tema nos grupos do Linkedin e WhatsApp na comunidade de gestão de produtos, então quero compartilhar minha experiência sobre este tema. Já compartilhei como parte do capítulo “Feedback e avaliação de desempenho” do meu livro Liderança de Produtos Digitais, mas talvez possa ser útil como um artigo separado possa adicionar mais foco sobre o tema.

Deixe-me começar com um “disclaimer“. O fato de duas pessoas discordarem não significa necessariamente que uma delas esteja errada.

Dito isto, a resposta curta a esta pergunta é depende! (=

A necessidade de entender o tema do produto

A necessidade de uma gestora de produto saber codar depende do tema do produto que ela cuida. Se o que a gestora de produto cuida é um produto mais técnico, é muito importante que ela tenha uma formação técnica. Alguns exemplos de produtos da Locaweb que são técnicos e precisavam de uma gestora de produto com formação técnica são Hospedagem de Sites, Cloud Server e SMTP. No entanto, mesmo empresas que não vendem produtos técnicos podem ter uma parte de seu produto com um viés mais técnico. Na Conta Azul tivemos APIs, integrações com fintechs (Iugu e Stone) e integração com os sistemas do governo para emissão de notas fiscais, e no Gympass tivemos integração com sistemas de gestão de academias e sistemas de RH. Para essas partes dos produtos, é importante ter uma pessoa gestora de produto com conhecimento técnico, pois a principal usuária do produto será uma pessoa técnica e o objetivo do produto é um objetivo técnico.

Por outro lado, um produto como a Loja Virtual da Locaweb, o app do usuário do Gympass ou o portal de busca de imóveis da Lopes são produtos feitos para o consumidor em geral. Na minha experiência, não é essencial que a gestora de produto tenha conhecimento técnico se ela gerencia produtos não técnicos. Na Conta Azul também tínhamos produto para contadores. Nesse caso era muito importante que a pessoa gestora de produto entendesse de contabilidade, a ponto de alguns de nossas gestoras de produto serem contadoras e as que não eram, precisavam passar por cursos para aprender contabilidade. Algumas das pessoas gerentas de produto da minha equipe que construíram produtos para contadores fizeram Faculdade de Contabilidade e até trabalharam como contadores antes de fazer a mudança de carreira para gestão de produtos.

Então isso é fundamental, uma gestora de produto deve, deixe-me repetir isso, DEVE entender sobre o tema do produto que ele irá gerenciar. Se for um produto técnico, um produto para desenvolvedores, será muito benéfico que a gestora de produto saiba codar. Se for um produto para contadores, quanto mais ela souber sobre contabilidade, melhor.

A necessidade de saber codar

Se o produto não for para desenvolvedores, como mencionei anteriormente, tudo bem se a gestora de produto não souber codar. Ela pode ser uma gestora de produto incrível, alcançar resultados incríveis tanto para seus usuários quanto para a empresa dona o produto sem saber escrever uma linha de código sequer.

No entanto, saber codar pode ser útil. O conhecimento técnico ajuda uma pessoa gestora de produto a entender como o produto é feito e, provavelmente, pode ajudá-la a ser uma gestora de produto melhor. Esse conhecimento pode ajudar uma gestora de produto a entender o trabalho feito pela equipe de engenharia e pode ser útil em muitas decisões sobre o produto, incluindo decisões de priorização e escopo. Aqui vão duas analogias que podem ajudar a entender melhor o benefício que saber codar traz para uma gestora de produto:

  • Um bom piloto de Fórmula 1 não precisa saber como o carro funciona, mas se o fizer, certamente poderá usar esse conhecimento para ser um piloto melhor.
  • Da mesma forma, um guitarrista não precisa saber cantar ou tocar baixo, bateria ou piano para ser um bom guitarrista, mas provavelmente esse conhecimento adicional pode ajudá-lo a ser um melhor guitarrista.

O conhecimento adicional pode trazer insights interessantes para a pessoa gestor de produto quando ela está cuidando de seu produto

Isso não significa que a gestora de produto precisa ser uma especialista em programação. Se ela não tem conhecimento de programação, seria interessante fazer um curso introdutório de lógica de programação e experimentar fazer seu primeiro aplicativo. Essa experiência só beneficiará a carreira dessa pessoa.

E precisa saber SQL?

Se a pessoa gestora de produto ainda não sabe, ela deve aprender SQL. O acesso aos dados está cada vez mais democrático e conhecer SQL é essencial para que a gestora de produto possa usufruir dos dados de forma independente, sem precisar pedir a terceiros para criar seus gráficos e dashboards. Quando colocamos o Metabase como solução de democratização de dados na Conta Azul, fiquei tão empolgado que passei uma semana inteira indo dormir às 2h, pois estava criando gráficos e dashboards para entender melhor como os produtos da Conta Azul eram usados. Foi tão divertido! (=

Resumindo

  • O fato de duas pessoas discordarem não significa necessariamente que uma delas esteja errada.
  • O gerente de produto DEVE entender sobre o domínio do produto que gerencia. Se for um produto técnico, um produto para codificadores, será muito benéfico que o gerente de produto saiba codificar. Se for um produto para contadores, quanto mais ela souber sobre contabilidade, melhor.
  • Se o produto não for para codificadores, tudo bem se o gerente de produto não souber codificar. Ela pode ser uma gerente de produto incrível, alcançar resultados incríveis tanto para seus usuários quanto para a empresa que possui o produto sem saber codificar.
  • No entanto, o conhecimento técnico ajuda um gerente de produto a entender como o produto é feito e, provavelmente, pode ajudá-lo a ser um gerente de produto melhor. Da mesma forma que um piloto de Fórmula 1 não precisa conhecer mecânica, mas pode se beneficiar desse conhecimento durante suas corridas.
  • Se o gerente de produto ainda não sabe, ele deve aprender SQL. O acesso aos dados está cada vez mais democrático nas empresas e conhecer SQL é essencial para que o gerente de produto possa usufruir dos dados de forma independente, sem precisar pedir a terceiros para criar seus gráficos e dashboards.

Mentoria de líderes de produto

Tenho ajudado líderes de produto (CPOs, heads de produtos, CTOs, CEOs, tech founders, heads de transformação digital) a extrair mais valor e resultados de seus produtos digitais. Veja aqui como posso ajudar você e a sua empresa.

Gestão de produtos digitais

Você trabalha com produtos digitais? Quer saber mais sobre como gerenciar um produto digital para aumentar suas chances de sucesso, resolver os problemas do usuário e atingir os objetivos da empresa? Confira meu pacote de gerenciamento de produto digital com meus 3 livros, onde compartilho o que aprendi durante meus mais de 30 anos de experiência na criação e gerenciamento de produtos digitais. Se preferir, pode comprar os livros individualmente:

Fim de Vida

O seu produto de software pode ter chegado aqui por três caminhos diferentes:

  1. O crescimento do seu produto desacelerou, e você fez todas as análises e testes descritos no capítulo anterior para ter certeza de que ele, de fato, chegou à fase da maturidade.
  2. Ou,então,vocêlançouoseuprodutoenãoestáconseguindo cruzar o abismo que existe no fim da inovação, a primeira fase do ciclo de vida de seu produto de software.
  3. Ou ainda, você optou por uma maturidade programada, planejando o fim de vida da versão atual de seu produto de software em função de uma nova, que foi desenvolvida e lançada.

Independente do caminho seguido – maturidade não programada, não cruzar o abismo ou maturidade programada –, você eventualmente chegou ao que é conhecido como o fim de vida do produto. Em inglês, usa-se um termo mais elegante, o sunset do produto.

Assim como todas as fases anteriores, essa também terá de ser gerenciada. Engana-se o gestor de produtos que acredita que, quando um produto chega ao fim de vida, termina-se o trabalho de gestão de produtos. Ao contrário, essa fase requer tanta atenção quanto as anteriores.

O primeiro passo é reconhecer que chegou ao fim de vida, e um ótimo indicador é avaliar se o custo de manter o produto é maior que o retorno que ele dá. Se isso acontecer, existe um forte indicativo de que ele está entrando nessa fase.

Custo vs. retorno

A decisão pelo fim de vida de um produto não é científica. Os números ajudam bastante nessa decisão; porém, como explicado no capítulo Considerações sobre métricas, além das métricas, é preciso usar outras informações como a experiência, a intuição, o julgamento e as informações qualitativas para se tomar a decisão de fim de vida do produto.

Cada um dos três possíveis caminhos que seu produto pode ter feito para chegar ao fim de vida vai trazer consigo fatos e considerações específicas para essa tomada de decisão. Normalmente, ela feita em comitê, com as pessoas que trabalham com o produto e os executivos da empresa.

Caso seu produto tenha de fato entrado no fim de vida, o gestor de produtos precisará gerenciar essa fase. A decisão e seu gerenciamento dependem do caminho seguido por ele para chegar a ela, e é isso que vamos ver nas próximas seções.

Fim de Vida por Maturidade não Programada

Esse é o pior dos casos pois, além de não planejado – como é o caso do fim de vida após a maturidade programada –, é uma situação difícil de identificar. Antes de decretar que é o fim de vida do produto, é preciso ter certeza de que isso não é só temporário. O mais comum nesses casos é deixar o produto dormente por um tempo.

O que significa dormente? Significa não investir em seu desenvolvimento e marketing, e observar como ele se comporta. Ele parou de crescer? Ou ele cresce muito devagar? Faz sentido parar de vendê-lo? Ou pode-se deixar o produto sendo comercializado por mais algum tempo? Após algum tempo dormente, deve-se reavaliar se vale investir novamente nele.

Esse foi o caso do produto PABX Virtual da Locaweb, que decidimos deixar dormente por uns 3 anos, sem nenhum investimento de marketing e de desenvolvimento, para podermos investir em outros produtos. Mesmo sem nenhum investimento, a quantidade de clientes não diminuiu. Inclusive, em certos momentos, houve até um crescimento. Esse crescimento, quando acontecia, era bem pequeno, mas não deixava de ser um crescimento. Por esse motivo, decidimos voltar a investir no produto.

Outro exemplo, já comentado no capítulo anterior, foi o caso do produto Hospedagem de Sites da Locaweb que, por nos focarmos demais em métricas e desconsiderarmos nosso conhecimento empírico, acabou entrando em uma situação de não crescimento que, felizmente, pôde ser corrigido. Não era o fim da vida útil da hospedagem na web. Foi uma desaceleração do crescimento que causamos ao produto.

Por isso quero dizer novamente para se ter muito cuidado para não tomar uma decisão precipitada, pois o fim de vida por maturidade não programada é extremamente difícil de ser identificada.

Se você realmente tiver certeza de que seu produto chegou mesmo ao fim de vida, você precisará gerenciar essa fase. A primeira decisão que você deverá tomar, junto com o comitê que mencionei – composto por pessoas que trabalham com o produto e executivos da empresa –, é se você vai descontinuar o produto ou deixá-lo dormente. Essa decisão será baseada no retorno que ele estiver dando para a empresa e no custo de mantê-lo.

Se o produto ainda der um retorno considerável, é provável que vocês decidam por mantê-lo e façam esforços para reduzir o custo de manutenção. O gestor de produtos será o responsável por coordenar os esforços de redução de custo de manutenção, e por avaliar se esses custos estão menores do que o retorno que o produto dá.

Por outro lado, se o retorno desse produto for pequeno, ou seus custos operacionais forem muito grandes e não passíveis de redução, é provável que vocês optem por descontinuá-lo. Nesse caso, o gestor deverá coordenar todos os passos necessários para descontinuar o produto, que incluem:

  1. Definir a data de fim de vendas e executar;
  2. Verificar se há um substituto no portfólio de produtos da empresa ou no mercado;
  3. Se houver substituto, definir como um cliente poderá migrar para este substituto;
  4. Preparar a comunicação com os clientes, definindo prazos para o fim do produto;
  5. Testar essa comunicação com um grupo pequeno de clientes para avaliar impacto e fazer os ajustes necessários;
  6. Executar a comunicação com toda a base de clientes;
  7. Acompanhar e agir pontualmente, quando necessário.

Fim de Vida por não Cruzar o Abismo

Se seu produto entrar no fim de vida por não cruzar o abismo, apesar de essa não ser uma situação desejada pelo time de desenvolvimento, é uma situação importante que precisa ser identificada rapidamente, e o gestor de produtos tem papel fundamental para detectar isso.

Essa situação é mais fácil de ser detectada, pois o produto não cresce. Ele conquista alguns poucos clientes, os early adopters, e depois para de crescer. Nesse ponto, você deve avaliar junto com o gestor de marketing se a estratégia de comunicação do produto está sendo eficiente e se está atingindo as pessoas que têm o problema que o seu produto se propõe a resolver.

É importante também entender com os possíveis clientes se o produto não só resolve o problema como também como eles estão dispostos a lhe remunerar por esse produto. Sempre é possível fazer ajustes no produto e no seu modelo de comercialização para adequá-lo aos seus clientes.

Contudo, se mesmo após avaliar essas questões e tentar fazer ajustes no produto e/ou no seu modelo de comercialização, você não estiver conseguindo fazê-lo crescer, é hora de decretar seu fim de vida. Quanto antes você chegar a essa decisão, melhor, para não perder tempo e investimento em um produto que não vai vingar.

Nesse caso, como o produto tem uma base pequena de clientes, as opções de mantê-lo dormente por ter uma receita considerável não faz sentido. Sendo assim, a única decisão viável é descontinuar o produto. Como no caso do fim de vida por maturidade não programada, aqui também o gestor de produtos deverá coordenar todos os passos necessários para descontinuá-lo, que são os mesmos descritos anteriormente na seção Fim de vida por maturidade não programada.

Fim de Vida por Maturidade Programada

Essa é a melhor das três opções para o dono do software, mas é a que dará mais trabalho para o gestor do produto. No caso de software instalado, isso acontece quando novas versões são lançadas. Para software online, isso ocorre quando o time de desenvolvimento opta por reescrever o produto por algum motivo, e decide lançar uma nova versão. Essa decisão por reescrever um produto online deve ser muito bem pensada, pois o tempo gasto em reescrever seu produto é tempo não utilizado em sua evolução do ponto de vista de quem o usa.

Pode acontecer que seu produto não tenha sido devidamente planejado do ponto de vista técnico e agora você esteja em um ponto em que: ou reescreve, ou o produto não poderá mais evoluir. Entretanto, cair em uma situação como essa deveria ser exceção, e não parte normal do ciclo de vida de um produto online.

Resumindo: Para software instalado, o fim de vida por maturidade programada é intrínseco ao modelo de negócios, enquanto para software online, o fim de vida por maturidade programada deve ser sempre exceção.

Como esse tipo de fim de vida pode ser programado, o gestor de produtos deve, em conjunto com UX e engenharia de produtos, desenhar como será essa fase, sempre visando ao mínimo de impacto para os clientes. Na Locaweb, no nosso produto de e-mail marketing, chegamos a um ponto em que tivemos de mudar o banco de dados. Usávamos MongoDB que, por problemas de projeto, não estava sendo capaz de aguentar o crescimento do produto; por isso, decidimos por mudar a base de dados para PostgreSQL.

Desenhamos essa reescrita do produto de tal forma para que o cliente não fosse impactado negativamente quando a nova versão com o PostgreSQL fosse implementada. Nada mudou na forma dos clientes usarem o produto. O único impacto percebido por eles foi que o produto estava com performance melhor, o que era esperado por nós.

Este é o ponto mais importante a ser pensado em relação ao fim de vida programado: o que vai acontecer com os clientes que estão na versão atual, que passará a ser a versão “velha”, quando lançarmos a nova? Isso tem de ser pensado com muito cuidado, e o foco tem de ser sempre em um impacto mínimo para o cliente.

É lógico que, quando a nova versão tem interface e interação diferentes da versão antiga, o cliente será impactado. É muito importante fazer testes com alguns deles para medir o impacto antes de forçar a mudança para toda a base de clientes. Em algumas situações, você pode até decidir por manter a versão antiga por algum tempo, dada a dificuldade de trazer os clientes para a versão nova. Mas, não se esqueça, o foco é sempre fazer seu cliente sofrer o mínimo possível.

Concluindo

Vimos em detalhes nos capítulos anteriores todo o ciclo de vida de um produto de software, passando por todas as suas fases: a inovação, o crescimento, a maturidade – que pode ser programada ou não –, e o fim de vida – que pode vir após a maturidade ou quando o produto não cruza o abismo que separa a fase da inovação da fase do crescimento.

Para concluir esse tema sobre ciclo de vida, vamos falar agora sobre a diferença entre startup e gestão de produtos de software; diferença esta, que tem muito a ver com o ciclo de vida de um produto de software.

Mentoria de líderes de produto

Tenho ajudado líderes de produto (CPOs, heads de produtos, CTOs, CEOs, tech founders, heads de transformação digital) a extrair mais valor e resultados de seus produtos digitais. Veja aqui como posso ajudar você e a sua empresa.

Gestão de produtos digitais

Este artigo é mais um capítulo do meu livro Gestão de produtos: Como aumentar as chances de sucesso do seu software, onde falo sobre o que é gestão de produtos digitais, seu ciclo de vida, que ferramentas utilizar para aumentar suas chances de sucesso. Você também pode se interessar pelos meus outros dois livros: