Growth: what is roadmap and OKR?

The roadmap is a very useful tool for product managers. It enables us to plan and communicate the view of the future that you have for your product.

Check out some roadmap examples:

Example of a software roadmap
Another example of a software roadmap
Windows Server Roadmap

The first two examples are short-term roadmaps, that is, they display a few months and the features that are going to be in each version of the software. On the other hand, in the Windows Server roadmap, we see a broader view, without major details but a long-term roadmap, holding almost a decade.

By setting up a roadmap for your product, you must adequate it to your audience. In other words, you must add more or less details, depending on to whom you will present this roadmap.

How frequently should I update the roadmap?

If you are part of a team that uses good practices in software engineering, you are going to be doing frequent deliveries and, by frequently delivering, you will have plenty of feedback from your users about the software and the features you are delivering. This will probably change your roadmap, because when users start to use a new feature, they will make suggestions for your software. However, even if you don’t get any suggestion, just seeing them using it will give you new ideas for your product.

If you are a product manager for hardware — such as a server, a notebook, a smartphone, a tablet, a smartwatch or even the operational system for these devices — your roadmap will be much less flexible. Many decisions will be taken months before your product is ready for the users.

Fortunately, continuous delivery in digital products allows much more flexibility. It is important to have a roadmap for a digital product of at least 12 months. However, this roadmap will frequently change, according to what you and your team will learn with your product’s users and with the way the market reacts to your novelties. Therefore, at each change of course you should update your roadmap and communicate it to everyone involved.

12-month rolling roadmaps

During my time at ContaAzul and now at Gympass my teams and I have been using a roadmap structure that has been very helpful for us to achieve the two main goals of product roadmaps, planning what are the next steps of the product and aligning the view of the product future with the entire organization.

Example of a 12-month rolling roadmap

We call this roadmap structure the 12-month rolling roadmap. I know that some people will comment that having a 12-month roadmap will prevent us from being agile, that we should have no more than 3 months planned ahead, ideally we should have no roadmap and we should only use OKRs. I tend to agree with all these comments. However, my experience has showed me that the need for roadmaps depends a lot on the product development culture maturity of the company. Probably companies like Google and Facebook have such maturity of product development culture that roadmaps are not needed and the product is developed only based on OKRs. This is also the case when we are managing mature products.

However, if you are working on a product in its innovation or growth phase, and your company does not have yet a mature product development culture, roadmaps in general and the 12-month rolling roadmap that I will present here can be very helpful.

The motivation

When a product manager presents to stakeholders a 3-month roadmap, it is not unusual that the product manager gets asked questions like “what about feature X?” or “when will we put more energy on objective Y?”. The answer is normally something in the lines of “it’s planned for future quarters but I believe that what we have planned for the coming quarter are the most important things to work on, do you agree?”. This answer will probably generate some frustration.

If a product manager decides not to use roadmaps and only use OKRs to present her plans for her product to stakeholders, the questions she will get will be in the lines of “how do you intend to reach objective Z?” or “why don’t you do W to get to your objective faster?”

For this reason, we created the 12-month rolling roadmap. It helps product managers communicate the view of the future of their product and, consequently, this will elevate the discussion to a more strategic level. Here’s an example of a 12-month rolling roadmap for a team that takes care of invoice issuance in an ERP product for SMBs.

Elements and how to use the 12-month rolling roadmap

The basic elements that should be in a 12-month rolling roadmap are:

  • Objectives and metrics: it is placed at the top of the slide because this is the most important thing of the roadmap, what you are planning to achieve by doing the things you plan to do and how do you measure that you achieved. From these, you create your OKRs.
  • Deliveries: here we have what is planned to be delivered by each team to achieve the objectives. It’s important to note down when a new team will be hired and onboarded. Normally it takes some time to hire people and have them onboarded with enough knowledge in order to deliver something. The deliveries are boxes of one or more months. That does not mean that delivery will happen only once per month. Teams should be deploying in production every week, every day, every hour if possible. This means that these deliveries are high-level deliveries, composed of many smaller deliveries that are one level down of details from what is shown in the 12-month rolling roadmaps. For those familiar with agile methodologies, think in terms of themes, epics, and stories. In the 12-month rolling roadmap we are at the level of themes and epics, we don’t go to the level of detail of stories. Note that deliveries for the upcoming quarter are in darker green while the others are in lighter green. This is by design, to show that we are more certain of the things that are closer. It is the job of the product manager presenting this roadmap to maintain the upcoming quarter the focus of the discussion. If your stakeholders want to discuss deliveries later in the roadmap, the only discussion that is important is if that delivery should happen in the upcoming quarter and, if so, what should be postponed.
  • Discoveries: the same way you present your deliveries in a timeline, you can present the required discoveries you need to do prior to the deliveries. Again, the result of discovery should not be presented only after one or more months. The discovery team (product manager, product designer and someone from engineering) will be making discoveries and sharing them with stakeholders on a weekly or even daily basis, but a better full picture of the discovery may need more time to be put together. This element is optional.
  • Constraints: if you have any relevant constraint, it is important to be placed here. In this example, the government was rolling out a new invoice layout that should be used since April 2018. For this reason, our invoicing system should be prepared to issue invoices in this new format by then. This element is also optional.

You can add other elements if it makes sense to you, your team, and your stakeholders. At Gympass we are building an integration layer that is enabling us to easily integrate our systems with gym booking and ERP systems as well as with payroll systems. As we build the building blocks of these integration layers, we are getting ready to offer specific types of professional services. For this reason, we created in our 12-month rolling roadmap an element called Professional Services readiness, to show stakeholders when we will be able to do certain types of integrations with our professional services team.

Note that with the 12-month rolling roadmap, when you get questions like “what about feature X?” or “when will we put more energy on objective Y?” or “how do you intend to reach objective Z?” or “why don’t you do W to get to your objective faster?”, it is easier to answer because you have a big picture of what’s coming next.

We named it “rolling roadmap” for a reason. It has to be reviewed regularly. If nothing changes, it should be reviewed at least quarterly, to guarantee it is aligned with the product vision and strategy. If there are changes in the external environment (new regulation, new competitors, etc) or in the internal environment (people leaving the team, change in company strategy, etc.) and these changes need to be dealt immediately, the 12-month rolling roadmap is the perfect tool to help everyone understand the impact of the changes in the objectives and deliveries of the team.

Should I keep a secret about my roadmap?

Many companies publish their roadmaps to users and to the market, while others rather keep them locked away fearing that competitors will copy their steps. I believe that the short-term roadmap (1 to 3 months) must be known by its users, so they can even present some feedback on it.

Regarding the market, you can respond reactively, that is, when asked, you can answer if it is or it is not on your short-term roadmap. The medium and long-term ones (three or more months) are not to be unveiled, not only for keeping them away from competitors, but because there are big chances of changing and, if it’s disclosed publicly, these changes will end up frustrating its users.

Cone of uncertainty

The cone of uncertainty is a concept used in project management that describes the amount of uncertainty through a given project’s lifecycle.

Cone of Uncertainty

In the beginning, very little is known and the uncertainty is high. As we move forward in the project, we learn more and the uncertainty diminishes.

Software researchers concluded that before starting a software development project, the uncertainty might vary from 0 to 4 times of the initially estimated regarding the time and the cost of developing the software.

How to build a roadmap?

After understanding what a roadmap is, the question remaining is: how to build a roadmap? That is, how to define which items are going to be in it and their order? The answer has three elements: the company, the users, and the possibilities.

What are the company’s goals?

The first element a product manager should know in order to build the roadmap is the company’s goals. The main goal of a company is not revenue or profit margin. Revenue and profit are its financial health indexes that can even show if its goals are being reached.

However, sometimes revenue and profit are not necessarily linked to goals. Moreover, these goals can change over time. For instance, in the beginning of any social network, the goal is not revenue but the number of users and the certainty that they will come back. Only after having a considerable base of active users that is reasonable to think of how to profit, whether with users or companies interested in communicating with them. That is why it is important that the product manager knows what the company’s goal is and, from time to time, check if it is still the same.

What do users want?

Knowing what are the company’s goals, the product manager should think of new products or evolve the existing ones in order to reach these goals. To do that, the product manager needs to know:

  • The users: it is necessary to know the users or possible users of your product, and which problems or needs they have that can be solved by your product. There are innumerous tools and methods to get to know your client. Some examples are surveys, interviews, access data analysis, A/B test, prototypes, usability test etc.
  • Context: the context in which your users are in and, specifically, when they use the product. Context is the set of physical conditions and events that surround your user. For instance, your user accessing your product from a desktop or from a smartphone is part of the context.
  • Market and competitors: either direct or indirect competitors. The direct ones are those that deliver the same or a similar product. The indirect competitors are the ones that somehow replace your product. For instance, suppose that you built a tool for managing orders of service for small service providers. One of the main competitors is e-mail, because these small providers can use it instead of using your tool. Or, yet, they can use the phone, paper and pen!

Can we do it?

So, you already know your company’s goals, understood your user and now you defined how your product is going to be, or that new feature that will, at the same time, meet the company’s goals and be useful to your user. Now you need to know if it’s feasible and what would be the cost. It may seem possible of building it, but if it takes too many months and too much money, it may not be worth it. Then you have the conversation with the team that will build the new product or feature; the people from UX and development. They will tell the cost, time-wise or money-wise, and if it’s not acceptable you’ll have to discuss in order to seek alternatives.

Putting everything into one image

After reading what to take into consideration while doing a roadmap, it is possible to translate product management into one image, that we saw in the chapter What is software product management?

Digital product management

In order to build your roadmap, you need to know the company’s goals, users, their needs and problems, and what can be done. With that in hand, you can build your roadmap. However, do not forget that the company’s goals may change, as well as the users’ problems and needs, and what can be done. Therefore, it is essential to make periodic reviews in your roadmap in order to keep it lined up with these three elements.

Roadmap = motivation + metrics

It is common to see roadmaps as a list of features, as depicted in the previous examples. This type of roadmap works well when you have to present it to an audience outside your company, that is, to users and the market.

Having the roadmap as a simple feature list is incomplete. Following are two very important elements to explain why these features are in the roadmap in this priority order.

What’s the motivation?

As previously stated, we should take into account three aspects while building a roadmap:

  • Company’s strategic goals;
  • Problems and needs of the client;
  • Available technology.

These are the inputs that the product manager has to take into consideration while building a roadmap, that is, to define which features to add up to it and in what order. For that reason, for the roadmap that is going to be used internally, in addition to the features themselves, it is important to state the motivation that lead the product manager to put it there. More clients? More revenue? Fewer client requirements asking for support? Increasing engagement? Etc.

Having the feature motivation in the roadmap will help the product manager to set the context for the team that will work on creating these features.

How to measure the result?

Aside from the motivation, the roadmap must also have an indication of how to measure if what motivates the features is being reached. If the motivation is to increase the number of clients, how to measure it? If it is to get more revenue, how to measure it? If it is fewer support requirements, how to measure it? If it is increasing engagement, how to measure it?

It is important to define how to measure if a given feature has accomplished its motivation and effectively measure it. It is very likely that the way of measuring it must be considered while developing the feature. Most likely, it requires adding specific programming code to allow this measurement.

An example

To illustrate the use of motivation plus metrics while building a roadmap, I’ll use an example from Locaweb: an e-mail marketing product for sending e-mails.

If you use e-mail marketing, you know that is necessary to follow some good practices in order to reach a good delivery ratio. First, it is necessary the agreement of the recipients to send them e-mails. After that, it is fundamental to hold a frequency of e-mails. If you send a message once and never again, you are not going to create a relationship with the recipient. Besides, it is important to keep your recipient address list clean, that is, remove an e-mail address that triggers error messages or spam complaints.

Those who don’t follow these simple rules will end up having a low e-mail delivery ratio, will get disappointed with the product, and eventually will no longer use e-mail marketing for thinking that it is ineffective.

Thinking about this, we decided at Locaweb to create the concept of reputation, translated into a percentage that aims to inform the clients how well they are doing while following these good practices. With that, we can educate them regarding the good practices of using e-mail marketing.

Therefore, the feature reputation from Locaweb’s e-mail marketing had:

  • Motivation: to educate clients on good practices of using e-mail marketing so they would reach a higher success rate in their campaigns and, consequently, would not cancel the service;
  • Metrics: the result of this feature is being measured in two ways: amount of deliveries (inbox delivery, opened message ratio, spam complaint ratio) and decrease of cancelling.

OKRs, the future of product roadmaps

Since 2012, we review Locaweb’s product roadmaps every quarter. At the beginning of each quarter, we look back on what was done in the previous quarter, which items were delivered, which weren’t, and what were the reasons for success or failure. Then we plan what to do in the following quarter.

In the middle of 2014, I wrote an article on writing roadmaps including the motivation behind each item in the roadmap and metrics that showed that the motivation was being fulfilled. It was the result of several conversations we had at Locaweb about having the roadmap as a list of items to make every quarter, but not always having clear why we were doing each of those planned items. Since that time we started to make our roadmaps with each item composed of three sub-items: what to do, why it had to be done, and what metric we expected to move when we do that item. However, while we try to make clear the motivation and the metric of each roadmap item, the discussions ended up mainly around the “what to do”.

In the first half of 2015, we heard about a framework called OKR, which means Objectives and Key Results. This framework has been used by Google since its early days and was brought there by John Doerr, an Intel employee, where this framework was created. John Doerr, after leaving Intel, became an investor in technology businesses such as Google, Amazon, Intuit, and Zynga and brought this framework to these companies. Several technology companies today use OKRs. A few more examples are LinkedIn, GoPro, Flipboard, Yahoo!, Amazon, Adobe, Baidu, Dropbox, Facebook, Netflix, and Spotify.

OKR is a framework derived from a management technique called Management by Objectives, a term coined by Peter Drucker in his book The Practice of Management, 1954. Management by Objectives is a process that requires the identification and accurate description of goals to achieve and deadlines for completion and monitoring. This process requires that those involved agree with what you want to achieve and that all of them play their roles for the achievement of the objectives.

How does OKRs work?

There are several articles and videos that explain in detail how OKRs work, so I will make my explanation very brief. OKRs are composed of two parts, a goal (objective) and 2 to 5 key outcomes (key results) indicating that the goal was achieved. For example:

Objective: To have satisfied customers to the point of recommending our services to their friends.

Key Result 1: To maintain 80% of satisfaction survey notes above 8 on a scale from 0 to 10.

Key Result 2: At least 50% of new sales should come from recommendations of existing customers.

The goal does not necessarily need to have numbers. However, key results must always have numbers, i.e., there must be some metric and must say where we are and where we want to be with regards to the metric, that is, the goal we want to achieve with that metric.

It is recommended to have at least two key results. When there is only one key result, we can suffer from what is called the “perverse effect”. For example, suppose the goal is to raise the productivity of the telephone service team. Let’s say we define only one key result, the AHT (average handle time) which is now in 8 minutes and we want it to drop to 2 minutes. One way to achieve this key result is for the attendant to hang up the phone when close to 2 minutes. Of course, this would be bad for the quality of service, but the key result and the goal would be achieved. In this case, to balance the “perverse effect”, another key result is recommended to ensure that customer satisfaction is maintained.

Implementing OKRs at Locaweb

After studying OKR for some time, we realized that it was very similar to what we always wanted to do, focusing more on the motivations and metrics than on the “what to do” itself. The big difference is that in OKRs the “what to do” simply does not exist. It can be discussed when defining each goal and its key results, but “what to do” is not documented and, therefore, it is not committed and can be changed. What matters is the goal and key results that indicate that the goal has been reached.

To help us in this change, we brought Felipe Castro from Lean Performance, a company that specialized in OKR implementation. We brought him in June 2015 and started implementation in the 3rd quarter of 2015 with a series of internal training on OKR, goal setting, metrics, and objectives. In August we made our first training planning session to set OKRs for the month of September. It was a test for us to understand a little better the mechanics of the OKR setting process. In late September we made our first planning session of a full quarter, where we defined the product development and marketing OKRs for the 4th quarter of 2015. In parallel, we continued with the quarterly product planning roadmap based on a list of items to do.

