Chuva de feedbacks, ideias e reclamações na mesa da product manager.

Como o PM se mantem firme em meio ao caos?

calmclinic.com — haha

Você está lá na sua mesa, trabalhando bem tranquila. O seu roadmap foi bem embasado, bem comunicado, e está sendo bem executado. Os product discoveries foram consistentes, e as priorizações foram feitas com ciência.

Aí chega alguém do suporte no Slack e fala que estão tendo muitos chamados porque "o produto está com bug" e as pessoas não sabem como fazer X.

E também o pessoal de Customer Success chega na sua mesa e diz que estão tendo churn porque falta a funcionalidade Y.

Nesse meio tempo, um cliente mandou um e-mail dizendo que é inaceitável ter que fazer Z manualmente porque o produto não tem isso de forma automatizada.

Para finalizar, Marketing fala que agora o concorrente tem essa nova funcionalidade maravilhosa e isso é um risco para a retenção dos nossos clientes.

(Para que fique claro: todos com suas razões).

Naturalmente, aquele suor começa a querer escorrer pela testa, e a resposta automática que alguns de nós no papel de gerentes de produto é querer desesperadamente sair resolvendo tudo para todos, questionar tudo o que vinha sendo feito e, em último caso, ficar um pouco desesperado.

No entanto, sabemos que pânico e mudança de rumo a cada nova demanda que surge são dois péssimos caminhos a seguir. Principalmente se as afirmações do primeiro parágrafo forem verdade, e você tiver caprichado no seu trabalho como PM.

Então, seja para dar uma resposta bem embasada para essas pessoas, ou para acalmar a sua mente para não cair nessa armadilha, separei algumas dicas para manter a calma quando começa a popular chuva de demandas e sugestões. E, a gente sabe, ela acontece semanalmente.

1- Separar bug de sugestão de melhoria

Muitas vezes essas duas coisas chegam misturadas para a pessoa de produto. É o clássico "está com bug, os clientes não conseguem…", quando na verdade, muitas vezes, nunca foi algo previsto para acontecer daquela forma.

Uma coisa é algo que deveria estar fazendo A estar fazendo B. Ou então, deveria fazer A, e está fazendo A, mas fazendo A acaba causando uma sobrecarga no produto e gera instabilidade, por exemplo. Isso é bug/issue, ou seja, não é algo que se coloque em roadmap. Ele deve ser priorizado pela PM de acordo com a sua gravidade e então encaixado em meio as entregas. Muitos times inclusive trabalham em um modelo de porcentagens dentro de suas sprints, com um percentual do tempo/time dedicado apenas para isso.

Outra coisa é algo que deveria estar fazendo A estar fazendo A, mas se fizesse B seria bem melhor pro usuário! Nesse caso, é algo que o PM deve inserir em seu backlog, e considerar em seus discoveries, priorizações, roadmaps e afins.

Separar isso é importante justamente para ter essa clareza de decisão: devo furar o roadmap atual e encaixar isso porque está tendo consequências graves para os usuários (bug), ou devo ponderar isso na minha priorização e próximos ajustes de roadmap (sugestão de melhoria)? Esse segundo caso precisa entrar junto com todo o resto no equilíbrio da priorização: é extremamente injusto com o nosso produto priorizarmos uma melhoria só porque veio disfarçada de bug.

2- Cuidar com o viés do que é mais recente

Isso já aconteceu várias vezes comigo: ninguém nunca tinha falado muito de algo, e do nada começa a aparecer como se fosse a coisa mais urgente do universo. (Por vezes, até some rapidamente de forma inexplicável depois).

A dica é olhar para o histórico do seu trabalho com produto e para o cenário macro e, mais uma vez, encaixar a nova hipótese junto com tudo o que você já vem estudando.

Às vezes tendemos a dar mais relevância para algo que começou a surgir mais forte agora (a famosa gritaria), mas se pensamos de forma macro, geralmente é fácil vermos que não há razão nenhuma para aquilo ganhar mais importância do que tudo que vinha sendo priorizado até então, assim, "do nada".

Cair nesse viés traz vários problemas: (1) ser aquele PM que muda de rumo o tempo todo, (2) priorizar por razões erradas — ou seja, na base de quem grita mais alto ou "para resolver o problema da vez" e (3) priorizar potencialmente as coisas erradas, porque não necessariamente o que vem mais forte agora é mais importante do que algo que vem aparecendo com consistência há anos. Até pode ser que sim, mas isso deve ser identificado de forma consciente, e não priorizado pela pressão de que "agora todo mundo está falando disso, então preciso resolver".

3- Contar com os dados

Quando chega esse furacão de "todo mundo pedindo tudo", os dados ajudam muito. Você pode, por exemplo, verificar quantos usuários da sua base de 35.000 usam aquela funcionalidade que alguns clientes estão pedindo enfaticamente para ser melhor. Se você descobrir que 97 usuários usam mensalmente ela, você já tem uma ajuda para entender como encarar essa demanda. (E, até, a repensar a existência dessa feature, mas isso é assunto pra outro post). Ou então, se vem o relato de que "às vezes é meio lento para fazer X", o que é "às vezes"? O que é "lento"? Outros dados que ajudam na tomada de decisão.

Sim, todos sabemos que o quanti não substitui o quali, mas já é um bom pré-filtro da situação, e nos ajuda a ter um cheiro sobre o que vale uma investigação mais profunda, e o que é um problema que afeta uma parte muito pequena da base, por exemplo, e não deve ganhar relevância nesse momento.

Isso tanto acalma o nosso coração, como ajuda a comunicar às pessoas que trazem essa demanda a razão pela qual não pararemos tudo agora para fazer ela, se essa for a conclusão.

4- Aliás, peça isso também de quem trouxe a demanda

Quando começar a vir aquela montanha de "precisa ver isso daí", conte com as pessoas que estão trazendo esses pontos até você para traçar um diagnóstico um pouco mais concreto. Peça números e mais detalhes. Pergunte quantos usuários falaram disso. Ou quantos chamados estão caindo diariamente sobre o assunto. Ou quais as consequências disso para o cliente. Qual o tamanho dos clientes impactados.

Peça, também, evidências quando achar necessário. Tem um print? Quando foi que aconteceu? Qual foi o cliente? Posso trocar uma ideia com ele? Não por você desconfiar de que seja verdade, mas às vezes pode ser que um "problema" era, na verdade, instabilidade na internet do usuário. Ou a pessoa que recebeu um feedback ficou um pouco nervosa pela forma com que o cliente o passou, e repassou internamente como se fosse o fim do mundo, mas na realidade, juntos, vocês percebem que não era.

Entender o cenário melhor te ajuda a perceber o que quer que seja que está vindo de uma forma mais realista frente a todo o seu planejamento de produto.

5- Conte com várias fontes de informação diferentes

Como PM, eu sempre gosto de montar o quebra-cabeça da forma mais completa possível. Coleto a visão dos clientes, do time de suporte, de marketing, atendimento, vendas, operações, etc. Por si só isso já traz um grande valor, e na verdade é como eu acredito que um bom trabalho de produto é feito.

No entanto, também ajuda bastante a manter a cabeça no lugar quando vem o turbilhão de pedidos: sem isso, você pode acabar simplesmente aceitando como verdades (e urgências) as demandas que chegam de focos muito específicos, por não ter uma base sólida do todo. Ao ter essa visão completa da figura, conseguimos ponderar melhor as coisas. Exemplo: cinco áreas da empresa estarem sendo afetadas por uma fraqueza do produto pode dizer mais do que apenas uma área estar sendo afetada por outra. Ou, ainda, os seus clientes estarem sofrendo por X é diferente da operação da sua empresa estar sofrendo por Z.

6- Foco no objetivo macro

Como sugiro nesse post, todo o trabalho de product discovery deve partir dos objetivos macro da empresa. E, na situação que descrevo aqui, isso também ajuda muito.

É simples: como produto, não devemos remar para uma direção diferente daquela que norteia toda a companhia. Nessa, metade das coisas que chovem na nossa mesa já automaticamente se ajeitam bonitinhas lá no backlog sem termos que pensar muito. Por mais que surjam milhares de demandas, e elas vão surgir, lembre do compromisso maior que temos junto com a nossa empresa.

Isso significa que devemos ser cegos, descartar de cara qualquer coisa que esteja fora desse rumo, e não questionar? Não. Mas serão necessários fortes argumentos para priorizar algo que não esteja alinhado com o norteador principal. Cabe ao PM ter a sensibilidade de identificar se é esse o caso, e ir atrás deles. Mas, no geral, esse alinhamento com o objetivo macro da empresa ajuda tanto a PM a encaixar a demanda dentro do cenário total das melhorias de produto, quanto a, novamente, alinhar expectativas com o "dono da ideia".

