Aprenda a dizer "Não" como Product Owner

**Dizer não pode ser extremamente difícil. A maioria de nós quer agradar outras pessoas. Mas quando dizemos "não", decepcionamos quem nos pediu algo.

No entanto, dizer não é uma parte importante do trabalho de todo Product Owner. O Product Owner tem a tarefa de otimizar o valor de um produto a ser entregue, e isso significa não dizer sim a todo pedido de um cliente.**

Cada vez que um Product Owner cede ao pedido de uma funcionalidade, ele precisa dizer não a outro pedido de cliente no futuro. O tempo da equipe é limitado e cada sim hoje significa ter que dizer não a uma oportunidade no futuro.

Por isso, dizer não é uma habilidade que todo Product Owner precisa aprender.

Quero apresentar a você seis diretrizes que vão te ajudar a dizer não de forma firme, mas educada:

1) Criar clareza: É um não definitivo? Ou apenas um não para o momento?

Quando Product Owners comunicam aos stakeholders que não vão incluir uma funcionalidade desejada na priorização, devem deixar claro o que o seu não significa exatamente.

Se tens a certeza de que nunca vais deixar a equipa trabalhar nessa funcionalidade, não cries falsas expectativas encorajando o stakeholder a voltar a falar contigo sobre isso mais tarde. Isso só é perda de tempo e frustrante, ter de rejeitar repetidamente uma funcionalidade que nunca vais implementar de qualquer forma.

No entanto, se acreditas que podes incluir a funcionalidade mais tarde e o não é apenas para este momento, então explica isso aos stakeholders exatamente dessa forma. Um exemplo:

Desculpe, mas no momento não podemos trabalhar nisso. Acredite, eu gostaria que pudéssemos. No entanto, já fizemos um commitment para XY, no qual vamos trabalhar até agosto. A equipe precisa se concentrar nesse commitment agora, caso contrário talvez não consigamos entregar. Mas se você me lembrar disso em agosto, prometo que vamos considerar o seu pedido.

Por favor, assim como neste exemplo, tenha cuidado para não prometer que a funcionalidade será implementada com certeza mais tarde, mas apenas que ela será considerada novamente no futuro.

Além disso, deixe a responsabilidade com o stakeholder ou cliente de fazer novamente a solicitação ou de lembrá-lo quando o momento for mais adequado. Faço isso conscientemente para ter certeza de que essa funcionalidade específica é realmente importante o suficiente para eles. Se um stakeholder não voltar a falar sobre a funcionalidade, duvido que ela fosse tão urgente ou importante assim.

Mas o mais importante é não deixar o stakeholder acreditar que ele pode perguntar novamente sobre a funcionalidade daqui a um mês, quando na verdade você não pretende implementá-la de qualquer forma.

2) Expressar valorização e empatia pelos clientes

Quando um stakeholder expressa um desejo por uma funcionalidade, o Product Owner deve sempre agradecer e confirmar que entende por que essa funcionalidade é importante para o stakeholder.

Alguém dedicou tempo para pedir algo à equipe. Isso significa que essa pessoa se interessa pelo seu produto. Deixe o cliente saber que você aprecia o fato de ele ter dedicado tempo para fazer esse pedido. Algo como este exemplo é totalmente suficiente:

Muito obrigado. Agradeço que você esteja pensando em como nosso produto pode ficar ainda melhor.

Além dessa demonstração de valorização , Product Owners também devem mostrar empatia pela situação do stakeholder. Você está prestes a recusar algo que provavelmente é muito importante para ele. A funcionalidade deve – pelo menos aos olhos do stakeholder – atender aos objetivos definidos pelo seu superior e pode até ter impacto financeiro.

Antes de tudo, porém, você deve tentar entender por que a funcionalidade é tão importante para o cliente. Só recuse o pedido quando realmente tiver compreendido por que ele é tão importante para o stakeholder.

Você pode demonstrar sua compaixão com uma declaração como esta:

Eu entendo que essa funcionalidade é tão importante para você alcançar XY.

Mas seja sempre sincero nisso. Acredito que não sou a única pessoa que não gosta de compaixão falsa!

3) Mencionar apenas uma única justificativa para o seu não

Quando você, como Product Owner, recusa um pedido de funcionalidade, é melhor apresentar uma boa justificativa do que uma série de razões. As pessoas tendem a escolher o argumento mais fraco entre vários e argumentar contra ele. Veja um exemplo:

Imagine que eu sou seu cliente e peço que sua equipe deixe o trabalho atual de lado para priorizar uma funcionalidade que eu quero. Você poderia me dizer algo assim:

"Desculpe, mas isso não é possível. Já planejamos este Sprint. Eu teria que marcar uma nova reunião de planejamento com o time e eles não vão gostar disso. Além disso, tenho certeza de que os trabalhos atuais têm uma prioridade maior no momento."

O que você acha, qual argumento eu tentaria atacar? A necessidade de uma nova reunião de planejamento ou o fato de que o trabalho atual tem prioridade?

Eu escolheria o argumento de que seria necessária outra reunião de planejamento e que a equipe não gostaria disso. Possivelmente eu ofereceria tornar a reunião menos desagradável, colocando-a no horário de almoço e pagando pizza para todos.

Mesmo que você ainda não goste do meu plano, acabei de mudar o foco da conversa: em vez de falar sobre a funcionalidade, agora estamos falando sobre a realização de uma reunião. Primeiro é preciso conseguir rebater esse argumento.

Além disso, essa é a base errada para tomar essa decisão.

Mantenha-se firme e mencione o motivo mais convincente para recusar a funcionalidade. Se o stakeholder conseguir mudar sua opinião, você deve considerar se seus outros argumentos são fortes o suficiente para justificar um não. Se não forem, talvez você deva ceder ao pedido.

4) Temos o mesmo objetivo

Quando o Product Owner e o stakeholder perseguem o mesmo objetivo maior, o Product Owner deve mencioná-lo ao comunicar notícias indesejadas.

Product Owner e stakeholders frequentemente têm objetivos bem diferentes. E sim, às vezes eles entram em conflito. No entanto, normalmente existe também um objetivo maior relacionado ao produto que ambos compartilham e ao qual podem se referir. Um exemplo de objetivo maior?

Isso é especialmente fácil quando ambas as partes trabalham na mesma empresa. Nesse caso, pode-se dizer:

"Por mais que eu gostasse de deixar a equipe trabalhar nisso, precisamos realmente nos concentrar agora em [objetivo comum superior]."

"Como você certamente sabe, todos nós temos o mesmo objetivo, que é [objetivo comum superior]."

Ao lembrar o cliente de que vocês têm um objetivo comum, você facilita que ele entenda por que está recusando o pedido dele, mesmo que ele ainda não concorde 100% com a sua resposta.

5) Explique as consequências ao stakeholder

Quando você recusa o desejo de um stakeholder, como Product Owner deve explicar as consequências que aconteceriam se cedesse a esse desejo.

Isso ajuda o stakeholder a entender por que você se vê obrigado a dizer não. Por exemplo, você poderia dizer:

"A equipe já está fazendo horas extras. Eu não poderia adicionar essa funcionalidade ao trabalho deles sem tirar algo que já prometemos a outra pessoa."

"Se trabalhássemos no seu recurso em vez das outras tarefas, não conseguiríamos cumprir o prazo."

Explicar as consequências vai ajudar o stakeholder a compreender sua decisão e desenvolver empatia pelo motivo de você ter recusado o pedido dele.

6) Ofereça uma alternativa

Em vez de simplesmente rejeitar um pedido do cliente, um Product Owner pode talvez oferecer uma alternativa.

Isso poderia ser assim:

"Não podemos de forma alguma fazer tudo o que você imaginou, mas que tal começarmos implementando uma parte disso?"

"Não posso deixar a equipe trabalhar nisso agora de jeito nenhum, mas que tal começarmos daqui a três semanas?"

Mas atenção: Ofereça esse tipo de compromisso apenas se você realmente estiver falando sério.

Sem medo de dizer "Não"

Product Owners frequentemente têm medo de dizer Não e decepcionar o stakeholder ou cliente. Mas recusar um pedido não precisa ser difícil.

Descobri que é muito mais fácil dizer Não quando você

• Clareza cria,

• uma boa razão em vez de várias indica,

• empático e grato é,

• ao objetivo comum aponta,

• as consequências de um Sim explica e

• uma alternativa oferece.

Quando bem feito, um "não" pode até melhorar a relação entre Product Owner e stakeholder em vez de prejudicá-la! Mais possibilidades de comunicação com stakeholders você encontra também nos nossos treinamentos. No Product Owner Training, são apresentadas e praticadas diferentes abordagens e possibilidades de comunicação.

Este artigo é do blog de Mike Cohn e foi traduzido por nós para o português.