Solucionando el problema adecuado.

Definir el problema es el inicio para entender cuál es el producto o servicio que debemos construir, y solucionar así los dolores de nuestros clientes.

“No necesitamos pegar papelitos en un tablero, nosotros ya sabemos cuál es el problema que tenemos que resolver”

Un ejecutivo en una empresa del sector financiero.

“No tengo dinero para malgastar investigando, aquí hay que hacer…hacer!”

Un CFO aprobando el presupuesto de diseño de producto.

“No entiendo, esto del design thinking enreda todo, hagamos una presentación y salgamos a vender”

Un Gerente Comercial en alguna parte del mundo.

¿Te han dicho alguna de estas frases?… o ¿tu las dijiste alguna vez? Si tu respuesta a cualquiera de las dos preguntas es sí entonces esta entrada te va a servir.

Las etapas iniciales de un producto son generalmente complicadas. Demasiada incertidumbre en aspectos claves como el segmento de usuarios, los clientes, el producto mismo, y sobre todo en el problema que realmente necesitamos resolver a los usuarios.

Es común encontrar equipos que en estas etapas se enfocan únicamente en la tecnología lo cual significa centrarse en el “cómo” sin saber aún el “qué” es lo que van a resolver. Esto es algo en lo que soy muy insistente: no habrá producto exitoso sin antes entender cual es el dolor que soluciona en los usuarios1.

A post shared by @duranoscarf

Construir un producto es un proceso iterativo que comprende varias fases: Descubrimiento, definición y estrategia, diseño, desarrollo, pruebas, lanzamiento y crecimiento. Como pueden ver la fase de desarrollo no es la primera! va después de un par de momentos importantes, donde el objetivo es poder descubrir los usuarios, sus necesidades y dolores, y en general las oportunidades que tenemos para solucionarlos.

Es entonces en la fase de Discovery o Descubrimiento donde debemos definir claramente el problema que queremos resolver, será el punto de partida para construir el producto adecuado, a esto se le conoce como Problem Framing o Problem statement.

Metodologías como design sprint de la que hablé en mi entrada anterior, utilizan la metodología de la que hablaré hoy como punto de partida para empezar a entender al usuario y prototipar ideas enfocandóse en resolver un problema real2.

¿Qué significa definir el problema?

Definir el problema significa tener una descripción concreta de los dolores que se pretenden resolver en los usuarios (bien sean personas o empresas). Es un metódo derivado del design thinking que nos permite entender, definir y priorizar problemas de negocio.

Los problemas empresariales de la actualidad son cada vez más complejos y eso hace que sea más difícil articularlos y definirlos con claridad. Cuando hay ambigüedad y la respuesta correcta no es tan obvia este proceso ayuda a estructurar el pensamiento.

A post shared by @duranoscarf

Tener un problema bien definido nos ayudará a hacer más eficiente el proceso de toma de decisiones y priorización, y le permitirá al equipo mantenerse alineado.

¿Por qué es importante?

Existen 4 razones fundamentales para invertir dinero, tiempo y esfuerzo en definir de manera correcta el problema:

  1. Ayuda a enfocar los esfuerzos del equipo en un problema y un segmento de clientes especificos.

  2. Permite descubrir nuevas oportunidades.

  3. Disminuye la probabilidad de enfocarse en problemas “ficticios” o que parecen muy atractivos a primera vista.

  4. Se convierte en la guía del proceso de decisión.

Este ejercicio no debe verse simplemente como un proceso de lluvia de ideas alrededor de un problema o del segmento de clientes, la definición del problema es un elemento estratégico dentro del proceso de construcción de productos y servicios que sincroniza las expectativas de los diferentes stakeholders de la organización y por ende actúa como north star o métrica clave para la estrategia de crecimiento.

¿Cuándo deberías aplicar la de Definición del Problema?

En los negocios y en la vida en general, el contexto es absolutamente cambiante, nuevos jugadores aparecen en el mercado, las reglas del juego evolucionan y las estrategias que funcionaron en el pasado pueden quedar obsoletas rápidamente. Para navegar a través de la complejidad, necesitamos una mentalidad diferente a la tradicional.

Necesitamos mirar tanto el “bosque como los árboles” simultáneamente; cambiar las perspectivas y estar abiertos a diferentes puntos de vista, alejarnos del escritorio e ir a donde nuestros usuarios o clientes están para entender su realidad.

El problem framing es útil cuando:

  • El problema que se está tratando de resolver no está claramente entendido.

  • Los enfoques tradicionales de resolución de problemas no funcionan o empeoran la situación.

  • Desea cambiar de dirección pero no está seguro de cómo o adónde ir.

  • Desea descubrir y definir nuevas oportunidades de negocio.

  • Tiene múltiples partes interesadas y está experimentando desalineación o falta de avance en el equipo.

¿Cómo hacerlo?

Hacer problem framing es un ejercicio de empatía, de entender el problema a resolver desde los dolores y necesidades de nuestro usuario o cliente y priorizarlos3:

Con esto en mente, vamos al proceso:

Contexto del problema:

