Let’s remove the product from the center?

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

Beyond the product

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

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

Making businesses grow and prosper through technology.

And Conta Azul’s mission is:

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

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

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

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

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

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

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

Help people conquer their place.

When the product is at the center

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

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

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

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

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

Removing the product from the center

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

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

Product is means, not the end

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

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

Summing up

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

Digital Product Management Books

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

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

Vamos tirar o produto do centro?

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

Além do produto

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

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

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

E a da Conta Azul:

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

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

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

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

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

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

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

Ajudar as pessoas a conquistarem o seu lugar.

Quando o produto está no centro

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

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

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

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

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

Tirando o produto do centro

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

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

Produto é meio, não é fim

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

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


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

Gestão de produtos digitais

EVocê trabalha com produtos digitais? Quer saber mais sobre como gerenciar um produto digital para aumentar suas chances de sucesso, resolver os problemas do usuário e atingir os objetivos da empresa? Confira meu pacote de gerenciamento de produto digital com meus 3 livros, onde compartilho o que aprendi durante meus mais de 30 anos de experiência na criação e gerenciamento de produtos digitais. Se preferir, pode comprar os livros individualmente:

Lifecycle of a digital product

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

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


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

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


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


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

End of life

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

Shall we begin?

How does the lifecycle of a software product work?

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

Technology adoption curve

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

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

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

S-curve of technology adoption

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

S-curve and the 3 stages

Check out some examples of the S-curve.

S-curve in real life

S-curve in real life

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

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

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

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

.br domains registered

domains registered in Brazil (.br)

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

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

.br domain registration acceleration after COBID-19 pandemic

The chasm

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

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

Crossing the chasm

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

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

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

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

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

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

Lifecycle of a digital product

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

Digital Product Management Books

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

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

Ciclo de vida de um produto digital

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

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

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

Vamos começar?

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

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

Curva de adoção de tecnologia

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

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

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

Curva S de adoção de tecnologia

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

Curva S e as 3 fases

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

Curva S na vida real

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

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

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

Registro de domínios .br até 2018

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

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

Registro de domínios .br até 2021

O abismo

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

Cruzando o abismo

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

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

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

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

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

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

Ciclo de vida de um produto de software

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

Gestão de produtos digitais

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

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.


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.


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.


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.


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

Cultura Organizacional

Cultura organizacional é um tema muito importante para gestores de produtos; por isso, quero abordar um pouco dele aqui. De uma certa forma, esse assunto complementa o capítulo Dicas de liderança para gestores de produtos.

Cultura organizacional é uma característica de toda empresa. Até mesmo dentro de uma empresa existem subculturas, ou seja, cada área ou time dentro de uma empresa pode ter uma cultura própria. Por exemplo, a cultura de um time comercial tem sempre algumas diferenças da cultura do time de engenharia de software.

Não existe cultura certa ou cultura errada. Empresas diferentes têm culturas diferentes e, mesmo assim, podem ter sucesso apesar dessas diferenças. A charge a seguir ilustra a diferença de cultura entre Amazon, Apple, Facebook, Google, Microsoft e Oracle. Mesmo com essas diferenças culturais, todas são empresas de sucesso.

Por Manu Cornet. Fonte: http://www.bonkersworld.net/organizational-charts/

Mas o que é cultura organizacional? Edgar Schein, professor da escola de administração de empresas do MIT, foi uma das primeiras pessoas a falar sobre cultura organizacional nos anos 1970. Segundo ele, cada empresa tinha sua própria personalidade, e sua própria forma de agir e reagir às situações; forma esta que é passada de funcionário para funcionário desde os fundadores da empresa. A definição de Schein para cultura organizacional é:


Cultura é um conjunto de premissas que foram aprendidas e compartilhadas por um grupo de pessoas enquanto resolviam problemas de adaptação externa e de integração interna. Esse conjunto de premissas funciona bem o suficiente para ser considerado válido e, consequentemente, ser ensinado aos novos membros do grupo como a forma correta de perceber, pensar e sentir em relação a esses problemas.

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

A cultura vem dos fundadores da empresa. Os fundadores têm sua própria cultura e é natural que imprimam essa cultura na organização que estão criando. Em função disso, é muito comum se pensar que ela é algo que emerge em uma organização.

O fundador traz sua cultura e, ao contratar novas pessoas, busca sempre pessoas com cultura similar à sua. Isso acaba criando uma cultura comum muito próxima daquela trazida pelo fundador da empresa. Esse conceito de cultura emergente dá a impressão de que não se pode alterá-la deliberadamente, e que ela se desenvolverá de forma orgânica.

Schein alerta que isso é um engano. Culturas podem e devem ser planejadas. Por esse motivo, vou compartilhar três valores de cultura organizacional que tenho visto em algumas empresas e que, a meu ver, são essenciais na criação de produtos de software de sucesso.


Quando erros acontecem, algumas pessoas têm uma tendência natural de ter como sua primeira reação procurar quem é o culpado, especialmente em atividades de grupo. Como se ter alguém para culpar fizesse o erro, de alguma forma, menos prejudicial. Isso é um grande desperdício de tempo e energia. Deixe-me explicar o porquê.

Blame game, por Ron Tandberg

Ocorreu um erro. Erros acontecem. Este é um fato da vida. Não importa o que você está fazendo – desenvolvendo software, publicando código em produção, operando um paciente, cozinhando o jantar, construindo uma casa, tocando guitarra, jogando futebol etc. –, há boas chances de que erros venham a acontecer.

Quando você gasta tempo tentando descobrir quem foi o responsável pelo erro, você vai adiar suas tarefas mais importantes em relação a ele:

  • Compreender o que aconteceu;
  • Descobrir como corrigir;
  • Encontrar formas de evitar que isso aconteça novamente.

Quando você gasta tempo tentando descobrir quem foi o responsável pelo erro, as pessoas podem, naturalmente, tentar esconder o erro por temer as consequências. Será que vou ser demitido? Será que vou ser excluído do grupo? Será que vou ser punido? Será que as pessoas vão zombar de mim?

Quando as pessoas tentam esconder quem foi o responsável, você vai acabar adiando as tarefas mais importantes que listei para tratar o erro, pois será mais difícil entender o que aconteceu. As pessoas não vão dizer toda a verdade sobre o erro e as circunstâncias em que ele aconteceu.

Se no processo de entender o que aconteceu, você descobrir que alguém foi responsável pelo erro, lide com ele em particular. O mais provável é que ele o tenha causado sem intenção de fazer mal. Por isso você precisa ajudá-lo a melhorar para que ele não cometa mais esse tipo de erro.

Por outro lado, você tem a responsabilidade de criar um ambiente em que é seguro falar sobre erros, para que estes sejam detectados o mais rápido possível. Contudo, se você descobrir que o erro foi feito com intenção de prejudicar a companhia, algum time ou alguma pessoa, nesse caso você deve ser direto na repreensão, dizendo que o comportamento é inaceitável e, na reincidência, convidar essa pessoa a sair do grupo.


É comum ouvir comparações entre o mundo dos negócios e situações de guerra, de combate e de luta. Aliás, a própria palavra “estratégia”, tão comum nas empresas de hoje em dia, vem do mundo militar. Vem da palavra grega strategos, junção das palavras stratos (exército) e agos (líder). Strategos significa originalmente o líder do exército, o general, aquele que define como a tropa deverá agir frente às situações.

Um dos livros que constantemente aparece na lista de mais recomendados para administração é A Arte da Guerra, um tratado militar escrito durante o século IV a.C. por Sun Tzu, general chinês.

Quem me conhece sabe que sou uma pessoa pacífica. Odeio brigas. Aliás, se acidentalmente entro em uma, estou disposto até a pagar para sair. Por isso, sempre que vejo essas comparações do mundo de negócios com guerra, combate, luta ou competição, eu me sinto profundamente incomodado.

Acho que essas imagens falam por si só… Usar guerra (combate ou luta) como analogia para o mundo dos negócios não faz o mínimo sentido. Nelas, o objetivo é derrotar o adversário. É estranho imaginar uma empresa cujo objetivo principal seja derrotar algo ou alguém.

Algumas pessoas já comentaram comigo que, em uma guerra, a guerra em si não é o objetivo, mas sim um meio para se atingir um objetivo. Ok, faz sentido, mas existem vários meios para se atingir um determinado objetivo. A guerra não é o único meio. Por que então a insistência em usar a guerra como analogia para as empresas?

Buscando na Wikipédia, encontramos a seguinte definição para empresa:


Empresa é uma instituição jurídica despersonalizada, caracterizada pela atividade econômica organizada, ou unitariamente estruturada, destinada à produção ou circulação de bens ou de serviços para o mercado ou à intermediação deles no circuito econômico.

Fonte: http://pt.wikipedia.org/wiki/Empresa.

Esta definição deixa claro que a empresa existe para produzir e/ou servir. Como pode algo que tem por objetivo produzir e/ou servir, ter por analogia algo que tem como objetivo a destruição? A maneira correta de olhar uma empresa e seus objetivos é pensando em construção, em relação ganha-ganha, onde o cliente, os funcionários, os donos da empresa e a sociedade na qual a empresa está inserida saem ganhando. Sempre que direcionamos energia para derrotar o “oponente” (cliente, competidor, funcionário etc.), estaremos desperdiçando energia que poderia ser usada em algo construtivo.


Não raro vemos acionistas, investidores e funcionários de uma empresa 100% focados nos resultados financeiros. Quando em período de crise, esse foco consegue ir além dos 100%… :-/

Certa vez ouvi uma frase, popularizada por Dick Costolo, CEO do Twitter, que comparava receita a oxigênio:

Receita é como oxigênio, é necessário, é vital para a saúde e para o sucesso de uma empresa, mas não é propósito da vida. Você não acorda de manhã e a primeira coisa que pensa é “como eu posso conseguir mais ar?”.

Gosto bastante dessa comparação. Toda empresa deve ter um propósito, e esse propósito não pode ser derrotar os inimigos (como explicado anteriormente), nem conseguir a maior quantidade de dinheiro possível.

O resultado financeiro deve sempre ser usado como uma das métricas que indicam que a empresa está tendo sucesso, que está cumprindo com o seu propósito. Contudo, mesmo como métrica, ela não deve ser olhada de forma isolada, pois existe a boa e a má receita.

A má receita é toda receita obtida às custas do detrimento do relacionamento com o cliente. Por exemplo, imagine uma empresa que presta um serviço com pagamento mensal; quando um cliente quer cancelar, ela dificulta sua saída para manter aquela fonte de receita por mais alguns meses. Isso é uma má receita. Quando uma companhia aérea cobra uma taxa para adiantar o horário de um voo, mesmo sabendo que o avião tem espaço de sobra; isso é má receita. As taxas de roaming internacionais exorbitantes também são um bom exemplo disso, como locadoras de veículos que cobram a taxa de gasolina quando você devolve o carro sem estar com o tanque cheio, com preço de gasolina bem mais caro do que o do mercado.

Se uma empresa vende algo com o preço acima do adequado, aproveitando-se do fato de que você precisa daquele item como, por exemplo, o custo absurdo da garrafa de água em um hotel, isso também é uma má receita.

Apesar de a comparação de receita e lucro com oxigênio ser boa, ela é incompleta, pois não capta o efeito da má receita. Raramente você pensa no oxigênio, a não ser que esteja com falta de ar. Eu não acho que a receita só deva ser lembrada quando está faltando. Receita é o que mantém a empresa viva, capaz de executar seu propósito. Se for uma boa receita, a empresa vai continuar cumprindo seu propósito por muitos anos. Já se for uma má, ela terá dificuldades no médio prazo.

Por esse motivo, prefiro comparar receita e lucro com comida. Da mesma forma que as pessoas saudáveis não pensam em oxigênio o dia inteiro, pessoas saudáveis também não pensam em comida o dia todo. Contudo, diferentemente do oxigênio, quando falamos de comida, existe a comida boa, saudável, que faz bem para o seu corpo; e existe a comida má, que vai prejudicar seu organismo, com possibilidade de fazer você ficar doente. É muito importante que a pessoa saiba o que é boa comida e má comida, e que pense sobre como obter a boa e como evitar a má.

Pegando a frase de cima e aprimorando-a, trocando o oxigênio pela comida, teremos:

Receita é como comida, é necessária, é vital para a saúde e para o sucesso de uma empresa, mas não é propósito da vida. Você não acorda de manhã e a primeira coisa que pensa é “como eu posso conseguir mais comida?”. Contudo, tanto uma empresa quanto uma pessoa devem estar sempre atentas à qualidade da comida que está ingerindo, para ter certeza de que ela não vai causar nenhum mal à saúde.


Vimos neste capítulo o quão importante é a cultura organizacional para o sucesso do seu produto de software, e que cultura não é um tema para deixar acontecer, ele pode e deve ser planejado. Compartilho três valores culturais que, a meu ver, são essenciais para a criação de um software de sucesso:

  • Não desperdiçar tempo buscando culpados;
  • Não comparar fazer negócios com guerra, combate ou luta;
  • Pensar em receita como comida, ou seja, algo necessário para viver, mas não é a razão do viver.

Gestão de produtos digitais

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

Leading product managers

Just as not every good developer can become a good developer manager, so do product managers. The same way as the skills a person has to manage software developers are different from the skills a developer needs to have to be a good software developer, the skills a manager of product managers needs to have to manage product managers are different from the skills that a product manager needs to have to manage his product.

So what does a manager of product managers do?

A manager of product managers has basically two concerns, one tactical and one strategic:

  • Helping product managers perform better. This is the tactical concern of the manager of product managers. He should be able to help the product manager develop the key characteristics of a good product manager: empathy, communication, time management, knowledge of new technologies, business skills, keen curiosity, and knowledge of the product theme. All these characteristics are fundamental to the success of the product manager, and the manager is not always able to understand what needs to be improved and how to improve. Then comes the manager of product managers, who should help the product manager see which features have room for improvement and how to improve each one. Often there is more than one feature that needs to be improved, and here the manager of product managers can once again help to realize priorities, which feature should be worked on first.
  • Helping product managers create product vision and strategy. This is a topic that will be covered later in the chapter What is it and how to create product vision and strategy?, and is the strategic concern of the manager of product managers. She must be able to help product managers create the vision and strategy of the company’s products. Here it is important to distinguish between the two product portfolio strategy options that a company can choose, focus or diversification, which we will see in the chapter Focus or Diversification?. In a company that has opted for focus, it is up to the manager of product managers to coordinate the process of creating the company’s product vision and strategy. She must, in conjunction with her product managers, UX designers, engineers, and product marketing managers, create the company’s product vision and design the strategy to achieve that vision. In a company that has opted for the product portfolio diversification strategy, the manager of product managers responsibility is to help each manager coordinate the process of creating the vision and strategy design for their specific product. In addition, in a company that has opted for diversification, it is up to the manager of product managers to manage the product portfolio. That is, she needs to ensure that the product portfolio is aligned with the company’s strategic objectives and that each product has the appropriate product development and marketing investment.

To be a good manager of product managers, it is important that the person has already been a product manager, that is, she has already put his hands on it and took care of the tactical and strategic issues of a product. This will help her when managing the work of other product managers.

However, care must be taken not to do the work in place of the product manager rather than to help him develop and do his work. Note that in both of the concerns I described earlier, I used “help product managers”. Having already been a product manager, it is tempting for the manager of product managers, at a time when a product manager under his leadership is struggling to do his job, to jump in on the job herself. The job of the manager of product managers is not to do the product manager’s job, but to teach and help him do his job.

If you have no experience as a product manager but find yourself coordinating the work of product managers (as may be the case with a CTO or an engineering team manager), the previous recommendations are worthwhile. That is, helping product managers perform better and help them create the vision and strategy for their products.

You may have some difficulty with not being a product manager yourself, but because you have been working with software product development, you have probably worked with product managers and have a good idea of what to expect of this role.

Digital Product Leadership

If you are interested in this topic, check out my newest book, Digital Product Leadership: The science and art of managing product teams, where I talk about concepts, principles, and tools that can be useful for someone acting as head of product, for anyone who wants to be, for whoever is led by a head of product or who has a person in that role in the company. You may also be interested in my other two books:

Gerindo gestores de produto

Da mesma forma que nem todo bom desenvolvedor pode virar um bom gestor de desenvolvedores, o mesmo acontece com gestores de produto. Assim como as habilidades que uma pessoa tem que ter para gerir desenvolvedores de software é diferente das habilidades que um desenvolvedor precisa ter para ser um bom desenvolvedor de software, as habilidades que um gestor de gestores de produto precisa ter para gerir gestores de produtos é diferente das habilidades que um gestor de produtos produto precisa ter para gerir seu produto.


Então o que faz um gestor de gestores de produtos?

Um gestor de gestores de produtos tem basicamente duas preocupações, uma tática e outra estratégica:

  • Ajudar os gestores de produto a performarem melhor. Essa é a preocupação tática do gestor de gestores de produto. Ele deve ser capaz de ajudar o gestor de produto a desenvolver as principais características de um bom gestor de produto, empatia, comunicação, gestão do tempo, conhecimento de novas tecnologias, business skills, curiosidade aguçada e conhecimento sobre o tema do produto. Todas essas características são fundamentais para o sucesso do gestor de produtos e nem sempre o gestor de produtos consegue perceber o que precisa ser melhorado ou, se percebe, não sabe bem como melhorar. Aí entra o gestor de gestores de produto, que deve ajudar o gestor de produtos a ver quais características tem espaço para melhoria e como melhorar cada uma delas. Muitas vezes há mais de uma característica que precisa ser melhorada e aqui o gestor de gestores de produto pode mais uma vez ajudar a perceber prioridades, ou seja, qual característica deve ser trabalhada primeiro.
  • Ajudar os gestores de produto a criar a visão e a estratégia dos produtos. Essa é a preocupação estratégica do gestor de gestores de produto. Ele deve ser capaz de ajudar os gestores de produto a criar a visão e a estratégia dos produtos da empresa. Aqui é importante fazer uma distinção entre as duas opções de estratégia de portfólio de produtos que uma empresa pode escolher, foco ou diversificação. Em uma empresa que optou pelo foco, cabe ao gestor de gestores de produto coordenar o processo de criação de visão e estratégia do produto da empresa. Ele deve, em conjunto com seus gestores de produto, designers de UX, pessoal de engenharia e gestores de mkt de produto, criar a visão do produto da empresa e desenhar a estratégia para chegar nessa visão. Já em uma empresa que optou pela estratégia de diversificação de portfólio de produto, a responsabilidade do gestor de gestores de produto é ajudar cada gestor de produto a coordenar o processo de criação da visão e do desenho da estratégia de seu produto específico. Além disso em uma empresa que optou pela diversificação, cabe ao gestor de gestores de produtos fazer a gestão do portfólio de produtos, ou seja, garantir que o portfólio de produtos está alinhado com os objetivos estratégicos da empresa e garantir que cada produto tenha o devido investimento de desenvolvimento e de mkt de produtos.

Para ser um bom gestor de gestores de produto é importante que a pessoa já tenha sido gestora de produtos, ou seja, que ela já tenha colocado a “mão na massa” e tenha cuidado diretamente das questões táticas e estratégicas de um produto. Isso irá ajudá-la quando estiver gerindo o trabalho de outros gestores de produto. Contudo, é preciso tomar muito cuidado para não fazer o trabalho no lugar do gestor de produtos ao invés de ajudá-lo a se desenvolver e a fazer seu trabalho. Note que em ambas as preocupações que descrevi acima eu usei “ajudar os gestores de produto”. Por já ter sido um gestor de produtos, é tentador para o gestor de gestores de produtos, no momento em que algum gestor de produto sob sua gestão estiver com dificuldades, fazer o seu trabalho. Mas a função do gestor de gestores de produto não é fazer o trabalho de gestor de produto, mas sim ensinar e ajudar os gestores de produto a fazerem seu trabalho.

Caso vc não tenha experiência como gestor de produtos, mas se veja na situação de coordenar o trabalho de gestores de produtos, como pode ser o caso de um CTO ou um gestor de time de engenharia, valem as recomendações acima, ou seja, ajudar os gestores de produtos a performarem melhor e a criar a visã e a estratégia de seus produtos.

Liderança de produtos digitais

Se você se interessou por esse assunto, irá gostar do meu mais novo livro, Liderança de produtos digitais: A ciência e a arte da gestão de times de produto, onde falo sobre conceitos, princípios e ferramentas que podem ser úteis para quem é head de produto, para quem quer ser, para quem é liderado por ou para quem tem uma pessoa nesse papel na empresa. Você também pode se interessar pelos meus outros dois livros: