Opportunity Solution Tree

L'albero si legge dall'alto verso il basso in quattro livelli. Alla radice c'è un unico outcome desiderato — un obiettivo misurabile che il team persegue, come aumentare l'attivazione o ridurre il time-to-value. Sotto si diramano le opportunità: bisogni, dolori e desideri del cliente espressi nelle sue stesse parole, emersi attraverso la discovery continua. Sotto ogni opportunità si trovano soluzioni candidate, e sotto ogni soluzione si trovano i test di ipotesi o esperimenti che verificano se la soluzione muoverà davvero l'opportunità.

La struttura è deliberatamente un albero, non una lista. Un unico outcome si dirama in molte opportunità, ogni opportunità in diverse soluzioni, ogni soluzione in più test. Questa ramificazione costringe un team a mantenere più di un'opzione a ogni livello, che è l'antidoto a impegnarsi sulla prima idea che sembra plausibile.

Il compito dell'albero è rendere visibili e contestabili le decisioni di discovery. Poiché ogni soluzione risale a un'opportunità e ogni opportunità all'outcome, chiunque può chiedere "quale bisogno del cliente serve questo, e quale obiettivo muove quel bisogno?" Una funzionalità che non può rispondere a queste domande viene esposta come lavoro orfano prima di consumare uno sprint.

Riformula anche la prioritizzazione. Invece di classificare un backlog piatto di funzionalità, il team confronta prima le opportunità rispetto all'outcome — valutando quale bisogno, se risolto, muoverebbe di più l'obiettivo — e solo dopo esplora le soluzioni all'interno del ramo scelto. Torres lo chiama "confrontare opportunità, non soluzioni", e questo mantiene onesti i framework di scoring come RICE assicurando che gli elementi valutati siano bisogni genuini del cliente e non funzionalità precotte.

L'errore più comune è scrivere soluzioni camuffate da opportunità. "Aggiungere un'integrazione Slack" è una soluzione; la vera opportunità è "perdo traccia delle menzioni perché vivono in un altro strumento". Quando il livello delle opportunità è pieno di funzionalità, l'albero collassa in un backlog e il suo potere comparativo scompare. Le opportunità devono essere formulate come bisogni del cliente, nel linguaggio del cliente, distinte da qualsiasi singola soluzione.

Un secondo errore è trattare l'albero come un artefatto una tantum. Dovrebbe evolvere ogni settimana man mano che arrivano nuove evidenze dalle interviste — i rami vengono aggiunti, potati e ripesati. Un albero che non è cambiato da un mese è di solito segno che la discovery si è silenziosamente fermata. Una terza trappola è saltare del tutto il livello degli esperimenti e rilasciare la prima soluzione sotto un'opportunità, il che scarta la generazione di opzioni che la struttura esiste per imporre.

Un opportunity solution tree è affidabile solo quanto le evidenze sotto ogni ramo. In pratica quell'evidenza — la nota dell'intervista, il ticket di supporto, il segnale di utilizzo, il ricavo dietro l'account che l'ha segnalata — vive di solito in strumenti separati, quindi le opportunità tendono a scivolare da bisogni reali verso supposizioni, e gli outcome perdono il loro legame con il comportamento reale degli account.

Un sistema operativo di prodotto come AIOProductOS mantiene quell'evidenza collegabile su una base condivisa: il suo feed Insights mostra il feedback proprio accanto al record Customer-360 e al ricavo dietro di esso, così un'opportunità può mostrare quali account paganti l'hanno segnalata prima di meritarsi un ramo, e l'outcome alla radice può essere tracciato rispetto ad analytics di prodotto reali invece che a un numero copiato in uno slide. L'albero resta uno strumento di discovery; la base mantiene aggiornata l'evidenza che lo sostiene.