Release early and often

In the previous chapters we saw my personal leadership principles:

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. And we saw the 5 values ​​needed to create successful digital products:

Product culture

It turns out that these values ​​are necessary, but not sufficient. There is a set of four values ​​that are in fact the core of the entire 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 four values, which will be the subject of this and the following chapters, are:

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

Let’s start with the first one: Early and frequent launch.

The sooner we present the product to our users, the better, as we can receive feedback from real users who will be able to use the product in their own context. There are 3 reasons that justify this need to launch your product or functionality as soon as possible and frequently.

Moment of truth

It doesn’t matter how much research, interviews, and prototypes you do, the moment of truth, that is, the moment when you will know if your product is, in fact, the solution to a problem of a group of people, is when the product is in your customers’ hands, in the context where they need the product.

The longer it takes you to get your product out on the street, the longer it will take to learn from real people if you are on the right track. And if that’s not enough, the more steps you will be taking in the wrong direction.

You will only know if the product you made really solves some people’s problems if they use it. The longer it takes for this to happen, the longer it will take to know whether or not it is the solution to the problem.

And if not, what do you do? Fix, adjust, change! The sooner you know that what you are developing is not on the right track, the better because the less time, energy, and money you will waste going the wrong direction.

Too many features

There is a limit of features that the user can understand. When we add too many features, instead of creating a solution to the customer’s problem, we end up creating a new problem for the customer.

Kathy Sierra, recognized programming and user experience instructor, has created a feature chart that illustrates in a clear and fun way how user satisfaction decreases as we increase the amount of functionality in a product.

User satisfaction curve as a function of the amount of functionality

Return on investment

The longer your product takes to have users and, consequently, customers who will at some point pay for your product, the more you will have to invest out of your own pocket. Below is a typical graph of a product’s return on investment (ROI).

During the period that you are building the product and don’t release it to users, all you will have is cost. That is, you will be in the investment part of the curve. This only changes when you start earning revenue and it is greater than your monthly costs. Then you enter the area described below as monthly profitability. Only after a few months in this area will you have a return on your investment. See how long the road is.

Return on investment

Now take a look in the graph below, how a 3-month delay in obtaining revenue can delay the return on investment by 6 months. Are these 3 months of delay in earning revenue worth it? What will you do in those 3 months really make up for 6 months of delayed return on investment?

Postponed return on investment

On the other hand, see what you get if you can accelerate the development of your product and launch it 3 months ahead of schedule. You get 6 months of return on investment! And the explanation for this is not just because you get to the revenue early, it’s because you spent less to be able to launch the product faster. See the chart below.

Antecipated return on investment

If you are not ashamed of your first version, you took too long to launch

LinkedIn founder Reid Hoffman once said that:

“If you are not ashamed of the first version of your product, you took too long to launch”.

To illustrate this phrase, which in a way summarizes the value of release early and often, I decided to take screenshots of the first version of some well-known services.

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

MMF – Minimal Marketable Feature

Minimal Marketable Feature or MMF comes from a 2003 book called Software by Numbers, by Mark Denne and Dr. Jane Cleland-Huang. In this book, they introduce the concept of:

Incremental Funding Methodology (IFM), an ROI-based approach (Return on Investment) for software development in which the software is developed and delivered in carefully prioritized blocks of functionality valued by the customer. These blocks are known as Minimum Marketable Features – MMFs.

It is a concept prior to that of MVP, which has the advantage of this mentality of implementing the minimum necessary for each feature of the product. The basic difference between MVP and MMF is that, while MVP talks about a minimum viable product, that is, it needs a complete product, even if minimal, in order to be presented to possible users, MMF brings the minimal concept down to the level of each feature.

