Desenvolvimento Orientado pelas Pessoas (com Sam Higham, da Glean)

Michael Luchen

Enquanto gestores de produto em exercício ou aspirantes a gestores de produto, somos constantemente bombardeados com certificações e formação especializada que nos dizem ser essencial para a nossa profissão. Seguir um processo adaptado para criar produtos é a chave para o sucesso, ou pelo menos é isso que nos dizem. Continue a ouvir, porque hoje vamos explorar este tema em profundidade. Serão as certificações e os processos adaptados tão necessários como parecem? Ou haverá algo melhor?

Este é o podcast The CPO Club, as vozes de uma comunidade que está a escrever o manual de gestão, desenvolvimento e estratégia de produto. Somos patrocinados pela Crema, uma agência de produtos digitais que ajuda pessoas e empresas a prosperarem através da criatividade, tecnologia e cultura. Saiba mais em crema.us. Continue a ouvir para obter perspetivas práticas e autênticas que o ajudarão a ter sucesso no mundo da gestão de produto.

O tema de hoje é algo que me é muito próximo e que se relaciona com a gestão de produto. Tenho o privilégio de dar as boas-vindas a Sam Higham ao programa para falar sobre este assunto. Sam é um líder de produto focado no utilizador, com uma carreira comprovada na transformação, para melhor, de produtos, processos e pessoas. Desenvolve-se tanto nos aspetos detalhados como nos aspetos direcionais da criação de produtos funcionais, desde as suas bases funcionais até às expectativas comerciais que proporcionam.

Sam tem um interesse ilimitado na forma como a tecnologia e a psicologia interagem nas jornadas dos consumidores, apoiando as equipas na identificação de formas de combinar e aperfeiçoar ambas para proporcionar os melhores resultados possíveis. Sam é o Vice-Presidente de Produto da Glean, uma solução de tomada de notas para aprendizagem e produtividade.

A solução de tomada de notas da Glean grava notas de áudio que pode captar e utilizar para aprender informação de forma mais eficaz. Sam também trabalha a tempo parcial como coach de produto e formador de gestão de produto para a Mind the Product, onde ajuda a orientar pessoas ao longo da carreira de gestão de produto que pretendem seguir.

Olá, Sam! Bem-vindo ao programa.

Sam Higham

Olá, obrigado pelo convite.

Michael Luchen

É bom tê-lo aqui. Para começar, pode partilhar como chegou ao ponto onde está hoje?

Sam Higham

Sim, claro. Resumidamente, através de muitas tentativas e erros. Penso que, tal como muitas pessoas de produto, acabei por entrar na gestão de produto ao longo dos últimos dez anos, mais ou menos.

Penso que desempenhei praticamente todas as funções que se podem desempenhar no desenvolvimento de produto, à exceção de programação. E, mesmo nesse campo, já tentei criar algumas APIs bastante más no passado. Portanto, comecei formalmente a trabalhar num centro de gestão de produto há cerca de oito anos, embora não com esse título.

Depois, ao longo desse período, tentei continuamente aperfeiçoar o que significa ser uma pessoa de produto e como melhorar no dia a dia. Penso que grande parte disso resultou da tentativa de perceber: afinal, o que é a gestão de produto? E, honestamente, é uma pergunta que ainda me faço todos os dias.

Michael Luchen

Sim, o que é? É uma pergunta bastante abrangente.

Sam Higham

Para mim, penso que se resume a tentar encontrar a melhor forma de criar valor, tendo em conta o contexto em que nos encontramos, quaisquer limitações que tenhamos e as pessoas com quem estamos a trabalhar. Penso que grande parte da abordagem mais purista à gestão de produto é fantástica, mas não tem necessariamente em conta as circunstâncias dos mais de 95% das organizações que não dispõem de tudo o que é necessário para seguir o processo à risca.

Penso que é aí que surgem alguns dos desafios. Existe muita informação aspiracional excelente que diz: eis como poderiam fazer produto num ambiente laboratorial perfeito. Mas nenhum de nós trabalha realmente nessas condições. E nenhum de nós, ou muito poucos, dispõe do financiamento necessário para aplicar todas estas práticas de ponta a ponta da forma perfeita.

