Why individual bonuses don’t work for product teams?

It is fairly common for the CTO or CPO to receive a request from the CEO to create some sort of individual bonus for the product development team. I have heard this kind of questioning quite often in some of the mentoring sessions I do. Something along the lines of “we need to measure people and reward them according to their individual performance, I want to implement the Ambev culture”. Usually, this quote about Ambev comes from the reputation of the strong and aggressive culture of obtaining compensation based on the achievement of individual goals.

Most of the CEOs I know have a sales background. Those that don’t, most likely have sales at the top of their priority list. People on sales teams are normally paid a base salary plus commission on sales, which is an individual incentive. That is, it is very easy, month by month, to identify who are the salespeople with the best and worst contribution to the company based on their sales results, and compensate the best results individually through the sales commission, and work with people with worse performance. Therefore, it is quite natural to think about using this dynamic of recognizing and rewarding individually based on these individual results for all people in a company, including product development teams.

Teamwork

However, in product development teams we have people with different roles, engineering, product design, and product management. This diversity of functions is essential to creating successful products. That’s why the team’s result is the team’s result, it’s the result of teamwork. Individual results are incomplete. It is useless for the product manager to define what will be done to achieve a certain result and solve a certain customer problem, if the product designer does not help in this definition, bringing her knowledge of user experience and interaction design, and if the engineers do not help in this definition and build what was defined. For this reason, the individual bonus makes no sense for product development teams.

Individual vs team bonus

Even Ambev, which has always had a strong culture of achieving individual goals, has changed. In a 2017 interview – in Portuguese – for Época Negócios magazine, Fabio Kapitanovas, then vice president of people and management at Ambev, said that:

The company has sought to increase collaboration among employees — the goals began to include collective variables and not just individual ones. Today, the bonus depends on individual, area and company results. We changed that so that people have an incentive to collaborate more with each other.

In a conversation with Ricardo Okino, a sales specialist, and consultant, who has worked in Linx, Conta Azul, and Vitta, he commented that some companies are already reviewing their compensation plan for commercial teams with the aim of, in addition to the commission, which is an individual bonus, also include team and company goals as part of compensation or as an accelerator. It’s a way to reward a person for their individual results and, at the same time, encourage group work and collaboration behaviors.

How then to recognize and reward the individual?

In commercial teams, even in those that adopt part of the bonus is based on team results, it is reasonably simple and objective to evaluate individual performance.

On the other hand, in product development teams, results do not appear only through individual efforts. Each person on the team has to do their part well for the result to happen. In a situation like this, how to recognize and reward each person on the team individually? First, you need to know how to evaluate people on a product development team. For this, we must look at two components, the “what” and the “how”, that is, what result was achieved by the team and how the person contributed to achieving this result.

Analyzing the “what”, if a certain result is expected from the team, it may make sense to have some kind of bonus for the entire team for a higher than expected result. Normally, this type of bonus can be defined in two ways:

  • the same reward for everyone, such as a dinner, a trip or even a cash prize. This type of bonus helps reinforce the sense of team.
  • some reward based on multiples of salary. In this case, we will already be making some kind of individual reward, given that the salary of people in a product development team is not the same.

When we analyze “how” each person on the product development team contributed to achieving the result, that’s when we have the opportunity to think about how to compensate each person on this team individually. This compensation can be done through a salary increase accompanied or not by an eventual promotion to the next career step. This salary increase directly impacts any team bonuses that are set for the product development team. Let’s imagine that a given product development team is entitled to a bonus of two additional salaries for surpassing a given result. Whoever has a salary of X will receive a 2*X bonus, while whoever has a salary of 1.25*X will receive a 2.5*X bonus.

In other words, the way to reward people from a product development team individually is the evolution that the person will have in their career at the company. People who contribute a lot to achieving and surpassing results end up evolving faster than those who contribute less.

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.

Por que bônus individual não funciona para times de produto?

É razoavelmente comum a pessoa CTO ou CPO receber o pedido da pessoa CEO para criar algum tipo de bonificação individual para o time de desenvolvimento de produtos. Tenho ouvido esse tipo de questionamento com certa frequência em algumas sessões de mentoria que faço. Algo na linha de “precisamos medir as pessoas e premiá-las de acordo com seu desempenho individual, quero implementar a cultura Ambev”. Normalmente essa citação da Ambev vem pelo fama da cultura forte e agressiva de obtenção resultados a partir de metas individuais dessa empresa.

Boa parte das pessoas CEO que conheço têm um background na área de vendas. As que não têm, muito provavelmente têm o tema vendas no topo da lista de prioridades. Pessoas de times de venda são normalmente remuneradas com um salário base mais comissão sobre as vendas, comissão essa de caráter individual. Ou seja, é muito fácil, mês a mês, identificar quem são as pessoas vendedoras com melhor e pior contribuição para a empresa baseado em seus resultados de vendas, e compensar os melhores resultados individualmente por meio da comissão de vendas, e trabalhar as pessoas com pior performance. Sendo assim, é bastante natural pensar em usar essa dinâmica de reconhecer e premiar individualmente baseado nesses resultados individuais para todas as pessoas de uma empresa, incluindo os times de desenvolvimento de produto.

