About Joca

I've been helping companies succeed in the digital era by guiding them on how to create and manage successful digital products that connect their strategic objectives with the problems and needs of their customers.

What is digital product management?

We already have the definition of digital products, we saw many examples and many ways of categorizing these products. We also understood the difference between a product and a platform. Now we are going to define the role of digital product management:

Digital product management is the function responsible for all aspects of a software product, during the whole lifecycle of this product, from its conception to the end of its lifetime.

It is the function responsible for making the connection between the company strategy and the problems and needs of clients using the digital product. This one must be, at the same time, helping the company to accomplish its strategic goals, while solving the problems and needs of clients.

This definition clears up three important points:

  • The first one is the responsibility for all the aspects of a digital product. That means that product managers have to worry with the user experience and with the engineering of their product including the architecture, infrastructure and operation. Product managers also have to worry with legal and financial matters, client support, and product marketing and sales.

Worrying about does not mean doing all those things. In your company, there are people and departments dedicated to take care of these themes. Therefore, worrying means understanding these aspects, what are the relations with the product, and how the product impacts in each one of these areas. This will be the subject on Part III – Relation with other areas, in which I’ll approach the connection between software product management and other areas of the company.

  • The second point is that the responsibility takes place during the whole lifecycle of the product. As we will see on Part II – Lifecycle of a software product, the lifecycle of a product has different stages and each one of them requires special attention.
  • The third point is the connection that product management must build between the company’s strategic goals and the problems and needs of clients, which is what we will see next.

Aligning company strategy with customer needs

The very important third point of defining software product management is the responsibility for guaranteeing the connection between the company strategy and the problems and needs of clients. At the intersection between the business goals and the solution of problems (and needs) of clients lies the digital product management, as we can see in the picture as follows:

Digital product management

This is the theory, and everything seems simple in theory. However, as we all know, practice and theory can be quite different. The real-life digital product management is better illustrated by the picture:

Real-life digital product management on practice

In this image, we see Louis Cyr, considered the strongest man on Earth in 1890, who lifted 227kg using only 3 fingers and 1,967kg on his back!

It better represents the digital product management role because it is not always simple to conciliate the company’s goals and the solution for a problem or need of a client. A simple example is Facebook that, like any other company, needs the revenue to pay its costs and present some return to its investors. That is Facebook’s business goal. On the other hand, we find Facebook’s users, who access the system for free and are not interested in paying for that access.

Facebook’s product manager had to find a way of generating revenue without charging the users. The solution was to find another type of client, the advertisers, who were willing to pay to display ads for the users.

This image is incomplete…

The first image is incomplete. It talks about the company’s strategic goals and about the problems and needs of clients. However, a product manager cannot look just at these two items. There’s a third and very important item, which is the available technology.

The product manager must know the available technology in order to know if it’s possible to solve the client’s problem or need, attending to the company’s strategic goals. See the picture below:

Complete software product management

The core team for developing software products

The three concerns we’ve approached previously give us some taste of the ingredients to the product’s success. A successful product must be:

  • Desirable: solves problems or fits the needs of clients;
  • Viable: meets the company’s strategic goals; and
  • Feasible: there’s available technology for developing it.

These three requirements define the essential functions for creating a successful product: designer, product manager, and developer. This trio is considered the core team for developing a digital product and must be very much in sync in every stage of its development.

Software product development core team

Viable — what will sustain the business?

Product managers have two main responsibilities: to evaluate the product’s opportunities and to define the products that are going to be built. After evaluating and deciding that the development of the product will pay off, they initiate the phase of discovering exactly how it should be (along with the core team), including the necessary features, the user experience, and the criteria for launching it.

Besides, it is in their hands to determine the business model that is going to be followed, and interacting with practically every other area of the company in order to set up legal matters, accounting, financial, marketing, distribution technicalities, etc.

Desirable — what do people need?

This is where the User Experience (UX) comes in. There are many roles in a UX team, however, the one that works closely with the product manager is the interaction designer. They are responsible for searching for a deep understanding of users, discovering their motivations, behavior, and skills; for helping to define the requirements, thus designing an interface that makes the user interaction with the product as simpler and efficient as possible, while achieving the business goals at the same time.

Feasible — what can we build?

The software engineers or developers are responsible for effectively building the product. Their role is important in the stage of defining the product and clarifying what is possible to be done, the evaluation of costs of different ideas and helping to identify the best feasible solutions. It’s their responsibility to define the most appropriate technology and architecture for developing a quality product.

What is the difference between managing a product and a platform?

Regarding software products, the concern is only with one type of client. In a platform, if it is single-side, besides worrying about understanding one single type of client, it is necessary to understand the relation with him.

But if the platform is multi-sided you should worry about two or more different types of users and the relation between users of the same kind and of different kinds. In other words, the concerns, both from the product manager and from everyone who works in developing the platform, can be more complex than the ones regarding a product with one single kind of client.

A platform strategy must take into account that the client does not perceive value only in the features of the product that are 100% under the company’s control. Aside from the features, the client seeks value in interactions with third parties, and it is the company’s responsibility (the owner of the platform) to manage these relations in order to obtain the best results, both for the participants of the platform and for itself.

New concerns in platform management

Besides all concerns of product management that I’m describing in this book, those who manage platforms must also take into consideration other aspects.

The platform features depend on the participation of users. In English, we use the expression tipping for this concern, i.e., how to attract enough users to a platform so it can be useful for those who participate in it? Some strategies for this are:

  • First user: to get a first user who by himself attracts other ones. This is a tactic used by shopping malls when they sign contracts with department stores that by themselves attract enough consumers. Later, you can offer spots to other stores, that will certainly be more interested in being on the mall.
  • Social: another way of getting users is to engage on social networks and engines. Something like “tell your friends from Facebook”.
  • Leader user: discover what is the user profile that will be strongly attracted by the idea at the point of being the first one to adopt the platform. Bitcoin attracted several people from technology areas initially who fell in love with the idea of a currency not linked to any government, and they defend the idea passionately.

Think about the benefits as a product. The product itself must have enough benefits as a standalone product. Instagram, before the feature of sharing photos, was able to make photos look cool. OpenTable, before the booking feature, was a good ERP (Enterprise Resource Planning) for restaurants.

Consider lowering prices. It is a strategy valid for attracting users, but it is good to remember that it is difficult to raise the price later, especially if you lower it to zero. Sure, you can subsidize it with ads, but you need to know if your users will like those ads and if you are going to get advertisers willing to invest.

There are also features that depend on users’ behavior. In English, the term used for that is coring, i.e. how to guarantee that they are not taking unfair advantage of each other, ensuring that every participant has benefits? Some strategies for taking care of coring:

  • Promote trust: auction and online payment sites usually do this, holding up the buyer’s money until he confirms that he received the product sold to him.
  • Offer quality information: usually, those user-made ratings. The big risk here is to manage false ratings; or a positive evaluation made by the analyzed person or company, and negative ones made by competitors.
  • Restrict the use: turn the subscription and the use more restricted, so that will bring fewer users, but quality ones. That’s what the online dating website eHarmony does. It charges a fairly expensive monthly fee (US$ 50.00) and gives you a very extensive form for you to fill up. In addition, even if its matchmaking algorithm finds several options, it will only present you a limited number in order to ease up the process of choice.

Concluding

It is important to understand if you are working on a product or on a platform because there are some differences in managing each one of them.

A platform needs a strategy for attracting the first users, and this is equally or more important than the features. As software product managers, we tend to get excited with technical features, however, in platforms, the focus is concentrated on users, on their relations, and on how to attract the first users. In addition to that, managing a platform requires control and relation governance inside the platform itself, in order to guarantee that all participants are benefiting from it.

Once we understand what software product management is and what are the differences between managing software and managing platforms, what we need now is to understand what a software product manager is. That’s the subject of our next chapter!

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

O que é Gestão de Produtos de Software?

Já temos a definição de produto de software, vimos vários exemplos e várias formas de classificar esses produtos, e conhecemos a diferença entre produto e plataforma. Agora, vamos definir a função de gestão de produtos de software:

GESTÃO DE PRODUTOS DE SOFTWARE

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

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

Essa definição deixa três pontos bem importantes bem claros:

  • O primeiro é a responsabilidade por todos os aspectos de um produto de software. Isso significa que um gestor de produtos de software deverá se preocupar com a experiência do usuário e com a engenharia de seu produto, incluindo sua arquitetura, infraestrutura e operação. Também deverá se preocupar com questões legais e financeiras, suporte ao cliente, e marketing e venda do produto.

Preocupar-se não significa fazer todas essas coisas. Na sua empresa, existem pessoas e áreas dedicadas a cuidar desses temas. Por isso, preocupar-se significa entender esses aspectos, quais são as suas relações com o produto, e como o produto impacta cada uma dessas áreas. Esse será o tema da Parte III – Relacionamento com as outras áreas, onde falarei sobre a relação entre gestão de produtos de software e as outras áreas da empresa.

  • O segundo ponto é que essa responsabilidade ocorre durante todo o ciclo de vida do produto. Como vamos ver na Parte II – Ciclo de vida de um produto de software, o ciclo de vida de um produto tem diferentes fases, e cada uma delas requer atenção especial.
  • O terceiro ponto é a conexão que a gestão de produtos deve fazer entre os objetivos estratégicos da empresa e os problemas e necessidades dos clientes, que é o que veremos a seguir.

ALINHANDO ESTRATÉGIA DA EMPRESA COM NECESSIDADES DE CLIENTES

O terceiro ponto bem importante da definição de gestão de produtos de software é a responsabilidade por garantir a conexão entre a estratégia da empresa e os problemas e necessidades dos clientes. É na interseção entre os objetivos do negócio e a solução dos problemas ou necessidade dos clientes que se encontra a gestão de produtos de software, como vemos na figura a seguir:

Gestão de produtos de software

Essa é a teoria, e tudo parece simples na teoria. Contudo, como todos nós sabemos, na prática é outra coisa. A gestão de produtos de software na vida real está bem melhor representada pela figura:

Gestão de produtos de software na prática

Nessa imagem, vemos Louis Cyr (http://en.wikipedia.org/wiki/Louis_Cyr) que foi considerado em 1890 o homem mais forte do mundo em sua época por ter levantado 227 kg com apenas 3 dedos e 1.967 kg em suas costas!

Ela representa melhor a função de gerenciamento de produtos digitais, porque nem sempre é simples conciliar os objetivos da empresa e a solução para um problema ou necessidade de um cliente. Um exemplo simples é o Facebook que, como qualquer outra empresa, precisa de receita para pagar seus custos e dar algum retorno aos seus investidores. Esse é o objetivo comercial do Facebook. Por outro lado, encontramos os usuários do Facebook, que acessam o sistema gratuitamente e não têm interesse em pagar por esse acesso.

O gestor de produtos do Facebook tinha então de encontrar uma forma de obter receita, mas sem cobrar dos usuários. A solução foi encontrar um outro tipo de cliente, os anunciantes, dispostos a pagar para exibir anúncios para os usuários do site.

Esta imagem está incompleta…

A primeira imagem está incompleta. Ela fala em objetivos estratégicos da empresa e em problemas e necessidades dos clientes. Contudo, um gestor de produtos não pode olhar apenas para esses dois itens. Há um terceiro item muito importante que é a tecnologia disponível.

O gestor de produtos precisa conhecer a tecnologia disponível para saber se é possível resolver o problema ou a necessidade do cliente, atendendo aos objetivos estratégicos da empresa. Veja a figura a seguir:

Gestão de produtos de software completo

O CORE TEAM DE DESENVOLVIMENTO DE PRODUTOS DE SOFTWARE

As três preocupações vistas anteriormente nos dão a dica do que compõe o sucesso de um produto. Um produto de sucesso deve ser:

  • Desejável: resolve problemas ou necessidades de clientes;
  • Viável: atende aos objetivos estratégicos da empresa; e
  • Possível de ser construído: existe tecnologia disponível para desenvolvê-lo.

Esses três quesitos definem as três funções essenciais para se criar um produto de sucesso: designer de UX (User eXperience, ou Experiência do Usuário), gestão de produtos e desenvolvedor. Esse trio é considerado o core team (time principal) para o desenvolvimento do produto, e deve estar bem alinhado em todas as fases do seu desenvolvimento.

Core team de desenvolvimento de produtos de software

Viável – o que sustentará o negócio?

O gestor de produtos tem duas responsabilidades principais: avaliar as oportunidades do produto e definir o produto que será construído. Depois de avaliado e decidido que vale a pena desenvolver o produto, ele inicia a fase de descobrir exatamente como ele deve ser (junto com o core team), incluindo as funcionalidades necessárias, a experiência do usuário e os critérios para o lançamento. Além disso, está em suas mãos determinar o modelo de negócio que deverá ser seguido, e interagir com praticamente todas as outras áreas da empresa para definir questões jurídicas, contábeis, financeiras, de marketing, de distribuição etc.

Desejável – o que as pessoas precisam?

É aqui que entra a Experiência do Usuário (UX). Há vários papéis em um time de UX, porém, o que trabalha em maior colaboração com o gestor de produtos é o designer de interação. Ele é responsável por buscar um profundo entendimento dos usuários, descobrindo suas motivações, comportamentos e habilidades; ajudar na definição dos requisitos e, assim, desenhar uma interface que torne a interação do usuário com o produto a mais simples e eficiente possível, ao mesmo tempo em que atenda aos objetivos do negócio.

Possibilidade – o que podemos construir?

O Engenheiro ou Desenvolvedor de Software é o responsável por construir o produto efetivamente. Seu papel é importante na fase de descoberta do produto para dizer ao seu gestor e ao designer de UX o que é possível ser feito, avaliar o custo das diferentes ideias propostas e ajudar a identificar as melhores soluções. É sua responsabilidade definir a tecnologia e a arquitetura mais apropriadas para desenvolver um produto de qualidade.

QUAL A DIFERENÇA ENTRE GERENCIAR UM PRODUTO OU UMA PLATAFORMA?

Com produtos de software, a preocupação é apenas com um único tipo de cliente. Em uma plataforma, se ela for single-side, além de se preocupar em entender um único tipo de cliente, é preciso entender como ele se relaciona entre si.

Já se a plataforma for multi-sided, você deve se preocupar com dois ou mais tipos diferentes de usuários, e a relação entre usuários de mesmo tipo e de tipos diferentes. As preocupações, tanto do gestor de produtos como de todas as pessoas que trabalham no desenvolvimento da plataforma, podem ser bem mais complexas do que em um produto com um único tipo de cliente.

Uma estratégia de plataforma deve mudar as prioridades da empresa dona dessa plataforma, uma vez que o cliente não enxerga valor unicamente nas funcionalidades do produto que estão 100% sob controle da empresa. Além das funcionalidades, o cliente busca valor nas interações com terceiros, e é responsabilidade da empresa (dona da plataforma) gerenciar essas relações, para obter os melhores resultados tanto para os participantes da plataforma quanto para si mesma.

Novas preocupações na gestão de plataformas

Quem gerencia plataformas, além de todas as preocupações de gestão de produtos que descrevo aqui no livro, deve também se preocupar com dois novos aspectos:

  • As funcionalidades dependem da participação dos usuários: em inglês, usa-se o termo tipping para essa preocupação, ou seja, como fazer a plataforma ganhar usuários para ela poder ser útil para quem participa dela? Algumas estratégias para fazer isso são:
    • Primeiro usuário: conseguir um primeiro usuário que, por si só, já atrai outros usuários. Essa é uma tática muito usada por shoppings quando fecham com uma loja de departamentos, que já atrai compradores suficientes por si só. Depois, é só falar com outras lojas, que certamente terão mais interesse em estar no shopping.
    • Social: outra forma de conseguir usuários é usar redes e mecanismos sociais para conquistar mais usuários. Algo como “chame seus amigos do Facebook”.
    • Usuário líder: descobrir qual o perfil do usuário que vai ser fortemente atraído pela ideia, ao ponto de ser o primeiro a adotar a plataforma. Bitcoin atraiu inicialmente várias pessoas de tecnologia, que se apaixonaram pela ideia de um dinheiro não atrelado a um governo, e são ferrenhos defensores da ideia.
  • Pense nos benefícios como produto: o próprio produto tem benefícios suficientes por si só. O Instagram, antes da funcionalidade de compartilhar, era capaz de fazer fotos ficarem legais. O OpenTable, antes da funcionalidade de reservas, era um ótimo ERP (Enterprise Resource Planning) para restaurantes.
  • Considere reduzir preços: é uma estratégia válida para atrair usuários, mas vale lembrar de que é difícil aumentar o preço depois, principalmente se você reduzir o preço para zero. Claro, você pode subsidiar com anúncios, mas você precisa saber se seus usuários vão aceitar anúncios e se você vai conseguir anunciantes que queiram pagar.
  • Há também funcionalidades que dependem de os usuários se comportarem bem: em inglês, o termo usado para isso é coring, ou seja, como garantir que os usuários não vão tirar proveito um do outro, assegurando sempre que todos os participantes tenham benefícios? Algumas estratégias para cuidar do coring:
    • Promova confiança: sites de leilão e de pagamento online costumam fazer isso, segurando o dinheiro do comprador até que ele diga que recebeu o produto que lhe foi vendido.
    • Ofereça informação de qualidade: normalmente, aqueles ratings feitos pelos usuários. O grande risco aqui é gerenciar os ratings falsos; positivos feitos pela própria pessoa ou empresa que está sendo analisada, e negativos pelos concorrentes.
    • Restrinja o uso: torne a associação e o uso mais restrito, o que trará sim menos usuários, mas mais usuários de qualidade. É o que fez um site chamado eHarmony, de procura de namorado(a). Ele cobra uma mensalidade razoavelmente cara (U$ 50.00) e tem um questionário bem extenso para ser preenchido. Além disso, mesmo que seu algoritmo de matchmaking encontre várias opções, ele só apresentará um número limitado para facilitar o processo de escolha.

Concluindo

É importante entender se você está trabalhando em um produto ou em uma plataforma, pois existem algumas diferenças em gerenciar cada um deles.

Uma plataforma precisa de uma estratégia para atrair os primeiros usuários, e isso é tão ou mais importante do que as funcionalidades. Como gestores de um produto de software, temos a tendência de ficar animados com funcionalidades técnicas, entretanto, nas plataformas, o foco é ainda maior nos usuários, em suas relações e em como atrair os primeiros usuários. Além disso, gerir uma plataforma requer controle e governança dos relacionamentos dentro da plataforma, para garantir que todos os participantes estejam se beneficiando com ela.

Uma vez que já entendemos o que é a gestão de produtos de software, e quais as diferenças entre gerir um software e gerir uma plataforma, precisamos agora entender o que é um gestor de produtos de software. Esse é o tema do próximo capítulo!

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:

What is a digital product?

Even before defining digital product management, let’s start from the beginning, that is, defining what is software and what is a digital product. Later, I’ll talk about what is digital product management and what are the main characteristics of being a good product manager.

I’ll also approach the differences between a product manager and a product owner, as well as when is the right time for the company to have a product manager. Lastly, I’ll give some leadership tips for product managers who are responsible for leading without being no one’s “boss”.

Are you ready? 🙂

What is a digital product?

Before defining a digital product based on software, I think it would be good for us to define what is software. According to Wikipedia on Software:

Software is any set of instructions that directs a computer processor (hardware) to perform specific operations.

In this Wikipedia article, there’s even a comparison between software and music, in which the author compares musical instruments to hardware, and the music (performed in these instruments) to software. I find this comparison very interesting.

Great, we already have a definition of software but what is a digital product?

You have certainly used some digital products; after all, the internet is made of them. Google, Facebook, and Twitter are good examples of what you’ve used or maybe use on a daily basis. When you shop on Amazon or on eBay, you are using a software product as well. The internet banking system from your bank can also be considered one, such as Netflix, that you can access from your computer, smartphone, tablet, or even directly from your TV.

The smartphone operational systems iOS and Android are software products. There are also the offline software products: the best known are the Microsoft Office, AutoCAD, SAP, and others; the least known, the embedded software inside hardware that is not computers, nor tablets, nor smartphones, but printers, TVs, videogame consoles, voting machine, network equipment such as routers, switches, hubs, and firewalls, etc.

A digital product is any software that has users.

So, can any software can be considered a digital product? No, because there is software that doesn’t have any users. They are the software that interfaces with other ones. Some examples are:

  • Hardware drivers that translate the information between the device and the applications or operational system.
  • Firmware, which is the set of operational instructions programmed directly into the hardware of an electronic equipment.
  • Compatibility layer, that allows software to run in an environment in which it was not originally programmed to run, such as a host system.

However, even this kind of software benefits from the concepts and practices of digital product management that I’ll approach in this book.

Types of digital products

Digital products can be categorized in different ways, depending on how we see them. We can look, as described previously, to the way that the product is delivered to users (online, offline, embedded), or according to what it does: e-mail, e-commerce, payment, e-mail marketing, content management, education, communication, collaboration, reports, entertaining, operational system, ERP, CRM, etc.

Another way — my favorite, because puts the user in the center — is to look and categorize products according to for whom it solves the problem. From this point of view, we can have three types of software products:

  • For end customers: in this type of product, a problem is solved for end customers who are willing to pay in order to use the software. Some examples are Netflix, LinkedIn and online games. There are also software products for end customers who pay indirectly, i.e., customers pay for another service and the software product is only a small part of this service. Some examples are internet banking, school or college intranets, access to lab exams and embedded software in general. E-commerce websites also belong to this category, since their use is free and the fee is paid by the products you buy and are delivered to you.
  • For companies: this type of product solves companies’ problems, who are more willing to pay for a software than the end customer. Some examples are Locaweb, Google AdWords, SAP, AutoCAD and Microsoft Office.
  • Mixed: in this case, the product solves the problem both for end customers and companies. Usually, this type of product doesn’t have any cost for the end customer; companies pay the bill. The most common model for revenue generation in this type of product is advertising, paid for the company when the final customer sees it, clicks on it or buys something because of it. A great example is Google Search, which is a software product for end customers, and Google AdWords, a software product for companies.

Note that, while describing each type, I had the concern of getting clear who’s paying the bill. This is very important because every software product has costs. Even though the costs might be hidden, they do exist; ergo, every software product needs to generate income in some way.

Even though I prefer to categorize software products while understanding to whom it solves the problem, there are other ways of classifying them. For example, Netflix is a software product for the final user, but also an online software product for entertainment.

These categorizations have a direct impact on the daily work of the product manager, i.e., different types of products require different types of product management skills. Managing an ERP is different from managing an e-mail marketing product. Managing an online product is different from managing a mobile app product. Managing a consumer product is different from managing a product for companies.

Digital or traditional?

Most recently I realized another way to categorize not only the software product but also the company that owns the software product, and this categorization has a HUGE impact not only on how a product manager manages her product but also on the role of the product manager in the organization that owns the product.

Digital companies

We all know digital companies. Google with its main product, Google Search and GMail. Amazon Web Services. Facebook. Instagram. WhasApp. SAP. Salesforce. Zendesk. The companies I worked for (Locaweb and Conta Azul). All of these companies sell their software products to their customers. The product is the core of the company. If there’s no software product, there’s no company. Can you imagine Google without Google Search software? Or Instagram without the Instagram app? Or Zendesk without Zendesk software?

In these companies, product management is the core of the company. Product management is responsible for defining a good portion – if not all – of the vision and the strategy of the company. The role of the product manager in this company is central.

Traditional companies

In the other end of the spectrum, there are what we can call the traditional companies. These companies sell products and services that are not software. However, all of them are in a way or another passing through some sort of digital transformation, i.e., learning how to use digital technology to improve their business. Examples of improvements that can result from the use of digital technologies are:

  • enhanced customer relationship.
  • data gathering and insights.
  • innovation through rapid experimentation.
  • increased process speed and quality through automation.

I’ll give some known Brazilian examples. Itau, one of the biggest Brazilian banks founded in 1924, is investing a lot to become digital, with internet banking and its app. From time to time they launch TV campaigns to show this transformation. Itau is 91 years old. Magazine Luiza, a physical retail chain founded in 1957, has also been investing a lot in its digital presence. They are well known in Brazil for their online presence and their app.

Other good examples of traditional companies investing in digital are airlines and hotels. They have websites and apps so customers can buy tickets, make reservations, interact with their customers.

In traditional companies, their products or services exist, and probably existed for a long time without digital technology. Executives and shareholders are beginning to understand how digital technologies can impact their businesses and are investing in digital transformation. In these companies, software product management is an enabler, but it is not the core. Normally it is part of a team named “the digital team”. Product managers will have to earn their space, showing how technology can impact the business.

The third type of company: born-digital traditional companies

These types of companies have traditional products or services that can exist without technology. However, as they have included technology since their beginning as a strategic capability, they look like digital companies.

Everyone considers them as tech companies and, in a sense, they are. Technology is at the core of their strategy. On the other hand, when we take a closer look, their product is not technology. Their product is enabled and potentialized by digital technology. Amazon’s products are goods (books, computers, cell phones, etc.). Netflix and YouTube’s product is video content. Spotify’s product is audio content. Airbnb is an advertisement business that generates leads to the advertised houses being offered for rent. Google Adwords is also an advertisement business that generates leads to whatever product or service is advertised. Nubank, a Brazilian digital bank, offers credit card and bank account services like any bank. Uber and Lyft main service is transportation. Rappi, a Colombian delivery service, and iFood and GrubHub, food delivery services, are what I just wrote, delivery services. And Gympass offers access to more than 50,000 gyms and studios around the world.

Examples of born-digital traditional companies

Their products are not technology. Their products are not software. Digital technology and software enable and potentialize their products. For this reason, product management is very important but is not central to the definition of the company vision and strategy. Product managers will have a very important role in defining and executing the company vision and strategy, but they will not have a central role.

Product or platform?

More and more we see software products that can be categorized as platforms. There are many examples from big tech companies such as:

  • Google, which with two products (Search and AdWords) created a platform connecting people who search information on internet to people who want to advertise things on internet.
  • Facebook, that started as a platform in which friends could find each other and exchange information, and then became a platform in which advertisers can talk to people through ads and fan pages.
  • LinkedIn, a platform for professionals, companies and, most recently, advertisers.
  • Apple, that connect software developers with iPhone, iPad and Macs with their AppStore. Another Apple platform is iTunes, connecting media producers with people interested in music, films, series, and books.
  • Amazon Kindle, a platform that allows publishing houses or authors to publish books for people interested in these contents.

By the way, some of those companies have more than one single platform such as Google, Apple, and Amazon.

Besides those big technology companies, there are also more recent examples:

  • Uber, connecting drivers to people who need transportation.
  • Airbnb, that connects owners of properties for short-period rental to people who want to rent properties in such conditions.
  • Bitcoin, a digital asset and payment system. The more users it has and more companies accept Bitcoin as payment, the better.

There are also examples of platforms that are not necessarily based in technology, like shopping malls, which put stores, restaurants and movie theatres next to people who want to buy, eat and have fun.

What are platforms?

Platforms are systems that get more valuable as more people use them.

In other words, they are systems strongly based on the concept of the network effect. A network effect is an effect by which a given software is more valuable when more users use the software.

Platform

There are two types of platforms:

  • Single-side platforms: are those that, the more users they get, the better. Using an old example, the FAX machine. It was not worth having one if only one person would use it; the more people using it, the better. The same is valid for social network (Facebook, Twitter, etc.).
  • Cross-side or multi-side platforms: those in which there are two or more different groups of people that use the platform in distinct ways and that benefit from this different way that each group uses it. This type can be divided in three categories:

Technologic platform: in which the platform is the operating system and, on one side we have the user and, on the other, we have operational system developers: Linux, Windows, and Android.

Exchange platform: it gathers buyers and sellers: MercadoLivre, Uber, and Airbnb.

Content platform: the content is the focus, and monetization usually takes place through ads (Google, Facebook, and news portals).

The following is an example of a technologic platform with 5 sides:

Android operation system seen as a 5-side platforma

It is important not to confuse the concept of platform in the product context with the concept of technical or computer platform. A computer platform is any computer environment where software applications are going to run at. In the product context, as we defined previously, we name it as a product platform when there are gains to users the more users are using the product.

In a 2019 book called The Business of Platforms: Strategy in the Age of Digital Competition, Innovation, and Power (https://www.amazon.com/Business-Platforms-Strategy-Competition-Innovation/dp/0062896326), the authors categorize platforms into either transaction platforms where transactions happen (marketplaces, ad networks, streaming, access to networks of houses, riders, gyms, etc.) and innovation platforms where new value is built on top of the platform (operating systems, app stores, AWS, etc.).

One important aspect mentioned in the book is that transaction platforms are somewhat easy to be copied and replaced, while innovation platforms are a bit harder to be copied and replaced due to all the technology investment that participants of the platform do to be part of the platform. Many transaction platforms evolve to become hybrid platforms, i.e., incorporate innovation characteristics to enable their users to build new value on top of the existing platforms.

In this chapter, we saw the definitions of software, digital product, and platform, let’s now uncover what is software product management.

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

O que é um produto de software?

Este é o primeiro capítulo da sessão Definições e requisitos. Antes mesmo de definir gestão de produtos de software, vamos começar do começo, ou seja, definindo o que é software e o que é um produto de software. Em seguida, falarei sobre o que é gestão de produtos de software e quais são as principais características para ser um bom gestor de produtos.

Abordarei também as diferenças entre gestor de produtos e product owner, e quando é o momento certo para uma empresa ter um gestor. Por fim, darei algumas dicas de liderança para gestores de produtos que têm responsabilidade de liderar sem ser “chefes” de ninguém.

Preparado? 🙂

O QUE É UM PRODUTO DE SOFTWARE?

Antes mesmo de definir produto de software, acho que seria bom definirmos o que é software. De acordo com a Wikipédia (https://en.wikipedia.org/wiki/Software):

SOFTWARE

Software é qualquer conjunto de instruções que direciona o processador de um computador (o hardware) a executar operações específicas.

Ótimo, já temos então uma definição de software, mas o que é então um produto de software?

Nesse artigo da Wikipédia, existe até uma comparação do software com a música, em que os instrumentos musicais estão para o hardware como a música produzida nesses instrumentos está para o software. Achei essa comparação interessante.

Você certamente já usou algum produto de software, afinal, a internet é feita de produtos de software. Google, Facebook e Twitter são bons exemplos que você certamente já utilizou, e talvez use diariamente. Quando você faz compras na Amazon ou no Submarino, também está usando um produto de software. O sistema de internet banking do seu banco também pode ser considerado um, assim como a Netflix, que você pode acessar do computador, do smartphone, do tablet ou mesmo direto de sua TV.

O iOS e o Android, sistemas operacionais de smartphones, são produtos de software. Existem também os produtos de software não online: os mais conhecidos, como o Office, Autocad, SAP e outros; e os menos conhecidos, aqueles softwares embarcados, que vêm dentro de hardwares que não são nem computadores, nem tablets, nem smartphones, mas sim dentro da impressora, da TV, de consoles de videogame, da urna eletrônica, de equipamentos de rede como roteadores, switches, hubs e firewalls etc.

PRODUTO DE SOFTWARE

Um produto de software é qualquer software que tenha usuários.

Então, todo software pode ser considerado um produto de software? Não, pois existem softwares que não têm usuários. São os softwares que fazem interface com outros softwares. Alguns exemplos são:

  • Drivers de dispositivos de hardware que fazem a tradução entre o dispositivo e as aplicações ou o sistema operacional.
  • Firmware, que é aquele conjunto de instruções operacionais programadas diretamente no hardware de um equipamento eletrônico.
  • Camada de compatibilidade, que permite softwares rodarem em um ambiente no qual não foram originalmente programados para rodar.

Contudo, mesmo esse tipo de software se beneficiaria dos conceitos e das práticas da gestão de produtos de software que abordarei neste livro.

TIPOS DE PRODUTOS DE SOFTWARE

Podem-se classificar os produtos de software de diferentes formas, dependendo de como os enxergamos. Podemos olhar, como descrito anteriormente, para a forma como o produto é entregue aos usuários (como online, não online e embarcado), ou de acordo com o que ele faz: e-mail, comércio eletrônico, pagamento, e-mail marketing, gestão de conteúdo, educação, comunicação, colaboração, relatório, entretenimento, sistema operacional, ERP, CRM etc.

Outra forma – que é a que prefiro, pois coloca o usuário no centro – é olhar e classificar produtos entendendo para quem o produto resolve o problema. Deste ponto de vista, podemos ter três tipos de produto de software:

  • Para o consumidor final: nesse tipo de produto, resolve-se um problema para o consumidor final que está disposto a pagar uma taxa para usar os serviços. Alguns exemplos são Netflix, LinkedIn e jogos. Pode-se também pensar em produtos web para consumidores finais que paguem a taxa pelo uso de forma indireta, ou seja, a taxa paga é por um serviço maior e o produto web está embutido nesse serviço. Alguns exemplos são internet banking, intranet de colégio ou faculdade, acesso a resultado de exames laboratoriais e softwares embarcados de forma geral. Os sites de comércio eletrônico são também dessa categoria, pois o uso do site é gratuito e a taxa paga é pelos produtos comprados no site que são entregues para o usuário.
  • Para as empresas: esse tipo de produto resolve o problema de empresas, que normalmente têm mais disposição de pagar que o consumidor final. Alguns exemplos são os produtos da Locaweb, Google AdWords, SAP, AutoCAD e Microsoft Office.
  • Mistos: nesse caso, o produto resolve tanto um problema para o consumidor final quanto para as empresas. Normalmente, esse tipo de produto não tem nenhum custo para o consumidor final; quem paga a conta são as empresas. O modelo mais comum de geração de receita nesse tipo de produto é o anúncio, pago pela empresa quando o consumidor final vê o anúncio, clica nele ou compra algo a partir dele. Alguns exemplos são Buscapé, Mercado Livre, Google Search + Google AdWords e UOL Conteúdo + anúncios.

Note que, na descrição de cada um desses tipos, tive a preocupação de deixar claro quem paga a conta. Isso é muito importante, pois todo produto de software tem custos. Por mais acessíveis que sejam esses custos, eles existem; logo, todo produto de software precisa gerar receita de alguma forma.

Mesmo eu preferindo a classificação dos produtos de software entendendo para quem o produto resolve o problema, as outras formas de se classificar também são válidas, e não são excludentes. Por exemplo, a Netflix é um produto de software para o usuário final, mas também é um produto de software online de entretenimento.

Essas categorizações têm um impacto direto no trabalho diário do gestor de produtos, ou seja, diferentes tipos de produtos requerem diferentes tipos de habilidades de gestão de produtos. Gerenciar um ERP é diferente de gerenciar um produto de marketing por e-mail. Gerenciar um produto online é diferente de gerenciar um produto de aplicativo móvel. Gerenciar um produto de consumo é diferente de gerenciar um produto para empresas.

DIGITAL OU TRADICIONAL?

Recentemente, percebi outra maneira de categorizar não apenas o produto de software, mas também a empresa proprietária do produto de software, e essa categorização tem um ENORME impacto não apenas na maneira como um gestor de produtos gerencia seu produto, mas também no papel do gestor de produto na organização que possui o produto.

Empresas digitais

Todos conhecemos empresas digitais. Google com seus principais produtos, Google Search e GMail. Amazon Web Services. Facebook. Instagram. WhatsApp. SAP. Salesforce. Zendesk. As empresas em que trabalhei (Locaweb e Conta Azul). Todas essas empresas vendem seus produtos de software para seus clientes. O produto é o núcleo da empresa. Se não houver produto de software, não há empresa. Você consegue imaginar o Google sem o software de pesquisa do Google? Ou o Instagram sem o aplicativo Instagram? Ou o Zendesk sem o software do Zendesk?

Nessas empresas, a gestão de produtos é o núcleo da empresa. A gestão de produtos é responsável por definir uma boa parte – se não toda – da visão e da estratégia da empresa. O papel do gestor de produtos nesta empresa é principal.

Empresas tradicionais

Na outra ponta do espectro, há o que podemos chamar de empresas tradicionais. Essas empresas vendem produtos e serviços que não são software. No entanto, todas elas estão, de uma forma ou de outra, passando por algum tipo de transformação digital, ou seja, aprendendo a usar a tecnologia digital para melhorar seus negócios. Estes são alguns exemplos de melhorias que podem resultar do uso de tecnologias digitais:

  • relacionamento aprimorado com o cliente.
  • coleta de dados e visões.
  • inovação através de experimentação rápida.
  • maior velocidade e qualidade do processo através da automação.

Vou citar alguns exemplos brasileiros conhecidos. O Itaú, um dos maiores bancos brasileiros, fundado em 1924, está investindo muito para se tornar digital, com o Internet Banking e seu aplicativo. De tempos em tempos, eles lançam campanhas de TV para mostrar essa transformação. O Itaú tem 91 anos. A Magazine Luiza, uma rede de varejo física fundada em 1957, também investe muito em sua presença digital. Eles são bem conhecidos no Brasil por sua presença online e seu aplicativo.

Outros bons exemplos de empresas tradicionais que investem em presença digital são companhias aéreas e hotéis. Eles têm sites e aplicativos para que os clientes possam comprar passagens, fazer reservas e interagir com seus clientes.

Nas empresas tradicionais, seus produtos ou serviços existem e provavelmente existiram por muito tempo sem a tecnologia digital. Executivos e acionistas estão começando a entender como as tecnologias digitais podem impactar seus negócios, e estão investindo na transformação digital. Nessas empresas, a gestão de produtos de software é um facilitador, mas não é o núcleo. Normalmente, faz parte de uma equipe chamada “a equipe digital”. Os gestores de produto terão que ganhar seus espaços, mostrando como a tecnologia pode impactar os negócios.

O terceiro tipo de empresa: empresas tradicionais nativas digitais

Esses tipos de empresas possuem produtos ou serviços tradicionais que podem existir sem tecnologia. Entretanto, como elas incluem a tecnologia desde o início como uma capacidade estratégica, elas são empresas digitais.

Elas são consideradas empresas de tecnologia e, de certa forma, são. A tecnologia está no centro de sua estratégia. Por outro lado, quando olhamos mais de perto, o produto delas não é tecnologia. Seus produtos são ativados e potencializados pela tecnologia digital. Os produtos da Amazon são mercadorias (livros, computadores, telefones celulares etc.). O produto da Netflix e do YouTube é conteúdo de vídeo. O produto do Spotify é conteúdo de áudio. O Airbnb é um negócio de propaganda que gera conexões com as residências oferecidas para aluguel. O Google Adwords também é uma empresa de publicidade que gera conexões com qualquer produto ou serviço anunciado. O Nubank, um banco digital brasileiro, oferece serviços de cartão de crédito e conta bancária, como qualquer outro banco. O serviço principal da Uber e da Lyft é o transporte. Rappi, um serviço de entrega colombiano, e iFood e GrubHub, serviços de entrega de comida, são o que acabei de escrever, serviços de entrega. O Gympass oferece acesso a mais de 50.000 academias e estúdios em todo o mundo.

Exemplos de empresas tradicionais nativas digitais

Seus produtos não são tecnologia. Seus produtos não são software. A tecnologia e o software digitais viabilizam e potencializam seus produtos. Por esse motivo, a gestão de produtos é muito importante, mas não é central para a definição da visão e estratégia da empresa. Os gestores de produto terão um papel muito importante na definição e execução da visão e estratégia da empresa, mas não terão um papel central.

PRODUTO OU PLATAFORMA?

Cada vez mais vemos produtos de software que podem ser classificados como plataformas. Exemplos não faltam, desde grandes empresas de tecnologia como:

  • Google que, com dois produtos (Search e AdWords), criou uma plataforma conectando pessoas que buscam informações na internet com pessoas que querem anunciar coisas na internet.
  • Facebook, que começou como uma plataforma em que amigos se encontravam e trocavam informações, e tornou- se uma plataforma na qual anunciantes podem falar com pessoas por meio de anúncios e páginas de empresas. LinkedIn, uma plataforma para profissionais, empresas e, mais recentemente, anunciantes.
  • Apple, que conecta desenvolvedores de software com usuários de iPhone, iPad e Macs com sua AppStore. Outra plataforma da Apple é o iTunes, conectando produtores de mídia com pessoas interessadas em música, filmes, séries e livros.
  • Amazon Kindle, plataforma para que editoras ou autores possam publicar livros para pessoas interessadas nesses conteúdos.

Aliás, algumas dessas empresas têm mais de uma plataforma, como Google, Apple e Amazon.

Além dessas grandes empresas de tecnologia, existem também os exemplos mais recentes:

  • Uber, conectando motoristas com pessoas querendo transporte.
  • Airbnb, conectando quem tem imóvel para alugar por períodos curtos com quem quer alugar um imóvel nessas condições.
  • Bitcoin, quanto mais usuários tiver e quanto mais empresas aceitarem Bitcoin, melhor.

Existem também exemplos de plataformas que não são necessariamente baseadas em tecnologia como os shoppings, que colocam lojas, restaurantes e cinemas próximos às pessoas que querem comprar, comer e se divertir.

O que são plataformas?

Plataformas podem ser definidas como:

PLATAFORMA

Sistemas que, quanto mais pessoas usam, mais são valorizados.

São sistemas fortemente baseados no conceito de efeito de rede (network effect). Efeito de rede é o valor que os usuários de um determinado software obtêm quando outros usuários também utilizam o software.

Plataforma

Existem dois tipos de plataforma:

  • Plataformas de um único lado (single-side): são aquelas que, quanto mais usuários tiver, melhor. Usando um exemplo mais antigo, a máquina de fax. De nada adianta apenas uma pessoa ter fax; quanto mais pessoas usando, melhor. O mesmo vale para redes sociais (Facebook, Twitter, etc.).
  • Plataformas com múltiplos participantes (cross-side ou multi-side): são aquelas em que são necessárias dois ou mais grupos distintos de pessoas que fazem uso da plataforma de forma diferente, e que se beneficiam dessa forma diferente de cada grupo usá-las. Esse tipo pode ser classificado em 3 categorias:

Plataforma tecnológica: onde a plataforma é o sistema operacional; de um lado, temos os usuários e, do outro, temos os desenvolvedores do sistema operacional: Linux, Windows e Android.

Plataforma de troca: reúne compradores e vendedores: MercadoLivre, Uber e Airbnb.

Plataforma de conteúdo: o conteúdo é o foco, e a monetização é feita normalmente por meio de anúncios (Google, Facebook e os portais de notícias).

Veja a seguir um exemplo de plataforma tecnológica com 5 lados:

Sistema operacional Android visto como uma plataforma de 5 lados

É importante não confundir o conceito de plataforma no contexto de produto, com o conceito de plataforma técnica ou plataforma computacional. Uma plataforma computacional é qualquer ambiente computacional onde um software será executado. Já no contexto de produto, como definimos anteriormente, chamamos o produto de plataforma quando existem ganhos para os usuários e quanto mais usuários estiverem usando o produto.

Em um livro de 2019 chamado The Business of Platforms: Strategy in the Digital Concorrence, Innovation and Power (por Michael A. Cusumano, Annabelle Gawer, David B.Yoffie, Harper Business, 2019, https://www.amazon.com/Business-Platforms- Strategy-Competition-Innovation/dp/0062896326), os autores categorizam as plataformas em plataformas de transações, nas quais as transações acontecem (mercados, redes de anúncios, streaming, acesso a redes de casas, passageiros, academias de ginástica, etc.) e plataformas de inovação, em que um novo valor é construído sobre a plataforma (sistemas operacionais, lojas de aplicativos, AWS, etc.).

Um aspecto importante mencionado no livro é que as plataformas de transações são relativamente fáceis de serem copiadas e substituídas, enquanto que as plataformas de inovação são um pouco mais difíceis para tal devido a todo o investimento técnico que os participantes da plataforma fazem para fazer parte da plataforma. Muitas plataformas de transações evoluem para se tornar plataformas híbridas, ou seja, incorporam características de inovação para permitir que seus usuários criem novo material sobre as plataformas existentes.

Neste capítulo, vimos as definições de software, produto e plataforma digital, agora vamos descobrir o que é a gestão de produtos de software.

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:

About the Product Management book

We are at that point in which there is software in places where a few years ago, we never imagined that there would be need and usefulness in having software: TVs, refrigerators, stoves, cars, watches, glasses, clothing, locks, tables, chairs, medical equipment and so on. Not to mention the most obvious, the phone and wristwatch that are in our pockets, purses, and wrists and from which we are becoming increasingly dependent.

The ubiquity of software is now a reality; the software permeates numerous activities and objects of our daily lives. I think one can say that 100% of the population has their lives affected by software, and much of this population has frequent contact with software. According to the Digital 2019 report, even underdeveloped regions like Africa already have more than 36% of their active population on the Internet. In 2015 it was already 25%.

Even with this evidence that software-based digital products are part of the life of every person on the planet, I still have the impression that we do not give it due attention and care. Think of all the times you used a digital product over the past seven days. Have you had any frustrating experiences with it? I’m sure you did.

I have frustrating experiences with the software on a daily basis. Even software made by experts on the topic of digital product development — such as Google, Facebook, and other companies that were born and raised making software and that are often cited as references when we discuss the software development process — cause us frustration.

Why does this happen?

Software development has evolved a lot over the years. Talking about processes, we had a waterfall where each phase of the software development occurred sequentially. The distance between the need that generated the demand of the software development and the software itself was huge.

At the beginning of this millennium, we begin experiencing agile methodologies, which turned the software development process into a cycle with short interactions that promote continuous feedback. This helped considerably to bridge the gap between the need that generated the demand for software development and the software itself.

In terms of the aspects taken into consideration in the software development, we also evolved a lot. In the beginning, software was developed by teams composed exclusively of software developers. In fact, it was not uncommon for these teams to be composed of a single person. We increasingly see multidisciplinary teams working together in the development of software; which is very good because it brings new insights to the software being developed.

On one hand, the concern with the user, her goals when using the software, and her interactions with this software are taken care of by user experience professionals, or UX.

On the other hand, the concern about software operation, i.e., where this software will run and what performance and availability it needs to have, brought system administration professionals (SysAdmins) closer to the software development process. This proximity between software operation and software development is what gave rise to the term and DevOps culture.

So, we deliver software more frequently, and brought UX and SysAdmins into the software development process; but is this really enough? How do we tell the world, or better, the people who can benefit from this software, that this software exists? How do we take care of your legal issues? When a user has a problem with the software, how do we help her? How do we manage the return it will bring? How to ensure that the software meets the objectives of its owner while it also meets the needs of its users?

Digital product management

Thinking about these issues, some companies that are considered experts on software development began to adopt new expertise in its software development process, Digital Product Management. This role aims to ensure that the software being developed meets the objectives of its owner while it also meets the needs of its users.

In addition, a person in this role has to consider all the aspects of the digital product that I mentioned earlier. Some agile methodologies such as Scrum have the role of the Product Owner, whose main responsibility is to prioritize items to be developed. In a way, this is what a Digital Product Manager does, but there’s a little bit more to be covered by this role.

That’s what I’ll talk about in this book. 🙂

Who will benefit from reading this book?

This book is recommended for anyone who works with software. It is for people who are product managers since every product manager knows that there is always plenty to learn. And even those who have good knowledge of all the topics presented in the book may benefit from reviewing the topics.

This book is also recommended for anyone who is willing to get into a product management career. I believe this book can relieve some of the anxiety of those who are considering becoming product managers and are not sure what they will do and what other people expect of them.

I believe that even people who are not planning to become product managers will also benefit from this book, understanding what a person in this position does in the software life cycle and how a product manager should relate to other areas.

Note that I said this book is suitable for anyone working with the software. Even companies that do not have software as their core business use software in their day-to-day and often have developed some software that interfaces with its customers, such as a website or a mobile application. It is important for these companies to understand the software product management role and responsibilities, so they can better manage this software and increase its chances of success.

This book does not pretend to cover all the topics extensively. If it did so, it would probably have to be in a collection of books. My goal is to talk about the main topics related to digital product management, deepening on some specific topics and providing various additional reading suggestions.

In some places, the book will refer to Agile software development and the role of PO (product owner). I believe that the knowledge of the software development process and the different roles involved in this process is not necessarily a prerequisite for reading this book, but it is certainly knowledge that will help increase the chances of success of your software. If you want to delve into the subject, I recommend the book “Learning Agile: Understanding Scrum, XP, Lean, and Kanban” by Andrew Stellman, Jennifer Greene. In addition to explaining the principles behind agile culture, it also presents Scrum, XP, Lean, and Kanban, the four most popular agile methodologies, and how to spread the agile culture throughout the company. Recommended reading.

Book structure

I wrote the book with the following structure:

  • Part I – Definitions and requirements: People who know me know that I like clear definitions before I start discussing a particular topic. This is what I call the “equalization of concepts”. Therefore, I start the book by defining some keywords such as software, product, platform, product management, among others. In this part, I will also talk about the characteristics of a good product manager, the typical career of a product manager, and what the role of a product manager is. I will also give some tips to product managers about leadership and organizational culture.
  • Part II – Life cycle of a software product: In this part, I will describe what the life cycle of a software product is like and what the phases of that cycle are: innovation, growth, maturity and end of life. Still, I’ll talk about innovation, how to find a problem to solve, how to find out if it’s really an opportunity to pursue, and how to get feedback from your software product. At the growth stage, when the product was developed and released, should we be concerned with how to manage the product during its growth, ie how to manage feedback? What is a roadmap? What is OKR? When to use roadmap and when to use OKR? How to prioritize the demands? What to do with special requests? How to say no? What metrics to track? What is it and how do you create the vision and strategy of your product? After this growth comes maturity. In this part, we will understand when maturity happens and what to do if the product reaches this stage. After maturity, or when the product is developed but not working, comes the end-of-life phase of a software product. We’ll see how to detect and what to do at this stage of the cycle. In the end, when we know all the phases of a product’s life cycle, I’ll show you the difference between startup and software product management.
  • Part III – Relationship with other areas: how product managers relate with all different business roles, such as engineering, UX, product marketing, project management, operations, sales, legal, finance, HR and administration?
  • Part IV – Product portfolio management: why do some companies decide to have more than one product? How do they manage this portfolio of products? Why do other companies prefer to focus on a single product? Focus or diversification, which is the most appropriate strategy? How to organize the product development team according to the chosen strategy? These issues are what I consider advanced topics of software product management, and that is what we will see in the chapters that make up this part of the book.
  • Part V – Where to use software product management: does software product management can only be used by companies that sell software products and only in the development teams that develop software that are commercialized as products? Or would other companies benefit from treating their software as a product and using the product management techniques to increase the chances of success of their software? And where should we put the software product management in a company? In marketing? In the technical area? These will be the themes of the final chapters of the book

This sequence has a logical order and some chapters reference topics covered in previous chapters. For this reason, I recommend the sequential reading of the book. However, the chapters can also be read independently. If you are very curious to read about a particular topic, feel free to jump straight to the relevant section.

Enjoy!

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

Sobre o livro Gestão de Produtos

Já chegamos àquele ponto no qual há software em lugares em que, há alguns anos, jamais imaginaríamos que haveria necessidade e utilidade: televisão, geladeira, fogão, carro, óculos, roupa, fechadura, mesa, cadeira, equipamento médico e por aí vai. Isso sem falar no mais óbvio, o telefone e o relógio que estão em nossos bolsos, bolsas e pulsos, e dos quais estamos nos tornando cada vez mais dependentes.

A ubiquidade do software é hoje uma realidade, o software permeia inúmeras atividades e objetos de nosso dia a dia. Acredito que se possa dizer que 100% da população mundial tem suas vidas afetadas por software, e boa parte dessa população tem contato frequente com software. De acordo com o relatório Digital 2019, mesmo regiões pouco desenvolvidas como a África já têm mais de 36% de sua população ativa na internet. Em 2015 já eram 25%.

Mesmo com essa evidência de que o software está cada dia mais fazendo parte da vida de todas as pessoas do planeta, tenho a impressão de que não damos a ele a devida atenção e cuidado. Pense em todas as vezes em que você usou um software nos últimos sete dias. Você teve alguma experiência frustrante com ele? Tenho certeza de que sim.

Eu tenho experiências frustrantes com software diariamente. Mesmo softwares feitos por quem consideramos experts no assunto de desenvolver software – como Google, Facebook e outras empresas que nasceram e cresceram fazendo-os e que são frequentemente citadas como referências do processo do seu desenvolvimento – nos causam frustração.

Por que isso acontece?

O desenvolvimento de software evoluiu muito ao longo dos anos. Em termos de processo, antigamente tínhamos o waterfall, em que cada fase do desenvolvimento de software acontecia de forma sequencial. A distância entre a necessidade que gerou a demanda de desenvolver o software e o software propriamente dito era enorme.

No início deste milênio, começamos a experimentar as metodologias ágeis, que transformaram o processo de desenvolvimento de software em um ciclo com interações curtas que promovem o feedback contínuo. Isso ajudou consideravelmente a diminuir a distância entre a necessidade que gerou a demanda de desenvolver o software e o software propriamente dito.

Do ponto de vista dos aspectos levados em consideração no desenvolvimento de software, também evoluímos bastante. Os primeiros softwares eram desenvolvidos por times compostos exclusivamente por desenvolvedores de software. Aliás, não era raro esses times serem compostos de uma única pessoa. Cada vez mais vemos times multidisciplinares trabalhando juntos no desenvolvimento de software; o que é muito bom, pois traz novas visões para o software que está sendo desenvolvido.

Por um lado, a preocupação com o usuário, seus objetivos ao usar o software e sua interação com esse software são cuidados por profissionais de experiência do usuário, ou UX (do inglês User eXperience).

Por outro lado, a preocupação com a operação do software – ou seja, onde esse software vai rodar e que performance e disponibilidade ele precisa ter – trouxe profissionais de administração de sistemas, os SysAdmins (do inglês System Administrators), mais próximos do processo de desenvolvimento de software. Essa aproximação da operação do software com o seu desenvolvimento é o que deu origem ao termo e à cultura DevOps.

Entregamos software mais frequentemente, e trouxemos UX e SysAdmins para o desenvolvimento de software; mas será que isso é suficiente? Como vamos contar para o mundo, ou melhor, para as pessoas que podem ser beneficiadas com esse software, que esse software existe? Como vamos cuidar das suas questões jurídicas? Quando o usuário tiver um problema com o software, como vamos ajudá-lo? Como vamos gerenciar o retorno que ele trará? Como garantir que esse software atenda os objetivos de seu dono ao mesmo tempo em que atenda à necessidade de seus usuários?

Gestão de produtos de software

Pensando nessas questões, algumas empresas que são consideradas experts no tema desenvolvimento de software começaram a adotar uma nova função em seu processo, a Gestão de Produtos de Software. Essa função tem por objetivo garantir que um software sendo desenvolvido atenda aos objetivos de seu dono ao mesmo tempo em que atenda à necessidade de seus usuários.

Além disso, essa função tem de pensar em todos os aspectos do software que citei anteriormente. Algumas metodologias ágeis, como o Scrum, têm o papel do Product Owner, que tem como principal responsabilidade priorizar os itens a serem desenvolvidos. De uma certa forma, a Gestão de Produtos de Software é isso, mas ainda é um pouco mais.

É sobre isso que vou falar neste livro. 🙂

Para quem é este livro?

Este livro é indicado para qualquer pessoa que trabalhe com software. Ele serve para pessoas que são gestoras de produto, pois todo gestor de produtos sabe que sempre há muito por aprender. E mesmo aqueles que já conheçam bem todos os temas apresentados aqui poderão tirar proveito revendo algum assunto.

Este livro também é indicado para qualquer pessoa que esteja querendo entrar na carreira de gestor de produtos. Acredito que ele possa tirar um pouco da ansiedade de quem estiver pensando em se tornar gestor de produtos, e não sabe ao certo o que fará e o que as outras pessoas esperarão dele.

Acredito que mesmo as pessoas que não pretendem ser gestoras de produto também poderão tirar proveito deste livro, entendendo como uma pessoa nessa função atua no ciclo de desenvolvimento do software e como um gestor de produto deve se relacionar com as outras áreas.

Note que eu disse que este livro é indicado para qualquer pessoa que trabalhe com software. Mesmo empresas que não têm software como seu core business utilizam software no seu dia a dia e, não raro, desenvolveram algum software que tem interface com seus clientes como, por exemplo, um site ou um aplicativo mobile. É importante para essas empresas entenderem a função de gestão de produtos de software e suas responsabilidades, para que possam gerir melhor esse software e aumentar suas chances de sucesso.

Vale lembrar de que este livro não tem a pretensão de cobrir de forma extensiva todos os temas que serão abordados, mesmo porque, se o fizesse, provavelmente teria de ser em uma coleção de livros. Meu objetivo é falar sobre os principais temas relacionados com gestão de produtos de software, aprofundando em alguns temas específicos e fornecendo várias dicas de leitura adicional.

Em alguns lugares do livro, referenciarei metodologias ágeis de desenvolvimento de software e o papel de PO (Product Owner). Acredito que o conhecimento desse processo de desenvolvimento de software e dos diferentes papéis envolvidos nesse processo não seja necessariamente um pré-requisito para a leitura desse livro, mas é certamente um conhecimento que vai ajudar a aumentar as chances de sucesso do seu software. Caso você queira se aprofundar no tema, recomendo o livro Learning Agile: Understanding Scrum, XP, Lean, and Kanban de Andrew Stellman, e Jennifer Greene. Além de explicar os princípios por trás da cultura ágil, ele também apresenta Scrum, XP, Lean e Kanban, as quatro metodologias ágeis mais conhecidas, e explica como espalhar a cultura ágil por toda a empresa. Leitura recomendada.

Estrutura do livro

Escrevi o livro seguindo a seguinte estrutura:

  • Parte I – Definições e requisitos: as pessoas que me conhecem sabem que gosto de definições claras antes de começar a discutir sobre um determinado tema. É o que chamo de “equalização de conceitos”. Por isso, começo o livro definindo algumas palavras-chaves como software, produto, plataforma, gestão de produtos, entre outras. Nesta parte, falarei também sobre as características de um bom gestor de produtos, a carreira típica de um gestor de produtos, e qual o papel de um gestor de gestores de produtos. Também darei algumas dicas para gestores de produtos sobre liderança e cultura organizacional.
  • Parte II – Ciclo de vida de um produto de software: nesta parte, descreverei como é o ciclo de vida de um produto de software e quais são as fases deste ciclo: inovação, crescimento, maturidade e fim de vida. Ainda, falarei sobre o que é inovação, como encontrar um problema a ser resolvido, como descobrir se ele é de fato uma oportunidade a ser perseguida e como obter retorno com seu produto de software.

Na fase do crescimento, quando o produto foi desenvolvido e lançado, devemos nos preocupar em como gerenciar o produto durante seu crescimento, isto é, como gerenciar o feedback? O que é um roadmap? O que é OKR? Quando usar roadmap e quando usar OKR? Como priorizar as demandas? O que fazer com pedidos especiais? Como dizer não? Que métricas acompanhar? O que é e como criar a visão e a estratégia de seu produto?

Após esse crescimento, vem a maturidade. Nessa parte, vamos entender quando acontece a maturidade e o que fazer se o produto chega nessa fase. Depois da maturidade, ou quando o produto é desenvolvido mas não dá certo, chega a fase conhecida como fim de vida de um produto de software. Veremos como detectar e o que fazer nessa fase do ciclo. No final, quando já conhecermos todas as fases do ciclo de vida de um produto, mostrarei qual a diferença entre startup e gestão de produtos de software.

  • Parte III – Relacionamento com as outras funções: como o gestor de produtos deve se relacionar com as diferentes funções da empresa, como engenharia, UX, marketing de produtos, gestão de projetos, operações, vendas, jurídico, financeiro, RH e administração?
  • Parte IV – Gestão de portfólio de produtos: por que algumas empresas decidem ter mais de um produto? Como elas fazem para gerenciar esse portfólio de produtos? Por que outras empresas preferem se focar em um único produto? Foco ou diversificação, qual é a estratégia mais apropriada? Como organizar o time de desenvolvimento de produtos de acordo com a estratégia escolhida? Esses temas são os que considero tópicos avançados de gestão de produtos de software, e é o que veremos nos capítulos que compõem esta parte do livro.
  • Parte V – Onde usar gestão de produtos de software: será que gestão de produtos de software só pode ser usada por empresas que comercializam produtos de software e somente nos times de desenvolvimento que desenvolvem softwares comercializados como produtos? Ou será que outros tipos de empresa se beneficiariam ao pensar em seu software como um produto e ao usar as técnicas de gestão de produtos para aumentar as chances de sucesso dos softwares que desenvolvem? E onde devemos colocar a gestão de produtos de software em uma empresa? No marketing? Na área técnica? Esses serão os temas dos capítulos finais do livro.

Essa sequência tem uma ordem lógica de assuntos, e alguns capítulos referenciam temas abordados em capítulos anteriores. Por esse motivo, recomendo a leitura sequencial do livro. Contudo, os capítulos também podem ser lidos isoladamente. Se você estiver muito curioso para ler sobre um determinado tema, pode pular direto para o respectivo capítulo.

Boa leitura!

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:

Cerimônias

Neste capítulo, vou falar das cerimônias que costumo usar com os times que eu lidero. 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. Falarei sobre reuniões 1:1 (one on one ou one to one), reuniões de liderança, reuniões de All-Hands, Product Council, Product Update e reunião de estrutura de time.

Reuniões de 1:1

As reuniões de 1:1 são aquelas que o head de produto tem com seus liderados, sua líder, outros membros do seu time e com pessoas de outras áreas.

1:1 com liderados

As reuniões de 1:1 com os liderados são, com certeza, uma das mais importante do head de produto. Devem ser semanais e de uma hora. Caso o head de produto não consiga fazer todas essas reuniões em uma semana e decida fazer quinzenalmente ou diminuir sua duração, é sinal de que o head de produtos está com muitos liderados. Apesar de ter uma hora, essa reunião não precisa necessariamente ocupar uma hora. Em algumas semanas, podem ocupar menos de uma hora, em outras, pode haver a necessidade de mais tempo.

O tema dessa reunião é livre. Questões pessoais, questões do dia a dia, preocupações, feedbacks, retrospectivas. Não deve focar apenas em prestação de contas e relatório de progresso da pessoa. Durante essas conversas certamente aparecerão temas que deveriam ser conversados em conjunto com outras pessoas de seu time, então sugira mover o tema para a reunião de liderança. Uma vez por mês, no início de um novo mês, é importante dar uma passada nos OKRs para ver se tem algum impedimento em que você possa ajudar.

Essa reunião pode ser feita em uma sala, ou em um café ou um restaurante para um almoço. Ou mesmo por vídeo, em casos de as pessoas não estarem no mesmo lugar. Já vi pessoas fazendo 1:1 andando. Fica a seu critério e de seu liderado.

Costumo anotar os temas à medida que lembro de um tópico a ser conversado em um documento compartilhado com o liderado. Divido esse documento em temas novos e, à medida que vamos conversando, anotamos alguns pontos sobre os temas para referência futura. Terminado o 1:1, marco a data quando ocorreu a reunião e abro uma seção de novos temas.

1:1 com sua líder

Você se reporta para alguém na organização, então é importante também manter uma cadência no mínimo semanal de conversas com essa pessoa. Essa reunião deve servir de alinhamento entre vocês dois, para garantir que essa pessoa lhe passe sempre o contexto da empresa e do produto que você lidera nessa empresa, e que ela o ajude a remover os impedimentos.

Como head de produto, pode acontecer de você reportar para alguém que não tenha tanta experiência com gestão de desenvolvimento de produto como você. Por outro lado, essa pessoa terá experiência e conhecimento em outras áreas. É importante essa diferença de conhecimento e de experiência estar clara para ambos, para vocês poderem fazer essas conversas da forma mais proveitosa possível para ambos.

Sobre onde fazer, e como anotar, valem os comentários que fiz acima sobre 1:1 com seus liderados.

1:1 com outras pessoas

Além dos 1:1 com seus liderados e com seu líder que, como disse acima, devem ser semanais e de uma hora, você pode ter a necessidade de fazer 1:1 com outras pessoas do seu time e com pessoas de outras áreas. Isso acontece porque a correria do dia a dia pode ser tão grande que não sobre tempo para que essas conversas aconteçam se não estiverem agendadas. Avalie junto com cada uma dessas pessoas se existe a necessidade semanal, periódica ou apenas eventual para essas conversas. A duração também pode ser menor do que uma hora.

Costumo ter a necessidade de 1:1 semanais com líderes de RH, para conversar sobre necessidades de contratação e gestão de pessoas do time de desenvolvimento de produto. Também costumo ter 1:1 semanais com a líder da área de marketing para falarmos sobre geração de demanda para produto e sobre marketing de produto, ou seja, sobre como contar ao mundo sobre o problema que o produto resolve e como nosso produto o soluciona. Com frequência menor que semanal, pode fazer sentido 1:1 com o líder de vendas, para falarmos sobre o processo de venda do produto, com o líder de operações, para entendermos os impactos operacionais do produto, e com a líder do financeiro, para entendermos as receitas e os custos gerados pelo produto e pelo time.

Reuniões do time de liderança

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. Se não tiver alguém dedicado de RH, traga a pessoa mais sênior do RH que tem estado mais próxima do time de desenvolvimento de produto.

Essa é uma reunião de time, não do head de produto. Ou seja, devem ser discutidos temas trazidos por qualquer pessoa do time, e não apenas temas do head de produto. Ela pode acontecer mesmo que não estejam todos presentes. Mesmo quando o head do produto não está presente, ela deve acontecer normalmente. Caso o tema sendo discutido precise da presença de alguém que não está na reunião, deve-se aguardar para discuti-lo quando essa pessoa estiver na reunião.

Os temas a serem discutidos podem ser colocados em um documento do Google Docs, compartilhado com todos as pessoas que participam da reunião. Qualquer pessoa pode colocar temas a serem discutidos. Podem ser os mais variados, desde que façam sentido serem discutidos com as pessoas presentes. Quando surgirem temas propondo para criar alguma nova rotina ou algum novo projeto que faça sentido ser executado, essa é uma excelente oportunidade para a head de produto delegar para alguma pessoa de seu time, que pode criar um subgrupo para lidar com o tema. Exemplos de temas assim são Design System, Hack Day, Plano de Carreira, entre outros. Alguns temas que devem aparecer periodicamente nessa reunião para serem discutidos com todos os líderes do time de desenvolvimento de produto:

  • OKRs: definição e acompanhamento de OKRs. Definição, uma vez por trimestre e acompanhamento pelo menos uma vez por mês, idealmente toda semana, para ver se não há algum impedimento que precise ser removido.
  • Product Council: falarei um pouco mais à frente neste capítulo sobre a Product Council, que é uma reunião trimestral de apresentação de planejamento do time de desenvolvimento de produto para a liderança sênior da empresa. É importante planejar junto com o seu time o que vai ser discutido na Product Council.
  • All-Hands e Product Update: para essas duas reuniões, que são mensais, sobre as quais também falarei um pouco mais à frente, é importante definir junto com o time sobre os temas.
  • P&L: do inglês profit and loss ou receita e custo. É importante discutir com o time, pelo menos mensalmente, quanto de receita está sendo gerada com o produto e quanto o time de produto custa, incluindo não só pessoas como todos os outros custos (infraestrutura, treinamento, consultorias etc.).

Antes de entrar no Gympass, eu costumava fazer essa reunião presencialmente uma vez por semana. Essas reuniões tinham uma hora de duração e, quando havia muitos temas, aumentávamos para 1,5 ou 2 horas para poder falar sobre todos os temas. No Gympass, como parte do time ficava em outros países, começamos a fazer a reunião remotamente, mas ainda uma vez por semana. Ainda no Gympass, quando começou a pandemia, decidimos mudar a cadência para diária, dado o volume de temas que tinham que ser discutidos em função da crise. Depois de algum tempo, tiramos a reunião de sexta-feira para criarmos um meeting free day, ou seja, um dia da semana sem reuniões. Quando me juntei à Lopes, por estarmos remotos e termos muito temas para conversar, optamos por fazer nossas reuniões diariamente. Quando percebermos que não há assunto suficiente para uma hora, vamos diminuir a frequência.

Reunião de liderança do seu líder

Além de coordenar sua reunião de liderança com seus liderados, muito provavelmente você participará da reunião de liderados do seu líder, que definirá o modelo e o ritmo dessas reuniões. Aproveite essas reuniões para fazer alinhamento com seus pares e seu líder. Traga temas de desenvolvimento de produto que possam ser relevantes para eles. Se houver espaço, essa é uma boa reunião para trazer esporadicamente algum dos seus liderados para expor algum tema. Com isso, você dará visibilidade para as pessoas do seu time, além de permitir a eles a oportunidade de interagir com outros líderes seniores da empresa.

Reunião de All-Hands

As reuniões de All-Hands são reuniões com todas as pessoas do time de desenvolvimento de produto, não só os seus liderados diretos. Além das pessoas do time de desenvolvimento de produto, devem participar também as pessoas de RH que trabalham junto com o time de desenvolvimento de produto e outros convidados tais como o CEO/founder, líderes de outras áreas e quem mais fizer sentido participar.

O objetivo é comemorar os resultados, falar sobre lições aprendidas, discutir sobre o andamento dos OKRs, apresentar os novos membros do time e qualquer outro assunto que faça sentido conversar com todo o time.

A frequência mais indicada é a mensal e é bacana fazer um happy hour com todo o time após a reunião para descontração. Caso a reunião seja remota, o happy hour também deverá ser remoto.

Product Council

O Product Council, ou conselho de produto é uma reunião com a liderança do seu time e a liderança sênior da empresa em que seu time apresente o planejamento do próximo trimestre e, na virada do ano, do próximo ano. O objetivo da product council é ter todos alinhados em relação aos objetivos a serem alcançados no próximo trimestre e nas métricas que contarão que esses objetivos estão sendo alcançados.

Ela deve acontecer trimestralmente, por volta de uma semana antes de começar o novo trimestre. Nessa reunião, cada líder do time de desenvolvimento de produto apresenta seu planejamento do próximo trimestre para a liderança sênior da empresa. Muitas vezes o planejamento de 3 meses não contempla alguns temas que podem ser importantes para os participantes dessa reunião. Por esse motivo, tenho recomendado o uso do roadmap contínuo de 12 meses (12-month rolling roadmap), que permite mostrar não só o que vem pela frente no próximo trimestre como também nos próximos 12 meses. O objetivo não é discutir se o que está no quarto trimestre deve vir antes do que está no terceiro trimestre, mas sim se o que está no quarto trimestre deveria ser trabalhado no próximo trimestre e, se sim, o que deve ser postergado.

Exemplo de 12-month rolling roadmap

Note que, apesar de estarmos falando de roadmap, a primeira parte fala de objetivos e resultados. É fundamental manter a ordem de prioridade dos temas. Mais importante do que o que vai ser feito são os objetivos que queremos alcançar e quais as métricas que indicam que estamos alcançando esses objetivos. É papel do head de produto relembrar dessa prioridade de discussão dos temas.

Uma forma de mudar o foco para ficar 100% em objetivos e resultados é não usar roadmap e discutir apenas os OKRs. Tanto no Gympass quanto na Lopes tenho tido a oportunidade de participar em Product Councils muito produtivas, focadas exclusivamente em discutir os OKRs.

A duração dessas reuniões depende da quantidade de temas a serem discutidos. Já cheguei a participar de reuniões de Product Council que tiveram que ser feitas em dois dias, dada a quantidade de temas e a necessidade de alinhamento necessário. Por outro lado, as reuniões mais curtas de Product Council que participei duraram entre 1,5 a 2 horas.

A agenda da reunião começa com o head de produto fazendo uma introdução com informações sobre o contexto do planejamento do próximo trimestre e, em seguida, cada um dos líderes do time de desenvolvimento de produto apresenta o seu planejamento.

Um ponto importante é fazer uma prévia da Product Council sem a liderança sênior da empresa, para dar a oportunidade dos membros do seu time se alinharem sobre seus planejamentos caso ainda não o tenham feito. Certa vez fiz uma Product Council sem esse alinhamento prévio e, no meio da apresentação do planejamento de uma pessoa, a outra comentou que ela “não pode ter planejado fazer aquilo pois X e Y não estão prontos e só serão entregues no final do trimestre”, o que mostrava a falta de coordenação entre elas.

Outro trabalho preparatório importante para a reunião de Product Council são reuniões 1:1 que podem ser feitas entre uma líder do time de desenvolvimento de produto e alguém da liderança sênior, para buscar feedback sobre o planejamento em um ambiente mais reservado e já levar o planejamento para a Product Council considerando esse feedback. A recomendação é fazer quantos 1:1s forem necessários para obter um bom alinhamento pré-Product Council.

Product Council com clientes

Uma variação da Product Council que pode ser interessante ser conduzida é a Product Council com clientes, ou seja, você convida alguns clientes para trabalhar com eles uma proposta de priorização para o próximo trimestre. Fizemos isso algumas vezes na Conta Azul, quando chamamos alguns de nossos contadores parceiros para passarem o dia conosco, para dar a eles a oportunidade de conhecer de perto nossa operação e, em uma determinada parte de dia, fazíamos um exercício de priorização com eles, onde elencávamos uma série de funcionalidades, cada uma com um certo custo de desenvolvimento, e os deixávamos escolher dentro de um limite de custo de desenvolvimento que eles poderiam aplicar.

É muito bacana ver clientes passando pela mesma dificuldade que nós, gestores de produto, temos ao tomar decisões de priorização. Essa priorização feita pelos corretores servia como mais um insumo para nosso trabalho de priorização a ser preparada para o próximo trimestre e para ser apresentada na Product Council com a liderança sênior da empresa.

Product Update

Essa também é uma reunião mensal onde o time de produto apresenta para toda a empresa o que foi feito no último mês e o que está planejado para o próximo mês, sempre conectando com os OKRs do time. Essa é uma reunião muito importante para gestão de expectativas. Na Conta Azul, como tínhamos reunião de All-Hands de toda a empresa todas as semanas, pegamos uma dessas reuniões para ser o product update. Já no Gympass, as reuniões de All-Hands aconteciam uma vez por mês, então criamos uma reunião separada, chamada de Global Product Update Call, que tinha que ser uma reunião remota já que o Gympass tinha na época times em 14 países.

Uma maneira de organizar o conteúdo é cada líder do time de desenvolvimento de produto apresentar sua parte ou, a cada mês, um dos líderes se responsabilizar por preparar e apresentar o conteúdo do mês. Além desse conteúdo, o head de produto deve fazer uma introdução e deve haver demonstrações das novas funcionalidades entregues. Idealmente, essas demonstrações devem ser ao vivo. Quanto mais demonstrações e menos slides, melhor. No último product update que participei na Conta Azul fiquei superfeliz pois foi 100% demonstrações.

No final do product update é importante abrir para perguntas e respostas, e as respostas devem ser dadas pelos líderes do time de desenvolvimento de produto.

Essa reunião é muito importante para “prestar contas” para a empresa sobre o que a área de produto está fazendo. Constantemente ouço que o time de tecnologia é uma caixa preta, “ninguém sabe o que eles estão fazendo e não entendemos o que eles falam”. Para tirar essa percepção de caixa preta, o melhor caminho é a comunicação e o product update é um elemento de comunicação bastante eficaz.

Reunião de estrutura de time

Essa reunião pode acontecer de forma independente, ou ser uma parte da reunião de liderança do time. O objetivo é bem simples: decidir em conjunto com o time como será organizado o time de desenvolvimento de produto, como será investido o orçamento para contratação de pessoas e qual a prioridade de contratação. Quais tribos e squads devemos montar? Será que devemos contratar só pessoas para engenharia, ou devemos também trazer designer e gestoras de produto? Devemos olhar o que temos para fazer, o que conseguimos fazer, e o que precisamos de ajuda. É uma reunião colaborativa, que o head de produto deve facilitar.

É importante o pessoal de RH participar dessa reunião. Certa vez na Conta Azul, uma pessoa de RH que acompanhava a área de operações e de vendas pediu para participar dessa reunião para entender a dinâmica e ela ficou impressionada com a capacidade dos participantes da reunião em convergirem sobre a melhor forma de usar o orçamento. Foi quando ela comentou comigo que “o seu time é muito maduro para poder esse tipo de discussão. Lá na liderança de operações e vendas não temos essa maturidade para podermos implementar essa dinâmica”, ao que eu respondi que no começo nós também não tínhamos essa maturidade, mas ela foi conquistada com o exercício constante dessa dinâmica, ou seja, o time foi ganhando maturidade à medida que aprendia a colaborar mais, a entender as necessidades dos outros líderes e a se perceber com um time com objetivo comum.

Resumindo

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

Com este capítulo, terminamos a parte III sobre ferramentas. No próximo capítulo, farei um grande resumo do livro para servir de referência rápida, com todos os “Resumindo” de todos os capítulos.

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:

Feedback e avaliação de desempenho

Uma das principais ferramentas para desenvolvimento das pessoas do seu time é o feedback. Essa palavra é um termo inglês que originalmente significa “retroalimentação”, ou seja, um processo em que as ações de um determinado sistema são inseridas de volta no sistema para o aprimoramento do próprio sistema. Na gestão de pessoas, o feedback é quando uma pessoa conta para outra como seu comportamento e suas ações foram percebidos por essa pessoa. Feedback pode ser dado por pares, por subordinados ou por líderes.

Feedback

Como líder, é muito importante você dar feedback sempre que necessário para as pessoas que trabalham com você. Seis aspectos são essenciais para que o feedback possa ser o mais útil e relevante possível:

  • Ser necessário: antes de dar um feedback, é importante entender se ele é necessário. O que a pessoa fez afeta o resultado negativamente? Ou é somente uma forma diferente de fazer o que precisa ser feito? Às vezes, damos feedback sobre algo porque foi feito de uma forma diferente do que esperávamos, mas não necessariamente gerou resultados ruins. Se o resultado foi atingido no mesmo tempo, de uma forma aceitável, precisamos aceitar essas diferentes formas de se fazer as coisas e de se obter os resultados.
  • Na hora: é importante dar o feedback o mais próximo possível do momento em que a situação sobre a qual você quer dar feedback aconteceu. Dessa forma, os detalhes sobre o ocorrido e as motivações que levaram as pessoas a agirem da forma como agiram estarão frescos na memória de todos.
  • Objetividade: ao conversar sobre o que aconteceu, seja objetivo, ou seja, vá direto ao ponto e baseie seu feedback em fatos. O seu feedback deve ser útil para a pessoa que está recebendo, ele deve dar claras indicações sobre o comportamento esperado para aquela situação.
  • Transparência: o feedback tem que ser transparente, não pode haver aspectos escondidos ou não ditos, contanto que sejam aspectos relevantes para aquele feedback.
  • Empatia: ser transparente e objetivo não significa ser rude. Ao contrário, o feedback tem por objetivo ajudar a pessoa a entender como suas ações e seu comportamento impactam as outras. Coloque-se no lugar dessa pessoa que vai receber esse feedback e pense em como você gostaria de recebê-lo para que ele seja o mais útil possível.
  • Privado: procure dar o feedback em um ambiente privado, para dar espaço e liberdade para uma conversa transparente e produtiva.

Características de uma boa gestora de produtos

Eu costumo avaliar gestores de produtos em relação a 7 principais características:

Empatia: é a capacidade que uma pessoa tem de se colocar no lugar de outra para compreender os seus anseios, motivações, necessidades e problemas. Essa característica é importante para entender os clientes e usuários do produto, saber como estes se relacionam com ele e que problema esperam resolver ou que necessidade querem ver atendidas. Isso ajudará a gestora de produtos a entender melhor seu usuário para poder, junto com o UX e a engenharia, desenhar o melhor produto. Contudo, a empatia não deve ser usada apenas com o cliente ou usuário. A gestora de produtos deve usá-la também no seu relacionamento com todas as áreas da empresa, e deve entender o impacto que seu produto tem no trabalho delas.

Comunicação: para poder ter empatia, é necessário que a gestora de produtos se comunique com as pessoas nos mais diferentes cenários: em conversas um a um e em pequenos grupos, ou fazendo apresentações para grupos pequenos e grandes de pessoas, apresentações que podem ser internas (dentro da empresa) ou externas (em conferências, grupos de usuários etc.). Porém, não é só de falar que vive o gestor de produtos. Comunicação é uma via de mão dupla, ou seja, a gestora de produtos tem de ser muito boa em saber ouvir e compreender o que os outros estão dizendo, e entender os anseios e as necessidades deles; o que tem a ver com a primeira característica, a empatia.

Gestão do tempo: o dia a dia de uma gestora de produtos pode se encher rapidamente de tarefas e ela precisa ser capaz de perceber e diferenciar o que é urgente do que é importante, para garantir que terá sempre tempo para conhecer mais sobre o cliente e o usuário de seu produto.

Novas tecnologias: o gestor de produtos deve estar antenado sobre as novas tecnologias para saber como ela pode impactar o seu produto. Acesso via smartphone, como isso impacta o produto? O usuário quer acessar via smartphone? Para fazer o quê? Redes sociais, como o produto pode tirar proveito delas? Bancos de dados não relacionais, quais os benefícios e as deficiências? Go, a nova linguagem de programação do Google, no que ela é melhor do que a linguagem usada no produto? E no que ela é pior? Smartwatches, smartglasses, como isso impacta o produto? Como o usuário espera interagir com o produto nessas novas interfaces?

Habilidades empresariais: o gestor de produtos deve se preocupar se o seu produto está atingindo os objetivos de negócio. Se o objetivo for margem, a receita e os custos estão sob controle? Se o objetivo for só receita, como está o crescimento dela? Se o objetivo for número de usuários, como está evoluindo essa métrica? Além disso, o gestor de produtos deve entender como cada área da empresa funciona e como o produto afeta essas áreas. Como o jurídico funciona? Como o produto impacta no departamento jurídico? E como o departamento jurídico impacta no produto? Essas perguntas podem ser repetidas para todas as áreas da empresa: suporte, operações, financeiro, RH, marketing, vendas, engenharia e UX.

Curiosidade aguçada: a gestora de produtos precisa ter a capacidade de aprender rápido para poder ter insights e fazer julgamentos sobre o produto. Deve ser capaz de aprender tanto o lado soft do produto (qual é a motivação de negócio, qual problema do cliente o produto resolve etc.) como o lado mais técnico (qual tecnologia usamos, qual o impacto dessa tecnologia, que métricas podemos obter etc.).

Tema do produto: por fim, mas não menos importante, a gestora de produtos precisa conhecer sobre o tema do produto. Se for um produto médico, o gestor de produtos deverá entender um pouco sobre medicina. Se for um produto financeiro, deverá conhecer um pouco de finanças. Por exemplo, na Locaweb, temos produtos mais técnicos (como o Cloud Server) e menos técnicos (como a Loja Virtual). A necessidade de conhecimento técnico é bem diferente nesses dois produtos. A gestora de produtos do Cloud Server deverá conhecer bem a fundo questões técnicas, enquanto o gestor de produtos da Loja Virtual não precisa ter tanto conhecimento técnico, mas deverá saber bastante sobre questões de venda online.

Gestor de produtos precisa saber programar?

Essa é uma pergunta razoavelmente polêmica. Como dito, a depender do tema do produto, é importante saber programar, principalmente se aquilo de que o gestor de produtos cuida é um produto mais técnico. Alguns exemplos da Locaweb são Hospedagem de Sites, Cloud Server e SMTP. Contudo, mesmo empresas que não “vendem” um produto técnico podem ter uma parte de seu produto com um viés mais técnico. Na Conta Azul tínhamos as APIs, as integrações com fintechs (Iugu e Stoce) e a integração com as Secretarias da Fazenda para emissão de nota fiscal, e no Gympass toda a parte de integração com sistemas de gestão de academias e com sistemas de RH. Para esses produtos, é importante ter um gestor de produtos com conhecimento de técnico, uma vez que o principal usuário do produto será técnico e o objetivo do produto é um objetivo técnico.

Por outro lado, um produto como Lova Virtual, o app do Gympass ou o portal de busca de imóveis da Lopes são produtos feitos para qualquer pessoa utilizar. Será que para esses produtos seria bom o gestor de produto ter conhecimento técnico, ou seja, saber programar? Na minha visão, não é essencial que o gestor de produtos tenha conhecimento técnico, mas certamente vai ajudar. O conhecimento técnico ajuda a entender como o produto é feito, e isso o ajudará a ser um gestor de produtos melhor. Ajuda a entender o trabalho feito pelo time de engenharia e pode ser útil nas decisões sobre priorização e escopo. Duas analogias que podem ajudar a entender melhor o benefício que saber programar traz para um gestor de produtos:

  • Um bom corredor de Fórmula 1 não precisa saber como o carro funciona, mas se ele souber, certamente poderá usar esse conhecimento para ser um piloto melhor.
  • Da mesma forma, uma guitarrista não precisa saber cantar nem tocar baixo, bateria, ou piano para ser uma boa guitarrista, mas certamente esse conhecimento adicional pode ajudá-la a ser uma guitarrista melhor.

Isso não significa que a gestora de produtos precisa ser uma expert em programação. Se ela não tem nenhum conhecimento de programação, seria interessante fazer um curso introdutório à lógica de programação e experimentar fazer seu primeiro programa. Essa experiência só vai beneficiar a carreira dessa pessoa.

SQL

Se o gestor de produtos ainda não sabe, deve aprender SQL. Acesso aos dados está cada vez mais democrático nas empresas e saber SQL é fundamental para que o gestor de produtos possa usufruir dos dados de maneira independente, sem precisar ficar pedindo para outras pessoas criarem seus gráficos e dashboards. Quando colocamos o Metabase como solução de democratização dos dados na Conta Azul eu fiquei tão animado que passei uma semana inteira indo dormir às 2:00 da manhã, pois ficava criando gráficos e dashboards para entender melhor como os produtos do Conta Azul eram utilizados.

Avaliação de desempenho

Muitas empresas utilizam a avaliação de desempenho como a ferramenta oficial da empresa para coletar e registrar o feedback dos seus funcionários. Líderes avaliando as pessoas do seu time. Pessoas avaliando os seus pares e seus líderes. Pessoas fazendo autoavaliações.

Algumas empresas utilizam a matriz 9-box que tem duas dimensões:

  • Desempenho: análise do passado, dos resultados entregues por aquela pessoa. Aqui, mais do que o resultado em si, é importante levar em conta o papel da pessoa no atingimento desse resultado, principalmente se considerarmos resultados de um time de desenvolvimento de produtos, que são um resultado de equipe.
  • Potencial: análise do futuro, ou seja, o quanto a pessoa está preparada para lidar com novos desafios. Literalmente, potencial significa “ter ou mostrar a capacidade de se tornar ou se desenvolver em algo no futuro”. Como dá para perceber, essa dimensão de avaliação de uma pessoa pode ser bastante subjetiva. Por esse motivo, algumas empresas têm substituído o potencial por cultura, ou seja, uma análise de como os resultados foram atingidos por aquela pessoa, e se estão alinhados com os valores da empresa. Tende a ser um pouco subjetivo também, mas um pouco menos do que potencial.

Líderes fazem a avaliação de seus liderados com base nessas duas dimensões. Em algumas empresas, essas avaliações incluem, com um peso menor, a autoavaliação, as avaliações de pares, clientes internos e, caso a pessoa lidere um time, de seus liderados. É a avaliação 360º. Em outras empresas, a autoavaliação e as avaliações de pares, clientes e liderados servem como dados adicionais para o líder fazer a avaliação, mas não entram no cálculo da avaliação.

Depois de feita a avaliação, normalmente se faz um processo de calibração, onde os líderes comparam a avaliação de seus liderados para entender se os critérios de avaliação usado por cada líder está equalizado. Esse processo todo de avaliação é liderado e coordenado pelo time de RH da empresa, e essa calibração é facilitada por alguém do RH. As pessoas avaliadas são plotadas na matriz 9-box e com isso tem-se um mapa das pessoas da empresa.

Matriz 9-box e seus quadrantes

Com essa avaliação calibrada em mãos, o gestor retorna para o liderado e então se inicia o trabalho de gestão de consequências, que é trabalho que precisa ser feito após o liderado receber sua avaliação:

  • Bem avaliados: pessoas que ficam em um dos 4 quadrantes superiores são as que foram bem avaliadas. Normalmente são as pessoas que são consideradas para aumentos e promoções. Normalmente elas ficam felizes com o feedback e se sentem motivadas a continuarem fazendo o trabalho da melhor forma possível. Contudo, se a autoavaliação da pessoa for superior à avaliação recebida, mesmo ela estando bem avaliada, há o risco de ela sentir alguma frustração. Isso só não acontece se ela for avaliada no quadrante superior direito da matriz 9-box.
  • Mal avaliados: pessoas que ficam em algum dos 3 quadrantes da esquerda ou algum dos 3 quadrantes superiores estão abaixo do esperado em desempenho e/ou em potencial (ou valores, se na empresa houve a decisão por trocar esse eixo da matrix 9-box). Essas pessoas precisarão fazer algo para serem bem avaliadas no próximo ciclo. Essa situação pode causar certo desconforto na pessoa avaliada por ela sentir que seu emprego pode estar em risco. Para algumas pessoas, essa situação pode servir de incentivo para ela buscar melhorar e, de fato, ser melhor avaliada no próximo ciclo. Por outro lado, algumas pessoas podem se sentir desmotivadas com essa avaliação e decidem procurar alguma oportunidade em outra empresa. Esta situação se agrava se a pessoa se autoavaliou melhor do que a avaliação que recebeu.

Crítica ao processo de avaliação de desempenho

O processo de avaliação de desempenho procura classificar os funcionários de uma empresa com o intuito de facilitar o entendimento de quem são as melhores pessoas e quem são as pessoas que precisam melhorar. Contudo, como expliquei acima, há muitas oportunidades para frustração nesse processo de avaliação, especialmente quando há discordância entre a autoavaliação e a avaliação recebida. Essa frustração normalmente é potencializada pelo fato de o processo de avaliação ser passível de:

  • subjetividade: como medir o potencial de uma pessoa? Como medir sua aderência aos valores da empresa? Como medir sua participação no atingimento dos resultados?
  • bias: distorção em função de diversos aspectos do julgamento do avaliador em relação ao avaliado. Normalmente, o avaliador lembra das ações mais recentes de um avaliado. É comum ações com consequência negativa serem percebidos de forma mais intensa do que ações com consequência positiva.

Além disso, estamos entendendo e respeitando cada vez mais a diversidade humana, não só em questões físicas e de preferências, como também a diversidade de perspectiva, de história e de contexto. Tendo essa maior clareza sobre a diversidade humana, torna-se cada vez mais complicado encaixar todos as pessoas de uma empresa em somente 9 caixas baseadas em duas dimensões (potencial vs. resultados). Para entender melhor a complexidade das pessoas que compõem uma empresa, provavelmente precisaremos pensar de forma multidimensional.

Por esses motivos, existe uma tendência mundial de abandonar o processo de avaliação de desempenho periódico e substituí-lo por conversas mais frequentes entre líder e liderado sobre carreira, performance, potencial e valores. Segundo algumas estimativas (https://hbr.org/2016/10/the-performance-management-revolution), mais de um terço das empresas americanas já abandonaram o processo de avaliação de desempenho periódico e adotaram essas conversas mais frequentes como alternativa.

Retrospectiva, alternativa ao processo de avaliação de desempenho

Em adição às conversas mais frequentes entre líder e liderado sobre carreira, performance, potencial e valores, acho importante a cada 6 meses fazer uma retrospectiva junto com o liderado sobre o que aconteceu nesse período. Da mesma forma que em desenvolvimento de produtos temos cerimônias de retrospectiva, é um momento de revisitar o que passou e avaliar o que foi bem, o que pode melhorar e os desafios pela frente.

Eu faço uma primeira versão, baseado no histórico que tenho com a pessoa. Caso haja um processo formal de avaliação de desempenho na empresa onde eu estiver trabalhando, uso essa oportunidade para fazer a retrospectiva e considero todas informações geradas através desse processo, autoavaliação, avaliação de pares, clientes internos e de liderados, se houver.

Essa primeira versão tem 3 seções, pontos fortes, pontos a melhorar e desafios do próximo semestre, que contempla não só os principais objetivos para o próximo semestre como também foco nos pontos de melhoria. Caso haja um processo formal de avaliação de desempenho na empresa onde eu estiver trabalhando, coloque minha sugestão inicial de classificação nos quesitos mensurados nesse processo formal.

O próximo passo é usar uma das reuniões de 1:1 para conversar com o liderado sobre essa retrospectiva, ouvir como ele a enxerga e, eventualmente, ajustar a retrospectiva de comum acordo com ele. É um excelente momento para ter uma conversa mais ampla e uma reflexão conjunta sobre o semestre que passou e sobre o que vem pela frente.

Caso haja um processo formal de avaliação de desempenho na empresa onde eu estiver trabalhando, faço essa conversa antes de inserir os dados no sistema de avaliação da empresa, pois acho importante a avaliação conter essa retrospectiva construída em conjunto com o liderado. Caso haja sessões de calibração, aviso o liderado de que a avaliação ainda pode sofrer ajustes pela calibração e, após a calibração, conto de forma transparente o que aconteceu na calibração, para ajudar a pessoa a entender como outras pessoas a percebem.

EXEMPLO

Pontos fortes

O primeiro semestre foi particularmente difícil para Felipa, com muitas incertezas e uma enorme pressão de entrega do Projeto Avengers. Diante disso tudo, Felipa conseguiu navegar muito bem pela situação e encontrar boas soluções, inclusive recomendando uma aquisição de empresa, como também manteve sua tribo engajada no processo.

Pontos a melhorar

Seu time de PMs ainda é júnior, com pouca experiência de gestão de produtos, apesar de ter bom conhecimento técnico do tema do produto. É importante buscar formas de acelerar essa senioridade do time.

Desafios para o próximo semestre

Deve trabalhar para aumentar senioridade de seus PMs pois eles ainda demandam bastante de seu tempo, impedindo-a de ter um papel mais estratégico.

Promoções e aumentos

No capítulo Contratar as pessoas certas comentei que, ao fazer a proposta para uma pessoa se juntar ao seu time, é importante balancear incentivo de curto prazo (salário e benefícios), médio prazo (bônus) e longo prazo (stock options e similares). De tempos em tempos, enquanto essa pessoa estiver no seu time, é importante avaliar se esses incentivos precisam ser revistos, ou seja, se ela merece um aumento ou uma promoção. Há dois aspectos importantes a considerar, quando e como dar aumentos e promoções.

Quando

É comum empresas que definem um período do ano para promoções e aumentos, normalmente logo após o período de avaliação de desempenho ou da retrospectiva periódica. Recomendo não fazer isso, pois na hierarquia de necessidades da maioria das pessoas, a necessidade por reconhecimento e recompensa financeira vem antes da necessidade por desenvolvimento pessoal. Sendo assim, se em uma mesma conversa colocarmos o tema sobre promoções e aumentos junto com o tema feedback e que pontos ela precisa para melhorar, a atenção da pessoa estará muito mais voltada ao tema promoções e aumento. Por esse motivo, recomendo separar essas duas conversas. Quando conversar sobre promoção e aumento, foque apenas nesse tema. E quando conversar sobre retrospectiva, novamente foque apenas nesse tema.

Como

Existem duas formas de promover uma pessoa. A primeira forma é esperar que ela esteja demonstrando habilidades de, pelo menos, 70% do próximo nível de carreira para promovê-la. É o que chamo de “promoção empurrada”, ou seja, ela deve empurrar para conseguir sua promoção. A outra forma é avaliar o potencial da pessoa, ou seja, se ela tem a capacidade de desenvolver as habilidades necessárias para operar no próximo nível de carreira e, se ela tiver, promovê-la. Chamo essa forma de “promoção puxada” pois a pessoa é puxada para operar no nível de habilidade do próximo nível de carreira.

Tenho preferência pelo modelo de promoção puxada, pois gera um desafio bastante motivador para a pessoa, que sentirá que está devendo as habilidades necessárias e vai correr para desenvolvê-las o mais rápido possível. Há, obviamente, o risco de ela não conseguir desenvolver essas habilidades mas, na maioria dos casos, vejo que pessoas com potencial normalmente conseguem desenvolvê-las bem rápido. Já na promoção empurrada, a principal vantagem é que não há risco, a pessoa que é promovida já demostra as habilidades necessárias. Contudo, exatamente por já apresentar as habilidades necessárias, essa pessoa pode achar que a promoção não vem, ou está demorando muito e pode querer olhar o mercado aumentando o risco de você perdê-la do seu time, por demorar a dar o seu reconhecimento.

Resumindo

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

No próximo capítulo vamos conhecer as cerimônias que costumo usar com os times que eu lidero.

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: