En el software, la ventaja ya no será la tecnología. Será la comprensión del contexto.

Durante mucho tiempo, la tecnología fue un verdadero diferenciador.

Quien podía permitirse una gran base Oracle, servidores potentes, una infraestructura seria y los equipos para hacerla funcionar tenía una ventaja competitiva real. El precio de entrada era alto. La tecnología en sí misma construía parte del moat.

Luego llegó el cloud.

Con AWS, Google Cloud, Azure y los demás, los mismos bloques tecnológicos se volvieron accesibles para todos. Ya no hace falta invertir fuerte por adelantado: se puede alquilar bajo demanda. Ya no hace falta ser grande para equiparse como los grandes.

Resultado: la tecnología se ha banalizado en gran medida.

Claro, todavía hay diferencias de ejecución. Algunos construyen mejor que otros. Algunos operan mejor, aseguran mejor, diseñan mejor la arquitectura. Pero el simple hecho de "tener la tecnología" ya no es, por sí solo, un diferenciador duradero.

Y con la IA, vamos a dar un paso más.

Vamos a poder producir más rápido:

• más funcionalidades,
• más pantallas,
• más variantes,
• más contenidos,
• más código.

El coste de producción del software va a seguir bajando. Y por tanto, el número de actores capaces de atacar un mercado va a seguir subiendo.

Pero si cualquiera puede producir rápido y bien, entonces producir rápido y bien ya no es suficiente.

Sacar funcionalidades en serie dejará de ser una ventaja. Será simplemente el nivel de base.

Por eso estoy cada vez más convencido de que, para los editores de software, el verdadero diferenciador se va a desplazar a otro lugar: hacia la comprensión del contexto.

Lo que va a contar es comprender antes de construir

Cuando la tecnología se convierte en commodity, y cuando la capacidad de producción se vuelve abundante, la escasez cambia de sitio.

Ya no está en el "hacer". Está en el "comprender".

Comprender el contexto no es solo escuchar a dos clientes, hacer tres entrevistas y escribir una nota de alcance. Es comprender en profundidad todo lo que encuadra una oportunidad de producto.

Por ejemplo:

• el sector,
• los usuarios,
• los clientes,
• las restricciones técnicas,
• las normas,
• la cultura de campo,
• la competencia.

Dicho de otra manera: los mejores editores no ganarán porque producen más. Ganarán porque comprenden mejor.

Comprender el negocio, de verdad

Muchos equipos de software siguen construyendo funcionalidades sin entender:

• el modelo de negocio del cliente,
• sus arbitrajes,
• sus márgenes,
• sus restricciones operativas,
• sus prioridades reales,
• y su cultura.

Y esa dimensión cultural está lejos de ser secundaria. A menudo es decisiva, especialmente en:

• los grandes grupos,
• las empresas internacionales,
• ciertas verticales muy codificadas.

Dos empresas pueden tener la misma necesidad aparente sobre el papel y esperar en realidad dos cosas muy distintas, simplemente porque no tienen:

• la misma cultura de decisión,
• la misma relación con el riesgo,
• el mismo nivel de centralización,
• la misma relación entre sede y campo,
• las mismas expectativas de estandarización.

Cuando no se entiende eso, se puede construir algo correcto… pero desenfocado.

En un mundo donde cualquiera podrá construir, la verdadera pregunta ya no será: "¿podemos desarrollar esta funcionalidad?" sino más bien: "¿comprendemos suficientemente bien la situación para construir lo correcto?"

Comprender a los usuarios, no a los usuarios imaginarios

A menudo hay un mundo de diferencia entre el usuario que se imagina en un taller y el que trabaja realmente sobre el terreno.

Lo que hay que comprender son:

• sus restricciones,
• sus hábitos,
• sus atajos,
• sus resistencias,
• su carga mental,
• sus soluciones alternativas.

Con la IA, podremos generar interfaces muy rápido. Pero generar rápido una mala respuesta a un problema real sigue siendo… una mala respuesta.

La diferencia se hará en la calidad de comprensión:

• ¿sabemos cómo trabaja la gente de verdad?
• ¿comprendemos qué toleran, qué rechazan, qué no se atreven a decir?
• ¿captamos las diferencias según los roles, los sectores, la madurez digital o el tamaño de la empresa?

Comprender al cliente, no solo al usuario

En B2B, el cliente no es solo "el usuario".

El cliente es también a menudo:

• quien paga,
• quien arbitra,
• quien lidera el proyecto,
• quien tiene que tranquilizar a su jerarquía,
• quien teme el riesgo,
• quien se pregunta si el despliegue será viable.

Un producto puede:

• ser apreciado por los usuarios y aun así no venderse,
• resolver un problema real y aun así bloquearse en el momento de la compra,
• ser bueno, pero incompatible con los criterios de decisión de la organización.

Aquí también, la comprensión del contexto se vuelve central.

Comprender la técnica, pero de otra manera

Decir que la tecnología ya no es el diferenciador principal no significa que ya no importe.

Sigue importando, pero de otra manera.

Lo que va a marcar la diferencia no es solo tener acceso al stack correcto. Es comprender qué es razonable, robusto y sostenible construir en un contexto dado.

Con la IA, podremos producir más código. Pero no tendremos automáticamente:

• más coherencia de arquitectura,
• más fiabilidad,
• más seguridad,
• ni mejores integraciones.

La pregunta se convierte entonces en algo menos de "¿podemos programar eso?" que:

• ¿podemos integrarlo limpiamente?
• ¿podemos mantenerlo?
• ¿podemos asegurarlo?
• ¿podemos hacerlo funcionar en la realidad?

Comprender la competencia, las señales débiles, los ángulos muertos

La otra trampa es pensar el producto de forma aislada.

El mercado se mueve mientras se construye. Los competidores cambian, las expectativas se desplazan, algunos usos se convierten en estándares, otros desaparecen, nuevos actores llegan más rápido que antes.

Con la IA, esa presión va a aumentar todavía más. Habrá más actores capaces de lanzar algo creíble.

Así que habrá que comprender:

• qué hacen los competidores,
• qué prometen,
• qué no saben hacer,
• dónde se estandariza el mercado,
• dónde quedan todavía verdaderos ángulos muertos.

Normas, regulación, trazabilidad: un tema cada vez más central

También creo que seguimos subestimando hasta qué punto el contexto regulatorio y normativo va a ganar valor en los próximos años.

A menudo pensamos en:

• las normas ISO,
• los marcos sectoriales,
• los requisitos de auditoría,
• la ciberseguridad,
• la protección de datos,
• el cumplimiento sectorial.

Pero también hay toda una capa muy concreta, muy de campo, que cobra cada vez más importancia:

• la trazabilidad,
• el archivado,
• la normalización,
• la comparabilidad de los datos,
• la justificación de las desviaciones,
• la legibilidad para las finanzas o el control.

Muy a menudo, eso se traduce en frases muy simples:

• "el controller me pide eso",
• "tenemos que poder justificar ese número",
• "hay que saber quién hizo qué, cuándo y por qué",
• "tiene que ser comparable entre sedes",
• "necesitamos un dato explotable para la auditoría".

Dicho de otra manera, ya no se trata solo de construir una herramienta útil. También hay que construir una herramienta que:

• deje rastros,
• estructure la información,
• haga legibles las decisiones,
• aguante frente a una lógica de auditoría,
• aguante frente a una lógica de pilotaje,
• aguante frente a una lógica de estandarización.

Y eso no es solo técnica. Es una comprensión fina del contexto del cliente.

Lo que va a ganar valor: el documento de contexto

Concretamente, creo que uno de los entregables que más valor va a cobrar en los próximos años no es solo la spec, ni siquiera el roadmap.

Será un verdadero documento de contexto para una oportunidad dada.

Un documento que obliga a explicitar, negro sobre blanco:

• el contexto de negocio,
• el contexto de producto,
• el contexto del cliente,
• el contexto del usuario,
• el contexto técnico,
• las reglas del sector,
• las normas y la regulación,
• la cultura y las prácticas de campo,
• la competencia y las alternativas,
• el historial y las decisiones ya tomadas.

Y un buen documento de contexto no sirve solo para acumular hechos. Sirve también para distinguir:

• lo que sé,
• lo que creo,
• lo que me hace dudar,
• lo que no se dice.

Porque mañana, cuando producir sea más fácil para todos, lo que tendrá valor no será simplemente la capacidad de sacar una solución.

Será la capacidad de:

• enmarcar correctamente el problema,
• documentar el contexto,
• hacer visibles las zonas de riesgo,
• alinear al equipo en una comprensión más profunda de la oportunidad.

De hecho, ese documento de contexto se convierte casi en un activo estratégico.

En el fondo, la ventaja competitiva se desplaza

Creo que entramos en un período donde la ventaja competitiva de los editores de software se va a desplazar de forma muy clara.

Ayer, estaba mucho en el acceso a la tecnología. Hoy, ya está menos ahí. Mañana, con la IA, estará todavía menos en la producción en sí misma.

La verdadera ventaja estará en la calidad de comprensión.

Comprender mejor que los demás:

• el sector,
• los usuarios,
• los clientes,
• las restricciones técnicas,
• las normas,
• la cultura de campo,
• la competencia,
• y todas las señales débiles que cambian la naturaleza de una oportunidad.

Cuando cualquiera puede construir, quien gana no es quien más produce.

Es quien mejor comprende qué construir, para quién, en qué entorno, con qué restricciones, y para crear qué valor.

Ejemplo concreto

• 00-context.md

**Estado** : Borrador / En revisión / Validado
**Responsable** : PM
**Última actualización** : YYYY-MM-DD

# Contexto

## Contexto de negocio
_¿Cuáles son los objetivos de negocio detrás de este tema? ¿Por qué existe? ¿Qué restricciones de negocio se conocen? ¿Esta oportunidad funciona para nuestro modelo económico, nuestro go-to-market, nuestra estrategia?_
_(→ riesgo de viabilidad de negocio)_



## Contexto de producto
_¿Cómo funciona hoy? ¿Cuáles son los límites actuales? ¿Qué se ha intentado o considerado ya?_



## Contexto del cliente
_¿Quién es el cliente (quien paga, quien decide la compra)? ¿Cuáles son sus objetivos, sus criterios de decisión, sus restricciones? ¿Qué motiva o bloquea la compra? ¿Este tema responde a una necesidad que el cliente está dispuesto a pagar?_
_(→ riesgo de valor del lado del comprador)_



## Contexto del usuario
_¿Quién usa el producto en el día a día? ¿Qué usos actuales? ¿Qué pain points conocidos? ¿El usuario va a entender y adoptar la solución? ¿Diferencias según los segmentos o los roles?_
_(→ riesgo de valor + riesgo de usabilidad)_



## Contexto técnico
_¿Qué elementos técnicos es útil conocer? ¿Podemos construir lo que contemplamos con nuestras competencias, nuestra stack y nuestros plazos? ¿Restricciones de datos o tracking? ¿Dependencias importantes?_
_(→ riesgo de viabilidad)_



## Reglas del sector
_¿Qué reglas sectoriales ya existen en nuestro CMMS sobre este tema? ¿Cómo gestionan esto hoy nuestros clientes en sus procesos? ¿Lógicas de validación, cálculo, derechos, workflow ya en marcha?_



## Normas y regulación
_¿Qué normas (ISO, EN, NF…) u obligaciones regulatorias se aplican? ¿Qué impacto tienen en lo que podemos o debemos construir? ¿Hay requisitos de trazabilidad, conformidad, auditoría?_



## Cultura y prácticas de campo
_¿Cómo trabajan realmente los equipos de campo? ¿Qué hábitos según el sector (industria, terciario, salud…) o el tamaño de empresa? ¿Qué percepciones, resistencias o expectativas específicas hay que tener en cuenta?_



## Competencia y alternativas actuales
_¿Cómo resuelven hoy los clientes este problema? ¿Qué competidor, qué herramienta interna, qué proceso manual (Excel, papel…)? ¿Qué funciona o no funciona en esas alternativas?_



## Historial y decisiones
_¿Decisiones ya tomadas sobre este tema? ¿Arbitrajes históricos útiles? ¿Elementos que no conviene reabrir sin motivo?_

Para saber más

El PM como arquitecto del Contexto Seguimiento de la competencia: copiar a los competidores no es una estrategia Wiki IA: por qué construí una base de conocimiento mantenida por una IA