End of life

Your digital product may have arrived here coming from three different paths:

  1. Your product growth has slowed, and you have done all the analysis and testing described in the previous chapter to make sure that it has indeed reached the stage of maturity.
  2. Or, you have launched your product and are unable to bridge the chasm that lies at the end of the innovation phase, the first phase of the life cycle of your digital product.
  3. Or, you have opted for a scheduled maturity by planning the end-of-life of the current version of your software product against a new one that has been developed and released.

Regardless of the path you take – unscheduled maturity, not crossing the abyss or programmed maturity – you have eventually reached what is known as the product’s end of life. Sometimes product managers use a more elegant term for this phase, the sunset of the product.

As with all previous phases, this phase also has to be managed. It is a mistake for a product manager to believe that when a product reaches the end of its life, the work of product management ends. On the contrary, this phase requires as much attention as the previous ones.

The first step is to recognize that you have reached the end of life, and a great indicator is to assess whether the cost of maintaining the product is greater than the return it gives. If this happens, there is a strong indication that it is entering this phase.

Cost vs. return

The decision to end a product’s life is not scientific. The numbers help a lot in this decision; however, as explained in the Growth: thoughts on metrics chapter, in addition to metrics, you need to use other information such as experience, intuition, judgment, and qualitative information to make the end-of-life decision for the product.

Each of the three possible pathways your product may have taken to the end-of-life phase will bring with it specific facts and considerations for making your making decisions about your product. Typically, this is a committee decision-making with product people and company executives.

If your product has indeed entered the end of life, the product manager will need to manage this phase. The decision and its management depend on the path it takes to reach it, and this is what we will see in the following sections.

End of life by unscheduled maturity

This is the worst case because besides being unplanned — as is the case with end-of-life after programmed maturity — this is a difficult situation to identify. Before you decree that it is the end of life of your digital product, you need to make sure that it is not only temporary. The most common in these cases is to numb the product for a while.

What does numb mean? It means not investing in its development and marketing, and watching how it behaves. Has it stopped growing? Or does it grow very slowly? Does it make sense to stop selling it? Or can the product be left in the market for a while? After some numb time, you should re-evaluate whether it is worth investing again in it.

This was the case with Locaweb’s Virtual PBX product, which we decided to lay dormant for about 3 years, without any marketing and development investment so that we could invest in other products. Even without any investment, the number of customers did not decrease. Even at times, when there was growth. This growth, when it happened, was quite small, but it was nonetheless a growth. For this reason, we decided to invest in the product again.

Another example, already commented on in the previous chapter, was the case of Locaweb’s Web Hosting product which, because we focused too much on metrics and disregarded our empirical knowledge, ended up in a non-growth situation that, fortunately, could be corrected. It was not web hosting end-of-life. It was a growth deceleration we caused to the product.

By that, I mean again to be very careful not to make a hasty decision because the end of life by unscheduled maturity is extremely difficult to identify.
If you are really sure your product has reached the end of its life, you will need to manage this phase. The first decision you should make, along with the committee I mentioned — made up of people who work with the product and company executives — is whether you will discontinue the product or make it dormant. This decision will be based on the return it is giving to the company and the cost of maintaining it.

If the product still yields a considerable return, you are likely to decide to maintain it and make efforts to reduce the cost of maintenance. The product manager will be responsible for coordinating maintenance cost reduction efforts and assessing whether these costs are lower than the return that the product gives.

On the other hand, if the return on this product is small, or your operating costs are too large and not reducible, you are likely to discontinue it. In this case, the manager should coordinate all necessary steps to discontinue the product, including:

  1. Set the sales end date and execute it;
  2. Check for a replacement in the company’s product portfolio or in the marketplace;
  3. If there is a substitute, define how a client can migrate to this one;
  4. Prepare communication with customers by setting deadlines for the end of the product;
  5. Test this communication with a small group of customers to assess the impact and make the necessary adjustments;
  6. Perform communication with the entire customer base;
  7. Follow up and act on time when necessary.

End of life by not crossing the chasm

If your product enters the end of life because it does not cross the chasm, although this is not a desired situation for the development team, it is an important situation that needs to be identified quickly, and the product manager plays a key role in detecting this.

This situation is easier to detect because the product does not grow. He wins a few clients, the early adopters, and then stops growing. At this point, you should assess with your marketing manager whether the product communication strategy is effective and is reaching people who have the problem your product is intended to solve.

It is also important to understand with potential customers whether the product not only solves the problem but how they are willing to compensate you for that product. You can always make adjustments to the product and your marketing model to suit your customers.

However, if even after evaluating these issues and trying to make adjustments to the product and/or your marketing model, you are unable to make it grow, it is time to decree its end of life. The sooner you reach this decision, the better, so as not to waste time and investment on a product that will not work.

In this case, as the product has a small customer base, the options of keeping it dormant based on having a sizable revenue make no sense. Therefore, the only viable decision is to discontinue the product. As in the case of unplanned end-of-life, here too the product manager must coordinate all the steps necessary to discontinue it, which are the same as those described earlier in the Unplanned End of Life section.

End of life by scheduled maturity

This is the best of the three options for the software owner, but it will give the product manager a hard time. In the case of installed software, this happens when new versions are released. For online software, this occurs when the development team chooses to rewrite the product for some reason and decides to release a new version. This decision to rewrite a product online should be very thoughtful because the time spent rewriting your product is unused time in its evolution from the point of view of those who use it.

It may happen that your product was not properly planned from a technical point of view and now you are at a point where: either rewrite it, or the product can no longer evolve. However, falling into such a situation should be the exception rather than a normal part of a digital product’s life cycle.

In a nutshell: for installed software, end-of-life by scheduled maturity is intrinsic to the model, while for online software, end-of-life by scheduled maturity should always be the exception.

Because this kind of end-of-life can be programmed, the product manager must, in conjunction with UX and product engineering, design what this phase will look like, always aiming for minimal impact on customers. At Locaweb, in our email marketing product, we got to the point where we had to change the database. We used MongoDB which, due to design problems, was not able to withstand product growth; that’s why we decided to change the database to PostgreSQL.

We designed this rewrite of the product in such a way that the customer would not be negatively impacted when the new version with PostgreSQL was implemented. Nothing has changed in the way customers use the product. The only impact they noticed was that the product was performing better, which was expected.

This is the most important point to think about at the end of life: what will happen to customers who are in the current version, which will become the “old” version when we launch the new one? This has to be carefully thought out, and the focus must always be on minimal impact on the customer.

Of course, when the new version has a different interface and interaction than the old version, the customer will be impacted. It is very important to test some of them to measure impact before forcing change for the entire customer base. In some situations, you may even decide to keep the old version for a while, given the difficulty of getting customers to the new version. But don’t forget, the focus is always to make your customer suffer as little as possible.


We saw in detail in previous chapters the entire life cycle of a software product, going through all its phases: innovation, growth, maturity — whether it can be programmed or not — and the end of life — that can come after maturity or when the product does not cross the chasm that separates the innovation phase from the growth phase.

To conclude this life cycle theme, let’s talk now about the difference between a startup and digital product management. This difference has a lot to do with the life cycle of a software product.

Product leadership advisor

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

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.

Product Manager’s #1 priority

In my recent articles, I’ve been discussing why “business demands => technology implements” doesn’t work, why business people hate discovery and I’ve introduced the concept of MVD (Minimum Viable Discovery).

Today I’ll talk about every Product Manager’s #1 priority which, I believe, will be a good addition to the 3 articles cited above.


To start this article, I want to propose a quiz. Based on your experience, what is every Product Manager’s #1 priority?

  1. Have a product vision and a sound strategy to execute this vision
  2. Have a good enough understanding of the user’s problem so the team can iterate quickly on solution hypotheses and deliver the best solution as fast as possible
  3. Create a complete Opportunity Tree to help the team assess opportunities and work on the ones that can validate solution hypotheses as fast as possible
  4. All of the above
  5. None of the above

Let’s analyze each of the answers above to find the correct answer and better understand why this is the correct answer:

Have a product vision and a sound strategy to execute this vision

I’ve already mentioned in the past that creating the vision is critical for every product leader and every product manager to do their job. Without:

  • having a clear understanding of the vision of your product
  • having this product vision clearly aligned with the leaders of your company
  • constantly communicating this vision to the entire company

It is very difficult to do anything with your product. How do you prioritize without knowing where you should lead your product? How to say no to the constant requests from your product’s stakeholders (company employees, customers, partners)? From this vision, a Product Manager can create a clear strategy on how to execute this vision. However, this is not the Product Manager’s #1 priority. It is a means to get this #1 priority.

Have a good enough understanding of the user’s problem so the team can iterate quickly on solution hypotheses and deliver the best solution as fast as possible

This is what I’ve been discussing in my latest articles and this is very important to get to the Product Manager’s #1 priority. We must never jump directly to implementing solutions, not when asked by business people to implement their demand and not when knowing about a problem and start implementing the first solution that comes to mind. We know that as we learn something about a problem, we should also map solution hypotheses, and test these solutions as fast as possible so we can deliver the best solution as fast as possible. However, as the first answer, this is not the #1 priority. Again, it’s a means to an end.

Create a complete Opportunity Tree to help the team assess opportunities and work on the ones that can validate solution hypotheses as fast as possible

This answer is a variation of the above question just making explicit a good tool to iterate from problem to solution, the Opportunity Tree. I mentioned this tool in my article about the two sides of product discovery. It helps a product team better understand the expected outcome, map the opportunities that can generate the outcome, generate possible solutions for the opportunities and build experiments to test the solutions. However, this answer is a little worse than the previous answer because it talks about creating a complete opportunity tree. We should use the opportunity tree to have a good enough understanding of the problem to scope out possible solutions and get to the expected result (outcome) as fast as possible. And again, this is a means to an end. It’s not the Product Manager’s #1 priority.

All of the above

So let’s put it all together and make it the Product Manager’s #1 priority, right? No! As explained above, these are all tools that a Product Manager can use to get to her #1 priority. Besides that, I believe it’s quite easy to understand why this one is not the correct answer. We are asking what’s every Product Manager’s #1 priority, so this priority cannot be 3 things. It must be only one thing! This is a common mistake some Product Managers incur, having more than one priority. When a product manager is asked what are her priorities, she cites a list of things, which is somewhat ok if, and only if, she knows and constantly works on her #1 priority, which we will know what it is pretty soon! (=

None of the above

I guess that after reading the explanation of why the previous 4 answers are incorrect, you probably know that “none of the above” is the correct answer. However, despite the fact that this is the correct answer, it’s still unclear what’s the Product Manager’s #1 priority. Even though I gave some hints above, let me now make it explicit.

The Product Manager’s #1 priority is to generate results as fast as possible

Let me repeat this one more time: every Product Manager’s #1 priority is to generate results as fast as possible.

As I mentioned in the comments about each of the answers above, answers 1., 2. and 3. are all means to an end, and this end is to generate results as fast as possible. Generate results for the company that owns the product and invests in building the product, and results for the customer, i.e., solve her problems and address her needs. It needs to be as fast as possible because generating results costs money and the more time we spent on generating results, the more money we will spend.

Above I cited some good tools to get results, but we should not forget that these are tools to help us generate results as fast as possible. OKR, roadmap, proof of concept, MVP, MVD, discovery, usability test, prototype, no-code/low-code, site, app, feature, bot, algorithm, opportunity tree, power x interest mapping, RASCI, BCG matrix, technology adoption curve, team structure, Tuckman’s model, Conway’s law, agile, lean, and the list can go on and on, but all of these are tools so we can generate results for the business and for the customer. Even the product, the very thing that goes in the title of the Product Manager’s function, is a tool to generate results.

By the way, generating results as fast as possible is not the Product Manager’s #1 priority only. It is the entire product development team’s #1 priority. Engineers, Product Designers, and Product Managers in product teams as well as in structural teams (data, devops, architecture, etc). The team must have always a common #1 priority to be a team. Otherwise, they will be a group of people working on different priorities that happens to seat together (or have a slack group for remote teams) and happens to have periodic planning and update sessions. And this #1 priority is generating results as fast as possible.

Another example of result generation

I gave some examples of the focus on results in my previous articles. I want to give another example from Lopes, the biggest real estate company in Brazil, where I lead the digital transformation efforts.

In order to sell properties from a new building, Lopes and the builder company create a partnership relationship where the builder company shares info about pricing, unit availability, and leads, and Lopes works on selling units based on its large experience commercializing new builds. In order to perform its attributions in this partnership, we need to know from the builder the prices of each unit that change frequently depending on the sales evolution, the available units, and we need to receive leads from the builder. This information was sent through files to be imported manually into our system. All manual information input tends to be slow and subject to errors, so it is clear to see that this manual integration was sub-optimal. Lopes integration with the builder companies was no different. Since it was a manual operation it was made once or twice per week, which could potentially generate outdated information about pricing and units available in our systems for brokers to use. Also, the older the lead information gets the colder it becomes, and probably the potential client figures out other ways to receive the information she needs and eventually closes a deal with another seller.

So, here’s how we solved this problem using the opportunity tree, always focused on generating results as fast as possible:

  • Outcome: more sales
  • Opportunity: bring info from builders as fast as possible, ideally in real-time
  • Solution 1: integrate with builders’ management system through APIs. The issue here is that all management systems used by builders do not have APIs for integration. So we would have to wait until the management system provider implemented APIs in their system
  • Solution 2: build our own RPAs (Robotic Process Automation) to get the information needed (pricing, available units, and leads) from builders’ management systems without the need for APIs. The issue here is that the team didn’t have enough experience to build these RPAs, so probably it will be a lengthy process.
  • Solution 3: hire an RPA provider to build the integrations for us.

We opted for Solution 3 because it was the one that would bring us results faster. It took us just a few weeks to have the first RPA up and running and bringing results. We are using this solution for more than one year. Still, no APIs were provided by the management system providers, and haven’t had the need to build our own RPAs. The RPA provider works ok with a reasonable cost and we can focus our team to generate results from other opportunities.

Summing up

  • The Product Manager’s #1 priority is to generate results as fast as possible. Generate results for the company that owns the product and invests in building the product, and results for the customer, i.e., solve her problems and address her needs.
  • Everything that we use in our day-to-day product management function, including the very own product that we build, is not the end goal. They are means to an end, to generate results as fast as possible.
  • Generating results as fast as possible is the #1 priority not only of the Product Manager but of the entire product development team, including engineers, product designers, and product managers from both product teams and structural teams. That’s the only way to guarantee that the team is actually a real team, having a common #1 priority.

Mentoring and advice on digital product development

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

Digital Product Management Books

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

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

Cone da Incerteza é outra razão pela qual precisamos entregar com antecedência e com frequência

Já escrevi sobre os 3 motivos pelos quais é importante entregar seu produto cedo e com frequência para seus usuários. Agora eu quero te dar uma 4ª razão, baseada no conceito Cone da Incerteza do mundo do gerenciamento de projetos.

Primeiro, vamos entender o que é o Cone da Incerteza:

No gerenciamento de projetos, o Cone da Incerteza descreve a evolução da quantidade de incerteza durante um projeto. No início de um projeto, comparativamente pouco se sabe sobre o produto ou os resultados do trabalho e, portanto, as estimativas estão sujeitas a grande incerteza. À medida que mais pesquisa e desenvolvimento são feitos, mais informações são aprendidas sobre o projeto e a incerteza tende a diminuir. (Wikipédia)

Em uma imagem, podemos imaginar assim:

Cone da Incerteza

Esta imagem mostra que quanto mais longe estamos do final de um projeto, maior a incerteza. No início de um projeto, a incerteza varia de 0,25x a 4x. Por exemplo, se estamos estimando o tempo de entrega de um projeto específico em 4 meses, no início do projeto essa estimativa varia de 1 mês a 16 meses. Isso é MUITA incerteza!

No entanto, esta é a teoria. Quando analisamos projetos na vida real, a maioria deles tem sua estimativa menor do que realmente acontece. É muito raro ver projetos sendo entregues antes de sua estimativa original. Assim, podemos representar melhor o Cone da Incerteza da seguinte forma:

Cone da Incerteza na vida real

Esta imagem mostra que a probabilidade de uma estimativa ser 2x a 4x vezes o que foi originalmente estimado é maior do que a estimativa estar correta ou ainda maior do que o que realmente acontece. Essa é a razão pela qual muitas pessoas, ao fornecer uma estimativa, tendem a aumentar essa estimativa para aumentar as chances de a estimativa ser mais precisa.

A solução: liberar cedo e frequentemente

A melhor maneira de reduzir a incerteza é liberar cedo e com frequência. Além dos 3 motivos que já expliquei anteriormente:

  • Momento da verdade: você só terá um feedback real quando seu produto estiver na frente de pessoas que o utilizam em seu próprio contexto.
  • Muitas funcionalidades: quanto mais funcionalidades você adicionar ao produto, maiores serão as chances de adicionar recursos desnecessários.
  • Retorno do investimento: quanto mais cedo você liberar alguma parte do seu produto, mais cedo você começará a recuperar seu investimento na construção desse produto.

Para adicionar a esses 3 motivos, vamos verificar o que acontece com o Cone of Uncertainty quando lançamos mais cedo e com frequência:

Abordagem iterativa do Cone da Incerteza

Como podemos ver, quando entregamos cedo e com frequência, estamos diminuindo o alcance da incerteza. No exemplo acima, reduzimos o intervalo de cada entrega entre 0,25x e 4x para 0,8x e 1,25 vezes. Essa abordagem é muito adequada para produtos digitais porque podemos dividir as entregas na menor entrega possível.

Então ai estamos, o quarto motivo para entregar cedo e muitas vezes é o Cone da Incerteza, quanto antes você liberar alguma parte do seu produto, menor será a incerteza.

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.

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.


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.

Guia da Startup agora é Gyaco / Guia da Startup now is Gyaco


Guia da Startup foi um blog que criei em 2012 quando eu estava escrevendo o meu primeiro livro. Eu trouxe todo o conteúdo para esse novo site, onde centralizarei todo o meu conteúdo.

Se você quer ser notificado de novos artigos, basta assinar a newsletter:

Para quem quiser ver esse conteúdo em português, aqui está o link da tradução automática do Google Tradutor. Você também pode acessar os artigos escritos em português.


Guia da Startup was o blog I created back in 2012 when I was writing my first book. I brought all the content to this new site, which is where I will centralize all my writing.

If you want to get notified about new content, just subscribe to my newsletter:

For those who want to access the content in Portuguese, you can access Google Translate automatic translation. Also, there are many articles written in Portuguese.

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? Check out my new bundle Digital Product Management with my 2 books where I share what I learned during my almost 30 years of experience in creating and managing digital products.

No alt text provided for this image

Combatendo o sedentarismo na prática!

Quinta-feira passada eu fui à Drogasil usando uma camiseta do Gympass. Depois que a moça me trouxe o remédio, ela me perguntou se eu trabalhava no Gympass. Ela explicou que baixou o aplicativo porque foi informada que recebeu esse incrível benefício da empresa em que trabalhava, mas não achou os preços tão atraentes.

Eu a ajudei a se inscrever novamente no app, pois ela havia se inscrito como se não fosse uma funcionária da Drogasil, então não estava se beneficiando dos descontos que a Drogasil estava dando a ela como parte do benefício Gympass. Quando ela viu os incríveis preços que a Drogasil e o Gympass criaram para poder dar a ela a a todos os funcionários da Drogasil a uma incrível rede de milhares de academias, ela ficou impressionada e muito feliz! Sua colega, que não conhecia o benefício corporativo Gympass, se interessou, mas nos desafiou a encontrar academias perto de seu bairro, Parelheiros. Não encontramos apenas uma, mas mais de cinco, incluindo uma que ela conhecia. Ela ficou tão animada que se inscreveu imediatamente.

Então veio a gerente. Fiquei preocupado porque talvez eu estivesse distraindo os funcionários e fossemos levar algum “bronca”. Foi quando ela perguntou “por que vocês não me convidaram para essa conversa sobre academias? Quero saber mais!” (:

Foi muito bom praticar meu novo propósito na linha de frente! (:

Se seu objetivo é melhorar sua saúde, mova seu corpo.

Se seu objetivo é se sentir melhor, mova seu corpo.

Se a sua empresa não te oferece Gympass, esse incrível benefício de bem-estar que oferece centenas de opções para você ser mais ativo e movimentar seu corpo, envie este link para seu amigo de RH:



Defeating inactivity in practice

Last Thursday I went to Drogasil using Gympass t-shirt. After I got my medicine, the girl who helped me asked if I worked at Gympass. She explained that she downloaded the app because she was informed that she received this amazing benefit from the company she worked for, but she didn’t find the prices so attractive.

I helped her sign up correctly. She signed up as a if she was not a Drogasil employee, so she was not benefiting from the discounts Drogasil was giving her as part of the Gympass benefit. When she saw the amazing prices Drogasil and Gympass were able to put together so she could access an incredible network of thousands of gyms, she got impressed and very happy! Her colleague, who was not aware of the Gympass corporate benefit, got interest, but dared us to find gyms close to her neighbourhood, Parelheiros. We found no only one, but more than five, including one that she knew. She got so excited that she signed up immediately.

Then came the manager. I got concerned because maybe I was distracting her employees. She asked “why didn’t you invited me to this interesting conversation about easy access to gyms?”.

It was so nice to practice my new purpose in the front line! (:

If your goal is to reduce your risk of death, move your body.

If your goal is to improve your health, move your body.

If your goal is to feel better, move your body.

If your company doesn’t provide you Gympass, this amazing wellness benefit that gives you hundreds of options to be more active and move your body, send this link to your HR friend:



My new mission: to defeat inactivity

I’ve always enjoyed talking to people from different companies to get to know other contexts and the different problems they face. It is an opportunity to share what I’ve been learning over the years about software development management and to learn new ways to see things, as I explained in this article. I’ve been advising and mentoring – pro-bono and paid – for more than 8 years. When I returned to São Paulo in August I intensified my advisory conversations and talked with many interesting companies who are working to solve diverse and important problems.

One of these companies is Gympass, whose purpose is to defeat inactivity, one of the most serious problems of our age. Who haven’t heard the phrase that “sitting is the new smoking”? According to WHO Global Health Risk Report, 3.2 million people die every year due to physical inactivity. It’s the 4th leading risk factor for global mortality.

Gympass has offices and serves customers in 15 countries providing companies with a unique benefit they can offer their employees: access to more 38,000 gyms and studios in 6,280 cities around the world. As Jana taught me, this is a karma free business model, since it’s not replacing anyone and it’s not pushing customers to buy anything they don’t want or that may harm them. It delivers benefits to all users, companies and gyms.

During my advisory conversations with Gympass, we built their product vision:

With this product vision in hands, it is now clear the need to build a world class product development team to execute it. For this reason I accepted their invitation to join them and help them build this team to evolve their product so Gympass can continue in its mission to defeat inactivity.

I’m pretty sure I’ll learn a lot in this new journey!

And we are hiring! 

  • We are Brazilian!
  • We are global!
  • We are karma free!

Come join us: https://www.gympass.com/careers

Do you want to lead one of the world’s best product teams?

Two years ago I decided to move from São Paulo to Joinville to join ContaAzul. I described the decision making process in this article I wrote almost 2 years ago. Due to personal reasons I’ll have to go back to São Paulo and leave ContaAzul. This was one of the toughest decisions of my life because I really love the people I work with. As I described in the article I mentioned earlier I have a deep alignment with the purpose of helping small business owners succeed and with ContaAzul’s culture.

During my two years as CPO (Chief Product Officer) we learned a lot together. We were able to translate ContaAzul’s purpose into our strategy to transform our product into an easy-to-use online platform connecting small businesses with their accountants and all tools they need to organize their business and be successful, which is now our product vision:

I use this product vision as part of presentations (in Portuguese) I give at some software development conferences in Brazil (TDC, Agile Brasil, Agile Trends, QCon among others) to present and explain product management to the software community as well as to improve ContaAzul’s employer branding.

This product vision gave us clarity of how much software we needed to build and how many people we needed to build that many software. That’s one of the main motivators of the $30MM Series D announced earlier this year.

As my last task, I’ll support Vini, CEO and co-founder of ContaAzul in finding the next CPO.

About the position

We are in a moment where we have a good clarity of what we need to deliver. What we need now is someone who support the team through reinforcing a continuous improvement culture through not only failing fast and learning fast, but also guaranteeing that the learning is part of the company knowledge so we can continuously deliver WOW to our customers, partners and stakeholders through our products.

The CPO will be responsible for product management and UX. This person must have the vision to design and implement a unified product & user experience strategy based on the company’s goals and business strategy. The role requires operating within an environment of change while leading a large team in a dynamic product atmosphere. Position reports directly to the Company’s founder and CEO and works and interacts closely with the rest of the functional heads as key contributor to build ContaAzul’s vision. The ideal candidate will have 10+ years functional experience managing product managers and UX designers of a B2B SaaS product. This position is based in Joinville, considered the second best city to live in Brazil. Working languages: Portuguese or English.

If you got interested, please send a message to cpo@contaazul.com with the subject CPO explaining how will you help this amazing team and what will you do in your first 3 months.