Ciclo e Visão: Produto é mais que Feature

Comecei recentemente um MBA em Liderança e Estratégia para Produtos Digitais na Tera. E de partida já tem agregado muito.

Como desenvolvedor, passei anos focado em implementar features da melhor maneira possível, mas sempre tive curiosidade sobre como essas decisões eram tomadas. Quem define o que vale a pena construir? Como saber se estamos no caminho certo?

Neste post, quero compartilhar dois conceitos fundamentais que aprendi nas primeiras aulas: Ciclo de Vida de Produto e Visão de Produto.

Ciclo de Vida de Produto: Tudo tem seu tempo

Antes de mais nada: ciclo de vida de produto não é a mesma coisa que ciclo de desenvolvimento de software. Esse foi meu primeiro “Opa!”.

O ciclo de desenvolvimento (definir problema → planejar solução → desenvolver → entregar) acontece várias vezes ao longo do ciclo de vida de um produto, que segue quatro fases maiores:

1. Introdução / Early Stage
2. Crescimento / Growth
3. Maturidade
4. Declínio

O que não é metrificado não é gerenciado

Um dos insights mais valiosos que aprendi é que você sabe em qual fase do ciclo seu produto está através de métricas.

“tudo que é metrificado é gerenciável, tudo que não é, é ingerenciável."

Para acompanhar qualquer produto, precisamos de três tipos de métricas:

Métricas de Negócio

• MRR/ARR (Monthly/Annual Recurring Revenue): receita recorrente mensal/anual
• ARPU/ARPA: receita média por usuário/conta
• LTV/CLTV: valor do cliente ao longo do tempo (lifetime value)
• CAC: custo de aquisição de cliente
• CCR: taxa de conversão de cliente

Métricas de Cliente

• NPS: Net Promoter Score (quão dispostos estão a recomendar seu produto)
• Taxa de churn: quantos clientes estão abandonando o produto
• Funcionalidades mais/menos usadas: entender o que realmente importa
• Pontos de abandono: onde os usuários desistem
• Total de clientes por segmento e faixa de receita: quem são seus usuários mais valiosos

Métricas de Produto

• Número de tickets de suporte: indica problemas ou confusão
• SLA: cumprimento de acordos de nível de serviço
• Custos de suporte: hospedagem, onboarding, engenheiros, desenvolvimento customizado
• Distribuição de recursos de engenharia: quanto está indo para inovação, manutenção e dívida técnica (por valor e porcentagem)
• Variação de cronograma: como está o planejamento vs. realidade
• Bloqueadores-chave: o que está impedindo progresso

Essas métricas variam em importância conforme a fase do ciclo de vida. Vamos ver como:

Introdução: Busca pelo PMF

Nessa primeira fase, o produto está tentando encontrar seu Product Market Fit. Você tem poucas métricas e poucos usuários, e está basicamente tentando entender:

“Como resolver as dores dos usuários da melhor maneira possível?"

Métricas principais: No começo, não existem muitas métricas para avaliar. O foco principal é retenção - você quer ver as poucas pessoas usando muito o produto. Métricas quantitativas são limitadas, então o foco é qualitativo: entender como as pessoas interagem e qual benefício estão extraindo.

O que isso significa para devs: Esse é o momento de aprender mais do que construir. Cada feature deve ser um experimento, cada interação com usuário uma fonte de insights. Não é hora de escalar ou otimizar, é hora de descobrir o que realmente importa.

Crescimento: Expansão e Testes

Agora que você já tem alguma tração, o foco muda para entender o que traz mais usuários e como melhorar sua aquisição e retenção. A pergunta-chave é:

“Quais iniciativas podem alavancar o uso do produto através do topo do funil?"

Métricas principais: Aqui já dá para estabelecer causalidade, mas ainda é difícil relacionar o benefício do produto porque, como está em crescimento, não há como saber se esses usuários continuarão. A chave é entender por que as poucas pessoas que ficaram realmente permaneceram, e focar nisso. Com retenção comprovada, o foco passa a ser entender o que traz mais usuários.

O que isso significa para devs: É hora de pensar em monitoramento avançado. Seu código precisa permitir testes constantes (A/B testing), medições precisas e iterações rápidas. O desafio está em entender o que é correlação e o que é causalidade baseado nos comportamentos de uso.

Maturidade: Simplificação e Otimização

Quando seu produto atinge a maturidade, seus números estão relativamente estáveis. O desafio muda para entender vazamentos no funil e tentar simplificar a proposta de valor para mantê-la relevante.

“Como simplificar o produto para que a proposta de valor continue relevante no mercado?"

Métricas principais: Os principais números são estáveis agora. O foco é compreender vazamentos/furos em todo o funil: por que os usuários deixam de usar o produto? O desafio está em manter uma visão analítica profunda para priorização e constantemente gerar e testar hipóteses que melhorem a proposta de valor - geralmente através da simplificação.

O que isso significa para devs: Refatoração e melhoria de performance se tornam cruciais. É quando aquela dívida técnica começa a pesar, e você precisa simplificar sistemas que foram ficando complexos demais.

Declínio: Inovação ou Disrupção

Eventualmente, seu produto começa a perder relevância. As métricas caem consistentemente, e você precisa decidir se vai inovar ou deixar o produto morrer com dignidade.

“Como mitigar riscos em novas apostas?"

Métricas principais: Há uma queda constante nas principais métricas de uso e recorrência, com impacto consequente nas métricas de negócio. Provavelmente existe um grande buraco no funil que precisa ser entendido - o foco está em descobrir a causa do declínio de uso.

O que isso significa para devs: Pode ser hora de experimentar novas tecnologias ou abordagens radicalmente diferentes. É quando times precisam de inovação tecnológica para revitalizar produtos estagnados. O desafio está em descobrir o que tornou o produto irrelevante e identificar oportunidades-chave que possam reverter o panorama.

Atravessando o Abismo

Um conceito que me chamou a atenção foi o do “abismo” (chasm) entre os primeiros usuários e o público mainstream/geral. Muitos produtos conseguem atrair inovadores e early adopters, mas falham em atingir o grande público.

Para atravessar esse abismo:

1. Entenda o ciclo de adoção de tecnologia
2. Segmente seu mercado (construa produtos específicos)
3. Forneça um produto completo (não apenas alguns features legais)
4. Conheça sua competição e adeque sua proposta de valor

Isso me lembrou quantos projetos open source são hypados, mas nunca conseguem atingir as massas. Uma API elegante não é suficiente se a proposta de valor não estiver clara para o público mainstream.

Visão de Produto: A bússola do time

Outro conceito fundamental que aprendi foi sobre Visão de Produto. Não é um slogan, não é um roadmap, é algo muito mais profundo.

A visão de produto responde à pergunta: “Por que estamos criando esse produto?" É o futuro que o produto irá criar, mesmo que seja apenas um pouquinho.

Visão é viagem; cabeça nas nuvens, nas estrelas.

Visão é para se inspirar.

Por que a visão importa?

• Funciona como uma bússola para as decisões do time
• Inspira pessoas a criar produtos fantásticos
• Conecta o trabalho a um significado e impacto maior
• Orienta o uso de novas tecnologias e tendências

Para mim, essa foi uma revelação. Como dev, frequentemente me pergunto “por que estamos construindo isso?”. Ter uma visão clara evita esse tipo de frustração e mantém todos alinhados com um propósito maior. E nunca senti que isso foi me comunicado pela gerência.

Como estruturar uma visão de produto: O Product Vision Board

O “Product Vision Board” divide a visão em componentes essenciais. Um ponto importante: ao montar o board, seja generalista e mantenha-se no alto nível - use apenas 1-2 post-its por seção.

1. Grupo Alvo: O usuário é o foco da visão

Esta seção define para quem estamos construindo o produto:

• Que mercados ou segmentos este produto quer atingir?
  • Foque no mercado mainstream (não apenas early adopters, a menos que seja o objetivo)
  • Busque mercados economicamente relevantes (novamente, a menos que seu produto tenha outro propósito)
  • Seja generalista, mas bem definido
• Quem são os clientes/usuários alvo?
  • Defina claramente o perfil do usuário ideal

2. Necessidades: Como o produto resolve problemas reais

Aqui você define o valor que o produto entrega:

• Qual problema específico o produto resolve?
• Qual benefício ele provê? Qual a proposta de valor?
  • O que está facilitando na vida das pessoas?
  • Que mudança positiva ele traz?
• Se há vários grupos-alvo, preencha necessidades específicas para cada um

3. Objetivos de Negócio: Como gera valor para a empresa

Esta parte conecta o produto aos objetivos comerciais:

• Como o produto vai beneficiar a companhia?
• Quais são os objetivos de negócio?
  • Importante: esses objetivos devem vir da liderança de negócios da empresa
  • Converse com stakeholders para entender o que realmente importa para a organização

4. Produto: Tecnologia e experiência como ponte

Aqui descrevemos o produto em si:

• O que é o produto concretamente?
• O que faz este produto ser diferente dos outros?
  • É a experiência do usuário (UX)?
  • É o atendimento ao cliente?
  • É o suporte técnico?
• É possível criar esse produto com os recursos disponíveis?

5. Visão: O propósito maior

Esta é a síntese que conecta todos os elementos anteriores:

• Qual o propósito para criar esse produto?
• Que mudança positiva ele vai trazer para o mundo?
• Pode (e deve) ser inspiradora e grandiosa
  • A visão não precisa ser modesta - ela pode e deve ser ambiciosa

Muitos times de desenvolvimento trabalham sem uma visão clara, o que acaba criando produtos incoerentes e decisões questionáveis.

Aplicando esses conceitos na engenharia

Como essas ideias impactam nosso dia a dia como engenheiros de software? Algumas reflexões:

1. Meça o que importa

“O que não é metrificável é ingerenciável."

Em cada fase do ciclo de vida, diferentes métricas importam:

• Na introdução, foque em retenção e feedbacks qualitativos
• No crescimento, meça conversão e custo de aquisição de clientes
• Na maturidade, monitore vazamentos no funil e simplicidade de uso
• No declínio, acompanhe o impacto de novas apostas

Como devs, precisamos construir instrumentação que capture esses dados corretamente.

2. Construa para a fase atual

O código que você escreve para um produto em fase de introdução deve ser diferente do código para um produto maduro:

• Em produtos iniciais: priorize velocidade e flexibilidade
• Em produtos em crescimento: foque em testabilidade e instrumentação
• Em produtos maduros: otimize performance e manutenibilidade
• Em produtos em declínio: considere componentização para reuso em novos produtos

3. Conecte código à visão

Antes de implementar qualquer feature, pergunte:

• Como isso se alinha com a visão do produto?
• Qual problema do usuário isso resolve?
• Como saberemos se foi bem-sucedido?

Essas perguntas simples podem evitar meses de trabalho desperdiçado.

Quer aprender mais sobre esse tema? O livro “Atravessando o Abismo” (Crossing the Chasm) de Geoffrey A. Moore é uma leitura essencial para entender as diferentes fases de adoção de tecnologia.

E Simon Sinek tem um ótimo TEDx talk sobre a importância de começar pelo “por quê”.