To illustrate MMF, they used a very simple example: imagine that you have to build an internet banking system on the web. There are many features and it can take many months or even years for this product to be delivered with all “mandatory” minimal set of features. When thinking in terms of MMF, we should look at those “mandatory” features and find out if we can launch them independently, that is, if a particular feature, if launched independently, would bring some value to the customer. In an internet banking system, we could choose to release it only with an account statement and no other resources. This would be a very simple internet banking system, but if launched as soon as it is ready, and not after some other features are also ready, it will bring value to the customer sooner. And whenever you deliver value to the customer, you also deliver value to your company. In addition to the satisfied customer, in this example you have probably reduced the cost that your company has in serving these customers, because if users do not obtain their account statements over the internet, they will certainly use another way of obtaining this information and probably this other way is not as economical as internet access, like going to an agency or an ATM.

Minimum marketable functionality (MMF) is minimal, because if it were smaller it would not be marketable. And an MMF is marketable because, when launched as part of a product, people use (or buy) the functionality.

The next time you are planning a new product or feature set for an existing product, try to think in terms of MMF. It can bring a lot of value to you, your customers and your company.

Summing up

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

In the next chapter we will see the importance of focusing on understanding the problem to be solved before thinking about solutions.

Missing something?

So, did you miss something in this chapter? What else would you like me to cover?

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 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 leading digital products

Leadership anti-patterns

An anti-pattern is a common but ineffective and counterproductive response to a problem. This term was coined by Andrew Koenig in 1995, inspired by the 1994 book Design Patterns: Elements of Reusable Object-Oriented Software by Gamma Erich, Helm Richard, Johnson Ralph, and Vlissides John, who lists a series of software development design patterns that their authors found simple, succinct and effective for the most common problems.

The term was popularized by the book AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis by Raphael Malveau, William Brown, Hays McCormick, and Thomas Mowbray, which extended its use beyond the software design field to refer informally to any bad solution to a problem.

Wikipedia anti-pattern page lists over 70 antipatterns. I will list below the anti-patterns that I have encountered most often in my career. These anti-patterns that I quote below happen when the company’s leadership does not have enough experience in digital product development and is advised by people who have been successful in managing software development in the past, but who have not updated themselves.

As I explained in the introduction, software development is a very new science, especially when compared to other sciences like astronomy, medicine, mathematics, chemistry, civil engineering, etc. The first time a computer stored software in memory and successfully ran it was at 11 am on June 21, 1948, at the University of Manchester, on the Manchester Baby computer. This means that software product development is in its infancy. If a professional does not keep up to date, the knowledge and experience that has made him successful in the past may not be the most suitable to make him successful in the future.


Excessive use of documentation will undoubtedly slow down the product development team. It is not for nothing that in the Agile Manifesto, written in 2001, we say that we value “Software in operation more than comprehensive documentation”. Unfortunately, for some leaders documentation is even more important than the product itself. Nothing can go into production if it is not properly documented.

The last time I wrote a PRD (Product Requirement Document or Product Requirements Document) was in 2005 right when I joined Locaweb. A very time-consuming job, where I documented in detail everything we needed to implement in the product. I passed to engineering and sometime later the implementation was made with many errors because the engineers ended up not understanding what was written in some parts and decided to implement it as they saw fit. From that, we started to decrease the use of extensive documentation and increased the interaction between product managers, product designers, and engineers.

Marty Cagan has a very cool article called How to write a good PRD where he comments at the beginning:

I provide this document here mainly for historical purposes. It was written in 2005 to reflect best practices from previous decades.

I have not advocated the use of PRDs for many years, starting around 2007. It is not that PRDs are so bad. However, if the product manager is spending his time writing the PRD, then it is unlikely that he or she is doing the actual product discovery work.

Recommended pattern: just follow the agile manifest, product in the hands of customers brings more value to customers and the company than comprehensive and detailed documentation.

Focus on data

It happens when the head of product and other leaders only make decisions if there is an abundance of data, reports, charts. There are two dangers with this anti-pattern:

  • time: sometimes it takes a long time to gather all the necessary data. It is the situation known as analysis paralysis. Nothing happens until the data is meticulously obtained and analyzed. Often, after a first analysis, more data is requested and more time is invested in the search for this new data, and this cycle can be repeated over and over again. And, while this cycle is repeated, no decision is made. Hence the paralysis of the analysis.
  • errors: when we rely solely and exclusively on data there is a great chance that we will incur errors. How can we be sure that we have all the data needed to complete the analysis? How can we be sure that the data is correct? It is common to hear that decisions must be data-driven, that is, based on data. However, as stated above, the data may be incorrect and / or insufficient to describe a particular situation. Thinking about it, more recently the concept of data-informed decisions has emerged, that is, decisions are based on data, but not only on data. They take into account qualitative information, previous experience, and intuition in addition to data.

Recommended standard: make decisions based on data, but always understanding that the data is incomplete, and always take into account qualitative information, previous experience, and intuition.

Big rewrite

Every company has legacy systems. Even a startup that was just created, in a few months will be able to look at its code base as a legacy and something that needs to be improved. At that moment we start to hear phrases like:

  • It is increasingly difficult to deal with the code.
  • If I were to do it from scratch, it would be much faster.
  • If we don’t rewrite, it will get slower and more dangerous to change the code.

And at that moment, the great solution of rewriting was born. And this major rewrite will, at some point, cause a product evolution freeze. Why write something for the legacy, if the new system will replace it? And there is also migration or transition. How will we go from the legacy system to the new one?

Normally, in the initial estimates, the rewriting will take about 2 or 3 months and when we move forward we realize that it will be a little longer, and may take years. At Locaweb we made the decision to rewrite the central system that managed customer data and collection. The original project was forecast to take 9 months and ended up taking more than two years. In addition, when the new system came in, our customer billing did not work for about 2 months and stayed for another 6 months running incorrectly until we finished all the necessary adjustments. That is, the rewriting that originally would take 9 months ended up taking 3 years.

Recommended pattern: avoid major rewrites at all costs. Most of the time, there will be ways to replace the legacy system gradually and progressively, without causing disruption to the company and customers.


When a new head of product joins a new company, it is common during the onboarding process, during the numerous conversations with people from various areas of the company, to hear a series of requests and complaints regarding the product that this new head will take care. To “score points” with these people, who will eventually give feedback on the head of product’s work, he may be tempted to build his list of what to do based on these reported requests and problems. It is the company’s “wish list”. Then, this product head will prioritize this list or even outsource this prioritization to a leader in the company’s sales or business area. I’ve seen situations where the product head collects the “wish list” and presents it at a meeting with leaders from various areas of the company and says “now I need you to prioritize what you want the product development team to do first “.

Although it is somewhat tempting because the “wish list” will actually help the head of product to score points with the leaders of other areas, this behavior will make the product development team become a mere order taker and feature factory, inhibiting the innovation potential that this team can bring to the business. When the head of product focuses the team on delivering the “wish list”, it ends up focusing the team on being an implementer of solutions that are given by other people, taking the team’s focus on the problems to be solved. It is the difference between the team that implements solutions that are already envisioned by other areas of the company versus a team focused on deeply understanding the company problems and then finding the best solutions to solve these problems. I’ll talk more about this in the part about principles.

Recommended standard: product development team works to understand problems and then evaluate possible solutions. So go find the list of problems to work on, not the list of things that other areas want the product development team to do.

Summing up

  • 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 product head 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 system.
  • Wishlist comes from the need for the new product head to please all stakeholders, focusing on the product development team to only implement what is requested, delegating prioritization to other areas of the company.

With this chapter, we finish part 1 on the Concepts needed to understand the roles and responsibilities of a product head. In the next part, we will see which Principles should guide the work of a head of product and his team.

Missing something?

So, did you miss something in this chapter? What else would you like me to cover?

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

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? 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

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., the Brazilian registrar for .br domains recently released a new way for Locaweb to charge the customer domain on behalf of 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 would continue billing the domain. What happens if he pays both bills? And if he pays only 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 Since it would be possible to charge for  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 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 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/