Product
Management
Fundamentos

Product management é resolver os problemas certos

Product management é a disciplina de identificar problemas que valem a pena resolver, definir soluções que criam valor para os utilizadores e para o negócio, e guiar equipas cross-functional para entregar e melhorar essas soluções ao longo do tempo.

A palavra-chave é problemas. Os PMs não são fábricas de funcionalidades. O seu trabalho não é construir tudo o que os stakeholders pedem. É perceber o que os utilizadores de facto precisam, determinar quais dessas necessidades são também comercialmente viáveis, e garantir que a equipa constrói as coisas certas pela ordem certa.

A sobreposição entre estes dois é onde vivem os bons produtos. Uma funcionalidade que os utilizadores adoram mas que não serve o negócio é um hobby. Uma funcionalidade que serve o negócio mas que os utilizadores não querem é shelfware. O product management é a prática de encontrar e construir nessa interseção.

O que os product managers fazem mesmo o dia todo

Os PMs ficam na interseção entre negócio, tecnologia e experiência do utilizador. O seu trabalho abrange quatro grandes áreas, não fases sequenciais, mas responsabilidades contínuas e em paralelo:

Repara no que não está nesta lista: os PMs não escrevem código, não desenham a UI, e não gerem o trabalho diário dos engenheiros. Lideram por influência e contexto, não por autoridade. É por isso que a comunicação, o pensamento analítico e a gestão de stakeholders são as skills de PM mais críticas, não a execução técnica.

PM vs PO vs BA vs Project Manager

Estes quatro papéis são comummente confundidos, sobretudo em organizações mais pequenas onde uma pessoa veste muitas vezes vários chapéus. Mas têm responsabilidades distintas, e perceber as diferenças importa quando se contrata, se constroem equipas, ou se posiciona a si próprio.

O ciclo de vida do produto: cinco fases

Os produtos não surgem totalmente formados. Avançam por um ciclo repetível, de perceber um problema até lançar e aprender com o uso real. Bons PMs estão sempre a correr várias fases em paralelo, em diferentes funcionalidades e apostas.

A isto chama-se por vezes o Double Diamond (divergir em problemas, convergir em soluções, divergir em possibilidades, convergir no que se entrega) ou o loop Build-Measure-Learn do Lean Startup. Os nomes diferem; a lógica é a mesma: não construir sem compreender, não lançar sem medir, não medir sem agir sobre os dados.

Encontrar o problema real

O erro mais caro em product management é construir bem a coisa errada. A discovery existe para o evitar. Não é uma fase pontual. É uma disciplina contínua de chegar suficientemente perto dos utilizadores para perceberes o que está mesmo a partir-se na vida deles, não apenas o que dizem que querem.

Três ferramentas conduzem a maior parte do trabalho de discovery:

Um bom problem statement é específico: “Os utilizadores que tentam concluir o X no contexto Y estão a abandonar no passo Z porque não conseguem fazer W.” Este nível de precisão deixa claro o que uma solução precisa de endereçar, e dá-te uma métrica para acompanhar a melhoria.

Decidir o que se constrói primeiro

Todos os backlogs têm mais boas ideias do que a equipa consegue construir. A priorização é a decisão mais visível e mais contestada do PM, e precisa de ser defensável. Os melhores PMs usam frameworks para tornar a lógica transparente, não para substituir o julgamento por uma fórmula.

Três frameworks cobrem a maioria das situações:

Com quem os PMs trabalham, e como

Os PMs são o tecido conjuntivo de uma organização de produto. Não têm reportes diretos, mas dependem, e dependem deles, quase todas as funções da empresa. A capacidade de trabalhar eficazmente ao longo destas relações é o que separa os PMs medianos dos excelentes.

Métricas que de facto te dizem alguma coisa

Uma das skills de PM mais críticas é definir como é o sucesso antes de lançar, não andar à pressa atrás de métricas que pareçam boas depois. As métricas devem ser escolhidas por estarem causalmente ligadas ao outcome que te importa, não por serem fáceis de medir.

Uma armadilha a evitar: métricas de vaidade. Total de utilizadores registados, downloads da app e page views ficam bem num deck mas não te dizem se o produto está de facto a funcionar. Foca-te em métricas que mudam quando o comportamento do utilizador muda, não nas que só sobem porque o tempo passa.

O perfil em T que torna os PMs eficazes

Product management é um dos poucos papéis que recompensa um background genuinamente abrangente. Os PMs mais eficazes são em forma de T: expertise profunda num ou dois domínios (analytics, design, engenharia, finanças) combinada com fluência ampla em muitos outros.

É isto que torna o papel acessível a pessoas com percursos não tradicionais. Um designer que percebe de dados, um business analyst que pensa em sistemas, um analista financeiro que sabe falar com utilizadores: todos estes perfis podem dar PMs excecionais. O fio comum não é um grau ou um título; é a capacidade de manter em mente, em simultâneo, o contexto de negócio, a empatia com o utilizador e a restrição técnica, e de tomar decisões sob incerteza.

Os frameworks deste guia (RICE, MoSCoW, OKRs, AARRR) são ferramentas, não regras. Tornam o teu pensamento explícito e as tuas decisões defensáveis. Mas o trabalho de fundo continua a ser julgamento: saber qual o problema que mais importa, quando os dados são bons o suficiente para agir, e quando contestar um pedido de um stakeholder que desviaria a equipa do que realmente importa.