What is the difference between project management and product management?

As with the functions of product marketing and product management which, as we saw in the previous chapter, are quite distinct but overlapping, project management and product management functions are also quite distinct, but they also have a lot in common.

Before talking about the difference between these functions, we need to make clear the difference between project and product. I will turn to Wikipedia once again:

Project
A project in business and science is usually defined as a collaborative venture, often involving research or design, that is carefully designed to achieve a particular goal.
Source: Wikipedia (https://en.wikipedia.org/wiki/Project)

Product
The term product is defined as “something produced by work or effort” or as “the result of an act or process” and has its origin in the Latin verb produce (re), ‘make exist’.
Source: Wikipedia (https://en.wikipedia.org/wiki/Product_(business))

That is, while the project is a process with a beginning, middle, and end; product is the result of a process.

See the table below for the main differences between project and product:

ProjectProduct
Clearly defined beginning, middle, and end.The beginning and middle are identifiable, but the end is not.
Focus on delivery with a well-defined path.Focus on results with a well-defined objective.
Closed scope defined during planning.Testing and validation of ideas lead the way.
May work in predictable scenarios.Suitable for volatile scenarios and contexts.

To help make these differences tangible, here are some examples:

  • Locaweb: before having its own data center, Locaweb placed its servers in Embratel’s data center. In 2006, Locaweb decided to invest in its own data center, which was clearly a project. In fact, two projects, the project to build their own data center and the project to migrate the servers that were at Embratel to their own data center. Locaweb’s products (Site Hosting, Email Marketing, Virtual Store, etc.) are clearly products.
  • Building: The construction of a building, from its conception to the delivery of the keys, is a project with well-defined phases. On the other hand, after the keys are handed over to the buyers, we can look at a building as a product. People will live in the building, some apartments will be rented, others will be sold, there will be renovations, condominium management, and so on.
  • Marriage: the decision to get married and the entire wedding process is clearly a project, with the wedding ceremony, party, and honeymoon. After the honeymoon is over, and married life begins, we must look at marriage as a product, married life, children and grandchildren, the family, and family life.

So, managing projects and products are two distinct functions?

Yes. While one manages a project, her concern is with the process and everything that surrounds it, ie if it is on time, has everything that is needed and is being done with the expected quality.

On the other hand, when building a product, the main concern is to ensure that it solves a problem of the customer to whom it is intended, and meets the company’s objectives.

In a 2007 blog post How To Be A Good Product Manager, author Jeff Lash recalls some important points to keep in mind when thinking about project management and product management:

  1. Just as every product needs a product manager, every project needs a project manager.
  2. The fact that product managers believe they are capable of managing their own projects does not mean that they should manage their own projects.
  3. The skills, talents, and knowledge involved in project management are very different from those involved in product management.
  4. Just as it is difficult to find a person capable of doing product management and product marketing at the same time very well, it is difficult to find a person capable of doing product management and project management at the same time.
  5. Project management is not a step in the product management career, nor is product management a step in the project management career.
  6. Good project managers are as valuable as good product managers.
  7. Having a good project manager to manage your projects will help you be a better product manager.
  8. The less time a product manager spends managing projects, the more time she spends managing the product.
  9. To avoid conflicts between project management and product management, project managers, product managers, and the entire team involved in the project should agree on the goals shared by the team as much as possible.

Marty Cagan makes clear the need to separate these roles in one of his posts:

“For internet companies, it’s really important that the roles are separated. You’ll have trouble managing your releases if you don’t separate those roles, and your releases will always be late and longer than they should be.” — Marty Cagan

And how do agile methodologies view these functions?

Agile methodologies, specifically Scrum, have two clear roles in the team: one more focused on the project, the Scrum Master; and another one more product-focused, the product owner (PO):

  • Product Owner: a person responsible for maintaining the product backlog, which represents the interests of stakeholders.
  • Scrum Master: a person responsible for the Scrum process, ensuring that it is used correctly and maximizing its benefits.
  • Team: Multifunctional group of people responsible for managing themselves to develop the product.
  • Scrum Team: Product Owner, Scrum Master, and the Team.

There is an article on InfoQ written by Mark Levison in 2008 called Can Product Owner and Scrum Master be Combined? – where the theme of having a single person managing project and product is discussed. Both in the opinions that make up the text – and include testimonials from people like Mike Cohn and Ken Schwaber – as in the comments made by readers of the article, it is unanimous that, although it is possible to combine the two roles – and if the team is very small, it is even acceptable – the most recommended is that they are performed by different people.

And in real life?

All the reports seen are based on actual facts, but we know that each company has its own reality and context. So, what is better to do: leave these roles separate or combined?

Ideally, you should experiment and at some point, you will find a combination that suits you, the team you work with, and your business. Note that each group of people has its own dynamics, and what works in one group of people may not work for another.

At Locaweb, we have several teams developing different products, and each one has its own dynamics where the product manager assumes different responsibilities with respect to the team. In some, the responsibility for technical project management tasks – that is, taking care of product development, deployment and operation issues – is handled by a project manager, while at other times this responsibility is shared between the engineering leader and product manager.

On the other hand, in all teams, the product manager plays the role of project manager for all non-technical tasks. That is, she coordinates with the marketing team product communication, coordinates with legal and finance areas the product’s legal and tax requirements, supports marketing in training for sales teams and takes care of passing knowledge to the customer support team.

You must find a balance that makes sense to you, your team, and the company you work for. Be careful not to absorb all project management responsibilities. Try to share them with someone, especially the technical issues; otherwise, there will be no time left for you to manage your product.

Digital product education, coaching and advisory

I’ve been helping companies bridge the gap between business and technology through education, coaching, and advisory services on digital product development and management. Check here how I can help you and your company.

Newsletter

I write regularly about product management, product development, digital product leadership, and digital transformation. You can receive a notification whenever I publish a new article, without depending on any social network algorithms to notify you! Just subscribe to my newsletter.

Digital Product Management Books

Do you work with digital products? Do you want to know more about how to manage a digital product to increase its chances of success, solve its user’s problems and achieve the company objectives? Check out my Digital Product Management bundle with my 3 books where I share what I learned during my 30+ years of experience in creating and managing digital products:

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

Qual a Diferença Entre Gestão de Projetos e Gestão de Produtos?

Assim como com as funções de gestão de marketing de produtos e gestão de produtos que, conforme vimos no capítulo anterior, são bastante distintas, mas apresentam sobreposição; as funções de gestão de projetos e de gestão de produtos também são bem distintas, mas também apresentam bastante coisa em comum.

Antes de falar sobre a diferença entre essas funções, é preciso deixar claro a diferença de projeto e produto. Vou recorrer mais uma vez à Wikipédia:

Projeto
Um projeto em negócio e ciência é normalmente definido como um empreendimento colaborativo, frequentemente envolvendo pesquisa ou desenho, que é cuidadosamente planejado para alcançar um objetivo particular.
Fonte: https://en.wikipedia.org/wiki/Project

Produto
O termo produto é definido como “algo produzido pelo trabalho ou esforço” ou como “resultado de um ato ou processo” e tem sua origem no verbo produzir, do Latim produce(re), ‘fazer existir’.
Fonte: https://en.wikipedia.org/wiki/Product_(business)

Enquanto o projeto é um processo com começo, meio e fim; o produto é o resultado de um processo, de um esforço.

Veja na tabela abaixo as principais diferenças entre projeto e produto:

ProjetoProduto
Tem começo, meio e fim claramente definidos.Começo e meio são identificáveis, mas seu fim não.
Foco na entrega com um caminho bem delimitadoFoco no resultado com um objetivo bem definido
Escopo fechado definido no planejamentoTestes e validações de ideias guiam o caminho
Pode funcionar em cenários previsíveis Indicado para cenários e contextos voláteis

Para ajudar a tangibilizar essas diferenças, aqui vão alguns exemplos:

  • Locaweb: antes de ter um datacenter próprio, a Locaweb colocava seus servidores no datacenter da Embratel. Em um determinado momento, Em 2006 a Locaweb decidiu investir em seu próprio datacenter, o que claramente era um projeto. Na verdade, dois projetos, o projeto de construção do datacenter próprio e o projeto de migração dos servidores que estavam na Embratel para o datacenter próprio. Já os produtos da Locaweb (Hospedagem de Sites, Email Marketing, Loja Virtual, etc.) são claramente produtos.
  • Prédio: a construção de um prédio, desde sua concepção até a entrega das chaves é um projeto com fases bem difinidas. Por outro lado, depois que as chaves são entregues para os compradores, podemos olhar um prédio como um produto. Pessoas irão morar no prédio, alguns apartamentos serão alugados, outros serão vendidos, haverá reformas, gestão de condomínio, e assim por diante.
  • Casamento: a decisão de se casar e todo o processo de casamento é claramente um projeto, com a cerimônia de casamento, festa, lua-de-mel. Depois que acaba a lua de mel, e come’xa a vida de casado, devemos olhar o casamento como um produto, a vida de casado, os filhos e netos, a família, o dia-a-dia em família.

Então Gerir Projetos e Produtos são Duas Funções Distintas?

Sim. Enquanto se está gerindo um projeto, a preocupação é com o processo e com tudo o que o cerca, ou seja, se está no prazo, se tem tudo o que é necessário e se está sendo feito com a qualidade esperada.

Por outro lado, quando gerimos um produto, a maior preocupação é garantir que este resolva um problema do cliente a quem ele é destinado, e atenda aos objetivos da empresa.

Em um post de 2007 do blog How To Be A Good Product Manager – disponível em https://www.goodproductmanager.com/2007/09/24/product-management-vs-project-management/ –, o autor Jeff Lash lembra alguns pontos importantes que não devemos esquecer quando pensamos em gestão de projetos e gestão de produtos:

  1. Assim como todo produto precisa de um gestor de produtos, todo projeto precisa de um gestor de projetos.
  2. O fato de os gestores de produtos acreditarem que são capazes de gerir seus próprios projetos não significa que eles devam gerir seus próprios projetos.
  3. As competências, talentos e conhecimento envolvidos em gestão de projetos são bem diferentes dos envolvidos em gestão de produtos.
  4. Assimcomoédifícilencontrarumapessoacapazdefazer,ao mesmo tempo, gestão de produtos e marketing de produtos muito bem, é difícil encontrar uma pessoa capaz de fazer ao mesmo tempo gestão de produtos e gestão de projetos muito bem.
  5. Gestão de projetos não é um passo na carreira de gestão de produtos, nem gestão de produtos é um passo na carreira de gestão de projetos.
  6. Bons gestores de projetos são tão valiosos quanto bons gestores de produtos.
  7. Ter um bom gestor de projetos para gerenciar seus projetos vai lhe ajudar a ser um gestor de produtos melhor.
  8. Quanto menos tempo um gestor de produtos passar gerenciando projetos, mais tempo passará gerindo o produto.
  9. Para evitar conflitos entre gestão de projetos e gestão de produtos, os gestores de projetos, os gestores de produtos e todo o time envolvido no projeto devem acordar sobre os objetivos compartilhados pelo time o máximo possível.

Já Marty Cagan deixa clara a necessidade de separação desses papéis em um de seus posts – disponível em https://www.svpg.com/product-management-vs-project-management/:

“Para empresas de internet é realmente importante que os papéis sejam separados. Você vai ter problemas em gerenciar seus releases se você não separar esses papéis, e seus releases vão sempre atrasar e demorar mais do que deveriam.” – Marty Cagan

E Como as Metodologias Ágeis Veem Essas Funções?

As metodologias ágeis, mais especificamente o Scrum, têm dois papéis claros no time: um focado mais no projeto, o Scrum Master; e outro focado mais no produto, o Product Owner (PO):

  • Product Owner: pessoa responsável por manter o backlog do produto, que representa os interesses dos stakeholders. Scrum Master: pessoa responsável pelo processo Scrum, garantido que é usado corretamente e maximizando seus benefícios.
  • Team: grupo de pessoas multifuncional responsável por se gerenciar para desenvolver o produto.
  • Scrum Team: Product Owner, Scrum Master e o Time.

Há um artigo na InfoQ escrito por Mark Levison em 2008, chamado Can Product Owner and Scrum Master be Combined? (em uma tradução livre, “Product Owner e Scrum Master podem ser combinados?”) – disponível em http://www.infoq.com/br/news/2008/12/scrum-master-product-owner –, em que o tema de ter uma única pessoa gerindo projeto e produto é discutido. Tanto nas opiniões que compõem o texto – e que incluem testemunhos de pessoas como Mike Cohn e Ken Schwaber – quanto nos comentários feitos por leitores do artigo, é unânime que, apesar de ser possível combinar as duas funções – e, se o time for muito pequeno, é até aceitável –, o mais recomendado é que estas sejam desempenhadas por pessoas diferentes.

E na Vida Real?

Todos os relatos vistos são baseados em fatos reais, mas sabemos que cada empresa tem sua própria realidade e seu próprio contexto. Então, o que é melhor fazer: deixar esses papéis separados ou combinados?

O ideal é você ir experimentando e, em algum determinado ponto, você encontrará uma combinação que seja a mais adequada para você, para o time com quem você trabalha e para a sua empresa. Note que cada grupo de pessoas tem sua dinâmica própria, e o que funciona em um grupo de pessoas pode não funcionar para outro.

Na Locaweb, tínhamos vários times desenvolvendo diferentes produtos, e cada um tem sua dinâmica própria onde o gestor de produtos assume responsabilidades diferentes em relação ao time. Em alguns, a responsabilidade pelas tarefas de gestão de projeto técnico – cuidar de questões de desenvolvimento, deploy e operação do produto – é tocada por um gestor de projetos, enquanto que, em outros times, essa responsabilidade é compartilhada entre o líder técnico da equipe e o gestor de produtos.

Por outro lado, em todos os times, o gestor de produtos exerce o papel de gestor de projetos para todas as tarefas não técnicas. Isto é, coordena com o time de marketing a comunicação do produto, coordena com o jurídico e com o financeiro suas necessidades legais e fiscais, suporta marketing no treinamento para as equipes de vendas, e cuida de passar o conhecimento para a equipe de suporte técnico.

Enfim, procure encontrar um equilíbrio que faça sentido para você, para o seu time e para empresa que você trabalha, só tome cuidado para não absorver todas as funções de gestão de projetos. Procure dividi-las com alguém, principalmente as questões técnicas; caso contrário, não sobrará tempo para você gerir seu produto.

Educação, treinamento e aconselhamento em gestão de produtos digitais

Tenho ajudado empresas a conectar negócios e tecnologia por meio de educação, treinamento e aconselhamento em gestão e desenvolvimento de produtos digitais. Ajudo líderes de produto (CPOs, heads de produtos, CTOs, CEOs, tech founders, heads de transformação digital) a extrair mais valor e resultados de seus produtos digitais. Veja aqui como posso ajudar você e a sua empresa.

Newsletter

Escrevo reguIarmente sobre gestão de produtos, desenvolvimento de produtos, liderança de produtos digitais e transformação digital. Vc pode receber uma notificação por email sempre que eu publicar algo novo, sem depender dos algoritmos de notificação de redes sociais. Basta assinar minha newsletter.

Gestão de produtos digitais

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

Devemos ter uma equipe dedicada à correção de bugs?

Semelhante à pergunta sobre a equipe dedicada à inovação, esta é outra pergunta que tenho recebido muito em minhas sessões de coaching, por isso acredito que sua resposta também pode interessar a mais pessoas. Neste caso, a resposta curta é NÃO. Este tema não tem espaço para uma resposta do tipo “depende”. Vamos mergulhar mais fundo.

Seu código, seus bugs

Se você constrói algo, você é o único responsável por sua qualidade. Se o que você construiu não está funcionando como esperado, você é responsável por corrigi-lo. É tão simples quanto isso. Não faz sentido ter uma equipe diferente para corrigir bugs feitos por pessoas diferentes. As pessoas mais capazes de corrigir um bug são as pessoas que criaram o bug. Aliás, esse é o melhor incentivo para as pessoas criarem menos bugs.

E os sistemas legados?

Em um sistema legado, a equipe herda um código que não escreveu. Normalmente, as pessoas que escreveram o código não estão mais na empresa. Nesse caso, faz sentido ter uma equipe dedicada a corrigir seus bugs? O ideal é NÃO. O sistema legado deve ser responsabilidade de uma equipe, que resolverá os bugs, mas também trabalhará na melhoria e evolução do sistema legado. Uma estratégia muito comum para lidar com sistemas legados é a estratégia de estrangulamento, ou seja, drenar lentamente a vida de um sistema legado substituindo gradualmente partes dele por uma implementação moderna.

Outro aspecto importante do sistema legado é que não precisamos necessariamente corrigir seus bugs. Às vezes, corrigir um bug em um sistema legado pode custar muito, pois ninguém tem conhecimento suficiente para depurar o sistema. Em alguns casos, em vez de corrigir o bug corrigindo sua causa raiz, podemos aplicar alguma correção alternativa que faz o sistema legado entregar o resultado esperado. Nesses casos, podemos aplicar uma estratégia chamada “monitorar e aplicar workaround”, ou seja, assim que descobrirmos uma solução paliativa para um determinado bug, provavelmente desenvolvido fora do sistema legado, monitoramos o comportamento indesejado e, assim que o comportamento aparece, aplicamos automaticamente a solução paliativa. É a ideia de que, dependendo do estado geral de saúde do paciente, algumas doenças são mais bem tratadas com remédios do que com cirurgia.

Devemos dedicar X% do tempo à correção de bugs?

Novamente, a resposta é um simples NÃO. Já expliquei como é importante entregar produtos de boa qualidade:

Qualquer usuário prefere usar um produto de boa qualidade que se comporte conforme o esperado. Esta é uma condição sine qua non para proporcionar uma boa experiência ao usuário.

Além da experiência do usuário, há outro aspecto importante a ser considerado quando falamos de qualidade e bugs. Sempre que alguém precisa trabalhar para resolver um bug que foi encontrado em um produto digital, essa pessoa precisa parar de trabalhar no que estiver trabalhando no momento para resolver o bug. Esta é uma interrupção no fluxo de trabalho. Se essa pessoa fosse capaz de entregar o software sem esse bug, ela poderia continuar trabalhando em coisas novas sem interrupção, o que a tornaria mais produtiva.

Neste mesmo artigo há um gráfico interessante sobre o número de bugs corrigidos como percentual do total de entregas em Conta Azul. Passou de 45% para 65%, bem mais que os 20%. Quando vimos isso, trabalhamos para diminuir esse percentual, melhorando a qualidade do que implantamos.

% de bugs corrigidos

Em outra equipe, rastreamos a porcentagem de novos itens implantados e criamos deliberadamente OKRs para aumentar essa porcentagem. Em 2 anos conseguimos passar de 50% de novos itens implantados para 90% de novos itens implantados:

% de novos itens implantados

Na minha experiência, em vez de corrigir o % de esforço dedicado à correção de bugs, é mais produtivo focar na criação de código de qualidade, sem bugs. Para fazer isso, devemos rastrear a porcentagem de trabalho gasto na correção de bugs e gerenciar ativamente diminuir esse número.

Resumindo

  • Semelhante à pergunta sobre a equipe dedicada à inovação, esta é outra pergunta que tenho recebido muito em minhas sessões de coaching, portanto, sua resposta também pode interessar a mais pessoas. Neste caso, a resposta curta é NÃO. Seu código, seus bugs.
  • Se você herdar um sistema legado, terá que gerenciar um código que não escreveu. Gerenciar significa não apenas corrigir seus bugs, mas também trabalhar na melhoria e evolução do sistema legado, o que provavelmente incluirá uma estratégia de estrangulamento para mover gradualmente os recursos do sistema legado para a nova arquitetura.
  • Também não devemos usar porcentagem fixa de tempo alocada para corrigir bugs. É mais produtivo focar na criação de código de qualidade, sem bugs. Para fazer isso, devemos rastrear a porcentagem de trabalho gasto na correção de bugs e gerenciar ativamente esse número para diminuir.

Educação, treinamento e aconselhamento em gestão de produtos digitais

Tenho ajudado empresas a conectar negócios e tecnologia por meio de educação, treinamento e aconselhamento em gestão e desenvolvimento de produtos digitais. Ajudo líderes de produto (CPOs, heads de produtos, CTOs, CEOs, tech founders, heads de transformação digital) a extrair mais valor e resultados de seus produtos digitais. Veja aqui como posso ajudar você e a sua empresa.

Newsletter

Escrevo reguIarmente sobre gestão de produtos, desenvolvimento de produtos, liderança de produtos digitais e transformação digital. Vc pode receber uma notificação por email sempre que eu publicar algo novo, sem depender dos algoritmos de notificação de redes sociais. Basta assinar minha newsletter.

Gestão de produtos digitais

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

Qual o tamanho ideal de time?

No capítulo sobre estrutura de time do meu livro Liderança de produtos digitais, dei alguns exemplos reais de tamanho de equipe do Gympass, Conta Azul e Locaweb. No entanto, uma coisa que não está nesse capítulo é como definimos o tamanho ideal do time. Então, aqui está um artigo focado neste tópico, que acredito pode ser útil não apenas em tempos regulares, mas também agora que o financiamento de VCs parece estar diminuindo e as avaliações das empresas estão mais baixas.

Benchmark

Quando entrei no Gympass em 2018, a empresa já tinha 800 pessoas, mas a equipe de desenvolvimento de produto, ou seja, gerentes de produto, designers, engenheiros e pessoas de dados, eram apenas 32 pessoas, ou seja, 4% da empresa, o que parece bastante baixo. Logo depois que entrei na empresa, tive que apresentar ao conselho meu plano de aumentar essa equipe e decidi incluir um slide com um benchmark de algumas empresas de tecnologia conhecidas.

Benchamrk de tamanho de times de produto

Usei o Linkedin para obter algumas estimativas do tamanho da equipe de desenvolvimento de produtos dessas empresas em comparação com o número total de funcionários. A maioria está tendo entre 24% a 40% de sua força de trabalho na equipe de desenvolvimento de produtos. A exceção é a Apple, com 20%, mas precisamos considerar que eles são donos de todas as suas lojas físicas, então todos os vendedores dessas lojas também são seus funcionários. Conta Azul, Locaweb e Lopes são de minhas experiências passadas. A Lopes, uma imobiliária tradicional que trabalha em sua transformação digital, tinha cerca de 11% de sua força de trabalho em desenvolvimento de produtos. No Gympass conseguimos trazer de 4% em meados de 2018 para 18% no final de 2019.

O que fazer vs quanto investir

No entanto, não podemos definir o tamanho ideal da equipe apenas pelo benchmarking. Precisamos considerar outros fatores, de dentro da empresa:

  • o que fazer: a partir do objetivo da empresa e do entendimento dos problemas do usuário, criamos nossa visão e estratégia de produto. Ter isso claro nos ajuda a definir o que precisamos fazer para executar essa estratégia, quais resultados e objetivos queremos atingir, e a equipe necessária para executar essa estratégia. Por exemplo, no Gympass, fazíamos produtos para academias, RHs de clientes e seus funcionários, então decidimos ter equipes dedicadas a cada um desses participantes de nosso marketplace. Além disso, precisávamos de ferramentas para gerenciar os pagamentos recebidos dos RHs e funcionários, e que tínhamos que fazer para as academias, então também tínhamos uma equipe focada nisso. Eram o que chamávamos de equipes de produto, que geravam resultados para o Gympass como mais usuários e menos trabalho operacional manual. Além das equipes de produto, tínhamos também equipes estruturais para cuidar de temas como SRE, ferramentas comuns a todos os times de produto, Dados e Segurança, conforme expliquei no artigo sobre estrutura de times. Esses times de produto e estruturais tinham suas próprias visões e estratégias alinhadas com a visão e estratégia global, e com base nisso propuseram suas próprias estruturas de time. Por exemplo, no Gympass, a equipe focada no funcionário de nossos clientes decidiu se dividir em duas equipes, uma focada em crescimento, ou seja, ajudar os funcionários a saberem que a empresa oferece o Gympass, fazendo com que os funcionários baixem o aplicativo, criem uma conta e se inscrevam no serviço. A outra equipe estava focada na experiência digital, ou seja, ajudar o funcionário a tirar o máximo proveito do Gympass, encontrando e usando academias, atividades e aplicativos de bem-estar adequados. O que fazer é um dos direcionadores para definir a estrutura e o tamanho do time.
  • quanto investir: por outro lado, precisamos saber quanto estamos planejando investir nessa equipe. Montar uma equipe de desenvolvimento de produtos custa dinheiro. Suponha que com base no que definimos que queremos fazer, criamos uma estrutura de time de desenvolvimento de produto que requer 15 pessoas. Vamos considerar R$ 6.000 como salário médio mensal das pessoas de sua equipe. Considerando todos os encargos, 13º salário e férias, isso custaria pra a empresa R$ 9.600 por mês. Então o custo mensal total dessa equipe é de R$ 144.000 ou R$ 1.728.000 por ano. É muito dinheiro. Essa equipe trará resultados para a empresa, mas às vezes os resultados podem demorar para serem gerados. Em todos os novos produtos que construímos e lançamos, enquanto não lançamos e começamos a receber alguma receita, essa equipe só vai gerar custos. Temos dinheiro para investir todo mês para pagar os salários e encargos trabalhistas dessa equipe, enquanto ela não gerar os resultados? Note que aqui estou considerando somente salário, sem bônus e stock options.

Por isso, precisamos saber quanto podemos investir e o que precisamos fazer para definir o tamanho ideal da nossa equipe de desenvolvimento de produtos.

Tamanho da equipe em uma crise

Há algum tempo atrás, passamos pela crise do COVID-19 e agora estamos enfrentando uma crise econômica que está fazendo com que os investimentos dos VCs diminuam e façam valuations mais baixos do que tínhamos antes de 2022. Muitas startups estão tendo que fazer demissões por causa dessa situação. Até empresas como Google, Meta e Apple mencionaram que vão desacelerar as contratações.

Então, qual deve ser o tamanho do time de desenvolvimento de produtos em uma crise? Bem, nessa situação quanto investir é o fator a ser considerado. Precisamos reduzir o quanto investimos em nossa equipe de desenvolvimento de produtos? Quanto de redução? Qual o impacto dessa redução no que temos que fazer e nos resultados que podem ser gerados por essa equipe? Ter menos pessoas fará com que a equipe deixe cair algumas bolas, ou seja, é preciso tomar uma decisão sobre o que parar de fazer. Alguns objetivos e resultados devem ser despriorizados, pois teremos que demitir algumas pessoas e teremos uma equipe menor. É simples assim. Menos dinheiro implica em equipe menor, o que implica em menos coisas que essa equipe poderá fazer e, consequentemente, menos objetivos e resultados podem ser priorizados.

Resumindo

  • O benchmarking é uma boa maneira de entender o tamanho da equipe de desenvolvimento de produtos. Através do Linkedin, podemos obter boas estimativas do número de pessoas nas equipes de desenvolvimento de produtos em comparação com o número de funcionários de muitas empresas.
  • No entanto, também devemos olhar para fatores internos para definir o tamanho ideal da equipe de desenvolvimento de produto. Quanto temos para investir e o que precisamos fazer são os dois fatores internos a serem considerados.
  • Em situações de crise, podemos precisar diminuir o investimento na equipe de desenvolvimento de produtos, o que pode fazer com que o tamanho da equipe diminua. Menos dinheiro implica em equipe menor, o que implica em menos coisas que essa equipe poderá fazer e, consequentemente, menos objetivos e resultados podem ser priorizados.

Mentoria de líderes de produto

Tenho ajudado líderes de produto (CPOs, heads de produtos, CTOs, CEOs, tech founders, heads de transformação digital) a extrair mais valor e resultados de seus produtos digitais. Veja aqui como posso ajudar você e a sua empresa.

Gestão de produtos digitais

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

Crescimento: Seja um “Data Geek”

Dê uma olhada nos dados que o seu produto gera! Além de conversar com seus usuários e obter feedback deles, uma maneira obrigatória de conhecer o seu produto e como os usuários interagem com ele é por meio de dados. Para poder tirar proveito desses dados, você deverá se transformar em um data geek, uma pessoa que conhece profundamente os dados gerados pela sua aplicação e seus significados.

Em Deus nós acreditamos. Todos os outros devem trazer dados.
W. E. Deming

William Edwards Deming é um engenheiro, estatístico e professor americano bastante conhecido pelo seu trabalho no Japão, logo após a II Guerra Mundial, onde ele ensinou sobre gestão estatística da qualidade, e ajudou os japoneses a se transformarem em 10 anos na segunda maior economia do mundo em apenas 10 anos. Tudo se resume a coletar e confiar nos valiosos dados do cliente.

Quais Dados são Importantes?

Todos os dados são importantes, mas, dependendo do que você está querendo entender, uns são mais importantes do que outros. Conhecer seus dados é uma tarefa contínua, pois a cada novo conhecimento que você adquire, aparecem novas questões, que vão precisar de mais dados para serem respondidas.

Uma das primeiras informações que você vai querer conhecer é quantas visitas você recebe no site de seu produto. Para conhecer esses números, você pode usar algum relatório de estatísticas que o provedor de hospedagem oferece. Outra opção muita usada é o Google Analytics.

Com um relatório como esse, você consegue algumas informações importantes, tais como: quantidade de visitas, quantidade de visitantes únicos, quantidade páginas vistas (pageviews) e várias outras. Dependendo do sistema de estatísticas que você estiver usando, você também conseguirá ver:

  • qual a primeira e a última página visitadas durante um acesso ao seu site;
  • de onde (que país e cidade) vêm seus visitantes;
  • se eles acessaram seu site partindo de uma campanha de Google AdWords, do Facebook;
  • ou de alguma outra campanha online que você está fazendo;
  • ou se acharam seu site de forma orgânica, digitando diretamente o endereço;
  • ou buscando por algo em algum sistema de busca.

Vale lembrar que é importante ter esses relatórios de acesso não só para o seu site como também para seu produto software.

Cuidado, pois esses sistemas de relatório de visitas normalmente dão uma quantidade muito grande de informação, e é fácil se perder nesse mar de dados.

Junto com a quantidade de visitas e acessos que seu site tem, outros dados importantes que você precisa conhecer de seu produto web são:

  • Quantidade de pessoas que ficam sabendo que seu produto existe: é possível diferenciar as formas como as pessoas ficam sabendo que seu produto existe classificando-as em duas categorias, as pagas e as gratuitas. As pagas são aquelas em que você tem de investir algum dinheiro, como Google AdWords, anúncios no Facebook, anúncio em sites de conteúdo (preferencialmente ligados ao tema de seu produto) e anúncios em revistas (também preferencialmente ligados ao tema de seu produto). Já as gratuitas são aquelas em que você investe tempo e trabalho para ficar conhecido como, por exemplo, criar conteúdo relevante sobre o tema do seu site, interagir em blogs sobre o tema do seu produto, facilitar que as pessoas recomendem seu produto para seus conhecidos etc. O retorno nesse caso é mais lento, mas tem a vantagem de não ter custo financeiro, só de tempo e trabalho.
  • Quantidade de cliques gerados pelos seus anúncios ou por outros meios: essa é uma informação um pouco mais difícil de obter, pois, dependendo de sua estratégia para atrair pessoas para o seu site, essa informação não estará disponível. Os sistemas de anúncio online como Google AdWords, Facebook e anúncios em sites de conteúdo normalmente têm essa informação disponível, e o preço que cobrarão normalmente será baseado em um preço por clique.
  • Quantidade de visitantes únicos: são os novos visitantes que seu site recebe. É diferente da quantidade de visitas, pois uma mesma pessoa pode visitar seu site mais de uma vez até decidir comprar.
  • Quantidade de visitantes que se tornaram usuários: desses visitantes únicos, alguns vão se cadastrar para se tornar um usuário do seu sistema. Se você oferecer um período de experiência gratuito ou uma versão grátis sem prazo de expiração, esse número pode ser razoavelmente grande.
  • Quantidade de usuários que se tornaram clientes: findo o período de experiência, alguns de seus usuários vão querer se tornar um cliente, ou seja, vão querer pagar para usar o seu serviço. Se você estiver oferecendo uma versão gratuita de seu produto, sem prazo de expiração, você deverá ter uma versão paga que motive seus usuários a saírem da versão gratuita e a pagarem pelo uso de seu produto.

Funil de Conversão

Napoleão Bonaparte, líder político e militar francês conhecido pelas Guerras Napoleônicas – por meio das quais foi responsável por estabelecer a hegemonia francesa sobre a maior parte da Europa no início do século XIX –, teve uma grande derrota em 1812, na Campanha da Rússia. Essa campanha foi uma gigantesca operação militar intentada pelos franceses e seus aliados, que teve grande impacto sobre o desenrolar das Guerras Napoleônicas, marcando o início do declínio do Primeiro Império Francês. Nessa campanha, Napoleão usou 580.000 combatentes. Desses, sobreviveram apenas 22.000 combatentes, o restante pereceu no caminho da França até Moscou devido às dificuldades encontradas nesse caminho (frio, chuva, rios etc.).

Campanha da Rússia

Essa imagem lembra muito um funil de conversão de um site, que pode ser feito com os dados que discutimos anteriormente. O funil de conversão nos mostra quantos potenciais clientes estamos perdendo no caminho entre atrair pessoas para o site até o ponto em que uma pessoa paga para se tornar seu cliente:

Funil de conversão

O funil apresenta várias oportunidades para você entender melhor como seus usuários interagem com seu produto. Cada pedaço do funil tem suas características específicas e pode ser alargado de diferentes formas. Concentre-se em um pedaço por vez e faça seus testes. Na pior das hipóteses, se o teste for ruim, você sempre pode voltar para a situação anterior. Para um data geek, o funil deve ser o primeiro foco de dados a se obter e analisar.

No próximo capítulo, vamos ver mais duas métricas que são a consequência natural do funil de conversão: o engajamento, que mostra como seu usuário utiliza seu produto; e o churn, que mostra quantos usuários deixam de usá-lo, ajudando a identificar por que isso acontece.

Gestão de produtos digitais

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

Mentoria e aconselhamento em desenvolvimento de produtos digitais

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

Cone of Uncertainty is another reason why we need to deliver early and often

I already wrote about 3 reasons why it is important to deliver your product early and often to your users. Now I want to give you a 4th reason, based on the Cone of Uncertainty concept from the project management world.

First, let’s understand what is the Cone of Uncertainty:

In project management, the Cone of Uncertainty describes the evolution of the amount of uncertainty during a project. At the beginning of a project, comparatively little is known about the product or work results, and so estimates are subject to large uncertainty. As more research and development is done, more information is learned about the project, and the uncertainty then tends to decrease. (Wikipedia)

In an image, we can picture it like this:

Cone of Uncertainty

This image shows that the farther away we are from the end of a project, the bigger the uncertainty. At the beginning of a project, the uncertainty ranges from 0.25x to 4x. For instance, if we are estimating the delivery time for a specific project as 4 months, at beginning of the project this estimation will range from 1 month to 16 months. This is A LOT of uncertainty!

However, this is the theory. When we analyze projects in real life, the majority of them have their estimation smaller than what actually happens. It’s quite rare to see projects being delivered before their original estimation. So we can better represent the Cone of Uncertainty as follows:

Cone of Uncertainty in real life

This picture shows that the probability of an estimation being 2x to 4x times what was originally estimated is greater than the estimation being right or even greater than what actually happens. That’s the reason why many people, when providing an estimation, tend to increase this estimation to increase the chances of the estimation being more accurate.

The solution: releasing early and often

The best way to reduce uncertainty is to release early and often. Besides the 3 reasons I already explained previously:

  • Moment of truth: you will only get real feedback when your product is in front of people using it in their own context.
  • Too many features: the more feature you add to the product, the bigger the chances to add unnecessary features.
  • Return on investment: the earlier you release some part of your product, the earlier you’ll start to recover your investment in you building this product.

To add to these 3 reasons, let’s check what happens to the Cone of Uncertainty when we release early and often:

The iterative approach to the Cone of Uncertainty

As we can see, when we deliver early and often, we are lowering the range of uncertainty. In the example above we lowered the range of each delivery from between 0.25x and 4x to 0.8x to 1.25 times. This approach is very well suited to digital products because we can break down deliveries to the smaller delivery possible.

So there we are, the fourth reason to deliver early and often is the Cone of Uncertainty, the earlier you release some part of your product, the smaller will be its uncertainty.

Digital Product Management Books

Do you work with digital products? Do you want to know more about how to manage a digital product to increase its chances of success, solve its user’s problems and achieve the company objectives? Check out my Digital Product Management bundle with my 3 books where I share what I learned during my 30+ years of experience in creating and managing digital products:

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

Mentoring and advice on digital product development

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

Cone da Incerteza é outra razão pela qual precisamos entregar com antecedência e com frequência

Já escrevi sobre os 3 motivos pelos quais é importante entregar seu produto cedo e com frequência para seus usuários. Agora eu quero te dar uma 4ª razão, baseada no conceito Cone da Incerteza do mundo do gerenciamento de projetos.

Primeiro, vamos entender o que é o Cone da Incerteza:

No gerenciamento de projetos, o Cone da Incerteza descreve a evolução da quantidade de incerteza durante um projeto. No início de um projeto, comparativamente pouco se sabe sobre o produto ou os resultados do trabalho e, portanto, as estimativas estão sujeitas a grande incerteza. À medida que mais pesquisa e desenvolvimento são feitos, mais informações são aprendidas sobre o projeto e a incerteza tende a diminuir. (Wikipédia)

Em uma imagem, podemos imaginar assim:

Cone da Incerteza

Esta imagem mostra que quanto mais longe estamos do final de um projeto, maior a incerteza. No início de um projeto, a incerteza varia de 0,25x a 4x. Por exemplo, se estamos estimando o tempo de entrega de um projeto específico em 4 meses, no início do projeto essa estimativa varia de 1 mês a 16 meses. Isso é MUITA incerteza!

No entanto, esta é a teoria. Quando analisamos projetos na vida real, a maioria deles tem sua estimativa menor do que realmente acontece. É muito raro ver projetos sendo entregues antes de sua estimativa original. Assim, podemos representar melhor o Cone da Incerteza da seguinte forma:

Cone da Incerteza na vida real

Esta imagem mostra que a probabilidade de uma estimativa ser 2x a 4x vezes o que foi originalmente estimado é maior do que a estimativa estar correta ou ainda maior do que o que realmente acontece. Essa é a razão pela qual muitas pessoas, ao fornecer uma estimativa, tendem a aumentar essa estimativa para aumentar as chances de a estimativa ser mais precisa.

A solução: liberar cedo e frequentemente

A melhor maneira de reduzir a incerteza é liberar cedo e com frequência. Além dos 3 motivos que já expliquei anteriormente:

  • Momento da verdade: você só terá um feedback real quando seu produto estiver na frente de pessoas que o utilizam em seu próprio contexto.
  • Muitas funcionalidades: quanto mais funcionalidades você adicionar ao produto, maiores serão as chances de adicionar recursos desnecessários.
  • Retorno do investimento: quanto mais cedo você liberar alguma parte do seu produto, mais cedo você começará a recuperar seu investimento na construção desse produto.

Para adicionar a esses 3 motivos, vamos verificar o que acontece com o Cone of Uncertainty quando lançamos mais cedo e com frequência:

Abordagem iterativa do Cone da Incerteza

Como podemos ver, quando entregamos cedo e com frequência, estamos diminuindo o alcance da incerteza. No exemplo acima, reduzimos o intervalo de cada entrega entre 0,25x e 4x para 0,8x e 1,25 vezes. Essa abordagem é muito adequada para produtos digitais porque podemos dividir as entregas na menor entrega possível.

Então ai estamos, o quarto motivo para entregar cedo e muitas vezes é o Cone da Incerteza, quanto antes você liberar alguma parte do seu produto, menor será a incerteza.

Gestão de produtos digitais

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

Mentoria e aconselhamento em desenvolvimento de produtos digitais

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

What’s the difference between product and project?

I already wrote about the difference between product management and project management but I believe there’s room to go a bit deeper on the differences between product and project. So, a quick remembering of the definitions of product and project:

Project

A project in business and science is usually defined as a collaborative venture, often involving research or design, that is carefully designed to achieve a particular goal.

Source: Wikipedia

Product

The term product is defined as “something produced by work or effort” or as “the result of an act or process” and has its origin in the Latin verb produce(re), ‘make exist’.

Source: Wikipedia

That is, while the project is a process with a beginning, and an end; the product is the result of a process.

Product and project differences

The above definitions can be expanded to help understand a bit more the differences:

  • While in a project we focus on the delivery with a well defined path, in a product we focus on the result with well defined objectives.
  • While in a project we have a clearly defined scope during the planning, in a product we use tests and idea validation to define next steps.
  • While a project approach may work in predictable situations, a product approach is useful in more volatile contexts.
  • While a project has clear and well defined end, a product is not designed to have a finite end in the foreseeble future.

To help us better understand these differences, I’ll provide one example from the tech world and two analogies from our daily lives.

  • At Locaweb, from the very beginning to around 2007 we used third-party Data Center services to host all of our services. As we grew, it made more sense to build our own data center and move our servers to this new data center, where we had better control and lowered costs. Building Locaweb’s own data center and moving all the servers to this data center can be easily identified as a project. On the other hand, all Locaweb services (Hosting, E-mail, eCommerce, etc.) can and must be managed as products. Even the data center, after being ready, was (and is) managed as a product.

And now the two analogies from our daily lives to help illustrate the difference between project and product::

  • A new apartment building construction is typically a project, including all the planning needed not only to build the building but also to sell all its apartment units. On the other hand, as soon as the building is ready for use and families move into their new apartments comes a phase where we can view the building as a product: apartment maintenance, condo management, renting, acquisition.
  • When two people get married, it’s easy also to see a project and a product. The marriage ceremony, party, honeymoon, moving in together, all of these events must be managed as projects. On the other hand, your daily life with your marriage partner, living together, growing a family, having children, grandchildren can be seen as a product.

Finite and infinite games

Simon Sinek, author of “Start with Why” and “Leaders Eat Last”, launched in 2019 a very interesting book called “The Infinite Game” where he built on top of the argument from the classic book “Finite and Infinite Games”, by James P. Carse, an American academic who was Professor Emeritus of history and literature of religion at New York University. In his book, Carse explains that while a finite game has an end and a clear winner, like sports, politics, and war, infinite games, like our life, cities, countries, carreer, are those activities that has no clear and defined end and not necessarily a winner. According to Carse:

A finite game is played for the purpose of winning, an infinite game for the purpose of continuing the play.

Sinek “started to see that many of the struggles that organizations face exist simply because their leaders were playing with a finite mindset in a game that has no end. The leaders who embrace an infinite mindset, in stark contrast, build stronger, more innovative, more inspiring organizations.”

It’s easy to see that projects are finite games while products are infinite games.

When I’m asked about the difference between a project and a product, I’ve been using the two analogies above, apartment building and marriage to help illustrate these concepts, with good feedback. Hopefully now that I was able to write down these concepts and analogies, they can help more people.

Digital Product Management Books

Do you work with digital products? Do you want to know more about how to manage a digital product to increase its chances of success, solve its user’s problems and achieve the company objectives? Check out my Digital Product Management bundle with my 3 books where I share what I learned during my 30+ years of experience in creating and managing digital products:

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

Mentoring and advice on digital product development

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

Qual a diferença entre produto e projeto?

Já escrevi sobre a diferença entre gerenciamento de produtos e gerenciamento de projetos, mas acredito que há espaço para aprofundar um pouco mais as diferenças entre produto e projeto. Então, uma rápida lembrança das definições de produto e projeto:

Projeto

Um projeto em negócios e ciência geralmente é definido como um empreendimento colaborativo, muitas vezes envolvendo pesquisa ou design, que é cuidadosamente projetado para atingir um objetivo específico.

Fonte: Wikipédia

Produto

O termo produto é definido como “algo produzido por trabalho ou esforço” ou como “o resultado de um ato ou processo” e tem sua origem no verbo latino produzir(re), ‘fazer existir’.

Fonte: Wikipédia

Ou seja, enquanto o projeto é um processo com início e fim; o produto é o resultado de um processo.

Diferenças de produto e projeto

As definições acima podem ser expandidas para ajudar a entender um pouco mais as diferenças:

  • Enquanto em um projeto focamos na entrega com um caminho bem definido, em um produto focamos no resultado com objetivos bem definidos.
  • Enquanto em um projeto temos um escopo claramente definido durante o planejamento, em um produto usamos testes e validação de ideias para definir os próximos passos.
  • Enquanto uma abordagem de projeto pode funcionar em situações previsíveis, uma abordagem de produto é útil em contextos mais voláteis.
  • Enquanto um projeto tem um fim claro e bem definido, um produto não é desenhado para ter um fim em um futuro previsível.

Para nos ajudar a entender melhor essas diferenças, darei um exemplo do mundo da tecnologia e duas analogias do nosso dia a dia.

  • Na Locaweb, desde o início até por volta de 2007, utilizávamos serviços de Data Center de terceiros para hospedar todos os nossos serviços. À medida que crescemos, fez mais sentido construir nosso próprio data center e mover nossos servidores para esse novo data center, onde tínhamos melhor controle e custos reduzidos. Construir o próprio data center da Locaweb e mover todos os servidores para este data center pode ser facilmente identificado como projetos. Por outro lado, todos os serviços da Locaweb (Hospedagem, E-mail, eCommerce, etc.) podem e devem ser gerenciados como produtos. Até o data center, depois de pronto, foi (e é) gerenciado como um produto.

E agora as duas analogias do nosso dia a dia para ajudar a ilustrar a diferença entre projeto e produto::

  • A construção de um novo prédio de apartamentos é tipicamente um projeto, incluindo todo o planejamento necessário não apenas para construir o prédio, mas também para vender todas as suas unidades de apartamentos. Por outro lado, assim que o prédio está pronto para uso e as famílias se mudam para seus novos apartamentos, chega uma fase em que podemos fazer a analogia do prédio como um produto: manutenção do apartamento, administração do condomínio, aluguel, aquisição.
  • Quando duas pessoas se casam, também é fácil ver um projeto e um produto. A cerimônia de casamento, festa, lua de mel, morar juntos, todos esses eventos devem ser gerenciados como projetos. Por outro lado, o seu dia-a-dia com seu parceiro de casamento, morar junto, formar uma família, ter filhos, netos podem ser vistos como um produto.

Jogos finitos e infinitos

Simon Sinek, autor de “Start with Why” e “Leaders Eat Last”, lançou em 2019 um livro muito interessante chamado “The Infinite Game” onde construiu em cima do argumento do clássico livro “Finite and Infinite Games”, de James P. Carse, um acadêmico americano que foi professor emérito de história e literatura da religião na Universidade de Nova York. Em seu livro, Carse explica que enquanto um jogo finito tem um fim e um vencedor claro, como esportes, política e guerra, jogos infinitos, como nossa vida, cidades, países, carreira, são aquelas atividades que não têm um fim claro e definido. e não necessariamente um vencedor. De acordo com Carse:

Um jogo finito é jogado com o propósito de ganhar, um jogo infinito com o propósito de continuar o jogo.

Sinek “começou a ver que muitas das dificuldades que as organizações enfrentam existem simplesmente porque seus líderes estavam jogando com uma mentalidade finita em um jogo que não tem fim. Organizações mais inspiradoras têm uma mentalidade de jogos infinitos.”

É fácil ver que projetos são jogos finitos enquanto produtos são jogos infinitos.

Quando me perguntam sobre a diferença entre um projeto e um produto, tenho usado as duas analogias acima, prédio de apartamentos e casamento para ajudar a ilustrar esses conceitos, com bom feedback. Espero que agora que consegui escrever esses conceitos e analogias, eles possam ajudar mais pessoas.

Gestão de produtos digitais

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

Mentoria e aconselhamento em desenvolvimento de produtos digitais

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

Medindo e gerenciando a produtividade

Como podemos andar mais rápido? Como podemos entregar mais com o mesmo time? Por que temos a impressão de que o time está lento? Quando o time era menor, parecia que ele conseguia entregar mais. Esses são questionamentos e afirmações muito comuns que ouço sobre times de desenvolvimento de produto. Toda empresa que tem um time de desenvolvimento de produtos digitais gostaria que esse time fosse mais rápido. Neste capítulo vou mostrar as duas ferramentas essenciais para conseguir ter times mais rápidos e produtivos.

Medição

Não há como melhorar algo que não se mede. O que é velocidade de desenvolvimento de produto? É importante haver uma definição clara dessa métrica e consequente mensuração.

No meu último ano na Locaweb, estávamos nos focando bastante em produtividade, ou seja, em como os times de desenvolvimento de produto e de software da Locaweb poderiam produzir mais, sem precisarmos colocar mais gente nos times, e sem que a qualidade das entregas caísse.

O gráfico seguinte mostra nossos números. Contabilizamos quantidades de entregas por semana e, como dá para ver, em algumas semanas mais do que quadruplicamos a quantidade de entregas por semana.

Quantidade de entregas por semana na Locaweb

Esse aumento de produtividade aconteceu quando o time cresceu apenas 10% em quantidade de pessoas, logo, não dá para creditar esse aumento de produtividade ao aumento de pessoas nos times.

Quando há um aumento desses, além do natural questionamento sobre se o aumento de produtividade se deve ao aumento de pessoas nos times, outro questionamento que existe é se houve queda da qualidade das entregas. Uma das medições de qualidade que fazemos é a quantidade rollbacks. Como é possível perceber a seguir, mesmo com o aumento de produtividade, a quantidade de rollbacks foi reduzida em 40%!

Quantidade de rollbacks por semana na Locaweb

Na Locaweb fizemos uns cálculos estimados de entregas por semana no período de setembro de 2015 a fevereiro de 2016. O cálculo foi bem simples, total de deploys feitos no período dividido pelo número de semanas. Passamos, então, a comunicar toda a empresa sobre as entregas da semana.

Depois que cheguei à Conta Azul, decidimos implementar o mesmo tipo de controle de entregas semanais e acabamos conseguindo também um bom aumento da produtividade.

Quantidade de entregas por semana na Conta Azul

Tanto na Locaweb quanto na Conta Azul, cada gestor de produtos me mandava na sexta-feira as entregas da semana, eu compilava os dados e anotava a quantidade de cada semana, gerando esses gráficos. A partir do momento em que começamos a medir, ficou mais claro o nível em que estávamos, e as ações que passamos a fazer visando o aumento de produtividade começaram a mostrar resultado no gráfico. Além disso, os times passaram a usar uma única ferramenta de medição, o Jira, o que deu a eles uma visão melhor de progresso de cada time e permitiu comparações com troca de experiência, isto é, algo como “olha que interessante o seu gráfico, como vocês conseguiram aumentar esse indicador?”.

No Gympass, como escalamos a equipe muito rapidamente, decidimos controlar o número de entregas por pessoa por semana. Contamos as pessoas que ingressaram 2 meses antes, uma vez que as pessoas precisam de 1 a 2 meses para se tornarem produtivas. Em um trimestre, conseguimos aumentar em 16% nossa produtividade por pessoa. O número de entregas era extraído diretamente do JIRA.

Quantidade de entregas por semana no Gympass

Na Gympass, também medimos o número de deploys, tanto em nosso core, conhecido como monólito, quanto em microsserviços. Também conseguimos um aumento considerável em um ano.

Quantidade de deploys por mês no Gympass

Na Lopes, assim que um deploy era feito, um email era enviado com uma lista dos itens “deploiados”. Uma das primeiras coisas que fiz foi compilar esses relatórios em uma planilha para construir o gráfico adiante. Daí foi fácil notar que os deploys não aconteciam todos os dias. Aconteciam em média uma vez por semana. Assim que notamos isso, definimos OKRs para aumentar a frequência de deploys, o que vem surtindo efeito. Os OKRs que definimos foram:

  • Objetivo: Aumentar a cadência de deploys em produção;
  • KR: Aumentar o número de deploys por semana para no mínimo 3 (quanto mais melhor);
  • KR: Reduzir o número máximo de novas features por deploy para no máximo 10.
Quantidade de deploys por dia na Lopes

O que impacta a produtividade

A produtividade de um time de desenvolvimento de produto é impactada por vários fatores. Certa vez encontrei um artigo bem interessante escrito por Michael Dubakov, fundador da empresa Targetprocess onde ele mostra um mapa mental com todos os elementos que podem impactar positiva ou negativamente a produtividade de um time de desenvolvimento de produto. Esse artigo não está mais disponível mas, graças ao site Wayback Machine, é possível acessá-lo em:

http://web.archive.org/web/20150827162352/http://www.targetprocess.com/articles/speed-in-software-development/

O mapa mental é este aqui:

Mapa mental da Targetprocess sobre o que impacta a produtividade

Este diagrama mostra coisas e atividades que afetam a velocidade de desenvolvimento de alguma forma. Verde significa que uma atividade aumenta a velocidade. Quanto mais você tiver, melhor. Amarelo indica que existe algum máximo. Por exemplo, você pode acumular dívida técnica e aumentar a velocidade, mas, se acumular muito, isso o atrasará significativamente. O vermelho mostra coisas que retardam o desenvolvimento, quanto menos você tiver, melhor. A seta verde indica efeito crescente. Por exemplo, o trabalho focado aumenta a velocidade de desenvolvimento. A seta vermelha indica efeito decrescente. Por exemplo, melhores habilidades de desenvolvimento diminuem a complexidade do sistema (bons engenheiros criam sistemas menos complexos).

O que gosto dessa imagem é que ela mostra quão complexo é esse tema e quantas coisas podem impactar positiva ou negativamente a velocidade do time. Na Conta Azul acompanhávamos esse tema todo trimestre na Product Council, reunião em que conversávamos sobre o planejamento trimestral do time de desenvolvimento de produto com a liderança. Tinha um slide onde elencávamos todos os temas que podiam impactar a velocidade para discutirmos o que estávamos fazendo sobre cada um desses tópicos.

Temas que impactavam a velocidade do time de desenvolvimento de produto da Conta Azul

Coloque o tema produtividade no centro da discussão

Não há bala de prata, com cada time que trabalho foram várias ações que tomamos e sempre tivemos a certeza de que sempre há mais ações que poderão ser tomadas para aumentar a produtividade ainda mais.

A única bala de prata que existe é transformamos produtividade em tema importante de nossas conversas. Todos passaram a conversar sobre produtividade e sobre o que poderíamos fazer para melhorá-la.

Esse movimento nos fez iniciar várias mudanças e experimentos que nos ajudaram a aumentar consideravelmente nossa produtividade. Se você também quer aumentar a produtividade de seu time de desenvolvimento de produtos, coloque isso como tema central de suas conversas e experimente bastante. Você verá como há espaço para melhorar bastante a produtividade dos seus times de desenvolvimento de software.

Outro ponto importante: não deixe para discutir o tema produtividade esporadicamente. Minha recomendação é que você o faça semanalmente. Criar uma cadência semanal dará oportunidade de, a cada semana, experimentar com algo novo e discutir os resultados com o time.

Resumindo

  • Não existe bala de prata para aumentar a produtividade de um time de desenvolvimento de produto. Contudo, existem sim duas ferramentas essenciais para ajudar nesse objetivo.
  • A primeira ferramenta é medição. Não há como melhorar algo que não se mede. O que é velocidade de desenvolvimento de produto? É importante haver uma definição clara dessa métrica e consequente mensuração.
  • A segunda ferramenta é trazer o tema produtividade para o centro da discussão. Todos do time de desenvolvimento de produto são responsáveis pela produtividade do time. Por isso, ao trazer o tema para o centro da discussão, todos poderão colaborar para melhorar a produtividade.

No próximo capitulo veremos como outra métrica que tem impacto direto na produtividade, a qualidade.

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: