O MVPM: Gerente de Produto Mínimo Viável

Gerente de Produto Mínimo Viavel

Um dia me perguntaram qual o Gerente de Produto Mínimo Viável (MVPM). A primeira coisa que fiz foi mostrar o diagrama de Venn abaixo. Ele mostra que o gerenciamento de produtos é uma interseção de um conjunto de habilidade de 3 grandes áreas: negocios, tecnologia e design.

Sua simplicidade o tornou uma das imagens mais icônicas a respeito da profissão e ajudou a evoluir muito a disciplina. (Como nota pessoal: foi quando eu notei que apesar de ter interesses tão distintos, o cargo de gerente de produto era o que tinha nascido para fazer).

Mas não se engane, você pode ter todo tempo do mundo, que ainda assim não vai conseguir entender tudo que existe dentro dessas 3 areas. O que é mais útil é entender o que existe dentro da interseção:

  • Essa interseção é o que chamamos de Gerente Mínimo de Produto Viável (MVPM), e define um conjunto de habilidades ou conhecimentos que são úteis para ser um gerente generalista de produtos eficaz, alguém que pode trabalhar em praticamente qualquer problema.

O MVPM: Gerente de Produto Mínimo Viável

• Tecnologia

Tecnologia

1. A Stack

Quando os engenheiros se referem à “Stack”, eles estão falando sobre as camadas de tecnologias usadas para fornecer funcionalidade ao seu produto. Desde o momento em que um cliente acessa sua aplicação, até quando exclui sua conta.

  • Maneira mais rápida de aprender peça a um engenheiro para guiá-lo pela “Stack” em alto nivel. Anote os nomes de cada tecnologia e entenda os benefícios de cada tecnologia escolhida e sua relação com as demais
  • Como isso te torna um PM melhor? – Quando os engenheiros estão discutindo como construir algo, eles utilizam diversas tecnologias. Conhecer a Stack significa que você pode pelo menos acompanhar e, com o tempo, começará a entender a que profundidade da pilha está se referindo. Geralmente, quanto mais camadas na pilha elas precisarem tocar, ou quanto mais profunda a camada, mais complicada e arriscada será a alteração.

2. Arquitetura do Sistema

Se a Stack representa quais tecnologias estão sendo usadas, a arquitetura do sistema representa como essas tecnologias estão estruturadas para trabalharem juntas para entregar o produto. Enquanto a Stack é principalmente sobre capacidade técnica bruta, a arquitetura de um produto incorpora o comportamento pretendido do cliente em seu design.

  • Maneira mais rápida de aprender peça a um engenheiro para desenhar a arquitetura e orientá-lo sobre o que cada componente do sistema faz. Alguns lidam com solicitações da Internet, alguns abrigam a ‘lógica de negócios’, outros ainda mantêm os dados que são salvos.
  • Como isso faz de você um PM melhor? Quando você entende a arquitetura, você começa a pensar no seu produto como um sistema, que geralmente é como os engenheiros também. Compreender como cada componente do sistema contribui para o todo ajuda a tomar melhores decisões e compensações. Geralmente, os componentes no sistema que têm mais conexões são os mais complicados de alterar, porque muitos outros dependem deles para dados ou funcionalidade.

Em empresas maiores, o número de componentes é sinônimo do número de equipes / grupos com os quais você precisa interagir e mais alinhamento você precisará obter para executar um projeto.

3. O Modelo de Dados e suas APIs

Um modelo de dados organiza as informações usadas pelo seu produto e padroniza como as partes dessas informações se relacionam. Por exemplo, por “informações”, estamos falando de coisas como usuários, produtos e cartões de crédito, que coletivamente são chamados de entidades. Essas entidades podem se relacionar de determinadas maneiras: um usuário pode ter muitos produtos, mas apenas um cartão de crédito.

O modelo de dados está intimamente relacionado à arquitetura do sistema em que determinadas entidades ‘vivem’ em determinados componentes. Por exemplo: o modelo de usuários pode residir no componente A e os dados dos produtos, mas, devido à sua sensibilidade, os cartões de crédito residem no componente B. S

Se a sua nova feature precisar exibir quais usuários possuem um produto em uma lista, isso é bastante fácil, pois eles residem no o mesmo componente. Mas se você precisar saber qual desses usuários possui um cartão de crédito armazenado, o componente A precisará de uma conexão com o componente B para compartilhar os dados. Isso é mais difícil e, para isso, eles precisam de uma API (interface de programação de aplicativos).

As APIs são construídas sobre o modelo de dados e representam como os dois componentes se comunicam e trocam informações sobre seus modelos subjacentes. Importante, as APIs também permitem conversar com componentes externos

Por exemplo, quando você chama um Uber a partir de mapas do Google, o aplicativo Google Maps está conversando com um componente do Uber. A maioria dos aplicativos possui APIs públicas e privadas, que podem ser usadas por qualquer pessoa na Internet ou apenas por quem você especificar.

  • Maneira mais rápida de aprender – você deve se concentrar primeiro em entender suas APIs públicas. A vantagem de estudar suas APIs é que elas geralmente representam a maior parte do seu modelo de dados subjacente, então será fácil entender-las.
  • Como isso faz de você um PM melhor?  Conhecer seu modelo de dados expande sua capacidade de saber quais informações você pode utilizar para criar produtos melhores e quão difícil pode ser acessar essas informações. Conhecer suas APIs significa que você entende quais tipos de parceiros de informações e desenvolvedores de terceiros podem obter do seu aplicativo e, portanto, que tipos de integrações são possíveis.

Onde não deve se concentrar – Programação

A menos que seja um produto altamente técnico, você não precisa saber programar para ser um PM eficaz. Se você estiver programando, pode precisar se perguntar se está realmente fazendo um trabalho de alta alavancagem ou se não tem certeza do que mais deveria estar fazendo. Dito isto, acho que é uma experiência muito interessante ter construído pelo menos um aplicativo.


• Negocio

Negócios

1. Gerenciamento de Projetos

Para ser um bom gerente de produtos, você PRECISA ser um bom gerente de projetos! (Não tem como fugir)

  • Maneira mais rápida de aprender. Para ser um gerente de projeto eficaz, é preciso muita experiência e tempo. Você pode ler tudo o que quiser, mas no final do dia é um problema de comportamento humano. Leva tempo para aprender sobre o espectro de personalidades com as quais você acabará trabalhando, e qualquer conselho que você encontrará sobre como abordá-lo também é subjetivo à sua personalidade.
  • Como isso faz de você um PM melhor? – Você fará mais coisas com sua equipe e as pessoas gostarão de trabalhar com você, porque todo mundo odeia um projeto mal gerenciado.

Dito isto, existem algumas coisas específicas em que você pode investir para acelerar sua curva de aprendizado:

  1. Entenda o básico do desenvolvimento de produtos. Para que você possa criar empatia com o time de desenvolvimento. Aprenda sobre controle de versão (Git), programação colaborativa (GitHub), processos de garantia de qualidade e em alto nível como e quando o código é implantado para os usuários do seu produto.
  2. Aprenda como funcionam as principais metodologias de desenvolvimento. Você encontrará coisas como ágil, scrum e kanban. É importante aprender as filosofias por trás de suas abordagens, independentemente de sua empresa as usar ou não.
  3. Entenda a tomada de decisões em sua empresa e mapeie seus stakeholders. Geralmente, esses são seus clientes, seu chefe, chefes dos membros de sua equipe e outros diretores executivos. Encontre uma maneira de garantir que todos estejam cientes do status e da direção em que um projeto está indo em um nível contextual ao que eles se importam (você precisará descobrir isso também).

2. Impacto da modelagem

As coisas que não são medidas raramente são bem-sucedidas. Todo produto deve ter objetivos quantitativos associados ao seu sucesso final, itens básicos como crescimento do usuário, adoção de features, receita etc. Quando sua equipe estiver debatendo a coisa demaior impacto para priorizar, é importante que você possa desenvolver um modelo de como o produto vai ter impacto em cada métrica.

  • Maneira mais rápida de aprender –  Crie uma planilha que mostra (1) crescimento do produto – numero de novos usuarios, nova aquisições, etc. Utilize um cohort para acompanhar essas métricas. (2) aumento dos gastos durante o tempo – CAC, custo operacional, custo de servidor, etc.
  • Como isso faz de você um PM melhor? – O exercício de construir um modelo para o seu produto é uma ótima maneira de testar suas suposições instintivas e garantir que seu produto tenha potencial suficiente para valer a pena. Também facilita o seu trabalho; permitindo que você justifique os projetos de maneira que se relacione com seus stakeholders e facilite a comparação do custo de oportunidade com outros projetos que você poderia estar realizando.

3. Reunir e analisar dados

Ser capaz de coletar dados de forma independente é vital paratomar decisões rápidas. Contar com outra pessoa para obter dados para você não é apenas um uso ineficiente do tempo deles, leva a poucos insights (os dados já chegaram a você filtrados) e reduz sua capacidade de tomar decisões (você precisa de dados o tempo todo, e ficar esperando por eles é ineficiente).

  • Maneira mais rápida de aprender – Você pode aprender algumas consultoras SQL básicas ou usar alguma ferramenta para isso, como o Mixpanel e Amplitude.
  • Como isso faz de você um PM melhor?  Quando os dados estiverem facilmente acessíveis e você souber utiliza-los, você os vai utilizar esses dados para embasar todas as suas decisões. (confie em mim, ninguém nuca mais vai duvidar de uma decisão sua).

