Category Archives: Product Management

Growth: financial metrics

Posted on by
Reply

When I talked about the importance of being a data geek in the previous chapter, I explained the conversion funnel, which is formed by a set of data that we can consider short-termed, because within a few days (or even hours) you can notice trends, take conclusions, create hypotheses and validate them, whether talking to your users or making experiments and measuring the results.

I also talked about engagement metrics, which show how your users interact with your product, and about churn, both from the client and revenue. That will help you to understand how many clients are no longer clients, why they gave up, and what is the impact of it on your revenue.

Aside from these data, there are other ones that take more time to be established and start to show some tendency, but that should be monitored from your product’s first month. These are the financial metrics, that can be categorized in global numbers (revenue and costs) and individual numbers: CAC (Customer Acquisition Cost), LT (Lifetime), and LTV (Lifetime Value).

Global numbers: revenue and costs

Revenue is the money you get when people use your product. Cost is any money that has to be spent or given up in order to get your product going. Basically, this revenue will be used to pay for your costs. When you can afford to pay for your monthly costs, the surplus will be used to offset the investment of the months when the monthly revenue doesn’t cover the costs.

Both revenue and costs should be checked out month over month. It is important to categorize your costs, so it can help you to understand where you are spending the most and where you can save. I use to put costs under 3 categories:

  • Infrastructure: it’s all the necessary costs to keep the service running. In this category, I include website and app hosting costs, domain register, tools for e-mail marketing, SEO, A/B tests, online chat system, etc. Usually, these costs are recurrent; therefore, they require a lot of attention every time you hire a new service like the above.
  • Development: here are all the costs to develop and implement new features in your website or application, including programming, interface development, visual design, logo design, etc.
  • Marketing: every investment you do to attract clients, such as AdWords, Facebook ads, ads on websites, magazines, newspapers, and TV. We should also include here the costs of flyer printing and distribution, coupons, folders, etc. In the beginning, you will very likely need to invest time in free tools to attract clients who, in spite of being long-termed, will help through the months to save on marketing expenses or, if you decide to continue to invest in paid publicity, will help you to increase your revenue.

In order to have a profitable product, the monthly income should be higher than the monthly expenses. It is as simple as that. However, it is easier said than done.

Individual numbers: CAC, LT, and LTV

The revenue and the costs are global indicators of your web product’s health. It is important to have individual indicators, that is, one for each client of yours.

There are three very important indicators:

  • CAC: is the Customer Acquisition Cost. It is the sum of the associated costs with finding and getting the attention of potential clients, bringing them to your site, converting them into users of your web product, and later, into paying users. For example, imagine that you have only invested on Google AdWords and, on a given month, you have spent $1,000 and got 10 new clients in that month. Dividing $1,000 per 10, you’ll have a CAC of $100. That is, your cost for getting each client is $100.
  • LT: it’s the Lifetime of your client. That is, how long on average a client is your client. This number only makes sense when you have a recurrent revenue stream. Using the previous example, let’s imagine that the LT of clients you have acquired is 20 months.
  • LTV: it’s the Lifetime Value, or the value of a client while he stays as your client. It’s the revenue this client generates while still your client. Following the previous example, let’s imagine this client generates monthly revenue of $8. Multiplying the LT of 20 months by the $8 per month gives us an LTV of $160.

In these definitions, it’s easy to see that your product will be as profitable as higher is the LT and the LTV and that you need your LTV higher than your CAC.

In this example, we have an LTV of $160 and a CAC of $100, which shows that we have a profitable situation. It is necessary to follow up closely on these numbers, month by month. If in a given month the LTV continues at $160 and the CAC goes up to more than $160, it’s necessary to review the client acquisition efforts. Also, you should study ways to increase the LTV, augment the LT, and/or augment the monthly value.

Revenue churn

Revenue churn is a measure of the lost revenue for a business model based on subscriptions, calculated in terms of client churn and the total revenue over a period.

You can calculate it as follows:

Monthly revenue churn = revenue from clients who canceled on the month / total revenue of the month.