Each team updated their OKRs weekly. Furthermore, we followed the evolution of the roadmap monthly. We have seen throughout these follow-ups that the roadmap items were the tasks that enabled the achievement of the objectives and key results, i.e., there were monitoring tools — OKRs and Roadmaps — for the same job. Throughout these monitoring sessions, we had an epiphany: what if we abandon the traditional roadmap, the list of tasks to do, and focus only on defining and tracking OKRs?

From ToDoers to pointer managers

That’s what we did in the 1st quarter of 2016. The planning was done completely based on goals and metrics that we wanted to move, i.e., the pointers we wanted to manage. We ceased being mere ToDoers, mere executors of tasks, to become pointer managers. Given a goal and a metric that indicates that this objective is being achieved, we decided what to do. In the OKRs review meeting for the 1st quarter of 2016 and planning for the 2nd quarter, no one missed the old roadmap list of tasks to do. Obviously, during the retrospective, each team commented a bit about what they did to move the pointers, but the “what to do” was just a means to achieve a goal, and not the goal itself. And of course, in each OKR planning session, the teams already have a sense of “what they will do” to achieve their goals, but they have the autonomy to decide “what to do” as they please.

OKRs or Roadmaps?

In August 2016, after 11 years leading product development and management at Locaweb, I decided to move to ContaAzul, a SaaS ERP startup at Joinville, a city in the south of Brazil, to help them scale their product development team. When I arrived at ContaAzul, I noticed that they also used OKRs for the entire company, including the product development team. However, besides using OKR, they also used roadmaps and it didn’t seem it would be possible to stop using roadmaps and manage all product development efforts only using OKRs. That made me ponder if OKR can really substitute roadmaps or if there are circumstances where both tools can be used together. And if the latter is true, what are those circumstances.

When discussing this topic with people from the software industry, it became clear to me that the use of a roadmap or OKR depends on the stage of the product in its lifecycle. I discussed the 4 stages of a product lifecycle in the Lifecycle of a software product chapter.

As described in that article, the software product lifecycle has 4 stages:

  • Innovation: from all 4 lifecycle stages of a software product, Innovation is the one that holds the biggest amount of doubts. It is also the stage that holds the biggest number of books. Any book on innovation and startups is helpful when your product is in this stage. The main objective is to create a product that addresses problems and needs of a group of customers. For this reason, during this phase there’s only one Objective, to find product-market fit, and to measure this Objective we can use various Key Results that demonstrate customer engagement and satisfaction. In the Innovation stage we should use neither OKR nor roadmaps. We should use the MVP (Minimum Viable Product) framework of build-measure-learn to reach the Objective of finding product-market fit.
  • Growth: In the growth stage, when the product has been developed and launched, we should worry about how to manage the product during its growth. Since during the innovation phase we built an MVP to reach our Objective of finding product-market fit, our product is quite incomplete, so we should have a roadmap describing which features we will build plus the motivation to build each feature and the metrics that will show us that we are fulfilling the motivation to build each feature, as I described in my article about roadmap. Motivation is another word for Objective and Metrics is the same as Key Results. In the Growth stage we should use Roadmaps together with OKR, since in the Innovation phase we launched an MVP lacking many features that would make the product more complete, and now we need to implement those features.
  • Maturity: After growth, comes maturity. In this phase, our product reached its potential market and consequently doesn’t grow as fast as it grew in the Growth phase. When a product reaches this stage, it has all needed features and there’s no need for a roadmap anymore. In the Maturity stage we should use only OKRs to manage the product development since in this phase we will be optimizing the product to fulfill its Objectives.
  • End of life: After maturity, or when the product is developed but it does not find product-market fit, comes the stage known as the end of life, or sunset, of a software product. In this phase, like in the Maturity phase, a roadmap is not needed since it doesn’t make sense to build any additional features. If your product reached the End of life phase after the Maturity phase, it already has all the features it needs to have. If your product reached the End of life phase right after the Innovation phase because it didn’t find the product-market fit, you should not invest any effort in building any additional features. In the End of life stage we should use only OKRs to manage the product development since in this phase our only Objective is to stop serving the product.

For this reason, it is clear that OKRs substitute Roadmaps in all stages of the product lifecycle except for the Growth stage, where Roadmaps are very helpful to understand where your product is heading, i.e., to understand the future of your product. In the Growth stage, we should use Roadmaps and OKRs in conjunction to manage the product development.

Detailing versus audience

As mentioned at the beginning of this chapter, the roadmap of your software product is your tool to communicate the vision of the future for your product. We know there are different types of targets that will demand different levels of detailing in your roadmap. In which level of detailing should we stand for each type of target?

Detailing versus audience in a roadmap

The picture points out a suggestion of detailing level according to each audience. The first aspect you have to consider is whether the target is internal or external. As previously said, to external targets you will usually talk about features. To internal audiences, your focus will be more on results and metrics than on the feature itself.

The second aspect to consider is the level of detailing you to have to display.

  • General target: in this case, detailing does not have to be high. The ideal is to talk in terms of features and you should disclose the features closer to being delivered.
  • Close clients: for the closest clients, it is possible to show more details, giving a medium-term vision. It is very important to create a good relationship with your close clients. You can guide the vision of your product based on the problems they have, and that your product is willing to solve.
  • Partners: to them it is worth to get into details, especially those who help the product to reach your clients. For instance, the final clients of the Locaweb hosting platform are the companies that host their websites there. However, you have to consider the partners, that is, the developers and agencies that develop these sites. In this case, you should continue to depict the roadmap as a list of features.
  • CEOs, vice-presidents and directors: at this point, we move to internal audience. This target group might be interested in the feature list, but they really want to know the motivation for these functionalities on the roadmap.
  • Sales and marketing: for the sales and marketing teams, it is necessary to get into a little more details. For sales, details are important because they may have already identified the market’s demand, and for marketing the need of more details comes from the publicity work they will do.
  • Product marketing: this group is practically the fourth element of that core team I mentioned in the chapter What is software product management? They must participate very closely of the product’s development, and must know the whole motivation and the metrics of the features in roadmap.
  • Costumer service: this group does not have to know a lot about the motivation of the features as many of the internal groups, but it is the one that needs to know more details of these future features, for it communicates with their clients on a daily basis.
  • Engineering and UX: they are part of the product’s core team. They need all the details, motivations and metrics in order to do their job.

Roadmap or backlog?

A question that I frequently hear is: what is the difference between roadmap and backlog? The roadmap is your map or guide, that is, the things you have to do; backlog is the term used in agile methodologies for your “record of things to do”. So, these terms are equivalent and can be used interchangeably.

In the next chapter, we’ll approach roadmap prioritizing techniques.

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 on their titles above.

Mentoring and advice on digital product development

I’ve been helping several companies extract more value and results from their digital products. Check here how I can help you and your company.

Crescimento: O que é roadmap e OKR?

O roadmap é uma ferramenta muito útil para gestores de produtos. Com ele, é possível planejar e comunicar a visão de futuro que você tem para o seu produto. Veja a seguir alguns exemplos de roadmap:

Exemplo de roadmap de software
Outro exemplo de roadmap de software
Roadmap do Windows Server

Os dois primeiros exemplos são roadmaps de curto prazo, ou seja, exibem alguns meses e as funcionalidades que estarão em cada versão do software. Por outro lado, no roadmap do Windows Server, vemos uma visão mais abrangente, sem grandes detalhes, mas sendo um roadmap de longo prazo, com quase uma década.

Ao preparar o roadmap de seu produto, você deve adequá-lo à sua audiência. Isto é, você deve colocar mais ou menos detalhes, dependendo de para quem você apresentará esse roadmap.

De quanto em quanto tempo tenho de atualizar o roadmap?

Se você está em um time que utiliza boas práticas de engenharia de software, vocês estarão fazendo entregas frequentes e, ao fazer entregas frequentes, você terá bastante feedback de seus usuários sobre o software e as funcionalidades que vocês estão entregando. Isso provavelmente vai mudar seu roadmap, pois quando seus usuários começam a usar uma nova funcionalidade, eles terão novas sugestões para o seu software. Mas, mesmo que você não receba nenhuma sugestão, ao vê-los utilizando, você provavelmente terá novas ideias para seu produto.

Se você for um gestor de um produto de hardware – como um servidor, um notebook, um smartphone, um tablet, ou mesmo um sistema operacional para rodar nesses aparelhos –, seu roadmap será bem menos flexível. Muitas decisões deverão ser tomadas meses antes de o produto estar na frente do usuário.

Felizmente, as entregas contínuas em produtos web permitem muito mais flexibilidade. É interessante ter um roadmap de um produto web de pelo menos 12 meses. Entretanto, não se esqueça de que esse roadmap mudará frequentemente, de acordo com o que você e seu time aprenderem com os usuários do seu produto web e com a forma como o mercado reage às suas novidades. Por isso, a cada mudança de rumo, atualize seu roadmap e comunique todas as pessoas interessadas.

Roadmaps contínuos de 12 meses

Durante meu período na Conta Azul e agora no Gympass, minhas equipes e eu usamos uma estrutura de roadmap que nos ajudou muito a alcançar os dois principais objetivos dos roadmaps de produtos, planejando quais seriam as próximas etapas do produto, e alinhando a visão do futuro do produto com toda a organização.

Exemplo de um roadmap contínuo de 12 meses

Chamamos essa estrutura de roadmap contínuo de 12 meses. Eu sei que algumas pessoas comentaram que o fato de ter um roadmap de 12 meses nos impedirá de ser ágeis, que não devemos ter mais de três meses planejados, na verdade não devemos ter um roadmap e devemos usar apenas OKRs. Costumo concordar com todos esses comentários. No entanto, minha experiência me mostrou que a necessidade de roadmaps depende muito da maturidade da cultura de desenvolvimento de produtos da empresa. Provavelmente, empresas como Google e Facebook têm uma maturidade tão grande na cultura de desenvolvimento de produtos que os roadmaps não são necessários e o produto é desenvolvido apenas com base em OKRs. Esse também é o caso quando gerimos produtos consolidados.

No entanto, se você estiver trabalhando em um produto em sua fase de inovação ou crescimento, e sua empresa ainda não possui uma cultura madura de desenvolvimento de produtos, os roadmaps em geral e o roadmap contínuo de 12 meses que apresentarei aqui podem ser muito úteis.

A motivação

Quando um gestor de produto apresenta às partes interessadas um roadmap de três meses, não é incomum que ele receba perguntas como “E o recurso X?” ou “Quando colocaremos mais energia no objetivo Y?”. A resposta é normalmente algo como “Está planejado para os trimestres seguintes, mas acredito que o que planejamos para o próximo trimestre são as coisas mais importantes para se trabalhar, concorda?”. E provavelmente provocará uma certa frustração.

Se um gestor de produto decidir não usar roadmaps e usar apenas OKRs para apresentar seus planos para o produto às partes interessadas, as perguntas que ele receberá serão em torno de “Como você pretende alcançar o objetivo Z?” ou “Por que você não faz W para alcançar seu objetivo mais rapidamente?”

Por esse motivo, criamos o roadmap contínuo de 12 meses. Auxilia os gestores de produto a comunicar a visão do futuro de seu produto e, consequentemente, isso elevará a discussão a um nível mais estratégico. Veja um exemplo de um roadmap contínuo de 12 meses para uma equipe que cuida da emissão de faturas em um produto de ERP para pequenas e médias empresas.

Elementos e como usar o roadmap contínuo de 12 meses

Os elementos básicos que devem constar em um roadmap contínuo de 12 meses são:

  • Objetivos e métricas: são colocados na parte superior do slide, porque essa é a coisa mais importante do roadmap, o que você planeja alcançar fazendo as coisas que planeja fazer, e como mensurar o que alcançou. A partir disso, você cria seus OKRs.
  • Entregas: aqui temos o que está planejado para ser entregue por cada equipe para que os objetivos sejam atingidos. É importante registrar quando uma nova equipe será contratada e integrada. Normalmente, leva algum tempo para contratar pessoas e incorporá-las com conhecimento suficiente para fornecer algo. As entregas são caixas de um ou mais meses. Isso não significa que a entrega acontecerá apenas uma vez por mês; as equipes devem estar implantando a produção toda semana, todos os dias, a cada hora, se possível. Isso significa que essas entregas são de alto nível, compostas por muitas entregas menores, com um nível abaixo dos detalhes do que é mostrado nos roadmaps contínuos de 12 meses. Para aqueles familiarizados com metodologias ágeis, pensem em termos de temas, épicos e histórias. No roteiro de 12 meses, estamos no nível de temas e épicos, e não vamos ao nível de detalhe das histórias. As entregas para o próximo trimestre estão em verde mais escuro, enquanto as outras estão em verde mais claro. Isso ocorre por projeto, para mostrar que estamos mais convictos das coisas que estão mais próximas. O trabalho do gestor de produto que apresenta este roadmap contínuo é manter o próximo trimestre no foco da discussão. Se as partes interessadas quiserem discutir as entregas posteriormente no roadmap contínuo, a única discussão importante é se essa entrega deve ocorrer no trimestre seguinte e, se houver, o que deve ser adiado.
  • Descobertas: da mesma maneira que você apresenta suas entregas em uma linha do tempo, pode também apresentar as descobertas necessárias que precisa fazer antes das entregas. Novamente, o resultado da descoberta não deve ser apresentado somente após um ou mais meses. A equipe de descoberta (gestor de produto, designer de produto e alguém de engenharia) fará descobertas e as compartilhará com os participantes semanalmente ou até mesmo diariamente, mas uma imagem mais completa da descoberta pode levar mais tempo para ser elaborada. Este elemento é opcional.
  • Restrições: se você tiver alguma restrição relevante, é importante que seja colocada aqui. Neste exemplo, o governo estava lançando um novo formato de fatura que deveria ser usado a partir de abril de 2018. Por esse motivo, nosso sistema de faturamento deveria estar preparado para emitir faturas neste novo formato até então. Este elemento também é opcional.

Você pode adicionar outros elementos, se fizer sentido para você, sua equipe e as partes interessadas. Na Gympass, estamos construindo uma camada de integração que nos permite integrar facilmente nossos sistemas aos sistemas de reserva de academias e ERP, bem como aos sistemas de folha de pagamento. À medida que construímos os blocos de construção dessas camadas de integração, estamos nos preparando para oferecer tipos específicos de serviços profissionais. Por esse motivo, criamos em nosso roadmap contínuo de 12 meses um elemento chamado Prontidão para Serviços Profissionais, para mostrar às partes interessadas quando poderemos fazer certos tipos de integrações com nossa equipe de serviços profissionais.

Observe que, com o roadmap contínuo de 12 meses, quando você recebe perguntas como “E o recurso X?” ou “Quando colocaremos mais energia no objetivo Y?” ou “Como você pretende alcançar o objetivo Z?” ou “Por que você não faz W para alcançar seu objetivo mais rapidamente?”, é mais fácil responder porque você tem uma visão geral do que está por vir.

Nós o denominamos “roadmap contínuo” por um motivo. Tem que ser revisto regularmente. Se nada mudar, deve ser revisado pelo menos trimestralmente, para garantir que esteja alinhado à visão e estratégia do produto. Se houver mudanças no ambiente externo (nova regulamentação, novos concorrentes etc.) ou no ambiente interno (pessoas saindo da equipe, mudança na estratégia da empresa etc.) e essas mudanças precisarem ser tratadas imediatamente, o roadmap contínuo de 12 meses é a ferramenta perfeita para ajudar todos a entender o impacto das mudanças nos objetivos e nas entregas da equipe.

Devo guardar segredo sobre meu roadmap?

Muitas empresas publicam seus roadmaps para os usuários e para o mercado, enquanto outras preferem guardá-los a sete chaves, temendo que concorrentes copiem seus passos. Acredito que o roadmap de curto prazo (1 a 3 meses) deve ser conhecido pelos seus usuários, até para que eles possam dar feedback sobre ele.

Já o mercado, você pode responder de forma reativa. Quando perguntado, você pode responder se está ou não no seu roadmap de curto prazo. Já o de médio e longo prazo (3 ou mais meses), não faz sentido ser divulgado, nem tanto para guardar segredo de seus concorrentes, mas porque há grandes chances de ele mudar e, se ele for público, essas mudanças acabarão frustrando seus usuários.

Cone da incerteza

O cone da incerteza é um conceito usado em gestão de projetos que descreve a quantidade de incerteza ao longo da vida de um projeto.

Cone da incerteza

