2 hacks to foster your digital product culture

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

What is digital product culture?

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

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

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

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

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

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

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

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

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

Hack #2: problem mindset

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

Summary

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

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

Digital Product Management Books

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

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

2 Hacks Para Promover e Fortalecer sua Cultura de Produto Digital

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

O que é Cultura de Produto Digital?

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

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

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

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

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

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

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

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

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

Hack #2: Qual é o Problema?

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

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

Resumo

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

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

Gestão de produtos digitais

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

Organizational culture

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

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

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

Culture differences by Manu Cornet

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

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

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

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

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

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

Don’t waste time looking for culprits

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

Blame game, by Ron Tandberg

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

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

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

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

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

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

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

War

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

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

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

I believe the images speak for themselves.

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

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

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

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

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

Air, food and profit

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

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

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

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

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

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

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

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

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

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

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

Concluding

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

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

Digital Product Management Books

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

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

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:

Conclusão

Após esse resumão, chegamos ao final do livro Liderança de produtos digitais: A ciência e a arte da gestão de times de produto. Procurei documentar nesse livro o que tenho aprendido ao longo da minha carreira na esperança de ajudar outras pessoas a conhecerem mais sobre como liderar o desenvolvimento de produtos digitais.

Ao longo dos meus 30 anos de carreira, tenho experimentado diferentes formas de ajudar times de desenvolvimento de produto a atingirem seus objetivos, ou seja, a conseguirem criar e evoluir produtos de sucesso. Tenho ajudado não só os times que liderei diretamente, como times de outras empresas para quem presto serviço de advisoring. Todas essas experiências me proporcionaram um campo muito fértil para experimentações e aprendizados.

Há outras formas de se liderar times de produtos, e algumas podem inclusive ter pontos de discordância com o que apresentei aqui no livro. Contudo, não existe uma única forma de se fazer as coisas e o fato de elas serem diferentes ou até mesmo discordantes não significa que alguma delas é errada. Quer dizer apenas que são diferentes e cabe a cada um de nós encontrar a forma que mais faça sentido para o desafio de liderança que encontrarmos.

O mais importante é que compartilhemos nossos aprendizados, mesmo que discordantes, para podermos sempre evoluir essa disciplina tão nova que é o desenvolvimento de produtos digitais. Não faz nem 100 anos que essa ciência começou, somos um recém-nascido se comparados à matemática, engenharia, medicina, astronomia e tantas outras ciências que existem há milênios.

Vamos continuar a conversa?

O fato de estarmos na 1ª infância do desenvolvimento de produtos digitais significa que há muito ainda para aprender e experimentar. Esses aprendizados e experimentações precisam ser compartilhados para ajudar outras pessoas a conhecerem mais, experimentarem, concordarem e discordarem para que possamos fazer a arte e a ciência de liderar produtos digitais evoluir cada vez mais para produzir produtos cada vez melhores e mais úteis.

Eu vou continuar compartilhando em http://gyaco.com. Incentivo você a também compartilhar sua experiência e seus aprendizados sobre liderança de desenvolvimento de produtos digitais! Estou ansioso para aprender mais!

Liderança de produtos digitais

Este artigo faz parte 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:

Resumindo

Neste capítulo transcrevi as seções Resumindo de todos os capítulos com o objetivo de criar um guia de referência rápida sobre todos os tópicos discutidos neste livro.

CONCEITOS

Comecei o livro estabelecendo algumas definições, fazendo uma revisão de conceitos básicos como produto e gestão de produtos, e apresentando novos conceitos como funções e responsabilidades de head de produto, estrutura de equipe, carreira e carreira Y para gerentes de produto.

O que é produto digital e gestão de produtos

  • Produto digital é qualquer software que tenha usuários.
  • Produtos digitais podem existir tanto em empresas digitais, em que o produto digital é o produto que a empresa vende, quanto em empresas tradicionais, que usam o produto digital para alavancar e potencializar o produto principal da empresa.
  • Recentemente começaram a surgir as empresas tradicionais nascidas digitais, ou seja, empresas que vendem um produto não digital, mas que têm o produto digital como parte crítica de sua estratégia desde o início da empresa.
  • Plataformas são produtos que entregam mais valor quanto mais usuários utilizam a plataforma, o famoso efeito de rede. Existem plataforma de um único lado e plataformas de múltiplos lados, que podem ser de troca, de conteúdo ou técnicas.
  • Gestão de produtos é a função responsável por conectar os objetivos estratégicos da empresa com os problemas e necessidades dos clientes.

Papéis, responsabilidade e senioridade

  • O head de produto é responsável por coordenar a definição da visão e estratégia de produto, por ajudar os gestores de produto em seu desenvolvimento e por gerir as expectativas de todas as pessoas que têm interesse em seu produto.
  • Um conceito muito importante para ajudar uma head de produto com suas responsabilidades é o conceito de senioridade, que tem 3 dimensões, duas bem conhecidas, o tempo e o conhecimento e uma terceira não tão conhecida, mas tão importante quanto às outras, a senioridade de comportamento.

Carreira de gestão de produtos

  • A carreira de produto tem a progressão de Associate Product Manager (APM) para Product Manager (PM) para Group Product Manager (GPM) para Chief Product Officer (CPO). Existem algumas variações de nomenclatura a depender da empresa e do país, mas em geral segue essa progressão. O importante é essa estrutura e progressão de carreira estarem claras para toda a empresa.
  • Quando se fala da liderança mais sênior de produto em uma empresa, há duas opções com seus prós e contras. Uma opção é a liderança única de todo time de desenvolvimento de produtos (PM, UX e engenharia), que funciona bem para times maiores, mas pode sobrecarregar quando são times de mais de 100 pessoas. A vantagem é ter todo o time alinhado com uma única liderança. A outra opção é a liderança compartilhada com CPO e CTO, que evita a sobrecarga em times grandes, mas pode causar uma diminuição de colaboração caso não haja boa sintonia entre esses dois ou mais líderes.
  • Para PMs que não querem seguir a carreira de gestão, é importante dar a opção da carreira em Y, com o papel de Principal Product Manager, que ajuda na integração e sincronia do trabalho dos diferentes times.

Visão de produto

  • Apesar de ser apenas 10% do tempo de um líder de produto, definição de visão de produto é sua responsabilidade mais importante. Sem ela todo o trabalho de desenvolvimento de produto fica muito mais difícil.
  • A visão de produto nada mais é do que o entendimento de como será o seu produto no futuro.
  • Para fazer a visão de produto é preciso ter clareza sobre os objetivos da empresa com o produto, bem como entender profundamente os problemas e as necessidades que os clientes têm e que serão resolvidos pelo produto.
  • Os 6 passos para construir uma visão de produto são: obter objetivos estratégicos da empresa, obter entendimento dos problemas e necessidades dos clientes, desenhar primeira versão da visão, iterar e refinar, comunicar e revisar.

Estratégia e objetivos

  • Estratégia de produto nada mais é do que o caminho que você vai seguir para chegar à sua visão de produto.
  • Para criar sua estratégia de produto você precisa ter bastante entendimento sobre seu mercado, ou seja, os concorrentes, o mercado potencial e acessível, o crescimento desse mercado, se existem disruptores e como esse mercado é regulado.
  • Utilize a análise SWOT para ajudar a definir que pontos você vai trabalhar em sua estratégia de produto.
  • Utilize OKRs para ajudar a definir os objetivos de sua estratégia e as métricas que dirão se você está no caminho correto.
  • Revise pelo menos anualmente, ou quando houver eventos relevantes no mercado, a sua estratégia e sua visão de produto. O mercado muda, seu produto evolui, então sua visão e estratégia de produto também deve evoluir. Os OKRs devem ser revistos trimestralmente.

Estrutura de time

  • Times de desenvolvimento de produto são organizados em times mínimos, também chamados de squads, compostos de engenheiros, product designers e product managers. É importante deixar esses times o mais enxuto possível para ajudar em sua produtividade. Esses times mínimos são agrupados em times de produto chamados de tribos de produto.
  • 4 formas de se organizar os times de produto: por produto ou funcionalidade, por tipo de usuário, por jornada ou por objetivo. É possível também usar dois tipos diferentes de organização, criando uma organização híbrida.
  • Existem também as tribos estruturais, que criam a estrutura necessária para as tribos de produto performarem. Times que compõem as tribos estruturais são SRE/DevOps, Dados, Arquitetura/ Ferramentas/ Fundação, Design Ops, Segurança da Informação, Sistemas Internos, Engenharia de Vendas e Serviços Profissionais.
  • A implementação da organização de time desenhada pode ser feita ou criando uma nova estrutura ou ajustando um time já existente. Em ambas as situações é importante conhecer bem a visão e a estratégia de produto para desenhar e implementar uma estrutura de time alinhada com ela.
  • A proporção mais indicada entre pessoas em engenharia e gestores de produto é de 7 +/- 2 engenheiros para cada gestor de produto. E de um product designer para cada gestor de produto.
  • Dois conceitos importantes no desenho de sua estrutura de time são o da Lei de Conway, que diz que as organizações tendem a criar sistemas que são uma cópia da estrutura de comunicação das empresas, e os 4 estágios de Tuckman de formação de times, formando, confrontando, normatizando e performando.
  • É possível também organizar times de produto por unidades de negócio que tenham outras funções além das compreendidas em um time de desenvolvimento de produto, tais como marketing, vendas e atendimento ao cliente. As motivações para criar unidades de negócio em vez de times de produto podem ser devido à aquisição, ou para dar mais agilidade ao novo negócio ou mesmo por se tratar de uma nova linha de produto completamente diferente do produto original.
  • O que faz um grupo de pessoas se comportar como um time são os objetivos comuns.

Desenvolvendo o time e gerenciando expectativas

  • Para desenvolver seu time e gerir expectativas, o head de produto deve ter as 7 características de um bom gestor de produtos: empatia, comunicação, gestão do tempo, novas tecnologias, habilidades empresariais, curiosidade aguçada e tema do produto
  • Três dessas características são essenciais para o trabalho de head de produto. Empatia para entender de onde vêm as expectativas e que elementos precisam ser desenvolvidos em seu time. Comunicação para poder entender e se fazer entender quando estiver conversando com as pessoas da empresa para gerir suas expectativas e quando estiver desenvolvendo seu time. Habilidades empresariais que ajudarão a entender os objetivos da empresa que são componentes importantes das expectativas que as pessoas têm em relação ao produto.

Antipadrões

  • Antipadrões são respostas comuns mas ineficazes de se resolver problemas. Existem muitos antipadrões bem documentados no mundo do desenvolvimento de produtos digitais. Os 4 antipadrões mais comuns em liderança de desenvolvimento de produto são documentação, foco em dados, grande reescrita e lista de desejos.
  • Documentação, que deveria ser mantida em um mínimo, para certos líderes chega a ser mais importante que o próprio produto. Nada pode ir para produção se não estiver devidamente documentado.
  • Foco em dados é quando toda e qualquer decisão tem que ser tomada com dados, sem levar em conta informações qualitativas, experiência prévia e intuição.
  • Grande reescrita acontece quando uma nova head de produto encontra um sistema escrito há algum tempo e identifica que será melhor reescrever do zero um novo sistema do que aprimorar o atual.
  • Lista de desejos vem da necessidade de o novo head de produtos de agradar a todos os stakeholders, focando o time de desenvolvimento de produtos a apenas implementar o que é pedido, delegando a priorização para as outras áreas da empresa.

PRINCÍPIOS

Aqui vimos meus princípios pessoais de liderança:

  • Pessoas: a prioridade nº 1, sempre.
  • Liderar é como ser um médico.
  • Liderando sob pressão.
  • Mentoria é uma via de mão dupla.
  • Como e quando delegar.

Vimos também o que é cultura empresarial, um conjunto de maneiras de resolver problemas e reagir a situação compartilhadas por um grupo de pessoas trabalha junto. Por fim, vimos quatro valores que são o núcleo de todo time de desenvolvimento de produtos digitais. São eles que compõem a cultura de produto, que nada mais é do que o conjunto de comportamentos dos times de desenvolvimento de produtos digitais que produzem os melhores resultados:

  • Lançamento antecipado e frequente.
  • Foco no problema.
  • Entrega de resultado.
  • Mentalidade de ecossistema.

Pessoas: prioridade nº 1, sempre

  • As pessoas são, e devem ser sempre, a prioridade número 1 de qualquer empresa. Gastamos dinheiro e energia para adquirir e reter as melhores pessoas. Ter as pessoas como a prioridade número 1 é a chave para atingir qualquer outro objetivo. Isso não significa ser “bonzinho”, dando tudo o que elas querem, e sim que devemos ser capazes de equilibrar os desafios que damos às pessoas para que possam melhorar continuamente.
  • A pessoas maçãs podres podem drenar e prejudicar seu time. Você deve ajudar essas pessoas a se encaixarem em seu time e, se isso não for possível, você deverá tomar a decisão mais difícil: tirá-la do time.

Liderar é como ser um médico

  • Da próxima vez que você estiver em uma equipe, seja como parte dela ou desempenhando o papel de liderar a equipe, pense no papel de liderança semelhante ao do médico e no trabalho em equipe semelhante ao processo de cura realizado pelo corpo. Ajuda a entender as funções e responsabilidades do líder e das pessoas do time.

Liderando sob pressão

  • Não existe um ambiente de trabalho sem pressão. Pessoas e equipes precisam da pressão externa (a meta, a data prevista, a falta de recursos) e também de dentro (motivação, drive, força interior) para existir e fazer as coisas, como um balão.
  • A pressão interna e a pressão externa precisam ser balanceadas com alguma tendência a ter um pouco mais de pressão do lado de fora para ter melhoria contínua.
  • Sob pressão, uma pessoa e uma equipe explodem ou ficam mais fortes. É papel do líder ajudar a pessoa ou a equipe a perceber isso e trabalhar em conjunto com eles para apoiar o aumento da pressão interna.

Mentoria é uma via de mão dupla

  • Mentoria é um dos papéis mais importantes de um head de produto. É através da mentoria que um head de produtos ajuda seu time a se desenvolver.
  • Mentoria é uma via de mão dupla. A pessoa no papel de mentora deve estar aberta a novos aprendizados vindos de suas sessões de mentoria com sua mentorada.

Como e quando delegar

  • Delegar é o ato de confiar uma tarefa e/ou uma responsabilidade a alguém. A liderança é um ato contínuo de delegação de tarefas e de responsabilidades.
  • Entre não delegar e delegar existem vários níveis de delegação que são usados de acordo com o contexto, ou seja, do problema a ser resolvido e quem estará trabalhando no problema.
  • O conceito de delegação anda de mãos dados com o conceito de microgestão, estilo de gestão em que o gerente observa ou controla de perto o trabalho de seus subordinados ou funcionários.
  • Existem diferentes maneiras de se fazer as coisas para se atingir o mesmo resultado. Líderes novos costumam achar que só o seu jeito de fazer é o certo.
  • Erros são oportunidades incríveis de aprendizado. Daí a importância em tolerar erros no trabalho.

Cultura e valores

  • Cultura é a forma como um grupo de pessoas reage às situações do dia a dia. É papel do head de produto ajudar no desenho e na promoção da cultura da empresa para garantir um ambiente propício para o desenvolvimento de produtos de sucesso.
  • Tem cinco valores que acredito serem essenciais para ajudar a criar uma cultura que propicie o desenvolvimento de produtos de sucesso. Neste capítulo falei de 3 desses valores: não desperdice tempo buscando culpados, foque nos aprendizados. Não compare situações de trabalho com guerra, ninguém quer matar ninguém. Lucro e receita são consequência, não deve ser o foco principal.

Transparência, a fundação de um time de alta performance

  • Toda líder, para ajudar seu time a desempenhar melhor, precisa explicar o contexto e remover impedimentos.
  • Para podermos explicar o contexto, é fundamental sermos transparentes, explicar os números da empresa, explicar as motivações por trás de cada decisão, incluir o time nas decisões.
  • A transparência na gestão das empresas parece algo moderno, mas existe há algumas décadas. Dois exemplos interessantes vêm da década de 1980. Um em uma empresa americana chamada Springfield ReManufacturing Corp (SRC), que criou o conceito de gestão do livro aberto. O outro em uma empresa brasileira chamada Semco, do Ricardo Semler, onde Clóvis Bojikian, seu diretor de RH, implementou a gestão participativa. Ambas são da década de 1980 e são indústrias, ou seja, a vanguarda da gestão participativa.
  • Com transparência, é possível dar às pessoas as informações necessárias para que elas entendam o contexto e motivação do trabalho que estão fazendo e consigam tomar melhores decisões sobre esse trabalho.

Diversidade, a base dos melhores produtos

  • Existem duas razões principais que motivam a construção de times de desenvolvimento de produtos digitais diversos. A primeira é que a diversidade traz novos pontos de vista. A segunda razão é que da mesma forma como o grupo de clientes que usa seu produto é diversa, sua equipe de desenvolvimento de produto também deve ser.
  • As pessoas têm diferentes origens, diferentes histórias, diferentes conhecimentos. Devemos reconhecer e respeitar essas diferenças e entender que às vezes não chegaremos a um acordo, mas tudo bem, desde que respeitemos a perspectiva uns dos outros.
  • Está em nossas mãos tornar o ambiente de desenvolvimento de produtos digitais mais inclusivo. O caminho para isso acontecer é trazer o tema à tona e torná-lo parte das conversas.

Lançamento antecipado e frequente

  • Existe um conjunto de quatro valores que são de fato o núcleo de todo time de desenvolvimento de produtos digitais. São os valores que compõem a cultura de produto, que nada mais é do que o conjunto de comportamentos dos times de desenvolvimento de produtos digitais que produzem os melhores resultados.
  • As três razões para você lançar logo seu produto são que (i) esse é o momento da verdade, (ii) assim você evita o excesso de funcionalidades e (iii) acelera o retorno do investimento.
  • Se você não tem vergonha da sua primeira versão, demorou demais para lançar.
  • Minimal Marketable Feature ou MMF é um conceito anterior ao de MVP, que traz a vantagem de trazer essa mentalidade de implementar o mínimo necessário para cada funcionalidade do produto.

Foco no problema

  • Um passo muito importante para criar uma boa solução é a compreensão do problema. Quando ouvimos sobre um problema, imediatamente começamos a pensar nas soluções. No entanto, quanto mais tempo gastamos aprendendo sobre o problema, mais fácil será encontrar uma solução e há boas chances de que essa solução seja mais simples e rápida de implementar do que a primeira solução que pensamos.
  • Se você tiver uma lista de projetos para fazer, crie duas colunas a mais nessa lista, uma para problemas a serem resolvidos em cada projeto e outra para quem os problemas serão resolvidos. Isso ajudará você a se concentrar nos problemas a serem resolvidos, e não nos projetos, que são a solução.
  • Equipes de implementação de solução são equipes trabalham na implementação de uma solução concebida por outra pessoa. Equipes de solução de problemas são equipes trabalham para compreender profundamente as causas do problema, o contexto e a motivação que as pessoas têm para resolvê-lo. Ao fazer isso, eles são capazes de implementar a melhor solução para o problema em questão.
  • A armadilha top-down é a percepção do processo de tomada de decisão sendo feito pelos líderes da empresa, sem oportunidade de participação do resto dos funcionários. Essa percepção é exacerbada quando uma empresa enfrenta uma pressão crescente, como a crise do COVID-19.
  • As pessoas são orientadas para a solução e, quanto maior a pressão, mais rápido as pessoas desejam que as soluções sejam implementadas.
  • Para ajudar a lidar com essa situação, use a empatia para entender o ponto de vista do solicitante de implementação da solução e pergunte a ele por que é necessário implementar a solução solicitada.
  • Os heads de produto têm a função e a responsabilidade de promover essas mudanças de comportamento para ajudar a construir um processo de tomada de decisão mais colaborativo.

Entrega de resultado

  • Outro valor fundamental para qualquer time de desenvolvimento de produto é o foco na entrega de resultado.
  • É preciso tomar cuidado na definição de resultado. Entregar uma funcionalidade não é um resultado. Toda funcionalidade é um meio que serve para um fim, o atingimento de um objetivo de negócio.
  • Mesmo empresas 100% digitais, cujo produto digital e a tecnologia são o core da empresa, têm por foco objetivos de negócio.

Mentalidade de ecossistema

  • Mentalidade de ecossistema significa tomar decisões que criam valor para todos os atores de uma plataforma.
  • No Gympass, durante a crise do COVID-19, depois de colocarmos o Gympass Wellness para todos os seus clientes e os funcionários desses clientes, uma parte importante do ecossistema ainda estava sofrendo, as academias. Foi a mentalidade de ecossistema que guiou o Gympass para criar o produto de Live Classes, que permitiu que as academias continuassem operando mesmo estando de portas fechadas.

FERRAMENTAS

Aqui vimos as ferramentas que tenho usado nos meus quase 30 anos de carreira em liderança de desenvolvimento de produtos e que tenho compartilhado com outros líderes para que eles possam usar com suas equipes. As ferramentas de que falarei incluem visão, estratégia, objetivos, estrutura de equipe, métricas, relacionamentos e cerimônias.

Visão, estratégia, objetivos e estrutura de time

  • Visão, estratégia, objetivos e estrutura de time são, além de conceitos muito importantes, ferramentas essenciais para qualquer head de produto.
  • Para visão e estratégia, uma apresentação com alguns slides é suficiente. Para OKR e estrutura de time, planilhas dão conta do recado.
  • Mais importante do que os softwares que você utiliza para documentar Visão, estratégia, objetivos e estrutura de time é o que você faz com essas ferramentas. Planilha de OKRs eu uso no mínimo toda semana. Visão e estratégia, sempre que tenho oportunidade, eu falo sobre esses temas. Estrutura de time, sempre que vamos falar de contratações ou mudanças no time, utilizo a planilha de estrutura de time.

Medindo e gerenciando a produtividade

  • Não existe bala de prata para aumentar a produtividade de um time de desenvolvimento de produto. Contudo, existem sim duas ferramentas essenciais para ajudar nesse objetivo.
  • A primeira ferramenta é medição. Não há como melhorar algo que não se mede. O que é velocidade de desenvolvimento de produto? É importante haver uma definição clara dessa métrica e consequente mensuração.
  • A segunda ferramenta é trazer o tema produtividade para o centro da discussão. Todos do time de desenvolvimento de produto são responsáveis pela produtividade do time. Por isso, ao trazer o tema para o centro da discussão, todos poderão colaborar para melhorar a produtividade.

Medindo e gerenciando a qualidade

  • Questionar se o desenvolvimento de produto deve ou não ter uma equipe de QA dedicada não é a pergunta certa.
  • O problema que você está tentando resolver é como melhorar a qualidade do seu produto.
  • Uma boa métrica proxy de qualidade são os bugs. Inventário de bugs, novos bugs por semana e SLA de resolução de bugs.
  • Uma equipe de desenvolvimento de produto deve ter todos os seus membros seguindo essas métricas e agindo para melhorá-las.
  • Gerir bugs não é suficiente para gerir a qualidade do produto digital. Desempenho, escalabilidade, operabilidade, monitorabilidade são alguns exemplos de requisitos não funcionais que impactam diretamente na qualidade do produto digital.
  • A qualidade está em primeiro plano para fornecer uma boa experiência do usuário. Além disso, é fundamental para aumentar a velocidade de sua equipe de desenvolvimento de produto. Quanto menos bugs uma equipe tiver para corrigir, mais tempo ela terá para se concentrar em coisas novas.
  • Organizações de alta velocidade são capazes de aprender muito rápido, especialmente com suas falhas, e de absorver esse aprendizado como parte integrante do conhecimento da organização.

Métricas

  • As métricas de um time de desenvolvimento de produto podem ser classificadas em 3 grandes categorias: internas, de usuário e de negócio.
  • Métricas internas mostram como o time está de saúde: as métricas de usuário mostram a relação de seu usuário com o produto e as métricas de negócio são aquelas que mostram se o produto está, de fato, entregando valor para o negócio.
  • Métricas devem ser acompanhadas com a maior frequência possível, no mínimo semanalmente. Mesmo se for uma métrica mensal, procure acompanhar as parciais semanais, ou mesmo diárias, dessa métrica, para dar maior oportunidade de agir mais cedo quando houver uma variação de curso.

Relacionamentos

  • O gerenciamento de expectativas é algo entre 50 a 80% do tempo de um head de produto.
  • RASCI é uma ferramenta muito útil para ajudar a definir e entender os papéis e responsabilidades de cada pessoa e cada função.
  • A matriz de poder-interesse, juntamente com RASCI, é uma ótima ferramenta para ajudá-lo a entender melhor e interagir com seus stakeholders.
  • Mas não se esqueça, a principal ferramenta que um head de produto precisa para entender melhor e, consequentemente, ter interações aprimoradas e frutíferas com seus stakeholders é a empatia.

Contratar as pessoas certas

  • O trabalho de contratação de pessoas deve ser feito em conjunto com o RH. É um trabalho em equipe.
  • As fases da contratação são definir o perfil, atrair candidatos, entrevistar, escolher e fazer a proposta, onboarding.
  • O ciclo de vida de uma pessoa no seu time não termina no onboarding. É importante constantemente dar e receber feedback dela, para garantir que o relacionamento funcione bem tanto para o time quanto para a pessoa nova no time.
  • Por fim, a última fase do ciclo de vida da pessoa no time é quando a pessoa sai do time. É preciso entender os motivos que levou a essa decisão para entender como esses temas podem ser trabalhados no futuro.

Feedback e avaliação de desempenho

  • Seis aspectos essenciais para um bom feedback são: checar se o feedback é necessário, dá-lo na hora em que acontece, ser objetivo, ser transparente, ter empatia e dar o feedback em privado.
  • As sete principais características de um bom gestor de produto são empatia, comunicação, capacidade de gestão do tempo, conhecimento de novas tecnologias, habilidades empresariais, curiosidade aguçada e conhecimento sobre o tema do produto.
  • Se o produto não for um produto técnico, não é necessário saber programar. Contudo, ter alguma noção de programação pode ser útil para entender como seu produto funciona. Saber SQL também é útil, pois ajudará a gestora de produtos a entender melhor as métricas de seu produto.
  • Processos formais de avaliação de desempenho têm sido vistos cada vez mais pelas empresas como algo que não traz tantos benefícios como esperado. Várias empresas estão substituindo esse processo por conversas mais frequentes entre líder e liderado sobre carreira, performance, potencial e valores.
  • Retrospectiva semestral é uma boa forma de ter uma conversa estruturada com o liderado sobre os resultados atingidos e como eles foram atingidos, e sobre os desafios que estão por vir. Essa retrospectiva deve ser construída em conjunto com o liderado. Caso haja um processo formal de avaliação de desempenho na empresa onde você estiver trabalhando, use o processo de retrospectiva para criar a avaliação de desempenho.
  • Sobre promoções e aumentos, há dois aspectos a considerar, quando e como. Recomendo separar as conversas de aumento e promoção das conversas sobre feedback para manter o foco total no tema de cada uma dessas conversas. Recomendo também promover a pessoa quando ela apresenta o potencial de desenvolver as habilidades necessárias para ocupar o próximo nível de carreira, e não esperar que ela já demonstre as habilidades necessárias para esse próximo nível de carreira, pois isso vai motivar mais a pessoa.

Cerimônias

  • Essas cerimônias com diferentes stakeholders têm por objetivo planejamento, alinhamento e gestão de expectativas. Saliento que essa lista não é definitiva, ou seja, a depender da empresa e do contexto, pode ser interessante criar outras e algumas das cerimônias listadas aqui podem não ser necessárias.
  • Reuniões de 1:1 são importantes para manter o alinhamento e a comunicação com seus liderados, seus líderes, outras pessoas do time e pessoas das outras áreas. 1:1 com seus liderados e seu líder devem ser semanais e ter reservada uma hora de conversa. Já os 1:1 com outras pessoas podem ter periodicidade e duração menor, ou mesmo ser eventuais. O tema dessas reuniões é livre, e não deve se ater apenas à prestação de contas. Envolvem questões pessoais, o dia a dia, preocupações, feedbacks, retrospectivas.
  • Reuniões do time de liderança são as reuniões que o head de produto faz com os seus liderados diretos. Além dos liderados diretos é importante ter a pessoa de RH que está dedicada a ajudar o seu time. O tema é livre, mas é importante discutir periodicamente sobre os OKRs e sobre as dinâmicas de comunicação com o restante da empresa. Devem ser no mínimo semanais. Podem acontecer mais de uma vez por semana, até mesmo diariamente caso haja muitos temas a serem discutidos.
  • All-Hands são reuniões com todo o time de desenvolvimento de produto onde são comemoradas as conquistadas e compartilhadas as lições aprendidas. A recomendação é que sejam mensais.
  • Product Council são as reuniões onde é apresentado o planejamento do próximo trimestre para a liderança sênior da empresa, preferencialmente no formato de OKRs. Costumam ser trimestrais.
  • Product Updates servem para tirar o efeito caixa preta dos times de produto e tecnologia. É quando os líderes desse time apresentam o que foi feito no último mês, o que será feito no próximo mês, como essas entregas impactam nos resultados da empresa, demonstrações das funcionalidades e abertura para qualquer pessoa possa perguntar o que quiser para o time.
  • Reunião de estrutura de time serve para discutir junto com a liderança do time de desenvolvimento de produto como o time será organizado, como usaremos o orçamento de contratação e qual a prioridade de contratação.

Liderança de produtos digitais

Este artigo faz parte 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: