Hace un tiempo, cuándo daba mis primeros pasos en Product Management, metí la pata en el desarrollo de una nueva funcionalidad.

Estaba trabajando para Coderhouse como Product Manager, y tenía un equipo pequeño que consistía en un 1 UX/UI Designer, 1 Tech Lead y 3 desarrolladores.

El objetivo que teníamos en mente era reducir la cantidad de tiempo que deben invertir los tutores en corregir los desafíos entregables de los estudiantes.

Esto se trasladaba directamente a menores costos para el negocio.

En este sentido, la oportunidad que vimos fue realizar un rediseño completo del flujo de trabajo de los tutores.

Una interfaz completamente nueva que vendría a resolver de raíz algunas ineficiencias que existían en el proceso.

A los pocos días, el Tech Lead acercó sus ideas en bocetos al equipo, y obtuvo aprobación interna inmediata. La solución se veía muy bien en el papel.

Pero había un detalle no menor.

Nadie del equipo había sido tutor.

Nadie del equipo había corregido desafíos entregables.

Esta falta de experiencia práctica se iba a volver evidente un par de meses después.

Por lo pronto, continuamos con nuestros procesos.

Análisis funcional, diseño, desarrollo, pruebas de calidad y demás.

A los dos meses, teníamos el nuevo sistema listo para lanzar.

Envíamos una comunicación por distintos canales, compartimos un tutorial sobre el nuevo sistema y aplicamos la actualización a toda la base de tutores.

De mi lado, buscaba proactivamente tutores que quieran compartir su feedback luego de la primer semana de uso.

El feedback eventualmente llegó, y no fue muy agradable.

En ese momento, comprendí que no haber involucrado a los usuarios en el proceso de diseño había sido un gran error.

Los tutores se quejaban intensamente del nuevo flujo de corrección.

Extrañaban funcionalidades que no estuvieron contempladas en el rediseño, y miraban con escepticismo el nuevo flujo de corrección, ya que este no les permitía trabajar cómodamente ante múltiples casos de uso.

De hecho, pedían recuperar las funcionalidades que habían perdido. Algunos, incluso, preferían que se vuelva atrás por completo, a cómo estaba antes.

El nuevo flujo no solo no aportaba valor al usuario, sino que tampoco resolvía el desafío que el equipo tenía por alcanzar el objetivo de ahorro en costos.

De hecho, los tiempos de corrección se acrecentaron y por consiguiente, los costos.

Era evidentemente que algo había que cambiar.

Si bien a corto plazo el nuevo flujo sufrió varias iteraciones que lo acercaron a lo que inicialmente se pretendía conseguir, lo cierto es que teníamos que plantear nuevas dinámicas de trabajo para evitar que un traspié así vuelva a suceder.

Luego de un intenso análisis y reflexión interna, sacamos los siguientes aprendizajes:

• No se puede confiar en la intuición si no hay experiencia real que la justifique.
• Cuánto más grande sea el cambio, mayor será el riesgo y la necesidad de validación.
• Un gran error se puede evitar, literalmente, con una entrevista de 30 minutos.
• Los objetivos deben bajarse con métricas claras, y las decisiones fundamentarse de igual manera.

SI bien como Product Manager yo sabía acerca de la importancia de realizar un Product Discovery, omití adrede este paso.

¿La razón? → Simplemente, la confianza natural que lleva a uno a desviarse de la teoría en ocasiones donde no estaría mal considerla.

Y esta confianza que puede llevar a resultados sub-óptimos es algo sobre lo que advierto a menudo.

No es una cuestión de fundamentar nuestras decisiones en base a la teoría, sino de tenerla más presente en el día a día, como una brújula que nos ayude a orientar el camino a tomar.

Afortunadamente, los aprendizajes fueron integrados, los procesos internos repensados y para próximas soluciones, consideramos el punto de vista del usuario.

Un Product Discovery es especialmente relevante cuánto mayor sea la incertidumbre del contexto.

Una pregunta que recibo con frecuencia es sí es necesario SIEMPRE hacer un Product Discovery.

Mi opinión es que, al menos en el 90% de los casos y sobretodo si afrontamos un entorno volátil e incierto, es SÍ.

¿Esto quiere decir que el Product Discovery deba seguir un proceso determinado en todos los casos? En absoluto.

Un Product Discovery es, esencialmente, una actividad que involucra comprender la oportunidad de negocio y el problema a resolver, y validar las soluciones antes de llevarse a cabo.

Es una actividad que puede tomar una semana, un mes o directamente no tener fin (de hecho, muchos equipos emplea Discovery continuo).

La clave está en saber leer bien el contexto actual, relevar lo que se necesita aprender y validar, y estructurar un Discovery que tenga sentido con tu estructura de equipo y recursos.

Aunque sea, un poco de Product Discovery (bien hecho) es mejor nada.

Como mencioné anteriormente, partiendo desde el absoluto conocimiento es muy grande el aprendizaje que puedes obtener a partir de una sola entrevista de 30 minutos con algún usuario.

Y, afortunadamente, puede evitarte dolores de cabeza y largas iteraciones en el medio.

En síntesis: no subestimes la importancia de un Product Discovery, incluso cuando el problema y la solución parezcan evidentes al equipo.