Uma história da Gestão de Produtos
Como software e a web obrigaram duas mentalidades diferentes, a do Marketing e a da Engenharia, a se aproximarem, até chegarmos a Product Management como conhecemos
A história de Product Management está em construção e, provavelmente, só conseguiremos contá-la de forma mais consistente dentro de décadas, quando a poeira e o buzz baixarem. Mesmo assim, nada impede de tentarmos juntar fatos disponíveis, interpretá-los e entender como esse ofício, profissão ou "arte" se consolidou como uma posição importante, desejada e bem remunerada nos negócios atuais.
Simplificadamente, há autores, como Joaquim Torres, um dos pioneiros na Gestão de Produtos no Brasil, no livro “Gestão de Produtos: Como aumentar as chances de sucesso de seu software”, que atribuem as origens de Product Management ao Mix de Marketing clássico.
Criado por Jerome McCarthy, em seu livro Basic Marketing, de 1960, e depois difundido pelo “papa” do Marketing Philip Kotler, o Mix esquematiza o Marketing como um conjunto de quatro “Ps”: Produto, Preço, Praça e Promoção. Product Management seria a especialização do “P” de Produto.
Observando-se outras referências que tentam abordar a história da área, porém, é possível enriquecer a abordagem e notar que a Gestão de Produtos atual pode ser entendida como uma construção a partir de duas frentes, que são:
o Marketing, aqui entendido como tudo aquilo que visa entender, satisfazer e conquistar clientes (o que abrange desde a gestão da marca até a experiência do usuário), domínio que se desenvolve e se consolida nas indústrias tradicionais de bens de consumo físicos, entre as décadas de 1930 e 1970, mais ou menos;
a Engenharia, aqui entendida como o domínio que cuida da construção de bens tangíveis ou, no caso da tecnologia da informação, de "bens" (se é que ainda podemos usar essa palavra) intangíveis, e que é a primeira a se deparar com a complexidade dos produtos de software, os quais escalam rapidamente a partir dos anos 1970 até os 2000.
A partir de então, os caminhos do Marketing e da Engenharia se tornam uma linha mais ou menos sobreposta até os dias atuais, moldando a função de Product Management como a conhecemos.
Um divisor de eras nesse processo, não só para essas duas mentalidades, o Marketing e a Engenharia, mas para praticamente todos os domínios do conhecimento, é o termo software.
Se etimologicamente é uma palavra oca (algo como “ferramenta abstrata”), nascida apenas para significar o oposto de hardware (que quer dizer “ferramenta física”), na prática é como algum tipo de magia ou bruxaria, porém paradoxalmente fundamentada em lógica e racionalidade, capaz de avançar e transformar os domínios mais improváveis.
Em Structure and Interpretation of Computers Programs (Estrutura e Interpretação de Programas de Computadores), um livro de 1985, reeditado em 1996 (com exercícios em Lisp!) e usado por muito tempo no MIT, há uma analogia muito boa sobre os “poderes” que o software nos deu:
“Um processo computacional [software] é de fato muito parecido com a ideia de espírito de um feiticeiro. Não pode ser visto ou tocado. Não é composto de matéria de forma alguma. No entanto, é muito real. Ele pode realizar trabalho intelectual. Pode responder a perguntas. Pode afetar o mundo desembolsando dinheiro em um banco ou controlando um braço robótico em uma fábrica. Os programas que usamos para conjurar processos são como os feitiços de um feiticeiro. Eles são cuidadosamente compostos de expressões simbólicas em arcanas e esotéricas linguagens de programação que prescrevem as tarefas que queremos que nossos processos executem.” — SICP, Capítulo 1: “Building Abstractions with Procedures” (“Construindo abstrações com procedimentos”).
Software tornou tudo muito mais complicado e interessante do que apenas produzir toneladas de alguma gordura perfumada, cortá-las em tabletes, embalá-las em papel estampado, empilhá-las em prateleiras de supermercados e anunciar, em outdoors e panfletos, que chegava ao mercado: “O sabonete para mulheres bonitas”.
Na falta de um modelo mental melhor, porém, produtos de software acabaram sendo construídos e vendidos como sabonete ou, no máximo, como “ferramenta”, por um bom tempo após virem ao mundo.
Contudo, foi a maior criação da dupla hardware e software — a Internet — que veio para pôr a pá de cal em tudo o que achávamos que sabíamos e nos obrigar a unir as duas mentalidades citadas, a do Marketing e a da Engenharia, em busca de soluções colaborativas e adaptativas.
A Internet fez o software deixar de ser ferramenta para se tornar um meio de fornecer serviços complexos, até então inviáveis ou inimagináveis, e é nesse estágio que entramos há cerca de duas décadas e estamos até agora.
Vamos recontar os melhores momentos dessa jornada para ver como chegamos na Gestão de Produtos atual. A história, a propósito, começa com os sabonetes.
“Homem da Marca” na P&G
Há quem diga que o Marketing existe desde que nos tornamos sapiens e há quem associe até Cristo a um marqueteiro “superstar”. Outros regressam à invenção da pólvora, na Antiguidade Chinesa, para associar a história da humanidade a uma grande Gestão de Produtos.
Criatividade e exageros à parte, parece ser consenso que uma das origens de Product Management esteja na Procter and Gamble (P&G), multinacional produtora de bens de consumo rápido (FMGC, no inglês), na década de 1930.
Na época, um executivo júnior, Neil McElroy, que trabalhava na campanha publicitária do sabonete Camay — uma inovação para a época, que por anos carregou o slogan “O sabonete para mulheres bonitas” —, tomou a liberdade e a coragem de escrever um memorando à diretoria da empresa.
No documento, solicitava a contratação do que chamou de “Homens da Marca”, mais especificamente um “Brand Man” (o “Homem da Marca”, literalmente) e um “Associated Brand Man” (em tradução livre, um “Auxiliar do Homem da Marca”).
Um predestinado — McElroy não só chegou à presidência da P&G, como se tornou Secretário de Defesa dos EUA, ajudando a fundar nada menos que a NASA —, o pedido acabou atendido, dando início à Gestão da Marca (Brand Management) moderna.
Na prática, assim como os departamentos de Marketing fazem até hoje, a inovação colocou pessoas especializadas para cuidar de todo o ciclo de vida do produto no que dizia respeito à sua precificação, aos pontos de venda onde eram comercializados e à sua promoção (desde embalagem até materiais de propaganda).
Ou seja, os brand men se tornaram responsáveis por três (“Preço”, “Praça” e “Promoção”) dos quatro “Ps” do Mix de Marketing clássico.
Em vez de ficarem sentados em um departamento criando ideias do nada, esses brand men inauguraram uma nova era, em que eram obrigados a conhecer as características do produto, ir até os pontos de venda, conversar com vendedores, enfim, estar muito mais próximo da fronteira entre empresa e clientes.
Moda pega na “startup” pioneira do Vale do Silício
A Universidade de Stanford, assim como outras dos Estados Unidos, colaborou com esforços de pesquisa de guerra do país, os quais mais tarde impulsionaram inovações como o desenvolvimento de computadores e a criação da Internet (ou da pré-história dela).
Foi em consultorias no campus da instituição que McElroy, certamente por causa de sua posição como Secretário de Defesa, fez contato com dois jovens engenheiros elétricos que, não por acaso, vieram a produziram osciloscópios e outros equipamentos ao Exército Americano: Bill Hewlett e David Packard.
Os dois detêm o trunfo de fundar a startup que inaugurou o Vale do Silício: a Hewlett & Packard (HP) — millennials talvez se lembrem de scanners e impressoras da marca —, companhia que nasceu em uma arquetípica garagem de Palo Alto, na Califórnia, associando startups a empreendimentos de jovens nerds em garagens.
O que interessa, porém, é que a HP, seguindo a filosofia dos brand men de McElroy, foi além e criou silos para cada um de seus produtos, que funcionavam como empresas próprias dentro da companhia. O resultado foram equipes de Marketing e de desenvolvimento de produto (Engenharia) muito mais próximas e trabalhando para entender o que o mercado necessitava.
Em uma comparação bastante rude, é como se os silos da HP fossem a pré-história dos squads que o Spotify criou em 2012 e que hoje são difundidos como padrão na maioria das startups e empresas de tecnologia.
Bill e David não pararam por aí. Eles também importaram conhecimento oriental para alavancar a Gestão de Produtos da empresa.
Filosofia japonesa
Foi observando supermercados americanos que Kiichiro Toyoda, fundador da Toyota Motors, chegou ao conceito de sistema “puxado” da montadora e a todo o Toyota Production System (TPS), nos anos 1950, que viria a revolucionar a manufatura de produtos físicos transmitiu genes a metodologias de desenvolvimento de software.
O mérito do TPS foi tornar a companhia mais ágil e enxuta, para produzir automóveis que os clientes desejavam (uma necessidade para competir com a indústria automobilística americana, então a maior do mundo) com o mínimo de desperdícios (outra necessidade, frente à escassez de recursos do Japão no pós-guerra).
Vem da Toyota e do TPS um bocado de métodos e conceitos usados até hoje em indústrias do mundo inteiro, como a produção just-in-time(produzir sob demanda e não para estocar), o kanban(sistema de gerenciamento da produtividade), o 5S (princípios para organização e limpeza de ambientes de trabalho), entre vários outros.
Tudo isso foi implantado na HP e em outras empresas ocidentais, muito a cargo dos departamentos de Engenharia, contribuindo para melhorias no desenvolvimento de produtos e no aumento da produtividade.
Mentalidades ainda separadas
Apesar de todos esses avanços, a própria característica e lógica de produção de produtos físicos manteve por muitas décadas embalagem e conteúdo, Marketing e Engenharia, bastante separados.
O sabão em pó Tide, também da P&G, apesar de considerado uma revolução tanto no desenvolvimento de produto (Engenharia) quanto na sua promoção (Marketing) quando lançado, por volta de 1945, demonstra essa divisão.
O produto foi o primeiro sabão em pó sintético mundialmente lançado, o que era um feito de P&D e Engenharia Química da empresa, e teve uma divulgação à altura, a ponto de ser considerada um marco da virada da P&G de fábrica de sabonetes para uma verdadeira indústria de tecnologia (o artigo “How Tide Cleaned Up the Competition”, de 2004, na Harvard Business School, conta toda a história).
Entretanto, Marketing era responsável pela caixa do sabão em pó, por posicioná-la em stands de venda e por gritar ao mundo que um novo tipo de produto de limpeza nascia. Pouco lhe diz respeito a composição química do sabão — e mesmo que o pó colorido dentro da caixa fosse uma farsa, ainda assim o Marketing poderia ter êxito e continuar levando a fama de ser capaz de vender até “fumaça enlatada”.
Por outro lado, a Engenharia perdia o domínio sobre o produto após ele ser embalado, ir para os supermercados e acabar na máquina de lavar de clientes. Talvez isso já acontecera quando a fórmula fosse à linha de produção para virar sabão em larga escala. Um detalhe que passava batido (o sabão não limpava as roupas como prometia, ou as manchava, ou o pó virava pedra depois de armazenado) poderia mandar todo investimento ao espaço.
Era fácil louros e culpas serem apontados ao Marketing ou à Engenharia em um ciclo como este, o que certamente perdura até hoje, sobretudo em empresas em que as duas mentalidades (mais do que departamentos ou profissionais) trabalham dissociadas.
Software de prateleira
Software, como dito no início, tornaria tudo muito mais complicado e interessante do que produzir sabão em pó e sabonetes, impressoras e, mais tarde, até carros.
Mas isso não aconteceu da noite para o dia. Por um bom tempo, até a Internet surgir e tomar conta de nossa vida, software genérico, para consumo de massa, continuou sendo planejado e produzido, anunciado e vendido da mesma forma que produtos físicos. As circunstâncias também contribuíam com isso.
Um batalhão de engenheiros e arquitetos técnicos — design de experiência do usuário nem fazia sentido na época — normalmente projetava e desenvolvia um código monolítico, compilava-o em arquivos instaláveis e salvava-o em escala industrial em uma série de CDs ou, antes, em disquetes de 31/2 ou 51/4 de polegadas.
O Marketing tratava de fazer com que esses CDs ou disquetes saíssem embalados em “caixinhas” da fábrica, com alguma identidade visual (algumas pouco atraentes, como se pode ver) e seguiam para venda em prateleiras de lojas — no Brasil, não raro acabavam pirateadas em camelôs.
Os mesmos millennials que usaram impressoras da HP certamente se lembram, com um misto de saudosismo e alívio, como era levar passar horas, se nada desse errado, é claro, para instalar o Windows 95 (ou um Red Hat Linux, para os mais geeks), a Suíte Office ou um CorelDRAW, que fez sucesso (e inimigos) em comunidades de design gráfico.
Essa maneira de produzir e distribuir programas acabou originando o termo “software de prateleira”. A gênese do termo “produto”, que usamos hoje para sistemas e aplicativos, de certa maneira está enraizada nesse conceito de software como algo que vem em uma embalagem, é vendido em loja e, de certa forma, ainda pode ser pego na mão.
(No Brasil, o conceito foi tão importante que determinou até a cobrança de impostos. Software de prateleira, para venda em série, era tributado como mercadoria (“produto”), por meio de ICMS. Software criado ou personalizado sob medida para um cliente, por sua vez, era tributado como “prestação de serviço”, por meio de ISS. O entendimento mudou em 2021.)
O software personalizado, obviamente, também rendeu frutos. Grandes empresas — a Intuit, que produz software financeiro e tributário nos Estados Unidos é um exemplo bastante citado em referências — souberam dominar filões de mercado e faturar em cima com chamados para personalização de software (quando não correções de bugs disfarçadas de melhorias).
O que fica da época para a Gestão de Produtos atual é que nascia ali um conceito de software como “produto”, que já podia ser comercializado em escala, poderia gerar alguma receita recorrente com atualizações e manutenções, mas, até pelos custos e limitações dos computadores, acabava muito mais em mãos corporativas do que pessoas físicas.
Apesar de permitirem gerir as contas correntes de um banco ou as operações de de uma usina hidrelétrica, esses softwares ainda não conseguiam otimizar serviços em larga escala como logística de mercadorias, de passageiros, hospedagens, compras, consultas médicas e afins.
A Engenharia dá seu jeito
Engenheiros, que foram os primeiros a capitalizar com a fama e dinheiro que o software trouxe, em compensação também sentiram na pele seus problemas, em forma de sistemas legados e débitos técnicos.
Não raro, uma solução era minuciosamente desenhada por arquitetos. Em seguida, escrevia-se um extenso documento de requisitos. O documento então ia a um gerente de projeto, que estabelecia cronograma e recursos para o desenvolvimento. Por fim, engenheiros passavam meses programando o código. Era o modelo Waterfall (cascata) em pleno funcionamento.
O problema é que quando o produto chegava às lojas ou era oferecido por um consultor de vendas a uma empresa, poucos entendiam como usá-lo, a maioria talvez nem precisasse dele e ninguém estava disposto a pagar por aquilo. Resultado: engenheiros frustrados e negócios perdendo dinheiro à toa.
O Manifesto Ágil, de 2001, é um dos maiores expoentes das saídas que a própria Engenharia encontrou para contornar essas consequências. Em resumo, ele estabeleceu princípios para desenvolver código de uma forma mais flexível, informal e adaptativa, em contato com o cliente, ouvindo suas necessidades, do que da forma rígida e em esteira como era feito.
Outros métodos, como eXtreme Programming (XP) e o próprio Scrum, que faz parte da Metodologia Ágil, vieram antes do Manifesto, mas foi ele quem consolidou o mindset. A Metodologia Lean Startup (Startup Enxuta), que também emprega muitos princípios da filosofia da Toyota, difundiu o Agile nas startups que amadureceram após os 2000. A bolha das empresas “ponto com”, na época, também foi pano de fundo para a busca de soluções comercialmente mais assertivas.
Uma das maiores contribuições do Movimento Ágil para o conceito de “produto” que temos hoje foi que software não era a mesma coisa que um sabonete, um microondas ou um carro. Havia muito mais riscos, imprevistos e incertezas em desenvolvê-lo do que produzir artefatos físicos. O melhor caminho era construir aos poucos, testar (iterar) com o clientes ou no mercado, aprender com o que precisava ser corrigido ou melhorado e, assim, de iteração em iteração, evoluir o produto por meio de melhoria incremental e contínua.
Outra contribuição do Agile foi criar o papel do Product Owner (PO), que continua presente em muitas organizações. Esse papel faria o “meio-de-campo” entre partes interessadas, como clientes externos que comprariam a solução e executivos da empresa que a desenvolvia com o time de desenvolvedores, de forma similar aos PMs atuais.
Era a pessoa que traduziria demandas do Negócio para a Engenharia e vice-versa, priorizaria o que fazer na próxima sprint (ciclo de desenvolvimento) e ajudaria a entender para onde a solução estava caminhando (visão).
O problema é que muitas organizações reduziram o papel a uma função da Engenharia, tornando-o um “entregador de bilhetes” acerca do que os programadores deveriam desenvolver, sem autonomia ou atribuições estratégicas.
Mesmo assim, a presença de uma pessoa encarregada de pensar e planejar o ciclo de desenvolvimento do produto era um avanço em relação aos modelos de “fábrica de software” que se tinha antes.
É em torno dessa época, também, que surgem engenheiros que começam a ver software com a cabeça do Marketing. Eles já não estavam mais preocupados só com o desenvolvimento, mas com todo o propósito e ciclo de vida do “produto de software”.
Um dos maiores exemplos dessa mudança de mentalidade, que também se tornou ícone nas comunidades de Product Management, é Marty Cagan, autor do livro Inspired, uma espécie de “bíblia” para muitos gestores de produto.
Cagan foi desenvolvedor de software (para variar) na HP, depois na Netscape, no eBay e em outras empresas, ou seja, em algumas das maiores expoentes da revolução do software, antes e nos primórdios da Internet.
Ele relata casos de falta de ajuste entre Marketing e Engenharia, que resultaram em produtos que ninguém comprava, o que o fez migrar para a Gestão de Produtos como motivações, ideias e ideais novos, os quais passou praticamente a “evangelizar” por meio do Silicon Valley Product Group (SVPG).
A Engenharia descobriu, assim, que não bastava fazer soluções mirabolantes no nível do código ou funcionalidades que ninguém queria ou sabia usar. Passou a pensar com uma mentalidade de Marketing, no sentido de ajustar o produto ao mercado desde sua concepção. O Marketing, por outro lado, teve de mergulhar mais fundo no “P” de Produto de seu mix clássico.
Produto se torna serviço
A Internet veio para pôr a pá de cal no que era tangível e criar um mundo de oportunidades e riscos intangíveis, principalmente entre os anos 2000 e 2010.
Quem vem de um background de Engenharia, sabe a dor de cabeça que a palavrinha “evento” colocou no desenvolvimento de software a partir dessa época (conceitos como concorrência, paralelismo, frameworks como Node e React, busca por linguagens funcionais e outros termos técnicos estão relacionados a isso).
De repente, não estávamos mais trabalhando com “objetos” ou com abstrações que ainda lembravam o mundo físico, mas com transações, e, para piorar, milhares, milhões ou bilhões delas, deixando rastros sem precedentes em bancos de dados (o que daria origem ao Big Data).
Isso nos deu poder de explorar soluções inovadoras e alterou a noção de “produto” sem que nos déssemos conta. Software foi para os bastidores, tornou-se o que toda tecnologia sempre foi (meio), para suportar uma gama de novos “serviços” (fim), até então inviáveis ou inimagináveis.
Provavelmente, foi mais cômodo continuar chamando o que era feito de “produto”. Mas talvez fosse mais preciso se Product Management hoje se chamasse Service Management, dada a natureza transacional das soluções atuais.
Afinal, o que são as grandes inovações que a Web permitiu, do consumo de filmes (Netflix) à venda de qualquer coisa (Amazon), da indexação de informações (Google) e ao compartilhamento da vida (Facebook, Twitter, Instagram), do transporte de passageiros (Uber) ou hospedagem (AirBnB) à entrega de alimentos (Ifood, UberEats, Zé Delivery etc.), das soluções que otimizam atividades no campo àquelas que automatizam rotinas industriais ou de escritório?
Essas soluções vão muito além de um aplicativo no smartphone e, vistos de forma mais ampla, são, na verdade, imensos fluxogramas de operações executadas por máquina e interagindo com o mundo físico por meio de pontos de inputs e outputs de informações. A tela é só um desses pontos.
Essa nova realidade obrigou Marketing e Engenharia a se entenderem do começo ao fim na concepção e desenvolvimento de novos produtos. A incerteza sobre se um produto digital atrairia consumidores e a complexidade para construí-lo ou evoluí-lo, mais a concorrência crescente e a escassez de pessoas formatadas para esse tipo tarefa, fez empresas iniciarem uma corrida por “talentos” inexistentes.
Assim como a busca por desenvolvedores de softwares talentosos na década anterior, nos 2000 a 2010 o fenômeno se repetiu com criadores de produtos “geniais”, “unicórnios”, “rockstars”, “CEOs do produto”, entre outras denominações que ajudaram a criar mitos sobre a função.
Como Ken Norton, ex-Google e um dos grandes nomes da Gestão de Produtos mundial, escreveu em um artigo seminal de 2005, procurava-se alguém com “instintos inatos de produto”. A impressão que se tem é que se estava realmente em busca de talentos individuais capazes de revolucionar a indústria com sacadas geniais, algo que teve seu auge no fim da década com Steve Jobs.
“Acredito piamente que certas pessoas nascem com instintos inatos de produto. Essas pessoas simplesmente sabem o que torna um ótimo produto. Eles nem sempre estão certos, mas seus instintos geralmente apontam na direção certa.” — Ken Norton.
Antecipando-se, a Google, já em 2001, decidiu formar seus próprios gestores de produto. Por meio de sua primeira PM, Marissa Meyer, criou o programa APM (Associate Product Manager), uma espécie de curso que formou não só muita mão-de-obra para a próprio Google como criou alguns dos nomes mais influentes da Gestão de Produtos em anos posteriores, alguns dos quais, mais tarde, viraram CEOs e investidores de novas startups.
O foco em construir soluções que os clientes necessitam ou desejam também ajudou a entender que o Marketing precisaria aprofundar a antiga pesquisa de mercado. Já não bastava apenas mapear público-alvo, faixa etária, regiões etc., como se fazia com produtos tradicionais. A Engenharia, da mesma forma, não tinha como otimizar aquilo que não era testado com pessoas reais.
Foi quando pesquisadores e designers de experiência do usuário entraram em jogo para aprofundar o entendimento sobre as pessoas que iriam usar esses “serviços” viabilizados por meio de software. Diferentemente do software de prateleira, em que se vendia primeiro para se testar depois, agora, com a Web, tinha-se de testar e validar primeiro para conseguir vender depois.
A era da busca por produtos disruptivos, de consolidação das big techs (Google, Facebook, Amazon, Apple) e proliferação de um sem-fim de novos modelos de negócios inovadores teve seu “big bang” pouco antes dos 2010, com Steve Jobs apresentando ao mundo criações como o iPod, o iPad e o iPhone, este último, como conceito (smartphone), capaz de impulsionar muito do que viria a seguir. Abriam-se, então, as cortinas da década passada.
Buzz, colaboração e perguntas
A década dos 2011 a 2020 começou com o crescimento do buzz em torno da função de Product Manager, passou a consolidar algumas práticas do ofício — “gênios” parecem ter dado lugar a um perfil mais de colaboração com times e de facilitação com stakeholders — e, naturalmente, coloca perguntas para o futuro, principalmente em relação ao avanço da tecnologia e suas consequências.
Vamos começar com o buzz. Em 2010, a Mind The Product, uma das grandes comunidades de Gestão de Produtos mundiais, iniciou suas atividades como Product Tank, evento que ocorreu em Londres e depois se multiplicou em diversos países, inclusive no Brasil. Hoje, é uma das grandes comunidades da área no mundo.
Em 2013, foi fundado o Product Hunt, site em que é possível divulgar novos produtos e submetê-los a avaliações. Em 2014, surgiu a Product School, que fornece treinamentos para gestores de produto. Em 2016, veio ao mundo a Women in Product (Mulheres em Produto), na tendência por mais representação feminina no mundo dos negócios e da tecnologia.
As comunidades, a multiplicação de startups e o aumento do número de vagas para PMs nesse cenário aceleraram a disseminação de conhecimento sobre a função, as tentativas de uma maior sistematização desse conhecimento (por meio de técnicas, framework, cerimônias etc.) e, obviamente, deram origens a debates, discussões e polêmicas naturais.
A área ganhou mais evidência com PMs na ativa ou que haviam passado por empresas conceituadas que se tornaram influenciadores, por meio da escrita de artigos, gravações podcasts, participação em conferências ou vivo e online (principalmente na pandemia), além de cursos, mentoria e livros.
No âmbito das startups e empresas, viu-se tentativas de consolidar uma certa “hierarquia” da Gestão de Produtos, começando por Associate Product Managers (APMs) ou “PMs juniores”, passando por plenos, seniores, até chegar a gestores de PMs, como Heads, GPMs (Group Product Managers) e CPOs (Chief Product Managers).
A prática mostrou que a função é democrática, aceita pessoas de todas as formações e com as mais diversas experiências de vida, de botânicos a pessoas do Marketing tradicional, de geógrafos a quem não tem graduação, apenas aptidão para lidar com os desafios das startups.
Como diz Martin Eriksson, fundador do Product Tank, também em um artigo sobre a história da função, “The History and Evolution of Product Management” (“A História e Evolução da Gestão de Produtos”):
“[Product Management] está se tornando uma disciplina na qual você pode ser um engenheiro, um designer, um fundador ou um gerente de produto — mas tudo o que importa é que você esteja no centro do produto e trabalhe com paixão pela melhoria desse produto a serviço de seus clientes.”
A diversidade de experiências dos gestores de produtos e a lida com pessoas que a função demanda, de designers e desenvolvedores a pessoas de negócio e gestores da empresa, de clientes a usuários, fez o papel evoluir de profissionais centrados em “criar” soluções para profissionais mais colaborativos e facilitadores na descoberta de problemas e construção de soluções a eles.
A década viu arrefecer um certo status de “bola da vez” que PMs tinham para observar um ganho em diplomacia, humildade, muita conversa, negociação e paciência dos profissionais. Produto deixou de ser sobre tecnologia, botões na tela ou o que ocorria a cada clique para ser sobre resolver “dores” (também, “criar desejos”) de usuários.
Como emenda Eriksson, em relação à citação anterior:
“Isso pode [a diversidade em produto], com o tempo, exigir menos pessoas chamadas de gerentes de produto em uma empresa, mas coloca cada vez mais ênfase na importância da arte do gerenciamento de produto. E coloca cada vez mais ênfase em aprender, compartilhar e trabalhar com outras pessoas dentro e fora de nossas empresas no desenvolvimento desse ofício.”
Como a história continua?
A proliferação e consumo de produtos digitais para todo tipo de tarefa também viu surgirem efeitos colaterais, de técnicas nada éticas de fazer o usuário permanecer mais tempo em aplicativos e comprar mais até a polarização política — discussões em que comunidades de UX parecem estar mais envolvidas.
Tudo isso coloca mais perguntas do que respostas sobre para onde a Gestão de Produtos irá, se seguirá um caminho mais ou menos “linear” de consolidação como profissão ou se estará sujeita a solavancos que inovações desconhecidas trarão no futuro.
Algumas questões bastante amplas, para reflexão:
Com o fato de startups atuais crescerem, amadurecerem e se consolidarem como empresas, a Gestão de Produtos ainda cuidará tanto da exploração de problemas como do desenvolvimento das soluções ou haverá uma especialização maior de pessoas ou times inteiros nesses dois momentos (Marketing e Engenharia, digamos) da criação de produtos?
Gestores de produtos continuarão vistos como potencial “criativo” e “disruptivo”, de somar inovações ao negócio (Marketing), ou se tornarão mais “operários” na tradução de visão e objetivos de stakeholders aos times de desenvolvimento (Engenharia)?
Gestão de Produtos é uma área que pode ser teorizada e sistematizada, em busca de formas (“meios”) padronizadas de ser exercida, como se fosse conhecimento técnico transferível (Engenharia)? Ou sempre estará mais associada a talento individual, soft skills, feeling, capacidade crítica, experiência de vida, “arte de gerir” (Marketing), de modo que os “fins” (produtos e serviços de sucessos) justifiquem os “meios” (maneiras de descobrir e desenvolvê-los)?
A Gestão de Produtos tem responsabilidade (poderá ser responsabilizada) em relação a efeitos colaterais que serviços baseados em tecnologia poderão causar ou essa questão continuará muito mais sob alçada do Design? A área terá papel crítico em relação a isso ou, no trade-off, acabará sempre pesando mais para engajamento, retenção e aumento de receita em detrimento de uso e consumo saudável das soluções?
Avanços mais perceptíveis, como aprendizado de máquina, Internet das Coisas (IoT) e automação, e outros mais “etéreos”, como financeirização da vida, blockchain, tokens não fungíveis e descentralização econômica, podem representar ameaças à Gestão de Produtos como ofício ou na verdade representam oportunidades para que se consolide ainda mais?
Na esteira econômica, política e tecnológica, a Gestão de Produtos, como a conhecemos hoje, tende a se perpetuar pelo menos ao longo deste século ou, na busca incessante por formas mais eficientes de gestão, veremos ela perder suas características e se diluir ou se transmudar em outras práticas, talvez até com denominações diferentes?
Por fim, uma imagem que resume um pouco o conceito de “produto” ao longo do tempo, que talvez ajude a pensar nos próximos momentos dessa história.
Algumas referências
Artigo escrito por Rogério Kreidlow, jornalista, que gosta de observar a tecnologia em relação a temas amplos, como política, economia, história e filosofia.