No começo, pouco se sabe e a incerteza é grande. À medida que progredimos no projeto, aprendemos mais e a incerteza diminui. Pesquisadores da indústria de software chegaram a concluir que, antes do início de um projeto de desenvolvimento de software, a incerteza pode variar de 4 vezes a até 1/4 do inicialmente estimado quanto ao tempo e ao custo de desenvolver esse software.

Como fazer um roadmap?

Após aprender o que é um roadmap, a pergunta que fica é: como fazer um roadmap? Como definir que itens vão nele e em qual ordem? A resposta é composta de três elementos: a empresa, os usuários e o que dá para fazer.

Quais os objetivos da empresa? O primeiro elemento que um gestor de produtos deve conhecer para fazer o roadmap são os objetivos da empresa. O principal objetivo de uma empresa não é receita ou margem. Receita e margem são indicadores da sua saúde, que podem até mostrar se seus objetivos estão sendo atingidos.

Contudo, algumas vezes receita e margem não estão necessariamente atreladas aos objetivos. Aliás, esses objetivos costumam mudar com o tempo. Por exemplo, no começo de qualquer rede social, o objetivo não é receita, mas sim obter a maior quantidade de usuários e garantir que estes retornem. Somente depois de ter uma base considerável de usuários ativos é que faz sentido pensar em como obter receita, quer seja dos usuários, quer seja de empresas interessadas em falar com eles. Por isso, é importante o gestor de produtos saber qual o objetivo da mpresa e, periodicamente, validar se ele continua o mesmo.

O que os usuários querem? Sabendo quais os objetivos da empresa, o gestor de produtos precisa pensar em novos produtos ou em evoluir produtos existentes para atender a esses objetivos. Para fazer isso, ele precisa conhecer:

  • Seus usuários: é preciso conhecer os usuários ou possíveis usuários de seu produto, e quais problemas ou necessidades eles têm que seu produto pode resolver. Existem inúmeras ferramentas e métodos para conhecer o cliente. Alguns exemplos são pesquisa, entrevistas, análise de dados de acesso, teste A/B, protótipos, teste de usabilidade etc.
  • Contexto: o contexto em que seus usuários estão inseridos no dia a dia e, especificamente, quando usam o produto. O contexto é o conjunto de condições físicas e de eventos que circundam seu usuário. Por exemplo, seu usuário acessar seu produto de um desktop ou de um smartphone faz parte do contexto.
  • Mercado e concorrentes: tanto concorrentes diretos como indiretos. Os concorrentes diretos são aqueles que entregam o mesmo produto ou um produto similar. Já os indiretos são aqueles que de alguma forma substituem o seu produto. Por exemplo, suponha que você fez uma ferramenta de gestão de ordens de serviço para pequenos prestadores de serviços. Um dos principais concorrentes é o e-mail, pois esses pequenos prestadores podem usá-lo em vez de usar sua ferramenta. Ou ainda, podem usar telefone, papel e caneta!

Dá para fazer? Muito bem, você já conhece os objetivos da empresa, entendeu o seu usuário e agora definiu como vai ser seu produto ou aquela nova funcionalidade que vai, ao mesmo tempo, atender os objetivos da empresa e ser útil para o seu usuário. Agora, você precisa saber se dá para fazer e qual seria o custo. Pode até ser que seja possível fazer, mas se demorar muitos meses e custar muito, pode ser que não valha a pena. Aí entra a conversa com o time que vai produzir o novo produto ou a nova funcionalidade; é o pessoal de UX e de desenvolvimento. São eles que dirão o custo, tanto em tempo quanto em dinheiro e, se ele não for aceitável, vocês terão de conversar para buscar alternativas.

Traduzindo tudo isso em uma imagem

Após ler o que é preciso levar em conta ao fazer um roadmap, dá para traduzir gestão de produtos em uma imagem, que já vimos no capítulo O que é gestão de produtos de software?:

Gestão de produtos de software

Para fazer seu roadmap, você precisa conhecer os objetivos da empresa, os usuários, suas necessidades e problemas, e o que dá para fazer. Com isso em mãos, você consegue construir seu roadmap. Mas não se esqueça de que os objetivos da empresa podem mudar, como também os problemas e necessidades de seus usuários, e o que é possível fazer. Por isso, é fundamental fazer revisões periódicas de seu roadmap para mantê-lo sempre em linha com esses 3 elementos.

Roadmap = motivação + métrica

É comum ver roadmaps como uma lista de funcionalidades, conforme ilustrado nos exemplos anteriores. Esse tipo de roadmap funciona bem quando você estiver apresentando-o para uma audiência externa à sua empresa, ou seja, para os usuários e para o mercado em geral.

Ter o roadmap como uma simples lista de funcionalidades está incompleto. A seguir, dois elementos muito importantes para explicar por que essas funcionalidades estão no roadmap nessa ordem de prioridade.

Qual a motivação?

Como dito anteriormente, devemos levar em conta 3 aspectos ao fazer um roadmap:

  • Objetivos estratégicos da empresa;
  • Problemas e necessidades do cliente;
  • Tecnologia disponível.

Esses são os insumos que o gestor de produtos tem de levar em conta ao construir um roadmap, para definir quais funcionalidades colocar nele e em que ordem. Por esse motivo, para o roadmap que será usado para comunicação interna, além da funcionalidade propriamente dita, é importante constar a motivação que levou o gestor de produtos a colocá-la lá. Mais clientes? Mais receita? Menos contatos de cliente pedindo suporte? Aumentar o engajamento? Etc.

Ter a motivação da funcionalidade no roadmap vai ajudar o gestor de produtos a setar o contexto para o time que trabalhará no desenvolvimento dessa funcionalidade.

Como medir o resultado?

Além da motivação, o roadmap deve também ter alguma indicação de como medir se o que motivou a funcionalidade está sendo atingido. Se a motivação for aumentar o número de clientes, como será medido esse aumento de clientes? Se for obter mais receita, como será medido esse aumento de receita? Se for menos contato de suporte, como será medida essa diminuição? Se for aumentar o engajamento, como isso será medido?

É importante definir como medir se uma determinada funcionalidade cumpriu a sua motivação, e efetivamente fazer essa medição. É muito provável que a forma de fazer essa medição deva ser considerada no desenvolvimento da funcionalidade, pois pode haver a necessidade de incluir código de programação específico para permitir essa medida.


Para ilustrar o uso de motivação mais métrica na construção de um roadmap, usarei um exemplo da Locaweb. Temos um produto de e-mail marketing que serve para fazer envio de e-mails.

Quem usa e-mail marketing sabe que é preciso seguir algumas boas práticas para conseguir uma boa taxa de entrega de e-mails disparados. Primeiro, é preciso ter o consentimento do destinatário para poder enviar e-mails para ele. Em seguida, é fundamental ter uma frequência de envio. Se enviar uma mensagem uma única vez e nunca mais mandar, você não está criando um relacionamento com o destinatário. Além disso, é importante manter sua lista de destinatários limpa. Sempre que receber mensagens de erro ou reclamação de spam de alguém, esse endereço deve ser removido de sua lista.

Quem não seguir essas regras simples acabará tendo uma taxa baixa de entrega de e-mails, vai se decepcionar com o produto e, eventualmente, deixará de usar o e-mail marketing por achá-lo ineficaz.

Pensando nisso, decidimos na Locaweb criar o conceito de “reputação” na forma de um percentual que tem por objetivo dizer ao cliente quão bem ele está seguindo essas boas práticas. Com isso, conseguimos educá-los sobre as boas práticas de envio de e- mail marketing.

Sendo assim, a funcionalidade “reputação” do e-mail marketing da Locaweb teve:

  • Motivação: educar os clientes sobre boas práticas de envio de e-mail marketing para que eles obtivessem maior taxa de êxito em suas campanhas e, consequentemente, não cancelassem o serviço.
  • Métrica: o resultado dessa funcionalidade está sendo medido de duas formas: quantidade de entregas (entregas no inbox, taxa de abertura de e-mails, taxa de reclamação de envio de spam) e diminuição de cancelamentos.

OKRs, o futuro dos roadmaps

Desde 2012, tínhamos na Locaweb uma mecânica de revisar o roadmap a cada trimestre. No início de cada trimestre, fazíamos uma retrospectiva sobre o que foi feito no trimestre anterior, quais itens foram entregues, quais não foram e quais as razões de sucesso ou insucesso. Em seguida, planejamos o que fazer no trimestre seguinte.

Em meados de 2014, escrevi um artigo sobre como escrever roadmaps, incluindo a motivação por trás de cada item no roadmap e métricas que mostravam que a motivação estava sendo cumprida. Foi o resultado de várias conversas que tivemos na Locaweb sobre ter o roadmap como uma lista de itens a fazer a cada trimestre, mas não estar sempre clara a razão de estarmos fazendo cada um daqueles itens planejados. Desde aquela época, começamos a experimentar fazer nossos roadmaps onde cada item deveria ser composto de 3 subitens: o que fazer, por que aquilo tinha de ser feito e qual a métrica que esperávamos mexer ao fazermos aquele item. Contudo, apesar de tentarmos deixar claro a motivação e a métrica de cada item do roadmap, as discussões acabavam girando mais em torno de “o que fazer”.

No primeiro semestre de 2015, ouvimos falar de um framework chamado OKR, que significa Objectives and Key Results. Esse framework é usado no Google desde seu início e foi trazido para lá por John Doerr, um funcionário da Intel, empresa na qual esse framework foi criado. John Doerr, após sair da Intel, se tornou investidor em negócios de tecnologia tais como Google, Amazon, Intuit e Zynga, e acabou levando esse framework para essas empresas. Várias empresas de tecnologia hoje usam OKRs. Mais alguns exemplos são LinkedIn, GoPro, Flipboard, Yahoo!, Amazon, Adobe, Baidu, Dropbox, Facebook, Netflix e Spotify.

OKR é um framework derivado de uma técnica de gestão chamada de Administração por Objetivos, termo criado por Peter Drucker em seu livro The Practice of Management, de 1954. A Administração por Objetivos consiste em um processo que requer a identificação e descrição precisas de objetivos a atingir e prazos para conclusão e monitorização. Tal processo exige que as pessoas envolvidas concordem com o que se pretende atingir no futuro e que todos desempenharão as suas funções em função dos objetivos.

Como funcionam os OKRs?

Existem vários artigos e vídeos que explicam em detalhes como funcionam os OKRs, por isso farei uma explicação sucinta. Os OKRs são compostos de duas partes: um objetivo e de 2 a 5 resultados-chaves (key results) que indicam que o objetivo foi atingido. Por exemplo:

  • Objetivo: ter clientes satisfeitos ao ponto de recomendar nossos serviços aos seus amigos.
  • Key Result 1: manter 80% das notas de pesquisa de satisfação acima de 8, em uma escala de 0 a 10.
  • Key Result 2: pelo menos 50% das novas vendas devem vir de recomendações de clientes existentes.

O objetivo não precisa necessariamente ter números. Já os key results devem obrigatoriamente ter algum número, ou seja, devem ser alguma métrica e devem dizer onde se está e onde se quer chegar com a métrica. Isto é, qual é a meta que queremos atingir com aquela métrica.

Recomenda-se ter pelo menos 2 key results, pois quando há apenas um key result, pode haver o chamado “efeito perverso”. Por exemplo, suponha que o objetivo seja aumentar a produtividade do time de atendimento telefônico e que seja definido um único key result que seria o TMA (tempo médio de atendimento), que hoje está em 8 minutos e deve cair para 2 minutos. Uma forma de se atingir esse resultado-chave é simplesmente o atendente desligar o telefone quando estiver próximo de dar 2 minutos de ligação. Claro que isso seria péssimo para a qualidade do serviço, mas o key result e o objetivo seriam atingidos. Nesse caso, para balancear o “efeito perverso”, é recomendável ter mais um key result que garanta que a satisfação do cliente que estiver sendo atendido se mantenha.

Implementando OKRs na Locaweb

Após estudarmos OKR por algum tempo, chegamos à conclusão de que ele era muito parecido com o que sempre quisemos fazer: nos focarmos mais nas motivações e métricas do que no “o que fazer” propriamente dito. A grande diferença é que, nos OKRs, o “o que fazer” simplesmente não entra. Ele pode ser discutido quando se define cada objetivo e seus respectivos resultados-chaves, mas o “o que fazer” não é documentado e, por isso, não vira um compromisso e pode ser mudado. O que importa é o objetivo e os resultados-chaves que indicam que o objetivo foi atingido.

Para nos ajudar nessa mudança, chamamos o Felipe Castro, da Lean Performance, consultoria especializada em implementação de OKR. Chamamos em junho de 2015 e começamos a implementação no 3o trimestre de 2015, com uma série de treinamentos internos sobre OKR, definição de objetivos, métricas e metas. Em agosto, fizemos uma sessão de planejamento “café- com-leite” para definir OKRs para o mês de setembro. Foi apenas um teste para podermos entender um pouco melhor a mecânica do processo de definição de OKR. No final de setembro, fizemos nossa primeira sessão de planejamento de um trimestre completo, em que definimos os OKRs do 4o trimestre de 2015 para os times de desenvolvimento e marketing de produtos da Locaweb. Em paralelo, continuamos com o planejamento trimestral de roadmap de produtos baseado em itens a fazer.

Cada time atualizava seus OKRs semanalmente. Além disso, acompanhávamos a evolução do roadmap mensalmente. Vimos ao longo desses acompanhamentos que os itens do roadmap eram as tarefas que habilitavam o atingimento dos objetivos e dos resultados chave, isto é, havia um acompanhamento duplo para o mesmo trabalho. Ao longo desse acompanhamento, surgiu a ideia: que tal abandonarmos o roadmap tradicional, da lista de tarefas a fazer, e focarmos apenas em definir e acompanhar OKRs?

De tarefeiros a gestores de ponteiros

Foi isso o que fizemos no planejamento de 1o trimestre de 2016. O planejamento foi feito totalmente baseado em objetivos e em métricas que queríamos mexer, os ponteiros que queríamos gerir. Deixamos de ser meros tarefeiros, meros executores de tarefas, para nos tornarmos gestores de ponteiros. Dado um objetivo e uma métrica que indica que esse objetivo está sendo atingido, decidimos o que vamos fazer. Na reunião de revisão dos OKRs do 1o trimestre de 2016 e de planejamento dos OKRs do 2o trimestre, ninguém sentiu falta da lista de tarefas a fazer do antigo roadmap. Obviamente, durante a retrospectiva cada time comentou um pouco sobre o que fez para tentar mexer os ponteiros, mas o “o que fazer” passou a ser apenas um meio para se atingir um objetivo, e não mais o objetivo em si. E é claro que, em cada sessão de planejamento de OKRs, os times já têm uma noção de “o que vão fazer” para atingir seus objetivos, mas eles têm autonomia para decidir esse “o que fazer” como quiserem.

OKRs ou roadmaps?

Em agosto de 2016, depois de 11 anos liderando o desenvolvimento e gestão de produtos na Locaweb, decidi me mudar para a Conta Azul, uma startup de ERP SaaS em Joinville, cidade no sul do Brasil, para ajudá-los a escalar sua equipe de desenvolvimento de produtos. Quando cheguei na Conta Azul, notei que eles também usavam OKRs para toda a empresa, incluindo a equipe de desenvolvimento de produtos. No entanto, além de usar o OKR, eles também usavam roadmaps e não parecia possível parar de usá-los e gerir todos os esforços de desenvolvimento de produtos usando apenas OKRs. Isso me fez refletir se o OKR pode realmente substituir roadmaps ou se existem circunstâncias em que ambas as ferramentas podem ser usadas juntas. E se isto for verdadeiro, quais são essas circunstâncias.

Ao discutir esse tópico com pessoas da indústria de software, ficou claro para mim que o uso do roadmap ou do OKR depende do estágio do produto em seu ciclo de vida. Eu discuti sobre os quatro estágios de um ciclo de vida do produto no capítulo Ciclo de vida de um produto de software.

