Gestão das Partes Interessadas: A Arte de Dizer Não

O bom desenvolvimento de produtos requer a identificação e o foco na sobreposição mágica entre conveniência, viabilidade e viabilidade – onde mora a inovação. Os gerentes de produto estão constantemente na posição de ter que defender o equilíbrio entre esses domínios, contrariando as forças que competem para puxar um produto longe demais em uma direção às custas das outras. Isso significa dizer não – muitas vezes e para muitas pessoas – ao longo da jornada de desenvolvimento do produto.

No início da minha carreira, trabalhei em um projeto no espaço automotivo, desenvolvendo um aplicativo que usava aprendizado de máquina informado por dados ambientais e comportamento do usuário para fornecer sugestões inteligentes aos motoristas. Na época em que entrei para a equipe, o aplicativo estava pronto para ser lançado e a gerência estava ansiosa para lançá-lo, mas logo percebi que estava longe de estar pronto para produção.

Embora o aplicativo fosse visualmente atraente, algumas das questões de design mais fundamentais foram ignoradas, como “Qual problema estamos resolvendo e para quem?” e “Quão desesperadas estão as pessoas para resolver esse problema?”

O aplicativo ostentava um recurso que mostrava o clima no destino do motorista. A partir de hábitos do usuário e dados de tráfego, o algoritmo pode inferir para onde um motorista pode estar indo e quanto tempo levaria para chegar lá, e uma simples integração de API meteorológica mostrava a previsão do tempo para o destino no momento da chegada. Este parecia um bom caso de uso, mas, na realidade, ninguém se importou. Quando realizei minha própria pesquisa de usuários, incluindo uma pesquisa paga de motoristas europeus, a resposta foi um sonoro “Meh”. Esse é sem dúvida o pior feedback que você pode obter: significa que seu produto resolveu um problema irrelevante e indica que a dimensão de conveniência é extremamente baixa. A viabilidade é então uma causa perdida: é impossível construir um negócio viável com um produto que ninguém quer. Tivemos que desfazer tudo.

Como isso pode ter acontecido? A resposta é complicada, mas se resume ao fato de que uma palavra crítica não foi pronunciada quando deveria: Não.

A principal competência e os ativos da empresa eram mecanismos de inferência de aprendizado de máquina e design de arquitetura altamente escalável. O chefe de ciência de dados era um stakeholder poderoso que queria ver seus mecanismos de inferência sendo bem usados ​​em um aplicativo de cliente. Sua influência, em parte, resultou em um produto completamente centrado em tecnologia. O desenvolvimento tinha sido impulsionado pelo que era tecnologicamente viável em vez do que os clientes desejavam.

Parecia que ninguém havia dito não a esse stakeholder e, se eles tentaram, não foi eficaz.

Estratégia de produto significa dizer não

Dizer não é difícil. As pessoas nem sempre gostam de ouvir a palavra, e muitas vezes há o medo de que dizer isso prejudique relacionamentos importantes. Como gerentes de produto, os relacionamentos são fundamentais para nosso papel, mas também é garantir que nossos produtos sejam bem-sucedidos e permaneçam em equilíbrio.

Então, como você rejeita o pedido de alguém enquanto mantém o relacionamento intacto? Recomendo estas práticas:

• Prepare-se para o sucesso.
• Não diga não muito rapidamente.
• Reformule o pedido.
• Incentivar um clima de contribuição.

Prepare-se para o sucesso

No início de um projeto, é essencial que todos concordem com uma visão compartilhada para o sucesso do produto (“Por que estamos fazendo isso?”) e um conjunto de métricas que serão usadas para medir o progresso (“Como saberemos se estamos indo bem?”). Se você não concordar com o que é o sucesso, é apenas uma questão de tempo até que os conflitos surjam.

É útil usar uma estrutura para documentar metas e mapeá-las para algo mensurável. Eu gosto de usar uma versão solta da estrutura HEART do Google, que organiza a experiência do usuário em categorias para Felicidade, Engajamento, Adoção, Retenção e Sucesso da Tarefa e, em seguida, articula metas, sinais e métricas para cada uma dessas categorias. As metas abordam o que você está tentando alcançar, os sinais dividem cada meta em ações do usuário e as métricas rastreiam essas ações para avaliar como você está se saindo de uma maneira quantificável.

Em um projeto de aplicativo de consumidor recente, eu queria conduzir um piloto limitado para determinar se os usuários achavam nosso protótipo útil e queriam continuar interagindo com ele; Eu estava focado principalmente na categoria Engajamento da estrutura HEART. Eu então tive que identificar sinais e métricas para acompanhar o progresso em direção a essa meta:

