Gerenciamento de produto é tudo sobre contar histórias. Então, deixe-me compartilhar como eu penso sobre gerenciamento de produto e como a IA mudou isso, contando uma história para você.
A pergunta da entrevista que nunca vou esquecer
Comecei minha carreira como engenheiro na RealNetworks e, em poucos anos, era responsável pela equipe de produto e engenharia do RealPlayer. Era um produto de consumo bastante significativo na época — tinha centenas de milhões de usuários e ajudou a levar áudio e vídeo à internet inicial. Eu me sentava em reuniões com pessoas da área de negócios, que sugeriam ideias como: “Devemos exibir um anúncio toda vez que o player iniciar.” Eu sabia que essa não era a coisa certa a fazer, mas não tinha como argumentar contra as planilhas Excel delas mostrando quanto dinheiro faríamos. Eu queria me tornar um gerente de produto de verdade e concluí que provavelmente deveria ir para uma escola de negócios.
Comecei meu MBA na Berkeley e, pouco depois de chegar, vi na lista de e-mails da minha antiga faculdade que o LinkedIn estava contratando. Me candidatei e acabei numa entrevista com Reid Hoffman. Ele se sentou e me fez uma pergunta de entrevista que nunca vou esquecer:
“Então, você quer ser gerente de produto. Qual é o artefato que um gerente de produto produz?”
Ele elaborou. Engenheiros têm um artefato: código. Desenvolvimento de negócios tem um artefato: contratos assinados. Designers criam a aparência visual e os gráficos. O CEO tem o organograma, o plano de financiamento e a visão que mantém todos unidos. E quanto ao gerente de produto?
Eu disse a ele que não tinha certeza se gerentes de produto realmente tinham “artefatos” assim, mas que a coisa fundamental que fazemos é reunir tudo o que está acontecendo e escrever em uma especificação. A especificação é a planta baixa. É onde definimos os requisitos e tudo o que vamos fazer, e ela se torna um dos documentos mais importantes da empresa porque destrava cada equipe para começar a construir a partir dali.
Eu estava claramente nervoso. Acho que ele percebeu, porque me tranquilizou dizendo que foi uma boa resposta. Acabei conseguindo o emprego, larguei o MBA para entrar no LinkedIn e tenho pensado nessa pergunta desde então.
A evolução da especificação para a história
Porque eu dei a resposta errada.
Isso ainda era a Era Cascata (Waterfall) de desenvolvimento de software. No LinkedIn, estávamos tentando reinventar uma plataforma de empregos dentro de uma plataforma social — onde recrutadores pudessem ver candidaturas no contexto de conexões mútuas, candidatos pudessem ver vagas e encontrar caminhos através de sua rede para chegar à porta da frente. Durante esse processo de descoberta, escrevi uma especificação de 120 páginas definindo toda a experiência e quais eram os requisitos.
Pensei muito nisso nos anos seguintes. Porque aquela especificação, obviamente, não é o artefato mais importante. A história é.
A especificação descreve um sistema, o que ele deve fazer e quais caixas devem ser marcadas antes de estar pronto. Isso não é a arte do gerenciamento de produto. Gerenciamento de produto é sobre contar a história das pessoas que vão usar o produto e por que ele fará diferença em suas vidas. Tem que ser imediatamente compreensível, para quem quer que você esteja falando. E tem que ser repetível — as pessoas precisam conseguir passá-la adiante fielmente, sem você estar na sala.
Esse é um documento completamente diferente e um trabalho completamente diferente.
Dez anos atrás, dei uma palestra sobre gerenciamento de produto, e as pessoas ainda me enviam; o que é ou lisonjeiro, ou um sinal de que o campo não avançou. Vou considerar ambas as possibilidades. De qualquer forma, toda a palestra se resumiu a uma frase: “Um gerente de produto ajuda sua equipe (e empresa) a entregar o produto certo para seus usuários.” Passei a maior parte da palestra decompondo essa frase, palavra por palavra.
- Ajuda sua equipe. Você não é o líder. Muitas pessoas acham que o gerente de produto é o líder. Você é a pessoa que ajuda a fazer as coisas acontecerem. O que significa que você deve...
- Entender sua equipe e sua empresa. Sua equipe é seu domínio: você precisa entendê-la! E você precisa entender como ela se encaixa no quadro geral, para poder servir aos objetivos da empresa e não apenas aos seus.
- Entregar. Podemos conversar o quanto quiser, mas no final das contas, o que importa é colocar o produto nas mãos dos clientes.
- O produto certo para seus usuários. Finalmente chegamos ao trabalho: refinar o que “certo” realmente significa.
Quanto disso muda num mundo de IA?
O que está mudando
Obviamente algo mudou, algumas coisas na verdade. Por um lado, está mudando como codificamos e quão rápido podemos passar de uma ideia para algo funcionando. Por outro lado, está mudando o que os usuários esperam que um produto seja. Acho que mal arranhamos isso, especialmente no consumidor. Poder descrever o que você precisa e ter o produto entregando, talvez com agentes rodando em segundo plano, sem você ter que aprender e interagir.
Não há dúvida de que o custo de fazer coisas despencou. Não é mais tão difícil escopar algo e tentar; isso te dá enorme flexibilidade. Mas o custo do julgamento não mudou nada. Descobrir o que construir é mais importante agora do que nunca.
Desenvolvimento de produto é um loop. Antigamente, alguém tinha uma ideia — e não precisa ser você; numa boa empresa pode vir de qualquer lugar. Você tenta. Escreve uma especificação, ou um brief de produto, ou seja lá qual for o nome desse documento. Há algum custo inicial nisso: escopo, design, discussões — tudo o que deve acontecer antes de gastar tempo precioso de engenharia. Esses são todos rituais que inventamos para proteger o tempo de engenharia de más decisões. Porque você só dava seis ou oito voltas nesse loop por ano.
Então, fazer coisas ficou absurdamente barato. Não um pouco mais barato; uma ordem de magnitude diferente. E o que aconteceu é realmente interessante. Aquel antigo loop ainda está muito presente — apenas reorganizado numa nova ordem.
O antigo loop ia: ideia, especificação, custeio, escopo, tudo o mais, então construção. Agora:
- Primeiro, pegue a ideia e construa-a rapidamente com IA, apenas para ver como funciona e como parece.
- Você brinca com ela e descobre como se sente e como se encaixa no quadro geral. Protótipos vencem “e se”, sempre.
- Então você projeta. Agora que brincou com ela, você sabe o que é, e pode realmente falar sobre o que será necessário para isso ser mais do que um protótipo. Quero dizer design aqui em ambos os sentidos: design visual e UX, e também design de engenharia.
- Depois você entrega e aprende.
Inverte completamente: de especificar-e-escopar, para construir-e-brincar. Acho que isso muda o gerenciamento de produto mais do que qualquer outra coisa acontecendo agora.
Isso finalmente significa que a especificação não é mais o entregável; de verdade. Você não precisa começar escrevendo um longo documento e acertando tudo no papel. Isso costumava ser verdadeiro num sentido aspiracional, mas agora é apenas obviamente verdadeiro, num sentido literal.
Mas quero ter cuidado, porque há um erro igual e oposto que você pode cometer.
Demos são quase grátis agora. Produtos funcionais não são. Continuo vendo o outro lado dessa nova abordagem: “Isso é ótimo, só entregue.” Ainda não é assim que funciona. Todos nós ainda temos que respeitar que a distância de um protótipo para algo real ainda leva tempo para ser percorrida.
Há um clichê sobre gerentes de produto, de que seu trabalho é principalmente perguntar: “Cabe no cronograma?” Jogue essa ideia fora totalmente. A pergunta mais importante é: Cabe no produto?
Todos temos ótimas ideias, e agora todos temos agentes que podem codificar para nós. Decidir o que construir oficialmente não é um debate de recursos. É um debate de impacto. “Isto ou aquilo”, não “isto ou nada”. Bom gosto e curadoria importam muito aqui, quando você tem uma visão e realmente sabe o que está tentando fazer pelo mundo. Mas o sistema que você constrói ainda precisa parecer completo.
Minha maior preocupação com a IA é que ela nos permite ir mais rápido e, portanto, simplesmente enfiar tudo. Falamos de “lixo de IA” (AI slop) em conteúdo; isso é o que lixo de IA significa para produto. Já vi acontecer em alguns lugares e acho que estamos todos um pouco preocupados com isso. Quando qualquer um pode construir qualquer coisa, decidir o que construir é todo o trabalho. E isso é um problema de história. Que história você quer contar? Que história você quer que seus clientes entendam? Que história você quer que viva na cabeça deles?
Seu trabalho como PM não é escrever uma especificação do que o produto fará. É sobre criar um entendimento compartilhado — uma imagem compartilhada do que estamos fazendo e por quê. Por que o usuário está aqui? O que eles sentem em cada etapa e por que isso importa? Onde é impressionante e onde é chato? Tudo bem um produto ser chato ocasionalmente, desde que você saiba onde. Mas se você não consegue escrever um bom roteiro, o produto será tedioso.
O presente que a IA te dá é que agora você pode descobrir isso de graça, logo no início. Você pode construir rapidamente, sentir o gosto, brincar e descobrir aquela única frase: o que este produto faz por alguém na vida dele? Porque se você puder responder isso, pode responder minha pergunta: “As pessoas estão realmente usando?” Porque agora você disse o que ele faz, e está perguntando se elas fazem.
O que não está mudando
O que significa ter uma “visão” para seu produto?
Quando digo visão, não quero dizer uma declaração de missão. Elas importam, mas não são uma visão. Uma visão é a razão fim-a-fim para o produto existir para os usuários. Tenho um framework simples para isso:
- Propósito. Por que alguém pega seu produto e coloca na vida dele?
- Ações principais. Quando pegam, o que estão realmente fazendo? Pode haver mais de uma coisa, você tem que entender todas.
- Ciclo. Qual é a frequência esperada de cada uma dessas ações principais?
Durante toda a minha carreira, enquanto me reunia com fundadores e outros profissionais de produto, eu perguntava a eles: as pessoas estão usando seu produto? E eles quase sempre pulam direto para dados de usuários. “Temos uma proporção DAU/MAU de 50%. Cruzamos 10.000 cadastros. Temos um milhão de pessoas na lista de espera. Nosso ARR é de um milhão. Estamos processando quatro bilhões de tokens por dia. Chegamos ao #3 na App Store.”
Algum desses é uma resposta à pergunta que fiz?
Às vezes faço a pergunta novamente, mas adiciono uma palavra: as pessoas estão realmente usando seu produto? E então, às vezes, eles percebem o que estou perguntando.
O propósito do LinkedIn era encontrar e ser encontrado. Talvez a ação principal, para algumas pessoas, fosse apenas responder quando alguém entrava em contato. Para a maioria, isso não é algo diário; pode ser uma ou duas vezes por ano.
Olhe para esse ciclo — uma ou duas vezes por ano. Entender isso foi crítico para o LinkedIn funcionar, porque a rede precisava de um número muito grande de pessoas dispostas a serem encontradas, e pelo menos algumas pessoas fazendo a busca.
LinkedIn era uma rede social, afinal, então você pode ser tentado a incitar usuários a tomar ações todos os dias. Nós não fizemos isso. Em vez disso, gastamos um tempo enorme nos primeiros dias garantindo que as pessoas mantivessem seus perfis atualizados. Estava tudo bem se você fosse encontrado apenas uma ou duas vezes por ano, desde que quando acontecesse, você clicasse e entendesse: “alguém está entrando em contato comigo, isso é ótimo.”
Quando você está medindo se seu produto está funcionando, essas ações principais são o que importa. Foque no tráfego direto: encontre as pessoas que literalmente vieram até você. Eles têm o app instalado e tocam no ícone, ou digitaram seu domínio manualmente; foram até você, por vontade própria. Esse é o tráfego que importa, em oposição a todas as outras maneiras de trazer alguém de volta no momento.
E então conte apenas as pessoas que realizam as ações principais. Não “abriu o app brevemente”, mas realmente engajou. No Discord seria: “entrou numa sessão ao vivo. Realmente leu e enviou mensagens.”
Se você não consegue definir quais são essas ações principais, então você não tem um produto, porque não tem algo que entende.
Agora, uma coisa nova, e que eu amo, é que em produtos de IA onde o usuário está falando com o produto, ou dando prompts de alguma forma, você agora tem uma transcrição literal da jornada do usuário. Você pode ver o que as pessoas estão dizendo em suas próprias palavras. Você pode ver o momento exato em que alguém desistiu e reformulou. Você pode ver o que esperavam que o produto fizesse e ele não fez. LEIA ISSO! A IA é ótima para revelar coisas que você não teria visto antes, mas não pode deixar que ela resuma tudo, e não pode deixar que ela forme sua opinião por você. Formar sua opinião — descobrir qual é a história real — é o trabalho e a arte do gerenciamento de produto.
Onboarding
O onboarding é o momento mais importante único que você tem para contar sua história a um cliente. Eles descobriram seu produto — talvez através de um anúncio, um convite viral, um artigo, o que for. Sabem que você existe; estão curiosos e querem experimentar. Você nunca terá tanta atenção deles novamente.
Você tem que lembrar, neste ponto, que nem todos chegam ao seu produto com a mesma motivação. Existem os ansiosos. Eles querem entrar tanto. Estão prontos para ir. E, só para esclarecer, se você trabalha na empresa, você vive na terra dos ansiosos. Todos internos à sua empresa devem ser tratados como ansiosos; eles já estão imersos no produto todos os dias. Quando fazem o onboarding, pensam: “Sei o que estou fazendo, isso é chato, por que esta etapa está aqui?”
Por outro lado, existem os passantes. Eles simplesmente não estão tão interessados em você. Ouviram falar, conferiram, mas a mensagem não chegou, e vão embora.
Esses dois tipos de usuários são as bordas da distribuição. No meio há um grande núcleo difuso. Essas são pessoas que apareceram por um motivo: estão curiosas! Querem saber mais! E você genuinamente pode convertê-las em usuários centrais do seu produto. Essas são as pessoas ao redor das quais você precisa construir. Você vai conseguir os ansiosos de qualquer maneira. O meio é quem você precisa entender.
Assuma que seus usuários são motivados e curiosos. Tire o tempo para introduzir o produto, passo a passo. Mais passos simples vencem menos passos complexos. Provei isso em testes A/B em várias empresas ao longo dos anos. Se cada passo for discreto e simples, e ficar claro o que você está pedindo e ensinando, isso vence telas grandes únicas, ou escolhas complexas para manter o número de passos baixo. Sempre.
Então, como você realmente constrói isso?
Comece repetindo a mensagem central: É isto para o que serve. Declare o contexto, dentro do produto. Está tudo bem pedir o básico - e-mail, senha, telefone. Para todo o resto, explique por que está pedindo e como se relaciona. Então divida seu produto em seus conceitos-chave, cada um com uma ação clara para o usuário tomar.
Produtos de IA tornaram isso mais difícil, não mais fácil. Você recebe a caixa de prompt em branco. Em alguns aspectos, é a pior tela de onboarding já projetada. É uma caixa mágica. Pode fazer qualquer coisa. Então... o que você quer fazer?
Muitos produtos hoje começam com: “Oi, estou aqui para ajudar, pergunte qualquer coisa!” Falando por mim, eu não sou a pessoa mais articulada ou criativa naquele momento. Você tem que ensinar capacidades conceito por conceito. “Se você perguntar algo assim, eu posso fazer.” E então deixe o produto fazer. Leve o usuário a pelo menos um caso de uso valioso rapidamente, idealmente com seus próprios dados, para que seja realmente valioso para eles.
As pessoas às vezes me perguntam: com um fluxo mais longo, mais pessoas não vão abandonar? Sim! Mas aqueles que passam têm muito, muito mais probabilidade de realmente usar seu produto. Se você estiver testando A/B dois fluxos de onboarding diferentes, NÃO olhe quantas pessoas chegaram ao fim do fluxo. Olhe quantas pessoas voltam no dia seguinte, ou na semana seguinte, e quantas tomaram uma ação principal. Se você perguntar a elas, naquele momento, “O que é este produto?”, elas devem dar mais ou menos a resposta certa. Seus dados de retenção, a partir deste ponto, são seu boletim escolar.
Uma história do Twitter
Vou amarrar tudo isso contando uma história do Twitter.
Entreii no Twitter no final de 2009. Tínhamos um problema de crescimento — exceto que não era realmente um problema de crescimento. O Twitter estava constantemente nas notícias. As pessoas blogavam sobre ele, a mídia falava dele, e muitas pessoas perguntavam: “O que é essa coisa do Twitter? Preciso descobrir e me cadastrar.” E então milhões delas fizeram. Mas nunca voltaram.
O problema era que ninguém podia te dizer o que o Twitter era. Posso realmente provar isso:
Legenda: “eventualmente chegamos ao número um.”
A maneira como fazíamos o onboarding era: as pessoas se cadastravam e viam opções para “Encontrar seus amigos” ou “Seguir 20 pessoas aleatórias”. A maioria pulava, e então aterrissava numa página que parecia assim:
Isso é bastante terrível! É uma grande caixa vazia. As pessoas olhavam e pensavam: “...não tenho nada a dizer.” E então iam embora. Se você perguntasse a elas naquele momento: “O que é o Twitter?”, diriam: “Acho que é sobre dizer algo ao mundo? Ou encontrar meus amigos? Não sei.”
Então reconstruímos o onboarding ao longo de alguns anos e encontramos o que funcionava, que era o Learn Flow (Fluxo de Aprendizado). Ensinávamos o Twitter, um conceito de cada vez, como uma história. E isso moveu a retenção mais do que qualquer outra coisa que lançamos naquele ano.
O Learn Flow, tela por tela
Primeiro, a nova página inicial: “Bem-vindo ao Twitter.” Não tentamos colocar conteúdo lá, apenas: “Descubra o que está acontecendo agora com as pessoas e organizações que você se importa.” Essa é uma descrição bastante boa do Twitter, honestamente.
Então: Este é um tweet. É uma mensagem curta, até 140 caracteres, e pode conter links. Agora você sabe que tweets são a unidade desta coisa.
Em seguida, você tem que construir sua timeline. Então mostramos uma timeline. Fizemos você clicar em “seguir” nas pessoas à esquerda. E quando clicam em seguir, os tweets delas apareciam à direita. Então você entende a ideia toda, num movimento: Eu clico em seguir, tweets aparecem, essa é minha timeline. Que é o conceito real do Twitter - tweets, seguindo e uma timeline.
E então, finalmente, sua timeline. Você reconheceria cada conta nela, porque você realmente as seguiu você mesmo.
Onboarding é sua história.
O produto certo para seus usuários
Seu trabalho como gerente de produto é ajudar sua equipe e sua empresa a entregar o produto certo para seus usuários. Num mundo de IA, a entrega é menos um problema do que costumava ser. Descobrir o produto certo, e quem são seus usuários, é tão importante quanto sempre foi. Senão mais.
Sempre pergunte se as pessoas estão realmente usando seu produto. Entenda o que isso significa. Pense no propósito, nas ações principais, no ciclo. Gaste mais tempo no onboarding do que parece razoável. É onde você converte o meio difuso, e é onde você realmente conta a história do seu produto.
Use IA para ir mais rápido nos protótipos — mas não acelere seu julgamento. Não abra mão do seu julgamento. Não diga apenas: “Bem, vamos testar e ver.” É assim que você acaba com um produto descuidado. Mantenha seu julgamento em toda parte. A parte mais difícil do trabalho ainda é equilibrar toda a nossa criatividade como gerentes de produto contra todos os dados que agora temos acesso.
Boa sorte!
