Innovation: Focus on the problem

The first step to creating a new software product is to understand the problem. It is very tempting, as you begin to understand the problem, to go on and seek solutions. Human nature is to solve problems.

Every software developer has some story to tell about demands that goes like this: “So, I need a system that does this and that, I need to have a field so I can type this information and it should give me a report that shows this.” Then, when the system is delivered, the person says “Well, this helps me, but now I also need a field to insert these other data and I need the system to export a file .txt with commas and that end of line marker.” In other words, demands come in the shape of solutions and normally don’t even mention the problem to be solved.

Next, I’ll share some techniques to focus on the problem.


It is a good way of understanding clients, the problems they have, the context in which these problems happen, and what motivates their solution. However, it is necessary to be careful, because the respondent will try to hand out the solution of what is thought to be the problem. You must be careful not to belittle the suggestion but should always keep the conversation focused on the problem.

The interview in which you talk directly to your client is considered a qualitative method, that is, you ask a few questions but get the opportunity to deepen the answers.

Next, there is a set of questions that will help to keep the conversation focused on the problem:

  • Tell me more about your problem.
  • What is the greatest difficulty you have regarding this problem?
  • What motivates you to wanting this problem solved?
  • Where does this problem usually happen?
  • When did it happen for the last time? What happened?
  • Why was it difficult/complicated/bad?
  • Did you manage to find a solution? Which one(s)?
  • What didn’t you like about the solutions you found?

For instance, let’s go back to the subject of the car and the cart of Henry Ford. Now imagine a dialogue between Henry Ford and a hypothetical Mr. Smith, a possible buyer for Ford’s product at that timeframe:

Ford: Mr. Smith, what distresses you the most?

Smith: Mr. Ford, the most distressful thing for me is that I don’t spend too much time with my family.

Ford: And why is that?

Smith: Because I spend too much time in the cart going from one place to another. If I could put one more horse to pull my cart it would go faster and I could spend more time with my family.

Ford: Oh, I see your problem, and I have an even better solution for you — it’s called car.

Do you think that Henry Ford got the problem? Or that he understood the solution Mr. Smith presented to him and developed a solution based on that suggestion? Do you think the real problem of Mr. Smith was that he didn’t spend too much time with his family?

Let’s try using the same questions shown previously to see if we can get the problem:

Ford: Mr. Smith, what distresses you the most?

Smith: Mr. Ford, the most distressful thing for me is that I don’t spend too much time with my family.

Ford: And what is the greatest difficulty you have regarding this problem?

Smith: I spend too much time at work, and going from one place to another, without talking to people.

Ford: What motivates you to wanting this problem solved?

Smith: I have small children and, because of work, I spend too much time out of home. When I get home, my kids are already asleep.

Ford: Where does this problem usually happen?

Smith: At work.

Ford: When did it happen for the last time? What happened?

Smith: Practically every day. It happened yesterday. I think I manage to get home in time to see my kids still awake once a week…

Ford: Why was it difficult/complicated/bad?

Smith: Because it has taken me away from the kids.

Ford: Did you manage to find a solution? Which one(s)?

Smith: I got off from work earlier.

Ford: What didn’t you like about the solutions you found?

Smith: The work piled up on the other days.

Note that this conversation can generate a solution such as the invention of the car to help Mr. Smith to get home faster. However, it could also be the motivation for creating a more efficient work process or a machine that would do the work for Mr. Smith.

You might have a solution in mind. But consider having a real interview, focusing on the questions for really understanding the client’s problem.


Another way of obtaining information from clients is through surveys. This method is considered quantitative because it seeks to survey a considerable amount of people in order to get what is known to be of statistical relevance. That is, for being confident that the results obtained weren’t got by chance.

For example, in case you ask in a survey if a person has iPhone or Android, and only get two people to answer, that is, only two answers — being both iPhone, both Android or one iPhone and the other Android — it is very difficult to reach a conclusion. But, if you have many more answers, you have bigger chances to picture the real world in your survey.

There are great tools for online surveys, such as Google Form and Survey Monkey. There is also a Brazilian tool called OpinionBox that, besides building your questionnaire and collecting the answers, allows you to select people for responding it based on the profile criteria you specify.

Surveys don’t have to be necessarily taken online. You can also perform them by phone or live. There are companies that can help you collect the answers.

Deciding to do a survey is easy, but building the questionnaire is hard. The first step is to have your survey goal very clear. Then, create your questions with these two main rules in mind:

  1. Be brief. The shorter your survey, the bigger are the chances of getting a good number of answers and guaranteeing a high statistical relevance.
  2. Be clear. Especially in online surveys, when you are not interacting with the respondent, there are big chances of the person misinterpreting your question. One good way of testing your questionnaire is to test it live with some people. Check if they understand each question, or if they have some difficulties in comprehending some part of it.

Check some examples of bad questions that could bring up some misguided interpretations or mix up the quality of the answers, and suggestions of how these questions can be improved:

  • Original question: How short was Napoleon?
  • Improved version: What was Napoleon’s height?
  • Original question: Should concerned parents use compulsory child seats in the car?
  • Improved version: Do you think the use of especial child seats in the car should be compulsory?
  • Original question: Where do you like to drink beer?
  • Improved version: Break into two questions: Do you like drinking beer? If yes, where?
  • Original question: In your current job, what is your satisfaction level regarding salary and benefits?
  • Improved version: Break into two questions: What is your satisfaction level with your salary in your current job? What is your satisfaction level with your benefits in your current job?
  • Original question: Do you always have breakfast? Possible answers: Yes / No.
  • Improved version: How many days a week do you have breakfast? Possible answers: Everyday / 5-6 days / 3-4 days / 1-2 days / I don’t have breakfast.


Another very useful technique to understand the problem is to observe. Seeing the client-facing the problem or having a need, in the context that it occurs, can be inspiring!

Observation is a qualitative way of understanding a problem. In order to make a good observation, be prepared; that is, hold in your hands a set of hypotheses. In each round of observation, re-evaluate your hypotheses and adjust them, if necessary. Usually, after 6 or 8 observations, you can already notice a pattern.

Observation may or may not have the observer’s interference. For example, if you are observing consumption habits in a drugstore, you can watch people without them noticing you. But in a usability test, in which you invite people to test your software, people will know that you are observing them. The observations can be complemented with interviews, helping to improve the quality of the findings.

A very useful technique to find out problems in the use of the software is to observe what the user does 10 minutes before and 10 minutes after using it. For example, if the user catches information in some other system to insert into the software. Maybe here there’s an opportunity for you to catch information from the other system automatically. And if, after using it, the user pastes information to a spreadsheet for building a graphic, eventually your software could spare the user from this work and automatically build this graphic.

Observation usually is depicted as a qualitative method. But you can and should treat it as a quantitative observation. For such, observe the user and some important metrics such as statistics of access and use, engagement, NPS, revenue, new clients, churn, etc. In other words, it is a way of observing the users’ behavior while they engage with your software.

Problem mindset vs solution mindset

When we hurry to launch an MVP, we are creating a solution for a problem. However, a very important step to creating a good solution is the understanding of the problem.

It is human nature to jump into solution mode when we learn about a problem. When we hear about a problem, we immediately start thinking about solutions. However, the more time we spend learning about the problem, the easier it will be to find a solution and good chances are that this solution will be simpler and faster to implement than the first solution we think about.

Here’s a great Albert Einstein quote:

“If I had an hour to solve a problem I’d spend 55 minutes thinking about the problem and five minutes thinking about solutions.”

Einstein believed the quality of the solution you generate is in direct proportion to your ability to identify and understand the problem you hope to solve.

Fischer Space Pen

Let me tell you a short story to illustrate this. During the space race, scientists were faced with the issue of writing in space where there’s no gravity to make the ink go down in a ballpoint pen. Americans started their R&D efforts and after some time and a few million dollars, they built a pen with a small engine that pumps ink to the paper, even with no gravity. Meanwhile, Russians decided to use pencils, which can do the job of writing in no gravity environments.

That focus on solutions, without a good understanding of the problem and the motivation to have this problem solved, can be quite harmful. It can make us spend unnecessary time and money to get to sub-optimal solutions. This is a cultural issue, i.e., a behavior that we can and must change. The first step to changing a behavior is recognizing it when it happens. When you, as a product manager or a product development team member, receive a request to implement something, ask the person who brought the request what is the problem that this “something” is supposed to solve and why there’s a need to solve that problem.

Here are some examples from the companies I worked for.

At Locaweb, a web hosting provider in Brazil, the hosting and email services may stop working due to external factors such as the domain associated with the hosting and email not being renewed.

  • Original solution:, the Brazilian registrar for .br domains released an API to allow Locaweb to charge the customer domain on behalf of At first, the idea seems good, since Locaweb billing the domain looks like the easiest way to guarantee that the customer knows that it has to pay for the domain registration to maintain the hosting and email services functioning properly. However, when we analyzed deeper, we saw that this solution could generate some problems. The customer would be billed twice for the same domain registration because the would continue billing the domain. What happens if the customer pays both bills? And if she pays only And if she pays only Locaweb? In addition, implementing a new type of billing where we will bill for a third party service was something new to the Locaweb team. New processes would have to be carefully designed.
  • Actual solution: we started to wonder if there would be simpler ways to solve the problem of helping our customer not to forget that he has to pay for her domain registration at Since it would be possible to charge for services, it was possible to access the information about the about-to-expire domain. We decided to design a simpler solution: we will implement a communication sequence with this customer advising him of the importance of paying to ensure that the email and hosting services continue to operate normally. This is a much simpler solution than implementing a double billing process. If provides us with the billing URL, we can send this link information to the customer and the chances of solving the problem will increase even further. And a communication sequence is much simpler and faster to implement than a duplicate billing process.

At Conta Azul, a SaaS ERP for MSE (micro and small enterprises) we used accountants as one of our distribution channels and wanted to increase sales through accountants.

  • Original solution: batch purchases, where accountants would acquire a fixed number of Conta Azul licenses to resell to their customers. A system to manage batch purchases would take around 3 months to be implemented since it should allow accountants to buy Conta Azul licenses in bulk, but should only start billing the accountant’s customer when she actually activated the license.
  • Actual solution: accountants didn’t care about batch purchases. What they wanted was to provide a discount to their customers so they could subscribe to Conta Azul with this exclusive discount provided by their accounts. The cost to implement this was zero since the system already had a discount management feature.

At Gympass, a fitness partner who was joining our fitness network requested us to present their waiver to everyone who check-in in their facilities.

  • Original solution: change our app to ask end-users who go to this fitness partner to read their waiver in our app and to check a box stating they read and are ok with it.
  • Actual solution: no change to our app. Use a customizable text field in the gym set up in our system that is normally presented to users who will check-in in that gym to present the following text: “By checking in, you agree with the waiver located at”.

Don’t get me wrong, it is really good that everyone brings solutions to the table whenever we want to discuss something to be done by the product development team. The more solution ideas we have, the better. However, we need to educate ourselves to have a deeper understanding of the problem behind that solution, so we have a chance to find simpler and faster to implement solutions. And it is ultimately the product manager and all product development team members’ job to ask what is the problem and why we need this problem solved.


In concluding this chapter, I’ll make some final considerations on this stage of understanding the problem that is crucial for your software product’s success.

I put aside, on purpose, a technique called focus group, in which we gather a group of people (between 6 and 15 individuals) to discuss a certain problem. It is a technique considered qualitative as it enables to deepen in the questions that are being discussed.

The reason I put it aside is that, in these discussion groups, there’s a strong social influencer element in which more assertive and extrovert people tend to dominate the discussion and end up polarizing the group’s opinion. In my point of view, individual interviews are generally much more relevant, unless in situations when the goal is to research exactly the influence and social interaction of the group.

Another important point to consider during your discovery of the problem is who are the people having this problem and which characteristics they have in common. Besides understanding very well the problem, it is important to know for whom we are intending to solve it and what are their motivations and aspirations. It is important to keep this in mind during the process of discovering the problem.

You might be asking yourself “Why is so important to invest that much time and effort in understanding the problem?” The answer is simple: developing a software product is expensive. Investing in good comprehension of the problem, of the people who have them, of the context in which it occurs and the motivation people have to see it solved, is essential for not wasting time and money building the wrong solution.

Lastly, as I mentioned before, the methods are not exclusionary, they can and must be used together, for they are complementary. An observation is complemented with an interview. The findings in observation and interviews can be confirmed (or confronted) with the results of a survey or the analysis of collected metrics.

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.

Inovação: foco no problema

O primeiro passo para se criar um novo produto de software é entender o problema. É bastante tentador, à medida que se vai entendendo o problema, já ir buscando soluções. É da natureza humana solucionar problemas.

Todo desenvolvedor de software tem alguma história para contar sobre demandas mais ou menos assim: “Então, eu preciso de um sistema que faça isso e aquilo, preciso ter um campo para eu digitar essas informações e ele deve ter um relatório que mostre isso aqui”. Aí, quando esse sistema é entregue, a pessoa fala: “Bem, já ajuda, mas agora eu preciso também de um campo para inserir esse outro dado, e preciso que o sistema exporte um arquivo .txt separado por vírgulas”. Em outras palavras, as demandas já vêm em forma de soluções e sequer mencionam qual o problema a ser resolvido.

Existem algumas técnicas para focar no problema:


É uma ótima forma de entender mais sobre o cliente, o problema que ele tem, o contexto onde esse problema acontece, e o que o motiva a ter esse problema resolvido. Contudo, é preciso ter cuidado, pois o entrevistado vai tentar dar a solução que ele já pensou para o problema. Você deve ser cuidadoso para não menosprezar a sua sugestão, mas deve sempre manter a conversa focada no problema.

A entrevista, na qual você conversa diretamente com seu cliente, é considerada um método qualitativo, ou seja, você faz algumas poucas perguntas, mas tem a oportunidade de se aprofundar nas respostas.

A seguir, está um conjunto de perguntas para ajudar a manter a conversa focada no problema:

  • Conte-me sobre seu problema.
  • Qual é a maior dificuldade que você tem em relação a esse problema?
  • O que o motiva a querer ter esse problema resolvido?
  • Onde esse problema costuma acontecer?
  • Quando aconteceu pela última vez? O que aconteceu?
  • Por que foi difícil / complicado / ruim?
  • Você conseguiu achar uma solução? Qual(is)?
  • O que você não gostou das soluções que achou?

Por exemplo, voltando à questão do carro e da carroça do Henry Ford, imagine um diálogo imaginário entre Henry Ford e um hipotético Sr. Smith, um possível comprador de seu futuro produto:

– Sr. Smith, o que mais o aflige?

– Sr. Ford, o que mais me aflige é que passo pouco tempo com minha família.

– E por quê?

– Porque passo tempo demais na carroça indo de um lado para o outro. Se eu pudesse colocar mais um cavalo puxando minha carroça, ela andaria mais rápido e eu passaria mais tempo com minha família.

– Ah, entendi seu problema, e tenho uma solução ainda melhor para você, chama-se automóvel.

Será mesmo que Henry Ford entendeu o problema? Ou ele entendeu a solução que o Sr. Smith apresentou para ele, e desenvolveu uma solução baseada na solução dada pelo Sr. Smith? Será que o problema real do Sr. Smith não era que ele passava pouco tempo com a família?

Vamos experimentar usar as perguntas mostradas anteriormente para ver se conseguimos entender melhor o problema:

– Sr. Smith, o que mais o aflige?
– Sr. Ford, o que mais me aflige é que passo pouco tempo com minha família.
– E qual é a maior dificuldade que o Sr. tem em relação a esse problema?
– Passo muitas horas no trabalho, indo de um lugar para outro, sem falar com as pessoas.
– O que o motiva a querer ter esse problema resolvido?
– Tenho crianças pequenas e, por causa do trabalho, passo muito tempo fora de casa. Quando chego em casa, meus filhos já estão dormindo.
– Onde esse problema costuma acontecer?
– No trabalho.
– Quando aconteceu pela última vez? O que aconteceu?
– Praticamente todos os dias. Aconteceu ontem. Acho que eu consigo chegar em casa a tempo de ver meus filhos acordados uma vez por semana…
– Por que foi difícil / complicado / ruim?
– Porque me deixou longe das crianças.
– Você conseguiu achar uma solução? Qual(is)?
– Saí mais cedo do trabalho.
– O que você não gostou das soluções que achou?
– O trabalho acumulou nos outros dias.

Note que essa conversa pode gerar como solução a invenção do carro para ajudar o Sr. Smith a chegar mais rápido em casa. Entretanto, poderia também ter sido a motivação para a criação de um processo mais eficiente de trabalho, ou de uma máquina que fizesse o trabalho pelo Sr. Smith.

Você pode ter uma solução em mente. Mas considere fazer uma entrevista real, concentrando-se nas perguntas para realmente entender o problema do cliente.


Outra forma de se obter informações dos clientes é pela pesquisa. Esse método é considerado quantitativo, pois procura-se pesquisar uma quantidade considerável de pessoas para poder obter o que é conhecido como relevância estatística. Ou seja, para se poder confiar que o resultado obtido não tenha acontecido por acaso.

Por exemplo, caso você pergunte em uma pesquisa se uma pessoa tem iPhone ou Android, e só consiga duas pessoas para respondê-la, isto é, só duas respostas – quer sejam as duas iPhone, as duas Android, ou uma iPhone e a outra Android –, é muito difícil concluir qualquer coisa. Já se você tiver mais respostas, maiores as chances de o resultado de sua pesquisa refletir a realidade.

Existem ótimas ferramentas para se fazer pesquisa online, como o Google Form e o Survey Monkey. Existe também uma ferramenta brasileira chamada OpinionBox que, além de ajudar a construir seu questionário e coletar respostas, permite também que você selecione pessoas para respondê-lo baseando-se em critérios de definição de perfil que você especifica.