Onde não deve se concentrar – Planos de negocios

Não perca seu tempo fazendo casos de negócios estratégicos, planos de três anos e outros artefatos de MBA. Não vou ao ponto de chamar isso de besteira, mas não é o caminho para ter sucesso em software. Entenda a visão, encontre um problema que valha a pena resolve-lo, crie uma hipótese para resolve-la e valide-a o mais rápido possível com clientes reais.


• Design / Experiência do usuário

Design

1. Conheça os padrões de design do seu produto

A maioria dos produtos desenvolve padrões de design ao longo do tempo, planejados ou não. Padrões são o uso consistente dos mesmos componentes visuais e interativos em seu produto. Por exemplo, tamanho dos botões, cores principais para utilizar.

Conhecer os padrões do seu produto é fundamental para entender como os usuários mapeiam o produto em suas mentes e como eles podem receber efetivamente novas features ao longo do tempo. 

À medida que o produto cresce, o uso consistente de padrões se torna ainda mais importante, pois permite que as equipes trabalhem independentemente umas das outras, mas ainda criam um produto que parece coeso.

Os padrões de design também costumam ser desenvolvidos em harmonia com os padrões técnicos, como guias e componentes de estilo, que são basicamente bibliotecas de códigos reutilizáveis ​​que aceleram as equipes porque elas não precisam redesenhar ou reimplementar a mesma funcionalidade novamente.

  • Maneira mais rápida de aprender converse com seu designer, ele deve conhecer esses padrões com clareza e capaz de fornecer links para um “guia de estilo. Além disso, converse com seus engenheiros de front-end, pois eles podem fornecer links equivalentes para uma “biblioteca de padrões”.
  • Como isso faz de você um PM melhor? – Projetar produtos com padrão é muito mais fácil e rápido. Eles permitem que você se apoie nas decisões de design que sua equipe tomou no passado, decisões que resultam em um produto mais fácil para os clientes usarem. 

2. Saiba como executar pesquisa de experiência do usuário

Os PMs é a voz do cliente – se você não entende seus usuários, nunca criará ótimos produtos. Desde entrevistar uma única pessoa pessoalmente, até analisar quantitativamente milhões de ações do usuário, é essencial entender o básico de uma boa pesquisa para o seu trabalho.

  • Maneira mais rápida de aprender – A pesquisa eficaz é um campo muito grande; por isso recomendo que consiga: (1) entender o tamanho da amostra e calcular a significância estatística, (2) como normalizar uma amostra, (3)fazer perguntas imparciais em pesquisas e entrevistas, (4) sintetizar resultados.
  • Como isso faz de você um PM melhor? – Ao testar seu produto de forma consistente e frequente com os clientes, você pode tirar muitas das suposições (e riscos) no desenvolvimento de produtos. 
    • Antes do projeto começar: você deve testar se o problema que você está tentando resolver é realmente um. 
    • Enquanto estiver projetando e construindo: você deve testar se o design do produto é fácil de usar e provavelmente resolverá o problema do cliente. 
    • Após o lançamento: ocê deve confirmar que o problema foi resolvido para os clientes para os quais você queria resolvê-lo.

3. Saiba como prototipar suas idéias

Prototipar nesse contexto significa ser capaz de criar modelos visuais que podem efetivamente expressar suas idéias. Eles precisam ser bons o suficiente para que você possa comunicar claramente um conceito de produto Um protótipo, algo que as pessoas podem ver e de preferência interagir é 10x mais eficaz do que a voz ou texto.

  • A maneira mais rápida de aprender – aprenda a utilizar alguma ferramenta de prototipação e interação, coo o Sketch ou o Figma.
  • Como isso faz de você um PM melhor? – Ao prototipar e mostrar às pessoas o que você pensa, assumindo que elas entendem, você obterá um feedback melhor da sua equipe sobre suas idéias e reduzirá o risco de que a falta de comunicação leve ao desperdício de esforços.

Onde não deve se concentrar – Ser um designer UI

Sua capacidade de criar uma interface elegante é redundante e desestimulador para alguém que passou uma carreira aprendendo o ofício do design de produto. A menos que você seja experiente em design (para deixar claro que existem alguns), e nesse caso você pode contribuir, usar seu tempo para criar as telas do produto é uma perda de tempo.