Vão todas as estradas dar à fábrica de funcionalidades?

Ler a transcrição:

Estamos a experimentar transcrever os nossos podcasts utilizando um programa de software. Pedimos desculpa por quaisquer erros de digitação, uma vez que o bot não está correto 100% das vezes.

Hannah Clark: Fábrica de funcionalidades — substantivo; uma empresa que lança constantemente produtos, funcionalidades e melhorias, mas que se concentra predominantemente na quantidade em detrimento da qualidade. Origem: John Cutler. Utilizado numa frase: “Lançámos três novas funcionalidades este trimestre e não sei para quem se destina nenhuma delas. Isto está a começar a parecer uma fábrica de funcionalidades.” Se esta definição lhe pareceu demasiado familiar, continue a ouvir.

No nosso painel recente, “Vão todas as estradas dar à fábrica de funcionalidades?”, reunimos três líderes de produto que observaram este fenómeno a partir de perspetivas diferentes. Aakash Gupta — que foi vice-presidente de Produto numa empresa unicórnio e é atualmente autor da publicação The Product Growth Newsletter —, Andrea Saez — líder de marketing de produto e autora de The Product Momentum Gap —, e Paweł Huryn — autor da publicação The Product Compass Newsletter.

Partilham a verdade desconfortável sobre reconhecer o pensamento orientado para resultados produzidos em vez de resultados alcançados, estruturas práticas para manter o foco estratégico perante as pressões do mercado intermédio e estruturas acionáveis para transformar a sua equipa de criadores de funcionalidades em impulsionadores de resultados.

Quer esteja a tentar ultrapassar os cem milhões de receita recorrente anual ou simplesmente a recuperar o espírito inovador da sua equipa, considere esta conversa o seu passe de saída da mentalidade de fábrica de funcionalidades. Vamos começar.

Ah, já agora, temos conversas como esta todas as semanas. Por isso, se isto lhe parece interessante, porque não subscreve? Está bem, vamos começar.

Vamos começar agora a nossa discussão, analisando alguns resultados preliminares da sondagem. Parece que temos uma divisão bastante equilibrada entre as pessoas que consideram que as suas organizações são fábricas de funcionalidades e as que ainda não têm a certeza. Vamos abordar isso através da definição do termo.

Penso que será útil para todos estarmos alinhados quanto ao que queremos dizer quando falamos de uma fábrica de funcionalidades. A definição que estamos a utilizar vem, creio, de John Cutler, que originalmente cunhou o termo. Assim, uma fábrica de funcionalidades é uma empresa que lança constantemente produtos, funcionalidades, melhorias, etc., concentrando-se predominantemente na quantidade em detrimento da qualidade.

Ou seja, concentra-se nos resultados produzidos em vez dos resultados alcançados. O que estamos a sugerir é que nos encontramos numa situação em que vemos que estamos a lançar uma enorme quantidade de funcionalidades, mas nem sempre é claro se essas funcionalidades têm um valor empresarial real ou se realmente correspondem às necessidades dos nossos utilizadores.

Obviamente, isto pode estar associado a alguns problemas. Vamos abordar o tema em três secções. A primeira será sobre o motivo pelo qual uma fábrica de funcionalidades é tão comum. Depois passaremos à segunda secção, que trata das estradas que saem da fábrica de funcionalidades. E a terceira secção será: estamos em modo de fábrica, e agora?

Vamos começar pela primeira secção. A primeira pergunta será dirigida à Andrea. Como é que organizações bem-intencionadas se tornam fábricas de funcionalidades? Como é que isto acontece?

Andrea Saez: Para ser sincera, não existe um único caminho. Muitas pessoas perguntam-me: como posso evitá-lo? Como posso evitá-lo? Há vários caminhos que podem levar-nos nessa direção.

Pode ser tudo, desde tentar fechar vendas, até não ter um bom líder de produto, responsável de produto ou vice-presidente de produto, seja qual for a designação. Pode ser uma questão de HIPPO, pode ser a síndrome do objeto brilhante. Há muitas formas diferentes de lá chegar, mas penso que o problema fundamental seria a falta de influência de um líder de produto que consiga realmente definir uma estratégia e dizer: é isto que vamos fazer e é por isto que o vamos fazer.

É também necessário conseguir negociar quando, por determinadas razões, é preciso lançar uma funcionalidade, mas depois trazer a equipa de volta à estratégia. A realidade é que, por muito que gostasse de estar aqui a dizer que nunca faremos isso e que podemos evitar completamente uma fábrica de funcionalidades, há momentos na carreira de qualquer pessoa e na trajetória de qualquer empresa em que podemos ter de fazer concessões e dizer: está bem, teremos de criar essa funcionalidade porque precisamos mesmo de obter essa receita; precisamos do dinheiro.

Por isso, não penso que seja uma situação totalmente a preto e branco. Há negociações e concessões que têm de ser feitas, mas o importante é ter um líder de produto capaz de dizer: está bem, fizemos isso. Agora vamos regressar à nossa estratégia, àquilo que estamos realmente a tentar fazer e resolver.

Hannah Clark: Aakash, querias acrescentar alguma coisa? Sei que partilhaste anteriormente comigo uma perspetiva que inspirou esta conversa: parece que todas as estradas dão à fábrica de funcionalidades. Qual tem sido a tua experiência no terreno?

