What is the difference between project management and product management?

In this series of articles where I write about the relationship between product management and the other areas of the company, I wrote about:

Now I want to write about the relationship between project management and product management.

As with the functions of product marketing and product management which, as we saw in the previous article, are quite distinct but overlapping, project management and product management functions are also quite distinct, but they also have a lot in common.

Before talking about the difference between these functions, we need to make clear the difference between project and product. I will turn to Wikipedia once again:


A project in business and science is usually defined as a collaborative venture, often involving research or design, that is carefully designed to achieve a particular goal.

Source: Wikipedia


The term product is defined as “something produced by work or effort” or as “the result of an act or process” and has its origin in the Latin verb produce(re), ‘make exist’.

Source: Wikipedia

That is, while the project is a process with a beginning, middle, and end; product is the result of a process.

So, managing projects and products are two distinct functions?

Yes. While one manages a project, her concern is with the process and everything that surrounds it, i.e., if it is on time, has everything that is needed and is being done with the expected quality.

On the other hand, when building a product, the main concern is to ensure that it solves a problem of the customer to whom it is intended, and meets the company’s objectives.

In a 2007 article at How To Be A Good Product Manager, author Jeff Lash recalls some important points to keep in mind when thinking about project management and product management:

  1. Just as every product needs a product manager, every project needs a project manager.
  2. The fact that product managers believe they are capable of managing their own projects does not mean that they should manage their own projects.
  3. The skills, talents, and knowledge involved in project management are very different from those involved in product management.
  4. Just as it is difficult to find a person capable of doing product management and product marketing at the same time very well, it is difficult to find a person capable of doing product management and project management at the same time.
  5. Project management is not a step in the product management career, nor is product management a step in the project management career.
  6. Good project managers are as valuable as good product managers.
  7. Having a good project manager to manage your projects will help you be a better product manager.
  8. The less time a product manager spends managing projects, the more time she spends managing the product.
  9. To avoid conflicts between project management and product management, project managers, product managers, and the entire team involved in the project should agree on the goals shared by the team as much as possible.

Marty Cagan makes clear the need to separate these roles in one of his posts:

“For internet companies, it’s really important that the roles are separated. You’ll have trouble managing your releases if you don’t separate those roles, and your releases will always be late and longer than they should be.”

And how do agile methodologies view these functions?

Agile methodologies, specifically Scrum, have two clear roles in the team: one more focused on the project, the Scrum Master; and another one more product-focused, the product owner (PO):

  • Product Owner: the person responsible for maintaining the product backlog, which represents the interests of stakeholders.
  • Scrum Master: the person responsible for the Scrum process, ensuring that it is used correctly and maximizing its benefits.
  • Team: Multifunctional group of people responsible for managing themselves to develop the product.
  • Scrum Team: Product Owner, Scrum Master and the Team.

There is an article on InfoQ written by Mark Levison in 2008 entitled Can Product Owner and Scrum Master be Combined? – where the theme of having a single person managing project and product is discussed. Both in the opinions that make up the text – and include testimonials from people like Mike Cohn and Ken Schwaber – as in the comments made by readers of the article, it is unanimous that, although it is possible to combine the two roles – and if the team is very small, it is even acceptable – the most recommended is that they are performed by different people.

And in real life?

All the reports seen are based on actual facts, but we know that each company has its own reality and context. So, what is better to do: leave these roles separate or combined?

Ideally, you should experiment and at some point you will find a combination that suits you, the team you work with, and your business. Note that each group of people has its own dynamics, and what works in one group of people may not work for another.

At Locaweb, we have several teams developing different products, and each one has its own dynamics where the product manager assumes different responsibilities with respect to the team. In some, the responsibility for technical project management tasks – that is, taking care of product development, deployment and operation issues – is handled by a project manager, while at other times this responsibility is shared between the engineering leader and product manager.

On the other hand, in all teams, the product manager plays the role of project manager for all non-technical tasks. That is, she coordinates with the marketing team product communication, coordinates with legal and finance areas the product’s legal and tax requirements, supports marketing in training for sales teams and takes care of passing knowledge to the customer support team.

You must find a balance that makes sense to you, your team, and the company you work for. Be careful not to absorb all project management responsibilities. Try to share them with someone, especially the technical issues; otherwise, there will be no time left for you to manage your product.

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.

Projects vs problems

The new year is time for retrospective and planning. What is normally done every quarter by most product development teams is done more intensely during the turn of the year, together with other areas of the company, and for the entire new year. It is the yearly planning process, that normally comes together with the budgeting process. What will we do this year that is just beginning? What are the main projects we will work on during the year?

Even though planning is super important to have clarity about what projects are most important for the new year, this list of projects may make you lose sight of a very important aspect of planning, the “why”.

It’s not uncommon to see the new year planning for a product development team, and even for the entire company, as a list of projects. To help you see your list of projects in a different angle, add 2 columns:

  • one to describe what are the problems you are trying to solve with each project;
  • and another one to describe for whom you are trying to solve this problem.

