La dificultad del desarrollo de productos basados en datos aconseja filosofías de desarrollo basadas en la iteración y la experimentación en el mercado. Por otro lado, los datos resultan ser una materia prima muy difícil de tratar.

Seguimos hablando del desarrollo de productos basados en datos, enfocándonos en las filosofías más recomendables y en la dificultad de usar datos como materia prima.

Los productos de datos tienen que construirse de manera diferente

Aparte de los inevitables riesgos de clientes y mercado los productos basados en datos se caracterizan por un elevado nivel de riesgo tecnológico. La dificultad intrínseca de desarrollo de productos basados en datos aboga por un proceso iterativo y centrado en los objetivos del cliente.

Parafraseando la famosa frase “la gente no quiere un taladro de un cuarto de pulgada, quiere agujeros de un cuarto de pulgada” la gente no quiere datos, sino que quiere soluciones e información accionable. Los clientes probablemente están considerando tu producto basado en datos para entender cómo les puede ayudar a tomar una decisión o realizar una acción. Así que tenemos que averiguar qué quieren hacer con el resultado y facilitarles que lleguen a algo tangible.

En “Designing great data products” J. Howard, M. Zwemer y M. Loukides proponen el enfoque Drivetrain, una filosofía basada en objetivos para diseñar productos de datos. Con este enfoque no usamos los datos para generar nuevos datos (en forma de predicciones) sino que usamos los datos para producir resultados accionables.

Por su parte DJ Patil, uno de los primeros científicos de datos de LinkedIn y Chief Data Officer de la administración Obama propone en su libro “Data Jujitsu” un método para resolver problemas de datos que evita intentar “la gran solución” desde el principio y en su lugar se concentra en construir algo rápido e iterar. A esto as a lo que llama Data Jujitsu, basado en aplicar la filosofía de esta antigua arte marcial que consiste en manipular la fuerza del oponente contar él mismo en lugar de enfrentarnos a ella con nuestra propia fuerza.

Data Jujitsu es el arte de usar varios elementos de datos de manera inteligente para resolver iterativamente problemas que, cuando se combinan, solucionan un problema de datos que de otra forma sería intratable. Como vemos, una especia de “divide (e itera) y vencerás”.

Según este enfoque no deberíamos resolver el problema entero de una vez. En su lugar tenemos que resolver una parte sencilla que nos demuestre si hay interés en el mercado y vamos a poder encontrar clientes. No tiene que tratarse de una gran solución; basta con que sea suficientemente buena como para hacernos saber si vale la pena ir más allá. Como vemos, este lenguaje del Data Jujitsu está totalmente en sintonía con los principios de Lean Startup y Customer Develoment (ej.: Producto Mínimo Viable o MVP).

La iteración y la experimentación son clave en el desarrollo de un producto de datos y algunas técnicas de MVP están especialmente indicadas en estos escenarios. La gran ventaja de algunas de ellas es que nos van a permitir sustituir tratamientos automáticos por procesamiento manual y así evitarnos el incurrir costes en desarrollar tecnologías e implementar productos que no va a ser necesarios. Por ejemplo:

• Concierge. Consiste en resolver el problema del cliente de una manera abiertamente manual, mediante un experto en continua interacción con el usuario. El objetivo es encontrar la mejor manera de resolverlo y descubrir una solución replicable. Es, por consiguiente, una técnica generativa que produce ideas de producto.
• “Mago de Oz” (también conocida como “Turco Mecánico” o “Los Picapiedra”). Consiste, en lugar de desarrollar la tecnología necesaria, en implementar la solución mediante procesos manuales. Esta circunstancia es desconocida por el usuario, que tiene una experiencia similar (aunque inevitablemente más lenta) a la que tendría con el producto final. De este modo validamos si la solución es aceptable. Una manera de implementar esta técnica de MVP es mediante un servicio tipo Amazon Mechanical Turk (cuyo irónico slogan es “Artificial Artificial Intelligence”). Se trata, por tanto, de una técnica evaluativa que nos permite comprobar si una solución concreta es válida y vale la pena implementarla.

Cuidado con los datos