In order for your product to grow, it is necessary to have an increase in the monthly revenue higher than your monthly revenue churn.

There is an important difference between revenue churn and client churn. Client churn will always be a positive number, but the revenue churn can end up being negative. How? The revenue growth from your existent clients must be higher than the revenue churn from clients who are canceling the service on that month, without considering the revenue from new clients on that given month.

Client churn is the number of clients who are no longer users or clients. It is important to know how many are they, and the reasons why that happened, because you need this data to improve your product, to reduce the churn.

See in the following picture the difference between client churn and revenue churn:

Negative churn

How is it possible to have negative churn?

The negative churn occurs when your existing clients use more of your software product and they have to pay for it, and revenue gain exceeds revenue loss from existing customers who purchase less over time, including clients churn. For example, when clients upgrade a service plan with more features, when they hire additional services, when they pay for additional use, or when they buy more access accounts.

This will make your product grow more than the number of new sales per month, because with a negative churn, even if you don’t have any new sales, your revenue will grow due to the revenue increase from existing clients. That’s why negative churn is considered the “Holy Grail” of products that have a business model based on subscriptions.

In the next chapter, we’ll see the best metrics of all, in my opinion: the loyalty metrics.

Mentoring and advice on digital product development

I’ve been helping several companies extract more value and results from their digital products. Check here how I can help you and your company.

Digital Product Management Books

Do you work with digital products? Do you want to know more about how to manage a digital product to increase its chances of success, solve its user’s problems and achieve the company objectives? Check out my Digital Product Management bundle with my 3 books where I share what I learned during my 30+ years of experience in creating and managing digital products:

You can also acquire the books individually, by clicking on their titles above.

Crescimento: métricas financeiras

Posted on by
Reply

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

Posted on by
1

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:

Growth: Engagement and churn

Posted on by
Reply

Once you get to bring in users (free or paid) to use your product, your next concern is related to the engagement from these users, that is, are they using the product? Are they solving the problem that the product is supposed to solve? How many times a day (or a week, or a month) your product is being used? For how long? How is it being used?

Engagement

It is very important to find metrics to measure engagement. For instance, for a product to send e-mail marketing, some engagement and usage metrics are:

  • how many times per day does the person access his/her inbox,
  • how many campaigns go off per month,
  • how many clicks this campaign had,
  • how many messages were sent with the incorrect e-mail address,
  • how many messages generated complaints.

Note that each product has different engagement and usage metrics. Each product manager must select metrics to track his/her specific product.

Have you ever stopped and thought about how many times a day you use your cell phone? What do you use to access it? WhatsApp? Facebook? Instagram? Can you tell that you are deeply engaged with these applications?

Promoting engagement should be one of the concerns of the product manager. In 2013, Nir Eyal launched his book called Hooked: How to Build Habit-Forming Products, in which he explains the theory behind these products that just end up entering our daily lives. It is a great book to understand more about this theme.

There are some strategies that can help you to increase your product’s engagement and usage. These techniques are called lock-in.

  • APIs: Short for Application Programming Interface, API is a way of giving access to your product, to the data that are stored and to the routines it executes to other software. When someone creates a new software using the APIs of your product, there’s a great chance of increasing the engagement with it.
  • Incentive to use: you can do promotions to incentive the use of your product. For instance, if your product has usage quota, you can increase this quota as the time goes by. be one of the concerns of the product manager. In 2013, Nir Eyal launched his book called Hooked: How to Build Habit-Forming Products [^hooked], in which he explains the theory behind these products that just end up entering our daily lives. It is a great book to understand more about this theme.
Churn example

Despite the fact that churn was greater than 20% every month, growth in the year was 73 new customers.

Why is it possible to grow even with a high monthly churn?

There are two reasons. The first, which I have already mentioned, is that it is necessary to have a greater inflow of customers than the amount that goes out.

The second is that churn varies based on the age of the customer. It is common to have cases where churn is high in the first month, because the customer did not like the service and decided to cancel right away. Or in the third or sixth month if your billing is quarterly or semi-annually. Some people call it premature churn.

