Tratar los datos como parte del producto cambia cuándo consideramos terminada una funcionalidad: no basta con que la pantalla cargue y la API responda. La información también debe ser correcta, comprensible, actual, observable y tener un responsable.
El equipo había terminado la nueva pantalla de catálogo.
El diseño estaba aprobado. Las pruebas pasaban. La API respondía en menos de 200 milisegundos. El despliegue había salido bien y los paneles estaban en verde.
Dos días después llegaron los primeros avisos.
- Había productos que aparecían como disponibles aunque ya no se podían vender.
- Algunos clientes estaban duplicados.
- Los estados de la aplicación no coincidían con los del ERP.
- Dos informes construidos sobre la misma actividad ofrecían cifras diferentes.
El frontend funcionaba.
También el backend.
El producto, en cambio, no.
No había una excepción clara que perseguir. Tampoco un servicio caído al que culpar. Los procesos de sincronización habían terminado correctamente y la API seguía devolviendo su impecable 200 OK.
Sin embargo, solo había un pequeño inconveniente: el usuario estaba tomando decisiones con información equivocada.
Esta escena se repite más de lo que solemos reconocer. Diseñamos pantallas, servicios, permisos e infraestructura. Después conectamos un ERP, un CRM, una base de datos o una API y damos por supuesto que los datos llegarán con el significado, la calidad y la actualidad que necesita la funcionalidad.
Ese supuesto sale caro.
En consecuencia, una pantalla rápida con información incorrecta sigue siendo un mal producto. Del mismo modo, una API disponible que entrega datos obsoletos sigue fallando. Y un informe que nadie sabe interpretar tampoco está terminado.
La tesis del artículo
Si una funcionalidad depende de un dato, ese dato forma parte de la funcionalidad. No es combustible invisible ni algo que «ya vendrá del sistema». Hay que diseñarlo, probarlo, documentarlo, observarlo y asignarle responsables con el mismo cuidado que aplicamos al código.
TL;DR
- Un error de datos es un error de producto, aunque no genere una excepción.
- La calidad necesita requisitos medibles, no la frase «el dato debe estar actualizado».
- Una API es una experiencia de producto para sus consumidores.
- Ownership significa responsabilidad sobre significado, contrato, calidad y operación.
- La observabilidad debe cubrir servicios, datos y resultado para el usuario.
- Un sistema legacy necesita una frontera de traducción, no convertirse en el contrato de todos los productos nuevos.
En esta guía aprenderás
- Qué significa realmente «Data is a Feature».
- Por qué el usuario no distingue un error de código de uno de datos.
- Cómo seguir el recorrido de un dato hasta la decisión.
- Cómo convertir la calidad en requisitos verificables.
- Por qué una API también es experiencia de producto.
- Cómo repartir el ownership sin crear otro buzón de tickets.
- Qué observar además de CPU, memoria y errores HTTP.
- Cómo desacoplar el producto nuevo de un sistema legacy.
- Cómo empezar con una sola funcionalidad crítica.
Qué significa tratar los datos como parte del producto
Decir que los datos son una feature puede sonar a otra etiqueta creada para presentar una idea antigua como si acabara de llegar. Y, en parte, lo es: llevamos décadas construyendo productos que dependen de datos.
La diferencia está en cómo los tratamos.
Normalmente, una historia de usuario describe lo que la persona podrá hacer: buscar un producto, consultar un pedido, comparar resultados o recibir una alerta. Después aparecen los componentes, los endpoints y las tareas de desarrollo.
Los datos suelen quedar escondidos en una frase:
La información se obtendrá del ERP.
Fin del diseño.
Pero «obtenerla del ERP» no responde a casi ninguna de las preguntas importantes:
- ¿Qué información necesita realmente el usuario?
- ¿Cuál es la fuente autorizada para cada campo?
- ¿Qué significa exactamente cada estado?
- ¿Cuánto retraso podemos aceptar?
- ¿Qué hacemos si falta un valor?
- ¿Cómo detectamos un registro duplicado?
- ¿Quién decide si dos sistemas se contradicen?
- ¿Qué consumidores se romperán cuando cambie el contrato?
- ¿Quién actúa cuando el dato deja de ser fiable?
Tratar los datos como parte del producto significa responder a esas preguntas durante el diseño. No tres semanas después del despliegue, cuando un usuario descubre la respuesta por nosotros.
No es exactamente lo mismo que «Data as a Product»
Las dos ideas están relacionadas, pero no son idénticas.
Data as a Product propone ofrecer conjuntos de datos como productos reutilizables: con consumidores identificados, documentación, contratos, niveles de servicio y ownership.
Data is a Feature mira la funcionalidad que ya estás construyendo y hace una pregunta más directa: ¿hemos diseñado la información con la que el usuario va a trabajar o solo hemos diseñado el lugar donde aparecerá?
La primera puede llevarte a una estrategia transversal. La segunda se puede aplicar mañana a una sola historia de usuario.
Este es el cambio práctico de tratar los datos como parte del producto: la información deja de ser una dependencia implícita y entra en la definición de lo que estamos construyendo.
Una forma sencilla de empezar
Añade esta pregunta a la definición de terminado: ¿qué debe ser cierto sobre los datos para que el usuario pueda confiar en esta funcionalidad?
Errores de datos, errores de producto: al usuario le da igual dónde se rompió
Imagina una aplicación ferroviaria que muestra que un tren sigue en la vía 4 cuando ya ha sido trasladado a la vía 6.
La pantalla se ha renderizado perfectamente. El endpoint ha respondido con un 200 OK. La caché funciona. La latencia es excelente.
Sin embargo, nada de eso le sirve a la persona que espera en el andén equivocado.
El fallo puede estar en un evento que no llegó, en una fuente desactualizada, en la normalización de un identificador o en una regla de prioridad mal definida. Son explicaciones útiles para diagnosticar el problema, pero no cambian cómo lo vive el usuario.
Para él, la aplicación está mal.
Del mismo modo, sucede cuando:
- una tienda permite comprar un producto sin stock;
- un campus muestra una convocatoria cerrada como disponible;
- un CRM crea dos identidades para el mismo cliente;
- un cuadro de mando calcula bien una métrica sobre datos incompletos;
- una aplicación muestra como activo un servicio cancelado en el sistema de origen.
Cuando «problema de datos» se convierte en excusa
El usuario no sabe —ni debería tener que saber— si el problema está en React, en una transformación, en una cola, en la API, en el ERP o en un dato introducido hace tres años.
Los equipos, en cambio, sí solemos hacer esa distinción. Clasificamos una incidencia como «problema de datos» y, casi sin darnos cuenta, la alejamos del producto. Como no hay una excepción, un timeout o un servicio caído, parece menos técnica. Incluso menos urgente.
Pero si asumimos los datos como parte del producto, esa etiqueta deja de servir como excusa para desplazar la incidencia fuera del equipo que responde por la experiencia completa.
Clasificarlo solo como «problema de datos» es una mala lectura.
Una aplicación que no responde bloquea una decisión. Una aplicación que responde con seguridad y rapidez, pero ofrece información incorrecta, puede ayudar a tomarla mal.
Los errores de datos son errores de producto, aunque no aparezcan en el registro de errores.
Una pantalla empieza mucho antes del frontend
Cuando vemos una ficha de producto, un expediente, una ruta o un pedido, solemos pensar en la pantalla que lo presenta. Pero esa pantalla es el último tramo de un viaje bastante más largo:
El dato atraviesa tres zonas antes de llegar al usuario
No viaja directamente de una tabla a una pantalla. En cada zona cambia de contexto y puede ganar —o perder— significado.
1. Origen
Sistema de origen → extracción o evento
Determina de dónde sale la información, cuándo se captura y con qué antigüedad llega.
2. Interpretación
Validación → modelo → reglas de negocio
Comprueba el dato, normaliza su forma y lo convierte en un concepto que el producto pueda utilizar.
3. Producto
Contrato → interfaz → decisión
Expone un significado estable y lo presenta en el momento en el que el usuario necesita actuar.
La pantalla es el final del recorrido. La calidad del producto depende de todo lo que ha ocurrido antes.
Cada paso puede conservar el significado, enriquecerlo o deformarlo.
Un código 03 puede significar «disponible» en el ERP, pero «pendiente» en una integración histórica. Una fecha sin zona horaria puede cambiar de día al llegar al navegador. Un cliente puede tener un identificador comercial y otro contable. Un proceso puede publicar correctamente solo el 70 % de los registros porque el resto no supera una validación que nadie está midiendo.
La información llega a la pantalla, sí. La cuestión es qué ha ocurrido durante el trayecto.
Preguntas que debería responder el diseño técnico
- ¿Cuál es la fuente autorizada para cada concepto importante?
- ¿Qué transformaciones se aplican entre origen y destino?
- ¿Cómo tratamos valores ausentes, desconocidos o contradictorios?
- ¿Cuánta latencia y antigüedad tolera el caso de uso?
- ¿Qué reglas determinan si un registro puede publicarse?
- ¿Quién consume cada campo y con qué propósito?
- ¿Podemos reconstruir el recorrido de un dato concreto?
Si no conoces ese camino, cada incidencia obliga a repetir el mismo ritual: abrir la aplicación, consultar la API, revisar una tabla intermedia, preguntar al equipo del ERP y tratar de adivinar en qué punto cambió el valor.
Eso no es observabilidad.
Es arqueología con JSON.
«Datos de calidad» no es un requisito
«Necesitamos datos de calidad» queda estupendamente en una reunión.
El problema es que no dice qué debe construir desarrollo, qué tiene que probar QA ni qué debería vigilar operaciones. Es una aspiración, no un requisito.
Para hacerla útil hay que convertirla en condiciones verificables.
Definir los datos como parte del producto obliga a concretar qué significa «bien» para cada decisión y cuánto error estamos dispuestos a aceptar.
Seis dimensiones de calidad para datos como parte del producto
| Dimensión | Pregunta práctica | Ejemplo de fallo |
|---|---|---|
| Exactitud | ¿Representa correctamente la realidad? | Un pedido entregado aparece como pendiente. |
| Completitud | ¿Están presentes los campos necesarios? | Un producto carece de precio o identificador. |
| Consistencia | ¿Coincide el significado entre sistemas? | «Cliente activo» significa algo distinto en CRM y ERP. |
| Actualidad | ¿Llega dentro del intervalo que necesita la decisión? | El stock publicado tiene dos horas de antigüedad. |
| Unicidad | ¿Representamos una sola vez la misma entidad? | El CRM crea dos identidades para el mismo cliente. |
| Validez | ¿Respeta formato, catálogo y reglas de negocio? | La fecha final es anterior a la fecha de inicio. |
La frescura merece una precisión especial. No es una propiedad universal. La dirección fiscal de un cliente quizá pueda sincronizarse cada noche. El stock de una venta o un cambio de vía no.
Criterios de aceptación para datos como parte del producto
En vez de escribir:
El catálogo debe estar actualizado.
Podemos definir:
- al menos el 99 % de los productos activos debe publicarse;
- ningún producto sin identificador puede llegar a la API pública;
- el stock mostrado no puede tener más de cinco minutos de antigüedad;
- cada registro rechazado debe quedar identificado y trazado;
- una sincronización fallida debe generar una alerta;
- el equipo debe poder reconciliar origen y destino por identificador.
Ahora sí hay algo que implementar, probar y operar.
También hay algo sobre lo que discutir. Quizá el 99 % no sea suficiente. Quizá cinco minutos sean demasiados. Perfecto: esa conversación es precisamente la que necesitamos tener antes de que el dato llegue al usuario.
Lo que no se convierte en una expectativa verificable acaba dependiendo de que alguien «se dé cuenta».
Las APIs convierten los datos en experiencia de producto
Cuando una aplicación expone datos mediante una API, es fácil verla como una tubería: recibe una petición y devuelve JSON. Si el esquema valida y el servidor responde, trabajo terminado.
No para quien tiene que utilizarla.
Para otro equipo, un cliente o una integración, la API es la interfaz. Sus nombres, estados, errores y reglas determinan si la integración se completa en dos días o empieza a acumular parches desde el primer curl.
Pensemos en esta respuesta:
{
"status": 3,
"date": "2026-08-07"
}Es JSON válido. También es una pequeña fábrica de preguntas.
¿Qué significa 3? ¿La fecha corresponde al dato de origen, a su publicación o al día para el que es válido? ¿Qué zona horaria utiliza? ¿Puede aparecer un estado 4 mañana? ¿null significa «desconocido» o «no aplicable»?
En cambio, una respuesta más expresiva elimina parte de esa incertidumbre:
{
"status": {
"code": "AVAILABLE",
"label": "Disponible"
},
"source_updated_at": "2026-08-07T10:42:00Z",
"published_at": "2026-08-07T10:43:12Z"
}
El contrato debe explicar los datos, no el almacenamiento
No propongo llenar cada respuesta de metadatos «por si acaso». Eso también genera ruido. Propongo diseñar el contrato desde la perspectiva de quien debe entenderlo, integrarlo y mantenerlo.
Diseñar los datos como parte del producto cambia la documentación de la API: el contrato debe explicar el dominio, no limitarse a reproducir la estructura del almacenamiento.
- Nombres vinculados al dominio, no a las columnas de una tabla.
- Semántica y catálogos documentados.
- Tratamiento explícito de nulos y valores desconocidos.
- Paginación y filtros coherentes.
- Errores que permitan actuar.
- Ejemplos realistas, no solo un esquema vacío.
- Versionado y compatibilidad hacia atrás.
- Procedencia y fecha de actualización cuando cambian la decisión.
- Reglas claras para modificar o retirar campos.
Mi criterio aquí es bastante firme: una API difícil de interpretar no está simplificando el sistema; está repartiendo su complejidad entre todos los consumidores. Y cada consumidor la resolverá a su manera.
Data ownership: el dato no puede ser siempre de otro equipo
Hay una conversación que se repite en muchas organizaciones.
- Producto avisa de que el dato se muestra mal.
- Desarrollo responde que la API ya lo devuelve así.
- El equipo del ERP explica que el campo nunca se diseñó para ese uso.
- Datos confirma que la transformación se ejecutó.
- Operaciones señala que el proceso terminó correctamente.
Todos tienen razón.
El usuario sigue teniendo el dato equivocado.
Cuando nadie es responsable del significado y la calidad, cada equipo protege su tramo de la tubería. El origen envió algo. La transformación hizo lo que tenía configurado. La API publicó lo que recibió. La interfaz lo mostró.
La cadena funciona, pero el resultado completo no tiene dueño.
Ownership funcional, técnico y operativo
| Responsabilidad | Pregunta que debe poder responder |
|---|---|
| Propietario del significado | ¿Qué representa el dato y qué reglas lo definen? |
| Propietario técnico | ¿Cómo se genera, transforma, transporta y almacena? |
| Responsable de producto | ¿Cómo afecta a la experiencia y a la decisión del usuario? |
| Consumidores | ¿Qué sistemas y procesos dependen del contrato? |
| Respuesta operativa | ¿Quién actúa si se incumple la calidad o la frescura esperada? |
Ownership no significa crear un «equipo de datos» al que reenviar cualquier incidencia. Eso solo cambia el destino del ticket.
Sin ownership, la promesa de tratar los datos como parte del producto queda incompleta: todos mantienen una pieza, pero nadie responde por el resultado.
En la práctica, significa asignar responsabilidad sobre cuatro cosas: significado, contrato, calidad y operación.
Y esa responsabilidad necesita autoridad. Nombrar a un propietario que no puede cambiar una regla, rechazar un registro o coordinarse con el sistema de origen añade una casilla a un documento, no una solución.
Observabilidad de datos: paneles verdes, producto roto
La observabilidad tradicional responde bien a preguntas importantes:
- ¿Está disponible el servicio?
- ¿Cuánto tarda en responder?
- ¿Ha fallado el proceso?
- ¿Se está agotando algún recurso?
Necesitamos esas respuestas. Pero no bastan.
Observar los datos como parte del producto significa comprobar no solo que el proceso vive, sino que la información sigue siendo útil para la tarea que pretendemos resolver.
Podemos tener CPU, memoria, latencia y tasa de errores dentro de rango mientras publicamos un 40 % menos de registros, la mitad de los productos pierde su categoría o el último dato disponible acumula seis horas de retraso.
El sistema funciona.
La información se está degradando.
Tres niveles de observabilidad
1. Técnica
Sabemos si servicios, procesos y dependencias están funcionando.
2. De datos
Sabemos si la información conserva el volumen, el esquema, la calidad y la actualidad esperados.
3. De producto
Sabemos si el usuario puede completar correctamente la tarea para la que construimos la funcionalidad.
En la capa de datos podemos medir:
- registros recibidos, procesados, publicados y rechazados;
- duplicados detectados;
- valores nulos inesperados;
- cambios anómalos de volumen;
- retraso respecto a la fuente;
- antigüedad del último dato publicado;
- diferencias entre origen y destino;
- rupturas de esquema;
- transformaciones aplicadas;
- consumidores potencialmente afectados.
En el tercer nivel conectamos esas señales con lo que sucede en el producto: búsquedas sin resultados por datos mal categorizados, pedidos cancelados por divergencias de stock, informes que dejan de cuadrar o usuarios que abandonan un proceso porque falta información.
«El job terminó correctamente» solo confirma que terminó. No que el resultado sea correcto.
Cómo desacoplar los datos del producto de un sistema legacy
En un sistema legacy, los datos cargan con años de decisiones acumuladas.
Con el tiempo, una tabla creada para operar el negocio acaba alimentando informes, una web, varias exportaciones y tres integraciones. Los códigos internos escapan del ERP y aparecen en APIs públicas. Una columna nacida para resolver una excepción temporal termina convertida en una regla de negocio permanente.
No culpo al legacy por esto. Muchos de esos sistemas llevan años sosteniendo operaciones críticas y contienen más conocimiento del negocio que cualquier documentación reciente.
El problema aparece cuando obligamos a cada producto nuevo a hablar su dialecto.
El atajo que crea acoplamiento
Aplicación moderna → consulta o API → ERP legacy
- Cada consumidor aprende a interpretar códigos y excepciones internas.
- Las mismas reglas de traducción terminan replicadas en varias aplicaciones.
- Cualquier cambio en el ERP puede romper productos que, en teoría, eran independientes.
El ERP deja de ser solo el origen de los datos y acaba dictando el contrato del producto.
Al principio funciona. Después cada consumidor aprende qué significa ESTADO = 3, cómo combinar cinco columnas y qué registros debe excluir. La lógica se replica. Los cambios se vuelven peligrosos. El modelo interno del ERP se convierte, sin haberlo decidido, en el contrato de toda la organización.
El atajo empieza a cobrar intereses.
Una alternativa más sostenible es introducir una frontera:
Una frontera para proteger los datos del producto
La alternativa no empieza reescribiendo el ERP. Empieza evitando que sus decisiones internas se propaguen a cada producto nuevo.
1. Encapsular el origen
ERP legacy → extracción controlada
Se extraen únicamente los campos autorizados sin exponer la base operativa ni su esquema completo.
2. Traducir el dominio
Capa anticorrupción → validación → modelo canónico
Los códigos, fechas e identificadores internos se convierten en conceptos de negocio comprensibles y verificables.
3. Publicar un contrato estable
API versionada → aplicaciones e integraciones
Los consumidores reciben un contrato predecible que puede evolucionar sin copiar las peculiaridades del legacy.
Resultado: el ERP puede conservar su dialecto. El producto moderno ya no necesita aprenderlo.
Qué debe hacer la capa anticorrupción con los datos
El nombre «capa anticorrupción» puede sonar más aparatoso de lo que es. No tiene por qué ser una nueva plataforma, un lago de datos ni seis meses de arquitectura en una pizarra.
Puede empezar como un adaptador bien definido para una sola funcionalidad.
Su trabajo consiste en proteger al producto moderno de las particularidades del origen:
- traducir códigos internos a conceptos de negocio;
- normalizar fechas, identificadores y estados;
- validar qué información puede publicarse;
- registrar la procedencia y las transformaciones;
- desacoplar los ritmos de evolución;
- evitar consultas externas contra la base operativa;
- ofrecer un contrato estable a los consumidores.
Este enfoque permite modernizar de forma incremental. No necesitas reescribir el ERP para mejorar cómo una nueva aplicación utiliza sus datos. Construyes una frontera, la observas y amplías su alcance conforme aparecen nuevos casos.
También hay una parte menos vistosa: reconciliar origen y destino durante la transición. Comparar volúmenes. Revisar diferencias. Demostrar que el nuevo flujo representa correctamente las reglas existentes antes de retirar el anterior.
No queda tan bien en un diagrama como la caja «API moderna».
Pero es lo que evita migrar rápido hacia datos equivocados.
Este mismo principio aparece en cualquier modernización de software legacy: primero hay que comprender y delimitar el sistema; después, reducir el acoplamiento con pasos verificables.
Cómo empezar a tratar los datos como parte del producto
La peor forma de aplicar esta idea es empezar catalogando todos los datos de la empresa.
El alcance se dispara, el valor tarda en aparecer y el proyecto se aleja del problema que queríamos resolver. Acabamos con muchas definiciones y el mismo usuario esperando en la vía equivocada.
Prefiero un recorrido más pequeño.
1. Elige una experiencia crítica
Puede ser la consulta de stock, el estado de un pedido, la publicación de un catálogo o un cuadro de mando que condiciona decisiones. Debe ser importante para el usuario y lo bastante acotada para terminarla.
2. Localiza los datos que cambian la decisión
No todos los campos merecen el mismo esfuerzo. Empieza por los que bloquean un proceso, modifican una acción o afectan directamente a la confianza.
3. Dibuja el recorrido real
Documenta fuentes, transformaciones, almacenamientos, contratos y consumidores. No buscamos un diagrama bonito. Buscamos los lugares donde el dato puede perder actualidad, contexto o significado.
4. Define expectativas medibles
Establece reglas de exactitud, completitud, consistencia, actualidad, unicidad y validez. El umbral correcto depende del caso: no cuesta lo mismo equivocarse en una etiqueta descriptiva que en el stock, el precio o el estado de un expediente.
5. Asigna responsables de verdad
Asegura que alguien puede decidir el significado, mantener el flujo, aprobar cambios en el contrato y actuar ante una incidencia. Un nombre sin capacidad de decisión es solo documentación decorativa.
6. Instrumenta el trayecto
Añade validaciones, métricas, alertas y trazabilidad. Si un registro se rechaza, debes poder averiguar por qué. Una caída de volumen debe activar una señal. La aplicación necesita saber cuándo el dato está obsoleto.
7. Mételo en el ciclo normal de producto
Los requisitos de datos deben aparecer en los artefactos que el equipo ya utiliza:
- PRD;
- diseño técnico;
- criterios de aceptación;
- pruebas automatizadas y funcionales;
- plan de despliegue;
- paneles y alertas;
- runbooks;
- postmortems.
En resumen, no hace falta crear un proceso paralelo para los datos. Hace falta dejar de excluirlos del proceso con el que ya construimos el producto.
Checklist: ¿los datos forman parte de la definición de terminado?
- ☐ Sabemos cuál es la fuente autorizada.
- ☐ Cada campo importante tiene un significado documentado.
- ☐ La información tiene requisitos de calidad y actualidad.
- ☐ La API expresa el dominio, no las peculiaridades de una tabla.
- ☐ Los cambios de esquema se gestionan como cambios de producto.
- ☐ Podemos detectar datos incompletos, obsoletos o contradictorios.
- ☐ Conocemos qué consumidores dependen de cada contrato.
- ☐ Existe un responsable funcional y otro técnico.
- ☐ Podemos rastrear un dato desde la fuente hasta el usuario.
- ☐ Las incidencias de datos forman parte de la operación del producto.
Si varias respuestas son negativas, añadir más tests al frontend no resolverá el problema.
El coste de diseñar los datos como parte del producto
Tratar los datos como parte del producto no elimina su complejidad. La hace visible y manejable.
Obliga a equipos diferentes a acordar conceptos que antes permanecían implícitos. Hace aflorar duplicidades, excepciones históricas y contradicciones. Exige mantener contratos, validaciones, métricas y responsabilidades.
Por supuesto, tiene un coste.
Dicho esto, no todas las funcionalidades necesitan el mismo nivel de control. Sería absurdo aplicar al texto descriptivo de una tarjeta el mismo rigor que al precio de una compra, la vía de un tren o el resultado de un expediente. Los requisitos deben ser proporcionales al impacto del error.
Tampoco compensa crear una arquitectura enorme para un dato de poco valor, baja variabilidad y un único consumidor. A veces una validación, un contrato claro y una alerta resuelven el problema. La arquitectura debe reducir riesgo, no coleccionar componentes.
Con todo, ocultar la complejidad tampoco sale gratis.
Se paga en incidencias difíciles de reproducir, integraciones frágiles, migraciones interminables, informes que nadie cree y decisiones tomadas con información incorrecta.
Qué cambia cuando los datos se diseñan como una feature
- Las APIs son más fáciles de comprender y consumir.
- Las incidencias se detectan antes y se diagnostican mejor.
- Los sistemas modernos dependen menos de las peculiaridades del legacy.
- Los cambios tienen consumidores y riesgos identificados.
- Las métricas de producto representan mejor la realidad.
- Los equipos discuten sobre reglas explícitas, no sobre interpretaciones.
- El usuario recupera algo especialmente difícil de medir: la confianza.
Esa última es la métrica que une todas las demás. Cuando el usuario empieza a comprobar en otro sistema si lo que ve es cierto, el producto ya ha perdido una parte de su valor.
Preguntas frecuentes sobre datos como parte del producto
¿Data is a Feature y Data as a Product son lo mismo?
No. Data as a Product trata un conjunto de datos como un producto reutilizable para consumidores concretos. Data is a Feature aplica una idea más cercana a cualquier funcionalidad: si la experiencia depende de un dato, su significado, calidad y operación forman parte de esa experiencia.
¿Quién debería ser el propietario de un dato?
No siempre es una sola persona. Conviene separar quién decide su significado, quién mantiene el flujo técnico, quién define su impacto en producto y quién responde ante una incidencia. Lo importante es que el reparto cierre la responsabilidad de extremo a extremo.
¿Cómo se mide la calidad de datos?
Con umbrales ligados al caso de uso: exactitud, completitud, consistencia, actualidad, unicidad y validez. Una métrica útil debe indicar qué esperamos, cuánto error aceptamos y qué ocurre cuando se supera ese límite.
¿Necesito una plataforma de datos para aplicar este enfoque?
No. Puedes empezar con una sola funcionalidad, documentar el recorrido, definir reglas de calidad, añadir trazabilidad y asignar responsables. La tecnología debe crecer cuando el número de fuentes, consumidores o riesgos lo justifique.
¿Cómo se aplica cuando el origen es un ERP legacy?
Evitando que el esquema interno del ERP se convierta en el contrato del producto nuevo. Una capa de traducción y validación puede normalizar códigos, preservar procedencia, ofrecer un modelo canónico y reconciliar el resultado sin exigir una reescritura completa.
Datos como parte del producto: la pantalla no es el final
Volvamos al catálogo.
La interfaz funcionaba. También respondía la API. La sincronización terminaba en verde. Cada equipo podía demostrar que su pieza había funcionado exactamente como se esperaba.
Y, aun así, el usuario seguía viendo productos que no podía comprar.
Ese es el punto ciego de Data is a Feature: el producto no termina donde termina el código.
Un producto digital también está hecho de datos. De la información que muestra, de las decisiones que permite tomar y de la confianza que construye o destruye en cada interacción.
Por eso los datos como parte del producto no pueden ser una ocurrencia tardía. Deben entrar desde el principio: en el PRD, en el diseño técnico, en los criterios de aceptación, en las pruebas y en la operación.
No se trata de lanzar una gran estrategia de datos.
Se trata de que cada funcionalidad sepa qué está diciendo.
Una pantalla no está terminada cuando se ve bien. Está terminada cuando lo que dice es cierto.
¿Qué están diciendo los datos de tu aplicación?
¿Tienes errores que no aparecen en los logs, APIs difíciles de interpretar, informes que no coinciden o integraciones demasiado dependientes del ERP?
Revisar el recorrido de la información —desde el sistema de origen hasta la decisión del usuario— suele descubrir problemas que una auditoría centrada únicamente en el código no llega a ver.
Deja una respuesta