O que você aprendeu com Marty Cagan pode estar mais para uma utopia do que para realidade. Entenda o porquê.

Publicado originalmente no blog da PM3

Ok, ok! Eu sei que isso não é uma opinião popular e, confesso, gosto muito do trabalho do Marty Cagan. Também não pretendo ser o dono da razão e minha intenção aqui é simplesmente compartilhar uma opinião e atiçar a parte crítica de quem consome conteúdo da área de produto. O problema que vejo nos textos e livros do Cagan é que ele não aborda muito a realidade da maioria das empresas — seja no livro Inspired, em alguns artigos no blog do SVPG ou até mesmo no seu novo livro Empowered. Ele aborda assuntos de uma maneira simples, clara e objetiva — e, muitas vezes, chega até ser motivacional. O porém é que, no mundo real, muitas das coisas pregadas por ele não se concretizam exatamente como está escrito e isso gera uma série de problemas na cabeça de vários profissionais.

Você deve estar pensando: “Ah, mas é porque no Brasil a gente é imaturo. Lá fora, em especial no Vale do Silício, as coisas não são assim”. Negativo. Chega dessa síndrome de vira-lata. Eu trabalhei na Intuit, referência em tecnologia e uma das maiores do mundo listada na NASDAQ, e posso dizer que não é muito diferente das grandes empresas de tech no Brasil e América Latina como Nubank, Mercado Livre, Movile e outras. Já fui no Vale do Silício diversas vezes e fiz benchmark em muitas empresas como Mozilla, Google, Evernote e várias outras. Conversei com muitos PMs, GPMs, Heads de diversas empresas… e todos com quem tive contato — sim, todos — estão no mesmo barco que nós brasileiros no quesito de maturidade da gestão de produtos digitais. Inclusive, dependendo da empresa no exterior, algumas têm uma estrutura de produto bem inferior a muita empresa brasileira. Essa é só a minha perspectiva. Se você encontrar um estudo que seja mais confiável para fazer essa comparação, linka nos comentários!

1. A falta de profundidade em alguns pontos

Marty Cagan prega muito o conceito de autonomia em times e pessoas empoderadas. Mas ele não fala como resolver o dilema da autonomia conforme as estruturas das empresas crescem. No livro Inspired, existem 6 cases de PMs em grandes empresas de tecnologia que ele usa como exemplo, mas, sinceramente, falta profundidade.

Ainda no mesmo livro, em dois capítulos diferentes, ele cita os desafios do “Growth Stage” e do “Enterprise Stage” em poucas páginas. Mas somente menciona os seus desafios, não há propostas de soluções e pouquíssimo benchmark. Isso só demonstra que não existe resposta fácil ou fórmula para solucionar esse tipo de desafio — cada empresa vai exigir soluções diferentes e não adianta tentar usar o que algum especialista fala como regra. E nem vou entrar no mérito que o Cagan só traz empresas que possuem muito dinheiro para queimar (ex: Big Techs como o Google).

Trecho dos capítulos 4 e 5 do livro Inspired

É muito fácil ter um time de 5–10 PMs seniores e empoderá-los. Agora quero ver ter uma equipe de +60 PMs, entre eles vários JRs e plenos, e ainda conseguir dar o mesmo nível de empoderamento. Sem mencionar que é comum os líderes das empresas (C-levels, VPs, Heads, etc) darem um direcionamento mais concreto sobre o produto, afinal essas pessoas acabam olhando só para isso, definindo visão, estratégias de curto/médio/longo prazo e que, de certa forma, acabam diminuindo o escopo do PM. Na prática, o PM acaba atuando numa parte menor do produto, já que ele precisa dividir sua responsabilidade com outros 50 PMs.

2. A verdade que ninguém fala

Faria Lima em 2020

Na comunidade da PM3tivemos uma discussão sobre isso puxada pelo nosso aluno Felipe Barbosa, e ele disse uma frase muito bacana: “talvez poucos admitam, porque é muito mais legal a visão do Cagan”. E é isso mesmo! O que o Cagan ensina está mais para uma utopia do que realidade. E é por isso que gostamos tanto, pois acaba ressoando com coisas que concordamos. Pode observar a sua reação ao ler qualquer coisa que o Marty escreve, você vai concordar com tudo. Você lê como se sua cabeça estivesse balançando para frente e para trás dizendo “Sim. É isso ai!”, “Concordo.”, “Caramba. Sempre pensei isso mas não tinha conseguido expor em palavras”.

Algumas definições de utopia:

  • “Situação ou local idealizado, onde tudo acontece de maneira perfeita ou ideal”;
  • “Lugar ou estado ideal, de completa felicidade e harmonia entre os indivíduos”;
  • “Ideia ou descrição de um país ou de uma sociedade imaginários em que tudo está organizado de uma forma superior e perfeita”.

Nada contra o modelo proclamado pelo Marty Cagan — pelo contrário! Eu me inspiro nele (tanto que o livro se chama Inspired rs) e acho que todo profissional deveria também. Apenas não assuma que isso é uma realidade nem aqui, nem nos EUA e nem na Europa. Idealmente na sua empresa você chegou em algum lugar no meio e tá tudo bem.

Não é à toa que o Cagan é referência em produto e que muita gente, inclusive a PM3, usa vários dos seus princípios como base para ensinar e subir a barra do mercado. Mas isso não quer dizer que tudo acontece como está escrito.

3. A realidade

3.1. Quando a liderança define o que deve ser construído não é a mesma coisa que top-down

Isso é uma grande falha de interpretação das pessoas. Muita gente comenta “Na minha empresa é top-down. Meus líderes decidem o que tenho que atacar baseado numa estratégia maior da empresa. Não tenho autonomia”.

Neste ponto aqui o Marty Cagan está coberto de razão e, ao meu ver, o problema está mais na interpretação das pessoas e é o que acaba gerando essa “utopia” no mercado. As pessoas acabam interpretando de um jeito diferente achando que tem autonomia para decidir tudo. Abaixo vamos ao resumo do que é a realidade (e, repito, aqui eu estou concordando com o Cagan pois o problema está na interpretação das pessoas).

Em linhas gerais, as equipes possuem autonomia e liberdade para mudar o rumo da solução e provocar possíveis pivôs. As equipes recebem as grandes apostas em um nível super abstrato e depois precisam se organizar para alcançar o objetivo (depois leia esse textosobre planejamento estratégico anual).

Se a sua empresa for muito grande, acaba sendo bastante comum que os líderes decidam as “grandes apostas” mas isso não quer dizer que é um top-down. Você continua com bastante autonomia para decidir o “como” e testar soluções. E ainda digo mais, quanto mais sênior você é, mais é esperado que você encontre oportunidades/necessidades não-atendidas pela atual estrutura organizacional. Uma coisa é você atacar o seu contexto com toda a capacidade. Outra coisa é mostrar que tem um contexto X com um potencial gigantesco e que a empresa não está atacando.

“The essential point of team objectives is to empower a team by a) giving them a problem to solve rather than a feature to build; and b) ensuring they have the necessary strategic context to understand the why, and to make good decisions.”

Fonte: https://svpg.com/team-objectives-empowerment/

Se a sua empresa é muito pequena, também é super comum as grandes apostas virem dos fundadores e sócios. Porém, com o tempo, espera-se que a equipe comece a perceber oportunidades e sugira grandes apostas. Aliás, eu diria que é assim que você pode se destacar nas empresas. Conseguir o sponsor de alguém com autonomia para “bancar” sua hipótese de grande aposta é ótimo, pois você vai conseguir fazer de ponta a ponta uma iniciativa bem grande.

Todas as vezes que trabalhei em empresas maiores (+50 PMs), a estratégia e as “big bets” eram definidas pela alta gestão. Não importava o framework que você usava, seja ele OKRs ou não. Você como PM tinha uma autonomia somente dentro do escopo da sua big bet. Raros os casos nos quais você conseguia fazer um pitch para conseguir uma equipe para atacar um novo segmento/problema — normalmente isso também vinha da liderança e eles procuravam alguém que tivesse performando bem para liderar isso.

3.2. Algumas pessoas não possuem o perfil ou não querem fazer discovery

A verdade é que alguns funcionários querem sim se envolver no Discovery de ponta a ponta. Porém, você sempre vai ter funcionários que ficarão mais felizes em trabalhar na implementação da solução do que o Discovery. O que o Marty Cagan prega, seja no Inspired ou Empowered, é uma cultura de colaboração onde um grupo de pessoas está engajado em fazerProduct Discovery para mitigar os 4 riscos e, talvez, até mesmo impactar a estratégia do produto de acordo com as descobertas que são feitas. Porém ele simplesmente ignora o perfil de pessoas que além de possuírem mais aptidão em construir, preferem atuar em cima disso do que discutir estratégias e fazer Discovery (esse texto sobre os 3 tipos de PMs aborda o tema muito bem (em inglês)).

É óbvio que qualquer pessoa vai valorizar designers, desenvolvedores e outros colaboradores que falem com os usuários. Mas alguns líderes (eu diria a maioria, inclusive) não possuem grandes expectativas de que esses profissionais descubram ou participem da direção estratégica da empresa/produto baseado no que foi descoberto em processos de pesquisa. A expectativa em cima dessas pessoas é mais direcionada à validação do que está sendo construído e da implementação, pois é nisso que elas são especialistas. Esse tipo de coisa se acentua ainda mais quando são times focados em plataformas internas ou eficiência de custo e performance (algo mais técnico mesmo).

Neste artigo o Cagan até fala que quando não há nenhum engenheiro que queira fazer Discovery, ele procura o CTO/VP de Engenharia para tentar fazê-lo subir a barra do time. Além disso, ele diz que acredita ser um papel do Tech Lead puxar isso e, inclusive, participar do Discovery. Concordo que seria o mundo ideal, mas como já sabemos, nem sempre é assim.

3.3. Times de missionários vs mercenários

Pensando no mundo ideal do Cagan:

  • Missionários acreditam numa visão e são apaixonados pelo problema que eles têm que resolver.
  • Frase inspiradora. Bonita. Até cai uma lágrima quando se lê.

A verdade é que muitos funcionários só estão trabalhando. Poucos (e geralmente são os que se destacam) realmente compram essa ideia e se apaixonam pelo problema. Na minha interpretação, o que Cagan está tentando passar aqui, tanto para PMs como para líderes de pessoas, é que devíamos tentar engajar pessoas em torno de um problema e criar empatia com o usuário — e um bom PM sabe fazer isso com maestria, com sua equipe e stakeholders.

  • Tem autonomia e responsabilidade sobre o problema, sendo responsáveis pelo sucesso e pelo fracasso.
  • Existe muita confusão sobre o que é autonomia. E isso varia de empresa para empresa, bem como da interpretação de cada pessoa. A verdade é que, como tudo na vida, precisa existir um balanço, nem tudo é top-down, nem tudo é democrático. Mas eu já cansei de ver diversas decisões não sendo tomadas porque queriam dar autonomia para os times e eles não chegavam num acordo. Ou, pior ainda, decisões tomadas sem um bom contexto ou direcionamento. Já estive em situações em que eu simplesmente gostaria que o C-level batesse o martelo e falasse no que devíamos focar.

Um time que consegue idear, testar, validar e colocar em produção com pouca ou nenhuma dependência de outros times é um time que tem certa autonomia. Mas nem sempre você vai ter todas essas autonomias. Depende do momento da empresa, do contexto do seu time e de vários fatores externos.

Além disso, os líderes precisam entender o momento de cada um de seus liderados e ajustar o estilo de liderança de acordo. É uma combinação de risco, contexto, estratégia e capacitação dos PMs. Aqueles que precisam sempre ter uma decisão de algum superior é porque, via de regra, estão sob uma liderança ruim, bem como aquele PM que não possui espaço para mostrar oportunidades para a liderança.

  • O time precisa funcionar como uma autêntica startup, com todos os membros colaborando para atingir os melhores resultados.
  • De fato precisa. Mas cansei de ver, tanto em big tech quanto startups menores (seja fora ou no Brasil), times de UX separados do squad, times de research alocados separadamente, áreas com diferentes prioridades (ou até mesmo conflitantes). Quem dera fosse fácil assim, todo mundo funcionando como uma autêntica startup onde os incentivos estão alinhados e todo mundo consegue cooperar e se ajudar.

É muito bacana ter alguém do calibre do Marty Cagan e outras pessoas com poder de influência lutando por uma forma diferente de trabalho. Porém, quando essa mensagem é transmitida, é necessário sempre lembrar que a realidade de MUITOS lugares não é bem assim. Caso contrário muita gente fica achando que essa “visão/utopia” é a realidade. Claro que, como já disse acima, o que o Marty prega é uma ótima visão para ser seguida ao invés de simplesmente aceitar o status quo.

Algumas pessoas vão dizer que quando uma ou todas estas coisas falham é culpa do PM, pois ele é o responsável em dar a direção que o time vai seguir e conseguir o buy-in. Se ele não consegue o buy-in a culpa é dele — e quando a diretoria tem que entrar para resolver, foi porque o PM falhou.

Não concordo com tal afirmação porque o PM não consegue resolver tudo. Simplesmente não dá. Algumas vezes pode ser falta de competência, mas há situações em que simplesmente está fora da alçada. Não dá para considerá-lo um super herói que deveria resolver tudo.

O meu livro favorito é “The Hard Things About Hard Things”, do Ben Horowitz, e gosto muito dele porque ele conta a realidade, fatos reais e aprofunda. Conversando com Raphael Farinazzo, chegamos à conclusão de que é impossível ser mais aprofundado e realista do que “eu tinha ânsia de vômito todos os dias, quase morri e não sabia o que fazer”. Também gosto de livros de liderança que são inspiradores, mas precisamos ser críticos para identificar o que é inspiração e o que é realidade. Muita gente migra para a área de produto achando que vai trabalhar no “Fantástico mundo de Bobby”, onde tudo é lindo, e acaba ganhando um burnout de brinde quando se depara com lugares que possuem uma realidade diferente.

Por fim, espero ter despertado em você um pouco de pensamento crítico com esse texto. Meu objetivo é que comece a refletir mais sobre o que Marty Cagan ou qualquer outra pessoa diga. Às vezes você precisa daquilo somente por um período na sua empresa e, depois que as coisas se ajustarem, você vai precisar focar em outros problemas. A visão do Cagan, apesar de idealista, é boa e transformadora. Acho que o ponto principal é que não dá para aplicar o que ele defende de uma só vez.

Deve ser construído aos poucos, especialmente em empresas grandes e mais tradicionais. Esse é o principal ponto de atenção que observo para as pessoas que querem aplicar tudo ao pé da letra, e se essa é a sua expectativa, se prepare para ficar frustrado. Ser agente de mudança é caro e, muitas vezes, cansativo. Se dispor a enfrentar o status quo e pagar o preço para lidar com as próprias frustrações é o que torna contribuidores individuais em líderes por influência.

Preste atenção em você mesmo, perceba se está entregando mais energia do que tem para gastar. Em alguns lugares, promover a mudança será mais tranquilo. Em outros, impossível. Discuta isso com sua liderança, alinhe expectativas e não se cobre demais.

Nem Roma, nem o ambiente utópico do Cagan podem ser construídos em um dia.

Foque nos princípios que são ensinados, seja pelo Marty, pelo manifesto ágil ou qualquer outro. Os pormenores são o de menos e estão em constante mudança — evite criar “regras que todo mundo deve seguir” para trabalhar bem. Evite cair na falácia do “vamos implementar o modelo Spotify e todos nossos problemas serão resolvidos”. A vida não é simples. E empresas, indivíduos, processos e produtos muito menos.

Obrigado a quem me ajudou a revisar e debater sobre o tema para escrever esse artigo: Gabriel WerlichDiego PobleteRafael JustinoRenato CairoRaphael FarinazzoBruno CoutinhoDan Printes e Efrem Filho.

E, de repente, o Instagram começa a ficar lotado de funcionalidades

 

  • Newsfeed
  • Stories
  • Reels
  • DMs
  • Chat em grupo
  • IGTV
  • Shopping

Sempre que um concorrente surge com um novo formato que funciona, o Instagram adiciona algo similar (para não dizer copiado) na sua interface. O grande risco é ficar sem graça ou difícil de usar. O Facebook é um exemplo disso, pois possui todas as funcionalidades imagináveis, mas o número de usuários ativos está cada vez menor.

Porém, a última atualização do Instagram claramente tem a ver com mais uma atitude defensiva (dessa vez contra o TikTok. Lembra como fizeram contra o Snapchat?) e com um posicionamento mais forte em relação ao seu novo modelo de negócio (Shopping).

Os Reels agora estão numa zona super acessível de clique, e os links de compras, que já estavam espalhados pelo aplicativo há algum tempo, agora ganham mais destaque, ficando no centro do app:

Image for post

Como não havia mais espaço para as notificações e nem para o botão de publicação no feed, eles moveram ambos para o canto superior direito:

Image for post

Essa mudança pode parecer pequena, mas deixou algumas pessoas chateadas, já que a Thumbzone ficou mais complicada para as atividades que, até então, eram as principais do Instagram:Image for post

A Thumbzone mostra o quão fácil é interagir em uma tela de celular com apenas uma mão. Quanto maior a tela, mais dificil é de interagir.

Cliques errados até o usuário aprender a usar a nova interface

A equipe de Produto do Instagram com certeza sabia que as pessoas iriam se confundir no começo e, como consequência, iriam acabar interagindo com o Reels e o Shopping. Enquanto a “Curva J” acontecia, isso era uma forma de fazer um marketing para as novas funcionalidades.

Image for post

Curva J

 

Obviamente, no início, a taxa de engajamento com o Reels e o Shopping através dos botões na parte central do app devem ter sido desastrosas. E, se duvidar, até mesmo outras funcionalidades devem ter caído em desuso. Afinal, as pessoas estavam aprendendo a usar a rede social com a nova interface.

Depois da curva de aprendizado acontecer (Curva J), é que o jogo do Instagram realmente começa. Estima-se que entre 49% e 75% das interações no celular são feitas com o polegar, sendo assim, a capacidade de alcançar funções essenciais com o polegar se torna bastante importante para qualquer aplicativo — e não é à toa que eles estão destacando o Shopping e o Reels.

Conclusão

Com esse movimento, nota-se que o Instagram está buscando reduzir o número de posts feitos pelas pessoas — em especial as que não são focadas em algum nicho, dado que o botão de publicar algo no feed está despriorizado dentro da Thumbzone.

Tudo indica que o Instagram quer deixar pessoas “não-influencers” focadas em consumir conteúdo, e não necessariamente em criá-los. Isso conecta muito com a estratégia do Shopping, pois tudo indica que o Instagram vai começar a priorizar influenciadores no seu feed e, mais que isso, priorizar influenciadores que de alguma forma influenciem em transações dentro da plataforma.

Diretamente do blog post oficial do Instagram sobre a mudança:

A aba de Shopping oferece uma maneira melhor de se conectar com marcas e criadores e descobrir os produtos que você adora

Vamos ver como as pessoas irão se adaptar durante esses próximos meses e analisar se começar a fazer esse push para criadores/influencers irá abrir uma oportunidade para outra rede social se destacar e começar a atrair pessoas, já que o Instagram se torna mais complexo a cada ano.

PS: Neste outro post sobre Estratégia de Produto eu conto como muitas funcionalidades pode prejudicar o produto como um todo e, no final das contas, machucar o negócio. Recomendo como leitura de follow-up caso você tenha chegado até o final desse artigo.

Originalmente publicado no blog de produto da PM3:  https://www.cursospm3.com.br/blog/analise-a-razao-pelo-qual-o-instagram-mudou-seu-design

Foi por causa disso que consegui meu primeiro emprego em São Paulo numa startup
Vejo muitas reclamações sobre o mercado estar exigente com a experiência dos profissionais que querem iniciar na área de Produto. Honestamente o mercado está certo — não é nada fácil ser um Product Manager e exige muita habilidade e entendimento de estratégia e da área técnica. Se falta experiência no seu currículo faça do limão uma limonada (com Gin) e inicie seu projeto paralelo! Além de se divertir você vai desenvolver habilidades e terá muito para compartilhar nas suas entrevistas.

Vejo algumas pessoas querendo fazer cursos, aprender linguagem de programação e coisas do tipo. Embora não haja nada de errado nisso (pelo contrário, super recomendo!), acredito que tirar do zero um projeto é muito mais eficaz pois você aprenderá como funcionam as linguagens de programação e ao mesmo tempo terá que ser o Product Manager para conseguir priorizar e definir o próximo passo do seu produto — além de ter que passar pelo desafio de Discovery, Solution Fit e Market fit. Inclusive o curso da PM3 ajuda bastante os alunos com estes conceitos.

Quando eu entrei no Easy Táxi (meu primeiro emprego na Grande São Paulo) eu perguntei porque haviam optado por mim, então descobri que tinha sido por causa dos meus vários projetos paralelos — alguns que deram certo e outros nem tanto. 

A verdade é que como um Product Manager o que você menos vai fazer é colocar a mão no código. Mas ter a habilidade de colocar a mão na massa vai facilitar muito a sua “fluência” na hora de comunicar com desenvolvedores e ter um senso melhor de priorização. Além disso você poderá exercitar habilidades que são essenciais para um bom Product Manager — criação de um roadmap, entender a dor do usuário e necessidade do mercado, ver o potencial de ganho do produto/funcionalidade nova, definir seu público alvo etc. 

“Aaaah, Marcell… Mas eu não sei qual ideia escolher.” 

Deixa eu tentar te ajudar!

Qual o propósito do projeto? O “porquê” da criação desse projeto é muito importante — e é uma das tarefas mais importante na concepção de um produto no qual a maioria dos PMs vai ter que fazer ao longo de sua carreira. Se você escolher o projeto errado — digamos que seja muito complicado — você provavelmente perderá motivação e o projeto ficará estagnado. O mesmo vale para um projeto que você não tenha paixão. Um projeto paralelo simples e concluído vale mais que mil projetos complicados e nunca terminados.
Algumas dicas sobre criar projeto paralelo:

1. Encontre uma dor:

Ela pode ser uma dor sua ou de amigos e conhecidos. Exemplo, no Product Camp e Product Stars existia uma grande dor para administrar as perguntas que os participantes queriam fazer para os palestrantes —  e por isso criei o OneAsk com outras duas pessoas como projeto paralelo.

2. Você não precisa fazer um projeto paralelo sozinho(a).

No caso do OneAsk somos três pessoas e um deles é desenvolvedor.

3. Você não precisa ganhar dinheiro com seu novo projeto.

E por isso o OneAsk é (pelo menos por enquanto) 100% gratuito.
4. Trate seu projeto como uma mini startup.

Crie a parte financeira, crie um racional de priorização, faça Product Discovery, tenha usuários para beta testers, tenha um sistema bacana para facilitar análises (no OneAsk usamos o Metabase)

5. Aprenda durante o processo

Tudo que você tiver aprendendo, seja mais técnico ou mais business, tente aprender com um propósito em mente.

Propósito na hora de estudar

A verdade é que o tempo gasto em cursos (seja online ou não) vai ser 10x mais valioso se você tiver em mente quais habilidades são chaves para o seu projeto avançar mais rápido. E, honestamente, nesse ponto o Curso de Product Management e o outro de Product Discovery da PM3 pode ser uma mão na roda.
Por exemplo, se você iniciou um projeto paralelo, você invariavelmente vai precisar de algumas coisas:

  • Ter um público alvo bem definido
  • Ter um problema ou oportunidade definido
  • Saber o canal de aquisição
  • Ter um nome, site e propósito que converse com sua audiência
  • Definir qual vai ser a stack técnica do seu projeto
  • Para definir isso e outras etapas críticas do seu projeto, recomendo estudar sobre o Lean Stack. Pode começar por esse vídeo.

Para definir isso e outras etapas críticas do seu projeto, recomendo estudar sobre o Lean Stack. Pode começar por esse vídeo.

Um ponto importante é que no começo você não precisa se preocupar em deixar o seu projeto super bonito e sem falhas. Lembre-se, o seu objetivo é descobrir como as coisas funcionam e quais habilidades você precisa para ser um Product Manager. Se você acabar gostando do seu projeto e quiser dar o próximo passo com ele, sempre será possível melhorar o design, a usabilidade e a aparência dele depois.
Não vai ser fácilA verdade é que você tem mais chances de falhar com seu projeto do que qualquer outra coisa — mas lembre-se, você está fazendo isso para aprender e/ou melhorar seu currículo! Confesso que eu acho um grande diferencial quando vejo Product Managers com projetos paralelos que tenham alguns usuários, e não me importo se é um sucesso ou não. Sempre gosto de ouvir as histórias para entender se a pessoa tem um bom racional de porque as coisas não deram tão certo — aprender com seus erros é uma virtude.
No curso de Product Management da PM3, além de ensinarmos muita coisa prática para um Product Manager, nós também ensinamos coisas essenciais para um projeto paralelo novo como:

  • Product Market Fit
  • Estratégia de produto
  • Product Discovery 
  • Análise de dados

Se você quer se tornar um Gerente de Produto, provavelmente você tem muitas ideias diferentes, portanto, tirar algo do papel não deve ser difícil.

Lembre-se de não escolher algo muito complicado que exija conhecimentos avançados de programação, uma quantidade excessiva de tempo, etc. Você deve escolher algo que tenha uma alta probabilidade de terminar. E a verdade é que não importa se a sua ideia já tem solução no mercado, apenas tire ela do papel e aprenda com isso. Pode ser um simples aplicativo de lista de afazeres, um bloco de notas, um chat estilo Telegram ou até mesmo um podcast — desde que você trate todos eles como um produto que exija uma visão estratégica de produto.

Sendo bem transparente, embarcar em um projeto paralelo gera uma boa quantidade de trabalho e, naturalmente, exige muito tempo. Eu costumo trabalhar quase todos os dias após o meu emprego CLT e sempre em todos os finais de semana — esse texto, por exemplo, foi escrito no domingo às 15h45. 

Apesar do esforço que esses projetos podem exigir, ter pelo menos um é uma maneira super poderosa de aprender os principais conceitos técnicos e estratégicos que qualquer PMs precisa desenvolver. Eventualmente a sua confiança em discutir bancos de dados, estratégia, e eventualmente arquitetura do software (se você for tiver a coragem de meter a mão em código), vai aumentar. Basta começar e não desistir — defina metas mensais ou trimestrais como todo bom PM — eu garanto que você não se arrependerá.

PS: Se você tiver fazendo um projeto paralelo ou 100% dedicado com sua startup me mande uma mensagem na comunidade da PM3 ou Linkedin. Vamos marcar um café ou call!

Este artigo foi originalmente publicado no Blog da PM3. Este é o link original.

Tem se tornado cada vez mais comum as pessoas me perguntarem porque eu não estou focado full-time em um (ou nos dois) side projects – PM3 e Product Camp. A verdade é que existe uma série de motivos pelo qual eu não estou e não pretendo tocar nenhum deles full-time no curto ou médio prazo. Até falei um pouco sobre isso no recém lançado episódio de podcast do Product Backstage do Alexandre Spengler.

1. Contexto

Comecei a construir produtos como hobby antes da faculdade — na época eu nem chamava de produto… Já tive site de pirataria, blog de memes, blog de opinião, blog de tecnologia, um site chamado “Aplicativo Do Dia”, Podcast e várias outras coisas que nem falo publicamente. Mas nada era muito sério e sempre rolava em paralelo com algumas outras coisas.

1.1 A primeira startup

Em meados de 2014 eu estava no Grana e o negócio só crescia — chegamos a bater +100k usuários únicos com uma retenção acima da média dos apps de finanças pessoais. Era somente eu e mais um sócio e parecia fazer muito sentido pedir demissão do Easy Táxi (onde eu trabalhava na época) para tocar a startup full-time. Afinal, se comigo part-time estava indo bem, imagina full-time, né? Ledo engano… Só piorou tudo.

Se dedicar full-time num projeto não é a receita do sucesso. Eu sei que isso pode parecer muito diferente do que a gente tá acostumado a ler nas histórias famosas. Mas a realidade, meu amigo, é bem diferente. Acho que várias pessoas podem passar ou estão passando pelos mesmos questionamentos — “devo tocar full-time agora ou não?”. Por isso resolvi compartilhar um pouco da minha experiência e como eu enxergo as vantagens de estar sendo um “Empreendedor Híbrido”.

2. Empreendedores híbridos

A indústria criou aquela imagem sexy de um empreendedor trabalhando duro, dedicando 100% do seu tempo em seu novo empreendimento, ficando até as 4 da manhã trabalhando em sua mais recente inovação.

Mas isso é a realidade do empreendedorismo? Se você tem uma ideia de um novo negócio, é realmente melhor sair do seu trabalho estável que dá um salário regular? Ou o ideal é tomar um caminho mais seguro?

De 1994 a 2008, dois pesquisadores acompanharam um grupo de possíveis empreendedores para responder exatamente a essa pergunta: quando você inicia um negócio, você tem mais sucesso se você mantiver o seu emprego fixo ou se você se dedicar full-time ao novo negócio?

(Link da pesquisa: https://sci-hub.tw/10.5465/amj.2012.0522)

Eles analisaram mais de 5.000 pessoas nos EUA que se tornaram empreendedores durante 15 anos. Os participantes do estudo tinham 20, 30, 40 e 50 anos e atuavam em diferentes indústrias. Houve uma resposta bastante clara:

aqueles que mantiveram seus empregos fixos possuem 33% menos probabilidade de falhar no seu novo negócio.

Hoje, ao ver a pesquisa e conectar os pontos das minhas experiências passadas, vejo que faz total sentido — afinal, abandonar seu emprego fixo para abrir uma empresa é como propor uma pessoa em casamento no primeiro encontro.

Abandonar seu emprego fixo para abrir uma empresa é como propor uma pessoa em casamento no primeiro encontro

  • 1905. Albert Einstein trabalhava seis dias por semana em tempo integral em um escritório examinando pedidos de patentes. Ele dedicou todas as horas que sobravam para estudar e fazer experimentos físicos. Um dia, a Teoria da Relatividade foi concebida.
  • 1964. Phil Knight passou cinco anos vendendo calçados esportivos antes de deixar seu emprego em tempo integral na área de contabilidade. A empresa que ele começou? Nike. (Por sinal recomendo demais ler o livro Shoe Dog)
  • 1976. A Apple nasceu em uma garagem, não em um escritório. Steve Jobs e Steve Wozniak, só conseguiam trabalhar no seu “projeto maluco sobre computadores pessoais” depois do expediente padrão dos seus empregos fixos..
  • 1985.O autor de best-sellers, John Grisham, era advogado e acordava todos os dias às 5 da manhã para escrever histórias antes de ir para o seu emprego. Ele fez isso durante três anos, recebeu múltiplas rejeições de editoras, e depois foi finalmente aceito e publicou seu primeiro livro.
  • 1993. Craig Newmark, empregado em uma empresa de investimentos, iniciou uma lista de e-mail no seu tempo livre para que ele e seus amigos pudessem se atualizar sobre diferentes eventos na cidade. A lista cresceu tanto que não havia espaço suficiente nas caixas de entrada das pessoas: era hora de um site. Nasceu o Craigslist.com.
  • 2009. Markus Persson era um programador que gostava de desenvolver games como side project. Ele colocou o Minecraft, ainda inacabado, em um portal de jogos. Markus manteve seu emprego durante um ano antes de se comprometer 100% do tempo com o Minecraft em tempo integral — que posteriormente vendeu para a Microsoft por US$ 2,5 bilhões.

Isso sem mencionar tantas outras empresas de sucesso que surgiram como side projects (Facebook, Product Hunt, Trello, AppSumo etc…).

2. Barbell Strategy — Os aprendizados ao mitigar riscos

Nassim Nicholas Taleb — autor do livro Antifrágil – fala que fazer all-in em alguma coisa — qualquer coisa, seja investimentos ou em projetos — torna você frágil. Com essa premissa ele incentiva os leitores a adotarem o que ele chama de “Barbell Strategy”. Barbell é um tipo de equipamento usado para levantamento de peso, basicamente é uma barra longa com dois pesos em extremidades opostas que criam estabilidade. De acordo com Taleb essa estratégia é uma forma de se proteger em algumas áreas e correr riscos em outras. Ele diz que ela oferece dois grandes benefícios:

  • É mais provável que você corra riscos maiores que podem dar um retorno enorme quando você sabe que o fracasso não vai prejudicar completamente sua vida.
  • Mesmo se você falhar, você ainda estará bem e poderá arriscar novamente quando quiser.

Depois de empreender full-time no Grana e fracassar, decidi que só iria fazer isso novamente — e se fizer — diante de uma situação completamente diferente, na qual eu não precisaria viver comendo miojo e me privar de várias outras coisas.

Porém, mesmo com o objetivo de não empreender tão cedo, é difícil ver algumas oportunidades passarem e não fazer nada. A partir daí surgiu a PM3 e o Product Camp, ambos como side project. Eu amo trabalhar com produto e impactar positivamente a empresa e milhares de pessoas através da tecnologia. Fora o benefício de ser uma profissão que paga muito bem, eu ainda tenho a chance de trabalhar com pessoas que admiro (geralmente, rs). Então por que não usar a barbell strategy e ainda aproveitar das vantagens de um bom emprego fixo?

2.1 Assertividade

Como empreendedor essa estratégia me permite ser mais seletivo no que eu quero atacar em cada side project. E. sinceramente, eu acho que isso me faz um empreendedor melhor. Eu sinto que acabo ficando mais relaxado (mas não tanto) e dou uma arriscada que em outra situação eu talvez não fizesse, porque eu sei que o fracasso é, na verdade, algo que eu posso conviver. Tem vezes que fico com vontade de me dedicar somente aos meus negócios? Com certeza! Mas eu acredito que side projects crescem em pequenas janelas de tempo que dificilmente afetam o seu dia, mas que acabam se acumulando ao longo de semanas e meses.

Por exemplo, a PM3 está cada vez maior (mês após mês) e eu, nem o Dan e Bruno (os outros fundadores da PM3), precisaram deixar o seu emprego para a empresa crescer e lançarmos coisas novas como a Biblioteca. Outro exemplo é o Product Camp, pois mesmo sendo um side project, este ano conseguimos lançar mais um evento e outros 4 workshops, além de escalar o evento para keynotes internacionais. Basta você se organizar, se dedicar e fazer acontecer. Todos nós sacrificamos algumas horas da vida pessoal ao longo da semana para resolver todas as pendências — seja para responder emails ou lançar coisas novas. E dá pra fazer isso, por exemplo, de manhã cedo antes de ir para o ‘trabalho de verdade’.

Side projects crescem em pequenas janelas de tempo que dificilmente afetam o seu dia, mas que acabam se acumulando ao longo de semanas e meses.

Todo mundo tem janelas de tempo livre no seu dia. O ‘macete’ é proteger essas janelas de tempo. Proteja de uma maneira como protege outras coisas que você prioriza. Se for necessário colocar um aviso “não perturbe” na porta do seu quarto para os seus familiares não interromperem você, faça.

Ao mesmo tempo, não coloque muita pressão em relação a prazos. Side project precisa ser divertido e não uma obrigação.

2.2 Side project não precisa de investidores e pode ser livre de pressão

Se você tem uma empresa bootstrapped e rentável como a PM3, você tem a liberdade de experimentar como e na velocidade que quiser — sem investidores pressionando e com a possibilidade de correr os riscos que quiser.

Essa é outra grande vantagem de um side project, você não precisa ser altamente focado em ter ROI e resultados financeiros para agradar o board. Porque quando se trata de side projects, algumas coisas não acontecem como foram planejadas (tanto para o bem quanto para o mal). Então é algo que você pode fazer sem expectativas e ver o que acontece.

Não tenha medo de investir tempo e esforço em algo que realmente mexe com você. Muita gente comenta comigo “nossa, mas você não cansa de fazer tanta coisa assim?” A verdade é que um bom side project não distrai ou cansa você, na verdade ele energiza você.

Isso pode vir com um certo “preço” a ser pago — algumas saídas a menos nas noitadas, menos tempo para “dates” e coisas do tipo. Mas sendo algo que me energiza e me deixa empolgado, qual o mal na verdade? É tudo uma questão de saber balancear. Ser capaz de fazer isso também tem muito a ver com o momento de vida de cada pessoa — conseguir fazer isso bem tendo filhos e sendo casado é muito mais complexo (eu imagino, já que não é meu caso) pois uma família demanda tempo e dedicação bem maior que o um side project.

E se der errado?

Na pior das hipóteses, você sacia sua curiosidade. Numa hipótese melhor, você se torna um profissional melhor e mais preparado para encarar um desafio em empresas antigas ou modernas. Numa hipótese perfeita, você encontra o trabalho da sua vida.
*Originalmente publicado no blog da PM3

Compartilhe conhecimento e ajude a subir a barra da área de produto e tecnologia no Brasil e América Latina

Quer ser palestrante do Product Camp 2019? Agora você pode compartilhar conhecimento, criar conexões e ajudar a subir a barra da área de produto e tecnologia no Brasil e América Latina.

Como funciona?

Para participar, faça a sua inscrição por meio desse formulário, defina a categoria da palestra (leaner, better, faster ou stronger), qual trilha você quer participar (Produto, Growth e UX) e o nível da palestra (básico, intermediário ou avançado) bem como uma explicação de porque sua palestra é única.

Cronograma:
  • Deadline de submissão para a Pcamp19: até 1 de setembro, às 23:59
  • Período de curadoria pelos coordenadores de trilha: 1 de setembro a 10 de setembro
  • Período de aceite dos participantes: até 7 dias (a partir do contato dos coordenadores de trilha)

Divulgação dos aprovados no site, após o término da curadoria.

Clique aqui para submeter sua palestra!  Dica: Leia os conteúdos que queremos para a edição desse ano
O Product Camp 2019 acontece nos dias 10 e 11 de dezembro no Centro de Convenções Frei Caneca em São Paulo.

Product Camp 2019 — Leaner, Better, Faster, Stronger.Ingressos a venda no site: www.ProductCamp.com.br

Este é o conceito que estamos trazendo para a Product Camp 2019.

Acreditamos que esse lema — inspirado na música do Daft Punk — diz muito sobre o universo de Product Management.E todo o conteúdo terá como norte esses 4 conceitos.

  • Leaner porque queremos fazer as coisas de maneira mais enxuta. Direto ao ponto, sem desperdícios de tempo, de dinheiro, de over-engineering ou de estudos desnecessários (mas os necessários têm que ser feitos!).

Os conteúdos “leaner” trarão hacks, MVPs e cases de “build to learn”.

  • Better porque um produto de sucesso deve, obrigatoriamente, tornar a vida das pessoas melhor. Você precisa adicionar valor! Em paralelo, todo produto precisa gerar retorno para quem o faz; ou seja, as métricas de negócio também precisam melhorar!

Conteúdos “better” serão cases de muito discovery, entendimento do problema e construção de soluções que, mesmo começando por MVPs, se tornaram cases de sucesso em entrega de valor e ROI para a organização.

  • Faster porque está cada vez mais difícil achar “oceanos azuis”, então você precisa de velocidade para ganhar mercado e conquistar o coração dos usuários.

Conteúdos “faster” serão atalhos de discovery, cost of delay / time to market e pequenos cases de fracasso (“fail fast”) que geraram aprendizado e evitaram problemas maiores.

  • Stronger porque um produto precisa de força para se sustentar no longo prazo. Não estamos correndo os 100m rasos, estamos em uma longa maratona!

Conteúdos “stronger” serão focados em profundidade, estratégia de produto e construção de negócios sólidos no longo prazo.

Em 2019, estamos assumindo a missão de subir a barra da gestão de produtos no Brasil.
Sabemos que nossa audiência é exigente e bastante crítica.
Sabemos que você quer ver novidade nos palcos e stands.
Por isso, subir barra é algo que também depende de você!
É a sua empresa que vamos buscar para patrocinar o evento.
Pode ser você um palestrante, painelista ou mediador selecionado.
E as perguntas que faremos ao final de cada talk poderão partir de você também.
Por isso, queremos convidar você a participar dessa missão.
Vamos fazer Produtos de maneira mais enxuta, melhor, mais rápido e mais robusta!
Product Camp 2019 — Leaner, Better, Faster, Stronger.
Ingressos a venda no site: www.ProductCamp.com.br

*Agradecimentos especiais ao Raphael Farinazzo na criação do conceito.

Originalmente publicado no blog da Cursos PM3

No decorrer dos últimos anos dei uma série de palestras enquanto estudava sobre vários assuntos de produto, como Visão de Produto, As verdades sobre ser Data-Driven, contei cases meus de Teste A/B, aprofundei no polêmico tema “Roadmap” e alguns outros tópicos. Mas um dos assuntos que mais gosto é estratégia de produto (ou Product Strategy para os mais chegados).

Como o alcance de qualquer palestra é limitado, resolvi fazer um artigo condensado alguns aspectos sobre Product Strategy. Porém, assim como a maioria dos artigos que tenho escrito ultimamente, este acabou ficando bem longo também. Então esteja bem acomodado ou vá lendo aos poucos.

Gerenciando um produto

Diferente do que muita gente pensa, gerenciar um produto não é tão simples quanto parece. Você precisa organizar os processos, motivar e influenciar as pessoas certas para fazer com que o produto seja um sucesso.Mas como evitar que um produto vire um Frankestein com tanta demanda de diferentes áreas? Bom, pra começar você precisa ter duas coisas: i) Uma visão para o seu produto e; ii) Gerenciar ele baseado nessa visão.

OBS: Eu escrevi sobre isso em meados de 2016 e você pode ler aqui. É importante para o entendimento desse artigo e não acho que vale a pena estender o assunto aqui já que essa parte do conteúdo está disponível em outro local.

1. Lidere com o problema e não com a solução

Esse é o cerne de todos os problemas de estratégia de produto. Peguei o conceito da Pirâmide do Product-Market Fit do Dan Olsen para ilustrar melhor esse erro clássico.

O foco do time de produto deveria ser na proposta de valor e nas necessidades não atendidas, conforme a imagem abaixo — é justamente onde você encontra o Product-Market Fit e possíveis alavancas para melhorar seu produto. Por isso é tão importante executar bem a fase de Discovery (mais detalhes sobre discovery em artigos futuros).

1.0.1 Ilustrando com Jobs to be done

O problema é que naturalmente nós pensamos nas soluções antes de entender o problema e por isso muitos times de produto (normalmente os ruins) focam em UX e conjunto de features. Tenho certeza que você já leu isso em vários lugares diferentes então vou poupar explicações e ir direto para exemplos práticos.

Jobs to be Done é uma boa forma de ilustrar como focar em problemas e não em soluções. Veja o caso abaixo, o consumidor simplesmente quer conselhos que ele possa confirar, ter uma direção certa do que fazer, se sentir motivado e inspirado etc. A forma que você alcance esses objetivos pouco importam — e essa forma são geralmente as soluções.

1.1 Exemplo Zendesk

O Zendesk foi lançado em 2007 mas levou 6 anos de muitos experimentos e investimentos para que eles lançassem o Help Center, o qual é uma extensão natural do serviço de tickets deles. Posteriormente eles cresceram tanto que criaram o Zendesk Suite que é composto por uma série de produtos que resolvem problemas distintios.Qual o aprendizado que podemos ter com o Zendesk aqui? Eles só expandiram o produto quando acharam que tinham resolvido o primeiro problema.Referência: https://www.zendesk.com/company/press/zendesk-announces-60-million-financing/

1.2 Exemplo Easy Taxi Empresas

Apesar de ser um produto que está prestes a acabar (Cabify adquiriu o Easy Taxi e o branding do Cabify deve ser mantido enquanto o do Easy desaparece) durante o período que trabalhei no Easy Taxi deu para ver um bom trabalho sendo executado. Quando lançamos o Easy Taxi Corporate ele era uma extensão natural do aplicativo de pedir corridas de Taxi porém focado para as empresas e com o objetivo de facilitar o reembolso e gastos por centro de custo. A versão para empresas só foi lançada depois de alguns anos e durante um bom período foi um dos produtos mais lucrativos da empresa.

A mesma lição que tivemos com o Zendesk podemos ter com o Easy Taxi — apenas expandir o seu produto quando você resolver muito bem um problema.

2. O que fazer depois de encontrar market-fit?

Só quando seu produto solucionar muito bem um problema você pode se preocupar em expandi-loImagine uma tesourinha de cortar unha. É muito fácil de explicar o que ela faz e, por consequência, é fácil de vender. Quer cortar unha? Compre uma tesourinha! Ela é fácil de manusear porque ela faz uma coisa com excelência — sem mencionar o fato de que ela é rápida para ser criada e testada.

Agora coloque um canivete suiço do lado de uma tesourinha de cortar unha. O que o canivete suiço faz bem? Você já cortou a unha com algum? Aposto que não… No mundo real a gente não costuma utilizar ferramentas que fazem de tudo. Se o seu amigo precisa de ajuda para colocar alguns parafusos com certeza não vai ser com um canivete que você vai apertar os parafusos. É muito legal e bonito falar que você tem um (assim como as empresas costumam fazer com o seu produto cheio de funcionalidades). Mas no mundo real, é dificil explicar para que ele serve, até porque ele não faz nada bem — o que prejudica a adesão do produto.

Existe um grande pesquisador da teoria dos sistemas chamado John Gall que concluiu que um sistema complexo que funciona bem evoluiu de um sistema simples que funcionava bem. De acordo com a Lei de Gall, um sistema complexo não pode ser projetado a partir do zero, caso contrário ele não vai funcionar bem e não vai poder ser consertado. É necessário que ele surja a partir de sistemas simples. Gall disse isso em 1975 e até hoje é válido. Encaixa em todos os conceitos de lean startup, ágil etc.

“Um sistema complexo que funciona é invariavelmente a evolução de um sistema simples que funciona. Um sistema complexo projetado a partir do zero nunca funciona e não pode ser consertado. Você tem que começar partindo de um sistema simples”Lei de Gall

2.1 Regra de bolso: O que pensar antes de criar novas funcionalidades?

  1. Está dentro da sua visão? Ela vai manter ou tirar você do caminho da visão?
  2. Vai fazer sentido em 5 anos? Ela não vai se tornar obsoleta em 5 anos?
  3. Ela beneficia todos os usuários? Se não todos, pelo menos a maioria? (Você precisa evitar fazer funcionalidades que beneficiem poucos clientes)
  4. Qual o objetivo? Melhorar alguma coisa que não está bem feita? Aumenta o uso do produto?
  5. E se a funcionalidade for um sucesso e todo mundo tiver usando, vai ser possível dar suporte para ela?

Confesso que na correria do dia a dia nem sempre consigo seguir essas regras de bolso mas me esforço ao máximo. Antes de pensar em avançar na criação de alguma funcionalidade me questiono com as perguntas acima. Isso tem me ajudado muito em todos os projetos que participo e dessa maneira quase nunca fugimos da visão/direcionamento estratégico.

2.2 O problema que ninguém vê em produtos com muitas funcionalidades

Existe uma diferença entre fazer um produto simples, e fazer o produto ser simples.

Se você fez um bom trabalho, você vai entregar o MVP do seu produto em algumas semanas. E como ele é bem enxuto você vai perceber que a maioria das pessoas está usando tudo. O que importa é que elas estão realmente fazendo o que você quer que elas façam.

No exemplo da imagem imagine que você criou um MVP de um app de finanças pessoais. Neste caso todas as funcionalidades estão sendo utilizadas quase que igualmente. Mas o seu produto vai evoluindo e evoluindo… Então em algumas semanas você simplesmente cria outras funcionalidades.

Você lança mais funcionalidades achando que todas elas vão continuar sendo usadas bastante. Mas mesmo que você erre, vocês devem estar imaginando que o pior cenário é o ao lado “Ah, se der ruim as pessoas não vão utilizar as funcionalidades novas mas as antigas vão continuar com uso alto”

Você lança mais funcionalidades achando que todas elas vão continuar sendo usadas bastante. Mas mesmo que você erre, vocês devem estar imaginando que o pior cenário é o ao lado “Ah, se der ruim as pessoas não vão utilizar as funcionalidades novas mas as antigas vão continuar com uso alto”

Quando na verdade o pior que pode acontecer é cair o uso de quase todas as suas funcionalidaes — impactando o produto de maneira geral. Afinal ele ficou mais complexo.

Agora imagine um cenário mais ou menos como o da imagem ao lado. Isso significa que você tem um produto incrivelmente bom nessas duas áreas. Mas que você adicionou um bocado de porcaria junto. Imagine se chega algum competidor e pensa “Opa. A melhor parte na verdade é só essa. Então vou criar um produto que só é bom nisso e acabar e ganhar o mercado”. Nessa hora que um novo player domina o mercado.

Evite criar funcionalidades que não são necessárias. E se por acaso você errar (quem nunca desenvolveu algo que não devia?) tenha coragem para matar a funcionalidade e lide com os stakeholders e aqueles poucos usuários chateados.

2.2.1 Você precisa ser bom no que importaExemplo 1: Google+ e Hangouts

O Google também seguiu a mesma linha com Hangouts. Ele surgiu dentro do Google+ e rapidamente o Google viu que o Hangout gerava muito mais engajamento que o Google+ e desmembrou eles (sábia decisão).

Também temos o Facebook como grande exemplo disso. Lembram quando era tudo junto? O aplicativo de mensagens junto com a rede social? Eles primeiro separaram o aplicativo e em seguida separaram no site também. Agora você pode acessar exclusivamente o Messenger do Facebook — mesmo sem ter um perfil no Facebook.

2.2.2 Não adianta ser bom no que importa se você pode ser facilmente copiado

Sou extremamente cético em relação ao futuro do Dropbox e muito curioso em ver pessoas inteligentes apostando nele como uma empresa que vai ser duradoura. O Dropbox é um ótimo serviço de sincronização de arquivos e já fizeram uma baita grana inovando no segmento — mas tenho a impressão muita gente ficou cega pela emoção do Dropbox ser um utilitário bem elaborado e esqueceram de olhar por outra perspectiva. Na prática o Dropbox é facilmente copiável e rapidamente se tornou praxe sistemas operacionais terem um sistema de cloud nativo — prejudicando o market share do Dropbox.

Apesar de muita gente ainda acreditar neles já dá pra ver uma resposta do mercado onde eles não enxergam um futuro próspero para o Dropbox — a não ser que algumas medidas drásticas sejam feitas. Veja o valor da ação abaixo:

Em 2018, as receitas do Dropbox aumentaram 26% em relação ao ano anterior, chegando a US$ 1.4 bilhão. Apesar de ser um bom crescimento, está abaixo de 31% e 40% que foram as taxas de crescimento de 2017 e 2016, respectivamente. Provavelmente isso está relacionado ao fato de estar muito mais fácil ter Cloud Storage — hoje temos o Google syncando tudo (Google Photos, Drive, etc), a Apple fortíssima como iCloud e até a Microsoft com o One Drive.

Querendo ou não quem está numa posição competitiva vantajosa são as empresas que são donas de sistemas operacionais: Apple, Microsoft ou Google. Cada uma dessas empresas tem uma solução similar ao Dropbox que já integra ao sistema e, sem esforço algum, o usuário tem seus arquivos salvos na nuvem.

O Dropbox obviamente está trabalhando para deixar de ser apenas uma “funcionalidade” e se posicionar diferente perante outras alternativas. Por isso não adianta você ser incrível em alguma coisa se pode ser facilmente copiável. Em 2009, Steve Jobs queria pagar mais de US$ 100 milhões pelo Dropbox, mas o CEO Drew Houston recusou a oferta e logo em seguida (talvez num ato de raiva) Jobs disse que o Dropbox era uma funcionalidade e não um produto. Ao meu ver ele estava certo. 10 anos depois dá pra ver que as empresas que possuem sistemas operacionais tem uma grande vantagem e não precisam do Dropbox.

Na verdade, até hoje, o Dropbox frequentemente tem problemas em sincronizar alguns arquivos. Vou usar como exemplo o Office, se você esquecer de fechar ou salvar o arquivo do Word no seu computador, ele não estará sincronizado no seu Dropbox. Isso não é culpa do Dropbox — é o Office que bloqueia esse tipo de ação. Mas isso destaca o que estou falando: o Dropbox só tem controle sobre uma pequena parte dos sistemas operacionais.

Tentando se diferenciar

O Dropbox já adquiriu pelo menos 10 empresas e a mais recente foi a HelloSign. Essa aquisição elimina a necessidade de integrar com outros serviços de assinatura (Docusign, Adobe Sign etc) e faz com que os usuários continuem dentro do ecossistema do Dropbox. Ter uma assinatura eletrônica nativa pode tornar a plataforma mais atraente para as empresas e ao meu ver esse movimento tem como objetivo principal entrar mais forte no mercado enterprise já que o B2C está saturado com o Google, Apple e Microsoft — isso inclusive faz com que a empresa ataque mais fortemente o seu outro concorrente Box.

2.3 Celebre o uso e não a entrega

Manifesto agil fala da entrega. Só que mais importante que isso é o uso. Inclusive é algo que o manifesto agil deveria evoluir e na minha visão está desatualizado.Outra opção seria criar um manifesto de produto, afinal na época da criação do Manifesto Ágil o mundo pensava muito em entregar valor para os clientes e não entender o problema em si. De qualquer maneira isso é um bom assunto para outro artigo.

  • Mas ressalto estes 3 pontos:
  • Entregar algo não é nada.
  • Taxa de uso é TUDO.
  • Faça mais pessoas usarem uma funcionalidade ou faça elas usarem mais do que o normal.

Recapitulando antes de irmos pra última parte do artigo:

Pra gerenciar bem o escopo de um produto, é necessário sempre medir as funcionalidades que estão sendo usadas. Entender que mais funcionalidades não vão necessariamente te dar mais usuários. E o ideal é primeiro resolver um ou dois problemas muito bem antes de pensar em evoluir o produto, afinal, você minimiza suas chances de erro começando por sistema simples ao invés de começar desenvolvendo um sistema complexo. E, por últitmo, considere sempre deixar os seus produtos desacoplados caso você detecte que eles possam ter propósitos diferentes porém com uma integração de sistemas útil para a maioria dos usuários.

3. Erros comuns de estratégia de produto

3.1 Querer se provar

Empresas, principalmente startups, cometem um erro de querer “se provar” com mais funcionalidades — como se isso fosse um diferencial hoje em dia. Você prefere o Excel ou o Google Sheets? É óbvio que o Excel tem mais funcionalidades, em especial as avançadas, mas o Sheets engoliu uma bela fatia do mercado com a simplicidade e focando em necessidades mais abrangentes como, por exemplo, edição de múltiplas pessoas em tempo real — algo que a Microsoft teve que copiar anos depois, com o Office 365.

3.2 Intuição levando ao erro

Muitas vezes a gente se pega pensando “Agora com essa nova funcionalidade os downloads vão aumentar!” ou algo como “Agora com essa funcionalidade vamos ter 1000 clientes novos pagando”. Embora isso possa acontecer, as chances de você estar enganado são enormes. Não se iluda! Nessa hora é importante lembrar da visão e seguir com ela independente das funcionalidades.

3.3 Falha na hora de gerenciar o portfólio de produtos (apenas para times maiores)

Uma das coisas mais difícieis em gerenciar um portfólio de vários produtos é fazer uma boa priorização de iniciativas. As empresas disfuncionais tendem a considerar todas as iniciativas como alta prioridade e isso, obviamente, torna tudo muito complicado.

Pela minha experiência os 4 maiores erros na gestão de um portfólio são os abaixo (em ordem):

  1. Projetos demais para a capacidade da empresa. Geralmente é um problema de alocação de pessoas. Empresas disfuncionais tendem a priorizar mais do que são capazes de entregar
  2. Decisões que vão e voltam e são tomadas em cima da hora, tornando tudo ineficiente
  3. Não ser capaz de inovar rápido o suficiente e perder o time to market. Normalmente a empresa possui uma série de disfunções, ou time incapacitado, e a inovação/velocidade não acontece. Uma solução que algumas empresas adotaram é criar uma unidade de negócio separada para dar velocidade e autonomia para algumas equipes.
  4. Sem forma consistente ou transparente de medir o sucesso dos produtos — a não ser por receita, o que coloca a empresa e a equipe de produtos numa situação ruim, na qual o foco é dinheiro e não resolver problemas com bons produtos (algo que leva tempo mas o resultado é muito superior)

Esses erros acima geram grandes disfunções nas empresas. i) Perda e tempo e/ou dinheiro; ii) Oportunidades de aumento de receita são perdidas; iii) A empresa começa a perder a sua vantagem competitiva; iv) Demorar muito para matar produtos e deixar um legado enorme de ‘produtos zombie’ que dão uma certa renda extra mas no fundo tiram o foco de uma série de profissionais que poderiam estar atacando produtos com um potencial maior;

3.3.1 O que se perguntar para endereçar esses problemas
  • Utilizar o que já tem: Que tecnologias e ativos (assets) temos atualmente que podemos utilizar para alavancar o nosso negócio atual ao invés de investir em criar algo do zero?
  • Tentar detectar a necessidade de novas habilidades e recursos: temos as pessoas certas e com as habilidades certas? E os nossos ativos atuais dão apoio aos novos investimentos para inovação?
  • Condições do mercado em constante mudança e novos concorrentes: Como podemos garantir que podemos agir com rapidez e ter uma vantagem competitiva?
  • As equipes de produto e engenharia agora precisam focar em muitas variáveis como tecnologias, serviços, localização, apps, mensagens e outros itens essenciais — geralmente ao mesmo tempo. Como podemos garantir que estamos conectando todas as equipes e mapeando as dependências para garantir que cada lançamento seja bem-sucedido?

Além de se fazer as perguntas acima e tentar responder elas de uma maneira completa e sem correria, o ideal é fazer os 4 passos abaixo também:

  1. Tomar decisões mais baseadas em dados do portfolio (e não necessariamente apenas números financeiros)
  2. Consistentemente seguir o processo de portfólio (obviamente para ter um processo você precisa criar um primeiro);
  3. Realocar pessoas e dinheiro para inovações de maior oportunidade — não necessariamente o que tem o maior valor no presente;
  4. Aumentar o foco (investimento de tempo) no gerenciamento de porftólio ao invés de reuniões demoradas e análises puramente financeiras.

Espero que esses insights possam ajudar qualquer profissional (seja agora, em 2019, seja no futuro) a resolver os problemas de estratégia de produto na sua empresa. Não acho que exista uma resposta correta para isso e sim vários métodos diferentes. Meu objetivo aqui era apenas compartilhar o que aprendi até hoje com as experiências que tive.

Se você que chegou até o fim do artigo tiver outros insights de como melhorar a estratégia de produto dentro das empresas, por favor, deixe um comentário e vamos discutir para crescer juntos. Só assim vamos ser capazes de inovar mais e aumentar a receita ao mesmo tempo.

Originalmente publicado no blog da Cursos PM3

Dicas e lições aprendidas de como ir do Output driven ao Outcome driven

Durante toda minha carreira como Gerente de Produto fui evoluindo cada vez mais para o lado de entregar resultados ao invés de simplesmente entregar funcionalidades. Quem mais me ensinou isso foi o Thomas Floracks, VP de Produto e Fundador do VivaReal, que sempre fez as perguntas certas para me fazer refletir “Nós queremos ser output driven ou outcome driven?”. Conforme fui mudando a forma de pensar para focar em resultados (outcome) fui percebendo que é um trabalho muito mais difícil porque você precisa pensar muito mais no cliente e se aprofundar nos problemas deles.

Recentemente fui ao Lean Startup Conference de 2017 e participei de um Workshop com Bruce McCarthy, um dos autores do livro Product Roadmaps Relaunched. O Workshop abriu ainda mais a minha mente sobre como criar roadmaps focados em resultados ao invés de meras funcionalidades.

No final do Workshop algumas pessoas ganharam o livro e eu fui um dos sortudos. Desde então esse livro virou uma grande referência para mim — super recomendo a leitura. Porém tem um trecho que discordo e é justamente quando ele fala como transformar soluções (output) em resultados (outcomes).

Vou usar o livro como base para explicar como você pode criar iniciativas, hipóteses ou experimentos mais voltados para resultados do que soluções e aproveitar para apontar uma pequena mudança no que foi proposto pelos autores do livro.

No exemplo do livro está dessa forma:

O problema é que eu não acredito que a descrição de outcomes devessem ser tão fracas assim. Acredito que eles precisam ter um racional mais bem explicado. No livro os autores usam a terminologia “Themes” para criar hipóteses. Para chegar onde eu quero primeiro vou explicar antes um simples conceito de Hipóteses Fracas vs Hipóteses Fortes

Existem dois tipos de hipóteses

Hipotese fraca

Se o funil de compra tiver menos páginas, vamos aumentar a conversão de compra da loja

Hipótese forte

Se a navegação for removida das páginas de checkout, a taxa de conversão em cada passo vai aumentar porque o analytics do site mostra que uma porção desses usuários está deixando a página antes de clicar no link de navegação dessas páginas
Você percebe a diferença?

Criando hipóteses

“Se [variável], então [resultado], porque [racional].”

Variável

  • O elemento que vai ser modificado
  • Isole essa variável para testar sua hipótese (pode ser através de A/B test ou prototipagem)
  • Pense no Call to action, visual ou formulário

Resultado

  • Preveja o resultado
  • Use dados para determinar o efeito dele
  • Mais e-mails? Mais signups? Mais CTA? Mais conversão? Mais CTR?

Racional

  • Demonstre o quanto você conhece os seus usuários
  • O que vai estar provado ser incorreto caso o experimento seja igual ou inferior ao atual?

Exemplo de como formular hipóteses

“Se as imagens chamarem mais atenção, então a taxa de clique vai aumentar, porque sabemos que as imagens são um dos fatores mais importantes para quem busca um imóvel.”

Acima é um exemplo real de pesquisas que fizemos no VivaReal quando eu ainda era Product Manager lá. Você consegue notar a diferença entre uma hipótese fraca com racional quase nulo versus uma hipótese forte com um racional que faz sentido e possui evidências?

Um bom Gerente de Produto precisa gostar de ser questionado e desafiado. Quando você apresenta uma hipótese mais forte, com um estudo e evidências por trás, você está se abrindo mais para tomar porradas com questionamentos do que simplesmente feedbacks como “ah, eu não concordo”. Dessa maneira você basicamente enriquece todo o processo de definição dos próximos passos do seu produto.

A minha alteração para a tabela que foi proposta no livro é a seguinte:

Parece uma mudança pequena mas não é. Gerentes de Produto são canalizadores de boa parte da comunicação dentro de uma empresa e as vezes até mesmo para fora. Pequenas melhorias na comunicação podem ter um efeito enorme no alinhamento e buy-in.

Acredito muito que a melhor forma de identificar se um gerente de produto é bem-sucedido é o feedback que você ouve das outras áreas e engenheiros que trabalham com ele. Eles entendem como e porque o PM está tomando certas decisões? Ele é flexível o suficiente para lidar com o roadmap e fazer todo mundo estar na alinhado em relação ao que foi decidido?

Independente se você trabalha em B2B ou B2C você precisa conseguir se comunicar bem. Explicar o porquê de você estar tomando determinadas decisões, seja no seu roadmap ou durante reuniões, é o que vai fazer a diferença. Comunicação é chave.

Não tem problema ter funcionalidades no seu roadmapÀs vezes vai ser necessário incluir soluções no seu roadmap ao invés de apenas outcomes guiados pelas necessidades do usuário. Por exemplo, supondo que você esteja implementando um novo sistema de busca, pode ser que o time já tenha decidido usar o Elasticsearch e portanto no seu roadmap você poderia colocar, sem problema algum, algo como “Elasticsearch: Prova de conceito”. Vamos supor outro exemplo no qual seria criar um sistema de pagamento para o seu produto. Nesse caso você também poderia ser mais especifico escrevendo algo como ” Billing: Integrar com Pagar.me”

Desde que exista uma justificativa explicando por que você está definindo uma solução está tudo bem colocar elas no roadmap. Não precisa forçar a barra para sempre criar outcomes.

1 — E você? Tem feito um planejamento guiado por resultados e evidências ao invés de apenas funcionalidades? Se precisar de ajuda ou simplesmente quiser trocar ideia sobre isso é só me procurar no Linkedin ou Twitter.
2 — Quer se aprofundar nesse assunto? Eu falo sobre isso, roadmap e priorização no melhor curso de Product Manager online, o Cursos PM3.

Confesso ter ficado extremamente feliz com o sucesso que foi a segunda edição do Product Camp! Quando realizei a primeira edição em 2016 era simplesmente porque sentia falta de discutir mais com outros Product Managers. Em 2016 foi possível reunir aproxidamente 180 Gerentes de Produto do Brasil inteiro e já nessa segunda edição de 2017 foi possível reunir 330 presencialmente e 400 através de um live streaming de altíssima qualidade que e a VOCS proporcionou. Também conseguimos subir a barra do evento por causa da ajuda de outros grandes patrocinadores como a Loggi, 99, Funeel e Nubank.

O evento foi 100% gratuito e feito para toda a comunidade de produto. Infelizmente como existe uma limitação física do espaço do evento, tivemos que selecionar os convidados e foi uma tarefa muito difícil escolher convidados de uma lista de 1500 interessados. Mas quem não conseguiu ir podia assistir ao streaming de forma convencional ou em realidade virtual com experiência imersiva em 360º.

O objetivo do Product Camp Brasil é ser um fórum de discussão sobre temas relacionados a produto e por isso o evento abordou diversos temas como roadmap, growth, priorização, A/B tests etc. Tivemos palestrantes de empresas de tecnologia renomadas como Nubank, OLX, QuintoAndar, VivaReal, Loggi e até mesmo de empresas internacionais como a Transferwise. Esse tipo de fórum de discussão também acontece recorrentemente em menor em escala na cidade de São Paulo no SP Product Meetup.

Abaixo um resumão do evento! E quem quiser mandar mais feedbacks é só procurar por mim, Renato Angrisani ou Pedro Axelrud que também fizeram parte da organização.

Onde aconteceu?
Notas para os dias do evento

Participantes votaram 112 vezes em 2 enquetes. O primeiro dia, que foi bem mais lotado, teve 72 votos. Já no segundo dia, com cerca de 220 pessoas no local, 40 pessoas votaram. Também recebemos bastante feedbacks por escrito e eles vão ajudar muito a subir ainda mais a barra do ano que vem!

Streaming

2.320 pessoas se inscreveram para para assistir ao vivo. Nos vídeos ao vivo tivemos +3000 visualizações e pico simultâneos de +400 pessoas.

Como assistirPara assistir ao evento completo basta acessar o nosso canal no Youtube. São dois vídeos separados por dia.

Live VR

O live VR também está disponível para todos que possuam Google Cardboard e Oculus Rift. Para assistir a transmissão ao vivo em realidade virtual acesse esse link para o primeiro e/ou esse link para o segundo dia.

Slides dos palestrantes

Todos os slides estão disponíveis aqui http://bit.ly/slidespcamp

A importância de eventos como esse

No fim das contas, mesmo com palestras que agradem mais que outras — dependendo do gosto de cada pessoa — o que mais vale é fazer com que as pessoas continuem dispostas a trocar conhecimentos mesmo que de maneira “underground” — principalmente se for aquilo que a gente não diz em palestra porque pegaria mal. Para a comunidade evoluir cada vez mais é importante que os PMs se aproximem, se conheçam e mantenham o contato mesmo que por Whatsapp ou Telegram etc.

Não conseguiu ir nessa edição?

Então se inscreva na newsletter acessando o http://productcamp.com.br/ para não perder o próximo. Seja feliz como os participantes abaixo!

Dados não passam de uma perspectiva e eles podem atrapalhar a inovação

Tenho visto em vários artigos, eventos, livros e vários outros cantos sobre ser “Data-Driven”. É a moda do momento! Coitado de quem falar que tomou uma decisão sem ser data-driven… Agora todo mundo tem que tomar decisões assim.

“Você pode inovar ou você pode prever e medir o desempenho, mas não os dois. Qual vai ser, Mr. Businessman?” — Alan Cooper

Ninguém pode dizer que os dados não são úteis ou que eles não podem ter um impacto positivo em muitas decisões. Mas o conceito central da inovação é justamente sobre criar algo novo, e Alan Cooper, Engenheiro de Software, ilustra isso muito bem: “Você pode inovar ou você pode prever e medir o desempenho, mas não os dois. Qual vai ser, Mr. Businessman?”¹.
Você não deve se basear completamente em dados para tomar decisões

Criar produtos é uma combinação de arte e ciência. Por isso você não deve se basear completamente em dados para tomar decisões

Para tomar uma boa decisão, você analisa todas as perspectivas que são importantes para você e pesa elas de acordo com o seu julgamento para decidir. Criar produtos é se tornar um mestre em fazer isso! Você toma decisões diariamente. É uma combinação de arte e ciência. Por isso você não deve se basear completamente em dados para tomar decisões

Eu já cansei de ouvir várias pessoas dizendo que todas as decisões deveriam sempre ter o apoio de dados. O que elas não entendem é que os dados não passam de uma perspectiva. Ou seja, o que o Marketing está pedindo é só mais um ponto de vista, o que a maioria dos usuários pedem não é necessariamente o melhor, e o que você quer fazer como PM/Founder é só mais uma perspectiva.

Citando alguns exemplos:

Exemplo positivo: Se Apple fosse uma empresa totalmente orientada a dados eles com certeza teriam tentado dominar o mercado de PC. Esse vídeo mostra que isso nunca foi o objetivo da empresa.

Exemplo negativo: Se a Gol Linhas Aéreas fosse orientada ao consumidor, eles certamente iriam oferecer lanches melhores durante o vôo. Mas ao invés disso eles reduziram os lanches e, pior ainda, durante um período acabaram completamente com o lanche gratuito.

Se o seu objetivo é criar um produto que você se orgulha e que recomendaria para sua família e amigos, significa que muitas vezes você tem que ignorar os dados. Sim, ignorar os dados!

É claro que eu uso — e todo mundo deveria usar quando necessário — dados para tomar decisões. Mas também deveríamos confiar muito nos ciclos de feedback, nas pesquisas, nos testes, na empatia humana e, principalmente, na nossa intuição.

Eu seria um PM irresponsável se apenas tomasse decisões baseadas em dados quando eu tenho milhares de pessoas contando comigo para criar um bom produto. As vezes é necessário dizer um “Foda-se” para os dados em determinadas situações.

O viés que existe em todos os dados

Um grande problema é que muitas pessoas enxergam os dados quantitativos como mais confiáveis que os dados qualitativos. Mas, na verdade, qualquer tipo de dado (qualitativo ou quantitativo), seja ele apresentado numa forma que descreva o comportamento ou numericamente através de um grande data set, são criados através de viés e julgamento próprio.

Digo isso porque todos os dados são criados por algum ser humano. Esse ser humano, em algum momento, decidiu que tipos de dados usar, como organizá-los, como apresentar e como chegar numa conclusão. Existe um viés nesse processo todo — seja ele proposital ou não. Nós escolhemos os dados que nos convém e isso é um fato inegável².

Nós escolhemos os dados que nos convém e isso é um fato inegável

Dentro de qualquer empresa é comum ter várias áreas com pontos de vista diferentes — e isso só piora conforme a empresa fica maior. A partir disso são geradas uma série de demandas e o responsável pelo produto precisa gerenciar todas elas enquanto toma a difícil decisão de escolher qual atacar primeiro³.

O problema é quando as outras áreas da empresa possuem uma análise muito clara sobre o que precisa ser feito e uma série de dados apontam a favor dessas análises. Isso gera um desalinhamento e ninguém percebe que por trás de cada uma dessas análises existem incentivos por trás, dentre eles: responsabilidades funcionais, métricas de performance, incentivos financeiros e etc — ou seja, mais viés.

Antes mesmo de passar horas ou talvez dias analisando algum tipo de dado, você devia gastar a mesma quantidade de tempo, e talvez até mais, decidindo qual é o melhor tipo de dado e como organizá-lo — independente se você é de marketing, TI, comercial ou outra área. Quando é que nós devíamos acreditar nos dados e quando é que nós devíamos simplesmente ignorá-los porque é a decisão mais sensata?

Pode ter ficado fácil mensurar, mas e a parte não mensurável?

A maioria dos gerentes se preocupam apenas com os números ao invés de se preocuparem em resolver o problema

Empresas, quando bem estabelecidas, gerenciam os números. Conforme você vai crescendo mais métricas vão surgindo e mensurar uma série de coisas fica cada vez mais fácil. Como essas métricas são fáceis de serem comunicadas para o restante da empresa, é mais do que natural que elas sejam utilizadas para medir sucesso e, inclusive, performance de toda a hierarquia empresarial — isso acontece a partir dos desdobramentos das métricas e criação das metas. Dessa forma a maioria dos gerentes se preocupam apenas com os números ao invés de se preocuparem em resolver o problema⁴.

Mas não são só produtos que sofrem desse mal. um ótimo exemplo é o sistema de saúde do mundo inteiro. No nosso sistema de saúde os médicos geralmente tratam sintomas ao invés de encontrarem a raiz do problema. O sistema basicamente só funciona quando nós ficamos doentes, afinal as “métricas” que os médicos olham ficam malucas e eles conseguem saber se tem algo errado — e então trabalham para que essas métricas se estabilizem dentro dos padrões novamente. Isso é a mesma coisa que muitas empresas fazem, elas respondem só quando os dados mudam, se tornando reativas. Elas não atuam em cima dos dados qualitativos que são, na maioria dos casos, o maior insight que você tem para resolver o problema do cliente⁵.

É essencial ter estômago enquanto acontece a UX CurveQual é a pior coisa que pode acontecer se você olhar só para números de adoção ao lançar alguma coisa nova? Jogar no lixo um MVP altamente promissor.

As pessoas podem se tornar muito eficientes em usar um design ruim

Em toda grande mudança de comportamento é preciso lembrar que as pessoas podem se tornar muito eficientes em usar um design ruim. Então toda a vez que você mudar o comportamento do seu produto, mesmo sendo para melhor, essa mudança pode ser muito frustrante quando quebra um conjunto de hábitos — dai a importância da UX Curve.

Até então muitos estudos de UX se concentraram principalmente em entender a adoção inicial de alguns produtos e features através de protótipos ou até mesmo de MVPs. A ideia desses estudos é entender o comportamento do usuário para que seja compreendida a adoção inicial de novos produtos e funcionalidades.

O problema é que isso é uma análise de muito curto prazo dado que a relação entre o usuário e o produto acaba evoluindo ao longo do tempo⁶. É um erro encarar a primeira impressão como regra — afinal o uso prolongado de um produto faz toda a diferença.

Deveríamos ficar tão desesperados quando inovamos com o nosso produto e algumas métricas acabam caindo?

Então, se existe uma curva de aprendizado, deveríamos ficar tão desesperados quando inovamos com o nosso produto e algumas métricas acabam caindo? Não! Se você realmente acredita na nova funcionalidade você precisa ter estômago e aguentar até a curva amenizar. Enquanto isso você também pode ir iterando e otimizar o seu produto.Decisões NOT-data-driven

Ser data-driven é tentar compreender e quantificar o impacto das mudanças feitas no produto, significa que você precisa realmente se preocupar em compreender os números de cada iteração. O problema é acreditar que as decisões NOT-data-driven são inúteis.

Existe uma crença de que os dados podem, em conjunto, dar insights sobre os clientes. Teoricamente (sim, teoricamente!), para conseguir ter esses insights basta descobrir quais são os dados certos que precisam ser analisados, colocar numa planilha e pronto!

Mas, por outro lado, dados qualitativos não podem ser encaixados numa planilha de uma forma tão fácil como dados quantitativos. Principalmente porque não existe uma “verdade única” como os dados costumam apontar. Eu até entendo que é simplesmente mais fácil crer em dados quantitativos, mas olhar apenas para eles é um grande erro.

Tenho certeza que qualquer pessoa que esteja lendo esse artigo pode compreender a dor de um usuário quando um produto que ele usa muda. Os primeiros minutos geralmente são estranhos. Basicamente temos que nos adaptar e isso é inegavelmente frustrante. Por isso é muito natural ter que alterar o baseline dos produtos após algumas mudanças de comportamento.

Empresas maiores costumam tomar muito cuidado com os detalhes justamente por isso. Quanto maior a escala do seu produto mais lento você fica para esse tipo de tomada de decisão. E é por isso que produtos como o Booking.com e OLX não mudaram quase nada na última década. Já quando você compara com o Netflix dá para ver claramente a diferença entre inovação e gerenciar métricas⁷.

Data-driven para startups

Se você está entrando em um mercado bem definido, tentando criar disrupção, então você deve saber que o sucesso da sua empresa não será medido pela mesma métrica utilizada pelos grandes players. E, por isso, muitas vezes fica difícil saber quais dados deveriam ser analisados.

Isso é uma das coisas que mais me frustram com quem quer colocar os dados acima de tudo. Você pode fazer tracking de todos os links, mensurar todas as métricas e executar testes A/B para cada decisão, mas não importa o quanto você se aprofunde, não importa quantas horas você se dedique, você vai sempre estar olhando para apenas algumas peças do quebra-cabeça.

Não importa quantas horas você se dedique, você vai sempre estar olhando para apenas algumas peças do quebra-cabeça.

Para startups early stage é bem complicado ser data-driven — especialmente quando você está em “pre-product-market-fit” criando algo que não existe⁸. É quase impossível saber quais métricas você deve focar em otimizar. Claro que você precisa sempre estudar seu funil de signup, otimizar as landing pages e simplificar o onboarding, mas essa é a parte fácil. Tá cheio de receita de bolo por aí! O verdadeiro desafio é descobrir como transformar novos clientes em clientes que ficam com você no longo prazo. E as métricas para isso só surgem ao longo do tempo. Até lá você só tem duas opções 1) Seguir sem rumo; 2) Falar com os seus clientes. Acho que não preciso dizer qual é a melhor opção.

Conclusão

O tamanho da recompensa é, na maioria das vezes, proporcional ao risco que você assume. As vezes você só precisa estar disposto a dizer “Nós acreditamos nisso. Foda-se o que os dados dizem”.

Você precisa entender bem o seu cliente e por isso a empatia e intuição são super importantes — por isso acredito que criar bons produtos é uma combinação de arte e ciência. É claro que entrevistar usuários, observá-los, testar protótipos e fazer design sprint também geram dados. Mas poucas pessoas tem ciência disso — e as que tem costumam ignorar porque é bem mais fácil ficar olhando apenas para os dados que você consegue extrair rodando uma query.

Por isso você não deve se basear completamente em dados quantitativos para tomar decisões. Fazer com que os dados não forcem você a olhar apenas no curto prazo é um trabalho de constante vigilância e, em muitas empresas, de intervenções e batalhas políticas. Ser data-driven é bom, mas nunca podemos deixar de lado os ciclos de feedback, pesquisas e a empatia humana.

Agredecimentos especiais a Alex Killian (Fucking big thanks!), Marcelio Leal, Raphael Farinazzo, Renato Kovarish, Petrus Gomes, Thiago Pereira e Zalan Lima pelas revisões, feedbacks e correções.1. Alan Cooper: Mr Businessman Quote — You can innovate or you can predict and measure performance, but not both. Which will it be, Mr Businessman?

2. Algumas coisas simplesmente não são mensuráveis, como diria John F. Kennedy em um dos seus discursos mais memoráveis. E como algumas coisas não possuem métricas perfeitas para serem mensuradas, nós ficamos com o que é mensurável e fazemos os dados trabalharem a nosso favor. O que suporta isso é um estudo que comprovou que as áreas do cérebro que estão relacionadas a tomadas de decisão são ativadas bem antes de você decidir algo. Em outras palavras, seu cérebro toma decisões antes mesmo de você perceber. Esse fato, por si só, já cria viés em qualquer análise de dados. How Customers Think: Essential Insights Into the Mind of the Market, Gerald Zaltman, página 55.

3. A dificuldade de gerenciar um produto começa a aparecer quando você ganha tração porque existe aquilo que os fundadores querem criar, aquilo que os competidores já fazem, aquilo que os usuários querem, aquilo que o board/investidores acham que você tem que focar, aquilo que os maiores clientes estão querendo pagar e assim por diante. Um grade risco de criar um software Frankenstein. Falei sobre isso durante uma palestra que dei no Agile Brazil em 2015.

4. Em um mundo ideal todo mundo tem acesso a todas as informações e as decisões racionais são sempre baseadas nessas informações. Mas a teoria “Limitação da Racionalidade” criada por Herbert Simon e James March explica que a racionalidade de qualquer indivíduo é limitada por três dimensões: i) A informação disponível; ii) A limitação cognitiva da mente do indivíduo e; iii) O tempo disponível para a tomada de decisão — “Maps of bounded rationality: psychology for behavioral economics”. Daniel Kahneman (2003).

5. Já tem um tempo que queria escrever sobre esse assunto, mas após ler o livro do Clayton Christensen, Competing Against Luck, consegui consolidar melhor as ideias. O livro é uma leitura bem densa sobre Jobs To Be Done. E o próprio Clayton Christensen toca em alguns assuntos abordados aqui e fala sobre como é arriscado para inovação quando você é muito data driven. Você pode criar empresas que param no tempo se não focar no Job To Be Done.

6. UX Curve é um ótimo conceito sobre validação e ciclo de feedback. As vezes você precisa esperar a curva passar para começar a medir resultados de forma mais eficiente. O problema é saber quando a curva acaba e se o burn rate da sua empresa/produto aguenta ate lá. O artigo se chama UX Curve: A method for evaluating long-term user experience e foi publicado na Interacting with Computers em 2011.

7. As imagens falam por si só 🙂

8. O ideal é ler o livro Running Lean para entender bem o conceito de Product Market Fit e inclusive saber formas de encontrar o Market Fit. Mas para entender rapidamente o conceito indico essa resposta do Vikash Koushik no Quora: How do you define Product Market Fit