Cómo las agencias usan tecnología sin cabeza para resolver desafíos técnicos y ganar nuevos proyectos

Publicado: 2023-04-09

La arquitectura de sitios web sin cabeza puede parecer que está de moda, pero ¿cómo se aplica a los desafíos técnicos del mundo real?

En este panel de discusión, aprenderá más sobre las formas en que nuestras agencias asociadas y sus desarrolladores resuelven problemas técnicos difíciles con soluciones sin cabeza.

Mire el video a continuación para averiguar cuándo tiene sentido usar headless para desbloquear un nuevo potencial para sus proyectos, cuándo confiar en el clásico WordPress y cómo hacer que su equipo de desarrollo se sume a la adopción de nuevas tecnologías.

Video: Cómo las agencias usan la tecnología autónoma para resolver desafíos técnicos y ganar nuevos proyectos

Altavoces:

  • Rami Perry, gerente de cuentas de socios sénior en WP Engine
  • David DiCamillo, director de tecnología de Code & Theory
  • Adam Davey, director de tecnología en CandySpace
  • Dennis Ngin, vicepresidente de experiencia digital en Wpromote
  • Scott Jones, fundador y director ejecutivo de Illustrate Digital

Transcripción:

RAMI: Hola a todos y gracias por acompañarnos en este panel DE{CODE}. Estoy emocionado de que me acompañen líderes, algunas de nuestras principales agencias estratégicas, para profundizar en el papel que desempeña WordPress sin cabeza para su equipo y sus clientes. Comenzaremos primero con algunas presentaciones para que pueda conocer a nuestros panelistas y luego nos sumergiremos de lleno para tener la oportunidad de aprender más sobre cómo headless puede ayudarlo a ganar más. Dave, ¿te gustaría comenzar con una presentación?

DAVE DICAMILLO: Claro. Hola a todos. Soy Dave DiCamillo. Soy el CTO de Código y Teoría. Somos una agencia creativa digital primero. A lo largo de los años, cortamos y nos hicimos un nombre haciendo plataformas de publicación, muy enfocadas en el contenido.

Y nuestra primera experiencia, probablemente, sin cabeza, probablemente fue alrededor de 2017-2018. Nuestro sitio actual no tiene cabeza y estamos trabajando mucho hoy con muchos clientes. Y es la arquitectura predominante hacia la que nos dirigimos. Pero es bueno estar aquí y espero con ansias la discusión.

RAMI: Hola, Scott. ¿Quieres presentarte a todos? Oye, seguro. Hola a todos. Soy Scott Jones. Soy el CEO y fundador de Illustrate Digital. Nos especializamos, principalmente, en la plataforma de WordPress, y tenemos un enfoque realmente fuerte en la creación de experiencias de usuario atractivas y libres de frustraciones en todo lo que hacemos.

SCOTT JONES: Todavía somos bastante nuevos en el juego sin cabeza. Hemos estado investigando y desarrollando durante 12 meses o más, construimos nuestro propio marco para WordPress sin cabeza y sí, todavía estamos en los primeros días de eso. Emocionado de seguir hablando de ello.

RAMI: Muchas gracias, Scott. Adam, ¿quieres entrar directamente?

ADAM DAVEY: Sí, genial. Mi nombre es Adam. Soy Adam Davey de Candyspace. Soy el director de tecnología allí. Somos una agencia digital con sede en Londres enfocada en diseñar, construir y optimizar productos digitales.

Sí, comenzamos nuestro viaje sin cabeza hace un par de años y estoy constantemente teniendo conversaciones con clientes sobre sin cabeza. Estoy justo en medio de una construcción sin cabeza en este momento. Así que es un viaje emocionante y estoy deseando hablar hoy sobre él.

RAMI: Muy bien, Dennis, ¿quieres terminar con introducciones?

DENNIS: Hola a todos. Mi nombre es Denis. Soy el vicepresidente de Experiencia Digital de Wpromote. Somos una agencia de marketing de rendimiento que impulsa el crecimiento de nuestras marcas desafiantes. Mi equipo comenzó por el camino de los decapitados en 2019. Lo han estado haciendo desde entonces. De hecho, adoptamos el producto WP Engine Atlas el año pasado y lanzamos con éxito un sitio sin cabeza en dos meses. Así que estoy muy emocionada de compartir nuestra historia.

RAMI: Gracias a todos por acompañarnos. Así que estamos aquí con una audiencia que probablemente tendrá antecedentes y experiencia bastante variados con headless, algunas personas que recién están comenzando el viaje, algunas que han sido jornaleros en lo que respecta a headless.

Entonces, me encantaría escuchar un poco más sobre cuándo, en cada una de sus carreras profesionales o en su agencia, fue como, OK, es hora, esta es la oportunidad o es el punto de inflexión donde está headless algo en lo que nuestro equipo necesita apoyarse? Entonces, ¿cuál fue ese punto de quiebre que te hizo saltar directamente? Si quieres saltar primero, Dave?

DAVE DICAMILLO: Claro. Lo adoptamos muy pronto y les prometo que fue porque era genial y estaba en todos los blogs y todos querían hacerlo y probablemente por eso empezamos. Pero las aplicaciones prácticas realmente comenzaron a llegar con muchos de nuestros clientes que tenían MarTech existente o plataformas de reproducción de video existentes u otro software del que no querían separarse, y dijeron, mira, estamos felices de hacer este nuevo headless acercarse.

Hemos escuchado muchas cosas buenas sobre cómo podemos administrar mejor los datos, cómo podemos ser más flexibles, desde la perspectiva de la interfaz de usuario, cómo podemos integrar nuevos productos de terceros, en el futuro, más fácilmente.

Y creo que probablemente comenzamos realmente a comercializar lanzamientos para nuestros clientes en algún momento de 2019 y ha sido, nuevamente, la arquitectura dominante con la que lideramos, con muchos de nuestros clientes. Pero sí, estamos muy emocionados. Estamos realizando varias instalaciones de WP Engine Atlas. Tenemos uno a la vuelta de la esquina, en un par de semanas también, lo cual es genial. Pero sí, ese es nuestro viaje inicial con headless.

RAMI: Adam, mencionaste que estás en la cúspide. Me encanta tu opinión, ya que podría ser un poco más reciente, de lo que está comenzando a llevarte en esa dirección.

ADAM DAVEY: Bueno, con ese cliente en particular, ya… a menudo es una decisión compleja, ¿verdad?, qué tecnología de CMS vas a usar. Pero este cliente en particular en realidad tenía una idea, exactamente, de cómo instalaría y configuraría el CMS y cómo administraría su contenido. Así que fue uno inusual. Realmente no necesitábamos llevarlos en ese viaje. Se decidieron por un CMS sin encabezado y por una forma de servir ese contenido en el front-end, a través de varios canales.

Pero muy a menudo, ese no es el caso. Era un cliente técnicamente astuto. Pero muy a menudo, tenemos que, igualmente, tenemos que llevar a las personas a un viaje y diría que también estamos construyendo otro sitio, en este momento, donde el cliente quiere un editor WYSIWYG para poder administrar su contenido. Así que realmente se trata de casos de uso.

Y headless resuelve muchos problemas y puede encajar, como dijiste, David, encajar en pilas existentes. Pero no hay una talla única para todos. Se trata de tener una conversación matizada y detallada con un cliente sobre los requisitos y diferentes clientes se encuentran en diferentes etapas de su curva de madurez con lo digital y sin cabeza y con CMS, por supuesto. Así que se trata de conocerlos, dónde están, en ese viaje, realmente.

RAMI: Sí, Scott o Dennis, ¿alguna idea para agregar a eso en cuanto a qué, algún indicador de cuándo podría ser el momento para las personas que están a punto de adoptar sin cabeza, que vieron en el viaje de ustedes?

SCOTT JONES: Sí, creo que para nosotros fue similar a lo que dijo Dave, en realidad. Era que estábamos leyendo sobre eso. Era algo que estaba ahí fuera. La gente parecía estar haciéndolo y luchando con ello. Y, de hecho, nuestro primer proyecto sin cabeza fue un proyecto de rescate y, sinceramente, fue una pesadilla. Honestamente, fue una pesadilla.

Un cliente vino a nosotros con una implementación sin cabeza realmente mala, algunas opciones tecnológicas muy cuestionables. Cada página tardó aproximadamente, bueno, al menos 30 segundos en cargarse, lo cual es alucinante y esa fue nuestra primera incursión en headless y fue desordenado, por decir lo menos.

Lo que ha sido el desafío para nosotros, a lo largo de varios años con la observación de headless, ha sido construir la experiencia interna en torno a JavaScript, esencialmente y ese desafío, creo, fue empujado y ayudado por el tipo de reconstrucción de WordPress en una plataforma basada en reacciones. Y creo que eso realmente nos ha llevado en un viaje.

Por lo tanto, en realidad ha ido de la mano, bastante bien para nosotros, al incorporar esa experiencia, crear una mejor comprensión con nuestros desarrolladores y luego avanzar en ese viaje hacia lo que realmente ofrecemos a nuestros clientes también.

DENNIS: Sí, para nuestro equipo, el impulsor son realmente nuestros ingenieros y nuestros desarrolladores y hacer una retrospectiva sobre cómo continuamos mejorando nuestra agencia, cómo continuamos mejorando nuestro proceso, son inflexibles sobre headless. Para mí, la analogía era pensar en mi papá, que es mecánico, trabaja en autos cinco días a la semana, ocho horas al día. Cuando haces eso durante 10 años, 20 años, realmente llegas a saber en qué marcas de autos, en qué motores te gusta trabajar. Esa analogía es la misma para mí, para nuestros ingenieros, y vieron al headless como una oportunidad para ser más eficientes en el trabajo y lograr una mejor entrega.

Entonces, para nosotros, fue impulsado por ingenieros como una forma de ser desafiantes e innovadores. Empezamos a identificar clientes que pensamos que encajarían bien. Les presentamos opciones a esos clientes y les dijimos, tienen la opción de ir sin cabeza, donde creemos que hay una mejora en la forma en que desarrollamos su sitio web, en comparación con lo tradicional y como los clientes comenzaron a abordar, comenzamos ese viaje a fines de 2019 y no hemos miró hacia atrás desde entonces.

RAMI: Gracias, señores. Así que todos conocemos y amamos WordPress. Por eso estamos aquí. ¿Bien? Pero también estamos muy familiarizados con algunas limitaciones allí y, obviamente, headless es una forma de mantener la familiaridad y la confiabilidad del backend de WordPress para nuestros creadores de contenido y nuestros vendedores, pero también poder abordar algunas de esas limitaciones que presenta WordPress. .

Entonces, si alguien tiene un caso de uso particular o incluso un proyecto de cliente específico en el que encontró que está bien, no podemos abandonar WordPress debido a las necesidades y los requisitos del cliente, en lo que respecta a la gestión de contenido, pero estamos va a necesitar ir sin cabeza porque hay algunas limitaciones? Me encantaría tener algunos ejemplos de la vida real que sirvan de inspiración a la gente cuando piensen en sus proyectos potenciales en el futuro.

DAVE DICAMILLO: Claro, puedo empezar, si quieres.

RAMI: Gracias, Dave.

DAVE DICAMILLO: Entonces, el que está a la vuelta de la esquina para nosotros, el proyecto Atlas que se avecina, es un DMP. Entonces son un proveedor basado en SAS. Han estado en WordPress durante años. Sin embargo, quieren integrarse mucho con su propio software. Por lo tanto, la arquitectura en sí necesitaba reflejar realmente su deseo de seguir funcionando con WordPress y poder publicar de manera efectiva (no quieren volver a capacitar al equipo), pero también querían integraciones más profundas en sus propios productos y más allá.

Así que también hemos podido ayudarlos a ampliar lo que pueden hacer con el contenido de su sitio. Así que eran bastante incipientes en lo que podían hacer antes del rediseño que se avecina. Pero usar, incluso, Atlas Content Modeler, y poder proporcionar un modelo de contenido más profundo y sólido para que publiquen, brindar una personalización más profunda, brindar esa capacidad de hablar con sus clientes de una manera más personalizada es va a ser un verdadero cambio de juego para ellos.

Así que WordPress era un requisito firme para entrar y dados algunos de esos objetivos del proyecto, tenía mucho sentido que Atlas fuera la aplicación. Así que con suerte, eso ayuda.

RAMI: Dennis.

DENNIS: Sí, para uno de nuestros clientes, el año pasado, hicimos este análisis de varias plataformas diferentes, plataformas nativas sin cabeza, WordPress con WP Engine, y realmente evaluamos dos factores. El número uno serán las características y la funcionalidad que el cliente necesitaba de la plataforma. Luego, el número dos, es realmente el costo total de propiedad de la plataforma.