El primer paso es pensar en ¿cuál es el problema? y ¿Por qué ha surgido? Ten en cuenta que, en algunos casos, es posible que no conozcas las causas exactas del problema, en dichos casos será fundamental la investigación y validación con fuentes primarias o secundarias que nos permitan entender mejor lo que sucede con los usuarios. Una herramienta para esto puede ser el diagrama de causa y efecto o también conocido como fishbone diagram.

Es clave que se haga una sesión de lluvia de ideas donde el equipo exponga sus puntos de vista sobre lo que creen es el problema a resolver. Esto enriquecerá el resultado final y permitirá tener diferentes visiones. Este ejercicio arrojará varias y diferentes ideas, cómo no podemos resolver todas al tiempo tendremos que priorizar.

Existen muchos frameworks o marcos metodológicos para priorizar, mi sugerencia es tratar al máximo de mantenerlo simple. Por entendimiento del equipo y agilidad, podemos usar una matriz como la presentada en la Figura 1. donde balanceemos la importancia del problema para el usuario y la viabilidad de resolver dicho problema.

Descarga aquí el template de Mural

¿Quién se ve afectado por el problema?.

Una vez tenemos la hipótesis del problema definida, es momento de identificar el segmento de usarios / clientes que se ven afectados. Puede haber varios grupos de usuarios afectados por un problema específico de diferentes maneras por lo cuál será clave entender en cuál de ellos el problema es más profundo.

Para esto hay varias metodologías que podrían funcionar: Jobs to be done, Customer profile canvas, son dos de las más usadas. Sin embargo hay una que me gusta mucho por su nivel de profundidad al analizar a los usuarios como humanos: el Empathy Map o mapa de empatía4.

Se trata básicamente de analizar a nuestro usuario o cliente desde 4 dimensiones principales:

  1. Lo que piensa y siente.

  2. Lo que ve en su entorno.

  3. Lo que escucha en su entorno.

  4. Lo que dice y hace.

Y a su vez identificar sus principales dolores o problemas y aquellas ganancias o hechos que lo hacen feliz.

Teniendo el problema definido y el segmento identificado, debes entender el contexto en el que dicho problema sucede. Que evidencias tenemos y cómo podríamos validar su existencia. El contexto será fundamental al momento de diseñar el producto y enfocar su caso de uso.

Haz una lista de todas las situaciones y contextos donde el problema se puede presentar y vota con tu equipo para priorizarlas de acuerdo a la información que tengas y el impacto sobre el usuario.

¿Cuál es el impacto del problema?

En esta etapa entramos al momento del “por qué?”… ¿por qué es importante resolver este problema? Si el problema no se soluciona, ¿cuál será el efecto en el negocio? ¿en el cliente o usuario?

Haz una lista de los beneficios y ganancias que el usuario podría obtener si el problema se soluciona de manera correcta, lo mismo para el negocio, identifica como el negocio se vería impactado de manera positiva si el problema es resuelto y a partir de allí nuevamente prioriza con tu equipo los beneficios con mayor impacto.

Este es el momento donde podríamos llegar a encontrarnos con que el problema que pensamos resolver a lo mejor no sea tan relevante, y esto pasa muy frecuentemente, son más los problemas fallidos que los que verdaderamente resuelven un dolor importante en el usuario, por eso tu y tu equipo deben estar preparados y abiertos a “estrellarse” y cambiar rápidamente.

Accede aquí el Mural de Problem Framing

Problem statement - escribiendo el problema

Una técnica comunmente usada para escribir el problema es la técnica de las 5W’s5 (por sus siglas en inglés Who, What, Where, When, Why..), es simple pero poderosa y te ayudará a tener todos los elementos dentro del problema a resolver.

Recuerda que todo el proceso lo desarrollamos para enfocarnos en un solo problema, no un par, no varios… UNO solo. Luego la definición debe estar enfocada en ese problema que mayor impacto tiene en los usuarios, no debe contener la solución, hasta este momento estamos definiendo lo que queremos solucionar no cómo lo queremos hacer.

Y por último pero no menos importante, ser concretos! máximo 3 o 4 líneas deberían bastar para presentar el problema trabajado.

Hasta aquí el trabajo colaborativo del equipo nos ha llevado a definir en un proceso estructurado un problema que parece ser relevante e impactante para un segmento específico de clientes o usuarios, es el primer paso en la construcción de la solución, lo que viene será validar con tus usuarios dicho problema.

Espera la próxima semana una nueva entrada dónde te contaré otro viaje digital, esta vez sobre cómo se puede validar el problema dentro del proceso de discovery de un producto.

Share Un viaje Digital

1

Are you doing real discoveries? https://www.nngroup.com/videos/real-ux-discoveries/

2

Why problem framing before a design sprint? https://medium.com/design-sprint-academy/design-sprints-picking-your-battles-45d30f9b06ce

3

How to write problem statements in UX Discovery https://www.nngroup.com/articles/problem-statements/

4

What is an empathy map? https://www.accenture.com/us-en/blogs/software-engineering-blog/what-is-an-empathy-map

5

Keep Your Business Plan Simple By Using The 5W’s https://arronfornasetti.medium.com/keep-your-business-plan-simple-by-using-the-5ws-4a7c14d4b50d