I already discussed the issues of having a solution-oriented mindset vs a problem-oriented mindset but when it comes to new year planning, this issue gets even more troublesome. The benefits of having clarity about the problems you want to solve and for whom are you planning to solve these problems are:

  • Making sure the problems are aligned with the company’s vision and strategy: when we focus on projects, it is easy to lose sight of the problems we are trying to solve, for whom are we planning to solve these problems and if these problems are the ones that we really need to solve.
  • Defining what problems are more important to solve: prioritizing projects without knowing what problems these projects solve and for whom may make the priorities not aligned with what’s really important for the company. However, to be more effective in bringing the desired result, we should prioritize the problems to be solved and guarantee that the prioritization is aligned with the company’s vision and strategy.
  • Solving more than one problem with the same project: Sometimes you may figure out that you are trying to solve more than one problem with a project, and that may be ok. But you need to know that. Maybe you can have simpler solutions if you treat each problem separately. Maybe not all of them are worth solving at this moment.
  • Checking if projects are the best solutions: when we move our focus from projects to problems and have clear visibility about problems priority, it is easier to check if the projects listed are the best solution for the problem at hand. Sometimes we may be able to find solutions that are easier to implement when we change our focus to understanding the problems.

So grab your list of projects and create these two columns, problems to be solved with each project and for whom the problems will be solved. This will help you focus on the most important things for this new year.

I wish you a happy and problem-oriented 2020!!! \o/

Here’s a list of the most read and commented articles of 2019:

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? Check out my new bundle Digital Product Management with my 2 books where I share what I learned during my almost 30 years of experience in creating and managing digital products.

No alt text provided for this image

Quadrupling software development productivity without increasing team size and without quality loss

I wrote some time ago an article about how to organize product development teams and about some changes we made ​​in the software development teams at Locaweb.

Since last year we have been focusing in productivity, i.e., how our software development teams at Locaweb could produce more without hiring more people and without dropping the quality of the software being delivered.

The chart below shows our numbers. We recorded the number of deliveries per week and, as you can see in the chart, in few weeks we were able to more than quadrupled the number of deliveries per week.

This increase in productivity occurred when the team grew only 10% in number of people, i.e., we cannot credit the increased productivity to the increase of people in our teams.

When there is an increase like the one presented above, besides the natural questioning of whether the increase in productivity is due to the increase of people, another common questioning is about whether there was a decline in the quality of deliveries. One of the quality measurements that we make is the number of rollbacks. As you can see below, despite the productivity increase, the number of rollbacks actually decreased by 40%!

How we did it?

There is no silver bullet, there were several actions we took and we are sure that there are still more actions that can be taken to increase productivity even further. Here is a list of what we did.

  • Measure: first of all, to improve anything you need to measure it in order to know if it is getting better! We made an estimated calculation of the number of deliveries per week from September 2015 to February 2016. The calculation was simple, total deploys made in the period divided by the number of weeks. We then started to communicate the entire company about the number of deliveries of each week. Each product manager sends me on Friday the deliveries of the week of her team. I then compile the data, write down the number of deliveries of the week and generate the chart above. From the moment we began to measure how we were in terms of number of deliveries per week and started to experiment with the process, we began to see results as seen in the chart above. In addition, the teams started using a single measurement tool, Jira , which gave them a better view of each team progress and allowed comparisons between teams with experience exchange, something along the lines of “look that interesting change in your chart, how did you manage to increase this indicator?”.
  • Kanban vs Sprint: Another area where we made changes was moving from Kanban to 2 weeks sprints. All teams ran with Kanban. The issue was that in Kanban, when an item has an impediment, it cannot be put aside in order for the team to work on something else. The team was locked. When an item is at the “doing” column, it cannot be moved back to the to “to be done” column so the team could get another item to do. Once in “doing” the task can only go to “done” can not go back to “to be done” column because you lose control of the team productivity. With time framed sprints, the team organizes the next two weeks of work, selecting more than one item to be worked. Thus, if an item has an impediment, the team can begin to work on another item and, therefore, can deliver more in the same time interval.
  • Discovery and delivery: what the UX designer and product manager do can be called discovery, that is, find out what needs to be done. On the other hand what engineering does can be called delivery, i.e., do and deliver what has to be done. This separation of roles seems obvious, but not making it explicit in teams can disrupt the process of software development. Why? Due to a few reasons. The first is that if the discovery is not seen explicitly, it is not clear what is done at this stage, nor what motivates certain decisions about what should be implemented in software. It is difficult to do something without knowing why it needs to be done. The second reason is that when this separation is not explicit, items can go back and forth from delivery to discovery and vice versa without discretion. Often times we saw something being implemented by engineers. Then UX and product manager, after seeing their specs implemented, want to change something in the middle of development. With the clear separation between discovery and delivery, we define that once going to delivery, it cannot be changed. If we need to change, we need to go through a new discovery and only then go to delivery again. 
  • Size of deliveries: we have been discussing for a few months ago now about the size of deliveries. In some cases our deliveries were very large, several weeks to a few months of work. As already widely discussed in Agile, frequent delivery of working software is one of the principles of agility, enhanced by the technique of continuous delivery. Just search Google to find numerous examples of world-class companies that make multiple deploys a day, with some making hundreds of deploys a day! :-O To do this, you need to deploy small, very small, chunks of software. We need to slice every big delivery into smaller stories. This is the product manager’s job, in conjunction with the UX designer. I’ve been asked if this is not cheating, after all, instead of delivering a great story will be delivering the same thing only sliced into short stories. It seems to be the same, but instead of delivering something big after weeks or even months, we end up delivering value every day, so our users can now enjoy the benefits immediately, rather than waiting weeks or months. Moreover, by deploying software in production every day, we can already learn from the feedback and adjust future deliveries. And there’s an added benefit, the fact of delivering software daily makes this process simpler by the simple fact that it is done everyday not every week or even worse, every month. So delivering a big story over a period of weeks or months is not the same thing as breaking the story into small pieces and delivering a little bit every day. There are clear productivity gains in deploying and delivering small pieces frequently.