Premature churn, despite being common, is something that can and should be reduced. You do this:

  • Aligning the customer’s expectations that you created in them by promoting your product with what they will find when they start using it.
  • Ensuring that the first experiences of using your product are very good and that your customer can achieve their goals in these first experiences.
  • Keeping your product useful to your customer over the months and years, investing in understanding your customer and their problems, and updating your product so it continues to solve your customer’s problems.

The concepts of churn and engagement go hand in hand, because the more engaged a user is, the less likely they are to cancel the service. So, a good way to predict the churn of a given customer is to track their engagement.

For example, if you’ve launched a distance learning product and track the usage of that product, you’ll likely see that the churn rate is higher for customers who have never attended the class. Review the previous lock-in thread for tactics to increase engagement and decrease churn.

Data science, machine learning, and product management

In recent years, the terms data science, machine learning, and artificial intelligence have appeared recurrently and abundantly. These terms are quite important for product managers. No wonder I dedicate 5 chapters of the book to subjects related to data and metrics.

As I mentioned in the previous chapter, the product manager must be a data geek, that is, a person who is always thinking about how to learn more from data. What is a person’s behavior in the months and days before unsubscribing to your product? And the behavior of a person who upgrades? What is the behavior of a user who says he is satisfied with your product? And what do you say very satisfied? If your product has multiple features, which is the most popular? Which generates greater satisfaction? What is the typical usage pattern for your product? If an atypical usage pattern appears, what does it mean? These are examples of some questions that the product manager can ask and that will have their answers in the product metrics. And with each new answer obtained, it is very likely that the product manager will want to ask more questions.

To find the answers to your questions, it is important that the product manager knows data science techniques and knows how to extract the answers to his questions himself, whether through data extraction and visualization tools or by running SQL in the product database. If the product manager does not have this independence and needs other people to extract the data for him, this can hinder the evolution of the product.

As this learning from the data takes place, it is likely that the product manager will begin to see opportunities to embed these learnings into the product. For example, a product manager of a CRM software may notice, after analyzing the usage and engagement data of the product, that customers end up canceling less when they are using the commercial proposal generation functionality. Once that discovery is made, he can make a change to his product to make it easier and more immediate to use this functionality and, in doing so, decrease customer churn by making them more engaged. This is a way to infuse data science into your product.

Machine learning, which is nothing more than a way of implementing artificial intelligence, is when we program machines to learn from data, and the more data the machine has in its hand, the more it will learn. In other words, it’s a way to insert data science into the product to make it better. The more you use a particular product, the more data is available to the team that develops the product to get to know your user and how they use that product. For example, the more purchases you make at an online store, the more it learns about your shopping habits and the easier it is for the store’s software to make recommendations that interest you. The same goes for Netflix and Spotify suggestions. In these cases, it is common for the store to compare its use with the use of people who show similar behavior to make suggestions such as “whoever bought this item also bought these other items”.

That’s why the product manager and the entire team that develops the product must know and know how to use data science, machine learning, and artificial intelligence in their daily lives. They are powerful tools to help you increase your chances of building a successful product.

In the next chapter, we will continue with the topic of metrics, focusing on financial and long-term metrics. Let’s also understand the concept of negative churn, the “Holy Grail” of products with a subscription-based business model.

Mentoring and advice on digital product development

I’ve been helping several companies to get more value and results from their digital products. Check here how I can help you and your company.

Digital Product Management Books

Do you work with digital products? Do you want to know more about how to manage a digital product to increase its chances of success, solve its user’s problems and achieve the company objectives? Check out my Digital Product Management bundle with my 3 books where I share what I learned during my 30+ years of experience in creating and managing digital products:

You can also acquire the books individually, by clicking on their titles above.

Crescimento: engajamento e churn

Posted on by
Reply

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 :

  • APIs – Application 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:

Another example of an MVD – Minimum Viable Discovery

Posted on by
Reply

