O papel do Product Manager na integração de tecnologia e design para criar grandes produtos

Em Inspired: How to Create Tech Products Customers Love (traduzido literalmente para “Inspirado: como criar produtos de tecnologia que os clientes amam”, mas sem versão em português publicada), Marty Cagan, um dos principais líderes de produto da atualidade, discorre sobre o papel de Product Manager (PM) de produtos, serviços e experiências movidos a tecnologia.

Fazem parte desse grupo produtos de atendimento ao consumidor, como e-commerces ou marketplaces (Netflix, Airbnb ou Etsy), redes sociais (LinkedIn, Facebook ou Twitter), serviços empresariais (Salesforce, Clickup, Monday), dispositivos de consumo (Apple, JBL, Tesla) e aplicativos móveis (Instagram, Uber).

Produtos movidos a tecnologia não precisam ser puramente digitais. Muitos dos melhores exemplos atuais são a mistura de experiências online e offline — como chamar um motorista por aplicativo, reservar um quarto de hotel ou encomendar um delivery. O autor acredita que a maioria dos produtos, hoje em dia, está se transformando em produtos movidos a tecnologia, e as empresas que não percebem isso estão ficando para trás. É preciso que as companhias abracem a tecnologia e inovem constantemente pelo bem de seus clientes.

Como tudo começou

Cagan relata que, nos anos 1980 trabalhava como engenheiro de software na Hewlett-Packard Company, uma prestigiosa empresa de tecnologia da informação multinacional americana que, após sua divisão, em 2015, deu lugar à HP.

A equipe de Cagan recebeu a desafiadora tarefa de desenvolver um produto robusto, que consistia em uma estação de trabalho habilitadora de Inteligência Artificial (IA), e que custaria cerca de U$100.000 por usuário. O time trabalhou no produto por aproximadamente um ano, fazendo o necessário para atingir os padrões de qualidade da HP, traduzindo-o para uma diversidade de idiomas — a fim de torná-lo internacional —, treinando a equipe de vendas e fazendo testes de lançamento com a imprensa, recebendo ótimas avaliações. Assim, o produto foi lançado. Entretanto, não houve nenhuma venda.

Ocorre que o produto foi um verdadeiro fracasso no mercado. Embora fosse tecnicamente impressionante e tivesse recebido ótimas avaliações, não era algo que as pessoas quisessem ou precisassem. Isso levou a equipe de engenheiros às seguintes perguntas:

• Quem decide que produtos devemos construir?
• Como isso será decidido?
• Como saberão que o que construiremos será útil?

Assim, Cagan entendeu que as decisões sobre o que construir vieram de um Product Manager: alguém que geralmente trabalhava no marketing e que era responsável por definir os produtos que a equipe de engenheiros (ou programadores, aqui tratados como sinônimos) desenvolveria. No entanto, o autor descobriu também que a HP não era particularmente boa em gestão de produto e que, na verdade, a maioria das empresas da época também não eram (e ainda não são). Ao trabalhar em outras grandes companhias ao longo do tempo, Cagan percebeu que há uma grande diferença entre como as melhores empresas produzem produtos e como a maioria das empresas produz.

Afinal, o que faz um Product Manager (PM)?

Para Marty Cagan, por trás de todo grande produto há uma pessoa que liderou a equipe de produto para combinar tecnologia e design, a fim de resolver problemas reais dos clientes de uma forma que vá ao encontro das necessidades do negócio. Esse é o escopo do PM.

É importante comentar que nem sempre essa função está formalizada na empresa. Muitas vezes, é desempenhada pelo co-fundador ou CEO de uma startup, ou simplesmente por alguém que possui outro papel na equipe, mas que percebeu a necessidade de assumir esse escopo também.

De qualquer forma, a verdade é que o PM precisa estar entre os melhores talentos da empresa. Se o PM não tiver a sofisticação para tecnologia, a habilidade para negócios, a credibilidade junto aos principais executivos, o profundo conhecimento sobre o cliente, a paixão pelo produto e o respeito do time de produto, isso significa uma receita para o fracasso. Sobretudo, o PM precisa possuir senso de responsabilidade: quando um produto tem sucesso, é porque todos do time fizeram o que precisava ser feito. Mas quando um produto é um fracasso, é culpa do PM.