Aakash Gupta: Sim, penso que tendemos a dizer: existem estas empresas fantásticas, estão na Silicon Valley — Google, Netflix, Meta — e fazem produto da forma correta. Se fizermos produto como elas, todos os nossos problemas serão resolvidos. Vamos atingir as nossas métricas, o negócio terá sucesso e vamos crescer na nossa carreira. Depois, as pessoas seguem este conselho e rapidamente percebem que existem algumas lacunas.

A principal lacuna que tenho observado é que, quando falo com gestores de produto que trabalham nessas empresas e pergunto qual foi a maior funcionalidade que lançaram no trimestre passado, eles respondem. E eu pergunto: qual foi a origem dessa funcionalidade? Como foi desenvolvida? Quem a criou? Invariavelmente, nessas grandes empresas tecnológicas, todas as funcionalidades com impacto foram decididas pela equipa executiva. Foram debatidas intensamente durante seis meses. Não houve a descoberta clássica de produto, em que o gestor de produto falava continuamente com os utilizadores de duas em duas semanas e encontrava uma solução brilhante que nenhum executivo da Google ou da Meta tinha imaginado, mudando a trajetória da empresa.

Isso simplesmente nunca acontece. Penso, portanto, que existe uma romantização excessiva do que realmente acontece nessas empresas. Em alguns casos, como na Apple ou até no Snapchat, é o diretor executivo, juntamente com alguns designers, que dita praticamente tudo. É uma fábrica de funcionalidades pura.

As pessoas provavelmente romantizam demasiado este modelo e, na realidade, muitas estradas dão a um ambiente semelhante a uma fábrica de funcionalidades. Talvez não aconteça sempre, como a Andrea salientou, mas por vezes existe uma exigência das vendas, do sucesso do cliente ou de outra área.

Todos precisamos de aprender a agir quando estamos nessa situação de fábrica de funcionalidades.

Andrea Saez: Posso ser ligeiramente controversa, já que me pediram para o ser antes desta chamada? Concordo a cem por cento com tudo o que o Aakash disse, mas há algo que considero realmente importante compreender: essas empresas que o Aakash mencionou, com toda a justiça, têm orçamento para fazer essas coisas.

Podem lançar algo para aprender ou simplesmente para ver o que acontece, porque conseguem absorver novamente esse risco. A maioria das empresas não tem orçamento para isso. Quando tentam operar como a Google ou a Apple e dizem simplesmente «lancem», existe aquela ideia do Facebook: «Mova-se depressa e parta coisas».

Essa é a pior coisa que se pode fazer, porque não somos o Facebook. Sejamos realistas: a maioria das pessoas não trabalha numa empresa tecnológica de topo. E, se trabalha, encontra-se na situação que o Aakash descreveu, mas essas empresas podem dar-se ao luxo de fazer essas coisas. Eu não posso dar-me a esse luxo, por isso tenho de agir de forma um pouco mais inteligente.

Hannah Clark: Penso que já temos uma visão de como estas situações se podem desenvolver, quem consegue fazê-lo e quem não consegue.

Se pensarmos nisto como um espetro entre o bom e o mau, ser uma fábrica de funcionalidades é intrinsecamente negativo ou pode funcionar em determinadas circunstâncias, dependendo do modelo de negócio? Existe uma alternativa realista e viável?

Paweł Huryn: Não concordo totalmente com a ideia de que temos sempre de fazer concessões quando escolhemos falar com as partes interessadas sobre funcionalidades, implementar funcionalidades ou analisar pedidos de funcionalidades dos utilizadores. Primeiro, alguns problemas são óbvios. Se recebermos dos interessados, por exemplo, a necessidade de uma integração com a Stripe, então precisamos de uma integração com a Stripe.

Podemos tentar fingir e fazer engenharia inversa até chegar ao problema financeiro, mas, em alguns casos, descobrir e explorar o espaço do problema não é necessariamente necessário. Noutros casos, as partes interessadas, como executivos, vendas ou sucesso do cliente, podem ter conhecimentos que o gestor de produto, ao falar com os utilizadores, não consegue obter.

Por isso, também não gosto de rejeitar completamente esses conhecimentos. Vi muitos gestores de produto que chegam a uma nova organização e começam a falar com os utilizadores. Não havia conhecimento existente na organização, mas muitas partes interessadas passavam centenas de horas com clientes todos os meses. Para mim, rejeitar aquilo que sabem é um desperdício.

No final do dia, as empresas precisam de ganhar dinheiro. Para algumas empresas, por exemplo, se trabalharem num modelo de fornecedor para clientes, fazer aquilo que os clientes pedem, mesmo que os gestores ou as equipas de produto não estejam satisfeitos, é uma forma viável de ganhar dinheiro. Nesse caso, podemos simplesmente sair da empresa em vez de tentar mudá-la, porque esse é o modelo de negócio.

Hannah Clark: Sim, é um ponto justo. Esse é o outro lado da questão: se funciona e mantém a empresa à tona, por vezes é simplesmente assim que as coisas acontecem.

Vamos voltar à Andrea. Vamos passar à segunda secção, que trata das estradas que saem da fábrica de funcionalidades. Vamos abandonar a questão moral — se é bom ou mau — e falar sobre como avaliar se uma organização pode ser considerada uma fábrica de funcionalidades. Como sabemos se a nossa organização está a investir demasiado no curto prazo e pouco no valor a longo prazo? Onde está o equilíbrio?

Andrea Saez: Penso que os primeiros sinais começam por saber se estamos a receber muito feedback negativo, se estamos a observar uma elevada rotatividade de clientes ou se os ciclos de vendas estão a demorar mais tempo. Estes são indicadores de que provavelmente estamos a perder alguma adequação produto-mercado. Normalmente, é nesse momento que começam as decisões do tipo: vamos simplesmente lançar isto, vamos simplesmente criar isto, numa tentativa de salvar determinadas contas ou fechar determinados negócios.

É aí que as coisas começam a ficar fora de controlo. Começamos a ver, sem sequer mencionar determinadas ferramentas, como a Jira, funcionalidades que não se ligam entre si. Faz sentido? É para o nosso público? A experiência do utilizador faz sentido? Pelo amor de Deus, Jira, o que estamos a fazer? As pessoas conseguem navegar facilmente pela interface?

Geralmente, isto acontece quando começamos a perceber que a adequação produto-mercado está a diminuir e já não é tão forte como era anteriormente.

Hannah Clark: Vamos falar um pouco sobre intervenção precoce. Se começarmos a desviar-nos, que verificações e equilíbrios podemos implementar para enquadrar a questão? Sabemos que existe uma influência limitada em determinados níveis da gestão de produto e que nem sempre é possível influenciar a direção da empresa, dependendo da sua maturidade. Há muitos fatores, mas, assumindo que estamos numa posição com influência significativa sobre a trajetória da empresa, que intervenções precoces ou verificações e equilíbrios podemos implementar para nos mantermos focados em entregar valor e sermos fiéis à visão da empresa?

Paweł, queres responder?

Paweł Huryn: Começaria por alinhar o que é importante e qual é a nossa estratégia para toda a organização. Se as equipas não estiverem alinhadas quanto à forma como criamos valor, aos clientes que queremos servir e aos problemas que queremos resolver, pode ser extremamente difícil entregar valor através de diferentes equipas.

O primeiro passo é o alinhamento estratégico e as escolhas que fazemos, para que todos conheçam o contexto estratégico. É aquilo a que a Netflix chama «contexto, não controlo». Depois, é necessário alinhar as equipas em torno dos objetivos, para que todos compreendam qual é o aspeto mais importante na organização ou quais são os objetivos mais importantes, por exemplo, durante o trimestre ou ao longo do ano.

Assim, as equipas podem alinhar os seus objetivos com as prioridades fundamentais da organização. Depois, há a capacitação, que pode exigir orientação, porque nem todas as equipas de produto sabem necessariamente como realizar uma descoberta contínua de produto.

Em termos gerais, por defeito — não em todas as situações, porque existem exceções — queremos capacitar as equipas com problemas relevantes para resolver e resultados pretendidos claros. Dessa forma, podem descobrir como resolver esses problemas, criar valor para os clientes e, em última análise, criar valor para a empresa.

Seria isso: começar pela estratégia e terminar com a capacitação das equipas para iniciarem o processo de descoberta.

Hannah Clark: Sim, há algo que me parece relevante acrescentar. Recentemente, conversei com Cem Kansu, da Duolingo, que é o diretor de produto da empresa, e falámos um pouco sobre a forma como a Duolingo pensa na visão, nos valores e em questões semelhantes.

Na empresa, têm alguns elementos intocáveis que acordaram não alterar, porque são fundamentais para aquilo que são. Isso funciona como uma bússola para algumas decisões e para as decisões a que dizem não.

Achei que era também uma forma interessante de abordar a questão.

Paweł Huryn: Esses elementos são extremamente importantes. Não se trata apenas das coisas em que queremos concentrar-nos, mas também das coisas que declaramos claramente que não fazemos, dos clientes que não servimos e das estratégias que não implementamos, para que todos possam evitá-las.

Hannah Clark: Antes de passar à terceira secção, algum dos participantes quer acrescentar verificações, equilíbrios ou intervenções precoces para garantir que nos mantemos afastados do modo de fábrica de funcionalidades?

Aakash Gupta: Penso que «fábrica de funcionalidades» é uma expressão pejorativa. Não queremos estar numa fábrica de funcionalidades. Mas, se dividirmos os elementos que a compõem, quais serão os mais destrutivos?

A primeira coisa que se pode fazer numa empresa é não se concentrar na área certa do negócio. Fazer com que a equipa executiva se concentre nas partes, nas métricas e nos problemas dos utilizadores que realmente importam é, na minha opinião, a área com maior impacto. Para isso, é necessário trazer conhecimentos que estabeleçam a nossa credibilidade.

Normalmente, penso em dois tipos de conhecimento que quero levar a quase todas as conversas com executivos. Quero ter conhecimentos sobre os utilizadores, fundamentados, idealmente, em gravações de sessões, análises de utilização, conversas baseadas em dados ou, de preferência, gravações de chamadas com clientes.

Depois, quero ter conhecimentos baseados em dados concretos, normalmente relacionados com um modelo de crescimento ou com a dimensão de uma oportunidade. Por exemplo: sabiam que 16% dos nossos clientes ainda não fizeram Y? Se conseguirmos que apenas 50% desses clientes o façam, isso poderá gerar X milhões de euros em receitas.

Se levarmos estes dois tipos de conhecimento aos executivos, começaremos a conseguir orientar o foco para as métricas e os problemas certos.

Esse é o primeiro ponto e corresponde ao que o Paweł disse sobre estratégia. O segundo ponto é permitir que as equipas no terreno — designers e gestores de produto —, enquanto criam protótipos e apresentam modelos aos utilizadores, possam iterar e mudar de direção relativamente àquilo que os executivos tinham inicialmente em mente.

Para isso, considero útil implementar pontos de controlo, como reuniões de revisão de produto, nas quais os executivos continuam a sentir que têm uma palavra a dizer. O que não queremos é que os executivos nos entreguem um design durante o planeamento, que três meses depois lhes enviemos os resultados finais e que eles digam: não implementaram o meu design; foi por isso que não funcionou.

Durante esses três meses, devemos envolvê-los através de várias revisões de produto: o vosso design foi apresentado aos utilizadores e melhorámo-lo por estas razões; foi isto que lançámos.

Para mim, estes são os dois pontos fundamentais de influência que acrescentam algumas táticas à estratégia de alto nível apresentada pelo Paweł.

Hannah Clark: É uma perspetiva muito valiosa. Antes de avançarmos, alguém quer responder?

Andrea Saez: Não diria nada de diferente. Concordo completamente. Não vou ser controversa desta vez. Penso que o Aakash e o Paweł têm razão a cem por cento. A única coisa que acrescentaria é que, enquanto se obtém alinhamento, é preciso garantir que existe realmente alinhamento.

Vejo muitas equipas falharem porque dizem que sim e, uma semana depois, todos estão a tentar fazer coisas diferentes. O alinhamento executivo tem de começar no topo. Todos precisam de estar alinhados quanto ao que estão a fazer, por que razão o estão a fazer, como o estão a fazer e para quem o estão a fazer.

O «quem» tende a ser a maior fonte de desalinhamento, porque todos tentam vender a pessoas diferentes e não existe alinhamento em torno do cliente ideal. Quando se tenta vender a públicos diferentes, começam a surgir funcionalidades que talvez não se adequem.

Hannah Clark: Relativamente à segunda questão, no que diz respeito ao desenvolvimento de funcionalidades de curto prazo, também é verdade que, por vezes, as empresas lançam funcionalidades desligadas do caminho para concretizar a visão, com a plena intenção de regressar mais tarde e aperfeiçoá-las?

No entanto, quando uma empresa entra na espiral da fábrica de funcionalidades, torna-se difícil sair desse ciclo e acaba por nunca regressar às funcionalidades abaixo do ideal que inicialmente deveriam ser melhoradas, criando uma espécie de dívida de funcionalidades. Alguém quer responder?

Paweł Huryn: Presumo que a questão seja sobre lançar funcionalidades que não são ideais ou que estão longe de ser perfeitas. Pelo menos na minha experiência, é precisamente isso que devemos fazer.

Devemos lançar funcionalidades sem implementar todos os detalhes possíveis e todos os casos-limite. Devemos fazer algo que resolva o problema para talvez 70% ou 80% dos utilizadores, nos casos de utilização mais comuns, e recolher feedback. Naturalmente, por vezes isso pode não ser possível, mas, na maioria das organizações de produto em que trabalhei, começámos de forma simples.

Mesmo que existisse um design ou uma ideia sobre aquilo que queríamos alcançar em quatro ou cinco meses, recolhíamos rapidamente o feedback dos utilizadores. Muitas vezes, depois de receber esse feedback, melhorávamos os nossos pressupostos iniciais.

Mesmo que se testem os designs, se realizem testes de usabilidade, se entreviste os clientes e se automatizem esses testes, os resultados reais em produção, quando os clientes começam a utilizar dados reais, podem ser diferentes. Por isso, sou totalmente a favor de lançar funcionalidades que não sejam ideais.

Hannah Clark: Andrea, como é que isso se enquadra na estratégia? Disseste que, na tua organização, não tens necessariamente orçamento para lançar funcionalidades a esse ritmo e que tens de ser mais estratégica relativamente ao que fazes. Tens uma abordagem diferente?

Andrea Saez: Não, concordo com o que o Paweł disse. Devemos lançar com intenção. Nem tudo tem de ser perfeito. Não quero fazer suposições, mas o Todd falou em algo incompleto, e já vi situações em que lançámos algo e dissemos: está bem, voltaremos mais tarde para melhorar isto. Depois avançamos para coisas novas, mas as equipas não regressam para fazer melhorias.

É uma armadilha de funcionalidades: vamos simplesmente lançar algo novo e não voltamos para melhorar aquilo que, por vezes, são aspetos muito básicos, como questões de usabilidade. Partimos do princípio de que as pessoas perceberão simplesmente porque a funcionalidade está ali.

Aakash Gupta: Penso que todos os comentadores têm razão. O Brent e o Todd estão a apontar para um fenómeno que acontece e que explica por que razão a fábrica de funcionalidades é tão negativa: temos a síndrome do objeto brilhante, lançamos funcionalidades incompletas e nunca as corrigimos ou atualizamos, apesar de sabermos que existem vários problemas, porque já estamos a avançar para o objeto brilhante seguinte.

Quando as pessoas perguntam como sair deste ciclo, é necessário trazer conhecimentos sobre os utilizadores. Por exemplo: analisámos cem gravações de sessões na semana passada e três pessoas clicaram nesta funcionalidade. Os dados mostram que, entre as pessoas que clicaram nela, a retenção aos 30 dias é de 7%. Ninguém está a adotar esta funcionalidade e ninguém está a permanecer nela.

Devemos levar estes conhecimentos aos executivos e aos líderes da fábrica de funcionalidades. Como estamos a falar a linguagem deles e a apresentar conhecimentos concretos, talvez permitam iterar para que a funcionalidade deixe de estar incompleta.

Muitas vezes, quando falamos de uma adoção de 7%, é necessário fazer com que as pessoas vejam e experimentem a funcionalidade. Mas também pode existir um problema de retenção, pelo que devemos corrigir os problemas relacionados com a retenção.

A outra opção — e muitas vezes aquilo de que as empresas realmente precisam — é eliminar funcionalidades. Existem demasiadas funcionalidades que estão efetivamente a dificultar a tarefa principal que o utilizador precisa de realizar. Isto é particularmente problemático no B2B, onde todos tentamos tornar-nos empresas de plataformas e expandir-nos para além de um produto. Assim que atingimos dez milhões de receita recorrente anual, pensamos que precisamos de um segundo produto.

Na realidade, concentrarmo-nos no núcleo do produto costuma ter um impacto muito maior.

Andrea Saez: Penso que foi a Pendo que realizou um estudo que concluiu que 80% das funcionalidades não são utilizadas. É um número enorme.

Hannah Clark: É impressionante.

Penso que isto constitui uma boa transição para a nossa última secção: estamos em modo de fábrica, e agora? Imagino que muitas pessoas tenham participado hoje porque já trabalham naquilo que consideram ser uma fábrica de funcionalidades ou porque estão preocupadas com o facto de a situação estar a piorar.

Vamos assumir que alterar esse modelo, pelo menos a curto prazo, é impossível ou constitui um objetivo muito difícil devido à forma como as coisas funcionam atualmente na infraestrutura consolidada da empresa. Existem passos que possamos dar, enquanto líderes, para nos afastarmos da mentalidade de fábrica de funcionalidades e passarmos a concentrar-nos mais no valor?

Aakash Gupta: Se somos líderes, isso passa a ser uma responsabilidade nossa. Se somos vice-presidentes de Produto, diretores de Produto ou temos qualquer outro título, se somos a pessoa no topo, então, fundamentalmente, se estamos a desempenhar bem o nosso trabalho, estamos sempre a identificar todas as deficiências da organização e todos os problemas que precisamos de resolver.

Esse é o trabalho. Não é dizer que somos fantásticos e que lançamos coisas incríveis. Estamos ali para resolver problemas da empresa. Devemos identificar os grandes problemas, e a fábrica de funcionalidades é um deles.

Podemos perguntar: qual era a vossa estratégia no ano passado? Quais eram todas as funcionalidades que nos comprometemos a criar e qual foi o seu desempenho? Quantas tiveram sucesso? Depois analisamos os resultados e dizemos: 75% não tiveram sucesso. É isso que queremos fazer este ano?

Se não for, como vamos começar a corrigir essa situação? Estamos a falar a linguagem das partes interessadas. Não estamos a dizer que alguém precisa de capacitar os gestores de produto porque um determinado especialista o afirmou. Estamos a utilizar aquilo que aprendemos e a apresentá-lo às partes interessadas.

Para mim, esse é o trabalho de um excelente vice-presidente de Produto. E penso que a Andrea o disse logo na sua primeira resposta: aquilo que levou à fábrica de funcionalidades foi a falta de um excelente vice-presidente de Produto ou de um excelente diretor de Produto.

Também diria que, por vezes, especialmente os fundadores, mas também alguns diretores executivos, são simplesmente difíceis de gerir. Podemos ter o melhor vice-presidente de Produto de sempre, mas o fundador ou diretor executivo continuará a impor as suas decisões. Se estivermos nessa situação, temos de pensar estrategicamente na nossa carreira e procurar outro lugar.

Andrea Saez: Ia dizer exatamente isso. Podemos ser o melhor diretor de Produto ou o melhor vice-presidente de Produto e fazer tudo corretamente, mas, se não tivermos o apoio do diretor executivo e do resto da equipa executiva, não vamos chegar a lado nenhum. Não vai acontecer. Tem de existir alinhamento ao nível executivo, porque, quando existe verdadeiro alinhamento, tudo se torna muito mais fácil.

Trabalhei com diretores de Produto que não tinham qualquer influência e em que era realmente a equipa de vendas que orientava o desenvolvimento, não o diretor de Produto. Outra coisa que acrescentaria é a importância de existir alinhamento e compreensão relativamente a comportamentos mensuráveis dos utilizadores.

Muitas funcionalidades são criadas sem se concentrarem em comportamentos repetíveis e escaláveis — coisas que as pessoas farão todos os dias porque são indispensáveis. Por vezes, as funcionalidades são lançadas apenas para cumprir objetivos. Mas será que estamos realmente a pensar no valor para o cliente?

A funcionalidade vai ajudá-lo a resolver um problema ou vai tornar a sua vida mais difícil? Talvez exista também uma questão ética relacionada com o impacto na vida, no comportamento e nos fluxos de trabalho do utilizador.

Paweł Huryn: Concordo com tudo o que foi dito até agora.

Também não posso deixar de acrescentar, da perspetiva de um gestor ou de uma equipa de produto sem influência na organização, que muitas vezes é possível mover as coisas na direção certa. Obviamente, não vamos mudar toda a organização nem a forma como funciona. Mas, no passado, por exemplo, trabalhei numa organização que era um centro de recursos para mais de 30 bancos da Dinamarca.

A minha iniciativa foi a única que conseguiu escapar ao SAFe, o Scaled Agile Framework, que, para mim, é como um modelo em cascata com planeamento a longo prazo. Analisámos as iniciativas anteriores e tentámos destacar os problemas. Tal como faria um diretor de Produto, mostrámos os problemas e medimos-nos com base na abordagem atual. Demonstrámos que, se continuássemos, uma das iniciativas mais complexas provavelmente falharia como todas as anteriores.

Propusemos uma experiência: a nossa iniciativa, com uma equipa principal e outras quatro equipas que colaboravam connosco, começou simplesmente a trabalhar de forma ágil, sem essa estrutura pesada. Os mesmos argumentos funcionaram. Obviamente, não mudámos toda a organização, mas, no caso da minha iniciativa, funcionou bastante bem.

Hannah Clark: Agradeço muito esta perspetiva de pessoas com um pouco menos de influência, porque tenho a certeza de que há pessoas nessa posição que não são necessariamente vice-presidentes de Produto, mas que querem tornar o seu trabalho tão impactante quanto possível.

Paweł Huryn: Também podemos influenciar muitas coisas dentro da nossa equipa. Não precisamos de pedir autorização: podemos começar a colaborar com os designers, convidar os engenheiros para sessões de reflexão sobre soluções e, em vez de prepararmos tudo sozinhos antecipadamente, falar com os clientes em conjunto.

Andrea Saez: Gostaria de acrescentar algo que o Paweł levantou: quanto trabalho árduo isso exige.

Fiquei surpreendida quando disseste isso. Pensei: como é que ele conseguiu? É muito trabalho. Na maior parte da minha carreira, tive uma espécie de conversa interna com o Aakash em que pensava: não vou perder tempo com isto; vou procurar um emprego novo. Mas fazer uma transformação deste tipo é realmente difícil.

Por isso, deixo o meu reconhecimento a quem consegue fazê-lo ou está a passar por isso, porque é desgastante para o bem-estar, para a saúde mental e para o dia a dia. Mas, quando conseguimos sair do outro lado, também há muita aprendizagem.

Hannah Clark: É, sem dúvida, uma trajetória extraordinária para levar para qualquer experiência seguinte, quer permaneçamos ou não na empresa.

Se quiserem acompanhar os nossos oradores, cada um deles é um líder de opinião extraordinário. Temos muito conteúdo excelente de todos. O livro da Andrea, The Product Momentum Gap, está disponível na Amazon. Podem procurá-lo. A publicação do Aakash chama-se The Product Growth Newsletter, por isso certifiquem-se de que a subscrevem. É um recurso fantástico.

A publicação do Paweł chama-se Product Compass. O Aakash e o Paweł colaboraram em alguns podcasts, mas sei que o Aakash também é muito ativo no seu podcast. Subscrevam os conteúdos dos nossos participantes, porque estão sempre a publicar material excelente, não apenas hoje.

Podemos agora avançar para as nossas perguntas e respostas. Recebemos hoje algumas perguntas excelentes do público. A primeira é da Aqueda. Espero ter pronunciado corretamente.

Como passamos de uma fábrica de funcionalidades para uma criação contínua de valor para os utilizadores e clientes que gere um impacto positivo no negócio? Sinto que já abordámos um pouco esta questão, mas talvez haja algo a acrescentar.

Ela diz que parece que a componente de valor para o cliente foi obscurecida por um resultado rápido de lucro. Andrea, se quiseres fazer um resumo do que abordas no livro, talvez seja útil.

Andrea Saez: É precisamente isso. Trata-se de reunir a estratégia de produto e o valor para o cliente. Falamos muito sobre o valor para o cliente, como identificá-lo, acompanhá-lo, concentrarmo-nos nele e reunir a equipa em torno dele.

Temos um modelo chamado plano de criação de valor do produto. A parte fundamental é que não cabe à equipa de produto tomar essas decisões isoladamente. É necessário ouvir as vendas, o sucesso do cliente e o apoio ao cliente, trazendo todas essas partes interessadas para o workshop, colaborando com elas e compreendendo o que significa valor para, depois, o podermos entregar.

Hannah Clark: Se quiserem ter uma amostra desse tema, discutimo-lo exatamente no podcast há cerca de um ano. O episódio do podcast do Product Manager chamava-se «Como os líderes de produto estão a prejudicar involuntariamente o crescimento do negócio».

A próxima pergunta é do Parker. Que ferramentas ou métodos utilizam para promover discussões estratégicas e alinhamento em torno de um objetivo comum de produto? O que foi mais eficaz para vocês? Esta é uma questão interessante e um pouco mais prática. Alguém quer começar?

Aakash Gupta: Se estamos a tentar criar alinhamento relativamente a um objetivo específico, a primeira coisa a fazer não é simplesmente sugerir que determinada resposta é a correta. O ideal é criar contexto com as pessoas que ainda não foram envolvidas e dizer: talvez não tenhamos o objetivo certo neste momento. Podemos passar por um processo conjunto para tentar descobrir qual é o objetivo certo?

Depois, devemos estruturar esse processo de forma muito colaborativa. Gosto de trabalhar com um analista ou alguém muito respeitado por ambas as partes, uma terceira pessoa externa, e dizer: podemos criar um relatório de investigação e apresentá-lo, para depois discutirmos e colocarmos perguntas? Assim, aprendemos em conjunto com as pessoas com quem discordamos.

Aprendemos sobre as métricas e as opções e, depois, fazemos uma sessão de reflexão. Muitas vezes utilizo o Miro, à distância. Não precisa de ser presencial. Estas são as métricas e os objetivos possíveis em que nos poderíamos concentrar. Quais são as vantagens e desvantagens destas opções?

Discutimos tudo em conjunto e, enquanto gestores de produto, utilizamos o poder da caneta para registar: estas são as opções e estas são as vantagens e desvantagens. Depois voltamos à terceira pessoa e trabalhamos com ela. A equipa de ciência de dados analisou isto, nós analisámos aquilo e envolvemos alguns gestores de produto, designers e engenheiros que trabalham no produto há seis meses, para obter o seu feedback sobre quais são as métricas fáceis ou difíceis de alterar.

Depois, fazemos uma discussão final. Não apresentamos a resposta certa de antemão; estamos dispostos a ouvir a outra pessoa, mas tomamos uma decisão nessa reunião.

É assim que gosto de estruturar o processo de forma muito prática: uma sequência de etapas. Demora mais tempo, mas esperamos conseguir um maior envolvimento.

Hannah Clark: Deixo sempre para ti a apresentação de um processo muito claro e específico, por isso agradeço.

Vamos passar à Mikayla. Temos um pedido de reformulação de um produto por parte da empresa e da equipa de experiência do utilizador. Queremos compreender corretamente os pontos problemáticos, obter conhecimentos e compreender as jornadas. Até agora, tem sido uma fábrica de funcionalidades e está desligada porque utilizamos vários sistemas para compor a interface, mas o gestor de produto está a pressionar para fazer algo rapidamente porque já sabemos algumas coisas, entre aspas, embora não exista uma direção clara. Qual seria uma boa forma de sair desta situação?

Temos, portanto, um conjunto de conhecimentos, mas parecem estar desligados das funcionalidades que estão realmente a ser desenvolvidas. O gestor de produto está simplesmente a privilegiar a rapidez em detrimento da qualidade.

Parece que existem vários problemas: os conhecimentos estão desligados do que está efetivamente a ser criado e o gestor de produto não parece estar a estabelecer essa ligação.

Paweł Huryn: Neste caso, é o gestor de produto que está a pressionar para lançar funcionalidades sem uma validação adequada.

Isso pode ser difícil, mas, em geral, se alguém está a pressionar para lançar funcionalidades, eu tentaria fazer engenharia inversa e perguntar qual é o problema que essa funcionalidade resolve. Depois, exploraria e validaria o problema e, talvez, as soluções.

Também gostaria de compreender se esse problema está alinhado com os objetivos mais amplos atualmente importantes para a organização, com a estratégia e com a visão da empresa.

Talvez alguém da equipa, que não seja o gestor de produto, possa fazer esta análise inversa ou, pelo menos, encontrar inconsistências entre os dados, os funis analíticos e a análise de coortes e as funcionalidades que estamos a criar. Deve existir um conjunto de pressupostos por trás dessas funcionalidades e eu gostaria de validar esses pressupostos.

Andrea Saez: Concordo com o Paweł. Existem duas perguntas mágicas: que problema estamos a tentar resolver e porquê? E para quem o estamos a resolver. Não nos podemos esquecer de quem é o utilizador.

Passei recentemente por uma situação semelhante. A equipa de produto queria lançar algo porque achava que sabia o que estava a fazer. Eu disse: não quero interromper, mas podem explicar-me o problema e o processo de tomada de decisão para que eu o compreenda? Como profissional de marketing de produto, preciso de vender isto e compreender o valor e o processo de decisão.

É um pequeno esboço do problema do produto, em que se pergunta: que problema estamos a tentar resolver? Porquê? Para quem? Qual é o impacto no negócio? Que valor estamos a entregar ao cliente? Analisar esta lógica pode ajudar a orientar a equipa com alguma influência e fazê-la pensar sobre a razão pela qual está a fazer as coisas.

Hannah Clark: Sim, responsabilizá-los por isso parece-me uma excelente sugestão. Temos mais perguntas, mas, tendo em conta o tempo, vamos avançar. Obrigada pela pergunta, Mikayla.

A próxima pergunta é do Brent. Numa situação ideal, uma empresa ou produto deveria tornar-se menos fábrica de funcionalidades à medida que amadurece? Poderá esta tendência ser um sinal de aplicação inadequada das equipas de produto?

Andrea Saez: Quem tem ideias? Hannah, quero ouvir a tua opinião.

Hannah Clark: Sou realmente uma pessoa externa a este tema, mas parece-me que uma empresa deveria ser o menos possível uma fábrica de funcionalidades no início, quando tem um objetivo específico e um problema concreto do utilizador para resolver.

Parece-me que a fábrica de funcionalidades surge à medida que se fazem concessões para manter o negócio vivo. Por isso, é algo que uma empresa em crescimento provavelmente encontrará com maior frequência. Mas, para ser totalmente transparente, nunca estive numa posição em que tivesse de lidar com estas preocupações. Podem corrigir-me.

Aakash Gupta: Penso que as percentagens são provavelmente semelhantes em todas as fases do ciclo de vida. Por vezes, quando estamos numa fase muito inicial, pensamos que basta copiar outro produto. Tudo está claro: é simplesmente uma fábrica de funcionalidades. Podem criar agora o gravador de chamadas da Gong. O roteiro está mesmo à vossa frente.

A fábrica de funcionalidades pode surgir em qualquer fase. O que devemos pensar, independentemente do ambiente em que nos encontramos, é quais são as partes da fábrica de funcionalidades que nos estão a prejudicar.

A questão é: não estou a conseguir gerar retorno sobre o meu salário? Se recebo 150 000 dólares, como gestor de produto médio, estou a gerar 150 000 dólares de lucro para a empresa? Se não estou, então a fábrica de funcionalidades tornou-se um problema para mim e preciso de começar a corrigir essas áreas uma a uma.

Quanto à distribuição por fase, penso que existe em todo o lado. Encontramos empresas muito boas e enormes, como a Meta, que muitas pessoas apresentam como exemplo de gestores de produto capacitados. Mas também existem empresas da série C e empresas da série A. Até o lançamento recente de geração de imagens da OpenAI parece ter surgido porque os investigadores e engenheiros descobriram coisas novas e as apresentaram, não porque alguém simplesmente ordenou que fosse lançado um produto melhor.

Existem, portanto, empresas de 300 mil milhões de dólares a fazer isto bem. Em todas as fases encontraremos uma proporção semelhante, provavelmente mais de 50% em modo de fábrica de funcionalidades.

Hannah Clark: Vou passar à pergunta do Sahi. Quais são alguns dos benefícios acrescentados que um gestor de produto proveniente de uma formação híbrida empresarial e técnica traz, em comparação com um gestor de produto com uma formação exclusivamente técnica, no que diz respeito às funcionalidades e ao design?

Andrea Saez: Penso que existe uma ligação. Posso estar completamente errada, mas, na minha experiência muito parcial, os gestores de produto exclusivamente técnicos tendem a não ter foco no negócio. No final do dia, todos construímos coisas para as vender.

Não estou a sugerir que todos devam estar totalmente concentrados no retorno do investimento, mas é importante compreender que estamos a criar algo que precisa de ser vendido, bem como a forma como as nossas decisões afetam o negócio, o retorno do investimento e tudo o resto.

Os gestores de produto com uma formação empresarial compreendem isso desde o início e tomam decisões orientadas nesse sentido. Por vezes, os gestores de produto técnicos concentram-se apenas no lado técnico e não se preocupam necessariamente com o retorno do investimento.

Um bom exemplo é quando estamos a falar de criar uma determinada funcionalidade ou entro num projeto já em fase final. A minha primeira pergunta será: já pensámos em como vamos vender isto? E todos respondem: não.

Essa deveria ter sido a primeira pergunta. Como vamos vendê-la? A quem? Se somos uma empresa B2B com um pacote individual e um pacote empresarial, a funcionalidade que estamos a criar está preparada para levar o cliente ao longo dessa jornada?

Um cliente empresarial não terá o mesmo problema que um indivíduo numa empresa em fase pré-semente que queira utilizar o nosso produto. Nem todas as pessoas passam por este processo de reflexão se não tiverem uma formação empresarial. Posso estar errada, por isso sintam-se à vontade para me corrigir.

Hannah Clark: Alguém sente necessidade de responder?

Aakash Gupta: Penso que a pessoa está provavelmente a perguntar, tendo uma formação técnica e empresarial, que vantagem pode trazer em comparação com pessoas de formação exclusivamente técnica. Passámos muito tempo a falar sobre impacto: o impacto do nosso trabalho.

Se temos uma formação empresarial, devemos tentar desenvolver competências de gestão de produto desse tipo. Criar o modelo de crescimento da equipa, dimensionar o impacto de todas as funcionalidades, escrever excelentes resultados de funcionalidades e relatórios. Devemos utilizar os nossos pontos fortes e não preocuparmo-nos demasiado com o que os outros estão a fazer.

Cabe aos gestores de produto técnicos aprender as competências empresariais. Sinceramente, não são muito difíceis, pelo que a maioria consegue aprendê-las facilmente. Devemos concentrar-nos em nós próprios e em como tirar partido dos nossos pontos fortes. Se somos muito bons a trabalhar no Excel, devemos fazer mais trabalho no Excel como gestores de produto. Essa é a magia da função: podemos torná-la nossa.

Andrea Saez: Concordo a cem por cento.

Hannah Clark: O Todd disse: Paweł, mencionaste anteriormente que gostarias de manter todos os conhecimentos. Em que momento transformas os conhecimentos em itens do backlog? O nosso backlog parece o chão de fábrica de funcionalidades. Recomendamos arquivar itens com mais de 12 meses. Podes responder a esta pergunta para que os outros possam retirar alguma conclusão?

Paweł Huryn: Primeiro, não tenho a certeza de ter mencionado que devemos manter todos os conhecimentos. Talvez tenha dito que devemos tirar partido de conhecimentos provenientes de diferentes fontes: não apenas entrevistas com clientes, mas também partes interessadas, investigação de mercado, análise de dados, inquéritos, etc.

Quanto à organização dos conhecimentos e dos itens do backlog do produto, sempre evitei colocar histórias de utilizador ou funcionalidades no backlog dos programadores prematuramente.

Preferia concluir a descoberta, partilhar os designs, testar os pressupostos fundamentais e partilhar as nossas conclusões com a organização. Só depois de obtermos confiança suficiente é que dividiríamos o trabalho em histórias de utilizador e definiríamos o processo com a equipa.

É como ter dois backlogs, embora não tenham de estar na mesma ferramenta. Pode ser simplesmente o Miro ou outra ferramenta visual para recolher esses conhecimentos e ligá-los às necessidades dos utilizadores.

Quanto a ocultar itens, normalmente arquivaria os elementos que permanecem demasiado tempo no backlog. Se o backlog tiver mais de 8 100 elementos, não é gerível. Pela minha experiência, esses itens nunca serão tratados. Se forem importantes, voltarão a ser apresentados.

Hannah Clark: Obrigada a todos por participarem. E, naturalmente, um enorme obrigado aos nossos participantes por disponibilizarem o seu tempo hoje. Aakash, Andrea e Paweł, muito obrigada. Foi uma sessão muito divertida e informativa. Quero agradecer a todos por participarem no nosso evento e por serem um público tão empenhado. Esperamos ver-vos na próxima vez.

Obrigado por nos ouvirem. Para obter mais perspetivas, 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 na plataforma onde costuma ouvir os seus podcasts.