Conforme descrito nesse artigo, o ciclo de vida do produto de software possui 4 estágios:

  • Inovação: das quatro etapas do ciclo de vida de um produto de software, a inovação é a que detém a maior quantidade de dúvidas. É também a etapa sobre a qual possui o maior número de livros. Qualquer livro sobre inovação e startups é útil quando o seu produto está nesta fase. O objetivo principal é criar um produto que atenda aos problemas e necessidades de um grupo de clientes. Por esse motivo, durante esta fase, há apenas um objetivo, encontrar a adequação do produto ao mercado, e para medir esse objetivo, podemos usar vários key results que demonstram o envolvimento e a satisfação do cliente. Na etapa da Inovação, não devemos usar OKR nem roadmaps. Devemos usar a estrutura MVP (Minimum Viable Product) do construir-medir-aprender para atingir o objetivo de encontrar a adequação do produto ao mercado.
  • Crescimento: na fase de crescimento, quando o produto foi desenvolvido e lançado, devemos nos preocupar em como gerir o produto durante o seu crescimento. Uma vez que na etapa de inovação construímos um MVP para atingir nosso objetivo de encontrar a adequação do produto ao mercado, nosso produto está bastante incompleto; portanto, devemos ter um roadmap descrevendo quais funcionalidades criaremos, mais a motivação para criar cada funcionalidade e as métricas que serão adotadas para nos mostrar que estamos cumprindo a motivação de criar cada funcionalidade, como descrevi no meu artigo sobre o roadmap. Motivação é outra palavra para Objetivo, e Métrica é o mesmo que key results. Na etapa de crescimento, devemos usar os roadmaps juntamente com o OKR, pois na fase de inovação lançamos um MVP sem muitas funcionalidades que tornariam o produto mais completo, e agora precisamos implementá-las.
  • Maturidade: após o crescimento, vem a maturidade. Nesta etapa, nosso produto atingiu seu mercado potencial e, consequentemente, não cresce tão rápido quanto na etapa Crescimento. Quando um produto chega a esse estágio, possui todos os recursos necessários e não há mais necessidade de um roadmap. Na etapa Maturidade, devemos usar apenas OKRs para gerir o desenvolvimento do produto, pois nesta fase otimizaremos o produto para cumprir seus Objetivos.
  • Fim da vida útil: após a maturidade, ou quando o produto é desenvolvido mas não se encaixa no mercado, chega a etapa conhecida como fim da vida útil ou pôr do sol de um produto de software. Nesta etapa, como na etapa Maturidade, não é necessário um roadmap, pois não faz sentido criar funcionalidades adicionais. Se o seu produto atingiu a etapa Fim da vida útil após a etapa Maturidade, ele já possui todas as funcionalidades necessárias. Se o seu produto atingiu essa etapa logo após a etapa Inovação, porque não encontrou o mercado adequado, você não deve investir nenhum esforço na construção de funcionalidades adicionais. Na etapa Fim da vida útil, devemos usar apenas OKRs para gerir o desenvolvimento do produto, pois nesta fase nosso único objetivo é parar de servir o produto.

Por esse motivo, fica claro que os OKRs substituem os roadmaps em todas as etapas do ciclo de vida do produto, exceto na etapa Crescimento, onde os roadmaps são muito úteis para entender para onde o produto está indo, o futuro do seu produto. Na etapa Crescimento, devemos usar roadmaps e OKRs em conjunto para gerir o desenvolvimento do produto.

Detalhamento vs. audiência

Como dito no início deste capítulo, o roadmap do seu produto de software é a sua ferramenta para comunicar a visão de futuro que você tem para o seu produto. Só que sabemos que existem diferentes públicos que precisarão de diferentes níveis de detalhamento do seu roadmap. Em qual nível de detalhamento devemos entrar para cada público?

Detalhamento vs. audiência de um roadmap

A figura dá uma sugestão de nível de detalhamento de acordo com cada audiência. O primeiro aspecto em que você tem de pensar é se o público é interno ou externo. Como disse anteriormente, para públicos externos, você normalmente falará de funcionalidades. Já com públicos internos, seu foco deverá ser mais em funcionalidade e métrica do que na funcionalidade em si.

O segundo aspecto a se preocupar é com o nível de detalhamento que você precisa dar.

  • Público em geral: para eles, o detalhamento não precisa ser grande. O ideal é falar em termos de funcionalidades e você pode só comentar as funcionalidades de destaque que estão mais próximas de serem entregues.
  • Clientes próximos: para os clientes mais próximos, já é possível dar um pouco mais de detalhes, dando uma visão de médio prazo. Com esses clientes, é importante criar uma boa relação para que eles lhe ajudem a direcionar a visão de seu produto baseado nos problemas que eles têm e que seu produto se propõe a resolver.
  • Parceiros: com eles, vale a pena entrar em mais detalhes, principalmente aqueles que ajudam o produto a chegar ao cliente. Por exemplo, o produto de hospedagem de sites da Locaweb tem as empresas que hospedam seus sites na Locaweb como clientes finais, mas tem também os parceiros que são os desenvolvedores e agências que desenvolvem esses sites. Aqui devemos continuar falando em roadmap como lista de funcionalidades.
  • CEOs, vice-presidentes e diretores: nesse ponto, movemos para o público interno. Para esse público, tão ou mais importante do que saber quais funcionalidades vêm pela frente é saber a motivação de essas funcionalidades estarem no roadmap. Para eles, essa visão pode ser bem macro.
  • Vendas e marketing: já para os times de marketing e vendas, é preciso entrar em um pouco mais de detalhes. Para vendas, os detalhes são importantes pois eles podem já ter identificado a demanda no mercado e, para marketing, a necessidade de mais detalhes vem do trabalho de divulgação que farão.
  • Marketing de produtos: esse grupo é praticamente o quarto elemento daquele core team que comentei no capítulo O que é gestão de produtos de software?. Eles devem participar muito próximo do desenvolvimento do produto, e devem conhecer toda a motivação e as métricas das funcionalidades que estão no roadmap.
  • SAC: esse grupo talvez não precise saber tanto sobre a motivação das funcionalidades quanto os outros grupos internos, mas ele, sem dúvida, é o que precisa conhecer mais detalhes dessas funcionalidades futuras, pois eles falaram diariamente com os seus clientes.
  • Engenharia e UX: fazem parte do core team do produto. Precisam de todos os detalhes, motivações e métrica para poderem fazer seu trabalho.

Roadmap ou backlog?

Por fim, uma pergunta que ouço com frequência é: qual a diferença entre roadmap e backlog? Roadmap é o seu “mapa da estrada”, as coisas que você tem de fazer; já backlog é o termo usado em metodologias ágeis para o seu “registro de coisa a fazer”. Esses termos são equivalentes e podem ser usados como sinônimos.

Gestão de produtos digitais

Este artigo é mais um capítulo 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:

Mentoria e aconselhamento em desenvolvimento de produtos digitais

Tenha ajudado várias empresas a extrair mais valor e resultados de seus produtos digitais. Veja aqui como posso ajudar você e a sua empresa.


Neste capítulo, vou falar das cerimônias que costumo usar com os times que eu lidero. Essas cerimônias com diferentes stakeholders têm por objetivo planejamento, alinhamento e gestão de expectativas. Saliento que essa lista não é definitiva, ou seja, a depender da empresa e do contexto, pode ser interessante criar outras, e algumas das cerimônias listadas aqui podem não ser necessárias. Falarei sobre reuniões 1:1 (one on one ou one to one), reuniões de liderança, reuniões de All-Hands, Product Council, Product Update e reunião de estrutura de time.

Reuniões de 1:1

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

1:1 com liderados

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

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

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

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

1:1 com sua líder

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

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

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

1:1 com outras pessoas

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

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

Reuniões do time de liderança

Reuniões do time de liderança são as reuniões que o head de produto faz com os seus liderados diretos. Além dos liderados diretos, é importante ter a pessoa de RH que está dedicada a ajudar o seu time. Se não tiver alguém dedicado de RH, traga a pessoa mais sênior do RH que tem estado mais próxima do time de desenvolvimento de produto.

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

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

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

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

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

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

Reunião de All-Hands

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

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

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

Product Council

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

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

Exemplo de 12-month rolling roadmap

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

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

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

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

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

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

Product Council com clientes

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

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

Product Update

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

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

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

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

Reunião de estrutura de time

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

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


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

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

Liderança de produtos digitais

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

Feedback e avaliação de desempenho

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


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

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

Características de uma boa gestora de produtos

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

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

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

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

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

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

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

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

Gestor de produtos precisa saber programar?

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

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

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

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


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

Avaliação de desempenho

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

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

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

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

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

Matriz 9-box e seus quadrantes

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

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

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

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

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

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

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

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

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

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

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

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

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


Pontos fortes

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

Pontos a melhorar

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

Desafios para o próximo semestre

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

Promoções e aumentos

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


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


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

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


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

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

Liderança de produtos digitais

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

Contratar as pessoas certas

Como comentei no capítulo Pessoas: prioridade nº 1, sempre nós 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. E o primeiro passo para ter as melhores pessoas no seu time é a contratação.

O trabalho de contratação de pessoas deve ser feito em conjunto com o RH. É um trabalho em equipe. Já vi situações em que esse processo é totalmente delegado para o time de RH, e a pessoa que está contratando fica apenas perguntando “cadê os candidatos?” e “por que o RH está demorando tanto para preencher essa vaga?”. Definir perfil, encontrar candidatos, entrevistar, selecionar, fazer onboarding é tanto responsabilidade do RH quanto do head de produto e de seu time.

Definir o perfil

O primeiro passo para contratar as pessoas certas para o seu time é definir o perfil de quem você está procurando para se juntar ao time. Quando falo de perfil, estou pensando não só em conhecimento técnico como também em senioridade comportamental e fit cultural, ou seja, que valores a pessoa precisa ter para trabalhar nesse time. É importante construir esse perfil em colaboração com mais pessoas do time. Desse perfil, sairá a descrição da vaga, ou job description em inglês.

Atrair candidatos

Tendo o perfil definido, é preciso anunciar a vaga a trazer candidatos. É o trabalho de atração de pessoas. Aqui o marketing pode ajudar. Da mesma forma que precisamos contar ao mundo sobre o problema que resolvemos com nossos produtos e como o produto o resolve para encontrar as pessoas certas que terão interesse em virar nossos clientes, precisamos contar ao mundo sobre o tipo de pessoa que precisamos em nosso time.

Para isso, é importante fazer um trabalho de employer branding, que é contar por que a sua empresa é uma empresa interessante na qual trabalhar. Contar nas redes sociais e em eventos sobre os trabalhos feitos pelo time, os desafios e as conquistas, como é o ambiente e a cultura do time. Isso tudo faz parte do employer branding e ajuda a atrair pessoas interessadas em trabalhar no seu time de desenvolvimento de produto. Esse é um trabalho feito em parceria entre RH, marketing e o time de desenvolvimento de produto.

Outra excelente fonte de novas candidaturas são as indicações internas. Peça para as pessoas do time indicarem pessoas com quem trabalharam em outros lugares e com quem eles gostariam de trabalhar de novo. É possível inclusive incentivar essas indicações dando prêmios para quem indicou caso a pessoa indicada seja contratada.


É importante ter a sequência de entrevistas bem definida. Quem são as pessoas que vão entrevistar? Em que ordem? Serão entrevistas individuais ou em grupo? Haverá resolução de caso? Normalmente, nas empresas em que trabalhei, a primeira entrevista é feita pelo RH, para apresentar a vaga e a empresa e para entender um pouco mais do perfil comportamental da candidata. O RH pode usar algum teste comportamental para isso.

Em seguida, vêm as entrevistas com as pessoas do time de desenvolvimento de produto. Se for uma contratação para uma posição que vai interagir bastante com outras áreas da empresa, é importante que a candidata também seja entrevistada por pessoas dessa outra área. Normalmente sugiro que o líder direto seja o primeiro a entrevistar, em seguida que a pessoa seja entrevistada por pares do time de desenvolvimento de produto e de outras áreas, se for o caso.

Se a pessoa for liderar um time, sugiro a oportunidade de algumas pessoas do time também entrevistarem. Apesar de deixar o processo mais longo, acho interessante mais pessoas entrevistarem por dois motivos: primeiro, dá a oportunidade de mais gente conhecer os candidatos e, quando a decisão for tomada, mais pessoas estarem comprometidas com o sucesso desse novo membro do time; segundo, dá a oportunidade de a candidata conhecer melhor a empresa e as pessoas que compõem o time.

Uma dica importante para quem entrevista é procurar fazer as mesmas perguntas para todos os candidatos, assim você poderá comparar as respostas para escolher aquela que mais se encaixa no perfil que você está buscando. Em relação a que tipo de perguntas fazer, costumo ouvir a história da pessoa e perguntar sobre acertos, erros, relação com outros membros do time e com pessoas de outras áreas.

Durante o processo de entrevistas, pode ser interessante pedir para a candidata resolver um problema em casa para depois ela apresentar a solução. Esse processo é bastante comum tanto em vagas de gestão de produto, como de UX e de engenharia. O objetivo desse teste é conhecer melhor a capacidade de resolução de problemas, bem como de apresentação de soluções. E essa apresentação da solução é uma boa oportunidade para entender como a pessoa se expressa e como ela lida com questionamentos.

Acho interessante o caso a ser resolvido ser um caso prático da empresa, em que o time está trabalhando ou pretende trabalhar em algum momento. Já ouvi críticas de que isso é consultoria gratuita e que depois a empresa vai usar a melhor solução. É importante deixar claro que a resolução de case tem dois objetivos, dar a oportunidade de as pessoas que estão contratando conhecerem melhor o candidato, como ele resolve problemas e apresenta suas soluções, assim como dar ao candidato a oportunidade de conhecer que tipo de problemas ele vai encontrar no dia a dia.

Vale ressaltar que ao pedir uma resolução de caso, há o perigo de perder candidatos. Por isso, é importante deixar claro que o processo terá essa fase, e é importante encantar o candidato antes de apresentar o caso a ser solucionado para deixá-lo com vontade de resolver o caso.

Como comentei, esse é um processo longo, com várias entrevistas e testes, o que pode fazer você perder boas candidaturas. Por isso, é importante manter esse processo atraente, contar à candidata como ela está indo, em que fase ela está e o que falta para chegar ao final do processo. Já ouvi relatos de empresas que conseguem fazer esse processo todo em um dia, chegando ao final do dia com candidatos recebendo uma proposta, mas nunca tive a oportunidade de presenciar um processo assim.

Escolher e fazer a proposta

Após as entrevistas e os testes, chegou o momento de escolher a melhor candidata. A melhor forma de fazer isso é juntando as pessoas que entrevistaram os candidatos para contarem suas impressões sobre cada um, assim a líder da vaga pode tomar a decisão sobre quem escolher. A decisão de quem contratar é da líder que tem a vaga aberta, mas esse momento para trocar percepções é importante. Costumo chamar essa reunião de comitê de contratação, que dá a oportunidade não só de escolher o melhor candidato, como de entender melhor como as pessoas estão fazendo o processo de entrevista e, eventualmente, alinhar alguns pontos em relação a esse processo. Isso deixa os membros do time mais engajados com o sucesso da pessoa que será contratada.

Uma vez definida quem é a pessoa, é preciso desenhar a proposta que será feita para ela. É importante que a proposta seja financeiramente relevante. Não é comum a pessoa aceitar receber menos do que ela está recebendo atualmente. E é importante balancear incentivo de curto prazo (salário e benefícios), médio prazo (bônus) e longo prazo (stock options e similares). Cuidado para não fazer uma oferta que seja muito discrepante com o que as pessoas atuais do time já têm, para não criar diferenças que podem minar o trabalho em equipe.


Supondo que a candidata aceitou a proposta, chegamos a uma nova fase do processo, o de onboarding, ou seja, o de trazer a pessoa para o time e fazê-la parte desse time. O RH vai cuidar da parte mais burocrática desse processo, mas é preciso também desenhar com o RH todo o onboarding para garantir que a contratada se sinta acolhida e entenda mais sobre a empresa, o time e os desafios que ela terá pela frente.

Na Conta Azul tínhamos um processo muito bacana de onboarding, coordenado pelo RH, onde todos os novos funcionários passavam por uma semana de imersão para conhecer todas as áreas da empresa e os principais membros dessas áreas. Em seguida, as pessoas tinham um onboarding local, no time do qual elas fariam parte. No Gympass, além do onboarding, todas as pessoas eram convidadas a participar de algumas ativações, que era o momento em que íamos a um cliente para apresentar o benefício do Gympass para seus funcionários. É importante dar à nova pessoa que está entrando no time a oportunidade de conhecer mais sobre as outras áreas da empresa e sobre o cliente, antes de ela começar a trabalhar.

