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!

Don’t waste time looking for culprits

As promised I’m starting a series of articles on company culture and how it can affect the quality of your product and service. Here’s the first article.

When mistakes take place, some people naturally tend to react by looking for culprits, especially in group activities. As if having anyone to blame for that mistake was, in some way, make it less harmful. doing this is a great waste of time and energy. Let me explain why. 

A mistake took place. Mistakes happen. That’s a fact of life. No matter what you are doing – building a software, publishing a code in production, operating a patient, cooking dinner, building a house, playing guitar, playing soccer, etc. – there are good chances that mistakes are going to be made. 

When you spend your time trying to figure out who was responsible for that mistake, you will postpone the most important tasks in relation to the mistake:

  • Understand what happened;
  • Figure out how to correct;
  • Find ways to avoid that it happens again.

When you spend your time trying to figure out who was responsible for that mistake, people might naturally try to hide the mistake, fearing the consequences. Will I get fired? Will I be excluded from the group? Will I be punished? Will people make fun of me?

When people try to hide who was responsible, you will end up postponing the most important tasks in order to fix the mistake. It’s is going to be more difficult to understand what happened. People will not tell the whole truth about the mistake and about the circumstances in which it happened. 

If, in the process of understanding what happened, you find out that someone was responsible for the mistake, deal with this person in private. It is most likely that the mistake was caused unintentionally. That’s why you need to help this person to improve so this same kind of mistake does not happen again. 

On the other hand, you are responsible for creating an environment in which is safe to talk about mistakes so they are detected as soon as possible. However, if you find out that the mistake took place with the intention to harm the company, the product, or someone, then you should be resolute on reprehending it, saying that this type of behavior is unacceptable and, if it happens again, you’ll invite the person to leave the group.

High performance and culture

In his book “Smarter Faster Better: The Secrets of Being Productive in Life and Business” author Charles Duhigg talks about how transparency helps teams be more productive and have better performance. He cites an example where two ICU teams are compared and the best performer is the one where transparency is a key value, mistakes are not only accepted but also embraced as learning opportunities. Group members can discuss openly about mistakes, why they happened and what can be done to prevent them in the future. The other team, where mistakes are not acceptable, mistakes are hidden and no one can learn and improve from the mistakes. As a consequence, the transparent group where mistakes are accepted and discussed has a better performance and make less mistakes than the group were mistakes are unacceptable.

In my next article I’ll discuss about the comparison between business and war. Stay tuned!

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!

Organizational culture

Organizational culture is a very important theme for product managers, therefore, let’s dig into it. In a way, this subject complements the article on leadership tips for product managers

Organizational culture is a feature of every group of people. Even within companies, there are sub-cultures. In other words, each area or team within a company can have its own culture. For instance, the culture of a commercial team has always some differences compared to the culture of the software engineering team.

There is not a right or wrong culture. Different companies have different cultures, and they can be successful in spite of these differences. The following cartoon illustrates the cultural differences amongst Amazon, Apple, Facebook, Google, Microsoft and Oracle. Even with all the cultural differences, these are all successful companies.

But what is organizational culture? Edgar Schein, professor at MIT’s business administration school, was one of the first to talk about organizational culture in the 1970s. According to him, each company had its own personality and its own approach to act and react to situations; and this approach is passed on from employee to employee since the company’s founders. Schein’s definition for organizational culture is:

Culture is a set of premises that have been learned and shared by a group of people while they were solving problems on external adaptation and internal integration. This set of premises works well enough to be considered valid and, consequently, be taught to the new members of the group as the correct way of perceiving, thinking and feeling regarding those problems. (SCHEIN, Edgar. Organizational Culture and Leadership. Jossey-Bass, 2010.)

Culture comes from the company’s founders. They have their own personal culture and values and it’s only natural that they spread this culture in the organization they are creating. That’s why is very common to think it emerges in an organization.

The founder brings the culture and when hiring new people, always looks for those with similar cultural values. This ends up creating a new common culture, very close to that one brought by the company’s founder. This concept of emerging culture gives the impression that we cannot alter it deliberately and that it would develop organically. 

Schein warns that this is a mistake. Organizational cultures can and must be planned.

For this reason, I’ll discuss in my next articles about organizational culture and values topics that directly impacts the development and delivery of great software products. 

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!

