QA or no QA? That’s NOT the right question…

Back in 2016, I wrote an article about the reasons that motivated us at Locaweb to extinguish the QA function in our product development team. At Locaweb we had 12 QAs, some with a developer profile and others with a SysAdmin profile. In proposing the extinction of the role of QA, some of the QAs became devs while others have taken on the role of sysadmins. The reasons that motivated us to extinguish the QA function at Locaweb are:

  • When there is a QA function separate from the software development function, it is common to hear phrases like “the feature is ready, now it is in the QA phase”, which denotes a waterfall culture. This culture can considerably increase development time and negatively affect the quality of the software.
  • When there is a QA function separate from the software development function, it is also common to hear phrases like “why didn’t QA catch this bug?”, Which denotes a culture of finding the culprits. This culture can be very harmful to the team’s engagement and motivation and, consequently, negatively impact the quality of the software.
  • Quality should not be the concern of one person or one team, it should be the concern of everyone who is working on creating the software.
  • Quality is a non-functional requirement, that is, a requirement that specifies a criterion to assess the operation of a software product, which is different from the functional requirement, which specifies a behavior of the software. Performance, scalability, operability, monitorability are some examples of non-functional software requirements that are just as important as quality. Even so, there are no defined functions for performance assurance, scalability assurance, operability assurance, and monitorability assurance. Why is quality the only non-functional requirement that has a specific dedicated function to ensure it?
  • QA focuses on ensuring the quality of the software development process. If a separate role is needed to ensure this quality, why is there no need for a separate role to ensure the quality of the product management process, the UX design process, the product marketing process, the sales process, the financial process of a company?
  • There was a concern among devs that, if the dev herself will now have to test, deliveries will take longer to get ready. This concern existed because the devs considered that their work was finished – and the delivery was ready – when they passed the story to the QA to test. However, this dev’s readiness concept is incorrect, as she just passed the story on to the next phase, the testing. From the user’s perspective, the story is only ready when the user can use the new feature. So the time the delivery stays in QA is still dev time, even not being in the dev’s hand anymore. And this time gets even bigger when the story goes through QA but is rejected and has to go back to development.

When I joined Conta Azul, they had also just extinguished the QA role, and the former QAs became business analysts, mainly helping product managers.

I’ve seen other companies also discussing the need for QAs and in some cases a heated debate emerges around this topic. However, having or not having QAs should not be the center of the discussion. Having or not having this role is a solution to a problem, normally stated as “how can we improve the quality of our product?”, and this problem should be the center of the discussion.

How can we improve the quality of our product?

A simple Google search about software quality will yield tons of definitions normally around meeting functional and non-functional requirements. When software does not meet a functional or non-functional requirement, it has a defect, a bug. So, to improve the quality of a software product, we need to work on two things:

  • reducing its existing bugs;
  • not generating new bugs.

A good way to control this is having a weekly measurement of your bug inventory and new bugs per week and discuss this every week with the team. We did this at Gympass. We defined at the beginning of every quarter what’s the target for bug inventory and average new bugs per week.

Image for post

The image above shows the evolution of our bug inventory for Q2 of 2019. We started the quarter with 215 bugs in our inventory and we aimed at a target of less than 166 by the end of the quarter, a decrease of almost 23%. We were able to end the quarter with an inventory of 136 bugs, a 36% decrease. We did this by focusing not only on resolving bugs in our inventory, but also controlling the number of new bugs per week.

Image for post

In Q1 2019 we had an average of 26.2 bugs created per week. During Q2 we reduced this average to 17.4 new bugs per week, to a total of 226 new bugs during the quarter. That’s a 33% decrease in the number of new bugs per week.

This looks like a very good improvement, right? But there’s plenty of room for improvement there. Let me explain the math of bug management:

If we were able to reduce our bug inventory from 215 to 136, this means we solved at least 79 bugs. However, we created 226 new bugs (17.4 new bugs per week x 13 weeks) during the quarter. So we solved 79 + 226 = 305 bugs during the quarter, that’s a lot of bug correction work. If we had generated 90 new bugs during the quarter, an average of 6.9 new bugs per week, instead of the 226 new bugs, we could have zeroed the bug inventory.

An additional aspect of the bug resolution to be measured is the resolution SLA, i.e., how many days the team took to solve a bug from the day the bug was first identified. To do this, we classified the bugs by its severity, which is the impact it causes to the users and to the business. Highest severity bugs are the ones that we need to solve in the same day. High severity bugs in 7 days and medium severity in 14 days. The chart below shows how we were at Gympass in Q4 2019.

Image for post

This is not the ideal visualization because it only shows a picture of the moment, and not an evolution. In order to understand the evolution of any metric, you need to see how it performed in different points in time.

Why quality is so important?

Any user prefers to use a product with good quality, i.e., that behaves as expected. This is front and center to provide a good user experience.

Besides the user experience, there’s also another important aspect to consider when we talk about quality and bugs.

Whenever someone needs to work on solving a bug that was found in a software product, this person needs to stop working on whatever she is currently working to be able to work on the bug. This is an interruption in the workflow. If this person were able to deliver the software without that bug, she could continue to work on new things without interruptions, which will make her more productive.


  • Questioning if a product development should or should not have a dedicated QA team is not the right question.
  • The underlying problem you are trying to solve is how to improve the quality of your product.
  • A good proxy metric for quality is bugs. Bug inventory, new bugs per week and bug resolution SLA.
  • A product development team should have all of its members following these metrics and acting on how to improve them
  • Quality is front and center to provide a good user experience. But it is also key to increase the speed of your product development team. The fewer bugs a team has to fix, the more time it will have to focus on new things.

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

We can’t stand it, we need to rewrite everything…

This article was originally published in Portuguese in June 2017.

I have heard this phrase several times throughout my career. Software developers know that invariably comes a moment when this kind of discussion comes up, which usually has phrases like: “it’s getting harder and harder to deal with the code”; “if it were to do it from scratch, it would be much faster”; “if we do not rewrite, it will become increasingly slow and dangerous to deal with the code”.

At Locaweb, we had an Email Marketing product for sending and managing email marketing campaigns, which used MongoDB as a database, a nonrelational database known for its ability to store large databases. However, probably because of our limited experience in software development using this type of database and in managing non-relational databases, as the database grew, the system became slower and slower.

So, it was necessary to rewrite the product to use PostgreSQL. We designed this rewrite to be transparent to customers. That is, the client would not be migrated from one database to another, thus avoiding going through a period of unavailability or possible data loss. The rewrite was a success. The entire rewrite process, including putting all existing clients (over 15,000 at the time) into the new database, allowing the MongoDB database to be shut down, took six months, a reasonable time for such an initiative.

However, during these six months, the team delivered nothing new to the customer. No new features. To lessen our customers’ frustration, we decided to hire a third party to build iOS and Android apps on top of existing product APIs. This enabled us to deliver new functionality to our customers while the product team focused on rewriting. If this option did not exist, we would have to find other ways to deliver user value that did not depend on the engineering team.

If you are a software developer, rest assured that if you have not experienced this situation in your career, you surely will. The problem with rewriting software is that by rewriting it, the team stops doing new things for its user, as I showed in the example of Locaweb’s Email Marketing product. From a business standpoint, when software does not evolve, customers see no evolution, may lose interest in using the product and will start looking for better options in the market. Therefore, I would like to make some considerations on the subject.

1) New and better technologies will always appear. In the past, systems were developed with everything in the same code base. Then it was the MVC concept (model, view, controller) separating software code into layers according to their function. More recently, the concept of microservices was created, breaking the application into small, loosely coupled applications, preferably done via APIs and facilitating maintenance. If with every new technology that comes along we are going to rewrite the software, we will certainly do nothing but rewrite software.

2) Software rewriting must have a clear business motivation, ie it must somehow meet the strategic goals of the software owner company as it fulfills a user’s need or solves a customer problem. If there is no clear business motivation, the recommendation is not to rewrite.

3) If rewriting is unavoidable (are you sure?), it is important to think about this rewrite initiative from a business perspective, that is, what is the impact of this rewriting on customers and the software owner. Understanding this is the responsibility of the product manager. Some questions to help you reflect with your team on this impact:

  • What will this rewrite look like?
  • While rewriting is going on, will new features be delivered?
  • How will the new system coexist with the old system?
  • When new features are implemented, will they be implemented on the new system and the old system, or only on the new system?
  • When can new clients be installed on the new system?
  • When will existing customers be migrated to the new system?
  • If there is a proposal to make a synchronizer, so that customer data exists simultaneously on the old system and the new system, what is the cost of this proposal compared to not making this synchronizer?
  • If the difference between the old system and the new system can be perceived by customers, how will this difference be communicated?

There you go, some considerations about software rewriting, a very important topic for any product manager.

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

The relationship between product engineering and product management

How should the product manager relate to different areas of the company? Engineering, UX, product marketing, project management, operations, sales, legal, finance, customer service, human resources, and general management.

Recalling what I said in the article Main characteristics of a product manager, the most important feature every product manager needs to have is empathy, that is, the ability to put oneself in someone else’s shoes to understand their desires, motivations, needs, and problems. This feature should be used not only with the customer of the product but also with people from different areas of the company.

As said, the product manager must understand the impact his product has on legal work: have legal issues increased due to some new functionality in the product? And what about the sales, support, operations, finance, marketing staff, did the new product complicate their lives so much? And for the product team, the engineers and UX analysts who are part of the product core team, how do your product decisions impact their functions?

This is what we will see in this new series of articles!

Product engineering and product management

I will start by talking about the relationship between product engineering and product management.


Product engineering is responsible for developing the product and keeping it operating. With the business vision brought by the product manager, plus the solution design made by UX people – based on an understanding of the customer’s need or problem – product engineering “builds” the product.

To build it, they must not only do the programming but also define the technical architecture. That is, what infrastructure it will run on, which programming language is most appropriate, which database is most appropriate, how to ensure the non-functional requirements of this product (response speed, availability, scalability, etc.). It is also important to validate with the product manager whether the cost of this infrastructure fits his business model.

No alt text provided for this image

The fact that the product manager is responsible for defining the product to be made may give the impression that product engineering reports to product management. However, this view is incorrect, and if areas behave in this way, the chance of product failure increases because those who perceive themselves subordinate have less commitment to the outcome.

Product engineering, product management, and UX are one team, there is no subordination relationship between any of these groups. They should function as partners, each with their own expertise and responsibility, collaborating to produce the best product possible.


In the previous diagram, product engineering brings the available technology. As I explained in the article Innovation: what is it?, to innovate is not simply to know the latest technology. You need to know not only this, but all available technologies, and how to use them. This is the role of product engineering. The opportunity and potential for producing an innovation lie in knowing the technologies available and knowing how to use them to solve a problem or meet a need of a group of people.

Practical Advice for Product Managers

To make life easier with the product engineering team, here are some practical tips:

  • Don’t get into the technical solution unless you have earned the right to meddle. A product manager should have some technical knowledge of your product, but this is not your area of expertise. The experts are in the product engineering team. Therefore, avoid presenting technical solutions to the engineering team unless this team is open to receive your suggestions, and even so, the more time you spend thinking and discussing about the technical aspects of your product, the less time you will have to learn about your companies’ objectives and your clients’ problems and needs.
  • Take engineers into conversations with customers and users. As part of your daily life as a product manager, you should always talk to your customers and users to understand how your product solves their problems or meets their needs, and how you can make your product look even better. Engineers love to go to these conversations very much. It is a very cool experience for them to see real people using software they have developed. They will be even more engaged in the mission of making a better product.
  • Always make data-driven decisions. Whether it’s data from your product access and usage, or data from your customer and user conversations, use data to make your decisions and present it to the team. This will give more consistency to the items you will place on your product roadmap.
  • Learn to take out the excess. Always look for the minimum product or the minimum functionality, ie try to implement as little as possible to achieve your business objective.
  • Be present. It is critical to be with the product engineering team or at least as accessible as possible to the team. During product development, doubts will inevitably arise and if you are not present, either the team stops, or they will implement as they think it should be, which may differ from what you had planned.
  • Provide the team feedback about the product. You, as a product manager, know how your product is doing, how many users it has, what these users are thinking of it, how this product is helping the company achieve the goals. Tell this periodically to the product engineering team. As a result, you will be giving context and purpose to the team.
  • Negotiate the rewriting and maintenance stories. The engineering team, if it is a good team – attuned to good software engineering practices evolution and always following what’s new in the software development industry – will always find better ways to implement each piece of the product. If it is dependent only on the engineering team, the product backlog will only have stories about technical improvement. This is good, it shows that you are working with a great engineering team. However, you should use the previous item to provide the team with product context, ie to show that there are certain definite goals for the product that you as a team have to achieve, and therefore you should always release new features in it. There must be a balance between maintenance and rewriting stories, and new features. I’ve read in many places something like: “define X% of the time for maintenance and rewriting stories”. I don’t like to make this suggestion because I believe that every moment of the product requires a different balance, and it’s up to the product manager and his engineering team to talk and mutually agree on this appropriate balance at each stage. Remember the importance of finding a good balance, as this will avoid the famous technical debt that, as it grows, will slow down the product engineering team.

Oh, and there’s one more thing!

Some product engineers end up becoming great product managers. It’s important to be able to figure out when an engineer is looking for “something else to do” and give him that career choice.

At Locaweb, we have (and had) great product managers who were product engineers. In some cases, they became product managers of the product in which they were engineers. On the other hand, there are some product engineers who have tried product management and disliked it.

For those who are used to measuring their productivity by features delivered, it may be strange at first to lose that productivity benchmark. As we have seen, a product manager’s day to day life is made up of a lot of talk with the various people involved in it, and that lot of talk can “scare” the engineer who is used to working focused on feature development. So, you have to leave the door open so that she can be a product engineer again, without any harm to her career.

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

A importância do contexto no desenvolvimento de software

Nesse artigo quero propor um experimento mental. Vamos usar da empatia, principal característica de um gestor de produtos de software, para nos colocarmos no lugar de um desenvolvedor de software que recebeu do gestor de produtos do seu time a seguinte história para ser implementada:

Quando chegar em 39, deve soar um alarme.

Apesar de parecer ter informação suficiente, quando você começar a implementar, verá que está faltando informação. O que são esses 39? Quando chegar em 39 vindo de 38 ou vindo de 40? Ou nos dois sentidos?

Vamos agora ver a mesma história, só que com o devido contexto:

Estamos fazendo um sistema que monitora temperatura corporal e esse sistema deve soar um alarme quando a temperatura subir e passar de 39ºC.

Com o contexto fica bem mais fácil de entender o que são os 39 e porque foi pedido para soar o alarme. Sabendo disso fica bem mais fácil escrever o software certo.

Por isso, em sua próxima sessão de planejamento com o time, invista um tempo em explicar o contexto das histórias. Com isso você aumentará as chances de sucesso de seu software!

Não dá mais, tem que reescrever tudo…

Já ouvi essa frase várias vezes ao longo da minha carreira. Quem trabalha com desenvolvimento de software sabe que invariavelmente chega um momento em que aparece essa discussão com frases como: Está cada vez mais difícil mexer no código. Se fosse fazer do zero, seria muito mais rápido. Se não reescrevermos, vai ficar cada vez mais lento e perigoso mexer no código.

Na Locaweb tínhamos o produto de Email Marketing, para envio e gerenciamento de campanhas de email marketing, que usava como base de dados o MongoDB, uma base de dados não relacional conhecida por sua capacidade armazenar grandes bases de dados. Contudo, provavelmente devido à nossa pouco experiência em desenvolvimento de software usando esse tipo de base de dados e em administrar bases de dados não relacionais, à medida que a base de dados crescia, o sistema ficava cada vez mais lento. Por isso foi necessário reescrever o produto para usar PostgreSQL. Desenhamos essa reescrita de forma a ser transparente para os clientes, ou seja, o cliente não ia ser migrado de uma base de dados para outra, evitando assim passar por um período de indisponibilidade ou eventual perda de dados. A reescrita foi um sucesso. O processo todo de reescrita, incluindo colocar todos os clientes existentes (mais de 15.000 clientes) na nova base de dados, permitindo desligar a base de dados MongoDB, levou seis meses, um prazo razoável para uma iniciativa desse tamanho. Contudo, durante esses seis meses o time não entregou nada novo para o cliente. Nenhuma nova funcionalidade. Para diminuir a frustração de nossos clientes, decidimos por contratar uma empresa terceirizada para construir aplicativos para iOS e Android em cima das APIs existentes do produto. Com isso conseguimos entregar novas funcionalidades para nossos clientes enquanto o time de produto ficava focado no reescrita. Se essa opção não existisse, teríamos que encontrar outras formas de entregar valor para o usuário que não dependessem do time de engenharia.

Se você trabalha com desenvolvimento de software, tenha certeza que, se ainda não passou por essa situação em sua carreira, certamente passará. O problema de reescrever software é que, ao reescrever software, o time deixa de fazer coisas novas para o usuário do software, como mostrei acima no exemplo do produto de Email Marketing da Locaweb. Ou seja, do ponto de vista de negócio o software não evolui, o cliente não vê evolução, e pode perder o interesse pelo seu produto passando a procurar opções melhores no mercado. Por isso eu gostaria de tecer algumas considerações sobre o tema:

  • Tecnologias novas e melhores irão aparecer sempre. Antigamente desenvolvia-se sistemas com tudo em um código só. Depois foi o conceito de MVC (_model_, _view_, _controller_) separando o código do software em camadas de acordo com sua função. Mais recentemente foi criado o conceito de microserviços, quebrando a aplicação em aplicações pequenas, conectadas com baixo acoplamento, feito preferencialmente via APIs, facilitando a manutenção. Se, a cada nova tecnologia que aparecer, formos reescrever o software, certamente não faremos outra coisa senão reescrever software.
  • Reescrever software tem que ter uma motivação clara de negócio, ou seja, deve de alguma forma atender os objetivos estratégicos da empresa que é dona do software e deve atender às necessidades ou resolver um problema dos clientes. Se não houver uma motivação clara de negócio, a recomendação é não reescrever.
  • Se reescrever for inevitável (tem certeza?), é importante pensar nessa iniciativa de reescrita do ponto de vista de negócios, ou seja, qual é o impacto dessa reescrita para os clientes e para o dono do software. Entender isso é responsabilidade do gestor de produtos. Algumas perguntas para te ajudar a refletir junto com o time sobre esse impacto:
    • Como será essa reescrita?
    • Enquanto a reescrita estiver acontecendo, vão ser entregues novas funcionalidades?
    • Como será a co-existência do sistema novo com o sistema velho?
    • Quando forem implementadas novas funcionalidades, serão implementadas no sistema novo e no sistema velho, ou só no sistema novo?
    • Quando novos clientes poderão ser instalados no sistema novo?
    • Quando os clientes existentes serão migrados para o sistema novo?
    • Se existir a proposta de fazer um sincronizador para que os dados dos clientes existam simultaneamente no sistema velho e no sistema novo, qual é o custo dessa proposta se comparado com a opção de não fazer esse sincronizador?
    • Se a diferença entre o sistema velho e o sistema novo puder ser percebida pelos clientes, como essa diferença será comunicado?