Pasamos por este análisis exhaustivo y finalmente llegamos a WordPress con WP Engine y Atlas como una solución desde una perspectiva de costos y la flexibilidad de la plataforma, y ​​realmente, la familiaridad con los equipos de marketing y la adopción de un enfoque basado en componentes para nuestro desarrollo. proceso, pudimos crear de manera efectiva un sitio web que permitió al usuario comercial que ya está familiarizado con WordPress, si ya aprovechamos el poder de esa plataforma, pero pudimos implementar componentes dentro de su página web para que, a medida que construyen nuevos páginas de destino o nuevas experiencias en su sitio, no necesariamente necesitan confiar en un desarrollador para implementar esas nuevas páginas de destino.

Y hemos visto una gran mejora en su velocidad de entrega a partir de ese momento. Así que fue un proyecto muy interesante en el sentido de que dedicamos mucho tiempo a hacer este análisis inicial. Y luego, tan pronto como se realizó ese análisis, es un tiempo de comercialización muy rápido y nuestros clientes han estado muy, muy contentos con los resultados.

RAMI: Nos gusta escucharlo. Scott, Adam, ¿alguna idea para agregar sobre esto?

ADAM DAVEY: Sí, al contrario, esta es una pequeña desviación. Pero en realidad hemos visto a un cliente alejarse recientemente de la tecnología sin cabeza, no con Atlas, por supuesto, sino como en una plataforma diferente. No mencionaré esa plataforma. Pero lo pasaron tan mal porque no pudieron administrar su contenido de manera efectiva. Han regresado a Gutenberg, lo cual es realmente… no queremos que eso suceda.

Pero creo que lo que no queremos hacer es dejar sin cabeza a las personas que no están preparadas para ello. Y es un salto para los equipos de marketing, creo, y no es adecuado para todos. Pero también desbloquea una gran cantidad de capacidades poderosas si está administrando contenido, multicanal a escala. Aquí es donde el modelado sin cabeza y de contenido realmente puede desbloquear muchas oportunidades para usted. Sí.

Pero no queremos ver a la gente asustada por los decapitados y queremos sugerir soluciones que sean adecuadas para ellos. Pero he visto muchos beneficios de headless, todo se reduce al caso de uso y al mejor ajuste.

RAMI: Y menciona un gran punto, la responsabilidad con su cliente primero, no demasiado liderar con la tecnología, liderar con lo que es mejor para su cliente y eso es lo que estamos viendo: es un punto de inflexión interesante para la adopción sin cabeza, en torno a lo que realmente es correcto para el cliente frente a lo que es la tecnología nueva, brillante y reluciente. Scott, ¿algo que agregar, ejemplos que hayas visto?

SCOTT JONES: Sin embargo, simplemente agregaría y diría que creo que todos asentimos cuando hay comentarios sobre la mala implementación de headless en el pasado y ese tipo de cosas y creo que ese es el punto importante, realmente, es hacer justo al lado de su cliente. Eso es lo que diría sobre esto, si no estás listo, no lo hagas.

Así que siempre hay un poco de... tienes que ponerte ahí fuera y probar si no lo has hecho antes. Pero en realidad, WP Engine y el proyecto Atlas tienen muchas herramientas, muchos recursos para poder ayudar, para emprender ese viaje. Creo que cuando todos comenzamos este viaje con headless, esas herramientas no existían y todos estábamos construyendo cosas como vistas previas de publicaciones desde cero, muy probablemente, para la mayoría de nosotros, y teníamos que hacer cosas que no estaban en un plataforma, como headless ahora tiene.

Así que sí, creo que diría, involúcrese en el proyecto de WP Engine y pruébelo. Pero definitivamente, siempre anímese a hacer lo correcto por su cliente y no sea uno de esos repartidores que no entrega, por así decirlo, y termina revirtiendo el proceso de regreso a Gutenberg nuevamente.

RAMI: Gracias, señores. Creo que cubrimos, de manera muy completa, los beneficios para el cliente de por qué podría recomendar la arquitectura Atlas. Me interesa saber, ¿cuáles son los beneficios para su equipo interno, para su equipo de desarrollo, para sus gerentes de proyecto, para su equipo de control de calidad? ¿Dónde ha visto, al asumir este papel de liderazgo en la adopción sin cabeza, el agua subir para sus equipos internos?

DAVE DICAMILLO: Adam, aunque puedes empezar.

ADAM DAVEY: Creo firmemente en asegurarme de que todos participen. Me encanta lo que dijiste, David, sobre jugar con cosas brillantes y eso es lo que quiero darles a los desarrolladores las herramientas con las que pueden hacer su mejor trabajo. Pero también es muy importante que la aceptación llegue en todos los niveles del negocio. Entonces, sí, los administradores de contenido están contentos, pero también las partes interesadas están contentas en todos los niveles.

Lo he visto donde se han vendido productos y no ha quedado del todo bien. Debe haber un consenso completo y una aceptación total. Debe llevar a todos con usted en ese viaje en torno a las decisiones tecnológicas.

Y sí, para mí, nuevamente, se trata de un equilibrio y se trata de tomar las decisiones correctas por las razones correctas para el negocio y el cliente porque a menudo, gran parte de la toma de decisiones en torno a headless es que podamos ofrecer un super- experiencia rápida con un front-end realmente encantador, limpio, que es rico e intuitivo, y obtiene puntajes de Lighthouse realmente buenos y todas esas cosas buenas, y con las que a los desarrolladores les encanta trabajar. Así que es un completo, es una mezcla. Obtener todos esos ingredientes correctamente es realmente importante.

DAVE DICAMILLO: Les diré quiénes aman los headless en nuestra tienda, son nuestros diseñadores, quienes se sienten mucho menos limitados. A nuestros ingenieros de reacción también les encanta. Se están volviendo locos por lo que podemos hacer y qué tan rápido podemos hacer esto y todo, todo lo que dices, Adam. Pero creo que la capacidad real para nosotros de extender parte de la creatividad más allá de lo que sería un sitio de publicación normal, creo que sería un sitio normal basado en contenido, ha sido muy revelador para algunos miembros de nuestro equipo, incluso más allá la gente de tecnología.

También diré que desde una perspectiva tecnológica, definitivamente aumenta el tiempo de entrega en algunas capacidades. Las pruebas, para nosotros, han aumentado, lo cual no es algo malo. Es lo correcto para el producto correcto, al final del día. Pero hemos visto un aumento de alrededor del 15% al ​​20% solo en ese pulido final antes de que entremos en funcionamiento, asegurándonos de que todas las conexiones estén atadas.

DENNIS: Sí, creo…

RAMI: Ese es un buen consejo. Esa es una buena idea, para cuando esté buscando una estimación, y al principio de sus primeros proyectos, asegúrese de tener eso en cuenta, oye, ese último 20%, el control de calidad, el lanzamiento y todo, sepa que podría llevar un poco más de tiempo cuando empieces a poner en marcha tus primeros dos proyectos. Lo siento, Denis. Adelante.

DENNIS: No, solo quería construir sobre eso. En cuanto a las operaciones de nuestro equipo de Experiencia Digital o el equipo de Desarrollo, me vienen a la mente algunas cosas. Realmente comenzó a avanzar en el año número dos, hacia el final del año número dos, en nuestro viaje sin cabeza.

Y observando objetivamente el desempeño de su equipo, en realidad vimos que la tasa de defectos disminuyó. Entonces, al desacoplar el front-end del back-end, nuestros errores y problemas que surgen de la implementación del código en el back-end no afectaban al front-end y, en general, estamos implementando un código mejor y más limpio, lo cual es fantástico de ver.

Al punto de David, el tiempo de comercialización fue significativamente más rápido que en el pasado, nuevamente, debido a esa arquitectura de desacoplamiento. Entonces, cuando un cliente necesitaba un cambio menor en un front-end, no tuvimos que programarlo con una actualización de back-end para el empleo. Allí todo se movía más rápido.

Y luego, lo que también ha sido interesante para nosotros, al pensar en los últimos dos años, es que ha cambiado la forma en que pensamos acerca de los recursos de nuestro equipo. Entonces, antes, realmente necesitaba a alguien que supiera WordPress y pudiera codificar en el front-end. Y también tratamos con muchos clientes de comercio electrónico y conocemos la plataforma de comercio electrónico.

Pero ahora puedo contratar a un ingeniero front-end puro y reactivo que no comprende el back-end, y hacerlos productivos en cuestión de semanas, mientras que en el pasado, necesitábamos desarrollar alguna competencia para el back-end. -plataforma final. Así que ha sido muy, muy bueno verlo, como operador, para nuestro equipo.

RAMI: ¿Y tú, Scott? Tiene alguna idea sobre esto?

SCOTT JONES: Sí, estoy pensando: he hablado con algunos fundadores de agencias diferentes sobre su enfoque de headless y, de alguna manera, ha sido similar al nuestro, que en realidad, como fundador de la agencia, quería hacer headless y no era necesariamente el resto del equipo el que ya estaba listo o comprometido para emprender ese viaje.

Y hablando sobre el punto de Adam, realmente, para nosotros, ha sido un viaje de cultura y de propósito y comprender nuestro por qué, como empresa. Y sé que eso puede sonar realmente cliché. Pero eso ha sido realmente importante. Si nuestro equipo, especialmente nuestros desarrolladores, entienden el por qué de nuestro negocio, a medida que avanzamos, y entienden lo que realmente estamos tratando de resolver para el cliente, lo que realmente estamos tratando de ofrecer, queremos lo más atractivo, lo más Experiencias libres de frustraciones que posiblemente podamos ofrecer.

¿Cómo hacemos eso y cómo juega un papel la tecnología en esa ha sido una conversación realmente interesante y eso ha sido lo que los ha llevado en el viaje porque sí, teníamos algunos brazos cruzados muy firmemente y caras de mal humor cuando empezamos a hablar? sobre sin cabeza. Y estoy seguro de que todos ustedes probablemente también han estado en esa situación y se ha asegurado de que tengamos esas conversaciones, asegurándose de que entiendan el por qué, lo que en realidad ha cambiado mucho esa dinámica para nosotros.

RAMI: Entonces, siguiendo con el tema de la velocidad y la eficiencia y todas esas palabras sexys y divertidas, que en realidad son muy importantes en el espacio de la agencia, ¿tienes un momento de ajá que puedas compartir, ya sea una determinada pieza de tecnología, tal vez? fue un cierto cambio en su proceso, tal vez solo estaba usando, literalmente, un vocabulario diferente, que usted estaba como, oh, Dios mío, si hubiera sabido esto hace dos años, habríamos sido más rentables, habríamos trabajado más rápido, la gente habría sido más feliz?

Entonces, tal vez podría compartir con la gente una anécdota que podría compartir con la gente que está un poco antes en su viaje de adopción sin cabeza. No estoy pidiendo secretos comerciales, tal vez solo un momento de iluminación.

SCOTT JONES: Volveré a mi punto, si está bien. Para mí, y tengo una función más orientada al cliente que una función técnica, por lo que siempre estoy pensando en el caso de negocios y cómo construir un caso de negocios y obviamente estoy pensando en eso externamente. Lo que no estaba haciendo necesariamente era pensar en eso internamente y traer el mismo caso de negocios a nuestros desarrolladores, a nuestros diseñadores, gerentes de proyecto, a nuestro equipo.

Una vez que comenzaron a ver algunas de las razones por las que los clientes necesitarían headless, por ejemplo, poder almacenar mapas de forma nativa, en un dispositivo móvil. Podrías estar a mitad de camino de una montaña. Necesitas ese mapa almacenado de forma nativa. Realmente no podrá hacer eso con monolítico, supongo, sin cabeza y, lo siento, WordPress, y mostrando algunos de esos casos de uso.

Creo que eran los... Entiendo por qué un cliente querría esto, entiendo por qué un cliente realmente querría servir una base de contenido a dos front-end diferentes. En realidad, mostrarles algo de eso ha sido lo mejor para nosotros, junto con lo cultural.

RAMI: ¿Y tú, Adán?

ADAM DAVEY: Sí, simplemente saltando allí, supongo que uno de mis ahas fue: trabajamos con todo tipo de clientes, con todo tipo de necesidades comerciales complejas. Pero en lo que los clientes suelen apoyarse es en una solución que aparentemente hace todo por ellos, como una suite todo en uno, que a menudo puede ser realmente poderosa para ellos. Pero esa navaja suiza, probablemente terminen usando solo una hoja o dos de todo el kit y eso es lo que vemos.

Así que el momento de aha, para mí, es que los clientes ahora están pensando en comprar una parte de una pila que hace algo muy, muy bien, y es lo mejor para hacer esa única cosa realmente bien, y luego simplemente acumular capas en su pila con igual... con otros componentes que hacen su trabajo muy, muy bien.

Así que el aha, para mí, es, supongo, ser testigo de los clientes, en los últimos años, y en realidad, el giro, el cambio hacia comprar lo que necesita, algo que es el mejor en su clase, que ofrece muy bien lo que se supone que debe hacer.

Como digo, las suites y los DXP tienen su lugar. Pero cada vez vemos más sin cabeza como parte de un ecosistema más amplio de tecnologías que, en realidad, solo hace un trabajo de manera excelente. Creo que han sido los últimos dos años. Ese es el cambio que hemos visto.

DAVE DICAMILLO: Sí, estoy de acuerdo y creo que la explosión de las herramientas de MarTech, y poder tomar lo mejor de su clase e integrarlo, no solo ahora, sino en el futuro, es realmente la razón para seleccionar headless.

Esos DXP, sí, son geniales. Pero estás en lo correcto. La mayoría de nuestros clientes usan el 10 % o el 20 % de lo que están pagando y no obtienen el valor que, si realmente trabajaron con estos proveedores más pequeños de MarTech, realmente obtienen el soporte que necesitan. En realidad, pueden usar mejor las funciones. Pero sí, una cosa en la que tratamos de entrenar a muchos de nuestros clientes es que no se trata de vivir sin cabeza. Se trata de mirar el futuro de lo que quieres hacer en los primeros 12 meses.

Cuando está lanzando un sitio sin cabeza, al menos en nuestro mundo, se trata más de la pila de MarTech que estamos poniendo en juego que solo del CMS. Estamos tratando de habilitar algunas características diferentes, personalización, herramientas ABM, lo que sea. Todo ese material entra en juego.

Y queremos despojar a los clientes para llegar a un punto en el que estén listos para el lanzamiento, y luego mirar, ¿cómo son los primeros 12 meses? Van a seguir creciendo. Nos gusta decir que el primer día del sitio web es su peor día. Usted está allí para tomar el sitio web y hacerlo crecer desde ese punto y si está pensando a más largo plazo, pensando en cómo se ve ese primer punto de lanzamiento, más 12 meses, creo que realmente solidifica un buen caso para headless, especialmente cuando no están relacionados con DXP, como dice Adam.

RAMI: ¿Alguna idea sobre eso, Dennis?

DENNIS: Creo que el momento de sorpresa, para nosotros, fue cuando vimos una mejora en el rendimiento orgánico, tres o cuatro meses después del lanzamiento del sitio sin cabeza. Y ahí fue cuando… comencé a promover eso. Esto realmente está sucediendo y es parte de por qué estamos haciendo lo que estamos haciendo y ver cómo se desarrolla ha sido muy poderoso para nosotros, como grupo.

Y es por eso que creo, al igual que David, la mayoría de nuestros proyectos de ley, en este punto, ahora, no tienen cabeza porque desde la perspectiva de ser una agencia de marketing de resultados, nuestro trabajo es posicionar el sitio web para que sea una herramienta para nuestro marketing. socios dentro de la agencia y crearles un sitio web que pueda formar, facilita su trabajo.

RAMI: Así que hemos hablado mucho sobre la aceptación interna y las razones por las que, obviamente, sus equipos internos están emocionados de trabajar en headless. Pregunta para todos los que están realmente involucrados en esa fase inicial de propuesta y presentación de ventas con prospectos y clientes actuales.

¿Cuál es la varita mágica que llama su atención? ¿Es rendimiento? ¿Es la flexibilidad? Solo un poco de entrenamiento, para otras personas, que se unen a nosotros, que están comenzando o lanzando puntos de venta, ¿qué está viendo que, en realidad, sus clientes o posibles clientes se aferran y realmente los empujan al límite?

Porque sabemos que adoptar nuevas tecnologías, especialmente para un negocio tradicional, da miedo. Son reacios al riesgo. El cambio puede ser muy costoso. Entonces, ¿qué está encontrando que los tomadores de decisiones, cuando están lanzando una arquitectura sin cabeza, realmente están captando su atención?

ADAM DAVEY: Sí, puedo saltar aquí si es necesario. Lo único que usamos, una y otra vez, son demostraciones de productos reales porque sin mostrar a los clientes lo que están comprando y cómo funcionan esas plataformas, no tiene sentido. Son solo palabras. Así que necesitamos demostrar tangiblemente cómo funciona el headless.

Y hay miedo en torno a esto. Entonces, lo que debemos hacer es responder todas las preguntas, mostrar los casos de uso, explicar cómo se modela y administra el contenido y cómo funcionan realmente esas aprobaciones de flujo de trabajo, o cualquiera de las funciones que estamos usando dentro del CMS. No hay nada mejor que una demostración porque, de lo contrario, es demasiado abstracto. Necesitamos realmente mostrar, demostrar, cuáles son las capacidades y el poder de la plataforma. Así que diría que esa es la herramienta más poderosa que tenemos bajo la manga.

DAVE DICAMILLO: Sí, voy a aprovechar eso. Pero la pregunta número uno que recibimos es, ¿cuál es el día en la vida? Y esta es una pregunta de CMS en general. Cada vez que alguien se muda a una nueva plataforma, es, ¿cómo será mi vida?

Pasamos mucho tiempo, en el proceso de lanzamiento, en realidad educando, solo de alto nivel, ¿qué significan estas diferentes arquitecturas? Pros, contras, cuáles son los diferentes jugadores en el espacio, todo ese tipo de cosas. Pero nunca tomamos una decisión en el campo. Siempre se trata de meterse debajo del capó, con el cliente, hasta el punto de Adam, hacer demostraciones, traer a los socios, hacer que presenten sus propios productos.

Una cosa es decir, oh, la agencia nos lo dijo. Pero otra cosa es que los fabricantes de software y la gente se sienten a la mesa y digan, bueno, he aquí por qué somos los mejores.

Tenemos un proceso de toma de decisiones muy largo en el que asesoramos a nuestros clientes, que se basa en criterios comerciales clave y queremos implementar CMS que sean los mejores en sus propias clases, sin cabeza o acoplados, y dejar que se destaquen, Bueno, ¿qué significa esto para su negocio? ¿Va a afectarlo realmente?

Aquí hay una puntuación en bruto. No se limite a seguir el consejo de Code and Theory. Aquí hay un resultado en un número que dice cuál es mejor para su negocio y luego toma una decisión informada sobre el camino que desea tomar.

DENNIS: Para nosotros, cuando comenzamos una conversación sobre si headless es o no la opción correcta para nuestro cliente, poder abrir uno de nuestros sitios web que construimos, y frente al cliente, en vivo, ejecutar una partitura de Lighthouse, en ese sitio web y mostrarles la puntuación. Eso es inmediato, de acuerdo, dígame más y luego seguiremos este camino de cuál es nuestro stock de tecnología o lo que sea.

Pero para nosotros, ese siempre ha sido el tema de conversación más importante en cualquier oportunidad de ventas, es mostrarles lo que es posible y cuando obtienes puntajes ecológicos en Lighthouse, eso es casi imposible en estas otras plataformas debido a una arquitectura acoplada, realmente es una historia poderosa para contar.

SCOTT JONES: Sí, estoy de acuerdo. Estoy de acuerdo con todas esas respuestas. Creo que para nosotros, se siente como si estuviéramos vendiendo FOMO un poco, realmente, ese miedo a perder el enfoque y, aparte de los beneficios obvios de rendimiento y seguridad, no sé si es lo mismo para ustedes, pero Nos dimos cuenta de que, en realidad, al hacer una auditoría en nuestra base de clientes, nos dimos cuenta de que nuestros mejores clientes son bastante fuertes en tecnología y experiencia de usuario. Tienen desarrolladores internos o equipos de UX internos o lo que sea. Ellos realmente entienden.

Y ellos mismos han investigado un poco sobre esto. Ellos entienden un poco de esto. Ya tienen lo obvio. Lo que tiende a faltar en la mentalidad es en realidad vender el futuro y pensar, desde una perspectiva de desarrollo, en todos los desarrolladores, programadores, que ahora están entrando en campamentos de entrenamiento, estoy generalizando, pero están aprendiendo JavaScript y, por lo tanto, si todavía está trabajando en el pasado o como estamos ahora, no está pensando en dónde irá el mercado en el 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. Es genial. 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.