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.]