In addition to these points above, we are beginning to experience some additional aspects that will certainly have an impact on productivity:

  • First solution vs simplest solution: it is human nature to want to solve problems. Once a problem arises, the first reaction is to think on a solution and get out implementing this solution to solve the problem. The issue here is that the first solution is not always the best solution, both from the customer’s point of view and from the point of view of who implements the solution. For this reason we prefer not to start immediately solving each new problem that comes out. We seek check for other possible solutions, we analyze all the solutions that we were able to gather and only then pick a solution to implement. Spend more time thinking about other possible solutions, having always clear what needs to be solved and why we need to address this issue. Knowing why helps you find simpler solutions. A simple solution (1 week implementation) that solves 70% to 80% of the problem is better than a complicated one (1 month implementation) that solves 100% and in most cases, solving 70% to 80% of the problem is more than enough. Sometimes the simplest solution is to do nothing!
    For example, at Locaweb the hosting and email services may stop working due to external factors such as the domain associated with the hosting and email was not renewed. Registro.br, the Brazilian registrar for .br domains recently released a new way for Locaweb to charge the customer domain on behalf of Registro.br. At first the idea seems good, since Locaweb billing the domain looks like the easiest way to guarantee that the customer knows that it has to pay for the domain registration to maintain the hosting and email services operational. However, when analyzing a bit better, we saw that this solution can generate problems. The customer will be billied twice for the same thing, domain registration, because the Registro.br would continue billing the domain. What happens if he pays both bills? And if he pays only Registro.br? And if he pays only Locaweb? In addition, implement a new type of billing where we will bill for a third party service is something new to the Locaweb team. New processes have to be carefully designed. So we started to wonder if there would be simpler ways to solve the problem of helping our customer not to forget that he has to pay for her domain registration at Registro.br. Since it would be possible to charge for Registro.br  services, it was possible to access the information that the domain is about to expire. So we thought about the following simpler solution: we will implement a communication sequence with this customer advising him of the importance of paying Registro.br to ensure that the email and hosting services continue to operate normally. This is a way simpler solution than implementing a double billing process. If Registro.br provides us with the billing URL, we can send this link information to the customer and the chances of solving the problem increase even further. And a communication sequence is much simpler to implement than a duplicate billing process.
  • Choose the most appropriate tool: here the subject are tools for implementing the solution, i.e., programming languages, frameworks and databases. Each tool has its own characteristics and these characteristics make them more appropriate to solve certain kinds of problems. Choosing the right tool for each problem will impact productivity. This is an issue that we are beginning to study now. Today we use Rails for almost everything, but it has some problems for which the solution developed and deployed using another framework or language or database can be simpler and faster. Using a single programming language for all problems is the same as using a single tool for all repairs that have to be made. Does the hammer is the best tool to tighten a bolt? Does Rails is the best tool to manage queues?

We are confident that with the above two points that we are starting to experiment now, we can increase productivity by 10x or even more! \O/

And certainly there are certainly other points that we haven’t even considered yet and that when we start to discuss and treat, may impact productivity even further.


As I said above there is no silver bullet, but there was one specific action taken that had crucial impact here: making productivity an important theme in our conversations. Everybody started to talk about productivity, what impacts productivity and how to address these points. This movement did start several changes and experiments that helped us to greatly increase our productivity. If you also want to increase the productivity of your software development team, put this issue as a central theme of their conversations and make lots of experiments. You’ll see how there is room to greatly improve the productivity of your software development teams.

Product Management: how to increase the success chances of your software

In 2015 I wrote a book on Software Product Management in Portuguese. In the beginning of 2016, Paulo Caroli talked to me about how he enjoyed the book and how this book could be useful to people in the software industry not only in Brazil but anywhere in the world. For this reason, we decided to create an English version of my book.

The book is organized in 5 sections:

  • Definitions and requirements
  • Life cycle of a software product
  • Relationship with other areas
  • Product portfolio management
  • Where to use software product management

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

We are working on the translation but as we progress we are already releasing the content. If you want to see the work in progress, please visit the book page at LeanPub. Still in beta but already with valuable content. Feedbacks are not only welcome, but needed!

More lessons learned on OKR

Some time ago I explained how we replaced roadmaps for OKRs at Locaweb. In that article I also talked about some lessons learned. Recently we made a retrospective of the last quarter and guess what happened? We learned some new interesting things, which I will share here!

Clear rules for KRs

One of the points that drew attention during our OKR retrospective was the lack of clarity in defining success and failure criteria for each KR. In an attempt to create an equal analysis pattern for all KRs we defined each KR with a target value, a success criteria defined as the attainment of 80% or more this target value and a failure criteria defined as the achievement of 40 % or less of the target value.

The problem is that each KR has its own context and dynamics. While for a certain KR the achievement of 80% of its target value could be considered a good result, to another KR the same achievement of 80% could be considered not good and to be considered good, reaching 98% of the target amount would be required.

Because of this, each KR will now have three values, the target value, the value above (or below) which the KR will be considered OK and the value below (or above) which the KR shall be considered not OK.

Weekly KRs

When defining KRs, it is common to come across monthly measurement metrics, for instance, churn, new sales, revenue, margin, support contacts and so on. Since these metrics are monthly, during a quarter we have only two opportunities to evaluate whether what we are doing is having an effect in moving the needle. Two opportunities is not enough, if we miss the first one, we only have one more.

For this reason we’ve decided split monthly metrics in weekly values. The idea is to do this very simply by dividing the monthly amount by 4. For example, if the goal is 2,000 new sales per month, we should have at least 500 new sales every week. Thus, if a given week we have 380 sales, we know that we are short and that we should compensate the following weeks. Another example can be a KR to achieve a churn 2% per month or less. This churn rate of 2% per month is equivalent to approximately 0.5% churn per week. Thus, if a given week we have 0.3% churn we will be fine, but if we have 0.6% churn we will need to compensate somehow in the following weeks.

With weekly KRs we can follow easily and frequently whether we are in the right path and make appropriate actions to maintain or improve the KR without having to wait the month end to see how close we are.

Lag measure vs lead measure

The majority of the metrics that we are used to can be called lag measures or historical measure. They represent the result of something that already happened, but do not show what was done to make it happen. For something to happen it is important that we know what are the lead measures, i.e., what needs to be done. For example, when a person loses 10 pounds in three months, the lag measure is the 10 pounds lost in three months, but what were the lead measures taken to achieve this result? Probably she restricted her food intake to a given number of calories per day, restrained from eating some specific food categories and exercised for at least certain amount of minutes a certain number of times per week. These are the lead measures that led to the described weight loss lag measure of losing 10 pounds in three months. Another good example, now that we are watching the Olympics, are the sports results. For example, US is leading the Olympic games in terms of number of medals. This is the lag measure. And what were the lead measures to achieve this result? All policies related to sport incentive in the US.

KRs usually are lag measures. NPS, Average Call Duration (ACD), new sales, revenue, cost, churn, number of contacts, etc. All these metrics are lag measures. But what are the  lead measures? What should we do to change their values? What does influence the final result? It is very important to know these influencers in order to understand where to work to move the metric. At Locaweb we mapped the influencer for NPS and ACD. This work consisted of some brainstorming sessions where we try to identify everything that influences the NPS or ACD. Then, for each item, we evaluated whether it was already measured, if the measured value seemed to be OK and its impact in the lag measure, using a simple scale such as Small, Medium or Large. We got a good guide of what should be our focus in order to improve NPS and ACD.

Visible dashboard

Another tool that can help is the concept of visible management. This concept is widespread in agile methodologies, with the teams having a board which allows the constant observation of how are the key metrics and, in some cases, its historical evolution. The use of visible management originated from the production system used in Japanese factories known as kanban. Incidentally, the Japanese word Kanban literally means sign or score.

The idea here is to create a visible board that shows what are the OKRs and how they are progressing. It mades it easier for the whole team to follow the progress of each of its metrics.

However, only having a visible dashboard is not enough. It needs to be constantly updated to be useful. Hence the fifth lesson learned.

OKRs weekly standup meetings

This is another tool that we are borrowing from agile methodologies. As explained above, besides creating its visible dashboard, the team needs to update this dashboard frequently or else the dashboard will become another office decoration piece. The suggestion is to update it weekly since we discussed earlier how important it is to update KRs weekly.

A standup meeting no longer than 15 minutes to update the KRs where each team member tells what she did last week and what she intend to do this week to improve each KR. This looks very simple and it is very simple indeed, but it helps to improve communication and team commitment.

Continuous learning

We have learned a lot from the use of OKRs. As we are now measuring more stuff, this helps us better understand how things are moving – or not moving – and identify areas for improvement. We are confident that we will continue to learn a lot and will continue to share as we learn.

Have you already implemented OKRs in your company? Please share your lessons learned so everybody can improve faster!

Product Management: how to increase the success chances of your software

In 2015 I wrote a book on Software Product Management in Portuguese. In the beginning of 2016, Paulo Caroli talked to me about how he enjoyed the book and how this book could be useful to people in the software industry not only in Brazil but anywhere in the world. For this reason, we decided to create an English version of my book.

The book is organized in 5 sections:

  • Definitions and requirements
  • Life cycle of a software product
  • Relationship with other areas
  • Product portfolio management
  • Where to use software product management

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

We are working on the translation but as we progress we are already releasing the content. If you want to see the work in progress, please visit the book page at LeanPub. Still in beta but already with valuable content. Feedback is always welcome!

Mais lições aprendidas sobre OKRs

Já contei sobre como substituímos os roadmaps por OKRs na Locaweb. Nesse artigo também falei sobre algumas lições aprendidas. Acabamos de fazer a retrospectiva do último trimestre e adivinha só o que aconteceu? Aprendemos mais algumas coisas interessantes, que vou compartilhar aqui! 🙂

Réguas claras para os KRs

Um dos pontos que chamou a atenção na última retrospectiva foram a falta de clareza da definição sucesso ou insucesso de cada KR. Na tentativa de criar um padrão de análise igual para todos os KRs, nós os definíamos sempre com um valor alvo e o critério de sucesso era definido como sendo o atingimento de 80% ou mais do valor alvo e o de insucesso era o atingimento de 40% ou menos do valor alvo.


O problema é cada KR tem seu próprio contexto e sua própria mecânica. Enquanto para um determinado KR o atingimento de 80% de seu valor alvo pudesse ser considerado bom, para outro, esse mesmo atingimento de 80% poderia ser considerado ruim e, para ser considerado bom, seria necessário o atingimento de 98% do valor alvo.

Em função disso, cada KR terá agora 3 valores, o valor alvo, o valor acima (ou abaixo) do qual o KR será considerado OK e o valor abaixo (ou acima) do qual o KR será considerado como não OK.


KRs semanais

Ao definir KRs, é comum nos depararmos com métricas de mensuração mensal como, por exemplo, churn, novas vendas, receita, margem, contatos de suporte e assim por diante. Como essas métricas são mensais, durante um trimestre teremos apenas duas oportunidades de avaliar se o que estamos fazendo está surtindo efeito em mover o ponteiro. Duas oportunidades é muito pouco, se você erra a primeira, só tem mais uma.

Por esse motivo nós decidimos nos esforçar em dividir métricas mensais em semanais. A ideia é fazer isso de forma bem simples, dividindo o valor mensal por 4. Por exemplo, se o objetivo for 2000 novas vendas por mês, deveremos ter pelo menos 500 novas vendas por semana. Assim, se numa determinada semana tivermos 380 vendas, saberemos que estamos atrás que teremos que compensar de alguma forma na semana seguinte. Um outro exemplo pode ser um KR de atingir um churn de 2% ao mês ou menor. Esse churn de 2% ao mês equivale aproximadamente a 0,5% de churn por semana. Assim, se numa determinada semana tivermos 0,3% de churn estaremos bem, mas se tivermos 0,6% de churn estaremos mal.

Com KRs semanais é possível acompanhar de forma fácil e frequente se estamos bem em relação a um determinado KR e fazer ações apropriadas para manter ou melhorar o KR sem ter que esperar o fechamento do mês para ver como estamos.

Lag measure vs lead measure

A maioria das métricas que olhamos podem ser chamadas de lag measures ou métricas históricas. Elas contam o resultado de algo que aconteceu, mas não contam o que foi feito para esse algo acontecer. Para que algo aconteça é importante que a gente saiba quais são as lead measures, ou seja, o que precisa ser feito. Exemplificando, quando uma pessoa emagrece 5 quilos em 3 meses, a lag measure é emagrecer 5 quilos em 3 meses, mas quais foram as lead measures feitas para atingir esse resultado? Provavelmente ela deve ter restringido sua alimentação a um determinado número de calorias por dia, evitado determinado tipo de alimentos e se exercitado por uma certa quantidade de minutos uma certa quantidade de vezes por semana. Essas são as lead measures que levaram à lag measure de emagrecimento descrita. Outro bom exemplo, agora que estamos próximos das Olimpíadas, são os resultados esportivos. Por exemplo, determinado país foi líder no quadro de medalhas dos últimos jogos Olímpicos. Essa é a lag measure. E quais foram as lead measures para obter esse resultado? Investiu em formação de atletas e em patrocínio para o esporte.

KRs normalmente são lag measures. NPS, TMA, novas vendas, receita, custo, churn, quantidade de contatos, etc. Todas essas métricas são lag measures. Mas quais são suas lead measures? O que as faz mudar de valor? O que as influencia? É muito importante conhecer esses influenciadores para saber onde trabalhar para mexer na métrica. Na Locaweb fizemos um trabalho de mapeamento de influenciadores de NPS e de TMA. Esse trabalho consistiu de algumas sessões de brainstorming onde procuramos identificar tudo o que influencia o NPS ou o TMA. Em seguida, para cada item, avaliamos se já o medimos, se o valor medido parece estar OK e qual o seu impacto, usando uma escala simples do tipo P, M eG, na lag measure. Com isso conseguimos um bom guia do que deve ser nosso foco para podermos melhorar o NPS e o TMA.

Dashboard visíveis

Outro ponto importante que pode ajudar bastante é o conceito de controles à vista. Esse conceito é bastante difundido nas metodologias ágeis, com os times tendo um quadro que os permite constante ver como andam as principais métricas e, em alguns casos, sua evolução histórica. O uso de controles à vista tem origem no sistema de produção usado em fábricas japonesas conhecido como kanban. Aliás, a palavra japonesa kanban significa, literalmente, cartaz ou placar.

A ideia aqui é criar um placa à vista que mostre o que são os OKRs e como eles estão progredindo. Com isso fica mais fácil para todo o time acompanhar a evolução de cada uma de suas métricas.


Contudo, só ter o dashboard visível não é suficiente. Ele precisa ser constantemente atualizado para ser útil. Daí a quinta lição aprendida.

OKRs weekly standup

Mais uma ideia que também está sendo “emprestada” das metodologias ágeis. Como explicado acima, não basta só o time criar o seu dashboard visível, ele precisa ser atualizado. A sugestão é atualizá-lo semanalmente, afinal definimos KRs para serem acompanhados semanalmente.



Uma reunião em pé de 15 minutos para atualizar os KRs, e cada um contar o que fez na semana passada e o que pretende fazer na semana atual. Algo bem simples, mas que ajuda na comunicação e no comprometimento do time.

Aprendizado contínuo

Temos aprendido muito com o uso dos OKRs. O fato de começarmos a medir mais nos ajuda a visualizar melhor como estão as coisas e a identificar pontos de melhoria. Temos certeza de que iremos continuar aprendendo bastante e vou continuar compartilhando à medida que formos aprendendo.

E vc, já implementou OKRs na sua empresa? Compartilhe vc também suas lições aprendidas!

What if we stop treating software development as a project?

When we treat software development as a project, we are giving it a start and an end, since all projects have clearly defined starts and ends. If we think about starts, that’s ok. All software development efforts have a clearly defined start.


However, when we talk about end, software development and the software which is the product of the software development process may have an end but:

  • it’s quite difficult to define when is the end of the software development since that as soon as we put the very first version of the software in front of real users, we’ll receive a lot of feedback which we’ll make us start to think on opportunities to improve the software;
  • it’s quite difficult to define when is the end of the software. Every software exists to support one or more business processes, to reach certain business objectives while satisfying the needs of its users. As long as theses processes exist, and the software reaches the business objectives and satisfy the user needs, there’s no reason to end the life of the software.

For this reason both software development and the software which is the product of the software development process may have an end, but it is a clearly defined end. When we treat software development as project we are forced to define an end for this development since projects require a clearly defined end. In this situation we tend to define the software development end as the delivery of the software first release. But what happens after this delivery? Aren’t we going to do anything new in this software? Or should we start a new project to work on the next release of the software? If we decide to start a new project, what we will do while we don’t start to work on this new version?

This is why companies have started to treat software development as a continuous process, not a project, and the software as a product of this process. Software is a product with a clearly defined start, but no clearly defined end. The history of a software product is written during the life cycle of this product and the end depends a lot on the decisions made during this life cycle.

Hence the need of software product management in our industry.

Product Management book

Are you interested in the software product management topic? Do you to learn more about it? I wrote a book about the topic. The book has 5 main sections:

  • Definitions and requirements
  • Software product life cycle
  • Relationship with the other areas
  • Software portfolio management
  • Where should we use software product management

This book is recommended not only for those who have software as her core business. Companies who develop tailor made software as well as companies who use software to communicate with its customers like banks, schools, hospitals, etc., can also benefit from the book.

Interested? Well, the book is currently only available in Portuguese. So if you can read Portuguese, get your copy today!

If you don’t speak Portuguese, don’t worry! Paulo Caroli and I are working on translating the book into English, so feel free to leave a comment below, and we’ll let you know when the book is ready.

E se a gente parar de tratar desenvolvimento de software como projeto?

Quando tratamos o desenvolvimento de software como um projeto, estamos atribuindo a ele um começo e um fim, pois todo projeto tem começo e tem fim claramente definidos. Em relação ao começo, sem problemas, todo desenvolvimento de software tem um começo claramente definido.


Contudo, quando falamos de fim, desenvolvimento de software e o próprio software podem sim ter fim mas:

  • é difícil definir quando deve ser o fim do desenvolvimento de software, já que ao colocarmos a primeira versão do software na frente dos usuários, haverá vários feedbacks que nos farão ter várias ideias de como melhorar esse software;
  • é difícil definir quando deve ser o fim do software, pois todo software é feito para suportar um ou mais processos do negócio, visando atingir certos objetivos desse negócio, ao mesmo tempo que tb visa satisfazer necessidades dos usuários do software. Enquanto esses processos existirem, e o software ajudar a atingir os objetivos do negócio e a satisfizer as necessidades dos usuários desse software, não há porque terminar o software.

Sendo assim, ao contrário de um projeto, o desenvolvimento de software, e o próprio software, não têm um fim claramente definido. Quando chamamos desenvolvimento de software de projeto, somos obrigados a definir um fim para esse desenvolvimento, pois projetos têm começo e fim claramente definidos. Normalmente definimos como fim de um projeto de desenvolvimento de software a tal primeira versão do software. Mas o que acontece depois que o projeto acaba e a primeira versão do software é entregue? Não vamos fazer mais nada em relação a esse software? Ou vamos começar um novo projeto para fazer a segunda versão desse software? Se vamos começar um novo projeto para fazer a segunda versão desse software, o que fazemos com o software enquanto não começamos essa segunda versão?

Por isso cada vez mais as empresas têm tratado desenvolvimento de software como um processo e não como um projeto, e o software como um produto desse processo. O software é um produto, que tem começo claro, mas não tem fim claramente definido. A história de um produto é escrita ao longo da vida desse produto e o fim depende muito das decisões que são feitas ao longo desse ciclo de vida.

Daí a importância da gestão de produtos de software para a nossa indústria.

ThoughtWorks finally moves “product over project” from trial to adopt!

ThoughtWorks is a well known software development company which is always one step ahead of the rest of the software industry. Many people who contributed and continue to contribute to our industry are – or were – ThoughtWorkers. Martin Fowler, Jeff Patton, Neal Ford, Jim Highsmith, Rebecca Parsons, Ola Bini, Jim Webber, Luca Bastos, Paulo Caroli, Claudia Melo are just a small sample of people who work – or worked – there and have contributed a lot for the evolution of the software industry.

Since 2010 they publish a document called Technology Radar where they talk about their view on techniques, languages, platforms and tools for software development. This view is based on the experience from their consultants who work on a variety of software development endeavours from customers all over the world. They classify the techniques, languages, platforms and tools in four main categories:

  • Hold: when placed in this band, the item may be of interest to ThoughtWorks and others in the industry. However it is their opinion that the item is not ready to invest significant time and resources in which to build experience.
  • Assess: a technique, tool, language or platform that moves into the assess band of the radar is something that they believe is worth exploring with the goal of understanding how it will affect the technology impacted dimensions of your enterprise.
  • Trial: having established a radar item as something worth pursuing, it is important to understand how to build up this capability. Enterprises should look to trial the technology on projects that have a risk profile capable of taking onboard a new technology or approach.
  • Adopt: is the final stage that is of interest to them on the radar. Here they feel that the industry has begun to move beyond the trial phase and has found the proper patterns of usage for an item. An item may also appear in the adopt band if they feel strongly that the industry should be adopting a radar item now, rather than going through a more gradual adoption approach.

In May 2015 I was quite pleased when May’s Technology Radar edition brought “Products over Projects” as new technique and already recommended it as TRIAL. This showed that ThoughtWorks started to believe that software development should not be viewed as a project with a clear start and finish, but rather as a product, developed to support business processes of the owner of the software. This software will have a long life cycle, so long as the life cycle of the business processes it supports. For this reason, software development should not be viewed as a project with a predictable end, but rather as a product, a tool that will support the business processes for as long as the business processes exist.

I wrote about the differences between a product and a project back in 2011 and the more I work with software development, the more it get clearer to me that we should manage software development as a product, with a long lifecycle, with an unpredictable end. For this reason product management is so important for software development.

From trial to adopt

When I saw the November 2015 Technology Radar edition I was even more pleased when I saw that ThoughtWorks decided to move “products over projects” from trial to adopt. Doing so they now consider software product management as a technique that they feel strongly that the industry of software should be adopting in order to increase the chances of success of their software. Here it is in their own words:

We’ve long been championing the idea that thinking of software development as a project – something budgeted and delivered during a limited time slot – doesn’t fit the needs of the modern business. Important software efforts need to be an ongoing product that supports and rethinks the business process it is supporting. Such efforts are not complete until the business process, and its software, cease to be useful. Our observation of this products over projects approach, both with our own projects and outside, makes us determine that it is the approach to use for all but exceptional cases.

Certainly this will help people all over the world in creating better software, which will meet the needs of their customers while helping the software owners reach their objectives.

This is a great step forward for the software industry! This is great step forward for software product management! \o/

ThoughtWorks finalmente move “products over projects” de trial para adopt

A ThoughtWorks é uma empresa de consultoria em desenvolvimento de software bastante conhecida por estar sempre um passo à frente da indústria de software. Várias pessoas que já contribuíram e continuam contribuindo para nossa indústria são ou já foram ThoughtWorkers. Martin Fowler, Jeff Patton, Neal Ford, Jim Highsmith, Rebecca Parsons, Ola Bini, Jim Webber, Luca Bastos, Paulo Caroli, Claudia Melo são só alguns exemplos de nomes de pessoas que trabalham (ou já trabalharam) nessa consultoria e contribuem muito para a evolução de indústria de software.


Desde 2010 eles publicam seu Technology Radar com sua visão sobre técnicas, linguagens, plataformas e ferramentas relacionadas a desenvolvimento de software. Essa visão é formada a partir da experiência de seus consultores trabalhando nos mais variados projetos de desenvolvimento de software em clientes de todo o mundo. Eles classificam essas técnicas, linguagens, plataformas e ferramentas em quatro categorias:

  • Hold: algo que aparece como hold, pode ser de algum interesse, mas não é recomendado investir muito.
  • Assess: quando algo aparece ou move para assess, já vale investir algum tempo para entender qual o impacto dessa técnica, linguagem, plataforma ou ferramenta.
  • Trial: quando algo aparece ou move para trial, além de investir algum tempo entendendo é importante também experimentar a técnica, linguagem, plataforma ou ferramenta.
  • Adopt: e finalmente, quando algo chega ao estágio de adopt, definitivamente é uma técnica, linguagem, plataforma ou ferramenta que deve ser incorporada no seu processo de desenvolvimento de software.

Em maio de 2015 eu já fiquei bastante feliz quando o Technology Radar trouxe como novo item o conceito de “Products over Projects” já classificado como trial. Em resumo, eles enxergam que desenvolvimento de software não deveria ser encarado como um projeto com começo, meio e fim, mas sim como um produto, que suporta processos da empresa que é dona do software, e que necessita de manutenção durante todo o seu ciclo de vida, que será tão longo quanto o ciclo de vida do processo de negócio que esse software suporta.

Ou seja, finalmente a ThoughtWorks começa
a enxergar a importância da Gestão de Produtos
para o sucesso do software!