Há quatro responsabilidades-chave para um PM:

• Conhecimento profundo sobre o cliente: saber suas questões, dores, desejos, como pensa, como funciona seu processo de decisão de compra. Isso subsidia muitas decisões que o PM precisa tomar todos os dias.
• Conhecimento profundo sobre os dados: hoje, é esperado dos PMs que se sintam à vontade ao lidar com dados e análises. É preciso que tenham habilidades tanto quantitativas como qualitativas. Mesmo que você tenha um analista de dados para te ajudar, a análise desses dados e o entendimento dessa análise não é algo que possa ser delegado.
• Conhecimento profundo sobre o negócio: produtos de sucesso não são apenas amados por seus clientes, mas também adequados ao seu negócio. Isso significa saber quem são as várias partes envolvidas na empresa e entender as limitações sob as quais operam. Esses stakeholders normalmente são as áreas de gerência geral, vendas, marketing, financeiro, jurídico, desenvolvimento de produtos e atendimento ao cliente. Ter sucesso em um produto é convencer cada stakeholder de que você entende suas limitações e está comprometido a oferecer apenas soluções que você acredita estarem de acordo com essas limitações.
• Profundo conhecimento do seu mercado e indústria: esse conhecimento inclui não apenas saber sobre a concorrência, mas também as tendências-chave em tecnologia, comportamento do consumidor e suas expectativas, entender o papel das mídias sociais para seu mercado e seus consumidores e assim por diante. Em se tratando de tecnologia, o que é possível está sempre mudando. Se você não se entusiasma em aprender sobre essas novas tecnologias e como seu time de produto pode utilizar essas tendências para entregar produtos e experiências substancialmente melhores para seus clientes, talvez essa não seja a carreira certa para você.

Boas práticas dos melhores times de produto

Um time de produto é um grupo de pessoas que reúne diferentes habilidades especializadas e responsabilidades, e possui verdadeiro “senso de dono” do produto ou, ao menos, de uma parte substancial de um grande produto.

Em um time de produto, todos são contribuidores individuais. Ninguém é líder de ninguém, a estrutura é horizontal e os participantes normalmente seguem respondendo a seus gestores funcionais. Por fim, é válido ressaltar que o PM não é gestor de ninguém do time de produto.

Há três práticas que são características aos melhores times de produto:

1. Riscos são enfrentados antecipadamente e não no final: riscos são enfrentados antes mesmo de se decidir construir o produto. São eles: risco de valor (se os clientes irão comprar ou utilizar), de usabilidade (se os usuários saberão utilizar o produto), de exequibilidade (se o time poderá construir com o tempo, habilidade e tecnologia disponíveis na empresa) e de viabilidade (se essa solução também é adequada para os vários aspectos do negócio em geral: vendas, marketing, financeiro, jurídico etc.).
2. Produtos são definidos e projetados colaborativamente e não sequencialmente: foi superado o modelo em que o PM define requisitos, o designer projeta a solução que entrega esses requisitos e o engenheiro implementa esses requisitos, com cada ator do processo tendo de lidar com as restrições e decisões que o responsável anterior criou. Em bons times, produto, design e engenharia/desenvolvimento trabalham lado a lado, em uma relação de via de mão dupla, para criar produtos que os clientes amam e que atendem as necessidades do negócio.
3. É tudo sobre resolver problemas, não implementar funcionalidade: bons times sabem que implementar uma funcionalidade ou criar um produto, simplesmente, não são a resposta; eles precisam garantir que essa solução resolva um problema. É sobre resultado de negócios.

Product discovery e product delivery: um modelo de alto nível

Como já comentado, o PM é responsável por avaliar oportunidades e determinar o que deve ser desenvolvido e entregue aos clientes. E nós normalmente descrevemos o que precisa ser desenvolvido como backlog do produto.

No entanto, uma das maiores dificuldades enfrentadas é ter certeza de que vale a pena construir o que foi colocado no backlog do produto. E atualmente, nos melhores times, os engenheiros e designers querem ver evidências de que o que o Product Manager está pedindo para ser desenvolvido realmente é válido.

Além disso, metade de nossas ideias dará errado. A verdade é que, muitas vezes, o mais comum é que os clientes não fiquem tão entusiasmados com uma ideia como a empresa ficou. E, assim, apenas não a utilizam. Ou, ainda, às vezes tentam utilizar, mas o produto é tão complexo que simplesmente não vale o esforço. É possível dizer que, pelo menos, metade das ideias no seu roadmap não vai funcionar.

Uma coisa, no entanto, é certa: uma das maiores formas de desperdício é projetar, construir, testar e implantar uma funcionalidade ou produto apenas para descobrir que isso não era necessário. E, enquanto estamos desperdiçando tempo e dinheiro, a maior perda acaba sendo o custo de oportunidade do que a empresa deveria estar fazendo no lugar disso; não há como recuperar esse tempo e dinheiro. É preciso abandonar o modelo de cascata, em que uma atividade é feita somente quando a anterior terminou, investindo muito tempo e dinheiro para descobrir apenas no final que não irá funcionar.

Um modelo de alto nível é aquele em que descobrimos o produto que precisa ser construído e entregamos aquele produto ao mercado.

A descoberta de produto (product discovery) consiste em um trabalho colaborativo entre as equipes de PM, design de UX e tecnologia, mapeando todos os riscos antes de iniciar qualquer desenvolvimento de produto. O objetivo é rapidamente separar as ideias boas das ruins. O resultado da descoberta de produto é um backlog validado de produto. Isso significa obter respostas para quatro perguntas críticas:

1. O usuário vai comprar isso (ou escolher usar)?
2. O usuário consegue identificar como usar isso?
3. Nossos programadores são capazes de desenvolver isso?
4. Nossos stakeholders podem apoiar isso?

Aqui, chamamos de uma boa ideia algo que resolva o problema principal, de uma forma que os clientes irão querer comprar, que eles serão capazes de descobrir como utilizar, que a empresa terá o tempo, habilidade e tecnologia necessários para construir e que funcionará para os vários aspectos do negócio. E não é suficiente ter apenas a opinião do PM guiando essas respostas. É preciso ter evidências.

A depender do caso, há mais ou menos riscos envolvidos no desenvolvimento de um produto. Assim, é possível escolher técnicas de testagem baseada em cada situação:

• Teste de exequibilidade;
• Teste de usabilidade;
• Teste de valor;
• Teste de viabilidade.

A etapa de descoberta serve para aplicar os testes nas situações em que entendemos haver maior risco ou nas situações em que os membros do time discordam.

O maior desafio dessa etapa é mostrar valor para o cliente. Embora todas as tarefas sejam complexas, o mais difícil é criar o valor necessário para que os clientes escolham comprar ou usar o produto. Podemos sobreviver por um tempo com problemas de usabilidade ou performance, mas sem o valor central do produto, não temos nada. Como resultado, essa etapa é geralmente onde precisamos investir a maior parte do tempo de descoberta.

Uma das maiores armadilhas em produto é acreditar que podemos antecipar a resposta de nossos clientes para nossos produtos. Talvez estejamos nos baseando em pesquisas sobre o cliente ou em nossas próprias experiências, mas de qualquer forma, atualmente sabemos que devemos validar nossas ideias junto a usuários ou clientes reais. Precisamos fazer isso antes de investir tempo e orçamento no desenvolvimento de um produto, e não antes.

É preciso, inicialmente, descobrir em detalhes o que a solução para o cliente precisa ser. É necessário se certificar de que há uma quantidade de clientes suficiente que precisa dessa solução e, então, encontrar uma alternativa que funcione tanto para o público como para o negócio. É necessário encontrar uma única solução que funcione para muitos clientes, e não lançar uma série de personalizações. Para isso, precisamos testar muitas ideias, e fazer isso de forma rápida e com baixo custo.

Ainda, o objetivo do discovery é garantir alguma evidência de que, quando pedimos à equipe técnica para desenvolver um produto de qualidade, não será um esforço desperdiçado.

A entrega de produto (product delivery) é o resultado da etapa de descoberta, em que, após todos os testes e protótipos realizados, é possível ter evidências de que vale a pena desenvolver o produto que, posteriormente, será entregue ao cliente. Isso significa que a escala, performance, confiabilidade, tolerância ao erro, segurança, privacidade, internacionalização e localização performaram conforme necessário e o produto funciona como anunciado.

Contudo, em se tratando de entrega de produto, é importante ressaltar que embora o conceito de MVP (Minimum Viable Product), ou Mínimo Produto Viável, tenha a letra “P” para representar “produto”, o MVP nunca deve ser um produto de verdade (se entendermos produto por algo que o time técnico pode lançar com confiança, que os seus clientes possam utilizar em seus negócios ou que você possa vender e prestar suporte). O MVP deveria ser um protótipo, não um produto.

Por fim, só porque investimos dinheiro e esforço na criação de um produto, não significa que alguém vai querer comprá-lo. É por isso que nos esforçamos para alcançar a adequação produto/mercado.

A importância do design em produto

Muitas empresas têm percebido a importância do design para produtos, no entanto, ainda lidam com esse tema de forma incorreta. Normalmente, contratam talentos e organizam a operação como uma agência interna: o demandante faz suas solicitações para este grupo de designers e, quando o trabalho é finalizado, eles entregam os resultados. Precisamos sim, de design — não apenas como um serviço para tornar nossos produtos bonitos — mas para fazer a descoberta certa de produto.

Em bons times de produto, o design orienta a funcionalidade tanto quanto a funcionalidade orienta o design. Para isso acontecer, o designer precisa ser um membro-chave do time de produto, sentado lado a lado com o PM, e não apenas um serviço de apoio.

Embora a qualidade técnica do produto seja muito importante, proporcionar uma boa experiência para o usuário é ainda mais difícil e mais determinante para o sucesso do produto. Enquanto todo time de produto possui desenvolvedores, nem todo time possui, necessariamente, habilidades de design.

Por fim, é importante comentar que o designer, no time de produto, é responsável pela experiência do usuário (UX), que é algo muito maior do que somente o design de interface (UI). Inclusive, o termo Customer Experience, ou Experiência do Cliente (CX), é utilizado por muitas empresas para enfatizar essa diferença. UX é qualquer forma pela qual os clientes e usuários finais percebem o valor fornecido pelo seu produto. Isso inclui todos os pontos de contato e interações que um cliente tem com sua empresa e produto ao longo do tempo.

Quer saber mais sobre como o design pode ser usado como uma estratégia para agregar valor? Acesse aqui o nosso material completo sobre esse tema.

ACESSE AGORA

Desafios na Construção do Roadmap de Produto

Roadmap de produto é uma lista priorizada de funcionalidades e projetos nos quais seu time foi convocado a trabalhar. Esses roadmaps normalmente são feitos trimestralmente, mas às vezes consideram quadrimestres, e algumas empresas fazem roadmaps anuais. Muitas vezes, os roadmaps vêm como orientação da gerência; outras vezes, são elaborados pelo PM. O ponto é que, em geral, eles contêm todas as melhorias e novas funcionalidades previstas, bem como a previsão de entrega.

No entanto, roadmaps costumam ser a causa da maior parte do desperdício e esforços falhos em empresas de produto.

O ponto é que a empresa geralmente enxerga o roadmap como um compromisso. Quando, na verdade, a maioria das ideias que temos simplesmente não funciona; sendo assim, nem sempre é possível cumprir o roadmap. E, ainda que as ideias propostas se provem viáveis, muitas vezes é necessária uma série de iterações para executar a ideia a ponto de entregar o valor esperado pela gerência. Não há problema em construir uma lista de ideias, entretanto, é preciso conscientizar as partes envolvidas de que o roadmap não deve ser visto como um compromisso, visto que não há sentido em construir um produto ou funcionalidade que posteriormente identificou-se desnecessário por não resolver o problema que inicialmente demandou sua produção.

No entanto, para substituir roadmap, é necessário propor algo pelo menos tão bom quanto para traduzir as necessidades do negócio. É preciso, então, traduzir o contexto do negócio para os envolvidos. Isso pode ser feito definindo e compartilhando a visão e estratégia do produto, ou seja, onde a empresa quer chegar com essa solução. Ou, ainda, é possível compartilhar com o time o objetivo do negócio: informar ao time o que o produto precisa, como os resultados serão mensurados e deixar os envolvidos encontrarem a melhor forma de resolver o problema. É tudo uma questão de resultado, não de produção.

O problema em firmar compromissos de entrega é quando esses compromissos são feitos. Eles são feitos cedo demais, antes de o time saber se realmente pode entregar o esperado e, mais importante, se essa entrega resolverá o problema do cliente. É por isso que, no modelo de descoberta e entrega contínua, o objetivo da descoberta é justamente responder a todas essas questões antes de investir o dinheiro e tempo necessários para a construção de um produto de qualidade.

Há alguns times de produto que modificaram seus roadmaps de forma que cada item é um problema de negócio a resolver, ao invés de uma funcionalidade ou projeto que talvez, ou talvez não, resolva esse problema. Esses são os chamados roadmaps baseados em resultados. É um sistema semelhante aos sistemas baseados em objetivos de negócios, como os sistemas de OKRs.

Cagan comenta que, ao trabalhar na HP, foi introduzido a um sistema baseado em objetivos de negócios, conhecido como MBO (managed by objectives, ou gerenciado por objetivos). Esse sistema foi refinado e melhorado em muitas empresas através dos anos e, atualmente, o mais utilizado deles é o sistema OKR (objectives and key results, ou objetivos e resultados-chave).

Em termos de produto, o sistema OKR funciona com base em duas premissas fundamentais:

1. Nunca diga às pessoas como fazer coisas. Diga a elas o que fazer e elas vão lhe surpreender.
2. A performance é medida por resultados: você pode lançar os produtos e funcionalidades que desejar, mas se não resolverem o principal problema enfrentado, na verdade, nada foi solucionado.

Assim, a transição para o sistema OKR representa uma evolução significativa na gestão de produtos, enfatizando a autonomia e a entrega de resultados tangíveis. Ao seguir a filosofia de não dizer como, mas sim o que fazer, e ao medir a performance exclusivamente pelos resultados obtidos, o OKR se estabelece como uma abordagem que impulsiona a inovação centrada na solução dos problemas essenciais, proporcionando um caminho mais eficaz para o sucesso no desenvolvimento de produtos.

Conclusão

Na gestão de produto, o PM emerge como um arquiteto estratégico, navegando entre as demandas dos clientes, as necessidades do negócio e a sinergia entre tecnologia e design.

A narrativa de Marty Cagan revela que o sucesso de um produto não apenas depende da sua qualidade técnica, mas também da capacidade de proporcionar uma experiência significativa para o usuário. As práticas destacadas, como a antecipação de riscos, a colaboração entre produto, design e engenharia e a ênfase na resolução de problemas, delineiam o caminho para equipes de produto eficientes. Além disso, a abordagem de product discovery e delivery, baseada em validação contínua, destaca a importância de evidências e adaptação constante no ciclo de vida do produto.

Em última análise, a mensagem ressoa: o PM não apenas lidera, mas também inspira a criação de produtos que não apenas atendem às expectativas, mas superam as necessidades e desejos dos usuários, garantindo a relevância e competitividade no dinâmico cenário do desenvolvimento de produtos movidos a tecnologia.

Quer receber um serviço de consultoria em design para o seu negócio? Clique aqui e conheça a Unio, nossa plataforma de consultorias onde você pode solicitar um orçamento e contratar o serviço desejado

CONHEÇA A UNIO