• Objetivo: os usuários desejam interagir com o aplicativo e continuar usando-o.
• Sinal: os usuários abrem o aplicativo com frequência.
• Métrica: Porcentagem de usuários que abrem o aplicativo pelo menos duas vezes por dia.

Esse processo de identificação e alinhamento de metas pode parecer simples, mas não é fácil. Nesse caso, envolveu ligações com o cliente e nossa equipe de vendas, pesquisas independentes e vários workshops em equipe. Com base nas informações que reuni dessa descoberta, pude apresentar a estrutura HEART completa durante a reunião inicial com o cliente. Passamos por todos os itens e adaptamos onde necessário.

Garantir que todas as partes interessadas estejam envolvidas no processo de definição de metas é fundamental e fazer com que todos concordem sobre quais sinais e métricas precisam ser rastreados elimina a necessidade de dizer não repetidamente à medida que o projeto avança. Ele também fornece dados para apontar se alguém se aproximar de você com uma solicitação que esteja fora dos parâmetros do plano.

Não diga não muito rapidamente

Mesmo quando as principais partes interessadas concordam sobre o que é o sucesso e o caminho a seguir parece claro, uma coisa é certa: alguém, em algum lugar, se aproximará de você com uma pergunta imprevista.

Quando isso acontecer, não diga não muito rapidamente. Mesmo se você tiver certeza de que o pedido não é razoável, rejeitá-lo imediatamente interrompe a conversa e pode prejudicar o relacionamento. Também prejudica o processo de descoberta do produto. Como gerentes de produto, precisamos ver o quadro completo, e ouvir as pessoas que discordam de nós reduz nossos pontos cegos.

Você ainda pode dizer não, é claro, mas precisa evitar respostas instintivas. Isso leva a discussões binárias que são o resultado do pensamento em preto e branco, certo ou errado, ganha ou perde: ou você implementa algo ou não.

Para avançar em direção a discussões mais eficazes e diferenciadas, você precisa organizar as solicitações de acordo com os critérios acordados que você estabeleceu como parte de seu processo de definição de metas.

Em vez de perguntar a uma parte interessada “Esse recurso é valioso para você?” pergunte "Qual é o valor desse recurso para você?" A conversa resultante deve fornecer as informações necessárias para colaborar em uma lista de “desejos”, ordenados em termos de importância. É essencial que essa classificação varie de 1 a n, sem permitir que vários itens compartilhem o mesmo lugar na hierarquia. Isso dá a todos uma voz no processo de priorização e dispensa você de rejeitar solicitações unilateralmente. Alguns pedidos cairão no esquecimento quando o grupo os rebaixar em favor de outros mais importantes.

Reformule a solicitação

Um pedido que parece irracional inicialmente pode produzir resultados positivos com alguma reengenharia sutil. Primeiro, ouça o que está sendo dito. Realmente ouça. Deixe suas suposições de lado e tente entender de onde a outra pessoa está vindo, e então encontre um terreno comum. Se você for um pouco mais fundo perguntando “Por quê” – não necessariamente as cinco vezes que você ouviu falar; dois a três geralmente são suficientes - você pode descobrir um fator que fala de um objetivo compartilhado.

Mesmo uma solicitação perfeitamente sensata pode se beneficiar de um mergulho mais profundo e um pouco de reenquadramento. Lembro-me de uma situação em que estava trabalhando em uma ferramenta de business intelligence para um serviço de mobilidade B2B. Meu cliente me pediu, não inesperadamente, para aumentar o número de assinantes. Embora a motivação para aumentar o número de assinantes pagantes possa parecer evidente, eu queria ter certeza de que tinha uma visão completa, então perguntei: “Por quê?”

Descobriu-se que o produto em questão estava chegando ao fim de seu ciclo de vida e meu cliente queria espremer as últimas gotas de lucro antes de substituí-lo por um novo produto. Com essas informações, reformulei a solicitação para "Como podemos aumentar consideravelmente a receita no curto prazo enquanto preparamos as bases para o próximo lançamento do produto?"

Em última análise, a melhor solução era não se preocupar com o número de assinantes, mas alinhar melhor os preços com o valor. Os clientes pagavam uma assinatura mensal fixa, independentemente da frequência com que usavam a ferramenta para transações de passageiros. No entanto, quanto mais transações de passageiros eles processavam, mais valor eles obtinham da ferramenta. Os clientes variavam de motoristas de táxi individuais fazendo apenas algumas transações mensais a transportadoras multinacionais de carga – com dezenas de subsidiárias e milhares de veículos – fazendo centenas de milhares de transações mensais. A mesma assinatura mensal fixa era muito alta para os pequenos clientes e muito baixa para os grandes.

Ao fazer pequenos ajustes de preços, aumentamos a receita enquanto avançamos em direção a uma estrutura de preços escalonada (com base no número de transações) para o produto que será lançado em breve. O novo modelo reduziu o preço para a maioria dos clientes e aumentou para os maiores clientes, que vinham se beneficiando desproporcionalmente.

Ao reformular as solicitações dessa maneira, você pode criar situações em que todos saem ganhando. A pessoa que apresenta a solicitação se sente ouvida e respeitada, e você obtém insights que podem agregar valor sem atrapalhar o processo de desenvolvimento do produto.

Incentive um clima de contribuição

Um dos maiores riscos de dizer não é que as rejeições podem minar o espírito de abertura e colaboração que você está tentando promover, tanto dentro quanto fora de sua equipe. As ideias inspiram, sejam ou não relevantes, e a última coisa que você quer fazer é conter o fluxo de criatividade e comunicação.

Certa vez, trabalhei com um engenheiro júnior de controle de qualidade que tinha muitas ideias. Em quase todas as reuniões ele fez várias perguntas e sugestões voluntárias. Suas soluções muitas vezes não eram acionáveis, e algumas delas poderiam ter sido descartadas como inúteis ou irrelevantes. Mas seu empenho e entusiasmo foram inestimáveis. Ele estava totalmente empenhado em entregar o melhor produto possível, e suas contribuições energizaram e inspiraram outros. Uma atitude assim é contagiante.

Você deseja criar um ambiente no qual as pessoas se sintam encorajadas a compartilhar pensamentos e ideias e sejam recompensadas por isso. Sua equipe deve ser motivada pela possibilidade de melhorar as coisas, em vez de desencorajada pelo pensamento de ser demitida, ignorada ou ridicularizada. A implementação de algumas práticas simples pode ajudar a garantir a segurança psicológica de sua equipe.

Reconhecer ideias e solicitações publicamente. Isso cria confiança e mostra que você valoriza as sugestões e está comprometido em considerá-las. Configure uma caixa de solicitação ou uma página do Confluence ou outro fórum público que todas as partes interessadas possam acessar. Quando uma solicitação chegar, registre-a e envie uma mensagem ao solicitante, agradecendo a contribuição.

Eu sei que isso pode ser controverso, mas às vezes chego ao ponto de abrir o backlog do produto para todos. Isso pode ser particularmente útil para promover o envolvimento da equipe de produto, além de permitir que membros da equipe, como testadores e designers de controle de qualidade, observem as coisas que encontraram. As regras são simples: qualquer pessoa pode adicionar ao final da lista de pendências e, durante os refinamentos (ou outras reuniões semanais), os membros da equipe compartilham o que adicionaram e explicam o porquê. Somente o gerente de produto pode alterar a ordem dos problemas ou excluir itens. Muitas pessoas supõem que conceder a todos esse nível de acesso levará ao caos e à anarquia, mas isso não acontece. Eu tentei isso em organizações de diferentes tamanhos e só falha quando as pessoas são muito tímidas para contribuir com suas ideias.

Depois de implementar uma solução ou lançar um recurso, mesmo que grosseiramente relacionado a uma dessas solicitações registradas, credite o solicitante publicamente. Isso é especialmente importante quando a solução não é um cumprimento claro da solicitação original, mas mais uma versão reformulada. Mostrar apreço por todos os envolvidos em um sucesso cria boa vontade, cria camaradagem e incentiva as pessoas a continuar participando.

Pesando os prós e contras de dizer não

Se você dedicar um tempo para realmente ouvir e entender de onde vêm as partes interessadas, raramente precisará rejeitar as propostas imediatamente. Escuta ativa, comunicação transparente e respeito mútuo são ingredientes essenciais para lidar com solicitações que podem parecer inicialmente problemáticas ou fora do escopo. Na maioria das vezes, a arte de dizer não nunca envolve dizer “não”.

Haverá situações em que será impossível encontrar um terreno comum, sendo necessário um não direto para proteger o produto e o projeto. Em outros casos, você pode ser obrigado a seguir em frente em coisas com as quais não concorda. Por mais que seu trabalho seja proteger o equilíbrio entre conveniência, viabilidade e viabilidade, há uma quarta dimensão a ser considerada: o pragmatismo. Para manter as coisas avançando, o compromisso é fundamental e, às vezes, isso significa evitar completamente um não.

A beleza do desenvolvimento de produtos Agile é que sua natureza iterativa oferece muitas oportunidades para correção de curso. Afinal, o objetivo é construir-medir-aprender, não debater-disputar-desviar.