Lopes is the biggest real estate company in Brazil, where I’m leading the digital transformation efforts. A new hire who came from an e-commerce site mentioned that app push notifications generated more leads and had greater conversion rates than SMS and email marketing. We got interested in testing this hypothesis, but always with the MVD – Minimum Viable Discovery mindset that I explained earlier.

How could we test this hypothesis as fast and cheaply as possible? Building an entire native app with all the features of our existing website would take months. Even if we scoped it down a lot, with the minimum to deliver some value to the user, it still would take many weeks.

Since our website is responsive, we devise a simple solution to test the hypothesis. We decided to create a webview app, a simpler solution than building a native app, eve if we scoped it to a minimum.

By the way, this is how Facebook and Linkedin launched their first mobile apps as well. Only when they the results generated by a mobile app, and proved that a native version would bring even more results, they decided to invest in building their native apps.

Here’s Lopes’ mobile app:

With this mobile app we were able to confirm that push notification generated more leads and had greater conversion rates than SMS and email marketing. We launched this app in early 2021.

I already heard that MVP doesn’t scale, it is just to test a solution hypothesis and then, if the solution hypothesis, we should work on delivering the solution in a scalable manner. As with everything related to product management, it depends! In our case, untill now we haven’t had the need to build a native version of this mobile app. The webview version is working quite fine for our needs and users seem to be ok with it as well. Maybe in the future we’ll have the need to build a native app but, at least for now, after more than one year that we launched our webview mobile app, there’s still no need to build the native mobile app.

You cantry Lopes App for Android or iOS.

Summing up

  • MVD – Minimal Viable Discovery mindset is essential to deliver results as fast as possible. For instance, why building a native mobile app to test some hypothesis if a webview is enough to test it?
  • The “MVP doesn’t scale” affirmation is not necessarily true. As everything related to product management, it depends. In our case, after more than a year after launching the MVP we created to test our Discovery Solution hypothesis, our webview app, we haven’t had the need to build a native app.

Mentoring and advice on digital product development

I’ve been helping several companies extract more value and results from their digital products. Check here how I can help you and your company.

Digital Product Management Books

Do you work with digital products? Do you want to know more about how to manage a digital product to increase its chances of success, solve its user’s problems and achieve the company objectives? Check out my Digital Product Management bundle with my 3 books where I share what I learned during my 30+ years of experience in creating and managing digital products:

You can also acquire the books individually, by clicking on their titles above.

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

Posted on by
Reply

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:

Why business people hate discovery

Posted on by
Reply

There are basically two reasons, one of them has to do with mindset and the other one has to do with the discovery process.

The one that has to do with mindset is clear when we hear phrases like “Why do you want to do a discovery? I’m the business person so I’m the person that understands the most about our business problems/needs and how to solve them. You just have to implement what I say”.

Sometimes this aversion is rooted in the “business demands => technology implements” mindset that I mentioned earlier. This was how things were made in the past, without any need for discovery, because “business people are the ones interacting with customers so they always know what is best for the customers”.

However, most frequently this aversion to the discovery process is motivated by the business person’s past experiences where the discovery process was too long. The business person needs the solution to his problems implemented as quickly as possible, so she can benefit from the results that this demand may generate. The business person can’t afford lengthy discovery processes.

It’s very difficult, but not impossible to change this mindset. It requires patience and repetition:

  • Ask why: by asking why the business person is demanding the implementation of a certain feature, we have the opportunity to show this person a very simple discovery tactic that helps both the product manager and the business person to find other solutions hypotheses to the problem. We change to a discovery mode without using the word discovery. After a few times applying this tactic, we can mention to the person that understanding the why of a certain demand, generating solution hypotheses, and testing these solution hypotheses is the process of discovery and it’s based on the product manager and the product development team needs to find the easiest and quick to implement the solution.
  • Learn about the business: sometimes the business person believes that she knows more about the business than the product manager. This normally happens when a new product manager joins a company and still doesn’t know much about its business. To solve this perception from the business person, the product manager needs to find ways to learn about the business as quickly as possible. Talk to business people, talk to customers, read about the business, attend short-term courses about the business, and go to conferences about the business topic. Product managers need to understand the business in order to discuss business issues with the business person.
  • Shorten the discovery process: sometimes discoveries take quite long. A few weeks, one month, more than one month. Meanwhile, the business person has a problem that needs a solution as quickly as possible so she can benefit from the expected outcome that the solution of the problem may generate. This happens especially when the discovery process is focused only on the problem discovery. If the product manager is able to cycle fast between problem discovery and solution discovery, the business person may see the product development team working sooner rather than later on a solution hypothesis for the problem and may have her expectations for a solution calmed down.

