A gestão de produtos é sobre contar histórias. Então, deixe-me compartilhar como eu penso sobre gestão de produtos 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, fui 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 do lado comercial, 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 do Excel deles mostrando quanto dinheiro ganharíamos. Eu queria me tornar um gerente de produto de verdade e concluí que provavelmente deveria ir para uma escola de negócios.
Comecei a faculdade de administração na Berkeley e, pouco depois de chegar, vi na lista de e-mails da minha antiga universidade que o LinkedIn estava contratando. Me candidatei e acabei tendo uma 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?
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 desbloqueia cada equipe para começar a construir a partir dali.
Eu estava claramente nervoso. Acho que ele percebeu, porque me tranquilizou dizendo que era uma boa resposta. Acabei conseguindo o emprego, larguei a faculdade de administração 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 na 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 que esteja pronto. Isso não é a arte da gestão de produtos. Gestão de produtos é sobre contar a história das pessoas que vão usar o produto e por que isso importará nas vidas delas. 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.
Há dez anos, dei uma palestra sobre gestão de produtos, e as pessoas ainda me enviam; o que é ou lisonjeiro, ou um sinal de que o campo não evoluiu. Vou considerar ambas as possibilidades. De qualquer forma, a palestra inteira se resumiu a uma frase: “Um gerente de produto ajuda sua equipe (e empresa) a entregar o produto certo aos 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, não apenas aos seus.
- Entregar. Podemos conversar o quanto quiser, mas, no final das contas, o que importa é colocar o produto na frente dos clientes.
- O produto certo para seus usuários. Finalmente chegamos ao cerne do trabalho: refinar o que “certo” realmente significa.
Quanto disso muda em um mundo de IA?
O que está mudando
Obviamente, algo mudou, na verdade algumas coisas. 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 arranhámos a superfície disso, especialmente no consumidor. Poder descrever o que você precisa e ter o produto entregando, talvez com agentes rodando em segundo plano, sem você precisar aprender e interagir.
Não há dúvida de que o custo de fazer coisas despencou. Não é mais tão difícil delinear algo e tentar; isso lhe dá enorme flexibilidade. Mas o custo do julgamento não mudou nada. Descobrir o que construir é mais importante agora do que nunca.
O desenvolvimento de produtos é um ciclo. Antigamente, alguém tinha uma ideia — e não precisa ser você; em uma boa empresa, pode vir de qualquer lugar. Você tenta. Escreve uma especificação, um resumo de produto ou seja lá qual for o nome desse documento. Há algum custo inicial: 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 ciclo 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 ciclo ainda existe — apenas reorganizado em uma nova ordem.
O antigo ciclo seguia: ideia, especificação, custeio, escopo, todo o resto, 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.
Isso inverte completamente: de especificar-e-escopar, para construir-e-brincar. Acho que isso muda a gestão de produtos 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 é simplesmente óbvio, num sentido literal.
Mas quero ter cuidado, porque há um erro igual e oposto que você pode cometer.
Demos estão quase grátis agora. Produtos funcionais não estã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 estereótipo sobre gerentes de produto, de que seu trabalho é principalmente perguntar: “Isso cabe no cronograma?” Jogue essa ideia fora completamente. A pergunta mais importante é: Isso cabe no produto?
Todos nós temos grandes ideias, e agora todos nós 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, apenas enfiar tudo. Falamos sobre “lixo de IA” em conteúdo; isso é o que lixo de IA significa para produto. Já vi isso 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 narrativa. Que história você quer contar? Que história você quer que seus clientes entendam? Que história você quer vivendo 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 que um produto seja 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 lhe dá é que agora você pode descobrir isso de graça, logo no início. Você pode construir rapidamente, sentir o gostinho, brincar com ele e descobrir aquela única frase: o que este produto faz por alguém na vida dele? Porque se você puder responder a 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 isso.
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-o em sua vida?
- 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 lhes pergunto: as pessoas estão usando seu produto? E elas quase sempre pulam direto para dados de usuários. “Temos uma taxa 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 entrasse em contato. Para a maioria das pessoas, 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.
O LinkedIn era uma rede social, afinal, então você pode ser tentado a empurrar os usuários a tomar ações todos os dias. 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 aplicativo 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 brevemente o app”, mas realmente engajou. No Discord seria: “entrou em uma sessão ao vivo. Leu e enviou mensagens de verdade.”
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 você entende.
Agora, uma coisa que é nova, e que eu amo, é que em produtos de IA onde o usuário fala com o produto, ou faz 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 você 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 da gestão de produtos.
Onboarding
O onboarding é o momento mais importante 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, etc. Eles 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 todo mundo chega ao seu produto com a mesma motivação. Existem os ansiosos. Eles querem entrar tanto. Estão prontos para ir. E, só para ficar claro, se você trabalha na empresa, você mora na terra dos ansiosos. Qualquer pessoa interna à sua empresa deve ser tratada como um ansioso; eles já estão imersos no produto todos os dias. Quando fazem o onboarding, pensam: “Eu sei o que estou fazendo, isso é chato, por que esta etapa está aqui?”
Por outro lado, existem os passageiros. Eles simplesmente não estão tão interessados. Ouviram falar, deram uma olhada, mas a mensagem não chegou, e eles vão embora.
Esses dois tipos de usuários são as bordas da distribuição. No meio há um grande núcleo nebuloso. 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 estiver claro o que você está pedindo e ensinando, isso vence telas únicas grandes 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: Aqui está para que serve isto. Declare o contexto, dentro do produto. Tudo bem pedir o básico - e-mail, senha, telefone. Para todo o resto, explique por que você 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 realizar.
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, não haverá mais abandono? 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, daqui para frente, são seu boletim escolar.
Uma história do Twitter
Vou unir 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 estavam blogando sobre isso, a mídia estava falando sobre isso, e muitas pessoas estavam perguntando: “O que é essa coisa do Twitter? Preciso descobrir e me inscrever.” 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 em uma página que parecia isto:
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ê ama.” Essa é uma descrição bastante boa do Twitter, honestamente.
Então: Isto é 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 mostrávamos uma timeline. Fazíamos você clicar em “seguir” nas pessoas à esquerda. E quando clicavam em seguir, os tweets delas apareciam à direita. Então você entende a ideia toda, em um movimento: Clico em seguir, tweets aparecem, essa é a 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 os seguiu você mesmo.
O onboarding é a 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 aos seus usuários. Em um mundo de IA, a entrega é menos problemática 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 nebuloso, e é onde você realmente conta a história do seu produto.
Use a 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 todos os lugares. 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!
