In the last few weeks, 3 of my clients have asked about how to increase the productivity of their product development teams. Interestingly, this is the subject of the next chapter of my book, “Product Management, how to increase the chances of success of your digital product.“, which I am publishing here chapter by chapter.
In my last year at Locaweb, we focused a lot on productivity, that is, how Locaweb’s product and software development teams could produce more without needing to put more people on the teams and without the quality of deliveries falling.
The following graph shows our numbers. We count delivery quantities per week, and, as you can see, we more than quadruple the number of deliveries per week in a few weeks.
This increase in productivity happened when the team grew by only 10% in terms of the number of people, so it is not possible to credit this increase in productivity to the increase in people in the teams.
When there is such an increase, in addition to the natural question of whether the increase in productivity is due to the increase in people in the teams, another question that exists is whether there has been a drop in the quality of deliveries. One of the quality measures we take is the number of rollbacks. As you can see below, even with the increase in productivity, the number of rollbacks was reduced by 40%!
After I arrived at Conta Azul, we decided to implement the same type of control for weekly deliveries and we also ended up achieving a good increase in productivity.
At Gympass, as we are developing the team very quickly, we decided to track the number of deliveries per person per week. We count people who joined two months earlier, as people need 1-2 months to become productive. In one quarter, we increased our productivity per person by 16%.
At Gympass, we also measure the number of deploys in our core, known as a monolith, and in microservices. We also achieved a considerable increase in one year.
At Lopes, we also achieved a considerable increase. As soon as a deploy was done, an email was sent with a list of the “deployed” items. One of the first things I did was compile these reports into a spreadsheet to build the next chart. Hence it was easy to notice that the deploys didn’t happen daily. They happened on average once a week. As soon as we noticed this, we set OKRs to increase the frequency of deploys, which is having an effect. The OKRs we set were:
Between August 21st and September 30th we had 41 days and:
Between October 1st and October 23rd, in the area marked in green in the graph above, we had 23 days (just over half of the previous period) and:
There is no silver bullet, there were several actions that we took and we are sure that there are still more actions that can be taken to increase even more. Here is a list of what we did at Locaweb to increase the productivity of the product development team, practices that I later took to other companies.
First of all, to improve anything, you need to measure it to be able to know if that thing is improving! We made some estimated deliveries per week for the period 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 communicating with the entire company about the week’s deliveries.
At Locaweb and Conta Azul, each product manager sent me the week’s deliveries on Friday. I compiled the data and wrote down the weekly quantity, generating this graph. From the moment we started measuring, our level became clearer, and our actions began to show results on the graph. In addition, the teams started to use a single measurement tool, Jira, which gave them a better view of the progress of each team and allowed comparisons with the exchange of experience, that is, something along the lines of “look how interesting your chart, how did you manage to increase this indicator?”.
Another point we changed was the change from Kanban to sprint. Before, all teams ran with Kanban. However, in Kanban, when an item has an impediment, it cannot be moved, and the team cannot do anything else, getting stuck. However, sometimes it happened that the team moved an item from “doing” to “to be done” because it was offside and picked up another item to do what shouldn’t be done. Once in “doing”, the task can only go to “done”, it cannot go back to “to be done” as productivity control is lost.
With sprint, the team organizes the next two weeks of work, putting several items to be worked on. That way, if any item has an impediment, the team can start working on another item and, with that, manage to deliver more in the same time frame.
It is important to emphasize that this is not a criticism of Kanban. This happens in 2015. I believe we didn’t have enough maturity and knowledge to get the best out of Kanban, so we chose to switch to Scrum.
What the UX designer and the product manager do can be called discovery: finding out what needs to be done. What engineering does can be called delivery: doing and delivering what needs to be done. This separation of roles seems obvious, but not making it explicit in teams can disrupt the software development process.
Why? For a few reasons. The first is that if discovery is not explicitly seen, it is unclear what is done in this phase nor what motivates certain decisions about what should be implemented in the software. It’s hard to do something without knowing why you’re doing it. 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.
It was not uncommon to see something being implemented by the engineers in the teams. And when the UX people and the product manager saw their specifications implemented, they wanted to change something in the middle of development. With the clear separation between discovery and delivery, we defined that you don’t move anymore once you go to delivery. If you want to move again, you must go through a new discovery and only then go to delivery.
Our deliveries were quite large in some cases, with work lasting several weeks or even a few months. As has been widely discussed in agile methodologies, the frequent delivery of working software is one of the principles of agility, reinforced by the technique of continuous delivery. Just Google it to find countless examples of top-tier companies deploying multiple times daily, with some deploying hundreds of times daily! :-O
To do this, the deploys must be of small deliveries. You have to break every big story into smaller stories. This is the product manager’s work in conjunction with the UX designer. I’ve been asked if this isn’t cheating; after all, instead of delivering a big story, we’ll deliver the same thing but divided into small stories. It seems to be the same thing, but instead of delivering something big after weeks or even months, we deliver value every day, so our users can enjoy the benefits immediately instead of waiting weeks or months.
Also, by putting it into production daily, we can learn from the feedback and adjust future deliveries. And there is an additional benefit: putting some code into production every day makes this process of putting code into production something simpler exactly because it is done daily.
So delivering a big story over a period of weeks or months is not the same thing as breaking that story into small pieces and delivering a little piece every day. There are clear productivity gains in delivering small chunks frequently.
Also, making it easier for engineers to deploy (and roll back) code will help get code into production faster.
When I left Locaweb, we were starting to experiment with a few more points that had good potential to impact productivity:
It is human nature to want to solve problems. As soon as a problem appears, the first reaction is to think of a solution and implement it to solve the problem. However, the first solution is not always the best, both from the customer’s point of view as well from the point of view of the person implementing the solution.
For this reason, we have preferred not to immediately start solving every new problem that appears. We first try to check if there are more possible solutions, we analyze all the solutions and only then do we choose a solution to start the solution. Invest more time thinking about other possible solutions, always being clear about the issue to be resolved and why we need to resolve this issue. Knowing why helps you find simple solutions. A simple solution (1 week of implementation) that solves 70% to 80% of the problem is better than a complicated one (1 month of implementation) that solves 100%. Most of the time, 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 e-mail service may stop working for reasons external to the service. The domain to which the hosting and e-mail are linked, which is paid annually to Registro.br, may not have been renewed and, when it is not renewed, the services associated with that domain stop working, even if everything is operating perfectly at Locaweb. Recently, Registro.br made available a way for Locaweb to charge the customer’s domain on behalf of Registro.br. At first, the idea seems good, because when we charge, we guarantee that the customer knows that he has to pay for that domain to keep the services in the air. But, looking a little better, we saw that this solution can generate more problems.
The customer will be billed twice for the same thing, the domain registration, as Registro.br would continue to charge him. What happens if he pays both charges? And if he only pays Registro.br? And if he only pays for Locaweb? In addition, implementing a new type of billing, in which we would charge for the third-party service, would be something new for the team and for Locaweb. New processes would have to be designed. So we started to wonder if there weren’t simpler ways to solve the problem of helping our client not forget that he must pay for his domain registration at Registro.br.
As in order to charge for Registro.br it is necessary to access the information that the domain is about to expire, we thought of the following solution: we are going to implement a communication rule with this client, advising him of the importance of paying Registro.br, to guarantee that the service continues to function; it’s a much simpler solution than duplicating the billing process. If Registro.br provides a direct link to charge for the domain, we can send this link in the communication. Thus, the chances of solving the problem increase even more, and a communication rule is much simpler to implement than a duplicate charge.
Here, the theme is tools for implementing the solution: programming language, frameworks, and databases. Each tool has its characteristics and, depending on them, makes them more appropriate to solve certain types of problems. Choosing the right tool for each problem will impact productivity. This is a topic we are starting to study now.
Today we use Rails for almost everything, but there are some problems with implementing a solution using another framework or language that may be simpler and faster to resolve. Using a single programming language for all your problems is like using a single tool for all the fixes needed. Is a hammer the best tool for tightening a screw? Is Rails the best tool to manage queues?
We are confident that with these two points, which we are starting to touch on now, we can increase productivity by 10x or more! And certainly, there are other points that we haven’t even noticed yet and that, when we realize and treat them, can have an even greater impact.
The productivity of a product development team is impacted by several factors. I once found a very interesting article written by the Apptio development team where they show a mind map with all the elements that can positively or negatively impact the productivity of a product development team:
This diagram shows things and activities that affect development speed in some way. Green means an activity increases speed. The more you have, the better. Yellow indicates that some maximum exists. For example, you can accumulate technical debt and increase velocity, but it will significantly slow you down if you accumulate too much. Red shows things that slow down development. The less you have, the better. The green arrow indicates an increasing effect. For example, focused work increases the speed of development. The red arrow indicates decreasing effect. For example, better development skills decrease system complexity (good engineers create less complex systems).
What I like about this image is that it shows how complex this topic is and how many things can positively or negatively impact the team’s speed. At Conta Azul, we followed up on this topic every quarter at the Product Council, a meeting where we discussed the quarterly planning of the product development team with leadership. There was a slide where we listed all the topics that could impact speed so that we could discuss what we were doing about each of these topics.
There is no silver bullet. With each team I worked with, we took several actions, and we were always sure that there were always more actions that could be taken to increase productivity even more.
The only silver bullet that exists is to make productivity an important topic in our conversations. Everyone started talking about productivity and what we could do to improve it.
This movement started several changes and experiments that helped us increase our productivity considerably. If you also want to increase the productivity of your product development team, put this at the center of your conversations and experiment a lot. You’ll see how much room there is to improve the productivity of your software development teams.
Another important point: don’t leave to discuss the topic of productivity sporadically. My recommendation is that you do it weekly. Creating a weekly cadence will give you the opportunity each week to experiment with something new and discuss the results with the team.
I’ve been helping companies and their leaders (CPOs, heads of product, CTOs, CEOs, tech founders, and heads of digital transformation) bridge the gap between business and technology through workshops, coaching, and advisory services on product management and digital transformation.
I write regularly about product management, product development, digital product leadership, and digital transformation. You can receive a notification whenever I publish a new article without depending on any social network algorithms to notify you! Just subscribe to my newsletter.
Do you work with digital products? Do you want to know more about managing 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.