About Joca

I've been helping companies succeed in the digital era by guiding them on how to create and manage successful digital products that connect their strategic objectives with the problems and needs of their customers.

Papéis, responsabilidades e senioridade

No capítulo anterior acabamos de rever alguns conceitos básicos de produtos digitais. Agora vamos entender o que é ser head de produto, quais os seus papéis e suas responsabilidades.

Gerenciamento de expectativas

Qualquer que seja o caminho que o leve à possibilidade de ocupar um cargo de liderança de produto, seja por considerar esse o seu próximo passo na carreira ou por ter a tarefa de encontrar alguém para ocupar esse cargo, é importante esclarecer qual é a principal responsabilidade deste papel: gerenciamento de expectativas. Será algo entre 50 a 80% do seu tempo.

Ouço de alguns gestores de produto que querem se tornar head de produto porque veem essa posição como uma grande oportunidade de ter uma opinião forte sobre, ou até mesmo de liderar, a construção da visão e estratégia do produto e, consequentemente, da empresa, especialmente se você estiver em uma empresa que é puramente digital ou tradicional nascida digital.

Isso realmente acontece, e é parte de sua responsabilidade, mas devo dizer que isso não representa mais de 10% do trabalho de head de produto. E mesmo esses 10% não são um empreendimento solo. Você precisará construir a visão e estratégia de produto em colaboração com as principais partes interessadas em seu produto, especialmente os fundadores da empresa, que são os primeiros gestores de produto de qualquer empresa e a diretoria, os C-level.

Os outros 90% da responsabilidade do head de produto são compartilhados entre ajudar gestores de produto em seu desenvolvimento – algo entre 10% a 40%, dependendo da senioridade desses gestores de produto – e o gerenciamento de expectativas, que vai tomar de 50% a 80% do seu tempo.

Por gerenciamento de expectativas, quero dizer gerenciar a ansiedade de todos os interessados no produto, internos e externos, em saber quando e como o produto vai ter essa ou aquela funcionalidade para trazer aquele resultado para atingir aquele objetivo.

É importante ter essa divisão de tarefas e responsabilidades clara antes de decidir aceitar a função de head de produto, para entender o que outras áreas e sua equipe vão esperar de você, caso você decida aceitar o trabalho.

Normalmente, tenho visto pessoas preenchendo uma posição de head de produto vindo com três históricos principais: ou é uma gestora de produto que começará a gerenciar outros gestores de produto ou é uma pessoa que lidera design ou marketing ou é uma pessoa que lidera engenharia.

Gerente de produto preenchendo a posição de head de produto

Esse pode ser um passo natural na carreira de uma gestora de produto. À medida que se torna mais experiente, ela pode se tornar a pessoa preferida de outros PMs em busca de conselhos. Portanto, os 10% a 40% de ajudar outros gerentes de produto a fazer parte da posição de chefe de produto podem vir naturalmente para ela. No entanto, ainda há 10% da construção da visão e 50% a 80% do gerenciamento de expectativas a serem considerados.

A construção da visão também não deve ser algo novo para um gestor de produto sênior. Ele já deve fazer isso para o produto ou parte do produto que cuida, portanto não deve ser novidade, apenas ter um escopo maior. Lembre-se de trabalhar na construção de uma visão de alto nível e dar espaço para que os detalhes sejam trabalhados pelos PMs que o head de produto lidera. Construir esses detalhes de uma visão de produto é uma responsabilidade e oportunidade desenvolvimento importante para gestores de produto.

Os 50% a 80% restantes do tempo gasto no gerenciamento de expectativas também não devem ser estranhos ao gestor de produto que aspira a se tornar head de produto. Na verdade, ele já faz isso com o produto ou parte do produto de que cuida. Desde os membros de sua equipe, as pessoas de outras áreas, os C-level, até o fundador da empresa. Aqui, novamente, estamos falando de um aumento de escopo. E, novamente, precisamos permitir que os PMs liderados pelo head de produto também gerenciem a ansiedade das partes interessadas, para que possam desenvolver essa habilidade. Mas não se esqueça de que, como head de produto, você será o responsável para gerenciar as expectativas do C-level, dos fundadores e do conselho.

Se você não deseja gerenciar outras pessoas, tudo bem. Sempre é possível ter espaço em sua equipe para uma posição de gerente de produto mais sênior. Algumas empresas chamam isso de principal product manager. Falarei mais sobre esse papel ao longo do livro.

O primeiro passo para um gestor de produto se tornar head de produto é quando continua trabalhando com sua própria equipe (engenheiros e designers de produto) e supervisiona o trabalho de um gestor de produto em outra equipe. Um nome possível para essa nova posição é group product manager (GPM), pois ela está gerenciando um grupo de produtos ou um grupo de partes de um produto. Indo tudo bem, o próximo passo é contratar seu substituto para a função existente que ele ainda desempenha como gestor de produto. Livre de seu trabalho diário de gerenciar um produto, ele poderá gerenciar dois ou mais gestores de produto.

Líder de UX ou líder de marketing

UX e marketing são duas áreas muito próximas à gestão de produtos. Enquanto o UX trabalha em conjunto com gestão de produtos em atividades de discovery, o marketing trabalha em conjunto com gestão de produtos em atividades para contar ao mundo sobre o produto e o problema que ele resolve e para aumentar sua base de usuários. Ou seja, ambos entendem bem o trabalho de gestão de produtos por trabalharem diariamente com isso.

Tanto para um líder de UX quanto para um líder de marketing que assume essa posição de head, é importante que essa pessoa entenda não apenas as semelhanças, mas também as diferenças entre as duas funções e seu papel e responsabilidades no sucesso do produto.
 

CTO / Head de Engenharia

Se você é um CTO ou um líder de engenharia e foi convidado para liderar a área de produto, é provável que você tenha sido solicitado a preencher essa posição em adição das suas responsabilidades existentes em engenharia. Existem prós e contras em combinar os dois papéis. Como ponto positivo, desenvolvimento de produto é uma área só que tem por objetivo entregar o melhor produto para atingir os objetivos da empresa enquanto resolve problemas dos usuários. Ter uma única pessoa liderando a área facilita o alinhamento do time.

Por outro lado, especialmente com time maiores, juntar esses dois papéis pode gerar uma sobrecarga considerável na sua agenda e no dia a dia de trabalho. É importante conseguir priorizar e ter boas pessoas no time para você delegar algumas de suas tarefas.

Tanto na Locaweb quanto na Conta Azul eu tive esse papel de liderar todo o time de desenvolvimento de produto, ou seja, gestores de produto, product designers e engenharia. Apesar de ter background técnico, eu sempre tive pessoas seniores para me ajudar na gestão de engenharia assim como na gestão de design e de produtos. Já no Gympass rodamos durante 18 meses com um CTO, um head de produtos para consumers e eu como head de produtos para empresas e parceiros.

Papéis e responsabilidades

Como eu comentei acima, o papel do head de produto está dividido em 3 grandes áreas:

Visão e estratégia de produto: normalmente toma algo em torno de 10% do tempo de um head de produto. Definir a visão de produto é definir como será o produto no futuro. O que você quer que o produto seja quando ele crescer? E a estratégia é o caminho para chegar até a visão. Construir visão e estratégia de produto é um trabalho que o head de produto faz alinhado com os fundadores da empresa, a alta gestão e o conselho, com input de todas as áreas da empresa e do cliente. Vou falar mais sobre construção de visão e estratégia nos próximos capítulos.

Ajudar gestores de produto em seu desenvolvimento: a depender da senioridade do seu time, isso vai tomar algo em torno de 10% a 40%. Quanto mais júnior e inexperiente, mais tempo você terá que dedicar para o desenvolvimento do seu time. Falarei mais à frente sobre algumas das Ferramentas importantes: reuniões 1:1, reuniões de time, avaliação e feedback, product council, product update e organização de time.

Gestão de expectativas: pelo menos metade do seu tempo será dedicado à gestão de expectativas, podendo chegar a até 80%. Na área de produtos e, principalmente, na liderança de produtos digitais, não existe “comunicação em excesso”. Sempre haverá alguém que tem expectativas sobre o produto e que ainda não está ciente da sua visão e estratégia. Com muitas empresas com quem converso sobre produtos digitais ouço uma reclamação bastante comum, de que a área de desenvolvimento de produtos é uma caixa preta. E isso gera muita expectativa das outras áreas, que precisam que suas dores de produto sejam resolvidas. Por outro lado, o time de desenvolvimento de produto também tem expectativas, quer saber qual a visão de produto, qual a estratégia, qual o roadmap, quais as prioridades. A melhor maneira de gerir essas expectativas é por meio de comunicação. Como comentado, as Ferramentas que serão apresentadas mais à frente serão muito úteis para a gestão de expectativas.

Pessoas que querem crescer na carreira para serem head de produto costumam justificar essa progressão de carreira motivados pelo desejo de poder ter uma voz mais ativa e até mesmo guiar a definição de visão e estratégia do produto. Sinto frustrá-los. Como já mencionei, isso é apenas 10% do trabalho de um head de produto. Os outros 90% do tempo de um head de produtos são dedicados ao trabalho de ajudar os gestores de produto a se desenvolverem e à gestão de expectativas. Reforço que, quanto mais júnior e inexperiente for o seu time, mais tempo você terá que dedicar para o desenvolvimento do seu time, o que pode tomar até 40% do seu tempo. Por outro lado, se seu time for júnior e inexperiente, mais trabalho você terá com gestão de expectativas, que pode chegar a tomar até 80% do seu tempo.

Imagine que você tem um time júnior e inexperiente, que tome 30% do seu tempo, e que, em função disso, você tenha muita gestão de expectativa para fazer, tipo 70% do seu tempo. Ou seja, 100% do seu tempo será tomado com ajudar seu time a se desenvolver e em gerir expectativas. Por isso, é importante você tomar muito cuidado com a senioridade do seu time, caso contrário não sobrará tempo no seu dia a dia para cuidar da visão e estratégia do produto que você lidera.

Certa vez, ao explicar essa divisão de tempo, recebi a pergunta se gestão de resultados não seria também uma das responsabilidades do head de produto. Sim, é uma das suas responsabilidades, e cai na categoria de gestão de expectativas. Todos na empresa esperam que o produto ajude no atingimento das metas e nos resultados da empresa. Assim como os usuários do produto também têm a expectativa de atingir suas metas e resultados utilizando o seu produto. Então, uma forma de gerir as expectativas das pessoas da empresa e de seus usuários é ajudando-os a atingir seus resultados e deixando claro como o produto está tornando isso possível.

Níveis de senioridade

