Puntos clave
- El modo de fallo mas comun es un desajuste de ritmos: las corporaciones se mueven en trimestres, las startups en semanas. Sin una capa de interfaz clara, la colaboracion se bloquea antes de producir nada.
- El encaje tecnologico es necesario pero no suficiente. El encaje de etapa, la velocidad de toma de decisiones y la claridad de los entregables importan mas en la practica.
- El equipo corporativo debe tener autoridad de decision real. Una colaboracion gestionada por personas que necesitan escalar cada eleccion no es una colaboracion: es un proceso de compra.
- Define como es el exito antes de que la colaboracion comience, y vinculalo a resultados, no a actividades.
- El crecimiento de la startup es el objetivo principal. La corporacion captura valor como consecuencia de acelerar a la startup, no como punto de partida.
He impartido este taller decenas de veces: en laboratorios de innovacion corporativa, en aceleradoras universitarias y en CERN IdeaSquare durante el programa de la escuela de verano. La sala siempre esta llena de personas que genuinamente quieren que la colaboracion funcione. Los problemas rara vez tienen que ver con la intension. Casi siempre tienen que ver con la estructura.
La colaboracion corporate-startup es una de esas ideas que parecen sencillas hasta que intentas llevarlas a cabo. Una gran empresa tiene recursos, distribucion y credibilidad. Una startup tiene velocidad, foco y un enfoque nuevo a un problema que la corporacion conoce bien. La logica de combinarlas es clara. Es en la ejecucion donde todo se rompe.
Este articulo describe el framework que uso en la practica: que definir antes de que la colaboracion comience, como estructurar la relacion mientras esta en marcha, y que observar cuando empieza a ir mal.
Por que fracasa la mayoria de las colaboraciones
El fracaso casi nunca tiene que ver con la tecnologia. Cuando el equipo corporativo selecciona una startup con la que trabajar, la tecnologia ya ha sido evaluada cuidadosamente. La diligencia debida sobre el producto es exhaustiva. El caso de negocio esta documentado. Y luego la colaboracion se bloquea, produce un piloto que no lleva a ningun lugar, o se desvanece silenciosamente tras seis meses sin resultados claros.
La razon es casi siempre una de estas tres cosas.
Desajuste de ritmos. Las corporaciones operan en ciclos de planificacion trimestral, con aprobaciones de presupuesto, procesos de compra y comites de seguimiento. Las startups operan en semanas. Cuando una startup necesita una decision en dos semanas y el proceso corporativo requiere ocho, la colaboracion no se adapta a esa brecha: se hunde en ella. La startup pasa a otras prioridades. El equipo corporativo pierde el hilo. Ambas partes se separan con la vaga sensacion de que la otra era dificil con quien trabajar.
Propiedad poco clara en el lado corporativo. Una colaboracion gestionada por alguien sin autoridad real de decision no es una colaboracion. Es una serie de reuniones. Si la persona que gestiona el programa necesita escalar cada decision significativa, la startup esta trabajando con una capa intermedia, no con la organizacion. Los mejores socios corporativos son aquellos equipos donde la persona en la sala puede decir que si.
Definicion de exito desalineada. La corporacion quiere aprender sobre el espacio tecnologico. La startup quiere un cliente de pago, una referencia o un acuerdo de co-desarrollo. Si estas expectativas no estan alineadas desde el principio, ambas partes mediran la colaboracion con criterios diferentes y ambas quedaran decepcionadas, incluso si se producen los mismos outputs.
La solucion es estructural, no cultural. No se trata de ensenara las corporaciones a pensar como startups ni de pedir a las startups que sean pacientes con los procesos corporativos. Se trata de disenar una capa de interfaz que permita a ambas organizaciones operar a su propio ritmo produciendo outputs compartidos en intervalos acordados.
Antes de empezar: cuatro cosas que definir
Cada colaboracion que he visto funcionar bien tenia estas cuatro cosas definidas antes de la primera sesion conjunta. Cada colaboracion que he visto ir mal le faltaba al menos una de ellas.
Como es el exito, y para cuando
No "queremos explorar sinergias" o "queremos entender mejor la tecnologia." Un resultado concreto y acotado en el tiempo. Un piloto con un alcance especifico completado antes del mes tres. Un acuerdo de co-desarrollo firmado antes del mes seis. Una tecnologia licenciada e integrada en una linea de producto antes de fin de ano. El objetivo no necesita ser ambicioso. Necesita ser lo suficientemente especifico como para que ambas partes puedan mirarlo seis meses despues y acordar si ocurrio.
El error comun: definir el exito en terminos de actividades en lugar de resultados. "Realizaremos cuatro talleres y produciremos un informe" es un plan de actividades, no una definicion de exito. La pregunta es que cambia en el mundo como resultado de esos cuatro talleres.
Quien tiene autoridad de decision en cada lado
Nombra a la persona del lado corporativo que puede aprobar el siguiente paso sin escalar. Nombra a la persona del lado startup. Si ninguna de esas personas esta en la sala para la primera reunion, ya has introducido un retraso en cada decision posterior. La colaboracion necesita un punto de contacto en cada lado que pueda comprometer recursos, aprobar cambios de alcance y desbloquear problemas sin un comite.
En la practica: aqui es donde la mayoria de los programas corporativos se rompen. La persona que gestiona el programa suele ser un gestor de programa, no un propietario del negocio. Un gestor de programa puede organizar. No puede comprar. Asegurate de que el propietario del negocio este identificado y comprometido antes de que comience la colaboracion.
Lo que la startup realmente necesita de esta colaboracion
No lo que la corporacion asume que necesita la startup. Pregunta directamente. Las startups se involucran en colaboraciones corporativas por razones diferentes: obtener un cliente de referencia, acceder a un canal de distribucion, co-desarrollar una funcionalidad que no pueden construir solas, validar un caso de uso en un entorno regulado. La corporacion no puede ser un socio util sin saber cual de estos es el objetivo real. Y la startup no puede obtener lo que necesita si no lo dice claramente.
La pregunta que siempre hago en el taller: "Si esta colaboracion produce exactamente una cosa concreta para tu empresa antes de final de ano, que quisieras que fuera esa cosa?" La respuesta suele diferir de lo que el equipo corporativo habia asumido que queria la startup.
La cadencia y el formato de los check-ins
Semanal es casi siempre demasiado frecuente para que ambas partes tengan algo significativo que reportar. Mensual es con frecuencia demasiado infrecuente para detectar problemas antes de que se acumulen. Quincenal funciona bien en la practica: lo suficientemente frecuente para mantener el impulso, lo suficientemente infrecuente para que algo haya ocurrido realmente entre sesiones. El formato tambien importa: una llamada de actualizacion periodica produce estado, no decisiones. Un check-in estructurado en torno a "que esta bloqueado y que decision se necesita" produce movimiento.
Una plantilla practica: comienza cada check-in quincenal con tres preguntas. Que ha progresado desde la ultima vez? Que esta bloqueado y que lo desbloquearia? Cual es la unica decision que debe tomarse antes de la proxima sesion?
Como elegir la startup correcta
El encaje tecnologico es el filtro que la mayoria de los equipos corporativos aplica primero, y es el menos predictivo de si la colaboracion producira resultados. Cuando evaluas startups, ya has reducido el campo a empresas que trabajan en la tecnologia relevante. Dentro de ese grupo, los criterios que realmente distinguen las colaboraciones exitosas de las fallidas son diferentes.
Encaje de etapa. Una startup en fase de idea necesita cosas diferentes de un socio corporativo que una startup con un producto existente y clientes de pago. Las startups en etapa temprana se benefician principalmente del acceso a conocimiento de dominio, datos y enunciados de problemas reales. Las startups en etapa avanzada se benefician principalmente de la distribucion, las relaciones de compra y la escala. La estructura de la colaboracion debe coincidir con la etapa actual de la startup. Un programa disenado para una frustrara a la otra.
Capacidad del equipo fundador para la colaboracion. Un equipo de dos personas trabajando en su producto principal no puede absorber una colaboracion que requiere informes semanales, presentaciones a comites de seguimiento y un flujo de trabajo de co-desarrollo que corre en paralelo. La colaboracion consumira la atencion del equipo de maneras que danan el negocio principal. Esta no es una razon para evitar las startups en etapa temprana. Es una razon para disenar la colaboracion de modo que cueste a la startup el menor overhead operativo posible.
La disposicion de la propia corporacion. Este es el criterio que la mayoria de los equipos corporativos olvida aplicarse a si mismos. Puede la corporacion tomar decisiones suficientemente rapido como para ser un socio util? Los datos o la infraestructura que necesita la startup son accesibles dentro de la linea de tiempo de la colaboracion? Existe un camino realista del piloto a la produccion, o se trata de una exploracion que produce un informe y luego se detiene? Una startup que entra en una colaboracion sin hacer estas preguntas esta asumiendo mas riesgo del que se da cuenta.
Como es una buena colaboracion mientras se desarrolla
Una colaboracion que funciona bien tiene una textura especifica. Las reuniones comienzan con decisiones que tomar, no con estado que compartir. Los problemas emergen pronto, porque ambas partes tienen suficiente confianza para decir "esto no esta funcionando" antes de que se convierta en una crisis. La startup esta construyendo algo real durante la colaboracion, no preparando materiales sobre lo que podria construir. Y el equipo corporativo esta aprendiendo cosas que cambian como piensa sobre el problema, no recopilando observaciones para anadir a un informe.
Una colaboracion que esta yendo mal tiene una textura diferente. Las reuniones se vuelven mas largas y menos conclusivas. La startup esta pasando mas tiempo gestionando la relacion que construyendo el producto. El equipo corporativo pide mas documentacion, mas detalle, mas justificacion. Ambas partes son educadas pero cada vez mas desconectadas del trabajo real de la otra.
La senal de alarma temprana que observo: cuando la startup deja de pedirle cosas a la corporacion. En una colaboracion saludable, la startup pide: datos, presentaciones, acceso a usuarios, una decision sobre el alcance. Cuando esas peticiones se detienen, generalmente significa que la startup ha dejado de esperar que la colaboracion sea util y ha seguido adelante mentalmente. La relacion sigue viva en el papel, pero la energia la ha abandonado.
La trampa del piloto
El piloto es donde mueren la mayoria de las colaboraciones corporate-startup. Parece un progreso: la corporacion se ha comprometido con una prueba real, la startup tiene una referencia a la que senalar, ambas partes estan involucradas. Pero un piloto que no esta disenado con un camino claro hacia un paso siguiente es un callejon sin salida disfrazado de hito.
Antes de que comience un piloto, ambas partes deberian ser capaces de responder: si este piloto tiene exito en las metricas que hemos acordado, que ocurre despues? Hay un proceso de compra listo para moverse? Hay una linea presupuestaria para la fase siguiente? Hay un propietario del negocio que se ha comprometido con el paso siguiente condicionado a los resultados del piloto?
Si la respuesta a cualquiera de esas preguntas es "ya veremos cuando lleguemos ahi," el piloto es casi con toda certeza lo ultimo que ocurrira. Las corporaciones son muy buenas haciendo pilotos. Son mucho menos buenas convirtiendo pilotos en despliegues en produccion, porque las condiciones que hacen facil un piloto, un alcance reducido, un presupuesto protegido, un champion motivado, suelen estar ausentes cuando llega la decision de compra real.
El trabajo de la startup es hacer que el paso siguiente sea lo mas facil posible de aprobar antes de que el piloto comience. Eso significa conocer el proceso de compra, entender el ciclo presupuestario e identificar quien es el comprador economico, no solo quien es el champion. No son conversaciones comodas antes de que comience un piloto. Son mucho mas incomodas despues de que uno haya concluido de forma inconclusa.
Que significa si estas gestionando un programa
Si estas disenando o gestionando un programa de colaboracion corporate-startup, la decision de diseno mas importante que tomaras es para quien es el programa. Los programas que producen resultados tratan a la startup como el cliente principal. La corporacion captura valor porque la startup crece, encuentra el product-market fit mas rapidamente, o resuelve un problema real para el negocio corporativo. El aprendizaje de la corporacion es una consecuencia de eso, no el objetivo.
Los programas que producen informes tratan a la corporacion como el cliente principal. El objetivo es dar al equipo corporativo informacion sobre el panorama tecnologico, exposicion a nuevos modelos de negocio, una sensacion de conexion con el ecosistema startup. No son malos objetivos. Pero producen un programa muy diferente, uno en el que las startups perciben que estan siendo utilizadas como accesorios en el viaje de aprendizaje de otra persona, y responden en consecuencia.
Los mejores programas en los que he participado, incluyendo trabajo realizado en entornos universitarios y en CERN IdeaSquare, comparten una caracteristica comun: el equipo corporativo se presenta como un recurso para la startup, no como un evaluador. La relacion se parece mas a la de un cliente que a la de un inversor. La startup sabe exactamente que puede pedir y que se espera que entregue. Y el equipo corporativo se mide por si las startups con las que trabaja hacen progresos, no por si el programa transcurre sin problemas.
Trabaja con nosotros
Estas disenando un programa corporate-startup?
Ayudamos a corporaciones europeas a disenar y gestionar programas de colaboracion que producen resultados reales. Desde la seleccion de las startups correctas hasta la estructuracion de la capa de interfaz que hace funcionar la colaboracion, lo hemos hecho en muchos sectores y contextos. Si estas construyendo un programa o repensando uno que no ha producido resultados, hablemos.
Inicia una conversacion