Pronto, aí estão algumas considerações sobre reescrita de software, um tema muito importante para qualquer gestor de produto.

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!

Como quadruplicar a produtividade de desenvolvimento de software sem aumentar o time e sem queda de qualidade

Escrevi há algum tempo atrás um artigo sobre como organizar times de desenvolvimento de produto e algumas mudanças que fizemos nos times de desenvolvimento de software da Locaweb.

Temos nos focado bastante, desde o ano passado, em produtividade, ou seja, em como os times de desenvolvimento de produto e de software da Locaweb podem produzir mais, sem precisarmos colocar mais gente nos times, e sem que a qualidade das entregas caísse.

O gráfico abaixo mostra nossos números. Contabilizamos quantidades de entregas por semana e, como dá para ver no gráfico, em algumas semanas mais do que quadruplicamos a quantidade de entregas por semana.


Esse aumento de produtividade aconteceu quando o time cresceu apenas 10% em quantidade de pessoas, ou seja, não dá para creditar esse aumento de produtividade ao aumento de pessoas nos times.

Quando há um aumento desses, além do natural questionamento sobre se o aumento de produtividade se deve ao aumento de pessoas nos times, outro questionamento que existe é se houve queda da qualidade das entregas. Uma das medições de qualidade que fazemos é a quantidade rollbacks. Como dá para ver abaixo, mesmo com o aumento de produtividade, a quantidade rollbacks foi reduzido em 40%!


Como conseguimos isso?

Não há bala de prata, foram várias ações que tomamos e temos certeza de que ainda há mais ações que poderão ser tomadas para aumentar ainda mais. Aqui vai uma lista do que fizemos.

  • Medir: antes de mais nada, para melhorar qualquer coisa é preciso medir, para poder saber se essa coisa está melhorando! Fizemos uns cálculos estimados de entregas por semana no período de setembro de 2015 a fevereiro de 2016. O cálculo foi bem simples, total de deploys feitos no período dividido pelo número de semanas. Passamos então a comunicar toda a empresa sobre as entregas da semana. Cada gestor de produtos me manda na sexta-feira as entregas da semana, eu compilo os dados e anoto a quantidade de cada semana, gerando esse gráfico mais acima. A partir do momento que começamos a medir, ficou mais claro o nível em que estávamos e as ações que passamos a fazer começaram a mostrar resultado no gráfico. Além disso, os times passaram a usar uma única ferramenta de medição, o Jira, o que deu a eles uma visão melhor de progresso de cada time e permitiu comparações com troca de experiência, ou seja, algo na linha de “olha que interessante no seu gráfico, como vcs conseguiram aumentar esse indicador?”
  • Kanban vs sprint: outro ponto que mexemos foi a mudança de Kanban para sprint. Antes, todos os times rodavam com Kanban. Só que no Kanban, quando um item tem um impedimento, ele não pode ser mexido, e o time não pode fazer mais nada, o time fica travado. Contudo, às vezes acontecia de o time, por estar impedido mover um item de “doing” para “to be done” e pegar outro item para fazer o que não deveria ser feito. Uma vez em “doing” a tarefa só pode ir para “done”, não pode voltar pra “to be done” pois perde-se o controle da produtividade. Com sprint, o time organiza as próximas duas semanas de trabalho, colocando vários itens para serem trabalhados. Assim, se algum item tiver impedimento, o time pode começar a mexer em outro item e, com isso, consegue entregar mais no mesmo intervalo de tempo.
  • Discovery e delivery: o que o designer de UX e o gestor de produtos fazem pode ser chamado de discovery, ou seja, descobrir o que é preciso ser feito. Já o que engenharia faz pode ser chamado de delivery, ou seja, fazer e entregar o que tem que ser feito. Essa separação de papéis parece óbvio, mas não deixar isso explícito nos times pode atrapalhar o processo de desenvolvimento de software. Por quê? Por alguns motivos. O primeiro é que se o discovery não é visto de forma explícita, não é claro o que é feito nessa fase e nem o que motiva certas decisões sobre o que deve ser implementado no software. É díficil fazer alguma coisa sem saber porque se estáfazendo aquilo. O segundo motivo é que quando essa separação não é explícita, itens podem ir e voltar de delivery para discovery e vice-versa sem critério. Não raro a gente via nos times algo sendo implementado pelos engenheiros e UX e gestor de produtos, ao verem sua especificação implementada, desejarem mudar algo, no meio do desenvolvimento. Com a separação clara entre discovery e delivery, definimos que, uma vez indo para delivery, não se mexe mais. Se quiser mexer de novo, deve passar por novo discovery para só então ir para delivery.
  • Tamanho das entregas: uma discussão que temos já há alguns meses é sobre o tamanho das entregas. Em alguns casos nossas entregas eram bem grandes, trabalho de várias semanas ou até alguns meses. Como já amplamente discutido em metodologias ágeis, a entrega frequente de software funcionando é um dos princípios de agilidade, reforçado pela técnica de entrega contínua. É só procurar no Google para encontrar inúmeros exemplos de empresas de primeira linha que fazem múltiplos deploys por dia, com algumas fazendo centenas de deploys por dia! :-O Para fazer isso, é preciso os deploys sejam de entregas pequenas, bem pequenas. É preciso dividir toda história grande em hostórias menores. Isso é trabalho deo gestor de produtos em conjunto com o designer de UX. Já me perguntaram se isso não é trapacear, afinal, ao invés de entregar uma história grande estaremos entregando a mesma coisa só que dividido em pequenas histórias. Parece ser a mesma coisa, mas ao invés de entregar algo grande depois de semanas ou até mesmo meses, a gente acaba entregando valor todo dia, e assim nosso usuário já pode usufruir dos benefícios logo, ao invés de esperar semanas ou meses. Além disso, ao colocar em produtção todos os dias, já podemos aprender com o feedback e ajustar entregas futuras. E ainda há um benefício adicional, o fato de colocar em produção todo dia algum código faz desse processo de colocar código em produção algo mais simples, exatamente pelo fato de ser feito diariamente. Então, entregar uma história grande num período de semanas ou meses não é a mesma coisa que quebrar essa história em pequenos pedaços e entregar um pedacinho todos os dias. Há ganhos claros de produtividade em se entregar pequenos pedaços com frequência.

Além desses pontos acima, estamos começando a experimentar mais alguns pontos que certamente têm impacto na produtividade:

  • Primeira solução vs solução mais simples: é da natureza humana querer resolver problemas. Assim que um problema aparece, a primeira reação é pensar em uma solução e sair implementando essa solução para resolver o problema. Só que nem sempre a primeira solução é a melhor solução, tanto do ponto de vista do cliente, quanto do ponto de vista de quem implementa a solução. Por esse motivo temos preferido não começar a resolver imediatamente cada novo problema que aparece. Buscamos antes verificar se há mais soluções possíveis, analisamos todas as soluções e só aí escolhemos uma solução e partimos para a solução. Investir mais tempo pensando em outras possíveis soluções, sempre tendo claro qual a questão a ser resolvida e porque precisamos resolver essa questão. Saber o porquê ajuda a encontrar soluções simples. Uma solução simples (1 semana de implementação) que resolve 70% a 80% do problema é melhor do que uma complicada (1 mês de implementação) que resolve 100% e, na maioria das vezes, resolver 70% a 80% do problemaé mais do que suficiente. Às vezes a solução mais simples é não fazer nada!

    Exemplificando, na Locaweb o serviço de hospedagem e de email pode deixar de funcionar por um motivo externo ao serviço. O domínio ao qual a hospedagem e o email estão ligados, que é pago anualmente para o, pode não ter sido renovado e, quando ele não é renovado, os serviços associados a esse domínio deixam de funcionar, mesmo que tudo esteja operando perfeito na Locaweb. Recentemente a disponibilizou uma forma de a Locaweb cobrar o domínio do cliente em nome da A princípio a ideia parece boa, com a gente cobrando a gente garante que o cliente sabe que tem pagar esse domínio para manter os serviços no ar. Só que, analisando um pouco melhor, vimos que essa solução pode gerar mais problemas. O cliente vai receber duas cobranças pela mesma coisa, o registro de domínio, pois o iria continuar cobrando o domínio. O que acontece se ele pagar as duas cobranças? E se ele pagar só a da E se ele pagar só a da Locaweb? Além disso, implementar um novo tipo de cobrança, onde iremos cobrar pelo serviços de terceiro, seria algo novo para o time e para a Locaweb. Novos processos teriam que ser desenhados. Começamos então a pensar se não existiriam formas mais simples de resolver o problema de ajudar nosso cliente a não esquecer que ele tem que pagar por seu registro de domínio na Como para poder cobrar pela é necessário acessar a informação de que o domínio está para expirar, pensamos na seguinte solução, vamos implementar uma régua de comunicação com esse cliente avisando-o da importância de pagar o, para garantir que o serviço continue funcionando, solução essa bem mais simples que duplicar o processo de cobrança. Se a fornecer tb link direto para a cobran;ca do domínio, podemos mandar esse link na comunicação e as chances de resolver o problema aumentam ainda mais. E uma régua de comunicação é bem mais simples de implementar do que uma cobrança duplicada.

  • Escolha da ferramenta mais apropriada: aqui o tema são ferramentas para implementação da solução, ou seja, linguagem de programação, frameworks e bancos de dados. Cada ferramenta tem suas características e essas características as fazem mais apropriadas para resolver certos tipos problemas. Escolher a ferramenta certa para cada problema vai impactar a produtividade. Esse é um tema que estamos começando a estudar agora. Hoje usamos Rails para quase tudo, mas tem alguns problemas para os quais a implementação de solução usando outro framework ou outra linguagem pode ser mais simples e rápido. Usar uma única linguagem de programação para todos os problemas é como usar uma única ferramenta para todos os consertos que tem que ser feitos. Será que o martelo é a melhor ferramenta para apertar um parafuso? Será que Rails é a melhor ferramenta para gerenciar filas?

Temos confiança de que com os dois pontos acima, que estamos começando a mexer agora, conseguiremos aumentar a produtividade por 10x ou mais! \o/

E com certeza há ainda pontos que sequer percebemos ainda e que, quando percebemos e tratarmos, podem impactar ainda mais.


Como disse acima que não há uma bala de prata, mas tem uma ação específica que fizemos que tem impacto crucial nesses resultados: transformamos produtividade em tema importante em nossas conversas. Todos passaram a conversar sobre produtividade, o que pode impactar e como endereçar esses pontos. Esse movimento nos fez iniciar várias mudanças e experimentos que nos ajudaram a aumentar consideravelmente nossa produtividade. Se você também quer aumentar a produtividade de seu time de desenvolvimento, coloque essa tema como tema central de suas conversas e experimente bastante. Vc verá como há espaço para melhorar bastante a produtividade dos seus times de desenvolvimento de software.

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/

Engenharia de produtos e gestão de produtos

Estava relendo alguns posts e quando li o último post da série sobre diversificação de portfólio de produtos lembrei que fiz promessa de dois posts, um sobre a relação de UX e gestão de produtos e outro sobre a relação de engenharia e gestão de produtos. Como promessa é dívida, está na hora de pagar as minhas dívidas. Vou começar falando sobre a relação entre engenharia de produto e gestão de produtos.



Engenharia de produto é responsável por desenvolver o produto e mantê-lo operando. Com a visão de negócios trazida pelo gestor de produto, mais o desenho de solução feito pelo pessoal de UX, baseado no entendimento da necessidade ou do problema do cliente, a engenharia de produto “constrói” o produto. Para construir o produto ela deve não só fazer a programação, como também definir a arquitetura técnica do produto, ou seja, qual é a infra-estrutura onde vai rodar esse produto, qual a linguagem de programação mais adequada, qual o banco de dados mais apropriado, como garantir os requisitos não funcionais desse produto (velocidade de resposta, disponibilidade, escalabilidade, etc). Deve tb validar com o gestor de produtos se o custo dessa infra-estrutura cabe no modelo de negócio desse produto.


Pelo fato de o gestor de produto ser responsável por definir o produto a ser feito, pode dar a impressão que a engenharia de produtos está subordinada à gestão de produtos, mas essa visão é incorreta e, se as áreas se comportarem dessa forma, a chance de fracasso do produto aumenta, pois quem se sente subordinado tem menos comprometimento com o resultado. Engenharia de produtos, gestão de produtos e UX são pares, não há relação subordinação entre nenhum desses grupos. Eles devem funcionar como parceiros, como sócios, cada um com sua especialidade e com sua responsabilidade, colaborando para produzir o melhor produto possível.


