Diversidade, a base dos melhores produtos

Tenho visto com cada vez mais frequência manifestações sobre diversidade. Não sou muito de assistir TV, mas certo dia em 2017 acabei vendo um pouco de TV Globo. Peguei o final do Jornal Nacional e o início da novela. No Jornal Nacional, vi uma matéria sobre a PUC de São Paulo inaugurando banheiros unissex – lembrando que PUC é Pontifícia Universidade Católica, uma universidade ligada à religião Católica. Em seguida, na novela apareceu uma personagem que estava contando para os pais e familiares que ela nasceu no corpo errado, que era um homem que havia nascido em um corpo de mulher, ou seja, que ele era transgênero. Em seguida, durante o intervalo, veio a campanha da Globo intitulada “Tudo começa pelo respeito” sobre respeito à identidade de gênero.

Isso é muito bom! Aceitar e respeitar as diferenças é a base para evoluirmos como sociedade e construirmos um futuro cada vez melhor para nós, para nossos filhos e para toda a humanidade.

Quando faltam o respeito e a capacidade de aceitar a diversidade, podem acontecer situações muito ruins, por exemplo, de pais rejeitando o próprio filho. Fiquei bastante impressionado quando li o relato da Daniela Andrade, consultora sênior da ThoughtWorks, onde ela conta que:

“Como fui expulsa da casa dos meus pais, por ser transexual —  e aqui eu digo que a primeira grande violência que sofremos é dentro de casa  —  há muitos anos não tenho parentes com quem contar em momentos de necessidade, todos deram as costas para mim.”

Como é possível um pai rejeitar a própria filha? Sou pai e sei como o amor de pai é algo muito intenso, capaz de passar por cima de qualquer problema para podermos sempre ajudar e suportar nossos filhos. Estava conversando outro dia com minha esposa sobre esse relato e sobre a dificuldade das pessoas em aceitarem as diferenças, ao ponto de rejeitarem seus próprios filhos. Foi nesse momento que minha esposa disse uma frase que me marcou. Ela disse que, em última instância, todas as pessoas são diferentes. Transgênero, cisgênero, heterossexual, homossexual, bissexual, assexual, negro, branco, amarelo, jovem, adulto, meia-idade, terceira idade, brasileiro, canadense, francês, vietnamita, fluminense, mineiro, paulista, carioca, belo-horizontino, corredor, ciclista, nadador, engenheiro, arquiteto, advogado, quem gosta de música pop, rock, jazz, clássico e assim por diante. Mesmo gêmeos idênticos são diferentes.

Se todas as pessoas são diferentes, aceitar e respeitar as diferenças não é só desejável, é necessário e obrigatório para que possamos viver em sociedade de uma forma mais harmônica e sustentável. São valores que devem ser ensinados para todas as pessoas desde o berço.

E o que diversidade tem a ver com gestão de produtos digitais?

Além da importância de aceitar e respeitar as diferenças para ajudar a criar uma sociedade mais harmônica e sustentável, a diversidade vai ajudar a criar produtos digitais cada vez melhores por dois motivos:

  • Diversidade traz novos pontos de vista. Ter um time de desenvolvimento de produtos mais diverso traz novos pontos de vista e novas maneiras de pensar, o que ajudará a desenvolver um produto melhor. Não é à toa que o time de desenvolvimento de produtos é composto de engenheiros de software, designers de experiência do usuário e gestores de produto. Cada pessoa tem visões diferentes do que é um bom produto e essas diferenças, quando bem trabalhadas pelo time, é o que ajuda a criar um produto melhor.
  • Da mesma forma que o grupo de clientes que usa o seu software é diverso, seu time também deveria ser. Normalmente os times de desenvolvimento de produto de software são compostos em sua maioria por homens, só que a população do Brasil é mais diversa. Tanto na Conta Azul como na Locaweb, mais de 88% do time é composto de homens. Só que esses times fazem produtos que serão usados pela população brasileira, que é composta por 48,2% de homens e 51,8% de mulheres segundo o IBGE (Instituto Brasileiro de Geografia e Estatística). Vale lembrar ainda que a divisão “homens” e “mulheres” é simplista e que a diversidade de gênero é não binária, ou seja, há outras identidades de gênero além de feminino e masculino.

Por isso é tão importante refletir e conversar sobre o assunto diversidade. Só assim você poderá pensar em questões tão essenciais para o sucesso do seu produto. Como melhorar a diversidade do seu time de desenvolvimento de produto? Como fomentar discussões que trazem diferentes pontos de vista e ajudam a enxergar sob novos ângulos o seu produto e os problemas que ele ajuda a resolver?

Em todos os times que liderei eu trouxe esse tema para ser discutido. Juntos pensamos em como poderíamos melhorar essa diversidade. Um exemplo interessante do resultado desse trabalho ao longo de 12 meses foi o que conseguimos fazer no Gympass, com um aumento de 5 pontos percentuais.

Time de desenvolvimento de produto do Gympass em setembro de 2018
Time de desenvolvimento de produto do Gympass em agosto de 2019
Evolução da diversidade do time de desenvolvimento de produto do Gympass

Na Conta Azul conseguimos algo similar entre 2016 e 2018 com um aumento de 6,1 pontos percentuais.

Time de desenvolvimento de produto da Conta Azul em 2016
Time de desenvolvimento de produto da Conta Azul em 2018
Evolução da diversidade do time de desenvolvimento de produto da Conta Azul

Diversidade de perspectivas

A equipe de desenvolvimento de produto é composta por engenheiras de software, designers de experiência do usuário e gestoras de produto. Cada uma tem uma perspectiva diferente do que é um bom produto e essas diferenças são o que ajudam a criar um produto melhor, quando as diferenças são bem resolvidas pela equipe.

Algum tempo atrás, ouvi a seguinte frase:

O fato de duas pessoas discordarem não significa necessariamente que uma delas esteja errada.

Isso realmente me fez pensar na diversidade de perspectivas. Isso tem a ver com empatia, uma das 7 características essenciais de um gestor de produto. Empatia é a habilidade de alguém de pisar no lugar de outra pessoa para entender suas aspirações, motivações, necessidades e problemas. Qual é o seu contexto? Como ela vê e ouve as coisas? O que a faz entender as coisas nessa perspectiva?

Existe uma ótima ferramenta chamada mapa de empatia, que tem o objetivo de ajudar as equipes a obter uma visão mais profunda de seus clientes.

Mapa de empatia

As pessoas têm diferentes origens, diferentes histórias, diferentes conhecimentos. Devemos reconhecer e respeitar essas diferenças e entender que às vezes não chegaremos a um acordo, mas tudo bem, desde que respeitemos a perspectiva uns dos outros. Talvez possamos criar uma terceira perspectiva a partir das duas diferentes. Talvez possamos decidir experimentar uma delas, ou ambas, e ver e comparar os resultados.

Desde que haja respeito e empatia, a diversidade traz muitos bons resultados para todos.

Resumindo

  • Existem duas razões principais que motivam a construção de times de desenvolvimento de produtos digitais diversos. A primeira é que a diversidade traz novos pontos de vista. A segunda razão é que da mesma forma como o grupo de clientes que usa seu produto é diversa, sua equipe de desenvolvimento de produto também deve ser.
  • As pessoas têm diferentes origens, diferentes histórias, diferentes conhecimentos. Devemos reconhecer e respeitar essas diferenças e entender que às vezes não chegaremos a um acordo, mas tudo bem, desde que respeitemos a perspectiva uns dos outros.
  • Está em nossas mãos tornar o ambiente de desenvolvimento de produtos digitais mais inclusivo. O caminho para isso acontecer é trazer o tema à tona e torná-lo parte das conversas.

Com este capítulo, terminamos de ver o que é cultura e quais são, na minha opinião, os 5 principais valores que toda a empresa deve ter para desenvolver produtos de sucesso:

  • Não desperdice tempo buscando culpados, foque nos aprendizados.
  • Não compare situações de trabalho com guerra, ninguém quer matar ninguém.
  • Lucro e receita são consequência, não deve ser o foco principal.
  • Transparência, a fundação de um time de alta performance.
  • Diversidade, a base dos melhores produtos.

Nos próximos capítulos vamos ver mais dois valores que, com base em minha experiência, são o coração de uma cultura de produto digital.

Liderança de produtos digitais

Este artigo faz parte do meu mais novo livro, Liderança de produtos digitais: A ciência e a arte da gestão de times de produto, onde falo sobre conceitos, princípios e ferramentas que podem ser úteis para quem é head de produto, para quem quer ser, para quem é liderado por ou para quem tem uma pessoa nesse papel na empresa. Você também pode se interessar pelos meus outros dois livros:

Transparência, a fundação de um time de alta performance

No capítulo sobre “Dicas de liderança para um gestor de produtos” no meu livro Gestão de produtos: Como aumentar as chances de sucesso do seu software falo sobre duas dicas de liderança que um gestor de produtos, ou qualquer líder, deve usar para ajudar seu time a desempenhar melhor:

  • Explicar o contexto: para ter um time mais motivado e engajado, é importante as pessoas saberem por que elas estão fazendo algo. Estabelecer o contexto ajuda muito no engajamento de quem está envolvido com o produto. Eles vão entender a sua importância tanto para a empresa – que é dona do produto – quanto para os seus usuários.
  • Remover impedimentos: é fundamental para que as pessoas do time possam desenvolver o produto. Isso é importante para poder termos aquela gostosa sensação de progresso, de que estamos fazendo algo, construindo algo.

Para podermos explicar o contexto, é fundamental sermos transparentes, explicar os números da empresa, explicar as motivações por trás de cada decisão, incluir o time nas decisões. Eu sempre procuro incluir o time nas decisões e, para poder fazer isso, é muito importante ser transparente sobre o contexto em que a decisão será tomada.

Um exemplo que gosto de dar é a gestão de estrutura de time, sobre a qual vou falar em mais detalhes na parte sobre Ferramentas. Para definir e evoluir a estrutura de time, costumo fazer isso junto com os líderes do meu time. Nós nos reunimos periodicamente – mensalmente ou mais frequente, se necessário – para avaliar a estrutura de time, se estão faltando pessoas e se temos orçamento para trazê-las. Esse tipo de conversa só pode ser feito se eu mostrar claramente qual o orçamento disponível. Ou seja, é preciso ter transparência.

A transparência na gestão das empresas parece algo moderno, mas existe há algumas décadas. Vou contar sobre dois casos interessantes da década de 1980, um em uma empresa americana Springfield ReManufacturing Corp (SRC) e o outro em uma empresa brasileira chamada Semco, ambas indústrias. Portanto, a vanguarda da gestão participativa.

Gestão do livro aberto

Da mesma forma que existe o conceito de open source, ou código aberto, para desenvolvimento e distribuição de software em conjunto com seu código-fonte, existe um conceito em administração chamado de open-book management ou gestão do livro aberto. Esse conceito foi criado por Jack Stack, que escreveu o livro The Great Game of Business: The Only Sensible Way to Run a Company sobre como aplicou esse conceito na Springfield ReManufacturing Corp (SRC), um fabricante de equipamentos em Springfield, Missouri.

O conceito é simples. Os relatórios financeiros da empresa devem ficar abertos para todos os funcionários para que sirvam de insumo para tomadas de decisão mais conscientes em seu dia a dia. As regras básicas são:

  • Dê aos funcionários o treinamento necessário para que eles possam entender as informações financeiras;
  • Dê aos funcionários toda informação financeira;
  • Dê aos funcionários a responsabilidade pelos números que estão sob seu controle;
  • Dê aos funcionários participação financeira nos resultados da empresa.

Obviamente não dá para praticar open-book management de uma hora para outra, mas esse conceito faz bastante sentido para qualquer empresa. Em sua forma mais simples, trata-se de uma forma de administrar uma empresa que faz com que todos se concentrem em ajudar o negócio a ter sucesso. As metas e responsabilidades dos funcionários estão diretamente ligadas ao sucesso da empresa. Jack Stack ensina a todos os funcionários o que é fundamental para o sucesso e como eles podem fazer a diferença, tanto individualmente quanto sendo parte de uma equipe. Os funcionários sabem e compreendem como cada um contribui para o desempenho financeiro da empresa, de forma a entenderem verdadeiramente o funcionamento do negócio.

