Let’s remove the product from the center?

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

Beyond the product

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

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

Making businesses grow and prosper through technology.

And Conta Azul’s mission is:

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

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

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

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

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

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

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

Help people conquer their place.

When the product is at the center

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

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

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

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

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

Removing the product from the center

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

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

Product is means, not the end

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

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

Summing up

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

Digital Product Management Books

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

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

2 hacks to foster your digital product culture

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

What is digital product culture?

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

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

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

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

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

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

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

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

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

Hack #2: problem mindset

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

Summary

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

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

Digital Product Management Books

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

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

2 hacks para promover e fortalecer sua cultura de produto digital

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

O que é Cultura de Produto Digital?

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

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

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

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

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

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

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

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

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

Hack #2: Qual é o Problema?

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

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

Resumo

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

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

Gestão de produtos digitais

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

Organizational culture

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

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

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

Culture differences by Manu Cornet

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

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

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

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

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

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

Don’t waste time looking for culprits

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

Blame game, by Ron Tandberg

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

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

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

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

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

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

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

War

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

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

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

I believe the images speak for themselves.

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

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

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

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

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

Air, food and profit

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

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

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

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

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

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

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

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

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

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

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

Concluding

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

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

Digital Product Management Books

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

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

Cultura Organizacional

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

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

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

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

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

CULTURA ORGANIZACIONAL

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

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

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

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

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

NÃO DESPERDIÇAR TEMPO BUSCANDO CULPADOS

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

Blame game, por Ron Tandberg

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

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

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

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

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

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

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

GUERRA

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

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

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

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

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

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

EMPRESA

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

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

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

AR, COMIDA E LUCRO

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

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

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

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

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

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

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

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

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

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

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

Concluindo

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

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

Gestão de produtos digitais

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

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.
  • Há 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:

Mentalidade de ecossistema

Esse valor eu aprendi no Gympass. Era um dos valores corporativos da empresa e, na minha opinião, toda plataforma tem que ter esse valor. Muitas vezes me deparei com CEOs e heads de produto de plataforma que afirmavam que faziam tudo pelo cliente, que a empresa inteira era voltada ao cliente. Contudo, quando eu perguntava mais sobre esse tema, eu acabava descobrindo que o cliente ao que eles se referiam era apenas um dos atores da plataforma e os outros eram tratados apenas como “mal necessário”.

Na descrição do valor no site do Gympass está escrito:

Mentalidade de ecossistema

Tomamos decisões que criam valor para o nosso ecossistema Gympass e nos ajudam a alcançar nossa missão.

O exemplo que darei sobre mentalidade de ecossistema foi a implementação do produto de aulas ao vivo que o Gympass criou durante a crise do COVID-19.

Diversificando – e digitalizando – um portfólio de produtos

Durante a pandemia do COVID-19, diversificamos – e digitalizamos – nosso portfólio de produtos em tempo recorde. Passamos de um produto offline, acesso a academias e estúdios, para 4 produtos, 3 deles totalmente digitais, em menos de um mês:

  • Acesso a academias e estúdios: acesso a mais de 50.000 academias e estúdios em 14 países;
  • Aulas ao vivo: para quem gosta de treinar em grupo ou quer reviver a sensação da aula com os colegas da academia;
  • Personal trainers: para quem prefere uma abordagem mais personalizada e gosta de se exercitar no seu tempo;
  • Gympass Wellness: pacote de aplicativos com mais de 60 aplicativos para quem busca opções para melhorar o bem-estar físico e mental (da nutrição à sessão de terapia).

A seguir explico como fizemos isso.

Visão do Produto

Quando entrei para o Gympass, em meados de 2018, uma das primeiras coisas que fiz foi construir uma visão de produto. Tínhamos um propósito muito forte: vencer a inatividade. No entanto, para construir um produto digital, precisamos mais do que um propósito.

Visão de produto do Gympass

Essa visão orientou a definição da organização de desenvolvimento de produtos Gympass. Como comentei no capítulo Estrutura de time, montamos equipes em torno de cada um dos participantes do marketplace, além de uma equipe central que atuava no fluxo de pagamentos recolhendo o pagamento das empresas e de seus funcionários, fazendo todos os cálculos e determinando o pagamento de cada academia parceira.

Quando eu estava construindo essa visão de produto e discutindo-a com diferentes pessoas na organização, foi fácil ver muitas oportunidades de expandir esse mercado. Há uma grande quantidade de novas categorias de oferta que poderíamos adicionar ao nosso marketplace:

Oportunidades de expansão do Gympass

Existem 3 tipos de elementos em um mercado:

  • Oferta: bens ou serviços disponíveis para consumo.
  • Demanda: pessoas ou empresas que podem precisar de bens ou serviços oferecidos pelo fornecedor.
  • Mercado: onde a demanda encontra oferta e ocorre uma transação.

Esses três elementos se relacionam da seguinte maneira:

  • Entrega de valor: o mercado agrega valor à demanda e à oferta. O valor entregue à oferta são pessoas ou empresas interessadas em seus bens ou serviços. O valor entregue à demanda é um número variado de fornecedores de bens e serviços.
  • Pagamento: para ter acesso aos bens e serviços oferecidos pelos fornecedores, a demanda paga o mercado e o mercado paga a oferta. Normalmente, o mercado retém uma taxa por transação. Essa taxa pode ser fixa ou uma porcentagem do pagamento.
Dinâmica de um marketplace

Dada a dinâmica acima, podemos expandir um mercado da seguinte maneira:

  • Diversificação da demanda: você pode oferecer os bens e serviços do seu mercado para novos segmentos e regiões geográficas.
  • Diversificação de suprimentos: você pode oferecer novos bens e serviços à sua demanda.
  • Entrega de novo valor: você pode oferecer um novo valor para sua oferta e demanda.
  • Gestão financeira de pagamentos: como o pagamento da demanda para a oferta passa pelo mercado, você pode oferecer serviços financeiros tanto para a demanda quanto para a oferta, como pagamento antecipado e crédito, e pode gerenciar o spread.
Possibilidade de expansão de um marketplace

No entanto, tínhamos muito a fazer em nosso produto principal naquela época, então não tínhamos energia suficiente para nos concentrar na expansão de nosso marketplace e deixamos os planos na gaveta.

Novo empreendimento

Em outubro de 2019, chegamos a um ponto em que nossa equipe de desenvolvimento de produto estava bem estruturada e trabalhando adequadamente para enfrentar nossos desafios em nosso produto principal, então decidimos nos concentrar na expansão de nosso marketplace.

Decidimos trabalhar em uma ideia chamada “hub de parcerias do usuário final Gympass”. O plano era fazer parceria com aplicativos de bem-estar e fornecê-los aos nossos usuários.

Essa nova ideia tinha duas hipóteses principais que precisávamos testar:

  • Disposição para parceria de fornecedores de aplicativos. Os provedores de aplicativos, assim como as academias, estão acostumados com o modelo de receita mensal recorrente. Eles aceitariam ser pagos por dia de uso?
  • Disposição de pagar de nossa base de usuários. Nossa base de usuários está interessada em pagar uma mensalidade para ter acesso aos aplicativos?

Para testar nossa primeira hipótese, construímos um deck com a proposta de valor que planejávamos entregar aos parceiros e conversamos com alguns parceiros em potencial. Apresentamos a oportunidade de parceria a 8 potenciais parceiros, dos quais 6 mostraram interesse e 4 decidiram juntar-se à nossa prova de conceito. NEOU, um app de treino de atividade física, 8fit, um app de treino de atividade física e de nutrição, Tecnonutri, um app de nutrição e ZenApp um app de meditação.

Ok, nossa primeira hipótese foi validada e precisávamos validar a segunda hipótese, a disposição a pagar. Nosso usuário está disposto a pagar para ter acesso a esses aplicativos através do Gympass?

Para testar nossa segunda hipótese, construímos um formulário simples, onde descrevemos o produto e perguntamos nome, e-mail e empresa. Após o usuário fornecer essas informações, ele seria direcionado para uma página de assinatura do Paypal, onde ele precisa fornecer os dados do cartão de crédito para assinar o serviço. O usuário receberia um e-mail com o link de ativação de cada aplicativo. Não havia um produto real, apenas um formulário para testar o interesse e um e-mail com os links para os aplicativos.

Inicialmente, o chamamos de Gympass W, o W significando wellness (bem-estar). Adicionamos um beta para que todos pudessem entender que não era um produto acabado. Mais tarde, renomeamos para Gympass Wellness para deixar sua proposta de valor mais clara.

Nosso plano era testar essa prova de conceito com 5 clientes corporativos nos EUA e 5 no Brasil, o que nos forneceria uma base de potenciais usuários de 15.000 funcionários. Nossa expectativa era ter cerca de 200 assinantes. Lançamos internamente – eat your own dog food (coma sua própria ração para cachorro) – em 9 de março de 2020 e conquistamos 66 inscritos. Em seguida, veio o COVID-19.

COVID-19

Quando uma empresa é atingida por uma crise, ela precisa olhar para estas duas perspectivas:

  • preservar o dinheiro;
  • identificar e se adaptar às mudanças nos problemas e necessidades do cliente.

Embora gestores de produto e as equipes de desenvolvimento de produto tenham um papel importante no primeiro, seu papel principal é no segundo.

No Gympass temos 3 clientes diferentes e todos eles profundamente impactados pelo COVID-19:

  • academias em muitas cidades foram fechadas para auxiliar nas medidas de distanciamento físico aplicadas em muitas cidades para evitar a disseminação do COVID-19 e, consequentemente, estão perdendo receitas recorrentes de usuários que não frequentam a academia;
  • os usuários, funcionários de nossos clientes, não podem mais ir às academias e têm que ficar em casa, mas também têm que se manter ativos de alguma forma, mas sua primeira reação é cancelar ou pausar sua inscrição no Gympass, pois não terão acesso às academias por um tempo;
  • clientes corporativos, cujos funcionários estão em casa e não vão mais a academias, enquanto os RHs se preocupam em como manter esses funcionários engajados e produtivos.

Gympass Wellness, o primeiro produto digital

Fomos capazes de adaptar nosso piloto do Gympass Wellness em tempo recorde para ser oferecido a toda a nossa base de usuários, de forma que eles possam não apenas permanecer ativos, mas também cuidar de sua alimentação e de suas mentes durante esses tempos tão desafiadores. Com o Gympass Wellness, fomos capazes de atender aos problemas e necessidades dos usuários e de nossos clientes corporativos durante a crise.

E aqui entra a mentalidade de ecossistema. Devemos sempre olhar para todos os participantes em nosso mercado e garantir que todos se beneficiem de usá-lo.

Live Classes, o segundo produto digital

