Como Ter Sucesso Numa Fábrica de Funcionalidades Enquanto Gestor de Produto (com Aakash Gupta, o Especialista em Crescimento de Produto)

Ler a transcrição:

Estamos a experimentar transcrever os nossos podcasts através de um programa de software. Perdoe quaisquer erros tipográficos, pois o bot não está correto a 100% do tempo.

Hannah Clark: Fábrica de funcionalidades: nome. Definição: uma empresa de software focada em criar e lançar constantemente novas funcionalidades, em vez de desenvolver um produto que os utilizadores realmente desejem. Utilizado numa frase: «Pensei que tinha sido contratado para orientar a equipa de produto numa nova direção arrojada, mas, em vez disso, estou apenas a trabalhar numa fábrica de funcionalidades.»

Diga-me: a sua fotografia estaria junto dessa definição no dicionário? A sua e a de milhares de outros gestores de produto, meu amigo. Portanto, se é assim que as coisas são, o que pode fazer a esse respeito?

O meu convidado de hoje é Aakash Gupta, que escreve a icónica newsletter Product Growth. Antes de se dedicar a tempo inteiro à newsletter, Aakash passou os últimos 12 anos em funções de produto sénior e executivas em empresas como a Epic Games, a Affirm e a Apollo, o que significa que experienciou praticamente todos os níveis de influência que um gestor de produto pode ter.

E, como pode imaginar, Aakash está muito familiarizado com as circunstâncias que criam fábricas de funcionalidades, e o seu manual para gerir enquanto gestor de produto nestas organizações é extremamente prático e refrescantemente realista. Este é um episódio ao qual vai querer prestar muita atenção até ao fim, por isso, vamos começar.

Bem-vindos de volta ao podcast The CPO Club.

Aakash, muito obrigado por ter arranjado tempo para falar connosco hoje.

Aakash Gupta: Com todo o gosto. É um prazer estar aqui. E obrigado pelo convite.

Hannah Clark: O prazer é nosso. Pode falar-nos um pouco sobre o seu percurso profissional e sobre como chegou onde está hoje?

Aakash Gupta: Quando comecei em gestão de produto, por volta de 2008, sinto que a disciplina ainda não estava tão desenvolvida. Penso que o livro INSPIRED foi publicado nessa altura. Acho que isso ajudou realmente em muitas coisas. Antes disso, talvez houvesse um artigo de Ben Horowitz sobre o bom e o mau gestor de produto. Mas, fora isso, a área ainda não era verdadeiramente profissionalizada. Na verdade, existia sobretudo em empresas e startups do Silicon Valley.

Fui apresentado à área porque os fundadores da startup onde trabalhava eram seguidores fervorosos de tudo o que dizia respeito à Y Combinator. E muitas empresas da Y Combinator tinham gestores de produto naquela altura. Por isso, apesar de trabalhar numa startup com apenas seis pessoas quando entrei, entrei como gestor de produto. Felizmente, tinha formação em engenharia, por isso já tinha programado muitas aplicações e tinha experimentado utilizar o Photoshop.

Assim, quando comecei, fazia praticamente tudo. Concebi o nosso site na totalidade, concebi e redesenhei grandes partes da nossa aplicação, apesar de ter competências de design muito limitadas. E, relativamente ao nosso site, geria o nosso CMS e toda a tecnologia por detrás dele. Fazia de tudo enquanto gestor de produto numa fase inicial, à medida que tentava perceber o que era a gestão de produto e aprendia em que consistia, mas era realmente um estilo de startup.

Depois fui trabalhar na minha própria startup, chamada Rap to Beats. E aí fazia basicamente a mesma coisa, mas programava ainda mais. Criava muitas mais versões da aplicação. Por isso, entrei na gestão de produto com esta experiência de construtor. A partir daí, passei para a verdadeira gestão de produto numa empresa chamada thredUP, que é agora uma empresa cotada em bolsa.

Entrei quando estava na série C e saí na série E. Em conjunto, criámos muitas das primeiras equipas de crescimento. Em 2014, se bem se lembra, o programa de referências da Uber era o tema do momento. Lembro-me de que, quando lançámos o nosso programa de referências, se tornou um enorme motor de crescimento. Podíamos fazer coisas simples como essa.

Nem sequer estava otimizado. Comecei a lançar produtos e percebi que, enquanto gestor de produto, podíamos mudar fundamentalmente a trajetória de crescimento das empresas. Foi então que me dediquei verdadeiramente à prática da gestão de produto. Desde então, fui gestor de produto em empresas como a Google, a Affirm e a Epic Games e, mais recentemente, na Apollo.io, onde fui vice-presidente de Produto. Agora trabalho a tempo inteiro na newsletter.

Hannah Clark: Excelente. E sei que muitas pessoas gostam muito dela.

Hoje vamos concentrar-nos nas fábricas de funcionalidades e, mais especificamente, em como os gestores de produto podem sobreviver numa organização desse tipo. Atualmente, é quase um palavrão no setor.

Comecemos pelo princípio. Como é que as organizações se transformam em fábricas de funcionalidades e porque é que este é um resultado tão comum?

