La investigación en producto es el corazón y la base para obtener productos exitosos. Independientemente de los métodos y de los recursos, es lo que nos permite acercarnos a las necesidades tanto de negocio como de los usuarios, entendiendo motivaciones y comportamientos, los que luego reflejaremos en funcionalidades a lo largo de las diferentes entregas de valor.
A pesar de tener esta sensibilidad o este entendimiento, la fase de Discovery (o incluso cualquier actividad de investigación en Producto) suele verse como un desafío complejo de abordar, como una etapa tediosa que muchas veces es cuestionada por sponsors y stakeholders ya que le ven valor inmediato, y para la que además muchas personas que trabajamos en esto no nos sentimos preparados.
Entre que a veces pensamos que no tenemos la experiencia suficiente o los conocimientos técnicos necesarios, generalmente acabamos entrampados en las buenas intenciones de diseñar la investigación más acuciosa y metodológicamente perfecta posible, ignorando otros factores que pueden atentar contra la ejecución de esta y, por consiguiente, el resultado final.
La teoría nos dice que tenemos que seguir una serie de pasos, realizar una cierta cantidad de actividades y contar con un tiempo más o menos extenso para poder llevar a cabo exitosamente una Investigación en Producto.
La realidad, por otro lado, nos muestra que generalmente no tenemos ni todo ese tiempo, ni las personas para ejecutar estas actividades e incluso, a veces ni siquiera tenemos a los usuarios.
¿Qué hacemos entonces? Los hechos nos dicen que debemos obtener información e insights que nos ayuden a definir el Producto que más adelante vamos a desarrollar.
Hay formas de sortear la trampa del Discovery y a continuación les compartiré algunas...
En los últimos años creo que hemos padecido de un exceso de Investigación que no está respaldada por ninguna hipótesis, y peor aún, por ningún caso de negocio.
Antes de zambullirnos a realizar entrevistas, prototipos, workshops y demases, como personas de Producto nos urge preguntar: ¿Cómo se enlaza esta iniciativa a los objetivos del negocio? ¿Qué indicador vamos a impactar?
Es 99,9% seguro que trabajando en Producto o Experiencia, al menos alguna vez te ha pasado que seguiste adelante con un Discovery que te pidieron, incluso sabiendo de antemano que: el resultado iba a ser que la necesidad no se validaba, la solución (sí, porque muchas veces las pedidas vienen con la solución prearmada) no era la óptima o que eventualmente iba a ser despriorizado por no ser estratégico.
Tengamos en cuenta que cualquiera de estos esfuerzos, incluso desde el Discovery, son costosísimos, por lo que si podemos descartar una iniciativa/necesidad/oportunidad antes de ponernos a investigar, mejor aún. Es una excelente práctica no priorizar ni tomar ningún research si la solicitud no viene al menos con una hipótesis (y ojalá traiga su caso de negocio también).
¿Es una inversión de tiempo? Seguro.
¿Es una ganancia tremenda a corto, mediano y hasta a largo plazo? Más seguro todavía.
Así que vale la pena preparar algunos artefactos para no tener que partir de cero cada vez.
Mis recomendados:
Sé que muchas veces es difícil hacer esa pausa y exigir ese tiempo, me ha pasado de verme en la vorágine del día y tomar requerimientos de Discovery sin darme el espacio para tener pre-trabajados estos materiales. Por esto mismo es que les digo que no cometan el mismo error que yo y la vida les sonreirá cuando necesiten montar una investigación y ya tengan los artefactos a mano.
Este punto es un win-win y se relaciona directamente con generar no solo los artefactos sino ojalá también poder incluir guías de cómo realizar las diferentes actividades. Uno de los puntos más críticos al momento de hacer Investigación de Producto es no contar con las personas suficientes para poder, de hecho, hacer el trabajo.
Si tenemos suerte estaremos ahí el rol de Producto y el rol de Experiencia de Usuario. Esto si tenemos suerte (lo más probable es que no sea así).
También puede pasar que esté la persona de Producto o el UX en solitario.
En lo personal, me pasó los últimos años que solo en momentos específicos conté con un rol de Experiencia con quien pudiera trabajar las investigaciones en conjunto. Y eso + no tener artefactos preparados es la combinación perfecta para el colapso.
Pero hay una solución: en ninguna parte se especifica que solo Producto y UX pueden hacer research. Y el equipo de Producto se llama así por algo: porque todos vamos en busca del mismo objetivo. Así que si tienes un equipo de Producto (con Desarrolladores, tal vez otros roles de UX como Writers, perfiles de Calidad, Data, etc), esos roles también pueden participar activamente de la investigación.
¿Y cómo lo van a hacer si no es su área de expertise? Usando las guías que quedaron preparadas en el punto anterior y con un pequeño entrenamiento de tu parte.
Creo que en el caso de las entrevistas esto es especialmente valioso y fructífero. Ya sea para moderar una o tomar notas, cualquier integrante del equipo podría potencialmente participar.
Esto es muy relevante, ya que al incluir a otros roles desde etapa tan temprana no solo ahorras tiempo o ganas recursos adicionales para tu investigación, también optimizas tu propio esfuerzo en cuanto a hacer bajadas y alinear al equipo sobre los dolores, necesidades y oportunidades encontradas.
Siempre es bueno que tú les puedas contar y ser la voz tanto de los usuarios como del negocio frente al equipo de Producto, pero es mejor todavía si ellos también lo son porque escucharon y conocieron los dolores de primera mano.
Así que ojo con esto, aprovecha también la visión de otros roles, quienes pueden aportar de forma muy valiosa en la posterior implementación si se encuentran enterados, alineados y sobre todo más comprometidos con el objetivo a lograr. Esto parece una obviedad pero no es algo que suceda habitualmente ni de forma natural (y lo más triste es que la mayoría de las veces es responsabilidad de la persona de Producto que esto no esté pasando).
El impacto de ser parte y de contar con un equipo que se siente dueño del problema y de la necesidad, es obtener la capacidad de encontrar y entregar las mejores soluciones, optimizando tiempos, recursos e incluso vueltas atrás. Un equipo de Desarrollo que comprende el dolor del usuario y el dolor del negocio, construye no solo con más conciencia sino también con mucha más motivación.
Como se dice: “Lo perfecto es enemigo de lo bueno” y acá quiero volver a lo que mencioné al inicio de este artículo.
No nos enredemos en lograr el mejor diseño de investigación ni en obtener la información más completa, acabada, depurada. Si realmente estamos trabajando en Producto, considero que necesitamos hacer lo justo que nos permita entender lo siguiente:
Con esto podemos iniciar la fase de Definición y Diseño, pero no sin antes dejar registradas las hipótesis que aún falta validar y todas aquellas que también surgieron durante este proceso de investigación, ¿para qué? Para seguir profundizando, refinando la solución y a la larga, haciendo evolucionar tu Producto, considerando también el feedback y mediciones que se obtengan constantemente una vez que este se haya lanzado.
Siempre debemos recordar que el Producto sí tiene un inicio, pero que no tiene un final y que el Discovery tampoco es una etapa que queda estática al principio de una iniciativa sino que debe continuar practicándose de forma continua, para que el Producto siga siendo valioso a lo largo del tiempo.
