Atto IV: L'incastro
Le app sono un problema di governance travestito
Il brand fatturava trecento milioni di dollari l’anno, e la prima domanda che il nuovo team si pose era abbastanza piccola da stare su un foglietto: se cambiamo le regole degli sconti in Flow, cosa si rompe?
È una domanda ragionevole. È il tipo di domanda che fai il primo giorno, prima di esserti guadagnato il diritto di chiederne di più difficili, come quando saggi col piede un lago ghiacciato prima di affidargli il tuo peso. Il team si aspettava una risposta nel giro di un pomeriggio. Un diagramma, forse. Una pagina wiki scritta da chi aveva impostato le regole, un po’ datata ma abbastanza vicina.
Ci vollero tre settimane.
Tre settimane, perché la logica degli sconti non viveva in un solo posto. Una parte viveva in Flow—non un’automazione, ma un groviglio di automazioni, una quarantina di trigger che si attivavano a vicenda in un ordine che nessuno aveva mai disegnato. Una parte viveva dentro le app: un’app di promozioni che teneva le proprie regole, un’app di loyalty che le sovrascriveva in silenzio al carrello, un’app di bundling che aveva opinioni su entrambe. Una parte viveva in una configurazione di Checkout Blocks che esattamente due persone avevano mai capito fino in fondo, e una di quelle due persone ormai lavorava da un’altra parte, e rispondeva all’email del recruiter “per caso ti ricordi—” come chiunque risponde a quell’email, cioè in modo caloroso e inutile.
Così il team fece l’unica cosa rimasta da fare. Fecero reverse engineering del proprio store. Aprirono le app e lessero le impostazioni. Esportarono le definizioni di Flow e le stesero una in fila all’altra su una parete. Piazzarono ordini di prova con codici sconto fasulli e guardarono cosa usciva dall’altra parte, come fisici che deducono una particella dalle macerie che lascia. Dopo tre settimane avevano una risposta, e la risposta era un documento di quaranta pagine, e la vera scoperta del documento non era ecco come funzionano gli sconti. La vera scoperta era: nessuno sapeva come funzionavano gli sconti, e nessuno lo sapeva da un pezzo, e lo store andava avanti lo stesso, come un corpo che porta avanti una febbre di cui non si è ancora accorto.
Questa è la parte su cui sbagliano tutti quando lasciano Magento. Il brand aveva lasciato Magento proprio per sfuggire a questo—il PHP custom che nessuno riusciva a leggere, i cron job che giravano per ragioni perse nel ricambio del personale, il plugin che qualche contractor aveva scritto nel 2017 e che non potevi rimuovere perché qualcosa, da qualche parte, ci si appoggiava ancora. Shopify doveva essere la cura. E in un senso ristretto lo era: il PHP è davvero sparito. I cron job sono davvero spariti. Nessuno ha più paura del database.
Ma la logica di business non evapora quando cambi piattaforma. Deve vivere da qualche parte. Deve sempre vivere da qualche parte. Su Magento viveva nel codice, il che faceva paura ma almeno era localizzato—c’era un repository, e la logica era lì dentro, e un engineer coraggioso con un weekend a disposizione poteva leggersela tutta. Su Shopify la stessa logica si sparpaglia. Un po’ nelle app. Un po’ in Flow. Un po’ in Checkout Blocks. Un po’ nelle Functions. Ogni pezzo è più facile da installare di quanto l’equivalente Magento sia mai stato—clicchi un bottone, attivi un’impostazione, non apri mai un terminale. E ogni pezzo è, preso singolarmente, più semplice. Ma sommati non danno qualcosa di più semplice. Danno il documento di quaranta pagine e le tre settimane perse.
La complessità non è scomparsa quando hanno lasciato Magento. È migrata da qualche parte di più colorato.
Vogliamo andarci cauti qui, perché esiste una versione di questo capitolo che si legge come le app fanno schifo, e quella versione è sbagliata, e avresti ragione a smettere di leggere se la scrivessimo. Le app sono il modo in cui Shopify funziona. L’ecosistema è il grande vantaggio della piattaforma su qualsiasi stack bespoke che potresti costruire al suo posto; il fatto che un motore di subscription o un portale resi o un calcolatore di tasse sia un’installazione da quindici minuti invece di un build da sei mesi non è una trappola, è un regalo, e i brand che rifiutano il regalo per purismo finiscono col reinventare l’equivalente commerce della ruota, male, su una scadenza.
L’argomento è più ristretto e più cattivo di le app fanno schifo. L’argomento è questo: più veloce da installare e più facile da ragionarci sopra non sono la stessa cosa, e a una certa scala smettono di essere la stessa cosa in modo piuttosto violento. In uno store piccolo sono abbastanza vicini che la differenza non ti presenta il conto. Installi dieci app, le configuri, riesci a tenere tutto l’assetto in testa, e se qualcosa si rompe sai più o meno dove guardare. A cento milioni di dollari di GMV in su, il divario si apre. Il numero di app cresce. Le interazioni tra di loro crescono più in fretta delle app stesse—è qui la crudeltà, le connessioni si moltiplicano in modo quadratico mentre le cose connesse si limitano a sommarsi—e arriva il giorno in cui nessuna singola persona sa rispondere a se cambiamo le regole degli sconti, cosa si rompe, e l’unica risposta onesta è scopriamolo, che costa tre settimane.
Vale a dire: su larga scala, la tua strategia sulle app non è una questione di procurement. È una questione di governance travestita da questione di procurement. Pensi di stare decidendo quale app di subscription. In realtà stai decidendo dove vivrà questa parte del nostro business, chi la possiederà, e qualcuno riuscirà a ritrovarla tra due anni. I brand che lo fanno bene non sono i brand che hanno installato meno app. Abbiamo visto store ascetici che erano incubi e store sterminati che erano immacolati. I brand che lo fanno bene sono quelli che hanno sempre saputo dove fosse ogni cosa.
Ci sono tre modi in cui la complessità colorata ti presenta il conto, e vale la pena prenderli con calma, perché ciascuno è invisibile alla dimensione in cui prendi la decisione e costoso alla dimensione in cui ci convivi.
Il primo è la frammentazione dei dati. Ogni app che installi è, in silenzio, un suo piccolo database. L’app di subscription tiene i suoi record di subscription—non nel tuo oggetto customer, nel suo store, rispecchiati verso di te attraverso i campi che lei sceglie di esporre. L’app di loyalty tiene il suo registro punti. L’app di recensioni tiene le sue recensioni; l’app di raccomandazione tiene il suo indice; l’app di wishlist tiene, in almeno una storia vera che non smetteremo mai di raccontare, le varianti di prodotto sbagliate per tre mesi. A basso volume va bene, come va bene una scrivania disordinata in un piccolo ufficio. Su larga scala sono tre problemi impilati uno sull’altro. È un problema di migrazione, perché il giorno in cui vorrai lasciare quell’app—e prima o poi vorrai lasciare qualche app, lo fanno tutti i brand—i dati che ti servono hanno la forma che il vendor ha trovato comoda, non la forma che gli avresti dato tu, e tirarli fuori è un progetto di archeologia. È un problema di reporting, perché la verità sui tuoi clienti è ormai spalmata su una dozzina di sistemi e nessuna singola query li tocca tutti. Ed è un problema di compliance, perché quando un cliente nella giurisdizione giusta esercita il proprio diritto all’oblio, sei tu il responsabile di trovarlo dentro ognuno di quei piccoli database, e non puoi cancellare un record di cui non sai l’esistenza.
Il secondo è il prezzo. Il prezzo delle app è quasi sempre una funzione del volume—ordini, o GMV, o subscriber attivi, qualche contatore che sale con il tuo successo. Nella demo è niente. Nella demo è così evidentemente niente che tirarlo fuori sembra meschino, come controllare il prezzo del pane. E poi il tuo business fa la cosa per cui hai iniziato la migrazione, cioè crescere, e il contatore sale, e a duecento milioni di dollari di GMV l’app che alla demo costava un errore di arrotondamento ora costa, all’anno, più che costruirti e mantenerti l’equivalente da solo. La differenza—ed è qui la parte che dovrebbe bruciare—è che hai pagato tutti quei soldi per affittare. Quando costruisci, il build è tuo; la manutenzione è un costo, ma l’asset è dalla tua parte del libro mastro. Quando affitti, paghi un affitto continuo per un’infrastruttura che non puoi modificare, e alla fine di ogni anno non possiedi esattamente niente, e il contatore è più alto di prima. Non stiamo dicendo di non affittare mai. Noi affittiamo di continuo. Stiamo dicendo: conosci il numero che pagherai al doppio della tua dimensione attuale, perché è quello il numero che conta, e la demo non te lo mostrerà. Fai i conti a 2× la tua dimensione attuale, non alla tua dimensione attuale. Scrivilo da qualche parte. Lo vorrai di nuovo.
Il terzo è il più sottile e quello che separa i brand che invecchiano bene dai brand che si calcificano. Chiamalo il divario dei primitivi. Shopify ha concetti nativi—metafield, Markets, B2B, Checkout Extensions, i nuovi customer account, le Functions. Sono la grammatica della piattaforma. Alcune app sono costruite in quella grammatica: salvano i loro dati in metafield che puoi leggere, estendono il checkout nativo invece di rimpiazzarlo, trattano i concetti di Shopify come fondamenta e ci costruiscono sopra un piano. Altre app si portano dietro tutto—il loro modello dati, la loro superficie di configurazione, la loro logica front-end imbullonata sul tuo storefront—e trattano Shopify come una relazione di fatturazione e un posto dove abitare. Il primo tipo compone valore. Siccome parla la lingua della piattaforma, interopera con l’app successiva che la parla anche lei, ed eredita ogni nuova capacità della piattaforma più o meno gratis. Il secondo tipo compone debito. Crea un sistema parallelo—i suoi dati, la sua config, la sua UI—che non è del tutto visibile a nient’altro, te incluso, e che va riconciliato a mano a ogni confine.
Questo ti dà un test, ed è quello che vogliamo tu porti via da questo capitolo e dentro il resto del libro, perché ci appoggeremo ancora e ancora: questa app costruisce sui concetti nativi di Shopify, o introduce un suo strato? Quella singola domanda prevede di più su come invecchierà un’app del suo numero di recensioni, della sua fascia di prezzo o della sicurezza del venditore che te la mostra in demo. Un’app come Shoplift, che lavora attraverso la piattaforma invece che aggirandola—costruendo sui primitivi nativi invece di duplicarli—si guadagna il suo posto per la via facile; più a lungo la usi, più vale, perché cresce mentre la piattaforma cresce. Un’app che reinventa quello che Shopify ti dà già ti costa un po’ di più ogni trimestre man mano che i due sistemi si allontanano, e un giorno l’allontanamento è un documento di quaranta pagine e tre settimane perse.
Quindi: prima il test dei primitivi, prima di ogni altra cosa. E solo dopo che un’app lo ha superato le altre domande si guadagnano il loro turno—la qualità della sua API e quanto dei tuoi stessi dati ti lascerà davvero raggiungere; se il suo prezzo resta sano al doppio della tua dimensione; l’azienda che c’è dietro, se esisterà e risponderà al telefono tra tre anni; e se è compatibile con le specifiche feature di Shopify su cui hai deciso di costruire il tuo business. Belle domande, tutte quante. Ma sono il secondo round. Un’app che fallisce il test dei primitivi può avere un’API bellissima e un prezzo amichevole e un team meraviglioso e ti costruirà comunque, in silenzio, un mondo parallelo, e sarai comunque tu quello che lo riconcilia ai confini per sempre.
Se le app e Flow sono dove la logica può vivere, la domanda viva è quando dovrebbe smettere di viverci e diventare qualcosa che costruisci. Ce lo chiedono di continuo, di solito formulato come dovremmo costruire o comprare, che è la cornice sbagliata perché suona come un bivio una tantum quando in realtà è una cosa che matura nel tempo. Lo schema onesto è quasi sempre lo stesso. Un brand parte con un’app, perché partire con un’app è corretto—non costruisci un motore di subscription da zero per testare se le subscription funzionano per te, ne installi uno e lo scopri. L’app serve bene. Poi il dominio cresce. Due anni dopo, le subscription non sono più una feature, sono un terzo del fatturato, e i bisogni del brand hanno superato quello per cui l’app era stata costruita—e il prezzo dell’app ha superato quello che il brand vuole pagare—e i dati che l’app custodisce sono diventati troppo importanti per lasciarli nel database di qualcun altro. Così il brand li estrae. Costruisce la cosa custom. Non perché comprare fosse stato un errore; comprare era giusto per gli anni in cui era giusto. Perché il brand è cresciuto dentro una decisione diversa. Le subscription sono l’esempio canonico, ma la forma si ripete ovunque: lo strumento giusto a una dimensione è lo strumento sbagliato a quella successiva, e i brand che soffrono sono quelli che hanno scambiato la prima decisione per una permanente.
Ci sono tre segnali che il giorno è arrivato, e di solito ne senti almeno uno prima di riuscire a dargli un nome. Il primo è la matematica—quella che hai già scritto—quando il prezzo dell’app al tuo volume reale, proiettato in avanti al doppio della tua dimensione, supera quello che costerebbe costruire la cosa e tenerla in piedi. Il secondo è la complessità: ti ritrovi a combattere con lo strumento, a scrivere workaround per i suoi limiti, ad aprire feature request e ad aspettare una roadmap che non controlli, con ogni nuova capacità di Shopify che diventa una trattativa col vendor su quando, o se, la supporteranno. Il terzo è la proprietà: i dati sono diventati rilevanti per la compliance, o per la portabilità, o centrali per il reporting in un modo che rende la loro permanenza nello store di un vendor una passività vera invece che teorica. Un segnale è una conversazione. Due sono un piano. Tre e sei già in ritardo, e l’unica domanda è se estrai secondo i tuoi tempi o secondo quelli del vendor.
Niente di tutto questo ti chiede di installare meno app. Continuiamo a ripeterlo perché è l’istinto a cui tutti si aggrappano per primo—la risposta è la moderazione, la risposta è uno stack più piccolo—e non è la risposta. Il brand con dieci app e nessuna mappa è più nei guai del brand con quaranta app e una mappa chiara. La disciplina non è la sottrazione. È una singola domanda, fatta prima di ogni app, ogni Flow, ogni toggle di Checkout Blocks, ogni Function—fatta presto, mentre rispondere costa ancora poco, invece che tre anni dopo quando costa tre settimane: dove vivrà questa logica, e chi la possiederà tra due anni?
Se sai rispondere, installa l’app. Costruisci il Flow. Attiva la cosa. Che la risposta sia “in questa app, di proprietà del team ops, e va benissimo così” è una risposta perfettamente valida—il più delle volte è quella giusta. Il pericolo non sono mai state le app. Il pericolo è che la risposta sia un’alzata di spalle.
E a quello tra voi che legge questo con una particolare sensazione di gelo allo stomaco—l’head of digital che ha approvato un’app il trimestre scorso, l’engineer che ha costruito l’undicesimo Flow di venerdì perché era più veloce della riunione che ci sarebbe voluta per farlo come si deve—non sei nei guai. Lo store di tutti ha un po’ di questo dentro. Anche il nostro. Il documento di quaranta pagine non è un verdetto sulla tua competenza; è il sedimento naturale di una piattaforma che rende ogni singola decisione facile e nessuna singola decisione visibile. Non devi tirare fuori tutto questa settimana. Devi smettere di aggiungere alla pila alla cieca. Vai a scoprire dove vive una cosa. Una soltanto. Poi chiediti chi la possiederà tra due anni. La mappa si disegna nello stesso modo in cui si è persa—una decisione alla volta—solo che stavolta c’è qualcuno che tiene la penna.