Product Manager’s #1 priority

In my recent articles, I’ve been discussing why “business demands => technology implements” doesn’t work, why business people hate discovery and I’ve introduced the concept of MVD (Minimum Viable Discovery).

Today I’ll talk about every Product Manager’s #1 priority which, I believe, will be a good addition to the 3 articles cited above.

Quiz

To start this article, I want to propose a quiz. Based on your experience, what is every Product Manager’s #1 priority?

  1. Have a product vision and a sound strategy to execute this vision
  2. Have a good enough understanding of the user’s problem so the team can iterate quickly on solution hypotheses and deliver the best solution as fast as possible
  3. Create a complete Opportunity Tree to help the team assess opportunities and work on the ones that can validate solution hypotheses as fast as possible
  4. All of the above
  5. None of the above

Let’s analyze each of the answers above to find the correct answer and better understand why this is the correct answer:

Have a product vision and a sound strategy to execute this vision

I’ve already mentioned in the past that creating the vision is critical for every product leader and every product manager to do their job. Without:

  • having a clear understanding of the vision of your product
  • having this product vision clearly aligned with the leaders of your company
  • constantly communicating this vision to the entire company

It is very difficult to do anything with your product. How do you prioritize without knowing where you should lead your product? How to say no to the constant requests from your product’s stakeholders (company employees, customers, partners)? From this vision, a Product Manager can create a clear strategy on how to execute this vision. However, this is not the Product Manager’s #1 priority. It is a means to get this #1 priority.

Have a good enough understanding of the user’s problem so the team can iterate quickly on solution hypotheses and deliver the best solution as fast as possible

This is what I’ve been discussing in my latest articles and this is very important to get to the Product Manager’s #1 priority. We must never jump directly to implementing solutions, not when asked by business people to implement their demand and not when knowing about a problem and start implementing the first solution that comes to mind. We know that as we learn something about a problem, we should also map solution hypotheses, and test these solutions as fast as possible so we can deliver the best solution as fast as possible. However, as the first answer, this is not the #1 priority. Again, it’s a means to an end.

Create a complete Opportunity Tree to help the team assess opportunities and work on the ones that can validate solution hypotheses as fast as possible

This answer is a variation of the above question just making explicit a good tool to iterate from problem to solution, the Opportunity Tree. I mentioned this tool in my article about the two sides of product discovery. It helps a product team better understand the expected outcome, map the opportunities that can generate the outcome, generate possible solutions for the opportunities and build experiments to test the solutions. However, this answer is a little worse than the previous answer because it talks about creating a complete opportunity tree. We should use the opportunity tree to have a good enough understanding of the problem to scope out possible solutions and get to the expected result (outcome) as fast as possible. And again, this is a means to an end. It’s not the Product Manager’s #1 priority.

All of the above

So let’s put it all together and make it the Product Manager’s #1 priority, right? No! As explained above, these are all tools that a Product Manager can use to get to her #1 priority. Besides that, I believe it’s quite easy to understand why this one is not the correct answer. We are asking what’s every Product Manager’s #1 priority, so this priority cannot be 3 things. It must be only one thing! This is a common mistake some Product Managers incur, having more than one priority. When a product manager is asked what are her priorities, she cites a list of things, which is somewhat ok if, and only if, she knows and constantly works on her #1 priority, which we will know what it is pretty soon! (=

None of the above

I guess that after reading the explanation of why the previous 4 answers are incorrect, you probably know that “none of the above” is the correct answer. However, despite the fact that this is the correct answer, it’s still unclear what’s the Product Manager’s #1 priority. Even though I gave some hints above, let me now make it explicit.

The Product Manager’s #1 priority is to generate results as fast as possible

Let me repeat this one more time: every Product Manager’s #1 priority is to generate results as fast as possible.

As I mentioned in the comments about each of the answers above, answers 1., 2. and 3. are all means to an end, and this end is to generate results as fast as possible. Generate results for the company that owns the product and invests in building the product, and results for the customer, i.e., solve her problems and address her needs. It needs to be as fast as possible because generating results costs money and the more time we spent on generating results, the more money we will spend.

Above I cited some good tools to get results, but we should not forget that these are tools to help us generate results as fast as possible. OKR, roadmap, proof of concept, MVP, MVD, discovery, usability test, prototype, no-code/low-code, site, app, feature, bot, algorithm, opportunity tree, power x interest mapping, RASCI, BCG matrix, technology adoption curve, team structure, Tuckman’s model, Conway’s law, agile, lean, and the list can go on and on, but all of these are tools so we can generate results for the business and for the customer. Even the product, the very thing that goes in the title of the Product Manager’s function, is a tool to generate results.

By the way, generating results as fast as possible is not the Product Manager’s #1 priority only. It is the entire product development team’s #1 priority. Engineers, Product Designers, and Product Managers in product teams as well as in structural teams (data, devops, architecture, etc). The team must have always a common #1 priority to be a team. Otherwise, they will be a group of people working on different priorities that happens to seat together (or have a slack group for remote teams) and happens to have periodic planning and update sessions. And this #1 priority is generating results as fast as possible.

Another example of result generation

I gave some examples of the focus on results in my previous articles. I want to give another example from Lopes, the biggest real estate company in Brazil, where I lead the digital transformation efforts.

In order to sell properties from a new building, Lopes and the builder company create a partnership relationship where the builder company shares info about pricing, unit availability, and leads, and Lopes works on selling units based on its large experience commercializing new builds. In order to perform its attributions in this partnership, we need to know from the builder the prices of each unit that change frequently depending on the sales evolution, the available units, and we need to receive leads from the builder. This information was sent through files to be imported manually into our system. All manual information input tends to be slow and subject to errors, so it is clear to see that this manual integration was sub-optimal. Lopes integration with the builder companies was no different. Since it was a manual operation it was made once or twice per week, which could potentially generate outdated information about pricing and units available in our systems for brokers to use. Also, the older the lead information gets the colder it becomes, and probably the potential client figures out other ways to receive the information she needs and eventually closes a deal with another seller.

So, here’s how we solved this problem using the opportunity tree, always focused on generating results as fast as possible:

  • Outcome: more sales
  • Opportunity: bring info from builders as fast as possible, ideally in real-time
  • Solution 1: integrate with builders’ management system through APIs. The issue here is that all management systems used by builders do not have APIs for integration. So we would have to wait until the management system provider implemented APIs in their system
  • Solution 2: build our own RPAs (Robotic Process Automation) to get the information needed (pricing, available units, and leads) from builders’ management systems without the need for APIs. The issue here is that the team didn’t have enough experience to build these RPAs, so probably it will be a lengthy process.
  • Solution 3: hire an RPA provider to build the integrations for us.

We opted for Solution 3 because it was the one that would bring us results faster. It took us just a few weeks to have the first RPA up and running and bringing results. We are using this solution for more than one year. Still, no APIs were provided by the management system providers, and haven’t had the need to build our own RPAs. The RPA provider works ok with a reasonable cost and we can focus our team to generate results from other opportunities.

Summing up

  • The Product Manager’s #1 priority is to generate results as fast as possible. Generate results for the company that owns the product and invests in building the product, and results for the customer, i.e., solve her problems and address her needs.
  • Everything that we use in our day-to-day product management function, including the very own product that we build, is not the end goal. They are means to an end, to generate results as fast as possible.
  • Generating results as fast as possible is the #1 priority not only of the Product Manager but of the entire product development team, including engineers, product designers, and product managers from both product teams and structural teams. That’s the only way to guarantee that the team is actually a real team, having a common #1 priority.

Mentoring and advice on digital product development

I’ve been helping several companies extract more value and results from their digital products. Check here how I can help you and your company.

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, solve its user’s problems and achieve the company objectives? Check out my Digital Product Management bundle with my 3 books where I share what I learned during my 30+ years of experience in creating and managing digital products:

You can also acquire the books individually, by clicking on their titles above.

Incerteza e transformação digital

