Como Criar Confiança na Sua Equipa de Produto e Obter o Apoio das Partes Interessadas

Ler a transcrição:

Estamos a experimentar transcrever os nossos podcasts através de um programa de software. Perdoem eventuais gralhas, pois o robô não está correto a 100% das vezes.

Hannah Clark: Deixe-me descrever o cenário: está numa sala de reuniões com todas as suas principais partes interessadas. Olha para a esquerda e vê o Diretor de Contas a terminar um e-mail. À sua direita, o Diretor de Engenharia está de braços cruzados e observa a sua apresentação com desconfiança. Também tem quase a certeza de que o Designer Principal de Produto está a avaliar o layout dos seus diapositivos. De alguma forma, vai ter de convencer todas estas pessoas a avançarem na mesma direção. Mas, antes de conseguir fazê-lo, precisa que confiem em si. Então, como pode conquistar essa confiança e obter o apoio de que precisa?

Hoje, juntei-me a Noa Goldman, Gestora Principal de Produto na DagsHub. A carreira da Noa começou no desenvolvimento de software, por isso já esteve dos dois lados — o que significa que sabe como pode ser difícil conquistar as pessoas em equipas multifuncionais e acabar com uma solução sólida para os problemas dos clientes. A Noa partilhou a sua receita para conquistar as partes interessadas, criar relações e reforçar o desempenho da equipa. Vamos começar.

Muito obrigada por se juntar a nós, Noa.

Noa Goldman: Obrigada. É um prazer estar aqui. Obrigada pelo convite.

Hannah Clark: Sim, é um prazer tê-la connosco. Noa, tem experiência no desenvolvimento de software, o que tenho a certeza de que lhe foi útil de muitas formas. Gostaria que nos explicasse de que modo isso influenciou a sua abordagem à gestão de produto.

Noa Goldman: Claro. Fui programadora de desenvolvimento integral durante oito anos. Parte desse período correspondeu ao serviço militar. Outra parte foi passada em pequenas empresas emergentes e grandes corporações. Depois, transitei para a gestão de produto e, atualmente, a minha especialização está no mundo das ferramentas para programadores, área em que me ajudou ter sido programadora.

Isso influenciou-me muito. Em primeiro lugar, desenvolveu realmente o hábito de pensar no utilizador e também no perfil do comprador. Sei que isto é algo que a maioria dos gestores de produto diz ser muito importante e afirma pensar constantemente no utilizador e no perfil do comprador. Mas, pela minha experiência, muitas vezes não o fazem.

Para mim, sendo programadora e agora gestora de produto de ferramentas para programadores, penso sempre tanto no utilizador como no perfil do comprador. Por exemplo, se tivermos uma nova funcionalidade que queremos lançar, ou talvez um novo produto que queremos colocar no mercado, penso sempre em mim própria a experimentar essa funcionalidade. Como me sentiria em relação a ela?

Como se sentiria o meu colega? Como a utilizaríamos? Por que métricas somos avaliados? Isto é algo muito importante que, na minha opinião, é frequentemente esquecido. Quando lançamos uma funcionalidade específica, devemos pensar sempre na forma como o utilizador é avaliado, ou seja, com base em quê, e se essa funcionalidade ou produto específico ajudará o utilizador a melhorar ou o ajudará nas suas métricas e na forma como a gestão o avalia nesse caso de utilização específico.

Por isso, obviamente, influenciou-me e influenciou o meu hábito de pensar no perfil do utilizador, mas também me ajudou muito no que diz respeito ao perfil do comprador. Mais uma vez, sinto que este perfil do comprador é constantemente deixado de fora no processo de lançamento de novas funcionalidades e produtos.

Quando tentamos lançar um novo produto, penso sempre: quem são as pessoas envolvidas no processo de compra? Quem está envolvido? Quem deve tomar esta decisão? Por exemplo, penso em mim própria. Enquanto programadora, iria ter com o líder da minha equipa com uma nova funcionalidade ou um novo produto e diria: “Isto é fantástico”.

E esses líderes de equipa diriam: “De que forma nos vai ajudar?” ou “Porque deveríamos pagar a esta empresa específica?” Por isso, tento sempre pensar também nesses perfis. Esta é uma parte muito importante de mim enquanto gestora de produto, mas o meu passado como programadora ajudou-me realmente nesse aspeto. Também acho que me influenciou muito no que diz respeito às prioridades.

Porque, para cada nova funcionalidade, nem sempre tenho de perguntar ao líder da equipa. Sinto que este é um processo que pode ser um pouco difícil para os líderes de equipa ou para os líderes de I&D quando o gestor de produto lhes pergunta constantemente quanto tempo algo vai demorar ou quais serão os esforços necessários. Por isso, sinto que é algo que consigo fazer praticamente sozinha, até certo ponto.

Isso ajudou-me e influenciou-me muito. Mas acho que o mais importante que retirei da experiência como programadora foram as relações com os outros programadores. Sei como me sentia em relação ao gestor de produto enquanto programadora e sei como os meus colegas se sentiam em relação a eles. E nem sempre é agradável ou divertido, e eles nem sempre concordam com eles.

Sinto que aquilo que retirei dessa experiência foi querer que os programadores com quem trabalho se sintam bem comigo e queiram ajudar-me. Sei como é importante a relação e sei — ou pelo menos penso que sei — como conquistar a confiança deles. Assim, sei escolher pelo que vale a pena lutar, o que é mais importante e o que é menos importante. Acho que perceber que esta confiança é importante me ajudou realmente muito, porque primeiro fui programadora.

Hannah Clark: Gostaria de ouvir um pouco mais sobre isso. Se um gestor de produto que nos esteja a ouvir estiver a tentar trabalhar da melhor forma possível com a sua equipa de desenvolvimento, não quiser ressentimentos nem tensão, quais são algumas das melhores práticas que os gestores de produto devem ter em mente para trabalharem eficazmente com a equipa de desenvolvimento?

Noa Goldman: Sim. Obviamente, por vezes existem muitos conflitos e a situação pode tornar-se um pouco frustrante para ambos os lados. Como estive dos dois lados, conheço bem essa realidade. Penso que uma das coisas mais importantes é explicar sempre o porquê, explicá-lo e relacioná-lo com o lado do negócio.

Nós, enquanto gestores de produto, por estarmos no centro de tudo, falamos constantemente. Estamos sempre em contacto com a equipa de marketing, a equipa de vendas ou a gestão de topo. Os programadores, muitas vezes, não estão. Quando apresentamos algo que queremos desenvolver aos programadores e às equipas de I&D, é muito claro para nós, enquanto gestores de produto, o que queremos, por que o queremos e como isso deverá ajudar a empresa.

Mas os programadores que ouvem falar disso pela primeira vez não irão necessariamente ligar todos os pontos. Por isso, é muito importante explicar o porquê e relacioná-lo com o lado do negócio. Especificamente no meu caso, sei que, se alguém me pedir para fazer algo, nem sempre vou concordar, porque não tenho a certeza do motivo. Mas, se me explicarem porquê, qual é a razão e de que forma isso ajudará a empresa, é muito provável que me mostre disponível ou, pelo menos, aberta a uma conversa. Penso que isto é muito importante. E, enquanto gestores de produto, grande parte do nosso trabalho depende de outras pessoas.

Quase nunca somos nós a desenvolver uma funcionalidade ou a fazer o marketing. Temos sempre de explicar aos outros o que queremos fazer. Por isso, é muito importante explicar o porquê e ligar os pontos em termos do lado do negócio. Também acho muito importante mostrar os dados. Se explicar por que algo é necessário, explicar o lado do negócio e de que forma ajudará a empresa a crescer, precisa de provas; precisa de sustentar o argumento com os dados certos.

Tenho a certeza de que todos, ou a maioria dos gestores de produto, dirão que são orientados por dados. Mas, nestes momentos específicos, quando apresenta algo à equipa de desenvolvimento, é muito importante ser orientado por dados. Mais uma vez, quer que confiem em si, quer conquistar a confiança deles e quer que apoiem a ideia. Esta é outra coisa muito importante que destacaria.

Outra coisa que aprendi com o tempo é — pode parecer estranho — dar reconhecimento. Como disse anteriormente, grande parte do nosso trabalho depende de outras pessoas. Quando alguém, como um programador, apoia a ideia e faz o trabalho árduo de desenvolver uma funcionalidade, é muito importante reconhecer, valorizar e elogiar esse esforço, dizendo “Bom trabalho” ou “Muito bem”, tanto individualmente como num fórum mais amplo, para que todos saibam.

Pessoalmente, quando alguém valoriza o meu trabalho, quero fazer um bom trabalho; quero continuar e ajudar. Por isso, diria que estas são as coisas que mais me ajudam quando trabalho com a equipa de desenvolvimento.

