How and when to delegate

Delegating is the act of entrusting someone with a task and/or responsibility, usually with less seniority than the person who is delegating. Leadership is an ongoing act of delegating tasks and responsibilities. It seems like a straightforward activity, but it has several important aspects to consider to increase the chances of success.

Jurgen Appelo, author of the aforementioned book Management 3.0: Leading Agile Developers, Developing Agile Leaders, comments that delegating is not a binary decision to which you delegate or do not delegate. There are other levels of delegation between these two extremes and each of these other levels should be used depending on the context, that is, the problem to be solved and who will be working on the problem. According to him, there are seven levels:

  • Say: you make decisions and announce them to your team. In fact, this is not delegation. (=
  • Sell: you make decisions, but try to “sell” your idea to your team.
  • Consult: you invite your team to comment and consider their contributions.
  • Agree: you invite your team to participate in a discussion and reach a consensus as a group. Your voice is just like the others.
  • Advise: you try to influence your team by giving them advice, but let them decide what to do with your opinion.
  • Ask: you let the team decide. And then you ask about their motivations or ask them to actively keep you informed.
  • Delegate: you leave it entirely to the team to handle the matter, and you don’t even need to know what decisions they make.

I confess that in my day to day I don’t think about what kind of delegation I’m doing in each situation, it’s something more intuitive, but it’s good to be aware of and to remember these different levels of delegation. I have the impression that between “saying” and “delegating” there are more than 5 options. We navigate between these options fluidly according to the seniority of the team, the specific experience of the team with the topic in question, and how much this topic implies in any kind of risks.

The concept of delegation goes hand in hand with the concept of micromanagement:

Micromanagement

Micromanagement is the management style in which the manager closely observes or controls the work of his subordinates or employees. Micromanagement generally has a negative connotation.

Source: Wikipedia

Micromanagement shows the leader’s inability to delegate. There are usually two reasons for a leader to micromanage his team:

  • Insecurity: the leader is insecure, concerned with doing everything right, so he wants to follow every detail of everything that is being done. In some (many) cases, this leader will do the work of a person on your team to ensure that it is being done “the right way”. This type of leader often creates many rules and procedures to ensure that things are being done the way he takes for granted.
  • Personality: It is the leader’s personality to enjoy seeing people suffering under pressure. This leader tends to be abusive on a daily basis with the team. He won’t do anyone’s job, but he will follow all the details closely to see them uncomfortable under this constant scrutiny.

The most common is to find leaders with insecurity, usually people who are leading for the first time, but who eventually end up understanding their role and exercising delegation. Leaders who micromanage because of their personality are rare and unlikely to change.

People on a team that is being micromanaged tend to quickly disengage. Once they are doing things the manager’s way, they do not perceive themselves as responsible for the result obtained, whether the result is good or bad. If the result is good, the leader will probably attribute success to his way of doing things. If it goes wrong, the person who did the job will not feel responsible, as he “just followed orders”.

Ways to do

One of the biggest barriers to delegation is the leader’s certainty that his way of doing things is the right one. When he was an individual contributor he did things that way and the result came. So much so that he was promoted to manager for doing things that way. So, what he understands that he has to do as a manager is to make sure that all the people on his team do things the way he does. At that moment, this leader’s need for micromanagement appears.

A leader must always focus on the expected result. The way in which this result is achieved is less important than obtaining the result. If a person on your team does things differently than you usually do, it does not mean that the way they do it is wrong (of course, as long as it is not an illicit way and does not harm people). It’s just a different way of doing things. Perhaps even more efficiently. The leader needs to respect this diversity of ways of doing things and only present his way of doing it when he realizes that the person is not managing to evolve alone.

Learning opportunity

Every time we delegate something for someone to do, if it is the first time that person is doing it, it will be a learning opportunity. For this reason, the person is very likely to make some mistakes, and here comes one of the most difficult trade-offs of a leader. How much error is acceptable? This depends a lot on each situation, it is up to the leader to understand if the mistakes are acceptable to allow learning, or if given the criticality of the work to be done, mistakes must be minimized. We must always create an environment conducive to learning from mistakes, as this will be the most effective learning. That’s what I try to do with the teams I lead.

Summing up

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

Okay, with this chapter we conclude the part about my personal principles of leadership (people: priority # 1 – always, leading is like being a doctor, leading under pressure, mentoring is a two-way street, and how and when to delegate). In the next chapters, we will see what culture is and what values ​​I believe are mandatory to create successful digital products.

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.

People: priority #1, always

Every company has its own culture and, within each company, every department also has its own culture. In addition, each person also has their principles and values ​​that guide their steps through life. In this part of the book, part 2 of 3, I will talk about the culture, values ​​and principles that I believe are mandatory to create successful digital products. Also, what are the 4 main values ​​that every product development team and, consequently, every company that has digital product development teams should have.

I’m going to start this part of the book by sharing my personal leadership principles. There will be five principles:

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

I will talk about these principles throughout this and the next chapters, starting with the principle that people are priority #1, always.

People: priority #1, always

I often see companies claiming that company valuation, revenue, growth, profit, number of customers, or customer satisfaction is their number one priority. All are good priorities and each is appropriate for specific contexts in which a company can be. However, I argue that they should be priority number 2, 3, 4 and so on, because our number 1 priority should always be the people who are part of our team. Without the people who work with us, it will be very difficult, if not impossible, to achieve any other goal that we have.

People are people (source: Flickr)

We spend money and energy attracting the best people and convincing them to join our company to build what we intend to build to achieve the goal we have set. We pay these people to be with us throughout the construction process. We are usually upset when we lose people on our team, especially if they are really engaged and aligned with our goals. Therefore, the people on our team are like customers, we spend money and energy to acquire and retain them. But they are even more important than our customers, because without our team, there is no way for us to be able to deal with our customers and achieve our goals.

This does not mean that we need to be “nice” to our team, or that we should give everything they ask for. What we need to do is to balance external and internal pressures so that people can continually improve. If the external pressure is increasing, we need to create the environment and provide the tools for people to be more motivated, have more drive, and increase their inner strength. And if we have people or teams with excess motivation and energy, we need to give them more responsibilities and higher goals. In the chapter Leading under pressure, I will talk more about this balance.

Rotten apples

The term rotten apple, although quite strong, serves to describe a very delicate situation in the formation and management of teams. We call the person who negatively clashes with the rest of the team and who, with his behavior, may spoil the team.

InfoQ (https://www.infoq.com/news/2009/01/handling-your-underperformer/) talked a lot about the technically rotten apple theme, the under-performer, the one who is technically below the rest of the team, and how the team can help this person to improve.

What to do when we come across a rotten apple from a behavioral point of view? Someone who is technically good, but who has behavioral problems? Technically this person can have enough to contribute to the team but his behavior makes the team unable to have a good relationship with that person.

In such cases there are two paths to follow:

  • The simplest is to remove that person from the team. This is an easy solution for both the team and its leader. The tendency in such a situation is for the team to isolate the difficult person until he, by himself or by the leader’s decision, leaves the team.
  • The most difficult path, but which will certainly bring more benefits to the team, is to help this difficult person to belong to the team to the point where the person is no longer a bad apple.

It is easy to welcome people who are easy to deal with. The challenge is to receive a difficult person and help them join the team. The values ​​of the team must be stronger than the values ​​of the difficult person to the point that the values ​​of the team are absorbed and assumed by the difficult person.

Frank conversations with the whole team and with the difficult person are a good tactic. Transparency is essential. If there are goodwill and willingness from both the team and the “rotten apple”, chances are good that the situation will be reversed.

It is worth remembering that, in most cases, a rotten apple does not want to be a rotten apple. He may not realize that her behavior is harmful to the team. He may have had previous experiences where her behavior would be considered normal. So it is worth investing in helping the team and the difficult person to understand each other. However, it is not possible to try indefinitely to make things right. It is important to set a deadline to reevaluate the situation and, if it has not been resolved, there may be no other option but to make a more difficult decision: dismiss one or more people from the team.

Summing up

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

In the next chapter, we will understand what a leader’s job should be like through the analogy that leading is like being a doctor.

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.

2 hacks para promover e fortalecer sua cultura de produto digital

Tenho liderado o desenvolvimento de produtos no Gympass há quase 2 anos. Antes do Gympass, eu sempre trabalhei em empresas onde a tecnologia era o principal produto da empresa como a Conta Azul e a Locaweb. Nesse tipo de empresa, a cultura de produtos faz parte da cultura organizacional. No entanto, se você estiver em uma empresa tradicional ou mesmo em uma “empresa tradicional nativa digital”, criar e manter uma cultura digital de produtos pode ser um grande desafio.

O que é cultura de produto digital?

As equipes de produtos digitais têm duas premissas principais quando criam produtos para atender aos objetivos estratégicos da empresa enquanto resolvem um problema ou atendem a uma necessidade dos clientes e usuários da empresa:

  • Lançamento antecipado e frequente: quanto mais cedo eu apresentar meu produto a seus usuários, melhor, pois poderei receber feedback de usuários reais que poderão usar o produto em seu próprio contexto. Expliquei as motivações por trás do lançamento antecipado e frequente neste artigo.
  • Foco no problema: é da natureza humana resolver problemas. Sempre que ouvimos falar de problemas, entramos quase imediatamente no modo de solução, ou seja, começamos a buscar soluções para o problema. No entanto, se conseguirmos entender melhor o problema, a motivação para resolvê-lo, o contexto em que o problema ocorre, há boas chances de conseguirmos encontrar soluções mais simples e fáceis de implementar. 

Quando a cultura tradicional da empresa entra em conflito com a cultura digital de produtos e como combater esse conflito

Nas empresas tradicionais, e mesmo em algumas empresas digitais e empresas tradicionais nativas digitais, a equipe de vendas está sempre conversando com clientes em potencial, entendendo seus problemas e dores e descobrindo onde o produto pode ser uma boa solução para esses problemas. Por esse motivo, os novos lançamentos da equipe de desenvolvimento de produtos quase sempre são bem-vindos, mas também são bastante esperados.

Assim que um novo lançamento estiver disponível, os vendedores desejam oferecer a todos os novos clientes em potencial. Isso aconteceu e ainda acontece muito aqui no Gympass. O problema é que, em função da premissa de “lançamento antecipado e frequente” que expliquei acima, as primeiras versões de uma funcionaliddade ou de um produto são normalmente um tanto desajeitadas, faltando funcionalidades e com mau funcionamento em determinados casos de uso. Precisamos do feedback do cliente para melhorar o produto em versões futuras. A questão é que, se os clientes em potencial decidirem se tornar novos clientes dessas primeiras versões, esses novos clientes provavelmente ficarão bastante chateados, pois o produto ou funcionalidade pode não funcionar em determinados cenários e pode não oferecer a melhor experiência.

Outro problema que ocorre com frequência quando lançamos cedo e com frequência é o time de suporte ao cliente que reclama, e com razão, que o novo recurso ou produto não está funcionando corretamente e que eles precisam fornecer assistência. Na Conta Azul, a equipe de desenvolvimento de produtos recebia constantemente a reclamação do suporte ao cliente de que lançamos constantemente recursos e produtos inacabados, ou seja, lançamos constantemente recursos ou produtos incompletos. E eles estavam corretos, essa é a consequência natural da premissa de liberação antecipada e frequente explicada acima.

Hack #1: Terminologia alfa, beta e go-live

Por esse motivo, decidi usar o que chamo de hack #1 para promover e fortalecer a cultura de produtos digitais no Gympass. Passamos a usar a terminologia alfa, beta e go-live para explicar em que estágio um produto ou funcionalidade está. No estágio alfa, o produto pode não funcionar corretamente. Se estiver em alfa, deve ser oferecido apenas aos clientes que entendem os problemas do uso de um novo produto e podem lidar com esses problemas sem maiores dificuldades. Portanto, a quantidade de clientes na fase alfa será pequena, no máximo uns 5 clientes, não mais do que isso. No estágio beta, os principais problemas do produto são corrigidos, mas os erros ainda podem ocorrer e a experiência do usuário pode e irá melhorar. Nesta fase, é possível oferecer o produto ou funcionalidade a dezenas de clientes. Depois, quando todos os erros conhecidos forem corrigidos e a experiência do usuário estiver funcionando corretamente, é hora de mover o produto para o estágio de go-live, onde o produto pode ser oferecido a todos os clientes existentes e em potencial. Isso certamente ajuda as equipes de vendas e de suporte ao cliente a entender o ciclo de lançamento de novos recursos e novos produtos e a entender em que estágio está o produto ou a funcionalidade.

A outra área em que a cultura tradicional da empresa entra em conflito com a cultura digital de produtos é a solicitação de novas funcionalidades. É comum ver outras áreas pedindo à equipe de desenvolvimento de produtos que implemente o recurso A ou B porque precisamos desse recurso para fechar um negócio ou para não perder esse grande cliente. Um exemplo comum que tenho ouvido atualmente é “precisamos implementar o Apple Pay e o Google Pay como um novo método de pagamento”. A questão aqui é que, falando em soluções, perdemos o foco no problema que originou essa solução. Se investirmos mais tempo aprendendo sobre o problema, a motivação para resolvê-lo e o contexto em que o problema ocorre, há boas chances de que possamos encontrar soluções mais simples e fáceis de implementar.

Hack #2: Qual é o problema?

Por esse motivo, decidi usar o que chamo de hack #2 para promover uma cultura de produto digital, perguntar sempre “qual é o problema?”. Sempre que uma nova solicitação de funcionalidade chega à equipe de desenvolvimento do produto, devemos agradecer ao solicitante pela pedido e em seguida devemos perguntar sobre o problema que gerou a solicitação. Cada membro da equipe de desenvolvimento de produtos precisa ter esse comportamento sempre que uma solicitação de nova funcionalidade for recebida. Ao praticar esse comportamento, em breve as solicitações virão não apenas com uma solução, mas também com muitas informações sobre o problema. É interessante ver essa mudança cultural, mas requer a disciplina dos membros da equipe de desenvolvimento de produtos para sempre perguntar sobre o problema. E quando menciono os membros da equipe de desenvolvimento de produtos, estou me referindo a todos, não apenas aos gestores de produto, mas também aos designers e às engenheiras e engenheiros de produto.

Resumo

Então, aqui estão eles, 2 hacks para promover e fortalecer sua cultura de produtos digitais:

  • Hack #1: use a terminologia alfa, beta e go-live para descrever em que fase está seu produto.
  • Hack #2: pergunte sempre “qual é o problema?” para entender bem o problema antes de investir energia em buscar soluções.

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

Problem vs solution mindset

When we hurry to launch an MVP, we are creating a solution for a problem. However, a very important step to create a good solution is the understanding of the problem.

It is human nature to jump into solution mode when we learn about a problem. When we hear about a problem, we immediately start thinking about solutions. However, the more time we spend learning about the problem, the easier it will be to find a solution and good chances are that this solution will be simpler and faster to implement than the first solution we think about.

Here’s a great Albert Einstein quote: 

“If I had an hour to solve a problem I’d spend 55 minutes thinking about the problem and five minutes thinking about solutions.” 

Einstein believed the quality of the solution you generate is in direct proportion to your ability to identify and understand the problem you hope to solve.

Let me tell you a short story to illustrate this. During the space race, scientists were faced with the issue of writing in space where there’s no gravity to make the ink go down in a ballpoint pen. Americans started their R&D efforts and after some time and a few million dollars, they built a pen with a small engine that pumps ink to the paper, even with no gravity. Meanwhile, Russians decided to use pencils, which can do the job of writing in no gravity environments.

That focus on solutions, without good understanding of the problem and the motivation to have this problem solved, can be quite harmful. It can make us spend unnecessary time and money to get to sub-optimal solutions. This is a cultural issue, i.e., a behavior that we can and must change. The first step to changing a behavior is recognizing it when it happens. When you, as a product manager or a product development team member, receives a request to implement something, ask the person who brought the request what is the problem that this “something” is supposed to solve and why there’s a need to solve that problem.

Here some examples from the companies I worked for.

At Locaweb, a web hosting provider in Brazil, the hosting and email services may stop working due to external factors such as the domain associated with the hosting and email not being renewed.

  • Original solution: Registro.br, the Brazilian registrar for .br domains released an API to allow Locaweb to charge the customer domain on behalf of Registro.br. At first, the idea seems good, since Locaweb billing the domain looks like the easiest way to guarantee that the customer knows that it has to pay for the domain registration to maintain the hosting and email services functioning properly. However, when we analyzed deeper, we saw that this solution could generate some problems. The customer would be billed twice for the same domain registration because the Registro.br would continue billing the domain. What happens if the customer pays both bills? And if she pays only Registro.br? And if she pays only Locaweb? In addition, implementing a new type of billing where we will bill for a third party service was something new to the Locaweb team. New processes would have to be carefully designed.
  • Actual solution: we started to wonder if there would be simpler ways to solve the problem of helping our customer not to forget that he has to pay for her domain registration at Registro.br. Since it would be possible to charge for Registro.br services, it was possible to access the information about the about-to-expire domain. We decided to design a simpler solution: we will implement a communication sequence with this customer advising him of the importance of paying Registro.br to ensure that the email and hosting services continue to operate normally. This is a much simpler solution than implementing a double billing process. If Registro.br provides us with the billing URL, we can send this link information to the customer and the chances of solving the problem will increase even further. And a communication sequence is much simpler and faster to implement than a duplicate billing process.

At Conta Azul, a SaaS ERP for MSE (micro and small enterprises) we used accountants as one of our distribution channels and wanted to increase sales through accountants.

  • Original solution: batch purchases, where accountants would acquire a fixed number of Conta Azul licenses to resell to their customers. A system to manage batch purchases would take around 3 months to be implemented since it should allow accountants to buy Conta Azul licenses in bulk, but should only start billing the accountant’s customer when she actually activated the license.
  • Actual solution: accountants didn’t care about batch purchases. What they wanted was to provide a discount to their customers so they could subscribe to Conta Azul with this exclusive discount provided by their accounts. The cost to implement this was zero since the system already had a discount management feature.

At Gympass, a fitness partner who was joining our fitness network requested us to present their waiver to everyone who check-in in their facilities.

  • Original solution: change our app to ask end-users who go to this fitness partner to read their waiver in our app and to check a box stating they read and are ok with it.
  • Actual solution: no change to our app. Use a customizable text field in the gym set up in our system that is normally presented to users who will check-in in that gym to present the following text: “By checking in, you agree with the waiver located at http://fitnesspartner.com/waiver”. 

Don’t get me wrong, it is really good that everyone brings solutions to the table whenever we want to discuss something to be done by the product development team. The more solution ideas we have, the better. However, we need to educate ourselves to have a deeper understanding of the problem behind that solution, so we have a chance to find simpler and faster to implement solutions. And it is ultimately the product manager and all product development team member’s job to ask what is the problem and why we need this problem solved.

Digital Product Management Book

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 book Product Management: How to increase the chances of success of your digital product, based on my almost 30 years of experience in creating and managing digital products.

Product Management Book

Fail fast vs learn fast

I recently attended a 2 day MIT course on how to create high velocity organizations. The course was taught by Professor Steven J. Spear, author of “The High-Velocity Edge: How Market Leaders Leverage Operational Excellence to Beat the Competition.” This is one of those very dense courses, full of content, but it can be summarized in one paragraph:

High-velocity organizations are able to learn very fast, especially from their failures, and to absorb that learning as an integral part of the organization’s knowledge.

A high-velocity organization has 4 capabilities:

  1. Be prepared to capture knowledge and encounter problems in your operation.
  2. Understand and solve these problems to build new knowledge.
  3. Share the new knowledge with the whole organization.
  4. Leading to develop skills 1., 2. and 3.

The classic example is Toyota, with lean manufacturing and the concept of stopping production whenever failures are encountered, correcting failures and using failures as a learning opportunity so that failures do not happen anymore. This ability to learn from failures is what gives Toyota the ability to stay ahead of its competitors for so long.

Another good example is Alcoa that had a 2% work incident rate per year which was considered normal. Alcoa has more than 40,000 employees so 2% of work incidents per year means that 800 employees per year have some kind of work incident. That’s a pretty impressive and troubling number. To combat this problem they implemented a policy of zero error tolerance. Prior to implementing this policy, errors was seen as part of the job. Now employees are encouraged to report operation errors in 24 hours, propose solutions in 48 hours and tell the solution found to his colleagues to ensure that knowledge was spread across the organization. This caused the risk of incidents to fall from 2% to 0.07% per year! This decreased incident rate meant less than 30 employees per year had some work incident problem after the zero error tolerance policy was implemented and Alcoa achieved an increase in productivity and quality similar to Toyota.

An important factor in both Toyota and Alcoa examples is that recognizing and learning from failures has to be part of the company’s culture. This is something a bit more common in internet companies culture, but not so common in traditional companies of a certain size. During the MIT course I shared a table with a Brazilian executive, from Grupo Globo, the largest Brazilian mass media group, a Spanish executive, from a AMC Networks International (Walking Dead, Breaking Bad and Mad Men), a German project manager living in Azerbaijan who works for Swire Pacific Offshore (oil and gas industry) and a Saudi Arabian MIT postdoctoral student on solar energy. All of my table mates were from more traditional industries. I was the only one from an internet, SaaS, born in the cloud company. Both Globo and AMC executives were there because they viewed both Netflix with its streaming video on demand and Youtube with its huge catalog of user-generated video as big threats, stealing their audience very quickly and they wanted to understand how they could defend themselves.

While the theme is somewhat obvious to internet companies, specially with the technology startup culture of failing fast. That’s what makes Netflix and Youtube be a threat to traditional media companies such as Grupo Globo and AMC Networks. However, even been part of internet companies’ culture, sitting there and discussing it with people from more traditional companies was a great opportunity for reflection on the relationship between failure, failure recognition, learning and high-velocity:

  • Recognizing failures and using failures as a learning opportunity should be well rooted in the organization’s culture. If people are not careful, as a company grows, it may lose that ability to accept failures as opportunities for learning. It is very common for companies as they grow to be more and more averse to failures and to create a culture that ultimately encourages people to hide mistakes and failures.
  • Another important point aspect learning from failures is to make this process a business standard. It has no use to fail, acknowledge the error, state that you will no longer commit that failure and, some time later, commit that failure again. This learning process from failures should be part of the company culture. Whenever a failure is identified, learning has to happen to prevent the failure from happening again. If the same failure happens again, something is broken in the learning from failure process.
  • Even in Internet companies I notice that learning from failure is more common in the product development team, since retrospectives and continuous learning are part of the agile software development culture. In other areas of the company, learning from failures is less common. This ability to systematize learning from failure should permeate the whole company.

Even though we hear a lot about the internet companies’ culture of failing fast, talking about failing fast diverges our focus from what is really important, learning fast. We must put our energy on learning, not on failing. Is the learning process that makes people and companies evolve. And it is the ability of an organization to learn fast, specially from its failures, that will enable this organization to move at really high-velocities.

Why diversity is so important for your digital product success

I have seen manifestations about diversity more and more often. I’m not much of watching TV, but sometime ago I ended up watching Globo TV, the main open TV network in Brazil. I was able to catch the final part of Jornal Nacional, the main TV news in Brazil, and the beginning of the soap opera. During Jornal Nacional there was a news piece about PUC, an well known university at São Paulo, inaugurating unisex bathrooms (article link in Portuguese). Keep in mind that PUC is an university linked to the Catholic religion. After that, during the soap opera, there was a scene where an actress who was telling her parents and family that she was born in the wrong body, that she was a man who had been born in a woman’s body, that is, she was a transgender. Then, during the break, came Globo’s campaign entitled “Everything Begins with Respect” about respect for gender identity (video and text in Portuguese):

That’s really good! Accepting and respecting differences is the basis for any society evolution and building an ever-better future for ourselves, our children, and all humanity.

When there is lack of respect and inability to accept diversity, very bad situations can happen, such as parents rejecting their own child. I was very impressed when I read an article (in Portuguese) by Daniela Andrade, a senior consultant at ThoughtWorks, where she says:

As I got kicked out of my parents’ house because I’m a transsexual – and here I say that the first great violence we suffer is in our house – I have not had relatives to count on in times of necessity for many years. They all turned their backs on me.

How can parents reject their own daughter? I am a father and I know how parenting love is very intense, capable of overcoming any problem so that we can always help and support our children. I was talking to my wife the other day about this and about the difficulty people have in accepting the differences, to the point of having parents rejecting their own children. It was at that moment that my wife said a phrase that struck me. She said that ultimately, all people are different. Transgender, heterosexual, homosexual, bisexual, asexual, black, white, yellow, young, adult, middle-aged, Brazilian, Canadian, French, Vietnamese, Rio de Janeiro, Minas Gerais, São Paulo, Rio Grande do Sul, cyclist, swimmer, engineer, architect, lawyer, who likes pop music, rock, jazz, classical and so on. Even identical twins are different.

If all people are different, accepting and respecting differences is not only desirable, it is necessary and mandatory for us to live together in a more harmonious and sustainable way. They are values that should be taught to all people from the cradle.

And what diversity has to do with software product management?

In addition to the importance of accepting and respecting differences to help create a more harmonious and sustainable society, diversity will help create even better digital products for two reasons:

  • Diversity brings new points of view. Having a more diverse product development team brings new insights and new ways of thinking, which will help you develop a better product. It is no wonder that the product development team is made up of software engineers, user experience designers, and product managers. Each one has a different perspective of what a good product is and these differences are what help create a better product when the differences are well worked out by the team,
  • Just as the customer group that uses your software is diverse, so should your team. Usually, digital product development teams are composed mostly of men, but the population that will use the software is more diverse. In both ContaAzul and Locaweb’s cases, more than 88% of the team is composed of men. To better illustrate let’s imagine a typically feminine product, for example, a party dress being developed by a men’s only team. It will be skewed, with features more important to men. Now imagine if it was developed by a women-only team. It would also be biased, with only the point of view of women. Even products that will be used by a less diverse audience, as in this example of a product made for the female audience, will benefit from having a team composed of women and men.
No alt text provided for this image
No alt text provided for this image
No alt text provided for this image

That is the reason why it is so important to the success of your product to discuss openly about diversity. How to improve the diversity of your product development team? How do you foster discussions that bring different points of view and help you see your product from new angles?

June 2018 update

I have recently updated these numbers and I’m very happy to share the progress of ContaAzul’s product development team! \o/

Since my very first days at ContaAzul, back in August 2016, I brought to everybody’s attention the need for a more diverse team. Since then we doubled our product development team, from 60 people to 116 people, and the share of women also almost doubled, from 6.7% to 12.9%. This means we went from 4 women to 15 women, almost quadrupling the number of women in our product development organization. Far from ideal, but good progress!

September 2019 update

Back in October 2018, I started a new journey at Gympass. Here women were already 13.1% in a team of 61 people but we knew we could do better. We decided to discuss this topic openly, how important it is to have a more diverse product development team in order to create better products and only by talking about the topic, we were able to improve a lot! \o/

Check out our numbers below:

No alt text provided for this image

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

Data science, machine learning e gestão de produtos

Nos últimos anos tem aparecido de forma recorrente e abundante os termos data science, machine learning e artificial inteligence. Esses termos são bastante importantes para os gestores de produtos. Não é à toa que dedico 5 capítulos do livro de Gestão de Produtos a assuntos relacionados a dados e métricas.

ds_ml

Como comentei nesse artigo, o gestor de produtos deve ser um data geek, ou seja, uma pessoa que está sempre pensando em como aprender mais com dados. Qual é o comportamento de uma pessoa nos meses e dias antes de cancelar a assinatura de seu produto? E o comportamento de uma pessoa que faz upgrade? Qual é o comportamento de um usuário que se diz satisfeito com seu produto? E do que se diz muito satisfeito? Se seu produto tem várias funcionalidades, qual é a mais popular? Qual gera maior satisfação? Qual é o padrão de uso típico de seu produto? Se aparecer um padrão de uso atípico, o que isso quer dizer? Esses são exemplos de algumas perguntas que o gestor de produtos pode fazer e que terão suas respostas nas métricas do produto. E a cada nova resposta obtida é muito provável que o gestor de produtos vai querer fazer mais perguntas.

Para achar as respostas às suas perguntas, é importante que o gestor de produtos conheça técnicas de data science e saiba como extrair ele mesmo as respostas para suas perguntas, quer seja por meio de ferramentas de extração e visualização de dados, quer seja rodando queries de SQL na base de dados do produto. Se o gestor de produtos não tiver essa independência, e precisar que outras pessoas extraiam os dados para ele, isso poderá atrapalhar a evolução do produto.

À medida que esse aprendizado a partir dos dados for acontecendo, é provável que o gestor de produtos comece a perceber oportunidades para inserir esses aprendizados dentro do produto. Por exemplo, um gestor de produtos de um software de CRM pode perceber, após fazer análises com dados de uso e engajamento do produto, que clientes acabam cancelando menos quando estão utilizando a funcionalidade de geração de propostas comerciais. Uma vez feita essa descoberta, ele pode promover uma mudança em seu produto para tornar mais fácil e imediato o uso dessa funcionalidade e, com isso, diminuir o churn de clientes por deixá-los mais engajados. Essa é uma forma de inserir data science em seu produto.

Machine learning, que nada mais é que uma forma de implementação de artificial inteligence, é quando programamos as máquinas para aprenderem com os dados e, quanto mais dados a máquina tiver em suas mãos, mais ela vai aprender. É uma maneira de inserir data science no produto para torná-lo melhor. Quanto mais você usa um determinado produto, mais dados estão à disposição do time que desenvolve o produto para conhecer seu usuário e como ele usa esse produto. Por exemplo, quanto mais compras você faz em uma loja virtual, mais ela aprende sobre seus hábitos de compra e mais fácil fica para o software da loja fazer recomendações que lhe interessem. O mesmo acontece com as sugestões do Netflix e do Spotify. Nesses casos é comum a loja comparar seu uso com o uso de pessoas que mostram comportamento similar para fazer sugestões do tipo “quem comprou esse item também comprou esses outros itens”.

É por isso que o gestor de produtos e todo o time que desenvolve o produto deve conhecer e saber usar data science, machine learning e artificial inteligence no seu dia a dia. São ferramentas poderosas para o ajudar a aumentar as chances de construir um produto de sucesso.

Prioridade 1: alinhamento de propósito e valores

Escrevi no blog de cultura da ContaAzul sobre a importância do alinhamento de propósito e valores na carreira. Esse blog é bem bacana, vale dar uma conferida!

Segue aqui o artigo na íntegra:

Trabalhei durante mais de 11 anos na Locaweb. É uma empresa incrível, onde tive a oportunidade de trabalhar com pessoas fantásticas e onde aprendi muito. Enquanto estava lá, eu pensava que se algum dia eu fosse sair de lá por opção minha, teria que ser para algo no mínimo tão bom quanto.

Conheço o Vini há uns 4 anos, desde 2012, quando a ContaAzul ainda estava dando os seus primeiros passos. A ideia era Locaweb e ContaAzul terem algum tipo de parceria para oferecermos a solução de ERP da ContaAzul para os clientes da Locaweb. Na época a parceria não vingou mas Vini e eu conversamos algumas vezes sobre gestão e desenvolvimento de produtos de software e desde essa época já havia afinidade sobre esses temas.

Ao longo de 2016 voltamos a conversar e começamos a explorar a possibilidade de eu me juntar ao time da ContaAzul. A empresa agora tinha 5 anos e está escalando a uma velocidade incrível. Por esse motivo o Vini estava buscando pessoas que tivessem já passado por isso em outras empresas e pudessem ajudar o time da ContaAzul a escalar de forma sustentável mantendo a alta velocidade de crescimento.

Comentei com ele sobre minhas prioridades caso eu decidisse fazer esse movimento de carreira, afinal eu estava em uma empresa que ajudei a construir ao longo desses 11 anos. Em nossas conversas deixei claro que minha preocupação primeira, antes de pensar em remuneração, é o alinhamento de propósito e de cultura. Se fosse para eu ir trabalhar em uma nova empresa, ela teria que ter um propósito que fosse alinhado com meus propósitos pessoais e precisaria ter uma cultura parecida com a que eu ajudei a criar na Locaweb.

Por propósitos pessoais tenho a busca por ajudar as pessoas a se desenvolverem. Essa é a razão pela qual escrevo tanto sobre gestão de produtos de software e não me furto a conversar sobre esse tema. Quero ajudá-las a se desenvolverem e, de quebra, quero sempre aprender mais para poder ajudar outras pessoas.

A ContaAzul tem por propósito ajudar o pequeno empreendedor a ter sucesso, o que está muito alinhado com meu propósito. Pronto, já temos alinhamento de propósito! \o/

E a cultura? Durante minhas conversas com o Vini e com outros Smurfs, como são carinhosamente chamados os funcionários da ContaAzul, pude perceber que havia, pelo menos em discurso, um grande alinhamento de valores. O trabalho em equipe, a busca pela excelência, a valorização do erro como oportunidade de aprendizado, a vontade encantar os clientes, a descontração no dia a dia. Esses valores estavam evidentes no discurso e transpareciam na forma como a ContaAzul é percebida pelo mercado.

Resolvi arriscar, apesar de saber que há certas coisas que só se percebe de fato estando dentro. Após ponderar bastante com minha família, afinal além da mudança de emprego haveria também uma mudança de cidade e de estado, saindo de São Paulo para morarmos em Joinville, decidi por fazer a aposta e aceitei o convite do Vini.

Nos primeiros dias há um receio, uma dúvida. Será que fiz a escolha certa? Será que aquele alinhamento de valores era só discurso, ou os valores eram de fato praticados no dia a dia? Contudo, essa dúvida durou poucos dias. Ao final da primeira semana ficou claro que não era só discurso. Os valores de fato correm nas veias dos Smurfs. São usados no dia a dia. Tanto decisões e conversas corriqueiras quanto discussões estratégicas que definem o rumo do negócio são pautadas pelos valores. Como já disse para o Vini e para os outros Smurfs com quem conversei antes de vir para cá, agradeço muito a eles pelo convite. É um prazer enorme poder trabalhar com pessoas com o mesmo alinhamento de propósito e de valores. Tenho certeza que vamos construir coisas incríveis juntos!

Air, food, and profit

I’m writing a series of articles on company culture and how it can affect the quality of your product and service. Checkout my previous articles on company culture:

Here’s the fourth article of the series:

Often we see shareholders, investors and employees of a company totally focused on its financial results. When there’s a period of crisis, this focus can be over 100%… :-/

Once I’ve heard a sentence that became popular with Dick Costolo, Twitter’s CEO, that compared revenue to oxygen:

“Revenue is like oxygen, it is vital for the health and the success of a company, but is not the purpose in life. Do you wake up in the morning and the first thing that comes to your mind is ìhow can I get more air?”

I’m very fond of this comparison. Every company must have a purpose, and this purpose should not be to defeat the enemies (as explained previously) nor getting the biggest amount of money as possible. 

The financial outcome must always be used as one of the metrics that indicate that the company is successful, that it is meeting its purpose. However, even as a metric, it should not be seen isolated, for there is the good and the bad revenue. 

The bad revenue is obtained at the expense of the prejudice of the relationship with the client. For example, imagine a company that provides a service over a monthly payment; when a client wants to cancel this service, the company makes it difficult in order to keep that revenue source for a few more months. This is bad revenue. The international roaming charges are also a good example of it, such as car rentals that charge for gas when you return the car without a full tank, using a more expensive price for gas than the one you find in the market. 

If a company sells something with a higher price, taking advantage of the fact that you need that item, such as the cost of bottle of water in a hotel, that is also bad revenue. 

In other words, although the comparison between revenue and profit with oxygen is good, it is also incomplete, because it doesn’t capture the effect of bad revenue. You rarely think about oxygen, unless you are with a shortness of breath. I don’t thing that revenue should only be remembered when there’s a shortness of it. Revenue is what keeps the company alive, able to fulfill its purpose. If it’s good revenue, the company will continue to meet its purpose for many years. If it’s bad revenue, it will have difficulties in the long run. 

For that reason, I prefer to compare revenue and profit to food. In the same way healthy people don’t think about oxygen all day long, healthy people don’t think about food all day long. However, unlike oxygen, when we talk about food, there’s good, healthy, good for your body food; and there’s bad, harmful for your body food, with the possibility of getting you sick. It is very important that people know what is good and bad food, and that everyone thinks about how to get the good one and avoid the bad one. 

Taking the sentence above, improving it and changing oxygen for food, we have:

“Revenue is like food, it is necessary for health and success of a company, but is not its purpose. However, both a company and a person must be always alert to the quality of the food they are ingesting, in order to assure that it is not going to cause any harm.”

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!

War

As promised I’m starting a series of articles on company culture and how it can affect the quality of your product and service. Checkout my first article “Don’t waste time looking for culprits“. Here’s the second article.

It is common to hear comparisons between the business world and war situations, combat or fighting. By the way, the word “strategy” itself, so common in business nowadays, comes from the military vocabulary. It derives from the Greek word strategos, a union between stratos (army) and agos (leader). In other words, strategos originally means the army leader, the general, the one who defines how the troop must act facing the situation.

One of the books that constantly appears on the list of most recommended administration books is “The art of war”, a military treatise written on the 4th century BC, by the Chinese general Sun Tzu. 

Everyone who met me knows that I’m a peaceful person. I hate fighting. By the way, if I accidentally get into one I’m even willing to pay to get out of it. That’s why every time I see these kind of comparisons between the business world and wars, combats, fighting or competition, I feel deeply uneasy. Checkout some images to remind us of what happens during a war:

Using war (combat or fighting) as an analogy for the business world does not make any sense. The goal in a war is to defeat the opponent. It is awkward to picture a company which goal is to defeat something or someone. 

Some people have said to me that, in a war, the battle itself is not the goal but a means to reach a goal. Ok, this makes sense but there are several means to achieve a certain goal. War is not the only one. So, why insisting on using war as an analogy for companies?

“A business, also known as an enterprise, company or a firm is an organizational entity involved in the provision of goods and services to consumers.” (Wikipedia: https://en.wikipedia.org/wiki/Business)

From the above definition, companies exist for provisioning goods and services to consumers, who can be people or other companies. How can something that aims provisioning hold the analogy to something that aims destruction? The right way to look at a company and its goals is to think of construction, in win-win relationships, where customers, employees, owners and the society are always winning. Every time we head our energy to defeat the “opponent” (client, competitor, employee, etc.) we will be wasting energy that could be used on something constructive. 

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!