Cómo identificar qué Data Products construir

Hemos discutido bastante sobre qué son Data Products y los tipos que pueden existir. La conclusión principal a la que queremos llegar al empezar a pensar en Data Products, es que queremos transformar los datos a insights y con ello generar estrategias. Lo queremos hacer con velocidad y precisión.

Lo que todavía no hemos abordado, pero es importante mencionar, es cómo identificar qué data products construir dentro de nuestra empresa.

Existen muchas maneras de definirlo, pero yo te voy a dar algunos de los métodos que me han ayudado a mí cuando he necesitado construir Data Products.

Los métodos que vamos a describir no son los únicos ni son mutuamente excluyentes.

Dependiendo del estado actual de tu estrategia de datos, puedes usar uno o el otro, o también puedes utilizar estos métodos juntos:

Cada método tiene sus ventajas y sus desventajas y vamos a intentar hablar un poco en detalle de los pros y contras de cada uno.

Los métodos que yo he utilizado son los siguientes:

1. Basado en unidades del Negocio:

Cada unidad de negocio de la empresa, o los equipos de desarrollo cercanos a estas, es responsable de sus productos de datos.

Aquí estamos asumiendo que cada parte de la organización (Finanzas, Mercadeo, Producto, Servicio al cliente, operaciones, etc) conoce sus datos y necesidades de mejor manera y van a poder construir y priorizar los data products que necesitan construir.

Una de las mayores ventajas de este modelo, es que se puede priorizar de forma independiente cada Data Product y de esta forma, cada uno tendrá los datos que son estrictamente necesarios para cubrir las funciones de esta parte de la organización.

Los equipos son responsables de los resultados de la unidad y, por lo tanto, tienen poder sobre decisión de la data que es requerida.

Una de las mayores desventajas, es que necesitas tener equipos de datos en cada parte de la organización y puede que sea más difícil coordinar temas de gobernanza de datos.

También existe la posibilidad de que tengamos data products duplicados, ya que distintas partes de la organización podrían tener necesidades de datos similares. Por ejemplo, el equipo de finanzas y contabilidad podrían tener necesidades similares y cada uno podría construir productos que se podrían usar en ambos equipos.

2. Estructura del negocio:

En este caso debe existir una persona o un equipo que esté destinado a identificar qué entidades dentro del negocio están generando mayor valor y construir tus Data Products en base a estas necesidades.

Una de las mayores ventajas de este método, es que se están construyendo Data Products que, en teoría, deberían ser los que van a crear mayor valor para la empresa.

Parte del proceso de identificar las estructuras del negocio que generan mayor valor ayudan a priorizar el trabajo de los data products.

Una de las mayores desventajas sería que podríamos omitir algunos casos de uso importantes que no son parte de una estructura del negocio.

Por ejemplo, si estamos en un estado de crecimiento tal vez pensamos que el primer Data Product debe ser para que el equipo de mercadeo pueda medir la efectividad de las campañas pero podríamos obviar construir un Data Product para el equipo de producto que nos permita entender por qué los usuarios no están convirtiendo.

3. En base a KPIs/OKRs:

Si el equipo de datos o el equipo de liderazgo ya tiene definidos sus KPIs, OKRs, North Star Metrics, etc. entonces este puede ser un buen punto de inicio para definir tus productos de datos.

Puedes empezar a construir los Data Products que te permitan monitorear estas métricas de manera confiable y consistente.

Una de las ventajas de este modelo es que tus Data Products van a estar alineados a la estrategia de la empresa.

Vas a estar enfocando tus esfuerzos en medir lo que realmente es valioso para la compañía y lo que genera mayor valor.

Estamos asumiendo que se hizo un trabajo estratégico muy completo a nivel de compañía para definir los indicadores principales que se quieren medir.

De nuevo, se pueden crear Data Products en base a los indicadores de distintas áreas de negocio y solo debes priorizar en base a los indicadores más importantes.

Es un buen método si es una empresa todavía pequeña y quieres empezar a sacar provecho de tus datos lo más pronto posible.

La mayor desventaja que yo veo con este método es que puede ser muy unidimensional.

Tus KPIs/OKRs pueden cubrir aspectos de partes muy distintas del negocio o de la experiencia del usuario y los modelos de datos que vas a construir pueden ser muy complejos.

Esto es a diferencia de hacer un enfoque basado en estructura o líneas de negocio. Un ejemplo es si definimos que nuestros dos KPIs principales son adquisición y conversión, uno es una métrica de mercadeo y otra de producto.

Probablemente los datos requeridos para medir ambos vienen de fuentes muy distintas y van a requerir mayor trabajo de nuestro equipo de desarrollo.

4. Modelos Externos Existentes:

Esta estrategia consiste en ver qué modelos están usando compañías existentes e intentar copiarlo.

Por ejemplo, si tienes una tienda en línea, podrías ver cómo estructuran sus datos, sus equipos y sus productos de datos una empresa como Amazon e intentar replicarlo.

La ventaja principal de este modelo, es que te puede reducir la cantidad de tiempo que debes invertir en descubrimiento, ya alguien lo hizo por ti.

Tal vez no vas a necesitar una persona o equipo dedicada a crear una visión y un roadmap porque ya sabes lo que tienes que construir.

Alguna persona del equipo Producto o Estrategia puede ser dueño del proceso de desarrollo y entrega pero sin necesidad de ser un experto en el área de datos.

La desventaja de esta estrategia, es que los modelos existentes pueden ser muy genéricos o muy específicos para una empresa particular.

Tal vez no es algo que se pueda aplicar totalmente a tu empresa o quizás podría tener brechas y no estás implementando todo lo que deberías implementar para tu caso específico.

Personalmente, no me gusta mucho este modelo pero por ser una manera fácil de empezar a construir creo que puede ser de valor para algunas empresas pequeñas y con pocos recursos.  

5. Capacidad actual de Datos:

La idea aquí es ver qué capacidad de datos tienes actualmente, definir qué capacidad quisieras tener y empezar a construir para lograr estas capacidades.

Por ejemplo, si tus fuentes de datos son muy difíciles de consumir, puedes empezar a construir productos de datos que la simplifiquen.

Si tus fuentes son muy buenas pero las herramientas que utilizas son malas, puedes construir productos para mejorar el proceso de habilitación de datos.

El objetivo aquí es construir una base sólida que te permita agilizar el tiempo que te lleva generar insights.

Si tienes las fuentes, modelos, y herramientas necesarias para generar insights entonces el proceso de generar reportes, tableros, estrategia, etc. es mucho más sencilla.

Para que este modelo funcione, tienes que tener una visión muy clara de qué capacidades quieres tener en tu arquitectura de datos.

Si te interesa tener un buen modelo self-serve, entonces construyes en base a esto.

Si no te interesa self-service porque tienes un equipo grande y capaz de Business Intelligence, entonces construyes Data Products que permitan a tu equipo de BI generar los mejores insights posibles.

Si quieres usar herramientas que te permitan generar insights y tendencias automáticamente, entonces debes construir data products que te habilite el uso de estas herramientas.

La mayor ventaja de esta estrategia es que te estás enfocando en construir una arquitectura de datos escalable y que te va a ayudar a poder contestar preguntas constantemente y a largo plazo.

Una visión bien construída y tomando en cuenta todas las herramientas que tu equipo puede necesitar te va a ayudar a utilizar mejor tus recursos.

Debes pensar a futuro y que lo que estés construyendo te pueda ayudar con casos que puedan ocurrir en el futuro. Por ejemplo, qué pasa si cambio mi herramienta de visualización o si quiero agregar una herramienta nueva en el futuro.

La mayor desventaja, es que requiere un dueño de la visión de datos, requiere mucho trabajo de descubrimiento y puede ser tardado en implementar.

Se requieren más recursos, mucho esfuerzo y una mentalidad de data-first. Puede que tardes un poco de tiempo en empezar a ver resultados y esto puede generar ansiedad.

Creo que este es un buen modelo para una compañía pequeña que todavía no tiene muchas necesidades de datos y quiere armar una buena base para el futuro o para una empresa más grande que quiere volverse data-driven y está dispuesta a pasar por los dolores de crecimiento en lo que se desarrolla.

6. Product Discovery:

Este es el modelo que más me gusta porque está alineado a la idea de ‘Data as a Product’.

Una de las partes más importantes de Product Management es el proceso de descubrimiento, que es donde un Product Manager entiende cuáles son los objetivos principales o ‘jobs to be done’ de los usuarios.

El proceso de descubrimiento requiere de mucho tiempo y trabajo ya que hay que hablar con los usuarios, entender sus frustraciones y diseñar productos que resuelvan estos problemas.

En este caso es más sencillo este proceso porque los usuarios todos son clientes internos entonces es más fácil (y gratis!) hacer el proceso de descubrimiento

Luego del proceso de descubrimiento, el product manager puede trabajar en proponer soluciones que resuelvan los problemas descubiertos y hacer un trabajo de priorización con los usuarios.

Este proceso consiste en construir una visualización que muestre todas las soluciones propuestas con un estimado de tiempo de desarrollo y una propuesta de priorización preliminar.

Con esta visualización y con todos los usuarios reunidos se puede definir una lista priorizada final. El proceso de priorización es bueno realizarlo cada mes para ver si es necesario hacer cambios en base a las necesidades de datos actuales.

De este proceso va a salir un roadmap y una visión bien definida en el que se esté trabajando, siempre, en lo que los usuarios definieron como mayor prioridad.

El proceso de retroalimentación y entrega de mejoras también se ve muy beneficiado y se puede priorizar mejoras sobre nuevos desarrollos, si así lo requieren las prioridades del momento.

En el proceso de descubrimiento y diseño de soluciones se puede tomar en cuenta también cómo queremos que nuestra arquitectura de datos se mire en el futuro, entonces esta metodología se puede aplicar muy bien en conjunto con el modelo anterior.  

La mayor ventaja de este proceso es que vamos a estar trabajando siempre en entregar los productos más importantes en el momento actual de la empresa pero siempre teniendo en cuenta qué debemos construir para el futuro.

Al tener un dueño claro del producto de datos nos podemos mantener fieles al roadmap y a la visión de la compañía en lo que se refiere a estrategia de datos. Podemos entregar más y mejores productos de manera recurrente.

La mayor desventaja es que, al igual que el método anterior, requiere de mucho esfuerzo, paciencia y tiempo.

Requiere tener un (o varios) Analytics Product manager (vamos a definir este rol en otro artículo) dedicado a hacer todo el proceso de descubrimiento,  desarrollo y priorización.

Muchas empresas no tienen un Analytics Product Manager y esto hace imposible poder aplicar este modelo. A diferencia del método del punto anterior, aquí existe un proceso de priorización entonces se puede empezar a entregar valor antes ya que no estamos enfocados solo en la capacidad sino en entregar lo que es más importante ahora.

Todos los métodos descritos en este artículo se van a ver beneficiados por un Analytics Product Manager y seguir el proceso de buenas prácticas de Product Management.

La diferencia principal entre este método y los otros es cómo aplicamos el proceso de Product Discovery para descubrir qué productos debemos construir.

Los métodos para identificar qué data products construir se ven resumidos en el siguiente diagrama.

Cada uno de estos métodos tiene su lugar dentro de las distintas empresas, dependiendo del tamaño, estado actual y visión para los datos.

La idea es que puedas tener varios métodos y que utilices el que más crees aplicará en tu caso para identificar tus posibles data products y los puedas poner en práctica para empezar tu recorrido en el mundo de los data products.

The post Cómo identificar qué Data Products construir first appeared on KVERGE.