Los datos son una materia prima muy complicada y difícil de conseguir, limpiar y adaptar para su uso. Según algunos estudios, las actividades de limpieza de datos habitualmente van a suponer el 80% o más del trabajo. En un escenario de desarrollo de productos basados en datos estos son realmente parte del problema y contribuyen a la dificultas del proceso.

• ¿De qué datos vamos a poder disponer? No tiene sentido construir un producto alrededor de datos que no tenemos. Más de una vez me he encontrado, al definir un producto de datos con un partner, que ese proveedor que nos iba a proporcionar la materia prima de nuestro producto al final no disponía de ella con los requisitos de volumen y calidad necesarios. Por otra parte, las nuevas leyes de protección de datos de carácter personal (p.ej., GDPR en la UE) son cada vez más restrictivas en cuanto al tratamiento que se puede hacer de los datos personales. Eliminemos estos riesgos comprobando que podemos aprovisionarnos de los datos antes de empezar el diseño. Del mismo modo que los grandes chefs empiezan a cocinar en el mercado, descubriendo qué ingredientes están disponibles y frescos, a la hora de “cocinar” con datos deberíamos seguir la misma política.
• ¿Cómo vas a conseguir esos datos? También me ha sucedido que a pesar de que el conjunto de datos parecía accesible a la hora de la verdad -y debido a problemas de índole técnica o legal- poder extraerlos con las consultas necesarias era un quebradero de cabeza. Si no eres al propietario de los datos haz un análisis de las capacidades técnicas y de licenciamiento del proveedor.
• ¿Cómo de limpios y completos son tus datos? Por mucho que nuestro proveedor diga que el conjunto de datos es exacto nunca lo es. Siempre hay problemas, sean datos que faltan, valores erróneos o esquemas ambiguos. Hay que intentar afrontar estos problemas lo antes posible ya que cambiar un script es barato, reimplementar un producto es caro y publicar algo basado en datos erróneos es devastador.
• Los insighst no se formulan, sino que se descubren. La extracción de insights a partir de datos se infrenta a unas incertidumbres y riesgos que no se dan en otros problemas. Y es que en general no vamos poder identificar a priori ni qué insights se van a derivar ni qué métodos y algoritmos van a ser los mas eficaces para extraerlos. Esto nos obliga a que este proceso sea muy especulativo, de exploración de diferentes alternativas para descubrir cuál es la mejor manera de avanzar, y donde las técnicas iterativas y ágiles son inevitables.

En el próximo post hablaremos de la necesidad de incorporar el diseño de producto a los productos basados en datos y de cómo gestionarlos a lo largo de todo su ciclo de vida.

El post “Desarrollando productos basados en datos (2)” se publicó primero en “Marketing & Innovación”.

[¿Quieres aprender a aplicar estas ideas en tu empresa? Nuestros talleres sobre Product Management de productos tecnológicos y Product Marketing de productos tecnológicos te pueden ayudar.]

La oportunidad para desarrollar y comercializar productos basados en datos nunca había sido tan grande. Pero hacerlo exige aplicar una “mentalidad de producto” diferente a la de proyectos a medida.

Ahora que “los datos son el nuevo petróleo” asistimos a un auge del desarrollo de nuevos productos basados en ellos. Nunca había sido tan grande la oportunidad para desarrollar productos de datos, a la que han contribuido la explosión del big data -que ha multiplicado la “materia prima” para estos productos- y la madurez y accesibilidad de las nuevas herramientas de almacenamiento y analíticas, que permiten su transformación.

Podemos definir un producto de datos como un producto que facilita un objetivo final mediante el uso de datos. O, dicho de otra manera, un activo de información envuelto en analítica que proporciona un valor a sus clientes. Ejemplos de productos de datos son un motor de búsqueda, un recomendador de productos, los datos de compras con tarjeta de crédito distribuidos por hora y ubicación, un servicio DMP (Data Management Platform), o un generador predictivo de leads para Account Based Marketing.

En general un producto de datos se compone tanto de datos como de procesos analíticos, pero hay productos donde los datos son más manifiestos y visibles como parte del resultado (por ejemplo, la función “gente que podrías conocer” de una red social) y otros donde los datos están más encubiertos (por ejemplo, el software para proponer la “siguiente mejor acción” a los usuarios de un sitio de e-commerce).

¿Cualquier solución basada en datos es un producto de datos?

Para muchos profesionales de los datos, desarrollar un producto no es ni obvio ni su primera opción. En general, suelen ser personas más acostumbradas a otras actividades y negocios basados en datos/analítica: mejora de procesos y decisiones internos, desarrollo de proyectos, consultoría externa.

Resulta difícil adoptar una “mentalidad de producto”, especialmente para un cierto perfil de data scientist que se encuentra más familiarizado y cómodo en el mundo de los desarrollos a medida para un cliente (sea interno o externo). Sin embargo, las perspectivas de rentabilidad y escalabilidad de este tipo de negocios los hacen muy atractivos.

Este asunto de la diferencia de los negocios basados en producto estándar frente a los basados en proyectos a medida lo hemos tratado anteriormente en el blog desde una perspectiva general. Por centrarnos en este caso digamos que, frente a otras actividades y negocios basados en datos, los productos poseen  unos aspectos diferenciadores esenciales:

• Los productos de datos deben ser replicables y para un mercado. Cuando hablamos de “producto” no utilizamos el término en el sentido en que se usa en proyectos a medida, y que designa al resultado final de ese proyecto. Un producto debe ser replicable, en el sentido de debemos poder vender unidades del mismo (con las mínimas modificaciones) al mayor número de clientes posible, y orientarse a un mercado, compuesto de clientes relativamente heterogéneos y difíciles de acceder.
• Uno de los aspectos primordiales de los productos para un mercado es cómo entender a los clientes y sus necesidades y decidir en qué segmento nos enfocamos para poder desarrollar un producto suficientemente estándar y rentable.
• Los productos de datos se caracterizan por unos costes de desarrollo y unos costes de replicación que definen completamente la rentabilidad del negocio. Estos costes de desarrollo, habitualmente muy elevados, hacen que un producto sea rentable con la repetición y su negocio plantee unas necesidades financieras muy exigentes al principio.
• Las expectativas de los clientes, especialmente si el producto se dirige al mercado de consumo, son muy elevadas. Acostumbrados a unas experiencias de uso impecables en todo tipo de productos, los clientes no van a exigir menos de los productos de datos. Y, sobre todo, no se van a conformar solo con los datos: el producto debe habilitar a los usuarios a hacer lo que quieren hacer (que muchas veces no tiene nada que ver con consumir datos).

Si no se tienen en cuenta estos aspectos diferenciadores nuestras iniciativas de desarrollo de productos de datos pueden fracasar

Desarrollo de productos

El desarrollo de un producto no es lo mismo que el desarrollo de un proyecto. La gran diferencia proviene del hecho de que un producto por su propia naturaleza debe satisfacer las necesidades de un conjunto amplio de clientes y, para garantizarlo, las actividades de diseño y construcción deben ser precedidas por (y hasta cierto punto simultaneadas con) actividades de comprensión de los clientes y descubrimiento de sus necesidades. Lo hemos descrito en detalle aquí y aquí.

El desarrollo de producto propiamente dicho está a su vez precedido por una fase previa en la que se identifican problemas de mercado y se cuantifican las oportunidades que representan. De esa evaluación se seleccionan las oportunidades que vale la pena perseguir y que pasarán al proceso de desarrollo de producto estrictamente hablando. En resumen, el proceso queda así:

Fase previa

0. Identificar problemas de mercado y evaluar oportunidades

Desarrollo de producto (fases que se solapan en un proceso iterativo):

1. Definición. Entender el mercado, recoger requisitos (= problemas de mercado) y definir los que el producto va a resolver

2. Diseño. Conceptualizar la solución y elaborar la especificación funcional y la experiencia de usuario

3. Implementación. Elaborar la especificación técnica, construir y probar la solución

Podéis encontrar más información sobre el proceso de desarrollo de productos en los numerosos posts sobre el tema que hemos publicado.

En el próximo post seguiremos hablando del desarrollo de productos de datos, centrándonos en las peculiaridades de su proceso de construcción y de los datos como su materia prima.

El post “Desarrollando productos basados en datos (1)” se publicó primero en “Marketing & Innovación”.

[¿Quieres aprender a aplicar estas ideas en tu empresa? Nuestros talleres sobre Product Management de productos tecnológicos y Product Marketing de productos tecnológicos te pueden ayudar.]