Muitas vezes, o gerenciamento de produtos pode parecer um jogo de “soma zero”. Você tem recursos finitos para desenvolver seu produto e, se alguém quiser que você adicione X ao roadmap, isso terá que acontecer às custas de Y. Para que isso não aconteça, é papel do gerente de produto dizer não aos vários pedidos. Mas como gerentes de produto podem dizer NÃO, é ainda ser convidado para os almoços?
Jogo de soma zero: ocorre quando o ganho obtido por um participante é equivalente à perda sofrida pelo outro participante, de forma que o resultado final é sempre o mesmo. Assim, cada participante maximiza o seu resultado às custas do outro. (Você pode aprender mais sobre teoria dos jogos nesse artigo)
O gerenciamento de produtos eficaz geralmente se resume a fazer as melhores escolhas possíveis com os recursos limitados que você possui. Para ter sucesso, um gerente de produto geralmente precisa dizer NÃO – a idéias, sugestões e solicitações ou até demandas urgentes de partes interessadas internas e clientes externos.
Mas isso não significa que, como gerente de produtos, você tenha que confrontar ou contradizer as muitas partes interessadas que entrarão em contato com você com solicitações que você simplesmente não tem recursos para cumprir. (E para aqueles que são novos no gerenciamento de produtos, confie em mim, você vai receber essas solicitações com frequência.)
Inclusive, se você aprender algumas técnicas para recusar essas solicitações efetivamente, vai começar a achar que as pessoas entendem completamente e até apoia sua decisão.
Dicas para os gerentes de produto dizerem NÃO
1. Reconheça e discuta a solicitação dos Stakeholders
No treinamento de atendimento ao cliente em praticamente todas as empresas mais bem-sucedidas do mundo, os novos vendedores são ensinados a ouvir atentamente a solicitação ou reclamação de um cliente e, em seguida, falar com o cliente de uma maneira que demonstre que o vendedor entende e simpatiza com o problema. O raciocínio é simples: as pessoas querem ser ouvidas.
Quando uma stakeholder interno ou um cliente chega até você com uma solicitação para adicionar uma feature – nesse exemplo, uma solicitação que você não pode apoiar, pelo menos não imediatamente – a maneira com que você conduz a conversa pode ser tão importante quanto a resposta em si.
Você não gostaria de dizer algo como: “Isso não é uma prioridade para este produto” ou “Não temos isso no roadmap”. Por quê? Duas razões.
Primeiro, quando você pula para uma rejeição sem dar legitimidade ao pedido de suas partes interessadas, você priva essa pessoa de se sentir ouvida.
Em vez disso, você deseja dedicar algum tempo a reconhecer a solicitação, explicando à pessoa que entende por que ela iria querer ou precisá-la e mostrando empatia por sua situação.
Você pode dizer, por exemplo, “Essa é uma ideia bao para uma nova feature, que inclusive consideramos [ou que atualmente estamos verificando a possibilidade] como uma possível adição ao produto”. Somente depois de reconhecer e demonstrar um entendimento da solicitação, você pode explicar por que não é algo que você possa apoiar no momento.
Segunda razão pela qual você não gostaria de responder a uma solicitação de feature com uma rejeição sem contexto/explicação – “Isso não é uma prioridade para nós” – é que, sem dar seu raciocínio, você faz o seu publico achar que seu “NÃO” foi arbitrário. Ter um pedido recusado pode ser decepcionante, mas tê-lo recusado sem motivo é muito pior.
O que me leva à próxima dica: quando você tiver que recusar alguém, seja capaz de demonstrar que você sabe o que esta fazendo, e que tem boas razões para fazê-lo.
2. Saiba o que esta fazendo, para estar sempre preparado
Essa é uma dica um pouco mais ampla, na verdade, mais uma sugestão: gaste o tempo que for necessário para se tornar um especialista incomparável em todos os detalhes relacionados ao seu produto. Isso inclui uma compreensão profunda do seu mercado, das features e capacidades internas da empresa, do cenário competitivo e de outros fatores que afetariam sua decisão de incluir (ou não incluir) uma nova feature ou outra solicitação relacionada ao seu produto.
Se você conhecer os detalhes de “cima a baixo”, quando chegar a hora de recusar uma solicitação, você estará muito melhor equipado para fornecer ao seu solicitante um bom e sólido raciocínio.
Você pode pensar nisso como a segunda parte de uma estratégia de duas partes que começa com a dica número um. Quando alguém lhe solicitar alguma coisa do produto e você tiver que recusá-lo, primeiro passe um tempo discutindo-o com seu solicitante.
Mostre que você entende as necessidades dela e a aprecia a sugestão. Então, quando você explicar o motivo de não pode acomodar a solicitação, você vai conseguir fornecer um contexto maior – que pode incluir problemas como projetos concorrentes ou preservar a simplicidade e a usabilidade do seu produto – que seu solicitante provavelmente não considerou.
Um exemplo comum de uma solicitação que você não poderá atender, é uma que está em conflito (ou pelo menos não se alinha) com os objetivos estratégicos da sua empresa.
Por exemplo: o principal objetivo da sua empresa para o próximo ano pode ser aumentar o número de usuários do seu produto de software. Com essa diretiva organizacional em mente, você pode ter priorizado iniciativas como otimizar o processo de inscrição e criar uma versão de gratuita do seu produto.
Com isso, quando um executivo ou outro stakeholder interno solicitar uma feature que não esta alinhado ao objetivo principal da empresa (como por exemplo a revisão de um épico importante do produto do qual somente seus usuários avançados se beneficiariam), você pode explicar a eles que precisamos concentrar todos os recursos disponíveis nos principais objetivos estratégicos da empresa, que nesse caso, é o de atrair novos usuários.
Ter total controle sobre seu dominio, também significa ter dados relevantes (feedback do usuário, relatórios de uso, informações competitivas, detalhes de vendas) sempre prontos para explicar “por que” a solicitação de stakeholder pode não ser tão urgente ou impactante quanto eles pensam.
Digamos que um executivo solicite que você priorize uma correção de bug encontrada em uma feature no aplicativo. Se você conseguir mostrar a essa parte interessada que menos de 1% da sua base de usuários acessa essa feature, os dados e seu raciocínio ajudarão a explicar por que a correção pode esperar.
Se você aplicar essa técnica corretamente, você vai conseguir:
- primeiramente demonstrar ao seu interessado que ouviu a solicitação dele e vê o valor dela.
- em segundo lugar, Isso fornecerá uma boa transição para sua explicação de que você também está operando no contexto macro, ponderando todas as solicitações (inclusive as válidas como a dele) de uma ótica maior.
Embora ser recusado possa ser decepcionante, fornecer uma razão clara e lógica pode amenizar o golpe.
3. Mostre ao solicitante que o “não”, não é para sempre.
Digamos que você precise recusar uma solicitação da equipe de vendas ou marketing que seja realmente válida. Ou um que você simplesmente não havia considerado e que pode ser digno de inclusão em seu produto, mas que primeiro precisa ser avaliado. Sua resposta pode não ser “não”, mas sim “não agora”.
Uma idéia para mostrar às partes interessadas que você planeja avaliar suas solicitações e que não as está rejeitando apenas é colocando essas solicitações em um “fórum comunitario” (ou mesmo um backlog publico), idealmente acessível a suas equipes internas e clientes externos, onde qualquer parte interessada pode votar ou comentar sobre novas idéias.
Dica: Se você estiver usando KanBan, você pode criar uma nova coluna no board chamada de “Backlog em avaliação”, onde todos serão permitidos colocar novas idéias (inclusive priorizando essas idéias para uma avaliação mais profunda).
Ideia bônus: se você ainda não está operando em um fórum tão aberto, crie um. Pode ser um canal do Slack da comunidade, um blog no site da sua empresa ou construído em uma plataforma de terceiros como a excelente da UserVoice.
A ideia é que você incentive sua base de usuários a contribuir com novas ideias para seus produtos e, em seguida, permita que outros usuários dêem feedback sobre essas idéias. Você pode descobrir features ou idéias para o seu produto que você nunca considerou, que seus concorrentes não pensaram e que seus clientes estão dizendo que eles querem.
A colocação de uma solicitação de produto/feature que você não pode atender imediatamente em um “backlog publico” ou em um “fórum aberto” onde outras pessoas possam examiná-la, é outra maneira de mostrar a todos os envolvidos que você está levando as solicitações de todos a serio.
4. Seja transparente sobre como você prioriza
Uma das melhores maneiras de dizer não, especificamente a um stakeholder interno (como um executivo ou diretor de vendas), é simplesmente mostrar o roadmap do produto, explicando a metodologia que utilizou para priorizar os epicos, temas e features para os próximos lançamentos .
Se você puder fazer uma apresentacão do seu roadmap, mostrando que o próximo ciclo de desenvolvimento da sprint (ou de longo prazo) está focado em X, a parte interessada vai achar mais lógico a sua decisão de não incluir a solicitação Y.
É aqui que um aplicativo de roadmap de produto visual ou framework de priorização pode ser tão útil. Na ferramenta ProductPlan, por exemplo, antes de começar a elaborar seu roadmap, você pode criar uma lista de iniciativas e trabalhar com as partes interessadas para pontuar seus níveis de prioridade de acordo com os fatores que você determinar. Quando suas discussões e pontuação estratégicas estiverem concluídas, você terá uma lista lógica e com suporte de prioridades para o seu roadmap.
Dica: Utilize algum dos diversos frameworks de priorização de feature em conjunto com seus stakeholders, onde ao final, você vai ter uma lista de features / iniciativas para o curto, médio e longo prazo, feitas em conjunto por todos os interessados na empresa.
Isso pode ajudar a demonstrar ao seu colega que você está sendo totalmente transparente com ele, além é claro, de colocar o seu “não” no contexto da visão macro de desenvolvimento do produto e da empresa.
5. Tente não dizer “eu” quando você diz não
Sim, como gerente de produto, você é a pessoa para quem um stakeholder irá levar ideia ou solicitação para o produto. Mas isso não significa que você está tomando uma decisão pessoal ao recusar a solicitação. Na verdade, se você está liderando o desenvolvimento de seu produto de maneira inteligente, as decisões que você tomar serão baseadas não em seus sentimentos pessoais, mas na sua compreensão especializada do seu produto, cliente e mercado.
Dica: Uma maneira poderosa de sublinhar esse fato e de proporcionar aos stakeholders internos e externos uma melhor compreensão do motivo pelo qual você precisa dizer não, é não se referir a si mesmo na conversa.
Por exemplo, ao invês de dizer coisas como: “Acho que não devemos nos concentrar nesse épico agora”,
- Você pode se referir aos dados: “Nossa pesquisa nos disse que …”.
- Você também pode se referir à estratégia acordada: “Os stakeholders decidiram que o próximo lançamento enfatize…. ”
- Ou você pode consultar a política do roadmap que você estabeleceu: “Para chamadas difíceis como esta, estabelecemos um conjunto de diretrizes… ”.
No final, a decisão de conceder ou recusar uma solicitação não é “sobre você”. A decisão será baseada no que é melhor para o produto e no que apoiará os objetivos estratégicos da empresa. Quando você tem que dizer “não”, quanto mais você conseguir manter a conversa focada nesse nível estratégico, e não em si mesmo (ou em seus pensamentos pessoas ou idéias), maior a probabilidade de seu solicitante terminar a conversa entendendo sua posição – mesmo que decepcionada.
6. Tente não dizer “não”, ao dizer não
Quem disse que você tem que dizer não? Agora você tem várias respostas legítimas (exceto o “não”) a uma solicitação que não você pode atender imediatamente, como:
- Adicionar solicitações em um backlog publico onde poderá revisá-las posteriormente.
- Colocá-los em um fórum aberto, onde você pode publicar uma ideia e permitir que fontes qualificadas (seus clientes) ajudem a determinar seu mérito.
- Criar dinamicas recorrentes de priorização, para que todos participem (e tenham “voz”) na criação do roadmap
O que significa que você realmente não precisa dizer “não“.
Digamos que alguém vá até você para adicionar uma nova feature e você sabe imediatamente que não vai poder incluí-lo no roadmap por algum tempo. Nesse caso, sua resposta pode ser algo como:
“Obrigado pela ideia. Nós realmente apreciamos ouvir nossos usuários. Solicitações como essa nos informam que você está usando e obtendo valor com nosso aplicativo/serviço/produto. Nosso roadmap de produtos e cronograma de desenvolvimento estão bem travados para o futuro imediato … mas deixe-me expor essa idéia à nossa comunidade [ou deixe-a colocar backlog publico ou permita-me revisá-la assim que concluirmos nossa próximo lançamento, quando nosso ciclo de desenvolvimento afrouxa um pouco]. “
Você não se comprometeu com nada. Mas você não disse não (ou algo parecido). Seu cliente se sente ouvido e apreciado, que sua ideia teve mérito e que você tem uma razão legítima para não poder executá-la imediatamente.
Esse cliente / stakeholder pode sair um pouco decepcionado, mas como você usou essas técnicas e mostrou que o ouviu e entendeu o seu pedido, é muito menos provável que eles também fiquem com raiva.
Conclusão
Dizer não é difícil. Dizer não para nossos parceiros, amigos, familiares é difícil. Dizer não a stakeholders e clientes pode ser ainda mais. Um dos papeis mais importantes do gerente de produto é manter todos os envolvidos alinhados ao objetivo da empresa e para onde o produto esta caminhando. Isso, muitas vezes, é feito através de um roadmap (aprenda a fazer seu primeiro roadmap aqui). Mas o que priorizar no roadmap é o trabalho mais dificil.
E a parte mais difícil, é justamente dizer “não” a ideias que não estão prontas, não estão alinhadas, ou simplesmente porque você priorizou outro foco de atuação. Espero que tenha ajudado a mostrar algumas maneiras que vocês possam construir o melhor para seu produto, dando voz para todos da empresa! Não vai ser fácil, mas é preciso.