¿Cómo puedo aplicar “Datos como un Producto”?

En el post anterior, hicimos una breve introducción a Datos como un Producto y un Data Product.

Por ser un artículo introductorio, los estábamos usando casi como sinónimo, pero realmente existe una pequeña, pero muy importante, diferencia entre los términos y es importante que aclaremos la diferencia entre uno y otro.

Como definimos anteriormente, un “Data Product” es un producto que usa los datos para facilitar un resultado.

Dimos varios ejemplos de “Data Products” dentro de la empresa, pero también pueden existir “Data Products” externos que tu compañía podría adquirir. Algunos ejemplos son: Google Analytics, Tableau, PowerBI, MixPanel, etc.

Cuando hablamos de “Data as a Product”, estamos hablando del proceso que utilizamos para crear un Data Product o convertir data en un Data Product.

Dicho de otra manera, es agregar procesos de producto o “Product Thinking” a los datos disponibles.

Podemos pensar en Product Thinking como una manera de capturar y entregar valor a los clientes.

Es importante que el producto que quieras construir cumpla con los siguientes requisitos para poder aplicar Product Thinking a los datos:

• Resuelve una necesidad específica.

• Hay planes a largo plazo para el producto.

• Tiene un dueño claro (Product Manager) y está empoderado a tomar decisiones.

• Existe un cliente definido.

Puede parecer que estas cuatro características son muy lógicas cuando pensamos en cualquier producto, pero muchas veces no son inmediatamente evidentes cuando pensamos en datos y podemos caer en el problema de invertir tiempo y esfuerzo en productos de datos que no serán de mayor utilidad para la empresa.

Si pensamos un poco en por qué es importante que cada una de estos requisitos se cumpla, podemos ver por qué es importante pensar en esto antes de decidir invertir recursos en construir un Data Product.

Miremos unos ejemplos de data products que pueden parecer un ejemplo obvio de algo que se debe construir pero que en la realidad no es práctico hacerlo:

1. Resuelve una necesidad específica:

La empresa puede tener muchos datos, podemos tener datos de ventas, de clientes, de productos, de costos, de márgenes, de visitas a nuestra página web, resultados de encuestas, etc. Tal vez me puede parecer muy interesante responder cuántas visitas por país tenemos en la página web pero si sólo ofrecemos servicio en Estados Unidos, ¿realmente necesito construir un Data Product para resolver esta pregunta? Seguramente puedo hacer una consulta a los datos y con eso resolver esta pregunta, sin necesidad de invertir en un Data Product. Entonces no parece que tener este data product resuelve una necesidad específica de la compañía.

2. Tiene una visión a largo plazo:

Imaginemos que realizamos una encuesta para saber por qué los clientes no completan sus compras.

Creemos que vamos a estar realizando encuestas todos los meses y pensamos que lo mejor es crear un Data Product para poder visualizar los resultados de las encuestas.

Creamos el data product y todo funciona muy bien, podemos ver los resultados y tomar decisiones en base al tablero que armamos.

Unos meses después contratamos a otro proveedor de encuestas y necesitamos hacer cambios al data product para incorporar a este nuevo vendedor pero el equipo que construyó el data product ya no está trabajando en este proyecto y no hay equipo para trabajarlo.

El data product ahora es obsoleto porque no hay quien haga mejoras al mismo.

Este tal vez es un producto que no debimos haber desarrollado.

3. Tiene un dueño claro:

Entre los datos que recolectamos de los usuarios tenemos datos personales como nombre, dirección y correo electrónico y también información de sus compras.

Con estos datos podemos generar un modelo de valor de cliente que ayuda al equipo de Mercadeo a generar una campaña segmentada pero como el plan estratégico de la compañía no incluye crecimiento por campañas de email, no se asigna un Product Manager a este producto.

El equipo de Mercadeo quiere hacer una prueba y se le pide al equipo dueño de los datos que genere un modelo sencillo.

El equipo de ingeniería genera el modelo y entrega al equipo de mercadeo un archivo con el resultado de este modelo y otro con la información de los usuarios pero no hay forma de relacionar un archivo con otro.

Aparte, no se almacenaron los datos de los usuarios que no desean recibir correos electrónicos.

Como no hay un dueño del producto que entienda los requerimientos, tenga los recursos y empoderamiento para solicitar se recolectan los datos necesarios y vele por intereses del cliente (p.e. el equipo de mercadeo) el producto resultante es un fracaso.

Perdimos tiempo en implementar un producto que no cumplía las expectativas del cliente porque no había un dueño claro.

4. Tiene un cliente definido:

Tomemos el ejemplo del punto 1.

Asumamos que sí tenemos servicio en Estados Unidos, Canadá, México y Europa.

Pareciera que entonces sí es importante tener un data product para conocer cuántas visitas por país tenemos a la página web pero resulta que nuestra página web no es capaz de ofrecer promociones específicas por país y que nuestro equipo de mercadeo no tiene presupuesto para hacer campañas fuera de Estados Unidos.

El Data Product puede ser muy útil y resolver una pregunta que nos interesa contestar pero si no hay nadie que va a utilizar el resultado de este producto, ¿realmente es necesario construirlo?

Lo mejor sería invertir el tiempo en otro producto.

Cuando tenemos acceso a tantos datos puede sonar razonable querer responder todas las preguntas posibles.

Nuestros clientes internos van a querer tener respuestas a todas sus preguntas, lo cual es muy lógico, pero cuando tenemos recursos finitos no es conveniente generar data products para resolver estas dudas.

Cuando pensamos en un producto que la empresa vende, es más fácil discernir qué vale la pena construir y qué no pero cuando se trata de datos, es más difícil responder esta pregunta y por eso los 4 requisitos mencionados anteriormente pueden servir para decidir qué construir y que no.

Ahora que ya entendemos cómo aplicar Data as a Product y qué tomar en cuenta antes de decidir invertir en un data product, pensemos un poco en qué debe tener un Data Product para poder ser considerado como tal.

Empecemos comparándolo con cualquier producto en el mercado, por ejemplo Amazon, donde tenemos muchos productos en venta, que queremos ordenar de alguna manera que simplifique al cliente encontrarlos.

Amazon luego quiere lograr que el usuario pueda, de manera muy sencilla, crear una cuenta, buscar los productos, elegir un método de pago, ingresar una dirección y completar su orden.

Cada uno de estos pasos es independiente del otro, se pueden desarrollar y mantener fácilmente por equipos distintos, tener un dueño distinto y un cambio a uno de los pasos no afecta a un cambio en otro.

Si usamos esta analogía para pensar en datos, encontramos algo muy similar.

Tenemos muchas fuentes de datos y muchos procesos que podemos hacer con ellos: limpiarlos, simplificarlos, unirlos, generar datos nuevos, unirlos nuevamente, y generar insights.

Idealmente queremos que cada paso se pueda desarrollar fácilmente, que sea fácil de utilizar y que un cambio en un paso no afecte a otro

Miremos un ejemplo más concreto.

Asumamos que tenemos datos de clientes, de ventas, de llamadas a servicio al cliente, de precios de productos y de costos.

Como primer paso podríamos limpiar todos los datos y luego vamos a unir datos de clientes con ventas para ver compras por cliente.

Vamos a generar una visualización para ver llamadas a Servicio al cliente.

Luego vamos a ver cuántos de estos clientes generaron algún reclamo en servicio al cliente y vamos a arreglar los datos para poder generar un reporte de clientes con quejas y generar un tablero de visualización.

Por el lado de productos y costos, vamos a limpiar los datos y luego unir los datos para ver el margen que obtenemos por cada producto.

Vamos a generar una visualización para poder ver márgenes por usuarios y vamos a unir estos datos con los datos de clientes para poder ver el margen generado por cada cliente y si las llamadas a servicio al cliente están causando que se pierda el margen generado por algunos clientes.

Para realizar este proceso tenemos dos opciones.

Podemos construir un gran producto de datos monolítico que haga todos estos pasos o podemos hacer que cada paso sea un data product independiente.

Si cada paso es independiente, podemos reutilizar productos y no necesitamos que existan varios desarrollos que hagan lo mismo (corriendo el riesgo de hacer los procesos distintos y obtener resultados distintos).

Por ejemplo, podemos generar el reporte de llamadas a servicio al cliente y luego reutilizar estos datos para unirlos con datos de clientes.

No necesitamos generar los datos de llamadas a servicio al cliente en dos lugares distintos.

Similarmente, si necesitamos hacer cambios en el data product que une clientes y ventas, podemos hacerlo sin necesidad de tocar el código de ningún otro paso del proceso.

Podemos desarrollar, mantener y desplegar cada paso independientemente.

El diagrama de flujo vería algo así:

Este diagrama muestra claramente cómo podemos unir varias fuentes de datos para crear Data Products independientes.

Cada Data Product es simple de construir porque sólo debe resolver ‘un’ problema de la cadena.

Por ser un producto independiente, lo podemos desarrollar, manejar y desplegar sin impactar el resto del flujo.

Cada paso puede ser reutilizado para cumplir varios objetivos y debería ser lo más sencillo de usar posible.

El objetivo principal de esta cadena de productos de datos es poder contar una historia con los datos para generar insights y estrategia.

Queremos que esto se haga de manera fácil, rápida y repetible.

Todo esto lo podemos lograr con la combinación de reportes y visualizaciones, que son el resultado de la unión de todos los data products en esta cadena.

Este diagrama se puede ver complejo y asume que tenemos los recursos necesarios para implementar varios data products.

Este solo es un ejemplo de cómo se podría ver tu diagrama y flujo de datos si implementas una buena estrategia de datos con un dueño claro y plan a futuro.

Sin embargo, no quiero que te desilusiones pensando que esto es lo que tiene que ser un data product y que si tu empresa todavía no está allí entonces no se puede implementar esta estrategia.

Para no desanimarte, resumamos un poco qué es lo que esperamos que tenga un Data Product:

• Fácil de construir y mantener.

• Fácil de lanzar.

• Fácil de manejar.

• Independiente.

• Fácil de Usar.

Si tu producto de datos cumple estos requisitos, se puede considerar un Data Product.

No importa lo simple que sea, esa es exactamente la idea, simplificar lo más posible.

Como describimos en el diagrama anterior, puede ser algo tan sencillo como limpiar o unir datos o puede ser tan complicado como limpiar, unir, preparar y visualizar.

Depende en qué nivel de madurez se encuentra tu estrategia de datos, tus Data Products se verán diferente.

Si empiezas con una idea clara de lo que quieres lograr, puedes construir Data Products que serán reutilizables y útiles en el tiempo.

Al final tu propósito es poder generar más y mejores insights de los datos que tienes para crear mejores experiencias y estrategias, que sea en el menor tiempo posible y con la mayor agilidad y velocidad posible.

Podrías visualizarlo de ésta manera:

The post ¿Cómo puedo aplicar “Datos como un Producto”? first appeared on KVERGE.