La Feature
Validata:
Uccidere
l'Idea Giusta

Il management aveva approvato 4 mesi di sviluppo per una dashboard analitica complessa. Motivazione: "i clienti la chiedono." User research: zero. Budget allocato. Tre settimane di prototipazione hanno cambiato tutto.

4 mesi

Di sviluppo evitato · Round di investimento chiuso

3 sett.

Per costruire e testare il prototipo

8

Utenti testati. Risultato unanime.

* Dati reali. Nome azienda omesso per riservatezza.

"I clienti lo
hanno chiesto."

Una piattaforma SaaS B2B enterprise aveva accumulato 4 mesi di roadmap intorno a una dashboard analitica avanzata. L'idea era nata da tre conversazioni con clienti soddisfatti in un trimestre di forte crescita. Il management ci aveva costruito sopra un piano di sviluppo completo, stimato a 4 mesi con un team di 5 persone.

Nessuno aveva fatto user research. Nessuno aveva verificato se quelle tre conversazioni rappresentassero un bisogno reale di segmento o tre outlier soddisfatti che stavano chiedendo qualcosa che non sapevano come chiedere in modo diverso.

Il budget era già allocato. Le sprint pianificate. I developer in attesa di specifiche. In quel contesto, chiedere "ma siamo sicuri che serva?" richiede una certa dose di coraggio , e qualcosa di concreto da mostrare come alternativa.

La frase più pericolosa in un meeting di prodotto: "I clienti lo hanno chiesto." Spesso significa che due o tre persone hanno menzionato qualcosa e l'azienda ci ha costruito sopra un piano trimestrale. La distanza tra "un cliente ha chiesto" e "il mercato ha un bisogno" è esattamente dove si spreca la maggior parte del budget di sviluppo.

Settore SaaS B2B
Enterprise
Ruolo Lead UX &
Product Strategist
Durata 3 settimane
prototipazione
Metodi JTBD, Proto
HiFi, Test utenti

3 settimane
per evitare 4 mesi.

La proposta era semplice: prima di allocare 4 mesi di sviluppo, diamo 3 settimane alla validazione. Se il prototipo conferma il bisogno, si va avanti con dati. Se no, si adatta. La resistenza iniziale è normale. Il pivot che ne è seguito, decisivo.

01

Jobs-to-be-done · Settimana 1

Interviste con 12 clienti attivi usando il framework JTBD. Non "vorreste una dashboard?" ma "quando avete bisogno di capire come sta andando il vostro team, cosa fate adesso?" La risposta era unanime e diversa dalla dashboard: volevano alert proattivi, non una pagina in più da monitorare.

02

Prototipo · Settimana 2

Due prototipi paralleli: la dashboard analitica originale e un sistema di alert proattivi intelligenti. Entrambi high-fidelity, entrambi interattivi, costruiti in Figma in 5 giorni. Questo è il momento dove la velocità conta: più il prototipo è realistico, più i test sono validi.

03

Test comparativo · Settimana 3

8 utenti target, 45 minuti ciascuno. Task identici su entrambi i prototipi. Misurazione: completion rate, time-on-task, preferenza dichiarata e soddisfazione. Risultato: 7 utenti su 8 preferivano il sistema di alert. La dashboard produceva ansia, non insight.

04

Pivot e pitch · Fine settimana 3

Presentazione al management con dati di test, video delle sessioni più significative e mockup del sistema di alert rivisto. Decisione in 48 ore: pivot completo. Il prototipo pivotato è diventato il centrepiece della pitch agli investitori del round successivo.

La domanda giusta

Non abbiamo chiesto "ti piace questa dashboard?" Abbiamo chiesto "quando hai bisogno di sapere se qualcosa non va, cosa fai oggi?" La domanda giusta produce risposte utili. La domanda sbagliata produce consenso inutile.

Il pivot in 5 giorni

Una volta confermato che il bisogno reale erano gli alert, abbiamo ridisegnato il prototipo in 5 giorni. Non partendo da zero: dai pattern che già funzionavano nella dashboard e rimodellandoli attorno a un flusso notifica-azione. Il materiale giusto era già lì. Mancava la direzione.

Il ruolo negli investitori

Il prototipo non era solo un deliverable di prodotto. Era una proof of customer validation , dimostrava che l'azienda aveva un processo per verificare le ipotesi prima di costruire. Per gli investitori, questo vale tanto quanto le metriche.

Non una feature
in meno. Una corretta.

4 mesi

Di sviluppo risparmiato sulla direzione sbagliata

3 sett.

Per validare, pivotare e produrre un prototipo investibile

7/8

Utenti che preferivano il sistema di alert alla dashboard

Round ✓

Chiuso con il prototipo come centrepiece della pitch

Questo non è un caso studio su come abbiamo fatto una bella feature. È un caso studio su come abbiamo evitato di fare la feature sbagliata, e su come quella scelta abbia prodotto qualcosa di più valido di quello che era pianificato.

I 4 mesi di sviluppo risparmiati non sono stati "sprecati": sono stati reindirizzati sul sistema di alert, che è entrato in produzione con una base di validazione che raramente accompagna una nuova feature.

Prima di costruire,
verifica.

Un UX Business Audit in 60 minuti identifica se stai costruendo sulla direzione giusta. Prima che costino mesi di sviluppo, le ipotesi vanno testate.