A SRC foi criada em 1983 quando 13 funcionários da International Harvester compraram uma parte daquela empresa que reconstruía motores de caminhão, com $100.000 de seu próprio dinheiro e $8,9 milhões em empréstimos, com o objetivo de salvar 119 empregos. O preço das ações em 1983 era de $0,10 e aumentou em 1988 para $13 por ação. Em 2015, a ação valia mais de $199.

Clóvis Bojikian, ex-diretor de RH da Semco, sobre como implementar a democracia organizacional

Em agosto de 2008, tive a oportunidade de conhecer e conversar com Clóvis Bojikian, diretor de RH da Semco desde o início dos anos 1980. Ele trabalhou com Ricardo Semler na implementação da estrutura de gestão participativa que fez da Semco uma das empresas brasileiras de maior sucesso no mundo. Vou contar aqui resumidamente o que Clóvis contou:

Definindo o contexto – Semco

Clóvis começou contando um pouco sobre a Semco, uma empresa de sucesso há 25 anos. Seu principal produto eram as bombas hidráulicas navais. A principal preocupação era a diversificação do portfólio de produtos uma vez que a indústria de construção naval estava dificuldades. A diversificação estava sendo feita por meio de:

  • novas licenças: para produzir e comercializar outros produtos como misturadores e agitadores;
  • aquisição de empresas brasileiras que eram operadas por multinacionais: geladeiras e máquinas de limpeza são exemplos;
  • joint ventures: foi assim que a Semco entrou no negócio de serviços. Manutenção industrial, conservação de edifícios, inventários são alguns exemplos.

Com essa diversificação, em 20 anos, a empresa cresceu de 300 para 4.000 funcionários.

DefiniNDO contexto – Clóvis Bojikian

Clóvis graduou-se em pedagogia. Algum tempo depois, ele estudou administração de empresas. Ele trabalhou pela primeira vez como diretor do “Colégio de Aplicação da USP”, uma escola experimental muito famosa nos anos 60 onde novos métodos de ensino foram experimentados, uma das escolas mais avançadas de sua época. Saiu devido a algumas pressões durante a ditadura militar iniciada em 1964. Em seguida, ingressou na Ford, na época com 4.000 funcionários, como gerente de RH. A Ford estava adquirindo a Willys, uma montadora de automóveis com 16.000 funcionários. Havia pouca liberdade para o profissional de RH trabalhar (“em uma equipe vencedora ninguém quer fazer mudanças”), então ele decidiu sair e se juntar a Bombas Hidráulicas KSB, onde pôde experimentar algumas ideias que tinha. Mas devido a uma mudança de CEO, a liberdade diminuiu. Naquela época, Clóvis foi conversar com Ricardo Semler, foram “muitas horas de conversa”, como Clóvis destacou. Ricardo tinha apenas 22 anos na época e acabava de assumir a presidência da Semco. Ele estava procurando um profissional de RH que pudesse ajudá-lo a implementar os conceitos de gestão participativa que ele estava pensando. Clóvis, 48 anos, adorou essa conversa e a sinergia com Ricardo e decidiu assumir a responsabilidade de dirigir o RH da Semco.

As raízes da gestão participativa

A Semco é uma fábrica e, como qualquer outra fábrica, os trabalhadores não gostavam de ir trabalhar. Toda semana eles contavam as horas até o próximo fim de semana. Esse foi o principal desafio de Clóvis: “Como motivamos as pessoas?” Algumas constatações de Clóvis:

  • Ninguém motiva ninguém.
  • A motivação vem da pessoa.
  • Precisamos criar condições para que as pessoas se sintam motivadas.
  • As pessoas que demonstraram mais interesse pelo trabalho são as que “estão no comando”.

E sua conclusão, com base nessas constatações, era de que:

As pessoas mais motivadas são os que mais participam.

É isso é fácil de entender. As pessoas que “estão no comando” são as pessoas que mais participam dos negócios tomando decisões e acompanhando os resultados de suas decisões. Mais participação significa mais interesse e mais motivação.

Exercitando a participação

Para exercer a participação, Clóvis recomenda começar com situações simples e não essenciais ao negócio. Ele deu dois exemplos da Semco:

Restaurante dos funcionários: os funcionários normalmente reclamavam do restaurante para o pessoal de RH. Essa reclamação era documentada e analisada pelo RH, mas nem sempre uma ação era tomada. Um dia, o RH resolveu retribuir a reclamação com uma pergunta: “O que você faria para mudar isso?”. Os reclamantes ficaram deslumbrados e, por recomendação do pessoal de RH, formaram uma comissão para estudar o que poderia ser feito melhor. A comissão acabou tendo ideias muito boas e voltou ao pessoal de RH, que perguntou: “Vocês conversaram com o pessoal do restaurante sobre suas sugestões?”. Eles foram ao restaurante, discutiram as sugestões e novamente voltaram para o pessoal de RH, que apenas disse: “Ok, siga em frente e implemente suas sugestões”. Desde então, o restaurante passou a ser administrado pelo próprio restaurante, com apoio da comissão de funcionários, sem interferência do pessoal de RH.

Uniforme de funcionários: o estoque de uniformes de funcionários estava acabando e uma nova compra se fazia necessária. Em vez de apenas fazer um pedido com o fornecedor de mais uniformes, eles decidiram fazer uma eleição com os funcionários para que decidissem a cor do uniforme. Lembrando, estamos falando da década de 1980, eleições não era algo muito comum nessa época. Alguns diretores não gostaram da ideia da eleição porque levaria tempo e provavelmente seria uma bagunça, mas o fato de que a democracia estava sendo exercida em uma situação não relacionada ao negócio principal deu início ao experimento. Duas cores tiveram muitos votos, e os próprios funcionários propuseram fazer uma segunda eleição, apenas com essas duas cores. Finalmente, uma foi escolhida.

Traci Fenton, da WorldBlu, uma organização que fomenta a gestão participativa, comentou certa vez que esse é o conceito de distribuição de liderança, distribuição de tomada de decisão de uma forma que faça sentido. Esse processo de tomada de decisão compartilhada pode ser mais lento. Mas a execução é muito mais rápida. E a razão disso é que as pessoas participaram da decisão. Elas têm propriedade nessa decisão. Elas querem ver o sucesso. E é isso que torna a execução muito mais rápida. E é aí que a maioria das empresas falha, na execução.

A próxima etapa – mais perto do core

Algum tempo depois, os funcionários passaram a definir suas próprias metas de produção, normalmente superiores às definidas anteriormente pelos executivos.

Isso mostra como, quando começamos a exercer a tomada de decisão participativa com questões não relacionadas ao negócio principal, é fácil e natural começar a nos mover para decisões mais perto do core do negócio.

No Brasil, há feriados às terças, quartas e quintas-feiras que as pessoas gostam de conectar ao fim de semana para terem um feriado mais longo. A famosa “emenda de feriado”. Normalmente é decisão da empresa definir quem vai emendar o feriado e quem vai trabalhar nesse feriado para compensar uma emenda de um feriado anterior. Após a experiência do processo de tomada de decisão participativa anterior, os próprios funcionários passaram a decidir e controlar suas emendas de feriado.

O próximo passo na Semco foi o desenho das novas funções, responsabilidades e plano de remuneração. Foi totalmente escrito pelos funcionários com a facilitação e ajuda do pessoal de RH. Quando o plano foi finalmente implementado, não apenas todos sabiam os salários dos outros, mas todos entenderam por que esses salários eram dessa forma e estavam totalmente de acordo com isso.

Outro exemplo interessante de tomada de decisão participativa foi a contratação de um novo gerente. Em vez de ser entrevistado apenas pelo pessoal de RH e pelo diretor, o gerente também foi entrevistado por outros gerentes e pela equipe que lideraria. O gerente escolhido teve um ótimo começo, pois era conhecido não apenas pelo seu diretor, mas também por todas as pessoas com quem trabalharia. A Semco também fez avaliações 360º para que os funcionários analisassem seus líderes.

Para permitir que os funcionários entendam mais de todo o negócio, eles decidiram mudar das linhas de montagem para pequenas células responsáveis por toda a peça. Nesse ponto, a Semco considerava que tinha uma estrutura de gestão participativa e decidiu passar para a próxima etapa.

A etapa final – uma fatia dos resultados

E a Semco estava pronta para a etapa final, a participação nos lucros. Os donos da Semco decidiram dar vinte e poucos por cento do lucro aos funcionários e todo o resto foi decidido de forma participativa. Os funcionários criaram um conjunto de princípios. Um dos princípios básicos diz mais ou menos assim: “Não basta ser transparente, é preciso educar”. A ideia é que não apenas todos os números da empresa sejam abertos a todos os funcionários, mas todos os funcionários devem ser treinados para serem capazes de ler esses números. A demonstração de resultados, o P&L e o fluxo de caixa requerem alguns conhecimentos para serem lidos e compreendidos. Esta é a base do open book management que comentei anteriormente.

Todos os meses eles fazem uma reunião na Semco para discutir os resultados e algumas situações muito interessantes aconteceram durante essas reuniões. Um dia, um funcionário questionou por que os executivos sempre tinham que se hospedar em hotéis cinco estrelas. Não seria possível se hospedar em hotéis quatro estrelas de vez em quando? Em outra revisão de relatório mensal, outro funcionário notou que a Semco gastou dinheiro pintando a fábrica em um mês em que os funcionários tiveram algum tempo livre e eles próprios poderiam ter pintado a fábrica.

Nesse ponto, a Semco implementou horários e locais de trabalho flexíveis, permitindo até que o trabalho fosse feito em casa. Lembro mais uma vez que isso aconteceu na década de 1980, mais de 30 anos atrás. Uma vez que todos têm interesse no sucesso da empresa, é possível implementar essa política. Claro, deve ser adotada onde fizer sentido. Por exemplo, não faz sentido para um recepcionista trabalhar em casa. Mas se houver dois recepcionistas para cobrir um determinado período de tempo, eles podem e devem decidir entre si quando cada um deve estar presente.

Gestão participativa em uma crise

A certa altura, Clóvis contou sobre uma crise na Semco, nos anos do presidente Collor (1990 – 92), em que o mercado foi abruptamente aberto para empresas estrangeiras. Isso impactou a Semco e os obrigou a fazer um downsize, o que é sempre doloroso. Clóvis discutiu com os funcionários como queriam fazer o downsize e os funcionários disseram que iriam fornecer uma lista de pessoas que não deveriam ser despedidas nem por idade nem por questões pessoais e disseram aos gestores que, preservando as pessoas dessa lista, os gestores poderiam selecionar quem deveria ser dispensado com base em critérios técnicos. Duas coisas que podemos ver neste episódio:

  • Mesmo em uma crise, não há necessidade de abandonar as inovações de gestão, como gestão participativa. É um bom teste para a inovação em gestão, para ver se ela é capaz de lidar com a crise em questão. Nesse caso, a gestão participativa conseguiu fazer frente à necessidade de dispensas por conta de uma crise de mercado.
  • Existem muitos números entre 0 e 1, ou seja, não é uma questão de delegação ou não delegação. Existem opções intermediárias, existem decisões que os trabalhadores estão dispostos a enfrentar e outras que eles não querem enfrentar e cada problema exigirá uma combinação diferente.

Concluindo a conversa

Ao final da conversa, Clóvis comentou que basta coragem para implantar a gestão participativa em uma empresa. Erros vão acontecer e devemos aprender com eles, mas o resultado final, uma empresa cheia de funcionários felizes em ir trabalhar todos os dias, vale todos os riscos.

Pedi a ele que nos contasse sobre um erro ou um momento em que pensaram que talvez todo esse processo de tomada de decisão participativa não pudesse ser uma boa ideia.

Ele nos contou uma história muito interessante sobre o sistema de relógio de ponto da folha de pagamento. Todos os funcionários tinham que fazer check-in na chegada ao trabalho, check-out e check-in durante o almoço e check-out novamente no final do expediente. Mas era um controle do que é regular, e o que uma empresa precisa mesmo saber é o que é irregular (horas extras, atrasos, faltas). O RH optou por alterar o sistema de relógio de ponto para que o funcionário apenas informasse horas extras, atrasos e faltas. E o mais importante, o funcionário deveria informar diretamente no sistema. Ela não precisava explicar nada ao chefe. No primeiro mês tudo correu bem, mas no segundo mês houve fraudes, as pessoas não informavam as irregularidades do horário de trabalho corretamente. Eles estavam aproveitando que ninguém estava verificando as informações. Muito preocupados, o pessoal de RH discutiu o assunto com um grupo de funcionários encarregados desse novo sistema. A resposta foi: “Deixe conosco!” Após essa conversa, o sistema funcionou muito bem sem nenhuma fraude relatada ou percebida. Clóvis comentou que os colaboradores perceberam que “quanto mais liberdade temos, mais responsáveis temos que ser” e agiram de acordo, para manter sua liberdade.

Minha visão sobre a importância da transparência na liderança

Sem transparência não é possível definir o contexto. Em minhas experiências, sempre busquei aumentar a transparência das informações sobre a empresa (como estão os números, quais são os processos) e a participação das pessoas de meus times no processo decisório.

Ao buscar aumentar a transparência das informações sobre a empresa, ajudando as pessoas a entenderem os números bem como os processos da empresa, quero dar ao time todas as informações necessárias para que elas possam conhecer o contexto onde estão inseridas e assim entender a motivação e o impacto de seu trabalho. É muito difícil alguém fazer um trabalho de qualidade sem ter clareza sobre por que aquele trabalho precisa ser feito e qual o impacto que ele terá na empresa, em seus funcionários e seus clientes.

Quando busco aumentar participação das pessoas de meus times no processo decisório, eu o faço por dois motivos. Primeiro, acredito que todas as pessoas têm o direito de tomar decisões sobre seu próprio trabalho, e por isso a transparência das informações sobre a empresa é tão importante. Sem essas informações é difícil para qualquer um tomar boas decisões. A segunda razão é que, quando as pessoas estão envolvidas no processo decisório, seu comprometimento com o resultado é muito maior. Consequentemente, as chances de obter bons resultados aumentam consideravelmente quando as pessoas participam do processo de tomada de decisão.

Resumindo

  • Toda líder, para ajudar seu time a desempenhar melhor, precisa explicar o contexto e remover impedimentos.
  • Para podermos explicar o contexto, é fundamental sermos transparentes, explicar os números da empresa, explicar as motivações por trás de cada decisão, incluir o time nas decisões.
  • A transparência na gestão das empresas parece algo moderno, mas existe há algumas décadas. Dois exemplos interessantes vêm da década de 1980. Um em uma empresa americana chamada Springfield ReManufacturing Corp (SRC), que criou o conceito de gestão do livro aberto. O outro em uma empresa brasileira chamada Semco, do Ricardo Semler, onde Clóvis Bojikian, seu diretor de RH, implementou a gestão participativa. Ambas são da década de 1980 e são indústrias, ou seja, a vanguarda da gestão participativa.
  • Com transparência, é possível dar às pessoas as informações necessárias para que elas entendam o contexto e motivação do trabalho que estão fazendo e consigam tomar melhores decisões sobre esse trabalho.

No próximo capítulo vamos entender por que diversidade é tão importante para o sucesso do time de desenvolvimento de produto.

Liderança de produtos digitais

Este artigo faz parte do meu mais novo livro, Liderança de produtos digitais: A ciência e a arte da gestão de times de produto, onde falo sobre conceitos, princípios e ferramentas que podem ser úteis para quem é head de produto, para quem quer ser, para quem é liderado por ou para quem tem uma pessoa nesse papel na empresa. Você também pode se interessar pelos meus outros dois livros:

Cultura e valores

Após falar dos meus princípios de liderança, vou falar de outro tema fundamental para uma head de produto, cultura organizacional e valores. São 5 os valores que considero críticos para o sucesso do produto:

  • Não desperdice tempo buscando culpados, foque nos aprendizados.
  • Não compare situações de trabalho com guerra, ninguém quer matar ninguém.
  • Lucro e receita são consequência, não devem ser o foco principal.
  • Transparência, a fundação de um time de alta performance.
  • Diversidade, a base dos melhores produtos.

Vamos começar definindo cultura.

O que é cultura?

A palavra cultura vem do latim cultus, que significa “cuidado”, e do francês colere, que significa “cultivar”. Edgar Schein, professor da escola de administração de empresas do MIT, foi uma das primeiras pessoas a falar sobre cultura organizacional nos anos 1970.

Segundo ele, cada empresa tinha sua própria personalidade, e sua própria forma de agir e reagir às situações; forma esta que é passada de funcionário para funcionário desde os fundadores da empresa.

Cultura Organizacional

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

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

A cultura vem dos fundadores da empresa. Os fundadores têm sua própria cultura e é natural que a imprimam na organização que estão criando. Em função disso, é muito comum se pensar que ela é algo que emerge em uma organização. Schein alerta que isso é um engano. Culturas podem e devem ser planejadas e é papel do head de produto ajudar a planejar e promover a cultura da empresa.

Por esse motivo, estou compartilhando estes cinco valores que ao meu ver são críticos para o desenvolvimento de produtos digitais de sucesso.

Não desperdice tempo buscando culpados, foque nos aprendizados.

Quando erros acontecem é comum as pessoas tentarem buscar quem foi o responsável pelo erro. Isso pode acabar gerando uma cultura do medo de errar e, consequentemente, de querer esconder os erros, especialmente se houver alguma punição.

Os times que não só reconhecem seus erros como os usam como fonte de aprendizado e melhoria são os times com melhor performance. No livro The High-Velocity Edge: How Market Leaders Leverage Operational Excellence to Beat the Competition, Steven J. Spear, professor do MIT, explica que um time de alta velocidade tem quatro habilidades:

  • Estar preparado para capturar conhecimento e encontrar problemas em sua operação.
  • Entender e resolver esses problemas para construir novos conhecimentos.
  • Compartilhar o novo conhecimento com toda a organização.
  • Liderar para desenvolver habilidades 1, 2 e 3.

Segundo o prof. Spear, esse é o segredo por trás do sucesso da Toyota por tantos anos. Alcoa é outro bom exemplo. Tinha uma taxa de incidentes de trabalho que girava em torno de 2% ao ano. Em uma equipe de 40 mil funcionários, isso significa 800 funcionários por ano com algum incidente de trabalho, mais de 2 por dia. Para combater esse problema, eles implementaram uma política de tolerância zero a erros. Antes de implementar essa política, os erros eram vistos como parte do trabalho. Agora os funcionários são incentivados a relatar erros de operação em 24 horas, propor soluções em 48 horas e contar a solução encontrada para seus colegas para garantir que o conhecimento se espalhe por toda a organização. Isso fez com que o risco de incidentes caísse de 2% para 0,07% ao ano! Essa redução na taxa de incidentes significava que menos de 30 funcionários por ano tinham algum problema de incidente de trabalho depois que a política de zero tolerância a erro foi implementada e a Alcoa obteve um aumento de produtividade e qualidade semelhante ao da Toyota.

No livro Smarter Faster Better: The Transformative Power of Real Productivity, Charles Duhigg, autor e jornalista premiado com o prêmio Pulitzer, compara a performance de dois times de UTI, um deles que costuma se reunir diariamente para discutir problemas e como evitá-los e o outro que costuma punir funcionários que cometem erros. O time que discute e aprende com os erros tem performance melhor, o que, para um time de UTI, significa menos mortes e mais pacientes recuperados.

Esse tipo de ambiente que aprende com os erros é conhecido como ambiente psicologicamente seguro, ou seja, em que as pessoas do time podem fazer seu trabalho sem medo de consequências negativas. Como head de produto é seu papel criar um ambiente assim para seu time e para toda a empresa.

Não compare situações de trabalho com guerra, ninguém quer matar ninguém.

Vejo com alguma frequência o uso de analogias de guerra no dia a dia das empresas. Vamos derrotar esse competidor. Vamos criar esse war room para tratar desse problema. Isso é uma guerra, temos que vencer nossos inimigos. Existe um livro chamado A arte da guerra, atribuído um general chinês chamado Sun Tzu que viveu entre os anos 550 e 500 a.C., que é considerado um dos 10 livros de negócios mais influentes de todos os tempos. Esse livro tem frases como “Diante de uma larga frente de batalha, procure o ponto mais fraco e, ali, ataque com a sua maior força” e “A suprema arte da guerra é derrotar o inimigo sem lutar”.

Apesar de eu entender a imagem que se quer criar fazendo essa comparação de guerra com negócios, para gerar uma motivação maior no time de um inimigo comum a ser derrotado, fico profundamente incomodado com essa analogia. Guerra é algo muito feio e triste. Experimente escrever guerra no Google e clique na opção “Imagens”. Você verá muitas fotos de dor e de sofrimento. Em uma guerra, para alguém ganhar, alguém precisa perder.

No meu entendimento, negócios é oposto disso. Os negócios mais prósperos são aqueles que impactam positivamente todos à sua volta, funcionários, clientes, fornecedores, sociedade e até mesmo os competidores. Um bom competidor é aquele que o motiva a melhorar. Os competidores tiram as empresas da zona de conforto. Se não fossem por eles, as empresas evoluiriam de forma bem mais lenta. Além disso, competidores podem e devem se juntar em associações para irem atrás de objetivos comuns.

Lucro e receita são consequência, não deve ser o foco principal.

Sim, o objetivo de toda empresa é crescer e dar lucro, mas esse não deve ser o foco. O propósito principal de uma empresa deve ser ajudar de alguma forma seus clientes, e a receita e o lucro devem ser usados como métricas que indicam se o propósito está sendo cumprido. Mas não devem ser as únicas métricas, uma vez que sempre há o risco de se obter a má receita, o que pode acontecer quando mantemos o foco principal em ter mais receita.

Imagine uma situação onde você é assinante de um serviço com pagamento mensal e, por algum motivo, você precise cancelar sua assinatura. Ao tentar fazer isso, descobre que o processo de cancelamento é supercomplicado. Isso certamente vai deixá-la insatisfeita. A mesma coisa acontece quando você pega uma água no frigobar de um quarto de hotel e descobre que a garrafa de água custa 3 vezes mais do que em um supermercado. São situações que até geram receita para a empresa, mas é uma má receita, que deixa os clientes insatisfeitos e que provavelmente fará esses clientes não retornarem e até mesmo falar mal de sua empresa quando tiverem a oportunidade.

Por este motivo gosto de fazer uma analogia entre receita e lucro com comida:

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

Contudo, tanto uma empresa quanto uma pessoa devem estar sempre atentas à qualidade da comida que está ingerindo, para ter certeza de que ela não vai causar nenhum mal à saúde.

Resumindo

  • Cultura é a forma como um grupo de pessoas reage às situações do dia a dia. É papel do head de produto ajudar no desenho e na promoção da cultura da empresa para garantir um ambiente propício para o desenvolvimento de produtos de sucesso.
  • Tem cinco valores que acredito serem essenciais para ajudar a criar uma cultura que propicie o desenvolvimento de produtos de sucesso. Neste capítulo falei de 3 desses valores: não desperdice tempo buscando culpados, foque nos aprendizados. Não compare situações de trabalho com guerra, ninguém quer matar ninguém. Lucro e receita são consequência, não deve ser o foco principal.

No próximo capítulo vamos conversar sobre a importância da transparência na criação de times de alta performance.

Liderança de produtos digitais

Este artigo faz parte do meu mais novo livro, Liderança de produtos digitais: A ciência e a arte da gestão de times de produto, onde falo sobre conceitos, princípios e ferramentas que podem ser úteis para quem é head de produto, para quem quer ser, para quem é liderado por ou para quem tem uma pessoa nesse papel na empresa. Você também pode se interessar pelos meus outros dois livros:

Como e quando delegar

Delegar é o ato de confiar uma tarefa e/ou uma responsabilidade a alguém, normalmente com menos senioridade do que a pessoa que está executando o ato de delegar. A liderança é um ato contínuo de delegação de tarefas e de responsabilidades. Parece um ato bastante simples mas tem vários aspectos importantes a serem considerados para aumentar as chances de sucesso.

Jurgen Appelo, autor do já mencionado livro Management 3.0: Leading Agile Developers, Developing Agile Leaders, comenta que delegar não é uma decisão binária em que você delega ou não delega. Existem outros níveis de delegação entre esses dois extremos e cada um desses outros níveis deve ser usado dependendo do contexto, ou seja, do problema a ser resolvido e de quem vai trabalhar nele. Segundo ele, são sete níveis:

  • Dizer: você toma decisões e as anuncia ao seu time. Na verdade, isso não é delegação. (=
  • Vender: você toma decisões, mas tenta “vender” sua ideia para sua equipe.
  • Consultar: você convida seu time para comentar e pondera suas contribuições.
  • Concordar: você convida seu time a participar de uma discussão e a chegar a um consenso como um grupo. Sua voz é igual às outras.
  • Aconselhar: você tenta influenciar o seu time dando-lhes conselhos, mas deixa que eles decidam o que fazer com sua opinião.
  • Perguntar: você deixa o time decidir. E depois você pergunta sobre suas motivações, ou pede que eles o mantenham ativamente informado.
  • Delegar: você deixa inteiramente para o time lidar com o assunto, e você nem mesmo precisa saber quais decisões eles tomam.

Confesso que no meu dia a dia não penso sobre que tipo de delegação estou fazendo em cada situação, é algo mais intuitivo do que pensado, mas é bom conhecer e relembrar essas diferentes formas de delegação. Tenho a impressão que entre “dizer” e “delegar” há mais do que 5 opções. Navegamos entre essas opções de forma fluida de acordo com a senioridade do time, a experiência específica do time com o assunto em questão e o quanto o tema em questão implica em riscos.

O conceito de delegação anda de mãos dadas com o conceito de microgestão:

Microgestão

Microgestão é o estilo de gestão em que o gerente observa ou controla de perto o trabalho de seus subordinados ou funcionários. A microgestão geralmente possui uma conotação negativa.

Fonte: https://pt.wikipedia.org/wiki/Microger%C3%AAncia

A microgestão mostra a incapacidade de delegação do líder. Normalmente há duas razões para um líder microgerenciar seu time:

  • Insegurança: o líder é inseguro, preocupado em fazer tudo certo, por isso ele quer acompanhar cada detalhe de tudo o que está sendo feito. Em alguns (muitos) casos, esse líder fará o trabalho de uma pessoa de seu time para garantir que esteja sendo feito “do jeito certo”. Esse tipo de líder costuma criar muitas regras e procedimentos para garantir que as coisas estejam sendo feitas do jeito que ele entende como certo.
  • Personalidade: é da personalidade do líder ter prazer em ver as pessoas sofrendo sob pressão. Esse líder tende a ser abusivo no dia a dia com a equipe. Ele não fará o trabalho de ninguém, mas acompanhará de perto todos os detalhes para vê-los desconfortáveis sob esse constante escrutínio.

O mais comum é encontrar líderes com insegurança, normalmente pessoas que estão liderando pela primeira vez, mas que eventualmente acabam entendendo seu papel e exercendo a delegação. Já líderes que microgerenciam devido à sua personalidade são mais raros e dificilmente vão mudar.

Pessoas que estão em um time que está sendo microgerenciado tendem a rapidamente se desengajar. Uma vez que estão fazendo as coisas do jeito do gestor, não se sentem responsáveis pelo resultado obtido, seja o resultado bom ou ruim. Se o resultado for bom, o líder provavelmente vai atribuir o sucesso ao seu jeito de fazer as coisas. Se der errado, a pessoa que fez o trabalho não se sentirá responsável, pois “apenas seguiu ordens”.

Maneiras de fazer

Uma das maiores barreiras para a delegação é a certeza que o líder tem de que seu jeito de fazer as coisas é o correto. Quando ele era um contribuidor individual ele fazia as coisas desse jeito e o resultado vinha. Tanto é que ele foi promovido a gestor por fazer as coisas daquele jeito. Então, o que ele entende que tem que fazer como gestor é garantir que todas as pessoas do seu time façam as coisas do jeito que ele faz. Nesse momento a necessidade de microgestão desse líder aparece.

Um líder deve sempre se focar no resultado esperado. A forma como esse resultado é atingido é menos importante do que obter o resultado. Se uma pessoa de sua equipe faz as coisas de forma diferente do que você costuma fazer, isso não significa que a forma como ela faz está errada (claro, desde que não seja uma forma ilícita e não prejudique as pessoas). É só uma forma diferente de fazer as coisas. Talvez até uma forma mais eficiente. O líder precisa respeitar essa diversidade de maneiras de se fazer as coisas e apenas apresentar a sua forma de fazer quando notar que a pessoa não está conseguindo evoluir sozinha.

Oportunidade de aprendizado

Toda vez que delegamos algo para alguém fazer, caso seja a primeira vez que aquela pessoa está fazendo, será uma oportunidade de aprendizado. Por esse motivo, é muito provável que a pessoa cometa alguns erros e aqui entra um dos trade-offs mais difíceis de um líder. Quanto de erro é aceitável? Isso depende muito de cada situação, cabe ao líder entender se os erros são aceitáveis para permitir o aprendizado, ou se dada a criticidade do trabalho a ser feito, erros devem ser minimizados. Devemos sempre criar um ambiente propício ao aprendizado a partir dos erros, pois esse será o aprendizado mais eficaz. É o que busco fazer com os times que lidero.

Resumindo

  • Delegar é o ato de confiar uma tarefa e/ou uma responsabilidade a alguém. A liderança é um ato contínuo de delegação de tarefas e de responsabilidades.
  • Entre não delegar e delegar existem vários níveis de delegação que são usados de acordo com o contexto, ou seja, do problema a ser resolvido e quem estará trabalhando no problema.
  • O conceito de delegação anda de mãos dados com o conceito de microgestão, estilo de gestão em que o gerente observa ou controla de perto o trabalho de seus subordinados ou funcionários.
  • Existem diferentes maneiras de se fazer as coisas para se atingir o mesmo resultado. Líderes novos costumam achar que só o seu jeito de fazer é o certo.
  • Erros são oportunidades incríveis de aprendizado. Daí a importância em tolerar erros no trabalho.

Pronto, com este capítulo concluímos a parte sobre meus princípios pessoais de liderança (pessoas: a prioridade nº 1, sempre; liderar é como ser um médico; liderando sob pressão; mentoria é uma via de mão dupla; e como e quando delegar). Nos próximos capítulos, veremos o que é cultura e quais são os valores que acredito serem obrigatórios para criar produtos digitais de sucesso.

Liderança de produtos digitais

Este artigo faz parte do meu mais novo livro, Liderança de produtos digitais: A ciência e a arte da gestão de times de produto, onde falo sobre conceitos, princípios e ferramentas que podem ser úteis para quem é head de produto, para quem quer ser, para quem é liderado por ou para quem tem uma pessoa nesse papel na empresa. Você também pode se interessar pelos meus outros dois livros:

Mentoria é uma via de mão dupla

A mentoria é uma das responsabilidades mais importantes de um head de produto: ajudar sua equipe a se desenvolver. Como já disse, entre 10% a 40% do tempo do head de produto deve ser focado em ajudar as pessoas de sua equipe a se desenvolverem. Quem me conhece sabe que gosto de termos claramente definidos, então aqui está a definição de mentoria da Wikipedia:

“A mentoria é um processo de transmissão informal de conhecimento, capital social e apoio psicossocial percebido pelo receptor como relevante para o trabalho, carreira ou desenvolvimento profissional; mentoria envolve comunicação informal, geralmente face a face e durante um período, entre uma pessoa que é percebida como tendo maior conhecimento, sabedoria ou experiência relevante (a mentora) e uma pessoa que é percebida como tendo menos (a mentorada)”.

A partir dessa definição, fica clara a natureza unidirecional da mentoria, ou seja, o conhecimento flui da pessoa “mentora” para a “mentorada”.

Recebi e dei orientação durante toda a minha carreira. Mesmo quando era estudante, dava e recebia orientação. Eu acho que alguém recebe orientação desde que nasce. Desde o início da minha carreira, tive a oportunidade de dar orientação às pessoas que lidero e, mais recentemente, tenho sido convidado a orientar empresários e gestores de produto para ajudá-los nas próximas etapas de seus empreendimentos e de suas carreiras. Fico muito feliz em saber que posso ajudar alguém compartilhando minha experiência.

Uma via de mão dupla

No entanto, minha experiência como mentor me mostrou que a definição da Wikipedia está incompleta. Wikipedia define mentoria como transmissão de conhecimento. Meu entendimento é que a mentoria é mais do que uma transmissão de conhecimento. É uma troca de conhecimento. Mesmo considerando que uma das pessoas envolvidas no processo de mentoria é mais experiente em determinado aspecto, tópico ou área, a outra pessoa pode ter experiência e conhecimento em outro aspecto, tópico ou área que pode trazer novos insights. Ou a outra pessoa pode usar sua novidade no tema em que está recebendo mentoria para trazer uma nova perspectiva que o mentor não percebeu.

Portanto, da próxima vez que você estiver em uma situação de mentoria, especialmente se estiver na posição de mentor, pense nisso como uma troca de conhecimento, capital social e apoio psicossocial relevante, útil e valioso tanto para o mentorado quanto para o mentor. Tenho a impressão de que você vai gostar ainda mais de sua próxima sessão de mentoria.

Resumindo

  • Mentoria é um dos papéis mais importantes de um head de produto. É através da mentoria que um head de produtos ajuda seu time a se desenvolver.
  • Mentoria é uma via de mão dupla. A pessoa no papel de mentora deve estar aberta a novos aprendizados vindos de suas sessões de mentoria com sua mentorada.

No próximo capítulo vamos entender um pouco mais sobre cultura, quais valores são essenciais para uma empresa ter produtos de sucesso e o papel do head de produto na criação e manutenção da cultura da empresa.

Liderança de produtos digitais

Este artigo faz parte do meu mais novo livro, Liderança de produtos digitais: A ciência e a arte da gestão de times de produto, onde falo sobre conceitos, princípios e ferramentas que podem ser úteis para quem é head de produto, para quem quer ser, para quem é liderado por ou para quem tem uma pessoa nesse papel na empresa. Você também pode se interessar pelos meus outros dois livros:

Liderando sob pressão

Não existe um ambiente de trabalho sem pressão. Não conheço nenhum local de trabalho em que as pessoas digam que as metas são fáceis, que não há riscos em entregar a meta ou que o projeto será entregue no prazo com 100% de confiança. Se a empresa está crescendo rapidamente, as pessoas precisam sustentar ou melhorar essa taxa de crescimento. Se a empresa está em crise, precisam tirar a empresa da crise.

E isso é bom! Na verdade, esta é a única maneira de fazer as coisas! As pessoas precisam de pressão para fazer as coisas.

O que os líderes precisam saber sobre pressão? Toda gente, incluindo líderes e as pessoas que elas lideram, recebe pressão de fora (o objetivo, a data prevista, a falta de recursos), bem como de dentro (motivação, determinação, força interior).

Pense em pessoas e equipes como balões

Uma boa analogia que eu gosto de usar, especialmente quando a pressão externa aumenta, é que pessoas e equipes são semelhantes a balões. Precisamos equilibrar a pressão exterior com a pressão interior, com alguma tendência a ter um pouco mais de pressão do lado de fora para garantir o melhor desempenho. Se colocarmos muita pressão do lado de fora, sem fornecer às pessoas as ferramentas necessárias para aumentar a pressão interna, o balão explodirá, ou seja, o desempenho diminuirá, as pessoas ficarão incomodadas, às vezes até ficarão doentes (burnout) e provavelmente deixarão a empresa.

Às vezes, podemos ver algum aumento no desempenho logo após um aumento exagerado de pressão externa, mas não devemos nos enganar com esses resultados iniciais. Eles não serão sustentáveis se a pressão interna não for aumentada. Esse aumento no desempenho durará alguns dias e o desempenho diminuirá para níveis ainda menores do que quando aumentamos a pressão externa.

Como podemos melhorar a pressão interna? Ninguém pode impactar diretamente a pressão interna de ninguém. Isso só pode ser feito indiretamente. Aqui estão algumas ferramentas:

  • Precisamos contratar pessoas com a motivação certa, drive e força interior, e devemos criar o ambiente para que elas possam manter tanto a motivação, como o drive e a força interior corretos. Pense em alinhamento de objetivos, visão, valores, cultura e incentivos financeiros e não financeiros.
  • Devemos apoiar o equilíbrio certo entre momentos com pressão e sem pressão. Podemos fazer isso incentivando as pessoas a se afastarem da pressão no local de trabalho e a fazerem outras coisas que gostam, como exercícios, ioga, meditação, música, leitura, passar tempo com seus entes queridos, cozinhar, festejar etc. Por outro lado, devemos evitar trabalhar longas horas, durante a noite, nos finais de semana e feriados. Note que que trabalhar longas horas é uma tática que pode e deve ser usada, mas somente quando necessário. Se isso se torna a norma, e não a exceção, não estamos apoiando o equilíbrio correto entre momentos com pressão e sem pressão.

A analogia do balão funciona tanto para indivíduos quanto para equipes. Muita pressão sobre uma equipe sem a pressão interna apropriada fará o balão explodir. No caso de uma equipe, ela começará a apresentar um mau funcionamento, os membros da equipe começarão a apontar dedos uns para os outros e o desempenho cairá. Para aumentar a pressão interna de uma equipe e ajudá-los a lidar com o aumento da pressão externa, precisamos criar um ambiente que promova a criação de vínculos mais fortes entre os membros da equipe para que eles sejam mais eficazes em responder à pressão externa, sendo mais resilientes e mais adaptativos ao mesmo tempo. Respostas mais eficazes à pressão externa exigem uma combinação de resiliência e adaptação.

Essa analogia também é boa para explicar por que as melhores pessoas decidem deixar uma companhia. Podemos pensar nessa situação como se houvesse mais pressão interna do que pressão externa. Se uma pessoa ou uma equipe tem mais motivação, drive e força interior do que aquilo que o líder lhe pede ou a estratégia da empresa exige dela, ela inflará o balão até ele explodir. Então elas vão deixar a empresa. Lembre da prioridade nº1: pessoas, sempre.

Resumindo

  • Não existe um ambiente de trabalho sem pressão. Pessoas e equipes precisam da pressão externa (a meta, a data prevista, a falta de recursos) e também de dentro (motivação, drive, força interior) para existir e fazer as coisas, como um balão.
  • A pressão interna e a pressão externa precisam ser balanceadas com alguma tendência a ter um pouco mais de pressão do lado de fora para ter melhoria contínua.
  • Sob pressão, uma pessoa e uma equipe explodem ou ficam mais fortes. É papel do líder ajudar a pessoa ou a equipe a perceber isso e trabalhar em conjunto com eles para apoiar o aumento da pressão interna.

No próximo capítulo falarei sobre mentoria.

Liderança de produtos digitais

Este artigo faz parte do meu mais novo livro, Liderança de produtos digitais: A ciência e a arte da gestão de times de produto, onde falo sobre conceitos, princípios e ferramentas que podem ser úteis para quem é head de produto, para quem quer ser, para quem é liderado por ou para quem tem uma pessoa nesse papel na empresa. Você também pode se interessar pelos meus outros dois livros:

Liderar é como ser um médico

Em fevereiro de 2011 fui submetido a uma cirurgia de substituição de disco da coluna cervical. O médico fez a cirurgia no dia 25 de fevereiro. No entanto, o processo de cicatrização levou meses. Segundo o médico, poderia demorar um ano até que todos os sintomas que motivaram a cirurgia desaparecessem.

O que me chamou a atenção é que o cirurgião só faz uma intervenção, mas todo o processo de cicatrização é feito pelo corpo. O mesmo acontece quando um médico prescreve um remédio, que também é uma intervenção, mas, novamente, cabe ao corpo todo o processo de cura.

Liderar uma equipe é bastante semelhante. O líder deve fazer algumas intervenções quando necessário, mas cabe à equipe fazer o trabalho para atingir os objetivos.

Liderança ágil

Em uma das minhas leituras sobre liderança, encontrei uma comparação interessante entre liderança e jardinagem feita por Jurgen Appelo, autor do livro Management 3.0: Leading Agile Developers, Developing Agile Leaders:

Costumo comparar gestores a jardineiros. Um jardim não cuidado é normalmente cheio de ervas daninhas, não de beleza. De uma perspectiva biológica, não há diferença. De qualquer forma, o ecossistema no jardim é auto-organizado. É preciso um jardineiro (autorizado pelos proprietários do jardim) para transformar um jardim anarquista em algo que os proprietários vão desfrutar. Da mesma forma, é necessário um gestor (autorizado pelos acionistas) para conduzir as equipes auto-organizadas em uma direção que agregue valor aos acionistas.

Mesmo que eu goste dessa comparação, ela considera que o jardineiro/gestor deve interferir constantemente, o que não acredito ser um comportamento adequado para um gestor. Na minha opinião, a interferência de um gestor deve ser feita apenas quando necessária e, após a interferência, a equipe deve trabalhar por si mesma para resolver as coisas com pouca ou nenhuma intervenção desse gestor. Daí a minha comparação com uma médica que interfere apenas quando necessário, prescrevendo mudança de hábitos, remédios, fisioterapia e/ou cirurgia e que deixa o corpo fazer o trabalho e se responsabilizar pelo processo de cura.

Resumindo

  • Da próxima vez que você estiver em uma equipe, seja como parte dela ou desempenhando o papel de liderar a equipe, pense no papel de liderança semelhante ao do médico e no trabalho em equipe semelhante ao processo de cura realizado pelo corpo. Ajuda a entender as funções e responsabilidades do líder e das pessoas do time.

No próximo capítulo vamos entender como liderar sob pressão.

Liderança de produtos digitais

Este artigo faz parte do meu mais novo livro, Liderança de produtos digitais: A ciência e a arte da gestão de times de produto, onde falo sobre conceitos, princípios e ferramentas que podem ser úteis para quem é head de produto, para quem quer ser, para quem é liderado por ou para quem tem uma pessoa nesse papel na empresa. Você também pode se interessar pelos meus outros dois livros:

Antipadrões

Um antipadrão é uma resposta comum mas ineficaz e contraproducente a um problema. Esse termo foi criado por Andrew Koenig em 1995, inspirado no livro de 1994, Design Patterns: Elements of Reusable Object-Oriented Software (Padrões de design: Elementos reutilizáveis de software orientado a objetos) escrito por Gamma Erich, Helm Richard, Johnson Ralph e Vlissides John, que lista uma série de padrões de design de desenvolvimento de software que seus autores consideraram simples, sucintos e eficazes para os problemas mais comuns.

Mas o termo foi popularizado pelo livro AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis (Antipadrões: Refatorando software, arquiteturas e projetos em crise), de 1998, escrito por Raphael Malveau, William Brown, Hays McCormick e Thomas Mowbray, que estendeu seu uso além do campo do design de software para se referir informalmente a qualquer solução ruim para um problema.

Na Wikipedia em inglês, o termo lista mais de 70 antipadrões. Vou listar a seguir os antipadrões que encontrei com mais frequência na minha carreira. Esses antipadrões que cito acontecem quando a liderança da empresa não tem experiência suficiente em desenvolvimento de produtos e é assessorada por pessoas que foram bem-sucedidas em gestão de desenvolvimento de software no passado, mas que não se atualizaram.

Como expliquei na introdução, desenvolvimento de software é uma ciência muito nova, especialmente se comparamos com outras ciências como astronomia, medicina, matemática, química etc. 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. Isso significa que desenvolvimento de produtos de software está engatinhando. Se um profissional não se mantiver atualizado, o conhecimento e experiência que o fez bem-sucedido no passado pode não ser o mais adequado para fazê-lo bem-sucedido no futuro.

Documentação

Uso excessivo de documentação vai sem dúvida desacelerar o time de desenvolvimento de produtos. Não é à toa que no Manifesto Ágil, escrito em 2001, dizemos que valorizamos “Software em funcionamento mais que documentação abrangente”. Para certos líderes chega a ser mais importante que o próprio produto. Nada pode ir para produção se não estiver devidamente documentado.

A última vez que escrevi um PRD (Product Requirement Document ou Documento de Requisitos de Produto) foi em 2005, logo quando eu entrei na Locaweb. Foi um trabalho bastante demorado, onde documentei em detalhes tudo o que precisávamos implementar no software. Passada para a engenharia, a implementação foi feita com vários erros porque os engenheiros acabaram não entendendo o que estava escrito em algumas partes e decidiram implementar como acharam melhor. A partir disso passamos a diminuir o uso de documentação extensa e aumentamos a interação entre gestores de produto, designers de produto e engenheiros.

Marty Cagan tem um artigo muito bacana chamado How to write a good PRD (Como escrever um bom PRD – https://svpg.com/assets/Files/goodprd.pdf) onde ele comenta logo no começo:

“Forneço este documento aqui principalmente para fins históricos. Foi escrito em 2005 para refletir melhores práticas das décadas anteriores.

Não tenho defendido o uso de PRDs por muitos anos, começando aproximadamente em 2007. Não é que os PRDs sejam tão ruins. Contudo, se o gerente de produto está gastando seu tempo escrevendo o PRD, então é improvável que ele ou ela esteja fazendo o trabalho real de discovery de produto.”

Padrão recomendado: é só seguir o manifesto ágil, produto na mão de clientes traz mais valor para os clientes e para a empresa do que documentação abrangente e detalhada.

Foco em dados

Acontece quando o head de produtos e outros líderes só tomam decisões se houver abundância de dados, relatórios, gráficos. Há dois perigos com esse antipadrão:

  • Tempo: às vezes para juntar todos os dados necessários leva-se muito tempo. É a situação conhecida como analysis paralysis ou paralisia da análise. Nada acontece enquanto os dados não são meticulosamente obtidos e analisados. Muitas vezes, após uma primeira análise, mais dados são pedidos e mais tempo é investido na busca desses novos dados, e esse ciclo pode se repetir por inúmeras vezes. E, enquanto esse ciclo se repete, nenhuma decisão é feita. Daí a paralisia da análise.
O custo da análise (fonte: https://xkcd.com/1445)
  • Erros: quando confiamos somente e exclusivamente nos dados, há grandes chances de incorrermos em erros. Como podemos ter certeza de que temos todos os dados necessários para concluir algo? Como podemos ter certeza de que os dados estão corretos? É comum ouvir que as decisões devem ser data-driven, ou seja, baseadas em dados. Contudo, os dados podem estar incorretos e/ou ser insuficientes para descrever uma determinada situação. Pensando nisso, mais recentemente surgiu o conceito de decisões data-informed, ou seja, que são baseadas em dados, mas não somente em dados. Levam em conta, além dos dados, informações qualitativas, experiência prévia e intuição.

Padrão recomendado: procure tomar decisões com dados, mas sempre entendendo que os dados são incompletos, e leve sempre em consideração informações qualitativas, experiência prévia e intuição.

Grande reescrita

Toda empresa tem um sistema legado. Mesmo a startup que acabou de ser criada, em poucos meses, poderá olhar para sua base código como legado e algo que precisa ser melhorado. Nesse momento aparecem frases como:

  • Está cada vez mais difícil mexer no código.
  • Se fosse fazer do zero, seria muito mais rápido.
  • Se não reescrevermos, vai ficar cada vez mais lento e perigoso mexer no código.

E nesse momento nasce a grande solução da reescrita. E essa grande reescrita vai, em algum momento causar aquele congelamento de evolução do produto. Por que escrever algo para o legado, se o novo sistema vai substituí-lo? E tem também a migração ou transição. Como vamos do sistema legado para o novo?

Normalmente nas estimativas iniciais a reescrita vai levar uns 2 ou 3 meses e quando avançamos percebemos que vai ser um pouco mais longo, podendo levar anos. Na Locaweb tomamos a decisão de reescrever o sistema central que tinha o cadastro de clientes e fazia a cobrança. O projeto original era de 9 meses e acabou levando mais de dois anos. Além disso, quando o novo sistema entrou, nossa cobrança de clientes não funcionou durante uns 2 meses e ficou mais uns 6 meses rodando de forma incorreta até terminarmos todos os ajustes necessários. Ou seja, a reescrita que originalmente levaria 9 meses acabou levando 3 anos.

Padrão recomendado: evite grandes reescritas a todo o custo. Na grande maioria das vezes haverá formas de substituir o sistema legado de forma gradual e progressiva, sem causar disrupções para a empresa e para os clientes.

Lista de desejos

Quando uma nova head de produto se junta a uma nova empresa, é comum durante o processo de onboarding, durantes as inúmeras conversas com pessoas de várias áreas da empresa, ouvir uma série de pedidos e de reclamações em relação ao produto de que essa nova head vai cuidar. Para “marcar pontos” com essas pessoas, que eventualmente vão dar feedback sobre seu trabalho, pode ser tentador construir sua lista do que fazer baseado nesses pedidos e problemas reportados. É a “lista de desejos” da empresa. Em seguida, essa head de produto vai priorizar essa lista ou até mesmo terceirizar essa priorização para algum líder da área de vendas ou de negócios da empresa. Já vi situações em que o head de produto coletava a “lista de desejos” e apresentava em uma reunião com líderes de várias áreas da empresa, dizendo “agora preciso que vocês priorizem o que querem que o time de desenvolvimento de produto faça primeiro”.

Apesar de ser algo tentador, pois a “lista de desejos” vai de fato ajudar o head de produto a marcar pontos com líderes das outras áreas, esse comportamento fará com que o time de desenvolvimento de produto se torne um mero cumpridor de ordens, inibindo o potencial de inovação que ele pode trazer para o negócio. Quando o head de produto foca o time em atender a “lista de desejos”, acaba focando o time em ser um implementador de soluções que são dadas por outras pessoas, tirando o foco dos problemas a serem resolvidos. É a diferença entre o time implementador de soluções que já vêm prontas das outras áreas da empresa versus um time focado em encontrar as melhores soluções para resolver problemas da empresa. Vou falar mais desse assunto na próxima parte do livro, sobre princípios.

Padrão recomendado: time de desenvolvimento de produto trabalham em entender problemas para depois avaliar soluções possíveis. Procure então descobrir a lista de problemas a trabalhar, e não a lista de coisas que as outras áreas querem que o time de desenvolvimento de produto faça.

Resumindo

  • Antipadrões são respostas comuns mas ineficazes de se resolver problemas. Existem muitos antipadrões bem documentados no mundo do desenvolvimento de produtos digitais. Os 4 antipadrões mais comuns em liderança de desenvolvimento de produto são documentação, foco em dados, grande reescrita e lista de desejos.
  • Documentação, que deveria ser mantida em um mínimo, para certos líderes chega a ser mais importante que o próprio produto. Nada pode ir para produção se não estiver devidamente documentado.
  • Foco em dados é quando toda e qualquer decisão tem que ser tomada com dados, sem levar em conta informações qualitativas, experiência prévia e intuição.
  • Grande reescrita acontece quando uma nova head de produto encontra um sistema escrito há algum tempo e identifica que será melhor reescrever do zero um novo sistema do que aprimorar o atual.
  • Lista de desejos vem da necessidade de o novo head de produtos de agradar a todos os stakeholders, focando o time de desenvolvimento de produtos a apenas implementar o que é pedido, delegando a priorização para as outras áreas da empresa.

Com este capítulo terminamos a parte 1 sobre os conceitos necessários para entender os papéis e responsabilidades de um head de produtos. Na próxima parte vamos ver quais princípios devem nortear o trabalho de uma head de produto e de seu time.

Liderança de produtos digitais

Este artigo faz parte do meu mais novo livro, Liderança de produtos digitais: A ciência e a arte da gestão de times de produto, onde falo sobre conceitos, princípios e ferramentas que podem ser úteis para quem é head de produto, para quem quer ser, para quem é liderado por ou para quem tem uma pessoa nesse papel na empresa. Você também pode se interessar pelos meus outros dois livros:

Desenvolvendo o time e gerenciando expectativas

Como comentei no capítulo Papéis, responsabilidades e senioridade, além de definir e implementar a visão e a estratégia de produto, é responsabilidade da head de produto desenvolver seu time e gerir expectativas. Na terceira parte deste livro, sobre Ferramentas, vou falar sobre várias ferramentas úteis para ajudar a head de produto a cumprir com essas duas responsabilidades. Contudo, antes de falar dessas ferramentas, eu queria falar sobre três conceitos muito importantes para um head de produto.

Como descrevi no livro Gestão de produtos: Como aumentar as chances de sucesso do seu software, as 7 principais características de um gestor de produtos são empatia, comunicação, gestão do tempo, novas tecnologias, habilidades empresariais, curiosidade aguçada e tema do produto.

Como você deve imaginar, essas características também são fundamentais para um head de produto. Contudo, gostaria de destacar e relembrar 3 delas, por considerá-las essenciais para o dia a dia da pessoa head de produto:

Empatia

Empatia é a capacidade que uma pessoa tem de se colocar no lugar de outra para compreender suas expectativas. Seus anseios, motivações, necessidades e problemas. Essa característica é importante para entender os clientes e usuários do produto, saber como estes se relacionam com ele, e que problema esperam resolver ou que necessidade querem ver atendidas. Isso ajudará o gestor de produtos a entender melhor seu usuário para poder, junto com o UX e a engenharia, desenvolver o melhor produto.

Empatia

Contudo, a empatia não deve ser usada apenas com o cliente ou usuário. O gestor de produtos deve usá-la também no seu relacionamento com todas as áreas da empresa para ajudá-lo a entender quais são as expectativas que essas áreas têm em relação ao produto, e qual o impacto que seu produto tem no trabalho delas. Será que aumentaram os problemas jurídicos devido a alguma funcionalidade nova no produto? Qual o impacto para a equipe de vendas, suporte, operações, financeiro e marketing? Até mesmo em relação ao time do produto, engenheiros e designers de UX, como o produto interfere no trabalho desses profissionais?

Empatia também é muito importante para que a head de produto possa entender como ela pode ajudar seu time a se desenvolver. Qual das 7 características citadas acima precisa de mais atenção nesse momento e por quê? Qual é a melhor forma de ajudar essa pessoa a desenvolver essa habilidade?

A head de produto também precisa se colocar no lugar dos donos do produto para entender suas expectativas sobre o produto e os resultados que ele trará para a empresa.

Comunicação

A capacidade de se comunicar é fundamental para que a head de produtos possa gerir expectativas e ajudar seu time a se desenvolver. A head de produtos precisa se comunicar com as pessoas nos mais diferentes cenários: em conversas um a um e em pequenos grupos, ou fazendo apresentações para grupos pequenos e grandes de pessoas, apresentações que podem ser internas (dentro da empresa) ou externas (em conferências, grupos de usuários etc.).

Deve também ser boa de comunicação escrita (e-mail, blog, documentação, chat, redes sociais etc.), e ser capaz de discernir sobre qual a forma de comunicação mais apropriada para cada momento, público e meio de comunicação; e de se comunicar de forma a ser entendido pelos diferentes públicos: técnico e não técnico. Como se isso tudo não bastasse, essa pessoa também precisa ser capaz de se comunicar passando segurança e confiança no que está comunicando; afinal, head de produtos não só é o porta-voz do produto como também é a referência mais sênior de toda a empresa sobre o produto.

É importante lembrar que comunicação é uma via de mão dupla, ou seja, a head de produtos tem de ser muito boa em saber ouvir e compreender o que os outros estão dizendo, e entender os anseios e as necessidades deles; o que tem a ver com a primeira característica, a empatia.

Habilidades empresariais

O gestor de produtos deve se preocupar se o seu produto está atingindo os objetivos de negócio, pois o atingimento – ou não – é a principal fonte de expectativas das pessoas em relação ao produto. Como o produto vai ajudar a atingir os objetivos de negócio? Se o objetivo for margem, a receita e os custos estão sob controle? Se o objetivo for só receita, como está o crescimento dela? Se o objetivo for número de usuários, como essa métrica está evoluindo?

Além disso, o gestor de produtos deve entender como cada área da empresa funciona e como o produto afeta essas áreas. Como o jurídico funciona? Como o produto impacta no departamento jurídico? E como o departamento jurídico impacta no produto? Essas perguntas podem ser repetidas para todas as áreas da empresa: suporte, operações, financeiro, RH, marketing, vendas, engenharia e UX.

Resumindo

  • Para desenvolver seu time e gerir expectativas, o head de produto deve ter as 7 características de um bom gestor de produtos: empatia, comunicação, gestão do tempo, novas tecnologias, habilidades empresariais, curiosidade aguçada e tema do produto
  • Três dessas características são essenciais para o trabalho de head de produto. Empatia para entender de onde vêm as expectativas e que elementos precisam ser desenvolvidos em seu time. Comunicação para poder entender e se fazer entender quando estiver conversando com as pessoas da empresa para gerir suas expectativas e quando estiver desenvolvendo seu time. Habilidades empresariais que ajudarão a entender os objetivos da empresa que são componentes importantes das expectativas que as pessoas têm em relação ao produto.

No próximo capítulo vamos ver os antipadrões de liderança de times de desenvolvimento de produto.

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:

Estrutura de time

O time de desenvolvimento de produto é quem vai executar a estratégia e atingir os objetivos para alcançar a visão de produto. Por isso, uma parte essencial da definição de estratégia é desenhar e implementar sua estrutura de time. Para isso, é importante entender as diferentes formas de se organizar um time de desenvolvimento de produtos e definir qual a mais apropriada para a sua estratégia.

Times de produto

O time mínimo de desenvolvimento de produto que vimos no capítulo sobre Carreira de gestão de produtos é composto um product manager, um product designer e dois ou mais engenheiros. Esse time mínimo pode também ser chamado de squad e deve ter no máximo umas 7 pessoas. Quanto maior o time, maior a dificuldade de coordenação. Na Amazon existe a famosa regra dos times de duas pizzas, ou seja, o tamanho máximo do time é aquele que consegue ser alimentado por duas pizzas grandes. O racional por trás da vantagem de rodar com times pequenos é baseado no mesmo conceito que apresentei quando falei de plataformas no capítulo O que é produto digital e gestão de produtos?. A quantidade de interações entre os membros do time crescem rapidamente com o tamanho do time, seguindo a fórmula n*(n-1)/2. Assim, enquanto um time de 5 pessoas tem 10 possibilidades de interação entre seus membros, em um de 7 pessoas esse número cresce para 21.

Quando juntamos dois ou mais squads temos um time de produto, que também pode ser chamado de tribo.

Times de produto

Essa tribo de produto pode ter um, dois ou três líderes. Se for uma líder, ela será responsável por liderar product managers, product designers e engenheiros. Se forem dois líderes, normalmente um vai liderar product managers e product designers, e o outro liderará engenheiros. Se forem três, um lidera product managers, outro, product designers e o terceiro, engenheiros. Já tive oportunidade de trabalhar em estruturas com um, dois e três líderes em cada tribo de produto e cada uma dessas estruturas traz seus pontos positivos e negativos, como expliquei no capítulo sobre Carreira de gestão de produtos onde falo sobre liderança única e liderança compartilhada.

Times de produto também podem ter alguns papéis compartilhados entre os squads. Tê-los compartilhados ao invés de dedicados por squad tem três principais objetivos:

  • Tamanho de squad: manter o squad pequeno é importante para conseguir preservar a agilidade desse time. Quanto maior o time, maior a necessidade de coordenação entre os membros do time.
  • Ownership: a partir do momento em que você tem uma pessoa no squad com uma função específica, essa função deixa de ser responsabilidade dos outros membros do time. Por exemplo, se tivermos uma pessoa cuidando da qualidade, esse tema virará responsabilidade dela, e as outras pessoas do squad vão se preocupar menos com o tema. As exceções são as três funções primárias de um squad que são engenharia, design de produto e gestão de produto.
  • Alocação de recursos: além de o squad ficar grande se colocarmos esses papéis dentro dele, necessitando de mais coordenação e tendo o risco de ficar mais lento, cada squad custará mais caro. Com squads menores, temos a possibilidade de alocar os recursos que você tem disponível para desenvolvimento de produto em mais squads que constroem produto.

Exemplos de papéis que podem existir em uma tribo de produto compartilhado entre os diferentes squads:

  • Agile Coach: ajuda os squads em seus processos e cultura ágil. Em vez de um scrum master por squad, tem-se um agile coach por tribo que ajuda os squads nesse tema, mas os processos e a cultura ágil de cada squad é responsabilidade de cada membro do squad.
  • Quality Assistance: assim como processos e cultura ágil são responsabilidade de cada membro do squad, o mesmo acontece com qualidade. Em vez de um quality assurance por squad, podemos ter um quality assistance por tribo de produto, que vai ajudar cada squad com questões de qualidade.
  • Data Analyst: todo squad gera muitos dados e precisa entender o que esses dados querem dizer. De novo, entender o que esses dados significam é uma responsabilidade do squad. Contudo, quando a estrutura de dados é muito complexa, pode fazer sentido ter uma pessoa por tribo de produto ajudando seus squads nas necessidades mais complexas de dados de cada squad.
  • SRE: para produtos com muita integração com sistemas de terceiros pode ser interessante ter um Site Reliability Engineer (SRE) por tribo ajudando os squads a definir e implementar arquiteturas estáveis, com boa performance e resilientes. Na Conta Azul, como tínhamos integração com bancos e com os sistemas das Secretarias da Fazenda de cada estado para emissão de nota fiscal, fez sentido termos uma pessoa com esse conhecimento em cada tribo.
  • User Research: essa é a responsabilidade dos product designers, com apoio dos gestores de produto de cada squad. Em alguns casos, pode fazer sentido ter uma pessoa com foco em research na tribo de produto para ajudar nessas pesquisas de cada squad.
  • Product Marketing: enquanto a missão da gestora de produtos é construir o produto ou funcionalidade que resolve problemas dos usuários, o product marketing tem por missão contar ao mundo sobre o produto ou funcionalidade e o problema que ele resolve. Esse “mundo” refere-se tanto aos usuários do produto quanto aos novos usuários que queremos trazer. É responsável por desenhar e implementar a estratégia de go to market (GTM) do produto. Em muitas empresas essa responsabilidade recai sobre a gestora de produtos. Isso funciona em muitos casos, mas pode tirar seu foco em construir o melhor produto ou funcionalidade.

Há outros papéis que podem ser compartilhados mas lembre-se de que, quanto mais papéis compartilhados tiver, mais difícil ficará a coordenação das pessoas da tribo. Minha recomendação é ter no máximo 3 papéis compartilhados. Eles podem ser liderados pela(s) líder(es) da tribo ou pela líder da tribo estrutural correspondente à sua função.

Organizando times de produto

Existem 4 formas possíveis de se organizar times de produto, por produto ou funcionalidade, por tipo de usuário, por jornada ou por objetivo. É possível também usar dois tipos diferentes de organização criando uma organização híbrida. Vou descrever a seguir cada uma:

Por produto ou funcionalidade

É uma das formas mais comuns de organização de times de produto. Para cada produto ou funcionalidade temos uma tribo. Na Locaweb tínhamos time de produto para cada produto, Email Marketing, PABX virtual, cloud, hospedagem de sites e assim por diante. Na Conta Azul também usávamos esse modelo, com um time, o Spartans, focado em funcionalidades relacionadas à gestão financeira e o outro time, o Underground, focado em funcionalidades fiscais e contábeis. Na Lopes, quando entrei, tínhamos um time focado no portal, outro no CRM utilizado pelos corretores e franquias e um terceiro focado no app para corretores.

A principal vantagem desse forma de organização é que a parte do produto que é responsabilidade da tribo é bem clara mas, por outro lado, com o foco no produto perde-se um pouco de perspectiva da(s) pessoa(s) cujos problemas esse produto resolve.

Por tipo de usuário

Esse é um modelo muito útil em marketplaces e plataformas. Cada tribo tem o foco em um ator. Por exemplo, no Gympass, onde tínhamos academias, RH das empresas e funcionários das empresas, tínhamos 3 tribos, cada uma focada nesses três atores do marketplace. Na Conta Azul tínhamos duas tribos focadas no dono do pequeno negócio e duas focadas no contador. Na Lopes desenhamos uma estrutura onde temos uma tribo focada no comprador de imóvel, outra no vendedor e uma terceira focada no corretor, que faz a intermediação.

A vantagem desse modelo de organização é que o foco de cada time é bem definido, visando melhorar a experiência e resolver o problema de cada ator da plataforma. Caso a arquitetura de sistemas seja muito acoplada, pode haver bastante dependência entre os times. Outro ponto de atenção é que algumas jornadas podem ficar divididas entre duas tribos. Por exemplo, no Gympass existe a jornada de fazer check-in em uma academia, que acontece quando o usuário vai até a academia, faz o check-in e a recepção o valida. Em uma organização de time por tipo de usuário, tanto o time de academias quanto o de usuário são responsáveis por essa jornada e devem se coordenar para fazer mudanças nessa parte do produto.

Por jornada

Nesse modelo, os times são organizados de acordo com cada jornada do usuário. Busca, compra, agendamento de aula e assim por diante são jornadas pelas quais seu usuário pode passar ao usar o seu produto. Confesso que nunca vi um time 100% organizado por jornada, mas já vi times organizados por produto ou por tipo de usuário terem uma ou mais tribos focadas em alguma jornada. Por exemplo, na Conta Azul tínhamos um time chamado Hubble que cuidava da jornada do usuário até ele poder usar funcionalidades financeiras, cuidadas pelo Spartans e funcionalidades fiscais e contábeis, cuidadas pelo time Underground. No Gympass, além dos times de usuário, academia e RH da empresa, tínhamos um time, chamado de Cross Features, que cuidava do cadastro de cada um dos participantes do marketplace (usuários, academias e RHs) e de receber o pagamento feito por RHs e usuários, e por fazer o pagamento para as academias. Na Lopes, decidimos criar, além dos times para comprador, vendedor e corretor, um time chamado Leads, que cuida das interações entre comprador e corretor. Na Locaweb criamos o time de sistemas centrais, depois renomeado para enterprise applications, responsável pela central do cliente, onde o cliente da Locaweb pode ver e administrar todos os produtos contratados.

A principal vantagem dessa estrutura é que o foco em uma jornada aumenta a chance de proporcionar uma ótima experiência naquela jornada específica. Por outro lado, normalmente um squad é suficiente para cuidar de uma jornada, então você pode acabar com muitas tribos de um só squad.

Por objetivo

A organização por objetivo significa que a tribo tem foco em um objetivo específico. Conversão, retenção, experiência de uso etc. Não conheço nenhum time 100% estruturado somente por objetivos. No Gympass usávamos esse modo de organização no time de usuário quando o dividimos em duas tribos, uma focada em crescimento, que tinha por objetivo garantir que os funcionários dos clientes baixassem o app, criassem a conta gratuita e se tornassem assinantes e a outra focada em experiência digital para garantir que os usuários utilizassem e tirassem o maior proveito possível do app, garantindo a satisfação e a retenção destes.

Nesse tipo de organização, o principal benefício é o foco no lugar aonde você quer chegar, o objetivo. A desvantagem é que você pode ter dois squads com objetivos diferentes lidando com a mesma área do produto, o que pode causar uma experiência estranha para o usuário. Outra desvantagem é que, se a arquitetura de sistemas estiver muito acoplada, pode haver muita dependência entre as equipes.

Prós e contras dos diferentes tipos de organização de times de desenvolvimento de produto

Híbrida

Essas diferentes formas de organizar times de produto podem ser usadas em conjunto, ou seja, não são exclusivas. Na verdade, nunca vi uma equipe de desenvolvimento de produto usando exclusivamente um tipo de organização. As equipes são estruturadas em organizações híbridas. Veja a seguir alguns exemplos de organização híbrida.

Na Locaweb tínhamos times por produto (Hospedagem, Email Marketing, Cloud etc.) e um time focado na jornada do cliente (Central do Cliente)

Times de produto da Locaweb (2016)

Na Conta Azul usávamos organização por funcionalidade. Um time para gestão financeira do pequeno negócio (Spartans) e outro para gestão fiscal e contábil (Underground). Um para gestão fiscal, contábil e de folha dos clientes do contador (Area 42) e outro para gestão de clientes do contador (Babilônia). Também organizávamos por tipo de usuário (times focados no dono do negócio e no contador) e por jornada (Hubble).

Times de produto da Conta Azul (2018)

No Gympass definimos os times por tipo de usuário (usuário final, academia e RH), mas também usamos a organização por jornada para criar o time de Cross Features, responsável pelo cadastro de cada um dos participantes do marketplace (usuários, academias e RHs), por receber o pagamento feito por RHs e usuários e por fazer o pagamento para as academias. E usamos também a organização por objetivos quando quebramos o time de usuário final em duas tribos, uma de crescimento e outra de experiência digital.

Times de produto do Gympass (2019)

Na Lopes também definimos os times por tipo de usuário (cliente final, incorporador & proprietário, corretor & franquia) e definimos uma tribo focado na jornada entre cliente e corretor, que chamamos de Leads.

Times de produto da Lopes

É importante ressaltar que esses exemplos são da época em que trabalhei nessas empresas. Da mesma forma que a visão e estratégia de produto evoluem, a estrutura de times também deve evoluir.

Organizando squads em um time de produto

Essas formas de organização de times de produto servem tanto para definir a organização entre tribos, bem como a organização dos squads de uma tribo. Alguns exemplos:

  • Hospedagem de sites (Locaweb): dentro do time de hospedagem de sites da Locaweb tínhamos 3 squads, um focado em hospedagem Windows, outro em hospedagem Linux e um terceiro com foco no painel de controle de gestão da hospedagem.
  • Academias (Gympass): no time focado em academias do Gympass tínhamos um squad focado em APIs para integração com sistemas de gestão para integração de processo de check-in dos usuários e de reserva de aulas e outro squad focado na experiência do gestor da academia, para que ele pudesse ter acesso a relatórios e configurar como sua academia apareceria no app do usuário.
  • Financeiro (Conta Azul): no time focado em gestão financeira do Conta Azul, tínhamos um time focado em integração com os bancos para receber dados de extrato bancário dos clientes, um outro focado na interface de gestão financeira, com relatórios e sistema de categorização dos lançamentos do extrato e um terceiro focado em uma funcionalidade que tinha nome próprio, o Receba Fácil, sistema de emissão de boleto bancário.

Times estruturais

Times estruturais são os times que trabalham na estrutura necessária para os times de produto poderem fazer seu trabalho.

Times estruturais

Alguns tipos de times estruturais necessários no desenvolvimento de produtos digitais:

  • SRE ou DevOps: SRE significa Site Reliability Engineering. Essa área, às vezes chamada de DevOps, é responsável pela infraestrutura onde o produto será hospedado e servido aos clientes. Responsável também por monitorar o produto e a infraestrutura de hospedagem para garantir que ele opere com a performance ideal.
  • Dados: aqui temos normalmente 3 disciplinas que precisam ser cuidadas pelo time de dados. Primeiro, é necessário um time de engenharia de dados que cuide da infraestrutura necessária para gestão dos dados da empresa. Em seguida, é necessário um time de análise de dados, responsável por gerar relatórios e dashboards com base nos dados e mostrando a performance do produto. Por fim, é interessante ter também um time de cientistas de dados capaz de tirar insights dos dados e eventualmente criar algoritmos de machine learning que possam evoluir à medida que mais dados são coletados e analisados.
  • Arquitetura/Ferramentas/Fundação: time que ajuda os times de produto a definirem os padrões de arquitetura de software. Esse time também pode trabalhar em temas que são comuns a todos os times como, por exemplo, autenticação e autorização, e infraestrutura de APIs.
  • Design Ops: time central de design que cuida de criar e manter o Design System, biblioteca de componentes e padrões de interação. Essa equipe também pode cuidar da eficiência operacional dos product designers, dando-lhes ferramentas, capacitando os gestores e líderes para avaliar o desempenho desses product designers e auxiliando no onboarding. Nesse time também podem ficar profissionais de user research e de UX writing.
  • Segurança da Informação: responsável por todos os aspectos de segurança da informação, tais como LGPD, certificação PCI, certificação ISO 27001, políticas de BYOD (bring your own device) para permitir que os funcionários utilizem seus próprio devices para o trabalho.
  • Sistemas Internos: responsável por cuidar dos sistemas de terceiros, tais como Google Suite, Office 365, Slack etc., bem como dos equipamentos da empresa.
  • Engenharia de Vendas: essa área faz bastante sentido em empresas que desenvolvem produtos para outras empresas. É um time com conhecimento técnico capaz de discutir detalhes de implementação e integração do seu produto com os sistemas do cliente.
  • Serviços Profissionais: caso as necessidades de implementação e de integração do novo cliente fujam do padrão, ou o cliente não esteja preparado para fazer essa implementação ou integração, pode ser interessante ter um time de serviços profissionais que faça esse trabalho. O recomendado é que esse time seja bem enxuto e utilize terceiros conforme a demanda para fazer o trabalho de implementação e integração.
  • HRBP e contratação: como visto acima, times de produto e suas estruturas são complexos, com muito trabalho colaborativo e com estruturas matriciais. É essencial ter um time de RH por perto para ajudar na gestão do time, com dois focos. HRBP, ou Human Resources Business Partners ajuda no dia a dia dos times e líderes em todas as questões ligadas à RH. Contratação, no inglês talent acquisition é responsável por todo o processo de atração e contratação de pessoas para o time.

Implementação

A implementação da estrutura de produtos que foi desenhada pode acontecer de duas formas. Ou você está criando uma estrutura do zero, ou você está ajustando uma estrutura já existente.

Criando uma nova estrutura

Quando você cria uma estrutura do zero, você tem a oportunidade de crescer de acordo com as necessidades. Você pode começar com um único squad, depois criar o segundo e assim por diante. É importante você ter em mente aonde você deseja chegar com essa estrutura. Você terá times estruturais? Quais? Que times de produto você pretende ter?

Recomendo também começar a montar esses times pelos seus líderes, para que eles possam ter a oportunidade de contratar e formar os times conforme suas necessidades, desde que alinhados com a visão que você desenhou.

Mudando uma estrutura existente

Quando você chega para liderar um time já formado, é importante ter clareza da visão de produto, da estrutura atual e das pessoas que fazem parte desse time. Você precisará fazer várias conversas para entender bem esses três aspectos antes de propor mudanças na estrutura atual. Assim que você desenhar uma primeira versão da sua proposta, apresente-a como trabalho em progresso para algumas pessoas para colher feedback e ir ajustando.

Uma vez acordada a nova estrutura, coordene com as pessoas dos times para fazer a mudança. Pode ser que alguns times que serão mexidos estejam terminando de fazer algumas coisas, então é importante alinhar com essas tarefas pendentes para permitir uma transição mais suave da estrutura atual para a nova.

Qual é a melhor proporção entre Eng, UX e PM?

Podemos encontrar muitos artigos de diferentes equipes de desenvolvimento de produto ao redor do mundo mostrando benchmarks de relações Eng:PM e UX:PM. Há um artigo recente de Ken Norton, parceiro do Google Ventures e ex-líder de gestão de produto do Google e do Yahoo!, onde ele compartilha os resultados de uma pesquisa informal que fez no Twitter:

Uma maioria significativa dos tweets recomendou algo na faixa de 5 a 9 engenheiros para cada PM. Houve motivos pelos quais as pessoas recomendaram ter mais ou menos, mas entre 5 e 9 parece ser o ideal. Pensando em minha própria experiência, minhas equipes de melhor desempenho também se enquadraram nessa faixa.

Quando se trata de designers, prefiro uma proporção de 1:1 com PMs para equipes de produtos focadas no usuário. As equipes de produto funcionam melhor quando a tríade dedicada de PM, designer e líder de tecnologia forma o núcleo.

Portanto, parece que a recomendação geral é de 5 a 9 engenheiros por PM e 1 UX por PM. Aqui, quando contabilizamos as pessoas de engenharia, devemos também considerar as pessoas dos times estruturais.

Alguns números da vida real

No Gympass, trabalhamos para aumentar o número de engenheiros por gestores de produto. Em nossos esforços para aumentar a equipe de 32 para 85 pessoas em 5 meses conseguimos aumentar a relação Eng:PM e também a relação UX:PM. Nosso plano era chegar ao final de 2019 com quase 200 pessoas em nossa equipe de desenvolvimento de produto, com ainda mais engenheiros por gerente de produto e um melhor equilíbrio entre designers de UX e gerentes de produto, como acabou acontecendo.

Gympass

Todos os benchmarks são claros quando explicam que cada gestor de produto deve ser pareado com um UX, especialmente para produtos voltados para o cliente. No caso do Gympass, são 3 tipos diferentes de clientes (usuários finais, academias e clientes corporativos) o que reforça a necessidade de manter a proporção recomendada de 1 product designer por gerente de produto.

Na Conta Azul já tínhamos uma boa relação Eng:PM quando entrei em agosto de 2016. No entanto, a relação UX:PM estava abaixo dos padrões de mercado. Principalmente levando em consideração que um dos 4 valores fundamentais da Conta Azul é entregar o “Uau” aos clientes. Por esse motivo, trabalhamos para aumentar a proporção de designers de experiência do usuário em relação aos gestores de produto para aumentar o “Uau” entregue aos clientes.

Conta Azul

Na Locaweb, muitos produtos que construímos eram para engenheiros de software. Hospedagem de sites, hospedagem de banco de dados, SMTP, Servidores cloud e servidores dedicados. Por isso, o número de engenheiros por gestores de produto é maior que o da Conta Azul e do Gympass. É ainda maior do que o limite superior recomendado de 9 engenheiros por gestor de produto. No entanto, podemos ver um fato interessante na proporção de designer de UX por gestor de produto. Como visto nos números de agosto de 2015, uma proporção maior de Eng:PM força um aumento em UX:PM em comparação à proporção de 1:1 recomendada. Quando olhamos os números de julho de 2016, temos mais engenheiros por gestores de produto, chegando a quase 12 Eng:PM, o que fez aumentar a proporção UX:PM para quase 2:1. Tivemos que colocar 2 designers de UX para cada gerente de produto para que eles pudessem lidar com todo o trabalho de discovery que precisava ser feito para que os engenheiros pudessem construir o produto certo. Considerando os engenheiros como responsáveis pelo delivery e UX e gestores de produto como discovery, isso nos mostra que tínhamos cerca de uma pessoa de discovery para cada 4 de delivery.

Locaweb

Lei de Conway

A Lei de Conway foi criada por Melvin Conway, cientista da computação americano, e publicada pela primeira vez em abril de 1968, em uma revista de Tecnologia da Informação bastante conhecida na época chamada Datamation. A Lei de Conway diz que:

Lei de Conway

Qualquer organização que desenvolve um sistema produzirá um sistema cuja estrutura é uma cópia da estrutura de comunicação da organização.

Já vi situações em que um time de desenvolvimento de produto é organizado em paridade com as áreas de negócio, ou seja, um time é focado nas necessidades do atendimento ao cliente, outro é focado no time de vendas, outro é focado no financeiro, mais um focado no marketing, e assim por diante. Não recomendo esse tipo de estrutura, pois diminui o foco no cliente.

Os estágios de Tuckman de evolução de times

Bruce Tuckman, um pesquisador americano sobre dinâmica de grupos, propôs em 1965 quatro estágios pelos quais passa um grupo de pessoas que começam a trabalhar juntas, e como esses estágios impactam na eficácia desse grupo.

Os 4 estágios de Tuckman para formação de times
  • Formando (forming): nesse estágio, as pessoas do grupo estão se conhecendo, entendendo os objetivos comuns e buscando formas de trabalharem juntas.
  • Confrontando (storming): em seguida, acontecem alguns confrontos, quando o grupo começa a discutir sobre como o trabalho será feito e começa a conhecer as habilidades de cada pessoa no grupo.
  • Normatizando (norming): esse é o momento em que os membros do grupo definem o processo de trabalho e os papéis e responsabilidades de cada membro do time. Nessa fase os membros do time já se conhecem melhor e respeitam as habilidades uns dos outros.
  • Performando (performing): é nesse momento que o time de fato começa a produzir e a entregar resultados. O time já se conhece bem, o processo de trabalho é claro e acordado entre todos os membros do time.

Não há uma melhor forma de se estruturar um time de produto. Há aquela que faz mais sentido para a estratégia e objetivos definidos para atingir a visão de produto. Por isso, a estrutura de time não é escrita em pedra. Se houver necessidade, por mudança de objetivos ou de estratégia, pode fazer sentido mudar a estrutura do time. Contudo, não recomendo fazer isso com muita frequência, devido ao tempo necessário para um time recém-formado passar pelos estágios de Tuckman. Ouvi certas pessoas comentando que trabalham em empresas que mudavam a estrutura de time de desenvolvimento de produtos a cada 3 ou 6 meses. Não é tempo suficiente para passar pelos estágios de Tuckman.

Unidades de negócio

Em algumas situações, em vez de ter times de produto separados, mas dentro da mesma organização, pode ser interessante criar unidades de negócio razoavelmente independentes. Em unidades de negócio, temos não só um time de desenvolvimento produto separado, como todas as áreas necessárias para o negócio acontecer de forma independente tais como marketing, vendas, atendimento ao cliente etc.

Na Locaweb optamos pelo modelo de unidades de negócio independentes quando adquirimos empresas. A Tray era uma empresa de soluções de ecommerce que passaram a fazer parte do portfólio de produtos da Locaweb. Como a Tray já operava como uma empresa independente, optamos por mantê-la dessa forma, somente tendo as áreas de administração, financeiro e RH em comum. Essa é uma maneira bem comum de criar áreas de negócio, por meio de aquisições de empresas.

No Gympass vislumbramos a oportunidade de criar um novo produto chamado Gympass Wellness, que oferece serviços de bem-estar tais como aplicativos de atividade física, de nutrição e de meditação para os funcionários dos clientes do Gympass. Optamos por iniciar esse novo produto como uma unidade de negócios, com time de produto, de marketing e de vendas independente do Gympass, visando dar maior autonomia e agilidade para esse time.

Na Lopes temos a CrediPronto, unidade de negócios que é uma joint-venture entre Lopes e Itaú para oferecer crédito para compradores de imóveis. Pelo fato de a natureza do negócio ser completamente diferente do negócio principal de transação imobiliária e ainda por ter um novo sócio, optou-se pelo modelo de unidade de negócio.

O que faz um grupo de pessoas se comportar como um time?

Não é suficiente organizar as pessoas na estrutura de equipes descrita aqui para que se comportem como uma equipe. Para que se percebam como uma equipe e passem a atuar como tal, precisam de objetivos comuns.

Um problema muito comum que vejo nas equipes de desenvolvimento de produto é que, mesmo sendo muito bem organizados em tribos e esquadrões, com tribos estruturais e tribos de produtos, e as pessoas certas com as funções certas em cada equipe, os objetivos são definidos por função. Os gerentes de produto têm um conjunto de objetivos diferente dos de designers de produto, que são diferentes dos objetivos dos engenheiros. Isso simplesmente não funciona, porque cada pessoa se concentrará nos seus próprios objetivos.

Se definirmos todos os objetivos como sendo comuns a todos os membros da equipe, todos eles trabalharão juntos para atingi-los. Mesmo que o objetivo pareça mais relacionado a um dos aspectos, como mais relacionado ao negócio (gerente de produto) ou à experiência do usuário, ou mais relacionado à engenharia, todos os membros da equipe devem ter os mesmos objetivos.

Então, a resposta curta para a pergunta “O que faz um grupo de pessoas se comportar como uma equipe?” são objetivos comuns.

Resumindo

  • Times de desenvolvimento de produto são organizados em times mínimos, também chamados de squads, compostos de engenheiros, product designers e product managers. É importante deixar esses times o mais enxuto possível para ajudar em sua produtividade. Esses times mínimos são agrupados em times de produto chamados de tribos de produto.
  • 4 formas de se organizar os times de produto: por produto ou funcionalidade, por tipo de usuário, por jornada ou por objetivo. É possível também usar dois tipos diferentes de organização, criando uma organização híbrida.
  • Existem também as tribos estruturais, que criam a estrutura necessária para as tribos de produto performarem. Times que compõem as tribos estruturais são SRE/DevOps, Dados, Arquitetura/ Ferramentas/ Fundação, Design Ops, Segurança da Informação, Sistemas Internos, Engenharia de Vendas e Serviços Profissionais.
  • A implementação da organização de time desenhada pode ser feita ou criando uma nova estrutura ou ajustando um time já existente. Em ambas as situações é importante conhecer bem a visão e a estratégia de produto para desenhar e implementar uma estrutura de time alinhada com ela.
  • A proporção mais indicada entre pessoas em engenharia e gestores de produto é de 7 +/- 2 engenheiros para cada gestor de produto. E de um product designer para cada gestor de produto.
  • Dois conceitos importantes no desenho de sua estrutura de time são o da Lei de Conway, que diz que as organizações tendem a criar sistemas que são uma cópia da estrutura de comunicação das empresas, e os 4 estágios de Tuckman de formação de times, formando, confrontando, normatizando e performando.
  • É possível também organizar times de produto por unidades de negócio que tenham outras funções além das compreendidas em um time de desenvolvimento de produto, tais como marketing, vendas e atendimento ao cliente. As motivações para criar unidades de negócio em vez de times de produto podem ser devido à aquisição, ou para dar mais agilidade ao novo negócio ou mesmo por se tratar de uma nova linha de produto completamente diferente do produto original.
  • O que faz um grupo de pessoas se comportar como um time são os objetivos comuns.

No próximo capítulo vamos ver um pouco mais sobre desenvolver o time e gerenciar expectativas.

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: