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

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

NÃO DESPERDIÇAR TEMPO BUSCANDO CULPADOS

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.

GUERRA

É 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

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.

AR, COMIDA E LUCRO

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.

Concluindo

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.

gestor_de_gestores

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:

2 leadership tips for product managers

Product managers have the hard task of leading the product’s evolution without being anyone’s “boss”. In other words, they must convince everyone who works with their product that the path they defined for the product is the most adequate.

In several texts about product management we find the definition that product managers are the product’s CEO. I’m not very fond of this definition because CEOs have at their disposal the direct leadership of everyone in the company and can, in spite that it is not the most adequate way, use hierarchy to achieve their goals.

On the other hand, product managers work within a matrix relation, i.e., they are not hierarchically in a position of being the manager of anyone involved in the product creation. By the way, this matrix relation is an excellent leadership exercise to showing an extremely important quality for a product manager: leading without being anyone’s manager.

Even though they work in completely horizontal relationships, with no hierarchy, they must hold some leadership in order to convince people to develop the product in the direction they visualized.

So, here are two leadership tips that product managers, or any leader, should remember in order to lead efficiently.

Set the context

This first tip has a more strategic aspect. Product managers are required to:

  • Understand, communicate and explain the context in which they are working.
  • Help the team to understand what’s the role of the product in the company strategy and in the market.
  • Know how customers use the product and what they expect from it.
  • Understand how a certain feature is inserted in the product strategy.

This tip may be simple and obvious, but is not uncommon to find people who work not knowing exactly why they are doing their job. Helping people to see the impact of their work makes them understand why it is necessary.

Try to bring software engineers in your next client meeting. Better yet, take them to a usability test so they can see their users using the software they created. This will help them to understand why the software they’ve developed exists, what problem it solves and to whom it solves this problem.

Setting the context helps to engage people who are involved with the product. They will understand the product’s relevance both (1) to the company who owns the product and (2) to the product’s users. This engagement is important not only to the product’s core team (engineers, product managers and UX designers) but also to everyone involved with the product, such as marketing, sales, legal, finance and customer support.

As I mentioned in an article yet to be translated to English about creating a product vision, knowing and communicating the context where the product is inserted helps the product manager build, together with the product team, the vision and strategy of her product.

At Locaweb we have some old systems that, as any legacy, are hard to handle: little test coverage, old programming languages, code built with practices from more than 10 years ago. It is a struggle every time we need to touch the legacy code.

We’ve been working for quite some time in order to minimize the amount of legacy code and to build new code that replaces “the legacy”. However, the business cannot stop, and, sometimes, the only way out is to work on “the legacy”. Every time that there’s a demand to make a change to “the legacy” the engineering team asks to wait for the new code that will replace it, since building the demand on “the legacy” will cost too much time and in the new code will be a matter of a few days, if not a few hours.

At the beginning of 2015 a demand that required changes to “the legacy” appeared. It was necessary to change the limits and prices of our web hosting plans to follow up with changes in the market, which has become more competitive with new entrants with more attractive offers. Initially, there was some resistance from the developers to work on the legacy code, but when we explained the motivation behind the changes, they went for it and got their hands dirty in the old code.

As soon as the changes were implemented, we constantly updated everybody who worked in this project about the positive results. The comprehension of why something is needed and should be done is fundamental both for motivating who is working on it and for the quality of what is going to be delivered.

Why context is so important in software development

I want to propose a thought experiment. Let’s use empathy, the main characteristic of a digital product manager, to put ourselves in the position of a software developer who has received the following story from his team’s product manager:

When it reaches 39, an alarm should go off.

Although it appears to have enough information, when you start implementing it, you will see that information is missing. What are 39? Does the alarm go off when it gets to 39 coming from 38 or coming from 40? Or both ways?

Let us now see the same story with the proper context:

We are developing a system that monitors body temperature and this system should sound an alarm when the temperature rises over 39ºC.

With the context, it becomes much easier to understand what the number 39 is and why you were asked to sound the alarm. And it is easier to code the right software.

So, in your next planning session with the team, take the proper time to explain the context of the stories. This will increase the chances of success of your software!

Remove obstacles

This tip has a more tactical aspect. Removing obstacles is fundamental so team members can work on the product. We must feel we are moving forward, that we are doing something, building something. The article What Really Motivates Workers from Harvard Business Review has some interesting data on satisfaction at work. They put together a study in order to find out what happens in an excellent day of work. The answer was in a word: progress.

The advice by the end of the article sums up well the second tip:

You can proactively create both the perception and the reality of progress. If you are a high-ranking manager, take great care to clarify overall goals, ensure that people’s efforts are properly supported, and refrain from exerting time pressure so intense that minor glitches are perceived as crises rather than learning opportunities. Cultivate a culture of helpfulness. While you’re at it, you can facilitate progress in a more direct way: Roll up your sleeves and pitch in. Of course, all these efforts will not only keep people working with gusto but also get the job done faster.

What obstacles?

So, here are some examples of obstacles that a product manager can remove:

  • Be present: the team needs you. During the product development process they’ll need to talk with you about their discoveries and what they are delivering, so you need to be present, otherwise the team may make decisions that could not be aligned with your product vision.
  • Make your product vision clear: even though you’ll be present, sometimes you simply can’t be present. For this reason, and also to set the context as explained above, you need to define your product vision and strategy.
  • Remove excess from stories: the sooner you are able to put your product or feature in front of real users, the earlier you’ll have feedback, so you need to remove all the excess from what you and your team are building, and focus only in the minimum required to get this feedback.
  • Manage expectations and anxieties: expectation management is a big part of a product manager’s job. By expectation management I mean managing the expectations of all of your product stakeholders, internal and external. Having stakeholders asking questions directly to the team can be a big distraction and it means that you were unable to properly align your product vision and strategy with your stakeholders.
  • Help the entire the team perceive themselves as owners of the product: everyone in the product team is a product owner and you have a big role in helping them perceive themselves as such. Show them the context where your product is inserted. Build the product vision and strategy together with them. Share your product numbers, discuss with your team how to improve these numbers.
  • And everything else that hinders the team’s progress! the above list is not comprehensive. The day-to-day product development work is full of obstacles and distractions that can move you away from your main objective, building a successful digital product that helps your company achieve its business goals as well as solves your customers and users problems.

Summing up

So, there you have the 2 leadership tips for product managers and for anyone who is leading a project:

  1. Set the context;
  2. Remove obstacles.

I have been using them throughout my professional life and they have been guiding my success as a product manager.

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

Dicas de liderança para um gestor de produto

Um gestor de produtos tem a difícil tarefa de liderar a evolução do produto sem ser “chefe” de ninguém, ou seja, ele deve convencer a todas as pessoas que trabalham com seu produto de que o caminho que ele definiu para o produto é o mais adequado.

Em vários textos sobre gestão de produtos encontramos que o gestor de produtos é o CEO do produto. Não gosto muito dessa analogia pois um CEO, em última instância, tem ao seu dispor a liderança direta de todas as pessoas da empresa.

Por outro lado, um gestor de produto trabalha em uma relação matricial, ou seja, não tem liderança direta de nenhuma das pessoas envolvidas com o produto. Aliás, esse é um excelente exercício de liderança e uma qualidade extremamente importante para um gestor de produtos: liderar sem ter a “chefia” organizacional.

Mesmo que ele trabalhe em uma organização totalmente horizontal, sem nenhuma hierarquia, ele deverá exercer alguma liderança para convencer as pessoas a evoluir o produto na direção que visualizou.

Por isso, aqui vão duas dicas de liderança que um gestor de produtos, ou qualquer líder, deve lembrar para liderar de forma eficiente.

Estabelecer o contexto

A primeira dica é de caráter estratégico. O gestor de produtos tem a obrigação de:

  • Entender, comunicar e explicar o contexto no qual se insere o que está sendo trabalhado.
  • Ajudar o time a entender onde o produto se insere na estratégia da empresa e no mercado.
  • Saber como os clientes utilizam o produto e o que estes esperam dele, e qual o objetivo do produto para o cliente e para a empresa.
  • Compreender como uma determinada funcionalidade (um novo desenvolvimento que o gestor de produtos pede para o time) se insere no produto e na estratégia desse produto.

Essa dica parece simples e óbvia, mas é comum encontrar pessoas que trabalham sem saber exatamente por que estão fazendo seu trabalho. Ajudar as pessoas a verem o impacto do seu trabalho faz com que elas entendam por que ele é necessário.

Experimente levar engenheiros de software em sua próxima conversa com cliente. Melhor ainda, leve-os a um teste de usabilidade, para que eles possam ver seus usuários utilizando o software que eles desenvolveram. Isso os ajudará a entender por que o software que eles desenvolveram existe, qual problema ele resolve e para quem ele resolve esse problema.

Estabelecer o contexto ajuda muito no engajamento das pessoas que estão envolvidas com o produto. Elas vão entender a sua importância tanto para a empresa – que é dona do produto – quanto para os seus usuários. Esse engajamento é importante não só no core team do produto como também com todas as pessoas envolvidas com ele, como o pessoal de vendas, marketing, jurídico e suporte ao cliente. Todos vão se beneficiar se o gestor de produtos sempre procurar estabelecer seu contexto e mostrar onde o trabalho de cada área se insere no sucesso do produto.

Na Locaweb, temos alguns sistemas antigos que, como todo legado, são bem difíceis de mexer: pouca cobertura de testes, linguagens de programação antigas, código feito com práticas de 10 anos atrás. Sempre que é preciso mexer no código legado é um sofrimento.

Estamos já trabalhando há alguns anos para minimizar a quantidade de código legado, e essa quantidade tem de fato diminuído. Contudo, o negócio não para e, às vezes, a única saída é mexer nele. Sempre que aparece uma demanda dessas, os desenvolvedores perguntam se não dá para esperar o novo sistema que o substituirá.

No início de 2015, apareceu uma demanda desse tipo, em que era necessário mexer nos limites e preços de nossos planos de hospedagem para acompanhar as mudanças do mercado, que estava mais competitivo. Claro que, inicialmente, houve resistência dos desenvolvedores em mexer no legado, mas quando mostramos todo o racional por trás das mudanças, eles arregaçaram as mangas e “sujaram” as mãos no código antigo.

Assim que as mudanças foram implementadas, frequentemente contávamos para as pessoas que trabalharam nesse projeto sobre os seus resultados positivos. Essa compreensão de por que algo é pedido e deve ser feito é fundamental tanto para a motivação de quem for trabalhar na demanda quanto para a qualidade do que será entregue.

POR QUE O CONTEXTO É TÃO IMPORTANTE NO DESENVOLVIMENTO DE SOFTWARE

Quero propor um experimento mental. Vamos usar a empatia, a principal característica de um gestor de produto digital, para nos colocar na posição de um desenvolvedor de software que recebeu a seguinte história do gestor de produto de sua equipe:

Quando atingir 39, um alarme deve disparar.

Embora pareça ter informações suficientes, quando você começar a implementá-las, verá que essas informações estão incompletas. O que são 39? O alarme dispara quando chega a 39 vindo de 38 ou vindo de 40? Ou nos dois sentidos?

Vamos agora ver a mesma história com o contexto apropriado:

Estamos desenvolvendo um sistema que monitora a temperatura corporal e esse sistema deve soar um alarme quando a temperatura subir acima de 39ºC.

Com o contexto, fica muito mais fácil entender qual é o número 39 e por que você foi solicitado a tocar o alarme. E é mais fácil codificar o software certo.

Portanto, em sua próxima sessão de planejamento com a equipe, reserve um tempo adequado para explicar o contexto das histórias. Isso aumentará as chances de sucesso do seu software!

Remover impedimentos

Remover os impedimentos é fundamental para que as pessoas do time possam desenvolver o produto. Isso é importante para poder ter aquela gostosa sensação de progresso, de que estamos fazendo algo, construindo algo. Recentemente li o artigo “What Really Motivates Workers” (O que motiva os trabalhadores) na Harvard Business Review que mostra uma informação importante. Fizeram um estudo para encontrar o que acontece em um excelente dia de trabalho. A resposta, em uma palavra: progresso.

Pesquisa que mostra o que é um bom dia de trabalho

O conselho no final do artigo resume bem a segunda dica:

Você pode criar proativamente a percepção e a realidade do progresso. Se você é um gestor de alto escalão, tome muito cuidado para esclarecer as metas gerais, garanta que os esforços das pessoas sejam adequadamente apoiados e evite exercer uma pressão de tempo tão intensa que pequenas falhas sejam percebidas como crises e não como oportunidades de aprendizado. Cultive uma cultura de utilidade. Enquanto você está nisso, pode facilitar o progresso de uma maneira mais direta: arregace as mangas e entre em campo. É claro que todos esses esforços não apenas manterão as pessoas trabalhando com gosto, mas também farão o trabalho mais rápido.

Evitar escrupulosamente o que estiver impedindo o progresso, evitar alterar objetivos autocraticamente, evitar indecisões, ou segurar recursos. Eventos negativos geralmente têm um efeito maior sobre as emoções, percepções e motivações das pessoas do que os positivos, e nada é mais desmotivador do que um revés – o tipo mais proeminente de evento nos piores dias dos trabalhadores do conhecimento.

QUAIS IMPEDIMENTOS?

Portanto, aqui estão alguns exemplos de impedimentos que um gestor de produto pode remover:

  • Esteja presente: a equipe precisa de você. Durante o processo de desenvolvimento do produto, eles precisarão conversar com você sobre as descobertas e o que estão entregando; portanto, você precisa estar presente; caso contrário, a equipe poderá tomar decisões não alinhadas à sua visão do produto.
  • Deixe sua visão do produto clara: mesmo que você esteja presente, às vezes você simplesmente não pode estar presente. Por esse motivo, e também para estabelecer o contexto conforme explicado acima, você precisa definir sua visão e estratégia de produto, como veremos mais adiante.
  • Remova o excesso de histórias: quanto mais cedo você colocar seu produto ou funcionalidade na frente de usuários reais, mais cedo receberá feedback; portanto, você precisa remover todo o excesso do que você e sua equipe estão construindo e se concentrar apenas no mínimo necessário para obter esse feedback.
  • Gerencie expectativas e ansiedades: o gerenciamento de expectativas é uma grande parte do trabalho de um gestor de produtos. Por gerenciamento de expectativas, quero dizer gerenciar as expectativas de todos os envolvidos no produto, internos e externos. Ter as partes interessadas fazendo perguntas diretamente à equipe pode ser uma grande distração, e isso significa que você não conseguiu alinhar adequadamente sua visão e estratégia de produto
  • Ajude todos na equipe a se perceberem como proprietários do produto: todos na equipe de produto são proprietários e você tem um grande papel em ajudá-los a se perceberem como tal. Mostre a eles o contexto em que seu produto está inserido. Crie a visão e a estratégia do produto junto com eles. Compartilhe seus números de produtos, discuta com sua equipe como melhorar esses números.
  • E tudo mais que dificultar o progresso da equipe! a lista acima não é abrangente. O trabalho diário de desenvolvimento de produtos está repleto de impedimentos e distrações que podem afastar você de seu objetivo principal, criar um produto digital de sucesso que ajude sua empresa a atingir seus objetivos de negócios e resolva problemas de clientes e usuários.

Concluindo

Bom, então estão aí duas dicas de liderança para gestores de produtos e para qualquer pessoa que se veja liderando algum projeto:

  • Estabelecer o contexto;
  • Remover impedimentos.

Tenho usado-as ao longo de toda minha vida profissional e elas têm orientado meu sucesso como gestor de produtos.

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:

Principais características de uma gestora de produtos

O que uma pessoa precisa ter para ser uma boa gestora de produtos? Existem algumas características bem importantes e falarei sobre elas aqui, mas a mais importante de todas é, sem dúvida alguma, a empatia.

empatia

Empatia é a capacidade que uma pessoa tem de se colocar no lugar de outra para compreender os seus anseios, motivações, necessidades e problemas. Essa característica é importante para entender os clientes e usuários do produto, saber como estes se relacionam com ele, e que problema esperam resolver ou que necessidade querem ver atendidas. Isso ajudará a gestora de produtos a entender melhor seu usuário para poder, junto com o UX e a engenharia, desenhar o melhor produto.

Contudo, a empatia não deve ser usada apenas com o cliente ou usuário. A gestora de produtos deve usá-la também no seu relacionamento com todas as áreas da empresa, e deve entender o impacto que seu produto tem no trabalho delas. Será que aumentaram os problemas jurídicos devido a alguma funcionalidade nova no produto? Qual o impacto para a equipe de vendas, suporte, operações, financeiro e marketing? Até mesmo em relação ao time do produto, engenheiros e analistas de UX, como o produto interfere no trabalho desses profissionais?

A segunda característica mais importante é a comunicação.

comunicacao

Para poder ter empatia, é necessário que a gestora de produtos se comunique com as pessoas nos mais diferentes cenários: em conversas um a um e em pequenos grupos, ou fazendo apresentações para grupos pequenos e grandes de pessoas, estes que podem ser internos (dentro da empresa) ou externos (em conferências, grupos de usuários etc.).

Deve também ser bom de comunicação escrita (e-mail, blog, documentação, chat, redes sociais etc.), e ser capaz de discernir sobre qual a forma de comunicação mais apropriada para cada momento, público e meio de comunicação; e de se comunicar de forma a ser entendido pelos diferentes públicos: técnico e não técnico.

Como se isso tudo não bastasse, ele também precisa ser capaz de se comunicar passando segurança e confiança no que está comunicando; afinal, a gestora de produto é a porta-voz do produto.

Porém, não é só de falar que vive a gestora de produtos. Comunicação é uma via de mão dupla, ou seja, a gestora de produto tem de ser muito boa em saber ouvir e compreender o que os outros estão dizendo, e entender os anseios e as necessidades deles; o que tem a ver com a primeira característica, a empatia.

A terceira característica mais importante é a gestão do tempo.

O dia a dia de uma gestora de produtos pode se encher rapidamente de tarefas, e ele precisa ser capaz de perceber e diferenciar o que é urgente do que é importante, para garantir que terá sempre tempo para conhecer mais sobre o cliente e o usuário de seu produto. É muito fácil uma gestora de produtos ver sua agenda repleta de reuniões, com pessoas de diferentes áreas para tratar dos mais diversos assuntos: backlog do produto, atendimento, comunicação de marketing, problemas operacionais, revisão de previsão de crescimento, questões jurídicas, cobrança, régua de comunicação etc.

Isso acontece pois a gestora de produto deve cuidar de seu produto por inteiro. Para o usuário, não existe engenharia, operações, financeiro, jurídico, atendimento e cobrança. Ele enxerga tudo isso como parte do produto que você cuida; e você tem sim de se importar com tudo isso. Contudo, importar-se não significa que você deva ir a todas essas reuniões. Se você fizer isso, poderá tirar o foco do que é mais importante para o seu produto.

Você, como gestora de produtos, precisa focar seu tempo em:

  • Com quantos clientes e usuários você falou essa semana?
  • Você tem uma estratégia e uma visão de longo prazo para o seu produto?
  • Como está e quais as últimas mudanças no cenário competitivo de seu produto?
  • Que insights você teve sobre o seu produto essa semana?
  • Você sabe qual a motivação e a métrica de cada item de seu roadmap?
  • Que novas tecnologias você vê aparecendo que podem influenciar, ou mesmo competir, com o seu produto?
  • Que novas habilidades você está procurando aprender?

As reuniões que mencionei anteriormente são importantes, e aconselho você participar delas quando puder. Apesar disso, você terá muito pouco a contribuir para essas reuniões se você não se focar nos 7 itens que acabei de listar. Procure bloquear um tempo em sua agenda para focar nisso, e você verá como sua participação nas reuniões será muito mais útil e produtiva.

Além dessas três características (empatia, comunicação e gestão do tempo), existem mais quatro que vão ajudar a gestora de produtos a fazer seu trabalho melhor:

  • Novas tecnologias: a gestora de produtos deve estar antenado sobre as novas tecnologias para saber como ela pode impactar o seu produto. Acesso via smartphone, como isso impacta o produto? O usuário quer acessar via smartphone? Para fazer o quê? Redes sociais, como o produto pode tirar proveito delas? Bancos de dados não relacionais, quais os benefícios e as deficiências? Go, a nova linguagem de programação do Google, no que ela é melhor do que a linguagem usada no produto? E no que ela é pior? Smartwatches, smartglasses, como isso impacta o produto? Como o usuário espera interagir com o produto nessas novas interfaces?
     
  • Business skills: a gestora de produtos deve se preocupar se o seu produto está atingindo os objetivos de negócio. Se o objetivo for margem, receita menos custos estão sob controle? Se o objetivo for só receita, como está o crescimento de receita? Se o objetivo for número de usuários, como está evoluindo essa métrica? Além disso, a gestora de produtos deve entender como cada área da empresa funciona e como o produto afeta essas áreas. Como o jurídico funciona? Como o produto impacta o departamento jurídico? E como o departamento jurídico impacta o produto? Essas perguntas podem ser repetidas para todas as áreas da empresa: suporte, operações, financeiro, RH, marketing, vendas, engenharia e UX.
     
  • Curiosidade aguçada: a gestora de produto precisa ter a capacidade de aprender rápido para poder ter insights e fazer julgamentos sobre o produto. Deve ser capaz de aprender tanto o lado soft do produto (qual é a motivação de negócio, qual problema do cliente o produto resolve etc.) como o lado mais técnico (qual tecnologia usamos, qual o impacto dessa tecnologia, que métricas podemos obter etc.).
     
  • Tema do produto: por fim, mas não menos importante, a gestora de produtos precisa conhecer sobre o tema do produto. Se for um produto médico, a gestora de produto deverá entender um pouco sobre medicina. Se for um produto financeiro, deverá conhecer um pouco de finanças. Por exemplo, na Locaweb, temos produtos mais técnicos (como o Cloud Server) e menos técnicos (como a Loja Virtual). A necessidade de conhecimento técnico é bem diferente nesses dois produtos. A gestora de produto do Cloud Server deverá conhecer bem a fundo questões técnicas, enquanto a gestora de produto da Loja Virtual não precisa ter tanto conhecimento técnico, mas deverá saber bastante sobre questões de venda online.

Dá para perceber que essa lista é um conjunto de características que nem todas as pessoas têm. É comum casos de pessoas de outras áreas que resolvem experimentar a carreira de gestora de produtos, mas que, após algum tempo, percebem que não têm todas as características necessárias.

Se você é uma gestora de produtos, ou deseja ser uma, faça uma autoanálise para ver como você está em cada uma das características e, se alguma estiver aquém do desejado, foque em desenvolvê-la. Se você é responsável por identificar e contratar gestoras de produto, use essa lista como guia para saber se o candidato tem as características necessárias para ter sucesso como gestora de produto.

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:

7 essential characteristics of a product manager

What does a person need to have in order to be a good product manager? There are some important characteristics and I’ll talk about them here. But the most important of all is, certainly, the one that illustrates this article, empathy.

Empathy is the ability someone has to walk in someone else’s shoes in order to understand her aspirations, motivations, needs, and problems. This characteristic is important to understand customers and users of the product, to know how they relate to the product, and what problem they expect to be solved, or what needs they want to fulfill. This will help the product manager to better understand his user in order to design the best product along with UX and engineering.

However, empathy must not be used only with the customer or the user. The product manager must use it also when relating with other areas of the company and must understand the impact the product has on their work as well. Did legal problems increase because a feature of the product was launched or changed? What is the impact on the sales team, on support, operations, finances, and marketing? Regarding the product team, engineers, and UX analysts, how does the product interfere with the work of these professionals?

The second most important characteristic is communication. In order to be empathetic, the product manager needs to communicate with people in several scenarios: in one-on-one conversations and in small groups or making presentations for small and big groups of people, internal (inside the company) or external communication (in conferences, user groups, etc.).

The product manager must also be good in written communication (e-mail, blog, documentation, chats, social networks, etc.) and be able to distinguish about what is the most appropriate way of communication in a given moment, to a given audience and using a specific media; and communicate in a way he gets understood by different audiences: technical and non-technical.

As if all this was not enough, the product manager must also be able to communicate with confidence and believing in what he’s communicating; after all, the product manager is the spokesperson of the product.

However, talking is not the only communication task of the product manager. Communication is a two-way street, in other words, the product manager must be very good at listening and understanding what others are saying, and understanding their aspirations and needs; and this has everything to do with the first characteristic, empathy. 

The third most important characteristic is time management. The day-by-day of a product manager can get quickly filled with tasks and he needs to be able to notice and distinguish what is urgent from what is important to guarantee that he will always have time to know more about the customer and the user of his product. It is very easy for a product manager to face his daily schedule full of meetings, with people from different areas to discuss several subjects: product backlog, customer support, marketing communication, operational problems, forecast review, legal matters, collection, etc.

The product manager has to take care of his product as a whole. For the user, there’s no engineering, operations, finance, legal and collection departments. He sees everything as part of the product that the product manager takes care of, and he does have to care about everything. However, caring about does not mean that he should go to all these meetings. If he does so, he will take the focus out of what is most important to his product.

As a product manager, he must focus his time on:

  1. With how many clients and users did you talk this week?
  2. Do you have a long term strategy and view for your product?
  3. How is it going and what are the last changes in the competition scenario of your product?
  4. Which insights did you have about your product this week?
  5. Do you know which is the motivation and the metrics for each item of your roadmap?
  6. What new technologies do you see coming up that could influence or even compete with your product?
  7. Which new skills are you trying to learn?

Some meetings are important, and I advise you to participate when possible. In spite of that, you won’t have much to contribute in these meetings if you don’t focus on the 7 items I’ve just listed. Do save some time in your schedule to focus on that, and you will see your participation in meetings get more useful and productive.

Aside from these three characteristics (empathy, communication, and time management), there are four other ones that will help the product manager to do a better job:

  • New technologies: the product manager must be aware of new technologies to know how they can impact her product. How does mobile access impact the product? The user wants to access via smartphone? To do what? Social networks, how can the product take advantage of them? Non-relational databases, what are the benefits and shortcomings? Go, Google’s new programming language, where is it better than the language used in the product? And where is it worse? Smartwatches, smartglasses, how does this impact the product? How do you expect to interact with the product on these new interfaces?
  • Business skills: every product exists to fulfill the user needs while reaching the company goals for the product. The product manager needs to understand what are these company goals, and needs to be sure that the product is evolving toward these goals. If it is margins, revenue and costs are under control? If the goal is revenue growth, is it evolving as expected? If the goal is number of users, how is the product compared to the target? Besides being concerned about company goals for the product, the product manager must understand how each area of the company works and how the product affects these areas. How the legal department works? How the product impacts it? And how the legal department impacts the product? These questions can be asked for every area of the company: support, operations, finances, human resources, marketing, sales, engineering and UX. 
  • Keen curiosity: the product manager must be able to learn fast in order to have insights and make judgments on the product. He must be able to learn both the soft side of the product (what is the motivation of the business, what is the problem of the client that the product solves etc.) and the more technical side (which technology do we use, what is the impact of this technology, what metrics can we obtain etc.).
  • Product theme: last but not least, the product manager must know the theme of the product. It it is a medical product, the product manager must understand a little about medicine. If it is a financial product, he must know a little bit about finance. For instance, at Locaweb, we have more technical products (such as Cloud Server) and less technical ones (such as Virtual Web Store). The need for technical knowledge is quite different regarding the two products. The product manager from Cloud Server must have a good technical knowledge while the product manager from Virtual Web Store does not have to know about technical questions, however he must have knowledge on online sales matters.

We can see that this list is a set of characteristics that not all people have. It is common for people from other areas that decide to try the product manager career, but after a while, they realize that they don’t have all that it takes.

If you are a product manager or wish to be one, do a self-analysis on each one of these characteristics. And if you are lagging behind in any of them, then focus on developing it. If you are responsible for identifying and hiring product managers, use this list as a guide to know if the candidate has the necessary characteristics for succeeding as a product manager.

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

Product manager or product owner?

Product manager or product owner? Which term should we use? Are they different roles? Are they complementary? Is there overlapping? Is it better to have two distinct individuals, one for each role? Or is it better to combine two roles in one single person?

Definitions

First of all, let’s see some other concepts.

“The Product Owner is responsible for maximizing the value of the product and the work of the Development Team.” says the Scrum Guide, and then it continues: “The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog items priority
must address the Product Owner.”

“The Product Owner represents the stakeholders and the voice of the customer,” says Wikipedia. “He is accountable for ensuring that the team delivers value to the business. The product owner writes (or has the team write) customer-centric items (typically user stories), ranks and prioritizes them, and adds them to the product backlog.”

By the definitions displayed, it is clear the product owner’s focus on:

  • Managing backlog priorities based on inputs from stakeholders and clients; and
  • Maximizing the deliveries from the development team.

On the other hand, in the chapter [ref-label what-is-product-management], I’ve defined digital product management as:

A> The function responsible for all aspects of a software product, during all lifecycle of the product, from its conception to the end of its life.
A>
A> It is the function responsible for connecting the company’s strategy and the problems and needs of clients using the software product, which must help, at the same time, (1) the company to accomplish its strategic goals, and (2) solve the problems and needs of clients.

In other words, product managers need to know very well their business and what are the goals they intend to reach with it, as well as who is going to use the software and what are the goals their users intend to reach by doing so. Based on it, the product managers define how their software is going to be.

On the one hand, the definitions of product owner are strongly focused on the process, meaning they prioritize the backlog and maximize the production of the development team; while the definition of product management is strongly focused on results, meaning they prioritize the software goals for its business and for its users.

The definitions of product owner focus on the process, as all agile methodologies focus on the software development process. The Agile Manifesto itself (http://agilemanifesto.org/) states that “We are discovering better ways to build software”. Notice that the concern is about discovering better ways of building it, and not discovering ways of building better software. Is a subtle but important difference from the grammar’s point of view.

While “discovering better ways of building software” is focused on the process of developing software, when we talk about “discovering ways of building better software” we immediately focus on the results of software development: the software! That’s why my definition of product management focuses on the software and the goals of its business and its users, while the definitions of product owner focus on how to improve the software development process.

So are they different roles?

The short answer is no. Although they have a distinct focus, it is valid to say that they are two sides of the same coin. You cannot have one without the other. In other words, we can’t focus on improving the process of software development without thinking of improving the software that is being built; the same way that is not possible to think of improving it without investing on improving the process of software development.

I’ve interviewed dozens of IT directors and asked them how they design their software development organization. The results: there are product owners who are a part of the software development team, and responsible for managing the backlog and detailing the items of this backlog, and there are the product managers who are not part of the development team, they are responsible for the software business view and provide to the team great epics which will be detailed by a product owner.

Founded in 1998, Locaweb is a pioneer and leader in IT hosting services in Brazil. I worked there from 2006 through 2016 and I’ll use some examples from my time there. The company currently has over 250,000 clients and partners with more than 14,000 developers. Locaweb products are designed for everyone, from the common user to major corporations. Some of Locaweb’s products are website hosting, domain registration, hosting reseller, e-mail services, and e-mail marketing, e-commerce, and infrastructure for audio and video streaming, cloud computing, dedicated servers, and specialized IT outsourcing services.

At Locaweb, we chose for using the terms product manager and product owner as synonyms because, as said earlier, for us they are two sides of the same coin. You can’t prioritize the backlog and maximize the deliveries of the development team if you don’t have profound knowledge of the goals of the business and the users of the software. In addition, in order to build the software that meets both the goals of the business and of the users, you must prioritize the backlog and optimize the development process.

One side of the coin is the development team’s “what” and the other side is the “how”. One doesn’t exist without the other.

So, if you’re in a company where the product manager and the product owner roles are divided in two distinct people, you must keep on reading. The next session explores your situation.

What to do if your company has product managers and product owners?

I know some companies that operate with this role division between two distinct individuals and that, by reading this book, you’re now thinking you have staff to spare. :-O

Please don’t. Very likely, some other role is missing in your software product development team. My recommendation in such cases:

  • Don’t go radical: don’t go on firing people thinking that there are overlapping roles. It is necessary a more careful look because other roles might be missing in your organization.
  • Product marketing: probably there’s a lack of people taking care of the product marketing, someone who has complimentary goals but different from the product manager. In the chapter about Product Marketing, I’ll write about the difference between product manager and product marketing manager.
  • Analyze what is being done today: it is probable that your product manager, sometimes called business manager, is doing more stuff than a product marketing manager. In this case, it is interesting that this person starts to work as an actual product marketer and leave the product manager activities for the product owner eventually. This one, thus, can take care of the product management.
  • Use a new product to experiment the new role division: another way to experiment this new role division and responsibilities is to use them only in a new product. When you start to develop a new product, experiment this new role division and see how it goes. If it works, you can unroll it to other existent products.

Now that we understand a little bit more about what is a software product manager, let’s see which are the main characteristics of this role.

BA, PO and PM

In August 2016 I took over the management of product management at ContaAzul, and when I arrived I came across a structure with business analysts (BAs) and product managers (PMs), a new scenario for me. I spent some time talking to people to understand the roles and responsibilities of each function and the motivations for the creation of such a structure. After these conversations, it became clear to me the difference of roles and responsibilities of each of the functions, which I try to translate into the image below.

BA, PO e PM

This image shows some important aspects:

  • POs do what BAs do (specification) plus the prioritization of what needs to be done. And PMs, in addition to prioritization and specification, are responsible for the development, communication, and execution of product vision and strategy. There is an increase in scope and responsibility as you move from BA to PO to PM.
  • Although PM is responsible for developing, communicating and executing product vision and strategy, it is also responsible for prioritization and specification.
    It may make sense for some companies to have BAs and PMs, or POs and PMs, or even BAs, POs and PMs. However, there cannot be companies without someone as PM, developing, communicating and executing the vision and strategy of the product.
  • If in a company, in addition to the PMs, there are people in the role of BA and / or PO functions, it is possible to place the PMs as managers of the BAs and / or POs. However, this creates an extra burden for the PM who, in addition to managing the product, will have to worry about managing people.
  • My preference is for not having this separation of roles and having only PMs. If there are BAs and / or POs in a certain organization, my recommendation is for treating those roles as intermediate career steps that will evolve to reach the PM level, with increased scope and responsibility. The rationale for my preference is that by leaving the roles separate, the PM may make little or no specification and / or prioritization, delegating those responsibilities to BAs and / or POs. By doing so, the PM will lose important input to developing the vision and strategy of her product.

I believe that with this image I was able to clarify the differences and similarities of the functions of BAs, POs and PMs.

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

Gestora de produtos ou product owner?

Gestora de produtos ou Product Owner? Que termo usar? São papéis diferentes? São complementares? Há sobreposição? É melhor ter duas pessoas distintas, uma para cada papel? Ou é melhor combinar os dois papéis em uma única pessoa?

DEFINIÇÕES

Antes de mais nada, vamos ver mais um pouco de definições.

“O Product Owner é a pessoa responsável por maximizar o valor do produto, o trabalho do time de desenvolvimento, e a gestão do backlog do produto.”, segundo o Guia do Scrum, e então continua: “O Product Owner é uma pessoa e não um comitê. O Product Owner pode representar o desejo de um comitê no backlog do produto. Entretanto, aqueles que quiserem uma alteração nas prioridades dos itens de backlog devem encaminhar ao Product Owner.

“O Product Owner representa os stakeholders e é a voz do cliente”, de acordo com a Wikipedia. “Ele é responsável por garantir que o time entregue valor para o negócio. O Product Owner escreve (ou faz o time escrever) itens centrados no cliente (em geral histórias de usuário), e classifica e prioriza esses itens, adicionando-os ao backlog do produto”.

Pelas definições, fica claro o foco do Product Owner em:

  • Gerenciar as prioridades do backlog, com base em inputs dos stakeholders e clientes; e
  • Maximizar as entregas do time de desenvolvimento.

Por outro lado, no capítulo anterior, definimos gestão de produtos como sendo:

GESTÃO DE PRODUTOS DE SOFTWARE

Gestão de produtos de software é a função responsável por todos os aspectos de um produto de software, durante todo o ciclo de vida desse produto, desde a sua concepção até o fim de sua vida.

É a função responsável por fazer a conexão entre a estratégia da empresa e os problemas e necessidades dos clientes por meio do produto de software. Este deve, ao mesmo tempo, (1) ajudar a empresa a atingir seus objetivos estratégicos, e (2) solucionar os problemas e as necessidades dos clientes.

Em outras palavras, o gestor de produtos precisa conhecer bem tanto quem é o dono do software e quais os objetivos que este deseja alcançar com ele, como quem vai usar esse software e quais os objetivos que esse usuário pretende alcançar ao fazer isso. Somente conhecendo tais objetivos é que o gestor de produtos poderá definir como será esse software.

Dá para perceber que, por um lado, as definições de Product Owner se focam bastante no processo, em priorização de backlog e em maximização da produção do time de desenvolvimento. Já a definição de gestão de produtos é totalmente focada no resultado, no software que está sendo feito e nos seus objetivos, tanto para seu dono quanto para seu usuário.

As definições de Product Owner focam no processo, pois todas as metodologias ágeis têm foco no processo de desenvolvimento de software. O próprio Manifesto Ágil (http://agilemanifesto.org/) diz que “Estamos descobrindo maneiras melhores de desenvolver software”. Note que a preocupação é em descobrir maneiras melhores de desenvolvê-lo, e não em descobrir maneiras de desenvolver softwares melhores. É uma diferença sutil do ponto de vista gramatical, mas enorme no significado. Enquanto “descobrir maneiras melhores de desenvolver software” se foca no processo de desenvolver software, quando falamos em “descobrir maneiras de desenvolver softwares melhores”, passamos imediatamente a nos focar no resultado do desenvolvimento de software: o software! Por isso, minha definição de gestão de produtos tem foco no software e nos objetivos de seu dono e de seus usuários, enquanto que as definições de Product Owner focam em como melhorar o processo de desenvolvimento de software.

ENTÃO SÃO PAPÉIS DIFERENTES?

Resposta curta: NÃO. Apesar de terem focos distintos, pode-se dizer que são dois lados da mesma moeda. Não dá para ter um sem o outro. Não dá para focarmos em melhorar o processo de desenvolvimento de software sem pensarmos em melhorar o software que está sendo produzido; da mesma forma que não é possível pensar em melhorá-lo sem investir no melhoramento do processo de desenvolvimento de software.

Entrevistei dezenas de diretores de TI e perguntei como eles projetam sua organização de desenvolvimento de software. Os resultados: existem Product Owners que são parte do time de desenvolvimento de software, e são responsáveis por gerenciar o backlog e detalhar seus itens; e existem os gestores de produtos, que não fazem parte do time de desenvolvimento, são responsáveis pela visão de negócio do software e passam para o time grandes épicos que deverão ser detalhados por um Product Owner.

Fundada em 1998, a Locaweb (http://www.locaweb.com.br) é pioneira e líder em serviços de hospedagem de TI no Brasil. Trabalhei lá de 2006 a 2016 e usarei alguns exemplos do meu tempo lá. Atualmente, a empresa possui mais de 250.000 clientes e parceiros com mais de 14.000 desenvolvedores. Os produtos Locaweb são projetados para todos, desde usuários comuns até grandes corporações. Alguns dos produtos da Locaweb são: hospedagem de sites, registro de domínio, revenda de hospedagem, serviços de e-mail e marketing por e-mail, comércio eletrônico e infraestrutura para streaming de áudio e vídeo, computação em nuvem, servidores dedicados e serviços especializados de terceirização de TI.

Na Locaweb, optamos por usar os termos gestor de produtos e Product Owner como sinônimos, pois, como dito anteriormente, eu os enxergo como dois lados da mesma moeda. Não dá para priorizar o backlog e maximizar as entregas do time de desenvolvimento se você não tiver um profundo conhecimento dos objetivos do dono e dos usuários desse software. Assim como não dá para produzir o melhor software que atenda aos objetivos tanto do dono como de seus usuários se você não priorizar corretamente o backlog e não maximizar as entregas do time de desenvolvimento.

Um é o “o quê”, e o outro é o “como” do desenvolvimento de software. Não existe um sem o outro. Caso você esteja em uma empresa onde esses papéis estão divididos em duas pessoas distintas, continue lendo. A próxima seção explora esta situação.

O QUE FAZER SE NA SUA EMPRESA TIVER GESTORES DE PRODUTOS E PRODUCT OWNERS?

Conheço algumas empresas que têm essa separação de papéis em pessoas distintas e que, ao lerem que esses papéis devem ser executados pela mesma pessoa, podem pensar que estão com sobra de gente. :-O

Não estão! Muito provavelmente algum outro papel está faltando no seu time de desenvolvimento de produtos de software. Minha recomendação para esses casos:

  • Não seja radical: não saia demitindo pessoas achando que há sobreposição de papéis. É preciso um olhar mais cauteloso, pois outras funções podem estar faltando na sua organização.
  • Marketing de produtos: provavelmente está faltando uma pessoa cuidando do marketing de produto, que tem objetivos complementares, mas bem diferentes do gestor de produtos. No capítulo Qual a diferença entre gestão de marketing de produtos e gestão de produtos?, escreverei sobre a diferença entre gestor de produtos e gestor de marketing de produtos.
  • Analise o que está sendo feito hoje: é provável que o seu gestor de produtos, às vezes chamado de gestor de negócios, esteja fazendo mais coisas de um gestor de marketing de produtos. Nesse caso, é interessante que essa pessoa comece a trabalhar como profissional de marketing de produtos e, eventualmente, deixe as atividades de gestor de produtos para o product owner. Este poderá, assim, cuidar da gestão de produtos.
  • Use um próximo produto para experimentar com a nova divisão de papéis: outra forma de experimentar com essa nova divisão de papéis e responsabilidades é usá-la somente em um novo produto. Quando você estiver pensando em fazer um novo produto, experimente essa nova divisão de papéis e veja como esse produto evolui. Se der certo, você pode estender para os produtos existentes.

Agora que entendemos um pouco mais sobre o que é um gestor de produtos de software, vamos ver quais são as principais características dessa função.

BA, PO OU PM

Em agosto de 2016, assumi a gestão da gestão de produtos na Conta Azul e, quando aqui cheguei, me deparei com Business Analysts (BAs) e Product Managers (PMs), um cenário novo para mim. Passei algum tempo conversando com as pessoas para entender papéis e responsabilidades de cada função e as motivações para essa estrutura ter sido criada. Após essas conversas, ficou mais claro a diferença de papéis e responsabilidades de cada uma das funções, diferença essa que tento traduzir na figura a seguir.

Em uma imagem a diferença entre BA, PO e PM

Essa imagem mostra alguns pontos importantes:

  • POs fazem o que BAs fazem (especificação) mais a priorização do que precisa ser feito. E os PMs, além de priorização e especificação, são responsáveis pelo desenvolvimento, comunicação e execução da visão e estratégia do produto. Existe um aumento de escopo e responsabilidade à medida que se move na carreira de BA para PO, e depois para PM.
  • Apesar de o PM ter por sua responsabilidade o desenvolvimento, comunicação e execução da visão e estratégia do produto, ele também é responsável pela priorização e pela especificação. Pode fazer sentido em algumas empresas ter BAs e PMs, ou POs e PMs, ou mesmo BAs, POs e PMs. Contudo, não pode haver empresas sem alguém fazendo o papel de PM, ou seja, desenvolvendo, comunicando e executando a visão e estratégia do produto.
  • Caso haja em uma empresa, além dos PMs, pessoas exercendo função de BA e/ou PO, é possível colocar os PMs como gestores dos BAs e/ou POs. Contudo, isso cria uma carga extra para o PM que, além de gerir o produto, terá de se preocupar com gestão de pessoas.
  • Minha preferência é por não ter essa separação de papéis e ter apenas PMs. Se houver BAs e ou POs em uma determinada organização, minha recomendação é por tratar esses papéis como passos intermediários de carreira que vão evoluir para atingir o nível de PM, com aumento de escopo e de responsabilidade. A justificativa para essa minha preferência é que, ao deixar os papéis separados, pode acontecer de o PM fazer pouca ou nenhuma especificação e/ou priorização, delegando essas responsabilidades para BAs e/ou POs. Ao fazer isso, o PM perderá insumo importante para o desenvolvimento da visão e estratégia do seu produto.

Acredito que, com essa imagem, consegui deixar mais esclarecidas as diferenças e similaridades das funções de BAs, POs e PMs.

GESTOR OU GERENTE DE PRODUTOS?

Em inglês, a função é conhecida como Product Manager e, olhando no Wikipédia, vemos a seguinte definição para a palavra manager:

MANAGER

Inglês para “gerente” ou “gestor”, em assuntos relacionados à economia e à administração de empresas, e “treinador”, para esportivos.

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

Então, usar gestor de produtos ou gerente de produtos é indiferente, pois ambas as palavras servem de tradução para manager. Aqui no livro, usarei sempre gestor por uma razão simples. Na cultura corporativa brasileira, a palavra gerente costuma denotar alguém que “chefia” pessoas, só que o gerente de produtos não é chefe de ninguém.

Essa função não deve gerenciar pessoas, mas gerenciar coisas. Da mesma forma que um gerente de contas e um gerente de projetos não deve gerenciar pessoas, mas sim contas e projetos, respectivamente. Por esse motivo, prefiro usar a palavra gestor, para tirar qualquer conotação de que essa função deva gerenciar pessoas.

Agora que já entendemos um pouco mais o que é um gestor de produtos de software, vamos conhecer quais são as principais características dessa função.

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: