¿Quieres ideas más inteligentes en tu bandeja de entrada? Regístrese en nuestros boletines semanales para obtener solo lo que importa a los líderes de IA, datos y seguridad empresariales. Suscríbete ahora en la última década, las empresas han gastado miles de millones en infraestructura de datos. Almacenes a escala de petabyte. Tuberías en tiempo real. Plataformas de aprendizaje automático (ML). Y, sin embargo, pregunte a su liderazgo de operaciones por qué la rotación aumentó la semana pasada, y es probable que obtenga tres paneles en conflicto. Pídale a las finanzas que reconcilien el rendimiento en los sistemas de atribución, y escuchará: «Depende de a quién le pregunte». En un mundo ahogándose en paneles, una verdad sigue surgiendo: los datos no son el problema, el pensamiento del producto sí. El colapso tranquilo de «datos como servicio» durante años, los equipos de datos operaban como consultorías internas: reactivas, basadas en boletos, basadas en héroes. Este modelo de «datos como servicio» (DAAS) estaba bien cuando las solicitudes de datos eran pequeñas y las apuestas eran bajas. Pero a medida que las empresas se convirtieron en «basadas en datos», este modelo se fracturó bajo el peso de su propio éxito. Tome Airbnb. Antes del lanzamiento de su plataforma de métricas, los equipos de productos, finanzas y OPS retiraron sus propias versiones de métricas como: Noches reservadas en el usuario activo disponible incluso KPI simples variados según los filtros, las fuentes y quién estaba preguntando. En revisiones de liderazgo, diferentes equipos presentaron diferentes números, lo que resultó en argumentos sobre quién era la métrica «correcta» en lugar de qué acción tomar. Estos no son fallas tecnológicas. Son fallas de productos. La desconfianza de los datos de las consecuencias: los analistas son dudos. Los paneles están abandonados. Routers humanos: los científicos de datos pasan más tiempo explicando discrepancias que generar ideas. Tuberías redundantes: los ingenieros reconstruyen conjuntos de datos similares en todos los equipos. Decisión de arrastre: los líderes retrasan o ignoran la acción debido a insumos inconsistentes. Debido a que Data Trust es un problema de producto, no es técnico que la mayoría de los líderes de datos piensan que tienen un problema de calidad de datos. Pero busque más de cerca y encontrará un problema de confianza de datos: su plataforma de experimentación dice que una característica perjudica la retención, pero los líderes de productos no lo creen. OPS ve un tablero que contradice su experiencia vivida. Dos equipos usan el mismo nombre métrico, pero una lógica diferente. Las tuberías están funcionando. El SQL es sólido. Pero nadie confía en los resultados. Esta es una falla del producto, no de ingeniería. Porque los sistemas no estaban diseñados para la usabilidad, la interpretabilidad o la toma de decisiones. Ingrese: el administrador de productos de datos ha surgido un nuevo rol en las principales empresas: el Gerente de Producto de Datos (DPM). A diferencia del PMS generalista, los DPM operan a través del terreno frágil, invisible y interfuncional. Su trabajo no es enviar paneles. Es para asegurar que las personas adecuadas tengan la visión correcta en el momento adecuado para tomar una decisión. Pero los DPM no se detienen en los datos de la tubería en paneles o tablas de curación. Los mejores van más allá: preguntan: «¿Esto realmente está ayudando a alguien a hacer mejor su trabajo?» Definen el éxito no en términos de resultados, sino resultados. No «¿Fue esto enviado?» Pero «¿Esto mejoró materialmente el flujo de trabajo o la calidad de la decisión de alguien?» En la práctica, esto significa: no solo defina a los usuarios; observarlos. Pregunte cómo creen que funciona el producto. Sentarse a su lado. Su trabajo no es enviar un conjunto de datos, es hacer que su cliente sea más efectivo. Eso significa comprender profundamente cómo el producto encaja en el contexto del mundo real de su trabajo. Las propias métricas canónicas y trátelas como API, versadas, documentadas, gobernadas, y asegúrese de que estén vinculados a decisiones consecuentes como desbloqueos presupuestarios de $ 10 millones o lanzamientos de productos Go/No-Go. Construya interfaces internas, como las tiendas de características y las API de la sala limpia, no como infraestructura, sino como productos reales con contratos, SLA, usuarios y bucles de retroalimentación. Diga no a los proyectos que se sientan sofisticados pero que no importen. Una tubería de datos que ningún equipo usa es la deuda técnica, no el progreso. Diseño para la durabilidad. Muchos productos de datos no fallan en el mal modelado, sino de los sistemas frágiles: lógica indocumentada, tuberías escamosas, propiedad de la sombra. Construya con la suposición de que su futuro yo, o su reemplazo, le agradecerá. Resolver horizontalmente. A diferencia de los PM específicos del dominio, los DPM deben alejarse constantemente. La lógica de valor de por vida de un equipo (LTV) es el aporte presupuestario de otro equipo. Una actualización métrica aparentemente menor puede tener consecuencias de segundo orden en el marketing, las finanzas y las operaciones. Administrar esa complejidad es el trabajo. En las empresas, los DPM están redefiniendo silenciosamente cómo se construyen, gobiernan y adoptan los sistemas de datos internos. No están allí para limpiar los datos. Están allí para hacer que las organizaciones crean en él nuevamente. Por qué tomó tanto tiempo durante años, confundimos la actividad con el progreso. Los ingenieros de datos construyeron tuberías. Los científicos construyeron modelos. Los analistas construyeron paneles. Pero nadie preguntó: «¿Esta idea cambiará realmente una decisión comercial?» O peor: preguntamos, pero nadie poseía la respuesta. Debido a que las decisiones ejecutivas ahora están mediadas por datos en la empresa actual, casi todas las decisiones importantes (cambios de presupuesto, nuevos lanzamientos, reestructuraciones de organización) pasan primero a través de una capa de datos. Pero estas capas a menudo no son propiedad: la versión métrica utilizada el último trimestre ha cambiado, pero nadie sabe cuándo o por qué. La lógica de experimentación difiere entre los equipos. Los modelos de atribución se contradicen entre sí, cada uno con lógica plausible. Los DPM no son dueños de la decisión: son dueños de la interfaz que hace que la decisión sea legible. Los DPM se aseguran de que las métricas sean interpretables, los supuestos sean transparentes y las herramientas están alineadas con los flujos de trabajo reales. Sin ellos, la parálisis de decisión se convierte en la norma. Por qué este rol se acelerará en la era de la IA, AI no reemplazará a los DPM. Los hará esenciales: el 80% del esfuerzo del proyecto de IA todavía se destina a la preparación de datos (Forrester). A medida que la escala de modelos de idiomas grandes (LLMS), el costo de los compuestos de entradas de basura. AI no soluciona datos malos, lo amplifica. La presión regulatoria (la Ley de AI de la UE, la Ley de Privacidad del Consumidor de California) está impulsando las organizaciones para tratar los sistemas de datos internos con el rigor del producto. Los DPM no son coordinadores de tráfico. Son los arquitectos de la confianza, la interpretabilidad y las bases responsables de la IA. Entonces, ¿qué ahora? Si eres un CPO, CTO o jefe de datos, pregunta: ¿Quién es el dueño de los sistemas de datos que alimentan nuestras decisiones más importantes? ¿Nuestras API y métricas internas son verificadas, descubiertas y gobernadas? ¿Sabemos qué productos de datos se adoptan y cuáles están socavando en silencio? Si no puede responder claramente, no necesita más paneles. Necesita un administrador de productos de datos. Seojoon OH es gerente de productos de datos en Uber. Insights diarias sobre casos de uso de negocios con VB diariamente Si desea impresionar a su jefe, VB Daily lo tiene cubierto. Le damos la cuenta interior de lo que las empresas están haciendo con la IA generativa, desde cambios regulatorios hasta implementaciones prácticas, por lo que puede compartir ideas para el ROI máximo. Lea nuestra Política de privacidad Gracias por suscribirse. Mira más boletines de VB aquí. Ocurrió un error.