Um aspecto das transformações digitais que parece ser senso comum entre as pessoas que estão ou que ajudam as empresas a passar por esse processo é que o mais difícil não são as mudanças digitais e tecnológicas, mas as mudanças culturais e de mentalidade necessárias para transformação bem sucedida. Neste artigo, vou me aprofundar um pouco mais nessas mudanças culturais e de mentalidade necessárias na esperança de que possamos entender melhor e enfrentar os obstáculos que dificultam a jornada por transformações digitais bem-sucedidas.

Trabalhei quase toda a minha carreira em empresas de tecnologia, ou seja, empresas onde a tecnologia era o produto. Minha própria empresa, no início dos anos 1990, era um provedor de serviços de internet. Depois trabalhei em um data center chamado .comDominio que acabou sendo adquirido pela Equinix. Depois disso, trabalhei na Locaweb, maior provedora de serviços de internet do Brasil, e na Conta Azul, plataforma de ERP que conecta pequenos empresários a seus contadores e tudo o que eles precisam para administrar seus negócios. Ingressei no Gympass em 2018. O Gympass vende um benefício corporativo para empresas, para que possam oferecer aos seus funcionários acesso a uma rede de academias e estúdios e, mais recentemente, outros serviços de bem-estar como meditação, nutrição e apoio à saúde mental. Para o Gympass, a tecnologia não é o produto, é um ferramenta para potencializar seu produto principal. Isso me fez pensar no poder do digital para potencializar substancialmente os negócios não digitais. E essa foi minha principal motivação para ingressar na Lopes, a maior imobiliária do Brasil, empresa fundada em 1935 que fez uma oferta de follow-on na bolsa de valores no final de 2019 para arrecadar fundos para investir em sua transformação digital. Trabalho na Lopes desde meados de 2020 e tenho aprendido muito nessa jornada de transformação digital.

O impacto da incerteza em diferentes indústrias

Um artigo interessante na HBR sobre As indústrias atormentadas pela maior incerteza apresenta um gráfico em que muitas indústrias são mostradas de acordo com sua incerteza tecnológica, medida pela pesquisa e desenvolvimento da indústria (P&D) gastos como porcentagem da receita e sua incerteza de demanda , medido como uma ponderação igual da volatilidade ou mudança da receita do setor nos últimos 10 anos e a porcentagem de empresas do setor que entraram ou saíram durante o mesmo período.

Incerteza da demanda e da tecnologia por indústria

Como podemos ver, na região superior direita do gráfico podemos encontrar as indústrias de Informática e Software, ao lado das indústrias Farmacêutica, de Equipamentos Médicos e de Transporte. Essas são as indústrias onde temos que investir mais em P&D e a demanda é a mais incerta. Computadores e Software são os mais novos. Farmacêutica, Equipamentos Médicos e Transportes são mais tradicionais, com incertezas de Tecnologia e Demanda semelhantes às indústrias de computadores e software.

Quando analisamos outros setores mais tradicionais, como bancos, seguros, varejo, entretenimento, imobiliário e construção, para citar alguns exemplos, eles apresentam menor tecnologia e incertezas de demanda.

A transformação digital é mais sobre transformação do que sobre digital

Quando uma empresa tradicional decide entrar na rota da transformação digital, uma coisa que precisa ficar clara é que essa rota tem mais a ver com transformação do que digital. O aspecto digital é muito importante, pois a tecnologia é central em qualquer transformação digital. No entanto, é relativamente fácil encontrar conhecimento e especialistas que possam ajudar a entender e abordar os aspectos técnicos de uma transformação digital. Por outro lado, o aspecto de transformação de qualquer transformação digital exige mudanças de negócios e culturais que são consideravelmente mais difíceis de implementar. E para dificultar ainda mais, não há muito conhecimento disponível sobre esse assunto, então tendemos a creditar sua dificuldade a uma causa cultural e de mentalidade um tanto genérica, o que é correto, mas insuficiente para nos ajudar a lidar com o assunto.

O gráfico de incerteza de demanda e tecnologia pode nos ajudar a entender por que as mudanças de negócios e culturais em uma transformação digital podem ser tão difíceis. A empresa tradicional normalmente está acostumada a um certo nível de tecnologia e demanda incertezas. No entanto, ao entrar no mundo digital, o nível de demanda e as incertezas tecnológicas aumentam consideravelmente:

  • Indústrias de Computadores e Software a incerteza da demanda é muito alta, uma das mais altas de todas as indústrias, o que significa que o software produzido nem sempre atinge seus objetivos. Esta taxa de sucesso tem vindo a melhorar nos últimos anos com a evolução das técnicas e mentalidade de desenvolvimento e gestão de produtos digitais, mas ainda existem muitos produtos digitais que falham total ou parcialmente na obtenção dos resultados esperados e objetivos estratégicos. Isso pode ser muito frustrante para uma empresa em um setor com menos incerteza de demanda. Para minimizar a incerteza da demanda, estamos usando o liberar cedo e frequentemente mentalidade, que as pessoas de indústrias mais tradicionais precisam entender e adotar para lidar com a incerteza da demanda das indústrias de computadores e software.
  • A incerteza tecnológica exigirá da empresa tradicional o entendimento de que (1) ela terá que investir e (2) o investimento em produtos digitais é um investimento plurianual. Para ilustrar essa necessidade de investimento e seu aspecto plurianual, usarei 2 exemplos. A primeira é a Amazon. Foi fundada em junho de 1994 e começou a operar em julho de 1995. Teve uma rodada de investimento de US$ 8 milhões da Série A em junho de 1996. O IPO foi em maio de 1997 e, em seguida, a Amazon recebeu US$ 100 milhões em um investimento de capital pós-IPO em julho /2001 e só apresentou lucro no relatório de resultados do 4T2001. Então, da fundação ao lucro, foram necessários 7,5 anos e um investimento de US$ 108 milhões, mais dinheiro arrecadado de investidores anjos e no IPO. O segundo exemplo é o Nubanlk, um banco digital brasileiro fundado em maio de 2013 que começou a operar em 2014. Arrecadou US$ 1,87 bilhão da Série A até a Série G. O IPO foi em dezembro de 2021 e o Nubank recebeu US$ 1 bilhão em um pós-IPO Investimento em ações em fevereiro de 2022. Seu 1º relatório pós-IPO apresentou uma perda de US$ 66,2 milhões no 4T2021. Assim, da fundação ao IPO, foram necessários quase 8 anos e US$ 2,87 bilhões, mais dinheiro arrecadado de investidores-anjo e em seu IPO. Mesmo depois de tanto tempo e dinheiro investidos, o Nubank ainda não apresenta resultados positivos. Observe que ambas as empresas são o que costumo chamar de empresas “tradicionais nascidas digitais”, ou seja, empresas cuja indústria principal não é computador ou software, mas que foram fundadas já com o digital como parte de sua estratégia para potencializar resultados. A Amazon está no setor de varejo com baixa incerteza tecnológica e incerteza de demanda média e o Nubank está no setor bancário com incerteza de baixa tecnologia e demanda, com base no gráfico de demanda e tecnologia por setor apresentado acima.

Quanto mais distante uma indústria estiver da Indústria de Software no gráfico, maior será a mudança de transformação necessária, ou seja, a empresa precisa (1) entender que o desenvolvimento de produtos digitais pode não trazer os resultados desejados e (2) produtos digitais reserve um tempo para fornecer um retorno sobre o investimento.

As pessoas também enfrentam a transformação digital

Estou falando aqui das empresas que passam pela transformação digital e dos desafios que essas empresas enfrentam durante essa transformação, mas as empresas são feitas de pessoas, então a transformação digital realmente acontece com pessoas que precisam entender a demanda e as incertezas tecnológicas que caracterizam um transformação digital.

Esse fato de as pessoas passarem pela transformação digital parece óbvio quando falamos de empresas tradicionais, principalmente aquelas com décadas de existência como banco, varejo, drogaria, livraria, imobiliária, seguradora, restaurante e assim por diante.

