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

Be the first to like.

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

Be the first to like.

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.

Be the first to like.

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

Be the first to like.

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.

Be the first to like.

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!

Be the first to like.

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!

Be the first to like.

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!

Be the first to like.

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!

Be the first to like.

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!

Be the first to like.