El entregable ya no es el capital

Durante mucho tiempo vi el entregable como el resultado principal del trabajo.

Un documento está terminado. Una presentación se ha enviado. Una spec se ha compartido. Un artículo se ha publicado. Una respuesta a un pliego ha vuelto al cliente.

Se ha producido algo.

Así que el trabajo parece hecho.

Pero cuanto más uso la IA con contextos, más incompleta me parece esa evidencia.

El entregable es visible.

Es necesario.

Pero no siempre es el capital de verdad.

El documento final consume un pensamiento

Un entregable se hace para un uso.

Responde a un público, a un momento, a una restricción de forma. Una spec habla a los desarrolladores. Un pitch habla a un CPO. Una documentación de soporte habla a un equipo que tiene que responder rápido. Un artículo habla a lectores que aún no conocen el tema. Una respuesta a un pliego habla a un cliente con sus propias casillas, su numeración, su vocabulario.

Cada entregable selecciona, simplifica, reformula y ordena el material para una necesidad precisa.

Es normal. De hecho, es su papel.

Pero darle esa forma tiene un coste: parte del pensamiento que permitió producir el entregable desaparece detrás de él.

Ves el documento final.

Ya no ves siempre las fuentes, las dudas, las alternativas descartadas, los ejemplos que quedaron fuera, las decisiones intermedias, las contradicciones, los matices que guardaste en la cabeza pero no en la versión enviada.

El entregable lleva el resultado.

No lleva necesariamente el razonamiento.

El problema empieza en el segundo entregable

Esto pasa desapercibido mientras solo hay una salida que producir.

Trabajas un material. Escribes un documento. Lo envías. Fin.

Pero en la vida real, el mismo fondo suele tener que servir varias veces.

A partir del mismo material, quizá haya que producir:

• una spec funcional;
• user stories;
• un pitch para la dirección;
• una nota para el equipo comercial;
• una documentación de soporte;
• un plan de pruebas;
• una respuesta a un pliego;
• un artículo;
• una síntesis corta para una reunión.

En un workflow clásico, cada formato nuevo da la sensación de empezar de cero.

Vuelves al documento anterior. Copias y pegas. Reformulas. Quitas lo que no habla al nuevo público. Añades lo que falta. A veces olvidas un matiz. Dos versiones empiezan a divergir.

Esto no solo es pesado.

Es peligroso.

Soporte puede recibir una explicación distinta de la que se dio al equipo comercial. La spec puede contener una hipótesis que ya no está en el pitch. La respuesta al pliego puede reutilizar una formulación antigua que ya no es cierta. El artículo puede aplanar una distinción importante porque el material disponible ya está sesgado.

El problema no es producir varios documentos.

El problema es tomar un entregable como fuente principal del entregable siguiente.

Una salida no es una fuente de verdad

Un documento final es una salida.

Puede ser muy bueno.

Pero se escribió para un contexto de uso preciso.

Por eso contiene decisiones que no siempre pertenecen al conocimiento mismo: el tono, el nivel de detalle, los ejemplos, el orden, el grado de prudencia, la forma de nombrar las cosas, lo que revelas y lo que no, lo que supones ya sabido.

Si partes de ese documento para producir todo lo demás, heredas sus decisiones.

A veces resulta útil.

A menudo encierra.

Una frase escrita para tranquilizar a un cliente no es necesariamente una buena base para una documentación interna. Una diapositiva de dirección no es una buena base para una user story. Una respuesta corta en una tabla no es una buena base para entender la decisión de producto.

El entregable está sesgado.

El conocimiento de trabajo debería seguir siendo más neutro.

El mundo de las ideas

Por eso me parece útil añadir una capa intermedia entre las fuentes y los entregables.

Yo lo llamo el mundo de las ideas.

No es un nombre muy técnico.

Pero dice bien lo que tiene que hacer.

El mundo de las ideas reúne lo que se ha comprendido, antes de transformarlo para un público concreto.

Ahí puedes encontrar:

• notas atómicas;
• notas temáticas;
• definiciones;
• hipótesis;
• contradicciones;
• decisiones;
• ejemplos;
• límites;
• relaciones entre ideas;
• puntos a verificar.

Ese material todavía no habla a un cliente, a un desarrollador o a un lector.

Habla al trabajo mismo.

Su papel no es ser elegante.

Su papel es ser reutilizable.

Una nota no debe convertirse en un gancho

Este punto es más sutil de lo que parece.

Cuando escribes un artículo, te apetece convertir una idea directamente en frase.

Cuando preparas una presentación, te apetece convertir una idea directamente en bullet de diapositiva.

Cuando escribes una spec, te apetece convertir una idea directamente en requisito.

El problema es que la nota se convierte ya, así, en un fragmento del entregable.

Pierde su neutralidad.

Una buena nota tiene que mantener el conocimiento en un nivel en el que podrá reexpresarse de otra manera.

Puede contener una distinción, una prueba, una hipótesis, un arbitraje, un matiz. Pero no debe quedar prisionera del artículo, de la diapositiva o de la spec del momento.

El build es lo que produce.

La nota sirve para conservar lo que podrá producir después.

La diferencia parece pequeña.

Lo cambia todo cuando vuelves tres semanas más tarde.

La IA hace esta separación mucho más útil

Antes de la IA, mantener esa capa intermedia podía parecer pesado.

Ya se podían tomar notas limpias, guardar fuentes, crear síntesis. Pero producir después varios entregables seguía siendo un trabajo manual considerable.

Con la IA, esa separación resulta mucho más rentable.

Si el material está bien organizado, la IA puede ayudar a recomponerlo.

Puede producir una versión larga, una versión corta, una versión comercial, una versión técnica, una versión prudente, una versión didáctica.

Puede adaptar el mismo conocimiento a varios públicos.

Pero, para hacerlo correctamente, tiene que partir de la capa correcta.

No solo del último documento enviado.

No solo de un chat.

No solo de un PDF final.

Tiene que poder volver a las fuentes, a las notas, a las decisiones, a los límites, a los puntos aún inciertos.

Entonces el trabajo cambia de naturaleza.

Ya no produces solamente un documento.

Construyes un material que puede producir.

El capital es lo que queda después de la salida

Una buena pregunta que hacerse después de cada entregable es simple:

¿qué queda?

No solo: ¿dónde está el archivo?

Sino:

• ¿qué ideas se han estabilizado?
• ¿qué fuentes sostienen esas ideas?
• ¿qué decisiones se han tomado?
• ¿qué alternativas se han descartado?
• ¿qué formulaciones se han validado?
• ¿qué puntos siguen siendo frágiles?
• ¿qué elementos podrán servir a otro público?

Si la respuesta es "nada, salvo el documento final", entonces buena parte del trabajo se ha consumido.

El entregable se ha producido.

Pero el capital no se ha construido.

Al contrario, si el trabajo deja tras de sí notas, fuentes conectadas, decisiones, preguntas abiertas, formulaciones probadas, niveles de confianza, entonces el próximo entregable no partirá de cero.

El resultado visible es el documento.

El capital es la capacidad de rehacer, adaptar, explicar, defender y prolongar.

Esto cambia la manera de trabajar

La idea puede parecer abstracta.

Se vuelve muy concreta en una semana de trabajo.

Una entrevista con un usuario no sirve solo para escribir un informe. Puede alimentar una nota de producto, una decisión, una hipótesis, un ejemplo para una futura presentación.

Un pliego no sirve solo para responder a un cliente potencial. Puede enriquecer una memoria de preguntas recurrentes, respuestas validadas, pruebas y límites de divulgación.

Un artículo no sirve solo para publicar un pensamiento. Puede estabilizar ideas que más tarde alimentarán un libro, una formación, un método, una discusión de producto.

Una spec no sirve solo para desarrollar una funcionalidad. Puede guardar el rastro de arbitrajes que permitirán entender, seis meses más tarde, por qué el producto funciona así.

En todos estos casos, el entregable no es inútil.

Sigue siendo indispensable.

Pero se convierte en una salida entre otras.

Ya no agota el valor del trabajo.

El documento correcto en el lugar correcto

No creo que haya que despreciar los entregables.

Al contrario.

Un buen entregable es a menudo lo que hace el trabajo transmisible. Obliga a aclarar, a elegir, a cortar, a formular. Pone el pensamiento en contacto con un público real.

Pero hay que dejar de pedirle que lo cargue todo.

El documento final no tiene por qué contener todas las fuentes.

No tiene por qué conservar todas las alternativas.

No tiene por qué exponer todas las incertidumbres.

No tiene por qué convertirse en la memoria completa del tema.

Tiene que hacer su trabajo de entregable.

Y la memoria del trabajo tiene que existir en otro lugar.

Es exactamente lo que permite un contexto.

El contexto conserva el material.

El build produce las salidas.

El humano se queda con el juicio.

La IA ayuda a recomponer.

El desplazamiento de valor

El desplazamiento me parece importante.

Antes capitalizábamos sobre todo los documentos.

Guardábamos las specs, las presentaciones, las notas de reunión, los informes, los pliegos respondidos.

De ahora en adelante habrá que capitalizar más el material que permite producirlos.

No es lo mismo.

Capitalizar un entregable es conservar una forma pasada.

Capitalizar un contexto es conservar una capacidad futura.

El entregable dice: esto es lo que hemos enviado.

El contexto dice: esto es lo que hemos comprendido, decidido, verificado, descartado, y lo que todavía podemos producir a partir de ahí.

Por eso el entregable ya no es el capital principal.

Sigue siendo la parte visible.

Pero el valor que dura se desplaza hacia lo que permite producir varias veces sin perder el fondo.

El documento se va.

El pensamiento organizado se queda.

Para saber más

El PM como arquitecto del Contexto Fuente de sesión: lo que tus documentos no capturan Bajo el capó de mi motor de contexto: cómo una IA recuerda una misión El segundo cerebro es un callejón sin salida para el product management En el software, la ventaja ya no será la tecnología. Será la comprensión del contexto.