Opportunity Solution Tree

A árvore se lê de cima para baixo em quatro camadas. Na raiz está um único outcome desejado — uma meta mensurável que a equipe persegue, como elevar a ativação ou reduzir o tempo até o valor. Abaixo dela se ramificam as oportunidades: necessidades, dores e desejos do cliente expressos nos próprios termos do cliente, revelados pela descoberta contínua. Sob cada oportunidade ficam soluções candidatas, e sob cada solução ficam os testes de hipótese ou experimentos que investigam se a solução realmente vai mover a oportunidade.

A estrutura é deliberadamente uma árvore, não uma lista. Um único outcome se ramifica em muitas oportunidades, cada oportunidade em várias soluções, cada solução em múltiplos testes. Essa ramificação força a equipe a manter mais de uma opção em cada nível, o que é o antídoto para se comprometer com a primeira ideia que parece plausível.

A função da árvore é tornar as decisões de descoberta visíveis e contestáveis. Como toda solução remonta a uma oportunidade e toda oportunidade remonta ao outcome, qualquer pessoa pode perguntar "que necessidade do cliente isso atende, e que meta essa necessidade move?" Uma funcionalidade que não consegue responder a essas perguntas é exposta como trabalho órfão antes de consumir uma sprint.

Ela também reformula a priorização. Em vez de ranquear um backlog plano de funcionalidades, a equipe primeiro compara oportunidades em relação ao outcome — avaliando qual necessidade, se resolvida, moveria mais a meta — e só depois explora soluções dentro do ramo escolhido. Torres chama isso de "comparar oportunidades, não soluções", e isso mantém frameworks de scoring como o RICE honestos, garantindo que os itens avaliados sejam necessidades genuínas do cliente, e não funcionalidades pré-cozinhadas.

A falha mais comum é escrever soluções disfarçadas de oportunidades. "Adicionar uma integração com Slack" é uma solução; a oportunidade real é "perco o controle das menções porque elas vivem em outra ferramenta". Quando a camada de oportunidades está cheia de funcionalidades, a árvore colapsa em um backlog e seu poder comparativo desaparece. As oportunidades precisam ser formuladas como necessidades do cliente, na linguagem do cliente, distintas de qualquer solução específica.

Uma segunda falha é tratar a árvore como um artefato único. Ela deve evoluir semanalmente conforme novas evidências de entrevista chegam — ramos são adicionados, cortados e repesados. Uma árvore que não muda há um mês costuma ser sinal de que a descoberta silenciosamente parou. Uma terceira armadilha é pular inteiramente a camada de experimentos e lançar a primeira solução sob uma oportunidade, o que descarta a geração de opções que a estrutura existe para impor.

Um opportunity solution tree só é confiável na medida das evidências sob cada ramo. Na prática, essa evidência — a nota da entrevista, o ticket de suporte, o sinal de uso, a receita atrás da conta que a levantou — geralmente vive em ferramentas separadas, então as oportunidades tendem a se afastar de necessidades reais e voltar a serem palpites, e os outcomes perdem sua ligação com o comportamento real das contas.

Um sistema operacional de produto como o AIOProductOS mantém essa evidência conectável em uma base compartilhada: seu feed de Insights exibe o feedback junto ao registro Customer-360 e à receita por trás dele, de modo que uma oportunidade pode mostrar quais contas pagantes a levantaram antes de merecer um ramo, e o outcome na raiz pode ser acompanhado em relação a analytics de produto reais, e não a um número copiado para um slide. A árvore permanece uma ferramenta de descoberta; a base mantém a evidência sob ela atualizada.