10.14 Gestão de produto e descoberta

Visão geral e motivação

A gestão de produto é a disciplina de decidir o que construir e por quê, e de responder por se funciona. Um gerente de produto é dono do problema, do cliente e do resultado. Não é dono do cronograma, da fila de chamados nem da lista de funcionalidades entregue por uma parte interessada. Essa distinção é o capítulo inteiro numa frase. Quando a gestão de produto colapsa em coordenação de projetos ou em tomada de pedidos, uma equipe vira uma fábrica de funcionalidades: entrega sem parar, atinge os números de velocidade e não move nenhuma métrica de negócio. O papel existe para evitar exatamente isso.

Para grandes equipes, a gestão de produto fraca é, em silêncio, o modo de falha mais caro que existe. A engenharia pode ser soberba, a entrega pode ser rápida e toda a máquina ainda assim pode gastar um ano construindo a coisa errada com grande eficiência. O custo nunca aparece num painel de engenharia. Aparece como receita estagnada, clientes que saem e um backlog de funcionalidades que ninguém usa mas que todos agora precisam manter. A boa gestão de produto torna esse risco visível antes de vocês comprometerem o dinheiro, insistindo que as metas sejam explícitas, mensuráveis e ligadas a um problema real do cliente.

Os contextos corporativo e governamental elevam as apostas e mudam a forma do trabalho. As empresas estão cada vez mais passando de um modelo operacional de projeto (financiar um projeto, entregá-lo, desfazer a equipe) para um modelo operacional de produto (financiar equipes duráveis que são donas de resultados por anos) e tratando as plataformas internas como produtos com clientes de verdade. Os governos estão aprendendo a mesma lição sob a bandeira do projeto centrado no usuário: financiar serviços, não projetos, e medir se os cidadãos estão de fato sendo servidos. Este capítulo trata da mentalidade e da mecânica que tornam real essa mudança. Combina de perto com o capítulo 11.1 (o pipeline de descoberta), que detalha a maquinaria do pipeline; aqui nos concentramos no papel, na estratégia e nos hábitos diários da descoberta.

Princípios fundamentais

Sejam donos do quê e do porquê. Os gerentes de produto respondem por resultados, não por coordenar tarefas.
Resultados em vez de produções. Entregar é um custo, não um resultado. O resultado é uma mudança no cliente ou numa métrica de negócio.
Conheçam o cliente e o problema melhor que qualquer um. Estratégia sem contato com o cliente é palpite.
A descoberta é contínua, não uma fase. Vocês conversam com clientes toda semana, em paralelo à entrega.
Os frameworks de priorização são auxílios ao julgamento, não oráculos. Os números informam a decisão. Não a tomam.
Os roteiros são declarações de intenção, não promessas datadas. Comprometam-se firmemente com problemas e frouxamente com soluções.
Empoderem o trio. Produto, design e engenharia decidem juntos. Um gerente de produto sozinho decide mal.

Recomendações

Seja dono do quê e do porquê e deixe a equipe ser dona do como

O teste mais claro de que a gestão de produto está saudável é quem é dono de qual pergunta. O gerente de produto é dono de que problema estamos resolvendo e de por que isso importa agora. O design é dono de como deve ser a sensação para o usuário. A engenharia é dona de como construímos. Quando um gerente de produto começa a ditar soluções, prazos e implementação, ele virou um gerente de projetos usando um título de produto e tirou a própria autonomia que torna eficaz uma equipe empoderada (o capítulo 5.1 cobre a parceria com o design, o capítulo 10.7 cobre o modelo de entrega ágil).

Uma equipe de produto empoderada, às vezes chamada de trio de produto, trabalha como produto, design e engenharia juntos, recebendo um problema a resolver e não uma funcionalidade a construir. Essa é a diferença entre “aumentar a retenção em 30 dias de novos usuários” e “construir a central de notificações até março”. A primeira empodera a equipe a achar a melhor solução e a cobra por um resultado. A segunda a reduz a um braço de entrega e transfere em silêncio o risco de errar para a pessoa que escreveu o requisito. Se vocês querem responsabilização por resultados, precisam abrir mão do controle das produções.

Defina uma visão e uma estratégia de produto fundamentadas no cliente

Uma estratégia de produto é um pequeno conjunto de escolhas difíceis sobre quais clientes vocês servem, quais problemas resolvem para eles e, de igual importância, quais recusam. A visão é o quadro durável do mundo que vocês tentam criar, em geral de dois a cinco anos adiante. A estratégia é a sequência de movimentos que leva até lá. Sem ambas, a priorização degenera em quem discute mais alto, e o roteiro vira uma lista das funcionalidades de estimação de todos grampeadas juntas.

A estratégia é impossível sem conhecimento profundo e de primeira mão do cliente e do problema. Um gerente de produto que não consegue descrever, em detalhe específico, quem é o cliente, que tarefa ele tenta realizar e onde hoje tem dificuldade, não está pronto para priorizar nada. Isso não é uma pesquisa que se encomenda uma vez. É um hábito permanente de contato. Os melhores líderes de produto conseguem relatar de memória a conversa com o cliente da semana passada, não o slide de pesquisa do trimestre passado. Quando vocês conhecem o problema de cor, a maioria das discussões de priorização se dissolve, porque a equipe consegue raciocinar a partir de evidências e não de opinião.

Gerencie por resultados e escape da fábrica de funcionalidades

A fábrica de funcionalidades é o que vocês obtêm quando o sucesso é definido como “entregamos”. As equipes medem a velocidade, contam lançamentos e celebram estreias enquanto as métricas que pagam as contas ficam paradas. O antídoto é definir o sucesso como um resultado (uma mudança no comportamento do cliente ou do negócio) e atrelar uma medida a ele antes de construir. É aqui que a gestão de produto encontra os objetivos e resultados-chave (capítulo 11.4): os objetivos descrevem a mudança que vocês querem, os resultados-chave a medem, e um resultado-chave formulado como “lançar a funcionalidade X” é uma tarefa disfarçada.

Fiquem atentos aos sinais. Se o seu roteiro é uma lista de funcionalidades sem resultado declarado, se ninguém sabe dizer que métrica uma funcionalidade entregue moveu, se a retrospectiva nunca pergunta “funcionou?” e só “entregamos?”, vocês estão numa fábrica de funcionalidades. Escapar dela é sobretudo uma questão de disciplina: recusem aceitar trabalho formulado como solução até alguém declarar o problema e a medida. A análise de produto e os experimentos controlados (capítulo 7.4) dão o painel de instrumentos para distinguir um resultado real de uma história confortável.

Rode a descoberta contínua ao lado da entrega

A descoberta contínua de produto significa que, toda semana, em paralelo à entrega, a equipe está aprendendo com os clientes e testando as suposições por trás do que planeja construir. O modelo é de trilha dupla: uma trilha de descoberta reduz o risco das ideias enquanto uma trilha de entrega constrói as validadas, e as duas rodam continuamente e não como fases sequenciais (o capítulo 11.1 detalha o pipeline). O compromisso prático por trás é pequeno e implacável: converse com clientes toda semana, mesmo quando estiver ocupado, especialmente quando estiver ocupado.

Uma espinha dorsal útil para isso é a árvore de oportunidades e soluções: vocês partem de um resultado desejado, ramificam nas oportunidades do cliente (necessidades, dores, desejos) que poderiam movê-lo, ramificam de novo em soluções candidatas para cada oportunidade e depois nos testes de suposição que diriam se uma solução funciona. A árvore mantém a equipe honesta sobre por que uma dada funcionalidade está na mesa e força a comparar oportunidades em vez de se apaixonar pela primeira solução. Antes de comprometer a engenharia, vocês testam a suposição mais arriscada com o experimento mais barato: uma entrevista, um protótipo, um teste de porta falsa, um teste A/B. A saída da descoberta não é uma lista de funcionalidades. É um fluxo de apostas validadas e mensuráveis prontas para a entrega.

Use os frameworks de priorização como auxílios ao julgamento, não como oráculos

Os frameworks de priorização trazem estrutura útil a uma decisão bagunçada, e todos estão errados se vocês tratam o seu número como verdade. O RICE pontua cada ideia por Alcance (Reach; quantos usuários), Impacto, Confiança e Esforço e depois ordena por (Alcance x Impacto x Confiança) / Esforço. A pontuação ponderada avalia as opções contra vários critérios ponderados. O custo do atraso pergunta o que cada semana de espera custa, o que costuma ser a lente mais afiada para sequenciar. O modelo de Kano classifica as funcionalidades em expectativas básicas, necessidades de desempenho e encantadores, lembrando que nem toda satisfação é linear.

Usem-nos para expor as suas suposições e tornar os compromissos discutíveis, não para abdicar da decisão. O termo Confiança no RICE e as estimativas na pontuação ponderada são julgamentos vestidos de aritmética, e uma falsa precisão pode lavar uma aposta ruim numa lista ordenada que parece objetiva. Rodem os números e depois perguntem se a ordem combina com a sua estratégia e com o seu conhecimento do cliente. Se não combina, confiem no julgamento e interroguem as entradas. O framework é um auxílio ao pensamento; vocês ainda são quem precisa acertar.

