In che modo le agenzie utilizzano la tecnologia headless per risolvere sfide tecniche e vincere nuovi progetti

Pubblicato: 2023-04-09

L'architettura dei siti web senza testa può sembrare di gran moda, ma come si applica alle sfide tecniche del mondo reale?

In questa tavola rotonda, imparerai di più sui modi in cui le nostre agenzie partner e i loro sviluppatori risolvono problemi tecnici difficili con soluzioni headless.

Guarda il video qui sotto per scoprire quando headless ha senso per sbloccare nuove potenzialità per i tuoi progetti, quando fare affidamento sul classico WordPress e come coinvolgere il tuo team di sviluppo quando adotti nuove tecnologie.

Video: come le agenzie utilizzano la tecnologia headless per risolvere sfide tecniche e aggiudicarsi nuovi progetti

Altoparlanti:

  • Rami Perry, Senior Partner Account Manager presso WP Engine
  • David DiCamillo, Chief Technology Officer di Code & Theory
  • Adam Davey, direttore della tecnologia presso CandySpace
  • Dennis Ngin, vicepresidente, esperienza digitale presso Wpromote
  • Scott Jones, fondatore e CEO di Illustrate Digital

Trascrizione:

RAMI: Ciao a tutti e grazie per esservi uniti a noi per questo panel DE{CODE}. Sono entusiasta di essere raggiunto dai leader, alcune delle nostre principali agenzie strategiche, per approfondire il ruolo che WordPress senza testa svolge per il loro team e i loro clienti. Inizieremo prima con alcune presentazioni in modo che tu possa conoscere i nostri relatori e poi ci tufferemo subito per avere la possibilità di saperne di più su come headless può aiutarti a vincere di più. Dave, vuoi iniziare con un'introduzione?

DAVE DICAMILLO: Certo. Ciao a tutti. Sono Dave Di Camillo. Sono il CTO di Code and Theory. Siamo un'agenzia creativa digital-first. Nel corso degli anni, ci siamo ritagliati e ci siamo fatti un nome realizzando piattaforme editoriali, quindi molto incentrate sui contenuti.

E la nostra prima esperienza, probabilmente, con i headless, risale probabilmente al 2017-2018 circa. Il nostro sito attuale è headless e oggi stiamo lavorando molto con molti clienti. Ed è l'architettura predominante verso cui ci stiamo dirigendo. Ma è bello essere qui e attendo con ansia la discussione.

RAMI: Ehi, Scott. Vuoi presentarti a tutti? Ehi, certo, ciao a tutti. Sono Scott Jones. Sono il CEO e fondatore di Illustrate Digital. Siamo specializzati, principalmente, nella piattaforma WordPress e ci concentriamo molto sulla creazione di esperienze utente coinvolgenti e prive di frustrazioni in tutto ciò che facciamo.

SCOTT JONES: Siamo ancora abbastanza nuovi nel gioco senza testa. Abbiamo svolto ricerca e sviluppo per 12 mesi o più, creato il nostro framework per WordPress senza testa e sì, siamo ancora agli inizi. Entusiasta di continuare a parlarne.

RAMI: Grazie mille, Scott. Adam, vuoi tuffarti subito?

ADAM DAVEY: Sì, fantastico. Il mio nome è Adam. Sono Adam Davey di Candyspace. Sono il direttore della tecnologia lì. Siamo un'agenzia digitale con sede a Londra focalizzata sulla progettazione, realizzazione e ottimizzazione di prodotti digitali.

Sì, abbiamo iniziato il nostro viaggio senza testa un paio di anni fa e parlo costantemente con i clienti sui senza testa. Sono proprio nel bel mezzo di una build senza testa in questo momento. Quindi è un viaggio emozionante e non vedo l'ora di parlarne oggi.

RAMI: Va bene, Dennis, vuoi concludere con le introduzioni?

DENNIS: Ciao a tutti. Mi chiamo Dennis. Sono il vicepresidente di Digital Experience per Wpromote. Siamo un'agenzia di performance marketing, che guida la crescita dei nostri marchi sfidanti. Il mio team ha iniziato il percorso dei senza testa nel 2019. Lo fanno da allora. In realtà abbiamo adottato il prodotto WP Engine Atlas lo scorso anno e abbiamo lanciato con successo un sito senza testa entro due mesi. Quindi sono super entusiasta di condividere la nostra storia.

RAMI: Grazie a tutti per esservi uniti a noi. Quindi siamo qui con un pubblico che probabilmente avrà un background e un'esperienza abbastanza vari con i senza testa, alcune persone che stanno appena iniziando il viaggio, alcuni che sono stati operai per quanto riguarda i senza testa.

Quindi quello di cui mi piacerebbe sapere qualcosa in più è quando, in ciascuna delle tue carriere professionali o presso la tua agenzia, è stato come, OK, è il momento, questa è l'opportunità o è il punto di svolta in cui è senza testa qualcosa a cui il nostro team deve appoggiarsi? Quindi qual è stato quel punto di rottura che ti ha fatto saltare dentro? Se vuoi entrare per primo, Dave?

