Que una tecnología funcione no significa todavía que esté construida como una propuesta que otra persona pueda comprender, valorar y defender dentro de su propia organización.
Hay un momento especialmente interesante en algunos proyectos tecnológicos: ya no hay que demostrar sólo que algo funciona.
La tecnología ha sido validada. Quizá exista un piloto, datos suficientes o una primera aplicación real. El equipo conoce bien lo que ha construido.
Y entonces cambia el problema.
Hasta ese momento buena parte del esfuerzo estaba orientado a responder una pregunta:
¿Funciona?
Cuando aparece un cliente, un inversor, un socio industrial o un comité, empiezan a aparecer otras:
¿Qué cambia para nosotros si adoptamos esto?
¿Por qué merece la pena hacerlo ahora?
¿Qué riesgo reduce?
¿Qué coste o dificultad introduce?
¿Por qué esta alternativa y no otra?
La tecnología sigue siendo la misma. Lo que ha cambiado es la situación en la que debe explicarse.
Y eso obliga a distinguir dos cosas que conviene no mezclar.
Describir algo no es lo mismo que proponerlo
Una descripción explica qué es una tecnología, cómo funciona, qué arquitectura tiene, qué resultados ha obtenido o en qué se diferencia técnicamente.
Todo eso puede ser necesario.
Una propuesta añade otra capa: organiza esa información alrededor de lo que está en juego para la persona que escucha.
No sustituye el rigor técnico.
Lo coloca dentro de una situación.
Porque quien tiene que valorar una propuesta puede necesitar entender suficientemente la tecnología, pero también necesita saber qué consecuencia tiene para su organización, qué tendría que cambiar, qué riesgo asume y por qué merece la pena seguir avanzando.
La pregunta deja de ser únicamente:
¿Lo he explicado correctamente?
Y pasa a incluir:
¿He explicado lo necesario para que esta persona pueda valorar lo que le estoy proponiendo?
No son exactamente la misma pregunta.
Seleccionar no es rebajar el proyecto
Aquí aparece una dificultad.
Cuando un equipo ha invertido mucho tiempo en construir algo, es lógico que casi todo le parezca relevante.
Cada decisión tiene una razón.
Cada detalle técnico puede tener detrás meses de trabajo.
Cada dato puede demostrar algo importante.
Pero una presentación concreta no tiene que contener el proyecto entero.
Tiene que contener lo que esa situación necesita.
Eso no significa hacer la tecnología más simple de lo que es.
Significa jerarquizar.
Decidir qué debe entenderse primero.
Qué necesita explicación adicional.
Qué evidencia es imprescindible.
Y qué información puede quedar disponible para cuando alguien pregunte por ella.
La profundidad no desaparece. Cambia de lugar.
Un ejemplo
Imaginemos una tecnología industrial que ha superado correctamente un piloto.
El responsable técnico tiene veinte minutos para presentarla ante una empresa que está valorando adoptarla.
Puede utilizar esos veinte minutos explicando con enorme precisión el funcionamiento del sistema, los ensayos realizados y los datos obtenidos.
La presentación puede ser impecable desde el punto de vista técnico.
Pero el interlocutor puede terminar la reunión sin tener suficientemente claro qué cambia en su operación, qué esfuerzo exige la adopción, qué riesgo evita o qué argumento necesitaría trasladar después a dirección.
No habría fallado la tecnología.
Ni necesariamente la explicación técnica.
Faltaría construir otra parte de la propuesta.
La pregunta que cambia el trabajo
Una pregunta que me resulta útil en estas situaciones es:
¿Qué necesitaría comprender esta persona para poder explicar después, con sus propias palabras, por qué merece la pena seguir adelante?
Esa pregunta obliga a salir durante un momento del proyecto.
Ya no organizas la presentación desde todo lo que sabes.
La organizas desde lo que necesita ocurrir al otro lado.
Y eso modifica qué información entra, en qué orden aparece y cuánto contexto necesita cada parte.
De funcionar a poder ser valorada
“Propuesta comprable” me interesa como forma de nombrar este paso, no como una fórmula universal.
No significa que alguien vaya a comprarla.
Ninguna narrativa puede prometer eso.
Significa algo más concreto: que aquello que funciona técnicamente se ha trabajado también para que una persona ajena al proyecto pueda entender qué se le propone, qué consecuencias tiene y qué tendría que valorar para avanzar.
Ahí el trabajo técnico y el narrativo no compiten.
Se complementan.
La tecnología aporta lo que es verdad.
La narrativa decide cómo organizar esa verdad para esta situación concreta.
Y ése puede ser el siguiente problema cuando conseguir que algo funcione deja de ser el único desafío.