Crescimento: métricas financeiras

Quando falei sobre a importância de ser um data geek nos capítulos anteriores, expliquei o funil de conversão. Este é composto por um conjunto de dados que podemos chamar de curto prazo, pois em questão de poucos dias (ou mesmo horas) você já poderá perceber tendências, tirar conclusões, criar hipóteses e validá-las, quer seja conversando com seus usuários, ou fazendo experimentos e medindo os resultados.

Falei também sobre métricas de engajamento, que mostram como seus usuários interagem com seu produto e de churn de cliente. Isso o ajudará a entender quantos clientes deixam de ser seu cliente, por que eles decidiram deixar de ser, e qual o impacto disso em sua receita.

Além desses dados, existem outros que levam mais tempo para se consolidarem e começarem a mostrar alguma tendência, mas que devem ser monitorados desde o primeiro mês de vida de seu produto. São as métricas financeiras, que podem ser classificadas em número globais (receita e custos) e números individuais: CAC (Customer Acquisition Cost), LT (Lifetime) e LTV (Lifetime Value).

Números globais: receita e custos

A receita é o dinheiro que você recebe quando as pessoas usam seu produto. Como explicado no capítulo Inovação: como obter retorno com seu produto de software?, há várias formas de se obter receita com seu produto. Essa receita será usada para pagar seus custos. Quando você conseguir pagar seus custos mensais, a sobra servirá para compensar o investimento dos meses em que a receita mensal não cobria os custos mensais.

Tanto receita quanto custos devem ser controlados mês a mês. É interessante você classificar seus custos em algumas categorias, para lhe ajudar a entender onde você está gastando mais e onde você pode economizar. Costumo classificar custos em 3 categorias:

  • Infraestrutura: são todos os custos necessários para manter o serviço operando. Nessa categoria, incluo custo de hospedagem do site e da aplicação, de registro de domínio, de ferramentas de e-mail marketing, de SEO, de teste A/B, de sistema de chat online para atender clientes etc. Normalmente, esses gastos são recorrentes e, por isso, requerem muita atenção sempre que você contratar um novo serviço desses.
  • Desenvolvimento: aqui entram todos os custos para desenvolver e implementar novas funcionalidades no seu site e na sua aplicação, incluindo programação, desenvolvimento de interface, design visual, design de logotipo etc.
  • Marketing: todo investimento que você faz para atrair clientes, como anúncio AdWords, anúncio Facebook, anúncios em sites, revistas, jornais e TV. Também devemos incluir aqui os custos com impressão e distribuição de panfletos, cupons promocionais, folders etc. No começo, você muito provavelmente precisará de investimento, mas é importante também investir tempo em formas gratuitas para atrair clientes que, apesar de serem de longo prazo, ajudarão ao longo dos meses a economizar um pouco nos custos de marketing ou, se você decidir continuar investindo na divulgação paga, ajudará a aumentar sua receita.

Para você ter um produto rentável, é preciso ter receita mensal maior que os custos mensais. Simples assim. Porém, é mais simples falar do que fazer.

Números individuais: CAC, LT e LTV

A receita e o custo são indicadores globais da saúde de seu produto web. É importante você também ter indicadores individuais, ou seja, indicadores por cada cliente que você tiver.

Existem três indicadores que são bem importantes:

  • CAC: é o customer acquisition cost, ou custo de adquirir um cliente. É a soma dos custos associados com descobrir e conseguir a atenção de potenciais clientes, e de levá-los para seu site, convertendo-os em um usuário de seu produto web e, posteriormente, em usuário pagante. Por exemplo, imagine que você só tenha investido em Google AdWords para atrair seus clientes e que, em um determinado mês, você tenha gastado R$1.000,00 e conseguido 10 novos clientes nesse mês. Com isso, dividindo R$1.000,00 por 10, você terá um CAC de R$100,00. Ou seja, seu custo para adquirir cada cliente é de R$100,00.
  • LT: é o lifetime, ou o tempo de vida de seu cliente. Isto é, quanto tempo, em média um cliente seu fica como seu cliente. Esse número só faz sentido quando você tem um fluxo de receita recorrente. Continuando o exemplo anterior, vamos imaginar que o LT dos clientes que você adquiriu é de 20 meses.
  • LTV: é o lifetime value, ou o valor de um cliente durante o tempo em que ele permanecer seu cliente. É a receita que esse cliente gera enquanto ele é seu cliente. Seguindo ainda no exemplo anterior, vamos imaginar que esse cliente gere uma receita mensal de R$8,00. Com isso, o LTV será a multiplicação dos 20 meses pelos R$8,00 por mês, que dá um LTV de R$160,00.

Nessas definições é fácil ver que seu produto será rentável quanto maior for o LT e o LTV, e menor o CAC, e que você precisa ter LTV maior que CAC.

No exemplo que vimos, temos um LTV de R$160,00 e um CAC de R$100,00, o que mostra que temos uma situação rentável. É preciso acompanhar esses números de perto, mês a mês. Se em um determinado mês o LTV continuar sendo R$160,00 e o CAC tiver aumentado para mais de R$160,00, é preciso revisar os esforços de aquisição de cliente para ver se é possível reduzir esse custo. Também deve-se estudar formas de aumentar o LTV, aumentando o LT e/ou aumentando o valor mensal.

Churn de receita

Uma métrica de receita bem interessante, que deriva da métrica de churn de clientes que vimos no capítulo anterior, é o conceito de churn de receita, bastante usado pelas empresas que têm um modelo de negócios baseado em assinaturas. Ele é bastante parecido com o conceito de churn de clientes, podendo ser calculado da seguinte forma:

Churn de Receita

Churn mensal de receita = receita dos clientes que cancelaram no mês / total de receita do mês.

Para o seu produto crescer, é preciso ter um aumento de nova receita mensal maior do que seu churn mensal de receita.

Existe uma diferença bem importante entre o churn de clientes e o de receita. O churn de clientes sempre será um número positivo, já o churn de receita poderá ser negativo. Como? Basta que o crescimento de receita de seus clientes existentes, sem contar a receita dos novos clientes daquele mês, seja maior do que o churn de receita dos clientes que estão cancelando o serviço naquele mês.

Veja na figura a seguir a diferença entre churn de clientes e churn de receita:

Churn negativo

Como isso é possível?

O churn negativo acontece quando seus clientes da base estão aumentando o uso de seu produto de software, e eles têm de pagar por isso. Por exemplo, quando eles fazem upgrade para um plano de serviço com mais recursos, quando eles contratam serviços adicionais, quando eles pagam por uso adicional, ou quando eles compram mais contas de acesso, se seu produto tiver precificação baseada em quantidade de contas de acesso.

Isso fará com que seu produto cresça mais do que a quantidade de novas vendas por mês, pois com o churn negativo, mesmo se você não tiver nenhuma venda nova, sua receita vai crescer devido ao aumento de receita dos clientes existentes. Por isso, o churn negativo é considerado o “Santo Graal” dos produtos com modelo de negócio baseado em assinatura.

No próximo capítulo, vamos conhecer a métrica da lealdade.

Mentoria e aconselhamento em desenvolvimento de produtos digitais

Tenho ajudado várias empresas 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:

Prioridade nº 1 da Gestora de Produto

Em meus artigos recentes, discuti por que “demandas de negócios => implementos de tecnologia” não funciona, por que as pessoas de negócios odeiam discovery e apresentei o conceito de MVD (Minimum Viable Discovery).

Hoje falarei sobre a prioridade nº 1 de toda Gestora de Produto que, acredito, será um bom complemento aos 3 artigos citados acima.

Quiz

Para iniciar este artigo, quero propor um quiz. Com base na sua experiência, qual é a prioridade nº 1 de toda Gestora de Produto?

  • Ter uma visão de produto e uma estratégia sólida para executar essa visão.
  • Ter uma compreensão boa o suficiente do problema do usuário para que a equipe possa iterar rapidamente nas hipóteses de solução e entregar a melhor solução o mais rápido possível.
  • Criar uma Árvore de Oportunidades completa para ajudar a equipe a avaliar oportunidades e trabalhar naquelas que podem validar hipóteses de solução o mais rápido possível.
  • Todas as anteriores
  • Nenhuma das anteriores

Vamos analisar cada uma das respostas acima para encontrar a resposta correta e entender melhor por que essa é a resposta correta:

Ter uma visão de produto e uma estratégia sólida para executar essa visão

Já mencionei no passado que criar a visão de produto é fundamental para que a líder de produto e a gestora de produto conseguir fazer seu trabalho. Sem:

  • ter uma compreensão clara da visão do seu produto
  • ter essa visão de produto claramente alinhada com os líderes de sua empresa
  • constantemente comunicar esta visão para toda a empresa

é muito difícil fazer qualquer coisa com o seu produto. Como você prioriza sem saber para onde deve levar seu produto? Como dizer não às constantes solicitações dos stakeholders do seu produto (funcionários da empresa, clientes, parceiros)? A partir dessa visão, a Gestora de Produto pode criar uma estratégia clara de como executar essa visão. No entanto, essa não é a prioridade número 1 da Gestora de Produto. É um meio de executar essa prioridade nº 1.

Ter uma compreensão boa o suficiente do problema do usuário para que a equipe possa iterar rapidamente nas hipóteses de solução e entregar a melhor solução o mais rápido possível

Isso é o que venho discutindo nos meus últimos artigos e isso é muito importante para chegar à prioridade nº 1 da Gestora de Produto. Nunca devemos pular diretamente para a implementação de soluções, nem quando solicitados por pessoas de negócio para implementar sua demanda e nem quando soubermos de um problema e começarmos a implementar a primeira solução que nos vier à mente. Sabemos que, à medida que aprendemos algo sobre um problema, também devemos mapear hipóteses de solução e testar essas soluções o mais rápido possível para que possamos entregar a melhor solução o mais rápido possível. No entanto, da mesma forma que a primeira resposta, essa não é a prioridade nº 1. Novamente, é um meio para um fim.

Criar uma Árvore de Oportunidades completa para ajudar a equipe a avaliar oportunidades e trabalhar naquelas que podem validar hipóteses de solução o mais rápido possível

Esta resposta é uma variação da resposta acima apenas tornando explícita uma boa ferramenta para iterar do problema à solução, a Árvore de Oportunidades. Mencionei essa ferramenta em meu artigo sobre os dois lados do product discovery. Ele ajuda uma equipe de produto a entender melhor o resultado esperado (outcame), mapear as oportunidades que podem gerar o resultado, gerar possíveis soluções para as oportunidades e construir experimentos para testar as soluções. No entanto, esta resposta é um pouco pior do que a resposta anterior porque fala sobre a criação de uma árvore de oportunidades completa. Devemos usar a árvore de oportunidades para ter uma compreensão boa o suficiente do problema para definir possíveis soluções e chegar ao resultado esperado (outcame) o mais rápido possível. E novamente, este é um meio para um fim. Não é a prioridade nº 1 da Gestora de Produto.

Todas as anteriores

