FAQ de um Time de Produto

Marty Cagan - 30/08/2019 Traduzido por Marcelo Knakiewicz

Antes de tudo, se você quiser uma resposta minha, por favor, me envie um e-mail diretamente.

De vez em quando, um artigo meu aparenta atingir algo em cheio, este último sobre a diferença entre Times de Produtos e Times de Funcionalidades certamente parece ter sido um desses. Agradeço as respostas positivas que recebi. Esta manhã eu acordei com muito mais do que cem pessoas que pegaram parte do seu tempo para me mandar um e-mail agradecendo e, muitas vezes, com perguntas complementares.

Como é minha prática (e que defendo para gerentes de produto em geral), gosto de considerar as perguntas e tentar chegar a uma resposta útil e, em seguida, compartilhá-la para que todos com essa pergunta possam, com sorte, se beneficiar do diálogo.

-Você disse que o designer é responsável pela usabilidade, e o engenheiro é responsável pela viabilidade, mas é só para isso que eles estão lá?

Isto é extremamente importante, e é algo sobre o qual sei que eu preciso escrever mais. Eu tentei capturar isto neste artigo que fiz recentemente sobre colaboração verdadeira, mas deixe-me ser claro; design é muito mais do que apenas usabilidade, e engenharia é muito mais do que apenas viabilidade.

Eu vou retornar a este ponto já já, mas primeiro eu quero endereçar o que eu estava tentando dizer antes.

Se algo é lançado por alguma das empresas que eu ajudo, e é virtualmente inútil porque tem um péssimo design (o que sabemos que ocasionalmente acontece), você pode apostar que eu vou diretamente no designer perguntar como isso aconteceu? É absolutamente responsabilidade do designer garantir que isto não aconteça, algo saiu errado.

Similar a isto, se o produto é lançado e tem uma performance horrível você pode apostar que eu vou diretamente no líder técnico com a mesma pergunta.

E mais frequentemente, se algo é lançado e as análises mostram que não está sendo comprado ou não está sendo usado, ou aconteceu de violar alguma regra de negócio como privacidade por exemplo, você pode apostar que eu vou diretamente no gerente de produto questionar o que aconteceu.

Entenda que como um orientador eu tenho que atuar como uma autoridade ou controle. Mas a maior parte dos times sabem que meu único objetivo é ajudá-los a se tornarem um time mais efetivo, e estas são oportunidades de aprendizados únicas que eu não vou deixar passar.

Portanto, é extremamente importante que em um time de produto empoderado tenhamos as habilidades que precisamos, e que estas pessoas sejam responsáveis pelo seu trabalho.

Dito isso, e de volta ao cerne da questão, a forma como chegamos à boas soluções é com um intenso dar e receber.

Designers frequentemente têm insights baseados em um conhecimento profundo sobre o usuário e seus comportamentos que nos levam em diferentes direções de solução para o problema que estamos enfrentando, ou nossa abordagem ao problema. Estes insights irão, com frequência, ter grandes impactos no valor do produto e impactos indiretos em outras coisas como performance.

Da mesma forma, bons engenheiros têm insights profundos sobre a tecnologia que muitas vezes nos leva a soluções totalmente diferentes para os problemas que nos foram atribuídos, muitas vezes muito melhores do que qualquer coisa que o gerente de produto, o designer ou especialmente o cliente poderiam ter imaginado.

Se eu tivesse que escolher uma única coisa que eu mais amo sobre o sentimento de trabalhar em um verdadeiro time de produto empoderado, é a magia que acontece quando temos pessoas que são a) motivadas e b) habilidosas em suas respectivas disciplinas - produto, design e engenharia - e eles sentam ao redor do protótipo, e o engenheiro aponta as novas possibilidades, o designer aponta as diferentes experiências possíveis, e o gerente de produto pondera com as vendas, aspectos financeiros ou implicações relacionadas à privacidade, e depois de explorar uma série de abordagens, eles encontram uma que realmente funciona - é valiosa, é utilizável, é viável e factível.

Espero que isso deixe claro que esses são dois pontos diferentes, mas relacionados. Sim, o designer é responsável por garantir um produto utilizável; e sim, o engenheiro é responsável por garantir um produto viável; mas criar esse produto requer toda uma gama de habilidades.


- Você consegue resumir quais as diferenças entre Times de Delivery, de Funcionalidade e de Produto?


Times de Delivery não são multi-funcionais (basicamente apenas desenvolvedores mais um gestor de backlog), eles não são focados em resultados (só pensam em entregas), e eles não são empoderados (eles estão lá para desenvolver e entregar).

Times de Funcionalidades usualmente são multi-funcionais (composto ao menos por algum tipo de designer e gerente de produto), mas eles ainda são focados em entregas e não são empoderados.

Times de Produto são multi-funcionais, focados em medir resultados, e empoderados ao ponto de definir quais as soluções que funcionam.


- Conseguimos ter um time de produto empoderado sem ter um gerente de produto competente?

No artigo Times de Produto Empoderados eu tentei descrever o contexto necessário para constituir times empoderados, e uma das peças mais críticas para conseguir ter times de produto empoderados depende do fato de ter um gerente de produto competente. Sem ele (ou ela), o primeiro problema é que a equipe dificilmente criará confiança na gerência. O segundo problema é que o time não terá o conjunto completo de habilidades para criar soluções para os problemas que lhes são atribuídos. E eu também acredito que a falta de competência de um gerente de produto é o impedimento mais comum em times de produto empoderados. Observe que considero o líder do produto responsável por garantir que cada equipe de produto tenha um gerente de produto competente.


- Eu ainda estou desconfortável com o conceito de que o gerente de produto é o CEO do produto

No artigo eu enfatizo que gerente de produtos são responsáveis por garantir o valor e viabilidade do produto. É daí que vem a analogia, e para aqueles que foram fundadores ou CEO de uma startup, vocês sabem que isto é o cerne do trabalho. E é por isso que eu continuo acreditando que é uma analogia importante e relevante. Se essa responsabilidade te deixa maluco, considere a possibilidade de que você talvez fique mais confortável como um gerente de produto de um time de funcionalidades.


- Por que as pessoas ficariam chateadas?

Eu gasto muito tempo dando treinamento e instruindo gerentes de produto e líderes de produto, e eu continuo encontrando gerente de produtos que estão fazendo o trabalho deles. Eu frequentemente pergunto-os onde eles aprenderam a fazer o que fazem, e eles frequentemente citam meus livros, conferências e treinamentos.

Eu tenho vindo a público e alertando do problema que temos quando temos gerentes de produtos achando que uma aula da CSPO os ensinará o trabalho que é esperado que eles façam, porém é muito pior que isso.

Hoje, há vários lugares que oferecem "treinamentos de gestão de produto", e alguns inclusive promovem seus "certificados" porém quando eu conheço as pessoas que frequentam esses programas, e mesmo eu desacreditando e olhando o currículo para ter certeza, fica claro para mim que eles têm ensinado como ser um gerente de produto de um time de funcionalidades.

Nos últimos vários anos, como a importância de produto se tornou largamente mais reconhecida, ensinar gestão de produto se tornou um negócio relativamente grande. E eu sabia que meu artigo, na sua essência, estaria chamando de porcaria vários desses programas.

Eu quero ser claro, nos últimos anos tem surgido poucos livros e conferências boas, eu faço o que posso para promover estes. Mas eles são a minoria. Eu não consigo nem se quer comparecer nessas conferências porque é fisicamente doloroso escutar o que frequentemente é defendido ali.

A outra coisa que eu estava chamando de porcaria, mas assumo que isto estava um pouco menos explícito, era a ideia de que "somos todos designers." (nota mental, eu acho divertido que vocês não escutam os times dizerem "somos todos desenvolvedores"). Em bons times de produto, nós não somos todos designers. Nós somos afortunados quando temos um profissional de design de produto. É verdade que nós todos (stakeholders, gerentes de produtos e engenheiros especialmente) trazemos dificuldades para o trabalho do designer, mas bons designers estão sempre tentando resolver essas dificuldades.


- Há alguma maneira de ter verdadeiros times de produto empoderados usando SAFe?

Eu tenho certeza que os exércitos de consultores e treinadores vão argumentar que sim, como eles fazem com todas os outros chavões que soam atrativos, mas eu realmente não vejo como ser possível. É um modelo de fábrica de software, e no time em si não há sequer um verdadeiro gerente de produto ou designer. É puramente um time de delivery. Eu escrevi sobre isso de forma bem detalhada neste artigo A revanche do PMO.


- Por que você não gosta de engajar em mídias sociais/Twitter?

A verdade é que para algumas coisas o Twitter é realmente bom (como notificar as pessoas que se importam que eu acabei de escrever um artigo novo). E há outras coisas que eu argumento que o Twitter é péssimo (como discutir sobre este artigo em questão).

Acontece a todo momento. Eu publico um artigo, e as pessoas frequentemente vão mencionar algo que elas gostaram, o que é legal, porém outros que não leram o artigo vão responder essas menções, sem contexto, e as coisas começam a declinar dali pra diante.

E acho que o meio traz à tona o que há de pior nas pessoas. O modelo de interação não incentiva o tipo de pensamento e diálogo necessários para lidar com problemas difíceis (o Twitter é, na verdade, o que inspirou o artigo sobre a necessidade de as pessoas de produto pensarem profundamente).

Além disso, mesmo quando desisto e ocasionalmente me envolvo, no dia, semana, mês, ano seguinte, as mesmas perguntas continuam voltando. O ponto principal é que há tantas bobagens espalhadas no Twitter e não vejo isso mudando.

Artigo original: http://bit.ly/38o2rWu

© 2021 por Product Guru's.