La discovery vuole scale di bisogni scoperti

La discovery comincia quasi sempre con materiale disordinato ma prezioso. Una call commerciale porta una lamentela. Un ticket di supporto ripete un workaround. Un’intervista fa emergere un rituale faticoso. Un customer success manager segnala che tre account hanno chiesto la stessa integrazione. In poco tempo il team si ritrova con citazioni, tag, screenshot e molta energia.

Non è ancora evidenza di prodotto. È materia prima.

La discovery prodotto ha bisogno di scale di bisogni scoperti perché le decisioni di roadmap non dovrebbero dipendere dalla citazione più memorabile. Dovrebbero dipendere da quale bisogno, in quale segmento, mostra il gap di soddisfazione più forte, l’evidenza più solida e il prossimo test più chiaro. Una scala trasforma la discovery da raccolta di osservazioni a oggetto decisionale che product, design, engineering e go-to-market possono discutere insieme.

Il Lean Product Process di Dan Olsen è un buon riferimento perché mette target customer e bisogni scoperti prima di value proposition, set di funzionalità MVP, prototipo, test con i clienti e iterazione. La sequenza è importante: se il bisogno resta vago, ogni scelta successiva diventa cosmetica. La pagina del libro descrive proprio questo passaggio da clienti target a bisogni scoperti, value proposition, MVP prototype, test con i clienti e iterazione verso il product-market fit: Dan Olsen, The Lean Product Playbook.

La discovery non è un mucchio di citazioni

Un mucchio di citazioni sembra utile perché conserva la voce del cliente. Questo conta, ma può anche nascondere la decisione. Dieci citazioni sugli export della dashboard, cinque sull’onboarding confuso e tre sull’ansia da fatturazione non dicono automaticamente cosa costruire. Il team deve ancora chiedersi: da quale segmento arriva il segnale, quale lavoro stavano cercando di completare, quanto male funzionano le alternative attuali e quale evidenza cambierebbe la nostra fiducia?

Per questo le note di discovery hanno bisogno di un secondo artefatto. Le note grezze vanno conservate, ma non si può chiedere a una riunione di roadmap di interpretarle da zero. La discussione scivolerà verso gerarchie, carisma e aneddoti recenti. L’account più rumoroso sembrerà il mercato. L’opportunità commerciale più nuova sembrerà strategia. Il prototipo più rifinito sembrerà prova.

Una scala dei bisogni riduce questo slittamento. Ogni riga cattura un bisogno potenzialmente scoperto e lo confronta con gli altri. La scala non elimina il giudizio. Lo rende ispezionabile. Se una product lead sostiene che il bisogno di onboarding deve stare sopra quello di reporting, deve rendere esplicito il motivo: segmento più grande, dolore più netto, workaround più fragile, evidenza più forte, maggiore coerenza strategica o test successivo più rapido.

È lo stesso principio discusso in Discovery non è chiedere ai clienti cosa vogliono. I clienti possono descrivere attriti, vincoli, ansie e workaround. Sono meno affidabili quando devono disegnare la roadmap al posto del team. La scala mantiene l’attenzione su dove i clienti sono serviti male, non solo su cosa hanno chiesto.

Cosa entra in una scala di bisogni scoperti?

Una buona scala deve essere abbastanza piccola da essere letta e abbastanza specifica da poter essere contestata. Per ogni riga, servono otto campi.

Primo, il segmento. Non tutte le persone che usano il prodotto appartengono allo stesso gruppo decisionale. Un admin finance in un’azienda da 40 persone, una manager RevOps in un’azienda da 700 e un founder che usa il prodotto di notte possono tutti chiedere reporting, ma non avere lo stesso bisogno.

Secondo, il job o contesto. Cosa stava succedendo quando è emerso il bisogno? Preparare un board update, ripulire un import fallito, approvare un rimborso, invitare una nuova collega o verificare se un’automazione ha girato correttamente sono contesti diversi.

Terzo, il bisogno dichiarato in linguaggio semplice. Deve essere noioso. Una buona riga può dire: capire quali record importati sono falliti prima del prossimo sync commerciale. Non dovrebbe dire: costruire un centro avanzato di osservabilità degli import.

Quarto, il dolore osservato. Che cosa ha fatto, rimandato, ripetuto, evitato o scalato l’utente? Qui il team registra comportamenti, non preferenze.

Quinto, il workaround attuale. I workaround sono evidenza sottovalutata. Spreadsheet, controlli manuali, escalation su Slack, screenshot, tool duplicati e riunioni ricorrenti mostrano che il cliente sta già pagando un costo.

Sesto, il gap di soddisfazione. La domanda non è solo se il bisogno esiste. La domanda è se le opzioni attuali lasciano quel segmento davvero scoperto. Un fastidio leggero con molte alternative accettabili non dovrebbe superare un bisogno che blocca un workflow operativo settimanale.

Settimo, la forza dell’evidenza. Basta una scala semplice: debole, media, forte. Debole può voler dire una intervista e un aneddoto commerciale. Media può significare interviste ripetute più pattern nel supporto. Forte può includere comportamento osservato, frequenza nei dati, disponibilità a pagare, rischio churn o risposta a un prototipo.

Ottavo, il prossimo test. Ogni riga deve avere una prossima mossa di apprendimento: un’altra intervista nello stesso segmento, un test di prototipo, un fake door, una quantificazione dei log di supporto, una prova di pricing, un workflow concierge o un test di usabilità.

Come cambia le scelte di roadmap?

La scala cambia la conversazione perché sposta il confronto dalle feature ai bisogni. Invece di chiedere se i filtri di export siano più importanti dei template di onboarding, il team chiede quale bisogno scoperto meriti ora una scommessa di prodotto.

La differenza è concreta. Le feature sono spesso ipotesi impacchettate. Una feature può risolvere il bisogno, risolverlo solo in parte o mancarlo del tutto. Se la scala dice che il bisogno principale è ridurre l’incertezza prima di un passaggio al finance, la roadmap può considerare più soluzioni: messaggi di stato migliori, riepiloghi delle eccezioni, code di approvazione, audit trail o proprietà esplicita del workflow. Il team non è più prigioniero della prima feature richiesta.

La scala rende anche più spiegabili i trade-off. Quando uno stakeholder chiede perché una richiesta visibile non è nel prossimo slice di roadmap, la product lead può mostrare la riga. Forse il segmento è troppo stretto. Forse il workaround è accettabile. Forse l’evidenza è debole. Forse il bisogno è reale, ma un altro bisogno ha un gap più ampio e un percorso di validazione più chiaro.

Questo si collega bene a Le scommesse prodotto servono criteri di stop. La scala aiuta a decidere cosa merita una scommessa. I criteri di stop aiutano a decidere quando quella scommessa è fallita. Insieme impediscono di trattare la discovery come autorizzazione a costruire ciò che sembrava già interessante.

Dove fallisce di solito l’evidenza?

L’evidenza fallisce in punti ricorrenti. Il primo è mescolare i segmenti. Il team combina lamentele enterprise, attriti self-service e opinioni interne nella stessa riga, poi si stupisce se la soluzione diventa gonfia. Bisogna dividere la riga finché segmento e contesto non sono coerenti.

Il secondo errore è confondere frequenza e importanza. Un problema citato spesso può essere comunque a bassa posta. Un bisogno più raro può avere molto valore se tocca rinnovo, attivazione, compliance o un workflow centrale. La scala deve separare quante volte qualcosa appare da quanto costa quando appare.

Il terzo errore è trattare le richieste come bisogni. Costruire export CSV è una richiesta. Riconciliare numeri offline prima di una riunione con la leadership è più vicino a un bisogno. La richiesta può ancora essere la soluzione giusta, ma non dovrebbe saltare il passaggio di traduzione.

Il quarto errore è lasciare vuoti i prossimi test. Una scala senza test diventa un backlog più elegante. Il punto non è creare una classifica permanente. Il punto è mostrare cosa il team crede oggi e quale apprendimento migliorerebbe o sfiderebbe quella credenza nel modo più efficiente.

Un rituale pratico prima della roadmap

Prima della prossima review di roadmap, prendi cinque note di discovery e trasformale in una scala. Non iniziare da una tassonomia enorme. Parti da cinque righe.

Per ogni riga, scrivi segmento, job, bisogno dichiarato, dolore osservato, workaround, gap di soddisfazione, forza dell’evidenza e prossimo test. Poi ordina le righe dalla più promettente alla meno promettente. Infine, marca la cella più debole nella prima riga. Forse il segmento è troppo largo. Forse il workaround è presunto e non osservato. Forse il gap è emotivo ma non operativo. Forse il prossimo test è vago.

Quella cella debole è il lavoro. Dice al team cosa imparare prima di trasformare discovery in delivery.

Una buona scala di bisogni scoperti non rallenta i team prodotto. Evita la falsa velocità. Tiene l’evidenza cliente vicino alla roadmap e rende visibile ogni salto: dal segmento al bisogno, dal bisogno al gap, dal gap all’evidenza e dall’evidenza al prossimo test.