Anotações sobre o livro "The Build Trap" de Melissa Perri

No livro “The Build Trap” a autora e gestora de produto (product manager) Melissa Perri apresenta a diferença entre output e outcome (em tradução livre: produção vs resultado).

Não é o bastante que uma organização seja eficiente em produzir novas funcionalidades para seus produtos (produção). Mais do que isso, essas funcionalidades devem necessariamente gerar valor (resultado) para o negócio e para o cliente.

É uma outra forma de trazer a diferença clássica entre eficiência e eficácia.

Além disso, a autora toca em um assunto de meu interesse: a interseção entre os papéis de Product Manager e UX Designer. Ela mostra que de fato há responsabilidades compartilhadas, o que absolutamente não impede que duas pessoas nesses dois diferentes papéis colaborem.

Outros assuntos abordados:

• Diferença entre Product Manager e Project Manager
• Organizações “orientadas a produto” versus “orientadas a vendas, visionários ou tecnologias”
• Diferença entre Product Manager e Product Owner
• Carreira típica de Product Manager: Associate product manager; Product manager; Senior product manager; Director of product; VP of product; Chief product officer (CPO)

Compartilho abaixo algumas anotações sobre esses tópicos.

Título: The Build Trap
Autora: Melissa Perri

---

Índice:

p. 1 a 5 - Depoimentos
p. 8 - Prefácio
p. 13 - Acknowledgments
p. 14 - Part I. The Build Trap
p. 37 - Part II. The Role of The Product Manager
p. 76 - Part III. Strategy
p. 115 - Part IV. Product Management Process
p. 172 - Part V. The Product-Led Organization
p. 199 - Afterword

---

Conteúdo principal: p. 14 a 198 (185 páginas)
    I. The Build Trap: 23 (12%)
    II. The Role of The Product Manager: 39 (21%)
    III. Strategy: 39 (21%)
    IV. Product Management Process: 57 (31%)
    V. The Product-Led Organization: 27 (15%)

---

Anotações

p. 14 - Part I. The Build Trap

"Build trap" é a situação em que organizações medem outputs em vez de outcomes

Anedota sobre consultoria na empresa Marquetly, que tinha vários problemas, incluindo migração de pessoas do Marketing para Produto para trabalhar com times de Scrum
    VP product com muita pressão, sem tempo pra ser estratégico
    Head of sales iludindo clientes
    Fogo cruzado

p. 21

Lembrou da histórida da Kodak que falhou em enxergar o que valor significa

Microsoft conseguiu se reinventar com CEO Satya Nadella

p. 22

Visão geral sobre o resto do livro: começa com o papel do PM. Depois, como a estratégia suporta o papel do PM e como os times de produto devem trabalhar para alcançar a estratégia. E por último, como a organização consegue definir políticas, cultura e sistemas de recompensa para fazer tudo funcionar

p. 23 - Chapter 1. The Value Exchange System

Output vs outcome
Valor para negócio: dinheiro, dados, informação, promoção
Valor para cliente/usuário: difícil de medir

Devido a essa dificuldade em medir valor para o usuário, empresas acabam desviando para uma métrica mais fácil de medir: quantidade de features

"The Value Exchange System": figura que mostra a troca de valor entre Customers (influenciados por Community, Technology e Market) e Businesses (age via Process, Strategy, Policies, Individuals, Culture, Incentives, Structure)

p. 27 - Chapter 2. Constraints on the Value Exchange System

Comenta um pouco mais sobre a figura descrita anteriormente

p. 29 - Chapter 3. Projects Versus Products Versus Services

Não confundir os frameworks a seguir (de projetos!) com frameworks de produtos: PRINCE2, Project Management Institue, PMBOK

Produtos são veículos de valor. Entregam valor continuamente para o cliente

Serviços utilizam mão de obra humana para entregar valor

Muitas empresas combinam produtos + serviços

Projeto é um escopo de trabalho bem definido. Normalmente tem um prazo, milestones, e outputs a serem entregues

Projetos são parte essencial de desenvolvimento de produto, mas focar exclusivamente em projetos é danoso

Produto é algo que necessita de tempo pra ser cultivado e crescer. Entregas de features são projetos, mas o produto precisa ser iterado com novos projetos

Product-led organizations: foco em alcançar valor com o produto 

p. 31 - Chapter 4. The Product-Led Organization

Alternativas a product-led: orientadas a vendas, visionários ou tecnologia. Essas alternativas podem resultar no "build trap"

Sales-led: vender features e implementar tudo que algum cliente deseja, sem uma estratégia clara

Visionary-led: Apple e Steve Jobs. Quando se perde o visionário, a direção do produto se perde

Technology-led: sempre utilizando a última e mais maneira tecnologia para guiar o produto

p. 34 - Chapter 5. What We Know and What We Don't

Known x Unknown: Facts, Questions, Intuition, Discovery

Product management é o domínio de reconhecimento e investigação dos "known unknowns" e de redução dos "unknown unknowns"

p. 37 - Part II. The Role of the Product Manager

PM é uma carreira; não apenas um papel em um time

Entende o negócio e o cliente para identificar oportunidades de produzir valor

Sintetiza dados de múltiplas fontes e determina a direção que o time deve seguir

PM mantém o time focado no "por que?" de estarem construindo algo

No primeiro trabalho da autora, aprendeu que PM tem o papel de criador e árbitro; conectava os times de desenvolvimento com o negócio, levantando requisitos e traduzindo isso para features. Anos depois, descobriu que PM e UX design não são a mesma disciplina

Hoje, percebe que um bom PM deve fazer o meio de campo com negócio, tecnologia e design e colher o conhecimento coletivo

p. 41 - Chapter 6. Bad Product Manger Archetypes

Não são comuns programas institucionalizados de carreira em PM

O que deve ser ensinado para PMs:
* Documentar requisitos
* Planejar reuniões com desenvolvedores
* Reuniões de atualização
* Coletar solicitações do time de negócio
* Testar a aceitação do trabalho desenvolvido

Para quem aprendeu com Waterfall, o aprendizado costuma ser diferente

Ágil não é bala de prata. No Ágil, é assumido que o time já recebe ideias validadas. Entretanto, em muitas empresas essa função se perde

PMs costumam ser avaliados (erroneamente) pelas especificações bem detalhadas e por cumprir o cronograma

PMs se definem de diversas maneiras diferentes:
* São os que têm a ideia do que construir
* São a voz do cliente
* São o CEO do produto

p. 44 - Arquetipos errados

The Mini-CEO: não é verdade que PMs são mini-CEOs, pois não são gerentes de pessoas no nível do time e não possuem o poder do CEO. Precisam influenciar o time

The Waiter: é o garçom, que obtém com os stakeholders tudo que eles querem, sem objetivos, sem visão, sem tomada de decisão 

The Former Project Manager: Product managers não são project managers. Project managers respondem o "quando?". Product managers respondem o "por que?". Muitas empresas ainda confundem os dois papéis. Metodologias ágeis diluíram o papel do project manager no restante do time

p. 48 - Chapter 7. A Great Product Manager

Papel: trabalhar com um time para criar o produto correto que equilibra necessidades do negócio e resolve problemas do usuário

Precisam entender de verdade a visão e o objetivo da organização

Empatia profunda com os usuários

Não é um papel de autoridade direta

PM é responsável pelo "por que?", e o time como um todo é responsável pelo "o que?"

p. 51 - Diferença entre UX design e product management?

Há certa interseção entre as 2 disciplinas (design)

PM é sobre olhar o sistema como um todo - requisitos, features, proposta de valor, UX, modelo de negócio, precificação e integração

Grande erro: contratar um especialista de mercado ou técnico. PMs não são especialistas nessas 2 áreas, e sim em PM. PM deve equilibrar entre todas as disciplinas, conseguir se comunicar com todas as áreas

p. 55 - Foco no "Why?"

Em muitas organizações, PMs não têm a oportunidade de questionar "por que?", e simplesmente recebem features e soluções dos stakeholders ou gerentes

Crítica recorrente de líderes: PMs deveriam assumir mais o papel de "ser dono do produto"

Confusão entre Product Owner vs Product Manager

Product Owner:
* Definir product backlog e criação de user stories prontas para serem trabalhadas pelo time de desenvolvimento
* Refinar e priorizar o trabalho no backlog
* Aceitar as user stories finalizadas e garantir que cumprem os critérios de aceitação

Mas os questionamentos abaixo não ficam atribuídos ao Owner, sendo assim acabam restando para o Product Manager:
* Como determinar valor?
* Como medir o sucesso do produto no mercado?
* Como ter certeza que estamos construíndo a coisa certa?
* Como precificar nosso produto?
* Como trazer nosso produto para o mercado?
* O que vale a pena construir em vez de comprar?
* Como integrar com software de terceiros para entrar em novos mercados?

PO é um papel do scrum; PM é uma carreira

p. 58 - Importância do PM

Frequentemente, organizações não sabem o que o PM faz ou por que são importantes

Organizações dizem que não precisam de PMs, já que o CEO decide tudo

Acredita que SAFe (Scaled Agile Framework) tem o ponto fraco quanto a liderar POs. POs são internos, e PMs trazem os requisitos para os POs

Nunca viu o SAFe funcionar bem

p. 60 - Discovery Mode

Se você entregar a um PM um backlog grande (do Scrum, por exemplo) para gerenciar ao mesmo tempo em que está em Discovery Mode (modo de descoberta), haverá um conflito entre fluir trabalho para os desenvolvedores e validar que o trabalho está na direção correta. Nenhum dos dois acaba bem

p. 60 - Chapter 8. The Product Manager Career Path

Tactical work: foco na construção de features de curto prazo; atividades diárias

Strategic work: posicionar o produto e a organização no mercado e obter resultados

Operational work: juntar a estratégia com o trabalho tático

Carreira típica:
1) Associate product manager (algumas empresas podem chamar de Product owner)
2) Product manager
3) Senior product manager
4) Director of product
5) VP of product
6) Chief product officer (CPO)

Associate product Manager: posição de entrada; necessário parear com seniores

Product Manager: foco no curto-prazo (trimestre); faz parte de um time maior de produto

Senior Product Manager: mesmas responsabilidades anteriores, mas com um escopo maior, ou produto mais complexo. É a posição mais alta da carreira que não gerencia pessoas. Papel similar ao do Arquiteto de desenvolvimento

Director of Product: encontrado em empresas maiores, quando muitas pessoas reportam para o Head of Product; promove alinhamento estratégico e eficiência operacional; foco no médio-prazo (1 ano) 

VP of Product: em empresas menores há um único, já que há 1 único produto. Para sucesso, precisa ser uma pessoa fundamentalmente mais estratégica, que contrata pessoas para assumir o lado tático e operacional

Chief Product Officer: posição relativamente nova; supervisiona todos os produtos da organização; posição útil a partir da criação do 2º produto da organização