Aakash Gupta: Na verdade, acho que todos os caminhos conduzem à fábrica de funcionalidades. Imaginemos que está num ambiente com autonomia, no sentido clássico. O que aconteceu nos últimos quatro ou cinco anos foi uma de algumas coisas.

Por exemplo, no caso da Airbnb, o fundador retomou o controlo e disse: «Está bem, estas são algumas das coisas que quero que sejam construídas.» Ou pode ter acontecido que os líderes de produto tenham assumido o controlo através de muitos despedimentos e reorganizações. Muitas vezes, utilizam reorganizações constantes como forma de colocar pessoas em posições e criar produtos e funcionalidades que querem ver construídos.

Em última análise, o que está a acontecer é que os CEO ou os líderes de produto, devido às pressões do contexto recente, disseram: «Não podemos simplesmente dar autonomia. Não podemos simplesmente entregar isto.» Por vezes, vejo gestores de produto com 26 anos e quatro anos de experiência profissional.

Não podemos simplesmente entregar-lhes as decisões de produto de um negócio de mil milhões de dólares. E, por isso, mesmo nesses ambientes tradicionalmente autónomos, até na Google e na Netflix, falo com pessoas que lá trabalham. Não é como se, de repente, os gestores de produto determinassem 100% do roteiro.

Muitas vezes, há um processo de baixo para cima e outro de cima para baixo a decorrer em paralelo, de forma invisível. No processo de baixo para cima, o gestor de produto desenvolve as suas ideias e apresenta-as no planeamento, mas, quando analisamos o resultado do que é finalmente acordado, grande parte corresponde a coisas que os executivos tiveram de aprovar, relativamente às quais tiveram de ser convencidos ou que muitas vezes foram ideias deles.

Por isso, penso que muitas pessoas acrescentam uma camada superficial de autonomia através dos OKR e do planeamento trimestral, mas o resultado final é uma fábrica de funcionalidades. Talvez, inicialmente, apenas um quarto das empresas tenha realmente autonomia e acabe por se transformar numa fábrica de funcionalidades.

Quanto aos outros 75% das empresas, diria que cerca de 30% estão numa fase de transformação. Essas empresas dizem: «Percebemos que precisamos de passar para o ágil. Percebemos que precisamos de gestores de produto com autonomia.» Mas o que acaba por acontecer é que, quando os gestores de produto trabalham com outras funções — design, engenharia, negócio e vendas — em setores como a banca ou os cuidados de saúde, onde ocorre grande parte desta transformação digital, essas pessoas continuam habituadas à forma de trabalhar de uma fábrica de funcionalidades, ao modelo em cascata.

Por isso, mesmo que a organização de produto queira implementar essas mudanças, são precisos anos. Estive a falar com Marty Cagan e ele disse que são precisos três anos. Penso que está certo. São necessários cerca de três anos. Assim, há empresas que estão nessa situação. O que acaba por acontecer é que os gestores de produto são responsabilizados pelas métricas, mas, ao mesmo tempo, recebem ordens sobre as funcionalidades que devem criar.

É uma zona intermédia confusa. E, depois, o último grupo é obviamente constituído por ambientes em cascata, claramente fábricas de funcionalidades, e muitos locais sentem-se perfeitamente bem a trabalhar assim. Se falar com um gestor de produto médio da Apple, os executivos determinam muitas das decisões relativas às funcionalidades do produto. Jony Ive e Steve Jobs, quando lá estava, tomavam muitas das decisões fundamentais.

Por isso, esse modelo ainda pode ser bem-sucedido, e as pessoas pensam: «Isso não funciona.» Marty disse que as melhores empresas têm todas autonomia, mas descobri que todos os caminhos conduzem à fábrica de funcionalidades.

Hannah Clark: Percebo que, quando seguimos o raciocínio, tudo faz sentido do ponto de vista lógico.

Vamos analisar alguns dos passos que descreve no artigo que escreveu sobre este tema. Se ainda não leu o artigo, é muito interessante a forma como o dividiu e como adotou uma posição algo controversa sobre a maneira de reagir quando se é gestor de produto numa fábrica de funcionalidades. Antes de avançarmos para os passos, pode falar um pouco sobre a sua posição e sobre o alinhamento que tem, especificamente com Melissa Perry?

Aakash Gupta: Penso que existem os idealistas e os realistas. Do lado idealista, temos pessoas como Marty Cagan, Teresa Torres e John Cutler, os três de quem gosto, que admiro e cujos textos leio integralmente. Mas penso que acreditam que, enquanto gestor de produto numa fábrica de funcionalidades, deve tentar transformar a sua organização.

É fundamentalmente isso que defendem, e muitas das ferramentas e ideias que partilham generosamente de forma gratuita têm esse objetivo. Gosto e respeito essas pessoas, mas é nisso que acreditam. Eu, Melissa Perry e outras pessoas semelhantes — diria que Clair Vaux e Powell Hearn também — estamos um pouco mais próximos do lado realista do espetro. Ou seja, enquanto gestor de produto, não penso que, a menos que tenha talvez oito ou dez anos de experiência, além de um título de gestor de produto de grupo ou superior, tenha realmente a experiência ou a influência necessárias para transformar eficazmente toda a organização.

Por isso, em vez de fazer apenas isso, talvez deva considerar outra estratégia. E por que razão digo isto? Porque vi tantas pessoas tentarem viver de acordo com esse idealismo. Há uma anedota que alguns talvez já me tenham ouvido contar, porque posso parecer um disco riscado, mas gosto de ordenar o subreddit de gestão de produto pelas publicações mais votadas de sempre.

Penso que ainda hoje oito em cada dez dessas publicações são de gestores de produto a dizer: «Detesto o meu trabalho, o meu trabalho é miserável.» E, se lermos os detalhes, são gestores de produto numa fábrica de funcionalidades. Algumas das frases que utilizam são: «Entrei na gestão de produto depois de ler INSPIRED e pensei que poderia determinar o roteiro, mas sou apenas um executor de encomendas do CEO.»

Este é um cenário extremamente comum: pessoas nos 75% de empresas que são explicitamente fábricas de funcionalidades e que estão insatisfeitas com o trabalho. Se pensarmos nisso, para evitar todo esse mistério — porque tenho muitos leitores de gestão de produto na newsletter —, o meu conselho realista é: aceite. Renda-se à fábrica. É melhor saber que está numa fábrica. E agora pode dizer: «Está bem, enquanto trabalhador de fábrica, o que tenho de fazer para aceitar esta realidade e avançar?»

Hannah Clark: Sim, penso que essa mentalidade tem muito que ver com o nosso desempenho em qualquer situação difícil. Mas não tem de ser difícil.

Vamos falar um pouco sobre os passos que apresentou no artigo, começando pela rendição à fábrica, que já abordou. Para si, quando é que isso se tornou realmente claro como um passo necessário do processo?

Aakash Gupta: Penso que foram as tentativas de transformação falhadas. Por exemplo, estive em diferentes tipos de ambientes. Muitos gestores de produto nunca estiveram, por exemplo, num ambiente de jogos. Trabalhei na Epic Games com o Fortnite. Muitas pessoas pensam na fábrica de funcionalidades como algo em que o CEO, o diretor de produto ou o diretor de design determinam tudo. Na realidade, numa empresa de jogos, normalmente são os designers que têm ideias superinteressantes, assim como os criativos, e dizem: «Isto vai ser incrível.»

Depois, enchem o lançamento da temporada seguinte com as experiências mais espetaculares. Enquanto gestor de produto, era óbvio para mim que havia melhorias fáceis no desempenho, na integração inicial e nas atualizações. Se alguém já tentou atualizar o Fortnite, sabe que, até hoje, apesar de termos feito muitas melhorias, eu atualizei-o recentemente.

Era um ficheiro de 42 GB. O meu computador demorou duas horas e uso um Mac, o que é horrível. A instalação da atualização demorou mais 50 minutos. Estamos a falar de uma fricção extrema, e a empresa lança estas atualizações duas vezes por semana. São horas de fricção duas vezes por semana. Na loja de monetização, havia também melhorias fáceis relacionadas com a criação de mais variantes para atingir pessoas que gastam 3000 ou 4000 dólares por ano na loja.

Mas, para convencer as pessoas que se preocupavam com o que era interessante, uma abordagem que poderia ter adotado — e que inicialmente pensei que fosse inteligente — seria dizer-lhes: «Precisamos de nos concentrar nos resultados e não nos produtos finais, nem nas funcionalidades interessantes.» Tudo isto caiu em saco roto. Estava a tentar implementar algumas destas ideias. Depois estive na Affirm, que tinha uma infraestrutura de planeamento muito centralizada.

Pensei: «Está bem. No meu roteiro, sou gestor de produto de grupo. A minha equipa vai trabalhar em problemas mais indefinidos.» Isso não funcionou de todo no meu primeiro ciclo de planeamento. Os executivos olharam para aquilo e disseram: «Vocês fizeram algum trabalho? Os roteiros dos outros são muito mais detalhados, com wireframes incríveis das funcionalidades, e a equipa de análise estimou até à sétima casa decimal o impacto nas receitas e nos lucros.»

Por isso, ficava muito mal. Cometi estes erros pessoalmente e, entretanto, tenho orientado muitos gestores de produto. Deparei-me com muitos que me procuram porque estão a ter algumas dificuldades na carreira ou receberam uma avaliação de desempenho inferior à que desejavam.

Quando investigo mais profundamente, uma das coisas que fazemos frequentemente é uma avaliação de 360 graus. Descubro que todos têm colegas de design e engenharia que dizem: «Os documentos de requisitos de produto dele não eram suficientemente detalhados.» Estes gestores de produto pensam que vivem num mundo com autonomia, mas, na realidade, vivem numa fábrica de funcionalidades, e a fábrica exige um documento de requisitos de produto excelente e muito detalhado.

Por isso, não cumprem esses princípios fundamentais e têm um desempenho inferior. Tudo isto é motivado pela necessidade de melhorar o desempenho. Na minha experiência real em diferentes ambientes, não vi que fosse possível provocar mudanças imediatamente. O único local onde consegui fazê-lo foi quando atingi o nível de diretor e vice-presidente.

Quando estava na thredUP e na Affirm, o meu trabalho era elevar as práticas das organizações. Quando isso acontece, é preciso avançar de forma muito intencional. É ótimo termos definido o que é uma fábrica de funcionalidades, porque podemos dizer: «Vou eliminar gradualmente cada elemento da fábrica de funcionalidades, pois é um antipadrão.» Mas o meu ponto, enquanto conselho de carreira, é que, se ainda não atingiu determinado nível, não deve tentar corrigir esse antipadrão.

Hannah Clark: O que nos leva ao passo seguinte: adaptar-se ao ambiente. O que escreveu é sobretudo sobre se concentrar no seu verdadeiro trabalho — fazer o seu verdadeiro trabalho. Pode desenvolver um pouco esse passo e as etapas secundárias que o acompanham?

Aakash Gupta: O que considero extraordinário é que, quando reflito sobre os tipos de produtos de trabalho que criei em cada função de gestão de produto, especialmente nos que foram bem recebidos, eram completamente diferentes. Na Epic Games, em última análise, eram propostas de funcionalidades interessantes.

Muitas vezes, ficava acordado até às duas da manhã com um designer técnico e criávamos uma demonstração jogável da funcionalidade, com gráficos rudimentares. Era isso que funcionava. Na Affirm, o ambiente era completamente diferente. O que funcionava era apresentar um roteiro com estimativas de impacto excelentes, todas as folhas de cálculo com dados e todos os modelos de estimativa de impacto. Eram opostos completos.

Por isso, é preciso avaliar o que significa ter sucesso na gestão de produto no seu ambiente. Recomendo entrevistar as pessoas que são gestoras de produto há mais tempo na empresa. Essa é uma boa abordagem. E também os gestores de produto que foram promovidos recentemente.

Não se limite à superfície dessas relações. Tente almoçar com essa pessoa. Talvez não tenha de fazer perguntas demasiado profundas logo no primeiro encontro. Tente primeiro oferecer-lhe algum valor. Depois de criar uma relação sólida e de essa pessoa começar a orientá-lo, poderá fazer perguntas como: «Escreve um documento de requisitos de produto para cada funcionalidade? Pode partilhar o seu melhor documento? Pode partilhar o seu último processo de promoção? Pode partilhar as suas últimas notas de reuniões individuais com o seu gestor?» São perguntas muito práticas, mas não podemos fazê-las a alguém que não seja nosso amigo.

Por isso, digo: torne-se primeiro amigo dessa pessoa. Talvez também possa torná-la sua mentora, embora não recomende pedir-lhe explicitamente que seja sua mentora. Muitas pessoas querem perceber que os seus gestores de produto e líderes de produto têm o seu próprio centro de gravidade. Assim, interpretariam isso como: «Ele ou ela é uma pessoa investigadora e preocupa-se realmente em ter sucesso.»

Quando entra numa empresa, vai entrevistar clientes, não clientes, concorrentes e outras pessoas da empresa. Recomendo também ter uma conversa individual direta com o responsável técnico, o gestor de engenharia, o designer, o investigador de utilizadores, o analista e provavelmente até com o seu chefe e com o chefe do seu chefe, para definir claramente os papéis e as responsabilidades.

Deve ser extremamente explícito. Pergunte ao designer: «O que pensa de os gestores de produto fazerem esboços e wireframes?» A maioria dos designers dirá: «Não estou muito interessado.» Alguns poderão dizer que não há problema, desde que não seja no Figma. É preciso conhecer essas nuances e perceber como trabalhar com as partes interessadas específicas.

Um erro que vejo em algumas pessoas que fazem estas entrevistas é presumirem que o seu trabalho de gestor de produto é igual ao de outro gestor numa equipa diferente. Mas o designer, o engenheiro e o analista com quem trabalha têm as suas próprias expectativas. Toda a gente quer escalar a montanha da liderança de produto até chegar a vice-presidente.

Mas, por agora, concentre-se apenas no passo seguinte, nas pessoas próximas e crie uma espécie de contrato. Depois de ter esse contrato, pode começar a testá-lo e perceber o que é bem recebido e o que não é. Talvez o gestor de engenharia não saiba que os engenheiros da equipa adoram ser convidados para chamadas de descoberta com clientes.

Só aprenderá isso na prática. Mantenha-se atento ao seu pequeno grupo. Este é um conselho básico de carreira, mas incluo-o aqui porque se trata de compreender em que consiste o seu trabalho de gestor de produto. Não penso que existam dois trabalhos de gestor de produto iguais.

Hannah Clark: Parece-me que, em qualquer ambiente de trabalho, as pessoas com quem trabalhamos mais de perto acabam por formar uma espécie de microcultura. É importante compreender as nuances dessa cultura e a linguagem que todos utilizam, garantindo que as expectativas mútuas estão alinhadas. Concordo totalmente.

Isso também se relaciona com o facto de ter mencionado reuniões individuais com pessoas que foram bem-sucedidas na função durante mais tempo.

O passo seguinte na sua trajetória é criar um percurso de promoção. Essas pessoas são uma parte importante desse passo. Pode falar-me um pouco sobre a estratégia para criar esse roteiro de carreira para si próprio?

Aakash Gupta: Essencialmente, se pensarmos na fábrica de funcionalidades, existe normalmente um conjunto muito consistente de critérios que é necessário cumprir. Muitas vezes, esses critérios não são escritos nem comunicados e são mal interpretados pelo próprio gestor. Por isso, muitas pessoas apoiam-se no seu gestor direto. Algumas pessoas da minha equipa eram bastante insistentes comigo em reuniões individuais sobre promoções. Mas não compreendiam — e tive de as orientar nesse sentido — que eu não era a única pessoa a decidir a promoção.

Por exemplo, na Affirm, escrevia um processo de promoção que submetia a um comité. Esse comité incluía todas as pessoas da liderança de produto ao meu nível ou acima dele. Todas essas pessoas participavam, pelo menos, numa parte da conversa. Por isso, depois de me convencer, precisava de convencer cada líder de produto na Affirm ao meu nível ou acima dele de que tinha algo positivo a dizer sobre si.

Era necessário trabalhar com essas pessoas, e foi isso que funcionou na Affirm. Trata-se realmente de compreender aquilo que não é dito. Estava a trabalhar com outros gestores de produto na Affirm que tinham dificuldade em ser promovidos. Uma delas era, penso eu, gestora de produto sénior há cerca de três anos e tinha feito muito bom trabalho.

Comecei a ter reuniões individuais com ela, embora não fizesse parte da minha equipa, e foi promovida no ciclo seguinte. Este foi o conselho que lhe dei: «Participei no seu último comité de promoção e apenas o seu gestor falou em seu favor.» O gestor dela não lhe tinha dado esse conselho.

Por isso, não podemos depender sempre do nosso gestor direto. É necessário criar relações com outros gestores que conseguem promover pessoas. Encontre essas pessoas e crie relações com elas. Mais uma vez, seja primeiro amigo, colabore com elas em algum trabalho para que possam perceber que é competente.

Depois, faça-lhes uma pergunta: «Qual é a sua experiência com comités de promoção?» Para mim, as melhores ideias sobre este tema surgiram pessoalmente, ao beber uma cerveja depois do trabalho. É aí que se aprende realmente o que está a acontecer. Algumas pessoas adotam uma abordagem das nove às cinco, durante 40 horas por semana.

Isso é aceitável, mas eu diria que deve retirar as 16 ou 17 horas de quinta e sexta-feira e transformá-las em 20 ou 21 horas, porque será muito mais eficaz para estas conversas. Use esse tempo para perceber como as pessoas são promovidas.

Muitas pessoas perguntaram-me: «Como chegou tão depressa a vice-presidente?» A resposta fundamental é que compreendi os percursos de promoção nas diferentes empresas. Em quase todas as empresas onde entrei, fui promovido ao fim de um ou dois anos. Foram acrescentadas pessoas à minha equipa e passei a ter um âmbito maior. Isso aconteceu porque estava completamente concentrado nesse percurso de promoção.

Quando perguntava aos meus amigos se tinham falado com alguém sobre isso ou o que sabiam acerca do assunto, muitas vezes nem sabiam que existia um comité de promoção na Affirm. Percebi que havia realmente uma lacuna de conhecimento. Por isso, o primeiro passo é colmatar essa lacuna. O segundo é pensar: «Quais são os meus pontos fortes únicos?»

Enquanto gestor de produto, penso que toda a gente vai deixar cair algumas bolas em algum momento. Talvez o seu feedback de design seja um oito em dez. Talvez a sua capacidade de gerir partes interessadas difíceis seja um sete em dez. Seja o que for, apoie-se nos seus pontos fortes. No meu caso, era a escrita.

Apoie-se realmente nisso. Como pode criar uma atualização semanal? Como pode divulgar uma estratégia de produto excelente junto de mais equipas de produto do que faria normalmente? Assim, está a utilizar os seus pontos fortes dentro dos critérios de promoção específicos.

Hannah Clark: Isto é muito inteligente e extremamente prático. Aprecio muito esta abordagem prática.

O passo seguinte é elevar práticas isoladas. Quando se refere às práticas isoladas neste contexto, a que diz respeito este passo e quais são alguns exemplos concretos de formas de desenvolver estas competências?

Aakash Gupta: Como mencionei, especialmente a partir do nível de gestor de produto de grupo, isto deve ser feito ao nível da organização.

Deve testar estas ideias com determinadas equipas e provar que funcionam. Se estiver abaixo do nível de gestor de produto de grupo, deve testá-las dentro da sua própria equipa. Depois de provar, nas reuniões individuais em que estabeleceu o contrato com os seus parceiros de design, engenharia e análise, que consegue ter sucesso de acordo com as expectativas deles, é altura de dizer: «Vamos elevar isto.»

Também deve pedir-lhes feedback e ajustar algumas coisas com base no que disserem. A ordem que considero mais eficaz é a seguinte.

O primeiro passo são os relatórios dos resultados das funcionalidades. Considero que não são ameaçadores num ambiente de fábrica de funcionalidades. Lançámos uma funcionalidade, que veio do CEO Brian Chesky, mas ele quer saber o que aconteceu e porquê. Nas fábricas de funcionalidades, os líderes preocupam-se realmente em saber por que razão algo aconteceu.

O que os gestores de produto costumam comunicar é: «A teve um desempenho superior ao de B, por isso vou manter A.» Mas isso não é tão impressionante como dizer: «A teve um desempenho superior ao de B porque…» De repente, está a influenciar o que acontece a seguir, mesmo que a fábrica de funcionalidades não dê ouvidos ao que vem depois.

Por exemplo, se estiver na Airbnb e tiver acabado de lançar o preço total porque Brian Chesky lhe disse para o fazer, deve voltar a ele e explicar o que aconteceu e porquê. É interessante porque sabemos que a taxa de conversão das compras vai diminuir, mas a questão é saber quanto. Sabemos que o NPS vai aumentar porque as pessoas deixarão de ser surpreendidas pelos preços.

Também pensamos que a taxa de conversão depois de as pessoas adicionarem algo ao carrinho e concluírem a reserva vai aumentar. Ainda não sabemos qual será o impacto geral. Depois, os dados chegam: a taxa de conversão diminuiu apenas 2% na página do mapa, mas aumentou 6% na página de compra. No total, a taxa de conversão aumentou 4%. A ideia aparentemente brilhante foi mesmo brilhante.

Por que razão aconteceu? Deve ir mais longe. Entreviste mais algumas pessoas, observe-as e fale com o investigador de utilizadores. Poderá descobrir que, antigamente, as pessoas não confiavam no preço apresentado no mapa. O que resolveu foi um problema de confiança.

Pode então dizer a Brian: «A razão pela qual o preço total teve um desempenho superior em termos de conversão — e, na verdade, também teve um desempenho superior nos mapas — foi o facto de as pessoas confiarem muito pouco no nosso preço por noite.» Ele pode perguntar onde mais existe falta de confiança: talvez nas avaliações ou em algumas localizações Airbnb Plus. A partir daí, pode criar um roteiro.

O segundo passo é a estimativa de impacto. Os gestores de produto são responsabilizados pelos resultados, mas recebem produtos finais para construir. Quando recebe um produto final, deve construir o melhor caso possível, com o máximo de dados, sobre o desempenho esperado da funcionalidade.

Na thredUP, o nosso CEO acreditava que passar o programa de referências de 10/10 para 30/30 poderia aumentar as receitas do mês seguinte em 5%. Apresentei as premissas mais favoráveis, o maior número possível de partilhas e as melhores taxas de aceitação de referências das nossas campanhas. O máximo a que consegui chegar foi um aumento de 0,1% nas receitas mensais do mês seguinte.

Tornou-se evidente que essa funcionalidade não alcançaria o objetivo pretendido. Assim, construir um modelo financeiro de estimativa de impacto é o segundo passo.

O terceiro passo é a descoberta. Muitas pessoas querem fazer descoberta primeiro, mas considero que deve ser o terceiro passo. Depois de começar a elaborar relatórios dos resultados e a estimar o impacto das funcionalidades antes de estas serem criadas, quando lhe entregarem um produto final, pode dizer: «Obrigado pelo wireframe. Vamos agora fazer uma descoberta adequada e levá-lo connosco ao longo do processo.»

Mostre vídeos de utilizadores e utilize ferramentas que permitam destacar rapidamente os principais problemas. Talvez a solução apresentada tente resolver um problema que deveria ser resolvido noutra parte do produto. Assim, passa da descoberta da solução para a descoberta do problema.

O quarto passo é avançar para os OKR. Aqui entramos verdadeiramente no território do gestor de produto de grupo. Se for gestor de produto principal, recomendo adotar OKR se o resto da empresa o fizer? Provavelmente não. Mas, se for gestor de produto de grupo, os OKR são eficazes depois de as equipas fazerem descoberta.

Muitas empresas fazem OKR em segundo lugar, antes de criarem a competência de elaborar relatórios dos resultados e estimar o impacto. Nessas empresas, os OKR são apenas conversa e geralmente falham. É por isso que defendo esta ordem intencional.

Depois dos OKR, vêm as árvores de problemas, objetivos e soluções, que ajudam a ligar os OKR aos problemas e às soluções. Por fim, vêm as estratégias de produto. É curioso, porque todos pensam que a gestão de produto é estratégia de produto, mas não acredito nisso até se ter controlo sobre toda a árvore de problemas, objetivos e soluções. Até lá, para todos os efeitos, é o CEO que escreve a sua estratégia de produto. Quando existe autonomia total, pode acrescentar a estratégia de produto.

Hannah Clark: O passo seguinte, naturalmente, é criar a sua coligação. Já falámos um pouco sobre a criação de relações estreitas com as equipas de design e engenharia. Gostaria de saber se tem alguma história de como isto se concretizou na sua vida profissional.

Aakash Gupta: Vamos falar da Epic Games. Na verdade, as relações estiveram no centro de todo o sucesso influente que tive lá. Uma das coisas em que queria trabalhar era o desempenho do Fortnite.

O Fortnite é um jogo de elevada exigência técnica. As pessoas jogam cerca de 2000 horas por ano, quase como se fosse um trabalho a tempo inteiro. Quanto mais horas jogam, mais obtêm do jogo. Existem pessoas a competir a esse nível e técnicas para aprender.

O problema é que, se tiver uma latência elevada ou uma taxa de fotogramas baixa, o limite da sua competência fica comprometido. Os dados mostravam que as pessoas com mau desempenho, por utilizarem um computador fraco ou terem uma ligação à Internet deficiente, tendiam a abandonar o jogo depois de 1000 a 2000 horas, enquanto as pessoas com bom desempenho permaneciam durante 12 000 ou 14 000 horas.

Este era o meu principal conhecimento, mas não podia simplesmente apresentá-lo e dizer que deveríamos dar prioridade ao desempenho. Em vez disso, tinha de exercer influência junto de designers e engenheiros importantes.

Havia um homem chamado Jason, que tinha criado o Call of Duty e liderava agora o Fortnite. Em última análise, tomava todas as decisões sobre o Fortnite. Respeitava muito a opinião dos engenheiros e designers que trabalhavam mais arduamente — pessoas que trabalhavam 120 horas por semana e lançavam tudo.

Decidi que eram essas as pessoas que precisava de integrar na minha coligação. Como trabalhavam tanto, não tinham tempo para perceber o desempenho de tudo aquilo que criavam. Essa foi a minha oportunidade. Comecei a mostrar-lhes: «Vocês lançaram o Fortnite Capítulo 2, Temporada 4, atualização 6.4. Eis o que aconteceu: os atiradores de elite aumentaram 8%, as eliminações diminuíram 6% e os jogadores de baixo nível estavam a vencer jogadores de alto nível a taxas nunca antes vistas.»

Ficaram entusiasmados com o resultado do seu trabalho e começaram a valorizar o que eu tinha para dizer. Acrescentei alguns dados sobre o desempenho: os jogadores com latência superior a 200 milissegundos estavam a abandonar o jogo a taxas muito elevadas. Estes pequenos dados ajudaram-nos a começar a integrar o desempenho no jogo.

Começaram a perceber o quanto o desempenho afetava o jogo e fomos melhorando-o gradualmente. Este é um exemplo de como pensei estrategicamente sobre quem deveria e poderia fazer parte da minha coligação, trabalhando de trás para a frente para criar a relação e a influência necessárias.

Hannah Clark: É inteligente a vários níveis. Está a construir excelentes relações, as pessoas confiam em si e torna-se influente quase passivamente. Brilhante.

Antes de terminarmos, quero abordar alguns erros comuns que observou nos gestores de produto em ambientes de fábrica de funcionalidades. Um deles é, obviamente, não reconhecer que se está condenado a trabalhar numa fábrica de funcionalidades. Quais são os outros erros que poderíamos abordar?

Aakash Gupta: Há talvez seis que quero mencionar. O primeiro é perseguir apenas métricas de resultados imediatos. A pessoa ouviu o meu conselho e rendeu-se à fábrica. A fábrica preocupa-se com a velocidade dos pontos de história no Jira, com o número de funcionalidades importantes lançadas a tempo e com o número reduzido de vezes que uma data de entrega é adiada.

Penso que isso continua a ser um erro. É preciso analisar os resultados de todas as funcionalidades. Não quero que a rendição à fábrica signifique deixar de fazer um bom trabalho de gestão de produto. A fábrica pode pedir-lhe que crie uma funcionalidade horrível e sem impacto, mas deve manter o seu sentido de produto antes de a construir.

Isso fará duas coisas: tomará as decisões certas sobre a alocação de recursos sempre que possível e desenvolverá a competência para fazer um bom trabalho de produto. Vejo muitas pessoas entrarem numa fábrica de funcionalidades e deixarem de evoluir.

O segundo erro é negligenciar a dívida técnica. Quando se corre atrás de funcionalidades importantes, a experiência dos programadores começa a degradar-se. O tempo de compilação passa a ser de três horas e até uma alteração simples demora um dia, mas a equipa continua a dizer que tem de lançar a próxima grande temporada.

Pense na dívida técnica acidental e na dívida técnica intencional. A dívida acidental resulta da experiência do utilizador e deve ser minimizada. A dívida intencional resulta de correr atrás de uma funcionalidade importante. Se fizer esses compromissos conscientemente e voltar a corrigi-los depois de a funcionalidade passar de zero a um e de um a cem, tudo bem.

O terceiro erro é ignorar o feedback dos utilizadores. Mesmo que esteja preso numa fábrica de funcionalidades, mostrar um wireframe aos utilizadores e alterá-lo com base no feedback deveria ser uma prática normal. Quando pergunto a alguém quantos utilizadores viram os designs finais da grande funcionalidade que lançou, cerca de metade responde que não mostrou os designs a nenhum utilizador.

Isso é um erro enorme. O seu trabalho está em jogo e tudo aquilo que a sua equipa lança constitui o seu currículo, seja para ser despedido ou promovido. Certifique-se de que essa má ideia é apresentada na melhor versão possível.

O quarto erro é deixar que o medo de ficar para trás determine o roteiro. Um concorrente lançou um CRM, por isso também precisamos de um CRM. Outra ferramenta lançou publicações no LinkedIn, por isso a nossa ferramenta também precisa dessa funcionalidade. Surge o medo de perder clientes e, de repente, queremos construir tudo o que poderia ter evitado a perda do nosso maior cliente.

É um erro enorme. Tente mostrar aos executivos a dimensão real de uma funcionalidade. Qual é a população que pode ser abrangida? O último produto novo é utilizado por 0,2% dos utilizadores. Precisamos realmente de investir noutro produto que será utilizado por 0,2% dos utilizadores? Sempre que vir esse medo de ficar para trás em quem dirige a fábrica de funcionalidades, encare-o como um sinal de alerta.

O quinto erro é levar a equipa ao esgotamento. Isto é comum até em ambientes com autonomia. Embora lançar rapidamente seja importante, uma equipa motivada e saudável tende a produzir os melhores resultados.

Enquanto gestor de produto, defenda ferramentas melhores, um orçamento de aprendizagem e desenvolvimento e um retiro de equipa bem planeado. Organizar ou defender estes momentos pode fazer uma grande diferença. Pode dizer ao seu chefe: «Acabámos de lançar uma grande funcionalidade, ou estamos prestes a fazê-lo. Seria ótimo se a equipa de produto pudesse reunir-se para celebrar.»

Quando comecei na gestão de produto, levava brownies aos programadores quando lançavam uma grande funcionalidade e felicitava os designers quando o design era excelente. Estas pequenas coisas têm grande impacto em qualquer fábrica de funcionalidades, porque não é apenas o gestor de produto que tende a estar infeliz. Os designers e engenheiros também estão frustrados.

O sexto erro é perder de vista a perspetiva global. Recebemos o quê, o quê e o quê, e esquecemo-nos frequentemente do porquê. Já falei do porquê no contexto das métricas e dos problemas dos utilizadores.

Não se esqueça também da estratégia de produto. Embora tenha colocado a estratégia de produto como o último passo, deve desenvolver essa competência. A função de gestor de produto sofreu uma grande compressão nos últimos três ou quatro anos. Existem simplesmente menos empregos de gestor de produto, enquanto o design de produto e a engenharia de produto continuam a crescer.

Se queremos que os gestores de produto tenham sucesso num ambiente em que os empregos estão a diminuir, temos de procurar causar impacto através da estratégia de produto. Mesmo numa fábrica de funcionalidades, haverá 10% a 15% do roteiro que pode influenciar e 10% a 15% do sprint em que o designer ou o gestor de engenharia lhe pedirão ajuda.

Continua a fazer parte da equipa. Certifique-se de que as funcionalidades que lança são estrategicamente extraordinárias. Alguns dos melhores gestores de produto em fábricas de funcionalidades trabalham na Epic Games e na Affirm. Cada funcionalidade que lançam altera a trajetória da empresa.

Não lançam funcionalidades com muita frequência porque estão presos nesse ambiente, mas, quando o fazem, o impacto é transformador. Na Affirm, um deles lançou um sistema de aprendizagem automática para organizar os empréstimos que deveriam ser reembolsados. Foi uma aplicação profunda de aprendizagem automática no back-end, mas melhorou as taxas de reembolso em cerca de 15%, proporcionando à Affirm uma vantagem líder no setor.

É esse tipo de impacto que deve motivar as pessoas. Se está preso numa fábrica de funcionalidades, procure ter ideias de funcionalidades geniais e integrá-las sempre que possível.

Hannah Clark: É um verdadeiro momento de deixar o microfone cair. Aakash, muito obrigada por ter arranjado tempo para conversar connosco. Para as cinco pessoas que estão a ouvir e que ainda não o seguem, onde podem acompanhá-lo online?

Aakash Gupta: Idealmente, através da newsletter. Estou no Substack. Sei que algumas pessoas não gostam da janela que pede o endereço de e-mail.

Pode simplesmente clicar em ignorar e continuar a ler. Atualmente, cada artigo meu envolve, em média, mais de dez pessoas. No último artigo, tive um colaborador convidado. Cada um de nós falou com dez pessoas e entrevistámo-las. Obtivemos ideias reais.

Não é o tipo de conteúdo de produto que talvez veja no LinkedIn ou no X e pense: «Ele publica conteúdo de produto como toda a gente.» Não. São estudos de investigação com pessoas reais. Para o artigo sobre procura de emprego na liderança de produto, falámos com líderes de produto que tinham conseguido recentemente funções de vice-presidente ou diretor. Falámos com recrutadores que colocam efetivamente pessoas no setor.

O que tento fazer é apresentar dados reais e ideias reais. Se as pessoas tiverem interesse nisso, é esse o trabalho que estou a desenvolver e é aí que me podem encontrar.

Hannah Clark: Fantástico. Vemo-nos por lá. E muito obrigada por ter vindo.

Aakash Gupta: Está bem, muito obrigado.

Hannah Clark: Obrigada por nos ouvir. Para obter mais ideias, guias práticos e análises de ferramentas, subscreva a nossa newsletter em theproductmanager.com/subscribe. Pode ouvir mais conversas como esta subscrevendo o The CPO Club, onde quer que ouça os seus podcasts.