No entanto, além das empresas tradicionais, existem também dois outros tipos de empresas:

  • empresas de tecnologia que vendem tecnologia, ou seja, a tecnologia é seu núcleo. Alguns exemplos são o Google com seu principal produto, Google Search e GMail. Amazon Web Services. Facebook. Instagram. WhatsApp. SAP. Salesforce. Zendesk. As empresas em que trabalhei (Locaweb e Conta Azul).
  • empresas tradicionais nascidas no digital que possuem produtos ou serviços tradicionais que podem existir sem tecnologia. No entanto, por terem incluído a tecnologia desde o início como uma capacidade estratégica, parecem empresas digitais. Exemplos são Amazon e Nubank que citei acima. Exemplos adicionais estão listados na imagem abaixo:
Empresas tradicionais nascidas digitais

Quando consideramos que a transformação digital acontece com as pessoas que fazem parte de uma empresa, fica claro que as empresas tradicionais nascidas digitais e até as empresas de tecnologia também enfrentam a transformação digital. Muitas pessoas que trabalham nessas empresas provavelmente vieram de indústrias mais tradicionais, com menos demanda e incertezas tecnológicas e terão que se adaptar a um contexto mais incerto. Por exemplo, para construir o Nubank, muitos de seus funcionários, incluindo C-level e fundadores, vieram do setor bancário, como Cristina Junqueira, que trabalhou para o Itaú antes de fundar o Nubank. Outro exemplo interessante é a CFO do Google, Ruth Porat, que trabalhou no Morgan Stanley antes de ingressar no Google.

Ser capaz de entender o contexto anterior das pessoas que estão trabalhando em uma transformação digital pode ajudar a lidar com as lutas e problemas que podemos enfrentar em uma transformação digital, especialmente com seu aspecto de transformação.

Resumindo

  • O aspecto digital da transformação digital é relativamente fácil, pois há muito conhecimento e muitos especialistas para ajudar a projetar, desenvolver e implementar produtos digitais. As técnicas de gerenciamento e desenvolvimento de produtos têm evoluído em ritmo acelerado.
  • O aspecto de transformação de uma transformação digital é mais difícil, pois não há muito conhecimento sobre isso e tendemos a creditar sua dificuldade a uma cultura e mentalidade um tanto genéricas causa.
  • As incertezas de demanda e tecnologia da indústria de software é o que dificulta a transformação digital. As empresas tradicionais que estão em contextos mais determinados lutam para entender e, consequentemente, lidar com essas incertezas.
  • As empresas tradicionais nascidas digitais e até as empresas digitais também enfrentam problemas de transformação digital, pois as pessoas que trabalham nessas empresas, incluindo C-level e fundadores, podem vir de empresas em contextos onde a demanda e a tecnologia são menos incertas.
  • Ser capaz de entender o contexto anterior das pessoas que estão trabalhando em uma transformação digital pode ajudar a lidar com o lutas e problemas que podemos enfrentar em uma tiranização digital, especialmente com seu aspecto de transformação

Gestão de produtos digitais

Você trabalha com produtos digitais? Quer saber mais sobre como gerenciar um produto digital para aumentar suas chances de sucesso, resolver os problemas do usuário e atingir os objetivos da empresa? Confira meu pacote de gerenciamento de produto digital com meus 3 livros, onde compartilho o que aprendi durante meus mais de 30 anos de experiência na criação e gerenciamento de produtos digitais. Se preferir, pode comprar os livros individualmente:

Mentoria e aconselhamento em desenvolvimento de produtos digitais

Tenha ajudado várias empresas a extrair mais valor e resultados de seus produtos digitais. Veja aqui como posso ajudar você e a sua empresa.

Uncertainty and digital transformation

One aspect of digital transformations that seems to be common-sense among people who are in or who help companies go through this process is that what is most difficult is not the digital and technology changes, but the cultural and mindset changes needed to make a successful transformation. In this article, I’ll go a bit deeper in these needed cultural and mindset changes in the hope that we can better understand and tackle the obstacles that hinders the journey through successful digital transformations.

I worked almost my entire career in tech companies, i.e., companies where technology was the product. My own company, back in the early 1990s, was an internet service provider. Then I worked at a data center called .comDominio which was eventually acquired by Equinix. After that, I worked at Locaweb, the biggest internet service provider in Brazil, and Conta Azul, an ERP platform that connects small business owners to their accountants and everything they need to run their business. I joined Gympass in 2018. Gympass sells a corporate benefit to companies, so they can offer to their employees access to a network of gyms and studios, and more recently other well-being services like meditation, nutrition, and mental health support. For Gympass, the technology is not the product, it is a tool to potentialize their core product. That got me thinking about the power of digital to substantially potentialize non-digital businesses. And that was my main motivation to join Lopes, the biggest real estate company in Brazil, a company founded in 1935 that made a follow-on offering in the stock market in late 2019 to raise funds to invest in their digital transformation. I’ve been working at Lopes since mid-2020 and I’ve been learning a lot in this digital transformation journey.

The impact of uncertainty in different industries

An interesting article on HBR about The Industries Plagued by the Most Uncertainty presents a chart where many industries are shown according to their technology uncertainty, measured by the industry’s research and development (R&D) spent as a percentage of revenue, and its demand uncertainty, measured as an equal weighting of industry revenue volatility, or change, over the past 10 years and percentage of firms in the industry that entered or exited during that same time period.

Demand and technology uncertainty by industry

As we can see, in the top right region of the chart we can find Computer and Software industries, next to Pharma, Medical Equipment and Transportation industries. These are the industries where we have to invest the most in R&D and the demand is the most uncertain. Computers and Software are the newest ones. Pharma, Medical Equipment, and Transportation are more traditional ones, having Technology and Demand uncertainty similar to Computer and Software industries.

When we look into other more traditional industries, like Banking, Insurance, Retail, Entertainment, Real Estate, and Construction to cite a few examples, they present lower technology and demand uncertainties.

Digital transformation is more about transformation than about digital

When a traditional company decides to enter the route of digital transformation, one thing that needs to be clear is that this route is more about transformation than it is about digital. The digital aspect is very important since technology is central in any digital transformation. However, it’s relatively easy to find knowledge and experts that can help understand and tackle the technical aspects of a digital transformation. On the other hand, the transformation aspect of any digital transformation requires business and cultural changes which are considerably more difficult to implement. And to make things even harder, there is not much knowledge available about this topic, so we tend to credit its difficulty to a somewhat generic cultural and mindset cause, which is correct, but insufficient to help us deal with the matter.

The demand and technology uncertainty chart can help us understand why the business and cultural changes in a digital transformation can be so difficult. The traditional company is normally used to a certain level of technology and demand uncertainties. However, when entering the digital world, the level of demand and technology uncertainties increases considerably:

  • Computer and Software industries demand uncertainty is very high, one of the highest of all industries, which means that the software produced not always achieve its objectives. This success rate has been improving in more recent years with the evolution of digital product development and management techniques and mindset, but there are still many digital products that either fail completely or partialy in achieving the expected results and strategic objetives. This can be very frustrating to a company in an industry with less demand uncertainty. In order to minimize the demand uncertainty we’ve been using the realease early and often mindset, which people from more traditional industries need to understand and adopt in order to cope with the demand uncertainty of the computer and software industries.
  • The technology uncertainty will require from the traditional company an understanding that (1) it will have to invest and (2) investment in digital products are multi-year investments. To illustrate this need for investment and it’s multi-year aspect, I’ll use 2 examples. The first one is Amazon. It was founded in June, 1994 and started operating in July, 1995. Had an $8M Series A investment round in Jun, 1996. IPO was in May, 1997 and then Amazon received a $100M in a post-IPO Equity investment in Jul/2001 and only showed a profit in 4Q2001 results report. So, from founding to profit it took 7,5 years and $108M investment plus money raised from angel investors and in the IPO. The second example is Nubanlk, a Brazilian digital bank founded in May, 2013 which started operating in 2014. Raised $1.87B from Series A through Series G. IPO was in Dec, 2021, and then Nubank received a $1B in a post-IPO Equity investment in Feb, 2022. Its 1st post-IPO report presented a $66.2M loss for 4Q2021. So, from founding to its IPO, it took almost 8 years and $2.87B plus money raised from angel investors and in its IPO. Even after all this time and money invested, Nubank still doesn’t show postive results. Please note that both companies are what I normally call “traditional born-digital” companies, i.e., companies which its core industry is not computer or software, but who were founded already with digital as part of their satrategy to potentialize results. Amazon is in the Retail Industry with low technology uncertainty and mid demand uncertainty and Nubank is in Banking industry witgh low technology and demand uncertainties, based on the demand and technology uncertainty by industry chart presented above.