Trabalho em equipe

Contudo, em times de desenvolvimento de produto temos pessoas com diferentes funções, engenharia, design de produto e gestão de produto. Essa diversidade de funções é essencial para a criação de produtos de sucesso. Por isso o resultado do time é do time, é resultado de um trabalho em equipe. Resultados individuais são incompletos. De nada adianta a pessoa gestora de produtos definir o que será feito para atingir determinado resultado e resolver determinado problema da cliente, se a product designer não ajudar nessa definição, trazendo seu conhecimento de experiência do usuário e de design de interação e se as pessoas de engenharia não ajudarem nessa definição e construírem o que foi definido. Por esse motivo não faz sentido a bonificação individual.

Bonificação individual vs de equipe

Mesmo a Ambev, que sempre teve uma cultura forte de atingimento de metas individuais, tem mudado. Em uma entrevista de 2017 para a revista Época Negócios, Fabio Kapitanovas, então vice-presidente de gente e gestão da Ambev, disse que:

A empresa tem buscado aumentar a colaboração entre os funcionários — as metas começaram a incluir variáveis coletivas e não apenas individuais. Hoje, o bônus depende dos resultados individuais, da área e da empresa. Mudamos isso para as pessoas terem incentivo de colaborarem mais entre si.

Em conversa com Ricardo Okino, especialista e consultor de vendas, com passagens por Linx, Conta Azul e Vitta, ele comentou que algumas empresas já estão também revendo seu plano de remuneração para equipes comerciais com o objetivo de, além da comissão, que é uma bonificação individual, incluir também metas de time e da empresa como parte da remuneração ou como acelerador. É uma maneira de premiar uma pessoa pelos seus resultados individuais e, ao mesmo tempo, incentivar comportamentos de trabalho e colaboração em grupo.

Como então reconhecer e premiar o indivíduo?

Em equipes comerciais, mesmo nas que adotarem parte da bonificação sendo baseada em resultados de equipe, é razoavelmente simples e objetivo avaliar a performance individual.

Já em times de desenvolvimento de produto os resultados não aparecem somente pelos esforços individuais. Cada pessoa do time tem que fazer bem sua parte para que o resultado aconteça. Numa situação como essa, como reconhecer e premiar individualmente cada pessoa do time? Primeiro é preciso saber como avaliar pessoas de um time de desenvolvimento de produto. Para isso devemos olhar dois componentes, o “o quê” e o “como”, ou seja, qual resultado foi atingido pelo time e como a pessoa contribuiu para o atingimento desse resultado.

Analisando o “o quê”, se for esperado um determinado resultado do time, pode fazer sentido algum tipo de bonificação para todo o time pelo resultado atingido se tiver sido superior ao resultado esperado. Normalmente esse tipo de bonificação pode ser definida de duas formas:

  • algo igual para todos como, por exemplo, um jantar, uma viagem ou mesmo premiação em dinheiro. Esse tipo de bonificação ajuda a reforçar o senso de time.
  • alguma premiação baseada em múltiplos do salário. Nesse caso, já estaremos fazendo algum tipo de premiação individual, dado que o salário das pessoas de um time de desenvolvimento de produtos não é igual.

Quando analisamos o “como” cada pessoa do time desenvolvimento de produtos contribuiu para o atingimento do resultado é quando temos a oportunidade de pensar em como compensar individualmente cada pessoa desse time. Essa compensação pode ser feita através de aumento de salário acompanhado ou não de uma eventual promoção para o próximo passo da carreira. Esse aumento de salário impacta diretamente em qualquer bônus de equipe que seja definido para o time de desenvolvimento de produto. Se um determinado time de desenvolvimento de produtos tiver uma bonificação por atingir um determinado resultado de duas vezes o salário. Quem tem salário de X receberá 2 * X de bônus, enquanto quem tem salário de 1,25 * X receberá 2,5 * X de bônus.

Ou seja, a maneira de premiar pessoas de um time de desenvolvimento de produto de maneira individual é o própria evolução que a pessoa terá em sua carreira na empresa. Pessoas que contribuem muito para o atingimento de resultados acabam evoluindo mais rapidamente do que aquelas que contribuem pouco.

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.

Innovation: a lot of opportunities

It is likely that, after focusing on the problem and understanding the job to be done, as described on the previous chapter, you will find not only one but a few opportunities to develop a new product or new features for your software product.

I’ve never seen in any organization a situation in which there was an abundance of resources and scarcity of opportunities. Usually, there are always a lot of opportunities ahead, and we don’t know which ones to pursue, because we can’t go after all of them since we don’t hold the necessary resources (time, money and people) available.

In these situations, I like using the opportunity assessment model, proposed by Marty Cagan in his book Inspired: how to create products customers love. Cagan is ex-VP of product management at eBay and currently, he works as a product management consultant.

By answering these 10-questions set, we can gather more information to decide if it’s worth pursuing a given opportunity or if it’s best to re-evaluate it in the future. The questions are very simple:

  • Which problem will it solve? — value proposition;
  • To whom this problem will be solved? — target market;
  • What is the size of this opportunity? — market size;
  • What are the alternatives? — competition scenario;
  • Why are we better qualified to pursue this opportunity? — our uniqueness;
  • Why now? — window of opportunity;
  • How are we going to take this opportunity to the market? — launching strategy;
  • How are we going to measure success and make money with this product? — metrics and revenue;
  • What are the critical factors for success? — essential requirements;
  • After answering the above, what is the recommendation? — go or no-go.

Questions 1 to 4 will help to understand the opportunity.

Questions 5 and 6 are very interesting because it is not enough to understand the opportunity and find it a good one. It is necessary to be sure that this is the right moment and that we have more expertise to pursue it.

From 7 to 9, there are what-if questions, that is, considering that the decision is to pursue this opportunity, how is it going to be presented to the market, how the success will be measured and what are the critical factors for success.

Answering these questions is good not only to decide if it’s worth developing a given product, but it also helps the partnership opportunities, opportunities to develop new features, and opportunity to attend a special client that needs changes in the product. Ultimately, every opportunity will require your or your team’s effort and should be analyzed to see if the revenue compensates for the required investment.

How many opportunities to pursue at the same time?

Another important tip is not pursuing many opportunities at the same time; otherwise, you and your team will lose focus and end up not getting return in any of the pursued opportunities.

In an ideal world, the recommended is to pursue one opportunity at a time. However, knowing that this is utopic, we will end up pursuing more than one opportunity simultaneously. Try to limit this amount to a few units (2, 3 or 4, maximum) reminding that, at any time, you and your team can only concentrate in one thing at a time.

In other words, if you are working on more than one opportunity simultaneously, every time you want to work in one of them you’ll not be working in the other ones momentarily. Therefore, stick yourself to pursue a few opportunities, preferably one at a time.

New opportunities vs. existing product improvements

This is a very common question. Should I pursue new opportunities? And what do I do with the pains of current customers? Should I develop a new product or new feature? Or should I solve current customer pain by developing improvements to my product? How to balance between pursuing new opportunities and implementing improvements to an existing product?

Here the solution is simple, at least in theory. Current product is current product, new opportunities are new opportunities. Each has to be treated separately. Ideally, they should be treated even by different teams. The thing is that is not always possible.

In such cases, if we want to pursue new opportunities, this team needs to be able to clearly separate work on existing products versus work on new opportunities. For example, two weeks for the existing product and one week for the new opportunity, until it is justified to create a new team for the new opportunity.

Warning: It’s not a bug team

This is an important point. The idea is not to separate teams to have one team doing new things and the other fixing bugs in the existing product. This does not work as it will create a very large separation between the two teams.

Anyone who does new things will eventually believe that they can do anything without worrying so much about quality, as there is a bug-focused team. On the other hand, the “bug team” will find it doing janitorial work, cleaning up the mess that other people do.

Opportunities vs. improvements

Before investing in a new opportunity, it is very important to understand why you are investing in it. A great tool for this is the opportunity assessment, described earlier. Without a clear understanding and the right engagement of everyone involved, one can put the opportunity to waste without even starting to explore it.

An important point that everyone involved should understand is that a new opportunity is a new opportunity, that is, it should generate results that aggregate to the current ones. These results should be sufficient to justify the creation of a new team to pursue this new opportunity. At least two software engineers.

Ideally, besides two engineers, it would be good to have a product manager, a UX designer, and a product marketer dedicated to this new opportunity. It will be a new product or a new feature. When this new product or new feature is ready and launched, those who worked on its development will take care of its bugs and enhancements.

Meanwhile, the other team takes care of the current product, that is, improving the current product so that it continues to achieve its goals. Improving the current product means fixing bugs, but it also means doing new things on the existing product. Improvements to make the product better, more useful and more usable.

If it is not possible to create a new team, you can share the time of the same team. Something like a week or two for bugs and enhancements to the current product, and a week for the new opportunity, until it is justified to create a new team for the new opportunity.

How to tell if it’s an improvement or a new opportunity?

It is the responsibility of the product manager, along with the team, to understand if this new thing that came up to be done is an opportunity or an improvement. But how to discern between improvement and opportunity? Especially when the new thing to do is a new feature of the existing product, should we look at it as a new opportunity or an enhancement of the existing product?

It depends on the effort and return involved. A new opportunity must have a high return to make sense of pursuing it. Remember that a new opportunity will eventually have a team just to take care of it, so the return must be sufficient to justify this new team. If the return is uncertain, it is best not to draw energy from the existing product to pursue it.

On the other hand, if there is the prospect of a good return, what is the effort to create something to exploit this opportunity? And what will be the effort to maintain this something? These two questions should guide the way you look. If the effort is low, this new thing can be treated as an improvement and developed by the current team. If the effort is high, it is recommended to treat it as a new opportunity and consider having a separate team to do the development.

Validating opportunities

After analyzing opportunities, the next step is to validate them, that is, to see if there are people interested in this product of yours that will solve the problem you researched. There are some ways of doing that. The first one is going back to the street and talking to possible clients. This will be an exploratory conversation in which you expose the problem to people who probably deal with it. Later, you tell about the solution that will be developed and evaluate the reaction. Just like that. The problem of telling about a solution is that, as better as it is the description, it is still not a ready product, and forces the person to imagine something that can be quite different from what you are conceiving.

In 2011, I decided to perform a little more realistic validation. At that time, I’ve conducted a startup experiment, did my initial research and ended up with 3 product ideas to develop. Having a hard time choosing in which of the 3 ideas to invest my money, my energy, and my time, I decided to take a simple test. I chose a name and a domain for each one of the ideas and registered them. Later, I created a webpage for each of the ideas of web products I’ve had. As I’m not a designer, nor have any skills to build beautiful pages, I used a site called unbounce, which enables us to create simple pages and even A/B tests in a very easy way. Using unbounce, I created the following page:

Sample website on unbounce

Note that this page only has 3 points that describe the product: one to talk about the problem; another one to talk about the solution; and a third one to inform the price.

The email form was useful to gather the amount of people interested. I’ve made a Google Adwords campaign of $ 10.00 per day per product that I wanted to text, during a month.

Below is a partial result of this validation:

Partial result on unbounce

This image is a screen of unbounce. After 30 days of tests, I ended up with 216 email addresses interested on ContaCal — the product I launched in 2011 that is running until today — and 1,043 pageviews, giving me 20.7% in conversion rate.

The other two ideas also kept the same trend of this partial result. But I preferred to let them unreadable in order not to influence anyone to bet in any of them without further validation.

For those who don’t know, ContaCal is a nutrition journal in which users record their eating and the system informs the total amount of calories, with a twist. Aside the total amount of calories, it also informs the quality of calories through a color system. The colors indicate how healthy that food is. If the calories are red, it is best to avoid them. Yellow calories can be ingested moderately. And the green calories have no restriction.

The total cost of this test was R$ 990.00:

  • AdWords campaign: $900.00.
  • Domains: $90.00.
  • Unbounce site: free for 30 days; after this period, $ 85.00 per month for up to 5 different domains that I would want to test at the same time.

Each new idea costs $ 30.00 by domain .br, and other $ 300.00 per month with a Google Adwords campaign if we make an investment of $ 10.00 per day.

A very important point to notice is that ContaCal was not necessarily the best of opportunities, but the best one for me to communicate. Therefore, this validation is interesting, for it helps not only to test the idea of a product but its capacity to communicate as well.

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: Muitas Oportunidades

É provável que, após se focar no problema e entender o trabalho a ser feito, como descrito no capítulo anterior, você descubra não só uma, como algumas oportunidades de desenvolvimento de novo produto, ou de funcionalidades novas para seu produto de software.

Nunca vi em nenhuma organização uma situação em que abundavam os recursos e havia escassez de oportunidades. Via de regra, sempre há muitas oportunidades pela frente, e não sabemos qual ou quais perseguir, pois não conseguimos perseguir todas já que não temos os recursos necessários (tempo, dinheiro ou pessoas) disponíveis.

Nessas situações, gosto de usar o modelo de análise de oportunidade, proposto por Marty Cagan, em seu livro Inspired: how to create products customers love. Cagan é ex-vice-presidente de gestão de produtos no eBay e, atualmente, consultor sobre gestão de produtos.

Respondendo a um conjunto de 10 perguntas, podemos ter mais informação para decidir se vale perseguir uma determinada oportunidade agora ou se é melhor deixar para reavaliá-la no futuro. As perguntas são bem simples:

  1. Qual problema vai resolver?–proposição de valor;
  2. Para quem esse problema será resolvido?–mercado alvo;
  3. Qual o tamanho dessa oportunidade? – tamanho do mercado;
  4. Que alternativas existem?–cenário competitivo;
  5. Por que somos os melhores qualificados para perseguir essa oportunidade? – nossa diferenciação;
  6. Porque agora?–janela de oportunidade;
  7. Como levaremos essa oportunidade ao mercado? – estratégia de lançamento;
  8. Como vamos medir o sucesso e ganhar dinheiro com esse produto? – métricas e receita;
  9. Que fatores são críticos para o sucesso? – requisitos essenciais;
  10. Dado o acima, qual a recomendação?–go ou no-go.

As perguntas de 1 a 4 servem para entender melhor a oportunidade. Já as 5 e 6 são bem interessantes, pois não basta só entender a oportunidade e ela ser muito boa. É preciso ter certeza de que esse é o momento certo e que nós somos os mais qualificados para persegui-la.

De 7 a 9 são perguntas do tipo “e se…”, ou seja, supondo que se decida por perseguir essa oportunidade, como ela vai ser levada ao mercado, como será medido o sucesso e quais fatores são críticos para o sucesso.

Responder a esse questionário é bom não só para decidir se vale a pena desenvolver um determinado produto, ele também pode ajudar com oportunidades de parceria, oportunidades de desenvolver novas funcionalidades, e oportunidade de atender um cliente especial que requer mudanças no seu produto. Enfim, todas as oportunidades que vão requerer esforço seu e do seu time podem e devem ser analisadas para ver se o retorno compensa o investimento de esforço requerido.

Quantas Oportunidades Perseguir ao Mesmo Tempo?

Outra dica importante é não perseguir muitas oportunidades ao mesmo tempo; caso contrário, você e seu time perderão o foco e acabarão não obtendo retorno de nenhuma das oportunidades perseguidas.

No mundo ideal, o indicado é perseguir uma oportunidade por vez. Porém, como sabemos que isso é utópico, acabaremos perseguindo mais de uma oportunidade simultaneamente. Procure limitar essa quantidade a poucas unidades (2, 3 ou 4, no máximo), lembrando de que, em qualquer momento, você e seu time só conseguem dar atenção a uma coisa por vez.

Se você estiver trabalhando em mais de uma oportunidade ao mesmo tempo, toda vez que quiser trabalhar em uma delas, deixará de trabalhar momentaneamente nas outras. Por isso, restrinja a poucas oportunidades para perseguir, preferencialmente, uma por vez.

Novas Oportunidades vs. Melhorias no Produto Existente

Essa é uma dúvida bastante frequente. Devo perseguir novas oportunidades? E o que faço com as dores dos clientes atuais? Devo desenvolver um novo produto ou uma nova funcionalidade? Ou devo resolver dores dos clientes atuais desenvolvendo melhorias em meu produto? Como fazer para balancear entre perseguir novas oportunidades e implementar melhorias no produto existente?

Aqui a solução é simples, pelo menos em teoria. Produto atual é produto atual, novas oportunidades são novas oportunidades. Cada um tem de ser tratado de um jeito. O ideal é que sejam tratados até mesmo por times diferentes. Só que nem sempre isso é possível. Nesses casos, se quisermos perseguir novas oportunidades, esse time precisa saber separar claramente o trabalho no produto existente versus o trabalho nas novas oportunidades. Por exemplo, 2 semanas para o produto existente e uma para a nova oportunidade, até que se justifique a criação de um novo time para a nova oportunidade.

Atenção: não é time de bugs

Esse é um ponto importante. A ideia não é separar os times para ter um time fazendo coisas novas e outro corrigindo bugs do produto existente. Isso não funciona, pois vai criar uma separação muito grande entre os dois times.

Quem faz coisas novas vai eventualmente acreditar que pode fazer qualquer coisa sem se preocupar tanto com qualidade, já que existe um time focado em correção de bugs. Do outro lado, o “time de bugs” vai achar que está fazendo trabalho de faxineiro, limpando as bagunças que outras pessoas fazem.

Oportunidades vs. melhorias

Antes de investir em uma nova oportunidade, é muito importante entender por que está investindo nela. Uma ótima ferramenta para isso é a análise de oportunidades, descrita anteriormente. Sem um claro entendimento e correto engajamento de todos os envolvidos, pode-se colocar a oportunidade a perder sem nem mesmo começar a explorá-la.

Um ponto importante que todos os envolvidos devem entender é que uma nova oportunidade é uma nova oportunidade, isto é, ela deverá gerar resultados que se somam aos atuais. Esses resultados deveriam ser suficientes para justificar a criação de um novo time para perseguir essa nova oportunidade. No mínimo, dois engenheiros de software.

Idealmente, além dos dois engenheiros, seria bom ter um gestor de produtos, um designer de UX e uma pessoa de marketing de produto dedicados a essa nova oportunidade. Ela será um novo produto ou uma nova funcionalidade. Quando esse novo produto ou nova funcionalidade estiver pronto e lançado, quem trabalhou no seu desenvolvimento vai cuidar de seus bugs e melhorias.

Enquanto isso, o outro time cuida do produto atual, isto é, de melhorar o produto atual para que ele continue atingindo seus objetivos. Melhorar o produto atual significa sim corrigir bug, mas significa também fazer coisas novas no produto existente. Melhorias para tornar o produto melhor, mais útil e mais usável.

Caso não seja possível criar um novo time, pode-se fazer compartilhamento do tempo do mesmo time. Algo como uma ou duas semanas para bugs e melhorias do produto atual, e uma semana para a nova oportunidade, até que se justifique a criação de um novo time para a nova oportunidade.

Como saber se é uma melhoria ou uma nova oportunidade?

É responsabilidade do gestor de produtos, junto com o time, entender se esse algo novo que surgiu para ser feito é uma oportunidade ou uma melhoria. Mas como discernir entre melhoria e oportunidade? Especialmente quando o algo novo a fazer for uma nova funcionalidade do produto existente, devemos encarar como nova oportunidade ou melhoria do produto existente?

Depende do esforço e do retorno envolvidos. Uma nova oportunidade deve ter um retorno alto para fazer sentido persegui- la. Lembre-se de que uma nova oportunidade vai eventualmente ter um time só para cuidar dela, então é preciso que o retorno seja suficiente para justificar esse novo time. Se o retorno for incerto, é melhor não tirar energia do produto existente para persegui-la.

Por outro lado, se houver a perspectiva de um bom retorno, qual o esforço de criar algo para explorar essa oportunidade? E qual será o esforço para o manter? Essas duas perguntas devem orientar a forma de encarar. Se o esforço for baixo, esse algo novo pode ser tratado como uma melhoria e ser desenvolvido pelo time atual. Se o esforço é alto, é recomendável tratá-lo como nova oportunidade e considerar ter um time separado para fazer o desenvolvimento.

Testando Oportunidades

Depois de analisar as oportunidades, o próximo passo é testá- las, ou seja, ver se realmente existem pessoas interessadas nesse seu produto que resolverá o problema que você pesquisou. Existem algumas maneiras para fazer isso. A primeira é voltar para a rua e conversar com possíveis clientes. Essa será uma conversa exploratória na qual você expõe o problema para pessoas que provavelmente o tenham. Em seguida, você conta sobre a solução que será desenvolvida e avalia a reação. Simples assim. O problema de contar sobre uma solução é que, por melhor que seja a descrição, ela ainda não é um produto pronto, e força a pessoa a imaginar algo que pode ser diferente daquilo que você está concebendo.

Em 2011, resolvi fazer um teste um pouco mais realista. Nessa época, conduzi um experimento de startup, fiz minha pesquisa inicial e acabei com 3 ideias de produto para desenvolver. Com dificuldade para escolher em qual das 3 oportunidades investir meu dinheiro, minha energia e meu tempo, resolvi fazer um teste bastante simples. Escolhi um nome e um domínio para cada uma das ideias e os registrei. Em seguida, criei uma página para cada uma das ideias de produto web que tive. Como não sou designer, nem tenho qualquer habilidade para fazer páginas bonitas, usei um site chamado unbounce (http://unbounce.com), que permite criar páginas simples e até testes A/B de forma bem fácil. Com o unbounce, criei a seguinte página:

Tela do ContaCal no unbounce

Note que essa página tem só 3 pontos que descrevem o produto: um para falar do problema; outro para falar da solução; e um terceiro para falar do preço. O formulário de e-mail serviu para captar a quantidade de interessados. Rodei uma campanha no Google AdWords de R$10,00 por dia por produto que queria testar durante um mês. Veja um print de um resultado parcial:

Resultado parcial no unbounce

Esse print é de uma tela do unbounce. Depois dos 30 dias de testes, terminei com 216 e-mails interessados no ContaCal – que foi o produto que acabei lançando e está no ar até hoje – e 1.043 pageviews, o que dá 20,7% de taxa de conversão. As outras duas ideias também mantiveram a mesma tendência desse resultado parcial. Preferi deixá-las ilegíveis para não influenciar ninguém a apostar em alguma delas sem fazer testes.

Para quem não conhece, o ContaCal é um diário alimentar virtual no qual o usuário registra sua alimentação e o sistema informa a quantidade total de calorias, como de um chocolate twix. Além da quantidade total de calorias, ele também informa a qualidade das calorias por meio de um sistema de cores. As cores servem para indicar quão recomendável é ingerir o alimento. Se é um alimento de calorias vermelhas, é melhor evitá-lo ao máximo. Calorias amarelas podem ser ingeridas com moderação. Já as calorias verdes podem ser ingeridas sem restrição.

O custo total desse teste foi de R$990,00:

  • Campanha AdWords: R$900,00.
  • Domínios: R$90,00.
  • Site unbounce: grátis por 30 dias; se passasse, pagaria R$85,00 por mês para até 5 domínios diferentes que eu quisesse testar ao mesmo tempo.

Cada nova ideia custa R$30,00 por registro de domínio .br, e mais R$300,00 por mês de campanha no Google AdWords se fizermos um investimento de R$10,00 por dia.

Um ponto importante a observar é que não necessariamente o ContaCal era a melhor das três oportunidades, mas sim a que eu melhor consegui comunicar. Por isso, esse teste é interessante, ajuda não só a testar a ideia de um produto como também a sua capacidade de comunicar.

Gestão de produtos digitais

Este artigo é o 12º 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:

Innovation: the job to be done

Professor Clayton Christensen teaches at Harvard and wrote several books — among them The Innovator’s Dilemma: the revolutionary book that will change the way you do business[^InnovatorDilemma], a must-read for all those who work in technology –, and he developed a technique to find out problems to be solved, called “the job to be done”.

[^InnovatorDilemma]: The Innovator’s Dilemma: The Revolutionary Book That Will Change the Way You Do Business, by Clayton M. Christensen, Harvard Business Review Press; 1st edition (1997)

The idea behind “the job to be done” is that we must understand for which job our clients have “hired” our products. In other words, the job our clients expect that our products will perform.

Clayton illustrates this technique with a very interesting example. He was hired to evaluate a specific product of a diner, the milkshake. The company had already surveyed clients asking what they wanted: creamier milkshakes, with cookies crumble, fruit or chocolate, or with more syrup. The answer of the research pointed out to a preference, which was implemented. However, this preference didn’t increase the sales, the main goal of the company.

Clayton decided to do the survey differently. Instead of asking what the clients wanted, he looked for understanding what was the work for which people hired the product, in this case, the milkshake. After many conversations with clients, he discovered that they passed by at the diner before going to work and spent a lot of time in the traffic. The milkshake was creamy and you could drink it using a straw, so it would take time to finish it. It would take the whole time of the trip to work, that is, it would entertain the client during the whole trip to work. People hired the morning milkshake before driving to work to have something to get entertained on the way.

They have already tried with other competitors, such as fruit juices, but they ended up very fast. They tried with bagels, but the work and mess to eat it didn’t compensate. The milkshake was perfect for this job to be done!

After understanding the job to be done, the diner could improve the milkshake, making it creamier and putting little fruit pieces and/or cereal in it, in order to add small surprises while the clients savor it. In addition, it set an attendance system that minimized lines to guarantee a minimum waiting time, for understanding that its clients were in a hurry and didn’t want to wait in the diner. These adjustments did bring sales improvements.

The “job to be done” market research

Clayton himself argues that, in traditional marketing, it is common to associate a certain product to a certain demographic group. For example, in the previous case, if we were responsible for the product management of the diner, we could relate milkshakes to people of a certain age who work and, consequently, always look for creamy milkshakes that last long. It happens that, using the technique “job to be done”, we have a wider view of where the product stands.

Clayton extended his survey to other periods of the day and caught the same people going back to the diner later in the afternoon, but now with their kids, for a quick meal. Often, the kids asked for a milkshake. The diner served the same milkshake: creamy, large and that lasted long. But parents didn’t want to wait that long for kids to finish their milkshakes; it was only a quick meal.

In this case, in spite of being the same client, the job to be done was another: to please the client’s kid quickly. Therefore, the milkshake could be smaller, maybe half of the size, and less creamy so it wouldn’t last long.

That is, the same client wants the same product doing different jobs, depending on the situation. That’s the importance of understanding the job to be done.

Understanding problems and their context

In the previous chapter and on this one, we learned how to understand more about a problem of a group of people; to deeply understand their problems and the context in which they take place, and to understand the motivation people have to want it solved.

Eventually, by using the technique of the job to be done, the suspicion appears: do we have a good opportunity in our hands? Or still, we can find more than one problem. So, how do we choose among all these problems? What is the best opportunity to be explored? This is the topic of the next chapter, stay tuned!

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: o trabalho a ser feito

O Prof. Clayton Christensen, professor de Harvard e autor de vários livros – dentre eles The Innovator’s Dilemma: the revolutionary book that will change the way you do business, obrigatório para todas as pessoas que trabalham com tecnologia –, desenvolveu uma técnica para descobrir problemas a serem resolvidos, chamada “o trabalho a ser feito”.

A ideia por trás do “trabalho a ser feito” é que precisamos entender para qual trabalho nossos clientes contrataram nossos produtos, isto é, qual o trabalho que nossos clientes esperam que nossos produtos façam.

Clayton ilustra essa técnica com um exemplo muito interessante. Ele havia sido contratado para avaliar um produto específico de uma lanchonete, o milkshake. A empresa já tinha feito pesquisas com os clientes perguntando o que eles queriam: se eram milkshakes mais densos, com pedaços de biscoito, de fruta ou de chocolate, ou com mais calda. A resposta da pesquisa apontou para uma preferência, que foi implementada. Contudo, essa preferência em nada mudou as vendas, o que era o objetivo principal da empresa.

Clayton decidiu fazer, então, a pesquisa de forma diferente. Em vez de perguntar o que os clientes queriam, procurou entender qual era o trabalho para o qual as pessoas contratavam o milkshake. Após várias conversas com clientes, descobriu que os clientes passavam na lanchonete antes de ir para o trabalho de carro e que ficavam bastante tempo no trânsito. O milkshake, por ser grosso e ser tomado de canudo, demorava para acabar. Demorava o tempo todo da viagem, ou seja, entretinha o cliente durante toda a viagem até chegar ao trabalho. As pessoas contratavam o milkshake de manhã antes de ir para o trabalho de carro para ter com que se entreter no caminho.

Elas já haviam tentado com outros “concorrentes”, como bananas, mas acabava muito rápido. Tentaram também com bagels, mas o trabalho e a sujeira para passar manteiga não compensava. O milkshake era perfeito para esse trabalho a ser feito!

Entendendo o trabalho a ser feito, a lanchonete pôde melhorar o milkshake, deixando-o mais denso e colocando pequenos pedaços de fruta e/ou cereais para adicionar pequenas surpresas enquanto seus clientes os degustavam. Além disso, preparou um sistema de atendimento que minimizou as filas para garantir um tempo mínimo de espera, por entender que seus clientes estavam com pressa e não queriam ficar esperando na lanchonete. Esses ajustes, sim, trouxeram melhorias nas vendas.

O alcance da técnica do “trabalho a ser feito”

O próprio Clayton comenta que, no marketing mais tradicional, é comum associar um determinado produto a um determinado conjunto demográfico. Por exemplo, no caso anterior, se fôssemos responsáveis pela gestão de produtos da lanchonete, poderíamos associar milkshakes com pessoas de certa idade que trabalham e que, consequentemente, sempre procuram milkshake densos que demorem para acabar. Acontece que, usando a técnica do “trabalho a ser feito”, temos uma visão mais ampla do contexto onde o produto está inserido.

Clayton estendeu sua pesquisa para outros períodos do dia e pegou as mesmas pessoas voltando à lanchonete no fim da tarde, só que agora com seus filhos, para um lanche rápido. Com certa frequência, os filhos pediam aos pais por um milkshake. A lanchonete servia o mesmo milkshake: denso, grande, e que demorava para acabar. Só que os pais não queriam esperar muito tempo para que os filhos terminassem seus milkshakes; era para ser um lanche rápido.

Aqui, apesar de o cliente ser o mesmo, o trabalho a ser feito era outro: agradar o filho do cliente de forma rápida. Sendo assim, o milkshake poderia ser menor, talvez metade do tamanho, e menos denso, para acabar mais rápido.

O mesmo cliente quer que o mesmo produto faça trabalhos diferentes, a depender da situação. Daí a importância de entender o trabalho a ser feito.

Compreendendo os problemas e seu contexto

Neste capítulo e no anterior, aprendemos como entender mais sobre um problema de um grupo de pessoas; entender a fundo seus problemas e o contexto em que eles acontecem; e entender a motivação que as pessoas têm para querer que ele seja resolvido.

Eventualmente, ao usarmos a técnica do trabalho a ser feito, fica a dúvida: será que temos uma boa oportunidade em mãos? Ou ainda, pode acontecer de encontrarmos mais de um problema. Como escolher, dentre esses problemas, qual é a melhor oportunidade a ser explorada? É o tema do próximo capítulo.

Gestão de produtos digitais

Este artigo é o 12º 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:

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.

Interview

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.

Survey

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.

Observation

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: Registro.br, the Brazilian registrar for .br domains released an API to allow Locaweb to charge the customer domain on behalf of Registro.br. 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 Registro.br would continue billing the domain. What happens if the customer pays both bills? And if she pays only Registro.br? 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 Registro.br. Since it would be possible to charge for Registro.br 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 Registro.br 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 Registro.br 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 http://fitnesspartner.com/waiver”.

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.

Concluding

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:

Entrevista

É 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.

Pesquisa

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ã.

Observação

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 Registro.br, o registrador brasileiro de domínios .br, lançou uma API para permitir à Locaweb cobrar o domínio do cliente em nome do Registro.br. 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 Registro.br continuaria cobrando o domínio. O que aconteceria se o cliente pagasse as duas contas? E se ela pagasse apenas o Registro.br? 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 Registro.br. Como seria possível cobrar pelos serviços do Registro.br, 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 Registro.br 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 Registro.br 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 http://fitnesspartner.com/termoderenuncia”.

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.

Concluindo

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.

OKRs

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.

OKRs

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.

Resumindo

  • 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: