Cómo trabajar con startups sin hacerles perder el tiempo ni perderlo tú

Para trabajar bien con startups hay que partir de un problema que ya se ha acordado resolver, dar a una persona autoridad para decidir con rapidez y hacer un piloto corto y pagado, con criterios de éxito escritos antes de empezar y un contrato preparado si sale bien. La mayoría de las colaboraciones entre corporaciones y startups no fracasan porque la tecnología falle, sino porque la gran organización avanza a su propio ritmo, cambia de opinión y trata el piloto como un experimento sin consecuencias. Para una startup, una «prueba de concepto» de seis meses sin cobrar que no lleva a ninguna parte puede marcar la diferencia entre sobrevivir o no.

Este artículo trata de la mecánica práctica. Para el panorama general de organizaciones que resuelven problemas juntas, consulta Innovación en ecosistema.

Por qué salen mal estas colaboraciones

Las dos partes funcionan con relojes distintos. Una startup mide su margen de supervivencia en meses; una gran organización aprueba presupuestos una vez al año. Los fundadores de una startup deciden en un día; una decisión corporativa puede requerir cuatro firmas y una revisión de compras. Ninguna de las dos se equivoca, pero el desfase produce una y otra vez los mismos fallos:

• La trampa del scouting. Un equipo de innovación conoce a cincuenta startups, organiza un demo day y no tiene ninguna unidad de negocio preparada para usar ninguna.
• El piloto interminable. La prueba se alarga porque nadie acordó qué significaba «éxito», así que nadie puede declararlo.
• La consultoría gratuita. La startup pasa semanas adaptando su producto a tus requisitos, sin cobrar, y después no vuelve a saber nada.
• El muro de compras. El piloto funciona, la unidad de negocio lo quiere y entonces el alta de proveedor, la revisión de seguridad y la licitación tardan un año.

La solución no es el entusiasmo. Es la estructura por tu parte.

Cómo hacerlo, paso a paso

1. Parte de un problema que sea de una unidad de negocio. No «queremos explorar la IA», sino un problema concreto con un responsable concreto que tenga presupuesto y que cambie su forma de trabajar si una solución encaja. Formúlalo como una pregunta ¿Cómo podríamos?: «¿Cómo podríamos reducir el tiempo que nuestro equipo de siniestros dedica a leer formularios escritos a mano?». Si ninguna unidad de negocio se compromete como responsable, no contactes todavía con startups.

2. Decide qué tipo de relación quieres. En líneas generales hay cuatro, y confundirlas hace perder tiempo:

   • Comprar: te conviertes en cliente de un producto que ya funciona. Es lo más rápido y lo más habitual.
   • Pilotar: pruebas un producto que funciona en tu contexto antes de comprarlo.
   • Codesarrollar: construís juntos algo nuevo, normalmente con cuestiones de propiedad intelectual compartida.
   • Invertir: entras en el capital. Otro equipo, otras condiciones, otros plazos. El enfoque venture client, que popularizó el Startup Garage de BMW a partir de 2015, sostiene que la mayoría de las organizaciones deberían empezar comprando y pilotando en lugar de invirtiendo, porque ser cliente de una startup es lo que antes genera valor para ambas partes.

3. Despeja tu circuito interno antes de buscar. Antes de contactar con nadie, averigua qué necesita tu organización para pagar a un proveedor pequeño: alta, revisión de seguridad y de datos, modelo de contrato, condiciones de pago. Acuerda una vía rápida para los pilotos por debajo de un importe determinado. Si no puedes pagar a una startup a las pocas semanas de un piloto con éxito, resuelve eso primero.

4. Busca con el problema, no con una convocatoria de «innovación». Describe el problema, los datos y el entorno disponibles y cómo es un resultado satisfactorio. Las startups que no puedan resolverlo se descartarán solas. Haz la preselección con una breve matriz de decisión ponderada: encaje con el problema, madurez del producto, capacidad de ejecutar en tu entorno, equipo.

5. Decide en días, no en meses. Reúnete con las startups preseleccionadas y decide. A las que descartes, díselo y explícales por qué. El silencio le cuesta más a una startup que un no.

6. Redactad juntos el plan del piloto, en una página. Indica la hipótesis, qué se medirá, el umbral de éxito, la duración, quién lo apoya por tu parte y qué ocurre si se supera. El formato de prueba de hipótesis funciona bien. Usa el mapa de supuestos para encontrar el supuesto más arriesgado y pruébalo primero.

7. Paga el piloto. Incluso unos honorarios modestos cambian la relación: ambas partes se lo toman en serio, la startup puede dedicarle personas y tu organización ya ha pasado los trámites de compras que necesitará más adelante.

8. Pon personas por tu parte. Un piloto necesita un responsable de negocio que vaya a usarlo, un contacto técnico que pueda dar accesos y alguien que elimine bloqueos. Una matriz RACI del piloto lleva diez minutos y ahorra semanas.

9. Decide en la fecha que fijaste. Al final, compara los resultados con el umbral acordado. Si se supera, se pasa a un contrato en condiciones fijadas de antemano. Si no, se para y se dice. «Alarguémoslo un poco» es la respuesta que hace perder el tiempo a todo el mundo; si prorrogas, hazlo una sola vez, por un motivo y con una nueva fecha.

10. Planifica el despliegue antes de que acabe el piloto. Quién lo gestionará, con qué sistemas se conecta, quién forma a los usuarios. Una lista de verificación de despliegue evita que el traspaso se atasque.

Qué hacer y qué evitar

Qué hacer

• Nombrar un responsable de negocio antes de contactar con una sola startup.
• Decir pronto a las startups cuánto puedes pagar, en qué plazo y por qué procedimiento.
• Acordar los criterios de éxito antes de que empiece el piloto.
• Pagar los pilotos, aunque sea poco.
• Proteger la propiedad intelectual de la startup. Ser claro sobre los derechos que necesitas y no pedir más.
• Presentarla a otras unidades si funciona. Una referencia tuya puede valer más que el contrato.

Qué evitar

• Organizar demo days sin responsables con capacidad de compra entre el público.
• Pedir desarrollos a medida durante un piloto. Prueba lo que ya existe.
• Cambiar a la persona responsable a mitad del piloto sin un traspaso en condiciones.
• Dejar que la revisión jurídica empiece después de que el piloto tenga éxito. Iníciala en paralelo.
• Usar los pilotos para recoger ideas sin coste con las que construir algo internamente. Las startups hablan entre ellas y tu reputación corre.
• Medir el programa por el número de startups con las que te has reunido. Mide cuántos pilotos se convirtieron en contratos.

Ejemplo ilustrativo

Ilustrativo. Una aseguradora mediana de los Países Bajos quería reducir el tiempo que su equipo de siniestros dedicaba a los partes domésticos por daños de agua. El director de siniestros aceptó ser el responsable del problema y reservó un pequeño presupuesto para un piloto.

Antes de buscar, la responsable de innovación pasó tres semanas con compras acordando una vía rápida: los pilotos por debajo de un importe determinado podían usar un modelo de contrato breve y pasar una revisión de seguridad más ligera, siempre que ningún dato de clientes saliera de los sistemas de la aseguradora. La convocatoria describía el problema, los datos anonimizados de siniestros disponibles y el objetivo: reducir de forma clara el tiempo de tramitación de los siniestros sencillos manteniendo la precisión al menos en los niveles actuales.

Respondieron doce startups. Se preseleccionaron cuatro con una matriz ponderada; se entrevistó a dos; se eligió una en diez días y a las otras tres se les explicó por qué no habían sido seleccionadas. El plan del piloto cabía en una página: ocho semanas, tres tramitadores, un conjunto definido de tipos de siniestro, un umbral de éxito y un precio de licencia pactado de antemano si se superaba.

El piloto alcanzó el umbral en la mayoría de los tipos de siniestro y no lo alcanzó en uno. El director de siniestros firmó el contrato para los tipos que lo superaron, y el restante pasó a una segunda prueba, más corta.

Preguntas frecuentes

¿Hay que pagar a las startups por una prueba de concepto? Sí, en la mayoría de los casos. Ambas partes se toman en serio un piloto pagado, la startup puede asignarle personas y tu organización se ve obligada a pasar los trámites de compras que necesitará de todos modos. Las pruebas de concepto sin pagar tienden a ir a la deriva y favorecen a las startups que pueden permitirse trabajar sin cobrar, no a las que tienen el mejor producto.

¿Cuánto debe durar un piloto con una startup? Lo necesario para medir el resultado acordado, y nada más. Para un producto que funciona en un proceso definido, lo habitual son entre seis y doce semanas. Si el piloto necesita seis meses, probablemente estéis codesarrollando, y eso requiere otras condiciones.

¿De quién es la propiedad intelectual en un piloto entre una corporación y una startup? Normalmente la startup conserva la propiedad de su producto y de todo lo que aporta, y tú conservas tus datos y lo que crea tu personal. Acordad por escrito qué derechos necesitas para usar los resultados. Los detalles los decide tu equipo jurídico; el principio es pedir solo lo que de verdad necesitas.

Por dónde seguir

Usa las preguntas ¿Cómo podríamos? para plantear el problema antes de buscar, una matriz de decisión ponderada para preseleccionar y una prueba de hipótesis para redactar el plan del piloto. Para el panorama general, lee Innovación en ecosistema; para una convocatoria pública a muchas startups a la vez, consulta Innovación abierta, cocreación y crowdsourcing, y para socios de investigación, Colaborar con universidades en innovación.