The more distant an industry is from the Software Industry in the chart, the bigger the transformation change needed, i.e., the company needs to (1) understand that digital product development may not bring the desired results and (2) digital products take time to provide a return on the investment.

People also face digital transformation

I’m talking here about companies going through digital transformation and the challenges theses companies face during this transformation but companies are made of people, so the digital transformation actually happens to people who need to understand the demand and technology uncertainties that charechterize a digital transformation.

This fact that people go through digital transformation seems obvious when we talk about traditional companies, specially the ones that have decades of existence like bank, retail, drugstore, bookstore, real estate, insurance, restaurant and so on.

However, besides traditional companies, there are also two other types of companies:

  • tech companies which sell technology, i.e., technology is their core. Some examples are Google with its main product, Google Search and GMail. Amazon Web Services. Facebook. Instagram. WhatsApp. SAP. Salesforce. Zendesk. The companies I worked for (Locaweb and Conta Azul).
  • born-digital traditional companies which have traditional products or services that can exist without technology. However, as they have included technology since their beginning as a strategic capability, they look like digital companies. Examples are Amazon and Nubank that I cited above. Additional examples are listed in the image below:
Born-digital traditional companies

When we consider that digital transformation happens to people who are part of a company, it’s clear to see that born-digital traditional companies and even tech companies also face digital transformation. Many people who work in these companies probably came from more traditional industries with less demand and technology uncertainties and will have to adapt to a more uncertain context. For instance, to build Nubank, many of its employees, including C-level and founders, came from the banking industry like Cristina Junqueira who worked for Itaú prior to founding Nubank. Another interesting example is Google’s CFO Ruth Porat who worked at Morgan Stanley prior to joining Google.

Being able to understand the previous context of the people who are working on a digital transformation may help cope with the struggles and issues that we may face in a digital transformation, especially with its transformation aspect.

Summing up

  • The digital aspect of digital transformation is relatively easy since there are tons of knowledge and many experts to help design, develop and implement digital products. Product management and development techniques have been evolving at a rapid pace.
  • The transformation aspect of a digital transformation is harder since there’s not much knowledge about it and we tend to credit its difficulty to a somewhat generic cultural and mindset cause.
  • Demand and technnology uncertaintIies of the software industry is what makes digital transformation difficult. Traditional companies that are in more certain contexts struggle to understand, and consequently to cope with, these uncertainties.
  • Born-digital traditional companies and even digital companies also face digital transformation issues since the people who work in these companies, including C-level and founders, may come from companies in contexts where demand and technology are less uncertain.
  • Being able to understand previous context of the people who are working on a digital transformation may help cope with the strugles and issues that we may face in a digital tyransformation, specially with its tranasformation aspect.

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, solve its user’s problems and achieve the company objectives? Check out my Digital Product Management bundle with my 3 books where I share what I learned during my 30+ years of experience in creating and managing digital products:

You can also acquire the books individually, by clicking on their titles above.

Mentoring and advice on digital product development

I’ve been helping several companies extract more value and results from their digital products. Check here how I can help you and your company.

Why individual bonuses don’t work for product teams?

It is fairly common for the CTO or CPO to receive a request from the CEO to create some sort of individual bonus for the product development team. I have heard this kind of questioning quite often in some of the mentoring sessions I do. Something along the lines of “we need to measure people and reward them according to their individual performance, I want to implement the Ambev culture”. Usually, this quote about Ambev comes from the reputation of the strong and aggressive culture of obtaining compensation based on the achievement of individual goals.

Most of the CEOs I know have a sales background. Those that don’t, most likely have sales at the top of their priority list. People on sales teams are normally paid a base salary plus commission on sales, which is an individual incentive. That is, it is very easy, month by month, to identify who are the salespeople with the best and worst contribution to the company based on their sales results, and compensate the best results individually through the sales commission, and work with people with worse performance. Therefore, it is quite natural to think about using this dynamic of recognizing and rewarding individually based on these individual results for all people in a company, including product development teams.

Teamwork

However, in product development teams we have people with different roles, engineering, product design, and product management. This diversity of functions is essential to creating successful products. That’s why the team’s result is the team’s result, it’s the result of teamwork. Individual results are incomplete. It is useless for the product manager to define what will be done to achieve a certain result and solve a certain customer problem, if the product designer does not help in this definition, bringing her knowledge of user experience and interaction design, and if the engineers do not help in this definition and build what was defined. For this reason, the individual bonus makes no sense for product development teams.

Individual vs team bonus

Even Ambev, which has always had a strong culture of achieving individual goals, has changed. In a 2017 interview – in Portuguese – for Época Negócios magazine, Fabio Kapitanovas, then vice president of people and management at Ambev, said that:

The company has sought to increase collaboration among employees — the goals began to include collective variables and not just individual ones. Today, the bonus depends on individual, area and company results. We changed that so that people have an incentive to collaborate more with each other.

In a conversation with Ricardo Okino, a sales specialist, and consultant, who has worked in Linx, Conta Azul, and Vitta, he commented that some companies are already reviewing their compensation plan for commercial teams with the aim of, in addition to the commission, which is an individual bonus, also include team and company goals as part of compensation or as an accelerator. It’s a way to reward a person for their individual results and, at the same time, encourage group work and collaboration behaviors.

How then to recognize and reward the individual?

In commercial teams, even in those that adopt part of the bonus is based on team results, it is reasonably simple and objective to evaluate individual performance.

On the other hand, in product development teams, results do not appear only through individual efforts. Each person on the team has to do their part well for the result to happen. In a situation like this, how to recognize and reward each person on the team individually? First, you need to know how to evaluate people on a product development team. For this, we must look at two components, the “what” and the “how”, that is, what result was achieved by the team and how the person contributed to achieving this result.

Analyzing the “what”, if a certain result is expected from the team, it may make sense to have some kind of bonus for the entire team for a higher than expected result. Normally, this type of bonus can be defined in two ways:

  • the same reward for everyone, such as a dinner, a trip or even a cash prize. This type of bonus helps reinforce the sense of team.
  • some reward based on multiples of salary. In this case, we will already be making some kind of individual reward, given that the salary of people in a product development team is not the same.

When we analyze “how” each person on the product development team contributed to achieving the result, that’s when we have the opportunity to think about how to compensate each person on this team individually. This compensation can be done through a salary increase accompanied or not by an eventual promotion to the next career step. This salary increase directly impacts any team bonuses that are set for the product development team. Let’s imagine that a given product development team is entitled to a bonus of two additional salaries for surpassing a given result. Whoever has a salary of X will receive a 2*X bonus, while whoever has a salary of 1.25*X will receive a 2.5*X bonus.

In other words, the way to reward people from a product development team individually is the evolution that the person will have in their career at the company. People who contribute a lot to achieving and surpassing results end up evolving faster than those who contribute less.

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, solve its user’s problems and achieve the company objectives? Check out my Digital Product Management bundle with my 3 books where I share what I learned during my 30+ years of experience in creating and managing digital products:

You can also acquire the books individually, by clicking on their titles above.

Mentoring and advice on digital product development

I’ve been helping several companies extract more value and results from their digital products. Check here how I can help you and your company.

Por que bônus individual não funciona para times de produto?

É razoavelmente comum a pessoa CTO ou CPO receber o pedido da pessoa CEO para criar algum tipo de bonificação individual para o time de desenvolvimento de produtos. Tenho ouvido esse tipo de questionamento com certa frequência em algumas sessões de mentoria que faço. Algo na linha de “precisamos medir as pessoas e premiá-las de acordo com seu desempenho individual, quero implementar a cultura Ambev”. Normalmente essa citação da Ambev vem pelo fama da cultura forte e agressiva de obtenção resultados a partir de metas individuais dessa empresa.

Boa parte das pessoas CEO que conheço têm um background na área de vendas. As que não têm, muito provavelmente têm o tema vendas no topo da lista de prioridades. Pessoas de times de venda são normalmente remuneradas com um salário base mais comissão sobre as vendas, comissão essa de caráter individual. Ou seja, é muito fácil, mês a mês, identificar quem são as pessoas vendedoras com melhor e pior contribuição para a empresa baseado em seus resultados de vendas, e compensar os melhores resultados individualmente por meio da comissão de vendas, e trabalhar as pessoas com pior performance. Sendo assim, é bastante natural pensar em usar essa dinâmica de reconhecer e premiar individualmente baseado nesses resultados individuais para todas as pessoas de uma empresa, incluindo os times de desenvolvimento de produto.

Trabalho em equipe

Contudo, em times de desenvolvimento de produto temos pessoas com diferentes funções, engenharia, design de produto e gestão de produto. Essa diversidade de funções é essencial para a criação de produtos de sucesso. Por isso o resultado do time é do time, é resultado de um trabalho em equipe. Resultados individuais são incompletos. De nada adianta a pessoa gestora de produtos definir o que será feito para atingir determinado resultado e resolver determinado problema da cliente, se a product designer não ajudar nessa definição, trazendo seu conhecimento de experiência do usuário e de design de interação e se as pessoas de engenharia não ajudarem nessa definição e construírem o que foi definido. Por esse motivo não faz sentido a bonificação individual.

Bonificação individual vs de equipe

Mesmo a Ambev, que sempre teve uma cultura forte de atingimento de metas individuais, tem mudado. Em uma entrevista de 2017 para a revista Época Negócios, Fabio Kapitanovas, então vice-presidente de gente e gestão da Ambev, disse que:

A empresa tem buscado aumentar a colaboração entre os funcionários — as metas começaram a incluir variáveis coletivas e não apenas individuais. Hoje, o bônus depende dos resultados individuais, da área e da empresa. Mudamos isso para as pessoas terem incentivo de colaborarem mais entre si.

Em conversa com Ricardo Okino, especialista e consultor de vendas, com passagens por Linx, Conta Azul e Vitta, ele comentou que algumas empresas já estão também revendo seu plano de remuneração para equipes comerciais com o objetivo de, além da comissão, que é uma bonificação individual, incluir também metas de time e da empresa como parte da remuneração ou como acelerador. É uma maneira de premiar uma pessoa pelos seus resultados individuais e, ao mesmo tempo, incentivar comportamentos de trabalho e colaboração em grupo.

Como então reconhecer e premiar o indivíduo?

Em equipes comerciais, mesmo nas que adotarem parte da bonificação sendo baseada em resultados de equipe, é razoavelmente simples e objetivo avaliar a performance individual.

Já em times de desenvolvimento de produto os resultados não aparecem somente pelos esforços individuais. Cada pessoa do time tem que fazer bem sua parte para que o resultado aconteça. Numa situação como essa, como reconhecer e premiar individualmente cada pessoa do time? Primeiro é preciso saber como avaliar pessoas de um time de desenvolvimento de produto. Para isso devemos olhar dois componentes, o “o quê” e o “como”, ou seja, qual resultado foi atingido pelo time e como a pessoa contribuiu para o atingimento desse resultado.

Analisando o “o quê”, se for esperado um determinado resultado do time, pode fazer sentido algum tipo de bonificação para todo o time pelo resultado atingido se tiver sido superior ao resultado esperado. Normalmente esse tipo de bonificação pode ser definida de duas formas:

  • algo igual para todos como, por exemplo, um jantar, uma viagem ou mesmo premiação em dinheiro. Esse tipo de bonificação ajuda a reforçar o senso de time.
  • alguma premiação baseada em múltiplos do salário. Nesse caso, já estaremos fazendo algum tipo de premiação individual, dado que o salário das pessoas de um time de desenvolvimento de produtos não é igual.

Quando analisamos o “como” cada pessoa do time desenvolvimento de produtos contribuiu para o atingimento do resultado é quando temos a oportunidade de pensar em como compensar individualmente cada pessoa desse time. Essa compensação pode ser feita através de aumento de salário acompanhado ou não de uma eventual promoção para o próximo passo da carreira. Esse aumento de salário impacta diretamente em qualquer bônus de equipe que seja definido para o time de desenvolvimento de produto. Se um determinado time de desenvolvimento de produtos tiver uma bonificação por atingir um determinado resultado de duas vezes o salário. Quem tem salário de X receberá 2 * X de bônus, enquanto quem tem salário de 1,25 * X receberá 2,5 * X de bônus.

Ou seja, a maneira de premiar pessoas de um time de desenvolvimento de produto de maneira individual é o própria evolução que a pessoa terá em sua carreira na empresa. Pessoas que contribuem muito para o atingimento de resultados acabam evoluindo mais rapidamente do que aquelas que contribuem pouco.

Gestão de produtos digitais

Você trabalha com produtos digitais? Quer saber mais sobre como gerenciar um produto digital para aumentar suas chances de sucesso, resolver os problemas do usuário e atingir os objetivos da empresa? Confira meu pacote de gerenciamento de produto digital com meus 3 livros, onde compartilho o que aprendi durante meus mais de 30 anos de experiência na criação e gerenciamento de produtos digitais. Se preferir, pode comprar os livros individualmente:

Mentoria e aconselhamento em desenvolvimento de produtos digitais

Tenha ajudado várias empresas a extrair mais valor e resultados de seus produtos digitais. Veja aqui como posso ajudar você e a sua empresa.

Let’s remove the product from the center?

I have been working with digital products for over 30 years. I graduated in computer engineering at ITA in the early 1990s and since then I have worked for companies whose core business is technology. Starting with Dialdata, my internet services startup from the time when new tech companies weren’t called startups yet. Then I worked with technology products at .comDominio, a data center that became Alog and was later acquired by Equinix. Then I went through Locaweb, Conta Azul, and more recently Gympass. All technology companies, i.e., that use technology to deliver value to their customers.

Beyond the product

At Gympass I started to understand the mechanics of a company where technology and the digital product are not the core business. Gympass product is a corporate benefit that companies hire to provide their employees access to a network of gyms and studios. At the end of 2019, there was an effort to digitalize – and diversify – Gympass product portfolio, but even so, the main product continued to be to provide wellness services as a corporate benefit for companies to offer their employees.

Even technology companies have a mission to do “something” through technology. Locaweb’s mission is:

Making businesses grow and prosper through technology.

And Conta Azul’s mission is:

Boost small entrepreneurs’ success by bringing to small businesses more organization, control and time through technology.

And well-known tech companies don’t even mention technology in their missions:

Our mission is to empower every person and every organization on the planet to achieve more. (Microsoft)

Organizing the world’s information and making it universally accessible and useful. (Google)

Give people the power to share and make the world more open and connected. (Facebook)

In other words, technology and technology products are not the mission of technology companies, they are the vehicles used by these companies to fulfill their mission.

When I joined Lopes, Brazil’s largest real estate company, founded in 1935, long before computers and the internet existed, I began to better understand something I was already noticing during my time at Gympass. The digital product is not at the core of a company. The company does not revolve around the product, but the other way around, i.e., the digital product is there to serve the company and its customers, to leverage its results, and to help fulfill its mission. Lopes’ mission is:

Help people conquer their place.

When the product is at the center

One of the products that was under developement when I joined Lopes was the “MVP” of the brokers’ app. I put the MVP in quotes because this app was already in development for 5 months and still had another 1 or 2 months to finish and be available for use.

When I started talking to people to understand what was the main problem that the app would solve, I found that the main focus was to make the lead, that is, the information about a person interested in a property, be as soon as possible in the hands of brokers, because the faster this broker get in touch with that person and engage in a conversation about their needs, the greater the chances that this engagement would evolve into a possible sale of a property. Hence the idea of ​​making an MVP of an app with push notification to alert the broker about the lead.

At this point, an app for brokers development team was created and they started thinking about the journey of the broker receiving this lead through push notification. When the broker receives this lead, she needs to consult the data of this potential customer in Lopes’ system and, if the person is not registered yet, register their data in the system. And then, there was one more feature that “MVP” had to have before it was released, the search and registration of new potential client. Thinking more about the broker’s journey, it is very common when receiving the lead and understanding the needs of this potential client, to do a search in the real estate firm database to be able to send other propety options. And voila, one more minimal mandatory feature for the “MVP” of the broker app, the property search. To the point of having been developed for this “MVP” the possibility of drawing the region for the property search with your finger on a map.

Screen drawing functionality to mark theproperty search region in the app for brokers.

By putting the product at the center, people start to care about the product and its features. And that’s where the demand for delivering features comes from. Designing the minimal scope of an MVP may lead to discussions revolving around “minimal” features. Even when we use the term MVP, the focus is on the minimum product.

Removing the product from the center

Ok, it’s clear that by putting the product in the center, we end up potentializing some pitfalls that can hinder our delivery of results. So what should we put at the center? The expected result. In the example above, the expected result was to get leads as quickly as possible into the hands of brokers so they could contact the potential customer as soon as possible and engage him in a conversation with potential for sale of property.

If we notice in the description of the expected result, there is no mention of app, push notification, customer registration, or property search. The expected result is to make the lead reach the brokers’ hands as quickly as possible. If we focus more on the problem we will see that there are other possible solutions besides the app for brokers. We can send notifications via SMS or WhatsApp, something much simpler and faster to develop than an app. And probably with greater reach, as all cell phones accept SMS and most people in Brazil have WhatsApp, while a new app needs to be downloaded by the user. We implemented SMS notification and within 10 days all brokers started to receive these notifications. Delivery of value to brokers, potential customers and Lopes much faster than thebroker app 5 month “MVP”.

Product is means, not the end

That is why I have often repeated that product, app, website, technology, data, algorithms are not the end, they are not the goal, they are vehicles to achieve the goal of delivering value. And they must be treated as such. Making the lead reach the brokers’ hands faster can be done by push notification in an app for brokers, but it can also be done by SMS notification or WhatsApp. The vehicle matters less than the value, and the result delivered.

When we have an app team for brokers, with people from engineering, design and product management, the main vehicle that people on this team know to deliver value to brokers is the app they are developing. For this reason we made a change at Lopes in the team structure. We went from teams by product like the app for brokers team to teams focused on the actors of our business, and we created the brokers and franchises team that focuses on delivering value to brokers and franchises, regardless of the delivery vehicle for that value. It can be via a web system, an app, an SMS notification, a chatbot, etc. What matters is delivering value, and results, to brokers and franchises as quickly as possible.

Summing up

  • Product, app, website, technology, data, algorithms are not the end, they are not the goal, they are vehicles to achieve the goal of delivering value, and results, for customers and for the company.

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, solve its user’s problems and achieve the company objectives? Check out my Digital Product Management bundle with my 3 books where I share what I learned during my 30+ years of experience in creating and managing digital products:

You can also acquire the books individually, by clicking in their titles above.

2 hacks to foster your digital product culture

I led product development at Gympass for almost 1.5 years. Prior to Gympass I always worked in companies where technology was the main product of the company, Conta Azul and Locaweb are two good examples. In this type of company, digital product culture is part of the organizational culture. However, if you are in a traditional company, or even in a “born-digital traditional company”, building and maintaining a digital product culture can be quite a challenge.

What is digital product culture?

Digital product teams have two main premises when they build products to meet companies strategic objectives while solving a problem or addressing a need for the company’s clients and users:

  • Release early and often: the early I present my product to its users, the better since I’ll be able to get feedback from real users who will be able to use the product in their own context. I explained the motivations behind release early and often in this article.
  • Problem mindset: it’s human nature to solve problems. Whenever we hear about problems we almost immediately jump into solution mode, i.e., searching for solutions. However, if we are able to understand better the problem, the motivation to have the problem solved, the context where the problem occurs, there are good chances that we will be able to find simpler and easier to implement solutions.

When traditional company culture clashes with digital product culture, and how to hack this clash

In traditional companies, and even in some digital companies and traditional born-digital companies, the sales team is always talking to prospective customers, understanding their problems and pains, and figuring out where the product can be a good solution for these problems and pains. For this reason, new releases from the product development team are almost always not only welcomed but also anticipated.

As soon as a new release is available, salespeople want to offer it to all new prospects. That happened and still happens a lot here at Gympass. The problem is that, following the release early and often premise of digital product culture, the first versions of a feature or a product is somewhat clunky, either missing functionalities, or mal-functioning in certain use cases, or even both. We need customer feedback in order to improve the product in future versions. The issue is that if prospective customers decide to become new customers of these early versions, which may not work in certain scenarios and may not offer the best experience, these new customers will probably be quite upset.

Another issue that happens frequently when we release early and often is customer support complaining that the new feature or product is not working properly and they have to provide assistance. At Conta Azul, the product development team constantly received the complaint from customer support that we constantly launch unfinished features and products, i.e, that we constantly launch half-baked features or products. And they were correct, that’s the natural consequence of release early and often way of work.

Hack #1: alpha, beta, and go-live terminology

For this reason, I decided to use what I call hack #1 to foster a digital product culture, alpha, beta, and go-live terminology. I started using this terminology to explain in which stage a product or a feature is. In the alpha stage, the product may not work properly. If it’s in alpha, it should be offered only to customers who understand the issues of using a new product and can cope with these issues without a bigger burden. So this should be a handful of clients, no more than that. At the beta stage, major issues of the product are fixed, but the errors may still occur and the user experience can and will improve. In this phase, it is possible to offer the product or feature to tens of customers. Then, when all known errors are fixed, and the user experience is working properly, then its time to move the product into the go-live stage, where the product can be offered to all prospects and existing clients. This certainly helps sales and customer support teams understand the release cycle of new features and new products.

The other area where traditional company culture clashes with digital product culture is new feature requests. It’s common to see other areas asking the product development team to implement feature A or B because we need this feature to close a deal or to not lose that big customer. A common example these days is “we need to implement Apple Pay and Google Pay as a new payment method”. The issue here is that talking about solutions, we lose the focus on the problem that originated that solution. As explained in this article, if we invest more time learning about the problem, the motivation to have the problem solved, and the context where the problem occurs, good chances are that we will be able to find simpler and easier to implement solutions.

Hack #2: problem mindset

For this reason, I decided to use what I call hack #2 to foster a digital product culture, problem mindset. Whenever a new feature request came to the product development team, they should thank the requester for the input and they must always ask for the underlying problem that generated the request. Each and every member of the product development team needs to have this behavior whenever a feature request is received. By practicing this behavior, soon the requests will come not only with a solution but also with a lot of information about the problem. It’s interesting to see this cultural change, but it requires the discipline of the product development team members to always ask for the problem. And when I mention product development team members I’m referring to everyone, not only the product managers but also product designers and engineers.

Summary

So here they are, 2 hacks to foster your digital product culture:

  • Hack #1: Use the alpha, beta and go-live terminology so everyone – clients, users, market, people in your company, understand in what phase your product is.
  • Hack #2: always ask “what’s the problem?” so you can better understand the problem prior to investing time in investigating solutions.

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, solve its user’s problems and achieve the company objectives? Check out my Digital Product Management bundle with my 3 books where I share what I learned during my almost 30 years of experience in creating and managing digital products:

  • Startup Guide: How startups and established companies can create profitable digital products
  • Product Management: How to increase the chances of success of your digital product
  • Leading Product Development: The art and science of managing product teams

2 hacks para promover e fortalecer sua cultura de produto digital

Liderei o desenvolvimento de produtos no Gympass durante 1,5 anos. Antes dele, 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:

  • 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: https://www.linkedin.com/pulse/why-hurry-launch-mvp-joaquim-torres-joca-/
  • 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 funcionalidade 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, eles 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 costuma ocorrer quando lançamos cedo e com frequência é com o time de suporte ao cliente que reclama, e com razão, de que o novo recurso ou produto não está funcionando corretamente e 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.

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, 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 vai 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 entenderem o ciclo de lançamento de novos recursos e novos produtos e 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 dele 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 pelo 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 que todos (clientes, usuários, mercado e pessoas da sua empresa) possam entender 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.

Gestão de produtos digitais

Este artigo faz parte do meu livro “Gestão de produtos: Como aumentar as chances de sucesso do seu software”, onde falo sobre o que é gestão de produtos digitais, seu ciclo de vida, que ferramentas utilizar para aumentar suas chances de sucesso. Você também pode se interessar pelos meus outros dois livros:

Organizational culture

Organizational culture is a very important theme for product managers and has a tremendous impact on the success of a digital product. Therefore, let’s dig into it. In a way, this subject complements the previous chapter 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 difference between Amazon, Apple, Facebook, Google, Microsoft, and Oracle. Even with all the cultural differences, these are all successful companies.

Culture differences by Manu Cornet

But what is organizational culture? Edgar Schein, professor at MIT Sloan School of Management, was one of the first to talk about organizational culture in the 70s. According to him, each company had its own personality and its own approach to act and react to situations; and this approach has been 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, to 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 culture and it’s only natural that they spread this culture in the organization they are creating. That’s why it 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 cultures. 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. Cultures can and must be planned. For that reason, I’ll share with you three essential organizational culture values that I’ve seen in some companies when creating successful software products.

Don’t waste time looking for culprits

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 could be, in some way, less harmful. That is a great waste of time and energy. Let me explain why.

Blame game, by Ron Tandberg

A mistake took place. Mistakes happen. That’s a fact of life. No matter what you are doing — building 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 it:

  • Understand what happened;
  • Figure out how to correct;
  • Find ways to avoid from happening 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 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 it is safe to talk about mistakes so they can be 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.

War

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. I hate watching fights, even on TV. 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 kinds of comparisons between the business world and wars, combats, fighting or competition, I feel deeply bothered.

I believe the images speak for themselves.

Using war (combat or fighting) as an analogy for the business world does not make any sense. The goal 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 businesses?

Business is the activity of making one’s living or making money by producing or buying and selling products (such as goods and services).

vWikipedia definition of Business: https://en.wikipedia.org/wiki/Business

This definition makes it clear that the business exists to produce and / or serve. How can something that aims to produce and / or serve by analogy have something that aims at destruction? The right way to look at a company and its goals is to think about building a win-win relationship, that is, where the customer, the employees, the owners of the company, and the society in which the company operates are winning. Whenever we direct energy to defeat the “opponent” (customer, competitor, employee, etc.), we are wasting energy that could be used in something constructive.

Air, food and profit

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 heard a sentence that became popular with Dick Costolo, Twitter’s former 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 being 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. That 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 at a higher price, taking advantage of the fact that you need that item, such as the cost of a 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 shortness of breath. I don’t think that the 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 food that is good for your body; and there’s bad food, harmful for your body, 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, 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 food?”. 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 is not going to cause any harm.

Concluding

We saw in this chapter how important the organizational culture is for the success of your software product, and that culture is not a theme to go with the flow, it can and must be planned. Here I’ll share three cultural values that, in my point of view, are essential for creating successful software:

  • Do not waste time looking for culprits;
  • Do not compare making business with making war, combat or fighting;
  • Think about revenue as good food, that is, something necessary for living but not the reason for living.

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, solve its user’s problems and achieve the company objectives? Check out my Digital Product Management bundle with my 3 books where I share what I learned during my almost 30 years of experience in creating and managing digital products:

  • Startup Guide: How startups and established companies can create profitable digital products
  • Product Management: How to increase the chances of success of your digital product
  • Leading Product Development: The art and science of managing product teams

Cultura Organizacional

Cultura organizacional é um tema muito importante para gestores de produtos; por isso, quero abordar um pouco dele aqui. De uma certa forma, esse assunto complementa o capítulo Dicas de liderança para gestores de produtos.

Cultura organizacional é uma característica de toda empresa. Até mesmo dentro de uma empresa existem subculturas, ou seja, cada área ou time dentro de uma empresa pode ter uma cultura própria. Por exemplo, a cultura de um time comercial tem sempre algumas diferenças da cultura do time de engenharia de software.

Não existe cultura certa ou cultura errada. Empresas diferentes têm culturas diferentes e, mesmo assim, podem ter sucesso apesar dessas diferenças. A charge a seguir ilustra a diferença de cultura entre Amazon, Apple, Facebook, Google, Microsoft e Oracle. Mesmo com essas diferenças culturais, todas são empresas de sucesso.

Por Manu Cornet. Fonte: http://www.bonkersworld.net/organizational-charts/

Mas o que é cultura organizacional? Edgar Schein, professor da escola de administração de empresas do MIT, foi uma das primeiras pessoas a falar sobre cultura organizacional nos anos 1970. Segundo ele, cada empresa tinha sua própria personalidade, e sua própria forma de agir e reagir às situações; forma esta que é passada de funcionário para funcionário desde os fundadores da empresa. A definição de Schein para cultura organizacional é:

CULTURA ORGANIZACIONAL

Cultura é um conjunto de premissas que foram aprendidas e compartilhadas por um grupo de pessoas enquanto resolviam problemas de adaptação externa e de integração interna. Esse conjunto de premissas funciona bem o suficiente para ser considerado válido e, consequentemente, ser ensinado aos novos membros do grupo como a forma correta de perceber, pensar e sentir em relação a esses problemas.

Fonte: SCHEIN, Edgar. Organizational Culture and Leadership. Jossey-Bass, 2010.

A cultura vem dos fundadores da empresa. Os fundadores têm sua própria cultura e é natural que imprimam essa cultura na organização que estão criando. Em função disso, é muito comum se pensar que ela é algo que emerge em uma organização.

O fundador traz sua cultura e, ao contratar novas pessoas, busca sempre pessoas com cultura similar à sua. Isso acaba criando uma cultura comum muito próxima daquela trazida pelo fundador da empresa. Esse conceito de cultura emergente dá a impressão de que não se pode alterá-la deliberadamente, e que ela se desenvolverá de forma orgânica.

Schein alerta que isso é um engano. Culturas podem e devem ser planejadas. Por esse motivo, vou compartilhar três valores de cultura organizacional que tenho visto em algumas empresas e que, a meu ver, são essenciais na criação de produtos de software de sucesso.

NÃO DESPERDIÇAR TEMPO BUSCANDO CULPADOS

Quando erros acontecem, algumas pessoas têm uma tendência natural de ter como sua primeira reação procurar quem é o culpado, especialmente em atividades de grupo. Como se ter alguém para culpar fizesse o erro, de alguma forma, menos prejudicial. Isso é um grande desperdício de tempo e energia. Deixe-me explicar o porquê.

Blame game, por Ron Tandberg

Ocorreu um erro. Erros acontecem. Este é um fato da vida. Não importa o que você está fazendo – desenvolvendo software, publicando código em produção, operando um paciente, cozinhando o jantar, construindo uma casa, tocando guitarra, jogando futebol etc. –, há boas chances de que erros venham a acontecer.

Quando você gasta tempo tentando descobrir quem foi o responsável pelo erro, você vai adiar suas tarefas mais importantes em relação a ele:

  • Compreender o que aconteceu;
  • Descobrir como corrigir;
  • Encontrar formas de evitar que isso aconteça novamente.

Quando você gasta tempo tentando descobrir quem foi o responsável pelo erro, as pessoas podem, naturalmente, tentar esconder o erro por temer as consequências. Será que vou ser demitido? Será que vou ser excluído do grupo? Será que vou ser punido? Será que as pessoas vão zombar de mim?

Quando as pessoas tentam esconder quem foi o responsável, você vai acabar adiando as tarefas mais importantes que listei para tratar o erro, pois será mais difícil entender o que aconteceu. As pessoas não vão dizer toda a verdade sobre o erro e as circunstâncias em que ele aconteceu.

Se no processo de entender o que aconteceu, você descobrir que alguém foi responsável pelo erro, lide com ele em particular. O mais provável é que ele o tenha causado sem intenção de fazer mal. Por isso você precisa ajudá-lo a melhorar para que ele não cometa mais esse tipo de erro.

Por outro lado, você tem a responsabilidade de criar um ambiente em que é seguro falar sobre erros, para que estes sejam detectados o mais rápido possível. Contudo, se você descobrir que o erro foi feito com intenção de prejudicar a companhia, algum time ou alguma pessoa, nesse caso você deve ser direto na repreensão, dizendo que o comportamento é inaceitável e, na reincidência, convidar essa pessoa a sair do grupo.

GUERRA

É comum ouvir comparações entre o mundo dos negócios e situações de guerra, de combate e de luta. Aliás, a própria palavra “estratégia”, tão comum nas empresas de hoje em dia, vem do mundo militar. Vem da palavra grega strategos, junção das palavras stratos (exército) e agos (líder). Strategos significa originalmente o líder do exército, o general, aquele que define como a tropa deverá agir frente às situações.

Um dos livros que constantemente aparece na lista de mais recomendados para administração é A Arte da Guerra, um tratado militar escrito durante o século IV a.C. por Sun Tzu, general chinês.

Quem me conhece sabe que sou uma pessoa pacífica. Odeio brigas. Aliás, se acidentalmente entro em uma, estou disposto até a pagar para sair. Por isso, sempre que vejo essas comparações do mundo de negócios com guerra, combate, luta ou competição, eu me sinto profundamente incomodado.

Acho que essas imagens falam por si só… Usar guerra (combate ou luta) como analogia para o mundo dos negócios não faz o mínimo sentido. Nelas, o objetivo é derrotar o adversário. É estranho imaginar uma empresa cujo objetivo principal seja derrotar algo ou alguém.

Algumas pessoas já comentaram comigo que, em uma guerra, a guerra em si não é o objetivo, mas sim um meio para se atingir um objetivo. Ok, faz sentido, mas existem vários meios para se atingir um determinado objetivo. A guerra não é o único meio. Por que então a insistência em usar a guerra como analogia para as empresas?

Buscando na Wikipédia, encontramos a seguinte definição para empresa:

EMPRESA

Empresa é uma instituição jurídica despersonalizada, caracterizada pela atividade econômica organizada, ou unitariamente estruturada, destinada à produção ou circulação de bens ou de serviços para o mercado ou à intermediação deles no circuito econômico.

Fonte: http://pt.wikipedia.org/wiki/Empresa.

Esta definição deixa claro que a empresa existe para produzir e/ou servir. Como pode algo que tem por objetivo produzir e/ou servir, ter por analogia algo que tem como objetivo a destruição? A maneira correta de olhar uma empresa e seus objetivos é pensando em construção, em relação ganha-ganha, onde o cliente, os funcionários, os donos da empresa e a sociedade na qual a empresa está inserida saem ganhando. Sempre que direcionamos energia para derrotar o “oponente” (cliente, competidor, funcionário etc.), estaremos desperdiçando energia que poderia ser usada em algo construtivo.

AR, COMIDA E LUCRO

Não raro vemos acionistas, investidores e funcionários de uma empresa 100% focados nos resultados financeiros. Quando em período de crise, esse foco consegue ir além dos 100%… :-/

Certa vez ouvi uma frase, popularizada por Dick Costolo, CEO do Twitter, que comparava receita a oxigênio:

Receita é como oxigênio, é necessário, é vital para a saúde e para o sucesso de uma empresa, mas não é propósito da vida. Você não acorda de manhã e a primeira coisa que pensa é “como eu posso conseguir mais ar?”.

Gosto bastante dessa comparação. Toda empresa deve ter um propósito, e esse propósito não pode ser derrotar os inimigos (como explicado anteriormente), nem conseguir a maior quantidade de dinheiro possível.

O resultado financeiro deve sempre ser usado como uma das métricas que indicam que a empresa está tendo sucesso, que está cumprindo com o seu propósito. Contudo, mesmo como métrica, ela não deve ser olhada de forma isolada, pois existe a boa e a má receita.

A má receita é toda receita obtida às custas do detrimento do relacionamento com o cliente. Por exemplo, imagine uma empresa que presta um serviço com pagamento mensal; quando um cliente quer cancelar, ela dificulta sua saída para manter aquela fonte de receita por mais alguns meses. Isso é uma má receita. Quando uma companhia aérea cobra uma taxa para adiantar o horário de um voo, mesmo sabendo que o avião tem espaço de sobra; isso é má receita. As taxas de roaming internacionais exorbitantes também são um bom exemplo disso, como locadoras de veículos que cobram a taxa de gasolina quando você devolve o carro sem estar com o tanque cheio, com preço de gasolina bem mais caro do que o do mercado.

Se uma empresa vende algo com o preço acima do adequado, aproveitando-se do fato de que você precisa daquele item como, por exemplo, o custo absurdo da garrafa de água em um hotel, isso também é uma má receita.

Apesar de a comparação de receita e lucro com oxigênio ser boa, ela é incompleta, pois não capta o efeito da má receita. Raramente você pensa no oxigênio, a não ser que esteja com falta de ar. Eu não acho que a receita só deva ser lembrada quando está faltando. Receita é o que mantém a empresa viva, capaz de executar seu propósito. Se for uma boa receita, a empresa vai continuar cumprindo seu propósito por muitos anos. Já se for uma má, ela terá dificuldades no médio prazo.

Por esse motivo, prefiro comparar receita e lucro com comida. Da mesma forma que as pessoas saudáveis não pensam em oxigênio o dia inteiro, pessoas saudáveis também não pensam em comida o dia todo. Contudo, diferentemente do oxigênio, quando falamos de comida, existe a comida boa, saudável, que faz bem para o seu corpo; e existe a comida má, que vai prejudicar seu organismo, com possibilidade de fazer você ficar doente. É muito importante que a pessoa saiba o que é boa comida e má comida, e que pense sobre como obter a boa e como evitar a má.

Pegando a frase de cima e aprimorando-a, trocando o oxigênio pela comida, teremos:

Receita é como comida, é necessária, é vital para a saúde e para o sucesso de uma empresa, mas não é propósito da vida. Você não acorda de manhã e a primeira coisa que pensa é “como eu posso conseguir mais comida?”. Contudo, tanto uma empresa quanto uma pessoa devem estar sempre atentas à qualidade da comida que está ingerindo, para ter certeza de que ela não vai causar nenhum mal à saúde.

Concluindo

Vimos neste capítulo o quão importante é a cultura organizacional para o sucesso do seu produto de software, e que cultura não é um tema para deixar acontecer, ele pode e deve ser planejado. Compartilho três valores culturais que, a meu ver, são essenciais para a criação de um software de sucesso:

  • Não desperdiçar tempo buscando culpados;
  • Não comparar fazer negócios com guerra, combate ou luta;
  • Pensar em receita como comida, ou seja, algo necessário para viver, mas não é a razão do viver.

Gestão de produtos digitais

Este artigo faz parte do meu livro “Gestão de produtos: Como aumentar as chances de sucesso do seu software”, onde falo sobre o que é gestão de produtos digitais, seu ciclo de vida, que ferramentas utilizar para aumentar suas chances de sucesso. Você também pode se interessar pelos meus outros dois livros: