Como foi a Product Camp SP 2016 - a primeira do Brasil!

Publicado por Raphael Farinazzo e Jacqueline Asano no dia gestão

Jacqueline Asano e Raphael Farinazzo na Product Camp SP 2016

Já se vão mais de 80 anos desde que Neil McElroy contratou o primeiro brand man, ou o “MVP do Product Manager”. Desde então, a profissão passou por várias mudanças, especialmente com o Agile Manifesto e o conceito de Lean Startup. Fato é que hoje, se você perguntar para 10 PMs de empresas diferentes, é bem provável que em cada um tenha rotinas, papéis e responsabilidades diferentes. Às vezes, até o nome do cargo muda!

Por isso ficamos bem felizes quando vimos que ia rolar a primeira edição da Product Camp SP e logo de cara confirmamos presença no evento! A ideia de reunir 140 Gerentes de Produto do Brasil inteiro para trocar experiências brilhou nossos olhos e no último 3 de junho, lá estávamos nós na Viva Real para passar o dia falando sobre cases, roadmaps, growth, métricas e vários outros assuntos.

Abaixo, vai um resumo do que vimos por lá:

Case Youse

A Loren Monteiro apresentou seus aprendizados como Product Manager da Youse:

Construa um Dream Team e dê autonomia: Como diria Steve Jobs: “It doesn’t make sense to hire smart people and tell them what to do, we hire smart people so they can tell us what to do.” Aqui na Resultados Digitais, também seguimos essa linha, dando autonomia ao time para contestar problemas e soluções.

Mantenha um processo bem definido: se comprometa com um processo e não com um objetivo. Faça lançamentos rápidos e colete os feedbacks:

Loop Build Measure Learn do Lean Startup

Loop Build Measure Learn do Lean Startup

Lance seu produto enquanto tem vergonha dele

“Se você não tem vergonha do seu produto na primeira vez que voce o mostra pra um cliente, provavelmente você esta mostrando-o tarde demais.” Reid Hoffman, Co-founder do LinkedIn.

A Loren contou que levou 6 meses a mais para lançar o produto por causa de um “menu mais completo”. Eles acreditavam que os usuários precisavam dele. Eles estavam errados. Muitas vezes trabalhamos duro numa solução aqui na RD e ficamos inseguros de lançar para nossos clientes e tudo bem. Deixe que seus clientes te mostrem onde estão os problemas.

Keynote - Scaling products and teams in a hyper growth environment: lessons learned

Gabriela Rojas e o Pedro Axelrud apresentando os cases da Nubank

Estava com grande expectativa para esta palestra e posso dizer que ela ainda assim me surpreendeu. A Gabriela Rojas e o Pedro Axelrud, Product Managers, começaram falando sobre a cultura do Nubank. Eles compartilharam três cases sobre como escalar times.

No primeiro case eles mostraram a importância da construção de uma ferramenta inhouse para automatizar a priorização de tickets e reduzir o custo de operação. O segundo case (o meu preferido!) foi sobre como escalar a empresa, mantendo os times de produto mais próximos do time de operação (customer service). Ao criar squads com pessoas de todas as áreas - produto, engenharia e customer service - o Nubank conseguiu receber melhores feedbacks em uma velocidade maior e, assim, aumentar o sentimento de accountability e ownership de todo o time.

Aqui na RD estamos trabalhando para integrar cada vez mais o time de produto da operação através das Product Reviews, nas quais mostramos uma big picture do estado atual do RD Station e nossos planos de curto e médio prazo a todos os RDoers.

Já o terceiro case mostrou como podemos surpreender nossos clientes ao eliminar tarefas repetitivas do seu cotidiano.

Principais aprendizados

  1. Ouça seus clientes (externos e internos): todos os funcionários são clientes!

  2. Documente quando necessário: seja ágil, mas não esqueça de documentar os processos e aprendizados para que as informações não se percam e não se gere retrabalho.

  3. Re-avalie suas premissas sagradas: “Olhamos o sagrado e contestamos. Precisamos mesmo fazer isso assim?”

  4. Move fast and break things… in a controlled environment!

O Nubank é prova de que é possível construir um produto digital freak por fazer um incredible customer service. Aqui na RD somos todos freaks por ser Customer First :)

O Produto Frete

A Carla Matsumoto trouxe um case da Elo7 bem interessante, principalmente por ser um produto diferente do que estamos acostumados em SaaS: o frete.

A Elo7 é um marketplace de produtos personalizados, que conecta artesãos a consumidores que buscam esses tipos de produtos - lembrancinhas de casamento, ovos de páscoa artesanais, itens para casa e escritório, todos feitos a mão. Com algumas fricções no processo de contratação de frete, foram para o mapeamento da jornada de ambas as pontas dos marketplace, visando o aumento de engajamento dos dois lados: comprador e vendedor.

Apostaram nas interações mais próximas com os usuários, tanto online, aplicando questionários para beta-testers, quanto presencial, realizando bazares periódicos a fim de entender mais sobre a realidade de cada um. Não vamos dar spoilers do case, mas o principal aprendizado aqui foi: não menospreze seus questionários e muito menos a vontade dos seus clientes em participarem da criação do seu produto!

Objetivos > Features

O Arthur Debert abriu contando um pouco da história de como ele e mais um sócio fundaram a Loggi e por algum tempo, fizeram gestão de produto mesmo sem saber que tinha esse nome!

Quando se formalizou como Head de Produto, saiu ligando para conhecidos da área, pesquisando, lendo, aprendendo etc. para então desenvolver um modelo que se adequasse à realidade da empresa.

Atualmente estão trabalhando com o seguinte fluxo:

  1. Começam pela Visão da empresa, seu “reason why”, antes de pensar em usuários ou mesmo em produto.

  2. Para realizar a visão, definem Objetivos mensuráveis a partir de necessidades de negócio, como “melhorar CAC e LTV”.

  3. As features são Recursos que combinam objetivo + hipótese do que fazer para atingir.

Gostei bastante desse fluxo, que é bem similar ao que fazemos aqui na RD: visão, problemas que impedem de atingi-la, apostas das melhores soluções e features em formato de press release. Mas isso é matéria para outro post!

O que mais gostei da Loggi foi utilizar a visão da empresa acima de qualquer outro critério para fazer produto. Os Exemplos são bem eloquentes: “o Facebook deixa os usuários descontentes com algumas alterações mas a empresa está realizando sua visão; o Twitter faz rollback toda hora porque o engajamento caiu, por isso o produto segue andando de lado.”

Ele trouxe que a importância de ouvir os usuários se dá no momento de iterar sobre um recurso (objetivo + hipótese) ou solução (UX/UI). No plano estratégico, vale a visão da empresa!

Gerenciamento de Produto: métricas para pimpar seu produto

O Paulo Silveira, da Caelum, fez um talk centrado nas diversas métricas importantes de serem analisadas em produto. Inclusive fomos citados como exemplo no slide sobre análise de churn:

Paulo Silveira mostrando a Resultados Digitais como exemplo de empresa que mede o churn

Vi pelas perguntas que várias empresas confiam no Google Analytics para analisar métricas de clientes. O Paulo apontou melhores soluções que são focadas em Customer Analytics como o Kissmetrics, Woopra, Amplitude e Mixpanel, que usamos aqui na RD.

É importante acompanhar as métricas do seu produto e extrair inteligência dessas métricas, encontrar correlações entre dados. O Facebook, por exemplo, tem o “magic number”: quem adiciona 7 amigos em 10 dias tem mais chance de continuar usando a rede social. Por isso investem no auto-suggest, uma ferramenta que sugere amigos em seu nome para amigos que são novos na rede.

Cuidado: Data Driven ou Data Informed?

Nas palavras do Paulo: “ser data-driven é legal, mas é interessante não se guiar só pelos números. Acredito em ser data-informed, ou seja, ter uma visão que esteja acima dos números.”

O ponto central desse Talk é que devemos ter em mente aquela métrica que é realmente importante pro seu negócio (OMTM - One Metric That Matters) e usá-la de combustível dos objetivos e features do roadmap.

Keynote - 13 dicas para colocar a operação da sua área de produtos nos trilhos

O Diego Alvarez (ex-Google, Microsoft, EduK; atual Nextel) trouxe 13 dicas muito legais para a gestão de produto. Como não sei se posso dar spoilers dizendo todas, separei as que me chamaram mais a atenção:

Desperdício é não aprender. Qualquer que seja a alteração que você vai fazer, aproveite para definir bem as métricas que serão impactadas, os critérios de sucesso e todo tipo de acompanhamento que fizer sentido: heatmaps, scrollmaps, teste A/B. Fazer uma alteração e não aprender com ela é um desperdício!

Abordagens pelo método científico ou, nas palavras do Diego, “um pouquinho de documentação não faz mal”. Documentar as hipóteses, os resultados e as condições de realização do teste é a melhor maneira de realmente aprender. Do contrário, há o risco de repetirmos experimentos que já falharam antes.

Seja próximo do seu usuário. Aproxime as áreas de Customer Service do time de Produto - aqui na RD, por exemplo, temos o RDoer Voice, uma forma de ouvir das customer facing areas os problemas que os clientes estão enfrentando! Incentive também alguns clientes a se tornarem Beta Testers e se achar que é o momento, mantenha um board público de ideias para o produto, sempre com uma boa gestão de expectativas, para não decepcionar seus usuários.

Saiba avaliar as oportunidades. É importante ouvir o usuário, mas raramente os usuários terão ideias disruptivas para elevar seu produto um nível acima. Um conselho do Diego foi tentar ser “70% métricas / 30% guts”, ou seja, deixar margem para decisões baseadas na sua intuição a respeito do que priorizar.

A cultura ninja do Kekanto

O Allan Panossian apresentou os aprendizados do Kekanto na construção da sua cultura. Aqui vão os que mais se destacaram para mim:

Dê autonomia com alinhamento: deixe o time escolher a melhor tecnologia e estrutura para desenvolver. Aqui na RD pensamos do mesmo jeito. Todos tem autonomia para decidir o que é melhor para si e estamos criando uma área de UI e UX transversal aos times para garantir esta autonomia com alinhamento.

Job Rotation para difundir o conhecimento no time: o dev muda de time para aprender outros conhecimentos com outras pessoas.

Hacktimes para estimular inovação: o time se reúne, analisa dados de uso do sistema e discute o que seria bacana fazer para o usuário a partir desta análise.

Browbags para difundir o conhecimento: na hora do almoço, o time compartilha seus conhecimentos em tecnologia. Aqui na RD, fazemos isso também, com seminários semanais por frente de atuação (Produto+Design, Marketing ou Engenharia), que estimulam essa troca de aprendizado no time.

Hackatons: a Kekanto estimula hackatons nos times com foco em projetos que podem começar e terminar em 3 dias, sempre fora do ambiente de trabalho.

Confiança no time, autonomia, ambiente colaborativo e aprendizado contínuo é o que levamos da cultura do Kekanto e vemos aqui na Resultados Digitais. :)

In God we trust, all others must bring data

O Bernardo Srulzon, da GetNinjas, fez um talk centrado no loop build-measure-learn do Lean Startup e no Pirate Metrics (AARRR), do Dave McClure.

Ele apresentou as métricas utilizadas pela GetNinjas em cada etapa, principalmente Ativação, que é a mais crítica para eles. Depois apresentou um case de otimização de funil para usuários que acessam via mobile e são direcionados ao download do app. Com muita análise e poucas mudanças de interface, conseguiram reduzir o atrito e guiar os usuários até o final do fluxo.

O grande ponto que ele trouxe foi: comece sabendo o que você vai investigar e o que você quer aprender. Pode parecer tentador navegar a esmo em gráficos e dashboards, mas (como ele disse) “data science só faz sentido se gerar ações” e para isso, você precisa começar sabendo o que você quer mudar.

Roadmaps that grinds my gears

O Renato Cairo falou um pouco sobre como a VivaReal trata seus roadmaps de produto. Como a RD, eles também partem de hipóteses (aqui chamamos de “apostas”) e procuram (in)validar as suposições mais arriscadas de forma metódica, deixando o roadmap um pouco mais tolerante a risco.

Ele apresentou o fluxo de elaboração de roadmap como:

  1. Pain Points - para o usuário, para o produto, para a empresa.

  2. Hipóteses - como solucionar essas dores.

  3. User Stories.

Nesse modelo, perceberam que estavam deixando de lado o encantamento, o “wow factor” que todo produto deve ter. Para ilustrar, o Renato trouxe alguns exemplos do Slack, como as cores hexadecimais em chats e o /shrug.

Foto exemplo

Quando se deram conta disso, passaram a olhar mais para o Modelo de Kano, acrescentando os famosos Delighters, se não ao roadmap, pelo menos à etapa de elaboração da solução de UX/UI. Ao desenvolver as User Stories, costumam se perguntar: “estamos esquecendo de encantar?”

Na sessão final de perguntas, ele esclareceu que entre resolver um problema crítico (pain point) e implementar um delighter, obviamente vão resolver o problema primeiro. Mas o ponto central do talk foi: não descarte os delighters! Resolver problemas não basta; faça um produto que resolva problemas e encante.

Design Thinking e Lean Startups para o desenvolvimento de um novo produto

O evento encerrou com o talk do Alex Kobayashi, da Geofusion. Ele trouxe a experiência da empresa com o Design Thinking e os conceitos de Lean Startup. Segundo ele, o produto era complexo em sua utilização e a estrutura técnica também havia se tornado complexa, com o time crescendo de 6 para 28 pessoas em pouco tempo.

Ele adotaram o Lean Inception, do Paulo Caroli, trazendo o time pelo processo de elevator pitch, criação de pessoas e jornadas, definição de métricas etc. até chegar às hipóteses. O Design Thinking entrou para ajudar a prototipar de modo rápido e barato, testar, medir e aprender. Feito isso, a tarefa entra no Kanban de Engenharia em Continuous Delivery. Ele reforçou que na cultura do time, “nada está escrito em pedra” e eles procuram ser ágeis e responder a mudanças sempre que elas aparecem.

Além disso, trouxeram os clientes mais para perto, com um User Research Lab, para validar protótipos e melhorar a usabilidade. Um dos protótipos, inclusive, foi validado presencialmente por meio de um jogo de tabuleiro para os clientes. Muito legal!

Impressões gerais da Product Camp SP

No geral, o saldo do evento foi muito positivo, tanto em aprendizado quanto em networking. Foi um grande passo para a comunidade de Product Managers no Brasil tomar corpo, e só temos a ganhar com isso.

Inclusive aproveitamos o convite da organização, ao final do evento, para um “Happy Hour não-oficial”, também muito produtivo. O assunto continuou em torno do desenvolvimento de produto na cultura ágil, com um bate-papo riquíssimo sobre práticas, dificuldades, experiências, lições aprendidas, entre outros.

Vale dedicar um parágrafo ao Product Manager que organizou o evento, Marcell Almeida. Ele está de parabéns, tanto pela tarefa heroica de organizar um evento com essa temática, quanto pela iniciativa de iniciar um movimento tão importante para o mercado brasileiro de gestão de produto!

Se você estava lá, compartilhe nos comentários o que achou! Se não estava, fique à vontade para comentar o que achou do nosso resumo!

Raphael Farinazzo

Raphael Farinazzo

Product Manager

Jacqueline Asano

Jacqueline Asano

Product Manager

Comentários