Come valuto la qualità dei prodotti digitali
Senza filtri #22
Da quando ho iniziato a costruire prodotti ho iniziato anche a studiare e ad osservare come li facevano gli altri.
Aprivo app di aziende con budget enormi, team di centinaia di sviluppatori e risorse praticamente infinite. Spesso, quello che vedevo, era uno schivo. Pensavo: “ma com’è possibile che siano così tremendi con tutti quei soldi investiti?”
Poi mi capita di vedere prodotti di startup che con due lire e team di cinque persone mettono in piedi un prodotto di qualità. E non è un caso isolato.
Ho iniziato a osservare con più attenzione e a cercare di capire cosa distingue un prodotto fatto bene da uno fatto male. Soprattutto perché ad alcuni escono bene e ad altri male (nonostante i budget differenti).
Sai cosa? La risposta non è così ovvia.
Non è un questione di soldi e nemmeno una questione di competenze tecniche.
È qualcos’altro.
Il problema non è mai uno solo
Quando un prodotto fa schifo, la tentazione è cercare un colpevole: il budget, il team, la tecnologia e il tempo.
Ma la realtà è più complessa… Ci sono diversi fattori che uccidono la qualità e spesso agiscono insieme.
La qualità non è mai una priorità
Hai mai sentito qualcuno entrare in riunione e dire “facciamo un prodotto di merda”?
Direi di no (o almeno spero).
Ma nessuno dice nemmeno “la qualità viene prima di tutto, anche se costa di più, anche se ci vuole più tempo”. La qualità resta sottintesa, data per scontata. E quando arriva la pressione, è la prima cosa che salta. Perché non era mai stata davvero una priorità.
La distanza tra chi decide e chi costruisce
Più un’organizzazione cresce, più si creano passaggi intermedi. Il designer propone qualcosa, il PM lo filtra, il manager lo annacqua per farlo passare e infine lo sviluppatore implementa ciò che resta.
Ogni passaggio crea distanza tra l’idea originale e il risultato finale, ergo il risultato finale non è più di nessuno, è il compromesso tra i compromessi.
Tutti responsabili, nessuno responsabile.
Tutti sono responsabili dell’esperienza utente, nessuno lo è davvero. Le decisioni diventano scollegate. Ogni pezzo del prodotto funziona per conto suo, ma l’insieme non ha senso. Manca qualcuno che guardi il tutto e dica “questa cosa non funziona”.
Metriche sbagliate guidano i risultati sbagliati.
Se il successo si misura in numero di feature rilasciate, otterrai tante feature fatte male. Se misuri la velocity, otterrai velocità senza direzione. Se misuri i ticket chiusi, otterrai ticket chiusi di fretta. I KPI guidano i comportamenti. E se i KPI non includono la qualità, la qualità sparisce.
La paura di dire no.
Ogni stakeholder ha la sua richiesta: il commerciale vuole quella feature in modo da chiudere il cliente, il marketing poi vuole quel banner e il CEO ha visto una cosa dal competitor che vuole implementare.
Nessuno ha il coraggio o l’autorità di dire di no, quindi il prodotto diventa un accumulo che somiglia più ad un albero di Natale dove ognuno ha appeso una sua pallina. E alla fine non si capisce più cosa dovrebbe essere o cosa dovrebbe fare.
L’urgenza sovrasta la cura.
L’urgenza di rilasciare sovrasta la cura per quello che rilasci. Prima lo facciamo funzionare, poi lo miglioriamo. Ma il “poi” non arriva mai, perché c’è sempre qualcos’altro di urgente.
Le scorciatoie si accumulano.
Ogni scorciatoia sembra innocua nel momento in cui la prendi, “tanto lo sistemiamo dopo”, “per ora va bene così”, “è un workaround temporaneo”.
Tutte frasi che portano a scorciatoie, scorciatoie che si sommano, che diventano debito tecnico, e che rende ogni miglioramento più costoso, più rischioso. E arrivi al punto in cui migliorare diventa più difficile che rifare. Ma indovina? rifare non si può, quindi si rattoppa, e il rattoppo genera altro debito.
Questi fattori non si escludono a vicenda. Si sommano. Si amplificano. E il risultato è quel comportamento che è alla luce del sole: aziende con risorse enormi che producono esperienze mediocri.
Le startup hanno un vantaggio, ma non è scontato
Team piccolissimi, decisioni veloci. Chi decide è spesso chi costruisce, non ci sono dieci layer tra visione ed esecuzione.
Ma questo non significa che le startup facciano qualità di default.
Significa solo che hanno meno ostacoli strutturali. Meno burocrazia da attraversare. Meno compromessi obbligati.
Ma la qualità resta una scelta: un investimento consapevole, e anche una startup con tre persone può fare un prodotto di merda se non ci investe, se non la mette come priorità, se cede alla tentazione di “fare veloce” invece che “fare bene”.
Il vantaggio delle startup non è che fanno qualità per natura. È che possono scegliere di farla senza dover prima smontare una struttura che la impedisce.
E questa scelta, secondo me, non è mai un errore.
Cosa significa qualità per me
Quando prendo in mano un prodotto per la prima volta, la mia testa fa automaticamente una checklist (tipo lo scanner).
La prima cosa che guardo è la prima impressione visiva e di interazione. È curato? C’è attenzione ai dettagli? Le cose sono dove me le aspetto? I margini sono consistenti? I colori hanno senso? Sembra che qualcuno ci abbia pensato o sembra buttato lì?
Poi c’è la performance percepita. Non i millisecondi reali, non sto con il cronometro. Parlo di come si sente l’esperienza. Mi sembra veloce o mi sembra di aspettare? Le transizioni sono fluide o a scatti? Quando faccio un’azione, la risposta è immediata o c’è quel micro-ritardo che ti fa dubitare se il click sia andato a buon fine?
Guardo la coerenza. Sembra fatto da un team con una visione condivisa o da quindici team che non si sono mai parlati? I pattern si ripetono o ogni schermata sembra un’app diversa? I bottoni funzionano allo stesso modo ovunque?
Guardo la gestione degli errori (o degli imprevisti). Cosa succede quando qualcosa va storto? C’è un messaggio d’errore che mi spiega cosa è successo e cosa posso fare? O l’app crasha e basta? Gli stati vuoti sono gestiti? Se non ci sono dati, cosa vedo?
E per ultimo ma non per importanza, il copy. Mi parlano come una persona o come un robot dell’ufficio legale? I messaggi sono chiari? Capisco cosa devo fare? O devo interpretare gergo tecnico e frasi contorte?
Queste cose le noti nei primi trenta secondi. E ti dicono già quasi tutto su quanto chi ha costruito quel prodotto ci teneva davvero.
Chi lo fa bene secondo me
Ci sono prodotti che quando li uso penso: qui qualcuno ci ha messo cura. Ti faccio un paio di esempi:
Pinterest è ossessionato dalla performance percepita, il caricamento infinito non lo senti mai e le immagini appaiono di continuo e progressivamente. Non c’è mai un momento in cui guardi qualcosa e ti chiedi se l’app si è bloccata. Tutto scorre, è una di quelle cose che non noti finché non trovi un’app che non lo fa.
Claude e ChatGPT hanno reso naturale qualcosa di tecnicamente complesso. Lo streaming della risposta che ti tiene ingaggiato. La sensazione di conversazione. Dietro c’è una complessità enorme, ma tu non la vedi. Vedi solo qualcosa che funziona.
PostHog è product analytics fatto da gente di prodotto. L’interfaccia non ti fa sentire stupido. La documentazione rispetta la tua intelligenza. È open source ma con una UX da SaaS premium. Ogni volta che lo uso penso: questi capiscono cosa serve a chi lo usa.
Revolut ha fatto sembrare le banche tradizionali dei dinosauri. Ogni interazione è fluida. Le notifiche sono utili (non spam). Il cambio valuta in tempo reale sembra magia. Hanno preso un’industria ingessata e hanno dimostrato che si poteva fare diversamente.
Nessuna di queste aziende aveva budget illimitati all’inizio eppure hanno scelto la qualità come differenziatore. E hanno continuato a sceglierla anche quando potevano permettersi di non farlo.
Metà budget, doppia soddisfazione
Ho avuto un’esperienza diretta su questo tema poco tempo fa.
Un cliente mi ha chiesto di rifare un SaaS che aveva fatto sviluppare da altri. Il budget che avevano speso la prima volta era più del doppio di quello che avevo io a disposizione. Team più grande, più tempo, più risorse.
Il risultato? Un prodotto che non funzionava. Lento. Incoerente. Pieno di bug. E la home page, giuro che non sto esagerando, aveva un’immagine di sfondo. Un SaaS B2B. Con un’immagine di sfondo sulla home. Come fosse un sito vetrina del 2008.
L’abbiamo rifatto con metà del budget. Il cliente era molto più contento.
Non perché siamo più bravi. Non perché abbiamo qualche tecnologia segreta. Ma perché le priorità erano diverse. L’ownership era chiara. Chi decideva era vicino a chi costruiva. Non c’erano dieci passaggi tra “questa cosa dovrebbe funzionare così” e “ok, facciamola funzionare così”.
La differenza non erano i soldi. Era come quei soldi venivano spesi.
Come costruisco qualità (e come la proteggo)
Negli anni ho sviluppato un approccio che ha due parti. La prima è come costruisco qualità. La seconda è come evito di perderla quando le cose crescono.
Come costruisco.
Parto sempre dall’esperienza utente, non dalle feature. La domanda non è “cosa deve fare questo prodotto” ma “cosa deve provare chi lo usa”. È una differenza sottile eh, ma cambia tutto.
Non negozio mai sulle basi. Performance, gestione errori, coerenza visiva. Queste cose non sono optional, non sono “nice to have”, non sono “le facciamo nella prossima release”. Sono il minimo. Se non ci sono, il prodotto non è finito.
Faccio scelte esplicite su cosa non fare. Ogni feature che non aggiungi è una feature che non può rompersi, che non richiede manutenzione, che non complica l’esperienza. Dire no è parte del lavoro.
Testo con persone vere il prima possibile. Non per validare che funziona tecnicamente, ma per vedere dove si inceppano, cosa non capiscono, dove perdono tempo.
Come la proteggo.
Questa è la parte più difficile. Perché la qualità tende a degradare naturalmente quando le cose crescono. Più persone, più comunicazione, più compromessi.
La chiave è l’ownership chiara. Ogni pezzo del prodotto deve avere un responsabile. Non un team. Una persona. Qualcuno che si sveglia la mattina pensando “questa cosa è mia, e deve funzionare bene”.
Team piccoli con responsabilità end-to-end funzionano meglio di team grandi con responsabilità frammentate. Meglio tre persone che fanno tutto che dieci persone dove ognuno fa un pezzetto e nessuno vede l’insieme.
Chi decide deve sporcarsi le mani. Il momento in cui chi prende le decisioni smette di usare il prodotto, di vedere il codice, di parlare con gli utenti, è il momento in cui la qualità inizia a scendere.
Meno layer significa meno diluzione e ogni passaggio tra la visione e l’esecuzione è un’opportunità per perdere qualcosa. Riduci i passaggi.
Serve il coraggio di dire di no: dire di no a feature che non servono, a stakeholder che vogliono aggiungere cose, a scorciatoie che creano debito. Siamo d’accordo, dire di no è scomodo, ma spesso è anche l’unico modo per proteggere ciò che conta.
La qualità non si mantiene per caso. Si mantiene con strutture che la proteggono attivamente.
Oggi abbiamo un nuovo alleato
L’intelligenza artificiale sta liberando tempo. Attività che prima richiedevano ore ora ne richiedono minuti. Codice che prima scrivevi riga per riga ora lo generi e lo raffini. Documentazione, test, debug, tutto sta accelerando.
La domanda è: quel tempo dove lo mettiamo?
Possiamo usarlo per fare di più. Più feature, più prodotti, più clienti, più tutto.
Oppure possiamo usarlo per fare meglio: più cura, più attenzione, più qualità.
Investire sulla qualità non è mai stato così accessibile perché abbiamo gli strumenti che ci permettono di dedicare più tempo alle cose che contano: l’esperienza e i dettagli (quelli importanti).
La scelta è nostra.
E la prossima volta che apri un’app che fa schifo, chiediti: stanno facendo schifo perché non sanno fare meglio, o perché hanno scelto di non investire sulla qualità?
Perché alla fine, è sempre una scelta.
Ci vediamo alla prossima newsletter.
Senza filtri,
Chri