A falta de clareza está a destruir silenciosamente o seu produto?

Leia a transcrição:

Estamos a experimentar transcrever os nossos podcasts utilizando um programa de software. Perdoe quaisquer erros tipográficos, pois o sistema automático não está correto a 100% do tempo.

Hannah Clark: É praticamente um lugar-comum, mas acontece constantemente: dizemos algo a três pessoas e cada uma ouve algo diferente. E isso não é assim tão grave se aquilo que dissemos for: “Vou buscar café, alguém quer alguma coisa?” Mas quando estamos a construir um MVP com uma margem de manobra cada vez menor, ou a tentar lançar algo dentro de um prazo rigoroso, essa falta de clareza pode ser o beijo da morte para uma startup.

O convidado de hoje é Bijan Shahrokhi — é o fundador da Product Management Exercises e da Product Monkey AI. Bijan passou a última parte da sua carreira a ajudar gestores de produto a tornarem-se mais produtivos e a gerirem melhor as equipas. E a capacidade de trazer clareza e alinhamento a uma equipa de produto é fundamental para essas competências. Dentro de alguns minutos, Bijan irá partilhar um processo fácil de replicar que lhe custará algum tempo inicialmente, mas que tem o poder de salvar uma startup à beira do colapso. Vamos começar.

Bem-vindos de volta, ouvintes. Hoje estou acompanhada por Bijan Shahrokhi. É o fundador da ProductManagementExercises.com e lançou recentemente uma ferramenta de produtividade exclusiva para gestores de produto chamada ProductMonkey.ai.

Bijan, muito obrigada por se juntar a nós hoje.

Bijan Shahrokhi: Muito obrigado pelo convite.

Hannah Clark: Ótimo. Começamos sempre da mesma forma. Gostaria que nos falasse um pouco sobre a sua experiência e sobre como chegou onde está hoje.

Bijan Shahrokhi: Claro. Sou gestor de produto de coração. Sou gestor de produto há mais de 10 anos, completamente por acaso.

Nem sequer sabia o que era gestão de produto até ter uma startup que não estava a correr muito bem. Perguntei a um amigo o que ele achava que eu devia fazer a seguir e ele disse-me: “Devias ser gestor de produto”. E eu pensei: espere aí. Parece muito interessante, algo como produto e gerir o produto. É isso que quero fazer.

A partir daí, tornei-me gestor de produto. Fiz algumas coisas diferentes nos últimos 10 anos. Trabalhei durante os primeiros anos da minha carreira em organizações maiores, como num banco, primeiro como gestor de produto e depois como estratega de produto. Depois disso, fiz parte de duas startups. Em ambas, lançámos o produto quando entrei para a empresa e uma delas foi adquirida, no espaço de um ano e meio, por um interveniente maior do ecossistema.

A outra foi, na verdade, um projeto bem-sucedido. No seu auge, valia vários milhares de milhões de dólares. Continua em funcionamento e continua a crescer bastante. Desde então, tenho-me concentrado sobretudo na Product Management Exercises nos últimos anos da minha carreira. E, recentemente, lançámos outro produto para a comunidade de gestão de produto chamado ProductMonkey.ai.

Hannah Clark: Extraordinário. Hoje vamos falar sobre clareza nas organizações, algo pelo qual é pessoalmente bastante apaixonado. E, quando digo clareza, refiro-me simplesmente a garantir que todos os intervenientes estão alinhados e partilham a mesma versão do que está a acontecer e do que deve ser construído.

Como é que isso se manifesta, para si, quando uma organização não tem um sentido de clareza?

Bijan Shahrokhi: Excelente pergunta. Penso que o maior sinal, o sinal mais óbvio de que uma organização não tem clareza, surge quando percorremos a organização e perguntamos a pessoas diferentes quais pensam ser os critérios de sucesso para aquilo que precisa de ser entregue como próximo grande marco, e começamos a ouvir histórias diferentes.

Vou dar um exemplo. Imaginemos que estamos a lidar com um produto muito técnico que terá de trabalhar com muitas métricas de desempenho, como latência, velocidade, número de transações por segundo ou o volume de tarefas que pode ser concluído. Se isto não estiver claramente definido por uma pessoa muito técnica dentro da organização, essa pessoa pode tentar construir algo capaz de suportar um volume extremamente elevado de transações, por exemplo.

Mas, se perguntarmos a alguém mais orientado para o negócio e para o cliente, essa pessoa poderá dizer: só precisamos de pôr algo no mercado para começarmos a obter feedback dos nossos clientes. Percebemos que existe falta de clareza quando começamos a conversar com pessoas de toda a organização e ouvimos números diferentes, ou quando dizem: “Ah, nunca pensámos nisso” ou “Nunca discutimos isso”. Normalmente, esse é um alerta bastante grande para um gestor de produto perceber: espere aí, parece que existe aqui falta de clareza.

Hannah Clark: Parece que teve algumas experiências diretas com esse tipo de situação. Sem mencionar nomes, consegue lembrar-se de algum episódio?

Bijan Shahrokhi: Claro. Na verdade, o último projeto de que lhe falei, que acabou por valer vários milhares de milhões de dólares, era uma empresa que estava apenas a alguns meses de ficar sem dinheiro e ainda não tinha lançado o projeto.

Pensavam que estavam apenas a alguns meses de lançar o produto. Quando entrei, disseram-me inicialmente que faltavam apenas três meses. Depois de entrar, percebi que aquilo que alguns dos fundadores tinham em mente estava talvez a 5 ou 10 anos da realidade.

E aquilo que alguns dos engenheiros pensavam estar a entregar também estava a alguns meses de distância. Havia, portanto, uma enorme diferença entre as duas perspetivas. Por causa disso, ficaram presos num ciclo de desenvolvimento durante mais de três anos, porque a equipa de engenharia continuava a apresentar algo como estando quase pronto. E alguns dos fundadores ou responsáveis pelo negócio olhavam para o produto e diziam: “Esperem aí, vocês não estão prontos”.

Isto não corresponde realmente àquilo que temos em mente. Redefiniam o que precisava de ser construído. E a equipa voltava a trabalhar, desiludida, sentindo que não estava realmente a acrescentar valor à organização. O que fizemos nesse momento foi passar os meus primeiros três meses como responsável pelo produto a reunir-me com muitos intervenientes e a compreender verdadeiramente quais eram os atributos que geravam perspetivas muito diferentes dentro da organização.

Por exemplo, percebi que, relativamente a determinado atributo, metade da empresa, ou algumas pessoas dentro da organização, achava que ele tinha de fazer parte do lançamento inicial. A outra metade não pensava assim. Começámos então a ter muitas conversas sobre esses itens específicos e obtivemos clareza sobre se seriam ou não construídos. Era uma decisão binária. Ou decidíamos fazer uma versão muito, muito simples desse elemento.

E definíamos exatamente o que iríamos fazer como parte dessa versão. Só depois disso demorámos cerca de um ano a construir uma versão simples daquilo que inicialmente se pensava que seria lançado em três meses. Honestamente, demorámos alguns meses apenas a obter clareza sobre o que seria construído ao longo de um ano.

Espero que este seja um exemplo de uma situação em que, ao trazer muita clareza, conseguimos efetivamente lançar algo. E, depois de o lançarmos, conseguimos utilizar o feedback dos utilizadores, da comunidade e de todo o ecossistema para perceber quais das coisas que estão no plano devem ser posteriormente priorizadas.

Hannah Clark: Sim, e isso também é uma enorme conquista. Fechar uma lacuna dessas parece uma tarefa impossível. É uma abordagem bastante poderosa. Recuando um pouco, quais diria serem algumas das implicações mais abrangentes quando uma organização não incorporou processos de clareza na sua cultura em geral, e não apenas na equipa de produto?

Bijan Shahrokhi: O maior impacto é normalmente acabarem por não lançar o produto, e isso é um problema bastante grande. Há muitos projetos excelentes que acabam por nunca chegar ao mercado porque ficam sem dinheiro antes de conseguirem começar a gerar receitas para a empresa. Infelizmente, esta é uma realidade ainda mais dura no caso de projetos baseados em I&D. Os projetos baseados em I&D, que são muito científicos e tentam realmente proporcionar algum tipo de avanço, são normalmente liderados por fundadores com fortes backgrounds académicos.

E, no caso de pessoas com fortes backgrounds académicos — sem qualquer ofensa, eu também tenho um forte background técnico e académico e considero isso algo positivo — o que acontece quando uma organização é liderada por essas pessoas é que procuram a perfeição. Como procuram a perfeição, continuam a construir, a construir, a construir e a acrescentar coisas. Estão sempre preocupadas com os cenários extremos que, honestamente, nem sequer representam o fim do mundo se ocorrerem durante as fases de incubação ou iniciais de um projeto.

O resultado é que nunca lançam o produto e o mundo nunca chega a ver aquilo que tinham idealizado para esta nova tecnologia.

Hannah Clark: Sim, toda essa questão de “concluído versus perfeito” é algo com que estamos sempre a lidar: de um lado, os perfeccionistas; do outro, as pessoas que simplesmente querem lançar o produto, certo? Uma área em que penso que todos podemos concordar que a clareza é absolutamente vital é, como disse, o desenvolvimento de um MVP. E penso que é uma área muito propensa a erros, falhas de comunicação e problemas que podem ser bastante desastrosos no final do dia.

Quais são alguns dos erros comuns que as equipas que constroem MVP devem ter em atenção e que soluções existem para os evitar?

Bijan Shahrokhi: Penso que o maior erro que tenho visto as startups cometerem relativamente ao conceito de MVP é confundi-lo com a entrega de um produto avariado que nem sequer é utilizável, certo?

Já vi isso acontecer muitas vezes. Sem mencionar nomes, vou dar um exemplo. Sou, por exemplo, investidor num determinado produto que é uma solução empresarial. Estou muito, muito entusiasmado e apaixonado por ele. Desde o primeiro dia, a razão pela qual fiquei entusiasmado foi conseguir imaginar-me a querer utilizá-lo.

Também conseguia imaginar a minha organização, a Product Management Exercises, a querer utilizá-lo diariamente. O maior obstáculo à sua adoção tem sido o facto de ter tantos erros que chega ao ponto de não conseguirmos utilizá-lo. Por isso, é muito importante que, enquanto líderes de produto, prestemos atenção a isto e garantamos que, quando falamos de um MVP, não estamos a falar de um produto cheio de erros que não consegue comunicar a sua proposta de valor.

Ainda temos de garantir que a experiência central do utilizador, ou o valor central do produto que estamos a tentar entregar, funciona muito bem e de forma fluida, de ponta a ponta. Podemos retirar muitas coisas que são desnecessárias, mas temos de garantir que conseguimos proporcionar essa experiência central do produto.

Penso que este é um dos maiores erros que vejo as empresas cometerem: não compreendem o que significa MVP e pensam que isso significa que podem simplesmente lançar algo que está avariado.

Hannah Clark: Sim. É quase como se existisse um grupo que não quer esperar para lançar até tudo estar perfeito e, depois, o outro extremo do espectro. Faz sentido.

Tem um processo bastante intensivo para procurar clareza dentro das organizações, ao qual aludiu anteriormente. Se as pessoas que nos estão a ouvir quisessem copiar e colar essa abordagem no seu próprio fluxo de trabalho, que passos lhes recomendaria para garantir que estão alinhadas com toda a equipa?

Bijan Shahrokhi: Obrigado por perguntar. É interessante que faça essa pergunta, porque muitas pessoas na PM Exercises consideram este processo muito útil. Para ser honesto, é bastante simples e centra-se em fazer o trabalho difícil logo no início, antes de começar efetivamente um projeto. É um processo bastante passo a passo e vou explicá-lo rapidamente.

Basicamente, começa-se por dedicar bastante tempo a criar alinhamento em toda a organização através de um processo passo a passo. Só depois, quando pensamos que toda a gente está alinhada, começamos. O interessante é que esta abordagem foi adotada em muitas organizações maiores, como, por exemplo, instituições financeiras.

Mas, quando passámos do modelo em cascata para a metodologia Ágil e o Scrum, pensámos que isso significava não precisarmos de ter clareza sobre o destino e apenas termos de pensar no que iríamos fazer nas duas semanas seguintes. Não, essa não era a intenção do Ágil. A intenção do Ágil era entregar algo significativo a cada duas semanas, sabendo claramente onde estamos a tentar chegar dentro de alguns meses.

Como se faz isso? A forma como abordo a questão é, por exemplo, quando lidero um projeto ou produto em que percebo que existe muita falta de clareza, a primeira coisa que faço é marcar reuniões individuais com os intervenientes do meu produto. Têm de ser reuniões individuais, não num ambiente de grupo, porque, quando alguém partilha uma opinião sobre temas sensíveis, outra pessoa pode intervir.

E nós, enquanto pessoa responsável pelo produto, deixamos de conseguir assimilar corretamente todo o contexto necessário. É preciso ouvir cada pessoa individualmente e garantir que compreendemos realmente as suas perspetivas. Imaginemos que estamos a lidar com uma decisão de compromisso: devemos construir X ou não? É uma decisão binária, mas este modelo funciona para muitas outras coisas.

Reunimo-nos com cada pessoa, percebemos a sua perspetiva sobre o motivo pelo qual algo deve ou não ser feito e perguntamos também quais são algumas das coisas a que devemos prestar atenção ao tomar essa decisão. É provável que nos indiquem quatro ou cinco coisas diferentes que são muito importantes para essa pessoa e para a sua área.

Isto é ainda mais importante no mundo da I&D. Quanto mais técnico for o produto, ou quanto mais dependências técnicas tiver de outras ferramentas dentro da organização, mais importante se torna, porque existem especialistas no assunto. Passamos à pessoa seguinte, depois à seguinte, reunindo-nos individualmente com toda a gente.

À medida que o tempo passa, pode acontecer que a nossa própria opinião sobre qual deve ser a decisão de compromisso se torne mais forte, que comecemos a desenvolver novas opiniões ou que os próprios compromissos mudem. Percebemos que há certas coisas que pensávamos serem mais difíceis do que realmente são, ou mais fáceis do que pensávamos, e ajustamo-las.

Mas, ao longo do caminho, à medida que recolhemos mais informação individualmente, voltamos a algumas dessas pessoas e dizemos: “Quando nos reunimos inicialmente, disse-me que estas eram as suas maiores preocupações: 1, 2 e 3. A partir das minhas conversas com outras pessoas, acredito que não deveriam ser preocupações. Eis o meu argumento. Diga-me por que razão estou errado ou diga-me se tenho razão”.

Ao passar por este processo de discussão e troca de ideias, que demora tempo, acabamos por perceber que muitos dos desafios que a equipa enfrentava resultavam realmente de falta de comunicação. Ninguém estava a dedicar tempo a explicar claramente todos estes diferentes compromissos aos vários intervenientes da organização, e muitas questões acabavam por ser resolvidas.

Com o passar do tempo, obtemos cada vez mais clareza sobre todos os diferentes compromissos a que temos de prestar atenção. Esta abordagem também pode funcionar para as prioridades do produto, aliás. Podemos falar um pouco sobre isso mais tarde. Mas, a dada altura, percebemos que talvez ainda existam alguns itens que geram opiniões diferentes. Por exemplo, metade da equipa pensa que determinado atributo é muito importante, como a segurança. A outra metade pensa que a segurança não é um atributo muito importante.

E têm as suas próprias razões para pensar assim. É nesse momento que organizamos uma reunião de grupo. Dizemos: “Para tomarmos esta decisão, este é um atributo muito relevante para nós. Existem duas perspetivas diferentes. Gostaria que tivéssemos uma conversa sobre o assunto”. Através dessa conversa em direto, normalmente conseguimos chegar a uma decisão.

Por vezes, existem alguns itens de ação, como: “Vamos investigar isto melhor”. Muito bem. Podemos organizar a reunião seguinte e voltar a dizer: “Este era o nosso objetivo inicial. Fizemos a pesquisa. Esta é a nova descoberta. O que fazemos agora?” Mas chegamos a uma decisão. Quando temos uma visão muito clara de todos esses compromissos, torna-se muito mais fácil, enquanto equipa, decidir se devemos seguir um determinado caminho ou definir as prioridades do produto. É então que podemos dizer: “Está bem, decidimos que esta é a nossa prioridade e vamos concentrar-nos nela”.

A um nível muito elevado, penso no processo da seguinte forma: primeiro passo, começar com reuniões individuais para compreender claramente a perspetiva de cada pessoa. Segundo passo, trocar ideias entre essas pessoas, se necessário, para garantir que todos os itens sobre os quais têm opiniões diferentes ficam resolvidos. Caso contrário, assinalá-los para discussão em grupo.

Depois, terceiro passo, realizar as discussões em grupo. Finalmente, isto resultará numa estratégia de produto, numa especificação de produto ou num conjunto de prioridades de produto coerente. Em cada um destes cenários diferentes, pode existir um passo adicional. Por exemplo, para as prioridades do produto, é necessário pensar mais sobre qual é o objetivo.

Talvez seja necessário dedicar algum tempo no início a dizer: “O nosso objetivo é lançar algo rapidamente e aprender”. Depois, queremos perceber se alguém discorda. Se todos concordarem, ótimo, podemos avançar e continuar este processo.

Hannah Clark: Sim, gostaria de falar um pouco mais sobre as prioridades do produto em geral. Penso que é algo que, mesmo quando estamos relativamente próximos de um consenso ou sentimos que concordámos sobre os objetivos e sobre o que é o sucesso, pode continuar a ser difícil equilibrar algumas prioridades concorrentes.

E, claro, existem centenas de estruturas diferentes para definir prioridades de funcionalidades de produto. Quais são alguns dos métodos que utilizou e que considera mais bem-sucedidos e amplamente aplicáveis quando trabalha com prioridades concorrentes nestes contextos?

Bijan Shahrokhi: Penso que uma das abordagens que utilizo é atribuir-lhes uma pontuação e analisá-las através de algumas perspetivas diferentes.

A primeira é o impacto que penso que determinada funcionalidade ou produto terá no meu público-alvo ou nos meus utilizadores-alvo. A segunda é a probabilidade de conseguirmos efetivamente concretizar esse impacto. Em muitos casos, nem sequer temos a certeza de que iremos conseguir fazê-lo, ou de que o nosso novo produto irá realmente ter impacto no público, certo?

Nesse caso, a probabilidade é menor. A terceira é a facilidade de implementação. A fórmula que tenho em mente é: “impacto multiplicado pela probabilidade do impacto, mais a facilidade de implementação”. Para o impacto, utilizo uma escala de um a cinco, sendo cinco o impacto mais elevado e um o impacto mais baixo.

Quanto à facilidade de implementação, se for cinco, significa que é fácil de implementar. Se for um, significa que exige muito esforço. A partir daí, obtemos uma pontuação. O que gosto nesta abordagem é que é objetiva e, através do processo que acabei de descrever, com as reuniões individuais e as conversas sucessivas, também podemos ter conversas semelhantes.

Podemos voltar a falar com um membro da equipa e dizer: “Veja, a partir das minhas conversas com toda a gente, esta é a minha tabela sobre quais penso serem os diferentes projetos-chave dentro da organização. Esta é a minha perspetiva sobre a pontuação de cada um em termos de impacto e esforço de implementação. Com base na forma como os classifiquei, este é o resultado relativo aos projetos de nível cinco”.

Essa pessoa pode responder: “Em primeiro lugar, penso que se esqueceu destes três projetos em que também estamos a trabalhar”. Ou: “Este projeto que incluiu deveria ser dividido em três, porque é muito maior do que imagina”. Também pode discordar da avaliação do impacto ou do esforço. Mas, nesse momento, começamos a ter conversas muito objetivas. Passamos a falar mais sobre os itens em si.

O interessante deste sistema de pontuação é que, como não estamos a tentar estimar exatamente quanto tempo tudo vai demorar e estamos a analisar cada elemento de forma relativa, comparando-o com outros projetos, torna-se muito mais fácil chegar rapidamente a algum tipo de consenso sobre o valor que será entregue ou o esforço que será necessário. Isso resulta num conjunto de prioridades claramente definidas, que nos permite dizer: “Está bem, estas cinco são aquelas em que nos vamos concentrar no próximo trimestre”.

Sempre que surge um novo item, ou quando um novo membro da equipa ou alguém dentro da organização nos diz: “Devíamos fazer isto”, consultamos a tabela de prioridades e respondemos: “Vamos analisar. Já discutimos isso. Decidimos que, neste momento, não é uma prioridade por esta razão, mas, quando terminarmos estes dois ou três itens, iremos dar-lhe prioridade”.

Por vezes, percebemos que há coisas adicionais que precisam de ser incluídas. Também podemos falar sobre como pensar nesses cenários.

Mas penso que esta abordagem é mais objetiva e facilita a definição de prioridades.

Hannah Clark: Sim, agradeço essa explicação. Já falámos no Product Manager sobre a importância de despersonalizar o feedback e algumas destas conversas sobre prioridades, para que as pessoas não sintam que existe uma razão pessoal para o seu projeto de estimação ou a sua agenda terem perdido prioridade ou terem sido colocados numa sequência de prioridades diferente daquela que consideravam adequada.

É um método muito concreto e aprecio-o bastante. Desculpe, o que disse que queria abordar novamente? Referiu há pouco que falaríamos sobre isso dentro de instantes.

Bijan Shahrokhi: Disse que também podíamos falar sobre situações em que alguém afirma que determinado item tem de ser uma prioridade e nós percebemos que, por qualquer razão, ele realmente precisa de o ser.

Como lidamos com isso? Por vezes, podemos pensar em como fazê-lo, mas não podemos simplesmente acrescentá-lo à lista de prioridades. Temos de considerar que, se quisermos avançar, teremos de o fazer de uma forma que não afete a velocidade de entrega dos itens que já têm prioridade elevada.

Existem algumas outras abordagens. Uma é retirar algo da lista, atribuindo-lhe uma prioridade inferior. Nesse caso, esse item é substituído pelo novo através do sistema de pontuação. Outra possibilidade é ter recursos adicionais a trabalhar neste novo item prioritário. O princípio que seguimos é que as coisas que estão na lista de prioridades não vão ficar mais lentas apenas porque acrescentámos outro item à lista.

Na minha opinião, esta é uma das funções de um gestor de produto, embora não o seja em algumas organizações. É aí que começamos a ter problemas com coisas que não são entregues.

Penso que um excelente gestor de produto presta muita atenção a este aspeto e garante que, quando surge nova informação que exige dar prioridade a outra coisa, pensa em como lidar com a situação. Ou retiro algo da lista, ou garanto que obtenho recursos adicionais capazes de trabalhar no novo item sem afetar a velocidade de entrega do outro.

Hannah Clark: Fascinante. Queria mudar um pouco de assunto, já que estamos a aproximar-nos do fim, porque queria falar um pouco sobre produtividade, que é outra área pela qual sei que é muito apaixonado e provavelmente uma das principais razões pelas quais decidiu fundar a productmonkey.ai.

Gostaria de saber se tem algumas dicas de produtividade relacionadas com produtos, de forma geral, para o nosso público, e também algumas informações sobre a Product Monkey AI que as pessoas possam considerar interessantes. É uma ferramenta muito interessante.

Bijan Shahrokhi: Claro. O que estou a fazer com a Product Monkey AI é automatizar a tarefa que considero muito necessária para nós, enquanto gestores de produto, mas que não gosto de fazer: passar muito tempo a escrever requisitos detalhados e critérios de aceitação, pelas razões que mencionei anteriormente.

Na Product Monkey AI, tentamos obter o máximo de informação possível sobre o projeto específico em que está a trabalhar, sobre a sua organização e sobre o fluxo de utilizador específico com que está a lidar.

Depois, com uma orientação adequada da sua parte e utilizando inteligência artificial, conseguimos fornecer-lhe requisitos de produto detalhados, critérios de aceitação, cenários de teste e até eventos e métricas a que deve prestar atenção quando construir efetivamente o produto. Assim, pode pegar nesse material e começar a trabalhar, obtendo um rascunho rápido que corresponde a cerca de 80% do trabalho necessário para os seus tickets de engenharia e documentos de requisitos do produto, antes de os colocar nos documentos principais.

Depois, pode dedicar o seu tempo aos últimos 20% para os aperfeiçoar. Penso que um dos benefícios que podemos proporcionar enquanto gestores de produto, como referi, é trazer clareza. E penso que a Product Monkey AI pode fazer isso ao reduzir o tempo necessário para que os gestores de produto tragam clareza às equipas de engenharia.

Hannah Clark: Fantástico. Tenho a certeza de que muitas das pessoas que nos estão a ouvir encontrarão muito valor nessa ferramenta. Bijan, muito obrigada por se juntar a nós hoje. Onde é que as pessoas podem acompanhá-lo online se quiserem saber mais sobre aquilo que está a fazer?

Bijan Shahrokhi: Podem encontrar-me no Twitter, ou X, como agora lhe chamamos. O meu nome de utilizador no X é bijan_sha. Podem encontrar-me lá. Também podem visitar a PM Exercises ou a Product Management Exercises. Podem pesquisar qualquer uma delas. Irão encontrar o nosso site e poderão entrar em contacto comigo também através desse meio.

Hannah Clark: Fantástico. Muito obrigada pelo seu tempo.

Bijan Shahrokhi: Muito obrigado pelo convite.

Hannah Clark: Obrigada por nos ouvirem. Para obter mais perspetivas ú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 The CPO Club na plataforma onde costuma ouvir os seus podcasts.