Conversas do RH com a pessoa após 45 e 90 dias que a pessoa foi contratada podem ajudar a perceber pontos de melhoria nesse processo de onboarding. Esses primeiros dias da pessoa no seu novo time são fundamentais para o sucesso da relação futura, por isso é importante monitorar de perto.


O título deste capítulo é Contratar as pessoas certas, mas não basta só contratar, é preciso também cuidar das pessoas durante todo o tempo que ela estiver no time.

Escrevi um capítulo inteiro sobre Feedback e avaliação de desempenho, mas quero pontuar aqui, pois feedback é algo muito importante para as pessoas que fazem parte do seu time. Como elas poderão saber que estão no caminho certo? No que elas podem melhorar? O que eles estão fazendo e que devem continuar fazendo? O que elas não estão fazendo e que deveriam fazer? O que elas estão fazendo e que elas deveriam parar de fazer?

É muito importante deixar claro para cada pessoa do seu time sobre esses pontos. E é muito importante lembrar que feedback é uma via de mão dupla, ou seja, você também deve procurar saber o que você pode fazer para ajudar a pessoa.

Encerrando um ciclo

Eventualmente você pode tomar a decisão de desligar alguém, o que é conhecido como turnover involuntário, ou alguém do seu time pode tomar a decisão de sair do seu time, o turnover voluntário. Esse sempre é um momento difícil, de ruptura, mas importante entender os motivos que acabaram fazendo chegar nessa decisão. Poderia ser evitado? Se inevitável, poderia ter acontecido de uma maneira mais planejada, evitando disrupção para o time?


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

No próximo capítulo, vamos entender como fazer feedback e gestão de desempenho.

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:


Como comentei no capítulo Papéis, responsabilidades e senioridade, o gerenciamento de expectativas é algo que ocupa entre 50 a 80% do tempo de uma head de produto. Seu dia a dia gira em torno de seus relacionamentos e interações com muitas pessoas dentro e fora de sua organização que têm interesse no produto que você lidera. No jargão corporativo, essas pessoas são chamadas de stakeholders:

Nas últimas décadas do século 20, a palavra stakeholder tem sido cada vez mais usada para significar uma pessoa ou organização que tem um interesse legítimo em um projeto ou entidade. Ao discutir o processo de tomada de decisão para instituições – incluindo grandes empresas, agências governamentais e organizações sem fins lucrativos – o conceito foi ampliado para incluir todos com interesse (ou “stake“, palavra em inglês que significa participação) no que a entidade faz.


Evolução do uso da palavra “stakeholder” na literatura (fonte: Google Books)

Uma gestora de produtos com alguma experiência sabe da importância de manter bons relacionamentos com os stakeholders do produto. Vou compartilhar aqui duas ferramentas que ajudam a mapear melhor esses stakeholders e como deve ser seu relacionamento com cada um deles.


RASCI é uma ferramenta muito útil para ajudar a definir e entender os papéis e responsabilidades de cada pessoa e cada função. É a abreviação das primeiras letras dos possíveis papéis que uma pessoa, área ou função pode ter em uma tarefa:

  • Responsible (encarregado): é a pessoa responsável pela execução da tarefa, ou seja, quem tem de liderar o esforço de planejar, fazer e concluir a tarefa. Não pode existir mais de um responsável por tarefa. É aquela máxima de que cachorro com dois donos morre de fome.
  • Accountable (responsável): é a pessoa que responde pela tarefa e que tem o poder de delegar para o responsible a tarefa a ser feita. Responsible e accountable podem ser a mesma pessoa. Também vale a regra de que não pode existir mais de um accountable por tarefa. Se responsible e accountable são duas pessoas diferentes, o accountable pode ser visto como o patrocinador.
  • Support (suporte): são as pessoas ou equipes que trabalham junto e sob a coordenação do responsible para a execução da tarefa.
  • Consulted (consultado): são as pessoas ou equipes que não participam da execução da tarefa, mas que precisam ser consultadas antes ou enquanto a tarefa estiver sendo executada, pois elas podem dar inputs relevantes para sua execução.
  • Informed (informado): são as pessoas ou equipes que não participam da execução da tarefa, nem precisam ser consultadas antes ou enquanto a tarefa estiver sendo executada, mas que precisam ser informadas quando a tarefa for concluída.

A seguir, está um exemplo de uma matriz de responsabilidade RASCI entre engenharia, UX, marketing de produtos e gestão de produtos que usamos na Locaweb:

Matriz de responsabilidade RASCI da Locaweb

Como usar

O primeiro passo é fazer a matriz de responsabilidades. Minha recomendação é preencher essa tabela juntando todas as pessoas envolvidas em uma sala, assim pode-se discutir se a divisão de responsabilidade está boa para todos e se tem alguma tarefa faltando. Muito provavelmente, vão surgir algumas “bolas divididas”, mas esse é um ótimo momento para discuti-las e definir quem é o responsável.

Em seguida, deve-se experimentar fazer as tarefas seguindo a matriz responsabilidade por algum tempo, tipo um ou dois meses. Depois, é importante fazer uma retrospectiva para ver se está tudo certo, ou se é necessário algum ajuste.

Daí para a frente, o uso passa a ser automático e as pessoas não precisarão mais se referir à matriz de responsabilidades. A cada 1 ano ou quando surgir alguma dúvida, ou mesmo quando surgir alguma tarefa nova, é bom revisitá-la.

Matriz de poder-interesse

A matriz de poder-interesse (do inglês Power-Interest Grid) é um conceito desenvolvido pela primeira vez na década de 90 por Aubrey L. Mendelow, e posteriormente explicado no livro, Making Strategy: Mapping Out Strategic Success, de Fran Ackermann e Colin Eden. Com base no poder e no interesse que uma pessoa ou equipe tem em seu produto, você pode classificá-los em 4 categorias principais.

Matriz de poder-interesse
  • Os atores principais são os que têm grande poder e interesse no seu produto. Você precisa colaborar frequentemente com eles. Os usuários e clientes do seu produto são atores principais, você precisa colaborar com eles para construir o melhor produto que resolva seus problemas e atenda às suas necessidades. Em algumas empresas, provavelmente o fundador mais próximo do produto também é um ator principal. Você deve convidar essas pessoas para qualquer reunião e dinâmica em que decisões estratégicas sejam tomadas. Agende individualmente para apresentar as decisões e pedir seus comentários e contribuições.
  • As pessoas são aquelas com pouco poder, mas alto interesse em seu produto. Eles não têm o poder de vetar ou alterar decisões, mas têm um profundo interesse em seu produto. Em algumas empresas, podemos pensar no suporte ao cliente, vendas e marketing como exemplos de áreas que desempenham o papel de pessoas. Elas têm grande interesse, mas não têm o poder de mudar seu produto. Você pode se comunicar com eles por e-mail semanal de status e demonstrações de produtos. É importante coletar suas opiniões, mas lembre-se de que eles não têm o poder de mudar suas decisões.
  • Os definidores de contexto são aqueles com poder de mudar seu produto, mas pouco interesse em seu produto. Exemplos de áreas que podem desempenhar uma função de definidor de contexto são RH e Jurídico. Se o RH não ajudar você a formar a equipe, você não terá uma equipe para construir seu produto. Se o Departamento Jurídico não estiver ciente e alinhado com os aspectos legais de seu produto, ele tem o poder de bloquear ou atrasar seu lançamento. Um CFO e um controlador também são duas funções que têm o poder de mudar decisões que afetam seu produto. É importante manter os definidores de contexto bem informados sobre as decisões do produto. Consulte-os antes de tomar decisões importantes. Mantenha-os informados semanalmente.
  • A multidão é quem tem baixo poder e pouco interesse. Mesmo que eles tenham pouco poder e interesse, é importante mantê-los informados. Normalmente, uma atualização mensal sobre o andamento do produto é suficiente. Pode ser por e-mail ou em uma reunião geral mensal com demonstrações de produtos como vou comentar mais adiante. Normalmente são as pessoas das áreas de RH, Jurídico, Administrativo e Financeiro que não estão no grupo de definidores de contexto.

É importante observar que cada empresa tem sua própria dinâmica, portanto, uma área ou pessoa que desempenha uma função específica na matriz de poder-interesse de uma determinada empresa pode ter outra função em uma empresa diferente.


Essas duas ferramentas são muito úteis para o head de produto poder entender melhor como se relacionar com seus stakeholders e como gerenciar suas expectativas, o que, como eu já disse, vai tomar de 50% a 80% de seu tempo.

A empatia é uma ferramenta fundamental para o head de produto poder gerenciar seus stakeholders. Como comentei no capítulo Desenvolvendo o time e gerenciando expectativas, empatia é a capacidade que uma pessoa tem de se colocar no lugar de outra para compreender os suas expectativas. Seus anseios, motivações, necessidades e problemas.

Essa característica é importante para que o head de produto entenda os clientes e usuários do produto, saber como estes se relacionam com ele, e que problema esperam resolver ou que necessidade querem ver atendidas. Também ajuda a entender o impacto de seu produto no seu time e nas pessoas de outras áreas. Por fim, mas não menos importante, o head de produto também precisa se colocar no lugar dos donos do produto, para entender suas expectativas e os resultados que ele trará para a empresa.


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

No próximo capítulo vamos entender mais sobre como contratar pessoas para o time.

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:


A essa altura você já deve ter percebido o quanto eu gosto de métricas. No meu primeiro livro, Guia da startup: como startups e empresas estabelecidas podem criar produtos de software rentáveis, eu dediquei 6 capítulos inteiros além de falar sobre métricas nos outros capítulos. No meu segundo livro, Gestão de produtos: como aumentar as chances de sucesso do seu software, são mais 5 capítulos dedicados ao tema de métrica, além de novamente esse tema aparecer em outras partes do livro. Aqui não é diferente, os dois últimos capítulos falaram bastante sobre métricas e tenho falado também em alguns outros capítulos sobre OKRs, objetivos, dados e resultados.

Métricas são ferramentas fundamentais para qualquer head de um time de desenvolvimento de produto. Sem métricas é impossível saber se o time está progredindo, evoluindo e cumprindo com sua missão. Contudo, é muito fácil se perder em quantidades enormes de métricas.

Neste capítulo quero compartilhar um pouco sobre como costumo trabalhar com métricas.

Tipos de métrica

Classifico métricas em 3 grandes grupos:


São as métricas que mostram como o time de desenvolvimento de produto está nesse momento e tem evoluído. Os dois capítulos anteriores mostraram as métricas de produtividade e de qualidade. São métricas que ajudam a head de produto e o time a entenderem como está o processo de trabalho e onde devem focar a energia para melhorar nessas métricas. Como podemos aumentar a produtividade? Como diminuímos a quantidade de bugs? Como garantimos a melhor performance do produto para nossos usuários?

Ainda dentro do tema métricas internas, existem outras mais “soft” mas também muito importantes para você entender a saúde do seu time de desenvolvimento de produto. São métricas que ajudam a entender se as pessoas estão felizes trabalhando nesse time, se estão alinhadas com a cultura e com o propósito do time e da empresa.

Uma métrica bastante simples de acompanhar é entrada, saída e tempo médio das pessoas do time a cada mês. Se saem mais pessoas do que entram, pode haver algum problema no time. Se as pessoas ficam poucos meses e depois vão embora, é mais um ponto de atenção. Você também pode rodar uma pesquisa de NPS (Net Promoter Score ou Índice Líquido de Promotores) com as pessoas do time periodicamente para entender se eles recomendariam trabalhar no seu time para outras pessoas e o porquê da resposta.

A seguir, há dois exemplos do Gympass. No primeiro está a evolução da quantidade total de pessoas do time mês a mês, com total de novos e total de pessoas que saíram, mostrando também quantas dessas saíram voluntariamente, ou seja, pediram para sair. No segundo está o eNPS (employee NPS ou NPS dos funcionários), que mostra se as pessoas estavam dispostas a indicar o time de desenvolvimento de produto do Gympass para os amigos virem trabalhar.

Evolução do time de desenvolvimento de produto do Gympass
NPS do time de desenvolvimento de produto do Gympass

De usuário

São as métricas que mostram que seu produto está sendo utilizado pelos usuários, ou seja, que ele está cumprindo seu objetivo. São as métricas de engajamento e de satisfação de seu usuário com o produto. Qual seria o engajamento ideal de seu usuário com o produto?

Na Conta Azul queríamos que o produto fosse a primeira janela que ele abrisse em seu browser de manhã e a última que ele fechasse à noite. Acompanhávamos quantidade de notas fiscais emitidas por usuário por semana e, por mês, qual o valor delas. No Gympass, acompanhávamos quantos usuários iam à academia por mês, qual a frequência de visita às academias e assim por diante. Na Lopes estamos acompanhando o uso pelos corretores do novo CRM que tem versão web e mobile. Queremos que eles usem pelo menos 4 vezes por semana e é esse número que acompanhamos.

Outra métrica de usuário que pode ser útil são as métricas de satisfação. Essa métrica tende a ser um pouco mais subjetiva, além de ser trabalhosa para medir. Você deve mandar todos os dias uma minipesquisa para uma parte de seus clientes. Por isso, antes de medi-la e acompanhá-la, recomendo acompanhar de perto o engajamento com o produto. Se o usuário está engajado, utilizando o produto na frequência esperada, há boas chances de ele estar minimamente satisfeito.

De negócio

São as métricas que mostram o time de desenvolvimento de produto está de fato entregando valor para o dono do negócio. Qual era o objetivo que a dona de negócio tinha para o produto? Aumento de vendas, diminuição de custos? Esses objetivos variam com o tipo de empresa onde está o produto digital. É uma empresa digital, uma empresa tradicional ou uma empresa tradicional nascida digital?

Na Conta Azul, como o produto vendido era o produto digital, as métricas de usuário e as métricas de negócio se misturam bastante. A quantidade de usuários que utilizam várias vezes por semana são aqueles que certamente vão continuar pagando a assinatura mensal e, consequentemente, continuarão gerando receita.

Já no Gympass, uma empresa tradicional nascida digital, e na Lopes, uma empresa tradicional, a receita existe sem a necessidade do produto digital. Então, o que o produto digital pode fazer para aumentar a receita ou para diminuir os custos? No Gympass, ao mesmo tempo que queríamos diminuir os custos de operação, automatizando a maioria das tarefas manuais, também utilizávamos o produto como potencializador de receita, ajudando o RH dos clientes e seus funcionários a entenderem e, consequentemente, se tornarem assinantes do serviço. Na Lopes, o foco principal é em aumentar as vendas, mas temos também um foco em como diminuir os custos de operação.

Um ponto importantíssimo acompanhar todos os meses é a comparação entre o valor entregue pelo produto digital – aumento de receita e diminuição de custo – e o custo de desenvolvimento de produto. O que se espera é que o valor entregue seja maior do que o custo de desenvolvimento. E gerenciar isso é papel do head de produto.

Acompanhando as métricas

Métricas podem ser diárias, semanais, mensais, trimestrais e anuais. Claro que, quanto maior o período de atualização, mais difícil é de entender o comportamento da métrica e tomar decisões sobre como impactá-la. Tenho preferência por métricas que podemos acompanhar diária e semanalmente. Com métricas semanais, em um trimestre temos 13 oportunidades de avaliar uma métrica, entender como podemos mexer nela e remover algum impedimento que esteja nos atrapalhando no atingimento de algum objetivo atrelado a ela. E as métricas diárias dão o pulso do negócio. Quanto novos usuários por dia? Quanto usuários cancelaram?

Na Locaweb sempre acompanhávamos esses números diariamente e, se algo estava fora do esperado, positiva ou negativamente, já buscávamos entender o que havia acontecido que havia impactado o número. Quando fazíamos algo com a intenção de mexer nesses números, tal como uma nova campanha de marketing ou de retenção, podíamos acompanhar esses resultados diariamente. É possível ainda medir com frequência ainda maior em caso de produtos com grande escala como, por exemplo, o Search do Google.

Por outro lado, há métricas que têm frequência maior mesmo, como o exemplo acima que dei de novas pessoas que entram ou saem em um time de desenvolvimento de produto. Mesmo com métricas mensais ou mesmo de periodicidade maior, recomendo fazer acompanhamento da parcial dessa métrica pelo menos semanalmente. Se você só acompanhar mensalmente, em um trimestre terá apenas 2 oportunidades de avaliar o andamento e corrigir o curso.


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