No diagrama acima a engenharia de produtos é quem traz a tecnologia disponível. Certa vez vi uma definição interessante sobre inovação. Inovar não é simplesmente conhecer a última tecnologia. É preciso conhecer não só a última tecnologia, como também todas as tecnologias disponíveis e saber como usá-las. Esse é o papel da engenharia de produtos. Conhecer as tecnologias disponíveis e saber como usá-las para resolver um problema ou atender a uma necessidade de um grupo de pessoas é o que tem potencial de produzir uma inovação.

Dicas práticas para gestores de produto

Para facilitar o dia-a-dia com o time de engenharia de produto, aqui vão algumas dicas práticas:

  • Não se meta na solução técnica, a não ser que vc tenha conquistado o direito de se meter nas soluções técnicas. Um gestor de produto deve ter algum conhecimento técnico sobre seu produto, mas essa não é sua área de especialidade. Os especialistas estão na equipe de engenharia de produto. Por isso, evite apresentar soluções técnicas para o time de engenharia de produto a não ser que esse time te dê abertura para isso.
  • Leve engenheiros nas conversas com clientes e usuários. Como parte do seu dia-a-dia como gestor de produto, vc deve conversar sempre com os clientes e usuários de seu produto para entender como seu produto resolve o problema ou atende à necessidade desse seu cliente ou usuário e como vc pode fazer seu produto ainda melhor. Os engenheiros gostam muito de ir a essas conversas. É uma experiência única quando eles vêem pessoas reais usando um software que eles desenvolveram. Eles ficarão ainda mais engajados na missão de fazer um produto melhor.
  • Sempre tome decisões baseadas em dados. Quer seja dados de acesso e de uso do produto, quer seja dados de conversas com clientes e usuários, use dados para tomar suas decisões e apresente esses dados para o time. Isso dará maior consistência às histórias que vc irá colocar no roadmap do seu produto.
  • Aprenda a tirar o excesso, busque sempre o produto mínimo ou a funcionalidade mínima, ou seja, procure implementar o mínimo possível para atingir o seu objetivo denegócio.
  • Esteja presente. É fundamental estar junto com o time de engenharia de produto ou, pelo menos, acessível ao time o máximo de tempo possível. Durante o desenvolvimento do produto inevitavelmente surgirão dúvidas e, se vc não estiver presente, ou o time para, ou o time vai implementar como eles acham que deve ser, o que pode ser diferente do que vc havia planejado.
  • Dê feedback para time sobre o produto. Vc, como gestor de produto, sabe como o seu produto está indo, quantos usuários tem, o que esses usuários estão achando do produto, como esse produto está ajudando a empresa a atingir seus objetivos. Conte periodicamente sobre isso para o time de engenharia de produto. Como isso vc estará dando um contexto e um propósito para o time.
  • Negocie as histórias de reescrita e de manutenção. O time de engenharia, se for um bom time, antenado na evolução das boas práticas de engenharia de software, sempre irá descobrir formas melhores de implementar cada pedaço do produto. A depender do time de engenharia, o backlog do produto só teria histórias de melhoria técnica. Isso é bom, mostra que vc está trabalhando com um ótimo time de engenharia. Contudo, vc deve usar o item anterior para dar o contexto do produto para o time, ou seja, mostrar que há determinados objetivos definidos para produto que vcs tem que atingir e que, por isso, vcs devem sempre colocar novas funcionalidades no produto. Deve existir um balanço entre histórias de manutenção e reescrita e de novas funcionalidades. Já li em vários lugares algo como defina X% do tempo para histórias de manutenção e reescrita. Eu não gosto de dar essa sugestão, pois acredito que cada momento do produto requer equilíbrio diferente e cabe ao gestor de produto e ao time de engenharia de produto conversar e definir de comum acordo esse equilíbrio apropriado a cada fase do produto. Vale lembrar da importância de encontrar um bom equilíbrio, pois isso evitará o famoso débito técnico que, à medida que cresce, fará com que o time de engenharia de produto fique cada vez mais lento.

Ah, e tem mais um ponto!

Alguns engenheiros de produto acabam se tornando ótimos gestores de produto. É importante ser capaz de perceber quando um engenheiro está procurando “outra coisa pra fazer” e dar a ele essa opção de carreira. Na Locaweb temos e tivemos ótimos gestores de produto que eram engenheiros de produto. Em alguns casos acabaram se tornando gestor de produto do próprio produto em que era engenheiro. Por outro lado, existem alguns engenheiros de produto que experimentam a gestão de produtos e não gostam. É preciso deixar a porta aberta para ele poder voltar a ser engenheiro de produto, sem nenhum prejuízo para a sua carreira.

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?