DAVE DICAMILLO: Certo. L'abbiamo adottato molto presto e ti prometto che è stato perché era bello ed era su tutti i blog e tutti volevano farlo ed è probabilmente per questo che abbiamo iniziato. Ma le applicazioni pratiche hanno davvero iniziato ad arrivare con molti dei nostri clienti che avevano MarTech esistente o piattaforme di riproduzione video esistenti o altri software da cui non volevano separarsi, e hanno detto, guarda, siamo felici di fare questo nuovo headless approccio.

Abbiamo sentito molte cose positive su come possiamo gestire meglio i dati, come possiamo essere più flessibili, dal punto di vista dell'interfaccia utente, come possiamo integrare nuovi prodotti di terze parti, in futuro, più facilmente.

E penso che probabilmente abbiamo iniziato a commercializzare davvero le versioni per i nostri clienti da qualche parte nel 2019 ed è stata, ancora una volta, l'architettura dominante con cui guidiamo, con molti dei nostri clienti. Ma sì, siamo molto eccitati. Stiamo effettuando una serie di installazioni di WP Engine Atlas. Ne abbiamo uno in arrivo, anche tra un paio di settimane, il che è fantastico. Ma sì, questo è il nostro viaggio iniziale con i senza testa.

RAMI: Quindi Adam, hai detto che ci sei all'apice. Adoro la tua opinione, dal momento che potrebbe essere un po' più recente, di ciò che sta iniziando a mandarti in quella direzione.

ADAM DAVEY: Beh, con quel particolare cliente, avevano già– spesso è una decisione complessa, non è vero, quale tecnologia CMS utilizzerai. Ma questo particolare cliente in realtà aveva un'idea precisa di come impostare e configurare il CMS e come gestire i propri contenuti. Quindi era insolito. Non avevamo davvero bisogno di portarli in quel viaggio. Hanno deciso per un CMS senza testa e hanno deciso un modo per servire quel contenuto sul front-end, attraverso più canali.

Ma molto spesso non è così. Quello era un cliente tecnicamente astuto. Ma molto spesso dobbiamo – allo stesso modo, dobbiamo accompagnare le persone in un viaggio e direi – stiamo anche costruendo un altro sito, al momento, in cui il cliente desidera che un editor WYSIWYG sia in grado di gestire i propri contenuti. Quindi si tratta davvero di caso d'uso.

E senza testa risolve molti problemi e può inserirsi, come hai detto tu, David, inserirsi negli stack esistenti. Ma non esiste una taglia unica. Si tratta di avere una conversazione sfumata e dettagliata con un cliente sui requisiti e diversi clienti si trovano in diverse fasi della loro curva di maturità con il digitale e con headless e con CMS ovviamente. Quindi si tratta di incontrarli, dove sono, in quel viaggio, davvero.

RAMI: Sì, Scott o Dennis, qualche pensiero da aggiungere per quanto riguarda cosa– qualche indicatore di quando potrebbe essere il momento per le persone che stanno per adottare senza testa, che avete visto nel viaggio di tutti voi?

SCOTT JONES: Sì, penso che per noi sia stato simile a quello che ha detto Dave, davvero. Era che ne stavamo leggendo. Era qualcosa che era là fuori. Le persone sembravano farlo e lottare con esso. E in realtà, il nostro primo progetto senza testa era un progetto di salvataggio ed è stato un incubo, onestamente. Onestamente, è stato un incubo.

Un cliente è venuto da noi con un'implementazione senza testa davvero pessima, alcune scelte tecnologiche molto discutibili. Ogni pagina ha impiegato circa... beh, almeno 30 secondi per caricarsi, il che è strabiliante e quella è stata la nostra prima incursione in headless ed è stato disordinato, per non dire altro.

Qual è stata la sfida per noi, nel corso di un certo numero di anni guardando senza testa, è stata effettivamente costruire l'esperienza interna attorno a JavaScript, essenzialmente e quella sfida, penso, è stata spinta e aiutata dal tipo di ricostruzione di WordPress in una piattaforma basata sulla reazione. E penso che questo ci abbia davvero portato in un viaggio.

Quindi in realtà è venuto di pari passo, abbastanza bene per noi, con l'apporto di tale esperienza, la creazione di una migliore comprensione con i nostri sviluppatori e poi ulteriormente in quel viaggio in ciò che effettivamente offriamo anche ai nostri clienti.

DENNIS: Sì, per il nostro team, il driver sono davvero i nostri ingegneri e i nostri sviluppatori e stanno facendo una retrospettiva su come continuiamo a migliorare la nostra agenzia, come continuiamo a migliorare il nostro processo, sono irremovibili riguardo ai senza testa. Per me, l'analogia stava pensando a mio padre, che è un meccanico, che lavora sulle auto cinque giorni alla settimana, otto ore al giorno. Quando lo fai per 10 anni, 20 anni, impari davvero su quali marchi di automobili, su quali motori ti piace lavorare. Questa analogia è la stessa per me, per i nostri ingegneri e hanno visto senza testa un'opportunità per essere più efficienti nel lavoro e per ottenere una consegna migliore.

