Como corrigir o rumo quando o roteiro é constantemente desviado

Ler a transcrição:

 

Estamos a experimentar transcrever os nossos podcasts através de um programa de software. Perdoe quaisquer erros de digitação, pois o robô não está correto a 100%.

 

Hannah Clark: Os roteiros de produto, tal como os roteiros reais, acabam inevitavelmente por sofrer atrasos. Alguns podem ser previstos e planeados, enquanto outros surgem simplesmente do nada, mas, na maioria das vezes, é possível encontrar um desvio e voltar ao caminho certo. Mas e se notar um padrão preocupante: os objetivos não estão a ser cumpridos, os prazos estão constantemente a ser prolongados e parece que todo o roteiro está sempre a descarrilar?

No episódio de hoje, vai ouvir Michael Pierce, Diretor de Gestão de Produto no Public Consulting Group, que defende que um roteiro constantemente atrasado pode ser um sintoma de desalinhamento entre a estrutura da empresa e a estrutura da equipa de produto. Por isso, se está a ter dificuldades em perceber por que razão os seus objetivos e iniciativas nunca parecem concretizar-se da forma que previu, esta pode ser a correção de rumo de que precisa. Vamos começar.

Olá, ouvintes. Bem-vindos novamente ao podcast Product Manager. Estou aqui com Michael Pierce. É o Diretor de Gestão de Produto no Public Consulting Group. Michael, muito obrigada por se juntar a nós hoje.

Michael Pierce: Sim. Obrigado, Hannah. Estou ansioso por estar aqui.

Hannah Clark: Michael, pode começar por nos falar um pouco sobre o seu percurso e sobre como chegou onde está?

Michael Pierce: Sim, claro. Comecei por tirar uma licenciatura em Economia, como muitas pessoas que trabalham em produto, certo? Temos percursos muito variados. Estava a trabalhar numa corretora de seguros e, nessa altura, um amigo deu-me um exemplar de Lean Startup. Comecei a lê-lo e a pensar nos vários processos de trabalho que eram ineficientes, numa espécie de mentalidade de produto ainda muito imatura.

Acabei por criar uma espécie de programa VBA sofisticado, aprendi sozinho algum código Visual Basic e comecei a automatizar tarefas. Foi aí que comecei a interessar-me por aquilo que, na altura, ainda não era tão popularizado como é hoje: a gestão de produto.

Falar com os utilizadores, perceber do que precisam, tentar criar uma solução e acompanhar a sua evolução ao longo desse processo. Pouco depois, criei a minha primeira startup. Era na área aquática. Trabalhávamos com muitas piscinas; a cidade de Denver, aqui no Colorado, onde vivo, era um dos nossos clientes, o que foi muito entusiasmante para nós. Mas foi realmente aí que começou o meu percurso em produto.

Falávamos com os utilizadores e criávamos uma espécie de roteiro, quase no estilo agora, a seguir e mais tarde, porque ainda estava numa fase muito inicial do meu percurso em produto. Foi, no entanto, uma excelente entrada nessa área. Alguns anos mais tarde, passei por uma situação de aquisição de talento e fui trabalhar para uma empresa em Boston. Foi uma experiência maravilhosa. Pouco depois, acabei por chegar à minha empresa atual, o Public Consulting Group, como Diretor de Gestão de Produto.

Hannah Clark: Fantástico. Ao longo da sua carreira, trabalhou com várias equipas, por vezes como membro da equipa, mas muitas vezes como líder. Quais são alguns dos desafios que considera, de certa forma, endémicos das equipas de produto em geral?

Michael Pierce: Penso que um grande desafio que muitas pessoas de produto nem sempre reconhecem é a necessidade de olhar para a empresa onde trabalham e tentar defini-la em duas grandes categorias. Uma é: a empresa é orientada pelas vendas? Pelas finanças? Pelo marketing? Todos já vimos excelentes exemplos disso.

Se olharmos para a HubSpot, por exemplo, no que diz respeito ao marketing, é claramente uma empresa orientada pelo marketing. Se olharmos para uma empresa como a Zoom ou a Slack, são exemplos clássicos de crescimento orientado pelo produto muito forte e de liderança orientada pelo produto. Por isso, é muito importante que as equipas de produto olhem para a sua empresa e pensem: o CEO reúne frequentemente com o departamento de vendas? Existe uma relação muito próxima?

Ou será que parte da liderança da empresa veio das operações, das vendas ou de outra função? Isso pode ser uma pista sobre a forma como a empresa funciona. Diria que outra coisa importante que as equipas de produto devem fazer para compreender a cultura da empresa é pensar na forma como são tomadas as grandes decisões.

É tudo completamente decidido de cima para baixo? É a liderança de topo que debate as decisões com outros gestores e executivos? É um processo muito democrático? Compreender a estrutura através da qual as empresas tomam decisões importantes é igualmente essencial. Se souber essas duas coisas — se a empresa é orientada pelas vendas ou pelas finanças e qual é a estrutura de tomada de decisões — isso pode ajudar o departamento de produto a perceber como se enquadra no panorama geral e como estão definidas as dinâmicas que terá de saber gerir.

Se ignorar toda essa informação e simplesmente prosseguir o seu dia como departamento de produto, pode deparar-se com muitos bloqueios e desafios, porque talvez não esteja a posicionar-se da forma correta para influenciar as outras pessoas na organização.

Hannah Clark: Talvez possamos enquadrar isto através de um exemplo. Quais são alguns exemplos de situações em que o desalinhamento entre a forma como a equipa de produto se vê e a forma como a empresa funciona pode causar problemas mais tarde?

Michael Pierce: Claro. Se compreendi corretamente a pergunta, um exemplo seria o facto de existir atualmente muita energia em torno do crescimento orientado pelo produto.

Eu gosto pessoalmente do crescimento orientado pelo produto — sou um pouco tendencioso —, mas se o departamento de produto estiver a operar de uma forma muito focada nesse modelo, enquanto a empresa é, na realidade, orientada pelo crescimento através das vendas, isso irá causar um grande desalinhamento no que diz respeito ao financiamento das iniciativas e à obtenção do apoio de diferentes departamentos.

Por isso, é realmente importante reconhecer o lugar do seu departamento e da sua função em relação a todas as outras funções, de modo a calcular os seus movimentos enquanto equipa.

Hannah Clark: Vamos falar um pouco sobre a priorização e os desafios que lhe estão associados. Penso que é algo com que todas as equipas de produto têm dificuldades, até certo ponto, independentemente do modelo de crescimento. Que desafios encontrou relativamente à priorização nas empresas onde trabalhou?

Michael Pierce: Há duas coisas que me vêm à cabeça. Uma delas é existir frequentemente uma diferença entre o estado ideal, ou a mentalidade de lista de desejos sobre aquilo que estamos a construir, e a realidade.

Um dos desafios da priorização surge quando se trabalha com conselhos de administração, empresas cotadas e investidores. Trabalhei em algumas empresas detidas por fundos de capital privado. Pode existir muita pressão para ter um roteiro enorme, cheio de coisas divertidas e apelativas.

O desafio consiste em trazer toda a gente de volta à realidade, mas de uma forma que faça as pessoas sentirem-se bem. Quando falamos de priorização, é necessário alinhar as pessoas relativamente aos aspetos de nível superior. A priorização só acontece depois de se saber: esta é a nossa visão, esta é a nossa estrela-guia.

É necessário definir esses elementos de nível superior para ter uma priorização eficaz. Talvez essa seja outra armadilha. Quando se alinham as partes interessadas e os executivos em torno da visão, da forma como o sucesso será medido, da estrela-guia, dos indicadores-chave de desempenho e dos objetivos e resultados-chave, torna-se muito mais fácil ter um processo de priorização saudável e afastar-se da mentalidade de lista de desejos inchada, avançando para algo muito mais claro.

Pode haver muitos itens, mas estão muito bem definidos. Enquanto organização, sabemos que estas quatro grandes funcionalidades ou iniciativas estão fortemente ligadas a estes dois objetivos e resultados-chave, que sabemos serem realmente importantes para o CEO e para a organização. É assim que penso, pelo menos, no problema da priorização.

Hannah Clark: Numa conversa anterior, partilhou comigo um exemplo sobre a análise de uma empresa. Não vamos dizer qual era a empresa, mas havia alguns problemas relacionados com objetivos que não estavam a ser cumpridos e pediram-lhe que identificasse as razões. Pode falar-nos um pouco sobre isso e recordar esse exemplo?

Michael Pierce: Sim, claro. Foi um caso em que a empresa não estava a cumprir uma grande parte dos itens do roteiro e queria saber porquê, o que é uma pergunta perfeitamente legítima. Enquanto pessoa de produto, vejo o roteiro como algo que resulta frequentemente de muitos outros processos. É o resultado de uma grande caixa de interações complexas e de contributos que entram nessa caixa.

Uma das primeiras coisas que fiz foi analisar as várias camadas para perceber: se estamos a falhar 50% dos itens do roteiro, quais são as causas principais? Uma delas, antes de avançar na exploração, era perceber se tínhamos simplesmente demasiados itens no roteiro.

Se tiver um roteiro que, por exemplo, exige 2000 horas, mas apenas dispõe de 1000 horas de capacidade de desenvolvimento, é evidente que irá falhar metade desses itens. Contudo, tanto quanto conseguia perceber, havia engenheiros, profissionais de garantia de qualidade e todo o pessoal de apoio suficiente para executar o roteiro.

Por isso, aprofundei a análise para compreender por que razão a empresa continuava a falhar muitos desses itens. Ao fazer a análise, descobri algumas coisas. Uma delas era que as equipas de desenvolvimento estavam organizadas de modo a serem partilhadas por vários produtos. Para uma pessoa de produto, o desafio de criar um bom roteiro é precisar de ter confiança de que existem cinco recursos fixos: estes cinco engenheiros trabalham neste produto e trabalham, digamos, 40 horas por semana. Talvez tenham 30 horas semanais de eficiência, porque existem distrações, mensagens no Slack, e-mails ou outras coisas. Assim, é possível analisar esse tempo, projetá-lo ou fazer uma previsão e perceber qual é a probabilidade — 80%, 90% — de cumprir o roteiro.

Mas o grande desafio do desenvolvimento partilhado é que, se houver um incêndio noutro produto ou se for celebrado um contrato enorme para um dos produtos do portefólio, isso pode fazer descarrilar fortemente o roteiro da empresa e o roteiro desse produto específico. Essa foi uma das causas principais que encontrei: o desenvolvimento partilhado.

A outra grande causa era o elevado volume de trabalho não planeado e de defeitos. O roteiro tinha sido criado com um elevado nível de confiança de que poderia ser cumprido. No entanto, quando as equipas se deparavam com problemas — talvez fosse necessário atualizar uma grande dependência, talvez surgisse um contrato importante que obrigasse a retirar recursos, ou talvez algum código fosse colocado em produção e fosse encontrado um erro —, todas essas situações podiam impedir a conclusão do roteiro.

Enquanto profissionais de produto, sabemos que existem muitas variáveis. Tentamos sempre perceber quais são fixas e quais são dinâmicas, para depois fazermos uma previsão de produção. Mas, à medida que aumenta o número de variáveis diferentes, diminui a probabilidade de concluir com sucesso esse trimestre ou esse ano fiscal.

Hannah Clark: E isso diz respeito apenas ao que está no roteiro. Nem sequer estamos a falar dos problemas que isso pode causar relativamente à inovação ou a tudo aquilo que vem a seguir.

Michael Pierce: Exatamente.

Hannah Clark: Então, na sua opinião, quais são algumas das formas de proteger o roteiro? Já contabilizámos todo o tempo de que precisamos para executar o roteiro, mas também existe o tempo de que sabemos que vamos precisar no futuro para inovar, criar novas funcionalidades e responder às funcionalidades que a equipa de vendas quer que sejam desenvolvidas para um determinado cliente. Como podemos proteger o roteiro e esse tempo?

Michael Pierce: É uma excelente pergunta. O primeiro passo que sugeriria a uma pessoa de produto seria analisar os trimestres anteriores e estabelecer uma boa base mental, recorrendo ao conceito clássico de que o tempo de ontem ajuda a prever o tempo de amanhã. Se no trimestre passado houve 20% de erros, 20% de pedidos de funcionalidades por parte de novos clientes e 10% de apostas de inovação, pode utilizar a soma desses valores para prever os roteiros futuros.

Uma boa forma de alinhar a organização em torno do roteiro é divulgar a ideia de que um roteiro deve ser uma alimentação equilibrada. Por exemplo, pode ter 40% de novas funcionalidades, com base nos dados históricos, 10% ou 15% de tempo dedicado a defeitos e talvez 20% de margem para um grande pedido de vendas que possa surgir.

Pode chegar a uma proporção adequada dos tipos de tarefas que devem ser realizadas e em que quantidades, tal como numa dieta. Penso que este é um excelente primeiro passo para os profissionais de produto: garantir que existe a proporção correta e comunicá-la às partes interessadas.

Assim, ninguém será apanhado de surpresa se 10% do tempo dos engenheiros for utilizado numa aposta interessante ou numa funcionalidade mais ambiciosa, porque isso já foi comunicado previamente. Isto permite que as equipas tenham muito mais autonomia para dizer respeitosamente que não: gostaríamos muito de fazer esse ajuste adicional à funcionalidade, mas estamos comprometidos em dedicar 10% da nossa capacidade deste trimestre à exploração de uma nova função que poderá ajudar bastante as vendas no próximo ano.

Mais uma vez, tudo se resume às expectativas — tanto para as equipas e os profissionais de produto como para a direção de topo ou para as diferentes partes interessadas.

Hannah Clark: Falando de equipas, qual é a relação entre a forma como as equipas são concebidas e o impacto daquilo que é priorizado e lançado?

Michael Pierce: Penso que isso remete para o que estávamos a falar inicialmente sobre empresas orientadas pelo produto ou pelas vendas. Muitas vezes, é possível analisar a forma como as equipas são concebidas com base na cultura da organização.

Se a organização tiver uma cultura de vendas muito agressiva — agressiva no bom sentido, isto é, tentando conquistar muitos negócios novos e com muita energia em torno desse objetivo —, isso irá afetar, em certa medida, a forma como as equipas são concebidas, porque talvez exista muito mais trabalho de desenvolvimento de funcionalidades.

Pode ser necessário ter equipas dedicadas exclusivamente a fazer personalizações para clientes. Grande parte da estrutura da equipa irá surgir naturalmente daquilo que a organização ou empresa valoriza, seja uma abordagem centrada nas vendas, nas finanças ou no produto, bem como das suas ideias e valores relativamente a trabalho novo ou a funcionalidades desenvolvidas de raiz.

Tudo isso pode influenciar a forma como uma equipa é concebida. Também pode ser útil falar sobre a estrutura existente para executar o trabalho. Ouvimos falar constantemente de métodos ágeis. No passado, havia mais empresas a utilizar o modelo em cascata, e existem várias outras formas de as empresas se organizarem.

Por isso, outra questão importante na conceção das equipas é compreender esse contexto: temos uma cultura muito orientada para os métodos ágeis? Somos de alguma forma orientados para o modelo em cascata? Tudo isso terá impacto na composição da equipa.

Mas, quando compreende esse contexto, pode, enquanto profissional de produto, defender as áreas em que identifica lacunas. Pode dizer: compreendo que no passado éramos fortemente orientados para o modelo em cascata. Temos este novo produto que vamos lançar no mercado. Vamos experimentar utilizar um processo ágil neste caso, ou passar de uma equipa de engenharia partilhada para uma equipa de engenharia dedicada.

Ter esta informação contextual é muito útil para as equipas de produto.

Hannah Clark: Já teve uma experiência desse tipo, em que precisou de experimentar reestruturar uma equipa para corresponder à forma como a empresa precisava de funcionar?

Michael Pierce: Sim, sem dúvida. A última empresa onde trabalhei era uma empresa de capital privado de Boston. Contrataram-me para criar um departamento de produto de raiz.

Como parte desse trabalho, analisei a forma como todas as equipas trabalhavam e como estavam organizadas. A empresa tinha vários produtos e, na prática, existia uma combinação de modelo em cascata e alguma desorganização. Depois de analisar tudo e falar com os proprietários e com o CEO, disse-lhes que parecia existir uma oportunidade para reestruturar a forma como as equipas trabalhavam e a forma como estavam agrupadas, de modo a funcionarem em prol do valor do portefólio geral de produtos.

Foi uma excelente experiência, porque tivemos a oportunidade de implementar métodos ágeis em todas as equipas. Pudemos agrupar diferentes equipas, distinguindo entre equipas de plataforma e equipas que trabalhavam diretamente nos produtos. Também capacitámos algumas pessoas para assumirem funções mais próximas das de gestores técnicos de produto, em vez de desempenharem o papel clássico de gestor de produto numa oferta de software como serviço normalizada.

Foi uma oportunidade fantástica para, enquanto profissional de produto, analisar de forma holística a estrutura existente e poder sugerir e recomendar a melhor forma de organizar as equipas. Medir a situação antes e depois foi realmente interessante. Vi melhorias na eficiência resultantes da realização de reuniões diárias, demonstrações de sprint e de todas essas práticas, que tiveram um impacto muito positivo e significativo na organização.

No mínimo, é isso que podemos pedir enquanto profissionais de produto: ter a capacidade de causar impacto e medir esse impacto.

Hannah Clark: Sem dúvida. Tendo passado por essa experiência, consegue recomendar alguns sinais de alerta que os profissionais de produto, especialmente os líderes, devam procurar e que possam indicar que seria uma boa ideia começar a reestruturar ou a pensar em reestruturar a equipa?

Michael Pierce: Sim, sem dúvida. Diria que um dos sinais de alerta é a necessidade de obter dados sobre estas questões. Um deles seria analisar o tempo total necessário para passar da ideia à produção. Se esse tempo estiver muito atrasado em comparação com o normal, isso pode ser um sinal de alerta. É difícil, porque não existem necessariamente muitos valores de referência publicados para estas situações.

Mas imaginemos que um novo desenvolvimento de funcionalidade, relativamente pequeno, demora duas semanas a chegar à produção. Isso é bastante bom, certo? O ciclo médio de um sprint é de duas ou três semanas. Enquanto profissional de produto, não consideraria necessariamente isso um sinal de alerta.

Mas se estiver a analisar uma pequena parte de funcionalidade que, por exemplo, exige 40 horas de desenvolvimento, e a sua entrada em produção demorar cinco, seis, sete ou oito semanas, isso seria, para mim, um sinal de alerta de que talvez exista um estrangulamento na garantia de qualidade ou na obtenção dos contributos das partes interessadas certas para essa funcionalidade ou para o documento de requisitos funcionais.

Esses seriam indicadores de que, ao considerar todo o sistema como uma caixa com entradas e saídas, os resultados não correspondem ao que seria expectável tendo em conta uma base normal.

Hannah Clark: Como mediria o sucesso da reestruturação das equipas?

Michael Pierce: Há várias formas de o fazer. As mais clássicas passam por analisar o resultado da equipa. Está a entregar mais incrementos de valor aos clientes finais num período de tempo mais curto? Outra forma clássica seria perceber se estamos a reduzir o tempo entre a ideia e a produção.

Estamos a tornar-nos mais rápidos e mais ágeis — aproveitando o trocadilho — na passagem do trabalho do ponto A para o ponto B? Outra forma frequentemente esquecida é combinar conversas individuais, acompanhar as pessoas e transmitir essas conclusões aos executivos, juntamente com um inquérito clássico que meça a situação antes e depois da reestruturação.

Como se sentiam os membros da equipa? Sentem que são menos puxados em direções diferentes, reduzindo a alternância entre tarefas? Sentem-se mais capacitados para tomar decisões com as pessoas certas e concluir o trabalho? Tudo isso são excelentes indicadores para avaliar a reestruturação, perceber se funcionou e se produziu resultados positivos.

Hannah Clark: Excelente. Para concluir, quais foram os resultados da sua experiência de reestruturação da equipa?

Michael Pierce: É uma excelente pergunta. Uma coisa que ficou evidente desde o início, quando falei com as pessoas, foi a redução significativa da falta de entendimento partilhado relativamente às questões e à ambiguidade do trabalho que a equipa estava a realizar. Antes de eu chegar à empresa, reuniam uma vez por semana.

Quando reestruturámos a equipa, passámos a realizar reuniões diárias. Assim, a equipa conseguia obter respostas às suas perguntas todas as manhãs, junto das pessoas certas. Isso aumentou realmente o volume de trabalho produzido, mas também reduziu a ansiedade dos programadores, porque não ficavam uma semana inteira à espera de respostas.

Se não tinham a certeza sobre algo, no dia seguinte podiam, esperava-se, obter uma resposta. Não acontecia em todos os casos, mas acontecia na maioria. Penso que isso fez com que a equipa se sentisse muito mais apoiada em toda a organização.

Hannah Clark: Para terminar, vamos falar um pouco sobre como obter o apoio das partes interessadas de nível superior. Quais são algumas das formas que utilizou com sucesso para provar, ou dar alguma indicação de prova, de que a reestruturação compensaria o investimento inicial?

Michael Pierce: Uma grande parte da reestruturação consiste em pensar naquilo a que, embora não goste de lhe chamar assim, poderíamos chamar uma caixa negra. Quando pensamos em todas as complexidades envolvidas na passagem do ponto A ao ponto B durante o desenvolvimento de software, percebemos que o software é complicado.

É complexo. Existem todo o tipo de reviravoltas. Por isso, ao considerar uma reestruturação, é importante falar com os executivos e com as partes interessadas de nível superior sobre o resultado real que se pretende alcançar. Quais são os objetivos e resultados-chave? Que resultados fundamentais estão a tentar promover na organização?

Depois, pode utilizar isso como referência ou base para avaliar a eficácia da organização do trabalho. O mesmo se aplica à medição do trabalho em geral: é essencial saber quais são os valores de referência e medir em relação a algo, para perceber até que ponto o objetivo foi alcançado.

Hannah Clark: Excelente. Michael, muito obrigada por se juntar a nós. Sei que é colaborador do The CPO Club. As pessoas podem ler o seu trabalho em TheProductManager.com, mas de que outras formas podem encontrá-lo online?

Michael Pierce: Exatamente. Diria que a melhor forma de me encontrar online é através do LinkedIn. Sou minimalista digital, por isso só tenho LinkedIn. Mas, se me enviar uma mensagem por lá, terei todo o gosto em conversar virtualmente com qualquer ouvinte do podcast.

Hannah Clark: Excelente. Muito obrigada pelo seu tempo e agradeço imenso os seus conhecimentos.

Michael Pierce: Sem dúvida. Obrigado, Hannah.

Hannah Clark: Obrigada por nos ter acompanhado. Para obter mais conhecimentos, 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.