Este é um tópico que ouvimos quase diariamente em todas as empresas: níveis de senioridade. Existem muitas situações em que esse assunto surge, como em contratação, avaliação de desempenho, aumentos, promoções, bônus etc. Quanto mais sênior é uma pessoa, mais você espera dela. Afinal, ela tem experiência e conhecimento para lidar com as situações mais difíceis do trabalho. Minha experiência me mostrou que precisamos analisar a senioridade de uma pessoa com base em três dimensões:

Tempo

Normalmente avaliamos a senioridade com base no tempo. Por exemplo, se uma pessoa tem mais de 10 anos de experiência, ela é sênior. No entanto, o tempo sozinho não é suficiente. Se ela fez a mesma coisa nesses 10 anos, sem se questionar e sem continuamente buscar melhorar e experimentar coisas novas, ela não evoluiu como profissional. Ela não colocou novas ferramentas em seu cinto de utilidades. E terá bastante dificuldade ao enfrentar novas situações uma vez que não tem as ferramentas necessárias.

Conhecimento

Portanto, além do tempo, também devemos considerar o conhecimento. Podemos traduzir o conhecimento como o conjunto de ferramentas que um profissional possui em seu cinto de utilidades. Se uma pessoa conhece apenas uma ferramenta, ela a usará para resolver todos os problemas. É como diz a lei do martelo: para um martelo, tudo parece um prego. Essa lei é atribuída a Abraham Maslow, psicólogo americano bastante conhecido pelo conceito da pirâmide de hierarquia de necessidades.

Quanto mais ferramentas alguém tiver, mais fácil será enfrentar novas situações e encontrar soluções. Essa é a razão pela qual os consultores são tão versáteis. Eles trabalham por curtos períodos de tempo em clientes diferentes, enfrentando problemas diferentes e precisam criar maneiras de resolver novos problemas, já que cada novo cliente em que trabalha tem problemas e contextos diferentes.

Às vezes, uma consultora com 3 anos de experiência, trabalhando em 6 clientes diferentes, terá muito mais ferramentas em seu cinto de ferramentas do que alguém que permaneceu na mesma empresa por 10 anos. A consultora provavelmente será mais sênior do que a pessoa que ficou por 10 anos na mesma empresa, fazendo o mesmo trabalho e resolvendo os mesmos problemas sem se questionar e buscando continuamente melhorar, melhorar e experimentar coisas novas.

Para avaliar a antiguidade de alguém – inclusive quando estamos autoavaliando nossa própria senioridade – precisamos olhar para anos de experiência e a qualidade do conhecimento acumulado durante esses anos. Contudo, isso não é suficiente.

Comportamento

O comportamento é uma dimensão da senioridade que normalmente não é discutida quando avaliamos a senioridade de alguém, mas é tão importante quanto tempo e conhecimento. Às vezes tenho a impressão de que é ainda mais importante que tempo e conhecimento.

A senioridade comportamental significa que a pessoa sabe como se comportar adequadamente:

  • ser ético, ser uma pessoa íntegra e com a intenção correta;
  • ter alinhamento com os valores e a cultura da empresa;
  • ter alinhamento e comprometimento com o propósito da empresa;
  • ter alinhamento e comprometimento com os objetivos estratégicos da empresa.

Vou dar alguns exemplos e contraexemplos de senioridade comportamental para tornar o conceito mais claro:

  • Metas: todas as empresas têm metas. Todas as empresas têm objetivos quantificados e metas são definidas para ajudar a atingir esses objetivos. Um método muito conhecido para definir objetivos e quantificar os resultados é o OKR (Objective and Key Results ou objetivos e resultados chaves). Algumas empresas ainda usam essas metas para definir a remuneração variável de seus funcionários, também conhecida como política de bônus. Invariavelmente, depois que os objetivos são definidos, as coisas mudam. E mesmo quando tudo estiver estável, pode ser necessário fazer um trabalho não relacionado aos objetivos. Alguém com senioridade comportamental entende que as coisas mudam e que seu trabalho não se limita às metas previamente acordadas e fará o que for necessário. Alguém sem senioridade comportamental dirá que ela não pode mudar ou fazer qualquer outra coisa além do que é definido como sua meta.
  • Reclamar: como todos sabemos, às vezes as coisas não andam como esperamos. É assim que a vida é. E sempre há pessoas que reclamam. E a culpa é sempre de outra pessoa e sempre há muitas desculpas para explicar por que as coisas não aconteceram como esperamos. Reclamar sem fazer nada para ajudar a resolver a situação é um comportamento típico de alguém que não tem senioridade comportamental. Uma pessoa sênior, quando enfrenta problemas, tenta entender o que aconteceu, sem procurar culpados. Procura uma solução para os problemas e procura entender como evitar que esses problemas ocorram novamente.

Acredito que com esses dois exemplos e contraexemplos fica mais claro o que significa senioridade comportamental.

Na minha opinião, esta é a dimensão mais importante de senioridade. Se você tem alguém com senioridade em conhecimento e muitos anos de experiência, mas sem senioridade comportamental, ela não só terá maiores chances de ter um desempenho ruim, como também interferirá no desempenho de sua equipe.

Qual a sua senioridade?

Portanto, da próxima vez que você estiver avaliando o nível de senioridade de alguém – inclusive quando estiver avaliando sua própria senioridade –, avalie anos de experiência, qualidade do conhecimento acumulado durante esses anos e a senioridade comportamental. Somente então você poderá avaliar completamente o nível de senioridade dessa pessoa.

Resumindo

  • O head de produto é responsável por coordenar a definição da visão e estratégia de produto, por ajudar os gestores de produto em seu desenvolvimento e por gerir as expectativas de todas as pessoas que têm interesse em seu produto.
  • Um conceito muito importante para ajudar uma head de produto com suas responsabilidades é o conceito de senioridade, que tem 3 dimensões, duas bem conhecidas, o tempo e o conhecimento e uma terceira não tão conhecida, mas tão importante quanto às outras, a senioridade de comportamento.

No próximo capítulo vamos entender um pouco mais sobre a carreira de produtos.

Liderança de produtos digitais

Estou publicando os 30 capítulos do meu mais novo livro, Liderança de produtos digitais: A ciência e a arte da gestão de times de produto, um por semana. Caso você queira ler o livro completo, pode adquiri-lo diretamente da editora. Você também pode se interessar pelos meus outros dois livros:

Ecosystem mindset

This value I learned at Gympass. It was one of the company’s corporate values ​​and, in my opinion, every platform must incorporate this value in its culture. I often came across CEOs and heads of platform products who claimed that they do everything for the customer, that the entire company is customer-centric. However, when I dive deeper in this topic, I end up discovering that the client they were referring to was just one of the actors of their platform and the others were treated only as “necessary evil”.

In the description of the value on the Gympass website it is written:

Ecosystem mindset

We make decisions that create value for our Gympass ecosystem and help us achieve our mission.

The ecosystem mindset example I will describe below is the implementation of the live classes product that Gympass created during the COVID-19 crisis.

Diversifying – and digitizing – a product portfolio

During the COVID-19 pandemic, we diversified – and digitized – our product portfolio in record time. We went from an offline product, access to gyms and studios, to 4 products, 3 of them totally digital, in less than a month:

  • Access to gyms and studios: Access to more than 50,000 gyms and studios in 14 countries;
  • Live classes: for those who like to train in groups or want to relive the feeling of the class with colleagues at the gym;
  • Personal trainers: for those who prefer a more personalized approach and like to exercise in their own time;
  • Gympass Wellness: app package with over 60 apps for those looking for options to improve physical and mental well-being (from nutrition to therapy session).

Below I explain how we did it.

Product Vision

When I joined Gympass in mid-2018, one of the first things I did was to build a product vision. We had a very strong purpose: to defeat inactivity. However, to build a digital product, we need more than a purpose.

Gympass product vision

This vision guided the definition of the Gympass product development organization. As I commented in the chapter Team structure, we set up teams around each of the marketplace participants, in addition to a central team that worked in the payment flow collecting the payment from the companies and their employees, doing all the calculations, and determining the amount to be paid to each gym partner.

When I was building this product vision and discussing it with different people in the organization, it was easy to see many opportunities to expand that marketplace. There are a lot of new service categories that we could add to our marketplace:

Gympass expansion opportunitties

There are 3 types of elements in a market:

  • Supply: goods or services available for consumption.
  • Demand: people or companies that may need goods or services offered by the supplier.
  • Market: where demand meets supply and a transaction occurs.

These three elements are related as follows:

  • Value delivery: the market adds value to demand and supply. The value delivered to the supply is people or companies interested in their goods or services. The value delivered to demand is a varied number of suppliers of goods and services.
  • Payment: To have access to goods and services offered by suppliers, demand pays the market and the market pays for the supply. The market typically retains a fee per transaction. This fee can be fixed or a percentage of the payment.
Dynamics of a marketplace

Given the dynamics above, we can expand a market as follows:

  • Diversification of demand: you can offer goods and services from your marketplace to new segments and geographic regions.
  • Supply diversification: you can offer new goods and services to your demand.
  • Delivery of new value: you can offer new value to your supply and demand.
  • Financial payment management: as the demand payment to the supply passes through the marketplace, you can offer financial services for both demand and supply, such as advance payment and credit, and you can manage the spread.
Marketplace expansion opportunities

However, we had a lot to do with our main product at that time, so we didn’t have enough energy to focus on expanding our marketplace and left the plans in the drawer.

New endeavor

In October 2019, we reached a point where our product development team was well structured and working properly to address our challenges in our core product, so we decided to focus on expanding our marketplace.

We decided to work on an idea called “Gympass end-user partnership hub”. The plan was to partner with wellness apps and provide them to our users.

This new idea had two main hypotheses that we needed to test:

  • Application providers willingness to partner. Application providers, like gyms, are used to the recurring monthly revenue model. Would they accept to be paid per day of use?
  • Our user base willingness to pay. Is our user base interested in paying a monthly fee to access the applications?

To test our first hypothesis, we built a deck with the value proposition that we planned to deliver to the partners and talked to some potential partners. We presented the opportunity to 8 potential partners, of whom 6 showed interest and 4 decided to join our proof of concept. NEOU, a workout app, 8fit, a workout and nutrition app, Tecnonutri, a nutrition app and ZenApp a meditation app.

Okay, our first hypothesis was validated and we needed to validate the second hypothesis, the willingness to pay. Is our user willing to pay to access these applications through Gympass?

To test our second hypothesis, we built a simple form, where we described the product and asked for name, email and company. After the user provided this information, he was directed to a Paypal subscription page, where he had to provide his credit card details to subscribe to the service. The user would receive an email with the activation link for each application. There was no real product, no logged in area, just a form to test interest and an email with links to the applications.

Initially, we call it Gympass W, the W meaning wellness. We added a beta so that everyone could understand that it was not a finished product. Later, we renamed it to Gympass Wellness to make its value proposition clearer.

Our plan was to test this proof of concept with 5 corporate clients in the USA and 5 in Brazil, which would provide us with a potential user base of 15,000 employees. Our expectation was to have around 200 subscribers. We launched internally – eat your own dog food – on March 9, 2020 and had 66 subscribers from our 1,200 employees. Then came COVID-19.

COVID-19

When a company is hit by a crisis, it needs to look at these two perspectives:

  • preserve cash;
  • identify and adapt to changes in customer problems and needs.

Although product managers and product development teams play an important role in the former, their primary role is in the latter.

At Gympass we have 3 different clients and all of them deeply impacted by COVID-19:

  • gyms in many cities have been closed to support with physical distance measures applied to prevent the spread of COVID-19 and, consequently, are losing recurring revenue from users who were not going to the gyms;
  • users, employees of our customers, can no longer go to the gyms and have to stay at home, but they also have to remain active in some way, but their first reaction was to cancel or pause their Gympass subscription, because they didn’t have access to the gyms for a while;
  • corporate customers, whose employees are at home and no longer go to gyms, while HRs are concerned with how to keep these employees engaged and productive.

Gympass Wellness, the first digital product

We were able to adapt our Gympass Wellness pilot in record time to be offered to our entire user base, so that they can remain active, and also take care of their nutrition and their minds during these challenging times. With Gympass Wellness, we were able to address the problems and needs of users and our corporate customers during the crisis.

And here comes the ecosystem mentality. We must always look at all participants in our marketplace and ensure that everyone benefits from using it.

Live Classes, the second digital product

With Gympass Wellness, we were able to meet the needs of our corporate customers and their employees. But what about the gyms? When closed, they were losing revenue. Their customers no longer visited them, so regular gym users were likely to cancel their subscription, while those who used to go to gyms using Gympass did not go to the gym during the crisis, which would cause a loss of revenue for gyms as well. To help partner gyms cope with this very difficult situation, we decided and implemented 2 solutions in record time:

  • We provided the academies with a white-label application so that they can offer it to all their customers, regardless if they were or weren’t employees of Gympass customers, so that the gyms could deliver value to their customers, helping them to stay active at their homes;
  • We provided a platform for gyms to schedule and broadcast live classes to all Gympass users, so they can keep their instructors employed, while providing Gympass users with exclusive content. This platform is called Live Classes.

Personal Trainers, the third digital product

Live Classes provided a 1:N platform, which means that an instructor could provide physical activity guidance to N users. We soon realized that we could create another product in addition to Live Classes. Workout guidance 1:1, which could be made available in Gympass’ higher tier plans. Then we created our third digital product, Personal Trainers.

Summing up

  • Ecosystem mindset means making decisions that create value for all actors on a platform.
  • At Gympass, during the COVID-19 crisis, after offering Gympass Wellness for all its customers and their employees, an important part of the ecosystem was still suffering, the gyms. It was the ecosystem mindset that guided Gympass to create Live Classes product, which allowed gyms to continue operating even though they were behind closed doors.

There, with this chapter we conclude the second part of the book, on Principles. Here we saw my personal leadership principles:

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

We also saw what corporate culture is, a set of ways shared by a group of people working together on how to solve problems and react to situations. We also saw the 5 values ​​needed to create successful digital products:

  • Don’t waste time looking for culprits, focus on learning.
  • Don’t compare work situations with war, nobody wants to kill anyone.
  • Profit and revenue are a consequence, should not be the main focus.
  • Transparency, the foundation of a high performance team.
  • Diversity, the basis of the best products.

Finally, we saw a set of four values ​​that are in fact the core of the entire digital product development team. These are the values ​​that make up the product culture, which is the set of behaviors of the digital product development teams that produce the best results:

  • Release early and often
  • Focus on the problem
  • Result delivery
  • Ecosystem mindset

In the next chapter we’ll start the third and final section of the book, about tools! \o/

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

O que é produto digital e gestão de produtos?

Como comentei na introdução sobre meu livro Liderança de produtos digitais, o livro é dividido em três seções, sendo a primeira seção intitulada Conceitos.

Pessoas que me conhecem sabem que sou um grande fã de iniciar qualquer novo empreendimento com uma linguagem ubíqua (ubiquitous language), termo que Eric Evans usa no seu livro Domain-Driven Design para a prática de criar uma linguagem comum e rigorosa entre desenvolvedores e usuários – no meu caso, entre autor e leitores(as).

Por esse motivo, começarei o livro definindo alguns conceitos, fazendo uma revisão de conceitos básicos como produto e gestão de produtos, e apresentando novos conceitos como funções e responsabilidades de head de produto, estrutura de equipe, carreira e carreira Y para gerentes de produto.

O que é produto digital e gestão de produtos?

Neste capítulo farei uma revisão de alguns conceitos básicos de gestão de produtos que serão necessários para os próximos capítulos, onde definirei conceitos mais ligados à liderança de desenvolvimento de produtos.

Vamos começar do começo:

Produto digital

Produto digital é qualquer software que tenha usuários.

Uma forma comum de classificar os produtos digitais é pelo tipo de público a que ele atende. Existem os produtos para consumidor final (Netflix, Spotify etc.) conhecidos como B2C (business to consumer), para empresas (Locaweb, Conta Azul, SAP etc.) conhecidos como B2B (business to business) e os mistos, que atendem tanto a consumidores finais quanto empresas (Instagram, Mercado Livre etc.).

Outra forma de se classificar um produto digital é olhando para a forma como o produto é entregue aos usuários (como online, não online e embarcado), ou de acordo com o que ele faz: e-mail, comércio eletrônico, pagamento, e-mail marketing, gestão de conteúdo, educação, comunicação, colaboração, relatório, entretenimento, sistema operacional, ERP, CRM etc.

Essas diferentes formas de se classificar não são excludentes. Por exemplo, a Netflix é um produto digital para o usuário final, mas também é um produto online de entretenimento.

Digital ou tradicional?

Além de entender o que é um produto digital e como classificá-lo, precisamos também entender a natureza da empresa dona desse produto digital.

Digital: o produto vendido pela empresa é o software ou a tecnologia desenvolvida pelo time de desenvolvimento de produto. Gestão de Produtos é o core da empresa, responsável pela visão de futuro e pela estratégia da empresa. O head de produto terá um papel central na definição e execução da estratégia da empresa. Exemplos: Locaweb, Conta Azul, Zendesk, Instagram.

Tradicional: o produto vendido pela empresa existiu, provavelmente durante muitos anos, sem a tecnologia, mas a empresa começa a entender como tecnologia pode potencializar o produto. Gestão de Produtos é um enabler, ou seja, algo que possibilita e potencializa o negócio principal, mas não é o core. É vista como a “área de digital”. O head de produtos terá que ganhar o seu espaço, mostrando os benefícios que a tecnologia pode trazer. Exemplos: Itaú, Magazine Luiza, Lopes.

Tradicional nascida digital: o produto vendido pela empresa poderia existir sem a tecnologia, mas a tecnologia potencializa muito o produto. Gestão de Produtos é também um enabler, mas não é o core. O head de produto terá um papel muito importante para a definição e execução da estratégia da empresa, mas não será central. Exemplos: Nubank, Netflix, Airbnb, Uber, Gympass.

Plataformas

As plataformas são produtos que entregam mais valor quanto mais usuários utilizam a plataforma. É o famoso efeito de rede, baseado na quantidade de interações possíveis entre esses usuários, quantidade essa regida pela fórmula n*(n-1)/2, onde n é o número de usuários. Plataformas existem há muitos anos no mundo offline. Um bom exemplo são os mercados da antiguidade. Eles são uma plataforma de dois lados, com compradores de um lado e vendedores do outro. Quanto mais vendedores tiver, mais útil é o mercado para os compradores. E quanto mais compradores tiver, mais atraente será o mercado para os vendedores.

Mercado antigo com compradores e vendedores (Copper Market, Cairo de Edward Angelo Goodall, 1871

Existem plataformas de um único lado (Facebook, Instagram, WhatsApp etc.) e plataformas de múltiplos lados, que podem ser de 3 tipos:

Troca: com compradores de um lado e vendedores do outro lado. Nesse tipo de plataforma, é comum uma pessoa entrar pelo lado comprador e ser convidado a participar do lado vendedor. Quem nunca foi convidado a dirigir para o Uber? Exemplos, além do Uber, são Airbnb, Mercado Livre etc. As plataformas de troca são também conhecidas como marketplaces.

Conteúdo: reúne produtores e consumidores de conteúdo com anunciantes. O conteúdo é o foco e a monetização é feita normalmente por meio de veiculação de anúncios. Exemplos são o Facebook, o Google e portais de notícia.

Técnicas: funcionam como um sistema operacional onde, de um lado, há os especialistas e, do outro, os usuários. O Android e o iOS são bons exemplos, com os desenvolvedores de apps de um lado e os usuários do outro. A Conta Azul é outro exemplo, de um lado estão os donos de pequenos negócios e do outro, os contadores.

Nas plataformas costuma-se desenvolver um produto para cada participante da plataforma, mais um ou mais produtos que cuidam da interação entre esses participantes.

Gestão de produtos digitais

Já vimos a definição de produto digital, a importância de entender se a empresa dona do produto é uma empresa digital, tradicional ou tradicional nascida digital e entendemos o que são plataformas. Agora vamos entender o que é gestão de produtos.

Gestão de produtos

Gestão de produtos digitais é a função responsável por todos os aspectos de um produto de software, durante todo o ciclo de vida desse produto, desde a sua concepção até o fim de sua vida.

É a função responsável por fazer a conexão entre a estratégia da empresa e os problemas e necessidades dos clientes por meio do produto digital. Esta pessoa deve, ao mesmo tempo, ajudar a empresa a atingir seus objetivos estratégicos, enquanto soluciona os problemas e atende às necessidades dos clientes.

Para saber mais

Pronto, já vimos, de forma bem resumida os principais conceitos de gestão de produtos digitais e estamos prontos para entender mais sobre como liderar produtos digitais.

Caso você queira saber mais sobre os conceitos que apresentei acima, você pode ler meu livro Gestão de produtos: Como aumentar as chances de sucesso do seu software. Nele, falo em detalhes sobre esses e outros conceitos relacionados a gestão de produtos digitais, bem como sobre ciclo de vida de um produto de software, relacionamento do gestor de produtos com as outras áreas e funções da empresa, gestão de portfólio de produtos e sobre onde usar gestão de produtos de software.

Resumindo

  • Produto digital é qualquer software que tenha usuários.
  • Produtos digitais podem existir tanto em empresas digitais, em que o produto digital é o produto que a empresa vende, quanto em empresas tradicionais, que usam o produto digital para alavancar e potencializar o produto principal da empresa.
  • Recentemente começaram a surgir as empresas tradicionais nascidas digitais, ou seja, empresas que vendem um produto não digital, mas que têm o produto digital como parte crítica de sua estratégia desde o início da empresa.
  • Plataformas são produtos que entregam mais valor quanto mais usuários utilizam a plataforma, o famoso efeito de rede. Existem plataforma de um único lado e plataformas de múltiplos lados, que podem ser de troca, de conteúdo ou técnicas.
  • Gestão de produtos é a função responsável por conectar os objetivos estratégicos da empresa com os problemas e necessidades dos clientes.

No próximo capítulo vamos ver o papel e as responsabilidades de um(a) head de produto e entender um pouco sobre um conceito muito importante, o de senioridade.

Liderança de produtos digitais

Estou publicando os 30 capítulos do meu mais novo livro, Liderança de produtos digitais: A ciência e a arte da gestão de times de produto, um por semana. Caso você queira ler o livro completo, pode adquiri-lo diretamente da editora. Você também pode se interessar pelos meus outros dois livros:

Result delivery

Result delivery

In the previous chapter, we saw the difference between a team that solves problems and a team that implements solutions. While a problem-solving team needs to have a deep understanding of each problem it will solve, the people who are affected by it, the context in which it occurs, and the motivation people have to have this problem solved, the solution implementing team focus on implementing what is asked, no matter if what is implemented will bring any results.

The measurement of result delivery for these two types of teams is often quite different. Through the way a team reports its results, we clearly know what kind of team it is. Something like:

Tell me about the results you deliver and I’ll tell you what kind of team you are on!

While the solution implementing team usually measures its delivery of results based on the number of features delivered, the problem-solving team measures its delivery of results based on how well the problems have been solved.

Feature Factory

Solution implementing teams are those “feature factories” that we already mentioned in the previous chapter, that is, whose main metric is the quantity and speed of feature delivery. As this is its main metric, this team is now measured by its deliveries. The team said it was going to deliver that functionality that day, so that’s what the organization expects and that’s what the organization will ask the team.

This situation is not as unusual as you might think. At Locaweb, before implementing OKRs, the product development team was primarily measured by its planning assertiveness. If the team said it was going to deliver X on day Y, that was what was expected of the team, with no concern whether X was the right thing to do and whether it was actually going to bring results for the company or customers. By implementing OKRs, we managed to make the team increasingly focused on understanding and solving problems.

When I joined Lopes, I found something very similar. A portal team, a CRM team, and an app team, all of them with predefined deliveries planned up to 6 months ahead, because that was what was agreed with the company’s management. Lopes had even hired two consulting companies that, when presenting their results report, showed the number of features delivered as their main result, because that was what was demanded of them, delivery of features.

It is important to note that a situation like this does not happen solely because of the product development team. It is also the responsibility of the people who are making the demands. While the product development team must always ask what problem they are trying to solve with that demand, the people who make the demands must always contextualize these demands bringing the problem that motivated the demand.

Focus on the result

After my first 30 days at Lopes, I started working with the team to define the OKRs for the next quarter, which even motivated HR to also make its planning based on OKRs. These OKRs were then presented to the entire leadership of the company. It was the way I found to bring about a change in culture and mentality both in the product development team and in the entire company.

Most of the OKRs we defined were focused on business results. Increase in sales, increase in the conversion rate, and so on. That’s what matters to the business. Features are a means to get to an end, they are not an end in themselves, even in 100% digital companies, such as Conta Azul and Locaweb, digital products are a means to the end. Locaweb even makes this very explicit in its mission to “make businesses born and prosper through technology”, while Conta Azul wants to “boost the success of small entrepreneurs by giving small businesses more organization, control and time through technology.” Note that in both companies the technology and, consequently, the digital product is a means to an end. Both achieve their mission “through technology”.

Summing up

  • Another fundamental value for any product development team is the focus on delivering results.
  • Care must be taken when defining the result. Delivering features is not a result. All features are a means that serves an end, the achievement of a business objective.
  • Even companies that are 100% digital companies, whose digital products and technology are the company’s core, need to focus on business objectives.

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

In the next chapter, we’ll look at the value of ecosystem mentality.

Sobre o livro Liderança de Produtos Digitais

Qual é o papel de um(a) vice-presidente ou head de produto? Ser um head de produto engloba muitos aspectos e habilidades diferentes, e foi por isso que decidi escrever um livro inteiro sobre esse tópico.

A arte e a ciência de liderar produtos digitais

Embora eu esteja falando sobre desenvolvimento de produtos digitais, que é baseado em engenharia de software, normalmente considerada uma ciência, acredito que há uma parte da liderança de equipes de desenvolvimento de produtos que é mais arte do que ciência. Perguntando ao Google o que é arte, obtemos algumas respostas interessantes:

“A expressão ou aplicação da habilidade e imaginação criativa humana, tipicamente em forma visual, como pintura ou escultura, produzindo obras a serem apreciadas principalmente por sua beleza ou poder emocional.”

Para desenvolver um produto digital, precisamos de criatividade e imaginação para criar um produto que empodere seus usuários para fazerem algo. O empoderamento é o processo de tornar-se mais confiante e a confiança é uma emoção. E todo produto digital tem interfaces que podem ser admiradas. Portanto, é fácil ver o processo de criação de um produto digital como criação de uma obra de arte.

“Uma habilidade para fazer uma coisa específica, tipicamente adquirida através da prática.”

Construir bons produtos digitais requer prática, muita prática.

Por outro lado, ao perguntar ao Google o que é ciência, também obtemos respostas interessantes:

“A atividade intelectual e prática que abrange o estudo sistemático da estrutura e comportamento do mundo físico e natural através da observação e do experimento”.

Muitas equipes de desenvolvimento de produtos estão compartilhando suas experiências e criando e melhorando o conhecimento sobre como criar produtos digitais.

“Um corpo de conhecimentos sistematicamente organizado sobre um assunto específico”.

Estamos construindo esse conhecimento à medida que experimentamos novos processos e refinamos os existentes. O desenvolvimento de produtos digitais é uma ciência nova e está intimamente ligada à história do software. A primeira vez que um computador armazenou um software em memória e o executou com sucesso foi às 11 horas do dia 21 de junho de 1948, na Universidade de Manchester, no computador Manchester Baby. Foi escrito por Tom Kilburn e calculou o maior divisor inteiro do número 2^18 = 262.144. Começando com um grande divisor de teste, ele executou a divisão de 262.144 por esse grande divisor e depois verificou se o resto era zero. Caso não fosse, subtraía 1 do divisor de teste e repetia o processo até o resto ser zero.

Ou seja, desenvolvimento de software e, consequentemente, gestão de produtos digitais são ciências com menos de 100 anos de vida. Se compararmos com medicina, construção civil, astronomia, matemática e outras ciências, estamos na primeira infância e ainda sabemos muito pouco. Temos investido muita energia na construção desse conhecimento para que as próximas gerações de desenvolvedores de produtos digitais sempre possam dar um passo à frente. É assim que todas as ciências são construídas, um passo de cada vez, cada geração começando a partir dos passos da geração anterior.

Para quem é indicado e como o livro está organizado?

O livro está focado na função de head de produto, mas será útil para qualquer pessoa da equipe de desenvolvimento de produtos digitais, bem como para quem não estiver nessa equipe, mas trabalha em uma empresa que possui ou planeja ter uma equipe de desenvolvimento de produtos. O conteúdo desse livro pretende ajudar a entender o que esperar da liderança desse time. O livro será dividido em três seções principais:

  • Conceitos: pessoas que me conhecem sabem que sou um grande fã de iniciar qualquer novo empreendimento com uma linguagem ubíqua (ubiquitous language), termo que Eric Evans usa no seu livro Domain-Driven Design para a prática de criar uma linguagem comum e rigorosa entre desenvolvedores e usuários – no meu caso, entre autor e leitores(as). Por esse motivo, começarei o livro definindo alguns conceitos, fazendo uma revisão de conceitos básicos como produto e gestão de produtos, e apresentando novos conceitos como funções e responsabilidades de head de produto, estrutura de equipe, carreira e carreira Y para gerentes de produto.
  • Princípios: toda empresa possui sua própria cultura e, dentro de cada empresa, todo departamento também possui sua própria cultura. Além disso, cada pessoa tem seus princípios e valores que norteiam seus passos pela vida. Aqui vou falar sobre a cultura, os valores e os princípios que acredito serem obrigatórios para criar produtos digitais de sucesso. E também, quais são os 4 principais valores que toda equipe de desenvolvimento de produtos e, consequentemente, toda empresa que tenha times de desenvolvimento de produtos digitais deve ter.
  • Ferramentas: aqui vou falar sobre as ferramentas que tenho usado nos meus quase 30 anos de carreira em liderança de desenvolvimento de produtos e tenho compartilhado com outros líderes para que eles ou elas possam usar com suas equipes. As ferramentas de que falarei incluem visão, estratégia, estrutura de equipe, métricas e cerimônias.

Uma novidade neste livro em relação aos meus livros anteriores são as seções “Resumindo” no final de cada capítulo. Elas têm por objetivo ser um guia rápido sobre o conteúdo de cada capítulo para ajudar a revisá-lo rapidamente antes de seguir em frente.

Outro ponto que gostaria de ressaltar é que o conteúdo deste livro é baseado em minha experiência prática em liderar desenvolvimento de produtos digitais. Ao longo de minha carreira venho experimentando diferentes formas de exercer essa liderança e o que estou descrevendo ao longo deste livro são os conceitos, princípios e ferramentas que melhor funcionaram, ou seja, que produziram os melhores resultados tanto para a empresa dona do produto, quanto para os usuários do produto, quanto para os times que trabalharam no desenvolvimento do produto.

Certamente há outras formas de liderar desenvolvimento de produtos digitais que podem ser diferentes e até mesmo discordantes do que estou passando aqui. Contudo, na minha opinião, o fato de duas pessoas discordarem não significa necessariamente que uma delas está errada. Apenas que há formas diferentes de se ver e de se fazer as coisas.

Qual é o seu propósito?

Li um livro intitulado Como avaliar sua vida (How will you measure your life?), do Prof. Clayton Christensen, professor de Harvard e criador do conceito “inovação disruptiva”. Nesse livro, publicado em 2012, ele conta como percebeu que ao longo dos anos seus colegas de turma acabaram se tornando pessoas infelizes, com suas vidas pessoais e profissionais distantes da que haviam planejado na época da faculdade. Alguns tinham seus nomes atrelados a escândalos financeiros e fiscais. Outros se casaram, separaram e brigam judicialmente com os ex-cônjuges. Outros ainda mal conseguem acompanhar o crescimento dos filhos.

Essa constatação o fez refletir sobre como seria possível aumentar as chances de encontrar satisfação e felicidade ao longo da vida. No livro, ele propõe que uma forma de se fazer isso é aplicando algumas das ferramentas do mundo da administração de empresas à gestão da vida pessoal e profissional.

Uma dessas ferramentas é o propósito. O propósito empresarial é o motivo de existir de uma determinada empresa. Muitas publicam esse motivo de forma clara. O Google tem por propósito organizar toda a informação do mundo, e fazê-la universalmente acessível e útil. A Nike quer trazer inspiração e inovação para todos os atletas do mundo, e que se você tem um corpo, você também é um atleta. Na Conta Azul impulsionamos o sucesso do pequeno empreendedor, e no Gympass, combatemos o sedentarismo.

Prof. Christensen propõe que as pessoas também tenham um propósito que deve nortear suas decisões ao longo da vida, da mesma forma que as empresas devem ter um propósito que norteie as suas. Achei essa ideia bem interessante e me provocou a pensar no meu propósito que, após analisar como invisto meu tempo e no que tenho prazer e satisfação em trabalhar, acabei definindo como sendo:

Meu propósito

Ajudar as pessoas a criarem produtos digitais melhores.

Por isso, compartilharei nas próximas páginas o que aprendi ao longo desses quase 30 anos de experiência. Acredito que o que vou compartilhar poderá ajudar na criação de produtos digitais melhores, que atingirão os objetivos do dono do produto, ao mesmo tempo em que atenderão às necessidades dos seus usuários.

Sei que ainda tenho muito a aprender e quero continuar aprendendo sempre. Como o aprendizado vem da troca de experiências e da conversa, convido-o a compartilhar suas experiências lá nos comentários

Vamos começar?

Liderança de produtos digitais

Estou publicando os 30 capítulos do meu mais novo livro, Liderança de produtos digitais: A ciência e a arte da gestão de times de produto, um por semana aqui. Caso você queira ler o livro completo, pode adquiri-lo diretamente da editora. Você também pode se interessar pelos meus outros dois livro:

https://www.casadocodigo.com.br/products/livro-lideranca-produtos

New book: Digital products leadership

I used the year-end low workload to finish translating my book “Digital products leadership: The science and art of managing product teams” into English. Enjoy! \o/

Here’s a special launch discount coupon:

https://leanpub.com/leadingproductdevelopment/c/launch

And happy 2021, full of amazing results brought to you by the products you manage!

Focus on the problem

It is human nature to solve problems. Whenever we hear about problems, we go into solution mode almost immediately: we start looking for solutions to the problem. However, if we are able to get a better understanding of the context in which the problem occurs and the motivation to solve it before jumping into solution mode, there are more chances of finding solutions that are simpler and easier to implement.

It is common to see other areas in the organization asking the product development team to implement feature A or B because we need it to close a deal or to not lose that big customer. A common example I have heard for sometime back in 2019 was “we need to implement Apple Pay and Google Pay as a new payment method”. The issue is that, talking about solutions, we lose focus on the problem that originated that solution.

What is the problem?

To help people focus on the problem, always ask “What is the problem?” When a new feature request arrives for the product development team, we must thank the requester and then ask about the problem that generated the request. Each member of the product development team must have this behavior whenever a request for a new feature is received.

By putting this into practice, requests will soon come with not only a solution but also a lot of information about the problem. It is interesting to see this cultural change, but it requires discipline from members of the product development team to always ask about the problem. And when I mention the members of the product development team, I’m referring to everyone, not just product managers, but also designers and product engineers.

Problem vs. solution mindset

The main advantage of focusing on better understanding the problem is that the more time we invest in it, the easier it will be to find a solution and there are good chances that this solution will be simpler and faster to implement than the first solution we thought of.

Here is a great quote from Albert Einstein:

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

Einstein believes that the quality of the solution you generate is in direct proportion to your ability to identify and understand the problem you are trying to solve.

Let me tell you a little story to illustrate this. During the space race, scientists were faced with the problem of writing in space where there was no gravity to make the ink fall into a ballpoint pen. The Americans started their R&D efforts and after some time and a few million dollars, they built a pen with a small engine that pumps ink onto paper, even without gravity. Meanwhile, the Russians decided to use pencils.

Pen that writes in weightless environments

This story shows a good example of how jumping straight to the solution can make us spend unnecessary time and money to come up with incomplete or exaggerated solutions. It is a cultural issue, that is, a behavior that we can and must change. And the first step in changing a behavior is to recognize when it happens. When a member of the product development team receives a request to implement something, he must ask the person who brought the request what is the problem that this “something” should solve and why it needs to be solved.

Here are some examples of the companies I worked for.

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

First solution: Registro.br, the Brazilian registrar of .br domains launched an API to allow Locaweb to charge the customer’s domain on behalf of Registro.br. At first, the idea seemed good, as Locaweb charging the domain seemed to be the easiest way to ensure that the customer knows that they have to pay for the domain registration to keep hosting and email services working properly. However, when we analyzed further, we saw that this solution could cause some problems. The customer would be charged twice for the same domain registration because Registro.br would continue to charge the domain. What happens if the customer pays both bills? What if he only pays for Registro.br? What if he only pays Locaweb? In addition, implementing a new type of billing in which we would charge for a third party service was something new for the Locaweb team. New processes would have to be carefully designed.

Implemented solution: we started to wonder if there would be simpler ways to solve the problem of helping our client not to forget that he has to pay for the domain registration at Registro.br. As it would be possible to charge for Registro.br services, it was possible to access information about the domain about to expire. We decided to design a simpler solution: implement a communication sequence with the client warning him of the importance of paying Registro.br to ensure that the email and hosting services continue to function normally. This is a much simpler solution than implementing a double billing process. If Registro.br provides us with the billing URL, we can send the information from this link to the customer and the chances of solving the problem will increase even more. And a communication sequence is much simpler and faster to implement than a duplicate billing process.

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

First solution: batch purchases, where accountants would acquire a fixed number of Conta Azul licenses to resell to their customers. A batch purchase management system would take about 3 months to implement, as it should allow accountants to purchase Conta Azul licenses in bulk, but it should only start charging the accountant’s customer when that customer actually activates the license.

Implemented solution: accountants didn’t care about batch purchases. What they wanted was to give a discount to their customers so that they could subscribe to Conta Azul with this exclusive discount provided by their relationship with us. The cost to implement this was zero, as the system already had a discount management feature.

At Gympass, a fitness partner who was joining our network asked us to present his waiver to all users who checked in to their facilities.

First solution: change our app to ask users who go to this fitness partner to read their waiver on our app and click a checkbox stating that they have read and agreed.

Implemented solution: no changes to our app. We use a customizable text field when configuring a gym in our system that is typically presented to users who will check in at that gym to present the following text: “By checking in, you agree to the terms and conditions located at http://fitnesspartner.com/waiver”.

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

Projects vs. problems

The New Year is a time for retrospective and planning. What is normally done every quarter by most product development teams is done more intensively at the turn of the year, in conjunction with other areas of the company. It is the annual planning process, which usually comes with the budgeting process. What will we do in this new year that is coming? What are the main projects that we will work on throughout the year?

Even though planning is super important to be clear about which projects are priorities for the new year, this list of projects can make you lose sight of a very important aspect of planning, the “why”.

It is not uncommon to see new year planning for a product development team, and even for the entire company, as a list of projects. To help you see your list of projects at a different perspective, I recommend you add 2 columns:

  • one to describe what problems you are trying to solve in each project;
  • and another to describe who you’re trying to solve this problem for.

I have already discussed the issues of having a problem-oriented mindset versus a solution-oriented mindset, but when it comes to New Year planning, that problem is even more evident. The benefits of being clear about the problems you want to solve and for whom you plan to solve them are:

  • Ensuring that problems are aligned with the company’s vision and strategy: When we focus on projects, it is easy to lose sight of the problems we are trying to solve, for whom we plan to solve, and if these are the problems we really need to solve.
  • Define which problems are most important to solve: prioritize projects without knowing which problems these projects solve, and for whom, it can make priorities unaligned with what is really important for the company. However, to be more effective in bringing the desired result, we must prioritize the problems to be solved and ensure that the prioritization is aligned with the company’s vision and strategy.
  • Solve more than one problem with the same project: Sometimes you may find that you are trying to solve more than one problem with a project, and this may not be a problem. But you need to know that. Perhaps you can have simpler solutions if you address each problem separately. Perhaps not all are worth resolving at this point.
  • Check if the projects are the best solutions: when we change the focus of the projects to the problems and we have clear visibility of the priority of the problems, it is easier to check if the projects listed are the best solution for the problem in question. Sometimes, we can find solutions that are easier to implement when we shift our focus to understanding problems.

Then take your list of projects and create these two columns, problems to be solved in each project and for whom the problems will be solved. This will help you to focus on the most important things for this new year.

Problem solving teams vs. solution implementing teams

Marty Cagan, a well-known reference in the digital products community, wrote an interesting article some time ago about product teams x feature teams, where he explains the difference between three types of teams, delivery teams, feature teams, and product teams. It defines each type of team as follows:

  • Delivery teams are not multifunctional (basically just developers plus a product owner who manages the backlog), are not focused on the result (people are all oriented towards delivering features) and have no autonomy (they are there to encode and deliver).
  • Feature teams are usually multifunctional (they have at least one designer and a product manager), but are still concerned with the production and delivery of features.
  • Product teams are multifunctional, focused and evaluated by the result, and have the autonomy to present solutions that work.

He explains that the best results for the organization that owns the product and for the users of that product come from the teams he calls product teams. He has used the word empowered a lot to describe these teams.

Any digital product exists for two main purposes:

  • Help the company that owns the digital product to achieve its goals.
  • Solve problems and meet the needs of its users.

Therefore, any digital product and its functionalities are solutions to problems of the company that owns the product and solutions to solve the user’s problems and meet their needs.

In this digital product context, when I say that spending more time understanding the problem produces the best solutions, I mean that we are able to deliver the best product and features as quickly as possible to solve the problem with good software quality and a good user experience.

solve problems vs. implement solutions

What Marty describes as delivery teams and feature teams are teams of solution implementers. These teams work on implementing a solution conceived by someone else. And that other person is usually someone from the so-called “business area” who can be someone from sales, marketing, customer success, customer support, finance, operations, a director, a vice president, or a founder. In such a team, the product manager mainly manages the backlog and helps the team to deliver the requested solution, the product designer focuses mainly on designing a pleasant interface, and engineers have to code and deploy the requested solution. The solution implementation teams do as they are asked to do, with little or no commitment to the quality of the solution, or even if the solution implemented really solves the problem. They may also be called a “feature factory”. Its performance is measured by the amount of functionality that the team produces.

On the other hand, what Marty describes as empowered product teams are problem-solving teams. These teams work to deeply understand the causes of the problem, the context, and the motivation that people have to solve it. In doing so, they are able to implement the best solution for the problem at hand.

There are three main reasons why problem solving teams are more effective than solution implementing teams:

  • Digital product knowledge: There is no one better than team members to find the best digital product solution to a problem. A solution delivered as quickly as possible, with good software quality and good user experience. This is because a team of problem solvers is a multifunctional team made up of engineers who understand the technology available, product designers, who have a deep understanding of users, their pains and needs, and product managers, who have a good understanding of the business context of the problem to be solved.
  • Two heads are better than one: this old saying means that it is easier for two people to help each other to solve a problem than for one person to solve a problem alone. A team of problem solvers does not rule out any suggestions for solutions from “business areas”. In fact, these solution suggestions are very useful in helping the team to better understand the problem, but they should be considered suggestions. A team of problem solvers first understands the problem and then looks at the solution options.
  • Commitment: An additional side effect of a problem-solving team is that members of that team are deeply committed to the successful implementation of the solution since they are deeply involved in the process of finding the solution.

Creation of problem solving teams

Now that I have explained why problem-solving teams are the best type of digital product team a company can have, I will explain how to build problem-solving teams. There are three aspects that need to be considered:

  • Environment: It is essential that the entire organization understands the power of having problem-solving digital product teams. The speed and quality of the solutions delivered by a digital product team that always starts to solve problems from a deep understanding of the problem are much better than the solutions delivered by teams of solution implementers. Consequently, business results will be better and faster. It is the role and responsibility of the product head to help the organization understand this.
  • What is the problem: A very effective way to focus the entire organization away from the solution mindset and closer to the problem mindset is to constantly ask “What problem are we trying to solve?” and “Why is it important to solve this problem?”. This will help people across the organization to change their perspective and, consequently, realize the importance of a deep understanding of the problem before implementing a solution. This is a behavior change that the entire digital product development team can help your organization make. Whenever someone asks the product team to implement something, ask “What problem are we trying to solve?”
  • Trust: This is a critical aspect of building successful problem-solver teams. Usually people in the “business area” believe they have a better understanding of the business than those of the product team. This behavior is even more visible when the digital product team is new to the organization. How can a new person in the organization understand more about the business than someone who has been with the company for years? She probably cannot, especially if she comes from a different market. However, those who are part of the digital product team usually have a lot of experience in building digital products, probably more experience than anyone else in the organization. Therefore, it is essential that the “business area” educate the digital product team about the business aspects of the organization. This search for education is the role and responsibility of product managers, who must learn from the “business area” and educate product designers and engineers about the business. A practical way to accelerate this learning is to bring people from the “business area” to the discussion sessions on the problem. This is how the product team gains the trust of the other areas of the organization.

I believe that the benefits of having digital product teams versus solution implementers teams are clear. The entire organization needs to understand the difference in order to push for more and more problem-solving teams. The head of product has this as one of her greatest responsibilities, helping to build the environment and the trust needed for the success of problem-solving teams.

The top-down trap

When I talk about the differences between problem solving teams vs solution implementing teams, I usually hear comments like “We want to be a problem solving team, but in my company all solutions are top-down and the only thing we can do is implement them “.

These situations worsen when a crisis arises. The most recent crisis that many companies are experiencing is the COVID-19 crisis. In an eagerness to solve problems as quickly as possible, company leaders ask teams to implement this or that solution quickly, very quickly.

The trap

Let me now approach the elephant in the room, the top-down decision-making environment. This has a huge impact on any team in this type of environment. Without being part of the decision about the solution, the people who implement the solution will end up discouraged and demotivated.

Why am I calling it a top-down trap? Because many of the decision-making environments perceived as top-down are what I just wrote, a perception.

Let’s use the main characteristic that every product manager should have, empathy. The ability of someone to put themselves in someone else’s shoes to understand their aspirations, motivations, needs, and problems. People I had the opportunity to talk to about the essential characteristics of a product manager know how important I consider empathy to be a critical trait for successful PMs.

Here are 2 tips to help product team members empathize with so-called top-down decision-makers and escape the top-down trap:

  • Understanding the situation: Put yourself in the place of the solution implementation requester. People solve problems, it is their nature, and whenever they encounter a problem, they jump into solution mode and try to find and implement solutions as quickly as possible. Under greater pressure, such as the COVID-19 crisis, the desire to find and implement solutions is exacerbated. In most cases, people do not want to be top-down decision-makers, they simply have a need to solve the problem as quickly as possible.
  • Changing the status quo: ask questions about the solution implementation request. What problem are we solving? For whom? Why is it important to solve this problem? Why now? Why do we need to deliver something fast, even while compromising quality? If you are asked the reason for so many questions, explain that you are trying to better understand the problem to see if there are other cheaper and faster to implement solutions.

These tips will help everyone on the product team make the move to a more collaborative decision-making process.

Most of the time, people understand the benefits of a collaborative decision-making process. Even under pressure, collaborative solutions will produce better results. Solutions designed in a collaborative process are usually cheaper and faster to implement because more people have had a chance to discuss solution options and the team that will implement the selected solution will be truly committed to your success.

To build, maintain and improve problem solving teams and avoid turning them into solution implementation teams, especially when under greater pressure, it is essential to avoid the top-down trap.

Heads of product have the role and responsibility to promote these behavioral changes to help build a more collaborative and, consequently, more effective decision-making process.

Summing up

  • A very important step in creating a good solution is understanding the problem. When we hear about a problem, we immediately start thinking about solutions. However, the more time we spend learning about the problem, the easier it will be to find a solution, and chances are good that this solution will be simpler and faster to implement than the first solution we thought of.
  • If you have a list of projects to do, create two more columns in that list, one for problems to be solved by each project and another for whom the problems will be solved. This will help you to focus on the problems to be solved, not the projects, which are the solution.
  • Solution implementation teams are teams working on implementing a solution designed by someone else. Problem-solving teams are teams that work to deeply understand the causes of the problem, the context, and the motivation that people have to solve it. In doing so, they are able to implement the best solution for the problem at hand.
  • The top-down trap is the perception of the decision-making process being made by the leaders of the company, with no opportunity for the rest of the employees to participate. This perception is exacerbated when a company faces increasing pressure, such as the COVID-19 crisis.
  • People are solution-oriented, and the greater the pressure, the faster people want solutions to be implemented.
  • To help deal with this situation, use empathy to understand the requestor’s view of implementing the solution and ask him why it is necessary to implement the requested solution.
  • Product heads have the role and responsibility to promote these behavioral changes to help build a more collaborative decision-making process.

In the next chapter, we will understand more about the focus on delivering results.

Digital Product Management Books

Do you work with digital products? Do you want to know more about how to manage a digital product to increase its chances of success? Check out my 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

Release early and often

In the previous chapters we saw my personal leadership principles:

We also saw what corporate culture is, a set of ways to solve problems and react to the situation shared by a group of people working together. And we saw the 5 values ​​needed to create successful digital products:

Product culture

It turns out that these values ​​are necessary, but not sufficient. There is a set of four values ​​that are in fact the core of the entire digital product development team. These are the values ​​that make up the product culture, which is nothing more than the set of behaviors of the digital product development teams that produce the best results. The four values, which will be the subject of this and the following chapters, are:

  • Release early and often
  • Focus on the problem
  • Result delivery
  • Ecosystem mindset

Let’s start with the first one: Early and frequent launch.

The sooner we present the product to our users, the better, as we can receive feedback from real users who will be able to use the product in their own context. There are 3 reasons that justify this need to launch your product or functionality as soon as possible and frequently.

Moment of truth

It doesn’t matter how much research, interviews, and prototypes you do, the moment of truth, that is, the moment when you will know if your product is, in fact, the solution to a problem of a group of people, is when the product is in your customers’ hands, in the context where they need the product.

The longer it takes you to get your product out on the street, the longer it will take to learn from real people if you are on the right track. And if that’s not enough, the more steps you will be taking in the wrong direction.

You will only know if the product you made really solves some people’s problems if they use it. The longer it takes for this to happen, the longer it will take to know whether or not it is the solution to the problem.

And if not, what do you do? Fix, adjust, change! The sooner you know that what you are developing is not on the right track, the better because the less time, energy, and money you will waste going the wrong direction.

Too many features

There is a limit of features that the user can understand. When we add too many features, instead of creating a solution to the customer’s problem, we end up creating a new problem for the customer.

Kathy Sierra, recognized programming and user experience instructor, has created a feature chart that illustrates in a clear and fun way how user satisfaction decreases as we increase the amount of functionality in a product.

Featuritis
User satisfaction curve as a function of the amount of functionality

Return on investment

The longer your product takes to have users and, consequently, customers who will at some point pay for your product, the more you will have to invest out of your own pocket. Below is a typical graph of a product’s return on investment (ROI).

During the period that you are building the product and don’t release it to users, all you will have is cost. That is, you will be in the investment part of the curve. This only changes when you start earning revenue and it is greater than your monthly costs. Then you enter the area described below as monthly profitability. Only after a few months in this area will you have a return on your investment. See how long the road is.

Return on investment

Now take a look in the graph below, how a 3-month delay in obtaining revenue can delay the return on investment by 6 months. Are these 3 months of delay in earning revenue worth it? What will you do in those 3 months really make up for 6 months of delayed return on investment?

Postponed return on investment

On the other hand, see what you get if you can accelerate the development of your product and launch it 3 months ahead of schedule. You get 6 months of return on investment! And the explanation for this is not just because you get to the revenue early, it’s because you spent less to be able to launch the product faster. See the chart below.

Antecipated return on investment

If you are not ashamed of your first version, you took too long to launch

LinkedIn founder Reid Hoffman once said that:

“If you are not ashamed of the first version of your product, you took too long to launch”.

To illustrate this phrase, which in a way summarizes the value of release early and often, I decided to take screenshots of the first version of some well-known services.

Facebook 2005
Facebook 2005
Google 1998
Linkedin 2005
Twitter 2006
Locaweb 2002
Conta Azul 2011
Agil ERP (Conta Azul) 2008
Gympass 2014
Lopes 1998

MMF – Minimal Marketable Feature

Minimal Marketable Feature or MMF comes from a 2003 book called Software by Numbers, by Mark Denne and Dr. Jane Cleland-Huang. In this book, they introduce the concept of:

Incremental Funding Methodology (IFM), an ROI-based approach (Return on Investment) for software development in which the software is developed and delivered in carefully prioritized blocks of functionality valued by the customer. These blocks are known as Minimum Marketable Features – MMFs.

It is a concept prior to that of MVP, which has the advantage of this mentality of implementing the minimum necessary for each feature of the product. The basic difference between MVP and MMF is that, while MVP talks about a minimum viable product, that is, it needs a complete product, even if minimal, in order to be presented to possible users, MMF brings the minimal concept down to the level of each feature.

To illustrate MMF, they used a very simple example: imagine that you have to build an internet banking system on the web. There are many features and it can take many months or even years for this product to be delivered with all “mandatory” minimal set of features. When thinking in terms of MMF, we should look at those “mandatory” features and find out if we can launch them independently, that is, if a particular feature, if launched independently, would bring some value to the customer. In an internet banking system, we could choose to release it only with an account statement and no other resources. This would be a very simple internet banking system, but if launched as soon as it is ready, and not after some other features are also ready, it will bring value to the customer sooner. And whenever you deliver value to the customer, you also deliver value to your company. In addition to the satisfied customer, in this example you have probably reduced the cost that your company has in serving these customers, because if users do not obtain their account statements over the internet, they will certainly use another way of obtaining this information and probably this other way is not as economical as internet access, like going to an agency or an ATM.

Minimum marketable functionality (MMF) is minimal, because if it were smaller it would not be marketable. And an MMF is marketable because, when launched as part of a product, people use (or buy) the functionality.

The next time you are planning a new product or feature set for an existing product, try to think in terms of MMF. It can bring a lot of value to you, your customers and your company.

Summing up

  • There is a set of four values ​​that are in fact the core of every digital product development team. These are the values ​​that make up the product culture, which is nothing more than the set of behaviors of the digital product development teams that produce the best results.
  • The three reasons for you to launch your product soon are that (i) this is the moment of truth, (ii) so you avoid the excess of features and (iii) accelerate the return of the investment.
  • If you are not ashamed of your first version, it took too long to launch.
  • Minimal Marketable Feature or MMF is a concept prior to that of MVP, which has the advantage of bringing this mentality of implementing the minimum necessary for each product functionality.

In the next chapter we will see the importance of focusing on understanding the problem to be solved before thinking about solutions.

Missing something?

So, did you miss something in this chapter? What else would you like me to cover?

Digital Product Management Books

Do you work with digital products? Do you want to know more about how to manage a digital product to increase its chances of success? 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 leading digital products

Diversity, the basis of the best products

I have seen demonstrations of diversity with increasing frequency. I’m not much into watching TV, but one day in 2017 I ended up watching a little bit of TV Globo, the biggest Brazilian TV network. I watched the end of Jornal Nacional and the beginning of the soap opera. In Jornal Nacional, I saw a report about PUC in São Paulo opening unisex bathrooms – remembering that PUC is Pontifical Catholic University, a university linked to the Catholic religion. Then, in the soap opera, a character was telling her parents and family that she was born in the wrong body, that he was a man who had been born in a woman’s body, that is, that he was transgender. Then, during the break, came the Globo campaign entitled “Everything starts with respect” about respecting gender identity.

That’s really good! Accepting and respecting differences is the basis for evolving as a society and building an ever better future for us, for our children and for all of humanity.

When respect and the ability to accept diversity are lacking, very bad situations can happen, for example, of parents rejecting their own child. I was very impressed when I read the report by Daniela Andrade, a senior consultant at ThoughtWorks, where she says:

“As I was expelled from my parents’ house, for being transsexual – and here I say that the first great violence that we suffer is at home – for many years I have no relatives to count on in times of need, everyone turned their backs on me.”

How is it possible for a parent to reject his own daughter? I am a father and I know how the love of a parent is something very intense, capable of overcoming any problem so that we can always help and support our children. I was talking the other day with my wife about this story and about the difficulty people have in accepting differences, to the point of rejecting their own children. It was at that moment that my wife said a phrase that marked me. She said that ultimately, everyone is different. Transgender, cisgender, heterosexual, homosexual, bisexual, asexual, black, white, yellow, young, adult, middle age, senior citizen, brazilian, canadian, french, vietnamese, fluminense, paulista, carioca, belo-horizontino, runner, cyclist, swimmer, engineer, architect, lawyer, who likes pop, rock, jazz, classical and so on. Even identical twins are different.

If all people are different, accepting and respecting differences is not only desirable, it is necessary and mandatory so that we can live in a society in a more harmonious and sustainable way. These are values ​​that must be taught to all people from birth.

And what does diversity have to do with digital product management?

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

  • Diversity brings new points of view. Having a more diverse product development team brings new points of view and new ways of thinking, which will help to develop a better product. It is no wonder that the product development team is comprised of software engineers, user experience designers, and product managers. Each person has different views of what a good product is and these differences, when worked well by the team, are what help to create a better product.
  • Just as the group of customers using your software is diverse, so should your team. Usually, software product development teams are mostly male, but the population of any country is more diverse. Both at Conta Azul and Locaweb, more than 88% of the team was composed of men. But these teams make products that will be used by the Brazilian population, which is made up of 48.2% men and 51.8% women according to IBGE (Brazilian Institute of Geography and Statistics). It is also worth remembering that the division between “men” and “women” is simplistic and that gender diversity is non-binary, that is, there are other gender identities besides female and male.

That is why it is so important to reflect and talk about diversity. Only then you will be able to think about issues so essential to the success of your product. How to improve the diversity of your product development team? How to foster discussions that bring different points of view and help to see your product and the problems it helps solve from new angles?

In all the teams that I led, I brought this topic to be discussed. Together we thought about how we could improve this diversity. An interesting example of the result of this work over 12 months was what we were able to do at Gympass, with an increase of 5 percentage points.

Gympass product development team in September 2018
Gympass product development team in August 2019
Evolution of the diversity of the Gympass product development team

At Conta Azul, we achieved something similar between 2016 and 2018 with an increase of 6.1 percentage points.

Conta Azul’s product development team in 2016
Conta Azul’s product development team in 2018
Evolution of the diversity of the product development team of Conta Azul

Diversity of perspectives

The product development team is comprised of software engineers, user experience designers and product managers. Each has a different perspective of what a good product is and these differences are what help to create a better product, when the differences are well resolved by the team.

Some time ago, I heard the following phrase:

The fact that two people disagree does not necessarily mean that one of them is wrong.

It really got me thinking about the diversity of perspectives. This has to do with empathy, one of the 7 essential characteristics of a product manager. Empathy is someone’s ability to step in someone else’s shoes to understand their aspirations, motivations, needs, and problems. What is her context? How does she see and hear things? What makes her understand things from this perspective?

There is a great tool called the empathy map, which aims to help teams gain a deeper view of their customers.

Empathy map (adapted from this source)

People have different backgrounds, different stories, different knowledge. We must recognize and respect these differences and understand that sometimes we will not reach an agreement, but that’s okay, as long as we respect each other’s perspective. Perhaps we can create a third perspective from the two different ones. Perhaps we can decide to try one, or both, and see and compare the results.

As long as there is respect and empathy, diversity brings many good results for everyone.

Summing up

  • There are two main reasons that motivate the construction of different digital product development teams. The first is that diversity brings new points of view. The second reason is that just as the group of customers using your product is diverse, so should your product development team.
  • People have different backgrounds, different stories, different knowledge. We must recognize and respect these differences and understand that sometimes we will not reach an agreement, but that’s okay, as long as we respect each other’s perspective.
  • It is in our hands to make the digital product development environment more inclusive. The way for this to happen is to bring up the topic and make it part of the conversations.

With this chapter, we finish to see what culture is and what, in my opinion, are the 5 main values ​​that the whole company must have to develop successful products:

  • Don’t waste time looking for culprits, focus on learning.
  • Don’t compare work situations with war, nobody wants to kill anyone.
  • Profit and revenue are a consequence, should not be the main focus.
  • Transparency, the foundation of a high-performance team.
  • Diversity, the basis of the best products.

In the next chapters, we will see four additional values ​​that, based on my experience, are the heart of digital product culture.

Missing something?

So, did you miss something in this chapter? What else would you like me to cover?

Digital Product Management Books

Do you work with digital products? Do you want to know more about how to manage a digital product to increase its chances of success? 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 leading digital products

Transparency, the foundation of a high-performance team

In the chapter on “Leadership tips for a product manager” in my book Product management: How to increase your software’s chances of success I talk about two leadership tips that a product manager, or any leader, should use to help his team perform better:

  • Explain the context: In order to have a more motivated and engaged team, it is important for people to know why they are doing something. Establishing the context helps a lot in the engagement of those involved with the product. They will understand its importance both for the company – which owns the product – and for its users.
  • Removing impediments: this is essential for people on the team to develop the product. This is important in order to have that delicious feeling of progress, that we are doing something, building something.

In order to explain the context, it is essential to be transparent, explain the company numbers, explain the motivations behind each decision, add the team to the decision process. I always try to at the team in the decisions and, in order to do this, it is very important to be transparent about the context in which the decision will be made.

One example I like to give is team structure management, which I will talk about in more detail in the part about Tools. To define and evolve the team structure, I usually do this together with the leaders of my team. We meet periodically – monthly or more frequently, if necessary – to assess the team structure, whether we need to bring more people to the team, and whether we have the budget to bring them in. This kind of conversation can only be done if I clearly show what budget is available. In other words, transparency is required.

Transparency in the management of companies seems modern, but it has existed for some decades. I will tell you about two interesting cases from the 1980s, one at an American company Springfield ReManufacturing Corp (SRC), and the other at a Brazilian company called Semco, both industries. Therefore, the vanguard of participatory management.

Open book management

Just as there is the concept of open source for software development and distribution in conjunction with its source code, there is a concept in administration called open-book management. This concept was created by Jack Stack, who wrote the book The Great Game of Business: The Only Sensible Way to Run a Company on how he applied this concept at Springfield ReManufacturing Corp (SRC), an equipment manufacturer in Springfield, Missouri.

The concept is simple. The company’s financial reports must be open to all employees so that they serve as input for more conscious decision-making in their daily lives. The basic rules are:

  • Give employees the training they need to understand financial information;
  • Give employees all financial information;
  • Give employees responsibility for the numbers under their control;
  • Give employees financial participation in the company’s results.

Obviously you can’t practice open-book management overnight, but this concept makes a lot of sense for any company. In its simplest form, it is a way of running a company that makes everyone focus on helping the business succeed. The goals and responsibilities of employees are directly linked to the company’s success. Jack Stack teaches all employees what is critical to success and how they can make a difference, both individually and as part of a team. Employees know and understand how each one contributes to the company’s financial performance, in order to truly understand the functioning of the business.

SRC was created in 1983 when 13 International Harvester employees bought a portion of that company that rebuilt truck engines, with $ 100,000 of its own money and $ 8.9 million in loans, with the aim of saving 119 jobs. The stock price in 1983 was $ 0.10 and increased in 1988 to $ 13 per share. In 2015, the share was worth more than $ 199.

Clóvis Bojikian, former director of HR at Semco, on how to implement organizational democracy

In August 2008, I had the opportunity to meet and talk to Clóvis Bojikian, HR director at Semco since the early 1980s. He worked with Ricardo Semler to implement the participatory management structure that made Semco one of the largest Brazilian companies success in the world.

I will briefly tell you what Clóvis said:

Defining the context – Semco

Clóvis started by telling us a little about Semco, a successful company for 25 years. Its main product was marine hydraulic pumps. The main concern was the diversification of the product portfolio since the shipbuilding industry was struggling. Diversification was being done through:

  • new licenses: to produce and sell other products such as mixers and agitators;
  • acquisition of Brazilian companies that were operated by multinationals: refrigerators and cleaning machines are examples;
  • joint ventures: this is how Semco entered the service business. Industrial maintenance, building conservation, inventories are some examples.

With this diversification, in 20 years, the company has grown from 300 to 4,000 employees.

Define context – Clóvis Bojikian

Clóvis graduated in pedagogy. Some time later, he studied business administration. He first worked as director of the “Colégio da Aplicaçãona USP”, a very famous experimental school in the 1960s where new teaching methods were tried, one of the most advanced schools of his time. He left due to some pressure during the military dictatorship that started in 1964. Then he joined Ford, at the time with 4,000 employees, as an HR manager. Ford was acquiring Willys, a car manufacturer with 16,000 employees. There was little freedom for the HR professional to work (“on a winning team nobody wants to make changes”), so he decided to leave and join KSB Hydraulic Pumps, where he could try out some ideas he had. But due to a CEO change, freedom has decreased. At that time, Clóvis went to talk to Ricardo Semler, it was “many hours of conversation”, as Clóvis pointed out. Ricardo was only 22 at the time and had just assumed the presidency of Semco. He was looking for an HR professional who could help him implement the participatory management concepts he was thinking about. Clóvis, 48, loved this conversation and the synergy with Ricardo and decided to assume the responsibility of managing Semco’s HR.

The roots of participatory management

Semco is a factory and, like any other factory, workers did not like to go to work. Every week they counted the hours until the next weekend. That was Clóvis’ main challenge: “How do we motivate people?” Some findings from Clovis:

  • Nobody motivates anyone.
  • Motivation comes from the person.
  • We need to create conditions for people to feel motivated.
  • The people who have shown the most interest in the job are those who “are in charge”.

And his conclusion, based on these findings, was that:

The most motivated people are the ones who participate the most.

This is easy to understand. People who are “in charge” are the people who participate most in business by making decisions and following the results of their decisions. More participation means more interest and more motivation.

Exercising participation

To exercise participation, Clóvis recommends starting with simple situations that are not essential to the business. He gave two examples from Semco:

Employees’ restaurant: employees usually complained about the restaurant to HR personnel. This complaint was documented and analyzed by HR, but action was not always taken. One day, HR decided to return the complaint with a question: “What would you do to change that?” The claimants were dazzled and, on the recommendation of HR personnel, formed a committee to study what could be done better. The committee ended up having very good ideas and returned to the HR staff, who asked: “Did you talk to the restaurant staff about your suggestions?” They went to the restaurant, discussed the suggestions, and again went back to the HR people, who just said, “Okay, go ahead and implement your suggestions”. Since then, the restaurant has been managed by the restaurant itself, with support from the staff committee, without interference from HR personnel.

Employee uniform: the inventory of employee uniforms was running low and a new purchase was needed. Instead of just placing an order with the supplier of more uniforms, they decided to make an election with the employees to decide the color of the uniform. Remember, we are talking about the 1980s, elections were not very common at that time in Brazil. Some directors did not like the idea of ​​the election because it would take time and probably be a mess, but the fact that democracy was being exercised in a situation unrelated to the main business started the experiment. Two colors had many votes, and the officials themselves proposed to hold a second election, using only these two colors. Finally, one was chosen.

Traci Fenton of WorldBlu, an organization that fosters participatory management, once remarked that this is the concept of leadership distribution, distribution of decision making in a way that makes sense. This shared decision-making process can be slower. But the execution is much faster. And the reason for that is that people participated in the decision. They have ownership in that decision. They want to see success. And that’s what makes execution so much faster. And this is where most companies fail to execute.

The next step – closer to core

Some time later, employees began to define their own production goals, which are usually higher than those previously defined by executives.

This shows how, when we start exercising participatory decision-making with issues unrelated to the core business, it is easy and natural to start moving towards decisions closer to the core of the business.

In Brazil, there are holidays on Tuesdays, Wednesdays, and Thursdays that people like to connect at the weekend to have a longer holiday. The famous “holiday amendment”. It is usually the company’s decision to define who will amend the holiday and who will work on that holiday to offset an amendment from a previous holiday. After the experience of the previous participatory decision-making process, the employees themselves started to decide and control their holiday amendments.

The next step at Semco was the design of the new roles, responsibilities, and compensation plan. It was written entirely by employees with the facilitation and help of HR personnel. When the plan was finally implemented, not only did everyone know the wages of others, but everyone understood why those wages were that way and were in full agreement with that.

Another interesting example of participatory decision-making was the hiring of a new manager. Instead of being interviewed only by HR personnel and the director, the manager was also interviewed by other managers and the team he would lead. The chosen manager had a great start, as he was known not only to his director but also to all the people he would work with. Semco also conducted 360º assessments for employees to analyze their leaders.

To enable employees to understand more of the entire business, they decided to move from the assembly lines to small cells responsible for the entire part. At that point, Semco considered that it had a participatory management structure and decided to move on to the next step.

The final step – a slice of the results

And Semco was ready for the final step, profit sharing. Semco’s owners decided to give twenty-one percent of the profit to employees and everything else was decided in a participatory manner. Employees created a set of principles. One of the basic principles goes something like this: “It is not enough to be transparent, you need to educate”. The idea is that not only are all company numbers open to all employees, but all employees must be trained to be able to read those numbers. The income statement, P&L and cash flow require some knowledge to be read and understood. This is the basis of the open-book management that I mentioned earlier.

Every month they hold a meeting at Semco to discuss the results and some very interesting situations happened during these meetings. One day, an employee questioned why executives always had to stay in five-star hotels. Wouldn’t it be possible to stay in four-star hotels from time to time? In another monthly report review, another employee noted that Semco spent money painting the factory in a month when employees had some free time and they could have painted the factory themselves.

At that point, Semco implemented flexible work schedules and workplaces, even allowing work to be done at home. I remember again that this happened in the 1980s, more than 30 years ago. Since everyone has an interest in the company’s success, it is possible to implement this policy. Of course, it should be adopted where it makes sense. For example, it doesn’t make sense for a receptionist to work from home. But if there are two receptionists to cover a certain period of time, they can and should decide with each other when each should be present.

Participatory management in a crisis

At one point, Clóvis told about a crisis at Semco, in the years of President Collor (1990 – 92), when the market was abruptly opened to foreign companies. This impacted Semco and forced them to do a downsize, which is always painful. Clóvis discussed with employees how they wanted to do the downsize and the employees said they would provide a list of people who should not be fired either for age or personal reasons and told managers that, by preserving the people on that list, managers could select who should be waived on the basis of technical criteria. Two things we can see in this episode:

  • Even in a crisis, there is no need to abandon management innovations, such as participatory management. It is a good test for innovation in management, to see if it is capable of dealing with the crisis in question. In this case, participatory management was able to face the need for layoffs due to a market crisis.
  • There are many numbers between 0 and 1, that is, it is not a matter of delegation or non-delegation. There are intermediate options, there are decisions that workers are willing to face and others that they do not want to face, and each problem will require a different combination.

Concluding the conversation

At the end of the conversation, Clóvis commented that it takes courage to implement participatory management in a company. Mistakes will happen and we must learn from them, but the end result, a company full of employees happy to go to work every day, is worth all the risks.

I asked him to tell us about a mistake or a time when he thought that perhaps this whole process of participatory decision-making might not be a good idea.

He told us a very interesting story about the payroll time clock system. All employees had to check in on arrival at work, check out and check in during lunch and check out again at the end of the working day. But it was a control of what is regular, and what a company really needs to know is what is irregular (overtime, delays, absences). HR opted to change the time clock system so that the employee only reports overtime, delays, and absences. Most importantly, the employee should report directly to the system. She didn’t need to explain anything to the boss. In the first month, everything went well, but in the second month there were frauds, people did not report irregularities in working hours correctly. They were taking advantage that no one was checking the information. Very concerned, HR personnel discussed the matter with a group of employees in charge of this new system. The answer was, “Leave it to us!” After this conversation, the system worked very well with no reported or perceived fraud. Clóvis commented that the collaborators realized that “the more freedom we have, the more responsible we have to be” and acted accordingly, to maintain their freedom.

My view on the importance of transparency in leadership

Without transparency it is not possible to define the context. In my experiences, I have always sought to increase the transparency of information about the company (how are the numbers, what are the processes) and the participation of people from my teams in the decision-making process.

When seeking to increase the transparency of information about the company, helping people to understand the numbers as well as the company’s processes, I want to give the team all the necessary information so that they can know the context where they are inserted and thus understand the motivation and the impact of your work. It is very difficult for someone to do quality work without being clear about why that work needs to be done and what impact it will have on the company, its employees, and its customers.

When I seek to increase the participation of people on my teams in the decision-making process, I do so for two reasons. First, I believe that everyone has the right to make decisions about their own work, which is why the transparency of information about the company is so important. Without this information, it is difficult for anyone to make good decisions. The second reason is that when people are involved in the decision-making process, their commitment to the result is much greater. Consequently, the chances of getting good results increase considerably when people participate in the decision-making process.

Summing up

  • Every leader, to help her team perform better, needs to explain the context and remove impediments.
  • In order to explain the context, it is essential to be transparent, explain the company numbers, explain the motivations behind each decision, add the team to the decision process.
  • Transparency in the management of companies seems modern, but it has existed for some decades. Two interesting examples come from the 1980s. One at an American company called Springfield ReManufacturing Corp (SRC), which created the concept of open-book management. The other is a Brazilian company called Semco, by Ricardo Semler, where Clóvis Bojikian, its HR director, implemented participatory management. Both are from the 1980s and are industries, that is, the vanguard of participatory management.
  • With transparency, it is possible to give people the necessary information so that they understand the context and motivation of the work they are doing and are able to make better decisions about that work.

In the next chapter, we will understand why diversity is so important for the success of the product development team.

Missing something?

So, did you miss something in this chapter? What else would you like me to cover?

Digital Product Management Books

Do you work with digital products? Do you want to know more about how to manage a digital product to increase its chances of success? 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 leading digital products