Hannah Clark: Sim, acho que essa questão do reconhecimento é muito importante em praticamente qualquer função. É uma daquelas coisas simples que as pessoas parecem negligenciar, mas que fazem uma enorme diferença em qualquer tipo de colaboração multifuncional.

Continuando nesse tema, quando pensa em colaborar com equipas multifuncionais para além da equipa de desenvolvimento, quais são algumas das melhores práticas que considera úteis para garantir que o desenvolvimento das funcionalidades decorre sem problemas e que todos estão alinhados, independentemente da sua área de competência?

Noa Goldman: Lembro-me de uma funcionalidade específica que me ajudou realmente a criar a minha própria receita para lidar com funcionalidades de longo prazo que exigem muito esforço e tempo. Tratava-se de uma funcionalidade específica. Melhorámos o processo de integração numa empresa onde trabalhava como gestora de produto e conseguimos aumentar a taxa de conversão de 15% para 90%.

Foi incrível, mas foi uma jornada muito longa. Eu era uma gestora de produto júnior, por isso trabalhar com equipas multifuncionais, com o marketing, as vendas e a gestão de topo foi muito difícil para mim. Mas foi aí que criei o meu próprio manual sobre como fazer isso. O primeiro passo, antes mesmo de apresentar a nova funcionalidade à equipa, é garantir que o motivo é o correto e que, internamente, esta é a coisa certa a fazer neste momento.

Antes de a apresentar aos outros, quero sentir-me confiante e certificar-me de que estou a fazer o que é correto. Por isso, independentemente de serem funcionalidades com grande esforço, tento sempre garantir que compreendo corretamente o cenário. Isto significa ouvir sempre o lado do negócio e os pedidos, manter uma lista de pedidos de funcionalidades dos utilizadores e observar a forma como os utilizadores usam o produto.

Tento sempre garantir que tenho uma visão de como as coisas estão neste momento, do que é importante para a empresa e do que não é. Quando surge uma funcionalidade de grande dimensão, a primeira coisa que faço é confirmar comigo própria que é a decisão certa. Comparo-a com a visão que tenho e certifico-me de que faz sentido avançar com ela agora.

Garanto que estou confortável com essa decisão. Depois, verifico-a novamente com base nos dados. Certifico-me de que os números fazem sentido, organizo-os muito bem, analiso-os e confirmo que fazem sentido e que o desenvolvimento desta funcionalidade de longo prazo irá aumentar o número que pretendemos melhorar.

Garanto que os dados estão corretos e fazem sentido. Ao fazer isto, também me certifico de que não estou simplesmente apaixonada por uma funcionalidade específica. Os dados convencem-me de que esta é a decisão certa. Depois de estar totalmente convencida de que é a coisa certa a fazer, encontro uma forma muito clara de a apresentar. Tento criar uma ou duas frases sobre o problema e explicar por que é importante resolvê-lo imediatamente.

Essas frases devem explicá-lo tanto à pessoa mais técnica como à pessoa menos técnica da sala. Como se trata de um esforço de uma equipa multifuncional, quero que as vendas, o marketing, a gestão de topo e os líderes de equipa de I&D compreendam claramente que este é o problema e que corrigi-lo ajudará a melhorar o negócio.

Por isso, certifico-me de que o apresento de forma muito simples e, depois, mostro claramente os dados que já organizei. Pode parecer estranho, mas temos sempre de garantir que os dados estão bem definidos e bem apresentados. Por exemplo, verde significa bom e vermelho significa mau. Utilize o gráfico correto.

São coisas que parecem muito triviais, mas que frequentemente não são apresentadas corretamente. Por isso, garanto que o problema e os dados que o sustentam são apresentados de forma agradável e clara, para que todos na sala os compreendam. Este é o segundo passo. O terceiro passo pode parecer estranho, mas no meu livro chama-se “Dividir para conquistar”, o que pode ter um significado ligeiramente negativo, embora não seja negativo de todo.

Isto significa basicamente que, antes de apresentar a funcionalidade a toda a sala e a todos os líderes da equipa multifuncional, tento ter conversas individuais com cada líder de cada equipa multifuncional. Isto vai demorar bastante mais tempo, mas valerá a pena. Sento-me individualmente com o responsável pelo marketing, o responsável pelas vendas, o responsável por I&D e todas as pessoas envolvidas neste processo que preciso de convencer a apoiar a ideia.

