o Gerente de Produtos vs Proprietário do Produto

é uma questão interessante e que leva tempo para desempacotar. Vamos ver de onde esses termos e disciplinas se originaram e como alguns frameworks comuns os explicam.,quando comecei a minha carreira, chamaram-me Analista de negócios. Eu fiz muito pouco “análise de negócios” como nós olharíamos para ele em empresas de TI tradicionais. Honestamente, eu fiz muito pouco do que eu ensino como Gestão de produtos agora também. Fui encarregado de reunir os requisitos das vendas, chegar a uma solução, projetá-la, e, em seguida, enviar o documento de especificação para o desenvolvimento a ser construído.continuei a ser chamado de Analista de negócios enquanto trabalhava em bancos e outras empresas de serviços financeiros. Não fui chamado de gerente de produto até ter escapado e aterrado numa startup., Era tudo o mesmo trabalho que eu tinha feito antes, mas agora tinha um nome diferente. Gostei deste nome. “Product Manager” parecia ter seriedade para ele, e quando eu olhei para outras empresas de tecnologia no Vale, eu podia ver um caminho de carreira claro esculpido para mim, enquanto os analistas de negócios eram diferentes em todas as empresas.não tinha ouvido falar do termo proprietário do produto até anos mais tarde. A primeira vez que ouvi o termo, perguntei a alguém o que significava. Disseram-me que era o mesmo que um gerente de produtos, mas era um termo usado no Scrum., Há anos que usávamos o Scrum, mas ainda me chamavam Gerente de produtos, por isso, o facto de serem intercambiáveis fazia sentido para mim. Raramente pensei nisso depois disso.isso foi até eu ter a minha primeira experiência a ensinar Gestão de produtos numa empresa usando o enquadramento seguro. Eu estava a fazer uma oficina para um banco muito grande quando um dos participantes apareceu.

“Você está nos ensinando a falar com os usuários, mas eu sou um proprietário de Produto. O Gerente de produtos fala com todos os usuários e nos diz quais são os requisitos., Eu passo Todo o meu tempo escrevendo histórias de usuários a partir destes e trabalhando com a equipe para executar na solução. Estou confuso.”

isto foi quando comecei a investigar as diferenças entre estes dois papéis e como diferentes filosofias os ensinam. A fim de entender como chegamos aqui

a gestão de produtos pode ser rastreada até 1931. Hewlett Packard foi uma das primeiras empresas de tecnologia a implementar este trabalho e organizar-se por produtos na década de 1940., A maioria das empresas do Vale do Silício tiveram gerentes de produtos desde o início, e muitos dos meus amigos que trabalharam lá nos anos 80 e 90 foram, de fato, gerentes de produtos. Então esta disciplina não é nova, mas está evoluindo rapidamente à medida que mais empresas começam a se transformar em organizações de software e começam a se estruturar em torno de produtos.

Scrum veio em cena pouco antes do Manifesto Ágil foi escrito em 2001. Introduziu o conceito de proprietário de um produto. Esta era uma pessoa que era um proxy para o cliente e diria aos desenvolvedores os requisitos para o que precisava ser construído., Nos primeiros dias, quando muitos dos criadores desses processos estavam trabalhando como consultores em empresas, o proprietário do produto era o cliente — uma pessoa interna no negócio que se sentaria com a equipe e priorizaria o atraso do trabalho. De fato, os objetivos de aprendizado de 2017 para sua certificação certificada de proprietário de produtos Scrum pela Scrum Alliance afirma: “ensinam que o papel do proprietário do produto é tipicamente desempenhado pelo cliente, ou representante do cliente, como um gerente de produtos.,”

Quando você olha para o papel do proprietário do produto na maioria da literatura Scrum, suas três principais responsabilidades incluem o seguinte:

• Define o backlog do produto e criar histórias de usuário acionáveis para as equipes de desenvolvimento. (Who creates the user stories varies depending on Scrum training)
• Groom and priorize the work in the backlog.
• aceitar as histórias completas do Usuário para se certificar de que o trabalho cumpre os critérios.,enquanto a mudança curricular entre professores e organizações, estas são as coisas que são focadas principalmente durante os cursos de dois dias para certificar os proprietários de produtos. Embora o Scrum tenha um monte de informações sobre os processos e rituais do que fazer como um proprietário de produto, ele deixa muitas perguntas que são importantes para a criação de produtos de sucesso sem resposta. Estes geralmente se centram em torno de ” como sabemos que estamos construindo a coisa certa?”

  é aqui que entra a gestão do produto., Um bom gerente de Produto é ensinado como priorizar o trabalho contra objetivos claramente orientados para o resultado, como descobrir e validar o valor real do cliente e do negócio, e que processos são necessários para reduzir a incerteza de que o produto vai ter sucesso no mercado.

  Sem Este fundo na gestão de produtos, alguém pode efetivamente passar pelos movimentos do proprietário do produto em Scrum, mas eles nunca podem ser bem sucedidos em se certificar de que eles estão construindo a coisa certa.,se retirar a sua equipa Scrum, se retirar o Scrum como processo para a sua organização, continuará a ser um Gestor de produtos. A gestão de produtos e Scrum trabalham juntos bem, mas a gestão de Produtos não depende do Scrum. Pode e deve existir com qualquer estrutura ou processo.

  recentemente tive um proprietário de Produto cujos desenvolvedores foram transferidos para outra parte da organização veio até mim porque eles estavam preocupados que eles não poderiam ser uma pessoa de produto nesta empresa por mais tempo. Toda a sua identidade aparentemente dependia de ter uma equipa de desenvolvedores.,

  Como um gerente de Produto seus papéis e responsabilidades irão mudar dependendo do seu contexto e do estágio do seu produto. Sem uma equipe Scrum ou com uma equipe menor, você pode estar fazendo mais trabalho de estratégia e validação com a descoberta de problemas em um produto que ainda não foi definido. Com uma equipe Scrum, você pode estar mais focado na execução de soluções. Como gerente de gerentes de produtos, você pode estar liderando a estratégia para uma parte maior do produto e treinando suas equipes para descobrir e executar bem.,

  A estrutura segura ensina isso de forma diferente, e eu acho que é um dos pontos mais fracos em toda a estrutura. Em SAFe, os gerentes de produtos são os gerentes de proprietários de produtos e são responsáveis por interações externas face e trabalho. Eles falam com os clientes, eles definem os requisitos e escopo dos produtos a serem construídos, e eles comunicam isso para os proprietários de produtos. Os donos dos produtos são internos, definem os Componentes da solução e trabalham com desenvolvedores para enviá-la.,

  

  Eu treinei dezenas de equipes que estão usando Seguro e eu nunca vi isso funcionar bem. Os proprietários do produto são desconectados de seus usuários e incapazes de criar soluções eficazes para eles que realmente resolvem seus problemas, porque eles não entendem os problemas bem., Os gestores de produtos estão essencialmente a reduzir os requisitos para eles e as equipas não estão autorizadas a provar se estas são as coisas certas a construir ou não. Ninguém está a fazer trabalho de validação.

  ouvi muitos argumentos de que os proprietários de Produtos não têm tempo para fazer ambos os papéis. No contexto actual, é verdade. Os proprietários de produtos com quem falo passam 40 horas por semana escrevendo histórias de usuários. Nesse momento, você tem que perguntar a si mesmo, essas histórias de usuário são valiosas? Qual é a prioridade deles? Como é que eles sabem que isso vai resolver um problema?,

  Se você tem uma pessoa gastando tanto tempo escrevendo histórias de usuário a cada semana, todas as semanas, você está caindo na armadilha de Compilação-concentrando-se na quantidade de itens que você libera e não na qualidade.

  com uma boa estrutura de estratégia no lugar e priorização implacável em torno de alguns objetivos-Chave, uma pessoa pode efetivamente falar com os clientes, entender seus problemas, e ajudar a definir as soluções com a equipe. Mesmo o CEO da Scrum.org concorda que pode ser esse o caso, ainda que, ao que parece, de forma negativa., Scrum Inc também diz que o proprietário do produto deve passar metade de seu tempo falando com os clientes, e metade trabalhando com a equipe. Não estou 100% de acordo com esta divisão, mas a direcção é boa. A quantidade de trabalho externo Versus interno irá mudar dependendo da maturidade e sucesso do seu produto. Nunca devias estar a fazer este trabalho todo de uma vez.,ensino aos meus clientes que os gestores de produtos em funções seniores (VPs ou chefias de produtos ou gestores intermédios) se concentram na definição da visão e da estratégia das equipas com base na pesquisa de mercado, na compreensão dos objectivos e da estratégia da empresa e na análise do actual estado de sucesso dos seus produtos. Os gerentes de produtos sem equipes Scrum ou com equipes menores (um Designer UX e um desenvolvedor, por exemplo) ajudam a validar e contribuir para essa estratégia para produtos futuros. Uma vez que validamos a direção, criamos maiores equipes de Scrum em torno dessas pessoas e criamos soluções.,

  é importante ter esta flexibilidade no tamanho da equipe, bem como dependendo do estágio do seu produto. Se você der a um gerente de Produto Um grande Backlog da equipe scrum para continuar preenchendo enquanto você está no modo discovery, eles vão manter esse backlog preenchido. Mas, eles também serão divididos entre manter o trabalho fluindo para os desenvolvedores e tentar fazer o trabalho para validar a direção. Como resultado, nenhum deles é bem sucedido.

  Se você quer construir produtos que criam valor para seus negócios e clientes, você precisa de boas fundações de gerenciamento de produtos em sua empresa., Se você quer um caminho de carreira para o seu povo, você precisa dar-lhes esta Fundação para que eles possam crescer em papéis mais seniores. Então lembre ao seu pessoal que eles são todos gerentes de produtos. Eles podem estar desempenhando o papel de um proprietário de produto em uma equipe Scrum na maioria dos dias, mas ainda precisamos que eles pensem como um gerente de produto e validar que estamos construindo as coisas certas.Melissa Perri é a CEO da Produx Labs, uma consultoria que ajuda as organizações a aprender e adotar boas práticas de gestão de produtos e Liderança de produtos., Ela dirige uma escola online para gerentes de produtos no Instituto de produtos e para Líderes de produtos no CPO Accelerator. Ela é professora sénior na Harvard Business School.

  isto foi originalmente publicado em melissaperri.com