Vamos então juntar todas as respostas anteriores e fazer disso a prioridade nº 1 da Gestora de Produto, certo? Não! Conforme explicado acima, essas são todas as ferramentas que uma Gestora de Produto pode usar para alcançar sua prioridade nº 1. Além disso, acredito que seja bem fácil entender por que essa não é a resposta correta. Estamos perguntando qual é a prioridade nº 1 da Gestora de Produto, então essa prioridade não pode ser 3 coisas. Deve ser apenas uma coisa! Este é um erro comum em que algumas Gestoras de Produto incorrem, ter mais de uma prioridade. Quando se pergunta para uma Gestora de Produtos quais são suas prioridades, ela acabe citando uma lista de coisas, o que é até certo ponto OK se, e somente se, ela souber e trabalhar constantemente em sua prioridade nº 1, que saberemos qual é daqui a pouco! (=

Nenhuma das anteriores

Acho que depois de ler a explicação de por que as 4 respostas anteriores estão incorretas, você provavelmente sabe que “nenhuma das anteriores” é a resposta correta. No entanto, apesar de esta ser a resposta correta, ainda não está claro qual é a prioridade nº 1 da Gestora de Produto. Mesmo que eu tenha dado algumas dicas acima, deixe-me agora deixar isso explícito.

A prioridade número 1 da Gestora de Produto é gerar resultados o mais rápido possível

Deixe-me repetir mais uma vez: a prioridade número 1 de toda Gestora de Produto é gerar resultados o mais rápido possível.

Como mencionei nos comentários sobre cada uma das respostas acima, as respostas 1, 2 e 3, são todos meios para um fim, e este fim é gerar resultados o mais rápido possível. Gerar resultados para a empresa que possui o produto e investe na construção do produto, e resultados para o cliente, ou seja, resolver seus problemas e atender suas necessidades. Precisa ser o mais rápido possível, pois gerar resultados custa dinheiro e quanto mais tempo gastarmos na geração de resultados, mais dinheiro gastaremos.

Acima citei algumas boas ferramentas para obter resultados, mas não devemos esquecer que são ferramentas para nos ajudar a gerar resultados o mais rápido possível. OKR, roadmap, prova de conceito, MVP, MVD, discovery, teste de usabilidade, protótipo, no-code/low-code, site, app, funcionalidade, bot, algoritmo, árvore de oportunidades, mapeamento poder x interesse, RASCI, matriz BCG, curva de adoção de tecnologia, estrutura de equipe, modelo de Tuckman, lei de Conway, ágil, lean, e a lista pode ser bem extensa, mas tudo isso são ferramentas para que possamos gerar resultados para o negócio e para o cliente. Até o produto, a palavra que vai no título da função da Gestora de Produtos, é uma ferramenta para gerar resultados.

A propósito, gerar resultados o mais rápido possível não é a prioridade nº 1 apenas da Gestora de Produto. É a prioridade nº 1 de toda a equipe de desenvolvimento de produtos. Engenheiras, Designers de Produto e Gestoras de Produto que trabalham tanto em equipes de produto, bem como em equipes estruturais (dados, devops, arquitetura, etc). A equipe deve ter sempre uma prioridade nº 1 comum para ser uma equipe. Caso contrário, eles serão um grupo de pessoas que sentam juntas (ou que têm um canal no slack para equipes remotas) e que têm sessões periódicas de planejamento e update, mas que trabalham em diferentes prioridades. E essa prioridade nº 1 é gerar resultados o mais rápido possível.

Outro exemplo de geração de resultados

Dei alguns exemplos do foco em resultados em meus artigos anteriores. Quero dar outro exemplo da Lopes, a maior imobiliária do Brasil, onde lidero os esforços de transformação digital.

Para vender imóveis de um novo prédio, a Lopes e a construtora criam uma relação de parceria onde a construtora compartilha informações sobre preços, disponibilidade de unidades e leads, e a Lopes trabalha na venda dessas unidades com base em sua larga experiência na comercialização de lançamentos. Para cumprir suas atribuições nesta parceria, precisamos saber da construtora os preços de cada unidade que mudam frequentemente de acordo com a evolução das vendas. Precisamos também saber quais unidades estão disponíveis, e precisamos receber leads da construtora. Essas informações era enviadas através de arquivos para serem importados manualmente em nosso sistema. Todas as entradas manuais de informações tendem a ser lentas e sujeitas a erros, por isso fica claro que essa integração manual não é o ideal. A integração da Lopes com as construtoras não é diferente. Por ser uma operação manual, era feita uma ou duas vezes por semana, o que gerava informações desatualizadas sobre preços e unidades disponíveis em nossos sistemas para uso dos corretores. Além disso, quanto mais antiga a informação do lead, mais fria esse lead se torna e, provavelmente, o cliente em potencial descobre outras maneiras de receber as informações de que precisa e, eventualmente, fecha um negócio com outro vendedor.

Resolvemos esse problema usando a árvore de oportunidades, sempre com foco em gerar resultados o mais rápido possível:

  • Resultado esperado: mais vendas
  • Oportunidade: trazer informações das construtoras o mais rápido possível, idealmente em tempo real
  • Solução 1: integrar com o sistema de gestão das construtoras por meio de APIs. A questão aqui é que todos os sistemas de gestão utilizados pelos construtores não possuem APIs para integração. Então, teríamos que esperar até que o fornecedor do sistema de gerenciamento implementasse APIs em seu sistema.
  • Solução 2: construir nossos próprios RPAs (Robotic Process Automation) para obter as informações necessárias (preços, unidades disponíveis e leads) dos sistemas de gestão das construtoras sem a necessidade de APIs. O problema aqui é que a nossa equipe não tinha experiência suficiente para construir esses RPAs, então provavelmente seria um processo demorado.
  • Solução 3: contratar um provedor de RPA para construir as integrações para nós.

Optamos pela Solução 3 porque era a que nos traria resultados mais rapidamente. Levamos apenas algumas semanas para ter o primeiro RPA funcionando e trazendo resultados. Estamos usando esta solução há mais de um ano. Ainda assim, nenhuma API foi fornecida pelos provedores do sistema de gerenciamento e, até o momento, não tivemos a necessidade de construir nossos próprios RPAs. O provedor de RPA funciona bem com um custo razoável e podemos focar nossa equipe para gerar resultados a partir de outras oportunidades.

Resumindo

  • A prioridade número 1 do Gerente de Produto é gerar resultados o mais rápido possível. Gerar resultados para a empresa que possui o produto e investe na construção do produto, e resultados para o cliente, ou seja, resolver seus problemas e atender suas necessidades.
  • Tudo o que usamos em gestão de produtos do dia-a-dia, incluindo o próprio produto que construímos, não é o objetivo final. São meios para um fim, gerar resultados o mais rápido possível.
  • Gerar resultados o mais rápido possível é a prioridade número 1 não apenas da Gestora de Produto, mas de toda a equipe de desenvolvimento de produto, incluindo engenheiros, designers de produto e gestoras de produto tanto de equipes de desenvolvimento de produto quanto de equipes estruturais. Essa é a única maneira de garantir que a equipe seja realmente uma equipe, ter uma prioridade nº 1 comum.

Mentoria e aconselhamento em desenvolvimento de produtos digitais

Tenho ajudado várias empresas 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:

Crescimento: engajamento e churn

Uma vez que você conseguiu trazer usuários (gratuitos ou pagos) para utilizarem seu produto, sua próxima preocupação será com o engajamento desses usuários, ou seja, será que eles estão conseguindo utilizar o produto? Será que eles estão conseguindo resolver o problema que o produto se propôs a resolver? Quantas vezes por dia (semana ou mês) seu produto é usado, e durante quanto tempo? Como ele é usado?

Engajamento

É muito importante encontrar métricas para medir o engajamento. Por exemplo, em um produto de disparo de e-mail marketing, algumas métricas de engajamento e uso são quantas vezes por dia a pessoa acessa, quantas campanhas o usuário dispara por mês, quantas vezes foi aberta a campanha disparada, quantas vezes essa campanha foi clicada, quantas mensagens foram disparadas com endereço de e-mail incorreto e quantas mensagens geraram reclamações.

Repare que cada produto tem métricas de engajamento e de uso diferentes. Cada gestor de produtos deve pensar em que métricas acompanhar em seu produto. Eventualmente, algumas métricas vão gerar demandas de desenvolvimento, pois elas podem não estar sendo medidas e precisam de alguma modificação no produto para passarem a ser.

Você já parou para pensar quantas vezes por dia você usa o seu celular? O que você costuma fazer ao acessar seu celular? WhatsApp? Facebook? Instagram? Dá para se dizer que você está bastante engajado com essas aplicações?

Fomentar o engajamento deve ser uma das preocupações do gestor de produto. Em 2013, foi lançado um livro chamado Hooked: How to Build Habit-Forming Products, de Nir Eyal, no qual ele explica a teoria por trás desses produtos que acabam entrando no nosso cotidiano. É um ótimo livro para entender mais sobre esse tema.

Existem algumas estratégias que podem ajudá-lo a aumentar o engajamento e o uso de seu produto. Em inglês, essas técnicas são chamadas de técnicas de lock-in :

  • APIsApplication Programming Interface (ou, em português, Interface de Programação de Aplicativos): é uma maneira de dar acesso ao seu produto, aos dados que estão armazenados lá e às rotinas que ele executa para outros softwares. Quando alguém cria um novo software usando as APIs de seu produto, existe grande chance de aumentar o engajamento com ele.
  • Incentivo ao uso: você pode fazer promoções que incentivem o uso do seu produto. Por exemplo, se seu produto tem quota de uso, você pode aumentar essa quota à medida que o tempo passa.
  • Treinamento: ensinar seus usuários a tirar todo o potencial de seu produto é uma forma de engajá-los. Quanto mais eles aprenderem, mais rápido entenderão como ele poderá ajudá-los. Não é necessário treinamento formal, em sala de aula. Você pode fazer treinamento virtual via webinars, ou até mesmo usar em seu produto aqueles tooltips, mostrando passo a passo como o usuário pode tirar proveito dele.
  • Historic data: os dados de utilização de seu produto, como logs e relatórios, podem ser uma ferramenta muito útil para o seu usuário. Ajude-o a tirar proveito desses dados. Por exemplo, você pode mandar resumos diários (ou semanais) via e-mail para ele, convidando-o a acessar seu produto para ver mais.
  • Integração com outros produtos: outra forma de aumentar o uso do produto é por meio de integrações com outros produtos que o seu cliente já usa. Por exemplo, uma loja virtual pode ter integração com gateways de pagamento, com sistemas de nota fiscal eletrônica e com sistemas de envio de pacotes via correio.

Churn

Outra métrica muito importante é churn, ou seja, a quantidade de usuários e clientes que deixaram de ser usuários ou clientes. Eventualmente, alguns deles vão deixar de ser seu usuário ou cliente. É importante saber quantos são, e os motivos por que isso aconteceu, pois aqui você descobrirá muita informação para melhorar seu produto de software.

Esse número é muito importante em qualquer empresa que tem por modelo de negócio o uso contínuo, principalmente aqueles baseados em assinatura. Ele costuma ser medido como um percentual da seguinte forma:

Churn

Churn mensal = quantidade de clientes que cancelou no mês / total de clientes do último dia do mês.

Existe também o churn anual, que se calcula da mesma forma, só que dividindo a quantidade de clientes que cancelaram em um determinado ano pelo total de clientes do último dia do ano anterior.

É um número que contém muita informação mas, por ser somente um único número, ele deixa várias perguntas em aberto. Já vi discussões do tipo: “se o churn está em 20%, em cinco meses não teremos mais clientes, então não vale a pena investir em divulgar esse produto”. Uma frase como essa não tem muito sentido, pois mesmo que o churn se mantenha a 20% durante vários meses, até mesmo mais de 5 meses, a quantidade total de clientes pode continuar crescendo. Como? Basta ter uma quantidade maior de ativações do que de cancelamentos, e a divulgação ajuda bastante nisso. Veja o exemplo:

Exemplo de churn

Apesar de em todos os meses o churn ser maior do que 20%, o crescimento no ano foi de 73 novos clientes.

Por que mesmo com um churn mensal alto é possível crescer?

São dois os motivos. O primeiro, que já comentei, é que é preciso ter uma entrada de clientes maior do que a quantidade que sai.

O segundo é que o churn varia de acordo com a idade do cliente. É comum ter casos nos quais o churn é alto no primeiro mês, pois o cliente não gostou do serviço e decidiu cancelar logo de cara. Ou no terceiro ou sexto mês, se sua cobrança for trimestral ou semestral. Algumas pessoas chamam de churn prematuro.

O churn prematuro, apesar de ser comum, é algo que pode e deve ser diminuído. Você faz isso:

  • Alinhando a expectativa do cliente que você criou nele por meio da sua divulgação do seu produto com o que ele vai encontrar quando passar a usá-lo.
  • Garantindo que as primeiras experiências de uso de seu produto sejam muito boas e que o seu cliente consiga atingir seus objetivos nessas primeiras experiências.
  • Mantendo seu produto útil para o seu cliente ao longo dos meses e dos anos, investindo em entender seu cliente e seus problemas, e em atualizar seu produto para que ele continue resolvendo os problemas de seu cliente.

Os conceitos de churn e de engajamento andam de “mãos dadas”, pois, quanto mais engajado estiver um usuário, menores são as chances de ele cancelar o serviço. Assim, uma boa maneira de prever o churn de um determinado cliente é acompanhar seu engajamento.

Por exemplo, se você lançou um produto de ensino a distância e acompanha a utilização desse produto, você provavelmente verá que a taxa de cancelamento é maior nos clientes que nunca assistiram aula. Reveja o tópico anterior sobre lock-in para ver táticas para aumentar o engajamento e diminuir o churn.

Data science, machine learning e gestão de produtos

Nos últimos anos tem aparecido de forma recorrente e abundante os termos data science, machine learning e artificial inteligence. Esses termos são bastante importantes para os gestores de produtos. Não é à toa que dedico 5 capítulos do livro a assuntos relacionados a dados e métricas.

Como comentei no capítulo anterior, o gestor de produtos deve ser um data geek, ou seja, uma pessoa que está sempre pensando em como aprender mais com dados. Qual é o comportamento de uma pessoa nos meses e dias antes de cancelar a assinatura de seu produto? E o comportamento de uma pessoa que faz upgrade? Qual é o comportamento de um usuário que se diz satisfeito com seu produto? E do que se diz muito satisfeito? Se seu produto tem várias funcionalidades, qual é a mais popular? Qual gera maior satisfação? Qual é o padrão de uso típico de seu produto? Se aparecer um padrão de uso atípico, o que isso quer dizer? Esses são exemplos de algumas perguntas que o gestor de produtos pode fazer e que terão suas respostas nas métricas do produto. E a cada nova resposta obtida é muito provável que o gestor de produtos irá querer fazer mais perguntas.

Para achar as respostas às suas perguntas, é importante que o gestor de produtos conheça técnicas de data science e saiba como extrair ele mesmo as respostas para suas perguntas, quer seja por meio de ferramentas de extração e visualização de dados, quer seja rodando queries de SQL na base de dados do produto. Se o gestor de produtos não tiver essa independência, e precisar que outras pessoas extraiam os dados para ele, isso poderá atrapalhar a evolução do produto.

À medida que esse aprendizado a partir dos dados for acontecendo, é provável que o gestor de produtos comece a perceber oportunidades para inserir esses aprendizados dentro do produto. Por exemplo, um gestor de produtos de um software de CRM pode perceber, após fazer análises com dados de uso e engajamento do produto, que clientes acabam cancelando menos quando estão utilizando a funcionalidade de geração de propostas comerciais. Uma vez feita essa descoberta, ele pode promover uma mudança em seu produto para tornar mais fácil e imediato o uso dessa funcionalidade e, com isso, diminuir o churn de clientes por deixá-los mais engajados. Essa é uma forma de inserir data science em seu produto.

Mechine learning, que nada mais é que uma forma de implementação de artificial inteligence, é quando programamos as máquinas para aprenderem com os dados e, quanto mais dados a máquina tiver em suas mão, mais ela vai aprender. Ou seja, é uma maneira de inserir data science no produto para torná-lo melhor. Quanto mais você usa um determinado produto, mais dados estão à disposição do time que desenvolve o produto para conhecer seu usuário e como ele usa esse produto. Por exemplo, quanto mais compras você faz em uma loja virtual, mais ela aprende sobre seus hábitos de compra e mais fácil fica para o software da loja fazer recomendações que te interessem. O mesmo acontece com as sugestões do Netflix e do Spotify. Nesse casos é comum a loja comparar seu uso com o uso de pessoas que mostram comportamento similar para fazer sugestões do tipo “quem comprou esse item também comprou esses outros itens”.

É por isso que o gestor de produto e todo o time que desenvolve o produto deve conhecer e saber usar data science, machine learning e artificial inteligence no seu dia-a-dia. São ferramentas poderosas para o ajudar a aumentar as chances de construir um produto de sucesso.

No próximo capítulo, vamos continuar com o tema de métricas, com foco nas métricas financeiras e de longo prazo. Vamos também entender o conceito do churn negativo, o “Santo Graal” dos produtos com modelo de negócio baseado em assinatura.

Mentoria e aconselhamento em desenvolvimento de produtos digitais

Tenha ajudado várias empresas 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:

Outro exemplo de um MVD – Minimum Viable Discovery (Descoberta Mínima Viável)

A Lopes é a maior imobiliária do Brasil, onde lidero os esforços de transformação digital. Uma nova pessoa que se juntou a gente e que veio de um site de comércio eletrônico mencionou que as notificações push do aplicativo geravam mais leads e tinham maiores taxas de conversão do que SMS e email marketing. Ficamos interessados ​​em testar essa hipótese, mas sempre com a mentalidade MVD – Minimum Viable Discovery que expliquei anteriormente.

Como poderíamos testar essa hipótese o mais rápido e barato possível? Construir um aplicativo nativo com todos os recursos do nosso site existente levaria meses. Mesmo que reduzíssemos muito o escopo, com o mínimo para entregar algum valor ao usuário, ainda levaria muitas semanas.

Como nosso site é responsivo, criamos uma solução simples para testar a hipótese. Decidimos criar um aplicativo webview, uma solução mais simples do que construir um aplicativo nativo, mesmo que o limitássemos o escopo ao mínimo.

Aliás, foi assim que o Facebook e o Linkedin também lançaram seus primeiros aplicativos móveis. Somente quando perceberam os resultados gerados por um app, e comprovaram que uma versão nativa traria ainda mais resultados, decidiram investir na construção de seus aplicativos nativos.

Aqui está o aplicativo móvel de Lopes:

Com este aplicativo móvel pudemos confirmar que a notificação push gerou mais leads e teve maiores taxas de conversão do que SMS e email marketing. Lançamos este aplicativo no início de 2021.

Já ouvi dizer que MVP não escala, é só para testar uma hipótese de solução e então, se a hipótese de solução for comprovada, devemos trabalhar para entregar a solução de forma escalável. Como em tudo relacionado ao gestão de produtos, depende! No nosso caso, até agora não tivemos a necessidade de construir uma versão nativa deste aplicativo móvel. A versão webview está funcionando muito bem para nossas necessidades e os usuários parecem estar ok com isso também. Talvez no futuro tenhamos a necessidade de construir um aplicativo nativo mas, pelo menos por enquanto, depois de mais de um ano que lançamos nosso aplicativo móvel, webview ainda não há necessidade de construir o aplicativo móvel nativo.

Você pode experimentar o Lopes App para Android ou iOS.

Resumindo

  • A mentalidade MVD – Minimal Viable Discovery é essencial para entregar resultados o mais rápido possível. Por exemplo, por que construir um aplicativo móvel nativo para testar alguma hipótese se uma visualização da web é suficiente para testá-la?
  • A afirmação “MVP não escala” não é necessariamente verdadeira. Como tudo relacionado à gestão de produtos, depende. No nosso caso, mais de um ano após o lançamento do MVP que criamos para testar nossa hipótese de Discovery Solution, nosso aplicativo webview, não tivemos a necessidade de construir um aplicativo nativo.

Mentoria e aconselhamento em desenvolvimento de produtos digitais

Tenho ajudado várias empresas 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:

Porque as pessoas de negócios odeiam discovery

Existem basicamente três razões, duas delas tem a ver com a mentalidade e a outra tem a ver com o processo de descoberta.

A que tem a ver com mentalidade fica clara quando ouvimos frases como “Por que você quer fazer uma descoberta? Eu sou a pessoa de negócios, então sou a pessoa que mais entende sobre nossos problemas/necessidades de negócios e como resolvê-los. Você apenas tem que implementar o que eu digo”.

Outras vezes, essa aversão está enraizada na mentalidade de “exigências de negócios => implementos de tecnologia” que mencionei anteriormente. Era assim que as coisas eram feitas no passado, sem necessidade de descoberta, pois “são os empresários que interagem com o cliente para que sempre saibam o que é melhor para os clientes”.

Contudo, na maioria das vezes, essa aversão pelo processo de descoberta é motivada pelas experiências passadas do empresário em que o processo de descoberta foi muito longo. O empresário precisa que a solução de seus problemas seja implementada o mais rápido possível, para que possa se beneficiar dos resultados que essa demanda pode gerar. A pessoa de negócios não pode arcar com longos processos de descoberta.

É muito difícil, mas não impossível, mudar essa mentalidade. Requer paciência e repetição:

  • Pergunte por quê: perguntando por que a pessoa de negócios está exigindo a implementação de uma determinada funcionalidade, temos a oportunidade de mostrar a essa pessoa uma tática de descoberta muito simples que ajuda tanto o gerente de produto quanto a pessoa de negócios a encontrar outras hipóteses de soluções para o problema. Mudamos para um modo de discovery sem usar a palavra discovery. Depois de algumas vezes aplicando essa tática, podemos dizer à pessoa que entender o porquê de uma demanda, gerar hipóteses de solução e testar essas hipóteses de solução é o processo de discovery e é baseado na necessidade do gerente de produto e da equipe de desenvolvimento de produto encontrarem a solução mais fácil e rápida de implementar.
  • Aprenda sobre o negócio: às vezes a pessoa de negócio acredita que sabe mais sobre o negócio do que o gerente de produto. Isso normalmente acontece quando um novo gerente de produto ingressa em uma empresa e ainda não sabe muito sobre o negócios. Para resolver essa percepção da pessoa de negócio, o gerente de produto precisa encontrar maneiras de conhecer o negócio o mais rápido possível. Converse com pessoas de negócio, converse com clientes, leia sobre o negócio, participe de cursos de curta duração sobre o negócio, vá a conferências sobre o tema de negócios. Os gerentes de produto precisam entender sobre o negócio para discutir questões de negócios com a pessoa de negócios.
  • Encurte o processo de discovery: às vezes os discoveries demoram bastante. Algumas semanas, um mês, mais de um mês. Enquanto isso, a pessoa de negócio tem um problema que precisa de solução o mais rápido possível para que possa se beneficiar do resultado esperado que a solução do problema pode gerar. Isso acontece principalmente quando o processo de descoberta é focado apenas na descoberta do problema. Se o gerente de produto for capaz de alternar rapidamente entre a descoberta do problema e a descoberta da solução, a pessoa de negócios poderá ver a equipe de desenvolvimento de produto trabalhando mais cedo nas hiopóteses de solução para o problema e pode ter suas expectativas por uma solução acalmadas.

MVD – Descoberta Mínima Viável

Infelizmente, esse terceiro motivo, o processo de descoberta lento, acontece com bastante frequência e a culpa é nossa como gestores de produto, principalmente quando buscamos entender tudo sobre um problema antes de testar as soluções.

Como mencionei anteriormente, o processo de descoberta tem dois lados, a descoberta do problema e a descoberta da solução. Não precisamos saber tudo sobre um problema antes de testar hipóteses de solução, ou seja, descobrir soluções. A descoberta de solução é uma ferramenta poderosa para entendermos mais sobre o problema. Por esse motivo, precisamos alternar o mais rápido possível entre a descoberta do problema e a descoberta da solução. Quanto mais rápido fizermos isso, mais rápido entenderemos o problema e mais rápido descobriremos uma solução para o problema.

Além disso, se fizermos uma descoberta completa do problema para entender tudo sobre esse problema, podemos acabar com tantos subproblemas que tornarão o processo de descoberta da solução também muito demorado e o delivery levará muito tempo para ser concluído.

A comunidade de desenvolvimento de produtos fala muito sobre MVP, o produto mínimo viável, mas não podemos esquecer que não se trata apenas de um delivery rápido de um produto mínimo, mas também de um processo de discovery enxuto. É hora de adotar uma mentalidade MVD – Minimal Viable Discovery ou Descoberta Mínima Viável, ou seja, qual é a descoberta mínima sobre o problema que preciso fazer para testar hipóteses de solução mínimas e entregar aquela que funciona e realmente resolve o problema?

App para corretores Lopes

Um bom exemplo para ilustrar isso é o app para corretores Lopes. A Lopes é a maior imobiliária do Brasil, onde lidero os esforços de transformação digital. Quando entrei na empresa, a equipe estava trabalhando em um “MVP” deste aplicativo. Coloquei aspas porque estava em desenvolvimento há 5 meses e ainda faltavam 2 ou 3 meses. Quando me aprofundei um pouco mais sobre o processo e porque estava demorando tanto, aprendi algumas coisas:

  • O processo de descoberta durou de 7 a 10 meses!
  • O processo de descoberta foi focado apenas na descoberta do problema.
  • O processo de descoberta foi interno, ou seja, levantamento de demanda das áreas de negócios e benchmarking com outros aplicativos para corretores disponíveis no mercado.
  • O “MVP” foi definido com 58 requisitos/funcionalidades e já havia mais 90 requisitos/funcionalidades com escopo definido para lançamentos futuros.
  • O principal problema a ser resolvido foi baseado na hipótese de que, se a corretora recebeu um lead, ou seja, um potencial cliente interessado em um imóvel, quanto mais rápido ela receber esse lead e interagir com o cliente, maiores serão as chances de fechar um negócio.
  • Em seguida, a equipe analisou a jornada da corretora e percebeu que, quando um lead chega, a corretora precisa pesquisar o banco de dados de potenciais clientes da Lopes para verificar se o potencial cliente do lead já está em nosso banco de dados e, caso não esteja, cadastrar seus dados nosso sistema.
  • E então, a partir dessa análise da jornada da corretora, o time percebeu que, se a corretora pudesse enviar algumas outras opções de imóveis para o cliente em potencial, isso aumentaria as chances de fechar um negócio.
  • Esse processo criou o escopo a ser implementado que levou de 7 a 10 meses de discovery mais 7 a 8 meses de entrega para construir o aplicativo “MVP”.

Há alguns pontos a destacar do processo acima:

  • O processo de descoberta foi muito longo, o que gerou uma enorme lista de problemas da corretora a serem resolvidos.
  • A fase de descoberta da solução não foi executada. A equipe passou da descoberta do problema diretamente para a entrega, sem qualquer oportunidade de testar hipóteses de solução.
  • A enorme lista de problemas a serem resolvidos impactava diretamente no processo de entrega tornando-o muito longo também.
  • Se a descoberta da solução fosse utilizada assim que o problema principal fosse descoberto, ou seja, a hipótese de que quanto mais rápido ela recebesse esse lead e interagisse com o cliente, maiores as chances de fechar um negócio, provavelmente a equipe conseguiria conceber uma solução mais simples, que levaria dias e não meses para ser implementada.

Em relação a este último ponto, após algumas discussões, pensamos em um aplicativo com apenas uma notificação push para cada lead recebido e a corretora poderia continuar as outras tarefas como já fazia. E para ser ainda mais simples de testar a hipótese da solução pensamos em nem construir um aplicativo, mas enviar um SMS ou uma mensagem de WhatsApp para a corretora. Um teste A/B pode ser feito para comparar as taxas de fechamento de negócios dos corretores que receberam notificação por SMS versus as taxas de fechamento dos corretores que não receberam.

Na verdade, acabamos implementando a notificação por SMS. Demoramos 10 dias para implementar e logo em seguida conseguimos testar a hipótese de que quanto mais rápido um corretor receber um lead e interagir com o cliente, maiores as chances de fechar um negócio.

O melhor método de discovery chama-se delivery

Já mencionei que uma das razões para entregar cedo e frequentemente é que o momento da verdade para o seu produto acontece quando um produto está na frente de seus usuários, sendo usado no contexto em que deve ser usado. Não importa quantas pesquisas, entrevistas e protótipos você faça, o momento da verdade, ou seja, o momento em que você saberá se o seu produto é, de fato, a solução para um problema de um grupo de pessoas, é quando o produto está nas mãos de seus clientes, no contexto em que eles precisam do produto.

Portanto, a melhor maneira de descobrir se uma hipótese de solução funciona é realmente implementá-la e apresentá-la a usuários em potencial que podem ter o problema que você descobriu durante a descoberta do problema.

Para muitas hipóteses de solução, não precisamos construir um produto completo para testar. Hoje existem muitas ferramentas low-code e no-code que nos permitem construir soluções simples. E algumas dessas ferramentas existem há bastante tempo, como apresentações e formulários. No Gympass testamos algumas hipóteses de solução que tínhamos para resolver o problema que descobrimos de trazer novas opções para pessoas que não queriam ir à academia, mas queriam seguir um estilo de vida mais saudável.

A hipótese de solução foi fazer parceria com aplicativos de bem-estar e fornecer esses aplicativos aos nossos usuários por uma taxa de assinatura mensal. Essa nova ideia tinha duas hipóteses principais que precisávamos testar:

  • Disposição dos provedores de aplicativos para fazer parceria. Provedores de aplicativos, assim como academias, estão acostumados com o modelo de receita mensal recorrente. Eles aceitariam ser pagos por dia de uso?
  • Nossa disposição de base de usuários para pagar. Nossa base de usuários está interessada em pagar uma taxa mensal para acessar os aplicativos?

Para testar nossa primeira hipótese, construímos um deck com a proposta de valor que planejamos entregar aos parceiros e conversamos com alguns potenciais parceiros. Apresentamos a oportunidade a 8 potenciais parceiros, dos quais 6 demonstraram interesse e 4 decidiram aderir à nossa prova de conceito. NEOU, um aplicativo de atividade física, 8fit, um aplicativo de atividade física e nutrição, Tecnonutri, um aplicativo de nutrição e ZenApp, um aplicativo de meditação.

Ok, nossa primeira hipótese foi validada apenas com um deck de slides. Nenhum produto foi criado. Agora precisávamos validar a segunda hipótese, a vontade de assinar. Nosso usuário está disposto a pagar para acessar esses aplicativos através do Gympass?

Para testar nossa segunda hipótese, construímos um formulário simples, onde descrevíamos o produto e pedíamos nome, e-mail e empresa. Após o usuário fornecer essas informações, ele era direcionado para uma página de assinatura do Paypal, onde precisava fornecer os dados do cartão de crédito para assinar o serviço. O usuário receberia um e-mail com o link de ativação para cada aplicativo. Não havia produto real, nenhuma área logada, apenas um formulário para testar o interesse e um e-mail com links para os aplicativos.

Primeira versão do Gympass Wellness

Ou seja, devemos utilizar as opções de ferramentas no-code ou low-code disponíveis para criar sua hipótese de solução para facilitar e agilizar a descoberta da solução. Como efeito colateral, as pessoas de negócios começarão a entender, apreciar e até querer participar de seus próximos discoveries.

Resumindo

  • Pessoas de negócios não gostam de discoveries por causa de 3 razões principais. (1) Acreditam saber mais sobre o negócio, os clientes e o que esse clientes precisam. (2) Eles podem ter tido experiências passadas em que a descoberta levou muito tempo. (3) Eles estão acostumados a um modelo de “negócios demanda => tecnologia implementa”.
  • Mudar essa mentalidade requer paciência e repetição. Três coisas que uma gerente de produto deve fazer continuamente para ajudar a mudar essa mentalidade. (1) Pergunte por que a pessoa está pedindo para implementar a funcionalidade pedida. (2) Procure conhecer mais sobre o negócio. (3) Encurte o processo de discovery.
  • Para encurtar o processo de discovery, devemos pensar em termos de uma mentalidade MVD, ou seja, Minimal Viable Discovery ou Descoberta Mínima Viável, onde descobrimos o suficiente sobre o problema para gerar e testar hipóteses de solução o mais rápido possível.
  • O melhor método de discovery chama-se delivery. O momento da verdade de qualquer hipótese de solução é quando somos capazes de apresentá-la ao potencial usuário em seu próprio contexto onde ele enfrenta o problema que queremos resolver. Hoje temos muitas soluções low-code e no-code que nos ajudam a construir nossa hipótese de solução para tornar mais fácil e rápido trabalhar na descoberta da solução.
  • Como efeito colateral, as pessoa de negócio começarão a entender, apreciar e até querer participar de suas próximas descobertas.

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:

Mentoria e aconselhamento em desenvolvimento de produtos digitais

Tenha ajudado várias empresas a extrair mais valor e resultados de seus produtos digitais. Veja aqui como posso ajudar você e a sua empresa.

Porque “negócios demanda => tecnologia implementa” não funciona

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 dessas empresas é 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”.

Normalmente, as pessoas de negócios tendem a pensar e dizer coisas como “Eu sou a pessoa de negócios, então sou a pessoa que mais entende sobre nossos problemas/necessidades de negócios e como resolvê-los. Você apenas tem que implementar o que eu digo”. Essa pessoa de negócios está pensando na equipe de tecnologia como uma equipe de implementadores de soluções, não uma equipe de solução de problemas ou, como Marty Cagan coloca, como um feature team, não um product team empoderado.

Então, por que o modelo “demandas de negócios => tecnologia implementa” não funciona?

Em vez de dar apenas um motivo, vou listar 5 motivos:

  • Empresas de tecnologia de sucesso como Apple, Amazon, Google, Netflix não usam o modelo “negócios demanda => tecnologia implementa” para construir seus produtos de sucesso. Eles preferem e usam o modelo de desenvolvimento de produto “negócio traz problemas/necessidades => a 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”, pois sabem que esse modelo traz os melhores resultados.
  • O modelo “negócios demanda => tecnologia implementa” gera uma posição de adversário entre negócios e tecnologia e, consequentemente, o comprometimento e engajamento da equipe de tecnologia diminui, o que causa alta rotatividade de pessoal e aumenta da frustração das pessoas de negócios, o que acaba gerando um círculo vicioso.
  • As pessoas de tecnologia não se sentem responsáveis ​​pelo resultado do que constroem, pois a área de negócios definiu o que fazer.
  • A área de negócios pode exigir desenvolvimentos que sejam bons para os interesses individuais de cada área de negócios, mas não necessariamente bons para a empresa.
  • A área de negócios pode pedir coisas complexas que causarão longos ciclos de desenvolvimento que, quanto mais longos, maior a frustração gerada e maiores as chances da entrega não satisfazer as necessidades e não gerar os resultados esperados.

O outro modelo realmente gera melhores resultados?

O fato de que o modelo de trabalho “negócios demanda => tecnologia implementa” ter muitos problemas, não significa necessariamente que o outro modelo realmente gera melhores resultados. Para responder a esta pergunta, ou seja, se o “negócio traz problemas/necessidades => a 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” entregar melhores resultados, compartilharei um case interessante.

Ingressei na Lopes, maior empresa de consultoria imobiliária do Brasil, no final de agosto/2020 como CDO (Chief Digital Officer) com a missão de liderar sua transformação digital. Após minha integração, implementamos o OKR, executamos o 4T2020 com a ferramenta OKR e definimos os objetivos estratégicos para 2021. Naquela época, mais de 50% do time era de empresas terceirizadas de consultoria de TI. Um de nossos objetivos estratégicos para 2021 era tirar gradualmente nosso envolvimento com essas empresas de consultoria de TI e contratar engenheiros, designers de produto e gerentes de produto para construir nossas equipes internas de desenvolvimento de produtos. Iniciamos a desativação das consultorias em janeiro/2021 e terminamos em julho/2021. Ao mesmo tempo, contratamos e integramos muitos engenheiros, designers de produtos e gerentes de produtos para substituir a capacidade de desenvolvimento de produtos que tínhamos com as empresas de consultoria de TI que estavam saindo.

A maioria das empresas de consultoria de TI opera sob o modelo “negócios demanda => tecnologia implementa” onde são medidos por suas entregas, sem nenhuma preocupação se essas entregas realmente trazem resultados para o negócio.

O principal objetivo da nossa equipa digital é, e foi desde a sua criação, trazer mais leads, ou seja, potenciais clientes interessados ​​em comprar um imóvel, a partir de fontes digitais. O gráfico acima mostra que quando as empresas de consultoria de TI, medidas pelas funcionalidades entregues, estiveram na Lopes não conseguimos cumprir esse objetivo. Assim que começamos a descontinuar as empresas de consultoria de TI em fev/2021 e contratamos e integramos engenheiros, designers de produtos e gerentes de produto para construir nossa equipe interna de desenvolvimento de produtos que foi medida pela geração ou potencialização de leads por meio do digital, começamos ver um aumento no número de leads em maio/2021.

Resumindo

  • 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ócios traz problemas/necessidades => a 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”.
  • Existem 5 razões pelas quais o modelo “negócios demanda => tecnologia implementa” não funciona. As melhores empresas de tecnologia não o usam esse modelo. Gera comportamento de adversários entre as equipes de negócios e tecnologia, as equipes de tecnologia não se sentem responsáveis pelos resultados, as pessoas de negócios podem exigir desenvolvimentos não alinhados com os objetivos da empresa e as pessoas de negócios podem exigir desenvolvimentos muito complexos e que demoram muito para trazer resultados.
  • Os benefícios da transição de um modelo de “negócios demanda => tecnologia implementa” para um modelo de “negócios 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” podem ser vistos quando passamos da medição do desempenho pelo número de entregas para a medição do desempenho pelos resultados alcançados.

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:

Mentoria e aconselhamento em desenvolvimento de produtos digitais

Tenha ajudado várias empresas a extrair mais valor e resultados de seus produtos digitais. Veja aqui como posso ajudar você e a sua empresa.

Crescimento: Seja um “Data Geek”

Dê uma olhada nos dados que o seu produto gera! Além de conversar com seus usuários e obter feedback deles, uma maneira obrigatória de conhecer o seu produto e como os usuários interagem com ele é por meio de dados. Para poder tirar proveito desses dados, você deverá se transformar em um data geek, uma pessoa que conhece profundamente os dados gerados pela sua aplicação e seus significados.

Em Deus nós acreditamos. Todos os outros devem trazer dados.
W. E. Deming

William Edwards Deming é um engenheiro, estatístico e professor americano bastante conhecido pelo seu trabalho no Japão, logo após a II Guerra Mundial, onde ele ensinou sobre gestão estatística da qualidade, e ajudou os japoneses a se transformarem em 10 anos na segunda maior economia do mundo em apenas 10 anos. Tudo se resume a coletar e confiar nos valiosos dados do cliente.

Quais Dados são Importantes?

Todos os dados são importantes, mas, dependendo do que você está querendo entender, uns são mais importantes do que outros. Conhecer seus dados é uma tarefa contínua, pois a cada novo conhecimento que você adquire, aparecem novas questões, que vão precisar de mais dados para serem respondidas.

Uma das primeiras informações que você vai querer conhecer é quantas visitas você recebe no site de seu produto. Para conhecer esses números, você pode usar algum relatório de estatísticas que o provedor de hospedagem oferece. Outra opção muita usada é o Google Analytics.

Com um relatório como esse, você consegue algumas informações importantes, tais como: quantidade de visitas, quantidade de visitantes únicos, quantidade páginas vistas (pageviews) e várias outras. Dependendo do sistema de estatísticas que você estiver usando, você também conseguirá ver:

  • qual a primeira e a última página visitadas durante um acesso ao seu site;
  • de onde (que país e cidade) vêm seus visitantes;
  • se eles acessaram seu site partindo de uma campanha de Google AdWords, do Facebook;
  • ou de alguma outra campanha online que você está fazendo;
  • ou se acharam seu site de forma orgânica, digitando diretamente o endereço;
  • ou buscando por algo em algum sistema de busca.

Vale lembrar que é importante ter esses relatórios de acesso não só para o seu site como também para seu produto software.

Cuidado, pois esses sistemas de relatório de visitas normalmente dão uma quantidade muito grande de informação, e é fácil se perder nesse mar de dados.

Junto com a quantidade de visitas e acessos que seu site tem, outros dados importantes que você precisa conhecer de seu produto web são:

  • Quantidade de pessoas que ficam sabendo que seu produto existe: é possível diferenciar as formas como as pessoas ficam sabendo que seu produto existe classificando-as em duas categorias, as pagas e as gratuitas. As pagas são aquelas em que você tem de investir algum dinheiro, como Google AdWords, anúncios no Facebook, anúncio em sites de conteúdo (preferencialmente ligados ao tema de seu produto) e anúncios em revistas (também preferencialmente ligados ao tema de seu produto). Já as gratuitas são aquelas em que você investe tempo e trabalho para ficar conhecido como, por exemplo, criar conteúdo relevante sobre o tema do seu site, interagir em blogs sobre o tema do seu produto, facilitar que as pessoas recomendem seu produto para seus conhecidos etc. O retorno nesse caso é mais lento, mas tem a vantagem de não ter custo financeiro, só de tempo e trabalho.
  • Quantidade de cliques gerados pelos seus anúncios ou por outros meios: essa é uma informação um pouco mais difícil de obter, pois, dependendo de sua estratégia para atrair pessoas para o seu site, essa informação não estará disponível. Os sistemas de anúncio online como Google AdWords, Facebook e anúncios em sites de conteúdo normalmente têm essa informação disponível, e o preço que cobrarão normalmente será baseado em um preço por clique.
  • Quantidade de visitantes únicos: são os novos visitantes que seu site recebe. É diferente da quantidade de visitas, pois uma mesma pessoa pode visitar seu site mais de uma vez até decidir comprar.
  • Quantidade de visitantes que se tornaram usuários: desses visitantes únicos, alguns vão se cadastrar para se tornar um usuário do seu sistema. Se você oferecer um período de experiência gratuito ou uma versão grátis sem prazo de expiração, esse número pode ser razoavelmente grande.
  • Quantidade de usuários que se tornaram clientes: findo o período de experiência, alguns de seus usuários vão querer se tornar um cliente, ou seja, vão querer pagar para usar o seu serviço. Se você estiver oferecendo uma versão gratuita de seu produto, sem prazo de expiração, você deverá ter uma versão paga que motive seus usuários a saírem da versão gratuita e a pagarem pelo uso de seu produto.

Funil de Conversão

Napoleão Bonaparte, líder político e militar francês conhecido pelas Guerras Napoleônicas – por meio das quais foi responsável por estabelecer a hegemonia francesa sobre a maior parte da Europa no início do século XIX –, teve uma grande derrota em 1812, na Campanha da Rússia. Essa campanha foi uma gigantesca operação militar intentada pelos franceses e seus aliados, que teve grande impacto sobre o desenrolar das Guerras Napoleônicas, marcando o início do declínio do Primeiro Império Francês. Nessa campanha, Napoleão usou 580.000 combatentes. Desses, sobreviveram apenas 22.000 combatentes, o restante pereceu no caminho da França até Moscou devido às dificuldades encontradas nesse caminho (frio, chuva, rios etc.).

Campanha da Rússia

Essa imagem lembra muito um funil de conversão de um site, que pode ser feito com os dados que discutimos anteriormente. O funil de conversão nos mostra quantos potenciais clientes estamos perdendo no caminho entre atrair pessoas para o site até o ponto em que uma pessoa paga para se tornar seu cliente:

Funil de conversão

O funil apresenta várias oportunidades para você entender melhor como seus usuários interagem com seu produto. Cada pedaço do funil tem suas características específicas e pode ser alargado de diferentes formas. Concentre-se em um pedaço por vez e faça seus testes. Na pior das hipóteses, se o teste for ruim, você sempre pode voltar para a situação anterior. Para um data geek, o funil deve ser o primeiro foco de dados a se obter e analisar.

No próximo capítulo, vamos ver mais duas métricas que são a consequência natural do funil de conversão: o engajamento, que mostra como seu usuário utiliza seu produto; e o churn, que mostra quantos usuários deixam de usá-lo, ajudando a identificar por que isso acontece.

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:

Mentoria e aconselhamento em desenvolvimento de produtos digitais

Tenha ajudado várias empresas a extrair mais valor e resultados de seus produtos digitais. Veja aqui como posso ajudar você e a sua empresa.

Crescimento: como priorizar o roadmap?

Essa é uma pergunta frequente de todo gestor de produtos. Quer seja um produto novo que está sendo criado agora, quer seja um produto já em pleno funcionamento, cheio de sugestões de clientes e usuários, como fazer para priorizar, ou seja, para decidir o que fazer primeiro?

Existe uma quantidade grande de técnicas. Falarei sobre algumas delas aqui e, no final da lista, vou dizer qual é a melhor. Só lhe peço que não vá agora até o final da lista para não estragar a surpresa… 😛

Valor versus custo

Uma das formas mais simples de priorizar um roadmap é fazendo uma análise de todos os itens, procurando estimar: o valor (benefício) de cada um para o negócio e para os usuários, e o custo de implementar cada item. Com esses dados em mãos, é possível até fazer um gráfico com dois eixos e colocar cada um dos itens, baseado no valor e no custo. A ideia é priorizar sempre o que tiver maior valor e menor custo, pois o benefício será obtido mais rapidamente.

Gráfico valor versus custo

Análise Kano

A análise Kano foi criada pelo Professor Noriaki Kano, da Universidade de Tokyo, para classificar os itens de um produto com base também em duas dimensões, na necessidade de um item e na satisfação que este causa no cliente.

Com isso, é possível classificar os itens em três tipos: mandatórios, satisfatórios e encantadores.

Diagrama de Kano

Por exemplo, em um carro, roda é um item mandatório, pois não há carro sem roda. Teto-solar é um item satisfatório, se seu cliente não o valoriza muito. Já ser muito silencioso é um item que encanta um cliente que aprecia essa característica. A recomendação é ter todos os mandatórios, alguns satisfatórios, mas não deixar de fora alguns encantadores para poder impressionar positivamente o cliente.

RICE

Quando cheguei na Conta Azul, deparei-me com outro método de priorização adotado pelo time de produtos, o RICE. RICE é a sigla em inglês para Reach (Alcance), Impact (Impacto), Confidence (Confiança) e Effort (Esforço). Os três primeiros itens da matriz são pontuados e, ao final, divididos pelo último.

Alcance se refere a quantas pessoas aquela tarefa vai alcançar em um determinado período de tempo, que deve ser igual para todas as features que estão sendo comparadas. Impacto estima a quantidade de pessoas que serão impactadas (use o valor 3 para um impacto massivo, 2 para um grande impacto, 1 para médio, 0.5 para pequeno e 0.25 para um impacto mínimo). Confiança aborda o quão confiante você está sobre suas estimativas (escolha entre 100% para uma alta confiança, 80% para média e 50% para baixa). Em Esforço, coloque quantas pessoas-mês a tarefa levará para ser concluída sendo o mínimo o valor 0,5, ou seja, uma pessoa por meio mês.

O cálculo matemático é bem simples:

RICE = (Alcance x Impacto x Confiança) / Esforço

Sequenciador de features

O Sequenciador de features foi criado por Paulo Caroli, da ThoughtWorks, para auxiliar no planejamento de um produto a partir de suas funcionalidades. As regras desse método, como o limite de 3 cards por linha, auxilia na conversa sobre priorização.

De acordo com seu livro Lean Inception: Como alinhar pessoas e construir o produto certo, o Sequenciador de features ajuda a organizar e visualizar as funcionalidades e sua relação com os entregáveis. O sequenciador organiza as releases do produto além do primeiro entregável. Tipicamente, times utilizando o Sequenciador de features vão vislumbrar a evolução do produto por meio de um entendimento claro das funcionalidades de cada entregável bem como a ordem dos releases.

Sequenciador de features

A imagem anterior possui um exemplo de sequenciador de features; cada funcionalidade é representada por um cartão de índice. Os post-its no lado direito representam os produtos a serem entregues.

Árvore de produto

A ideia é mais ou menos parecida com a análise de Kano: classificar os itens do roadmap de acordo com as partes de uma árvore. Raízes são a infraestrutura; caule é o que dá o suporte; galhos são os diferentes caminhos que você pode colocar no seu produto; as folhas são as funcionalidades propriamente ditas; e as flores e os frutos são as funcionalidades que realmente vão encantar o cliente.

Todo produto tem de ter raízes, caule e alguns galhos com suas respectivas folhas, mas é importante sempre incluir algumas flores e frutos para deixar seu produto encantador.

Exemplo de árvore de produto

Compre suas funcionalidades

Nessa técnica, você põe o seu cliente para trabalhar. Você mostra todos os itens que estão em seu roadmap e dá um valor para cada um deles baseado no quanto vai lhe custar fazer cada um. Em seguida, convide alguns clientes e diga para eles que eles têm X para gastar. Esse X tem de ser consideravelmente menor que a soma do valor de todos os seus itens.

Com esse X, cada cliente tem de “comprar” as funcionalidades que são mais importantes para ele e, como o dinheiro é limitado, ele é forçado a fazer escolhas do tipo “Será que pego essas duas funcionalidades, ou as troco por essa outra mais cara?”. É um exercício muito interessante e dá ao gestor de produtos um bom conhecimento sobre o comportamento do cliente.

Na Conta Azul, utilizávamos essa técnica com os contadores para priorizar o que fazer no nosso sistema para contadores e foi muito interessante ver esses contadores passando pelo dificuldade de priorizar o que fazer no produto.

UserVoice

UserVoice é um sistema de sugestões que você pode colocar dentro do seu produto. Com isso, seus usuários poderão fazer sugestões sobre ele, e poderão também votar em sugestões feitas por outros usuários. Você ainda pode limitar a quantidade de votos, forçando-os a fazer escolhas como no método anterior. Você pode usar outros sistemas de gerenciamento de sugestões.

Exemplo de sugestão no UserVoice

A que você lembrar primeiro

Jason Fried, fundador da 37signals, que agora se chama Basecamp, disse no seu livro Getting Real que, na sua empresa, a opção foi por priorizar baseado na lembrança. Eles recebem várias sugestões todos os dias, e decidiram simplesmente não anotar para não ter de depois gastar tempo contando e classificando-as.

Como sugestões aparecem todos os dias, eles as ouvem todos os dias. De tempos em tempos, eles se reúnem e discutem sobre as sugestões que se lembram, e essas são as que são tratadas e eventualmente priorizadas no roadmap dos produtos.

A melhor técnica de priorização

Como deu para perceber, existem várias maneiras de se priorizar um roadmap, todas elas bastante úteis. O que dá para concluir é que, se há tantas maneiras de se priorizar um roadmap e se todas as maneiras de se priorizar podem ser úteis, isso significa que a priorização de um roadmap não é uma ciência exata.

Temos um anseio de querer achar um método de priorização para justificar nossas escolhas. Entretanto, sempre que esse método falhar em um determinado item, que temos certeza de que seria melhor fazer antes (ou depois) do que o método diz, acabamos tentados a seguir essa nossa certeza, pondo abaixo o método.

Por isso, por mais que existam várias técnicas e métodos de priorização de roadmap, o melhor método é o bom senso. Ou seja, a capacidade do gestor de produtos de analisar as opções disponíveis e, usando-se de sua empatia, priorizar essas opções levando em conta os objetivos da empresa e as necessidades dos usuários.

O que fazer com pedidos especiais?

Ao longo da vida de seu produto, você certamente encontrará pedidos de novas funcionalidades vindas de clientes (ou da equipe comercial) que vêm acompanhados, de forma explícita ou não, de uma ameaça de que, se não fizermos essa funcionalidade, vamos perdê-los. Por outro lado, se você atender a essa demanda, em detrimento de todo o planejamento de roadmap feito, corre o risco de atrasar a entrega de funcionalidades importantes para o resto dos clientes e para os objetivos estratégicos do dono do produto de software.

O que fazer?

A resposta a essa pergunta depende muito do seu produto e de sua base de clientes. Vou explicar melhor essa resposta com um exemplo.

Na Locaweb, tínhamos dois produtos de e-mail marketing. Um deles se chama E-mail Marketing Locaweb (nome bem original, né?), e o outro é o All In Mail. Para dar um pouco da dimensão de cada produto e do tipo de cliente que cada um deles atende, aqui vão alguns números.

Tabela comparativa das diferentes ofertas de produto de e-mail marketing da Locaweb

Na tabela, podemos ver que, apesar de o e-mail Marketing da Locaweb ter 75 vezes mais clientes que o All In Mail, ele dispara somente 16,7% do total de mensagens disparadas no All In Mail. O E-mail Marketing tem uma quantidade muito maior de clientes que o All In Mail, mas são clientes bem pequenos, que usam pouco o produto se comparado aos da All In Mail.

Por esse motivo, a gestão de produtos do E-mail Marketing Locaweb não pode se dar ao luxo de atender pedidos especiais. Não pode favorecer o pedido de um único cliente em detrimento dos outros 29.999. A gestão de produtos nesse caso deve se preocupar em implementar funcionalidades que atendam a maior quantidade possível de clientes. Já a gestão de produtos do All In Mail não só pode como deve prestar total atenção aos pedidos especiais. São poucos clientes, mas são todos clientes especiais que demandam atenção personalizada.

O problema de falar sim para tudo

Quando falamos em priorizar um roadmap, uma coisa que acaba acontecendo é que acabamos atendendo absolutamente todos os pedidos, de todo mundo. Tudo é importante, pois tudo entra no roadmap, só que o que é menos importante fica para depois. A pessoa que pediu tem o alento de que “está no roadmap”, apesar de ter ficado lá para a frente, e ter boas chances de ser empurrado ainda mais para a frente se aparecer algum item mais importante.

Por que isso acontece?

O gestor de produtos acabando dizendo “sim” para pedidos que recebe por vários motivos:

  • Precisa agradar a todos: esse é um problema bastante comum do gestor de produtos, a necessidade de agradar a todos. Quando o gestor de produtos vê que a resposta “vou colocar no backlog” acalma as pessoas que estão pedindo algo, ele começa a usar essa resposta de forma indiscriminada. Com isso, o roadmap ficará enorme e bastante complexo de gerenciar. Além disso, quando a pessoa que lhe pediu algo vir que “estar no backlog” não é garantia de que será feito logo, ele não ficará feliz… :-/
  • Os dados mostram que temos de fazer: cada vez mais vejo empresas focadas em tomar decisões exclusivamente baseadas em dados. Com isso, em breve poderemos todos nós ser substituídos por algoritmos que tomarão as decisões, já que basta basear-se nos dados. Acontece que os dados nem sempre estão certos. Pode haver dados insuficientes, ou mesmo errados. Outro problema de decisões baseadas em dados é o risco de se cair em um ótimo local. A sugestão é usar dados como um dos inputs para a tomada de decisão, mas não esquecer também dos dados qualitativos, sua intuição e sua capacidade de julgamento.
  • Mas é uma funcionalidade tão pequena: toda funcionalidade, por menor que seja, implicará em mais código e mais interação. Mais código significa complexidade de código, e quanto mais complexo o código, mais difícil de manter. Mais interação significa mais complexidade para seu usuário lidar, ou seja, chances de oferecer uma experiência ruim para ele. Nenhuma funcionalidade é tão pequena que não traga complexidade de código e de interação, por isso, pondere bem se essa complexidade adicional trará benefícios para seu usuário e para o dono do software.
  • O cliente pediu e, se não fizermos, ele vai embora: esse é o momento de tomar decisões difíceis. Se você quiser agradar todos os clientes, acabará agradando nenhum. Você precisa escolher quem é o cliente para quem você está fazendo seu produto. Um produto não pode ter mais do que duas ou três personas primárias. Aliás, o recomendado é ter apenas uma persona primária; ter duas ou três já dará um trabalho razoável para conseguir gerenciar. Se o que esse cliente pediu não atende sua persona primária, você terá de ter coragem de dizer NÃO.
  • Nós sempre podemos fazer dessa nova funcionalidade mais uma opção nas configurações: mais uma vez, estamos criando complexidade sem necessidade. Como já dito, toda funcionalidade implica em complexidade de código e de interação. Colocar todas as novas funcionalidades como opcionais a serem configuradas em uma tela de configuração fará dessa tela algo bem difícil para seu usuário.
Tela de configuração de um software
  • Nossos competidores já têm: esse é um erro bem comum, basear-se nos competidores e não no seu cliente/usuário. Lembre-se: um gestor de produtos tem de se preocupar em fazer o software atender os objetivos da empresa dona do software, ao mesmo tempo que resolve um problema ou atende uma necessidade de seus clientes. É importante saber o que o competidor está fazendo, mas se o que ele estiver fazendo não tem a ver com o objetivo de sua empresa, nem com os problemas ou necessidades de seus clientes, então você não precisa fazer igual.
  • O chefe quer: existem chefes e chefes. Se o seu chefe for extremamente antenado em relação aos clientes, é importante ouvi-lo. Ele será sempre um grande aliado. Agora, se seu chefe quer uma determinada funcionalidade simplesmente porque viu em algum competidor, ou alguém falou para ele que deveria fazer assim, você deve lembrá-lo dos objetivos da empresa e dos problemas e necessidades de seus clientes que você está tentando atender com o seu produto de software.

Apesar das razões vistas, para dizer sim a todo pedido de funcionalidade que um gestor de produtos recebe, ele tem de aprender a dizer NÃO.

Dizer NÃO pode parecer difícil, mas se você tiver muito claro os objetivos de seu produto, ou seja, quais objetivos da empresa o seu produto deve alcançar, quem é seu cliente principal e qual problema desse cliente você está procurando atender, você terá os argumentos necessários para dizer NÃO a certas demandas.

Seja gentil com a pessoa que está trazendo a demanda e diga algo como:

Como dizer não

Sua sugestão é interessante e consigo entender por que você a está pedindo. Contudo, deixe-me lhe mostrar o que já temos planejado em nosso roadmap, e quais são os objetivos de cada item que está nele. Por este motivo, não conseguiremos dar a devida atenção ao seu pedido nesse momento. Você me lembra de conversarmos novamente sobre isso no futuro?

Deixe para quem está pedindo a nova funcionalidade a responsabilidade de lembrar-se de ter essa conversa novamente no futuro. Se ele não se lembrar, é porque o pedido dele não era tão importante assim. Se ele lembrar, avalie novamente o pedido e, se necessário, diga NÃO novamente.

Lidando com pedidos especiais de clientes B2B

Mencionei anteriormente que, se você tem um produto B2B focado em clientes maiores, o gestor de produto “deve prestar total atenção a solicitações especiais. Existem poucos clientes, mas todos são especiais e exigem atenção personalizada. O gestor de produto deve ter cuidado e não implementar recursos que serão usados por apenas um cliente. No entanto, solicitações de um cliente, especialmente os maiores, sempre serão uma prioridade neste cenário”.

Como gerir esses pedidos especiais

Então isso significa que o gestor de produto deve fazer tudo o que os grandes clientes exigem? A resposta curta é NÃO! Você ainda está gerindo um produto, portanto, dois aspectos importantes da gestão de produto ainda se aplicam:
A demanda normalmente vem na forma de soluções, e os grandes clientes podem ser bastante incisivos ao descrever a solução que desejam. O trabalho do gestor de produto é entender qual é o problema subjacente que levou o cliente a solicitar essa solução específica. Dica rápida: pergunte por que o cliente precisa dessa solução e o que fará assim que obtê-la. Isso fornecerá muitas informações sobre o problema do cliente.

Você está gerindo um produto, não um software personalizado. Se você implementar cada solicitação de funcionalidade dos clientes, estará criando um software personalizado para cada cliente ou, o que é ainda pior, um produto de “software frankenstein”.

A resposta mais longa é não, mas você ainda precisará gerir as solicitações especiais. Existem algumas técnicas que podem ajudá- lo a lidar com esses pedidos especiais:

  • Modularização: se você for capaz de criar seu produto como módulos que trabalham juntos em diferentes combinações para fornecer diferentes tipos de soluções, isso permitirá que sua equipe de vendas selecione e combine os módulos para atender às necessidades de seus clientes. E sempre que uma nova solicitação de funcionalidade chegar, e você descobrir o problema subjacente e decidir criar uma solução para esse problema, poderá construí-la como um módulo separado. Você pode até cobrar desse cliente pelo desenvolvimento deste novo módulo. Cobrar um cliente pelo desenvolvimento de uma nova solução, mesmo considerando que essa nova solução possa ser oferecida a outros clientes, é uma boa maneira de testar a real necessidade desse cliente. Se ele estiver disposto a pagar a você para que forneça essa solução, ele realmente precisa dela e confia em você para construí-la. SAP é um bom exemplo de soluções modulares.
  • Configuração avançada: outra maneira de personalizar seu produto sem parecer um produto “software frankenstein” é através da configuração avançada. Por exemplo, para um determinado cliente, o recurso X pode ser entregue como a sequência da etapa A, etapa B e etapa C. Para outro cliente que não deseja o recurso X, mas precisa do recurso Y, ele pode ser entregue pela sequência da etapa C, depois a etapa E, e você desativa o recurso X para este cliente. Dependendo da complexidade, também é possível fornecer essa configuração avançada por meio de linguagens de programação. Alguns exemplos são, novamente o SAP, com ABAP (Advanced Business Application Programming) e o Salesforce com Apex, que permitem que os desenvolvedores adicionem lógica de negócios à maioria dos eventos do sistema Salesforce, incluindo cliques em botões, atualizações de registros relacionados, e páginas do Visualforce.
  • Integração: outra necessidade comum das grandes empresas é ter seu produto integrado a outros produtos que elas já usam. Por exemplo, vamos imaginar que sua empresa fornece soluções de comércio eletrônico. Seu cliente contratou seu produto de comércio eletrônico e ele incluirá todo o catálogo de produtos, além de dados sobre clientes e compras em seu produto. Esse grande cliente certamente solicitará que você integre sua solução de comércio eletrônico ao ERP deles, para que eles possam faturar clientes e gerenciar seu inventário. Essa integração pode ser feita de várias maneiras: completamente manual através da redigitação de dados, troca de arquivos ou uso de uma integração via API. A melhor solução é através da API, pois fornece uma solução sem erros e em tempo real para a integração de dados entre sistemas. Por esse motivo, é muito importante que seu produto tenha APIs com as extremidades necessárias para conectar-se a outros sistemas.

Tech Sales (ou Engenharia de Vendas ou Pré-vendas)

Novos pedidos especiais surgem durante o processo de vendas. Cada uma dessas solicitações especiais tomará tempo do gestor de produto bem como da equipe de desenvolvimento do produto. A equipe precisará entender a solicitação especial, o problema subjacente e as opções de projeto de solução que podem ser usadas com outros clientes. Isso tomará tempo do gestor de produto e da equipe.

A certa altura, a equipe usará as técnicas descritas acima para lidar com solicitações especiais de forma escalável. Assim que a equipe começar a usar essas técnicas, a necessidade de interagir com os clientes para cada solicitação provavelmente persistirá ou aumentará. A equipe de vendas solicitará que o gestor de produto faça reuniões com o cliente e ajude-o a mostrar ao cliente quais são as opções técnicas disponíveis para atender à solicitação.

O primeiro passo é treinar a equipe de vendas. No entanto, isso não será suficiente. O gestor de produto continuará sendo solicitado a participar de reuniões para responder a perguntas técnicas. Para ajudar com esse problema, devemos criar uma nova função, a de Tech Sales, também conhecidas como Engenheiro de Vendas ou Consultor de Pré-venda, alguém com formação técnica que participará de discussões técnicas com o cliente durante o processo de vendas.

Às vezes essa função, por conter a palavra vendas, é colocada como liderança de vendas. É uma possibilidade, mas pode levar ao desalinhamento de incentivos. Como liderança de vendas, o incentivo é o número de vendas. Portanto, se um vendedor de tecnologia estiver demorando muito para projetar a solução e outras solicitações forem adiadas, um novo vendedor de tecnologia será contratado, aumentando o número de funcionários e, consequentemente, o custo da venda. Uma alternativa é colocar essa função sob a liderança da gestão de produto, para que o foco esteja na ativação de vendas, ou seja, fornecer à equipe de vendas as ferramentas necessárias para realizar vendas sem a necessidade de um vendedor de tecnologia.

Serviços profissionais

Supondo que tudo corra bem com a negociação e o cliente decida comprar o seu produto, se houver personalizações a serem feitas, será necessário um trabalho adicional, não importa se através de módulos, configuração avançada e/ou integração. Esse trabalho pode acabar caindo no backlog da equipe de desenvolvimento de produtos, o que não é o ideal, pois esse trabalho é específico para atender a uma determinada solicitação do cliente, enquanto que a equipe de desenvolvimento de produtos deve estar trabalhando em itens que possam ser usados pela maioria dos clientes.

Para ajudar com esse problema, devemos criar uma segunda função, chamada de serviços profissionais. Uma pessoa com essa função trabalha nesse tipo de projeto, estabelecendo um novo cliente utilizando as técnicas de personalização do produto (módulos, configuração avançada e/ou integração). Eles devem ser pessoas com habilidades técnicas capazes de executar o trabalho de personalização necessário para estabelecer o produto da nova empresa.

Os serviços profissionais podem ser realizados por uma equipe dentro da empresa que oferece o produto e/ou por terceiros. Por exemplo, para implementar o SAP, Salesforce ou Zendesk, você pode optar por usar serviços profissionais deles ou de terceiros certificados, que tenham conhecimento e experiência na implementação e personalização do software deles em muitos clientes. Este trabalho é normalmente cobrado como taxa de configuração.

Resumindo

Vimos muitas técnicas para priorizar um roadmap. Priorizar um roadmap não é uma ciência exata, e aprendemos que a melhor maneira de priorizar um roadmap é pura e simplesmente bom senso, ou seja, construir um roadmap que alinha as metas e objetivos da empresa enquanto resolve um problema ou atende a uma necessidade de clientes e usuários. Também aprendemos a dizer não às solicitações de priorização e o que é e como lidar com solicitações especiais.

Lidar com pedidos especiais pode ser uma necessidade do seu mercado, especialmente se você estiver no espaço B2B com clientes maiores. É possível criar um produto que atenda a essas solicitações especiais sem criar um produto de “software frankenstein”. Para fazer isso, o gestor de produto e a equipe de desenvolvimento de produto devem utilizar uma ou mais das técnicas conhecidas para lidar com solicitações especiais, modularização, configuração e integração avançadas. Colocar essas técnicas em prática provavelmente não será suficiente, pois a equipe de vendas ainda precisará de ajuda para apresentar as opções ao cliente e, após a venda, implementá-las. Em seguida, surgem duas novas funções, que devem estar próximas da gestão de produtos: vendas técnicas – ou engenheiro de vendas – e serviços profissionais, que podem ser internos, podem ser executados por terceiros ou por ambos.

Próximo tópico: dados!

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:

Mentoria e aconselhamento em desenvolvimento de produtos digitais

Tenha ajudado várias empresas a extrair mais valor e resultados de seus produtos digitais. Veja aqui como posso ajudar você e a sua empresa.

Incerteza e transformação digital

Um aspecto das transformações digitais que parece ser senso comum entre as pessoas que estão ou que ajudam as empresas a passar por esse processo é que o mais difícil não são as mudanças digitais e tecnológicas, mas as mudanças culturais e de mentalidade necessárias para transformação bem sucedida. Neste artigo, vou me aprofundar um pouco mais nessas mudanças culturais e de mentalidade necessárias na esperança de que possamos entender melhor e enfrentar os obstáculos que dificultam a jornada por transformações digitais bem-sucedidas.

Trabalhei quase toda a minha carreira em empresas de tecnologia, ou seja, empresas onde a tecnologia era o produto. Minha própria empresa, no início dos anos 1990, era um provedor de serviços de internet. Depois trabalhei em um data center chamado .comDominio que acabou sendo adquirido pela Equinix. Depois disso, trabalhei na Locaweb, maior provedora de serviços de internet do Brasil, e na Conta Azul, plataforma de ERP que conecta pequenos empresários a seus contadores e tudo o que eles precisam para administrar seus negócios. Ingressei no Gympass em 2018. O Gympass vende um benefício corporativo para empresas, para que possam oferecer aos seus funcionários acesso a uma rede de academias e estúdios e, mais recentemente, outros serviços de bem-estar como meditação, nutrição e apoio à saúde mental. Para o Gympass, a tecnologia não é o produto, é um ferramenta para potencializar seu produto principal. Isso me fez pensar no poder do digital para potencializar substancialmente os negócios não digitais. E essa foi minha principal motivação para ingressar na 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. Trabalho na Lopes desde meados de 2020 e tenho aprendido muito nessa jornada de transformação digital.

O impacto da incerteza em diferentes indústrias

Um artigo interessante na HBR sobre As indústrias atormentadas pela maior incerteza apresenta um gráfico em que muitas indústrias são mostradas de acordo com sua incerteza tecnológica, medida pela pesquisa e desenvolvimento da indústria (P&D) gastos como porcentagem da receita e sua incerteza de demanda , medido como uma ponderação igual da volatilidade ou mudança da receita do setor nos últimos 10 anos e a porcentagem de empresas do setor que entraram ou saíram durante o mesmo período.

Incerteza da demanda e da tecnologia por indústria

Como podemos ver, na região superior direita do gráfico podemos encontrar as indústrias de Informática e Software, ao lado das indústrias Farmacêutica, de Equipamentos Médicos e de Transporte. Essas são as indústrias onde temos que investir mais em P&D e a demanda é a mais incerta. Computadores e Software são os mais novos. Farmacêutica, Equipamentos Médicos e Transportes são mais tradicionais, com incertezas de Tecnologia e Demanda semelhantes às indústrias de computadores e software.

Quando analisamos outros setores mais tradicionais, como bancos, seguros, varejo, entretenimento, imobiliário e construção, para citar alguns exemplos, eles apresentam menor tecnologia e incertezas de demanda.

A transformação digital é mais sobre transformação do que sobre digital

Quando uma empresa tradicional decide entrar na rota da transformação digital, uma coisa que precisa ficar clara é que essa rota tem mais a ver com transformação do que digital. O aspecto digital é muito importante, pois a tecnologia é central em qualquer transformação digital. No entanto, é relativamente fácil encontrar conhecimento e especialistas que possam ajudar a entender e abordar os aspectos técnicos de uma transformação digital. Por outro lado, o aspecto de transformação de qualquer transformação digital exige mudanças de negócios e culturais que são consideravelmente mais difíceis de implementar. E para dificultar ainda mais, não há muito conhecimento disponível sobre esse assunto, então tendemos a creditar sua dificuldade a uma causa cultural e de mentalidade um tanto genérica, o que é correto, mas insuficiente para nos ajudar a lidar com o assunto.

O gráfico de incerteza de demanda e tecnologia pode nos ajudar a entender por que as mudanças de negócios e culturais em uma transformação digital podem ser tão difíceis. A empresa tradicional normalmente está acostumada a um certo nível de tecnologia e demanda incertezas. No entanto, ao entrar no mundo digital, o nível de demanda e as incertezas tecnológicas aumentam consideravelmente:

  • Indústrias de Computadores e Software a incerteza da demanda é muito alta, uma das mais altas de todas as indústrias, o que significa que o software produzido nem sempre atinge seus objetivos. Esta taxa de sucesso tem vindo a melhorar nos últimos anos com a evolução das técnicas e mentalidade de desenvolvimento e gestão de produtos digitais, mas ainda existem muitos produtos digitais que falham total ou parcialmente na obtenção dos resultados esperados e objetivos estratégicos. Isso pode ser muito frustrante para uma empresa em um setor com menos incerteza de demanda. Para minimizar a incerteza da demanda, estamos usando o liberar cedo e frequentemente mentalidade, que as pessoas de indústrias mais tradicionais precisam entender e adotar para lidar com a incerteza da demanda das indústrias de computadores e software.
  • A incerteza tecnológica exigirá da empresa tradicional o entendimento de que (1) ela terá que investir e (2) o investimento em produtos digitais é um investimento plurianual. Para ilustrar essa necessidade de investimento e seu aspecto plurianual, usarei 2 exemplos. A primeira é a Amazon. Foi fundada em junho de 1994 e começou a operar em julho de 1995. Teve uma rodada de investimento de US$ 8 milhões da Série A em junho de 1996. O IPO foi em maio de 1997 e, em seguida, a Amazon recebeu US$ 100 milhões em um investimento de capital pós-IPO em julho /2001 e só apresentou lucro no relatório de resultados do 4T2001. Então, da fundação ao lucro, foram necessários 7,5 anos e um investimento de US$ 108 milhões, mais dinheiro arrecadado de investidores anjos e no IPO. O segundo exemplo é o Nubanlk, um banco digital brasileiro fundado em maio de 2013 que começou a operar em 2014. Arrecadou US$ 1,87 bilhão da Série A até a Série G. O IPO foi em dezembro de 2021 e o Nubank recebeu US$ 1 bilhão em um pós-IPO Investimento em ações em fevereiro de 2022. Seu 1º relatório pós-IPO apresentou uma perda de US$ 66,2 milhões no 4T2021. Assim, da fundação ao IPO, foram necessários quase 8 anos e US$ 2,87 bilhões, mais dinheiro arrecadado de investidores-anjo e em seu IPO. Mesmo depois de tanto tempo e dinheiro investidos, o Nubank ainda não apresenta resultados positivos. Observe que ambas as empresas são o que costumo chamar de empresas “tradicionais nascidas digitais”, ou seja, empresas cuja indústria principal não é computador ou software, mas que foram fundadas já com o digital como parte de sua estratégia para potencializar resultados. A Amazon está no setor de varejo com baixa incerteza tecnológica e incerteza de demanda média e o Nubank está no setor bancário com incerteza de baixa tecnologia e demanda, com base no gráfico de demanda e tecnologia por setor apresentado acima.

Quanto mais distante uma indústria estiver da Indústria de Software no gráfico, maior será a mudança de transformação necessária, ou seja, a empresa precisa (1) entender que o desenvolvimento de produtos digitais pode não trazer os resultados desejados e (2) produtos digitais reserve um tempo para fornecer um retorno sobre o investimento.

As pessoas também enfrentam a transformação digital

Estou falando aqui das empresas que passam pela transformação digital e dos desafios que essas empresas enfrentam durante essa transformação, mas as empresas são feitas de pessoas, então a transformação digital realmente acontece com pessoas que precisam entender a demanda e as incertezas tecnológicas que caracterizam um transformação digital.

Esse fato de as pessoas passarem pela transformação digital parece óbvio quando falamos de empresas tradicionais, principalmente aquelas com décadas de existência como banco, varejo, drogaria, livraria, imobiliária, seguradora, restaurante e assim por diante.

No entanto, além das empresas tradicionais, existem também dois outros tipos de empresas:

  • empresas de tecnologia que vendem tecnologia, ou seja, a tecnologia é seu núcleo. Alguns exemplos são o Google com seu principal produto, Google Search e GMail. Amazon Web Services. Facebook. Instagram. WhatsApp. SAP. Salesforce. Zendesk. As empresas em que trabalhei (Locaweb e Conta Azul).
  • empresas tradicionais nascidas no digital que possuem produtos ou serviços tradicionais que podem existir sem tecnologia. No entanto, por terem incluído a tecnologia desde o início como uma capacidade estratégica, parecem empresas digitais. Exemplos são Amazon e Nubank que citei acima. Exemplos adicionais estão listados na imagem abaixo:
Empresas tradicionais nascidas digitais

Quando consideramos que a transformação digital acontece com as pessoas que fazem parte de uma empresa, fica claro que as empresas tradicionais nascidas digitais e até as empresas de tecnologia também enfrentam a transformação digital. Muitas pessoas que trabalham nessas empresas provavelmente vieram de indústrias mais tradicionais, com menos demanda e incertezas tecnológicas e terão que se adaptar a um contexto mais incerto. Por exemplo, para construir o Nubank, muitos de seus funcionários, incluindo C-level e fundadores, vieram do setor bancário, como Cristina Junqueira, que trabalhou para o Itaú antes de fundar o Nubank. Outro exemplo interessante é a CFO do Google, Ruth Porat, que trabalhou no Morgan Stanley antes de ingressar no Google.

Ser capaz de entender o contexto anterior das pessoas que estão trabalhando em uma transformação digital pode ajudar a lidar com as lutas e problemas que podemos enfrentar em uma transformação digital, especialmente com seu aspecto de transformação.

Resumindo

  • O aspecto digital da transformação digital é relativamente fácil, pois há muito conhecimento e muitos especialistas para ajudar a projetar, desenvolver e implementar produtos digitais. As técnicas de gerenciamento e desenvolvimento de produtos têm evoluído em ritmo acelerado.
  • O aspecto de transformação de uma transformação digital é mais difícil, pois não há muito conhecimento sobre isso e tendemos a creditar sua dificuldade a uma cultura e mentalidade um tanto genéricas causa.
  • As incertezas de demanda e tecnologia da indústria de software é o que dificulta a transformação digital. As empresas tradicionais que estão em contextos mais determinados lutam para entender e, consequentemente, lidar com essas incertezas.
  • As empresas tradicionais nascidas digitais e até as empresas digitais também enfrentam problemas de transformação digital, pois as pessoas que trabalham nessas empresas, incluindo C-level e fundadores, podem vir de empresas em contextos onde a demanda e a tecnologia são menos incertas.
  • Ser capaz de entender o contexto anterior das pessoas que estão trabalhando em uma transformação digital pode ajudar a lidar com o lutas e problemas que podemos enfrentar em uma tiranização digital, especialmente com seu aspecto de transformação

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:

Mentoria e aconselhamento em desenvolvimento de produtos digitais

Tenha ajudado várias empresas a extrair mais valor e resultados de seus produtos digitais. Veja aqui como posso ajudar você e a sua empresa.

Qual a diferença entre produto e projeto?

Já escrevi sobre a diferença entre gerenciamento de produtos e gerenciamento de projetos, mas acredito que há espaço para aprofundar um pouco mais as diferenças entre produto e projeto. Então, uma rápida lembrança das definições de produto e projeto:

Projeto

Um projeto em negócios e ciência geralmente é definido como um empreendimento colaborativo, muitas vezes envolvendo pesquisa ou design, que é cuidadosamente projetado para atingir um objetivo específico.

Fonte: Wikipédia

Produto

O termo produto é definido como “algo produzido por trabalho ou esforço” ou como “o resultado de um ato ou processo” e tem sua origem no verbo latino produzir(re), ‘fazer existir’.

Fonte: Wikipédia

Ou seja, enquanto o projeto é um processo com início e fim; o produto é o resultado de um processo.

Diferenças de produto e projeto

As definições acima podem ser expandidas para ajudar a entender um pouco mais as diferenças:

  • Enquanto em um projeto focamos na entrega com um caminho bem definido, em um produto focamos no resultado com objetivos bem definidos.
  • Enquanto em um projeto temos um escopo claramente definido durante o planejamento, em um produto usamos testes e validação de ideias para definir os próximos passos.
  • Enquanto uma abordagem de projeto pode funcionar em situações previsíveis, uma abordagem de produto é útil em contextos mais voláteis.
  • Enquanto um projeto tem um fim claro e bem definido, um produto não é desenhado para ter um fim em um futuro previsível.

Para nos ajudar a entender melhor essas diferenças, darei um exemplo do mundo da tecnologia e duas analogias do nosso dia a dia.

  • Na Locaweb, desde o início até por volta de 2007, utilizávamos serviços de Data Center de terceiros para hospedar todos os nossos serviços. À medida que crescemos, fez mais sentido construir nosso próprio data center e mover nossos servidores para esse novo data center, onde tínhamos melhor controle e custos reduzidos. Construir o próprio data center da Locaweb e mover todos os servidores para este data center pode ser facilmente identificado como projetos. Por outro lado, todos os serviços da Locaweb (Hospedagem, E-mail, eCommerce, etc.) podem e devem ser gerenciados como produtos. Até o data center, depois de pronto, foi (e é) gerenciado como um produto.

E agora as duas analogias do nosso dia a dia para ajudar a ilustrar a diferença entre projeto e produto::

  • A construção de um novo prédio de apartamentos é tipicamente um projeto, incluindo todo o planejamento necessário não apenas para construir o prédio, mas também para vender todas as suas unidades de apartamentos. Por outro lado, assim que o prédio está pronto para uso e as famílias se mudam para seus novos apartamentos, chega uma fase em que podemos fazer a analogia do prédio como um produto: manutenção do apartamento, administração do condomínio, aluguel, aquisição.
  • Quando duas pessoas se casam, também é fácil ver um projeto e um produto. A cerimônia de casamento, festa, lua de mel, morar juntos, todos esses eventos devem ser gerenciados como projetos. Por outro lado, o seu dia-a-dia com seu parceiro de casamento, morar junto, formar uma família, ter filhos, netos podem ser vistos como um produto.

Jogos finitos e infinitos

Simon Sinek, autor de “Start with Why” e “Leaders Eat Last”, lançou em 2019 um livro muito interessante chamado “The Infinite Game” onde construiu em cima do argumento do clássico livro “Finite and Infinite Games”, de James P. Carse, um acadêmico americano que foi professor emérito de história e literatura da religião na Universidade de Nova York. Em seu livro, Carse explica que enquanto um jogo finito tem um fim e um vencedor claro, como esportes, política e guerra, jogos infinitos, como nossa vida, cidades, países, carreira, são aquelas atividades que não têm um fim claro e definido. e não necessariamente um vencedor. De acordo com Carse:

Um jogo finito é jogado com o propósito de ganhar, um jogo infinito com o propósito de continuar o jogo.

Sinek “começou a ver que muitas das lutas que as organizações enfrentam existem simplesmente porque seus líderes estavam jogando com uma mentalidade finita em um jogo que não tem fim. organizações mais inspiradoras.”

É fácil ver que projetos são jogos finitos enquanto produtos são jogos infinitos.

Quando me perguntam sobre a diferença entre um projeto e um produto, tenho usado as duas analogias acima, prédio de apartamentos e casamento para ajudar a ilustrar esses conceitos, com bom feedback. Espero que agora que consegui escrever esses conceitos e analogias, eles possam ajudar mais pessoas.

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:

Mentoria e aconselhamento em desenvolvimento de produtos digitais

Tenha ajudado várias empresas a extrair mais valor e resultados de seus produtos digitais. Veja aqui como posso ajudar você e a sua empresa.