Como fundador de Voizzup, una startup que ayuda a emisoras de radio a evaluar sus contenidos de antena a diario midiendo la reacciones espontáneas de sus oyentes en aplicaciones móviles, tendré la suerte de trabajar en los próximos meses con VRT, una de las organizaciones públicas de radio más innovadoras de Europa. También, si todo va bien, ayudaré pronto a algunas de las emisoras de un grupo de radio comercial muy activo e inspirador.
Estas dos organizaciones se han dado cuenta por sí solas de que necesitan adaptarse para estar al día de los últimos avances tecnológicos y cambios profundos que se están produciendo en la industria del audio. Ambas han modificado su estructura interna para albergar equipos tipo startup, poner en marcha laboratorios de innovación e incorporar nuevos roles en Radio como arquitectos de soluciones, Scrum masters, product managers de automatización de datos, diseñadores de experiencia de usuario para voz, etc.
La semana pasada, durante una sesión de trabajo con una de estas organizaciones hablamos sobre radio ágil. En este escenario de cambio constante, las organizaciones de grandes dimensiones se enfrentan al reto de ser capaces de adaptarse con rapidez. Necesitan pasar de ser pesados y lentos elefantes a ser ratones rápidos y ágiles. Mi presentación se basaba en dos requisitos básicos para la agilidad: crear de forma iterativa y tener al usuario en el centro en todas las fases y procesos. Me explico:
Iteración
Al trabajar en ciclos cortos, invertimos poco tiempo y esfuerzos, arriesgamos menos. Si en lo que estamos trabajando no funciona, lo descubriremos rápido sin poner mucho en riesgo. Si funciona, podremos seguir avanzando y mejorarlo.
Usuarios en el centro
Los usuarios, oyentes en nuestro caso, cambian hoy en día sus comportamientos y expectativas más rápido que nunca antes. Lo que funcionaba para ellos ayer, puede no funcionar hoy. Necesitamos preguntarnos constantemente si a nuestros usuarios todavía les importa lo que les estamos ofreciendo.
Muchos de los puestos y funciones que he mencionado anteriormente – habituales en empresas de software, nuevos en Radio – estaban presentes entre los asistentes a mi sesión de la semana pasada. Tal vez alguno de ellos (supongo que no la mayoría) descubrió, durante la sesión, que esos dos ingredientes para la agilidad no son exclusivos de su equipo y disciplina. Los desarrolladores de software e ingenieros usan Agile, probablemente Scrum. Generan tanto código libre de bugs como sea posible en un ciclo quincenal o mensual, o sprint. Los product managers usan Lean. Éstos priorizan de forma eficiente, señalan no lo que se puede desarrollar sino lo que se debe desarrollar. A través de tests y experimentos, identifican tan rápido como sea posible el producto mínimo que da valor al cliente. Crean MVP’s (productos mínimos viables). Los diseñadores usan Design Thinking. Llevan a cabo ejercicios de investigación y diseño, así como otras actividades de exploración, para testar rápidamente sus hipótesis sobre el encaje entre problema del usuario y potencial solución.
Agile, Lean y Design Thinking, tres disciplinas para ayudar a los equipos a ser ágiles. Bueno, no exactamente. Ser ágil es reaccionar rápido, mostrar flexibilidad, adaptarse. Como Jeff Gothelf explica en su libro “Lean Vs. Agile Vs. Design Thinking: What you really need to know to build high-performing digital product teams”, estas metodologías o sistemas de trabajo tienen algo en común, todas ellas hacen posible la mejora continua (que es lo que motiva a las organizaciones a implementarlas). Tienen, sin embargo, diferentes enfoques y objetivos: Agile ayuda a ser más veloz. Lean persigue la máxima eficiencia. Design Thinking valida la relación problema-solución. Como dice Gothelf en su libro y en numerosos artículos, la verdadera agilidad sólo está al alcance de aquellas organizaciones que, para permanecer enfocadas y alineadas, usan y combinan las actividades centrales de mejora continua comunes a las tres disciplinas.
¿Dónde está la gente de radio, los profesionales del contenido? ¿No necesitan los presentadores, productores, editores, programadores musicales, invesigadores de audiencias, directores de programación, ser parte de esta agilidad? Miembros de ambas organizaciones a las que me he referido anteriormente, me han expresado la misma preocupación: “la gente de radio” (equipos tradicionales de radio, más cercanos al contenido) no parece estar interesada en conseguir esa agilidad. ¿No necesitan responder más rápido a los cada vez más cambiantes comportamientos de escucha?
Yo creo que sí lo necesitan. Creo que sí lo NECESITAMOS. No hay nada inherente a nuestra profesión, vocación o experiencia que nos proteja de la incertidumbre del cambio. También nosotros necesitamos desafiar continuamente a nuestras suposiciones y validar si lo que estamos produciendo y emitiendo, subiendo o compartiendo tiene valor para nuestra audiencia. Necesitamos confirmar a diario que a nuestros oyentes todavía les importa lo que hacemos.
Lean, Agile o Design Thinking nos suenan a chino. Pero, ¿por qué razón no deberíamos perseguir la mejora constante? Al igual que Gothelf, creo que la organización (de radio) entera, como un solo equipo multifuncional, debe combinar actividades para la mejora continua. Los equipos de antena, programación, redacción, producción de sonido, investigación de audiencias, etc. no están exentos. En mi opinión, también éstos necesitan incorporar los ciclos cortos y el feedback del oyente a todas las fases de su creación, para permitir la mejora continua. Incluso si eso requiere crear su propio sistema de trabajo y su propia terminología.
Se puede hacer. Voizzup, junto a los editores de De Ochtendspits, el morning de BNR Nieuwsradio (nuestro cliente en Amsterdam, recientemente galardonado como la empresa más innovadora de Países Bajos) ha desarrollado una metodología para la mejora continua de los contenidos de antena. Los datos recogidos de las reacciones de los oyentes durante su escucha en aplicaciones móviles son procesados y cruzados con los contenidos de antena, minuto a minuto. Esa información es entregada al equipo del programa a diario, para la evaluación continua de sus contenidos. A lo largo del tiempo, los editores encuentran patrones. Estos patrones no son tratados como conclusiones sino como hipótesis que son testadas a través de experimentos. En BNR, los editores que iteran a través de experimentos y los desarrolladores que programan en sprints conforman equipos y trabajan en proyectos de forma conjunta.
Ya seas un ingeniero, desarrollador o diseñador trabajando en radio, haz un favor a tu organización y comparte este artículo con tus colegas de Contenido. También puede ser útil recomendarles alguna de estas lecturas. Más importante aún, invítales a participar en vuestras actividades de equipo multifuncional, comparte tu conocimiento y aboga por la transparencia dentro de tu organización.
Si eres director de contenidos o programación, director de morning show, presentador o productor y estás interesado en las técnicas de mejora continua, puedes empezar hoy mismo. Para iniciarte no necesitas más herramientas que papel, lápiz y post-its. En este artículo, encontrarás una serie de ejercicios de exploración, similares a algunas actividades de Design Thinking que constituyen la base de mi propuesta para la auto-evaluación y el desarrollo continuo de talento en antena (o fuera de antena). Pruébalos y dame un toque si necesitas ayuda. ¡Que te diviertas!
______________________________________
Mi nombre Tommy Ferraz. Soy uno de los fundadores de Voizzup y anteriormente director de programación en radio. Por favor, contacta conmigo si quieres que ayude a tu equipo a adoptar un proceso de mejora continua: tommy@voizzup.com