Anotações sobre o livro "Inspired" do Marty Cagan

Qual é a diferença entre um Product Manager e um Product Designer?

O autor Marty Cagan, em sua obra “Inspired”, aborda essa e outras questões.

Para ele, o Product Manager é o dono da visão do produto, se questionando continuamente:

• Quem é o usuário do produto?
• Como estamos gerando valor para o usuário?
• Como o produto se alinha ao negócio?

Disso, eu tiro que de fato há um overlap importante entre as funções do Product Designer e do Product Manager, já que ambos pensam no usuário do produto e como entregar o melhor valor, a melhor experiência.

Até por isso, em estágios iniciais de produto, muitas vezes os dois papéis são executados pela mesma pessoa.

Me parece que a principal diferença entre os dois é o foco na viabilidade de negócio.

Podemos pensar que o Product Designer é a pessoa capaz de gerar soluções próximas à perfeição, dado um contexto de abundância de recursos.

Já o Product Manager poda essas soluções, transformando-as em uma estratégia de produto. Lidando com limitações de recursos como financiamento, mão de obra, e tempo, constrói um produto que chega próximo à visão do Designer, gerando valor para o usuário e ao mesmo tempo sendo viável para o negócio.

Para minha própria referência, registro abaixo algumas anotações que fiz sobre o livro “Inspired”.

Dividido em 5 partes

1) Lessons from Top Tech Companies
2) The Right People
3) The Right Product
4) The Right Process
5) The Right Culture

---

Tamanho de cada parte

1) Lessons from Top Tech Companies
    10%
    8 capítulos: 1 a 8
    32 páginas: 1 a 32

2) The Right People
    23%
    13 capítulos: 9 a 21
    74 páginas: 33 a 106
    Itens que lembro ou considero fazer parte dessa parte após ler o índice:
        Designer
        Engineering
        Supporting Roles
        Testing

3) The Right Product
    16%
    11 capítulos: 22 a 32
    52 páginas: 107 a 158

4) The Right Process
    45%
    31 capítulos: 33 a 63
    150 páginas: 159 a 308
    Itens que lembro ou considero fazer parte dessa parte após ler o índice:
        Ferramentas
        Testes
        Usabilidade

5) The Right Culture
    6%
    4 capítulos: 64 a 67
    18 páginas: 309 a 326
    Itens que lembro ou considero fazer parte dessa parte após ler o índice:
        Perda de velocidade
        Perda de inovação
        Time de produto bom vs time de produto ruim

---

Parte 0 - Pré-conteúdo

* p. I até p. VI
    Testimonials de empresas como HotelTonight, Guardian News e outras

* p. XIII
    Dedicatória

* p. XVII
    Prefácio para 2ª edição
    Reescrita completa
    Na 1ª, Ágil ainda não estava consolidado, e antes de popularização
        da nomenclatura Customer Development e Lean Startup
    1ª edição focou em Startups
    Agora está focando em companhias em growth-stage
    Há outros livros para Product Designers e Engineers, mas falta para
        Product Managers, que são responsáveis por produtos de tecnologia. 
    Trabalho do PM é difícil, e nem todos estão aptos

---

Part 1 - Lessons from Top Tech Companies

* p. 1
    Trabalhou na HP em 1980: baratear AI
    Bom produto, bom desenvolvimento técnico, mas ninguém comprou
    Não importa quão bom é seu time de engenharia, se não constroem algo de valor

* p. 2
    PM é a pessoa que tomou a decisão errada do AI
    HP não era boa com PM
    Autor trabalhou com várias empresas de sucesso depois disso:
        Computadores pessoais na HP, Netscape, eBay
    Diferença no modo de criar produtos entre melhores empresas vs. maioria das empresas

* p. 5 - Chapter 1 - Behind Every Great Product
    Atrás de todo produto de sucesso: PM, CEO ou outra pessoa fazendo esse papel de combinar tecnologia e design para resolver problemas de pessoas
    E esse papel é bem diferente de Design, Engineering, Marketing ou Project Manager
    É um trabalho que exige 60 horas por semana
    É difícil conciliar com papel de designer ou engineer, mas pode ter resultados muito positivos
    Time de produto: PM + 2 a 10 engenheiros
    Em caso de user-facing product: precisa também de um product designer

* p. 7 - Chapter 2 - Technology-Powered Products and Services
    Foco em produtos "powered by technology"
    Exemplos de produtos aplicáveis: Netflix, Airbnb, Facebook, LinkedIn, Salesforce, Apple, Tesla, Uber, Audible
    Não precisa ser 100% digital

* p. 9 - Chapter 3 - Startups: Getting to Product/Market fit
    3 estágios de empresas:
        startups
        growth-stage
        enterprise 
    Em startups, o PM é normalmente um dos co-founders
    Normalmente há menos de 25 engenheiros
    1 a 5 times de produtos
    Corrida para obter produto antes de acabar o dinheiro
    Trabalhar em uma startup é estressante, exaustivo e arriscado
    Pode ser recompensador

* p. 11 - Chapter 4 - Growth-Stage Companies: Scaling to Success
    As poucas que sobrevivem, devem começar a gerenciar o crescimento
    Dores do crescimento é um problema "bom"
    Contratar pessoas
    Como replicar sucesso anterior em novos produtos e serviços
    Entre 25 e algumas centenas de engenheiros
    Times de produtos reclamam que não enxergam a visão global da organização
    Estratégias de marketing são diferentes do primeiro produto
    "Technical debt" e problemas de infraestrutura técnica
    Estilos de liderança que funcionavam no começo frequentemente não escalam
    Líderes mudando de papel, e de comportamento

* p. 13 - Chapter 5 - Enterprise Companies: Consistent Product Innovation
    Inovação consistente de produto
    Constantemente criando valor para clientes
    Não apenas otimizar produtos já existentes, mas desenvolver produtos para atender todo o potencial
    Há mais stakeholders, talvez a empresa seja pública. Há maior aversão a risco
    Empresa já alcançou visão inicial de startup, e agora precisa descobrir o que vem depois
    Times de produto sem visão
    Decisões lentas
    Design by committee

* p. 15 - Chapter 6 - The Root Causes of Failed Product Efforts
    Comparação entre processos das melhores empresas vs. maior parte das empresas
    Figura 6.1 - Mostra o processo que a maior parte das empresas utilizam: Ideas > Biz Case > Roadmap > Requirements > Design > Build > Test > Deploy
    Processo da maior parte das empresas:
    > Ideias vêm de dentro (owners) ou de fora (clientes)
    > Priorizar ideias no formato de um roadmap
    >     Informar prioridades para times de desenvolvimento
    >     Prever quando cada coisa estará pronta
    > Sessão de planejamento trimestral ou anual de negociação do product roadmap
    > Para negociar, é necessário o "business case"
    >     1) Quanto dinheiro ou valor será gerado?
    >     2) Quanto dinheiro ou tempo será gasto?
    > Quando uma ideia é a próxima da lista, um PM conversa com stakeholders para levantar requisitos
    >     No formato de user stories, ou especificação funcional, para comunicar com designers ou engenheiros
    > Após requisitos reunidos, ao time de UX Design é solicitado o design de interação, o design visual e possivelmente o design industrial
    > Em seguida, os requisitos e especificações chegam aos engenheiros. É nessa etapa que normalmente começa o Ágil

* p. 17 - Continuação do capítulo anterior
    Criticando o modelo acima, tem mais cara de Waterfall do que Ágil, mas a maior parte das empresas fazem assim
    Maiores 10 problemas na opinião do autor:
        1) Produtos do tipo sales-driven specials e stakeholder-driven não são os melhores (autor vai falar mais sobre isso posteriormente). Também não há autonomia nenhuma dos times, já que estão ali apenas para implementar
        2) Business cases: é impossível saber qual será o valor gerado, e qual será o custo. Engenheiros experientes vão se recusar a fornecer estimativas
        3) Roadmaps: 2 verdades inconvenientes. Primeira: pelo menos metade das ideias não vai funcionar. Bons times assumem que 75% das ideias não vão funcionar. A segunda verdade é que para o restante das ideias que funcionam, são necessárias diversas iterações até chegar em um ponto de valor ("time to money")
        4) No formato acima, o Product Manager na verdade é um Project Manager, que seria juntar requisitos e documentá-los para os engenheiros
        5) Design entra muito tarde no processo ("lipstick on the pig")
        6) Engenheiros também entram muito tarde. Metade do valor dos engenheiros é programar. Engenheiros são a melhor fonte de inovação
        7) Benefícios do Ágil chegam muito tarde, junto com os engenheiros
        8) O processo é projeto-cêntrico, leva a projetos órfãos
        9) Validação do cliente acontece muito tarde. O princípio chave em métodos Lean é reduzir desperdício, e isso não acontece
        10) Custo de oportunidade: a organização deveria estar fazendo algo diferente. Desperdício de tempo e dinheiro

* p. 23 - Chapter 7 - Beyond Lean and Agile
    Não há "silver bullets" para criar produtos
    Está em moda criticar Lean e Ágil, mas o autor acredita que esses princípios vieram para ficar
    Ele conhece diversos times que seguem o "Lean" mas que estão há meses desenvolvendo um MVP, e ainda não sabem se isso vai vender
    Empresas que aplicam bem Ágil e Lean muitas vezes usam outra nomenclatura
    Três princípios gerais de sucesso na aplicação:
    1) Riscos são enfrentados no início, e não no fim (riscos de valor, usabilidade, viabilidade técnica, viabilidade de negócios)
    2) Produtos definidos e com design feito de forma colaborativa, e não sequencialmente
        Modo antigo: PM define requisito, designer propõe uma solução, engenharia implementa os requisitos
        Modo novo: product, design e engineering trabalhando lado a lado
    3) É sobre resolver problemas, e não entregar features

* p. 25 - Chapter 8 - Key Concepts
    Alguns conceitos fundamentais utilizados em produtos
    * Produto holístico: inclui funcionalidade/features, tecnologia, UX design, monetização, aquisição de usuários e clientes, experiências offline
    * Continuous Discovery and Delivery: descobrir o produto a ser criado; entregar esse produto ao mercado. PM e designer trabalham diariamente na descoberta do produto, e engenheria na entrega do produto. Mas os engenheiros também ajudam diariamente com descoberta, e muitas boas inovações vem dali. Ao mesmo tempo, PM e designer ajudam diariamente com entregas, clarificando o comportamento
    * Product Discovery: colaboração de PM, UX design e engenharia, enfrentando riscos antes de escrever uma única linha de software para produção. Responder às perguntas: O usuário vai comprar isso? O usuário vai entender como utilizar? Nossos engenheiros conseguem construir? Nossos stakeholders conseguem financiar?

* p. 27 - Continuação Chapter 8
    * Prototypes: requerem uma ordem de magnitude menor de tempo e esforço do que criar um produto
    * Product Delivery: escala, performance, realibility, fault tolerance, segurança, privacidade, internacionalização, localização
    * Products and Product/Market Fit: é o menor produto possível que atende às necessidades de um mercado específico de consumidores. É um dos principais focos do livro
    * Product Vision: visão de longo prazo do produto (2 a 10 anos)
    * MVP: termo cunhado em 2001; popularizado em 2011 (Then Lean Startup). Confusão: o P é Product, mas um MVP nunca deve entregar um produto (da definição anterior). A letra P deveria ser de Prototype.

Part 2 - The Right People

* p. 31
    Como você define papéis (roles), e pessoas que você seleciona, tem uma influência alta nos resultados
    * Product Teams: é o conceito principal do livro 

* p. 33 - Chapter 9 - Principles of Strong Product Teams
    Também conhecidos como "dedicated product team" ou "durable product team", ou "squad". São cross-functional.
    Diferentes skills e responsabilidade, e se sentem dono de um produto
    Teams of Missionaries: precisamos de times de missionários, e não de mercenários
    Mercenários constroem o que lhes é pedido
    Missionários compram a visão e estão comprometidos em resolver o problema do cliente
    Composição de times: PM + Product Designer + 2 a 12 engenheiros. Possivelmente também Product Marketing Manager, engenheiros de automação de testes, pesquisador de usuários, data analyst, delivery manager
    Times recebem objetivos claros. Possuem autonomia, e são accountable pelos resultados
    Tamanho do time: pelo menos 1 PM, 1 Designer, 2 Engenheiros
    Normalmente a estrutura é horizontal (flat), e não há people managers
    As pessoas do time continuam respondendo aos seus supervisores funcionais. Exemplo, engenheiros reportam para o engineering manager; designer reporta para o head of design; product manager reporta para o head of product

* p. 35 - Continuação Chapter 9
    Recomendação: times co-located. A tela de um deve estar visível para o outro
    "All other things being equal, a co-located team is going to substantially outperform a dispersed team. That's just the way it is."
    Escopo do time: todos os tipos de trabalho, como features, bug fixes, performance, otimizações, alteração de conteúdo
    Escopo do trabalho: dentro da uma grande organização com um único produto, cada time de produto é responsável por uma parte menor, mas significativa, da experiência. Em alguns casos, a divisão é feita por tipo de cliente, ou pela stack de tecnologia
    Head of product e head of engineering decidem em conjunto o tamanho e escopo dos times
    Quando você otimiza para algo, outro parâmetro acaba sendo afetado. Deve haver uma escolha explícita do que é desejado
    Duração do time: não há uma definição clara. Meses? Anos? Quanto mais, melhor
    Autonomia do time: redução de dependência entre times. "They are able to try to solve the problems they are assigned in the best way they see fit"

* p. 38 - Continuação Chapter 9
    Por que funciona?
        Colaboração é construída na base de relacionamentos
        Para inovar é necessário expertise, o que pode ser obtido dada a natureza durável dos times
        O time inteiro entende, precisa entender, os objetivos de negócio e o contexto. E o time inteiro se sente responsável pelo resultado

* p. 41 - Chapter 10 - The Product Manager
    3 formas de trabalhar para um PM, e somente 1 funciona:
        1) Escalar todo problema e decisão para o CEO. É o "backlog administrator"
        2) PM envolve todos os stakeholders em uma reunião para eles brigarem entre si ("design by committee"). É o "roadmap administrator"
        3) Fazendo o trabalho dele

    Empresas antiquadas migram para Ágil e deslocam antigos project managers e business analysts para o cargo de product manager, um cargo que não é necessariamente adequado

    É um cargo difícil: sofisticação tecnológica, conhecimento de negócio, credibilidade com executivos, conhecimento profundo de clientes, paixão pelo produto, respeito do time do produto.

    Responsabilidades principais: avaliar oportunidades e determinar o que será construído. O que será construído é o backlog do produto

    Atualmente, designers e engenheiros querem evidência de que você está construindo algo de valor

    PM é accountable pelo sucesso do produto, pois ele determina o que vai ser construído. Em caso de sucesso, o mérito é de todos. Em caso de falha, a responsabilidade é do PM

    Os melhores venture capitalists (VCs) só querem investir em empresas em que um comprovadamente bom PM é um dos co-founders

* p. 43 - Continuação Chapter 10

    4 habilidades principais de PMs:
    1) Conhecimento extensivo sobre o cliente (e ser um expert no produto que você está desenvolvendo)
    2) Conhecimento extensivo em dados. Analytics, métricas, vendas, utilização, resultados de testes A/B
    3) Conhecimento extensivo do seu negócio/empresa. Além de amado pelos clientes, deve trabalhar em prol do negócio, conhecendo os stakeholders e as constraints
    4) Conhecimento extensivo do mercado e da indústria: concorrentes, tendências de tecnologia, comportamentos de clientes. Você precisa ser substancialmente melhor para trazer clientes do concorrente. Você precisa construir produtos para o amanhã, e não baseados no ontem

    Em algumas organizações, o conhecimento do domínio é tão extenso que o PM é suplementado por especialistas de domínio (domain experts / subject matter experts). Exemplos: software fiscal, indústria médica

    Normalmente são necessários 2 a 3 meses de trabalho dedicado de um PM para começar a ser produtivo

* p. 46 - Continuação Chapter 10
    Tipo de pessoa que floresce nesse ambiente: inteligente, criativa, persistente
    Paixão por produtos e resolver problemas de clientes não é algo que pode ser ensinado
    PM é o trabalho mais exigente. Os outros papéis dentro do time de produto são mais equilibrados na questão trabalho/lazer

    Passo a passo para começar:
    Vire um especialista nos seus usuários e clientes
    Crie uma relação forte com seus stakeholders. Demonstre que você está a par das constraints, e que você só irá trazer soluções que satisfaçam as constraints
    Vire um especialista no seu produto e indústria
    Trabalhe duro para construir e nutrir uma relação colaborativa com seu time de produto

* p. 48 - Continuação Chapter 10
    Lista de PMs de sucesso:
        Jane Manning (Google)
        Lea Hickman (Adobe)
        Alex Pressland (BBC)
        Martina Lauchengco (Microsoft)
        Kate Arnold (Netflix)
        Camille Hearst (Apple)

* p. 49
    Em todos os exemplos listados, as melhores soluções não vieram dos usuários, clientes ou vendas. Os usuários não tinham ideia de que aquelas soluções incríveis eram possíveis

* p. 50 - Product Manager vs Product Owner
    É absolutamente necessário que o PM seja também o Product Owner do Ágil, caso contrário, o PO fica sem autonomia
    Atribuições do PO é um subconjunto reduzido das atribuições do PM

* p. 51 - Continuação Chapter 10
    Não é necessário gradução em computação para o papel de PM (o principal é o que já foi dito anteriormente: inteligência, criatividade e persistência)
    Mas recomenda cursos técnicos básicos:
        Introduction to Computer Programming
        Introduction to Business Accounting/Finance

* p. 53 - Chapter 11 - The Product Designer
    O autor se surpreende como esse papel é desvalorizado dentro de organizações
    Responsáveis por:
    * Product Discovery em conjunto com PM e Engineer. Designers são avaliados pelo sucesso do produto, e não pela velocidade de entrega de interfaces. Preocupações similares à do PM: clientes, valor, constraints do negócio
    * Holistic UX Design (UX também chamado de CX para dar ênfase no cliente): formas concretas de levar valor ao cliente, incluindo todas as interações ao longo do tempo (interfaces, e-mail, campanhas de marketing, processo de venda, suporte ao cliente, serviços offline) 
    * Prototipagem: bons product designers utilizam protótipos como meio para comunicarem suas ideias
    * User Testing: estão constantemente testando suas ideias com usuários e clientes. "User testing" é mais amplo do que "usability testing". É a oportunidade de avaliar o valor das ideias
    * Interaction and Visual Design: historicamente, esses dois papéis eram separados, mas de forma mais moderna esses dois papéis tem sido agrupados, permitindo ampliar o controle da experiência

* p. 56 - Continuação Chapter 11
    The Absence of Product Design
    Há 3 situações recorrentes no caso de ausência de Product Design:
        * PM tenta fazer o product design por conta própria. Você fornece wireframes para os engenheiros, e eles convertem isso para um design por conta própria
        * Você não fornece os designs, e sim user stories de alto nível para os engenheiros. Eles acabam desenvolvendo um design por conta própria 
        * Você fornece o "interaction design", incluindo wireframes, e um designer gráfico converte esse design para um "visual design"

    As 3 situações acima são problemáticas e raramente trazem bons resultados. Não conseguem suprir o design holístico desejado

    Se você está criando produtos para consumidores, um bom design é requisito obrigatório. Se estiver criando produtos para empresas, é no mínimo um diferencial competitivo

    A maior parte de produtos para empresas tem um design horrível, em parte por que o usuário não é quem compra. Há uma tendência de mudança

* p. 57 - Continuação Chapter 11
    
    Para uma empresa utilizar de forma satisfatória os seus designers, não pode simplesmente tratá-los como uma prestadora de serviços interna. Precisamos dos designers para descobrir o produto, e não para embelezar o produto

    5 dicas para bom relacionamento entre PM e Designer:
    1) Faça de tudo para o Designer estar sentando ao seu lado
    2) Inclua o designer na concepção de qualquer nova ideia
    3) Inclua o designer em contatos com clientes e usuários
    4) Lute contra a tentação de fornecer para o Designer suas próprias ideias de design
    5) Encoraje o Designer para iterar frequentemente, não sendo muito rigoroso em detalhes nas primeiras iterações, e fomentando a exploração de alternativas

* p. 59 - Chapter 12 - The Engineers
    Engineers, Developers ou Programmers
    Não há relação mais importante do que a entre o PM e os engenheiros
    Se houver uma boa relação, o trabalho do PM é ótimo
    Engenheiros são tipicamente inteligentes e céticos por natureza, então é melhor você não fingir que entende de algum assunto que não entende
    É importante compartilhar abertamente o que você sabe sobre os clientes, e as restrições de negócio
    Você pode ser contundente, mas ao mesmo tempo se demonstrando open minded
    Há dois tipos frequentes de interação: 1) você solicita ideias e inputs para os itens que estão em etapa de descoberta; e 2) você clarifica dúvidas sobre os itens que estão entregando
    Evite forçar a maneira de como um problema deve ser resolvido junto aos engenheiros
    Eles devem se sentir como missionários, e não mercenários

    Dentro da carreira de engenharia, os Tech leads têm uma responsabilidade explícita de ajudar o PM e o product designer na obtenção de uma solução robusta

    Não são todos os engenheiros e até mesmo engenheiros seniores que desejam participar das atividades de Discovery

    Um grande problema é se nenhum deles quiser participar dessas atividades. É por isso que PM, Product Designer e Tech Lead devem trabalhar bem próximos

    Em alguns times, pode haver mais de 1 Tech Lead, o que é melhor ainda

* p. 63 - Chapter 13 - Product Marketing Managers

* p. 67 - Chapter 14 - The Supporting Roles
    Li muito rapidamente. Alguns deles: User Researchers, Data Analysts, Test Automation Engineers

* p. 71 - Chapter 15 - Profile: Jane Manning (Google)
    Li bem rapidamente. Foi a principal responsável pelo sucesso do AdWords. Convenceu um engenheiro importante que a ideia era boa, e conseguiu construir um time para entregar um produto que gera dezenas de bilhões de dólares de receita anualmente

* p. 74 - People @ Scale
    É uma introdução do próximo grupo de capítulos

* p. 75 - Chapter 16 - The Role of Leadership
    Recrutar, desenvolver e reter grandes talentos
    Além disso, em grandes organizações: "visão holística do produto" (conectar os pontos entre os times)

    3 elementos da visão holística do produto:
    1) Leaders of Product Management, por exemplo um Principal Product Manager, para revisar o trabalho dos outros PMs e resolvendo conflitos, ou o próprio Head of Product
    2) Leaders of Product Design, responsável pela experiência holística do usuário
    3) Leaders of Technology Organization: CTO ou VP engineering, normalmente auxiliados por engineering managers e diretores, e arquitetos de software. São responsáveis pela visão holística da implementação do sistema e pelo controle da dívida técnica

    Quanto maior a empresa, mais falta faz cada um desses 3 papéis holísticos

    Se a experiência do usuário é conflitante, provavelmente falta um head of design
    Se PMs precisam pedir para engenheiros analisar o código para identificar como algo realmente funciona, falta um "principal product manager"
    Se o seu software é uma grande macarronada e é muito lento para fazer uma mudança simples, provavelmente há muita dívida técnica

    Retenha essas pessoas. Cuide delas, e deixe claro que não precisam virar managers para ganhar mais dinheiro

    Desenvolva mais dessas pessoas, e cada uma delas deve sempre estar desenvolvendo uma segunda nova pessoa (o que é demorado, e valioso)

    Algumas empresas tentam documentar tudo extensivamente, para substituir o papel dos 3 líderes, mas o autor ainda não viu sucesso nessa abordagem

    O autor recomenda que os 3 líderes estejam muitos próximos entre si, preferencialmente no mesmo escritório

* p. 79 - Chapter 17 - The Head of Product Role
    Se você é CEO, esse capítulo te ajuda a encontrar um Head of Product
    Posição conhecida como "VP product", "Director of Product Management", "Chief Product Officer"
    Reporta para o CEO
    Gerencia PMs e Product Designers
    4 competências: team development, product vision, execution and product culture
    Principal responsabilidade: formar um time forte de PMs

* p. 80
    Se CEO é forte em produto e visão, aumenta chances de colisão ao contratar um "VP product"
    Se CEO é fraco, contrata alguém parecido com ele, e continua faltando visão 
    Ambos acima são ruins. A moral da história é que o VP product deve complementar o CEO, e não ser alguém igual

    Independentemente da visão, o product leader precisa ter compotência comprovada em execução

* p. 82
    Product Culture: o time entende a importância de protótipos rápidos e aprendizado. Erros são necessários para aprender, mas devem ser rápidos e mitigando riscos
    Entendem inovação contínua
    Entendem o valor de colaboração

    GPM (Group Product Manager) papel "player-coach", útil para transição de carreira de PMs, em que ele é um PM, e ao mesmo tempo supervisiona outros (1 a 3) PMs mais juniores

* p. 87 - Chapter 18 - The Head of Technology Role
    Também conhecido como "VP engineering", "CTO"

    OBS - Já o papel de CIO (chief information officer) é bem diferente do CTO, e não devem ser confundidos

    CTO: Head da organização responsável por arquitetura, engenharia, qualidade, site operations, site security, gestão de releases e gestão de entregas

    CTO: Atua para aplicar a tecnologia como um habilitador estratégico para o negócio e produtos 
    Remove as barreiras de tecnologia
    
    6 principais responsabilidades:
    1) Organização: construir uma organização forte
    2) Liderança: representar a tecnologia junto a outros executivos
    3) Entrega: garantir que a organização consegue rapidamente, confiavelmente e consistentemente entregar produtos ao mercado. Garantir que dívida técnica se mantenha em níveis toleráveis para não tornar lenta a evolução do produto
    4) Arquitetura: garantir que a organização possua uma arquitetura capaz de entregar funcionalidade, escalabilidade, confiabilidade, segurança e performance
    5) Descoberta: garantir que os seniores de engenharia estão participando ativamente e contribuindo para o Product Discovery
    6) Evangelização: porta-voz da organização de engenharia

* p. 91 - Chapter 19 - The Delivery Manager Role

* p. 93 - Chapter 20 - Principles of Structuring Product Teams

* p. 103 - Chapter 21 - Profile: Lea Hickman of Adobe

* p. 111 - Chapter 22 - The Problems with Product Roadmaps
    Muitas ideias acabam não acontecendo
    Múltiplas interações para chegar em um nível de valor: "Time to money"

* p. 115 - Chapter 23 - The Alternative to Roadmaps
    Uma boa alternativa deve continuar tendo as 2 funções do roadmap:
        1. Assegurar à direção que os itens de maior valor estão priorizados
        2. Negócios muitas vezes têm compromissos baseados em datas (contratos, etc)

* p. 123 - Chapter 24 - Product Vision and Product Strategy
    Visão: futuro que queremos criar daqui a 2 a 5 anos, com propósito de comunicar e inspirar

    Devemos evitar um esforço multide múltiplos anos para lançar algo que entrega a visão de uma única vez

    Product Strategy: sequência de produtos (ou releases) para concretizar a visão

* p. 129 - Chapter 25 - Principles of Product Vision
    10 princípios:
        1. Por que?
        2. Se apaixone pelo problema, não pela solução
        3. Pense grande
        4. Disrupt yourself
        5. Inspire
        6. Adote tendências importantes
        7. Mire no futuro, não no presente
        8. Seja teimoso com a visão, mas flexível com detalhes
        9. Toda visão é um salto de fé / voto de confiança
        10. Evangelize

Part 3 - The Right Product

Part 4 - The Right Process

* p. 159
    Não é um processo em si, e sim uma combinação de técnicas de Product Discovery
    Além de Discovery, PM e PD devem estar sempre disponíveis para os engenheiros nas atividades diárias (1 hora por dia)

* p. 165 - Chapter 33 - Principles of Product Discovery
    O cliente vai comprar ou usar?
    O cliente vai entender como usar?
    Somos competentes para construir?
    Essa solução é viável para nosso negócio?

* p. 171 - Chapter 34 - Discovery Techniques Overview
    Discovery Framing Techniques: quais questões devem ser enfrentadas 
    Discovery Planning Techniques: identificar os grandes desafios e planejar como atacá-los

    Discovery Ideation Techniques: soluções promissoras

    Discovery Testing Techniques: separar ideias boas das ruins  

    Testar viabilidade: dificuldades do lado da engenharia: nova tecnologia, escala, performance

    Testar usabilidade: atuar em áreas de problemas 

    Testar valor: garantir que clientes vão comprar

    Testar viabilidade de negócio: nosso negócio consegue financiar a criação do produto, lançamento e venda?

    Técnicas de transformação: técnicas simples para guiar a transição do time para o modo de trabalho desejado 

* p. 187 - Chapter 37 - Startup Canvas Technique
    
    Mais recomendada para novos produtos
    É parente do "thick business plan"
    Listar os maiores riscos do negócio e encorajar o time a enfrentá-lo cedo

* p. 193 - Chapter 38 - Story Map Technique
    Matriz de user stories para manter o contexto
    Contexto ordenado da esquerda para a direita
    Detalhamento ordenado de cima para baixo

    O autor conhece diversos times fãs das técnicas "story map" e "high-fidelity user prototype"

* p. 227 - Chapter 45 - Principles of Prototypes

    5 princípios:
        1. Aprender algo com um custo ao menos 1 ordem de grandeza menor
        2. Forçar a pensar de modo profundo no problema
        3. Ferramenta para colaboração e alinhamento de entendimento
        4. Diferentes níveis de fidelidade que se ajustam a diferentes objetivos. Alta fidelidade é mais caro, fazer apenas quando necessário
        5. Deve enfrentar 1 ou mais riscos de produto (valor, usabilidade, viabilidade técnica, viabilidade de negócio). Além disso, o protótipo muitas vezes é suficiente como documentação primária (prototype as spec)

* p. 229 - Chapter 46 - Feasibility Prototype Technique
    Quando engenheiros estão trabalhando nos protótipos, é considerado Discovery Work, e não Delivery Work

* p. 319 - Chapter 66 - Top Reasons for Loss of Velocity
    1. Technical debt
    2. Lack of strong product managers
    3. Lack of delivery management
    4. Infrequent release cycles
    5. Lack of product vision and strategy
    6. Lack of co-located, durable product teams
    7. Not including engineers early enough during product discovery
    8. Not utilizing product design in discovery and instead having them try to do their work at the same time the engineers are trying to build
    9. Changing priorities
    10. A consensus culture