Ao fazer isto, em primeiro lugar, faço com que se sintam ouvidos. Como disse anteriormente, se quiser que alguém apoie uma ideia, essa pessoa não tem necessariamente de o ouvir nem de concordar consigo. Tem outras coisas em que pensar. Se quer que apoie a ideia, tem de fazer com que sinta que conta e que é importante.

Por isso, sentar-se com essa pessoa individualmente e ter uma conversa breve ou longa, conforme necessário, mesmo que isso lhe ocupe mais tempo, valerá a pena. Ajuda a pessoa a sentir-se ouvida e, quando se sente ouvida, quer ajudá-lo. A segunda vantagem é que isso me prepara para o passo seguinte, que consiste em reunir toda a gente na mesma sala.

Porque já sei como todos se sentem. Estou preparada com respostas para o que vão dizer e sei como irão reagir relativamente a esta funcionalidade. Por fim, estas conversas individuais ajudam porque as outras pessoas têm frequentemente ideias muito boas e queremos integrá-las na funcionalidade.

Isso fará obviamente com que se sintam mais envolvidas, porque as suas ideias são tidas em conta, mas podem também ter boas ideias que queremos ouvir. Ao realizar estas conversas individuais, consigo criar uma funcionalidade melhor, que a maioria da equipa estará disposta a desenvolver. Portanto, este é um passo: ter uma conversa individual com cada uma dessas pessoas.

Com estes passos, pelo menos segundo a minha experiência, a maioria das pessoas envolvidas já estará a apoiar a ideia, porque sente que faz parte do processo e que foi ouvida. O passo seguinte será a reunião da equipa: juntar toda a gente na mesma sala. É um pouco difícil.

Deixa-nos um pouco nervosos, mas, a esta altura, já devemos estar preparados, porque tivemos todas essas conversas individuais. Sentamo-los na mesma sala, reunimo-los e apresentamos simplesmente a mesma coisa que apresentámos individualmente. Se se lembrar dos passos anteriores, tem aquelas uma ou duas frases que descrevem o problema de forma muito simples, tem os dados e já falou com todas as pessoas presentes na sala.

Por isso, faz tudo novamente e apresenta-o outra vez. Nesta altura, a maioria das pessoas estará a favor da ideia ou, pelo menos, aberta a uma conversa. O que pretende nesta reunião é, em primeiro lugar, garantir que todos são ouvidos no mesmo fórum, num fórum mais amplo, e obter o acordo da maioria.

Nunca conseguirá, ou quase nunca conseguirá, o acordo de todas as pessoas na sala. Mas, quando sentem que foram ouvidas, estarão pelo menos abertas à ideia. Nesta fase, a maioria deverá já apoiar a proposta. Este é o passo final para conseguir que todos apoiem a ideia. Os passos seguintes são aquilo a que gosto de chamar “subir ao palco”.

Quando todos estão alinhados ou envolvidos no desenvolvimento da funcionalidade e o processo já está a decorrer, deve garantir que mantém todos atualizados. Suba ao palco, seja semanal ou mensalmente, ou utilize uma reunião de acompanhamento já existente e dedique alguns minutos a atualizar toda a gente. Gosto sempre de mostrar as alterações visuais.

Gosto de dividir uma funcionalidade de grande dimensão em pequenas vitórias rápidas. Assim, conseguiremos ver visualmente as alterações e o progresso. Ao atualizar todos, mantém o envolvimento. As pessoas querem saber novidades, veem que estamos a progredir e isso ajuda muito. É também uma boa oportunidade para mostrar os dados: se a funcionalidade já tiver sido lançada, mostre os sucessos e os fracassos.

Certifique-se apenas de que é muito claro e honesto relativamente ao processo e todos apoiarão a ideia. É também uma excelente oportunidade para voltar a ouvir as suas opiniões, as suas ideias e o que pensam sobre o progresso que já alcançámos. Fazer isto ao longo do desenvolvimento da funcionalidade é, basicamente, aquilo que deve ajudar todas as equipas multifuncionais a manterem-se constantemente alinhadas e dispostas a ajudar.

Hannah Clark: É um ótimo processo. Acho que também é muito claro e fácil de seguir. Mas estou curiosa: o que acontece, ou qual é a sua abordagem, quando a sala está um pouco mais dividida, quando não existe um acordo total ou quando não há consenso suficiente para avançar com uma funcionalidade? Como lida com uma situação dessas?

Noa Goldman: Se tiver a certeza de que é a coisa certa a fazer e de que faz sentido para a empresa, tento sempre lembrar-me de que, no fundo, estamos todos na mesma equipa e queremos que a empresa tenha sucesso. Por isso, tento novamente dividir para conquistar, explicar o negócio e o porquê e convencê-los de que estamos todos na mesma equipa.

Acaba por funcionar. Se ainda assim não funcionar, tento escolher as minhas batalhas. Por exemplo, se alguém não estiver a apoiar a ideia, tento escolher a melhor forma de o convencer: talvez permitir que essa pessoa avance com outras funcionalidades ou ajudá-la a promover a sua agenda de determinada forma.

Mais uma vez, para mim, tudo se resume às relações. Quando ajudamos alguém, essa pessoa muitas vezes vai querer ajudar-nos em troca. Por isso, trata-se de conduzir essas negociações e garantir que, no final, todos obtêm aquilo que pretendem.

Hannah Clark: Sim, faz sentido. Mudando um pouco de assunto para a definição de prioridades, como digo sempre, quando falamos de gerir e desenvolver funcionalidades, a priorização das funcionalidades é sempre uma parte importante. Quais são os seus segredos para o sucesso ou alguns dos métodos que utilizou para estabelecer prioridades entre funcionalidades?

Noa Goldman: Tenho a minha própria métrica orientadora, que é o negócio. Tudo aquilo de que a empresa precisa para crescer é a minha métrica orientadora. É com isso que comparo tudo. No fim de contas, o meu trabalho consiste em ajudar o negócio e a empresa a crescer.

Não se trata das funcionalidades de que gosto nem daquilo que as minhas equipas querem desenvolver neste momento. Trata-se de ajudar a empresa. Descrevi a visão que mantenho constantemente. Acompanho continuamente aquilo que os utilizadores pedem, os pedidos do negócio, o que o marketing quer e todo o mercado.

Tento pensar no negócio. Para cada funcionalidade, pergunto: esta é a coisa que mais ajudará a empresa a crescer neste momento? Se fizer sentido e a resposta for sim, faço a pergunta seguinte: esta é a forma mais fácil de desenvolver esta funcionalidade?

Em termos de prioridades, escolho sempre aquilo que mais ajuda o negócio e que é mais fácil de desenvolver e exige menos esforço, diria eu. Estas são as duas perguntas que faço a mim própria. Se conseguir responder a estas duas perguntas, conseguirá estabelecer prioridades para tudo.

Hannah Clark: Estamos quase sem tempo, mas queria terminar com algo um pouco mais divertido. Uma das coisas que tenho perguntado recentemente a alguns dos nossos convidados é sobre música, e é uma questão um pouco inesperada. Quer esteja a ouvir música durante o trabalho ou fora dele, existe algum artista, álbum ou género musical de que goste particularmente neste momento?

Noa Goldman: Uau. É uma pergunta muito divertida. Fico muito contente por a ter feito. Nem sei por que estou tão contente. Sim, ouço definitivamente música constantemente, o tempo todo. Tento fazê-lo enquanto trabalho em coisas que não exigem muita concentração, porque, caso contrário, fico confusa. O principal artista que estou a ouvir neste momento é o Paulo Nutini.

Não sei se já ouviu falar dele, mas é ótimo. Acabou de lançar um álbum novo de que gosto muito e o meu sonho é vê-lo atuar num concerto, o que provavelmente não vai acontecer, mas vou trabalhar nesse objetivo, por isso veremos.

Hannah Clark: Ótimo. Não conheço, mas espero que possamos criar uma lista de reprodução de podcasts de gestores de produto com músicas escolhidas por todos os nossos convidados.

Noa Goldman: Adoraria.

Hannah Clark: Sim. Gostaria de o conhecer melhor. Muito obrigada por se juntar a nós hoje, Noa. Agradeço muito o seu tempo e adorei a receita que nos deu; é um formato excelente e fácil de seguir para adquirirmos conhecimentos concretos. Agradeço muito a sua presença.

Noa Goldman: Obrigada. Gostei muito, sinceramente. Muito obrigada.

Hannah Clark: Obrigada por nos ouvir. Para mais informações úteis, guias práticos e análises de ferramentas, subscreva a nossa newsletter em theproductmanager.com/subscribe. Pode ouvir mais conversas como esta subscrevendo o Product Manager onde quer que ouça os seus podcasts.