Como quase ter virado um Product Manager me fez ser um Product Designer melhor

Permitam-me começar esse texto com uma reflexão profunda, filosófica e, devo dizer, revolucionária. Preparados? Lá vai:

‍Desenvolver produtos é difícil pra caramba.

‍Vivemos em um mundo cheio de incertezas (o famoso mundo VUCA - se você não conhece o termo, dá uma olhada aqui). Nascemos, crescemos, estudamos e trabalhamos em uma sociedade que ainda está entendendo o impacto das novas tecnologias no seu dia a dia. Além disso, estamos em um país (ou seria em um planeta?) marcado pelas desigualdades: de recursos, de acesso, de educação, etc. A cereja dessa torta de climão? A pandemia que mudou drasticamente todos os planos que foram feitos ao pular as ondinhas no dia 1 de janeiro de 2020.

Nesse contexto, está o nosso famigerado produto digital. Uma solução tecnológica, desenvolvida por um time multidisciplinar, que busca resolver os problemas de uma pessoa em um contexto específico. Nesse time multidisciplinar estão designers, desenvolvedores, profissionais de marketing, vendas, atendimento e suporte, além de uma figura enigmática: o Product Manager - nosso querido PM.

Você pode estar se perguntando, "Por que enigmática, caro autor?". Ora, porque, na minha humilde opinião, ninguém tem certeza absoluta de quais são as atribuições de um Product Manager. De forma mais ou menos consensual, o mercado entende que o PM deve facilitar o desenvolvimento de produtos em uma empresa, conciliando os aspectos técnicos de implementação (a mão na massa) com a visão estratégica de negócio (o planejamento de médio e longo prazo) - esse vídeo do Nubank faz um resumo legal de como eles encaram essa posição.

Josh Anon e Carlos González de Villaumbrosia, do Product School, no livro "The Product Book" (que é de graça e pode ser baixado nesse link) dão exemplos mais práticos sobre as responsabilidades de um PM:

‍"No dia a dia, os PMs devem entender tanto a estratégia quanto a execução dos negócios. Eles devem primeiro descobrir quem são os clientes e quais os problemas que os clientes têm. Eles devem saber como definir uma visão, encontrando as oportunidades certas em um mar de possibilidades, usando dados e intuição. Eles devem saber como definir o sucesso, para o cliente e o produto, priorizando fazer o que é certo em vez de fazer o que é mais fácil. Eles devem saber como trabalhar com engenheiros e designers para obter o produto certo, mantendo-o o mais simples possível. Eles precisam saber como trabalhar com marketing para explicar ao cliente como o produto preenche melhor as necessidades do cliente do que o produto de um concorrente. Eles precisam fazer o 111. O Que é o Product Management que for necessário para ajudar a lançar o produto, encontrando soluções em vez de desculpas. Às vezes, isso significa até mesmo um PM indo buscar café para uma equipe, que está trabalhando longas horas, para demonstrar apreço."

‍No meio de tudo isso, cheguei em um momento da minha carreira, há 6 meses atrás, que, imagino, deve ter acontecido com muitos designers antes de mim: deveria eu virar um Product Manager?

‍Momento flashback - Seria eu um PM em pele de PD?

‍Para entender minha crise de identidade profissional, é necessário um pouco de contexto.

Trabalho no Reclame AQUI há 5 anos (sim, dá pra reclamar do Reclame AQUI no Reclame AQUI). Porém, na maior parte desse tempo atuei no time de marketing, fazendo minha transição para o time de produtos há 1 ano e meio.

Pouco depois da minha transição, um novo Product Manager entrou no Reclame AQUI e formamos um par dedicado a um dos produtos da empresa. Nesse período, minha experiência como veterano de RA aliada à experiência dele como veterano de mercado definiu nosso fluxo de trabalho. Por isso, muitas das nossas funções ficaram "misturadas". Costumávamos dizer que eu era um co-PM do produto.

Com a saída recente desse PM, um pensamento pairou na minha mente - seria o momento de assumir de vez a posição de Product Manager? Essa dúvida me assombrou por um tempo, deu alguma dor de cabeça e um pouco de insônia. No fim, decidi continuar sendo um designer, e agora, tal qual grandes nomes antes de mim, transformo minhas inseguranças em conteúdo para a internet.

‍O que aprendi sendo um co-PM?

‍Antes de mais nada, é importante ressaltar: não acredito que Product Managers e Product Designers façam "a mesma coisa". Tampouco defendo que um PD assuma as duas funções em um time.

A propósito, a própria posição de Product Designer já é, por si só, difícil de definir. Vou me apropriar da definição que usamos no Reclame AQUI para tentar dar algum contexto: Product Designer é um profissional que usa métodos e técnicas de design para propor soluções "produtizáveis" que resolvam problemas de pessoas. Ele acompanha todo o processo de pesquisa e descoberta, geração de hipóteses, prototipação, desenho de interface, aprovação e entrega da solução para o time de desenvolvimento.

Como falei lá em cima, é responsabilidade de um PM facilitar o desenvolvimento de produtos. Quando essa facilitação tem a ver com o design de produtos, ela não significa apenas "tirar as pedras do caminho" do designer. Eu acredito que os papéis de PMs e PDs se misturam naturalmente, como eu exemplifico nesse gráfico extremamente científico e preciso:

PMs e PDs tem responsabilidades complementares. Porém, enquanto muitas vezes os PDs mantém sua visão focada em aspectos tradicionalmente relacionados ao design de produtos, os PMs constróem uma visão holística de funcionamento, visão estratégica e posicionamento de negócios. E é aí que podemos aprender.

Mas como isso é um conteúdo para internet, nada melhor do que uma boa lista. Então vamos lá. Essas são as 3 coisas que aprendi sendo um co-PM:

‍1 - Aproximação com o dia a dia dos times

‍Atire a primeira pedra quem nunca pensou "não é possível que essa galera tava fazendo o trabalho desse jeito nesse tempo todo". Normalmente, você pensa isso em uma reunião de discovery ao perceber que seu time financeiro precisa baixar dados de um sistema, abrir esses dados no Excel, fazer uma fórmula complexa para no final conseguir te dizer quais empresas usam o plano gratuito do seu produto.

Esse exemplo pode parecer esdrúxulo, mas eu tenho certeza que alguém na sua empresa está suspirando de dor agora mesmo, ao fazer um trabalho manual que você poderia ter resolvido com um botão a mais em uma interface.

Um PM, por característica da função, está conversando constantemente com todas as áreas que permeiam o produto. Isso dá a ele uma visão ampla das necessidades de melhoria, tanto para seus stakeholders internos quanto para seus usuários.

Quando o PD também possui essa visão, começam a surgir novas oportunidades de entrega de valor. Essas oportunidades muitas vezes estão escondidas em processos nebulosos, em gambiarras bem intencionadas, em fluxos pouco inteligentes, mas que são feitos da mesma forma há tanto tempo, que ninguém mais se incomoda. A propósito, falando em entrega de valor...

‍2 - Entrega contínua de valor

‍Valor é um negócio difícil de definir, mas dá pra resumir de um jeito simplista: se seus stakeholders ficaram mais felizes depois da sua entrega, você entregou algo de valor. Essa entrega pode ser tão grande quanto um redesign completo de uma plataforma ou tão pequena quanto uma alteração de texto. Ela só tem uma regra - precisa ser constante.

Essa filosofia de entrega de valor é muito comum em metodologias ágeis. Espera-se que um time ágil tenha capacidade de iterar um produto em períodos curtos - as famosas sprints - e evoluir constantemente. Isso não é diferente da mentalidade que se espera de um designer. O que muda, geralmente, é o tempo.

Não é incomum ouvir designers reclamando de tempo. Sempre falta tempo para fazer uma última entrevista, para redesenhar um teste que não funcionou como se esperava, para aplicar uma dinâmica de cocriação com toda a equipe… E é verdade, sempre vai faltar tempo para tudo isso, porque essas atividades podem ser infinitas. A cada teste realizado, outras dúvidas e hipóteses surgirão, até que alguém decida parar de testar e focar em uma ideia.

Ter uma noção mais clara do que é valor para o seu produto ajuda a definir até onde você precisa explorar novas soluções e qual o fluxo de entrega ideal para contribuir com a evolução do trabalho do seu time.

‍3 - Design de produtos é design de sistemas

‍Vou admitir: sempre me sinto mais completo quando minha solução final de design é uma bela de uma interface. Sou designer gráfico de formação, adoro trabalhar com cores, formas, tipografias e, principalmente, sombras (tudo fica mais descolado com box shadow, quem discorda tá errado).

Entretanto, existem diversas oportunidades de melhoria de design indo além da interface. Seja em regras de negócio, em fluxos de captação e tratamento de dados ou até em tecnologias empregadas, todas as decisões "por trás dos panos" impactam diretamente a qualidade da experiência do usuário com um produto.

Como Product Designer, é importante conhecer essas decisões profundamente. Assim, você será capaz de ajudar a encontrar formas de evoluir esses sistemas ou identificar suas limitações para guiar o usuário no melhor fluxo o possível. No fim do dia, suas interfaces serão muito mais eficazes e seus box shadow poderão brilhar.

‍Conclusão: Afinal, quem faz o que?

‍Como dizia o sábio (no começo desse texto), desenvolver produtos é difícil pra caramba. Diferentes times têm diferentes contextos, e o que vale para mim muito possivelmente não fará o menor sentido para você.

Porém, acredito que uma coisa é certa. Todo time de produtos que se preze precisa construir uma visão holística de como gerar valor para todos os seus stakeholders: seus usuários, seus investidores e o próprio time.

De modo geral, o mercado atribui a responsabilidade de definir essa visão ao Product Manager. O que eu proponho é que nós, Product Designers, temos muito a aprender participando ativamente da definição dessa visão.