No próximo capítulo vamos ver como gerenciar os relacionamentos com as diferentes áreas.

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:

Medindo e gerenciando a qualidade

Em 2015, decidimos extinguir a função de Quality Assurance (QA) de nossa equipe de desenvolvimento de produtos da Locaweb. Tínhamos 12 QAs, alguns com perfil de desenvolvedor e outros com perfil SysAdmin. Ao propor a extinção da função de QA, alguns dos QAs se tornaram devs, enquanto outros assumiram a função de administradores de sistemas. Os motivos que nos levaram a extinguir a função de QA da Locaweb são:

  • Quando existe uma função de QA separada da função de desenvolvimento de software, é comum ouvir frases como “a funcionalidade está pronta, agora está em fase de QA”, o que denota uma cultura de desenvolvimento de produto em cascata. Essa cultura pode aumentar consideravelmente o tempo de desenvolvimento e afetar negativamente a qualidade do software.
  • Quando há uma função de QA separada da função de desenvolvimento de software, também é comum ouvir frases como “por que o QA não detectou esse bug?”, o que denota uma cultura de encontrar os culpados. Essa cultura pode ser muito prejudicial ao engajamento e motivação da equipe e, consequentemente, impactar negativamente a qualidade do software.
  • A qualidade não deve ser preocupação de uma pessoa ou equipe, deve ser preocupação de todos os que estão trabalhando na criação do software.
  • A qualidade é um requisito não funcional, ou seja, que especifica um critério para avaliar o funcionamento de um produto digital, enquanto requisito funcional especifica um comportamento do software. Desempenho, escalabilidade, operabilidade, monitorabilidade são alguns exemplos de requisitos de software não funcionais que são tão importantes quanto a qualidade. Mesmo assim, não há funções definidas para garantia de desempenho, garantia de escalabilidade, garantia de operabilidade e garantia de monitorabilidade. Por que a qualidade é o único requisito não funcional que tem uma função específica dedicada para garanti-la?
  • O controle de qualidade se concentra em garantir a qualidade do processo de desenvolvimento de software. Se uma função separada é necessária para garantir essa qualidade, por que não há necessidade de uma função separada para garantir a qualidade do processo de gestão de produto, o processo de design, o processo de marketing de produto, o processo de vendas, o processo financeiro de uma empresa?
  • Havia uma preocupação de que, se o próprio engenheiro agora tivesse que testar, as entregas demorariam mais para ficar prontas. Essa preocupação existia porque os engenheiros consideravam que seu trabalho estava concluído – e a entrega estava pronta – quando passavam a história para o QA testar. No entanto, o conceito de pronto do engenheiro está incorreto, pois ele acabou de passar a história para a próxima fase, o teste. Do ponto de vista do usuário, a história só está pronta quando o usuário pode usar o novo recurso. Portanto, o tempo que a entrega permanece no controle de qualidade ainda é o tempo de desenvolvimento, mesmo não estando mais nas mãos do engenheiro. E esse tempo fica ainda maior quando a história passa pelo controle de qualidade, mas é rejeitada e precisa voltar para a engenharia.

Quando entrei na Conta Azul, eles também haviam acabado de extinguir a função de QA, e os ex-QAs passaram a ser analistas de negócios, principalmente ajudando gerentes de produto.

Eu vi outras empresas também discutindo a necessidade de QAs e, em alguns casos, um debate acalorado emerge em torno deste tópico. No entanto, ter ou não ter QAs não deve ser o centro da discussão. Ter ou não ter essa função é a solução de um problema, normalmente referido como “como podemos melhorar a qualidade do nosso produto?”, e esse problema deve ser o centro da discussão.

Como podemos melhorar a qualidade do nosso produto?

Uma simples pesquisa no Google sobre qualidade de software produzirá toneladas de definições normalmente relacionadas ao atendimento de requisitos funcionais e não funcionais. Quando o software não atende a um requisito funcional ou não funcional, ele apresenta um defeito, um bug. Portanto, para melhorar a qualidade de um produto de software, precisamos trabalhar em duas coisas:

  • reduzindo seus bugs existentes;
  • não gerando novos bugs.

Uma boa maneira de controlar isso é ter uma medição semanal de seu inventário de bugs e novos bugs por semana e discutir isso todas as semanas com a equipe. Fizemos isso no Gympass. Definimos no início de cada trimestre qual é a meta para o inventário de bugs e a média de novos bugs por semana.

Quantidade total de bugs no Gympass

A imagem mostra a evolução do nosso estoque de bugs para o 2º trimestre de 2019. Iniciamos o trimestre com 215 bugs em nosso estoque e almejamos uma meta de menos de 166 ao final do trimestre, uma redução de quase 23%. Fechamos o trimestre com um estoque de 136 bugs, uma redução de 36%. Fizemos isso nos concentrando não apenas na resolução de bugs em nosso inventário, mas também no controle do número de novos bugs por semana.

Quantidade de novos bugs detectados por semana no Gympass

No primeiro trimestre de 2019, tivemos uma média de 26,2 bugs criados por semana. Durante o segundo trimestre, reduzimos essa média para 17,4 novos bugs por semana, para um total de 226 novos bugs durante o trimestre. Isso é uma redução de 33% no número de novos bugs por semana.

Isso parece uma melhoria muito boa, certo? Mas há muito espaço para melhorias aí. Deixe-me explicar a matemática do gerenciamento de bugs:

Se fomos capazes de reduzir nosso estoque de bugs de 215 para 136, isso significa que resolvemos pelo menos 79 bugs. No entanto, criamos 226 novos bugs (17,4 novos bugs por semana x 13 semanas) durante o trimestre. Resolvemos 79 + 226 = 305 bugs durante o trimestre, é muito trabalho de correção de bugs. Se tivéssemos gerado 90 novos bugs durante o trimestre, uma média de 6,9 novos bugs por semana, em vez dos 226 novos bugs, poderíamos ter zerado o inventário de bugs.

Um aspecto adicional da resolução do bug a ser medido é o SLA (Service Level Agreement) de resolução, ou seja, quantos dias a equipe levou para resolver um bug a partir do dia em que o bug foi identificado pela primeira vez. Para isso, classificamos os bugs pela sua gravidade, que é o impacto que causa aos usuários e ao negócio. Os bugs de maior gravidade são aqueles que precisamos resolver no mesmo dia; erros de alta gravidade, em 7 dias e média de gravidade, em 14 dias. O gráfico a seguir mostra como estávamos no Gympass no quarto trimestre de 2019.

SLA de resolução de bugs no Gympass

Essa não é a visualização ideal porque mostra apenas uma imagem do momento, e não uma evolução. Para entender a evolução de qualquer métrica, você precisa ver como ela se saiu em diferentes pontos no tempo.

Assim que me juntei à Lopes, comecei a trazer esse tema para a discussão com os times. Uma das coisas que notamos é que 50% dos itens “deploiados” era correção de bugs. Fui informado de que “esses bugs eram pegos antes de ir para produção, o que é algo bom”. De fato, ainda bem que esses bugs não chegaram ao ambiente de produção e apareceram para nossos usuários. Contudo, eles chegaram à pré-produção e precisavam ser corrigidos. Não seria melhor se esses erros nem sequer existissem, nem mesmo em pré-produção?

Os OKRs que definimos para nos ajudar com o tema qualidade foram 3 KRs adicionais no objetivo de Aumentar a cadência de deploys em produção que comentei no capítulo anterior:

  • KR: Reduzir o número de novos bugs para 5% em pré-produção.
  • KR: Reduzir o número de bugs totais para 10% em pré-produção.
  • KR: Manter o número de bugs totais abaixo de 5% em produção.

E adicionamos o seguinte OKR:

  • Objetivo: Melhorar a qualidade das entregas das squads.
  • KR: Revisar 100% das novas histórias para encontrar requisitos mal definidos e/ou ambíguos.
  • KR: Efetuar revisão de 25% dos Pull Requests dos squads.
  • KR: Mensurar volume de Pull Requests dos squads.

Outro exemplo de controle de bugs

Na Conta Azul dobramos o time de desenvolvimento de produtos em um período de 8 meses entre novembro de 2017 e julho de 2018. Esse crescimento tinha por objetivo aumentar a capacidade produtiva do time.

Quantidade de entregas e de pessoas por semana da Conta Azul

Além disso dividimos a quantidade de entregas pelo total de pessoas no time para avaliar se estávamos conseguindo aumentar nossa produtividade individualmente.

Quantidade de entregas por pessoa na Conta Azul

Contudo, com o aumento de pessoas no time, acabou aumentando a quantidade de bugs. Tanto que o time que já vinha tendo 40% de suas entregas como correção de bugs acabou tendo que aumentar essa proporção para 60%. Ou seja, apesar de ter aumentado a produtividade individual e total, esse aumento de produtividade não estava sendo sentido pelo usuário, pois acabava sendo usado para refação.

Percentual de correção bug na Conta Azul

Para controlarmos esse problema, aumentamos nosso foco em corrigir esses bugs dentro dos SLAs, que eram:

  • 85% dos chamados resolvidos em até 7 dias
  • 98% dos chamados resolvidos em até 30 dias
SLA de resolução de bugs em 7 dias da Conta Azul
SLA de resolução de bugs em 30 dias da Conta Azul

Veja que a qualidade piorou e o cliente sofreu com isso. Mas, depois de algum tempo, conseguimos retornar aos níveis de SLA definidos. Olhávamos essa métrica semanalmente e, sempre quando discutíamos sobre essa métrica, concordávamos que a melhor maneira de cumprir o SLA era não criar bugs!

Qualidade não é só controle de bugs

Além do controle de bugs, há vários outros aspectos que impactam na qualidade do produto digital que entregamos para os usuários. Desempenho, escalabilidade, operabilidade, monitorabilidade são alguns exemplos de requisitos não funcionais.

Quando me juntei ao Gympass, na minha segunda segunda-feira o sistema ficou fora para os usuários por volta das 19:00. Comecei a perguntar para as pessoas do time o que estava acontecendo e a resposta foi que as segundas-feiras são dias de pico de visita às academias e que às vazes o sistema não dava conta do volume. Como não havia monitoração, não éramos alertados de que o volume estava maior que o usual e não conseguíamos nos preparar adequadamente. Dois meses depois, quando o Rodrigo Rodrigues se juntou ao Gympass como CTO, ele apelidou o evento de “Back Mondays”. Para endereçar o problema passamos a monitorar e implementar uma infraestrutura que desse conta dos picos das segundas-feiras. E definimos OKRs para uptime, requests de HTTP bem-sucedidos e tempo de reposta do backend.

Uptime – Gympass
Requests de HTTP bem sucedidos – Gympass
Tempos de resposta do backend – Gympass

Por que a qualidade é tão importante?

Qualquer usuário prefere utilizar um produto de boa qualidade que se comporte conforme o esperado. Isso é condição sine qua non para fornecer uma boa experiência do usuário.

Além da experiência do usuário, há outro aspecto importante a considerar quando falamos sobre qualidade e bugs. Sempre que alguém precisa trabalhar na resolução de um bug que foi encontrado em um produto digital, essa pessoa precisa parar de trabalhar no que quer que esteja trabalhando no momento para poder resolver o bug. Esta é uma interrupção no fluxo de trabalho. Se essa pessoa fosse capaz de entregar o software sem aquele bug, ela poderia continuar a trabalhar em coisas novas sem interrupções, o que a tornaria mais produtiva.

A relação entre produtividade e qualidade

Tive a oportunidade de participar de um curso do MIT sobre como criar organizações de alta velocidade. O curso foi ministrado pelo Professor Steven J. Spear, autor do livro The High-Velocity Edge: How Market Leaders Leverage Operational Excellence to Beat the Competition. Esse é um daqueles cursos muito densos, cheios de conteúdo, mas que pode ser resumido em um parágrafo:

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.

Uma organização de alta velocidade trabalha seguindo os 4 passos adiante:

  • Estar preparado para capturar conhecimento e encontrar problemas em sua operação.
  • Entender e resolver esses problemas para construir novos conhecimentos.
  • Compartilhar o novo conhecimento com toda a organização.
  • Liderar para desenvolver habilidades 1, 2 e 3.

O exemplo clássico é a Toyota, com a manufatura enxuta e o conceito de parar a produção sempre que houver falhas, corrigindo-as e usando-as como oportunidade de aprendizado para que não aconteçam mais. Essa capacidade de aprender com as falhas é o que dá à Toyota a capacidade de permanecer à frente de seus concorrentes por tanto tempo.

Outro bom exemplo é a Alcoa, que tinha uma taxa de incidentes de trabalho de 2% ao ano, considerada normal. A Alcoa tem mais de 40.000 funcionários, portanto, 2% dos incidentes de trabalho por ano significa que 800 funcionários por ano têm algum tipo de incidente de trabalho. Esse é um número bastante impressionante e preocupante.

Para combater esse problema, eles implementaram uma política de tolerância zero a erros. Antes de implementar esta política, os erros eram vistos como parte do trabalho. Agora, os funcionários são incentivados a relatar erros de operação em 24 horas, propor soluções em 48 horas e contar a solução encontrada para seus colegas para garantir que o conhecimento se espalhe por toda a organização.

Isso fez com que o risco de incidentes caísse de 2% para 0,07% ao ano! Essa redução na taxa de incidentes significava que menos de 30 funcionários por ano tinham algum problema de incidente de trabalho depois que a política de tolerância a erro zero foi implementada e a Alcoa obteve um aumento de produtividade e qualidade semelhante ao da Toyota.

Falhar rápido vs. aprender rápido

Um fator importante nos exemplos da Toyota e da Alcoa é que reconhecer e aprender com as falhas deve fazer parte da cultura da empresa. Isso é algo um pouco mais comum na cultura das empresas de tecnologia, mas não tão comum em empresas tradicionais. Durante o curso do MIT dividi mesa com um executivo brasileiro, do Grupo Globo, um executivo espanhol, da AMC Networks International (Walking Dead, Breaking Bad e Mad Men), um gerente de projetos alemão residente no Azerbaijão que trabalha para a Swire Pacific Offshore (indústria de petróleo e gás) e uma estudante de pós-doutorado do MIT em energia solar vinda da Arábia Saudita.

Todos os meus companheiros de mesa eram de indústrias mais tradicionais. Eu era o único de uma empresa de internet. Os executivos da Globo e da AMC estavam lá porque viram a Netflix com seu streaming de vídeo sob demanda e o YouTube com seu enorme catálogo de vídeos gerados por usuários como grandes ameaças, roubando seu público muito rapidamente e eles queriam entender como poderiam se defender.

Embora o tema seja um tanto óbvio para as empresas de internet, especialmente com a cultura de startups de tecnologia que valorizam o fail fast (falhar rápido). É isso que torna a Netflix e o YouTube uma ameaça às empresas de mídia tradicionais, como o Grupo Globo e AMC Networks. No entanto, mesmo isso sendo parte da cultura das empresas de internet, sentar e discutir isso com pessoas de empresas mais tradicionais foi uma grande oportunidade de reflexão sobre a relação entre a falha, o reconhecimento da falha, o aprendizado e a alta velocidade:

  • Reconhecer as falhas e usar as falhas como uma oportunidade de aprendizagem deve estar bem enraizado na cultura da organização. Se as pessoas não tomarem cuidado, à medida que uma empresa cresce, ela pode perder a capacidade de aceitar as falhas como oportunidades de aprendizado. É muito comum que as empresas, à medida que cresçam, sejam cada vez mais avessas a falhas e criem uma cultura que, em última análise, incentive as pessoas a esconderem erros e falhas.
  • Outro aspecto importante do aprendizado com as falhas é tornar esse processo um padrão da empresa. Não adianta falhar, reconhecer o erro, afirmar que você não vai mais cometer aquela falha e, algum tempo depois, cometê-la novamente. Esse processo de aprendizado com as falhas deve fazer parte da cultura da empresa. Sempre que uma falha é identificada, o aprendizado deve acontecer o mais rápido possível para evitar que ela aconteça novamente. Se a mesma falha acontecer novamente, algo está quebrado no processo de aprendizagem com a falha.
  • Mesmo em empresas de internet, percebo que aprender com as falhas é mais comum na equipe de desenvolvimento de produtos, uma vez que retrospectivas e aprendizado contínuo fazem parte da cultura de desenvolvimento ágil de software. Em outras áreas da empresa, aprender com as falhas é menos comum. Essa capacidade de sistematizar o aprendizado com o fracasso deve permear toda a empresa.