MVD – Minimal Viable Discovery

Unfortunately, this third reason, the lengthy discovery process, happens quite often and this is our fault, especially when we aim to understand everything about a problem prior to testing solutions.

As I mentioned earlier, the discovery process has two sides, problem discovery, and solution discovery. We don’t need to know everything about a problem prior to testing, i.e., discovering solutions. The solution discovery is a powerful tool for us to understand more about the problem. For this reason, we need to cycle as quickly as possible between problem discovery and solution discovery. The faster we do so, the faster we understand the problem and the faster we discover a solution for the problem.

Also, if we do a complete problem discovery to understand everything about the problem, we may end up with so many sub-problems that will make the solution discovery process also very lengthy and the delivery will take a lot of time to be completed.

The product development community talks a lot about MVP, the minimal viable product, but we cannot forget this is not only about fast delivery of a minimal product, but also a lean discovery process. It’s time to adopt an MVD – Minimal Viable Discovery mindset, i.e., what’s the minimal problem discovery we need to make in order to test the minimal solution hypotheses and deliver the one that works and actually solves the problem?

Lopes’ broker app

A good example to illustrate this is the Lopes’ broker app. Lopes is the biggest real estate company in Brazil, where I’m leading the digital transformation efforts. When I joined the company the team was working on an “MVP” of this app. I put in quotes because it was under development for 5 months and there were still 2 to 3 months to go. When I dig a bit deeper into the process and why it was taking so long, I’ve learned a few things:

  • The discovery process took anywhere between 7 to 10 months!
  • The discovery process was focused only on the problem discovery.
  • The discovery process was internal, i.e., demand gathering from business areas and benchmarking with other broker apps available in the market.
  • The “MVP” was scoped as having 58 requirements/features and there were already 90 requirements/features scoped for future releases.
  • The main pain point was based on a hypothesis that, if the broker received the lead, i.e., a potential customer interested in a property, the faster she received this lead and interacted with the customer, the greater the chances of closing a deal.
  • Then, the team analyzed the broker journey and realized that when a lead arrives, the broker needs to search Lopes potential customers database to check if the potential customer is already in our database and if it is not, register the user data in our database.
  • And then, from this broker journey analysis they realized that, if the broker was able to send a few other property options to the potential customer, it would potentially increase the chances of closing a deal.
  • This created the scope to be implemented that took 7 to 10 months of discovery plus 7 to 8 months of delivery to build the app “MVP”.

There are a few points to highlight from the process above:

  • The discovery process was too long, which created a huge list of problems to be solved.
  • The solution discovery phase was not performed. The team went from problem discovery directly to delivery, without any opportunity to test some solution hypotheses.
  • The huge list of problems to be solved impacted directly the delivery process making it very long too.
  • If the solution discovery was used as soon as the main problem was discovered, the hypothesis that the faster she received this lead and interacted with the customer, the greater the chances of closing a deal, probably the team would be able to devise a simpler solution, that probably would take days, not months to be implemented.

Regarding this last point, after a few discussions, we thought about an app with only a push notification for each lead and the broker could continue the tasks as she already did them. And it could be even simpler to test the solution hypotheses by not to even building an app, but by sending an SMS or a WhatsApp message to the broker. An A/B test could be made to compare the closing rates of the brokers who received SMS notifications versus the closing rates of brokers that didn’t receive them.