The fallacy of the internal customer

I have seen quite often people using the concept of internal customer or internal user when discussing work done between areas. Something along the lines of “I have here a demand for you and, as I am your internal customer I need that demand solved as soon as possible, preferably until the day X”. I have even seen some people suggesting that we evaluate each other as internal customers and internal suppliers.

The problem with using the internal customer concept for relationship between areas is that it tends to put people in these areas on opposite sides. Someone from an area has a demand for another area. One area asks and the other area executes. If the other area does not execute well, the demanding area complains. If the other area does not deliver on the agreed time, the demanding area complaims. Then the area that has to execute the demand justifies that the request was unclear and that the demand should be made in Z format, specifying A, B and C because, without it, they cannot execute the demand correctly or on time. And so it continues…

In addition, companies typically have more than two areas. Thus, an area may have more than one internal customer and thus can receive various demands which, most often, are all “needed yesterday” and all are “the most important for the company.” Then begins the prioritization dispute.

Internal customer vs. teamwork

In 2001 a group of people who worked with on-demand software development met to discuss the best ways to make software. These conversations gave rise to the Agile Manifest containing the basis of the agility concepts that have improved considerably the success rate of software development projects in our industry. During these conversations they came to the conclusion that, among other things, there needed to be more customer collaboration. To have more success in software development projects is essential that the customer became part of the team that is developing software, and not a mere spectator plaintiff.

We must stop with this concept of internal customer and return to using the good old concept of teamwork, even among different areas. Teamwork is not just for people of the same area, but also for people from different areas. Any business can and should be seen ultimately as a team of teams.

To work well in a team, you must have empathy, that is, know how to understand and respect the viewpoints of others, put yourself in their shoes, try to understand how others think and why they think that way. Different areas have different cultures and different ways of thinking. And that’s good! Teams work mainly because different people, working together, are able to produce a result with greater impact than using only their individual skills. If everyone thought alike, this would not be possible. Therefore, in order to have real teamwork, it is important not only to tolerate and live with the differences: we must exploit them. We must cooperate. We must exchange knowledge. Valuing healthy conflict, not being afraid of debate and disagreements. When two people exchange ideas, each one gets out of the exchange with more ideas. Everyone wins. Different viewpoints help to build better results, s as long as people is not motivated by ego or distrust.

Practical example

Moving from theory to practice,  let me give you an example. I’ll use the need for hiring new employees in a given area that will need HR for this these example. When we need to make new hirings, we should avoid simply sending the job description to the HR and passively wait HR to do this task and only then get back to the HR and ask if they managed to fill the vacancy. The problem to be solved is to fill the vacancy with the best person possible within the budgeted salary range for the position and within the deadline. This is not an HR only problem. It is a problem to be solved by the HR team together with the demanding area. For this reason, the person who asked for a new hiring needs to work with the HR department to fill that vacancy, not only doing the interviews, but also helping to promote the vacancy, discussing each received curriculum, each candidate interviewed and so on. A new hire should be a teamwork of the HR team and the area who needs to do this new hiring. The chances of making a good hiring in proper time are much higher when the demanding area and HR come together and work as a team to do this hiring.

So I suggest we stop using the concept of internal customer and get back to the good old teamwork, even among areas. This will greatly increase the success rate of new endeavours, as well as the motivation of the people of the areas involved.

Product Management: Delight your customers with your software

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

The book is organized in 5 sections:

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

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

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

A falácia do cliente interno

Tenho visto com alguma frequência pessoas usando o conceito de cliente interno ou de usuário interno, quando se referenciam a trabalhos feitos entre áreas. Algo na linha de “eu tenho aqui uma demanda para você(s) e, como sou seu cliente/usuário interno, preciso dessa demanda solucionada por você(s) o mais rápido possível, preferencialmente até o dia X”. Tenho inclusive visto algumas pessoas propondo que avaliemos uns aos outros como clientes-fornecedores internos, ou seja que avaliemos satisfação do cliente/usuário interno com seu fornecedor interno.

O problema de usar esse conceito de cliente interno para a relação entre áreas é que ele tende a colocar as pessoas dessas áreas em lados opostos, ou seja, uma pessoa de uma área pede algo ou, termo que também já vi sendo usado, tem uma demanda, para outra área. Uma área pede e a outra faz. Se a outra área não fizer bem feito, a área que pediu reclama. Se a outra área não entregar no prazo combinado, a área de pediu reclama. Aí a área que atendeu a demanda justifica que o pedido não estava claro e que o pedido tem que ser feito no formato Z, especificando A, B e C pois, sem isso, não dá para atender a demanda direito, nem no prazo. E assim por diante.

Além disso, as empresas normalmente têm mais do que duas áreas. Assim, um área pode ter mais de um cliente interno e, consequentemente, pode receber várias demandas que, na maioria das vezes, são todas “pra ontem” e todas são “a mais importante para a empresa”. Aí começa a disputa de prioridades.

Cliente interno vs trabalho em equipe

Em 2001 um grupo de pessoas que trabalhavam com desenvolvimento de software sob demanda se reuniu para conversar sobre maneiras melhores de se fazer software. Essas conversas deram origem ao Manifesto Ágil contendo a base dos conceitos de agilidade que melhoraram em muito a taxa de sucesso dos projetos de desenvolvimento de software em nossa indústria. Durante essas conversas eles chegaram à conclusão que, dentre outras coisas, era necessário haver mais colaboração com o cliente. Ou seja, para ter mais sucesso nos projetos de desenvolvimento de software é essencial que o cliente seja parte do time que está desenvolvendo software, e não mero demandante espectador.

cliente-interno-x-trabalho-em-equipe

É preciso parar com esse conceito de cliente-fornecedor interno e voltar a usar o bom e velho conceito de trabalho em equipe, inclusive entre áreas diferentes. Trabalho em equipe não serve apenas para pessoas da mesma área, mas também para pessoas de áreas diferentes. Qualquer empresa pode e deve ser vista, em última instância, como uma equipe de equipes.

Para se trabalhar bem em equipe, é preciso ter empatia, ou seja, saber entender e respeitar o ponto de vista do outro, colocar-se em seu lugar, tentar entender como o outro pensa e porque ele pensa dessa forma. Áreas diferentes têm culturas e modos de pensar diferentes. E isso é bom! Equipes funcionam, principalmente, porque pessoas diferentes, colaborando entre si, são capazes de produzir um resultado de maior impacto do que se usassem somente suas habilidades individuais. Se todos pensassem igual, isso não seria possível. Por isso, para que haja um verdadeiro trabalho em equipe, é importante não só tolerar e conviver com as diferenças: é preciso explorá-las. É preciso colaborar, trocar conhecimento. Valorizar o conflito saudável, não ter medo de debater e discordar. Quando duas pessoas trocam ideias, cada uma sai com uma ideia a mais, todos ganham. Opiniões diferentes ajudam a construir, desde que motivadas não por ego ou desconfianças, mas sim pela crença num resultado melhor.

Exemplo prático

Para sair do teórico e citar um exemplo prático, vamos usar a necessidade de contratações de novas funcionários de uma determinada área que vai precisar do RH para efetuar essas contratações. Quando precisamos fazer novas contratações, devemos evitar simplesmente mandar para o RH um descritivo do cargo e aguardar passivamente o prazo que o RH tem para fazer essa tarefa e só aí chegar para o RH e perguntar se conseguiram preencher a vaga. O problema a ser resolvido é preencher a vaga com a melhor pessoa possível dentro da faixa salarial orçada para a vaga e dentro do prazo. Esse não é um problema só do RH. É do RH e da área que pediu. Por isso quem pediu deve trabalhar junto com o RH para preencher esse vaga, não só fazendo as entrevistas, mas também ajudando a divulgar a vaga, conversando sobre cada currículo recebido, cada candidato entrevistado e assim por diante. Uma nova contratação deve ser um trabalho em equipe do RH e da área que precisa fazer essa nova contratação. As chances de fazer uma boa contratação no prazo adequado são muito maiores quando a área que precisa fazer essa contratação e o RH se juntam e trabalham em equipe.

Por isso sugiro pararmos de usar o conceito de cliente interno e voltarmos ao bom e velho trabalho em equipe, inclusive entre áreas. Isso vai aumentar em muito a taxa de sucesso das novas empreitadas, assim como a motivação das pessoas das áreas envolvidas.