Product Owner ou Product Manager? Eis a questão!

Com o advento dos métodos ágeis, a complexidade de outrora em desenvolver e distribuir softwares tem diminuído ao longo dos últimos anos. Os métodos ágeis como Scrum e XP promoveram uma verdadeira revolução na forma de se pensar e construir software. Times multifuncionais, compostos por desenvolvedores, testadores, user experience designers, agile masters e Product Owners, modificaram o mercado de tecnologia e as estruturas das empresas tradicionais.

Como a história nos ensina, toda revolução traz consigo a semente do novo sobre uma proposta declinante. O conflito é inevitável e as estruturas e ideias obsoletas não são facilmente esquecidas ou abandonadas.

Foram intermináveis os debates sobre o que seria feito, por exemplo, com os gerentes de projetos, uma vez que os agile masters estavam assumindo as atribuições daqueles. Qual seria o futuro dos gerentes? Poderiam estes assumir este novo papel? Deveriam abraçar o destino e navegar em outros mares?

Alguns gerentes de projetos realmente abraçaram a causa ágil e se tornaram excelentes agilistas. Outros, voltaram o foco ao desenvolvimento de pessoas, infelizmente tão carente nas empresas. Obviamente, não podemos nos esquecer dos que ficaram no limbo, presos no passado e infelizmente muito presentes em nosso dia a dia corporativo.

Com a propagação dos métodos ágeis, dois papéis logo se destacaram nos times: o agile master e o Product Owner. Ambos os papéis são imprescindíveis ao sucesso de um produto. O agile master foca no processo e conduz o time na estrada da eficiência. O Product Owner, por sua vez, se responsabiliza pela eficácia. Eficácia para um Product Owner é tornar o produto desejável e útil aos clientes, e viável e rentável ao negócio.

Para atingir esta eficácia, o Product Owner utiliza várias ferramentas: business model canvas, roadmaps, data driven, lean startup, design thinking, design service dentre tantas outras técnicas possíveis.

Além desse conjunto de ferramentas, um profissional de produtos precisa ter certas características, como ser capaz de analisar o produto de forma holística, autonomia para decidir o que priorizar e cortar do backlog e ter alta capacidade de negociação para mediar os conflitos de interesses entre stakeholders e clientes, sendo estes representados nas empresas pelo gestor de produto.

A visão holística do produto evita decisões com viés especializado ou departamental. A autonomia se apodera deste profissional para a tomada de decisões e o lado negociador media, trata e alinha com todas as partes interessadas, o que e o porquê de cada requisito priorizado, gerando convergência e unicidade de trabalho e de informação.

Pode-se destacar que a falta de visão e autonomia incapacita e mina a negociação do produto, resultando em graves problemas pelos quais os times ágeis vem enfrentando: Product Owners sem empowerment e com visões de negócio fragmentadas ou nulas, tornando estes profissionais geradores de especificações ao invés de geradores de oportunidades e valor.

Mas o que está acontecendo realmente? Por que não é dado o empowerment necessário aos Product Owners? Por que lhes falta tanta informação? Por que estes profissionais mal conseguem dar o feedback de sucesso ou fracasso do que estão priorizando?

Podemos achar algumas respostas nas abordagens tradicionais. Vale lembrar que a engenharia de produção de software foi baseada nas engenharias civil e naval. Estas engenharias não eram os modelos mais aptos para a engenharia do software, mas eram os sistemas de produção conhecidos até então.

Junto do famigerado waterfall, as empresas de tecnologia herdaram toda estrutura matricial que servia de arcabouço para este sistema de produção. Hoje temos um blend entre este modelo e as metodologias ágeis que chegaram com força nas empresas a partir de 2001.

O passado e o presente se fundem em um ambiente complexo, caótico e nebuloso, gerando insatisfação e desgaste constantes.

Dentro deste cenário, uma análise faz-se necessária. Resquícios e fragmentos da história da engenharia de produtos podem ajudar na busca do que se perdeu para entender melhor o cenário vigente. Seguindo a ordem cronológica, a história da gestão de produtos começa em 1931, quando Neil H. McElroy escreve um memorando para a empresa Procter & Gamble solicitando algumas contratações. Os candidatos deveriam acompanhar as vendas para gerenciar melhor o produto, publicidade e promoções, tudo isto o mais próximo possível do cliente. Este memorando projeta os alicerces do “Brand Management” e mais tarde da própria disciplina de "Product Management".

Vale ressaltar que McElroy, além de lançar os alicerces da disciplina de Product Management, também foi secretário de defesa americano, ajudou a fundar a NASA e tornou-se conselheiro na Universidade de Stanford, onde influenciou outros dois notáveis: Bill Hewlett e David Packard.

Na HP, as ideias de Product Management ganharam impulso. O usuário ocupava o centro das tomadas de decisões e a área de produtos representava a voz do cliente internamente, influenciando desta forma grande parte das empresas de hardware e software daquela época.

A disciplina de Product Management ganha um novo capítulo a partir da década de 60, com a introdução de uma nova abordagem - chamada de "mix de marketing" - formulada por Jerome McCarthy em seu livro Basic Marketing. O mix de marketing começa a ser usado para controlar e influenciar a forma como os consumidores se relacionavam com os produtos. O modelo é composto por 4 Ps: Produto (fornecer bens e serviços que respondam as necessidades dos clientes), Preço (valor cobrado pelo bem e\ou serviço prestado), Praça (distribuição dos produtos aos mercados consumidores) e Promoção (é a parte de comunicação e propaganda, lembrando e persuadindo o cliente sobre o produto ofertado).

Entretanto, devido aos longos períodos de desenvolvimento dos produtos, que poderiam levar meses ou até mesmo anos, os Product Managers concentravam-se em somente 3 Ps: Preço, Praça e Promoção. O último P (Produto) era delegado a outras áreas das empresas, como Pesquisa & Desenvolvimento. Esse foi o padrão dominante das quatro décadas seguintes.

Somente em 2001, com a publicação do manifesto ágil, inicia-se um novo capítulo na história da disciplina de Product Management. A partir desse momento, os Product Managers ganham flexibilidade para mudar, questionar e propor novos requisitos de forma mais dinâmica e intensa. É possível testar mais, ser mais ousado e atender mais aos anseios dos clientes.

A complexidade, o tempo e os processos de desenvolvimento de software mudam drasticamente. Requisitos são debatidos de forma multidisciplinar e intensa, envolvendo as métricas do analista de dados, a interação e comportamento do usuário analisados pelo profissional de UX, o esforço de implementação dos desenvolvedores, o SEO (Search Engine Optimization) e o SEM (Search Engine Marketing) do profissional de marketing e a automação do testador.

O sucesso do produto torna-se o resultado do trabalho multidisciplinar, onde o mix de marketing (Praça, Preço e Promoção) está agora intimamente ligado e dependente do “P “abandonado pelos Product Managers de outrora, o P de produto.

Infelizmente, esse cenário animador não se aplica até hoje na maioria das empresas, as quais mantém distintas as gestões de produtos e desenvolvimento, gerando uma série de infortúnios, prejuízos e anomalias que nada trazem de valor às empresas e aos clientes, ou seja, todos saem perdendo.

Dentre as anomalias está a distinção entre Product Owners e Product Managers dentro das empresas. Estes dois papéis são sinônimos para um mesmo fim (criar produtos de valor aos clientes e rentáveis para as empresas) e sua distinção funcional e nominal pode ser considerada uma anomalia mercadológica.

Os conflitos decorrentes destas distorções são inevitáveis. Delegar somente o desenvolvimento e execução dos requisitos aos Product Owners e seus respectivos times é deixá-los distantes do contato com os clientes, da visão do produto e do propósito do mesmo, gerando miopia em quem deveria estar atento aos mínimos detalhes.

Privar Product Managers da priorização e escrita de requisitos e do contato com o time de desenvolvimento é arruinar a qualidade do trabalho colaborativo, fomentar o handoff de informações e a incentivar a falta de unicidade, elementos que só corroboram para o fracasso do produto.

Outra grave anomalia é a transferência de responsabilidades e atribuições dos gerentes de produtos a outros profissionais e áreas, promovendo decisões cartesianas, departamentais e especializadas, incentivando a visão de silos ao invés da visão do propósito.

O ponto máximo destas distorções é composto pelo tempo desperdiçado, o investimento perdido e o produto que deveria servir, mas no final não serve para nada.

A gestão holística e centralizada do produto faz-se necessária. Desta forma, é possível executar uma priorização assertiva dos requisitos, a unicidade do propósito, a comunicação e transparência de informações e métricas, e desta forma atingir o sucesso do produto.

Nas próximas seções, serão detalhadas as atribuições dos product owners e product managers, algumas anomalias mercadológicas encontradas e propostas para resolver os problemas identificados.

Confira cursos que podem ser do seu interesse

• Curso Extreme Programming (XP)
• Série agilidade

Atribuições de Product Manager/Product Owner (PO)

Antes de definir as atribuições de um Product Owner/Product Manager, é válido reforçar algo importante: ambos são o mesmo papel e a coexistência de ambos não é um bom presságio. O Product Owner (PO) é o Product Manager no modelo ágil, mais propriamente dito no framework Scrum. Porém, outras metodologias como o Kanban (idealizado por David J. Anderson) também trabalham com este profissional.

O Product Owner é um papel multifacetado e não especializado, justamente porque precisa navegar entre diversas disciplinas para obter o sucesso do produto. Vamos listar as atribuições deste profissional:

• Visão do produto: definir e capturar a visão do produto, bem como partilhar ela com o time e stakeholders. É possível que o PO também represente a visão do CEO ou de um diretor de produtos e trabalhe para que a mesma seja realizada;
• Responsável pelo ROI (Return On Investment): o PO é o principal responsável por identificar oportunidades de mercado e melhorias que podem trazer mais valor ao produto. O acompanhamento constante das métricas e do mercado é de vital importância para este fim;
• Organização e priorização do backlog: o backlog do produto é o artefato onde ficam todos os requisitos que serão implementados, geralmente escritos no formato de user story. Sua organização e priorização seguem das histórias de maior valor para as de menor valor ao negócio;
• Planejamento de release: o lançamento de uma nova versão pode conter correções de bugs, novas features, melhorias e até mesmo reformatação do modelo de negócio. Cabe ao PO o planejamento destes releases, orquestrando datas comerciais, contratos e acordos firmados tanto internamente quanto externamente;
• Gerenciar interesses dos clientes, time e stakeholders: é muito comum haver conflitos entre stakeholders (makerting, comercial, financeiro, backoffice, P&D, etc.), que podem possuir interesses divergentes para o mesmo backlog. Cabe ao PO a mediação e decisão final;
• Gerenciar orçamento: apesar de infelizmente passar despercebido por muitos profissionais de produtos, cada user story tem um custo de produção que deve ser usado como critério de priorização. É muito comum também em Startups, POs serem responsáveis pelo EBTIDA do produto e responderem pelos gastos dos seus respectivos times;
• Autoridade para tomar decisões: todos concordam que o trabalho colaborativo traz muito valor ao produto, e o PO não é o sabe tudo do time, apesar de estar sempre muito bem informado. Porém, como em qualquer outra área, alguém precisa ter a palavra final e dar a direção correta. Este profissional é o PO.

Perfil de um de Product Manager/Product Owner (PO)

Por ser um profissional multifacetado, a tarefa de encontrar bons gestores de produtos torna-se árdua. Em seu livro “Inspired: How to create products customers love”, Marty Cagan descreve as características exigidas de um Product Manager/PO e que compõem o mosaico funcional do que deve ser um gestor de produtos:

• Paixão por Produtos: Product Managers são apaixonados por produtos. Estão sempre falando de modelos de negócios inovadores e de como estes modelos impactam a vida das clientes. Um Product Manager que não persegue e aprimora constantemente um modelo de negócios, é somente um gerador de requisitos, nada mais;
• Empatia pelos clientes: clientes são o propósito do produto. Entenda-se por empatia colocar-se no lugar do cliente, compreender seus medos, anseios e contexto. Cada vez mais, faz sentido usar abordagens como o Design Thinking para criar produtos com foco nos usuários, e não em nós mesmos;
• Inteligência: é necessária uma mente perspicaz para capturar oportunidades e costurar o trabalho multidisciplinar de forma valiosa e focada;
• Ética e Integridade: é uma grande responsabilidade gerenciar um produto. Quando um profissional se propõe a tal missão, deve agir de forma ética e com zelo pelo produto sobre sua alçada. Negligenciar a gestão de um produto é uma forma rápida de matá-lo. Afinal se o Product Manager não se importa com o produto, quem mais se importará?
• Confiança: o Product Manager é um líder, e mais do que isto, um vendedor do seu produto. A confiança passa a mensagem de segurança ao time, investidores e demais interessados de que o produto está em boas mãos;
• Atitude: decisões difíceis devem ser tomadas. Atitude é a energia que impulsiona a resolução de problemas. Não seria incorreto dizer que o sucesso ou fracasso de um produto seja a somatória das atitudes tomadas ou não pelos Gerentes de Produtos;
• Tecnologia: este é um ponto sempre controverso, porém é muito difícil escrever boas user stories sem o mínimo conhecimento de tecnologia. Produtos web são feitos desta matéria prima, e conhecer as principais tecnologias, padrões, protocolos e arquitetura web ajudam na negociação com os times e na priorização de requisitos com os mesmos;
• Foco: um Product Manager deve decorar a fórmula de lei de little: Tempo de espera = quantidade de trabalho em andamento / taxa de entrega. Esta fórmula nos ensina que, quanto mais trabalho em andamento, maior o tempo de espera de entrega. Imaginando que estamos falando de três features, ambas extremamente importantes para a companhia, você trabalharia em todas ao mesmo tempo ou faria uma por vez? Focar no que é mais importante trará resultados mais rápidos para a empresa e, inevitavelmente, o que for de menor valor ficará para trás;
• Gestão de tempo: o foco do Product Manager deve ser as tarefas mais importantes e valiosas ao Produto. Como “key person”, deverá estar vigilante quanto ao assédio constante dos stakeholders, que têm como objetivo a realização dos seus respectivos interesses. Faz parte do ofício do Product Manager gerenciar este assédio, contanto que ele não prejudique o tempo do produto;
• Comunicação: talvez um dos quesitos mais importantes. Um gestor de produtos está a todo momento negociando e vendendo o seu produto através da fala. A arte de se comunicar de forma clara e objetiva deve ser um traço inerente deste profissional, e obviamente esta qualidade é transferida para o ato da escrita dos requisitos;
• Habilidades de negociação: delegar, vender, comunicar, mediar, promover, informar, priorizar, todas estas ações se concretizam no contato com o outro. Trabalhar nos melhores acordos através da empatia, serenidade, foco e ética sempre garantem um resultado satisfatório.

Anomalias encontradas na gestão de produtos web

Nesta seção, serão analisadas algumas anomalias envolvendo Product Owners (PO) / Product Managers no mercado, iniciando pela própria contradição entre estes dois papéis, bem como outros problemas decorrentes da descaracterização e desconstrução das responsabilidades e atribuições do gestor de produtos.

Anomalia 1: Gestão do produto dividido entre Product Owner e Product Manager

Este cenário é decorrente da fusão dos elementos dos processos ágeis com a disciplina de product management, principalmente em empresas tradicionais como bancos, governo, telefonia e grandes empresas de varejo.

A falta de conhecimento do papel do PO por estas empresas e da disciplina de Product Management pelo movimento ágil, propiciou várias distorções e adaptações para estes perfis, dentre elas a divisão da gestão do produto em dois, onde o Product Owner ficou responsável pela execução e andamento do backlog, mas sem muita autoridade sobre o mesmo. O Product Manager por sua vez ficou encarregado de ouvir e ser a voz do cliente, de cuidar de toda parte promocional, de aquisição e vendas, o que explica de certa forma a predominância de profissionais de marketing atuando neste papel. Em suma, o Product Owner olha para dentro da empresa (desenvolvimento), enquanto o Product Manager olha para fora (mercado).

Este cenário traz uma série de consequências: lacunas no entendimento dos requisitos, falta de alinhamento e planejamento entre as áreas envolvidas, fragmentação da autoridade e responsabilidade do produto, problemas decorrentes de ruídos e falta de comunicação, perda de foco e dificuldade de priorização.

Anomalia 2: Gerente de Marketing atuando como Gerente de Produtos

Estes profissionais geralmente trabalham focados em metas agressivas de receita. Inevitavelmente, um profissional de marketing como gerente de produtos irá priorizar histórias que favoreçam o alcance destas respectivas metas e certamente o mesmo aconteceria se um arquiteto fosse o dono do backlog, que acabaria por sua vez priorizando histórias mais técnicas. O problema é que o foco em receita desvaloriza o restante das métricas importantes do funil do produto: aquisição, ativação, retenção e recomendação.

A receita, portanto, é a etapa final do caminho do usuário, desde a sua chegada até o momento que ele paga por um determinado serviço. Porém, o foco obsessivo em receita traz como consequência uma gestão de produto imediatista, comprometendo a gestão sustentável de longo prazo.

Desta forma, toda e qualquer história que não seja relacionada diretamente à receita, não será priorizada. É uma questão de tempo para que o valor do produto seja corroído, e após algum tempo, ele perca o valor e interesse dos usuários e deixe de existir no mercado.

Anomalia 3: Gerente de Projetos atuando como Gerente de Produtos

O gerente de projetos tem a responsabilidade de alinhar os requisitos, garantir a comunicação e o tracking do projeto e, na maioria das vezes, também assume tarefas de gestão de pessoas, como controle de pontos de horas e demais assuntos administrativos. Delegar a gestão do produto a este profissional envolve uma série de problemas.

O primeiro deles é que o gerente de projetos dentro de uma estrutura matricial é extremamente sobrecarregado. O papel deste profissional é chave para fazer toda a engrenagem girar e o projeto andar. O foco, portanto, é extremamente direcionado para a execução e entrega do projeto, porque não há tempo para olhar oportunidades e melhorias do produto.

Ainda dentro da estrutura matricial, raramente este profissional tem a oportunidade de sugerir ou opinar sobre os requisitos, pois os mesmos são definidos por diretores ou um board executivo, cabendo ao gerente de projetos o papel de executor e não de questionador.

A própria estrutura matricial não é pensada para gestão de produtos, e quando há um gerente de produtos nesta estrutura, ele compartilha dos mesmos problemas encontrados na anomalia 01, onde o product manager divide a responsabilidade do produto com outro profissional.

Portanto, um gerente de projetos assumir a gestão de produtos, no cenário matricial, é a mesma coisa de não ter um. Dentro da perspectiva ágil, as responsabilidades de gestão do projeto são assumidas pelo time de desenvolvimento, o que libera este profissional do foco em "projetos" e lhe incube o foco em "desenvolvimento", direcionando suas energias no desenvolvimento de pessoas e da área de tecnologia como um todo, o que preenche todo o tempo deste profissional.

Além disto, a metodologia ágil já delega a gestão do produto ao Product Owner, o que elimina a necessidade de o gerente de projetos assumir a gestão de produtos. Porém, caso isto aconteça, o product owner terá assumido também a responsabilidade de gestão do projeto, descaracterizando o seu papel no time e impactando a saúde do produto. Esta anomalia também afetará o agile master, que terá um desafio extra na missão de migrar a gestão do projeto do gerente de produtos para o time de desenvolvimento.

Anomalia 4: User experience designer (UX) atuando como Gerente de Produtos

O mercado entendeu finalmente a importância deste profissional para o sucesso de um produto. O user experience designer, popularmente conhecido como UX, é o profissional encarregado de toda experiência e interação dos clientes com os produtos. Isto não é pouca coisa, estes profissionais passam anos estudando técnicas como user mapping, focus group e técnicas de pesquisas qualitativas e quantitativas, design thinking, design service, psicologia dentre tantas outras.

Apesar de haver uma intersecção entre o product manager e UX, uma vez que ambos advogam em prol do usuário, isto não os fazem ter as mesmas atribuições e responsabilidades. A entrega de valor aos clientes é obtida através do trabalho de várias disciplinas, sendo UX somente uma delas.

Muitas vezes é necessário sacrificar o valor ao usuário final por questões técnicas, restrição de orçamento e conflitos internos. Achar o ponto de equilíbrio, na maioria das vezes, é uma tarefa árdua. Apesar do valor ao cliente ser o ponto a ser perseguido, inegavelmente isto se faz no acordo entre os interesses destes e os da empresa. Como o foco do profissional de UX é extremamente centrado no usuário, isto o impede de uma visão mais holística, principalmente sobre a disciplina técnica, o que explica o porquê deste profissional não ser recomendado para a gestão do produto.

Anomalia 5: Gerente de Tecnologia atuando como Gerente de Produtos

A matéria prima dos produtos web é a tecnologia. Somente os profissionais desta área compreendem a complexidade que toda esta disciplina envolve. As áreas são diversas: banco de dados, infraestrutura, operações e desenvolvimento. E para aumentar a complexidade, todas estas áreas são lideradas por profissionais especializados e com diferentes skills.

Todo profissional de tecnologia é focado em resolução de problemas e dentro de sua especialidade, procura sempre fazer isto de forma técnica. Aqui reside o perigo em delegar a gestão de produtos para um gerente de tecnologia.

Tomando como referência as anomalias 2 e 4, onde se explanou os problemas de especialidades serem donas do backlog do produto, o gerente de tecnologia irá priorizar naturalmente histórias de cunho técnico, e os demais requisitos irão perder importância e valor. É o típico caso onde o produto tecnicamente é impecável, porém sem valor de mercado. Conforme cita Marty Cagan no livro Inspired How to create products customers love: "Construir corretamente o produto é diferente de construir o produto certo."

Anomalia 6: Agile Master atuando como Gerente de Produtos

Processo é a forma de se construir ou produzir algo. Um gestor de produtos eficiente deve ter na manga conhecimentos e técnicas desta disciplina, principalmente conceitos provenientes do sistema Toyota de produção (Lean).

O agile master é a fonte e autoridade quando o assunto é processo. Ele é responsável por prover coach e treinamento aos times de desenvolvimento, e muitos destes profissionais vêm se especializando para atender aos anseios dos profissionais de produtos, lhes ensinando técnicas como Lean Startup, Lean, Kanban dentre outras.

Apesar do skill de processos ajudar na gestão do produto, esta habilidade só ganha impulso se for usada para orquestrar a evolução e retorno do investimento de um produto. É forte a tendência do agile master em focar mais no processo do que na evolução do produto, o que explica o porquê deste profissional não poder liderá-lo.

Product Manager/PO generalista x especialista

Como detalhado nas seções anteriores, fica claro o papel generalista de um Product Manager/PO. O gerente de produto é pluralista e via de regra gosta de navegar entre as demais disciplinas. É por causa deste perfil que este profissional consegue desenvolver a visão holística e convergir os trabalhos dos especialistas em um ponto em comum: a proposta de valor ao produto.

Muitos leitores podem achar que não é possível um gestor de produtos ser tão generalista. Na verdade, o perfil pregado como ideal no mercado, o do especialista em um determinado campo, não é o único a ser tido como padrão. Esta visão de especialização profissional é fruto da filosofia cartesiana e da revolução científica, onde a visão pluralista do conhecimento começa a dar lugar a análises e estudos mais segmentados.

Porém, no renascimento o modelo era justamente o contrário, a pluralidade era cultuada como modelo ideal para desenvolver o intelecto e potencialidades humanas. A escritora e artista Emilie Wapnick em sua palestra no TED (ver seção Links), nomeia estes profissionais de multipotencialidades. Ela explana que existem dois perfis de pessoas: as que gostam de se aprofundar em um respectivo assunto por muito tempo (os especialistas) e os que gostam de aprender sobre tudo, e tem necessidade de conhecer e aprender vários assuntos diferentes (os generalistas).

São dois perfis que se complementam e que juntos geram ótimos resultados. O Product Manager/PO mapeia, compartilha e gerencia a visão e proposta do produto, e a partir desta orientação, os especialistas começam a construção e materialização da visão.

Contra anomalias, times "produtizados"

As anomalias citadas prejudicam o trabalho dos times ágeis e o valor entregue aos produtos, tendo efeitos negativos em toda a cadeia produtiva. Porém, estes males podem ser remediados. Antes de mais nada, vale ressaltar a diferença conceitual entre produto e projeto.

Projeto é uma empreitada com começo e fim, com objetivo de entregar um produto ou melhoria. Um produto, por sua vez, é um meio de se entregar um serviço e com prazo indefinido de término (termina quando o modelo de negócio se esgotar).

Este conceito deriva do modelo Service Dominant Logic (SDL), introduzido por Stephen Vargo e Robert Lusch em 2004, em uma edição do Journal of Marketing. Tennyson Pinheiro e Luis Alt, explicam este modelo no livro Design Thinking Brasil: "Este modelo defende uma mudança na antiga perspectiva tradicional de produtos, que enxerga serviços apenas como atributos e custos de uma oferta. Segundo a SDL, tudo é serviço. Produtos são, então, bens tangíveis que orbitam no ecossistema de um serviço. ".

Vamos dar um exemplo: um e-commerce de roupas é um serviço de vendas e entrega de vestuário. Esta é a "serventia" e valor do mesmo ao cliente. Um serviço por sua vez é composto por um ou vários produtos, que são os meios de se entregar um serviço. No caso deste e-commerce, o pagamento é um produto, pois ele permite que o cliente pague suas compras utilizando vários meios de pagamento. O delivery é outro produto, pois permite que a compra seja entregue na casa do cliente. Ambos produtos orbitam o ecossistema do serviço de vendas de vestuário.

O serviço de música Spotify é uma das empresas que usam este modelo. Dentro deste serviço, os times de desenvolvimento são autônomos, multifuncionais e responsáveis cada um por um produto. Exemplo: os playlists do Spotify são gerenciados por um time, que é responsável pelo uso e entrega de valor deste produto dentro do serviço de música Spotify. Este time tem como meta concretizar a visão e melhorar as métricas deste respectivo produto, cujo responsável é o Product Owner. Portanto, o PO define a visão, métricas e histórias, e todo o resto do trabalho fica a cargo do time, que executa e responde por tudo o que for feito.

Ás vezes acontece de os produtos crescerem mais do que os serviços que os originaram, como foi o caso do PayPal no eBay. O meio de pagamento criado para sustentar o Ebay hoje é independente e maior do que o próprio eBay. O fato da indústria de software estar adotando o modelo de produtos para o desenvolvimento de softwares não significa que projetos não são mais necessários.

Produtos podem ter projetos, isto é perfeitamente normal dentro da concepção de que um projeto é um trabalho finito. Um projeto é bem-vindo quando o escopo e necessidade do que será implementado são conhecidos, válidos e importantes para o cliente e/ou para o produto. A anormalidade está em empresas que conduzem produtos como se fossem projetos, dentro de estruturas matriciais.

Nestes casos, você não constrói times perenes e focados na evolução de produtos, mas sim times efêmeros focados na entrega de projetos. Quando estes acabam, todo o conhecimento é pulverizado em novos projetos e times. Esta forma de trabalho é ineficiente e retrógrada, pois gera pouco envolvimento dos profissionais, que são sempre alocados temporariamente em alguma frente. São os profissionais que trabalham mais focados em tickets do Jira do que em histórias de evolução e valor aos clientes.

Um time focado em produto usa sua energia e inteligência em melhorar de forma incremental e colaborativa o produto. Estes times usam de métodos, como o Lean Startup, para validar as suas hipóteses e aprender com o resultado dos experimentos, gerando desta forma conhecimento, que por sua vez se reverte em valor ao produto.

Esta forma de trabalho gera uma atmosfera desafiadora e dinâmica, o sentimento de "dono" é incorporado pelo time, e os ganhos não demoram a aparecer. Todos integrantes do time sentem-se de fato parte do produto e do processo: brigam, discutem, vibram e vivem cada conquista e derrota intensamente.

A tríade proposta no livro Drive, do autor Daniel Pink, materializa-se em toda a sua potencialidade em um ambiente produtizado:

• Maestria, onde cada profissional especializado faz o seu melhor;
• Autonomia, permitindo a independência e liberdade de trabalho;
• Propósito, razão pela qual se faz algo, o bem maior que faz tudo ter sentido.

O papel do Product Manager/Product Owner é dar este sentido, servindo de guia no cenário diário de incertezas, complexidades e desafios que envolvem o desenvolvimento de um produto.

O papel Product Manager/Product Owner está sendo debatido como nunca. Esta discussão era previsível, uma vez que os times ágeis vêm progredindo e cumprindo o seu papel de serem mais eficientes no desenvolvimento de software. Logo, é natural que as atenções se voltem para a eficácia, cuja responsabilidade cabe ao Product Manager/Product Owner.

Entender as atribuições, responsabilidades e importância do gerente de produtos dentro de um time, fortalece o movimento ágil como um todo e impacta diretamente na entrega de valor para as empresas, os clientes e a sociedade.