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.

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 lutas 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.”

É 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:

Pessoas: prioridade nº 1, sempre

Toda empresa possui sua própria cultura e, dentro de cada empresa, todo departamento também possui sua própria cultura. Além disso, cada pessoa tem seus princípios e valores que norteiam seus passos pela vida. Neste e nos próximos capítulos vou falar sobre a cultura, os valores e os princípios que acredito serem obrigatórios para criar produtos digitais de sucesso. E também, quais são os 4 principais valores que toda equipe de desenvolvimento de produtos e, consequentemente, toda empresa que tenha times de desenvolvimento de produtos digitais deve ter.

Vou começar esta parte do livro compartilhando meus princípios pessoais de liderança. Serão cinco:

  • Pessoas: a prioridade nº 1, sempre
  • Liderar é como ser um médico
  • Liderando sob pressão
  • Mentoria é uma via de mão dupla
  • Como e quando delegar

Falarei desses princípios ao longo deste e dos próximos capítulos, a começar pelo princípio de que pessoas são a prioridade nº 1, sempre.

Muitas vezes vejo empresas afirmando que a valorização da empresa, a receita, o crescimento, o lucro, o número de clientes, ou a satisfação do cliente é sua prioridade número 1. Todas são boas prioridades e cada uma é apropriada para contextos específicos em que uma empresa pode estar. No entanto, eu argumento que elas devem ser prioridade número 2, 3, 4 e assim por diante, porque nossa prioridade número 1 deve sempre ser as pessoas que fazem parte nossa equipe. Sem as pessoas que trabalham conosco, será muito difícil, se não impossível, atingir qualquer outro objetivo que tenhamos.

Gastamos dinheiro e energia atraindo as melhores pessoas e convencendo-as a se unirem à nossa empresa para construir o que pretendemos construir para atingir a meta que estabelecemos. Pagamos a elas para estarem conosco durante todo o processo de construção e normalmente ficamos chateados quando perdemos pessoas da nossa equipe, especialmente se elas estiverem realmente engajadas e alinhadas com nossos objetivos. Portanto, as pessoas da nossa equipe são como clientes, gastamos dinheiro e energia para adquiri-las e retê-las. Mas elas são ainda mais importantes do que nossos clientes, porque sem a nossa equipe, não há como sermos capazes de lidar com nossos clientes e alcançar nossos objetivos.

Isso não significa que precisamos ser “bonzinhos” com nossa equipe, ou que devemos dar tudo o que eles pedem. O que precisamos fazer é equilibrar as pressões externas e internas para que as pessoas possam melhorar continuamente. Se a pressão externa estiver aumentando, precisamos criar o ambiente e fornecer as ferramentas para que as pessoas fiquem mais motivadas, tenham mais drive e aumentem sua força interior. E se temos pessoas ou equipes com excesso de motivação e de energia, precisamos dar a elas mais responsabilidades e objetivos mais elevados. No capítulo Liderando sob pressão vou falar mais sobre esse equilíbrio.

Maçãs podres

O termo maçã podre, apesar de bastante forte, serve para descrever uma situação bastante delicada na formação e gerenciamento de times. Chamamos de maçã podre a pessoa que destoa negativamente do resto do time e que, com seu comportamento, poderá estragar a equipe.

A InfoQ (https://www.infoq.com/news/2009/01/handling-your-underperformer/) falou bastante sobre esse tema da maçã podre do ponto de vista técnico, o under-performer, aquele que é ou está tecnicamente abaixo do resto da equipe e mostrou como o time pode ajudar essa pessoa a melhorar.

Agora, o que fazer quando nos deparamos com uma maçã podre do ponto de vista comportamental? Alguém que é tecnicamente bom, mas que tem problemas de comportamento? Tecnicamente essa pessoa pode ter bastante para contribuir para o time mas seu comportamento faz com que o time não consiga ter um bom relacionamento com essa pessoa.

Nesses casos há dois caminhos a seguir:

  • O mais simples é tirar essa pessoa do time. Essa é uma solução fácil tanto para o time quanto para o seu líder. A tendência numa situação dessas é o time isolar a pessoa difícil até que ela, por vontade própria ou por decisão do chefe, saia do time.
  • O caminho mais difícil, mas que certamente trará mais benefícios para a equipe, é ajudar essa pessoa difícil a se integrar ao time ao ponto de ela deixar de ser uma maçã podre.

É fácil receber no time pessoas fáceis de lidar. O desafio é receber uma pessoa difícil e ajudá-la a se integrar ao time. Os valores do time devem ser mais fortes que os valores da pessoa difícil ao ponto de os valores do time serem absorvidos e assumidos pela pessoa difícil.

Conversas francas com todo o time e com a pessoa difícil são um bom caminho. A transparência é essencial. Se houver boa vontade e disposição tanto do time quanto da “maçã podre”, há boas chances de a situação ser revertida.

Vale lembrar que, na maioria das vezes, uma maçã podre não quer ser maçã podre. Ele pode não se dar conta de que seu comportamento é prejudicial para o time. Ele pode ter tido experiências anteriores onde seu comportamento seria considerado normal. Por isso vale investir em ajudar o time e a pessoa difícil a se entenderem. Contudo, não dá para tentar indefinidamente fazer com que as coisas se ajeitem. É importante definir um prazo para reavaliar a situação e, caso ela não tenha se resolvido, talvez não haja outra opção a não ser tomar uma decisão mais difícil: dispensar uma ou mais pessoas do time.

Resumindo

  • As pessoas são, e devem ser sempre, a prioridade número 1 de qualquer empresa. Gastamos dinheiro e energia para adquirir e reter as melhores pessoas. Ter as pessoas como a prioridade número 1 é a chave para atingir qualquer outro objetivo. Isso não significa ser “bonzinho”, dando tudo o que elas querem, e sim que devemos ser capazes de equilibrar os desafios que damos às pessoas para que possam melhorar continuamente.
  • A pessoas maçãs podres podem drenar e prejudicar seu time. Você deve ajudar essas pessoas a se encaixarem em seu time e, se isso não for possível, você deverá tomar a decisão mais difícil: tirá-la do time.

No próximo capítulo vamos entender como deve ser o trabalho de um líder por meio da analogia de que liderar é como ser um médico.

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:

Relationships

As I commented in the chapter Roles, responsibilities and seniority, expectations management is something that occupies between 50 to 80% of the time of a head of product. Your daily routine revolves around your relationships and interactions with many people inside and outside your organization who are interested in the product you lead. In corporate jargon, these people are called stakeholders:

In the last decades of the 20th century, the word stakeholder has been increasingly used to mean a person or organization that has a legitimate interest in a project or entity. When discussing the decision-making process for institutions – including large companies, government agencies and non-profit organizations – the concept was expanded to include everyone with an interest or stake in what the entity does.

Source: https://en.wikipedia.org/wiki/Stakeholder_(corporate)

Evolution of the use of the word stakeholder in the literature (Source: Google Ngram Viewer)

A product manager with some experience knows the importance of maintaining good relationships with product stakeholders. I will share here two tools that help to better map these stakeholders and how your relationship with each one should be.

RASCI

RASCI is a very useful tool to help define and understand the roles and responsibilities of each person and function. It is the abbreviation of the first letters of the possible roles that a person, area or function can have in a task:

  • Responsible: is the person responsible for executing the task, that is, who has to lead the effort to plan, do and complete the task. There cannot be more than one responsible. Remember the saying that a dog with two owners dies of hunger.
  • Accountable: is the person responsible for the task and who has the power to delegate to the responsible the task to be done. Responsible and accountable can be the same person. The rule also applies that there cannot be more than one accountable per task. If responsible and accountable are two different people, the accountable can be seen as the sponsor.
  • Support: are the people or teams that work together and under the coordination of the responsible for the execution of the task.
  • Consulted: are the people or teams who do not participate in the execution of the task, but who need to be consulted before or while the task is being performed, as they can provide relevant inputs for its execution.
  • Informed: are the people or teams who do not participate in the execution of the task, nor need to be consulted before or while the task is being performed, but who need to be informed when the task is completed.

The following is an example of a RASCI responsibility matrix between engineering, UX, product marketing and product management that we used at Locaweb:

Locaweb’s RASCI responsibility matrix

How to use

The first step is to build the responsibility matrix. My recommendation is to fill this table by bringing together in a room all the people involved, so you can discuss whether the division of responsibility is ok for everyone and if there is a task missing. Most likely, some “shared responsibilities” will appear, but this is a great time to discuss them and define who is responsible. There can be only one person responsible for any task.

Then, the team should try to do the tasks following the responsibility matrix for some time, like one or two months. Then, it is important to do a retrospective to see if everything is ok, or if any adjustment is needed.

From then on, the use becomes automatic and people will no longer need to refer to the responsibility matrix. Every year or when a question arises, or even when a new task arises, it is good to revisit it.

Power-Interest Grid

The Power-Interest Grid is a concept first developed in the 90s by Aubrey L. Mendelow, and later explained in the book “Making Strategy: Mapping Out Strategic Success”, by Fran Ackermann and Colin Eden. Based on the power and interest that a person or team has in your product, you can classify them into 4 main categories.

Power-interest grid
  • The players are those who have great power and interest in your product. You need to collaborate with them often. The users and customers of your product are players, you need to collaborate with them to build the best product that solves their problems and meets their needs. In some companies, probably the closest founder to the product is also a player. You should invite these people to any meeting where strategic decisions are made. Schedule individually to present the decisions and ask for their comments and contributions.
  • The subjects are those with little power, but high interest in your product. They do not have the power to veto or change decisions, but they do have a deep interest in your product. In some companies, we can think of customer support, sales and marketing as examples of areas that play the role of subjects. They have great interest, but they do not have the power to change the product. You can communicate with them via weekly status email and product demos. It is important to collect their opinions, but remember that they do not have the power to change your decisions.
  • The context setter are those with the power to change your product, but little interest in your product. Examples of areas that can play a role of context setter are HR and Legal. If HR doesn’t help you build the team, you won’t have a team to build your product. If Legal is not aware of and aligned with the legal aspects of your product, it has the power to block or delay its launch. A CFO and a controller are also two functions that have the power to change decisions that affect your product. It is important to keep context setters well informed about product decisions. Consult with them before making important decisions. Keep them informed weekly.
  • The crowd is the one with low power and little interest. Even if they have little power and interest, it is important to keep them informed. Usually, a monthly update on the progress of the product is sufficient. It can be by email or in a monthly general meeting with product demos – I’ll talk about this and other meetings in another chapter. Usually it is people in the HR, Legal, Administrative and Financial areas who are not in the context setting group.

It is important to note that each company has its own dynamics, therefore, an area or person that plays a specific role in the power-interest grud of a given company may have another role in a different company.

Empathy

These two tools are very useful for the head of product to better understand how to relate to their stakeholders and how to manage their expectations, which, as I already said, will take 50% to 80% of her time.

Empathy is a fundamental tool for the head of product to be able to manage its stakeholders. As I commented in the chapter “Developing the team and managing expectations”, empathy is the ability of one person to put himself in the place of another to understand his expectations. Their desires, motivations, needs and problems.

This characteristic is important for the head of product to understand the customers and users of the product, to know how they relate to it, and what problems they expect to solve or what needs they want to be met. It also helps to understand the impact of your product on your team and people in other areas. Last but not least, the head of product also needs to put herself in the shoes of the owner of the product, to understand their expectations on the results the product will bring to the company.

Summing up

  • Expectation management is anywhere from 50 to 80% of a head of product’s time.
  • RASCI is a very useful tool to help define and understand the roles and responsibilities of each person and function.
  • The Power-Interest Grid, together with RASCI, is a great tool to help you better understand and interact with your stakeholders.
  • But don’t forget, the main tool that a head of product needs to better understand and, consequently, have improved and fruitful interactions with its stakeholders is empathy.

In the next chapter we will understand more about how to hire people for the team.

Digital Product Management Books

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

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

Release early and often

In the previous chapters we saw my personal leadership principles:

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

Product culture

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

Let’s start with the first one: Release early and often.

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

Moment of truth

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

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

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

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

Too many features

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

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

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

Return on investment

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

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

Return on investment

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

Postponed return on investment

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

Antecipated return on investment

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

LinkedIn founder Reid Hoffman once said that:

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

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

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

MMF – Minimal Marketable Feature

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

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

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

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

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

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

Summing up

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

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

Update

There’s a fourth reason to release early and often. It’s the Cone of 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? Check out my Digital Product Management bundle with my 3 books where I share what I learned during my almost 30 years of experience in creating and managing digital products:

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

Leadership anti-patterns

An anti-pattern is a common but ineffective and counterproductive response to a problem. This term was coined by Andrew Koenig in 1995, inspired by the 1994 book Design Patterns: Elements of Reusable Object-Oriented Software by Gamma Erich, Helm Richard, Johnson Ralph, and Vlissides John, who lists a series of software development design patterns that their authors found simple, succinct and effective for the most common problems.

The term was popularized by the book AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis by Raphael Malveau, William Brown, Hays McCormick, and Thomas Mowbray, which extended its use beyond the software design field to refer informally to any bad solution to a problem.

Wikipedia anti-pattern page lists over 70 antipatterns. I will list below the anti-patterns that I have encountered most often in my career. These anti-patterns that I quote below happen when the company’s leadership does not have enough experience in digital product development and is advised by people who have been successful in managing software development in the past, but who have not updated themselves.

As I explained in the introduction, software development is a very new science, especially when compared to other sciences like astronomy, medicine, mathematics, chemistry, civil engineering, etc. The first time a computer stored software in memory and successfully ran it was at 11 am on June 21, 1948, at the University of Manchester, on the Manchester Baby computer. This means that software product development is in its infancy. If a professional does not keep up to date, the knowledge and experience that has made him successful in the past may not be the most suitable to make him successful in the future.

Documentation

Excessive use of documentation will undoubtedly slow down the product development team. It is not for nothing that in the Agile Manifesto, written in 2001, we say that we value “Software in operation more than comprehensive documentation”. Unfortunately, for some leaders documentation is even more important than the product itself. Nothing can go into production if it is not properly documented.

The last time I wrote a PRD (Product Requirement Document or Product Requirements Document) was in 2005 right when I joined Locaweb. A very time-consuming job, where I documented in detail everything we needed to implement in the product. I passed to engineering and sometime later the implementation was made with many errors because the engineers ended up not understanding what was written in some parts and decided to implement it as they saw fit. From that, we started to decrease the use of extensive documentation and increased the interaction between product managers, product designers, and engineers.

Marty Cagan has a very cool article called How to write a good PRD where he comments at the beginning:

I provide this document here mainly for historical purposes. It was written in 2005 to reflect best practices from previous decades.

I have not advocated the use of PRDs for many years, starting around 2007. It is not that PRDs are so bad. However, if the product manager is spending his time writing the PRD, then it is unlikely that he or she is doing the actual product discovery work.

Recommended pattern: just follow the agile manifest, product in the hands of customers brings more value to customers and the company than comprehensive and detailed documentation.

Focus on data

It happens when the head of product and other leaders only make decisions if there is an abundance of data, reports, charts. There are two dangers with this anti-pattern:

  • time: sometimes it takes a long time to gather all the necessary data. It is the situation known as analysis paralysis. Nothing happens until the data is meticulously obtained and analyzed. Often, after a first analysis, more data is requested and more time is invested in the search for this new data, and this cycle can be repeated over and over again. And, while this cycle is repeated, no decision is made. Hence the paralysis of the analysis.
  • errors: when we rely solely and exclusively on data there is a great chance that we will incur errors. How can we be sure that we have all the data needed to complete the analysis? How can we be sure that the data is correct? It is common to hear that decisions must be data-driven, that is, based on data. However, as stated above, the data may be incorrect and / or insufficient to describe a particular situation. Thinking about it, more recently the concept of data-informed decisions has emerged, that is, decisions are based on data, but not only on data. They take into account qualitative information, previous experience, and intuition in addition to data.

Recommended standard: make decisions based on data, but always understanding that the data is incomplete, and always take into account qualitative information, previous experience, and intuition.

Big rewrite

Every company has legacy systems. Even a startup that was just created, in a few months will be able to look at its code base as a legacy and something that needs to be improved. At that moment we start to hear phrases like:

  • It is increasingly difficult to deal with the code.
  • If I were to do it from scratch, it would be much faster.
  • If we don’t rewrite, it will get slower and more dangerous to change the code.

And at that moment, the great solution of rewriting was born. And this major rewrite will, at some point, cause a product evolution freeze. Why write something for the legacy, if the new system will replace it? And there is also migration or transition. How will we go from the legacy system to the new one?

Normally, in the initial estimates, the rewriting will take about 2 or 3 months and when we move forward we realize that it will be a little longer, and may take years. At Locaweb we made the decision to rewrite the central system that managed customer data and collection. The original project was forecast to take 9 months and ended up taking more than two years. In addition, when the new system came in, our customer billing did not work for about 2 months and stayed for another 6 months running incorrectly until we finished all the necessary adjustments. That is, the rewriting that originally would take 9 months ended up taking 3 years.

Recommended pattern: avoid major rewrites at all costs. Most of the time, there will be ways to replace the legacy system gradually and progressively, without causing disruption to the company and customers.

Wishlist

When a new head of product joins a new company, it is common during the onboarding process, during the numerous conversations with people from various areas of the company, to hear a series of requests and complaints regarding the product that this new head will take care. To “score points” with these people, who will eventually give feedback on the head of product’s work, he may be tempted to build his list of what to do based on these reported requests and problems. It is the company’s “wish list”. Then, this product head will prioritize this list or even outsource this prioritization to a leader in the company’s sales or business area. I’ve seen situations where the product head collects the “wish list” and presents it at a meeting with leaders from various areas of the company and says “now I need you to prioritize what you want the product development team to do first “.

Although it is somewhat tempting because the “wish list” will actually help the head of product to score points with the leaders of other areas, this behavior will make the product development team become a mere order taker and feature factory, inhibiting the innovation potential that this team can bring to the business. When the head of product focuses the team on delivering the “wish list”, it ends up focusing the team on being an implementer of solutions that are given by other people, taking the team’s focus on the problems to be solved. It is the difference between the team that implements solutions that are already envisioned by other areas of the company versus a team focused on deeply understanding the company problems and then finding the best solutions to solve these problems. I’ll talk more about this in the part about principles.

Recommended standard: product development team works to understand problems and then evaluate possible solutions. So go find the list of problems to work on, not the list of things that other areas want the product development team to do.

Summing up

  • Anti-patterns are common but ineffective responses to problem-solving. There are many well-documented anti-patterns in the world of digital product development. The 4 most common anti-patterns in product development leadership are documentation, focus on data, big rewriting, and wish list.
  • Documentation, which should be kept to a minimum, for certain leaders is even more important than the product itself. Nothing can go into production if it is not properly documented.
  • Focus on data is when any and all decisions have to be made with data, without taking into account qualitative information, previous experience, and intuition.
  • Big rewrite happens when a new product head finds a system written some time ago and identifies that it will be better to rewrite a new system from scratch than to improve the current system.
  • Wishlist comes from the need for the new product head to please all stakeholders, focusing on the product development team to only implement what is requested, delegating prioritization to other areas of the company.

With this chapter, we finish part 1 on the Concepts needed to understand the roles and responsibilities of a product head. In the next part, we will see which Principles should guide the work of a head of product and his team.

Missing something?

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

Digital Product Management Books

Do you work with digital products? Do you want to know more about how to manage a digital product to increase its chances of success? While you wait for my new book, check out my Digital Product Management bundle with my 2 books where I share what I learned during my almost 30 years of experience in creating and managing digital products.

What is the difference between project management and product management?

In this series of articles where I write about the relationship between product management and the other areas of the company, I wrote about:

Now I want to write about the relationship between project management and product management.

As with the functions of product marketing and product management which, as we saw in the previous article, 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

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, middle, and end; product is the result of a process.

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, i.e., 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 article at 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.”

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: the person responsible for maintaining the product backlog, which represents the interests of stakeholders.
  • Scrum Master: the 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 entitled 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 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.