Com o Gympass Wellness, fomos capazes de atender às necessidades de nossos clientes corporativos e de seus funcionários. E as academias? Ao serem fechadas, estavam perdendo receita. Seus clientes não os visitavam mais, então os usuários regulares das academias estavam propensos a cancelar sua assinatura, enquanto aqueles que costumavam ir às academias usando o Gympass não iam à academia durante a crise, o que causaria uma perda de receita para as academias também. Para ajudar as academias parceiras, decidimos e implementamos em tempo recorde 2 soluções:

  • Fornecemos às academias um aplicativo white-label para que elas pudessem oferecer a todos os seus clientes, independente de serem ou não funcionários de clientes do Gympass, para que as academias pudessem entregar valor aos seus clientes, ajudando-os a se manter ativos em casa;
  • Fornecemos uma plataforma para as academias agendarem e transmitirem aulas ao vivo para todos os usuários do Gympass, para que eles possam manter seus instrutores empregados, enquanto fornecem aos usuários do Gympass conteúdo exclusivo. Essa plataforma é chamada de Live Classes.

Personal Trainers, o terceiro produto digital

As Live Classes forneciam uma plataforma 1:N, o que significa que um instrutor poderia fornecer orientação de atividade física para N usuários. Logo percebemos que poderíamos criar outro produto além do Live Classes, orientação de atividade física 1:1, que poderia ser disponibilizada nos planos de nível superior do Gympass. Em seguida, criamos nosso terceiro produto digital, Personal Trainers.

Resumindo

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

Pronto, com este capítulo concluímos a segunda parte do livro, sobre 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. Vimos também os 5 valores necessários para criar produtos digitais de sucesso:

  • 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.
  • Diversidade, a base dos melhores produtos.

Por fim, vimos 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:

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

Vamos agora ver as ferramentas? \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:

Entrega de resultado

No capítulo anterior vimos a diferença entre um time que soluciona problemas e um time que implementa soluções. Enquanto um time que resolve problemas precisa ter um profundo entendimento de cada problema que vai resolver, das pessoas que são afetadas por ele, do contexto onde acontece e da motivação das pessoas para terem esse problema resolvido, o time implementador de soluções se foca em implementar aquilo que lhe é pedido, não se importando se o que está sendo implementado serve para algo.

A medição de entrega de resultado desses dois tipos de times costuma ser bem diferente. Por meio da forma como um time reporta seus resultados conseguimos claramente saber que tipo de time é. Algo como “conte-me sobre seus resultados que lhe direi que tipo de time é!”. Enquanto o time implementador de soluções costuma medir sua entrega de resultado baseado na quantidade de funcionalidades entregues, o time solucionador de problemas mede sua entrega de resultado baseado em quão bem os problemas foram resolvidos.

Fábrica de funcionalidades

Os times implementadores de soluções são aquelas “fábricas de funcionalidades” que já mencionamos no capítulo anterior, ou seja, cuja principal métrica é a quantidade e a velocidade de entrega de funcionalidades. Como essa é sua principal métrica, esse time passa a ser medido pelas suas entregas. O time disse que ia entregar tal funcionalidade nesse dia, então é isso que a organização espera e será isso que a organização vai cobrar do time.

Essa situação não é tão incomum quanto se imagina. Na Locaweb, antes de implementarmos OKRs, o time de desenvolvimento de produto era primariamente cobrado por assertividade do planejamento. Se o time disse que ia entregar X no dia Y, era isso que era esperado do time, com nenhuma preocupação se X era a coisa certa a fazer e se ia de fato trazer resultado para a empresa ou para os clientes. Ao implementarmos OKRs, conseguimos fazer o time cada vez mais focado em entender e resolver problemas.

Ao me juntar à Lopes, encontrei algo bastante similar. Um time de portal, outro de CRM e outro de app, todos eles com entregas predefinidas até 6 meses para frente, porque foi isso o que foi acordado com a direção da empresa. Inclusive a Lopes tinha contratado duas empresas de consultoria que, ao apresentarem seu relatório de resultados, mostravam a quantidade de funcionalidades entregues como seu principal resultado, porque foi isso que foi demandado delas, entrega de funcionalidades.

É importante notar que uma situação como essa não acontece exclusivamente por responsabilidade do time de desenvolvimento de produto. É também responsabilidade das pessoas que estão fazendo as demandas. Enquanto o time de desenvolvimento de produto deve sempre perguntar qual o problema que está tentando resolver com aquela demanda, as pessoas que fazem as demandas devem sempre contextualizar essas demandas trazendo o problema que motivou a demanda.

Foco no resultado

Após meus primeiros 30 dias na Lopes já comecei a trabalhar com o time na definição dos OKRs para o próximo trimestre, o que motivou inclusive o RH a também fazer seu planejamento baseado em OKRs. Depois, esses OKRs foram apresentados para toda a liderança da empresa. Foi a forma que encontrei de provocar a mudança de cultura e de mentalidade tanto no time de desenvolvimento de produto quanto em toda a empresa.

A maioria dos OKRs que definimos são focados em resultados de negócio. Aumento de vendas, aumento da taxa de atendimento e assim por diante. É isso o que importa para o negócio. As funcionalidades são um meio, não um fim em si mesmo, mesmo em empresas 100% digitais, como a Conta Azul e a Locaweb, os produtos digitais são um meio para o fim. A Locaweb inclusive deixa isso bem explícito em sua missão de “fazer negócios nascerem e prosperarem por meio da tecnologia”, enquanto a Conta Azul quer “impulsionar o sucesso dos pequenos empreendedores levando às pequenas empresas mais organização, controle e tempo por meio da tecnologia.” Repare que em ambas a tecnologia, o produto digital é um meio para se atingir um fim.

Resumindo

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

No próximo capítulo vamos ver o valor de mentalidade de ecossistema.

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:

Foco no problema

É da natureza humana resolver problemas. Sempre que ouvimos falar de problemas, entramos quase imediatamente no modo de solução: começamos a buscar soluções para o problema. No entanto, se antes conseguirmos um melhor entendimento sobre o contexto em que o problema ocorre e a motivação para resolvê-lo, há mais chances de conseguirmos encontrar soluções mais simples e fáceis de implementar.

É comum ver outras áreas pedindo à equipe de desenvolvimento de produtos que implemente o recurso A ou B porque precisamos dele para fechar um negócio ou para não perder esse grande cliente. Um exemplo comum que tenho ouvido atualmente é “precisamos implementar o Apple Pay e o Google Pay como um novo método de pagamento”. A questão aqui é que, falando em soluções, perdemos o foco no problema que originou essa solução.

Qual é o problema?

Para ajudar as pessoas a se focarem no problema, pergunte sempre “Qual é o problema?”. Quando uma nova solicitação de funcionalidade chega à equipe de desenvolvimento do produto, devemos agradecer ao solicitante pelo pedido e, em seguida, devemos perguntar sobre o problema que gerou a solicitação. Cada membro da equipe de desenvolvimento de produtos precisa ter esse comportamento sempre que uma solicitação de nova funcionalidade for recebida.

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

Mentalidade de problema vs. solução

A principal vantagem de nos focarmos em entender melhor o problema é que, quanto mais tempo investirmos nisso, 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.

Aqui está uma ótima citação de Albert Einstein:

“Se eu tivesse uma hora para resolver um problema, gastaria 55 minutos pensando sobre o problema e cinco minutos pensando nas soluções.”

Einstein acredita que a qualidade da solução que você gera está em proporção direta com sua capacidade de identificar e compreender o problema que espera resolver.

Deixe-me contar uma pequena história para ilustrar isso. Durante a corrida espacial, os cientistas se depararam com o problema de escrever no espaço onde não houvesse gravidade para fazer a tinta cair em uma caneta esferográfica. Os americanos começaram seus esforços de P&D e depois de algum tempo e alguns milhões de dólares, eles construíram uma caneta com um pequeno motor que bombeia tinta para o papel, mesmo sem gravidade. Enquanto isso, os russos decidiram usar lápis.

Caneta que escreve em ambientes sem gravidade.

Essa história mostra um bom exemplo de como pular direto para a solução pode nos fazer gastar tempo e dinheiro desnecessários para chegar a soluções incompletas ou exageradas. É uma questão cultural, ou seja, um comportamento que podemos e devemos mudar. E o primeiro passo para mudar um comportamento é reconhecer quando ele acontece. Quando um membro da equipe de desenvolvimento de produto recebe uma solicitação para implementar algo, ele deve perguntar à pessoa que trouxe a solicitação qual é o problema que esse “algo” deve resolver e por que é necessário resolvê-lo.

Aqui estão alguns exemplos das empresas em que trabalhei.

Na Locaweb, provedora de hospedagem web no Brasil, os serviços de hospedagem e e-mail podem parar de funcionar devido a fatores externos como o domínio que está associado à hospedagem e ao e-mail não ser renovado.

Primeira solução: Registro.br, o registrador brasileiro de domínios .br lançou uma API para permitir que a Locaweb cobrasse o domínio do cliente em nome do Registro.br. A princípio, a ideia parecia boa, já que a Locaweb cobrar o domínio parecia a forma mais fácil de garantir que o cliente saiba que tem que pagar pelo registro do domínio para manter os serviços de hospedagem e e-mail funcionando corretamente. Porém, quando analisamos mais a fundo, vimos que essa solução poderia gerar alguns problemas. O cliente seria cobrado duas vezes pelo mesmo registro de domínio porque o Registro.br continuaria cobrando o domínio. O que acontece se o cliente pagar as duas contas? E se ele pagar apenas o Registro.br? E se ele pagar apenas Locaweb? Além disso, implementar um novo tipo de cobrança em que cobraríamos por um serviço de terceiros era algo novo para a equipe da Locaweb. Novos processos teriam que ser cuidadosamente projetados.

Solução real: começamos a nos perguntar se haveria maneiras mais simples de resolver o problema de ajudar nosso cliente a não esquecer que ele tem que pagar pelo registro de domínio no Registro.br. Como seria possível cobrar pelos serviços do Registro.br, foi possível acessar as informações sobre o domínio prestes a expirar. Decidimos desenhar uma solução mais simples: implementar uma régua de comunicação com este cliente avisando-o da importância de pagar ao Registro.br para garantir que os serviços de e-mail e hospedagem continuem funcionando normalmente. Esta é uma solução muito mais simples do que implementar um processo de faturamento dobrado. Se o Registro.br nos fornecer a URL de cobrança, podemos enviar as informações desse link ao cliente e as chances de solucionar o problema aumentarão ainda mais. E uma sequência de comunicação é muito mais simples e rápida de implementar do que um processo de faturamento duplicado.

Na Conta Azul, um ERP SaaS para MPEs (micro e pequenas empresas), usamos contadores como um de nossos canais de distribuição e queríamos aumentar as vendas por meio de contadores.

Primeira solução: compras em lote, onde os contadores adquiririam um número fixo de licenças do Conta Azul para revender aos seus clientes. Um sistema de gerenciamento de compras em lote levaria cerca de 3 meses para ser implementado, pois deveria permitir que os contadores comprassem licenças da Conta Azul a granel, mas só deveria começar a cobrar do cliente da contadora quando esse cliente realmente ativasse a licença.

Solução real: os contadores não se importavam com as compras em lote. O que eles queriam era dar um desconto aos seus clientes para que eles pudessem assinar a Conta Azul com esse desconto exclusivo proporcionado por seu relacionamento conosco. O custo para implementar isso foi zero, pois o sistema já tinha um recurso de gerenciamento de descontos.

No Gympass, um parceiro de fitness que estava ingressando em nossa rede solicitou que apresentássemos seu waiver (termo de isenção de responsabilidade) a todos os usuários que fizessem o check-in em suas instalações.

Primeira solução: mudar nosso aplicativo para pedir aos usuários que vão a este parceiro de fitness que leiam seu waiver em nosso aplicativo e marquem um checkbox informando que leram e estão de acordo.

Solução real: nenhuma alteração em nosso aplicativo. Usamos um campo de texto personalizável na configuração de uma academia em nosso sistema que normalmente é apresentado aos usuários que farão check-in nessa academia para apresentar o seguinte texto: “Ao fazer o check-in, você concorda com os termos e condições localizados em http://fitnesspartner.com/waiver”.

Não me interprete mal, é muito bom que todos tragam soluções sempre que quisermos discutir algo a ser feito pela equipe de desenvolvimento de produto. Quanto mais ideias de solução tivermos, melhor. No entanto, precisamos nos educar para ter um entendimento mais profundo do problema por trás dessa solução, para que tenhamos a chance de encontrar soluções mais simples e rápidas para implementar. E é, em última análise, o trabalho da gestora de produto e de todos os membros da equipe de desenvolvimento de produto perguntar qual é o problema e por que precisamos resolvê-lo.

Projetos vs. problemas

O ano novo é tempo de retrospectiva e planejamento. O que normalmente é feito a cada trimestre pela maioria das equipes de desenvolvimento de produtos é feito de forma mais intensa na virada do ano, em conjunto com outras áreas da empresa. É o processo de planejamento anual, que normalmente vem junto com o processo de orçamento. O que faremos neste novo ano que está chegando? Quais são os principais projetos que trabalharemos ao longo do ano?

Mesmo que o planejamento seja superimportante para ter clareza sobre quais projetos são prioridades para o novo ano, esta lista de projetos pode fazer você perder de vista um aspecto muito importante do planejamento, o “porquê”.

Não é incomum ver o planejamento de ano novo para uma equipe de desenvolvimento de produto, e até mesmo para toda a empresa, como uma lista de projetos. Para ajudá-lo a ver sua lista de projetos em um ângulo diferente, adicione 2 colunas:

  • uma para descrever quais são os problemas que você está tentando resolver em cada projeto;
  • e outra para descrever para quem você está tentando resolver este problema.

Já discuti as questões de ter uma mentalidade orientada para a solução versus uma mentalidade orientada para o problema, mas quando se trata de planejamento de ano novo, esse problema fica ainda mais evidente. Os benefícios de ter clareza sobre os problemas que deseja resolver e para quem você planeja resolvê-los são:

Garantir que os problemas estejam alinhados com a visão e estratégia da empresa: quando focamos em projetos, é fácil perder de vista os problemas que estamos tentando resolver, para quem planejamos resolver, e se são esses problemas que realmente precisamos resolver.

Definir quais problemas são mais importantes para resolver: priorizar projetos sem saber quais problemas esses projetos resolvem, e para quem, pode tornar as prioridades não alinhadas com o que é realmente importante para a empresa. Porém, para sermos mais eficazes em trazer o resultado desejado, devemos priorizar os problemas a serem resolvidos e garantir que a priorização esteja alinhada com a visão e estratégia da empresa.

Resolver mais de um problema com o mesmo projeto: às vezes, você pode descobrir que está tentando resolver mais de um problema com um projeto, e isso pode não ser um problema. Mas você precisa saber disso. Talvez você possa ter soluções mais simples se tratar cada problema separadamente. Talvez nem todos valham a pena resolver neste momento.

Verificar se os projetos são as melhores soluções: quando mudamos o foco dos projetos para os problemas e temos uma visibilidade clara da prioridade dos problemas, fica mais fácil verificar se os projetos listados são a melhor solução para o problema em questão. Às vezes, podemos encontrar soluções que são mais fáceis de implementar quando mudamos nosso foco para a compreensão dos problemas.

Então pegue sua lista de projetos e crie essas duas colunas, problemas a serem resolvidos em cada projeto e para quem os problemas serão resolvidos. Isso ajudará você a se concentrar nas coisas mais importantes para este novo ano.

Equipes solucionadora de problemas vs. equipes implementadoras de solução

Marty Cagan, uma referência bem conhecida na comunidade de produtos digitais, escreveu há algum tempo um artigo interessante sobre equipes de produtos x equipes de funcionalidades, onde explica a diferença entre três tipos de equipes, as equipes de entrega, as equipes de funcionalidades e as equipes de produto. Ele define de cada tipo de equipe da seguinte forma:

  • As equipes de entrega não são multifuncionais (basicamente apenas desenvolvedores mais um product owner que administra o backlog), não estão focadas no resultado (as pessoas são todas orientadas à entrega de funcionalidades) e não têm autonomia (estão lá para codificar e entregar).
  • As equipes de funcionalidades geralmente são multifuncionais (têm pelo menos uma designer e uma gestora de produto), mas ainda se preocupam com a produção e entrega de funcionalidades.
  • As equipes de produto são multifuncionais, focadas e avaliadas pelo resultado, e têm autonomia para apresentar soluções que funcionem.

Ele explica que os melhores resultados para a organização dona do produto e para os usuários desse produto vêm das equipes que ele chama de equipes de produto. Ele tem usado muito a palavra empoderado (empowered) para descrever esses times.

Qualquer produto digital existe para dois propósitos principais:

  • Ajudar a empresa dona do produto digital a atingir seus objetivos.
  • Resolver os problemas e atender as necessidades de seus usuários.

Portanto, qualquer produto digital e suas funcionalidades são soluções para problemas da empresa dona do produto e soluções para resolver os problemas do usuário e atender às suas necessidades.

Neste contexto de produto digital, quando digo que gastar mais tempo entendendo o problema produz as melhores soluções, quero dizer que somos capazes de entregar o mais rápido possível o melhor produto e funcionalidades para resolver o problema em mãos com software de boa qualidade e boa experiência de usuário.

Solucionar problemas vs. implementar solução

O que Marty descreve como equipes de entrega e equipes de funcionalidades são equipes de implementadores de soluções. Essas equipes trabalham na implementação de uma solução concebida por outra pessoa. E essa outra pessoa normalmente é alguém da chamada “área de negócios”, que pode ser alguém de vendas, marketing, sucesso do cliente, suporte ao cliente, finanças, operações, um diretor, um vice-presidente ou um fundador. Em tal equipe, o gerente de produto gerencia principalmente o backlog e ajuda a equipe a entregar a solução solicitada, o designer de produto se concentra principalmente em desenhar uma interface agradável e os engenheiros têm que codificar e implantar a solução solicitada. As equipes de implementação da solução fazem o que foi solicitado, com pouco ou nenhum compromisso com a qualidade da solução, ou mesmo se a solução implementada realmente resolve o problema. Podem também ser chamadas de “fábrica de funcionalidades”. Sua performance é medida pela quantidade de funcionalidades que o time produz.

Por outro lado, o que Marty descreve como equipes de produto empoderadas são equipes de solução de problemas. Essas 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.

Existem três razões principais pelas quais as equipes de solução de problemas são mais eficazes do que as equipes de implementadores de soluções:

Conhecimento de produto digital: não há ninguém melhor do que os membros da equipe para encontrar a melhor solução de produto digital para um problema. Uma solução entregue o mais rápido possível, com boa qualidade de software e boa experiência do usuário. Isso acontece porque uma equipe de solucionadores de problemas é uma equipe multifuncional composta por engenheiros que entendem a tecnologia disponível, designers de produto, que têm um conhecimento profundo dos usuários, suas dores e necessidades, e gestores de produto, que têm um bom entendimento do contexto empresarial do problema a ser resolvido.

Duas cabeças pensam melhor do que uma: este velho ditado significa que é mais fácil para duas pessoas que se ajudam resolverem um problema do que para uma pessoa resolver um problema sozinha. Uma equipe de solucionadores de problemas não descarta nenhuma sugestão de solução das “áreas de negócios”. Na verdade, essas sugestões de solução são muito úteis para ajudar a equipe a entender melhor o problema, mas elas devem ser consideradas dessa forma, sugestões. Uma equipe de solucionadores de problemas primeiro entende profundamente o problema e, em seguida, analisa as opções de solução.

Compromisso: um efeito colateral adicional de uma equipe de solução de problemas é que os membros dessa equipe estão profundamente comprometidos com o sucesso da implementação da solução, uma vez que estão profundamente envolvidos no processo de busca da solução.

Criação de equipes de solução de problemas

Agora que expliquei por que as equipes de solução de problemas são o melhor tipo de equipe de produto que uma empresa pode ter, explicarei como construir equipes de solução de problemas. Existem três aspectos que precisam ser considerados:

Ambiente: é fundamental que toda a organização entenda o poder de ter equipes de produtos digitais para solução de problemas. A velocidade e a qualidade das soluções entregues por uma equipe de produto digital que sempre começa a resolver os problemas a partir de um entendimento profundo do problema é muito melhor do que as soluções entregues por equipes de implementadores de soluções. Consequentemente, os resultados do negócio serão melhores e mais rápidos. É função e responsabilidade do head de produto ajudar a organização a entender isso.

Qual é o problema: uma maneira muito eficaz de enfocar toda a organização para longe da mentalidade de solução e mais próximo da mentalidade de problema é perguntar constantemente “Qual é o problema que estamos tentando resolver?” e “Por que é importante resolver este problema?”. Isso ajudará as pessoas de toda a organização a mudar sua perspectiva e, consequentemente, perceber a importância de um entendimento profundo do problema antes de implementar uma solução. Essa é uma mudança de comportamento que toda a equipe de desenvolvimento de produto digital pode ajudar sua organização a fazer. Sempre que alguém pede à equipe de produto para implementar algo, pergunte “Qual é o problema que estamos querendo resolver?”.

Confiança: este é um aspecto crítico para construir equipes bem-sucedidas de produtos digitais de solucionadores de problemas. Normalmente as pessoas da “área de negócios” acreditam ter um melhor entendimento do negócio do que as da equipe de produto. Esse comportamento fica ainda mais visível quando a equipe de produto digital é nova na organização. Como uma pessoa nova na organização pode entender mais sobre o negócio do que quem está na empresa há anos? Provavelmente ela não pode, especialmente se ela vier de um mercado diferente. No entanto, quem faz parte da equipe de produto digital normalmente tem muita experiência na construção de produtos digitais, provavelmente mais experiência do que qualquer outra pessoa na organização.

Por isso, é fundamental que a “área de negócios” eduque a equipe de produto digital sobre os aspectos de negócios da organização. Essa busca por educação é papel e responsabilidade dos gerentes de produto, que devem aprender com a “área de negócios” e educar designers e engenheiros de produto sobre o negócio. Uma forma prática de acelerar esse aprendizado é trazer pessoas da “área de negócios” para as sessões de discussão sobre o problema. É assim que a equipe de produto ganha a confiança das demais áreas da organização.

Acredito que estão claros os benefícios de ter equipes de produto digital de solucionadores de problemas versus implementadores de solução. Toda a organização precisa entender a diferença a fim de pressionar por mais e mais equipes de resolução de problemas. A head de produto tem essa como uma de suas maiores responsabilidades, ajudar a construir o ambiente e a confiança necessária para o sucesso das equipes de solução de problemas.

A armadilha do top-down

Quando falo sobre as diferenças entre equipes solucionadoras de problemas vs equipes implementadoras de solução, normalmente ouço comentários como “Queremos ser uma equipe de solucionadores de problemas, mas na minha empresa todas as soluções são top-down e a única coisa que podemos fazer é implementá-las”.

Essas situações agravam-se quando surge pressão. A pressão mais recente que muitas empresas estão sofrendo é a crise do COVID-19. Na ânsia de resolver os problemas o mais rápido possível, os líderes da empresa pedem às equipes que implementem esta ou aquela solução de maneira rápida, muito rápida.

A armadilha

Deixe-me agora abordar o elefante na sala, o ambiente de tomada de decisão top-down. Isso tem um impacto enorme em qualquer equipe neste tipo de ambiente. Sem fazer parte da decisão sobre a solução, as pessoas que implementam a solução acabarão por ficar desmotivadas.

Por que estou chamando de armadilha do top-down? Porque muitos dos ambientes de tomada de decisão percebidos como top-down são isso que acabei de escrever, uma percepção.

Vamos usar a principal característica que toda gestora de produto deve ter, empatia. A habilidade de alguém se colocar no lugar de outra pessoa para entender suas aspirações, motivações, necessidades e problemas. Pessoas com quem tive a oportunidade de falar sobre as características essenciais de um gestor de produto sabem o quão importante considero a empatia como um traço crítico para PMs de sucesso.

Aqui estão 2 dicas para ajudar os membros da equipe de produto a ter empatia com os chamados tomadores de decisão top-down e escapar da armadilha de cima para baixo:

  • Compreendendo a situação: coloque-se no lugar do solicitante da implementação de solução. As pessoas resolvem problemas, é a natureza delas, e sempre que se deparam com um problema, pulam para o modo de solução e tentam encontrar e implementar soluções o mais rápido possível. Sob maior pressão, como a crise COVID-19, o desejo de encontrar e implementar soluções é exacerbado. Na maioria dos casos, as pessoas não querem ser tomadores de decisão top-down, elas simplesmente têm uma necessidade de resolver o problema o mais rápido possível.
  • Alterando o status quo: faça perguntas sobre a solicitação de implementação de solução. Que problema estamos resolvendo? Para quem? Por que é importante resolver esse problema? Por que agora? Por que precisamos entregar algo rápido, mesmo comprometendo a qualidade? Se lhe perguntarem o motivo de tantas perguntas, explique que está tentando entender melhor o problema para ver se existem outras soluções mais baratas e rápidas.

Essas dicas ajudarão todos na equipe de produto a fazer a mudança para um processo de tomada de decisão mais colaborativo.

Na maioria das vezes, as pessoas entendem os benefícios de um processo colaborativo de tomada de decisão. Mesmo sob pressão, as soluções colaborativas produzirão melhores resultados. Soluções concebidas em um processo colaborativo são normalmente mais baratas e rápidas de implementar porque mais pessoas tiveram a chance de discutir as opções de solução e a equipe que implementará a solução selecionada estará verdadeiramente comprometida com seu sucesso.

Para construir, manter e melhorar as equipes de solução de problemas e evitar transformá-las em equipes de implementação de soluções, especialmente quando sob maior pressão, é fundamental evitar a armadilha do top-down.

Os heads de produto têm o papel e a responsabilidade de promover essas mudanças de comportamento para ajudar a construir um processo de tomada de decisão mais colaborativo e, consequentemente, mais eficaz.

Resumindo

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

No próximo capítulo vamos entender mais sobre o foco em entrega de resultados.

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:

Lançamento antecipado e frequente

Nos capítulos anteriores 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 à situação compartilhado por um grupo de pessoas trabalha junto. E vimos os 5 valores necessários para criar produtos digitais de sucesso:

  • 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ências, não devem ser o foco principal.
  • Transparência, a fundação de um time de alta performance.
  • Diversidade, a base dos melhores produtos.

Cultura de produto

Acontece que esses valores são necessários, mas não suficientes. 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. Os quatro valores, que serão tema deste e dos próximos capítulos, são:

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

Vamos começar com o primeiro: Lançamento antecipado e frequente.

Quanto mais cedo apresentarmos o produto a seus usuários, melhor, pois poderemos receber feedback de usuários reais que poderão usar o produto em seu próprio contexto. Existem 3 razões que justificam essa necessidade de lançar seu produto ou funcionalidade o quanto antes e frequentemente.

Momento da verdade

Por mais pesquisas, entrevistas e protótipos que você faça, o momento da verdade, ou seja, o momento em que você saberá se o seu produto é, de fato, a solução de um problema de um conjunto de pessoas, é quando ele estiver nas mãos de seus clientes, no contexto onde eles precisam do produto.

Quanto mais tempo você demorar para colocar seu produto na rua, mais tempo demorará para aprender com pessoas reais se você está no caminho certo. E pior, mais passos você certamente estará dando na direção errada.

Você só vai saber se o produto que você fez realmente resolve o problema de algumas pessoas se elas o usarem. Quanto mais tempo demorar para isso acontecer, mais tempo vai levar para saber se ele é ou não é a solução do problema.

E se não for, o que você faz? Conserta, ajusta, muda! Quanto mais cedo você souber que o que você está desenvolvendo não está no caminho certo, melhor, pois menos tempo, energia e dinheiro você desperdiçará indo no caminho errado.

Excesso de funcionalidades

Existe um limite de funcionalidades que o usuário consegue entender. Quando colocamos funcionalidades demais, em vez de criarmos uma solução para o problema do cliente, acabamos criando um novo problema para ele.

Kathy Sierra, reconhecida instrutora de programação e de experiência do usuário, criou um gráfico de funcionalidades que ilustra de forma clara e divertida como a satisfação do usuário diminui à medida que aumentamos a quantidade de funcionalidades de um produto.

Curva de satisfação do usuário como função da quantidade de funcionalidades

Retorno do investimento

Quanto mais tempo seu produto demorar para ter usuários e, consequentemente, clientes que em algum momento pagarão pelo seu produto, mais você terá de investir do seu próprio bolso. Veja a seguir um gráfico típico de retorno de investimento de um produto (ROI).

Enquanto você não o lançar e não tiver receita, tudo o que você terá é custo. Ou seja, você estará na parte de investimento da curva. Isso só muda quando você começar a ter receita e esta for maior do que os custos mensais. Então você entra na área descrita a seguir como rentabilidade mensal. Só depois de alguns meses nessa área é que você terá o retorno do seu investimento. Veja como o caminho é longo.

Retorno do investimento

Agora veja no gráfico adiante, como um atraso de 3 meses em obter receita pode atrasar em 6 meses a obtenção do retorno do investimento. Será que esses 3 meses de atraso em obter receita valem a pena? O que você vai fazer nesses 3 meses realmente compensam 6 meses de atraso no retorno do investimento?

Retorno do investimento postergado

Por outro lado, veja só o que você ganha se conseguir acelerar o desenvolvimento de seu produto e lançá-lo 3 meses antes do planejado. Você ganha 6 meses de retorno do investimento! E a explicação para isso não é só porque você adiantou a entrada de receita, é porque você gastou menos para poder lançar o produto mais rápido. Veja no gráfico a seguir.

Retorno do investimento antecipado

Se você não tem vergonha da sua primeira versão, demorou demais para lançar

Reid Hoffman, fundador do LinkedIn disse certa vez que:

“Se você não tem vergonha da primeira versão do seu produto, você demorou demais para lançar”.

Para ilustrar essa frase, que de certa forma sumariza o valor de lançamento antecipado e frequente, resolvi pegar prints da tela da primeira versão de alguns serviços bem conhecidos.

Facebook 2005
Facebook 2005
Google 1998
Google 1997
Linkedin 2005
Twitter 2006
Locaweb 2002
Conta Azul 2011
Ágil ERP (Conta Azul) 2008
Gympass 2014
Lopes 1997

MMF – Minimal Marketable Feature

Minimal Marketable Feature ou MMF vem de um livro de 2003 chamado Software by Numbers, de Mark Denne e Dra. Jane Cleland-Huang. Neste livro, eles introduzem o conceito de:

Metodologia de Financiamento Incremental (Incremental Funding Methodology – IFM), uma abordagem baseada no ROI (Return on Investment – Retorno do Investimento) para o desenvolvimento de software em que o software é desenvolvido e entregue em blocos cuidadosamente priorizados de funcionalidades valorizadas pelo cliente. Esses blocos são conhecidos como Funcionalidades Mínimas Comercializáveis ou Minimal Marketable Features – MMFs.

É um conceito anterior ao de MVP, que traz a vantagem dessa mentalidade de implementar o mínimo necessário para cada funcionalidade do produto. A diferença básica entre MVP e MMF é que, enquanto MVP fala de um produto mínimo viável, ou seja, precisa de um produto completo, mesmo que mínimo, para poder ser apresentado a possíveis usuários, o MMF traz esse conceito do mínimo para o nível da funcionalidade.

Para ilustrar o MMF, eles usaram um exemplo muito simples de entender: imagine que você tenha que construir um sistema de internet banking na web. Existem muitos recursos e pode levar muitos meses ou até anos para esse produto ser entregue com todos os recursos “obrigatórios”. Ao pensar em termos de MMF, devemos olhar para aqueles recursos “obrigatórios” e descobrir se podemos lançá-los de forma independente, ou seja, se um determinado recurso, se lançado de forma independente, traria algum valor para o cliente. Em um sistema de internet banking pela Web, poderíamos optar por liberá-lo apenas com extrato da conta e nenhum outro recurso. Esse seria um sistema de internet banking muito simples, mas, se lançado assim que estiver pronto, e não depois que alguns outros recursos também estiverem prontos, ele trará valor para o cliente mais cedo. E sempre que você entrega valor ao cliente, você também entrega valor à sua empresa. Além do cliente satisfeito, neste exemplo você provavelmente reduziu o custo que sua empresa tem em servir esses clientes, pois se os usuários não obtiverem seus extratos de conta pela internet, eles certamente usarão outra forma de obter essas informações e provavelmente esta outra forma não é tão econômica quanto o acesso via internet, como ir a uma agência ou a um caixa eletrônico.

Uma funcionalidade mínima comercializável (MMF) é mínima, porque se fosse menor não seria comercializável. E uma MMF é comercializável pois, quando lançada como parte de um produto, as pessoas usam (ou compram) a funcionalidade.

Da próxima vez que você estiver planejando um novo produto ou conjunto de funcionalidades para um produto existente, tente pensar em termos de MMF. Pode trazer muito valor para você, seus clientes e para sua empresa.

Resumindo

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

No próximo capítulo veremos a importância de nos focarmos em entender bem o problema a ser resolvido antes de pensarmos em soluções.

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: