Já conversei com muitos Product Managers na vida e percebi que poucos conseguem definir quais indicadores eles devem acompanhar e principalmente como esses indicadores se conectam diretamente com o negócio. É uma dúvida legítima mas que na minha opinião é uma dúvida sintoma. Por que de tanto responder essa dúvida de maneiras diferentes, eu notei outro padrão: poucos conseguiam definir o produto que trabalhavam.
Então, sempre que pedia para a pessoa definir o que é o produto que ela cuida, a resposta vinha turva. Alguns confundiam o produto com a feature, outros com uma jornada...
- "É a plataforma de pagamento."
- "É o checkout."
- "É a jornada de compra."
- "São as ferramentas que a gente entrega para o vendedor."
- "É o app."
- "São os módulos do sistema."
As duas primeiras respostas eu ouvi dentrp de uma mesma empresa. Eles cuidam do mesmo produto. Só que cada um descreve uma camada diferente, e nenhum dos dois consegue ancorar essa descrição em algo maior.
Na minha visão, isso não é detalhe semântico. É a raiz de quase todos os problemas que esses times relatam depois: roadmap virou lista de features sem critério, ninguém sabe explicar para o board o que o produto move, e os indicadores que o time acompanha não conversam com os indicadores de negócio.
Separar produto de feature, de solução e de jornada importa mais do que parece. E a partir dessa separação, é possível encontrar indicadores de produto que conversem com o negócio.
Por que essa confusão é tão comum
Antes de cair em cima dos PMs, quero dizer que entendo a confusão. Ela tem uma razão real.
O tamanho do que se chama de "produto" varia muito. Uma feature numa empresa grande pode ser o produto inteiro de uma startup. O checkout do Mercado Livre é uma camada interna do produto Mercado Livre. Mas a Pagar.me, em outro contexto, vende exatamente checkout como o seu produto. Então a mesma coisa, dependendo do ângulo, vira uma feature dentro de um produto maior, ou um produto independente.
Essa fluidez é real. Não é erro de quem define. Mas ela vira problema quando há confusão quando não se tem claramente domínios e limites entre times ou até mesmo como cada coisa se chama. E aí o time inteiro fica em loop discutindo se "isso é uma feature do produto X" ou "é o produto Y novo" ou pior: isso é meu e aquilo é seu?
Na minha experiência, esse loop só termina quando alguém senta e desenha a cadeia de cima até embaixo. Da empresa até a feature. Não importa quem, ok? Pode ser o Diretor de Produto, o PM ou até mesmo a galera de Marketing, que precisa disso para saber exatamente como vender.
E essa cadeia é o ponto do artigo.
A hierarquia que você precisa enxergar
Eu uso uma cadeia de sete camadas para destravar essa discussão com times. Ela vai do problema mais primário do negócio até a menor funcionalidade que o time entrega. Cada camada tem um nome, uma função, e responde uma pergunta diferente.
A cadeia, na ordem:
- Problema primário — qual problema essa empresa nasceu para resolver? Geralmente é a proposta de valor mais essencial, a razão de existir do negócio.
- Segmento de clientes e parceiros chave — quem é afetado por esse problema, e quem vai pagar para que ele seja resolvido.
- Dores, desejos e objetivos — o que esse segmento sente quando tenta resolver o problema sozinho hoje.
- Oferta — qual o grande aspecto, narrativa, discurso que a empresa traz para o mercado para amenizar essa dor.
- Solução — como a oferta é entregue: por software? por serviço? por uma combinação dos dois? A solução é o pacote, o tema, o momento, o grande assunto que precisa ser resolvido para a oferta acontecer.
- Produto — o pedaço concreto de software (ou de serviço) que materializa parte de uma solução. Vários produtos podem compor uma mesma solução. Ou um produto é a solução completa.
- Feature — a menor unidade do produto, executada pelo time, que entrega uma capacidade específica dentro de uma jornada do usuário.
Veja bem: o produto é a camada 6. Não é o ponto de partida (que é o problema) e não é o ponto de chegada (que é a feature). Produto é uma camada intermediária. Na minha visão, essa separação existe desde antes de frameworks modernos de PM formalizarem isso.
Esse desenho (e dezenas de outros) estão no meu Miro, que só que me assinante do Segundo Cérebro tem acesso. Se você se interessar, veja aqui.
Pensando no Spotify para deixar concreto. Para simplificar, podemos dizer que o problema primário do Spotify é "ouvir música em qualquer lugar" e "divulgar e monetizar música". Tem dois segmentos: ouvinte e artista (mais a gravadora, como parceiro chave - e que na verdade pode ser considerado como outro cliente, mas não quero complicar).
- A dor do ouvinte é encontrar música e ter acesso.
- A oferta para o ouvinte é disponibilizar música de vários artistas em um único lugar.
- A solução é uma plataforma de streaming.
- O produto, dentro dessa solução, pode ser quebrado em "Descoberta e Seleção", "Player de Música", "Assinatura de Acesso".
- E cada um desses produtos tem features: search, playlists, categorização, recomendação.
Outro exemplo, com Mercado Livre.
- Mercado Livre atua no mercado de varejo e comércio.
- O segmento macro é B2B.
- O sub-segmento que importa aqui são lojistas profissionais.
- A jornada que esses lojistas precisam executar é venda.
- A solução que Mercado Livre oferece para essa jornada é uma loja personalizada.
- E o produto que materializa essa solução tem features de busca e seleção: filtro, ordenação, categorização, recomendação.
Esse desenho (e dezenas de outros) estão no meu Miro, que só que me assinante do Segundo Cérebro tem acesso. Se você se interessar, veja aqui.
Na minha visão, o exercício de quebrar dessa forma resolve metade dos problemas de definição que vejo nos times. O time consegue dizer com clareza onde o produto que ele cuida começa e onde termina.
Solução, produto e feature: a fronteira que importa
A parte mais escorregadia dessa cadeia é a fronteira entre solução, produto e feature. É aqui que mora a maior parte da confusão.
Vamos por partes.
Solução é o tema, o momento, o grande assunto que precisa ser resolvido para a oferta da empresa funcionar. "Plataforma de streaming" é uma solução. "Loja personalizada para lojistas profissionais" é uma solução. Solução não é um software pronto. Ela é o caminho que a empresa decidiu tomar para amenizar a dor do segmento.
Produto é o pedaço de software (ou de serviço) que materializa parte de uma solução. O produto é o que o time constrói, mantém e evolui. Uma solução pode ser composta por vários produtos: a plataforma de streaming do Spotify é composta pelo produto de descoberta, pelo produto de player, pelo produto de assinatura, pelo produto de dados para o artista. Cada um tem seu PM, seu roadmap, seus indicadores.
Feature é a menor unidade do produto. É a funcionalidade específica que o cliente interage. Search é uma feature do produto de descoberta. Filtro é uma feature da listagem.
O Tim Herbig, num curso que fiz com ele, definiu de uma forma boa: "feature é a tarefa, ou a solução que você está criando com o time, de acordo com o segmento e o campo de jogo que a empresa e o produto escolheram atuar".
Ele separa estratégia da empresa, estratégia do produto, e estratégia da feature como três camadas distintas, e isso bate exatamente com o que estou descrevendo aqui.
Mas o próprio Tim reconhece que entre product strategy e feature strategy existe um gap. A pergunta que fiz pra ele no curso foi essa: "não precisamos de algo no meio que justifique a feature? Tipo uma oportunidade ou um problema?". A resposta dele foi que esse gap se preenche com discovery.
Eu concordo, mas só em parte.
Na minha visão, antes do discovery preencher esse gap, o produto já preencheu metade dele. O produto é o que conecta o tema da solução com a tarefa do time. Sem essa camada explícita, discovery vira generalismo: você descobre coisas para o quê?
Outra forma de enxergar: o Marty Cagan, fala sobre a diferença entre feature team e product team. O feature team é medido pelo que entrega. O product team é medido pelo problema que resolve. Não é só uma diferença de mindset. Para o time virar product team, ele precisa saber qual o produto que cuida, separado das features. Senão, mesmo com discurso de outcome, o time vai continuar medindo o que entrega.
Onde fica a jornada nessa cadeia
Tem mais uma camada que confunde quase todo PM: a jornada.
Já ouvi várias versões. "O nosso produto é a jornada de venda." "O nosso produto é a jornada do comprador." "Olha o nosso story map, esse é o produto." Não é.
Jornada é como o cliente atravessa um momento dentro da solução. É a sequência de passos que o usuário executa para resolver alguma coisa. O story map mapeia jornada. O fluxo no Figma mapeia jornada. Tudo isso é representação do uso, não do produto.
Por que essa confusão acontece? Porque jornada é fácil de visualizar. Você desenha o story map e tem ali, na parede, uma narrativa concreta: o usuário entra, busca, escolhe, finaliza. Produto, por outro lado, é mais abstrato. Você precisa nomear a fatia de software que está construindo, e essa fatia não tem desenho fácil de mostrar. O produto é formado por jornadas, faz sentido? Uma feature é uma jornada? Ou uma jornada tem várias features? Discute com a sua mente aí.
Mas usar story map como definição de produto é confundir "como o usuário usa" com "o que estamos construindo". O usuário usa a jornada através do produto. O produto é o que existe; a jornada é o que acontece quando alguém interage com ele.
Concretamente: o ouvinte do Spotify tem uma jornada de descoberta de música — ele abre o app, vê uma playlist sugerida, escuta, salva. Essa é uma jornada. Mas o produto que viabiliza essa jornada é a combinação do player com o motor de recomendação com a busca. Três produtos, uma jornada.
E ainda assim, essa é só uma das jornadas de descoberta de música. Ele pode usar a busca. Ele pode receber um compartilhamento de amigo. Ele pode receber uma newsletter.
Por isso que confundir os dois quebra a discussão de roadmap. Quando o PM diz "vou priorizar a jornada de descoberta", ele não está priorizando produto. Está priorizando uma sequência. E aí ele acaba mexendo em três times diferentes para mover uma jornada que ele não consegue medir, porque não há nenhum produto dono daquela jornada inteira (bom, depende de como os times estão estruturados e organizados... outro papo).
O que se perde por não fazer essa separação
Tudo o que falei até aqui pode parecer discussão de definição. Não é. Pelo menos três coisas concretas pioram quando o time não tem essa cadeia clara.
Primeira: o roadmap pode virar lista de features sem critério. Sem produto definido, o PM não tem limite claro para decidir o que entra e o que não entra. Funciona? Sim, pode até funcionar. Mas cabe espaço para discussão entre domínios de times. Corre o risco de roadmap virar mural de demandas, e o time vira fábrica de feature. Essa é exatamente a definição de feature factory que o Cagan ataca.
Segunda: o time não sabe responder de forma clara o que está construindo hoje e como isso vai ser evoluído amanhã. Já participei de várias rodadas de status com C-Levels onde a pergunta "o que esse time faz e quais os próximos passos dessa evolução?" recebia uma lista de features como resposta. "A gente tá entregando o filtro novo, o relatório de vendas e a integração com o sistema X." Isso não é resposta sobre produto. É resposta sobre output.
Terceira, e a mais cara: os indicadores vão para o lugar errado. Sem produto definido, o PM acaba medindo features (taxa de uso da feature nova, adoção de funcionalidade) ou jornadas (taxa de conversão do funil). Não me leve a mal: essas coisas precisam que ser medidas... mas elas são métricas, que formam indicadores. Muito difícil uma métrica de produto conectar com indicadores de negócio. Indicador conecta com Indicador. Métrica fica dentro do indicador. Conversão de funil é meio, não é fim. Adoção de feature é leading indicator, não é resultado.
Quando o PM tem clareza do que é o produto que cuida, ele consegue derivar três níveis de indicadores: indicador de feature, indicador de produto e indicador de negócio. Cada um responde uma pergunta diferente. Os três precisam estar conectados, mas não são a mesma coisa. Confundir os três é o equivalente, na operação, de confundir feature com produto na estratégia. É a mesma confusão, só que descendo a cadeia.
O exercício que vale a pena fazer agora
A minha dica para você seria: antes da próxima reunião de roadmap, desenha essa cadeia para o seu produto. Pega uma folha de papel, ou um Miro, e quebra:
- Qual o problema primário da empresa onde você trabalha?
- Quais segmentos a empresa atende?
- Qual a oferta da empresa para esses segmentos?
- Qual a solução que materializa essa oferta?
- Quais produtos compõem essa solução? (Aqui você descobre quantos produtos a sua área tem de verdade.)
- Quais features compõem o seu produto?
- Quais jornadas atravessam esse produto?
Você vai descobrir, sinceramente, que metade do que o seu time chama de produto é na verdade feature. E que a outra metade é jornada. E vai descobrir, também, que o produto que você cuida é menor do que parece, mas está conectado a uma cadeia muito maior do que o seu time consegue ver.
Essa é a primeira limpeza. No próximo artigo, mostro como ela vira base para indicadores. Mas antes disso: qual camada da sua empresa ainda não tem nome?
References and further reading
- Product vs Feature Teams — Marty Cagan, SVPG — distinção entre time medido por output e time medido por outcome, e por que isso depende de saber qual produto o time cuida.
- Product Vision vs. Product Strategy — Tim Herbig — separação das três camadas de estratégia (company, product, feature) que serve de base para a cadeia descrita aqui.
- A estratégia de produto — Diego Eis (Gestão Tática e Estratégica de Produtos Digitais) — capítulo do livro que aprofunda a derivação da estratégia de produto a partir da estratégia da empresa.
- What is product management — Lenny Rachitsky — definição operacional do papel do PM como entrega de impacto de negócio através do time, base que reforça a leitura de produto como meio.