Mesmo que ouçamos muito sobre a cultura das empresas de internet de falhar rápido, falar sobre falhar rápido diverge nosso foco do que é realmente importante, aprender rápido. Devemos colocar nossa energia no aprendizado, não no fracasso. É o processo de aprendizagem que faz evoluir pessoas e empresas. E é a capacidade de uma organização aprender rápido, principalmente com seus fracassos, que vai permitir que ela se mova em velocidades realmente altas.


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

No próximo capítulo vamos ver um pouco mais sobre métricas.

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:

Summing up

In this chapter, I have transcribed the Summing up sections of all chapters in order to create a quick reference guide on all topics discussed in this book.


I started the book by establishing some definitions, reviewing basic concepts like product and product management, and introducing new concepts like product head roles and responsibilities, team structure, career and Y career for product managers.

What is digital product and product management

  • Digital product is any software that has users.
  • Digital products can exist both in digital companies, where the digital product is the product that the company sells, and in traditional companies, which use the digital product to leverage and leverage the company’s main product .
  • Recently, traditional digital-born companies started to appear, that is, companies that sell a non-digital product, but that have the digital product as a critical part of their strategy since the beginning of the company.
  • Platforms are products that deliver more value the more users use the platform, the famous network effect. There are single-sided platforms and multi-sided platforms, which can be exchange, content or techniques.
  • Product management is the function responsible for connecting the company’s strategic objectives with the customers’ problems and needs.

Roles, responsibility and seniority

  • The head of product is responsible for coordinating the definition of the product vision and strategy, for helping product managers in their development and for managing the expectations of all people who have interest in your product.
  • A very important concept to help a product head with its responsibilities is the concept of seniority, which has 3 dimensions, two well known, time and knowledge and a third not so known, but just as important as others, behavioural seniority.

Product management career

  • The product career has progressed from Associate Product Manager (APM) to Product Manager (PM) to Group Product Manager (GPM) to Chief Product Officer (CPO). There are some variations of nomenclature depending on the company and the country, but in general it follows this progression. The important thing is that this structure and career progression are clear for the entire company.
  • When talking about the most senior product leadership in a company, there are two options with their pros and cons. One option is the unique leadership of the entire product development team (PM, UX and engineering), which works well for larger teams, but can be overwhelming when teams of more than 100 people. The advantage is having the entire team aligned with a single leadership. The other option is shared leadership with CPO and CTO, which avoids overload in large teams, but can cause a decrease in collaboration if there is no good harmony between these two or more leaders.
  • For PMs who do not want to pursue a management career, it is important to give the Y career option, with the role of Principal Product Manager, which helps in integrating and synchronizing the work of the different teams.

Product vision

  • Despite being only 10% of a product leader’s time, defining product vision is his most important responsibility. Without it all the product development work is much more difficult.
  • The product vision is nothing more than an understanding of what your product will look like in the future.
  • To make the product vision it is necessary to be clear about the company’s objectives with the product, as well as to deeply understand the problems and needs that customers have and that will be solved by the product.
  • The 6 steps to build a product vision are: obtain strategic objectives of the company, gain understanding of the problems and needs of customers, design the first version of the vision, iterate and refine, communicate and review.

Strategy and objectives

  • Product strategy is nothing more than the path you will take to reach your product vision.
  • To create your product strategy you need to have a good understanding of your market, that is, the competitors, the potential and accessible market, the growth of this market, if there are disruptors and how that market is regulated.
  • Use SWOT analysis to help define what points you will work on in your product strategy.
  • Use OKRs to help define your strategy goals and metrics that will tell you if you are on the right track.
  • Review at least annually, or when there are relevant events in the market, your strategy and your product vision. The market changes, your product evolves, so your product vision and strategy must also evolve. OKRs must be reviewed quarterly.

Team structure

  • Product development teams are organized into minimal teams, also called squads, composed of engineers, product designers and product managers. It is important to keep these teams as lean as possible to help your productivity. These minimum teams are grouped into product teams called product tribes.
  • There are 4 ways to organize product teams: by product or functionality, by type of user, by journey or by objective. It is also possible to use two different types of organization, creating a hybrid organization.
  • There are also the structural tribes, which create the necessary structure for the product tribes to perform. Teams that make up the structural tribes are SRE / DevOps, Data, Architecture / Tools / Foundation, Design Ops, Information Security, Internal Systems, Sales Engineering and Professional Services.
  • The implementation of the designed team organization can be done either by creating a new structure or by adjusting an existing team. In both situations it is important to know the product vision and strategy well to design and implement a team structure aligned with it.
  • The most suitable ratio between people in engineering and product managers is 7 +/- 2 engineers for each product manager. And a product designer for each product manager.
  • Two important concepts in the design of their team structure are the Conway’s Law, which says that organizations tend to create systems that are a copy of the companies’ communication structure, and the 4 stages of Tuckman of team formation, forming, confronting, standardizing and performing.
  • It is also possible to organize product teams by business units that have other functions besides those included in a product development team, such as marketing, sales and customer service. The motivations for creating business units instead of product teams may be due to the acquisition, or to give more agility to the new business or even because it is a new product line completely different from the original product.
  • What makes a group of people behave as a team are the common goals.

Developing the team and managing expectations

  • To develop your team and manage expectations, the product head must have the 7 characteristics of a good product manager: empathy, communication, time management, new technologies, business skills, keen curiosity and product theme.
  • Three of these features are essential for a head of product. Empathy to understand where expectations come from and what elements need to be developed in your team. Communication to be able to understand and make yourself understood when you are talking to the people of the company to manage your expectations and when you are developing your team. Business skills that will help you understand company goals that are important components of people’s expectations of the product.


  • Anti-patterns are common but ineffective responses to problem solving. There are many well-documented anti-patterns in the world of digital product development. The 4 most common anti-patterns in product development leadership are documentation, focus on data, big rewriting and wish list.
  • Documentation, which should be kept to a minimum, for certain leaders is even more important than the product itself. Nothing can go into production if it is not properly documented.
  • Focus on data is when any and all decisions have to be made with data, without taking into account qualitative information, previous experience and intuition.
  • Big rewrite happens when a new head of product finds a system written some time ago and identifies that it will be better to rewrite a new system from scratch than to improve the current one.
  • Wishlist comes from the need for the new head of product to please all stakeholders, focusing on the product development team to only implement what is requested, delegating prioritization to other areas of the company.


Here we saw my personal leadership principles:

  • People: priority # 1, always.
  • Leading is like being a doctor.
  • Leading under pressure.
  • Mentoring is a two-way street.
  • How and when to delegate.

We also saw what corporate culture is, a set of ways to solve problems and react to the situation shared by a group of people working together. Finally, we saw four values ​​that are the core of the entire digital product development team. They make up the product culture, which is nothing more than the set of behaviors of the digital product development teams that produce the best results:

  • Release early and often.
  • Focus on the problem.
  • Result delivery.
  • Ecosystem mentality.

People: priority #1, always

  • People are, and should always be, the number 1 priority of any company. We spend money and energy to acquire and retain the best people. Having people as number one priority is the key to achieving any other goal. This does not mean being “nice”, giving everything they want, but that we must be able to balance the challenges we give people so that they can improve continuously.
  • Bad apples can drain and damage your team. You must help these people to fit into your team, and if that is not possible, you must make the most difficult decision: get them out of the team.

Leading is like being a doctor

  • The next time you are on a team, either as part of it or playing the role of leading the team, think of the doctor’s leadership role and teamwork similar to the body’s healing process. It helps to understand the roles and responsibilities of the leader and the people on the team.

Leading under pressure

  • There is no work without pressure environment. People and teams need external pressure (the goal, the expected date, the lack of resources) and also from within (motivation, drive, inner strength) to exist and do things, like a balloon.
  • The internal pressure and the external pressure need to be balanced with some tendency to have a little more pressure on the outside to have continuous improvement.
  • Under pressure, a person and a team explode or become stronger. It is the leader’s role to help the person or team to realize this and work together with them to support increased internal pressure.

Mentorship is a two-way street

  • Mentoring is one of the most important roles for a product head. It is through mentoring that a head of products helps his team to develop.
  • Mentoring is a two-way street. The person in the role of mentor should be open to new learning from his mentoring sessions with his mentor.

How and when to delegate

  • Delegating is the act of entrusting someone with a task and / or responsibility. Leadership is an ongoing act of delegating tasks and responsibilities.
  • Between not delegating and delegating there are several levels of delegation that are used according to the context, that is, the problem to be solved and who will be working on the problem.
  • The concept of delegation goes hand in hand with the concept of micromanagement, a management style in which the manager closely observes or controls the work of his subordinates or employees.
  • There are different ways of doing things to achieve the same result. New leaders often think that only their way of doing things is right.
  • Mistakes are incredible learning opportunities. Hence the importance of tolerating mistakes at work.

Culture and values

  • Culture is the way a group of people respond to everyday situations. It is the role of the head of product to assist in the design and promotion of the company’s culture to ensure an environment conducive to the development of successful products.
  • It has five values ​​that I believe are essential to help create a culture that enables the development of successful products. In this chapter I spoke about 3 of those values: don’t waste time looking for the culprits, focus on learning. Don’t compare work situations with war, nobody wants to kill anyone. Profit and revenue are a consequence, it should not be the main focus.

Transparency, the foundation of a high performance team

  • Every leader, to help her team perform better, needs to explain the context and remove impediments.
  • In order to explain the context, it is essential to be transparent, explain the company numbers, explain the motivations behind each decision, include the team in the decisions.
  • Transparency in the management of companies seems modern, but it has existed for some decades. Two interesting examples come from the 1980s. One at an American company called Springfield ReManufacturing Corp (SRC), which created the concept of open book management. The other in a Brazilian company called Semco, by Ricardo Semler, where Clóvis Bojikian, its HR director, implemented participatory management. Both are from the 1980s and are industries, that is, the vanguard of participatory management.
  • With transparency, it is possible to give people the necessary information so that they understand the context and motivation of the work they are doing and are able to make better decisions about that work.

Diversity, the basis of the best products

  • There are two main reasons that motivate the construction of different digital product development teams. The first is that diversity brings new points of view. The second reason is that just as the group of customers using your product is diverse, so should your product development team.
  • People have different backgrounds, different stories, different knowledge. We must recognize and respect these differences and understand that sometimes we will not reach an agreement, but that’s okay, as long as we respect each other’s perspective.
  • It is in our hands to make the digital product development environment more inclusive. The way for this to happen is to bring up the topic and make it part of the conversations.

Release early and often

  • There is a set of four values ​​that are in fact the core of every digital product development team. These are the values ​​that make up the product culture, which is nothing more than the set of behaviors of the digital product development teams that produce the best results.
  • The three reasons for you to launch your product soon are that (i) this is the moment of truth, (ii) so you avoid the excess of features and (iii) accelerate the return of the investment.
  • If you are not ashamed of your first version, it took too long to launch.
  • Minimal Marketable Feature or MMF is a concept prior to that of MVP, which has the advantage of bringing this mentality of implementing the minimum necessary for each product functionality.

Focus on the problem

  • A very important step in creating a good solution is understanding the problem. When we hear about a problem, we immediately start thinking about solutions. However, the more time we spend learning about the problem, the easier it will be to find a solution and chances are good that this solution will be simpler and faster to implement than the first solution we thought of.
  • If you have a list of projects to do, create two more columns in that list, one for problems to be solved in each project and another for whom the problems will be solved. This will help you to focus on the problems to be solved, not the projects, which are the solution.
  • Solution implementation teams are teams working on implementing a solution designed by someone else. Problem solving teams are teams that work to deeply understand the causes of the problem, the context and the motivation that people have to solve it. In doing so, they are able to implement the best solution for the problem at hand.
  • The top-down trap is the perception of the decision-making process being made by the leaders of the company, with no opportunity for the rest of the employees to participate. This perception is exacerbated when a company faces increasing pressure, such as the COVID-19 crisis.
  • People are solution-oriented, and the greater the pressure, the faster people want solutions to be implemented.
  • To help deal with this situation, use empathy to understand the requestor’s view of implementing the solution and ask him why it is necessary to implement the requested solution.
  • Heads of product have the role and responsibility to promote these behavioral changes to help build a more collaborative decision-making process.

Result delivery

  • Another fundamental value for any product development team is the focus on delivering results.
  • Care must be taken when defining the result. Delivering functionality is not a result. All functionality is a means that serves an end, the achievement of a business objective.
  • Even 100% digital companies, whose digital product and technology are the company’s core, focus on business objectives.

Ecosystem mindset

  • Ecosystem mindset means making decisions that create value for all actors on a platform.
  • At Gympass, during the COVID-19 crisis, after placing Gympass Wellness for all its customers and their employees, an important part of the ecosystem was still suffering, the gyms. It was the ecosystem mentality that guided Gympass to create the Live Classes product, which allowed gyms to continue operating even though they were behind closed doors.


Here we saw the tools that I have used in my almost 30 years of leadership in product development leadership and that I have shared with other leaders so that they can use with their teams. The tools I will talk about include vision, strategy, goals, team structure, metrics, relationships and ceremonies.

Vision, strategy, objectives and team structure

  • Vision, strategy, objectives and team structure are, in addition to very important concepts, essential tools for any product head.
  • For vision and strategy, a presentation with a few slides is sufficient. For OKR and team structure, spreadsheets do the trick.
  • More important than the software you use to document Vision, strategy, goals and team structure is what you do with these tools. OKR worksheet I use at least every week. Vision and strategy, whenever I have the opportunity, I talk about these topics. Team structure, whenever we talk about hiring or changes in the team, I use the team structure worksheet.

Measuring and managing productivity

  • There is no silver bullet to increase the productivity of a product development team. However, there are two essential tools to help achieve this goal.
  • The first tool is measurement. There is no way to improve something that is not measured. What is product development speed? It is important to have a clear definition of this metric and consequent measurement.
  • The second tool is to bring the topic of productivity to the center of the discussion. Everyone on the product development team is responsible for the team’s productivity. Therefore, by bringing the topic to the center of the discussion, everyone will be able to collaborate to improve productivity.

Measuring and managing quality

  • Questioning whether or not product development should have a dedicated QA team is not the right question.
  • The problem you are trying to solve is how to improve the quality of your product.
  • A good quality proxy metric is the bugs. Bug inventory, new bugs per week and bug resolution SLA.
  • A product development team must have all its members following these metrics and taking action to improve them.
  • Managing bugs is not enough to manage the quality of the digital product. Performance, scalability, operability, monitorability are some examples of non-functional requirements that directly impact the quality of the digital product.
  • Quality is at the forefront to provide a good user experience. In addition, it is essential to increase the speed of your product development team. The less bugs a team has to fix, the more time it has to focus on new things.
  • High-speed organizations are able to learn very quickly, especially with their failures, and to absorb that learning as an integral part of the organization’s knowledge.


  • The metrics of a product development team can be classified into 3 major categories: internal, user and business.
  • Internal metrics show how the team is in health. User metrics show the relationship of its user with the product. Business metrics are those that show whether the product is, in fact, delivering value to the business.
  • Metrics should be monitored as often as possible, at least weekly. Even if it is a monthly metric, try to follow the weekly, or even daily, partials of this metric, to give greater opportunity to act earlier when there is a course variation.


  • Expectation management is anywhere from 50 to 80% of a product head’s time.
  • RASCI is a very useful tool to help define and understand the roles and responsibilities of each person and function.
  • The power-interest matrix, together with RASCI, is a great tool to help you better understand and interact with your stakeholders.
  • But don’t forget, the main tool that a product head needs to understand better and, consequently, have improved and fruitful interactions with its stakeholders is empathy.

Hire the right people

  • The work of hiring people must be done in conjunction with HR. It’s team work.
  • The hiring phases are defining the profile, attracting candidates, interviewing, choosing and making the proposal, onboarding.
  • The life cycle of a person on your team does not end with onboarding. It is important to constantly give and receive feedback from her, to ensure that the relationship works well for both the team and the new person on the team.
  • Finally, the last phase of the person’s life cycle on the team is when the person leaves the team. It is necessary to understand the reasons that led to this decision to understand how these themes can be worked on in the future.

