Frameworks de descoberta e validação que evitam funcionalidades mortas

São 16h47 de uma quinta-feira. O CRO larga uma mensagem no Slack: "Um logo grande acabou de dar churn. Eles queriam roteamento de aprovação customizado. Precisamos disso no roadmap do Q3." No sync de liderança da sexta, "roteamento de aprovação customizado" é uma entrega comprometida para o Q3. Dois engenheiros são puxados. Seis meses depois ela é entregue, 9% das contas a tocam nos primeiros 60 dias, e ninguém consegue explicar que problema ela de fato resolveu.

Eu já entreguei essa funcionalidade. Duas vezes. Uma vez numa ferramenta de workflow, uma vez num CRM. Nas duas vezes, o diagnóstico foi o mesmo. Pulamos a descoberta porque alguém com um cargo transformou um único ponto de dados numa estratégia. O trimestre de engenharia não foi o custo. O custo foram as três oportunidades que não exploramos porque o time estava ocupado construindo a funcionalidade de estimação do cliente mais barulhento.

Se você é um PM que continua entregando coisas que ninguém adota, este guia é a stack de descoberta que eu queria que alguém tivesse me passado três anos atrás.

Por que entregar a primeira ideia falha

Os benchmarks de produto da Pendo têm sido deprimentemente consistentes por uma década. 60% a 70% das funcionalidades em produtos B2B SaaS têm menos de 15% de adoção nos primeiros seis meses. Alguns estudos colocam a taxa de funcionalidades mortas ainda mais alta. Isso não é um bug de nenhum time específico; é a taxa base de construir antes de validar.

Vamos chamar isso pelo que é. Adoção abaixo de 15% após 60 dias = funcionalidade morta. Não "precisa de mais enablement". Não "o movimento de GTM está errado". Morta. A coorte que precisava dela não a puxou, a coorte que não precisava dela a ignorou, e agora você tem área de superfície para manter para sempre.

Um trimestre morto não são 12 semanas de tempo de engenharia. São 12 semanas de tempo de engenharia, mais tempo de PM, mais tempo de design, mais QA, mais a dívida técnica que você vai carregar por anos, mais o custo de oportunidade das outras três apostas que você não fez. Um squad de quatro engenheiros entregando uma funcionalidade morta queima cerca de US$ 400 mil de custo totalmente carregado. Você não tem muitos desses antes de alguém do financeiro começar a fazer perguntas pontiagudas no QBR.

A correção não é "fazer mais pesquisa". É uma prática de descoberta que roda toda semana, não como um sprint.

A árvore de oportunidades e soluções (Teresa Torres)

A árvore de oportunidades e soluções de Teresa Torres é o único artefato que mais fez pelo meu senso de produto. A estrutura é brutalmente simples:

                Outcome
                   |
         +---------+---------+
         |         |         |
    Opportunity Opportunity Opportunity
         |         |         |
      +--+--+   +--+--+   +--+--+
      |     |   |     |   |     |
    Sol   Sol Sol   Sol Sol   Sol
      |
   Assumption tests

Resultado no topo: um resultado de negócio ou de produto mensurável, como "aumentar workspaces ativos semanais em 20%". Não uma funcionalidade. Não um lançamento. Um resultado.

Oportunidades são problemas de clientes, enquadrados na linguagem do cliente, que (se resolvidos) moveriam o resultado. "Novos admins não conseguem dizer quais projetos estão travados" é uma oportunidade. "Construir um dashboard de saúde de projeto" não é. Isso é uma solução.

Soluções ficam abaixo das oportunidades, três a cinco por oportunidade. Baratas, múltiplas e explicitamente competindo entre si.

Testes de suposição ficam abaixo de cada solução. São os experimentos de fato (portas falsas, protótipos, MVPs concierge) que decidem se a solução é construída.

A razão pela qual a maioria dos times falha com a árvore não é a estrutura, é que eles a tratam como um artefato único. Eles a montam num quadro do Miro, a apresentam numa reunião de planejamento trimestral, e então ela morre. A árvore deveria viver numa parede (física ou digital), e você passa por ela toda semana. Aconteceu uma entrevista nova? Você adiciona um ramo de oportunidade. Um teste de suposição falhou? Você poda uma solução. O resultado mudou? Sub-ramos inteiros morrem.

Eu reviso minha árvore toda quinta de manhã, sozinha, por 30 minutos. Adiciono o que aprendi naquela semana e mato o que deixou de fazer sentido. Se você não faz isso, a árvore vira papel de parede.

Descoberta contínua: pelo menos 3 entrevistas com clientes por semana

Aqui está a regra que eu roubo da Torres: um PM que não está fazendo pelo menos três entrevistas com clientes por semana não está fazendo descoberta.

Isso soa agressivo até você fazer a conta. Três entrevistas × 45 semanas = 135 conversas com clientes por ano. A maioria dos PMs faz 30. O efeito de composição no reconhecimento de padrões é enorme. No fim do primeiro ano, você consegue prever o que um cliente vai dizer nos primeiros cinco minutos, e é aí que você começa a rodar entrevistas que pressionam suposições específicas em vez de pescar por dores vagas.

Sprints de pesquisa trimestrais são o oposto disso. Você empilha suas incógnitas, contrata um fornecedor de pesquisa, recebe um deck de 40 páginas, e tenta encaixar as descobertas num roadmap que já está meio comprometido. Quando o deck chega, o mundo já se moveu.

Entrevistas semanais corrigem três coisas de uma vez:

1. Recência. A dor que você ouviu na semana passada vence a dor que você ouviu no trimestre passado.
2. Iteração. Você consegue ajustar seu roteiro de entrevista com base no que ouviu ontem. Sprints não deixam você fazer isso.
3. Credibilidade com stakeholders. Quando o CRO diz "os clientes querem X", você conversou com nove deles nas últimas três semanas e consegue dizer "na verdade, três deles mencionaram X, mas o padrão maior era Y." Essa é uma conversa diferente.

Recrutar entrevistas sem esgotar os CSMs

O problema de recrutamento é real. Três fontes sólidas, ordenadas por qualidade:

• Prompts de recrutamento in-app. Um banner simples ("PM aqui, posso pegar 25 minutos do seu tempo? Vale-presente de US$ 50 da Amazon.") converte a cerca de 1% a 2% dos ativos semanais em B2B. Se você tem 10 mil WAU, são 100 a 200 conversas disponíveis por semana. A maioria dos PMs nunca explora isso porque tem medo de pedir.
• Apresentações via CSM. Pré-negocie uma cota ("preciso de 5 apresentações por mês da sua carteira") escrita nas metas mensais do CSM. Sem cota, isso desmorona na terceira semana.
• Entrevistas de deals perdidos. Converse com pessoas que avaliaram e te rejeitaram. Elas vão te contar coisas que os clientes atuais não contam, porque não têm nada a perder.

Um vale-presente de US$ 50 é o limiar certo para a maioria dos segmentos de ICP. Abaixo disso, você atrai curiosos que só querem um bate-papo. Acima de US$ 100, o financeiro começa a fazer perguntas. Para personas executivas (VP+ em empresas acima de 500 funcionários), você normalmente precisa de US$ 150 a 200 ou uma doação para caridade, porque US$ 50 é um insulto para elas.

O que conta como entrevista

Uma entrevista com cliente não é uma call de descoberta de vendas, um check-in de CSM ou um demo. A entrevista conduzida pelo PM tem um único trabalho: entender um comportamento ou dor passada específica. Se você está mostrando slides, fazendo demo ou apresentando qualquer coisa, você não está entrevistando. Você está vendendo. Pause e recomece.

Mapeamento de suposições

Toda ideia de produto se apoia em quatro baldes de suposições. O framework de mapeamento de suposições de David Bland, popularizado em Testing Business Ideas, toma emprestada a clássica lente de desejabilidade/viabilidade/factibilidade da IDEO e adiciona usabilidade:

Para cada suposição, pontue-a em dois eixos:

• Risco. Se esta suposição estiver errada, a ideia inteira colapsa?
• Evidência. Quanta evidência real temos agora? (Não opiniões. Não "já conversamos sobre isso". Evidência.)

Plote-as num 2x2. O quadrante superior direito (alto risco, baixa evidência) é onde você foca o trabalho de descoberta primeiro. O teste mais barato que poderia matar a ideia vai primeiro. Se a desejabilidade está frágil, rode uma porta falsa antes de construir qualquer coisa. Se a factibilidade é o que mata, construa um spike de 2 dias, não um MVP de 6 semanas.

Eu mantenho o mapa de suposições no mesmo quadro do Miro que a árvore de oportunidades e soluções, um frame à direita. Cada ramo de solução aponta para suas três principais suposições. Quando uma suposição é testada e falsificada, eu a risco de vermelho e a solução é rebaixada ou morta.

A porta falsa / smoke test

Uma porta falsa é a ferramenta de descoberta de maior alavancagem que eu rodo. A premissa: construir o ponto de entrada para uma funcionalidade sem a funcionalidade por trás dela. Meça se alguém clica. Se não clicam, a funcionalidade está morta antes de uma única linha de código ser escrita.

Como funciona na prática:

1. Adicione um botão, item de menu ou card in-app que promete uma capacidade, como "Agendar relatórios recorrentes".
2. Quando os usuários clicam, mostre um formulário "Em breve, quer acesso antecipado?" que captura o e-mail e um "para que você usaria isto?" de uma linha.
3. Acompanhe o CTR contra a coorte que viu.

Os limiares que eu de fato uso

São os números que calibrei em três empresas. Os seus vão variar, mas são um ponto de partida:

O limiar de 5% importa porque é mais ou menos a taxa em que você consegue justificar investimento de engenharia para uma funcionalidade que aborda uma dor clara. Abaixo de 2%, você está perseguindo 1 em 50 que levantou a mão, e a coorte não é grande o suficiente para impulsionar resultados de negócio relevantes mesmo que cada clicador converta.

As salvaguardas éticas

Você não pode mentir para seus clientes. O estado de acompanhamento "Em breve" é obrigatório, sem exceções. Mais duas regras:

• Sempre envie e-mail para todos que clicaram, mesmo que a resposta seja "decidimos não construir isto". Diga a eles o que você está fazendo em vez disso. Isso te custa 20 minutos e protege a próxima porta falsa que você rodar.
• Nunca rode uma porta falsa para algo que você jamais construiria. Se você está minerando pura curiosidade, faça entrevistas. Portas falsas são ferramentas de validação, não pesquisas de mercado.

Uma vez matei uma funcionalidade na fase de porta falsa que o time executivo vinha empurrando havia seis meses: um módulo de upsell de "pontuação preditiva de leads". Lançamos o ponto de entrada para uma coorte de 1.400 admins de mid-market, esperando pelo menos 8% a 10% de CTR com base nas anedotas de vendas. Conseguimos 1,7%. Dos 23 clicadores, 14 acharam que "pontuação preditiva de leads" significava algo completamente diferente do que planejávamos construir. Tiramos a funcionalidade do roadmap numa sexta, redirecionamos o squad para uma oportunidade diferente, e a nova aposta foi entregue seis meses depois com 41% de adoção. A porta falsa nos custou quatro dias de tempo de design e dev. A funcionalidade teria custado um trimestre.

Validação orientada por protótipo

Quando uma porta falsa passa da barra de 5%, você provou a demanda. Você não provou que a solução funciona. Esse é o trabalho do protótipo.

Eu combino a fidelidade do protótipo com a suposição que estou testando:

• Protótipo clicável no Figma. Para testar usabilidade e arquitetura da informação. Cinco usuários testados via testes não moderados do Maze vão trazer à tona a maioria dos problemas catastróficos de UX. Custo: 1 a 2 dias de design.
• MVP concierge. Quando factibilidade ou suposições de workflow são o que mata, faça o trabalho manualmente para 5 a 10 clientes. Se um cliente quer um relatório automatizado de análise de concorrentes, gere os dez primeiros à mão e envie por e-mail. Se os clientes param de abrir os e-mails na terceira semana, o valor subjacente não está lá.
• Wizard of Oz. O front-end é real, o back-end são humanos. Útil quando você precisa validar dados comportamentais (os usuários de fato sobem o arquivo? eles voltam?) sem construir infraestrutura real.
• Fatia vertical hard-coded. Uma construção real, porém estreita. Uma persona, um workflow, feia mas funcional. Entregue a 10 a 20 parceiros de design. Este é o seu último teste barato antes de um investimento de engenharia de verdade.

Não pule níveis. Não vá de "o CRO pediu" para "fatia vertical" sem uma porta falsa e um protótipo no meio. Cada nível pulado é um multiplicador no seu raio de explosão se a suposição estava errada.

O Mom Test (não induza a testemunha)

The Mom Test, de Rob Fitzpatrick, consertou minha prática de entrevistas mais do que qualquer outro recurso. A premissa: as pessoas mentem para você em entrevistas, especialmente quando gostam de você. Seu trabalho é fazer perguntas que te dão a verdade até da sua própria mãe.

As três regras:

1. Fale sobre a vida deles, não sobre a sua ideia. "Qual é a pior parte da sua segunda-feira de manhã?" vence "Você usaria uma ferramenta que conserta as segundas de manhã?" A primeira pergunta não pode ser lisonjeada. A segunda pode.
2. Pergunte sobre especificidades no passado, não sobre genéricos no futuro. "Me conte a última vez que isso aconteceu" vence "Você faria X?" Comportamento passado é dado. Intenção futura é fantasia.
3. Escute mais do que fala. Uma boa entrevista é 80% deles, 20% você. Se você está explicando seu produto, acabou. Encerre a call, anote, faça melhor na próxima.

O anti-padrão mais danoso que vejo em entrevistas de PM é o demo disfarçado de descoberta. Você marca uma call de 30 minutos para "aprender com um cliente". Vinte minutos depois, você mostrou três mockups e perguntou "isto seria útil?" Eles dizem sim, porque são educados, porque estão confusos, porque querem que a call termine. Você registra uma "entrevista de validação" nas suas notas. Você entrega a funcionalidade. Ela morre.

Se você se pegar abrindo o Figma durante uma call de descoberta, desligue e recomece. Isso não é entrevistar. Isso é vender.

Quando matar um thread de descoberta

Matar as próprias ideias é a habilidade mais difícil em produto. Três sinais me dizem que um thread está morto:

• Três testes de suposição falhos seguidos. Porta falsa abaixo de 2%, protótipo testado com cinco usuários e três travaram, MVP concierge sem uso recorrente. Isso não é azar. É o universo te dizendo para parar.
• Sem pull das entrevistas após 6 a 8 conversas. Se você conversou com oito clientes sobre um problema e nenhum se ofereceu para dizer "sim, esta é uma dor real que pagaríamos para resolver", a oportunidade não está lá. Os entrevistados vão acenar vagamente por uma ou duas conversas. Em oito, o padrão é honesto.
• Pontuações de oportunidade abaixo do limiar. Eu ranqueio cada oportunidade na minha árvore em três dimensões: frequência (com que frequência a dor bate), severidade (quão ruim quando bate) e alcance (que % do nosso ICP a sente). Se duas de três estão fracas após um mês de descoberta, o ramo morre.

Quando eu mato um thread, escrevo um memorando de morte de uma página. Não por política. Para mim, daqui a seis meses, quando alguém ressuscitar a ideia e eu precisar lembrar por que a estacionei. Template:

Ideia: [nome]
Oportunidade que pretendia abordar: [oportunidade da árvore]
Suposições testadas: [lista]
Evidência coletada: [tópicos]
Motivo da morte: [a falha específica]
O que precisaríamos ver para revisitar: [as condições]
Data: [AAAA-MM-DD]

O memorando de morte vive na mesma pasta do Notion que a árvore de oportunidades e soluções. Quando o CRO volta seis meses depois perguntando "o que aconteceu com a pontuação preditiva de leads", eu envio o memorando. Dois minutos de conversa, não duas semanas reproduzindo o mesmo debate.

Minha cadência semanal de descoberta

Aqui está o ritmo que eu rodo, caso seja útil como template de partida:

• Segunda de manhã. Três slots de entrevista são reservados para a semana. Eu os confirmo, preparo perguntas e atualizo o rastreador de entrevistas. O recrutamento acontece via prompts in-app (rodando continuamente) e apresentações via CSM.
• Terça a quinta. As entrevistas acontecem, 45 minutos cada. As notas vão para o Dovetail. Trechos de destaque são compartilhados com eng e design (clipes de cinco minutos, não transcrições). Os engenheiros de fato assistem aos clipes.
• Quinta de manhã. Revisão solo da árvore de oportunidades. 30 minutos. Novas oportunidades adicionadas, ramos mortos podados. Mapa de suposições atualizado.
• Sexta à tarde. Um teste de suposição é entregue a cada sprint (porta falsa, protótipo ou MVP concierge). Sexta é quando eu escrevo a spec do teste do próximo sprint.

É isso. Sem sprint de pesquisa trimestral. Sem decks de 40 páginas. Três entrevistas por semana, uma árvore de oportunidades, um teste de suposição por sprint. A disciplina chata vence o esforço dramático, toda vez.

Os PMs que eu mais respeito não têm instintos melhores que os do resto de nós. Eles têm uma prática de descoberta melhor. Eles conversaram com 135 clientes neste ano, rodaram 26 portas falsas, mataram 18 ideias, e entregaram as quatro que sobreviveram. É por isso que as funcionalidades deles atingem 40% de adoção enquanto todo mundo encara 9%.

Você não precisa de um orçamento maior ou de mais pesquisadores. Você precisa de três slots de entrevista no calendário da semana que vem e da disciplina de mantê-los reservados quando o trimestre fica barulhento. Comece por aí.

Saiba mais

• Modelo de descrição de cargo de gerente de produto
• Construindo roadmaps sem mentir para os stakeholders
• Escrevendo PRDs que os engenheiros de fato leem
• Métricas de PM: resultado versus entrega, North Star, indicadores antecedentes