Pesquisas não precisam necessariamente ser feitas online. Pode-se também fazer uma por telefone ou ao vivo. Existem empresas que podem ajudá-lo a coletar as respostas.

Decidir fazer uma pesquisa é fácil, já fazer o questionário é difícil. O primeiro passo é ter bem claro qual é o seu objetivo com a pesquisa. Em seguida, crie suas perguntas tendo em mente duas regras principais:

  1. Seja breve. Quanto menor o seu questionário, maiores são as chances de obter um bom número de respostas e garantir maior relevância estatística.
  2. Seja claro. Principalmente em questionários online, quando você não interage com o respondente do questionário, são grandes as chances de a pessoa interpretar sua pergunta de forma diferente da qual você havia originalmente pensado. Uma boa forma de você testar seu questionário antes de disponibilizá-lo para obter um grande número de respostas é testá-lo com algumas pessoas ao vivo. Verifique o que as pessoas entenderam de cada pergunta, ou se tiveram dificuldade em compreender alguma parte dele.

Veja alguns exemplos de perguntas ruins que podem gerar interpretações equivocadas ou atrapalhar a qualidade das respostas obtidas, e sugestões de como essas perguntas podem ser melhoradas:

Pergunta original: Quão baixo era Napoleão?

Versão melhorada: Qual era a altura de Napoleão?

Pergunta original: Pais preocupados devem usar cadeirinhas infantis no carro?

Versão melhorada: Você acha que o uso de cadeiras especiais para crianças no carro deve ser obrigatório?

Pergunta original: Onde você gosta de beber cerveja?

Versão melhorada: Quebrar em duas perguntas: Você gosta de beber cerveja? Se sim, onde você gosta de beber cerveja?

Pergunta original: No seu trabalho atual, qual é seu nível de satisfação ou insatisfação com o salário e benefícios?

Versão melhorada: Quebrar em duas perguntas: Qual é seu nível de satisfação com seu salário em seu trabalho atual? Qual é seu nível de satisfação com seus benefícios em seu trabalho atual?

Pergunta original: Você sempre toma café da manhã? Respostas possíveis: Sim / Não.

Versão melhorada: Em quantos dias por semana você costuma tomar café da manhã? Respostas possíveis: Todos os dias / 5-6 dias / 3-4 dias / 1-2 dias / Não tomo café da manhã.


Uma outra técnica bem útil para entender o problema é a observação. Ver o cliente enfrentando o problema ou tendo uma necessidade, no contexto em que isso ocorre, pode ser inspirador!

A observação é uma forma qualitativa de se entender um problema. Para fazer uma boa observação, se prepare; tenha em mão um conjunto de hipóteses. A cada rodada de observação, reavalie as suas hipóteses e ajuste-as, se necessário. Normalmente, após umas 6 ou 8 observações, você já começará a encontrar um padrão.

A observação pode ou não ter a interferência do observador. Por exemplo, se você estiver observando hábitos de consumo em uma farmácia, você pode fazer isso sem que as pessoas notem que você as está observando. Já em um teste de usabilidade, no qual você convida pessoas a testarem seu software, as pessoas saberão que você as está observando. As observações podem ser complementadas com entrevistas, o que pode ajudar a melhorar a qualidade dos achados.

Uma técnica muito útil para descobrir problemas no uso do software é observar o que o seu usuário faz 10 minutos antes e depois de usá-lo. Por exemplo, se ele pegar informações em algum outro sistema para inserir no seu software. Talvez haja aí uma oportunidade para você já trazer essas informações do outro sistema de forma automática. E se, após usá-lo, ele copia informações para uma planilha para gerar algum gráfico, eventualmente seu software poderia poupar esse trabalho e já gerar esse gráfico para ele.

A observação geralmente é descrita como um método qualitativo. Mas você pode e deve tratá-la como uma observação quantitativa. Para isso, observe o usuário e algumas métricas importantes, como estatísticas de acesso e de uso, engajamento, NPS, receita, novos clientes, churn etc. Em outras palavras, é uma forma de observar o comportamento do seu usuário enquanto ele se relaciona com seu software.

Foco no problema vs foco na solução

Quando nos apressamos em lançar um MVP, estamos criando uma solução para um problema. No entanto, um passo muito importante para criar uma boa solução é o entendimento do problema.

É da natureza humana entrar no modo de solução quando aprendemos sobre um problema. Quando ouvimos sobre um problema, imediatamente começamos a pensar em soluções. No entanto, quanto mais tempo gastamos aprendendo sobre o problema, mais fácil será encontrar uma solução e há boas chances de que essa solução seja mais simples e rápida de implementar do que a primeira solução em que pensamos.

Aqui está uma ótima citação de Albert Einstein:

“Se eu tivesse uma hora para resolver um problema, passaria 55 minutos pensando no problema e cinco minutos pensando em soluções.”

Einstein acreditava que a qualidade da solução gerada é diretamente proporcional à sua capacidade de identificar e entender o problema que você espera resolver.

Deixe-me contar uma pequena história para ilustrar isso.

Durante a corrida espacial, os cientistas se depararam com a questão de escrever no espaço, onde não há gravidade para fazer a tinta cair em uma caneta esferográfica. Os americanos iniciaram seus esforços de P&D e, após algum tempo e alguns milhões de dólares, construíram uma caneta com um pequeno motor que bombeia tinta para o papel, mesmo sem gravidade. Enquanto isso, os russos decidiram usar lápis, que podem fazer o trabalho de escrever em ambientes sem gravidade.

Fisher Space Pen, caneta que escreve sem gravidade

Esse foco nas soluções, sem uma boa compreensão do problema e a motivação para resolvê-lo, pode ser bastante prejudicial. Isso pode nos fazer gastar tempo e dinheiro desnecessários para chegar a soluções abaixo do ideal. Essa é uma questão cultural, ou seja, um comportamento que podemos e devemos mudar. O primeiro passo para mudar um comportamento é reconhecê-lo quando isso acontecer. Quando você, como gerente de produto ou membro da equipe de desenvolvimento de produto, recebe uma solicitação para implementar algo, pergunta à pessoa que a solicitou qual é o problema que esse “algo” deve resolver e por que é necessário resolvê-lo.

Aqui estão alguns exemplos das empresas em que trabalhei.

Na Locaweb, um provedor de hospedagem de sites, os serviços de hospedagem e email podem parar de funcionar devido a fatores externos, como o domínio associado à hospedagem e ao email, não serem renovados.

Primeira solução: o, o registrador brasileiro de domínios .br, lançou uma API para permitir à Locaweb cobrar o domínio do cliente em nome do No início, a ideia parecia boa, já que a Locaweb faturava o domínio como a maneira mais fácil de garantir que o cliente soubesse que precisava pagar pelo registro do domínio para manter os serviços de hospedagem e email funcionando corretamente. No entanto, quando analisamos mais profundamente, vimos que essa solução poderia gerar alguns problemas. O cliente seria cobrado duas vezes pelo mesmo registro de domínio porque o continuaria cobrando o domínio. O que aconteceria se o cliente pagasse as duas contas? E se ela pagasse apenas o E se ela pagasse apenas Locaweb? Além disso, implementar um novo tipo de cobrança em que se cobra por um serviço de terceiros era algo novo para a equipe da Locaweb. Novos processos teriam que ser cuidadosamente projetados.

Solução implementada: começamos a pensar se haveria maneiras mais simples de resolver o problema de ajudar nosso cliente a não esquecer de que precisa pagar pelo registro de domínio no Como seria possível cobrar pelos serviços do, foi possível acessar as informações sobre o domínio prestes a expirar. Decidimos criar uma solução mais simples: implementar uma sequência de comunicação com esse cliente, aconselhando- o sobre a importância de pagar o para garantir que os serviços de email e hospedagem continuem funcionando normalmente. Essa é uma solução muito mais simples do que implementar um processo de cobrança dupla. Se o nos fornecer o URL de cobrança, podemos enviar essas informações para o cliente e as chances de resolver o problema aumentarão ainda mais. E uma sequência de comunicação é muito mais simples e rápida de implementar do que um processo de cobrança duplicado.

Na Conta Azul, um ERP SaaS para MPEs (micro e pequenas empresas), usamos contadores como um de nossos canais de distribuição e queríamos aumentar as vendas por meio de contadores.

Primeira solução: compras em lote, onde os contadores adquiriam um número fixo de licenças da Conta Azul para revender aos seus clientes. Um sistema para gerenciar compras em lote levaria cerca de três meses para ser implementado, pois deveria permitir que os contadores comprassem licenças da Conta Azul em massa, mas só deveria começar a cobrar do cliente do contador quando ela realmente ativou a licença.

Solução implementada: os contadores não se importaram com as compras em lotes. O que eles queriam era oferecer um desconto a seus clientes para que eles pudessem assinar a Conta Azul com esse desconto exclusivo fornecido por suas contas. O custo para implementar isso foi zero, pois o sistema já tinha um recurso de gerenciamento de descontos.

Na Gympass, uma academia que estava ingressando em nossa rede de parceiros solicitou que apresentássemos seu termo de renúncia a todos os usuários que fizessem check-in em suas instalações.

Primeira solução: alterar nosso aplicativo para solicitar aos usuários finais que acessam este parceiro de fitness que leiam sua renúncia em nosso aplicativo e marque uma caixa informando que leem e estão de acordo.

Solução implementada: nenhuma alteração em nosso aplicativo. Use um campo de texto personalizável no ginásio configurado em nosso sistema que normalmente é apresentado aos usuários que fazem check-in nesse ginásio para apresentar o seguinte texto: “Ao fazer o check-in, você concorda com a renúncia localizada em”.

Não me interprete mal, é muito bom que todos tragam soluções para a mesa sempre que quisermos discutir algo a ser feito pela equipe de desenvolvimento de produtos. Quanto mais ideias de soluções tivermos, melhor. No entanto, precisamos nos educar para termos uma compreensão mais profunda do problema por trás dessa solução, para que possamos encontrar soluções mais simples e rápidas para implementar. E, em última análise, é tarefa do gerente de produto e de todos os membros da equipe de desenvolvimento de produtos perguntar qual é o problema e por que precisamos resolvê-lo.


Para concluir este capítulo, vou fazer algumas considerações finais sobre essa fase de entendimento do problema, crucial para o sucesso do seu produto de software.

Deixei de lado, propositadamente, uma técnica chamada de focus group (ou grupo focal), em que reunimos um conjunto de pessoas (entre 6 a 15) para discutir sobre um determinado problema. É uma técnica tida como qualitativa, pois permite nos aprofundarmos nas questões que estão sendo discutidas.

Minha razão para deixar de lado é que, nesses grupos de discussão, existe um elemento forte de influência social, no qual pessoas mais assertivas e extrovertidas acabam dominando a discussão e polarizando a opinião do grupo. Na minha opinião, entrevistas individuais são de forma geral muito mais relevantes, a não ser em situações nas quais o que se queira pesquisar é exatamente a influência e a interação social do grupo.

Outro ponto importante a considerar durante sua descoberta do problema é quem são as pessoas que têm esse problema, e que características elas têm em comum. Além de entender muito bem sobre o problema, é muito importante conhecer para quem pretendemos resolvê-lo, e quais são suas motivações e seus anseios. Vamos falar sobre isso mais à frente; entretanto, é importante manter isso em mente durante o processo de descoberta do problema.

Uma pergunta que você pode estar se fazendo é “Por que é tão importante investir tanto tempo e esforço em entender bem o problema?”. A resposta é simples: desenvolver um produto de software é caro. Investir em ter uma boa compreensão do problema, das pessoas que o têm, do contexto onde ele ocorre e das motivações que as pessoas têm para vê-lo resolvido é essencial para não gastar tempo e dinheiro construindo a solução errada.

Por fim, como mencionei antes, os métodos não são excludentes, podem e devem ser usados em conjunto pois se complementam. Uma observação é bem complementada com uma entrevista. Os achados da observação e da entrevista podem ser confirmados (ou confrontados) com resultados de pesquisa e análise de métricas de uso.

Gestão de produtos digitais

Este artigo faz parte 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:

Leading and lagging indicators

During a mentoring session about a data concept that I think is very important, I noticed that I hadn’t written about that concept yet, so here it is. Anyone who knows me knows the importance I give to metrics. They are essential to understand what is happening and to help with decision-making. There is a way to classify metrics that helps a lot in understanding the potential impact of the metric. The terms used are leading and lagging.

Churn prediction

To explain what they are and what the difference is between leading indicators and lagging indicators, I’ll tell about a work we did both at Locaweb (web hosting and internet services provider) and Conta Azul (ERP for small business) to find ways to predict churn, that is, predict which customers were more likely to cancel the contracted service. We did a lot of analysis to find out which behaviors were most likely to indicate that a customer would cancel and we found a number of interesting behaviors like, for example, that if a website hosting customer redirects their domain to point to a website hosted elsewhere, she probably did it because she is changing the hosting service. Or if her website had high access volume and that volume has drastically reduced, chances are good that she will cancel the website hosting service as well. Or if a Conta Azul customer who used to register 50 sales per month, decreases the number of sales registered to zero, there is a high chance that this customer will cancel her account in the Azul Account.

Churn is an example of a lagging indicator as it tells what happened – customers canceled. Lagging indicators are metrics that help us assess a company’s bottom line. Examples of lagging indicators are churn, revenue, profit, number of customers, and NPS. These are metrics that must be tracked frequently, in some cases even daily or even more than once a day, but they are the consequence. They show the result, but they do not show how that result was obtained.

To understand how a result was obtained we must use leading indicators. In the above example of churn and the understanding of factors that help predict churn, customer behaviors that were detected as predictors of churn, ie, the number of visits to a website or number of sales recorded are the leading indicators. This type of indicator helps to predict an outcome, that is, it helps to predict how a lagging indicator will behave. And it is on the leading indicators that we should focus our energy so that we can see the lagging indicator hand move.

Cause and effect

For example, what should we do to decrease the churn of a product? Ensure that the product is being used and being useful, that is, solving a problem or meeting a need of its user. At Locaweb, in the website hosting product, the website has to be useful to the website owner. What does this website owner or online store expect from this website? Visits? Customers? Purchases? How to help the website owner achieve her goal? This is the way to avoid churn. At Conta Azul, what is the expected behavior of a customer who is solving their small business management problems using the product? How many times a week does she access? What does she do when she logs into the system? How can I help the customer get the most out of the product?

So whenever I see product teams setting churn or even NPS goals, I recommend including engagement goals and leaving churn and NPS not as goals but as metrics to track. If you have a product that generates engagement according to what you had planned for that product, you will most likely have low churn and good NPS.

One way to help understand these concepts is to think about cause and effect, that is, cause and effect indicators. While churn and NPS are effect indicators, engagement can be seen as a cause indicator.


Thinking about OKRs, one way to use leading indicators and lagging indicators is to think about lagging indicators, or effect indicators, as objectives and leading indicators, or cause indicators, as key results.

Using OKR’s classic losing weight example, losing 3 kilos is the goal, and it’s a lagging indicator or effect indicator. While the key results of exercising 3 times a week, not eating sweets, and limiting daily calories to a certain value are leading indicators or cause indicators.

Summing up

  • An important way to look at metrics is to understand if the metric is a lagging indicator, that is, an indicator that is a consequence such as, for example, revenue, profit, churn, number of customers and NPS, or if it is a leading indicator, an indicator that is a cause, such as the engagement of a customer with a product, is the cause of a lower churn and a higher NPS.
  • Leading indicators can be seen as the cause while lagging indicators can be seen as the effect.
  • In OKRs, objectives are the lagging indicators, while key results are the leading indicators.

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.

Indicadores leading e lagging

Conversando em uma sessão de mentoria sobre um conceito de dados que considero muito importante, notei que eu ainda não havia escrito sobre esse conceito, então aqui vai. Quem me conhece sabe da importância que dou às métricas. São essenciais para entender o que está acontecendo e para ajudar na tomada de decisões. Existe uma forma classificar métricas que ajuda muito a entender o potencial de impacto da métrica. Em inglês os termos usados são leading e lagging.

Predição de churn

Para explicar o que são e qual a diferença entre indicadores leading e indicadores lagging, vou contar sobre um trabalho que fizemos tanto na Locaweb quanto na Conta Azul para descobrir maneiras de predizer o churn, ou seja, predizer quais clientes tinham maior probabilidade de cancelar o serviço contratado. Fizemos várias análises para descobrir que comportamentos indicavam com maior chances de acerto que um cliente iria cancelar e descobrimos vários comportamentos interessantes como, por exemplo, que um cliente de hospedagem de sites que redireciona o seu domínio para apontar para um site hospedado em outro lugar, provavelmente o fez porque está mudando de serviço de hospedagem. Ou se seu site tinha alto volume de acesso e esse volume reduziu drasticamente, também há boas chances que ele vai cancelar seu serviço de hospedagem de sites. Ou se um cliente do Conta Azul que costumava registrar 50 vendas por mês, diminui a quantidade de vendas registradas até zero, há grandes chances de esse cliente cancelar sua conta na Conta Azul.

O churn é exemplo de indicador lagging pois ele conta o que aconteceu – clientes cancelaram. Indicadores lagging são métricas que nos ajudam a avaliar o resultado de uma empresa. Exemplos de indicadores lagging são churn, receita, lucro, número de clientes e NPS. São métricas que devem ser acompanhadas frequentemente, em alguns casos até mesmo diariamente ou mesmo mais de uma vez por dia, mas elas são a consequência. Elas mostram o resultado, mas não mostram como esse resultado foi obtido.

Para entender como um resultado foi obtido devemos usar os indicadores leading. No exemplo acima do churn e da pesquisa dos fatores que ajudam a predizer o churn, os comportamentos dos clientes que foram detectados como preditores do churn, ou seja, quantidade de acessos de um site ou quantidade de vendas registradas são os indicadores leading. Esse tipo de indicador ajuda a predizer um resultado, ou seja, ajuda a predizer como irá se comportar um indicador lagging. E é nos indicadores leading que devemos focar nossa energia, para que possamos ver o ponteiro do indicador lagging mexer.

Causa e efeito

Por exemplo, o que devemos fazer para diminuir o churn de um produto? Garantir que o produto esteja sendo usado e sendo útil, ou seja, resolvendo um problema ou atendendo uma necessidade de seu usuário. Na Locaweb, no produto de hospedagem de sites, o site tem que ser útil para o dono do site. O que esse dono do site ou loja virtual espera desse site? Visitas? Clientes? Compras? Como ajudar o dono do site a atingir seu objetivo? Esse é o caminho para evitar o churn. Na Conta Azul, qual é o comportamento esperado de um cliente que está resolvendo seus problemas de gestão utilizando o produto? Quantas vezes por semana ele acessa? O que ele faz quando se loga no sistema? Como posso fazer para ajudar o cliente a tirar o máximo de proveito do seu produto?

Por isso, sempre que vejo times de produto definindo metas de churn ou mesmo de NPS, eu recomendo incluir metas de engajamento, e deixar churn e NPS não como metas, mas sim como métricas a serem acompanhadas. Se você tiver um produto que gera um engajamento dentro do que você havia planejado para esse produto, você muito provavelmente terá um churn baixo e um bom NPS.

É um pouco difícil traduzir os termos leading e lagging para o português, mas uma forma de ajudar a entender esses conceitos é pensar em causa e efeito, ou seja, indicador causa e indicador efeito. Enquanto churn e NPS são indicadores efeito, o engajamento pode ser visto como um indicador causa.


Pensando nos OKRs, uma forma de utilizar indicadores leading e indicadores lagging é pensar nos indicadores lagging, ou indicadores efeito, como objetivos e indicadores leading, ou indicadores causa, como os key results (resultados chave).

Usando o clássico exemplo do OKR de emagrecimento, emagrecer 3 kilos é o objetivo, e é um indicador lagging ou indicador efeito. Enquanto os key results de fazer exercício 3 vezes por semana, não comer doces e limitar caloris ingeridas por dia a um determinado valor são indicadores leading ou indicadores causa.


  • Uma importante maneira de enxergar as métricas é entender se a métrica é um indicador lagging, ou seja, um indicador que é consequência como, por exemplo, receita, lucro, churn, número de clientes e NPS, ou se é um idicador leading, ou seja, um idicador que é causa, como por exemplo o engajamento de um cliente com um produto é a causa de um churn menor e de um NPS maior.
  • Indicadores leading podem ser vistos como a causa enquanto indicadores lagging podem ser vistos como o efeito.
  • Nos OKRs, os objectives são os indicadores lagging, enquanto os key results são os indicadores leading.

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:

What is innovation?

Of all stages of the lifecycle of a software product, innovation is the one that uses to present the greatest amount of questions. But what is innovation? How to find a problem to be solved? How to find out if this problem is, in fact, an opportunity to be looked for? And how to obtain a return with your software product?

These are the themes that I’ll approach in the next pages.

Innovation is a very common term, but if you ask different people about it, each one will give you a different definition. Some will define it by focusing on creativity, that is, they will say that innovation is something creative, something that didn’t exist before, something different from what you find usually.

There are many products, not only software, that are very creative. There are stores specialized in these creative products. In the United States, a very well-known store of creative products is Sharper Image.

Portable air conditioner

Without a doubt, this portable air conditioner from Sharper Image is a very creative product.

Another company that sells creative products is SkyMall. The company distributes a catalog full of different and creative products on local flights in the United States.

However, are these products really innovative? How many people do you know that really need a portable air conditioner? Does it solve a problem or need of a group of people?

Besides people that associate innovation to creativity, others understand innovation as being the latest technology. Quantic computer, wireless electricity transmission, genome editing, virtual reality, augmented reality, nanotechnology and the internet of things are some examples of the latest technologies.

Whereas, once again, I have the same question: Are these really innovations? How many people need these technologies? Do they solve some problem or need of a group of people?

Defining innovation: Innovating is not just simply being creative or knowing the latest technology. It is necessary to know the available technologies and how to use them to solve a problem or serve a need of a group of people, this has the potential of really producing innovation.

This definition makes clear that innovation – and we can consider creating a new digital product as innovation – should start by discovering and understanding the problems and needs of a group of people.

But how can we do this? Do clients know what they want?

Of course clients know what they want!

“Clients don’t know what they want.” Unfortunately, It’s common to hear such a sentence in conversation about products and clients. At a certain point, someone will utter the famous quote from Henry Ford, the automobile inventor:

“If I had asked people what they wanted, they would have said faster horses.” – Henry Ford

Steve Jobs, Apple’s eternal CEO, enjoyed repeating this sentence to exhaustion.

Nevertheless, I disagree. Clients do know what they want. They want a solution for their problems. That’s where Henry Ford, Steve Jobs and us, mere mortals, come in, willing to develop products to solve these problems.

The first steps to creating a good product are:

  • To realize that there are people with a problem or need to be solved;
  • Understand very well what this problem or need is;
  • Understand what motivates people to want this problem or need solved.

When you talk to people with problems or needs, some will even say that this problem could be solved like this or that; however, in this initial moment, the priority is to find out if there really is a necessity to be solved. You must decouple the problem from the suggestion of solution your interlocutor is trying to give.

People used to take a long time to move. This was the problem to be solved at Henry Ford’s time. No matter how.

It could be more horses in front of the carts, it could be horses trained to walk on rollerblades, it could be using genetically modified horses that would ride faster, it could be the invention of the car, the invention of the airplane, even the invention of tele-transportation.

The specific solution for the problem didn’t matter, as long as it was solved. Many people probably gave solutions, like the fastest horses from Henry Ford’s quote, but this is just a suggestion. The problem to be solved is that people spent too much time moving from one place to another. The problem was not that they wanted to move faster. That’s already part of the solution.

In the next chapters, we will approach some techniques that will help us to find out and understand the problems or needs.

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 in their titles above.

O que é inovação?

De todas as fases do ciclo de vida de um produto de software, a fase de inovação é a que costuma ter a maior quantidade de dúvidas. Mas o que é inovação? Como encontrar um problema a ser resolvido? Como descobrir se esse problema é, de fato, uma oportunidade a ser perseguida? E como obter retorno com seu produto de software?

Inovação é um termo usado com frequência por várias pessoas, mas a cada uma que perguntar “o que é inovação?”, você vai obter uma resposta diferente.

Algumas pessoas vão dar uma definição focada na criatividade, ou seja, vão dizer que inovação é algo criativo, algo que não existia antes, algo diferente do que se encontra no dia a dia.

Existem vários produtos, não só de software, que são bastante criativos. Existem lojas dedicadas a esses produtos criativos. Nos Estados Unidos, uma loja bastante conhecida de produtos criativos é a Sharper Image.

Ar-condicionado portátil

Sem dúvida, esse ar-condicionado portátil da Sharper Image é um produto bastante criativo.

Outra empresa que comercializa esse mesmo tipo de produto é a SkyMall, que distribui nos aviões de voo local nos Estados Unidos aquele catálogo cheio de produtos diferentes e criativos. Aqui no Brasil, a Imaginarium é uma loja que oferece esse tipo de produtos.

No entanto, estes produtos chegam a ser realmente uma inovação? Quantas pessoas precisam de um ar-condicionado portátil? Isso resolve algum problema ou uma necessidade de um conjunto de pessoas?

Além das pessoas que associam inovação à criatividade, existem aquelas que entendem inovação como sendo a última tecnologia. Computador quântico, transmissão de eletricidade sem fio, edição de genoma, realidade virtual, realidade aumentada, nanotecnologia e internet das coisas são alguns exemplos das tecnologias mais recentes.

Então, novamente faço a mesma pergunta: estes produtos são realmente uma inovação? Quantas pessoas precisam dessas tecnologias? Isso resolve algum problema ou uma necessidade de um conjunto de pessoas?

Definindo Inovação: Inovar não é simplesmente ser criativo ou conhecer a última tecnologia. É preciso conhecer as tecnologias disponíveis e saber como usá-las para resolver um problema ou atender a uma necessidade de um grupo de pessoas, isso tem o potencial de produzir uma inovação.

Essa definição deixa claro que a inovação – e podemos olhar a criação de um novo produto de software como uma inovação – deve começar pela descoberta e entendimento de problemas e necessidades de um grupo de pessoas.

Mas como fazer isso? O cliente sabe o que quer?

Claro que o cliente sabe o que quer

“Os clientes não sabem o que querem”. Infelizmente, é comum ouvir esta frase em conversas sobre produtos e clientes. Em determinada altura, alguém soltará a famosa frase de Henry Ford, o inventor do automóvel:

“Se eu tivesse ouvido os usuários, em vez do automóvel eu teria inventado uma carroça mais rápida.” – Henry Ford

Aliás, quem gostava de repetir essa frase à exaustão era o eterno CEO da Apple, Steve Jobs.

No entanto, eu discordo. Os clientes sabem o que querem. Eles querem uma solução para seus problemas. É aí que Henry Ford, Steve Jobs e nós, o resto dos mortais, entramos, querendo desenvolver produtos para resolver esses problemas.

Os primeiros passos para criar um bom produto são:

  • Perceber que existem pessoas com um problema ou uma necessidade a ser resolvida;
  • Entender muito bem qual é esse problema ou necessidade;
  • Entender o que motiva as pessoas a querer que esse problema ou necessidade seja resolvida.

Quando você conversar com pessoas com problemas ou necessidades, algumas até dirão que acham que esse problema poderia ser resolvido assim ou assado; entretanto, nesse momento, o mais importante é descobrir se existe uma necessidade a ser resolvida. Você deve separar o problema da sugestão de solução que seu interlocutor está tentando passar.

As pessoas demoravam muito tempo para se locomover. Esse provavelmente era o problema que as pessoas queriam que fosse resolvido na época de Henry Ford. Não importava como. Podia ser com mais cavalos na frente da carroça, podia ser com cavalos treinados para andar de patins, podia ser com cavalos geneticamente modificados para andar mais rápido, podia ser com a invenção do automóvel, podia ser com a invenção do avião, podia até mesmo ser com a invenção do teletransporte.

A solução específica para o problema não importava, desde que fosse resolvido. Algumas pessoas provavelmente devem ter sugerido soluções, como a carroça mais rápida da famosa frase de Henry Ford, mas isso é só uma sugestão de solução. O problema a ser resolvido é que as pessoas gastavam muito tempo se locomovendo. Note que o problema não é que as pessoas queriam se locomover mais rápido. Isso já é parte da solução.

Nos próximos capítulos, veremos algumas técnicas para ajudar a descobrir e a entender bem problemas ou necessidades.

Gestão de produtos digitais

Este artigo faz parte 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:

Let’s remove the product from the center?

I have been working with digital products for over 30 years. I graduated in computer engineering at ITA in the early 1990s and since then I have worked for companies whose core business is technology. Starting with Dialdata, my internet services startup from the time when new tech companies weren’t called startups yet. Then I worked with technology products at .comDominio, a data center that became Alog and was later acquired by Equinix. Then I went through Locaweb, Conta Azul, and more recently Gympass. All technology companies, i.e., that use technology to deliver value to their customers.

Beyond the product

At Gympass I started to understand the mechanics of a company where technology and the digital product are not the core business. Gympass product is a corporate benefit that companies hire to provide their employees access to a network of gyms and studios. At the end of 2019, there was an effort to digitalize – and diversify – Gympass product portfolio, but even so, the main product continued to be to provide wellness services as a corporate benefit for companies to offer their employees.

Even technology companies have a mission to do “something” through technology. Locaweb’s mission is:

Making businesses grow and prosper through technology.

And Conta Azul’s mission is:

Boost small entrepreneurs’ success by bringing to small businesses more organization, control and time through technology.

And well-known tech companies don’t even mention technology in their missions:

Our mission is to empower every person and every organization on the planet to achieve more. (Microsoft)

Organizing the world’s information and making it universally accessible and useful. (Google)

Give people the power to share and make the world more open and connected. (Facebook)

In other words, technology and technology products are not the mission of technology companies, they are the vehicles used by these companies to fulfill their mission.

When I joined Lopes, Brazil’s largest real estate company, founded in 1935, long before computers and the internet existed, I began to better understand something I was already noticing during my time at Gympass. The digital product is not at the core of a company. The company does not revolve around the product, but the other way around, i.e., the digital product is there to serve the company and its customers, to leverage its results, and to help fulfill its mission. Lopes’ mission is:

Help people conquer their place.

When the product is at the center

One of the products that was under developement when I joined Lopes was the “MVP” of the brokers’ app. I put the MVP in quotes because this app was already in development for 5 months and still had another 1 or 2 months to finish and be available for use.

When I started talking to people to understand what was the main problem that the app would solve, I found that the main focus was to make the lead, that is, the information about a person interested in a property, be as soon as possible in the hands of brokers, because the faster this broker get in touch with that person and engage in a conversation about their needs, the greater the chances that this engagement would evolve into a possible sale of a property. Hence the idea of ​​making an MVP of an app with push notification to alert the broker about the lead.

At this point, an app for brokers development team was created and they started thinking about the journey of the broker receiving this lead through push notification. When the broker receives this lead, she needs to consult the data of this potential customer in Lopes’ system and, if the person is not registered yet, register their data in the system. And then, there was one more feature that “MVP” had to have before it was released, the search and registration of new potential client. Thinking more about the broker’s journey, it is very common when receiving the lead and understanding the needs of this potential client, to do a search in the real estate firm database to be able to send other propety options. And voila, one more minimal mandatory feature for the “MVP” of the broker app, the property search. To the point of having been developed for this “MVP” the possibility of drawing the region for the property search with your finger on a map.

Screen drawing functionality to mark theproperty search region in the app for brokers.

By putting the product at the center, people start to care about the product and its features. And that’s where the demand for delivering features comes from. Designing the minimal scope of an MVP may lead to discussions revolving around “minimal” features. Even when we use the term MVP, the focus is on the minimum product.

Removing the product from the center

Ok, it’s clear that by putting the product in the center, we end up potentializing some pitfalls that can hinder our delivery of results. So what should we put at the center? The expected result. In the example above, the expected result was to get leads as quickly as possible into the hands of brokers so they could contact the potential customer as soon as possible and engage him in a conversation with potential for sale of property.

If we notice in the description of the expected result, there is no mention of app, push notification, customer registration, or property search. The expected result is to make the lead reach the brokers’ hands as quickly as possible. If we focus more on the problem we will see that there are other possible solutions besides the app for brokers. We can send notifications via SMS or WhatsApp, something much simpler and faster to develop than an app. And probably with greater reach, as all cell phones accept SMS and most people in Brazil have WhatsApp, while a new app needs to be downloaded by the user. We implemented SMS notification and within 10 days all brokers started to receive these notifications. Delivery of value to brokers, potential customers and Lopes much faster than thebroker app 5 month “MVP”.

Product is means, not the end

That is why I have often repeated that product, app, website, technology, data, algorithms are not the end, they are not the goal, they are vehicles to achieve the goal of delivering value. And they must be treated as such. Making the lead reach the brokers’ hands faster can be done by push notification in an app for brokers, but it can also be done by SMS notification or WhatsApp. The vehicle matters less than the value, and the result delivered.

When we have an app team for brokers, with people from engineering, design and product management, the main vehicle that people on this team know to deliver value to brokers is the app they are developing. For this reason we made a change at Lopes in the team structure. We went from teams by product like the app for brokers team to teams focused on the actors of our business, and we created the brokers and franchises team that focuses on delivering value to brokers and franchises, regardless of the delivery vehicle for that value. It can be via a web system, an app, an SMS notification, a chatbot, etc. What matters is delivering value, and results, to brokers and franchises as quickly as possible.

Summing up

  • Product, app, website, technology, data, algorithms are not the end, they are not the goal, they are vehicles to achieve the goal of delivering value, and results, for customers and for the 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 in their titles above.

Vamos tirar o produto do centro?

Trabalho com produtos digitais há mais de 30 anos. Me formei em engenharia de computação no ITA no início da década de 1990 e desde então trabalho em empresas cujo core business é tecnologia. Começando com a Dialdata, minha startup de serviços de internet da época em que novas empresas de tecnologia ainda não se chamavam startups. Depois trabalhei com produtos de tecnologia na .comDominio, data center que virou Alog e depois foi comprada pela Equinix. Em seguida passei por Locaweb, Conta Azul e mais recentemente Gympass. Todas empresas de tecnologia, ou seja, que usam tecnologia para entregar valor para seus clientes.

Além do produto

No Gympass comecei a entender a mecânica de uma empresa em que a tecnologia e o produto digital não são o core business. O produto do Gympass é um benefício corporativo que empresas contratam para dar aos seus funcionários acesso a uma rede de academias e estúdios. No final de 2019 houve um trabalho de digitalização – e diversificação – do portfólio de produtos do Gympass, mas mesmo assim, o produto principal continuou sendo a oferta de serviços de bem-estar como benefício corporativo para empresas oferecerem aos seus funcionários.

Mesmo empresas de tecnologia têm por missão fazer “alguma coisa” por meio de tecnologia. Veja a missão da Locaweb:

Fazer negócios nascerem e prosperarem por meio da tecnologia.

E a da Conta Azul:

Impulsionar o sucesso dos pequenos empreendedores levando às pequenas empresas mais organização, controle e tempo por meio da tecnologia.

E empresas tech bem conhecidas sequer mencionam a tecnologia em suas missões:

Nossa missão é capacitar cada pessoa e cada organização no planeta para alcançar mais. (Microsoft)

Organizar as informações do mundo e torná-las universalmente acessíveis e úteis. (Google)

Dar às pessoas o poder de compartilhar e tornar o mundo mais aberto e conectado. (Facebook)

Ou seja, a tecnologia e os produtos de tecnologia não são a missão das empresas de tecnologia, são os veículos utilizados por essas empresas para cumprirem com sua missão.

Quando me juntei à Lopes, maior empresa de consultoria imobiliária do Brasil, fundada em 1935, bem antes da existência dos computadores e da internet, comecei a entender melhor algo que eu já estava percebendo durante meu tempo no Gympass. O produto digital não deve estar no centro da empresa. A empresa não gira em torno do produto, mas sim o contrário, o produto digital está ali para servir a empresa e seus clientes, para potencializar os seus resultados e para ajudar a cumprir com sua missão que, no caso da Lopes, é:

Ajudar as pessoas a conquistarem o seu lugar.

Quando o produto está no centro

Um dos produtos que estavam sendo desenvolvidos quando comecei a trabalhar na Lopes era o “MVP” do app dos corretores. Coloco o MVP entre aspas pois esse app já estava em desenvolvimento há 5 meses e ainda faltava mais 1 ou 2 meses para terminar e ser disponibilizado para uso.

Quando comecei a conversar com as pessoas para entender qual era o problema principal que o app iria resolver, descobri que o foco era fazer com que o lead, ou seja, a informação sobre uma pessoa interessada em um imóvel, chegasse o mais rápido possível na mão das corretoras e corretores pois, quanto mais rápido essa corretora entrasse em contato com essa pessoa e engajasse em uma conversa sobre suas necessidades, maiores as chances de esse engajamento evoluir para uma possível venda de um imóvel. Daí surgiu a ideia de fazer um MVP de um app com push notification para alertar a corretora sobre o lead.

Nesse ponto, foi criado um time de app para corretores e começaram a pensar sobre essa jornada da corretora recebendo esse lead através do push notification. Quando a corretora recebe esse lead, ela precisa consultar os dados desse possível cliente no sistema da Lopes e, se a pessoa ainda não estiver cadastrada, cadastrar seus dados no sistema. E pronto, surgiu mais uma funcionalidade que o “MVP” tinha que ter antes de ser lançado, busca e cadastro de clientes. Pensando mais na jornada da corretora, é muito comum ao receber o lead e entender a necessidade desse potencial cliente, fazer uma busca na base de imóveis para poder enviar outras opções de imóveis. E pronto, mais uma funcionalidade mínima obrigatória para o “MVP” do app de corretores, a busca de imóveis. Ao ponto de ter sido desenvolvido para esse “MVP” a possibilidade de desenhar com o dedo em um mapa a região para a busca de imóvel.

Funcionalidade de desenho na tela para marcar a região de busca por imóveis no app para corretores.

Ao colocarmos o produto no centro, as pessoas passam a se preocupar com o produto e com suas funcionalidades. E é daí que vem a cobrança por entrega de funcionalidades. No desenho do escopo mínimo de um MVP, a discussão acaba girando em torno das funcionalidades “mínimas”. Até mesmo quando usamos o termo MVP, o foco é no produto mínimo.

Tirando o produto do centro

Ok, está claro que ao colocar o produto no centro, acabamos potencializando algumas armadilhas que podem atrapalhar a nossa entrega de resultado. Então o que devemos colocar no centro? O resultado esperado. No exemplo acima, o resultado esperado era fazer os leads chegarem o mais rápido possível nas mãos das corretoras para que elas pudessem entrar em contato com o possível cliente o quanto antes e engajá-lo em uma conversa com potencial de venda de imóvel.

Se notarmos na descrição do resultado esperado, não há menção a app, push notification, cadastro de cliente, nem busca de imóveis. O resultado esperado é fazer o lead chegar o mais rápido possível nas mão das corretoras. Se nos focarmos mais no problema veremos que há outras possíveis soluções além do app para corretores. Podemos enviar notificações via SMS ou WhatsApp, algo bem mais simples e rápido de desenvolver do que um app. E provavelmente com alcance maior, pois todos os celulares aceitam SMS e a maioria das pessoas no Brasil têm WhatsApp, enquanto um app precisa ser baixado pelo usuário. Fizemos a implementação de notificação via SMS e em 10 dias todos os corretores passaram a receber essas notificações. Entrega de valor para os corretores, para os potenciais clientes e para Lopes bem mais rápida do que no “MVP” de 5 meses do app de corretores.

Produto é meio, não é fim

Por isso tenho repetido com frequência que produto, app, site, tecnologia, dados, algoritmos não são o fim, não são o objetivo, são veículos para se atingir o ogjetivo de entrega de valor. E devem ser tratados como tal. Fazer o lead chegar mais rápido na mão das corretoras pode ser feito por push notification em um app para corretores, mas também pode ser feito por notificação SMS ou WhatsApp. O veículo importa menos do que o valor, e o resultado entregue.

Quando temos um time de app para corretores, com pessoas de engenharia, design e gestão de produtos, o principal veículo que as pessoas desse time conhecem para entregar valor para os corretores é o app que elas cuidam. Por esse motivo fizemos uma mudança aqui na Lopes na estrutura de times. Saímos de times por produto como o time de app para corretores para times por atores do nosso negócio, e criamos o time de corretores e franquias que tem por foco entregar valor para corretores e franquias, não importando o veículo de entrega desse valor. Pode ser por um sistema web, um app, notificação via SMS, chatbot, etc. O que importa é entregar valor, e resultado, para corretores e franquias o mais rápido possível.


  • Produto, app, site, tecnologia, dados, algoritmos não são o fim, não são o objetivo, são veículos para se atingir o ogjetivo de entrega de valor, e resultado, para os clientes e para a empresa.

Gestão de produtos digitais

EVocê 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:

Lifecycle of a digital product

I’ve talked a little about what is digital product management, the main characteristics of a product manager, and about some leadership and organizational culture tips for helping managers to lead without being “the boss”.

Now, let’s talk about the lifecycle of a software product and its different stages: innovation, growth, maturity and end of life.


From all the lifecycle stages of a software product, innovation is the one that holds the biggest amount of doubts. It is also the topic that has the biggest number of books. Just go to Amazon and search for books on innovation and startup. On the next pages let’s explore the following questions.

  • What is innovation?
  • How to find a problem to be solved?
  • How to find out if this problem is, in fact, an opportunity to be pursued?
  • How to get payback with your software product?


In the growth stage, when the product has been developed and launched, we should worry about how to manage the product during its growth, that is, how to manage feedback? What is a roadmap? How to prioritize demands? What to do with special requests? How to say no? What metrics we should follow?


After growth, comes maturity. In this phase, we will figure out when it happens and what to do if the product has survived this far.

End of life

After maturity, or when the product is developed but it does not work, comes the stage known as end of life of a software product. Let’s see how to detect it and how to handle it.

Shall we begin?

How does the lifecycle of a software product work?

Before we see how the lifecycle of software works, we need to understand the technology adoption curve. This concept came up for the first time in a book in 1962, called Diffusion of Innovations, written by Everett M. Rogers, sociologist, and professor at Iowa State University. In this book, Rogers explains that technological innovations are adopted according to the curve shown in the following picture:

Technology adoption curve

In the beginning, innovators are the first to get interested in new products and novelties. They even accept incomplete or defective products just for the pleasure of being the first ones to use this new product. In second place we find the early adopters, also known as visionaries or enthusiasts, who accept the risks of testing a new product, not for the pleasure of coming first but because they see the potential in it. Usually, they are influencers within organizations and communities in which they participate.

The early majority also called pragmatics, buy new products only after they got references. The late majority are the conservatives, in other words, those who buy only after the price has dropped substantially. Lastly, we have the laggards, who only buy a new product if it is the only option available.

By calculating the integration (who remembers the calculus classes?) we can obtain the famous S-curve regarding technology adoption.

S-curve of technology adoption

This S-curve can be broken into three stages: the slow beginning, which is the innovation stage; later comes the growth stage, when the early majority and late majority adopt the product; and, lastly, the maturity stage, in which the product has already conquered practically the whole market.

S-curve and the 3 stages

Check out some examples of the S-curve.

S-curve in real life

S-curve in real life

It is not always so perfect as the theoretical curve, but close enough. The TV curve is the closest one and explains why the television manufacturers are always inventing something new, and then selling it to us.

In the first place, there were black and white TVs; then, the colored ones. Then, there were the ones with remote control, flat screen, plasma screen, LCD, LED, 3D and SmartTV. All that, so manufacturers could keep getting revenue out of their clients, even after the TV market has matured about 30 years after it had been invented.

The internet and cell phones curves seem to grow the same way. The curves from PC, electricity, airplanes, telephone, and cars have some alterations in their designs but, in general, they are very similar to the theoretical S-curve.

Another example of the S-curve, closer to who is involved with software development, is the curve regarding the amount of .br domains registered.

.br domains registered

domains registered in Brazil (.br)

Notice the typical acceleration in the innovation stage that happened between 1996 and 2008. From this year on, we’ve entered into the growth stage. It seems that, from 2013 on, a new deceleration has been taking place. In 2017 it seems we’ve entered into the maturity phase. People and businesses seem to not be registering domains anymore since there are other ways to be present on the internet (market places, Facebook, Instagram, etc.).