Quindi per noi, è stato guidato dagli ingegneri come un modo per sfidare ed essere innovativi. Abbiamo iniziato a identificare i clienti che pensavamo sarebbero stati adatti. Abbiamo presentato le opzioni a quei clienti e detto, hai la possibilità di andare senza testa, dove pensiamo che ci sia un miglioramento nel modo in cui sviluppiamo il tuo sito web, rispetto al tradizionale e quando i clienti hanno iniziato a salire a bordo, abbiamo iniziato quel viaggio alla fine del 2019 e non l'abbiamo fatto guardato indietro da allora.

RAMI: Grazie, signori. Quindi tutti conosciamo e amiamo WordPress. Ecco perché siamo qui. Giusto? Ma conosciamo anche tutti molto bene alcune limitazioni lì e, ovviamente, headless è un modo per mantenere la familiarità e l'affidabilità del back-end di WordPress per i nostri creatori di contenuti e i nostri esperti di marketing, ma anche essere in grado di affrontare alcune di quelle limitazioni che WordPress presenta .

Quindi, se qualcuno avesse un caso d'uso particolare o anche un progetto cliente specifico in cui l'hai trovato OK, non possiamo abbandonare WordPress a causa delle esigenze e dei requisiti del cliente, per quanto riguarda la gestione dei contenuti, ma siamo avrà bisogno di andare senza testa perché ci sono alcune limitazioni? Mi piacerebbe solo qualche esempio di vita reale che dia ispirazione alle persone quando pensano ai loro potenziali progetti, lungo la pipeline.

DAVE DICAMILLO: Certo, posso iniziare, se vuoi.

RAMI: Grazie, Dave.

DAVE DICAMILLO: Quindi quello che è dietro l'angolo per noi, il progetto Atlas che sta arrivando, sono un DMP. Quindi sono un provider basato su SAS. Sono su WordPress da anni. Tuttavia, vogliono integrare molto con il proprio software. Quindi l'architettura stessa doveva riflettere davvero sia il loro desiderio di essere ancora operativi con WordPress, sia di essere in grado di pubblicare in modo efficace (non vogliono riqualificare il team), ma volevano anche integrazioni più profonde nei propri prodotti e oltre.

Quindi siamo stati anche in grado di aiutarli a espandere ciò che possono fare con i contenuti del loro sito. Quindi erano piuttosto nascenti in ciò che erano in grado di fare prima della riprogettazione che sta arrivando. Ma l'utilizzo, anche, di Atlas Content Modeler e la possibilità di fornire loro un modello di contenuto più profondo e robusto su cui pubblicare, fornire una personalizzazione più profonda, fornire quella capacità di parlare con i propri clienti in un modo più one-to-one è sarà un vero punto di svolta per loro.

Quindi WordPress era un requisito fermo e dati alcuni di quegli obiettivi del progetto, aveva perfettamente senso che Atlas fosse l'applicazione. Quindi, si spera, questo aiuta.

RAMI: Dennis.

DENNIS: Sì, per uno dei nostri clienti, l'anno scorso, abbiamo fatto questa analisi di una serie di piattaforme diverse, piattaforme headless native, WordPress con WP Engine, e abbiamo davvero valutato due fattori. Il numero uno saranno le caratteristiche e le funzionalità di cui il cliente aveva bisogno dalla piattaforma. Quindi il numero due, è davvero il costo totale di proprietà per la piattaforma.

Abbiamo svolto questa analisi approfondita e alla fine siamo approdati a WordPress con WP Engine e Atlas come soluzione dal punto di vista dei costi e della flessibilità della piattaforma e, in realtà, della familiarità con i team di marketing e adottando un approccio basato sui componenti al nostro sviluppo processo, siamo stati in grado di creare in modo efficace un sito Web che consentisse all'utente aziendale che ha già familiarità con WordPress, abbiamo già sfruttato la potenza di quella piattaforma, ma essere in grado di distribuire componenti all'interno della loro pagina Web in modo che, mentre stanno costruendo nuovi pagine di destinazione o nuove esperienze sul loro sito, non devono necessariamente affidarsi a uno sviluppatore per implementare quelle nuove pagine di destinazione.

E abbiamo visto un enorme miglioramento nella loro velocità di consegna da allora in poi, da quello. Quindi è stato un progetto molto interessante, nel senso che abbiamo passato molto tempo a fare questa analisi iniziale. E poi non appena l'analisi è stata fatta, è un momento molto rapido per il mercato e i nostri clienti sono stati molto, molto contenti dei risultati.

RAMI: Ci piace sentirlo. Scott, Adam, qualche idea da aggiungere su questo?

ADAM DAVEY: Sì, al contrario, questa è una leggera deviazione. Ma di recente abbiamo visto un cliente allontanarsi da headless, off, non con Atlas, ovviamente, ma su una piattaforma diversa. Non menzionerò quella piattaforma. Ma hanno passato un brutto momento perché non erano in grado di gestire i loro contenuti in modo efficace. Sono tornati a Gutenberg, il che è davvero… non vogliamo che accada.

Ma penso che ciò che non vogliamo fare sia forzare la decapitazione su persone che non sono pronte per questo. Ed è un salto per i team di marketing, penso e non è giusto per tutti. Ma sblocca anche un intero carico di potenti funzionalità se gestisci contenuti, multicanale su larga scala. È qui che la modellazione senza testa e dei contenuti può davvero sbloccare molte opportunità per te. Sì.

Ma non vogliamo vedere le persone spaventate dai senza testa e vogliamo suggerire soluzioni adatte a loro. Ma ho visto molti vantaggi del senza testa, dipende tutto dal caso d'uso e dalla migliore vestibilità.

RAMI: E sollevi un grande punto, della responsabilità verso il tuo cliente prima, non guidare troppo con la tecnologia, per guidare con ciò che è meglio per il tuo cliente ed è quello che stiamo vedendo– è un punto di svolta interessante per l'adozione senza testa, intorno a ciò che è effettivamente giusto per il cliente rispetto a ciò che è la nuova, brillante, brillante tecnologia. Scott, niente da aggiungere, esempi che hai visto?

SCOTT JONES: Vorrei solo aggiungere, e dire, penso che stiamo tutti annuendo quando ci sono commenti su headless implementati male in passato e quel genere di cose e penso che questo sia il punto importante, davvero, è fare proprio dal tuo cliente. Questo è quello che direi su questo, è, se non sei pronto, non farlo.

Quindi c'è sempre un po' di– devi metterti in gioco e provarci se non l'hai mai fatto prima. Ma in realtà, WP Engine e il progetto Atlas hanno molti strumenti, molte risorse per essere in grado di aiutare, per intraprendere quel viaggio. Penso che quando abbiamo iniziato tutti questo viaggio con headless, quegli strumenti non esistessero e stavamo tutti costruendo cose come le anteprime dei post da zero, molto probabilmente, per la maggior parte di noi, e dovevamo fare cose che non erano in un piattaforma, come ha fatto ora senza testa.

Quindi sì, penso che direi, fatti coinvolgere nel progetto di WP Engine e provaci. Ma sicuramente, torna sempre indietro per fare la cosa giusta dal tuo cliente e non essere uno di quei fattorini che non consegnano, per così dire, e finisce per invertire di nuovo il processo di nuovo a Gutenberg.

RAMI: Grazie, signori. Penso che abbiamo coperto, in modo davvero approfondito, i vantaggi per il cliente del motivo per cui potresti consigliare l'architettura Atlas. Mi interessa sapere quali sono i vantaggi per il tuo team interno, per il tuo team di sviluppo, per i tuoi project manager, per il tuo team di controllo qualità? Dove hai visto, assumendo questo ruolo di leadership nell'adozione senza testa, visto salire l'acqua per i tuoi team interni?

DAVE DICAMILLO: Adam, puoi iniziare però.

ADAM DAVEY: Credo fermamente nell'assicurarmi che tutti abbiano il consenso. Adoro quello che hai detto, David, sul giocare con cose luccicanti ed è quello che voglio dare agli sviluppatori gli strumenti con cui possono fare il loro lavoro migliore. Ma è anche molto importante che il buy-in arrivi a tutti i livelli del business. Quindi sì, i gestori dei contenuti sono felici, ma anche le parti interessate sono felici a tutti i livelli.

L'ho visto dove i prodotti sono stati venduti e non è stato del tutto corretto. Ci deve essere un consenso completo e un consenso completo. Devi portare tutti con te in quel viaggio intorno alle decisioni tecnologiche.

E sì, per me, ancora una volta, si tratta di un equilibrio e si tratta di prendere le decisioni giuste per le giuste ragioni per l'azienda e il cliente perché spesso, gran parte del processo decisionale in giro senza testa è che siamo in grado di offrire un super- un'esperienza veloce con un front-end davvero bello, pulito, ricco e intuitivo, e ottiene punteggi Lighthouse davvero belli e tutte quelle cose buone, e con cui gli sviluppatori adorano lavorare. Quindi è un completo– è un mix. Ottenere tutti quegli ingredienti giusti è davvero importante.

DAVE DICAMILLO: Ti dirò chi ama gli headless nel nostro negozio, sono i nostri designer, che si sentono molto meno limitati. Anche i nostri ingegneri di reazione lo adorano. Stanno solo impazzendo per cosa possiamo fare e quanto velocemente possiamo fare questo e tutto il resto, tutto quello che stai dicendo, Adam. Ma penso che la reale capacità per noi di estendere parte della creatività al di là di quello che sarebbe un normale sito di pubblicazione, un normale sito basato sui contenuti, penso, sia stata molto illuminante per alcuni membri del nostro team, anche appena oltre la gente della tecnologia.

Dirò anche che dal punto di vista tecnologico, aumenta decisamente il tempo per fornire alcune capacità. I test, per noi, sono aumentati, il che non è un male. È la cosa giusta da fare per il prodotto giusto, alla fine della giornata. Ma abbiamo visto un aumento dal 15% al ​​20% solo nell'ultima rifinitura prima di andare in diretta, assicurandoci che tutte le connessioni siano bloccate.

DENNIS: Sì, penso–

RAMI: Questo è un buon consiglio. Questa è una buona intuizione, quando stai guardando la stima, e sei all'inizio dei tuoi primi progetti, assicurati di prenderlo in considerazione, ehi, quell'ultimo 20%, il QA, il lancio e tutto, sappi che potrebbe volerci un po' di più quando inizi a far decollare i tuoi primi due progetti. Mi dispiace, Dennis. Andare avanti.

DENNIS: No, volevo solo basarmi su quello. Per quanto riguarda le operazioni del nostro team Digital Experience o del team di sviluppo, mi vengono in mente alcune cose. Ha davvero iniziato a fare progressi nell'anno numero due, verso la fine dell'anno numero due, nel nostro viaggio senza testa.

E così guardando oggettivamente le prestazioni della loro squadra, abbiamo effettivamente visto diminuire il tasso di difetti. Quindi, disaccoppiando il front-end dal back-end, i nostri bug e problemi derivanti dall'implementazione del codice sul back-end non hanno influito sul front-end e, nel complesso, stiamo implementando un codice più pulito e migliore, il che è fantastico da vedere.

Per quanto riguarda David, il time-to-market è stato significativamente più rapido rispetto al passato, ancora una volta, grazie a quell'architettura di disaccoppiamento. Quindi, quando un cliente aveva bisogno di una piccola modifica in un front-end, non dovevamo programmarlo con un aggiornamento back-end per l'occupazione. Tutto si stava muovendo più velocemente lì.

E poi ciò che è stato anche interessante per noi, mentre ripensiamo agli ultimi due anni, è cambiato il modo in cui pensiamo alle risorse del nostro team. Quindi, prima, avevo davvero bisogno di qualcuno che conoscesse WordPress e sapesse programmare sul front-end. E abbiamo a che fare anche con molti clienti di e-commerce e conosciamo la piattaforma di e-commerce.

Ma ora sono in grado di assumere un ingegnere front-end puro, reattivo che non ha alcuna comprensione del back-end e renderlo produttivo nel giro di poche settimane, mentre in passato avevamo bisogno di sviluppare una certa competenza per il back-end -fine piattaforma. Quindi è stato davvero, davvero bello da vedere, come operatore, per il nostro team.

RAMI: E tu, Scott? Qualche idea su questo?

SCOTT JONES: Sì, sto pensando: ho parlato con diversi fondatori di agenzie sul loro approccio a headless e, in qualche modo, sono stati simili al nostro, che in realtà, come fondatore dell'agenzia, volevo fare headless e non era necessariamente il resto della squadra che era ancora pronto o impegnato a intraprendere quel viaggio.

E parlando del punto di Adam, davvero, per noi, è stato un viaggio di cultura e di scopo e capire il nostro perché, come azienda. E so che potrebbe sembrare davvero un cliché. Ma questo è stato davvero importante. Se il nostro team, in particolare i nostri sviluppatori, comprende il perché della nostra attività, man mano che procediamo, e comprende cosa stiamo effettivamente cercando di risolvere per il cliente, cosa stiamo effettivamente cercando di offrire: vogliamo il più coinvolgente, il più esperienze prive di frustrazione che possiamo eventualmente offrire–

Come lo facciamo e in che modo la tecnologia gioca un ruolo in quella conversazione davvero interessante e questa è stata la cosa che li ha portati nel viaggio perché sì, avevamo delle braccia ben conserte e facce scontrose quando abbiamo iniziato a parlare circa senza testa. E sono sicuro che probabilmente anche voi vi siete trovati in quella situazione e ci siamo assicurati che avessimo quelle conversazioni, assicurandoci che capissero il perché, che in realtà ha cambiato molto quella dinamica per noi.

RAMI: Quindi, rimanendo sul tema della velocità e dell'efficienza e di tutte quelle parole sexy e divertenti, che in realtà sono super importanti nello spazio dell'agenzia, hai un momento aha che puoi condividere, sia che si trattasse di un certo pezzo di tecnologia, forse è stato un certo cambiamento nel tuo processo, forse è stato solo usando, letteralmente, un vocabolario diverso, che hai detto, oh, cavolo, se l'avessi saputo due anni fa, saremmo stati più redditizi, avremmo lavorato più velocemente, le persone sarebbero state più felici?

Quindi forse potresti condividere, con la gente, un aneddoto che potresti condividere con persone che sono un po 'precoci nel loro viaggio di adozione senza testa. Non sto chiedendo segreti commerciali, solo un momento luminoso, forse.

SCOTT JONES: Ritornerò sul punto, se va bene. Per me– e ho un ruolo più rivolto al cliente che a un ruolo tecnico e quindi penso sempre al business case e a come costruire un business case e ovviamente ci penso esternamente. Quello che non stavo necessariamente facendo era pensarci internamente e riportare lo stesso business case ai nostri sviluppatori, ai nostri designer, project manager, al nostro team.

Una volta che hanno iniziato a vedere alcuni dei motivi per cui i clienti avrebbero bisogno di headless, ad esempio la possibilità di archiviare le mappe in modo nativo su un dispositivo mobile. Potresti essere a metà di una montagna. Hai bisogno di quella mappa memorizzata in modo nativo. Non sarai davvero in grado di farlo con monolitico, immagino, senza testa e, scusa - WordPress - e mostrando alcuni di quei casi d'uso.

Penso che fossero il ... capisco perché un cliente lo vorrebbe, capisco perché un cliente vorrebbe effettivamente servire una base di contenuti a due diversi front-end. In realtà mostrare loro alcune di queste è stata la roba aha, per noi, insieme alle cose culturali.

RAMI: E tu, Adam?

ADAM DAVEY: Sì, appena entrati, immagino che uno dei miei aha fosse: lavoriamo con tutti i tipi di clienti, con tutti i tipi di esigenze aziendali complesse. Ma ciò su cui spesso i clienti si appoggiano è una soluzione che apparentemente fa tutto per loro, come una suite all-in-one, che spesso può essere davvero, davvero potente per loro. Ma quel coltellino svizzero, probabilmente finiscono per usare solo una o due lame dell'intero kit ed è quello che vediamo.

Quindi il momento aha, per me, è che i clienti ora stanno pensando di acquistare una parte di uno stack che fa qualcosa davvero, davvero bene, ed è il migliore per fare quell'unica cosa davvero bene, e poi semplicemente stratificare il tuo stack con ugualmente– con altri componenti che fanno davvero bene il loro lavoro.

Quindi l'aha, per me, è, immagino, assistere ai clienti, negli ultimi anni, e in realtà, il perno, lo spostamento verso l'acquisto di ciò di cui hai bisogno, qualcosa che è il migliore della categoria, che offre davvero bene ciò che dovrebbe Fare.

Come ho detto, le suite e le DXP hanno il loro posto. Ma stiamo vedendo sempre più senza testa essere inseriti come parte di un più ampio ecosistema di tecnologie che fa, davvero, un lavoro in modo eccellente. Penso che siano stati gli ultimi due anni. Questo è il cambiamento che abbiamo visto.

DAVE DICAMILLO: Sì, sono d'accordo e penso che l'esplosione degli strumenti MarTech, e la possibilità di prendere il meglio della classe e integrarlo, non solo ora, ma nel futuro, sia davvero la ragione per scegliere headless.

Quelle DXP, sì, sono fantastiche. Ma hai ragione. La maggior parte dei nostri clienti utilizza il 10%, il 20% di ciò per cui sta pagando e non ottiene il valore che, se lavorasse effettivamente con questi fornitori MarTech più piccoli, otterrebbe effettivamente il supporto di cui ha bisogno. Possono effettivamente utilizzare meglio le funzionalità. Ma sì, una cosa su cui cerchiamo di istruire molti dei nostri clienti è che non si tratta di vivere con i senza testa. Si tratta di guardare al futuro di ciò che vuoi fare nei primi 12 mesi.

Quando si lancia un sito headless, almeno nel nostro mondo, si tratta più dello stack MarTech che stiamo mettendo in gioco che del semplice CMS. Stiamo cercando di abilitare alcune funzionalità diverse, personalizzazione, strumenti ABM, lo chiami. Tutta quella roba entra in gioco.

E vogliamo eliminare i clienti per arrivare a un punto in cui sono pronti per il lancio, e poi guarda, come sono i primi 12 mesi? Continueranno a crescere. Ci piace dire che il primo giorno del sito web è il giorno peggiore. Sei lì per prendere il sito web e farlo crescere da quel punto e se stai pensando a lungo termine, pensando a come sarà il primo punto di lancio, più 12 mesi, penso che questo rafforzi davvero un buon caso per headless, specialmente quando tu non sono legati alla DXP, come dice Adam.

RAMI: Qualche idea su questo, Dennis?

DENNIS: Penso che il momento aha, per noi, sia stato quando abbiamo effettivamente visto migliorare le prestazioni organiche, tre o quattro mesi dopo il lancio del sito headless. E fu allora che iniziai a promuoverlo. Questo sta realmente accadendo e questo fa parte del motivo per cui stiamo facendo quello che stiamo facendo e vedere che il gioco è stato piuttosto potente per noi, come gruppo.

Ed è per questo che penso, come David, che la maggior parte delle nostre bollette, a questo punto, ora, siano senza testa perché dal punto di vista di un'agenzia di performance marketing, il nostro compito è posizionare il sito Web in modo che sia uno strumento per il nostro marketing partner all'interno dell'agenzia e costruendo loro un sito web che possa formarsi, facilita il loro lavoro.

RAMI: Quindi abbiamo parlato molto del buy-in, interno, e dei motivi per cui, ovviamente, i tuoi team interni sono entusiasti di lavorare su headless. Domanda per tutti voi che siete effettivamente coinvolti in quella fase iniziale, di proposta, di presentazione delle vendite con potenziali clienti e clienti attuali.

Qual è la pallottola magica che attira la loro attenzione? È la prestazione? È la flessibilità? Solo un po 'di coaching, per altre persone, che si uniscono a noi, che stanno avviando o lanciando sbocchi, cosa vedi che, davvero, i tuoi clienti o potenziali clienti si stanno aggrappando e li spingono davvero oltre il limite?

Perché sappiamo che l'adozione di nuove tecnologie, soprattutto per un'azienda tradizionale, fa paura. Sono avversi al rischio. Il passaggio può essere molto costoso. Allora cosa trovi che i responsabili delle decisioni, quando proponi un'architettura senza testa, stiano davvero attirando la loro attenzione?

ADAM DAVEY: Sì, posso saltare qui se necessario. L'unica cosa che usiamo, più e più volte, sono demo di prodotti reali perché senza mostrare ai clienti cosa stanno acquistando e come funzionano quelle piattaforme, è inutile. Sono solo parole. Quindi dobbiamo effettivamente dimostrare in modo tangibile come funziona senza testa.

E c'è paura intorno a questo. Quindi quello che dobbiamo fare è rispondere a tutte le domande, mostrare i casi d'uso, spiegare come il contenuto è modellato e gestito e come funzionano effettivamente quelle approvazioni del flusso di lavoro, o qualsiasi altra caratteristica che stiamo utilizzando all'interno del CMS. Niente batte una demo perché altrimenti è semplicemente troppo astratto. Dobbiamo effettivamente mostrare, dimostrare, quali sono le capacità e la potenza della piattaforma. Quindi direi che è lo strumento più potente che abbiamo nella manica.

DAVE DICAMILLO: Sì, me ne occuperò. Ma la domanda numero uno che riceviamo è, qual è il giorno della vita? E questa è una domanda CMS in generale. Ogni volta che qualcuno passa a una nuova piattaforma, è come sarà la mia vita?

Trascorriamo molto tempo, nel processo di lancio, in realtà educando, solo ad alto livello, cosa significano queste diverse architetture? Pro, contro, quali sono i diversi giocatori nello spazio, tutto quel genere di cose. Ma non prendiamo mai una decisione in campo. Si tratta sempre di mettersi sotto il cofano, con il cliente, fino al punto di Adam, fare demo, coinvolgere i partner, fargli presentare le proprie merci.

Una cosa è dire, oh, ce l'ha detto l'agenzia. Ma è un'altra cosa avere i produttori di software e la gente venire al tavolo e dire, beh, ecco perché siamo i migliori.

Abbiamo un processo decisionale molto lungo attraverso il quale istruiamo i nostri clienti, che si basa su criteri aziendali chiave e vogliamo creare CMS che siano i migliori nelle loro classi, headless o accoppiati, e farli risaltare, beh, cosa significa questo per la tua attività? Influirà davvero?

Ecco un punteggio grezzo. Non limitarti a seguire i consigli di Code and Theory. Ecco un output in un numero che dice qual è il migliore per la tua attività e quindi prendi una decisione informata su quale strada vuoi prendere.

DENNIS: Per noi, quando iniziamo una conversazione sul fatto che headless sia o meno l'opzione giusta per il nostro cliente, essere in grado di richiamare uno dei nostri siti Web che abbiamo creato, e di fronte al cliente, dal vivo, eseguire un punteggio Lighthouse, su quel sito Web e mostrare loro il punteggio. Va bene subito, dimmi di più e poi seguiamo questa strada di, qual è il nostro stock tecnologico o altro.

Ma per noi, questo è sempre stato il più grande spunto di conversazione in qualsiasi opportunità di vendita, è mostrare loro cosa è possibile e quando ottieni punteggi verdi su Lighthouse, che è quasi impossibile su queste altre piattaforme a causa di un'architettura accoppiata, è davvero è una storia potente da raccontare.

SCOTT JONES: Sì, sono d'accordo. Sono d'accordo con tutte queste risposte. Penso che per noi, sembra che stiamo vendendo un po 'FOMO, davvero, quella paura di perdere l'approccio e quindi, a parte gli ovvi vantaggi in termini di prestazioni e sicurezza, non so se è lo stesso per voi ragazzi, ma abbiamo notato che in realtà, eseguendo un audit sulla nostra base di clienti, ci siamo resi conto che i nostri migliori clienti sono in realtà piuttosto forti sulla tecnologia e abbastanza forti sull'esperienza dell'utente. Hanno sviluppatori interni o team UX interni o qualunque cosa assomigli. In realtà capiscono.

E così hanno fatto loro stessi un po' di ricerca su questo. Ne capiscono un po'. Hanno già l'ovvio. La cosa che tende a mancare nella mentalità è in realtà vendere il futuro e pensare, dal punto di vista dello sviluppo, a tutti gli sviluppatori, programmatori, che stanno andando nei campi di addestramento ora - sto generalizzando, qui - ma sono imparando JavaScript e quindi se stai ancora lavorando nel corso della giornata o come stiamo facendo ora, non stai pensando a dove andrà il mercato in futuro.

And I think we've all seen– JavaScript developers have been quite expensive, reactive developers, in particular. They've been very in demand. That's going to change because every new developer is learning this technology and this progressive set of frameworks.

That is the important thing in a business case, that actually are pointing forward, to particularly, the technology-minded companies, that this is a consideration for you. If you build something now, what's your development team going to look like in three, four, five years? What's our team going to look like in that time?

If you went to another agency and didn't work with us, what would that team look like? how much would you struggle to get the resource you need, based on what we've built? And so yeah, I'm looking forward and trying to switch the mindset a little bit there.

RAMI: Scott, you took my last question–

SCOTT JONES: Oh, sorry.

RAMI: –right away for me, which is– it's OK. It's all good. I would imagine folks that attended– I know my first DE{CODE], and folks that, this is their third, fourth, fifth year they're joining us, I think that the weight that headless WordPress and Atlas is carried in our agenda has continued to increase and grow. Three years ago, I don't know that we had a full track developed to it and now we do.

So as we wrap up, what I would love, just to get your magic. If you're looking in the crystal ball and looking ahead, as you are future proofing what your headless WordPress practice looks like, what's on your radar right now? Maybe you're not spending a lot of time on it. But what's in the back of your head, that this is something that's coming down the pipe, that we've got to be prepared for, regarding headless architecture? I'll start with you, Dennis. First one up.

DENNIS: Oh, goodness. The pressure's on. So as you think about the future– and I have a lot of these conversations internally, with our team– I think a world of low code, no code is very real, and especially as a traditional systems integrator and SI team that historically done backend integrations. So as we think about that, and we think about how the composition of the team will evolve, absolutely, design is a core competency. Strategy is a core competency.

And then in front-end development or with ArcGIS development, I think, is going to become a core competency and we're already seeing this shift from heavy back-end to heavy front-end, heavy-strategy team members as well. So we're positioning our team that way. We think that's going to be the future. And we're going to scale and adjust as things evolve.

RAMI: What do you think, Adam?

ADAM DAVEY: For me, I think composable is the way forward. That that's where it's at and the ability for all these different components to integrate with each other and the interoperability of these different platforms is really important. So I think that that ability to communicate and offer best-in-class, best-in-breed solution with a stack like that, that's going to– these platforms are only going to be more and more powerful in that sense.

So the ability for these things to integrate together cleanly and for freeing up developers to, as you were saying, Dave and Dennis, just really do their best work and for the designers to do their best work, for me, it's all about composable, I think, particularly with headless CMS, is how they pair nicely and play nicely with that, as you said, David, the MarTech stack, but particularly e-commerce.

That's where we're seeing most of the opportunity at the moment and the biggest conversations that we have are really around headless commerce solutions, coupled with headless CMS solutions and I think that ability to integrate and couple those systems together is going to be really, really key.

DAVE DICAMILLO: Yeah, you took the one that I was going to say, as well. Composable web is– new technologies spur new innovations and composable web's the thing that's being built on top of the headless world, which is, how do I orchestrate everything? How do I make this all easy for my team to use?

I have seven different pieces of MarTech and it's all over the place. But the data sets can all be integrated. And they can all be used in one tool. It's actually the number-one thing we've seen come back from clients, six months, a year after. Hey, we love it. È ottimo. But we need to be more efficient and what are the tools out there, the stack bits of the world and everything else, that's coming around?

And it's doing– it's the next level of headless integrations. So I totally agree that that's where this is going, not downplaying anything with low-code, no-code. We're seeing all that stuff too. But, yeah.

RAMI: Gentleman, thank you so much for being so gracious and sharing so much with us. This has been super valuable. I know I learned a lot and I think this is a great foundation for our partners and developers out there, that are just now stepping into headless, as well as those that have been on a similar headless journey as your four agencies and are three, four years in.

I appreciate everybody joining us today and I hope you enjoy the rest of your time at DE{CODE}. Have a good one.