De trial para adopt

Qual não foi minha alegria ao ver que, no último Technology Radar, publicado agora em novembro, a ThoughtWorks mudou “products over projects” de trial para adopt. Com isso, eles passam a considerar a Gestão de Produtos como algo que deve ser adotado no processo de desenvolvimento de software com o objetivo de aumentar as chances de sucesso desse software.

Certamente isso ajudará a termos softwares cada vez melhores, que atendam as necessidades de seus usuários ao mesmo tempo que ajudará o dono desse software a atingir seus objetivos.

Isso é muito bom para a indústria de software. Isso é muito bom para a gestão de produtos de software! \o/

The IT problem

I have talked to some people lately about IT departments and how they seem disconnected from the companies they belong to, often being very reactive to business demands. It is common to hear complaints from the business people about IT saying they almost never deliver what was asked and that it is hard to understand what they say. On the other hand, it is also common to hear IT folks saying that the business area does not know what they want and that IT cannot answer “zillion” high priority demands of the business. This lack of understanding between IT and the business area of ​​the company is so common that it even became a subject of cartoons of all kinds:



But what is wrong? What is the IT problem?

Software development

For those who live in the part of IT that has to do with software development, this problem has been addressed for some time now. The Agile Manifesto, from 2001, makes this clear:

  • We have come to value customer collaboration over contract negotiation.
  • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  • Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  • Business people and developers must work together daily throughout the project.

As the software developers need to deploy their software somewhere, they decided to involve the people who takes care of the production environment in this new way of thinking that bring together IT and business. Thus was born the DevOps movement in 2009:

DevOps (a portmanteau of development and operations) is a software development method that stresses communication, collaboration and integration between software developers and information technology (IT) professionals. DevOps is a response to the interdependence of software development and IT operations. It aims to help an organization rapidly produce software products and services.

Source: Wikipedia

In these software development teams it is common to see someone with the role of Product Owner or Product Manager. This is a role I’ve already described earlier:

Product Manager is responsible for all aspects of a software product, from strategic objectives to the details of the user experience. She is responsible for making the connection between the business strategy and the problems and needs of customers through the software that should help the company achieve its strategic objectives while solving the problems and needs of the customers.

The IT problem

Now imagine the IT department of Gap, American Airline, Disney, MIT or any other non-tech company. These IT departments will have among its scope the following functions:

  • Hardware inventories.
  • Software inventory and installation.
  • Server availability monitoring and metrics.
  • Security management.
  • Anti-virus and anti-malware management.
  • Anti-manipulation management.
  • User’s activities monitoring.
  • Capacity monitoring.
  • Storage management.
  • Network capacity and utilization monitoring.

As you can see, these IT departments already have enough stuff to worry about and will hardly develop software. If they choose to develop software, they will most likely use third parties to do this development. Even if they decide to develop internally, software development is still a small piece of IT. The concern of these IT areas is with how to integrate off-the-shelf software and make them work to meet the business needs.

The problem is that unlike software development, which already discovered the importance of having a product manager to help deliver results more aligned with the business, all other functions of an IT department does not have this bridge between IT and the business.

One possible solution to the IT problem

I would like to propose a solution to the IT problem: have more people with the role of “product manager”. I believe that name does not fit very well when the IT delivery is not software. That person will need to create a bridge between IT and business. Perhaps a more appropriate name is “business manager”.

This person would have the following responsibilities:

  • Gather IT needs in all areas of the company and identify and propose solutions to any conflicts between these needs.
  • When these requirements have impact on the end customer of the company, understand this impact on these customers.
  • Negotiate requirement implementation priorities with all business areas.
  • Work with IT teams to ensure that deliveries are made in accordance with the requirements gathered with the other departments of the company.
  • Act with the demanding areas and IT teams on any relationship with suppliers / partners. (e.g. banks, consultants, etc.)
  • Inform all areas of the company on new IT implementations as well as upcoming implementations. Prepare training as needed.
  • Work with marketing to inform customers when the new implementations are customer facing.
  • Define, track and analyze usage metrics from IT, to use them as further relevant information for decision making.

And to be able to carry out these responsibilities, this person needs to have:

  • Experience working with IT teams to deliver quality projects within expected deadlines.
  • Good understanding of IT and technical topics to be able to negotiate delivery options. Having been in the IT field is not required, but may help in the function.
  • General knowledge about the company’s products and services, as well as an understanding of the different departments of the company.
  • Good oral and written communication skills.
  • Negotiation skills between different stakeholders with different priorities.
  • Ability to documente requirements and use cases.
  • Leadership.

As you can see from the above description, this person have a senior profile. It will be a pair of the IT manager.

A question that may arise while reading this proposal to add a “business manager” to the IT team is why IT managers can not assume this role? Actually, they can, but they shouldn’t. IT managers already have many concerns. The IT manager has two main focuses, technology and people. She needs to be up-to-date on the technologies in her area to learn how to better meet the needs that arise. And she needs to manage the team, finding and coordinating good IT professionals is no an easy task. Putting on the IT manager the additional burden of business requirement management can lower the overall quality in current tasks.

In software development we’ve realized that it’s better to have a separate person taking care of business needs. Why not apply the same role separation for other IT areas?