Por isso, grande parte do trabalho envolve desenvolvimento iterativo. E não me refiro apenas ao desenvolvimento iterativo no sentido do software, mas também no sentido dos processos e da colaboração. Tudo está continuamente a ser trabalhado de forma interativa.

Michael Luchen

Interessante. Portanto, o que está a dizer é que grande parte da documentação e da formação sobre gestão de produto se centra em sermos iterativos no desenvolvimento de produto. Mas também está a dizer que temos de ser iterativos no processo e com as pessoas, com base no ambiente em que trabalhamos.

Sam Higham

Exatamente. Penso que muitas vezes se esquece que nós, enquanto seres humanos, somos pessoas muito complexas.

Não somos indivíduos perfeitamente organizados, capazes de seguir tudo à risca. Também não partilhamos todos o mesmo conhecimento. Por isso, quando uma pessoa de produto entra às cegas — e eu próprio já o fiz — e diz: “Está bem, vamos praticar gestão de produto e este é o quadro que vamos utilizar, e tudo vai funcionar na perfeição”, não está a ter em conta uma questão fundamental: será que os meus colegas compreendem sequer o que estamos a tentar alcançar? Percebem o que estamos a fazer ou por que razão esta abordagem pode ser uma forma valiosa de trabalhar? Até que ponto falamos a mesma linguagem?

Se não der esse primeiro passo e não disser: “Está bem, todos nós estamos a trabalhar em conjunto; qual é a melhor forma de fazermos isto?”, e não tiver essa conversa aberta, pode trazer as suas próprias experiências e técnicas que funcionaram no passado e tentar aplicá-las. Mas não espere que tudo aconteça e funcione automaticamente. Por vezes, podemos ficar cegos pela ideia de que “funciona na Google”, “funciona na Amazon” ou “funciona noutro sítio qualquer”, sem pensar: será que funciona connosco?

Michael Luchen

Sim. E penso que é realmente fascinante: quanto mais aprendo sobre o funcionamento interno da Google ou da Amazon, mais percebo que muitas das histórias que contamos a nós próprios talvez sejam dos primeiros tempos, quando eram uma espécie de exemplo perfeito de empresas emergentes e da forma como trabalhavam.

Mas agora são grandes empresas, com muitas equipas diferentes e muitas formas diferentes de trabalhar, inclusive internamente.

Sam Higham

Sim, sem dúvida. É um ponto muito interessante. Muitas pessoas falam das melhores experiências que tiveram quando trabalhavam numa empresa emergente. Penso que isso acontece porque estão num espaço em que todos compreendem o que estão a tentar fazer e estão todos a tentar descobrir a solução em conjunto. Partilham uma linguagem comum e estão dispostos a ter rapidamente conversas abertas sobre o que podem fazer.

E não me refiro apenas às pessoas do desenvolvimento de produto — design, produto e engenharia. Refiro-me a vendas, marketing, operações, a toda a organização. Todos estão no mesmo espaço e existe um ciclo de feedback muito próximo. Penso que os desafios, e o momento em que os processos entram em cena e começamos a introduzir estruturas, surgem à medida que crescemos. Começamos a perder essa proximidade, porque desenvolvemos a nossa própria forma interna de falar sobre as coisas, o que reduz a acessibilidade para que outras funções colaborem eficazmente.

A nossa abordagem pode estar tão avançada e tão distante daquilo que as outras pessoas compreendem sobre a nossa função que, se não mantivermos continuamente o ciclo de feedback — “Eis o que estamos a tentar fazer, eis por que razão estamos a seguir esta abordagem” — perdemos essa ligação. De repente, as vendas já não colaboram devidamente com as pessoas de produto, as pessoas de produto já não colaboram devidamente com os engenheiros e todos falam sobre a importância da sua própria função, mas não sobre o quão boa poderia ser a organização em conjunto.

Michael Luchen

Parece dar muito trabalho.

Sam Higham

Dá, não é? É precisamente isso.

Michael Luchen

Sim. Estou a pensar nos nossos ouvintes, muitos dos quais talvez trabalhem em organizações maiores que já não são propriamente empresas emergentes. Como orientaria essas pessoas a trabalhar num ambiente em que têm realmente de defender o processo, mas talvez sintam que não existe espaço para isso, ou talvez esse espaço não esteja disponível?

Sam Higham

Começar pequeno, como acontece com tudo. Muitos dos bons fundamentos de coisas como o Manifesto Ágil continuam a ser válidos. Começar pequeno e pensar qual é a experiência mais simples que podem realizar enquanto grupo, dentro da vossa área de controlo. Também é importante sentirem-se confortáveis com aquilo que está sob o vosso controlo.

Por vezes, podemos ficar muito frustrados quando tentamos mudar demasiadas coisas demasiado depressa. Nunca vamos ganhar essa batalha se dissermos: “Ouvi uma pessoa num podcast dizer que devemos fazer estas experiências e colaborar de forma mais eficaz, por isso é isso que vamos fazer.” Em vez disso, podemos dizer: “Trabalha com uma equipa de desenvolvimento, idealmente multifuncional, com designers, engenheiros e pessoas de produto. Que experiências poderíamos realizar em conjunto para sermos mais eficazes?”

Depois, podemos envolver outra função nessa colaboração e começar a demonstrar a abordagem. É importante compreender que talvez não funcione. Pode não funcionar, e temos de perceber por que razão não funcionou e começar então essas conversas.

É muito esforço e está longe daquilo que pensamos ser a melhor forma de trabalhar. Quanto mais distante estivermos, mais tempo levará a chegar lá, mas isso não significa que não devamos começar. E o melhor momento para começar é hoje. É a única coisa que podemos fazer.

Michael Luchen

Adoro o foco em começar pequeno. Também já vi isso resultar, especialmente ao trabalhar com vários clientes que estão a criar os seus próprios produtos. Estamos constantemente a entrar e a sair de ambientes em que os processos estão a mudar. O que descobrimos ser muito eficaz é restringir realmente o âmbito e dizer: “Vamos experimentar isto durante duas semanas.”

Não estamos a vender uma forma de trabalhar para o próximo ano; estamos a lançar as sementes dessa mudança. O que estamos realmente a propor é uma experiência de duas semanas. “Confiem em nós, vamos experimentar. Vejamos como corre.” É aí que conseguimos provar o valor e começar a introduzir outras coisas.

Também tenho curiosidade sobre uma questão que abordamos frequentemente enquanto pessoas de produto: assumir um papel de coaching. Existe uma responsabilidade de coaching que contribua para o sucesso desta abordagem no dia a dia?

Sam Higham

Sim, sem dúvida. Para mim, coaching significa garantir que fazemos mais perguntas do que damos respostas. No nível mais elevado, trata-se de descobrir como encontramos respostas em conjunto, e isso tende a acontecer através de perguntas melhores.

Grande parte do que faço diariamente, quer esteja a trabalhar com pessoas enquanto parte de uma equipa, quer esteja numa conversa de coaching individual, consiste em fazer perguntas como: “Que aspetos considerou? Por que razão está a considerar essas opções? Considerou outras alternativas? Se sim, por que escolheu esta? Pensou na forma como poderia envolver outras pessoas neste processo?”

O objetivo é ajudá-las a criar o hábito de fazerem essas perguntas a si próprias e aos outros, para que todos sigam a mesma metodologia.

Do ponto de vista do coaching, também é importante entrar nessa mentalidade e sentirmo-nos confortáveis por sermos mais a sombra do sucesso do que o centro das atenções. Temos de ficar satisfeitos por ver as pessoas vencerem porque estivemos nos bastidores a ajudá-las, sem reivindicar que fizemos parte do processo, porque isso retiraria valor ao seu próprio desenvolvimento.

Não devemos permitir que as pessoas pensem: “Na verdade, foi o Sam que esteve nos bastidores a orientar aquela pessoa ou aquela equipa.” Deve ser: “A equipa ultrapassou o problema por si própria e alcançou essa melhoria.” Na verdade, devemos minimizar completamente o nosso envolvimento. Quase não quero que as pessoas saibam que essas conversas aconteceram ou que passámos horas a explorar diferentes formas de apresentar algo.

Aquela pessoa era dona da apresentação. Foi ela que a preparou e foi ela que conseguiu o resultado. O facto de eu ter feito algumas perguntas que a ajudaram a chegar lá é irrelevante.

Michael Luchen

Está muito bem dito. Penso que também funciona no sentido inverso: permitir que as pessoas falhem através desse coaching, para que possam aprender diretamente. “Uau, foi uma situação muito difícil. Mas agora sei como enfrentá-la da próxima vez e sinto-me capacitado para o fazer.”

Sam Higham

Sem dúvida. Por vezes temos medo de falhar. Em algumas organizações, existem desafios em que há quase uma cultura invisível segundo a qual o fracasso é excessivamente exposto.

Por exemplo, pode existir um pequeno erro numa parte do software. De repente, começam a circular mensagens e um dos executivos mais poderosos da organização pergunta: “Quando é que isto vai estar corrigido? Meu Deus, isto é um desastre.” O que não percebemos é que a consequência direta é as pessoas passarem a ter medo de qualquer falha ou pequena alteração.

Assim, ficam menos dispostas a correr riscos e a tentar algo novo, porque não querem ser aquelas a quem se aponta o dedo. O mesmo acontece em sessões de crítica de design. Existem boas práticas que envolvem apresentar o trabalho cedo e abertamente para obter colaboração. Mas, se as críticas forem excessivas ou atacarem diretamente a capacidade dos designers, eles deixam de apresentar o trabalho tão cedo ou com tanta frequência. Perdemos todo o poder de aprender, falhar e desenvolver essa mentalidade.

Enquanto líder, temos de estar muito conscientes disso e ajudar as outras pessoas a evitar esse comportamento. Esses sinais invisíveis podem ser muito prejudiciais para alcançar a mentalidade positiva que queremos, em que as pessoas estão dispostas a experimentar e encaram as experiências como oportunidades de aprendizagem, não como fracassos.

Michael Luchen

Penso que são os líderes das organizações que criam as estruturas para que as pessoas possam falhar em segurança e aprender com os seus erros, em vez de viverem com medo de falhar e, por isso, não aprenderem. É provavelmente uma das coisas mais difíceis de fazer, porque, enquanto líder, pensamos: “Não quero que a minha organização falhe.”

Para os líderes que nos estão a ouvir, qual é o valor, em termos de resultados para a organização, de permitir que as pessoas de produto falhem até alcançarem esses resultados?

Sam Higham

É uma excelente pergunta. Esperemos que os resultados reais acabem por surgir. Conseguimos ver as equipas que se sentem confortáveis, confiantes e capacitadas para serem proativas: “Esta experiência que realizámos foi inconclusiva ou estava errada, mas agora podemos fazer esta outra coisa.”

É importante que sejam ativas e claras sobre a razão por que escolhem correr esses riscos e sobre aquilo que aprenderam. Também se relaciona genuinamente com a velocidade. Quando as pessoas falam de velocidade, referem-se normalmente a pontos de história. Não me refiro a nada disso. Refiro-me à capacidade das pessoas trabalharem de forma confortável, confiante e rápida, sem receio de terem de obter outra aprovação ou de confirmar várias vezes que todos assinaram a autorização para realizar uma pequena experiência.

O contrário é conversar com as equipas e dizer: “Eis o nível de autonomia que quero que tenham. Eis os casos em que gostaria que conversássemos sobre avançar. E eis as decisões que continuo a considerar da minha responsabilidade.” Isso tem a ver com o risco.

Trata-se de acordar qual é a tolerância ao risco da organização e em que nível se deve tomar cada decisão. Se alguém disser: “Vou fazer uma alteração fundamental na nossa base de dados, não vou encerrar o nosso site e existe uma grande probabilidade de falhar”, talvez não queiramos que a equipa de produto tome essa decisão sem supervisão. Mas se disser: “Vou realizar uma experiência A/B num botão para 10% da nossa base de utilizadores e o pior que pode acontecer é a conversão diminuir 0,01%”, então provavelmente queremos que a equipa avance, porque a melhoria iterativa compensa largamente o potencial impacto negativo.

Michael Luchen

É quase um acordo de trabalho entre a equipa de produto e os líderes.

Sam Higham

Sim. Mesmo assim, continua a haver espaço para conversas de coaching quando o nível de risco foi demasiado alto ou demasiado baixo. Podemos ter uma conversa ativa para dizer: “Tendo em conta o risco envolvido, da próxima vez vamos garantir que falamos sobre isto antes.” Não tem de ser mais complicado do que isso.

Michael Luchen

Falando de coisas complicadas, algo que se torna evidente ao longo desta conversa é o quão complicado, confuso e ambíguo é o produto. Ao ouvir a sua perspetiva sobre desenvolvimento de produto, com a qual concordo, percebe-se que não existe um único processo ou quadro que sirva para todos.

Imagino que, para um gestor de produto que está a começar, a questão seja: “Por onde começo? Começo por um processo? Vou ter com a equipa? Vou ter com os líderes? Qual é a minha bússola? Como navego neste contexto?” Que conselho lhe daria?

Sam Higham

Posso partilhar a minha própria experiência, porque pode funcionar para algumas pessoas e não para outras. Eu aprendo as coisas no último momento responsável. Quando comecei a trabalhar em produto, aprendia literalmente aquilo que tinha de fazer no momento em que tinha de o fazer.

Na primeira vez que tive de preparar uma apresentação, procurei perceber como se fazia um roteiro, que opções existiam para o apresentar e por que razão uma poderia ser melhor do que outra. Depois, na segunda vez, pensei: “O que aprendi com a primeira vez? Como poderia priorizar um backlog?” E fui descobrir como priorizar um backlog.

É genuinamente assim que aprendo. A razão é que fico facilmente sobrecarregado quando consumo muita informação e depois me esqueço dela. Existe uma tentação de ler 20 livros sobre gestão de produto e assumir que seremos capazes de recordar toda essa informação no momento certo para a aplicar.

Se consegue fazer isso, excelente. É uma ótima forma de aprender. Mas eu não consigo. Tenho de praticar algo, aprender sobre isso e perceber se funciona para mim. É isso que continuo a fazer atualmente.

Se há algo novo que vou experimentar, tento aprender sobre isso no momento. Continuo a ler bastante e a procurar inspiração sobre o que está a acontecer e a ser experimentado, mas, quando chega o momento da aplicação, aprendo no último momento responsável.

A alternativa é frequentar um curso. Não penso que haja nada de errado com isso. É bom ter conhecimentos fundamentais. Desde que não dependamos disso como sendo a forma exata como as coisas vão acontecer e não sigamos rigidamente aquilo que aprendemos num ou dois dias, é perfeitamente válido.

É outra forma de aprender, mas não significa necessariamente que saibamos aplicá-lo na prática, devido a toda a complexidade que resulta do facto de sermos humanos e de tentarmos trabalhar em coisas complicadas, com um milhão de fatores externos e internos que podem tornar muito difícil realizar algo aparentemente simples.

Michael Luchen

Isso é excelente. Também reconheci isso no meu próprio percurso e vi outros gestores de produto à minha volta prosperarem ao adotarem a atitude: “Vou simplesmente começar e aprender fazendo.” Existe tanta coisa na nossa área que, como referiu, quando se trata de criar um roteiro, a melhor forma pode ser fazer uma pesquisa e começar a experimentar a ferramenta escolhida, percebendo o que funciona, o que resulta para a equipa e o que não resulta.

Sam Higham

Exatamente. Não penso que exista uma forma correta de criar um roteiro. Existem formas que podem ser ligeiramente melhores, mas podem não funcionar no seu contexto. É muito fácil dizer: “Agora, depois e mais tarde, sem datas, sem funcionalidades, apenas resultados.” Mas não quero ser responsável por o seu diretor executivo gritar consigo porque nunca viu esse formato, não estava à espera dele e está completamente fora da forma como trabalha.

É necessário fazer uma mudança incremental entre aquilo que gostaríamos idealmente de fazer e aquilo que funciona para nós neste momento. Depois temos de perceber como construir a ponte entre essas duas coisas.

Michael Luchen

Grande parte do que estamos a discutir envolve pessoas. Parece que temos de manter os olhos no longo prazo. Não apenas no longo prazo dos resultados que queremos criar para o produto, nas métricas que queremos alcançar ou em algo semelhante, mas também no longo prazo da otimização da equipa com que colaboramos.

Como deve um gestor de produto manter isso em mente todos os dias enquanto trabalha com as suas equipas?

Sam Higham

Existem algumas formas relativamente simples — embora nada disto seja fácil. Uma delas é através de retrospetivas. Para mim, uma autoavaliação da equipa é muito mais saudável do que números arbitrários retirados de um sistema de gestão de tarefas ou avaliações feitas por outras pessoas.

Também já organizei retrospetivas ou workshops sobre a saúde da equipa, em que se acordam dez aspetos nos quais a equipa quer concentrar-se e, trimestralmente, se revê o progresso: “Melhorámos ou piorámos num determinado aspeto? O que vamos fazer para mudar isso?”

Essas abordagens abrangem dois aspetos diferentes. Uma retrospetiva normal centra-se muito mais no presente: “O que estamos a tentar fazer, tendo em conta este trabalho específico e o ponto em que nos encontramos?” A avaliação da saúde da equipa é mais abrangente, quase como uma grande retrospetiva sobre temas gerais, que permite acompanhar a tendência da equipa.

A equipa pode decidir os aspetos que entram nessa avaliação mais abrangente e identificar aquilo que pode indicar que está saudável ou não. Também penso que isto tem muito a ver com competências interpessoais. Enquanto pessoa de produto, temos de estar atentos às mudanças na forma como a equipa se comporta.

Por exemplo, podemos perceber que, de repente, já não existe tanta interação quando discutimos o que poderíamos fazer ou como poderíamos alcançar a nossa visão de produto a curto prazo. Ou quando tentamos resolver um problema específico. Devemos pensar conscientemente: “O que mudou? O que aconteceu?” E depois conversar com as pessoas e perguntar-lhes.

Muitas vezes podemos ficar sentados a fazer psicologia de gabinete e pensar: “Isto aconteceu por esta razão, por isso vou fazer outra coisa.” Mas eu iria conversar com as pessoas e perceber o que aconteceu. Pode ser que alguém tenha recebido críticas muito duras sem que soubéssemos, que algo tenha corrido mal ou que essa pessoa esteja a enfrentar problemas pessoais ou profissionais.

Somos seres humanos e estamos destinados a comunicar. Foi assim que sobrevivemos e criámos uma sociedade humana: através da colaboração e da formação de comunidades. Vejo uma equipa de produto como uma pequena comunidade que se torna maior à medida que atravessa a organização.

Michael Luchen

Uma equipa de produto é uma pequena comunidade. É uma ideia bastante poderosa. Falando de comunidade, toda esta conversa está tão centrada nas pessoas. Se eu for gestor de produto e pensar: “Os exercícios de saúde da equipa e as retrospetivas parecem ótimos”, talvez até já os tenha sugerido, mas os meus líderes ou outras pessoas com quem trabalho perguntam: “Qual é o valor disso? Não vamos gastar tempo nisso. É uma perda de tempo.” Como se navega nessa situação?

Sam Higham

Mais uma vez, trata-se de fazer estas coisas abertamente. Devemos explicar por que razão estamos a tentar fazê-las e quais serão os indicadores de uma experiência bem-sucedida ou não.

Se falarmos de saúde da equipa, a retenção pode ser um bom ponto de partida. Também podemos pedir às pessoas que façam uma autoavaliação da sua satisfação. Existem muitas ferramentas que fazem isso semanalmente: “Quão satisfeito me sinto no trabalho?” Há formas de medir esses aspetos.

Também podemos falar de forma mais geral: “Como está a nossa equipa a trabalhar? Quais são alguns dos desafios que temos?” Suponhamos que o trabalho está constantemente bloqueado porque não estamos a contactar os departamentos certos no momento certo. A nossa hipótese pode ser que vamos colaborar de forma mais ativa com esse departamento desde o início.

Podemos envolvê-lo no nosso processo de planeamento no início do trabalho e incluí-lo nas demonstrações semanais, se as fizermos. Esperamos então deixar de ouvir no último minuto: “Esqueceram-se daquele aspeto e agora não conseguem disponibilizar a funcionalidade porque não nos envolveram.”

É importante manter uma comunicação geral aberta. Outra forma de abordar o assunto é perguntar à equipa de liderança: “O que gostariam de ver? Como gostariam que medíssemos alguns destes aspetos?” e iniciar uma conversa ativa.

É possível que a conversa siga uma direção errada e que comecem a dizer: “Quero ver a velocidade e os pontos de história a aumentar todas as semanas.” Nesse caso, eu diria provavelmente para fugirem. Mas devemos tentar manter uma conversa de confiança com a liderança e aproximá-la do problema.

É quase como fazer coaching para cima. Tentamos fazer perguntas para compreender o que querem ou o que receiam que aconteça se fizermos estas coisas, e como podemos aliviar a ansiedade de que estamos a desperdiçar tempo ao realizar este trabalho.

Michael Luchen

Essa ideia de fazer coaching para cima é interessante. Voltamos às perguntas: perguntas simples e de alto nível. Gosto também da sua ideia de fugir se o objetivo for aumentar a velocidade e os pontos de história, porque já ouvi isso antes.

O interessante é que, por vezes, quando perguntamos “porquê?”, percebemos que existe apenas um mal-entendido fundamental sobre o valor de acompanhar pontos de história e velocidade. E isso permite ter esse diálogo.

Se, mesmo depois de compreendermos isso, a resposta continuar a ser “queremos que aumente”, então é altura de fugir. Mas é interessante porque, enquanto gestores de produto, temos um conhecimento geral muito vasto sobre processos, ferramentas e práticas. Não podemos assumir que os nossos interlocutores têm o mesmo conhecimento.

Sam Higham

Sem dúvida. A falta de compreensão e de uma linguagem comum é, por vezes, uma parte enorme do problema. Até a utilização de expressões como “orientado pelo produto”. Podemos dizer que temos uma cultura orientada pelo produto, mas, a menos que as pessoas compreendam que isso significa trabalharmos coletivamente para criar um produto incrível que se venda mais facilmente, podem assumir que significa que o produto se vai tornar a função mais poderosa e o árbitro de tudo.

É assim que começamos a colocar as pessoas nas suas próprias torres, assustadas e a lutar por tudo. A linguagem é extremamente poderosa. Quando as pessoas interpretam mal algo e não explicamos claramente o seu significado, podem tirar conclusões e, de repente, estamos numa conversa em que não queríamos estar.

Tenho cada vez mais consciência da terminologia que utilizo. Será que todos compreendem essa terminologia? Se não, como posso simplificá-la ou explicar o que é realmente importante?

As pessoas são muito relutantes em admitir que não compreendem algo. Normalmente, apenas as pessoas mais confiantes numa reunião dizem: “Espere, o que quer dizer com orientado pelo produto?” A maioria fica em silêncio, a pensar que os outros devem compreender, e isso pode ser perigoso.

Michael Luchen

Temos de assumir uma postura de orientação, uma orientação paciente para todos.

Sam Higham

Sim.

Michael Luchen

Tenho uma última pergunta antes de terminarmos. Está numa função muito prestigiada, tem uma excelente carreira e, além disso, orienta e forma pessoas. Tem um conhecimento muito próximo da nossa área. Para ter sucesso, para onde vê a gestão de produto a dirigir-se? Como será a gestão de produto nos próximos três anos?

Sam Higham

Penso que provavelmente começará a dividir-se em mais especializações. A gestão de produto começou por ser muito abrangente e significa coisas muito diferentes para pessoas diferentes. Penso que começará a dividir-se em especialidades e tipos mais específicos de profissionais de produto.

É semelhante ao que vemos na engenharia de software, com especializações e subespecializações. Poderá incluir crescimento, B2B ou B2C. Utiliza-se muita desta terminologia, mas ainda não começámos realmente a associá-la àquilo que funciona melhor para uma pessoa de produto focada no crescimento, para uma pessoa de produto B2B ou B2C, para um mercado ou para qualquer outro tipo de produto.

Parte da formação e do conteúdo que começo a ver está a orientar-se nessa direção. Espero que isto se torne formalmente uma disciplina, com especializações, porque a comunidade de profissionais de produto está a crescer muito. É natural que isso aconteça.

Michael Luchen

Fantástico.

Antes de terminarmos, gostaria de fazer algumas perguntas pessoais rápidas, se estiver de acordo.

Sam Higham

Sim.

Michael Luchen

Qual dos seus hábitos pessoais mais contribuiu para o seu sucesso?

Sam Higham

Diria resiliência. Grande parte do que falámos hoje relaciona-se com o fracasso. Por vezes, as pessoas não aceitam muito bem o fracasso e podemos ser criticados quando as coisas não correm bem, especialmente se não existir um ambiente seguro. Portanto, essa é definitivamente uma das principais características.

A adaptabilidade é provavelmente outra. É assim que aprendo: adapto-me continuamente à informação que tenho. E, depois, provavelmente, a humildade. Digo abertamente que não sei metade das coisas que preciso de saber. Na verdade, dependo de muitas outras pessoas que são muito mais brilhantes nas suas áreas para conseguirmos ter sucesso.

Tento nunca fingir que sou o especialista e que sei tudo, porque não sei. E não penso que alguma vez venha a saber.

Michael Luchen

Gosto muito de todas essas características e identifico-me claramente com o seu valor.

Qual é a sua ferramenta preferida entre as que utiliza regularmente?

Sam Higham

Miro, ou Myra? Não sei como se pronuncia. Não me lembro qual é a pronúncia correta, mas é a ferramenta mais flexível. Não saberia trabalhar sem ela.

Utilizo-a todos os dias, o dia inteiro, para tudo. Na última empresa onde trabalhei, utilizámo-la para lançar um negócio de mil milhões de dólares em seis meses. Foi simplesmente o Miro, como se não fosse nada de especial. É uma ferramenta impressionante. Também a utilizo para todo o meu conteúdo e para tudo o resto. É uma excelente ferramenta.

Michael Luchen

Também concordo. A minha equipa e eu adotámo-la quando ainda se chamava RealTime Board. Rapidamente se tornou a ferramenta mais utilizada na história da empresa, com um valor enorme.

Por último, para alguém que está a começar o seu percurso em produto, qual é o principal conselho que já deu?

Sam Higham

Peça ajuda. Existe a ideia de que, enquanto pessoa de produto, devemos saber tudo, porque estamos frequentemente na interseção de todas as áreas. Podemos sentir relutância em pedir ajuda quando não sabemos algo, seja a outras pessoas de produto, a um excelente engenheiro com quem trabalhamos, a um designer ou a alguém da organização.

Algumas das melhores pessoas que conheço em gestão de produto são aquelas que estão sempre a pedir ajuda, porque sabem que isso as ajuda a melhorar.

Também existe uma comunidade de profissionais de produto em crescimento no Twitter. Penso que a maioria das pessoas está lá porque quer ajudar outras pessoas a aprender. Por isso, o meu principal conselho é: peça ajuda. Na verdade, não apenas para produto, mas para qualquer pessoa. Sem exceção.

Michael Luchen

É um excelente conselho e concordo plenamente. Mesmo quando pensamos que sabemos, devemos pedir ajuda, porque obter uma segunda opinião pode, por si só, ser muito valioso.

Muito bem, Sam. Muito obrigado por se juntar ao programa hoje.

Sam Higham

Obrigado pelo convite.

Michael Luchen

Pode saber mais sobre o trabalho do Sam no Twitter ou no LinkedIn. Mais uma vez, muito obrigado, Sam, por se juntar a nós. Obrigado a todos por nos ouvirem e não se esqueçam de deixar uma avaliação do podcast. Visitem também e juntem-se à nossa comunidade em theproductmanager.com, caso ainda não façam parte dela.

Mais uma vez, obrigado a todos por se juntarem a nós e até ao próximo episódio. Até breve!