¿Cómo pueden los científicos de datos y diseñadores de productos trabajar juntos de manera más efectiva? ¿Cómo deberían los desarrolladores ayudar a los diseñadores a comprender las posibilidades y limitaciones del análisis de datos y el aprendizaje automático?

Después de haber trabajado en ambos roles, he hecho un montón de meta-pensamiento en torno a esto, mi postura actual es un tipo de árbol de decisión. La decisión de nivel superior que tomo es:

1. ¿Es la calidad de ML / ranking / AI el producto principal?
2. ¿Estoy construyendo un producto informado por datos?

La mayoría de los productos tienden a inclinarse fuertemente de una forma u otra. La Búsqueda de Google o los autos sin conductor son los primeros, mientras que Instagram o Twitter son los últimos. Quora o Netflix están en algún lugar en el medio.

Cuando los datos son el producto , como diseñador, usted se asegura de amplificar lo que es bueno y minimizar lo que no es tan bueno, pero generalmente suele haber un umbral de precisión por encima del cual el producto se siente mágico y por debajo del cual se siente terrible (o en el caso de autos sin conductor, puede matarlo). Esto es independiente de qué tan bien puede diseñar a su alrededor.

Al crear un producto informado por datos , hay dos formas de usar los datos para impulsar una decisión de producto:

1. Validación : ¿esta característica que agregué (o eliminé) es buena?
2. Exploratorio : ¿cuál es una buena característica / producto para construir? Esto podría ser tan pequeño como una optimización de conversión o tan grande como comenzar una empresa y pensar en qué producto construir.

Siempre es una buena idea utilizar la experiencia de un Científico de Datos para validar los cambios de productos. ¿Esto aumentó el compromiso, las acciones, la conversión, etc.? La mayoría de las empresas tienen un marco de pruebas A / B para este tipo de cosas.

A veces recibirás un golpe en uno de estos números y aún así lo justificarás porque es mejor en general de una manera que es más difícil de cuantificar. Eso está bien, pero debería ser la excepción, no la norma.

El análisis exploratorio para informar las decisiones del producto es donde las aguas se vuelven turbias . Esto también se divide en dos casos:

1. Hay una señal de demanda latente.
2. No hay señal de demanda latente.

Esto es lo que quiero decir con “señal de demanda latente”. Digamos que X es el producto que tienes e Y es el producto que crees que es una buena idea para construir. En el comportamiento de sus usuarios con el producto X actual, ¿están indicando que quieren Y? Por ejemplo, las personas que usan Messenger dicen cosas como “Te pagaré con Venmo”. Esa es una señal interna de demanda latente .

Otra metodología que me gusta para descubrir una señal interna de demanda latente es una prueba de puerta pintada. Es cuando prometes una función que en realidad no existe, y ves cuántos clics le llegan. Esto es muy arriesgado y debe usarse con moderación.

También puede haber señales externas de demanda latente , como estimar lo que los competidores están haciendo de manera diferente o encontrar necesidades análogas del mercado a través de otros productos. Estas inspiraciones pueden ser muy variadas, como la primera persona que pensó “oye, la gamificación funciona para juegos, así que ¿por qué no probarlo con este producto de salud?”

Las señales internas y externas de demanda latente ofrecen un enfoque incremental para el desarrollo de productos, y puede ser muy tedioso validar, enviar y probar cada pequeño cambio.

Siendo humanos, simplemente no podemos darnos el tiempo para tomar cada micro decisión a través de una prueba. La prueba de Google de 40 tonos de azul es un ejemplo muy citado. Así que tenemos que hacer juicios sobre lo que vale la pena el rigor y lo que no. Esto suele ser una combinación de instinto de producto desarrollado a través de la experiencia, libros transmitidos y sentido común.

tl; dr con señales latentes: por lo general, hay una manera de medir la señal latente para la demanda de algo que estás considerando construir o un problema que crees que vale la pena resolver, a menudo es necesario que seas creativo y pienses fuera de la caja para buscarlo . Me referiré a la respuesta de Peter Skomoroch aquí.

Escucha los datos. En lugar de perder tiempo debatiendo posibles escenarios, trabajen juntos para encontrar las respuestas reales. Ejecute algunas consultas, genere gráficos y vuelva a hacer los cálculos del sobre para guiar sus decisiones. No tenga miedo de ser franco con los desarrolladores si alguna característica no está a la altura, o si cree que algo debería cortarse del producto.

Haga una lluvia de ideas sobre productos juntos y haga algunos bocetos de servilletas. Antes de que cualquier diseño avance demasiado, descubra cuál será la característica principal del producto. Este es el único elemento sin el cual el producto ya no sería reconocible para los usuarios.

A veces, la señal de demanda latente es tan ruidosa que en realidad distrae si la usa.

Esto funciona en ambos sentidos: a veces los datos solo te desanimarán de construir algo que podría ser genial , esto generalmente es por la visión del túnel y por mirar los datos de manera demasiado estrecha, y estás haciendo preguntas equivocadas al respecto.

Otras veces, los datos muestran una gran cantidad de promesas, pero su ejecución simplemente no es lo suficientemente buena como para capitalizarla , o alguien más resolvió el problema lo suficientemente bien y la fricción de cambiar a su producto no vale la pena.

Y aquí es donde la mayoría de las decisiones equivocadas tienden a tomarse con datos. Steve Jobs dijo una vez: “Muchas veces, la gente no sabe lo que quiere hasta que se lo enseñas” y este es el tipo de producto que es realmente difícil de descubrir con datos.

Estos productos son muy difíciles de encontrar con los datos, no porque los datos se encuentren, sino porque estamos haciendo las preguntas equivocadas.