Feedback and performance evaluation

  • Six essential aspects for good feedback are: checking if feedback is necessary, giving it when it happens, being objective, being transparent, empathizing and giving feedback in private.
  • The seven main characteristics of a good product manager are empathy, communication, time management skills, knowledge of new technologies, business skills, keen curiosity and knowledge about the product theme.
  • If the product is not a technical product, it is not necessary to know how to program. However, having some sense of programming can be useful in understanding how your product works. Knowing SQL is also useful, as it will help the product manager to better understand the metrics of their product.
  • Formal performance appraisal processes have been increasingly seen by companies as something that does not bring as many benefits as expected. Several companies are replacing this process with more frequent conversations between leaders and followers about career, performance, potential and values.
  • Semi-annual retrospective is a good way to have a structured conversation with the team member about the results achieved and how they were achieved, and about the challenges to come. This retrospective must be built together with the team member. If there is a formal performance appraisal process in the company where you are working, use the retrospective process to create the performance appraisal.
  • Regarding promotions and salary increases, there are two aspects to consider, when and how. I recommend separating salary increase and promotion conversations from the feedback conversations to maintain full focus on the topic of each of these conversations. I also recommend promoting the person when he has the potential to develop the skills necessary to occupy the next career level, and not expect him to already demonstrate the skills necessary for that next career level, as this will motivate the person more.


  • These ceremonies with different stakeholders are aimed at planning, alignment and expectation management. I emphasize that this list is not definitive, that is, depending on the company and the context, it may be interesting to create others and some of the ceremonies listed here may not be necessary.
  • 1:1 meetings are important to maintain alignment and communication with your followers, your leaders, other team members and people from other areas. 1:1 with your team members and your leader should be weekly and have an hour of conversation set aside. The 1:1 with other people may have a shorter periodicity and duration, or even be occasional. The topic of these meetings is free, and should not be limited to accountability. They involve personal issues, day to day, concerns, feedbacks, retrospectives.
  • Leadership team meetings are the meetings that the product head has with its direct followers. In addition to direct team members, it is important to have the HR person who is dedicated to helping your team. The topic is free, but it is important to periodically discuss OKRs and communication dynamics with the rest of the company. At least weekly. They can happen more than once a week, even daily if there are many topics to be discussed.
  • All-Hands are meetings with the entire product development team where the achievements are celebrated and the lessons learned are shared. The recommendation is that they are monthly.
  • Product Council are the meetings where the planning of the next quarter is presented to the senior leadership of the company, preferably in the format of OKRs. They are usually quarterly.
  • Product Updates are used to remove the black box effect from product and technology teams. That’s when the leaders of this team present what was done in the last month, what will be done in the next month, how these deliveries impact the company’s results, demonstrations of features and openness for anyone to ask what they want for the team.
  • Team structure meeting serves to discuss with the leadership of the product development team how the team will be organized, how we will use the hiring budget and what the hiring priority is.

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


In this chapter, I’m going to talk about the ceremonies I usually use with the teams I lead. These ceremonies with different stakeholders aim at planning, aligning and managing expectations. I emphasize that this list is not definitive, that is, depending on the company and the context, it may be interesting to create others, and some of the ceremonies listed here may not be necessary. I will talk about 1:1 meetings (one on one or one to one), leadership meetings, All-Hands meetings, Product Council, Product Update and team structure meetings.

1:1 meetings

1:1 meetings are those that the head of product has with his direct reports, his leader, other members of his team and with people from other areas.

1:1 with direct reports

The 1:1 meetings with the team members are, certainly, one of the most important meetings of the head of product. Ideally they should be every week and one hour long. If the head of product is unable to do these meetings in one week and decides to do it every other week or to shorten its duration, it is a sign that she has too many direct reports. Despite having an hour, this meeting need not necessarily take an hour. In some weeks, they may take less than an hour, in others, more time may be needed.

The theme of this meeting is free. Personal issues, day-to-day issues, concerns, feedbacks, retrospectives. It should not focus solely on the person’s accountability and progress report. During these conversations there will certainly be themes that should be discussed together with other people on your team, so suggest moving the theme to the leadership meeting. Once a month, at the beginning of a new month, it is important to stop by the OKRs to see if there are any impediments you can help with.

This meeting can be held in a room, or in a cafe or restaurant for lunch. Or even by video, in case people are not in the same place. I’ve seen people doing 1:1 walking. It is up to you and the person you are doing the 1:1 with.

I usually write down the themes as I remember a topic to be discussed in a document shared with the team member. I divide this document into new themes and, as we talk, we write down some points about the themes for future reference. After the 1:1, I mark the date when the meeting took place and open another section for new topics.

1:1 with your leader

You report to someone in the organization, so it’s also important to maintain a cadence of at least weekly conversations with that person. This meeting should serve as an alignment between the two of you, to ensure that that person always gives you the context of the company and the product that you lead in that company, and that it helps you to remove the impediments.

As a head of product, it may happen that you report to someone who doesn’t have as much experience with product development management as you do. On the other hand, that person will have experience and knowledge in other areas. It is important that this difference in knowledge and experience is clear to both, so that you can make these conversations as beneficial as possible for both of you.

Regarding where to do it, and how to write it down, the comments I made above about 1:1 with your direct reports are valid here.

1:1 with other people

In addition to the 1:1s with your team members and your leader which, as I said above, should be weekly and one hour long, you may need to do 1:1s with other people on your team and with people from other areas. This is because the rush of everyday life can be so that there is no time for these conversations to happen if they are not scheduled. Assess with each of these people whether there is a weekly, periodic or just occasional need for these conversations. The duration can also be less than an hour.

I usually have the need for 1:1 weekly with HR leaders, to talk about the needs of hiring and managing people from the product development team. I also usually have 1:1 weekly with the leader of the marketing area to talk about generating demand for product and about product marketing, that is, about how to tell the world about the problem that the product solves and how our product solves it. Less frequently than weekly, it may make sense 1:1 with the sales leader, to talk about the product sales process, with the operations leader, to understand the operational impacts of the product, and with the financial leader, to understand the revenues and costs generated by the product and the team.

Leadership team meetings

Leadership team meetings are the meetings that the head of product has with its direct reports. In addition to the direct reports, it is important to have the HR person who is dedicated to helping your team. If you don’t have someone dedicated to HR, bring the most senior HR person who has been closest to the product development team.

This is a team meeting, not the head of product meeting. In other words, topics brought by anyone on the team should be discussed, and not just topics from the head of product. Even when the head of product is not present, it should happen normally. If the topic being discussed requires the presence of someone who is not at the meeting, you must wait to discuss it when that person is at the meeting.

The topics to be discussed can be placed in a Google Docs document, shared with everyone who attends the meeting. Anyone can post topics to be discussed. They can be the most varied, as long as it makes sense to be discussed with the people present. When themes arise proposing to create a new routine or a new project that makes sense to be executed, this is an excellent opportunity for the head of product to delegate to someone on her team, who can create a subgroup to deal with the theme. Examples of such themes are Design System, Hack Day, Career Plan, among others. Some topics that should appear periodically at this meeting to be discussed with all leaders of the product development team:

  • OKRs: definition and monitoring of OKRs. Definition, once a quarter and follow-up at least once a month, ideally every week, to see if there are any impediments that need to be removed.
  • Product Council: I will talk a little later in this chapter about the Product Council, which is a quarterly planning presentation meeting of the product development team for the company’s senior leadership. It is important to plan together with your team what will be discussed at the Product Council.
  • All-Hands and Product Update: for these two meetings, which are monthly, which I will also talk about a little later, it is important to define together with the team on the topics.
  • P&L: profit and loss or revenue and cost. It is important to discuss with the team, at least monthly, how much revenue is being generated with the product and how much the product team costs, including not only people but all other costs (infrastructure, training, consulting, etc.).

Before joining Gympass, I used to have this meeting in person once a week. These meetings were one hour long and, when there were many topics, we increased to 1.5 or 2 hours to be able to talk about all the topics. At Gympass, as part of the team was in other countries, we started to do the meeting remotely, but still once a week. Still at Gympass, when the pandemic started, we decided to change the rate to daily, given the volume of issues that had to be discussed due to the crisis. After some time, we took off the Friday meeting to create a meeting-free day, that is, a day of the week without meetings. When I joined Lopes, as we are remote and have so much to talk about, we chose to hold our meetings daily. When we realize that there is not enough subject for an hour, we will decrease the frequency.

YOUR LEADER’s Leadership meeting

In addition to coordinating your leadership meeting with your team members, you will most likely participate in your leader’s team meeting, which will define the model and pace of those meetings. Take advantage of these meetings to align with your peers and your leader. Bring product development themes that may be relevant to them. If there is space, this is a good meeting to sporadically bring in some of your team members to discuss a topic. With this, you will give visibility to the people of your team, besides allowing them the opportunity to interact with other senior leaders of the company.

All-Hands Meeting

All-Hands meetings are meetings with everyone on the product development team, not just your direct reports. In addition to the people on the product development team, HR people working together with the product development team and other guests such as the CEO / founder, leaders from other areas and whoever makes sense to participate should also participate.

The objective is to celebrate the results, talk about lessons learned, discuss the progress of OKRs, introduce new team members and any other topic that makes sense to talk to the whole team.

The most recommended frequency is monthly and it’s nice to have a happy hour with the whole team after the meeting for relaxation. If the meeting is remote, happy hour will also be remote.

Product Council

The Product Council is a meeting with the leadership of your team and the senior leadership of the company in which your team presents the planning for the next quarter and, at the turn of the year, the planning for next year. The product council’s goal is to have everyone aligned in relation to the objectives to be achieved in the next quarter and in the metrics that will count that these objectives are being achieved.

It should happen quarterly, about a week before the new quarter begins. At this meeting, each leader of the product development team presents their next quarter planning to the company’s senior leadership. Often, the 3-month plan does not include some topics that may be important for the participants of this meeting. For this reason, I have recommended the use of the 12-month rolling roadmap, which allows us to show not only what lies ahead in the next quarter but also in the next 12 months. The objective is not to discuss whether what is in the fourth quarter should come before what is in the third quarter, but whether what is in the fourth quarter should be worked on in the next quarter and, if so, what should be postponed.

Example of a 12-month rolling roadmap

Note that, although we are talking about the roadmap, the first part talks about goals and results. It is essential to maintain the order of priority of the themes. More important than what is going to be done are the goals we want to achieve and which metrics indicate that we are achieving those goals. It is the role of the head of product to remember this priority of discussion of the themes.

One way to change the focus to stay 100% in objectives and results is to not use a roadmap and discuss only OKRs. Both at Gympass and Lopes, I have had the opportunity to participate in very productive Product Councils, focused exclusively on discussing OKRs.

The duration of these meetings depends on the number of topics to be discussed. I have already participated in Product Council meetings that had to be held in two days, given the number of topics and the need for necessary alignment. On the other hand, the shortest Product Council meetings I lead lasted between 1.5 to 2 hours.

The meeting’s agenda starts with the head of product making an introduction with information about the planning context for the next quarter and then each of the leaders of the product development team presents their planning.

An important point is to make a preview of the Product Council without the company’s senior leadership, to give your team members the opportunity to align themselves on their plans if they have not already done so. I once did a Product Council without this prior alignment and, in the middle of presenting a person’s planning, the other commented that he “could not have planned to do that because X and Y are not ready and will only be delivered at the end of the quarter” , which showed the lack of coordination between them.

Another important preparatory work for the Product Council meeting is 1:1 meetings that can be done between a leader of the product development team and someone from the senior leadership, to seek feedback on planning in a more reserved environment and to already take the planning for Product Council considering that feedback. The recommendation is to do as many 1:1s as necessary to obtain a good pre-Product Council alignment.

Product Council with customers

A variation of the Product Council that can be interesting to conduct is the Product Council with customers, that is, you invite some customers to work with them on a prioritization proposal for the next quarter. We did this a few times at Conta Azul, when we called some of our partner accountants to spend the day with us, to give them the opportunity to get to know our operation up close and, in a certain part of the day, we did a prioritization exercise with them, where we listed a series of features, each with a certain development cost, and let them choose within a development cost limit that they could apply.

It is very nice to see customers experiencing the same difficulty that we, product managers, have when making prioritization decisions. This prioritization made by the accountants served as another input for our prioritization work to be prepared for the next quarter and to be presented at the Product Council with the company’s senior leadership.

Product Update

This is also a monthly meeting where the product team presents to the entire company what has been done in the last month and what is planned for the next month, always connecting with the team’s OKRs. This is a very important meeting for managing expectations. At Conta Azul, since we had a company-wide All-Hands meeting every week, we took one of these meetings to be the product update. At Gympass, the All-Hands meetings took place once a month, so we created a separate meeting, called “Global Product Update Call”, which had to be a remote meeting since Gympass had teams in 14 countries at the time.

One way to organize the content is for each leader of the product development team to present their part or, each month, one of the leaders is responsible for preparing and presenting the content for the month. In addition to this content, the product head must make an introduction and there must be demos of the new features delivered. Ideally, these demos should be live. The more demos and fewer slides, the better. In the last product update that I participated at Conta Azul I was super happy because it was 100% demos and no slides. \o/

At the end of the product update it is important to open for questions, and the answers must be given by the leaders of the product development team.

This meeting is very important to report to the company about what the product area is doing. I constantly hear that the tech team is a black box, “nobody knows what they are doing and we don’t understand what they say”. To take this perception out of the black box, the best way is communication and the product update is a very effective communication ceremony.

Team structure meeting

This meeting can take place independently, or be a part of the team’s leadership meeting. The objective is very simple: decide together with the team how the product development team will be organized, how the budget for hiring people will be invested and what the hiring priority will be. Which tribes and squads should we set up? Should we only hire people for engineering, or should we also bring in designers and product managers? We must look at what we have to do, what we can do, and what we need help with. It is a collaborative meeting, which the product head should facilitate.

It is important for HR personnel to attend this meeting. Once at Conta Azul, an HR person who accompanied the operations and sales area asked to participate in this meeting to understand the dynamics and she was impressed with the meeting participants’ ability to converge on the best way to use the budget. It was when she commented to me that “your team is too mature to be able to have this type of discussion. In the leadership of operations and sales, we do not have the maturity to implement this dynamic”, to which I replied that at the beginning we did not have this maturity, but it was achieved with the constant exercise of this dynamic, that is, the team gained maturity as it learned to collaborate more, to understand the needs of other leaders and to perceive itself as a team with a common goal.

Summing up

  • These ceremonies with different stakeholders are aimed at planning, alignment and management of expectations. I emphasize that this list is not definitive, that is, depending on the company and the context, it may be interesting to create others and some of the ceremonies listed here may not be necessary.
  • 1:1 meetings are important to maintain alignment and communication with your direct reports, your leaders, other team members and people from other areas. 1:1 with your team members and your leader should be weekly and have an hour of conversation set aside. The 1:1 with other people may have a shorter periodicity and duration, or even be occasional. The topic of these meetings is free, and should not be limited to accountability. They involve personal issues, day-to-day, concerns, feedbacks, retrospectives.
  • Leadership team meetings are the meetings that the product head has with its direct followers. In addition to direct team members, it is important to have the HR person who is dedicated to helping your team. The topic is free, but it is important to periodically discuss OKRs and communication dynamics with the rest of the company. This meeting should happen at least weekly. They can happen more than once a week, even daily if there are many topics to be discussed.
  • All-Hands are meetings with the entire product development team where the achievements are celebrated and the lessons learned are shared. The recommendation is that they are monthly.
  • Product Council are the meetings where the planning of the next quarter is presented to the senior leadership of the company, preferably in the format of OKRs. They are usually quarterly.
  • Product Updates are used to remove the black box effect from product and technology teams. That’s when the leaders of this team present what was done in the last month, what will be done in the next month, how these deliveries impact the company’s results, demonstrations of features and openness for anyone to ask what they want for the team.
  • Team structure meeting serves to discuss with the leadership of the product development team how the team will be organized, how we will use the hiring budget and what the hiring priority is.

With this chapter, we finish part III on tools. In the next chapter, I will make a large summary of the book to serve as a quick reference, with all the “Summing up” of all chapters.

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