16 horas com Marty Cagan: o que aprendi sobre liderança e gestão de produtos

Bons times falham rápido; times ruins demoram até para falhar. Essa foi uma das frases que mais ficaram na cabeça depois de dois dias inteiros de workshop com Marty Cagan.  Em junho de 2018 participei do [SVPG Workshop — How to Create Products Customers Love](https://svpg.com) com Marty Cagan, autor do **Inspired** — um dos primeiros livros (leitura obrigatória) sobre produto, advisor de várias startups e uma das pessoas mais influentes do mundo quando se fala em gerenciamento de produto e liderança. Foram dois dias intensos, com centenas de insights para continuar construindo produtos que os clientes amam. Sem contar que reforçou ainda mais alguns dos princípios em que eu acredito muito quando se fala em produto: visão, cultura e validação. ## Os highlights - Todo mundo está buscando a "bala de prata" do produto, mas saiba que ela não existe. - Inovar está difícil como nunca. - Estamos em 2018 e ainda tem muita gente que não sabe de fato o que é um MVP… - Fique atento e avalie **sempre** estes quatro tópicos: 1. Value risk; 2. Usability risk; 3. Feasibility risk; 4. Business viability risk. - Uma das coisas mais importantes na gestão de produtos é saber **gerenciar seu tempo**. - Não adianta ter o melhor código-fonte ou a melhor arquitetura se você **não entrega valor para o cliente e não resolve os problemas dele**. - A **visão do produto** é a pintura daquilo em que você acredita. - A **estratégia do produto** descreve o caminho para transformar a visão em realidade. - Os **princípios de produto** descrevem a essência dos produtos que você pretende criar e refletem suas crenças sobre o que é essencial. - **OKR não é para mensurar pessoas.** Se você usar com esse intuito, as pessoas serão conservadoras na definição dos OKRs e você provavelmente vai perder o aspecto de team building. - Discovery é sobre **falhar rápido**. - **Bons times falham rápido; times ruins demoram até para falhar.** - É bom ter um time de missionários, não de mercenários. - Se você não está gastando a maior parte do seu tempo em discovery, corrija isso rápido e comece a fazer. (Mas não estamos falando daqueles processos de discovery infinito, ok?) - Design sprints podem ajudar muito no processo de transformação de cultura e aumentar a velocidade dos aprendizados. - Mas **design sprint não se roda toda semana**, ok? - Dentro de salas de reunião **não existem fatos, apenas opiniões**. - Quando o assunto é precificação, os *early adopters* não são as melhores pessoas para testar. - **Os dados não vão te mostrar o porquê**, mas vão te dizer que **não está funcionando**. - Testes qualitativos servem muito para **aprender**. - Todos os momentos são excelentes oportunidades para mostrar algo aos seus usuários (mesmo que seja um protótipo de baixa fidelidade). - Product/market fit é **só o início**. - Normalmente, roadmaps são uma lista de entregas (mas são um "quentinho no coração" dos stakeholders, então já sabe, né?). - Uma boa estrutura para quando algum stakeholder perguntar sobre algo é responder a estas duas perguntas: 1. Qual é o objetivo que estamos impactando? 2. Qual é o resultado que a gente espera? E, por último, mas não menos importante: - O foco deve estar no **resultado**, na entrega de **valor**, e não apenas em entregar features. (Mas às vezes rola uns pasteizinhos, não tem como fugir.) ## Bônus: as recomendações de livros do Cagan  - **[Hard Things About Hard Things](http://a.co/5AnibeZ)** — Ben Horowitz - **[User Story Mapping](http://a.co/bCIQ4MZ)** — Jeff Patton com Peter Economy - **[Sprint: How To Solve Big Problems and Test New Ideas in Just Five Days](http://a.co/i7jIdS6)** — Jake Knapp, John Zeratsky e Braden Kowitz - **[Lean Analytics](http://a.co/fVmOnEl)** — Alistair Croll e Benjamin Yoskovitz - **[Creativity, Inc.: Overcoming the Unseen Forces That Stand in the Way of True Inspiration](http://a.co/gxbriIP)** — Ed Catmull e Amy Wallace Valeu, Marty!