Decisioni Sottrattive
La decisione di prodotto più importante è cosa non costruire. "Chiedi a un team cosa ha rilasciato quest'anno e otterrai una lista; chiedigli cosa ha eliminato e la stanza tace"1. Il consiglio di Nugent ha due parti: essere estremamente selettivi su cosa si lascia aggiungere al sistema, ed essere militanti nel togliere le cose1.
Il bias cognitivo
Klotz et al. (Nature, 8 esperimenti): le persone trascurano sistematicamente le modifiche sottrattive anche quando togliere è evidentemente la mossa migliore. Le idee additive arrivano velocemente e a basso costo; quelle sottrattive costano sforzo cognitivo reale. Siamo cablati per aggiungere1.
La cultura organizzativa amplifica il bias: per Gerry McGovern chi crea e lancia viene premiato; rivedere, mantenere, rimuovere sono visti come lavoro minore. Il suo lavoro sui Top Tasks: togliere circa l'80-90% del contenuto di un sito faceva vendere di più alle aziende, riduceva le chiamate al supporto e aiutava le persone a trovare prima ciò che cercavano. La rimozione è il miglioramento, non il riordino successivo. Nugent ricorda di aver già sostenuto la versione in piccolo di questo argomento, a proposito di eliminare la pagina delle FAQ1.
Cosa non costruire: i due casi classici
Nelle app fintech consumer, i due rifiuti duri di Nugent1:
- Document hub: il bisogno reale (PDF da sistemi legacy, canali di comunicazione persistenti richiesti dalla compliance) degenera, a forza di richieste aggiuntive degli stakeholder, in una ricostruzione di Google Drive, con costi di manutenzione perpetui a ogni ciclo di release di iOS e delle altre piattaforme
-
Notifications centre: la campanella col puntino rosso diventa in pochi mesi un brutto clone di Gmail; ed è capitato che l'intento del messaggio originale non potesse essere soddisfatto dallo strumento costruito per portarlo
-
Il document hub, oltre a tagging, archiviazione, stampa e condivisione su più canali, deve superare gli ostacoli di sicurezza e autenticazione perché la persona giusta veda solo i documenti giusti; e ogni release di iOS, o un cambiamento di Google, Microsoft o Amazon, può rimuovere unilateralmente qualche particolarità su cui una funzione si reggeva1
Entrambi sollevano l'organizzazione dalle sue responsabilità a spese dell'utente, anche se, ammette Nugent, molti utenti ormai sono stati abituati ad aspettarseli e sanno più o meno come funzionano1. Il test per ogni use case: "does it make the boat go faster?". Il più delle volte la risposta è usare qualcosa di semplice o già esistente, anche imperfetto1.
La leva: mostrare i running costs
Non è facile far abbandonare un modello mentale, soprattutto quando un focus group di clienti sembra in parte validarlo: Nugent richiama la frase attribuita a Henry Ford sui "cavalli più veloci" che la gente avrebbe chiesto al posto dell'automobile1. Ciò che secondo lui funziona davvero è mostrare non il build cost ma i costi di esercizio, proiettati su anni: è ciò che riporta le persone dall'orlo del baratro1.
Uccidere la piattaforma non fa sparire il problema originale (comunicare con i clienti in modo adatto a loro e rispettando gli obblighi legali). La risposta di Nugent: valutare ogni use case nel merito, essere rigorosi su cosa va davvero comunicato e quando, e spietati nel chiedersi se serva prima costruire un'intera piattaforma. "Resist, resist, resist the temptation to build a one-size-fits-all."1
Il secondo consiglio, togliere, è molto più difficile del primo, e non per semplice codardia. Richiede lo sforzo di capire cosa sia davvero il successo, che di solito sta nel mondo del cliente, non in quello dell'organizzazione1.
Il metodo Jobs (1997)
La matrice del 1997: due prodotti consumer, due pro, un prodotto stellare per box, tutte le altre linee chiuse, accentrando il talento ingegneristico invece di spalmarlo. Apple oggi ha circa 52 prodotti e servizi: il punto non era vendere quattro cose per sempre ma non sperperare l'opportunity cost1. Vedi Focus e Opportunity Cost.
Nell'era degli agenti
DHH festeggia l'endless execution, ma secondo Nugent è facile fraintenderla come invito a costruire di più: meglio usare gli agenti per la potatura e la manutenzione. Il paradosso di Stewart Brand: la manutenzione è necessaria e interamente opzionale, "opzionale finché non diventa essenziale"1. Vedi Agenti per la Potatura.
Vedi anche: Focus e Opportunity Cost, Agenti per la Potatura, Liam Nugent