We actually ended up implementing the SMS notification, it took us 10 days to implement, and right after that, we were able to test the hypothesis that the faster a broker received a lead and interacted with the customer, the greater the chances of closing a deal.

The best discovery method is called delivery

I already mentioned that one of the reasons to deliver early and often is that the moment of truth for your product is when a product is in front of its users, being used in the context where it is supposed to be used. It doesn’t matter how much research, interviews, and prototypes you do, the moment of truth, that is, the moment when you will know if your product is, in fact, the solution to a problem of a group of people, is when the product is in your customers’ hands, in the context where they need the product.

So the best way to discover if a solution hypothesis works is actually implementing it and presenting it to potential users that may have the problem that you discovered during the problem discovery.

For many solution hypotheses, we don’t need to build a complete product to test. Today there are many low-code and no-code tools that allow us to build simple solutions. And some of these tools exist for quite a while, like presentations and forms. At Gympass we tested some solution hypotheses that we had to solve the problem we discovered of bringing new options to people that didn’t want to go to the gym but wanted to pursue a healthier lifestyle.

The solution hypothesis was to partner with wellness apps and provide this app to our users for a monthly subscription fee. This new idea had two main hypotheses that we needed to test:

  • Application providers willingness to partner. Application providers, like gyms, are used to the recurring monthly revenue model. Would they accept to be paid per day of use?
  • Our user base willingness to pay. Is our user base interested in paying a monthly fee to access the applications?

To test our first hypothesis, we built a deck with the value proposition that we planned to deliver to the partners and talked to some potential partners. We presented the opportunity to 8 potential partners, of whom 6 showed interest and 4 decided to join our proof of concept. NEOU, a workout app, 8fit, a workout and nutrition app, Tecnonutri, a nutrition app, and ZenApp a meditation app.

Okay, our first hypothesis was validated with just a simple slide deck. No product was built. Now we needed to validate the second hypothesis, the willingness to subscribe. Is our user willing to pay to access these applications through Gympass?

To test our second hypothesis, we built a simple form, where we described the product and asked for the user’s name, email, and company. After the user provided this information, he was directed to a Paypal subscription page, where he had to provide his credit card details to subscribe to the service. The user would receive an email with the activation link for each application. There was no real product, no logged-in area, just a form to test interest and an email with links to the applications.

The first version of Gympass Wellness

So use the no-code or low-code tools options available to build your solution hypothesis to make it easier and faster to go through the solution discovery. As a side-effect, business people will start to understand, appreciate and even want to participate in your next discoveries.

Summing up

  • Business people dislike discoveries because of 3 main reasons. (1) They believe they know more about the business, the clients, and what they need. (2) They may have had past experiences where the discovery took too long. (3) They are used to a “business demands => technology implements” model.
  • Changing this mindset requires patience and repetition. Three things a product manager should do continuously to help change this mindset. (1) Ask why the person is asking to implement the demanded feature. (2) Learn about the business. (3) Shorten the discovery process.
  • In order to shorten the discovery process, we should think in terms of an MVD mindset, i.e., minimal viable discovery, where we discover enough about the problem in order to generate and test the solution hypothesis as fast as possible.
  • The best discovery method is called delivery. The moment of truth of any solution hypothesis is when we are able to present it to the potential user in her own context where she faces the problem we want to solve. Today we have many low-code and no-code solutions that help us build our solution hypothesis to make it easier and faster to go through the solution discovery.
  • As a side-effect, business people will start to understand, appreciate and even want to participate in your next discoveries.

Digital Product Management Books

Do you work with digital products? Do you want to know more about how to manage a digital product to increase its chances of success, solve its user’s problems and achieve the company objectives? Check out my Digital Product Management bundle with my 3 books where I share what I learned during my 30+ years of experience in creating and managing digital products:

You can also acquire the books individually, by clicking on their titles above.

Mentoring and advice on digital product development

I’ve been helping several companies extract more value and results from their digital products. Check here how I can help you and your company.

Porque as pessoas de negócios odeiam discovery

Posted on by
Reply

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

Posted on by
1

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.