However, due to COVID-19 pandemic, the business digitalization re-accelerated, as we can see in the chart below:

.br domain registration acceleration after COBID-19 pandemic

The chasm

There is always a but. In 1991, Geoffrey Moore wrote a book called Crossing the Chasm: Marketing and Selling High-Tech Products to Mainstream Customers.

In his book, Moore explains that among the early adopters (enthusiasts) and the early majority (pragmatics) there is a chasm that many products can’t cross. This happens because the pragmatics need good references for buying a new product and the enthusiasts usually are not the best reference. Hence the difficulty of some products for crossing this chasm.

Crossing the chasm

In his book, Moore also presents strategies to cross this chasm but, unfortunately, the strategies proposed are all based on war tactics that, as said in the previous chapter, I don’t think make much sense for the business world.

The proposed strategy, except for the war reference, is summed up in focus. In other words, try to focus in one single type of client and solve their problem with your product. When these clients are very satisfied, then it’s the moment for you to seek new types.

The chasm described by Moore shows one out of two ways possible for the software product:

  • It is not going to cross the chasm: the company can’t get its product to go beyond the enthusiasts and, consequently, will not have clients to guarantee its survival. This is one of the reasons that many startups close their doors prematurely.
  • Mature: your product is going to work and the company will eventually reach the top of the S-curve, and will decelerate until some other company comes up with a product to replace yours. Take a look at Kodak that, until today, hasn’t recovered from the invention of digital cameras, for its revenue came primarily from the sales of camera films and photographic material.

And here we are in the fourth stage of the software product lifecycle: the end, or, in nicer terms, sunset.

So, we have the four stages in the software product lifecycle: innovation, growth, maturity, and sunset.

Lifecycle of a digital product

Now we’ll see each one of these stages with more details and understand the role of product management in each one of them.

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 almost 30 years of experience in creating and managing digital products:

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

Ciclo de vida de um produto digital

Já falei um pouco sobre o que é gestão e gestor de produtos de software, suas principais características, sobre como gerenciar gestores de produtos e até mesmo algumas dicas de liderança e de cultura organizacional para ajudar gestores a liderar sem serem “chefes”.

Agora, vamos falar sobre o ciclo de vida de um produto de software e suas diferentes fases: inovação, crescimento, maturidade e fim de vida.

  • Inovação: de todas as fases do ciclo de vida de um produto de software, acredito que a de inovação é a que tem a maior quantidade de dúvidas. É também a fase que tem a maior quantidade de livros. Basta ir à Amazon e procurar livros sobre inovação e startup. Nas próximas páginas, vamos explorar as seguintes perguntas.
    1. O que é inovação?
    2. Como encontrar um problema a ser resolvido?
    3. Como descobrir se esse problema é, de fato, uma oportunidade a ser buscada?
    4. Como obter retorno do seu produto de software?
  • Crescimento: nessa fase, quando o produto foi desenvolvido e lançado, devemos nos preocupar em como gerenciar o produto durante seu crescimento, ou seja, como gerenciar o feedback? O que é um roadmap? Como priorizar as demandas? O que fazer com pedidos especiais? Como dizer não? Que métricas acompanhar?
  • Maturidade: após o crescimento, vem a maturidade. Nessa parte, vamos entender quando ela acontece e o que fazer se o produto chegar a essa fase.
  • Fim de vida: depois da maturidade, ou quando o produto é desenvolvido mas não dá certo, chega a fase conhecida como fim de vida de um produto de software. Vamos ver como detectar e o que fazer nela.

Vamos começar?

Como é o ciclo de vida de um produto de software?

Antes de vermos como é o ciclo de vida, precisamos entender a curva de adoção de tecnologia. Esse conceito apareceu pela primeira vez em um livro de 1962, chamado Diffusion of Innovations, escrito por Everett M. Rogers, sociólogo e professor da Universidade Estadual de Iowa. Nesse livro, Rogers explica que as inovações tecnológicas são adotadas conforme a curva mostrada na figura a seguir:

Curva de adoção de tecnologia

No começo, os inovadores são os primeiros a se interessar por novos produtos e inovações. Topam até produtos incompletos e com defeitos, pelo prazer de serem os primeiros a utilizar esse novo produto. Em seguida, estão os early adopters, também conhecidos como visionários ou entusiastas, que aceitam os riscos de testar um novo produto, não pelo prazer de ser o primeiro, mas sim porque enxergam seu potencial. Normalmente, têm influência nas organizações e comunidades de que fazem parte.

Early majority, também chamados de pragmáticos, compram novos produtos somente depois de ter referências. Late majority são os conservadores, ou seja, aqueles que compram somente depois que o preço caiu consideravelmente. Por fim, há os laggards, que só compram um novo produto se essa for a única opção disponível.

Fazendo a integral dessa curva (quem se lembra das aulas de cálculo?), obteremos a famosa curva em S de adoção de tecnologia.

Curva S de adoção de tecnologia

Essa curva em S pode ser quebrada em 3 fases: o início mais lento, que é a fase de inovação; em seguida vem a fase de crescimento, quando early majority e late majority adotam o produto; e, por fim, a fase de maturidade, quando o produto já conquistou praticamente todo o mercado.

Curva S e as 3 fases

Na sequência, veja alguns exemplos da curva S.

Curva S na vida real

Nem sempre é tão perfeita quanto a curva teórica, mas se aproxima bastante. A curva da TV é a que mais se aproxima, e explica por que toda hora os fabricantes de televisões estão inventando algo novo para nos fazer comprar uma nova.

Primeiro, eram TVs em preto e banco; depois, as coloridas. Aí vieram as com controle remoto, tela plana, tela de plasma, LCD, LED, 3D e SmartTV. Tudo isso para que os fabricantes pudessem continuar tendo nova receita de seus clientes, uma vez que o mercado da TV amadureceu uns 30 anos depois que ela foi inventada. As curvas de internet e de celulares parecem crescer da mesma forma. Já as curvas de PC, eletricidade, aviões, telefone e automóveis têm algumas alterações em seu desenho; mas, de forma geral, se assemelham bastante à curva S teórica.

Outro exemplo de curva, mais próximo de quem está envolvido com desenvolvimento de software, é a curva de quantidade de registro de domínios .br feitos.

Registro de domínios .br até 2018

Dá para notar nessa curva a aceleração típica da fase da inovação que aconteceu entre 1996 e 2008. A partir desse ano, entramos na fase de crescimento. Parece que, a partir de 2013, está acontecendo uma desaceleração dessa curva. Em 2017, parece que entramos na fase de maturidade. Pessoas e empresas parecem não estar mais registrando domínios, pois existem outras maneiras de se estar presente na internet (mercados, Facebook, Instagram, etc.).

Contudo, veio a pandemia da COVID-19, que ac elerou muito os negócios digitais.

Registro de domínios .br até 2021

O abismo

Sempre tem um “mas”. Em 1991, Geoffrey Moore escreveu um livro intitulado Crossing the Chasm: Marketing and Selling High- Tech Products to Mainstream Customers.
Nesse livro, ele explica que entre os early adopters (entusiastas) e a early majority (pragmáticos) existe um abismo que muitos produtos não conseguem cruzar. Isso acontece pois os pragmáticos precisam de boas referências para poder comprar um novo produto, e os entusiastas normalmente não são boa referência. Daí a dificuldade de alguns produtos cruzarem esse abismo.

Cruzando o abismo

No livro, Moore também apresenta estratégias para cruzar esse abismo; só que, infelizmente, as estratégias propostas são todas baseadas em estratégias de guerra que, como expliquei no capítulo anterior, não acho que fazem muito sentido para o mundo dos negócios.

A estratégia proposta, tirando a referência à guerra do livro, resume-se em foco. Procure se focar em um único tipo de cliente e resolver muito bem o problema dele com seu produto. Quando esse cliente estiver muito satisfeito, aí é o momento de você procurar novos tipos de clientes.

O abismo descrito por Moore mostra um dos dois possíveis caminhos de um produto de software:

  • Não vai cruzar o abismo: a empresa não consegue fazer seu produto ir além dos entusiastas e, consequentemente, não terá clientes para sobreviver. Esse é um dos motivos da morte prematura de muitas startups.
  • Amadurecer: seu produto vai dar certo e a empresa vai eventualmente chegar ao topo da curva S, e desacelerará até que alguma outra empresa invente um produto que substitua o seu. Veja a Kodak que, até hoje, não se recuperou da invenção das máquinas digitais, pois tinha sua receita vinda primariamente da venda de filmes e material fotográfico.

Com isso, chegamos à quarta fase do ciclo de vida de um produto de software: o fim – em inglês, usa-se um termo mais elegante, sunset.

Temos, então, quatro fases no ciclo de vida de um produto de software: a inovação, o crescimento, a maturidade e o fim.

Ciclo de vida de um produto de software

Vamos agora conhecer cada uma dessas fases em mais detalhes e entender o papel da gestão de produtos em cada uma delas.

Gestão de produtos digitais

Este artigo faz parte 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: