10 lições de Produto que aprendemos com Rappi, Nubank, Grow e Loft
A área de Produto envolve muita coisa. Há quem diga que bons Product Managers são pessoas capazes de reunir as habilidades de um empreendedor, um expert em processo, um diplomata, um negociador e, claro, um manager.
Para entender melhor — e tentar pegar alguns hacks — , reunimos por aqui um pessoal que entende muito do assunto, numa edição do Canary Talks. Ariel Lambrecht, founder da Yellow (que, depois da fusão com a Grin, se tornou Grow), Geraldine Hagenbuch, head de produto da Rappi, e Hugh Strange, VP de produto do Nubank, participaram de um papo mediado pelo head de Produto e Tech da Loft, Marcio Reis.
Aqui vão as principais lições divididas por eles:
1. Como saber o que as pessoas querem? Vá para a rua!
Ser capaz de trazer inputs do mundo “real” para dentro das paredes de uma empresa é importantíssimo para um time de produto. O que você ouve não só dos clientes, mas de todos aqueles que compõem a jornada do consumidor (nessa lista, entram os estabelecimentos que fazem parte de um marketplace, os motoboys que fazem as entregas de uma startup de delivery, os motoristas de apps etc) é a validação final de que os objetivos da empresa estão sendo cumpridos — ou não. Há muita teoria por trás da área, mas conseguir se colocar no lugar desses players deve ser a principal essência do time. “Produto é a capacidade de resolver a dor de alguém que nem sabe que tem uma dor”, diz o Ariel.
Para conseguir pegar feedbacks do “mundo real”, Geraldine explica que, na Rappi, é importante o time viver a experiência de vender o aplicativo para donos de restaurante. Mesma coisa na 99. A equipe tinha de fazer um número específico de corridas como motorista do app. Assim, é possível saber em primeira mão as resistências, preocupações e dores e identificar soluções mais assertivas (de uma forma muito mais eficiente do que ficar “brigando” com o time de vendas).
Isso ajuda a descobrir novas maneiras de lapidar o produto, considerando o que seu cliente, de fato, busca ou precisa. “Você só entende o que é transportar pessoas quando está dirigindo. Se colocar no lugar do usuário é super importante para conseguir resolver a dor e entender quais hábitos precisa modificar, para chegar onde você quer”, diz Ariel.
Trazer a vida real para dentro da empresa é importante não só para sacar o user behavior, mas também para que o seu produto não vire um empecilho na vida de ninguém. Um exemplo bacana trazido pela Geraldine: na Rappi, quando um estabelecimento está com uma alta taxa de cancelamento de pedidos, pode ser que o problema não tenha nada a ver com o produto em si. “Pode ser que metade da equipe do restaurante tenha faltado naquele dia e o dono não tenha braço para atender todos. Pode ser que tenha acontecido um acidente na cozinha. Quando você entende a dor do outro lado, mesmo que ela não esteja relacionada à sua solução, é possível ajudar com um maior value proposition.”
Essa prática se torna ainda mais importante quando a empresa cresce. Boa parte dos produtos são criados a partir de um problema que o founder sente na pele ou que ele vê um grupo de pessoas próximas sentirem. Então, é normal começar projetando uma solução para si mesmo. Foi o caso do Nubank. Os fundadores sabiam muito bem quais eram os pain points de um cliente de banco tradicional, porque eles sentiam esses pain points. Mas quando a startup ganha tamanho e o produto/serviço passa a ser usado por uma clientela distante dos early adopters, ir para a rua para sacar novos comportamentos e as novas dores que podem aparecer se torna ainda mais importante.
2. Benchmarks: são úteis?
Sim. O lado positivo dos benchmarks é não precisar “inventar a roda” de novo, porque alguém já fez esse trabalho antes. O principal objetivo ao usá-los é o de economizar tempo. Benchmarks também ajudam a mostrar pontos cegos da estratégia, uma vez que trazem lições que a sua empresa, em algum momento, iria aprender de qualquer jeito se tivesse inventado a roda por si própria. Há um “mas” nessa história.
Nenhuma startup deve ser guiada por benchmarks. Cases de fora não estão no mesmo contexto social, político, econômico, cultural e geográfico, com suas vantagens e desvantagens, que o seu negócio. O lance é aprender o que há para aprender e criar uma versão que funcione melhor para o seu contexto.
A indústria de bike-sharing é gigante na China, país de onde os sócios da Yellow (que virou Grow depois) tiraram inspiração para criar a startup. Quando Ariel e o time de fundadores anunciaram que queriam montar um negócio do tipo no Brasil, muita gente falou que não ia dar certo. Os motivos são até meio óbvios: quando se disponibiliza um bem físico nas ruas de um país conhecido pela desigualdade social, as chances de depredação e roubo são altas. Só que a Yellow não queria fazer as coisas da mesma maneira que os chineses.
Enquanto os benchmarks da Ásia haviam apenas colocado bicicletas nas ruas das cidades e lidado com as repercussões depois (ao estilo “melhor pedir desculpas do que permissão”), a Yellow alinhou com o poder público o lançamento do novo serviço. Chegou até mesmo a envolver as comunidades ao redor das estações de bicicletas, para que os moradores passassem a vê-las como um patrimônio da cidade e, portanto, cuidassem para que não fossem depredadas.
3. Tomada de decisões + mitigação de risco
Um dos trabalhos do Product Manager é analisar várias opções de estratégia e conseguir escolher aquela com o menor número de trade-offs ou com trade-offs menos impactantes para a empresa. Resumindo, quase toda decisão em Produto tem trade-offs. Exemplo: se o pessoal da Yellow colocasse nas ruas bicicletas de alumínio (mais leves, mais fáceis de guiar e, portanto, melhores para a experiência dos usuários) corriam o risco de que elas fossem roubadas, derretidas e aparecessem em algum depósito de sucata. Outro exemplo: na Rappi, que opera em sete países, há uma porção de soluções que poderiam ser implementadas ao produto para resolver questões baseadas em costumes regionais — mas nem sempre investir na criação dessas soluções traria retorno relevante para a empresa, globalmente.
Some a esses pontos outra questão: é complicado tomar algumas decisões usando a medida de relevância. Não dá para comparar o número de novos clientes com a segurança digital de uma plataforma, por exemplo. Toda empresa quer crescer, mas quer crescer garantindo segurança aos dados dos usuários.
Tem mais. Uma empresa é formada por pessoas e, quanto mais satisfeitas essas pessoas estão com seu trabalho, mais chances de elas 1) desempenharem bem o que precisam fazer; e 2) não só continuarem na startup, mas trazerem mais gente boa para dentro. Digamos que um desenvolvedor está há um bom tempo num squad essencial para o negócio, mas ele quer trabalhar em outro projeto. A lição aqui é a de que, às vezes, você vai ter que deixar um squad subótimo só pelo investimento de longo prazo nas pessoas. Resumindo: trade-offs, trade-offs everywhere.
Dois conceitos que podem ajudar a dividir problemas e estruturar abordagens diferentes para eles são os de highway (estrada, em inglês) e dirt road (estrada de terra). Basicamente representam os lugares em que você quer e pode dirigir muito rápido e aqueles em que você deve dirigir devagar e com calma — até porque, muitas vezes, apenas não dá para ir rápido.
Uma situação que ilustra bem a ideia acima foi vivida pelo Nubank. O cartão de crédito da startup se espalhou pelas carteiras do país com velocidade, mas esse crescimento poderia ter sido muito mais rápido. Hugh explica que, na época, o time ainda estava estabelecendo qual modelo de pontuação de crédito deveria seguir, por isso, precisou puxar a embreagem e guiar ao estilo dirt road. O ponto é que os testes envolvendo pontuação de crédito não eram tão rápidos quanto os de conversões e fluxos do site, por exemplo, porque o feedback loop de um credit score é bem mais demorado.
Quando Hugh fala em feedback loop, ele se refere a uma técnica cunhada por Eric Ries, autor de Lean Startup, como “Build-Measure-Learn feedback loop”. De um jeito simples, significa que cada movimento de um negócio deve passar por 3 passos: construir — medir — aprender. Esse loop, então, é representado assim:
4. Como contratar um PM
Um product manager não constrói ou opera o produto, diretamente. Seu trabalho é garantir que a galera que faz e opera tenha todas as ferramentas e o mindset certo.
Por ser uma especialidade relativamente nova, não há uma formação específica que a empresa deva procurar. Ariel e Geraldine até levantam o ponto de que algumas das melhores pessoas com quem já trabalharam na área, nunca haviam atuado com Produto antes. Uma coisa é certa, porém: o sujeito tem de ter a habilidade de organizar problemas, quebrá-los em pedaços e encontrar maneiras de resolvê-los, um por um.
Geralmente, a entrevista de um PM gira em torno de três etapas, no mínimo — a ordem delas varia de empresa para empresa. Uma entrevista cultural, outra sobre visão de produto e, por fim, uma mais técnica: a resolução de um case. Essa última fase é importante porque é o momento não só de notar a vontade que a pessoa tem de trabalhar na empresa e quais opiniões tem sobre o produto (o mínimo esperado de um candidato é que ele tenha opiniões sobre o produto), mas também seu jeito de pensar sobre a área. Normalmente, participam dessa última etapa PMs seniores ou tech leads.
A entrevista de case pode ser feita em tempo real (o candidato analisa um problema junto com o entrevistador, via Skype, por exemplo) ou ter um prazo de apresentação. Dar um deadline para o candidato pensar no case para depois apresentá-lo pode ser legal, especialmente quando a pessoa não tem muita experiência. Assim, ela tem mais tempo para analisar o problema com profundidade e planejar como expor seu raciocínio.
5. Product Market Fit
Há uma porção de métricas para avaliar se um produto vai bem: número de novos clientes, taxa de retenção, quantidade que segue ativa depois de X tempo…
Mas há algumas noções de sucesso menos óbvias. Ariel conta que, na Yellow, eles resolveram que saberiam se a empresa tinha encontrado PMF no dia em que assistissem a alguém na rua levantando uma bike caída no chão. “Significa que um cara, que nem é meu usuário, consegue encarar aquilo como um patrimônio da cidade.”
Nos primeiros anos de Nubank, as duas principais métricas eram o número de novos clientes e o entusiasmo deles em relação à marca. O objetivo aqui, explica Hugh, era garantir que os clientes só mencionassem coisas boas a respeito da empresa, quando falassem dela aos amigos.
Na hora de determinar o que vai fazer você bater o sino do “conquistei meu PMF”, é importante não focar em uma métrica blindada. “Entender o ‘fit’ não é olhar binariamente um pedaço do negócio, mas a cadeira inteira”, diz Geraldine. “Se o adoption está bom, mas o GMV está caindo, será que o time de operações tem todas as ferramentas para ver o que está acontecendo? Para consertar o problema?”.
6. Offline x Online
Produto não é só a parte de tecnologia. Produto envolve toda a experiência do usuário. Quando o time foca somente no digital, pode ser difícil notar problemas que aparecem no mundo físico. Só para ilustrar: na 99, o taxista faz parte da experiência do cliente. Se ele é citado no maior número de reclamações dos usuários, é preciso encontrar maneiras de ajudá-lo para melhorar a experiência. Note que essa é uma tarefa que pode se tornar até mais complicada do que construir um aplicativo, pois envolve cultura, remuneração, metas, motivação etc.
No começo de uma empresa, pode funcionar criar squads relativamente grandes para não perder o contato com o offline. Assim, os engenheiros conseguem ficar a par da dor do frontline e os loops de feedback se tornam, portanto, mais rápidos. O lado ruim é que esse squad pode começar a pensar como time e algumas decisões podem tomar prioridade sobre outras — por isso, essa fórmula não funciona ad aeternum. Na Loft, que já tem mais de 150 funcionários, Márcio conta que o layout do escritório influencia na comunicação entre squads: atendimento está ao lado de Produto, o comercial negocia ali perto e a decisão acaba ficando dentro do squad estendido e não necessariamente somente no time de Produto.
Para Geraldine, por outro lado, pode ser importante separar os squads em etapas da jornada do usuário para conseguir ter métricas mais claras sobre o desempenho de cada uma — e até por uma questão de identificar problemas com mais clareza.
Pense nos times de pré-venda e pós-venda. Na pré-venda, o cara vai estar preocupado em maximizar a conversão, ou seja, garantir que o pagamento funcione e o check-out seja eficiente. Mas não vai, necessariamente, estar preocupado se os ovos vão chegar quebrados à casa do cliente ou se serão entregues no prazo estipulado, porque esse é o trabalho de pós-venda.
7. Quais sinais para quebrar a jornada do usuário com PMs dedicados?
Todo squad precisa de uma meta de negócio muito clara — seja um problema que precisa ser resolvido ou uma métrica que deve ser otimizada. Se não é possível ter uma meta diferente para cada squad, talvez o escopo esteja muito grande e seja necessário fatiá-lo em pequenas metas.
Para Hugh, você vai perceber quando precisa quebrar a jornada do usuário ao sentir que as coisas estão indo muito devagar — ou que os squads estão perdendo muito tempo.
Um ponto importante de cuidar aqui (ainda mais quando se é uma startup dando os primeiros passos) é para que a meta de uma equipe não ganhe prioridade sobre outra.
Quando diferentes componentes do negócio dividem os mesmos recursos, uma das metas pode ser comprometida. Um exemplo para ilustrar melhor: imagine que times de pré-venda e pós-venda de um e-commerce dividam o mesmo time de tecnologia. A meta de pré-venda é garantir que a compra seja feita, sem nenhuma fricção. Já a de pós-venda, é se certificar de que o produto adquirido pelo usuário chegará à casa dele na data prometida. Não é difícil imaginar as demandas do time de pré-venda se tornando “mais importantes” para o time de tecnologia, já que trazem maior retorno no curto prazo. Ao mesmo tempo, quantos clientes irão retornar ou promover o negócio se o prazo combinado para a entrega não for cumprido?
Uma solução é focar em uma parte da jornada e despriorizar outras tarefas, até que aquela parte esteja funcionando bem. E então, seguir para a próxima parte e assim por diante.
8. Comunicação e visibilidade = confiança em Produto
Criar ferramentas que deixem mais fácil visualizar e entender o que o time de Produto está fazendo pode ser bastante útil. Para Hugh, inclusive, essa é uma das funções da área: garantir que todo mundo sabe para onde a empresa está indo e qual a função de cada um na conquista desse objetivo final.
O conselho dele é conseguir alinhar toda a empresa numa “north star metric”, uma métrica final, imutável, que todas as equipes devem trabalhar para perseguir. Outro, é ter um espaço (uma parede, um quadro branco, uma cartolina, que seja) que exiba os projetos que estão sendo desenvolvidos por cada time, deixando bem claro como eles se relacionam com as prioridades do negócio. “A ideia é que, só de olhar o quadro, a pessoa consiga entender o que está sendo feito.”
Com ou sem quadro branco, uma coisa é fato: é preciso trabalhar a comunicação do time de Produto com o resto da empresa. Estimular mesmo o pessoal a falar, a encontrar maneiras de se comunicar com intensidade. Documentar é essencial aqui, com atenção para onde essa documentação vai ser exibida. Tem de estar nos canais de comunicação que as pessoas usam de fato. No Rappi, toda semana, faça chuva ou faça sol, o CTO solta uma atualização do que o time de tech está fazendo, num grupo da empresa. Geraldine ainda dá a sugestão de criar páginas internas simples (em Google Sites) e usá-las como um portal de release notes. Assim, fica mais rápido responder à pergunta: “o que o seu time está fazendo?.” É só enviar um link.
Mas é importante estimular os times a conversarem tête-à-tête. Ainda mais quando a empresa cresce e o colaborador pode ficar com a impressão de que não tem ideia do que a pessoa que senta ao lado dele está fazendo.
Se o quadro branco ou o canal de comunicação não funcionam estimule 1:1s (as pessoas podem se sentir receosas de fazer esse tipo de contato, se não há estímulo). Lembre-se de que a cultura de startups ainda é relativamente nova por essas bandas e que, em empresas tradicionais, não é sempre que o trainee de marketing tem espaço (ou sente que tem) para chamar um product manager para um café.
9. PMs e tech teams: uma história de amor
Ainda no tema relações interpessoais entre colaboradores, impossível não falar sobre a relação entre o time de Engenharia e o de Produto. O PM ideal vai ser o sujeito que cria uma relação de parceria com os desenvolvedores. Como se faz isso? Comunicação. Para começar, é preciso que exista muita visibilidade para os dois times da direção que o barco deve tomar. Boas decisões exigem contexto, para ambos os lados.
Há quem diga que é importante que a relação entre Tech e Produto seja de uma “saudável tensão”, em outras palavras, que não haja problema de um desafiar o outro quando achar que deve. Nessas situações, ajuda ter uma cultura de comunicação construída em cima de argumentos bem fundamentados e dados, muitos dados. No final do dia, o resultado que um bom relacionamento entre as duas áreas deve gerar é a resolução de problemas importantes, com soluções eficientes, ao mesmo tempo em que se constrói uma equipe qualificada e motivada pelo trabalho que precisa fazer. Se há muito atrito entre as partes, vale a pena dar uma olhada para ver se a liderança de um dos lados não está com a pessoa errada.
Da mesma maneira que o time de Produto, o líder de tecnologia também precisa ir para a rua e saber quais os pain points dos usuários. Se ele ficar preso em codar, não vai ter contexto para tomar boas decisões ou para estar alinhado com os objetivos do time de Produto.
10. O valor de research
A necessidade de montar um time de research aparece quando 1) há muita demora para achar o product market fit ou 2) o seu público está crescendo e ficando muito diferente dos early adopters. Em ambos os casos, o desafio é o mesmo: entender com profundidade o comportamento de um grupo de usuários diante do produto/serviço.
Se você não vive nenhum desses momentos, provavelmente, só precisará de um baita time de research quando sua empresa estiver mais madura. No começo, até por uma questão de alocação de tempo e recursos, o que você precisa fazer é colocar seu produto para rodar e colher feedbacks dos usuários e métricas. Uma frase do fundador do Wordpress, Matt Mullenweg, resume bem a idea: usage is like oxygen for ideas.
O time de research é um time especializado que deve trabalhar em algo mais complexo do que a cor de um botão, por exemplo. Quando o time da Grow teve de escolher como seriam as plaquinhas das estações de bicicletas, não fazia sentido fazer uma baita pesquisa só para descobrir a melhor opção de texto, cor etc. Ariel conta que deu para resolver a questão com um teste A/B, super simples, feito internamente mesmo. Com uma ferramenta de pesquisa, toda a empresa votou na plaquinha que achava melhor e pronto. A ideia é que algumas coisas (principalmente detalhes) não dependam de um debate ou imersão gigantesca para começarem a rodar.
10 Hacks rapidinhos sobre Product Management
- Sempre que der, vá para a rua: É muito fácil o time de Produto ficar totalmente imerso em apagar incêndios do dia a dia e esquecer de buscar inputs no mundo real. É importante que a equipe vá à rua para tentar entender por completo o lado, não só do usuário, mas de todas as pontas formam o produto que você oferece.
- Como usar benchmarks do jeito certo: Benchmarks podem ser bastante úteis para construir argumentações, mostrar pontos cegos na estratégia do business e economizar tempo — uma vez que alguém já resolveu o problema (ou parte do problema) que você quer resolver. Atente-se, porém, para o fato de que usar benchmarks como guia para a empresa pode ser uma baita enrascada: geografias diferentes terão vantagens e desvantagens diferentes. A dica aqui é sempre adequar o produto ao local em que você está.
- Negociando com trade-offs: Boa parte das decisões que um PM vai tomar vão ter downsides. Cabe a ele conseguir medir os prós e contras, dentro daquilo que a startup considera como seu grande objetivo, para tomar decisões.
- Contrata-se PMs: Bons profissionais de Produto podem vir de formações diferentes e podem, inclusive, nunca ter trabalhado com Produto antes. Na hora de recrutar um PM, no entanto, é importante notar algumas características: a habilidade do candidato para quebrar problemas e simplificá-los, o engajamento dele com os problemas enfrentados pelo negócio e a capacidade de relacionamento interpessoal.
- Achando o Product Market Fit: É essencial acompanhar na ponta do lápis métricas como aquisição de novos clientes, retenção e churn para saber se há Product Market Fit. Às vezes, porém, pode fazer sentido ter algum indicador mais qualitativo do que quantitativo. Na Yellow, os fundadores costumam dizer que saberiam que tinham encontrado PMF no dia em que vissem as pessoas encarando as bicicletas espalhadas pela cidade como patrimônio e, portanto, cuidando para que elas não fossem depredadas. No Nubank, a empolgação dos usuários também era um resultado visto para o PMF.
- Tem diferença entre produto online e produto offline? Produto precisa encarar todos os elementos que formam a jornada do cliente como parte de seu trabalho. Não adianta separar a visão de online e offline, uma vez que, se uma dessas pontas não estiver funcionando direito, a experiência do cliente será ruim.
- Quebrando a jornada do usuário: Squads precisam de metas de negócios claras. Se não é possível estabelecer objetivos diferentes para cada um, pode ser sinal de que o escopo está muito grande e que é hora de dividi-lo melhor. Atenção nesse ponto para que a meta de uma equipe que compartilha os mesmos recursos com outras não se torne “mais importante” do que as demais.
- Comunicar, comunicar e comunicar: Lembre-se de que todas as equipes da empresa precisam ter o contexto necessário para estarem alinhadas e, assim, perseguirem o mesmo objetivo. Comunicação é elemento-chave aqui. Cabe ao time de Produto encontrar maneiras de deixar claro o que está sendo feito pela área, nos canais de comunicação usados por todo mundo, seja com relatórios enviados via WhatsApp, Slack ou num site interno.
- PMs e Tech teams: É muito importante o Product Manager estabelecer uma relação de parceria com o time de tecnologia. Para isso, vale estruturar uma comunicação focada em argumentos embasados na experiência do usuário e dados, muitos dados. Ao mesmo tempo, ambos os times precisam se sentir confortáveis para desafiar um ao outro, então, é importante criar um ambiente no qual críticas e opiniões sejam não só bem-vindas, como estimuladas.
- Time de research: Um time de research é super importante em duas situações especiais. 1) Se a sua empresa ainda não encontrou Product Market Fit ou 2) se o negócio cresceu e o perfil de novos usuários ficou muito distante do perfil inicial. Nem toda decisão tomada sobre um produto exige uma enorme pesquisa por trás: é possível criar ferramentas de research, internas mesmo, para conseguir decidir com velocidade.
