Essa é a primeira parte do resumo do livro Inspired: how to create tech products customers love, muito famoso na área de Produto, do autor do Marty Cagan.
Boa leitura!
__________________________
Esse livro (2ª edição) aparece na lista de várias pessoas que eu admiro na área de produtos. Sendo isso motivo suficiente para que eu o colocasse na minha lista também.
Mas além do fator indicação, o livro me chamou atenção pela experiência do autor, que trabalhou em empresas incríveis, como HP e Ebay, e orientou muitas mais através da SVPG, e pelo tema, já que o livro traz conteúdo sobre produtos digitais, trabalhando o tema “do início ao fim” do abc, ou melhor dizendo, trazendo conteúdo para quem está começando do zero e avançando no tema conforme as páginas vão sendo viradas.
Decidi comprá-lo e, para a minha surpresa, não encontrei uma versão brasileira, ou seja, a escolha teria que ser ler em inglês. O que me causa uma certa tristeza, pois apesar de ter bastante familiaridade com leitura em inglês, sei que não é o caso da maioria dos brasileiros, e, no sonho de que o Brasil se torne referência em produtos digitais, a falta de conteúdo em português é uma BAITA barreira.
Por isso, enquanto uma tradução não chega, por que não fazer um resumo e disponibilizar pra quem quer, mas ainda não consegue ler em inglês, certo?
Bom, vamos lá. O Marty (que já chamo pelo primeiro nome de tão íntima que fiquei do livro) divide o livro em 5 partes, e assim também será nosso resumo.
Parte 1 do Livro Inspired – Lições das principais empresas de tecnologia
No primeiro capítulo Marty conta um pouco sobre a sua jornada, começando em meados dos anos 80 como um engenheiro de software na Hewllet Packard (mais conhecida como HP) em um produto de grande importância na época.
A fim de dar contexto para o livro, conta que depois de um ano trabalhando em um produto que tinha como base Inteligência Artificial, ao lançá-lo no mercado, ninguém o comprou e o produto foi um completo fracasso, apesar de ser tecnicamente impressionante. O ponto é que, ninguém queria ou precisava da solução que o produto apresentava.
A conclusão dessa experiência foi a de que não importa quão bom o time de engenharia seja, se eles não receberem algo que valha a pena ser desenvolvido.
O papel de encontrar e definir algo que valha a pena é do Product Manager (que seria traduzido como Gerente de Produto, mas vamos apelidar aqui de PM), mas a maioria das empresas não é boa na matéria de criar produtos, por isso, depois disso ele dedicou sua carreira a entender mais sobre isso.
Seguindo em frente, ele destaca que o trabalho de PM é um trabalho de tempo integral devendo ter como objetivo principal resolver problemas reais de clientes, de um jeito que case com as necessidades do negócio.
A definição do o que faz um Product Manager poderia ser encaixada em basicamente todos os tipos de empresa, afinal, existem vários tipos de produtos, mas no Inspired o foco são produtos digitais, de base tecnológica (que podem misturar experiências online e offline).
As principais causas de fracasso de produtos
Apesar da definição parecer simples, a verdade é que a maioria dos produtos falham. E existe um padrão no processo que a maioria das empresas que tem produtos que falham usam:
- Tudo começa com ideias. Na maioria das empresas as ideias estão vindo de áreas internas (executivos ou stakeholders chave) ou de fora (clientes ou potenciais clientes), resumindo-se em um monte de coisas que várias pessoas querem que sejam feitas.
- A maioria das empresas querem priorizar essas ideias em roadmaps, com o objetivo de garantir que o time está trabalhando nas coisas mais importantes e para ter uma noção de quando determinada ideia estará pronta. Para isso, provavelmente são feitas reuniões anuais ou trimestrais de planejamento na qual os líderes consideram as ideias e definem o roadmap.
- Mas para poderem considerar as ideias, os líderes geralmente pedem “Business Cases”, que giram em torno de definir quanto de dinheiro ou valor aquela ideia irá gerar, e quanto de dinheiro e tempo ela irá custar.
- Depois de definido o roadmap de prioridades, a equipe de produto começa a trabalhar, cabendo ao Product Manager conversar com Stakeholders para levantar requisitos e comunicar aos designers e engenheiros o que eles precisam construir.
- Uma vez que os UX Designers (Designers de Experiência do Usuário) criam o design visual e determinam as interações, os requerimentos são passados para o time de engenharia, que, pode ou não estar usando de uma metodologia ágil, e, depois de construída e testada, a ideia é, finalmente, liberada para os usuários.
Nesse processo, que diga-se de passagem não é, de forma alguma, ágil e sim um processo cascata, independente se o time de engenharia trabalha com alguma metodologia ágil, existem diversos problemas, que são falados durante o decorrer do livro, mas para destacar alguns:
- Na etapa inicial do processo não temos ideia de quanto determinada funcionalidade irá gerar de receita ou quanto irá custar, já que afinal nessa fase não sabemos o quão bem a solução irá desempenhar na prática e que a maioria delas não gera absolutamente nada, além de não sabermos o que de fato vamos construir, portanto uma previsão de custo é extremamente difícil.
- Roadmaps acabam sendo uma lista de features e projetos priorizados, mas a verdade é que a maioria das ideias ali colocadas não vão funcionar e se funcionarem vão ser necessárias várias interações com clientes para que aquela ideia gere o valor necessário para o negócios (time to money). Então qual o ponto de se apegar com uma lista de features?
- O trabalho do Product Manager nesse modelo está mais para um Gerente de Projetos. O Designer acaba entrando muito tarde no processo, restando o trabalho de apenas “passar batom no porco”. Os engenheiros também entram muito tarde, restando apenas o trabalho de construir com base nos requisitos, e não são capazes de inovar.
- O processo é muito centrado no projeto, sendo voltado para a entrega de features, enquanto times de produto devem estar voltados para a entrega de resultados.
- A validação com o usuário acontece muito tarde, somente depois de ter sido gasto muito tempo de dinheiro construindo algo, que tem grandes chances de não gerar resultados. É o jeito mais caro e lento de testar algo.
Além do Lean e Agile
No que se trata de métodos como Lean e Agile, é importante dizer que eles não são balas de prata que podem e devem ser usados para tudo, resolvendo todos os problemas. O mais importante sobre essas metodologias é entender quais são os princípios nos quais elas são baseadas e usá-las de forma eficiente para o seu contexto. E os principais princípios dessas metodologias na sua visão são:
- Riscos são assumidos no começo, e não no final, ou seja, é melhor arriscar e falhar antes de decidir construir algo do que depois do produto já pronto.
- Produtos são definidos e projetados colaborativamente, ao invés de sequencialmente, melhor dizendo, fugimos do modelo cascata onde produtos são definidos por líderes que repassam o que deve ser feito para os times de produto. Em times fortes, produto, design e engenharia trabalham lado a lado, em uma relação de troca, para levantar soluções.
- É tudo sobre resolver problemas, não sobre implementar funcionalidades. Produtos convencionais são sobre entrega, enquanto bons times estão preocupados não só com a implementação da solução, mas também em garantir que a solução resolve o problema. Trabalhar com produto é sobre gerar resultados de negócio e não sobre entregar features.
Produto Holístico
Mas afinal, o que é um produto? De forma holística, um produto inclui funcionalidades (features), tecnologia (que possibilita a funcionalidade), experiência do usuário (que apresenta a funcionalidade), como monetizamos, como atraímos e adquirimos usuários e clientes, assim como experiências offline, caso essas sejam essenciais para entregar o valor do produto. Como se pode ver, um produto não é composto de apenas features, e, por isso o trabalho de um time de produto não é apenas trabalhar na implementação dessas.
Discovery e Delivery
Sendo assim, falando sobre o trabalho dos times de Produto, existem duas atividades essenciais em todos eles, que são: Descobrir o produto que deve ser criado e entregar esse produto no mercado.
Essas duas atividades estão sempre andando em paralelo dentro do time, cabendo a parte de descobrir o produto a ser criado primariamente ao PM e ao Designer. Apesar disso, o processo de descoberta (conhecido como Discovery no Brasil) é uma colaboração entre todo o time, sendo extremamente importante o envolvimento e engajamento do time de engenharia nesse processo.
No discovery separamos as boas ideias das ruins, ao levantar e colocar a prova vários dos riscos que giram em torno de uma nova ideia. O resultado dessa atividade é um backlog validado, e o objetivo é diminuir os riscos antes de escrever sequer uma linha de código.
O discovery envolve fazer uma série de experimentos rápidos e de baixo custo para levantar evidências que determinada ideia vale a pena ser construída e levada ao mercado, e para isso, em determinados momentos usamos protótipos, que podem ser de vários tipos, mas essencialmente devem custar menos tempo e esforço do que construir o próprio produto, e ajudam a invalidar ou validar uma proposta com usuários e/ou stakeholders.
Por sua vez, a entrega (Delivery), é feita essencialmente pelos engenheiros, que desenvolvem, testam e entregam o produto validado ao mercado.
Product Market Fit e Visão de Produto
Uma vez entregue o produto ao mercado, é importante que consigamos atingir o Product/Market Fit, que é um passo importante para atingir a visão do produto. Conceitualmente Marty entra em mais detalhes sobre esses dois tópicos adiante.
MVP – Mínimo Produto Viável
O conceito de MVP é destacado ao final desta parte do livro, para lembrar desse que é um dos maiores conceitos do mundo de produtos.
A verdade é que a maioria dos times trabalha duro para entregar um MVP, às vezes por meses ou anos, sendo que este deveria ter sido feito em semanas ou talvez horas, e que na maioria das vezes os líderes ficam confusos e envergonhados dos produtos que o time está tentando entregar aos usuários.
Marty fala em horas ou semanas, tendo em vista que um MVP NUNCA deveria ser um produto (num contexto no qual produto se define como algo que os engenheiros possam entregar com confiança, clientes possam usar para gerir negócios, e você possa vender e dar suporte), e sim, deveria ser um protótipo.
Construir um produto, mesmo que com o mínimo de funcionalidades para aprender, geralmente gera grandes perdas de tempo e de dinheiro, o que não é nada Lean.
__________________________
E é assim que finalizamos a Parte 1 do livro Inspired, com um contexto geral e conceitos chaves do mundo de produtos. Mais a frente, todos os conceitos falados nessa primeira parte são detalhados, falando sobre composição do time, roadmaps, visão de produto, discovery e muito mais.
Confira a Parte 2 e a Parte 3 que já estão disponíveis aqui no blog também.
Este conteúdo foi escrito por Letícia Rezende, aluna da PM3 e também Product Manager na Zup Innovation.
Que tal conhecer mais sobre a gestão de produtos digitais?
Se quer se tornar um Product Manager mais preparado(a) para enfrentar o mercado, baixe a ementa do curso referência em produto no país e aprenda com 17 instrutores de empresas como OLX, Nubank, Booking.com, iFood, Creditas, Grupo ZAP, entre outras grandes Tech companies brasileiras.