Trate os roteiros como declarações de intenção

Um roteiro datado que promete funcionalidades específicas em trimestres específicos é uma ficção que todos assinam e ninguém consegue cumprir, porque fixa justamente o que (a solução) a descoberta deveria continuar aprendendo. Prefiram um roteiro agora / em seguida / depois: no que estamos trabalhando agora, o que provavelmente vem em seguida e o que estamos considerando para depois, expressos como problemas e resultados e não como funcionalidades comprometidas com datas. Isso comunica a direção com honestidade enquanto preserva a liberdade de mudar a solução conforme a evidência chega.

O movimento subjacente é se comprometer firmemente com problemas e resultados e frouxamente com soluções. As partes interessadas que exigem compromissos de funcionalidades com data certa costumam estar pedindo previsibilidade, o que é razoável; deem-na no nível dos resultados e dos prazos (“reduziremos de modo significativo a desistência na integração neste semestre”) e não no nível de funcionalidades específicas que vocês ainda não validaram. Quando precisarem dar uma data rígida, liguem-na a um resultado valioso e deixem o escopo da solução flexionar, exatamente como o capítulo 10.6 recomenda para a entrega de projetos.

Valide a desejabilidade, a viabilidade, a exequibilidade e a usabilidade

Antes de comprometer investimento real, uma ideia de produto precisa vencer quatro riscos. Desejabilidade: os clientes de fato a querem? Viabilidade: funciona para o negócio (jurídico, financeiro, marca, vendas)? Exequibilidade: a engenharia consegue construí-la com o tempo e a tecnologia disponíveis? Usabilidade: as pessoas conseguem de fato usá-la? O trio foi montado para cobrir isso: o produto lidera a viabilidade, o design a usabilidade, a engenharia a exequibilidade, e a desejabilidade é problema de todos. Pulem um e ele volta como um lançamento que os clientes ignoram, que o jurídico bloqueia, que a engenharia não consegue entregar ou que os usuários não entendem.

Esse também é o enquadramento para as decisões de construir, comprar ou fazer parceria. Se uma capacidade é central para a sua diferenciação, construam. Se é necessária mas sem diferenciação (cobrança, autenticação, envio de e-mails), favoreçam com força comprar ou fazer parceria, porque cada funcionalidade que vocês constroem carrega uma cauda perpétua de manutenção, superfície de segurança e carga cognitiva. Um produto mínimo viável (MVP) é a coisa mais barata que testa a sua suposição mais arriscada, não uma versão 1.0 reduzida que vocês entregam e esquecem; mantenham-no honesto perguntando o que vocês aprenderão e não apenas o que lançarão.

Conheça o ajuste produto-mercado e invista em operações de produto

O ajuste produto-mercado (product-market fit) é o momento em que um produto satisfaz uma forte demanda de mercado, e vocês costumam senti-lo antes de conseguir prová-lo: as curvas de retenção se achatam em vez de decair a zero, o uso cresce de boca em boca, os clientes ficariam genuinamente chateados de perder o produto e vocês lutam para acompanhar a demanda em vez de criá-la. Antes do ajuste, o seu trabalho é achá-lo, e quase nada mais importa. Depois do ajuste, o seu trabalho muda para escalar e defendê-lo. Confundir as duas fases (escalar antes de ter o ajuste, ou ainda procurar depois de tê-lo) é um erro clássico e caro.

À medida que o número de equipes de produto cresce, invistam em operações de produto: a pesquisa, os dados, as ferramentas e as práticas compartilhadas que permitem a muitas equipes fazer bem a descoberta sem cada uma reinventá-la. As operações de produto mantêm dotada de pessoal a cadência de entrevistas com clientes, confiáveis as análises, consistente o formato do roteiro e rodando o ritmo de OKRs. Numa empresa que passa a um modelo operacional de produto, e numa organização de plataforma como produto em que as plataformas internas têm clientes internos reais, as operações de produto é o que mantém o modelo coerente entre dezenas de equipes em vez de deixá-lo fragmentar em hábitos locais.

Compromissos: prós e contras

Abordagem	Prós	Contras
Equipe de produto empoderada (resultados)	É dona de resultados. Acha soluções melhores. Motivada	Exige talento sênior e confiança real. Mais difícil dirigir de cima para baixo
Modelo de equipe de funcionalidades / tomada de pedidos	Produção previsível. Fácil de gerir e de contratar	Entrega as coisas erradas com eficiência. Ninguém é dono do resultado
Descoberta contínua	Reduz o risco das apostas toda semana. Aprendizado rápido. Menos desperdício	Exige capacidade de pesquisa e disciplina. Mais difícil de agendar
Requisitos pesados de antemão	Confortáveis para os financiadores. Escopo claro	Suposições não testadas. Retorno tardio. Risco de tudo de uma vez
Roteiro agora/em seguida/depois	Honesto sobre a incerteza. Preserva o aprendizado	Frustra as partes interessadas que querem compromissos de funcionalidades com data
Roteiro datado de funcionalidades	Parece previsível. Fácil de comunicar	Promete o que vocês não podem saber. Recompensa produção sobre resultado
Priorização por pontuação de framework	Estruturada, discutível, reduz a política	Falsa precisão. Pode lavar uma aposta ruim como objetiva

A tensão central é compromisso versus aprendizado. Orçamentos, contratos e executivos querem compromissos firmes, o que puxa para roteiros datados de funcionalidades e requisitos de antemão. Bons produtos precisam de espaço para descobrir, o que puxa para resultados e experimentos contínuos. Resolvam do mesmo modo ao longo de todo este guia: comprometam-se firmemente com problemas, resultados e prazos e segurem soluções específicas com frouxidão. Isso dá à liderança a previsibilidade de que ela de fato precisa (progresso mensurável nas coisas que importam) sem forçar a equipe a prometer funcionalidades que ainda não validou.

Perguntas para discutir com sua equipe

O seu gerente de produto é dono de um resultado ou de um backlog? Esta é a pergunta mais reveladora sobre como a sua equipe realmente opera. Se o gerente de produto é medido por entregar o roteiro, perseguir pedidos de partes interessadas e manter o sprint cheio, vocês têm um coordenador de projetos com um título de produto, e ninguém é de fato responsável por se o trabalho move uma métrica. Levem evidências: olhem as três últimas entregas do seu gerente de produto e perguntem que resultado de cliente ou de negócio cada uma devia mudar e se alguém conferiu. Numa grande organização as apostas se compõem, porque uma única equipe apontada para produções pode queimar vários trimestres construindo funcionalidades que vão bem em demonstrações e não mudam nada em produção. A resposta deve remodelar tanto aquilo por que vocês medem o gerente de produto quanto quanto controle sobre soluções vocês estão dispostos a dar à equipe. Se ninguém é dono de um resultado, consertem isso antes de discutir o roteiro.
Quando alguém desta equipe conversou com um cliente pela última vez, e foi esta semana? A descoberta contínua vive ou morre desse hábito, e é a primeira coisa cortada quando a pressão de entrega sobe, que é precisamente quando vocês mais precisam dela. As equipes que param de conversar com clientes não percebem que ficaram cegas; simplesmente começam a raciocinar a partir de opinião interna e pesquisa velha, ficando mais confiantes e menos corretas. Levem o registro real: contem quantas das suas últimas dez funcionalidades passaram por uma suposição documentada e um teste barato antes de construir, versus da boca de uma parte interessada direto para o backlog. Para equipes corporativas e governamentais, em que uma única iniciativa desalinhada pode desperdiçar muitos equipes-trimestre e, no setor público, a confiança pública real, nomeiem quem é responsável por manter vivo o contato semanal com o cliente. Se a resposta honesta é “não esta semana” ou “não tenho certeza”, vocês estão voando sobre suposições e chamando de estratégia.
O que seria preciso para passar de um modelo operacional de projeto para um modelo operacional de produto, e o que está impedindo? Muitas empresas ainda financiam projetos temporários, dotam-nos de pessoal, entregam e desfazem a equipe, o que destrói a propriedade durável e o conhecimento do cliente de que o bom trabalho de produto depende. Passar para equipes duráveis que são donas de resultados por anos, inclusive tratando as plataformas internas como produtos com clientes de verdade, é uma mudança de financiamento, de desenho organizacional e de governança, não apenas de títulos de cargo. Levem evidências: rastreiem como uma iniciativa atual é financiada e dotada de pessoal e perguntem o que acontece com o aprendizado acumulado quando o projeto termina e a equipe se dispersa. A consideração contrária é real, porque o orçamento anual por projeto e as regras de contratação existem por razões legítimas de responsabilização, e vocês precisam satisfazê-las, não ignorá-las. A resposta deve identificar o menor passo concreto (uma equipe persistente dona de um resultado com orçamento estável) que prova o modelo antes de tentar converter todo o portfólio (capítulo 10.1).
Quando rodamos um framework de priorização, ele está informando a decisão ou apenas ratificando uma já tomada? O RICE, a pontuação ponderada e o custo do atraso são úteis precisamente porque forçam as suposições a aparecer, e se tornam corrosivos no instante em que um número vira desculpa para parar de pensar. A consideração contrária é real: os frameworks reduzem a política e dão um rastro defensável em papel, de que as grandes organizações genuinamente precisam, mas os termos Confiança e Impacto são julgamento vestido de aritmética e podem lavar uma aposta ruim numa ordem de aparência objetiva. Levem as suas últimas decisões de priorização e conferiram duas coisas: se alguém alguma vez sobrescreveu a pontuação quando a estratégia ou o conhecimento do cliente discordavam e se a preferência da pessoa mais bem paga definiu em silêncio as entradas que produziram a ordem. Em contextos corporativos e governamentais, em que um backlog pontuado costuma virar o artefato mostrado a comitês diretivos e auditores, nomeiem quem pode sobrescrever o número e com que fundamento, porque um framework que ninguém pode contrariar deixou de ser um auxílio ao pensamento e virou carimbo.
O que prometemos às partes interessadas como funcionalidades com data, e conseguiríamos reformular esses compromissos como resultados sem perder a confiança delas? Os roteiros datados de funcionalidades parecem previsibilidade e costumam ser ficção, porque fixam a solução que a descoberta deveria continuar aprendendo, e numa grande organização cada promessa dessas se propaga para equipes dependentes, planos de marketing e expectativas executivas. A tensão é legítima: os financiadores e as partes interessadas querem certeza por razões de orçamento e de responsabilização, então vocês não podem simplesmente recusar-se a comprometer; precisam dar previsibilidade no nível dos resultados e dos prazos e não de funcionalidades não validadas. Levem o roteiro atual e marquem cada item como um resultado com que vocês podem se comprometer ou uma solução específica sobre a qual estão chutando e depois esbocem como reformulariam os chutes como problemas de agora/em seguida/depois. Para equipes corporativas e do setor público presas a orçamentos anuais e marcos de contratação, identifiquem quais compromissos são genuinamente contratuais versus meramente habituais, porque os habituais são onde vocês podem trocar falsa precisão por direção honesta, e os contratuais são onde vocês precisam negociar o compromisso com um resultado e não com uma funcionalidade.
Onde estamos construindo capacidade sem diferenciação que poderíamos comprar ou obter por parceria, e quem decide? Cada funcionalidade que vocês constroem carrega uma cauda perpétua de manutenção, superfície de segurança e carga de suporte, então montar à mão cobrança, autenticação ou envio de e-mails gasta a sua capacidade mais escassa em trabalho que não diferencia vocês (capítulo 10.4). A consideração contrária é que “comprar” troca controle e ajuste por velocidade e menor custo de propriedade, e às vezes uma capacidade que vocês presumiam commodity é na verdade central para a sua vantagem, então a lente de desejabilidade, viabilidade, exequibilidade e usabilidade precisa ser aplicada com honestidade e não como cobertura para uma preferência. Levem um inventário do que as suas equipes estão construindo hoje internamente, marquem cada item como diferenciador central ou encanamento sem diferenciação e estimem o custo contínuo de propriedade do encanamento contra uma alternativa de fornecedor. Em contextos corporativos e governamentais, incorporem as regras de contratação, os requisitos de residência de dados e de segurança e os termos de aprisionamento e de saída, porque a decisão de construir, comprar ou fazer parceria ali não é apenas um compromisso de engenharia, mas de conformidade e de responsabilização, e quem for dono dela deve conseguir defender a escolha perante um auditor.

Perspectiva por setor

Startup. Com pouco fôlego, a descoberta é sobrevivência, não processo. Um fundador usa o chapéu de produto, conversa com clientes toda semana sem cerimônia e roda os testes mais baratos possíveis (um botão de porta falsa, cinco entrevistas) antes de comprometer qualquer engenheiro com uma construção. Pulem frameworks pesados e roteiros datados; a empresa inteira consegue guardar a estratégia na cabeça, então gastem a disciplina em recusar construir o pedido barulhento até alguém declarar o problema e a métrica.

Pequena empresa. Vocês não têm gerente de produto dedicado, então o pensamento de produto é um hábito que o dono ou um engenheiro líder carrega ao lado de outras tarefas. Enquadrem a maioria das decisões de construir ou comprar rumo a comprar: capacidade sem diferenciação, como agendamento, pagamentos ou e-mail, pertence a um fornecedor, e a sua atenção escassa vai para a uma ou duas coisas que de fato conquistam clientes. Mantenham uma lista leve de agora/em seguida/depois em vez de um roteiro formal e tratem uma única métrica antecedente (compras repetidas, ausências) como o seu resultado em vez de um aparato completo de OKRs.

Grande empresa. O trabalho é coordenar muitas equipes de produto sem deixar o modelo fragmentar: trios duráveis donos de resultados, um formato consistente de roteiro e operações de produto mantendo coerentes entre dezenas de equipes a cadência de entrevistas, a análise e o ritmo de OKRs. A governança e a auditoria querem rastreabilidade, então tornem legíveis os resultados, a justificativa de priorização e as decisões de encerramento em vez de reverter a promessas datadas de funcionalidades que satisfazem um comitê mas recompensam a produção sobre o impacto. Gerenciem a passagem do financiamento por projeto para um modelo operacional de produto deliberadamente, porque o desenho organizacional e o orçamento mudam mais devagar que os títulos de cargo.

Governo. A contratação, a transparência e a prestação de contas públicas moldam toda escolha. Financiem equipes de serviço duráveis em vez de projetos de escopo fixo, definam o sucesso como um resultado do cidadão (tempo até solicitar, conclusão por autoatendimento) que os órgãos de supervisão possam verificar e tratem o projeto centrado no usuário e os padrões de acessibilidade como exigências rígidas testadas com solicitantes reais, incluindo usuários de tecnologia assistiva. Publiquem resultados e progresso com clareza para que o escrutínio veja valor público e estruturem as decisões de construir ou comprar e os contratos de fornecedores em torno de portabilidade de dados e saída, para que uma escolha de fornecedor hoje não vire uma década de aprisionamento.

Exemplos

Startup. Uma startup de seis pessoas que constrói uma ferramenta de agendamento para clínicas independentes resiste à tentação de construir a grande funcionalidade de “agendamento online” que três clientes barulhentos não param de pedir. O fundador e gerente de produto roda em vez disso uma semana de descoberta: cinco entrevistas com donos de clínicas, um botão de porta falsa no site de marketing e uma métrica antecedente (a porcentagem de consultas que terminam em ausência). A evidência diz que as ausências, não o agendamento, são a dor real, então a equipe enquadra um único resultado (cortar as ausências abaixo de 10% nas clínicas-piloto neste trimestre), entrega um pequeno MVP de depósito e lembrete para testar a suposição mais arriscada e mata a funcionalidade de agendamento antes de escrever uma linha dela. O roteiro é uma lista de agora/em seguida/depois, não um plano datado, e a equipe inteira consegue relatar de memória a ligação com o cliente da semana passada.

Grande empresa. Um banco de varejo passa seu grupo de pagamentos de um modelo de projeto para um modelo de produto: um trio durável (produto, design, engenharia) é dono de “os pagamentos do dia a dia parecem instantâneos” como resultado permanente, com um orçamento anual estável, em vez de uma série de projetos autorizados. A equipe roda entrevistas semanais com clientes e mantém uma árvore de oportunidades e soluções, usa o RICE para sequenciar soluções candidatas mas sobrescreve a ordem quando a análise de custo do atraso mostra que uma correção de latência importa mais e publica um roteiro de agora/em seguida/depois para as partes interessadas em vez de promessas datadas de funcionalidades. Duas funcionalidades propostas morrem na descoberta por falhar em mover os indicadores antecedentes, poupando uma estimativa de dois trimestres de esforço de construção, e as operações de produto mantêm a cadência de entrevistas e a análise confiáveis entre as quinze equipes de produto do banco.

Governo. Uma agência nacional que moderniza os pedidos de benefícios adota a mentalidade de produto do setor público defendida pelas equipes de serviço digital: financia uma equipe de serviço durável, não um projeto de escopo fixo, e define o sucesso como um resultado do cidadão (cortar o tempo mediano até solicitar de 40 para 15 minutos e elevar a conclusão bem-sucedida por autoatendimento de 55% para 85%) em vez de módulos entregues. O projeto centrado no usuário é inegociável: a equipe roda testes moderados de usabilidade com solicitantes reais, incluindo usuários de tecnologia assistiva, antes de cada lançamento e trata os padrões de acessibilidade como exigências rígidas. Como o roteiro é enquadrado como resultados e a equipe é dona do serviço por anos, os órgãos de supervisão veem valor público mensurável em vez de um relatório de gastos, e a agência pode entregar capacidade útil cedo em vez de apostar tudo num único go-live distante (capítulos 11.1, 5.1).

Justificativa de negócio: motivações, ROI e TCO

O retorno de uma gestão de produto real é dominado pelo desperdício evitado. Os programas de experimentos controlados em grandes empresas de tecnologia repetidamente acham que uma grande parcela das funcionalidades construídas, muitas vezes citada em torno de metade, não produz melhoria mensurável ou prejudica ativamente a métrica-alvo. Se até um quarto da capacidade de uma equipe vai para ideias que a descoberta contínua teria matado barato, a disciplina se paga muitas vezes: uma semana de entrevistas com clientes e um teste de porta falsa custam quase nada diante de um trimestre de engenharia, mais a manutenção perpétua de uma funcionalidade que ninguém usa. O custo principal de uma fábrica de funcionalidades não são as funcionalidades que ela entrega. É o custo de oportunidade dos resultados que nunca moveu.

No custo total de propriedade, cada funcionalidade entregue é um passivo permanente: manutenção, testes, superfície de segurança, carga de suporte e peso cognitivo para todos que precisam navegar o produto (capítulo 10.4). A gestão de produto baixa esse custo de dois modos. Mata as ideias ruins na descoberta, evitando não apenas a construção mas toda a cauda de propriedade. E conduz as decisões de construir, comprar ou fazer parceria rumo a comprar capacidade sem diferenciação, de modo que a capacidade finita da sua equipe vá para o que de fato diferencia vocês. A passagem de um modelo operacional de projeto para um de produto acrescenta um retorno adicional, mais sutil: as equipes duráveis retêm o conhecimento do cliente e o contexto da base de código que as equipes de projeto jogam fora toda vez que se desfazem e se refazem.

Para defender o caso junto à liderança, mudem a conversa de “quanto estamos entregando” para “quanto estamos movendo as métricas que importam” e mostrem dois ou três exemplos concretos de funcionalidades caras que não moveram nada. O custo de adoção é modesto: capacidade de pesquisa, uma cadência de descoberta, um roteiro baseado em resultados e a disciplina de definir o sucesso antes de construir. O risco de não investir é silencioso, não contado e se compõe, porque uma fábrica de funcionalidades parece produtiva até vocês notarem que o negócio não se moveu.

Antipadrões e armadilhas

A fábrica de funcionalidades: o sucesso definido como “entregamos”, com a velocidade celebrada enquanto as métricas de negócio ficam paradas.
Gerente de produto como gerente de projetos: ser dono do cronograma e da fila de chamados em vez do problema e do resultado.
Gerente de produto como secretário de funcionalidades: transcrever pedidos de partes interessadas num backlog sem problema nem medida atrelados.
Roteiro como promessa datada de funcionalidades: comprometer-se com soluções específicas em trimestres específicos que vocês ainda não conseguem validar.
Descoberta como fase pontual: um sprint de descoberta no início e depois meses de construção sem mais contato com o cliente.
Priorização guiada por HiPPO: a opinião da pessoa mais bem paga se sobrepõe à evidência, e os frameworks viram teatro para ratificá-la.
Culto ao framework: tratar uma pontuação RICE ou ponderada como verdade, deixando a falsa precisão lavar uma aposta ruim.
Construir infraestrutura sem diferenciação: montar à mão cobrança ou autenticação que um fornecedor entregaria melhor e mais barato.
Escalar antes do ajuste produto-mercado: derramar dinheiro em crescimento num produto que o mercado ainda não deseja com força.
Plataforma interna sem dono de produto: uma equipe de plataforma construindo o que acha interessante e não o que seus clientes internos precisam.

Modelo de maturidade

Nível 1, Iniciar: A gestão de produto é tomada de pedidos e reativa. Um roteiro datado de funcionalidades é entregue de cima, e o sucesso é entregá-lo. Sem resultados declarados, sem contato regular com o cliente e sem ninguém responsável por se o trabalho moveu uma métrica.
Nível 2, Desenvolver: Aparecem práticas básicas de produto, mas inconsistentes entre as equipes. Existem resultados e OKRs para algumas equipes, mas as metas costumam ter forma de produção e os roteiros ainda são listas de funcionalidades. A descoberta acontece ocasionalmente, em geral como fase inicial, e a priorização usa um framework, às vezes como cobertura para a voz mais alta.
Nível 3, Padronizar: Trios empoderados são donos de resultados, e a prática é documentada e esperada em toda a organização. Os roteiros são declarações de intenção de agora/em seguida/depois. A descoberta contínua é um hábito semanal com pessoal, com testes de suposição documentados. Os frameworks de priorização informam o julgamento em vez de substituí-lo. E o ajuste produto-mercado é compreendido e acompanhado como padrão compartilhado e não como hábito local.
Nível 4, Gerenciar: A prática é medida e controlada em relação a linhas de base. Cada equipe acompanha métricas de resultado antecedentes e posteriores contra uma linha de base declarada, e após o lançamento toda funcionalidade é conferida contra uma métrica de sucesso pré-registrada, com um limiar de encerramento imposto com base em evidências e não em opinião. A saúde da descoberta também é instrumentada (cadência de entrevistas cumprida, suposições testadas antes de construir, ideias mortas na descoberta versus entregues), os sinais de ajuste produto-mercado, como curvas de retenção e pontuações de “ficaria desapontado”, são quantificados e as entradas do framework, como a Confiança do RICE, são calibradas contra como as apostas de fato resultaram.
Nível 5, Orquestrar: Um modelo operacional de produto roda por todo o portfólio e é continuamente melhorado e integrado ao financiamento e à estratégia. As equipes duráveis são donas de resultados por anos e as plataformas internas são geridas como produtos. A descoberta e a entrega se retroalimentam continuamente. Os dados de resultados conduzem o investimento e reequilibram o portfólio de modo adaptativo. As operações de produto mantêm a prática coerente em escala. E a liderança gerencia um portfólio de resultados, rotineiramente aposentando, redefinindo o escopo e repriorizando apostas conforme a evidência e o mercado mudam.

Ideias para discussão

Olhem o seu roteiro atual: quantos itens declaram um resultado mensurável versus apenas uma funcionalidade e uma data?
Quem na sua equipe é dono da relação com o cliente a ponto de relatar de memória a conversa da semana passada?
Quais das suas funcionalidades recentes vocês teriam matado se tivessem rodado primeiro um experimento barato sobre a suposição mais arriscada?
Onde vocês estão construindo capacidade sem diferenciação que poderiam comprar ou obter por parceria, e quanto isso custa?
Vocês têm ajuste produto-mercado, e como saberiam de fato, em vez de presumir?
Qual é o menor passo que vocês poderiam dar rumo a um modelo operacional de produto, e que obstáculo de governança está no caminho?

Principais conclusões

A gestão de produto é dona do quê e do porquê e responde por resultados, não por coordenar tarefas nem transcrever pedidos.
Escapem da fábrica de funcionalidades definindo o sucesso como uma mudança medida no comportamento do cliente ou do negócio antes de construir.
Rodem a descoberta contínua ao lado da entrega: conversem com clientes toda semana e testem a suposição mais arriscada com o experimento mais barato (capítulo 11.1).
Usem os frameworks de priorização (RICE, pontuação ponderada, custo do atraso, Kano) como auxílios ao julgamento, nunca como oráculos.
Tratem os roteiros como declarações de intenção (agora/em seguida/depois): comprometam-se firmemente com problemas e resultados, frouxamente com soluções.
Empoderem o trio e validem desejabilidade, viabilidade, exequibilidade e usabilidade antes de investir (capítulo 5.1).
Em contextos corporativos e governamentais, passem de um modelo operacional de projeto para um modelo operacional de produto, financiem serviços e não projetos e invistam em operações de produto (capítulos 10.1, 11.4).

Referências e leitura complementar

Marty Cagan, Inspired and Empowered (empowered product teams, the product operating model).
Marty Cagan and Chris Jones, Transformed (moving to a product operating model).
Teresa Torres, Continuous Discovery Habits (opportunity-solution trees, weekly customer contact).
Melissa Perri, Escaping the Build Trap (outcomes over outputs, product operations).
Roman Pichler, Strategise (product vision, strategy, and roadmaps).
C. Todd Lombardo, Bruce McCarthy, Evan Ryan, and Michael Connors, Product Roadmaps Relaunched (now/next/later roadmaps).
Dan Olsen, The Lean Product Playbook (product-market fit).
Eric Ries, The Lean Startup (minimum viable product, build-measure-learn).
Noriaki Kano et al., “Attractive Quality and Must-Be Quality” (Journal of the Japanese Society for Quality Control, 1984): origin of the Kano model.
Melissa Perri and Denise Tilles, Product Operations (scaling product practice).
U.S. Digital Service, Digital Services Playbook; UK Government Digital Service, Government Design Principles and Service Standard (public-sector, user-centred product delivery).