7- Visão clara de produto

Em linha similar ao ponto anterior, se você constrói junto com o seu time uma visão clara para o produto/feature, e ela está bem difundida/comunicada com todos, isso ajuda a própria PM nessas horas que cito aqui: ok, veio coisa X "urgente", veio coisa Y loucamente, mas péra — essas coisas estão alinhadas com a essência do que estamos fazendo? Pode ser que sim, pode ser que não.

8- Processos de produto sólidos

Sem mistérios aqui. Se a pessoa de produto realiza (1) product discoveries consistentes, e (2) tem organizados o backlog, roadmap, árvore de oportunidades, priorizações e análises de esforço vs. impacto, ela tem muito mais segurança para enfrentar com maturidade a chegada atropelada de mil coisas.

Do contrário, realmente falta a base para analisar todos os aspectos daquilo que chega até nós e colocar isso em uma perspectiva maior, e daí a tendência acaba mesmo sendo sair fazendo tudo que aparece de forma desordenada. Capriche nos processos, e isso trará mais tranquilidade para jogar com uma nova peça quando ela chegar ao jogo.

Aliás, vale ressaltar: quando essas "coisas novas" chegam até o PM, não há razão nenhuma para tratá-las diferente do restante (e priorizar sem fazer um discovery, por exemplo). Essas hipóteses devem ser validadas, caso a PM ache que faz sentido, por discoveries assim como qualquer outra coisa.

9- Cuidado com o "viés do amigo"

Pode parecer óbvio, mas acontece, então vou listar aqui. Por mais que seja natural do ser humano criar mais empatia e envolvimento com algo que vem de um amigo ou alguém/uma área mais próxima, não devemos dar mais valor para algo em produto porque chegou de pessoas com as quais você tem mais contato. Voltando ao ponto 5, tendo considerado os mais diversos pontos de vista no processo de discovery, você vai tomar as melhores decisões em produto, principalmente nos momentos de enxurrada de ideias. Mesmo (ou principalmente) as dos seus amigos.

10- Busque o problema

É o maior clichê de produto essa história de problema, eu sei, mas vamos lá. Quando as pessoas começam a chegar com uma série de feedbacks e ideias e demandas e pedidos, elas geralmente chegam com uma solução pronta.

Não tem como colocar um botão aqui pra eu poder fazer o download dos arquivos?

Como todos os processos de produto sugerem, dê uns passos atrás com a pessoa e tente entender a dor que ela está tendo, as razões para querer "o botão".

Pode ser que outra coisa que está no seu roadmap já resolva aquele problema, e não é "um botão para fazer download". Ou, ainda, pode ser que o problema seja relevante e mereça ser ponderado, mas não necessariamente a ideia da pessoas é a melhor solução para você validar.

No entanto…

Dito tudo isso, um lembrete. Precisamos nos manter abertos! Todas essas dicas nos ajudam a não cair na armadilha de entrar em pânico com um volume grande de demandas que chegam, e sair revendo os planos e encaixando os novos feedbacks de forma desornada na priorização.

Mas de forma alguma isso significa que devemos nos fechar ao que chega até a gente. Por exemplo, a ideia não é catar uns dados para provar que a ideia que as pessoas estão trazendo loucamente "é furada", e poder seguir com o planinho antigo ali, na maior paz.

A intenção aqui é termos insumos e boas práticas que nos ajudam a (1) frear o ímpeto que pode surgir de sair fazendo algo só porque estamos agora nos deparando com uma dor nova de alguém/um grupo e (2) entender e encaixar as novas demandas de forma justa dentro do cenário macro do que já vem sendo trabalhado/estudado, para daí a ponderarmos de forma equilibrada.

E por fim…

É uma boa prática desenvolver um "canal oficial" para que as diferentes pessoas da empresa possam enviar as suas demandas para produto, assim como um canal organizado para coleta de feedbacks de clientes.

Isso, claro, não vai "resolver o problema" de como lidar com essa enxurrada (aliás, prepare-se, porque isso vai trazer ainda mais ideias/feedbacks para a sua mesa — e que bom!): tudo precisará ser avaliado conforme as dicas que coloquei no post. No entanto, as coisas chegarão de forma organizada e ficarão centralizadas em um lugar, prevenindo muitas interrupções do seu trabalho.