Por dónde empezar a innovar en tu equipo: los primeros 30 días

Se empieza por un problema real que el equipo ya tiene entre manos, no por una estrategia, un laboratorio o un curso de formación. En los primeros 30 días, se elige ese problema junto a un patrocinador, se escucha a las personas que lo viven, se formula como una pregunta, se prueban unas cuantas ideas baratas y se termina con una decisión sobre qué conservar. Un equipo que completa con honestidad un ciclo pequeño ya ha empezado a innovar; un equipo que pasa el mes redactando un marco de trabajo, no.

Esta guía recorre el primer mes completo: qué decidir antes de empezar, un plan semana a semana, a quién hay que implicar, qué debería poder enseñarse el día 30 y los errores que frenan la mayoría de los primeros intentos. Cada apartado enlaza con un artículo más detallado por si se quiere profundizar.

Qué significa realmente «empezar a innovar»

La mayoría de los equipos cree que necesita permiso, una partida presupuestaria o una unidad nueva antes de arrancar. Para empezar no hace falta nada de eso. Hace falta un hábito: detectar un problema, entenderlo bien, probar algo pequeño, aprender de ello y decidir.

Conviene tener claro qué tipo de innovación se está poniendo en marcha. El Observatorio de Innovación del Sector Público de la OCDE describe cuatro facetas: la de mejora (hacer mejor el trabajo existente), la orientada a misiones (avanzar hacia un objetivo claro por medios todavía desconocidos), la adaptativa (responder a una situación que ha cambiado) y la anticipatoria (prepararse para posibilidades que podrían transformar lo que se hace). El modelo se escribió para gobiernos, pero sirve a cualquier equipo. Casi todos los primeros 30 días pertenecen a la primera faceta. No es falta de ambición. Mejorar algo que la gente usa a diario es la forma en que un equipo aprende los métodos, se gana la confianza y obtiene el derecho a intentar cosas más grandes después.

Así que el objetivo del primer mes no es un gran avance. Es un equipo que ha completado un ciclo honesto, del problema a la decisión, y que quiere hacer otro. Si no está claro que se den las condiciones, merece la pena leer 7 señales de que tu equipo está listo para innovar, y 3 de que no lo está. Si parece que primero hace falta una unidad dedicada, mejor leer «Primero necesitamos un departamento de innovación». Por qué no es así.

Antes del primer día: tres decisiones

Hay que dedicarles una hora con quien vaya a patrocinar el trabajo. Si se saltan, la misma discusión aparecerá en la tercera semana, con menos buena voluntad.

1. Qué problema. Elegir un problema, no un tema. «La experiencia de cliente» es un tema. «Los clientes nuevos esperan once días hasta su primera reunión y no sabemos por qué» es un problema. Un buen primer problema es uno sobre el que el equipo puede influir sin la aprobación de otro departamento, que la gente sufre hoy y sobre el que se puede aprender hablando con usuarios reales en una semana. El artículo La primera pregunta antes de cualquier proyecto de innovación profundiza en cómo elegir y poner a prueba el problema.
2. Quién lo patrocina. Una persona sénior con nombre y apellidos que se compromete a dedicar 30 minutos la primera semana y una hora al final, y que tomará la decisión el día 30. No un comité. Si nadie está dispuesto a poner su nombre, o el problema no es lo bastante importante o se ha elegido el equivocado.
3. Qué significa «terminado». Acordar por escrito que el día 30 termina con uno de tres resultados: mantener y escalar un cambio, hacer una segunda ronda o parar. Parar cuenta como éxito si se ha entendido por qué. Ponerlo por escrito pronto protege al equipo de que se le juzgue por si la primera idea «funcionó».

Los primeros 30 días, semana a semana

El plan que sigue parte de un equipo central de tres a seis personas que dedican aproximadamente un día a la semana, más algunas sesiones concentradas. Funciona sin más presupuesto que el tiempo de las personas. Si el dinero es la preocupación, véase Innovar sin presupuesto: lo que puedes empezar el domingo.

Semana 1: entender quién está implicado

• Dibujar un mapa de partes interesadas. En 45 minutos, anotar a todas las personas que tocan el problema: quienes lo sufren, quienes lo provocan sin querer, quienes podrían bloquear una solución y quienes se beneficiarían. Un mapa de partes interesadas evita diseñar solo para quienes están en la sala.
• Agendar las conversaciones. A partir del mapa, elegir de seis a ocho personas con las que hablar la semana siguiente, incluidas al menos dos que vivan el problema directamente y una que vaya a ser escéptica.
• Informar al patrocinador. Mostrarle el enunciado del problema y el mapa. Hacerle una sola pregunta: «¿Qué te haría decir que esto ha merecido la pena?».

Semana 2: escuchar antes de resolver

• Hacer entrevistas breves. De treinta a cuarenta y cinco minutos cada una, dos personas por entrevista: una pregunta y otra toma notas. Preguntar por la última vez que ocurrió algo, no por lo que la gente piensa en general. La guía de entrevistas a partes interesadas incluye un banco de preguntas.
• Observar siempre que se pueda. Veinte minutos viendo cómo ocurre un proceso suelen valer más que una hora hablando de él.
• Mapear la experiencia. Al final de la semana, trazar los pasos por los que pasa la gente y marcar dónde duele. Un mapa de experiencia construido con lo que se ha escuchado, no con lo que se suponía, es el artefacto más útil del mes.

Semana 3: enmarcar el problema y después generar ideas

• Encontrar la causa. Usar un árbol de problemas para separar el síntoma visible de lo que lo provoca. Es habitual que el problema real esté un paso antes de donde se empezó.
• Convertirlo en pregunta. Redactar dos o tres preguntas «¿Cómo podríamos…?». La fórmula procede del trabajo de Min Basadur en Procter & Gamble en los años setenta y más tarde la popularizó IDEO. «¿Cómo podríamos…?» invita a explorar opciones sin prometer una solución. Véase la guía de preguntas ¿Cómo podríamos?.
• Generar primero en silencio. Hacer una ronda de brainwriting antes de cualquier debate abierto, para que la voz más sénior o la más fuerte no marque la dirección en el primer minuto.
• Elegir dos o tres ideas para probar. Usar una matriz impacto-esfuerzo para una primera criba rápida. Escoger ideas que se puedan probar en una semana, no las más grandes.

Semana 4: probar y después decidir

• Hacerlo barato y real. Un prototipo en papel, un formulario simulado, un guion distinto en un mostrador durante una mañana. Si se tarda más de dos días en construirlo, es demasiado grande para este mes.
• Probar con unos cinco usuarios reales. Observar lo que hacen, anotar dónde dudan, preguntar qué esperaban.
• Hacer un premortem antes de recomendar nada. Pedir al equipo que imagine que han pasado seis meses y el cambio ha fracasado, y que enumere por qué. El psicólogo Gary Klein describió la técnica en Harvard Business Review en 2007. Saca a la luz riesgos que la gente, de otro modo, se guardaría. Véase premortem.
• Celebrar la reunión de decisión. Una hora con el patrocinador. Mostrar lo que se escuchó, lo que se probó y lo que pasó, y recomendar mantener, repetir o parar.
• Cerrar con una retrospectiva. Treinta minutos sobre cómo ha trabajado el equipo, no sobre lo que ha producido. Una retrospectiva es lo que convierte un proyecto en un hábito.

Si se prefiere concentrar el trabajo de método en un único bloque intensivo, La primera semana de innovación de tu equipo: un plan de cinco días condensa las semanas dos a cuatro en cinco días seguidos.

A quién hay que implicar

• Un patrocinador que es dueño de la decisión del día 30 y protege el tiempo del equipo.
• Una persona que lidera el ritmo, agenda las sesiones y deja por escrito lo que se decide. No tiene por qué ser la persona más sénior. Tiene que ser alguien por quien los demás se presenten.
• Un equipo central de tres a seis personas que, idealmente, combine a quienes hacen el trabajo, a quienes ven al usuario y a alguien de fuera de la unidad que haga preguntas ingenuas.
• Usuarios y personal de primera línea, implicados en las semanas dos y cuatro, no invitados a una presentación al final.

Hay que mantener pequeño el equipo central. Con diez personas, cada sesión se convierte en una reunión. Si mucha gente quiere sumarse, se la puede invitar a las sesiones de prueba de la cuarta semana, donde un par de ojos extra resulta realmente útil.

Qué debería tenerse el día 30

No se busca un producto terminado. Se debería poder mostrar:

• un enunciado del problema de un párrafo que el patrocinador considera acertado;
• notas de seis a ocho conversaciones y un mapa de experiencia construido a partir de ellas;
• dos o tres ideas probadas, con lo que ocurrió en cada prueba;
• una decisión (mantener, repetir o parar) con una razón breve;
• una lista de quién aportó qué, para que las personas que hicieron el trabajo sean visibles;
• la visión del propio equipo, salida de la retrospectiva, sobre qué hacer distinto la próxima vez.

Ese último punto importa más de lo que parece. El sentido del primer mes es desarrollar la capacidad del equipo para volver a hacerlo sin ti.

Los métodos que conviene aprender primero

No hacen falta docenas de herramientas. Cinco sostienen la mayor parte de un primer proyecto: entrevistas para escuchar, «¿Cómo podríamos…?» para enmarcar, brainwriting para generar, una matriz impacto-esfuerzo para elegir y un prototipo en papel para probar. Cada una se explica en Los 5 métodos que todo equipo debería aprender primero, junto con lo que se puede dejar para más adelante.

Si trabajas en la Administración pública

Los organismos públicos tienen limitaciones propias: normas de contratación, cadenas de aprobación, ciclos de planificación anuales y un temor razonable al fracaso público. El ciclo de 30 días sigue funcionando, pero los tres primeros meses necesitan otro ritmo, con más atención al mandato, la gobernanza y la evidencia. Véase Empezar a innovar en una entidad pública: los primeros 90 días.

Qué hacer y qué no

Qué hacer

• Elegir un problema lo bastante pequeño para terminarlo en un mes y lo bastante real para que a la gente le importe.
• Hablar con los usuarios antes de que nadie proponga una solución.
• Proteger una franja fija cada semana. La innovación que encaja «cuando haya tiempo» nunca ocurre.
• Anotar, sobre la marcha, quién aportó cada hallazgo, idea y prueba.
• Considerar un «paramos» bien razonado como un buen resultado.

Qué no hacer

• Empezar con un ejercicio de marca, un logo para la iniciativa o un evento de lanzamiento.
• Pedir ideas a toda la organización antes de conocer el problema. Llegarán cientos a las que no se podrá dar seguimiento, y la gente dejará de enviarlas.
• Dejar que la persona más sénior hable primero en las sesiones de ideas.
• Construir algo que lleve más de dos días antes de haberlo probado en papel.
• Juzgar el mes por si la primera idea funcionó. Juzgarlo por si el equipo aprendió y decidió.

Ejemplo ilustrativo

Ilustrativo: una organización inventada, solo a efectos explicativos.

La oficina regional de una empresa logística internacional en Róterdam tiene un equipo de atención al cliente de doce personas. La responsable quiere «empezar a innovar» y la sede central le ha pedido que enseñe algo dentro del trimestre.

En lugar de lanzar una campaña de ideas, elige un problema: los clientes llaman varias veces para preguntar dónde está un envío retrasado. Su director acepta patrocinarlo y decidir el día 30.

En la primera semana, cuatro personas del equipo mapean quién está implicado: clientes, conductores, el almacén y el equipo del sistema de seguimiento. En la segunda entrevistan a siete clientes y acompañan a dos conductores durante un turno. El mapa de experiencia revela algo que no esperaban: los clientes no preguntan sobre todo dónde está el paquete, sino si alguien sabe que va con retraso. En la tercera semana, la pregunta pasa a ser «¿Cómo podríamos avisar a los clientes de un retraso antes de que lo noten?». El brainwriting produce 40 ideas; la matriz las reduce a dos. En la cuarta prueban, durante tres días y en una ruta, un mensaje enviado a mano para los envíos retrasados. Las llamadas repetidas en esa ruta bajan de forma notable, y el premortem advierte de que un mensaje manual no sobrevivirá a una semana de mucho trabajo.

La decisión del día 30: repetir, esta vez con el equipo del sistema de seguimiento en la sala para explorar cómo automatizarlo. La retrospectiva recoge que los turnos con los conductores fueron las dos horas más valiosas del mes.

Preguntas frecuentes

¿Cómo se empieza a innovar en un equipo que nunca lo ha hecho? Eligiendo un problema que el equipo ya tenga entre manos, dándole una franja semanal fija y un patrocinador, y haciendo un ciclo: escuchar, enmarcar, generar, probar, decidir. No hay que empezar por la formación. La gente aprende los métodos más rápido usándolos en algo real.

¿Cuánto se tarda en ver resultados de la innovación? Una idea probada y una decisión clara deberían llegar en unos 30 días. Un cambio medible en un servicio suele tardar más, a menudo un segundo o tercer ciclo. Conviene desconfiar de quien prometa una transformación en un trimestre.

¿Hace falta una estrategia de innovación antes de empezar? No. Una estrategia es mucho más fácil de escribir después de algunos ciclos, cuando se sabe en qué es bueno el equipo y dónde están los problemas reales. Mejor empezar en pequeño y usar lo aprendido para dar forma a la estrategia.

Hacia dónde seguir

Los artículos de esta sección profundizan en cada parte del primer mes. ¿Está tu equipo listo para innovar? ayuda a comprobar el terreno antes de empezar. La primera pregunta que hay que hacerse ayuda a elegir el problema. La primera semana de innovación de tu equipo y Los 5 métodos que todo equipo debería aprender primero cubren la práctica. Innovar sin presupuesto, Por qué no hace falta primero un departamento de innovación y Empezar a innovar en una entidad pública abordan las objeciones y los contextos habituales.

Para los métodos en sí, lo mejor es empezar por las guías de entrevistas a partes interesadas, mapa de experiencia, preguntas ¿Cómo podríamos? y premortem, o recorrerlas todas en el índice de guías.