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:

What is innovation?

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

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

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

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

Portable air conditioner

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

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

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

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

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

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

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

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

Of course clients know what they want!

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

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

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

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

The first steps to creating a good product are:

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

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

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

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

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

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

Digital Product Management Books

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

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

O que é inovação?

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

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

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

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

Ar-condicionado portátil

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

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

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

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

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

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

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

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

Claro que o cliente sabe o que quer

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

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

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

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

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

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

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

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

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

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

Gestão de produtos digitais

Este artigo faz parte do meu livro Gestão de produtos: Como aumentar as chances de sucesso do seu software, onde falo sobre o que é gestão de produtos digitais, seu ciclo de vida, que ferramentas utilizar para aumentar suas chances de sucesso. Você também pode se interessar pelos meus outros dois livros:

Let’s remove the product from the center?

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

Beyond the product

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

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

Making businesses grow and prosper through technology.

And Conta Azul’s mission is:

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

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

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

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

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

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

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

Help people conquer their place.

When the product is at the center

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

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

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

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

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

Removing the product from the center

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

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

Product is means, not the end

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

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

Summing up

  • Product, app, website, technology, data, algorithms are not the end, they are not the goal, they are vehicles to achieve the goal of delivering value, and results, for customers and for the company.

Digital Product Management Books

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

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

Lifecycle of a digital product

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

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

Innovation

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

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

Growth

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

Maturity

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

End of life

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

Shall we begin?

How does the lifecycle of a software product work?

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

Technology adoption curve

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

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

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

S-curve of technology adoption

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

S-curve and the 3 stages

Check out some examples of the S-curve.

S-curve in real life

S-curve in real life

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

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

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

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

.br domains registered

domains registered in Brazil (.br)

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

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

.br domain registration acceleration after COBID-19 pandemic

The chasm

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

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

Crossing the chasm

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

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

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

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

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

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

Lifecycle of a digital product

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

Digital Product Management Books

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

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

Ciclo de vida de um produto digital

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

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

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

Vamos começar?

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

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

Curva de adoção de tecnologia

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

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

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

Curva S de adoção de tecnologia


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

Curva S e as 3 fases

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

Curva S na vida real

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

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

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

Registro de domínios .br até 2018

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

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

Registro de domínios .br até 2021

O abismo

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

Cruzando o abismo

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

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

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

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

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

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

Ciclo de vida de um produto de software

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

Gestão de produtos digitais

Este artigo faz parte do meu livro “Gestão de produtos: Como aumentar as chances de sucesso do seu software”, onde falo sobre o que é gestão de produtos digitais, seu ciclo de vida, que ferramentas utilizar para aumentar suas chances de sucesso. Você também pode se interessar pelos meus outros dois livros:

2 hacks to foster your digital product culture

I led product development at Gympass for almost 1.5 years. Prior to Gympass I always worked in companies where technology was the main product of the company, Conta Azul and Locaweb are two good examples. In this type of company, digital product culture is part of the organizational culture. However, if you are in a traditional company, or even in a “born-digital traditional company”, building and maintaining a digital product culture can be quite a challenge.

What is digital product culture?

Digital product teams have two main premises when they build products to meet companies strategic objectives while solving a problem or addressing a need for the company’s clients and users:

  • Release early and often: the early I present my product to its users, the better since I’ll be able to get feedback from real users who will be able to use the product in their own context. I explained the motivations behind release early and often in this article.
  • Problem mindset: it’s human nature to solve problems. Whenever we hear about problems we almost immediately jump into solution mode, i.e., searching for solutions. However, if we are able to understand better the problem, the motivation to have the problem solved, the context where the problem occurs, there are good chances that we will be able to find simpler and easier to implement solutions.

When traditional company culture clashes with digital product culture, and how to hack this clash

In traditional companies, and even in some digital companies and traditional born-digital companies, the sales team is always talking to prospective customers, understanding their problems and pains, and figuring out where the product can be a good solution for these problems and pains. For this reason, new releases from the product development team are almost always not only welcomed but also anticipated.

As soon as a new release is available, salespeople want to offer it to all new prospects. That happened and still happens a lot here at Gympass. The problem is that, following the release early and often premise of digital product culture, the first versions of a feature or a product is somewhat clunky, either missing functionalities, or mal-functioning in certain use cases, or even both. We need customer feedback in order to improve the product in future versions. The issue is that if prospective customers decide to become new customers of these early versions, which may not work in certain scenarios and may not offer the best experience, these new customers will probably be quite upset.

Another issue that happens frequently when we release early and often is customer support complaining that the new feature or product is not working properly and they have to provide assistance. At Conta Azul, the product development team constantly received the complaint from customer support that we constantly launch unfinished features and products, i.e, that we constantly launch half-baked features or products. And they were correct, that’s the natural consequence of release early and often way of work.

Hack #1: alpha, beta, and go-live terminology

For this reason, I decided to use what I call hack #1 to foster a digital product culture, alpha, beta, and go-live terminology. I started using this terminology to explain in which stage a product or a feature is. In the alpha stage, the product may not work properly. If it’s in alpha, it should be offered only to customers who understand the issues of using a new product and can cope with these issues without a bigger burden. So this should be a handful of clients, no more than that. At the beta stage, major issues of the product are fixed, but the errors may still occur and the user experience can and will improve. In this phase, it is possible to offer the product or feature to tens of customers. Then, when all known errors are fixed, and the user experience is working properly, then its time to move the product into the go-live stage, where the product can be offered to all prospects and existing clients. This certainly helps sales and customer support teams understand the release cycle of new features and new products.

The other area where traditional company culture clashes with digital product culture is new feature requests. It’s common to see other areas asking the product development team to implement feature A or B because we need this feature to close a deal or to not lose that big customer. A common example these days is “we need to implement Apple Pay and Google Pay as a new payment method”. The issue here is that talking about solutions, we lose the focus on the problem that originated that solution. As explained in this article, if we invest more time learning about the problem, the motivation to have the problem solved, and the context where the problem occurs, good chances are that we will be able to find simpler and easier to implement solutions.

Hack #2: problem mindset

For this reason, I decided to use what I call hack #2 to foster a digital product culture, problem mindset. Whenever a new feature request came to the product development team, they should thank the requester for the input and they must always ask for the underlying problem that generated the request. Each and every member of the product development team needs to have this behavior whenever a feature request is received. By practicing this behavior, soon the requests will come not only with a solution but also with a lot of information about the problem. It’s interesting to see this cultural change, but it requires the discipline of the product development team members to always ask for the problem. And when I mention product development team members I’m referring to everyone, not only the product managers but also product designers and engineers.

Summary

So here they are, 2 hacks to foster your digital product culture:

  • Hack #1: Use the alpha, beta and go-live terminology so everyone – clients, users, market, people in your company, understand in what phase your product is.
  • Hack #2: always ask “what’s the problem?” so you can better understand the problem prior to investing time in investigating solutions.

Digital Product Management Books

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

  • Startup Guide: How startups and established companies can create profitable digital products
  • Product Management: How to increase the chances of success of your digital product
  • Leading Product Development: The art and science of managing product teams

2 hacks para promover e fortalecer sua cultura de produto digital

Liderei o desenvolvimento de produtos no Gympass durante 1,5 anos. Antes dele, eu sempre trabalhei em empresas onde a tecnologia era o principal produto da empresa como a Conta Azul e a Locaweb. Nesse tipo de empresa, a cultura de produtos faz parte da cultura organizacional. No entanto, se você estiver em uma empresa tradicional ou mesmo em uma “empresa tradicional nativa digital”, criar e manter uma cultura digital de produtos pode ser um grande desafio.

O que é Cultura de Produto Digital?

As equipes de produtos digitais têm duas premissas principais quando criam produtos para atender aos objetivos estratégicos da empresa enquanto resolvem um problema ou atendem a uma necessidade dos clientes e usuários:

  • Lançamento antecipado e frequente: quanto mais cedo eu apresentar meu produto a seus usuários, melhor, pois poderei receber feedback de usuários reais que poderão usar o produto em seu próprio contexto. Expliquei as motivações por trás do lançamento antecipado e frequente neste artigo: https://www.linkedin.com/pulse/why-hurry-launch-mvp-joaquim-torres-joca-/
  • Foco no problema: é da natureza humana resolver problemas. Sempre que ouvimos falar de problemas, entramos quase imediatamente no modo de solução, ou seja, começamos a buscar soluções para o problema. No entanto, se conseguirmos entender melhor o problema, a motivação para resolvê-lo, o contexto em que o problema ocorre, há boas chances de conseguirmos encontrar soluções mais simples e fáceis de implementar.

Quando a cultura tradicional da empresa entra em conflito com a cultura digital de produtos e como combater esse conflito

Nas empresas tradicionais, e mesmo em algumas empresas digitais e empresas tradicionais nativas digitais, a equipe de vendas está sempre conversando com clientes em potencial, entendendo seus problemas e dores e descobrindo onde o produto pode ser uma boa solução para esses problemas. Por esse motivo, os novos lançamentos da equipe de desenvolvimento de produtos quase sempre são bem-vindos, mas também são bastante esperados.

Assim que um novo lançamento estiver disponível, os vendedores desejam oferecer a todos os novos clientes em potencial. Isso aconteceu e ainda acontece muito aqui no Gympass. O problema é que, em função da premissa de “lançamento antecipado e frequente” que expliquei acima, as primeiras versões de uma funcionalidade ou de um produto são normalmente um tanto desajeitadas, faltando funcionalidades e com mau funcionamento em determinados casos de uso. Precisamos do feedback do cliente para melhorar o produto em versões futuras. A questão é que, se os clientes em potencial decidirem se tornar novos clientes dessas primeiras versões, eles provavelmente ficarão bastante chateados, pois o produto ou funcionalidade pode não funcionar em determinados cenários e pode não oferecer a melhor experiência.

Outro problema que costuma ocorrer quando lançamos cedo e com frequência é com o time de suporte ao cliente que reclama, e com razão, de que o novo recurso ou produto não está funcionando corretamente e eles precisam fornecer assistência. Na Conta Azul, a equipe de desenvolvimento de produtos recebia constantemente a reclamação do suporte ao cliente de que lançamos constantemente recursos e produtos inacabados, ou seja, lançamos constantemente recursos ou produtos incompletos. E eles estavam corretos, essa é a consequência natural da premissa de liberação antecipada e frequente.

Hack #1: Terminologia Alfa, Beta e Go-live

Por esse motivo, decidi usar o que chamo de hack #1 para promover e fortalecer a cultura de produtos digitais no Gympass. Passamos a usar a terminologia alfa, beta e go-live para explicar em que estágio um produto ou funcionalidade está. No estágio alfa, o produto pode não funcionar corretamente. Se estiver em alfa, deve ser oferecido apenas aos clientes que entendem os problemas do uso de um novo produto e podem lidar com esses problemas sem maiores dificuldades. Portanto, a quantidade de clientes na fase alfa será pequena, no máximo uns 5, não mais do que isso. No estágio beta, os principais problemas do produto são corrigidos, mas os erros ainda podem ocorrer e a experiência do usuário pode e vai melhorar. Nesta fase, é possível oferecer o produto ou funcionalidade a dezenas de clientes. Depois, quando todos os erros conhecidos forem corrigidos e a experiência do usuário estiver funcionando corretamente, é hora de mover o produto para o estágio de go-live, onde o produto pode ser oferecido a todos os clientes existentes e em potencial. Isso certamente ajuda as equipes de vendas e de suporte ao cliente a entenderem o ciclo de lançamento de novos recursos e novos produtos e em que estágio está o produto ou a funcionalidade.

A outra área em que a cultura tradicional da empresa entra em conflito com a cultura digital de produtos é a solicitação de novas funcionalidades. É comum ver outras áreas pedindo à equipe de desenvolvimento de produtos que implemente o recurso A ou B porque precisamos dele para fechar um negócio ou para não perder esse grande cliente. Um exemplo comum que tenho ouvido atualmente é “precisamos implementar o Apple Pay e o Google Pay como um novo método de pagamento”. A questão aqui é que, falando em soluções, perdemos o foco no problema que originou essa solução. Se investirmos mais tempo aprendendo sobre o problema, a motivação para resolvê-lo e o contexto em que o problema ocorre, há boas chances de que possamos encontrar soluções mais simples e fáceis de implementar.

Hack #2: Qual é o Problema?

Por esse motivo, decidi usar o que chamo de hack #2 para promover uma cultura de produto digital, perguntar sempre “qual é o problema?”. Sempre que uma nova solicitação de funcionalidade chega à equipe de desenvolvimento do produto, devemos agradecer ao solicitante pelo pedido e em seguida devemos perguntar sobre o problema que gerou a solicitação. Cada membro da equipe de desenvolvimento de produtos precisa ter esse comportamento sempre que uma solicitação de nova funcionalidade for recebida.

Ao praticar esse comportamento, em breve as solicitações virão não apenas com uma solução, mas também com muitas informações sobre o problema. É interessante ver essa mudança cultural, mas requer a disciplina dos membros da equipe de desenvolvimento de produtos para sempre perguntar sobre o problema. E quando menciono os membros da equipe de desenvolvimento de produtos, estou me referindo a todos, não apenas aos gestores de produto, mas também aos designers e às engenheiras e engenheiros de produto.

Resumo

Então, aqui estão eles, 2 hacks para promover e fortalecer sua cultura de produtos digitais:

  • Hack #1: use a terminologia alfa, beta e go-live para que todos (clientes, usuários, mercado e pessoas da sua empresa) possam entender em que fase está seu produto.
  • Hack #2: pergunte sempre “qual é o problema?” para entender bem o problema antes de investir energia em buscar soluções.

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:

Organizational culture

Organizational culture is a very important theme for product managers and has a tremendous impact on the success of a digital product. Therefore, let’s dig into it. In a way, this subject complements the previous chapter on leadership tips for product managers.

Organizational culture is a feature of every group of people. Even within companies, there are sub-cultures. In other words, each area or team within a company can have its own culture. For instance, the culture of a commercial team has always some differences compared to the culture of the software engineering team.

There is not a right or wrong culture. Different companies have different cultures, and they can be successful in spite of these differences. The following cartoon illustrates the cultural difference between Amazon, Apple, Facebook, Google, Microsoft, and Oracle. Even with all the cultural differences, these are all successful companies.

Culture differences by Manu Cornet

But what is organizational culture? Edgar Schein, professor at MIT Sloan School of Management, was one of the first to talk about organizational culture in the 70s. According to him, each company had its own personality and its own approach to act and react to situations; and this approach has been passed on from employee to employee since the company’s founders. Schein’s definition for organizational culture is:

Culture is a set of premises that have been learned and shared by a group of people while they were solving problems on external adaptation and internal integration. This set of premises works well enough to be considered valid and, consequently, to be taught to the new members of the group as the correct way of perceiving, thinking, and feeling regarding those problems.

SCHEIN, Edgar. Organizational Culture and Leadership. Jossey-Bass, 2010.

Culture comes from the company’s founders. They have their own culture and it’s only natural that they spread this culture in the organization they are creating. That’s why it is very common to think it emerges in an organization.

The founder brings the culture and when hiring new people, always looks for those with similar cultures. This ends up creating a new common culture, very close to that one brought by the company’s founder. This concept of emerging culture gives the impression that we cannot alter it deliberately and that it would develop organically.

Schein warns that this is a mistake. Cultures can and must be planned. For that reason, I’ll share with you three essential organizational culture values that I’ve seen in some companies when creating successful software products.

Don’t waste time looking for culprits

When mistakes take place, some people naturally tend to react by looking for culprits, especially in group activities. As if having anyone to blame for that mistake could be, in some way, less harmful. That is a great waste of time and energy. Let me explain why.

Blame game, by Ron Tandberg

A mistake took place. Mistakes happen. That’s a fact of life. No matter what you are doing — building software, publishing a code in production, operating a patient, cooking dinner, building a house, playing guitar, playing soccer, etc. –, there are good chances that mistakes are going to be made.

When you spend your time trying to figure out who was responsible for that mistake, you will postpone the most important tasks in relation to it:

  • Understand what happened;
  • Figure out how to correct;
  • Find ways to avoid from happening again.

When you spend your time trying to figure out who was responsible for that mistake, people might naturally try to hide the mistake, fearing the consequences. Will I get fired? Will I be excluded from the group? Will I be punished? Will people make fun of me?

When people try to hide who was responsible, you will end up postponing the most important tasks in order to fix the mistake. It’s going to be more difficult to understand what happened. People will not tell the whole truth about the mistake and about the circumstances in which it happened.

If, in the process of understanding what happened, you find out that someone was responsible for the mistake, deal with this person in private. It is most likely that the mistake was caused unintentionally. That’s why you need to help this person to improve, so this same kind of mistake does not happen again.

On the other hand, you are responsible for creating an environment in which it is safe to talk about mistakes so they can be detected as soon as possible. However, if you find out that the mistake took place with the intention to harm the company, the product, or someone, then you should be resolute on reprehending it, saying that this type of behavior is unacceptable and, if it happens again, you’ll invite the person to leave the group.

War

It is common to hear comparisons between the business world and war situations, combat or fighting. By the way, the word strategy itself, so common in business nowadays, comes from the military vocabulary. It derives from the Greek word strategos, a union between stratos (army) and agos (leader). In other words, strategos originally means the army leader, the general, the one who defines how the troop must act facing the situation.

One of the books that constantly appears on the list of most recommended administration books is “The Art of War”, a military treatise written on the 4th century BC by the Chinese general Sun Tzu.

Everyone who met me knows that I’m a peaceful person. I hate fighting. I hate watching fights, even on TV. By the way, if I accidentally get into one, I’m even willing to pay to get out of it. That’s why every time I see these kinds of comparisons between the business world and wars, combats, fighting or competition, I feel deeply bothered.

I believe the images speak for themselves.

Using war (combat or fighting) as an analogy for the business world does not make any sense. The goal is to defeat the opponent. It is awkward to picture a company which goal is to defeat something or someone.

Some people have said to me that, in a war, the battle itself is not the goal but a means to reach a goal. Ok, this makes sense but there are several means to achieve a certain goal. War is not the only one. So, why insisting on using war as an analogy for businesses?

Business is the activity of making one’s living or making money by producing or buying and selling products (such as goods and services).

vWikipedia definition of Business: https://en.wikipedia.org/wiki/Business

This definition makes it clear that the business exists to produce and / or serve. How can something that aims to produce and / or serve by analogy have something that aims at destruction? The right way to look at a company and its goals is to think about building a win-win relationship, that is, where the customer, the employees, the owners of the company, and the society in which the company operates are winning. Whenever we direct energy to defeat the “opponent” (customer, competitor, employee, etc.), we are wasting energy that could be used in something constructive.

Air, food and profit

Often we see shareholders, investors, and employees of a company totally focused on its financial results. When there’s a period of crisis, this focus can be over 100%… :-/

Once I heard a sentence that became popular with Dick Costolo, Twitter’s former CEO, that compared revenue to oxygen:

Revenue is like oxygen, it is vital for the health and the success of a company, but is not the purpose in life. Do you wake up in the morning and the first thing that comes to your mind is “how can I get more air?”

I’m very fond of this comparison. Every company must have a purpose, and this purpose should not be to defeat the enemies (as explained previously) nor getting the biggest amount of money as possible.

The financial outcome must always be used as one of the metrics that indicate that the company is being successful, that it is meeting its purpose. However, even as a metric, it should not be seen isolated, for there is the good and the bad revenue.

The bad revenue is obtained at the expense of the prejudice of the relationship with the client. For example, imagine a company that provides a service over a monthly payment; when a client wants to cancel this service, the company makes it difficult in order to keep that revenue source for a few more months. That is bad revenue. The international roaming charges are also a good example of it, such as car rentals that charge for gas when you return the car without a full tank, using a more expensive price for gas than the one you find in the market.

If a company sells something at a higher price, taking advantage of the fact that you need that item, such as the cost of a bottle of water in a hotel, that is also bad revenue.

In other words, although the comparison between revenue and profit with oxygen is good, it is also incomplete, because it doesn’t capture the effect of bad revenue. You rarely think about oxygen, unless you are with shortness of breath. I don’t think that the revenue should only be remembered when there’s a shortness of it. Revenue is what keeps the company alive, able to fulfill its purpose. If it’s good revenue, the company will continue to meet its purpose for many years. If it’s bad revenue, it will have difficulties in the long run.

For that reason, I prefer to compare revenue and profit to food. In the same way, healthy people don’t think about oxygen all day long, healthy people don’t think about food all day long. However, unlike oxygen, when we talk about food, there’s good, healthy food that is good for your body; and there’s bad food, harmful for your body, with the possibility of getting you sick. It is very important that people know what is good and bad food, and that everyone thinks about how to get the good one and avoid the bad one.

Taking the sentence above, improving it, and changing oxygen for food, we have:

Revenue is like food, it is necessary, it is vital for the health and the success of a company, but is not the purpose in life. Do you wake up in the morning and the first thing that comes to your mind is “how can I get more food?”. However, both a company and a person must be always alert to the quality of the food they are ingesting, in order to assure that is not going to cause any harm.

Concluding

We saw in this chapter how important the organizational culture is for the success of your software product, and that culture is not a theme to go with the flow, it can and must be planned. Here I’ll share three cultural values that, in my point of view, are essential for creating successful software:

  • Do not waste time looking for culprits;
  • Do not compare making business with making war, combat or fighting;
  • Think about revenue as good food, that is, something necessary for living but not the reason for living.

Digital Product Management Books

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

  • Startup Guide: How startups and established companies can create profitable digital products
  • Product Management: How to increase the chances of success of your digital product
  • Leading Product Development: The art and science of managing product teams