Capítulo 04 — Definir: el problema correcto
Definir: el problema correcto
Definir es la modalidad en la que el equipo convierte la masa de observaciones de la investigación en un enunciado de problema preciso, accionable y centrado en una persona concreta. Es la bisagra entre el espacio del problema y el espacio de la solución: un problema bien definido hace que las ideas del capítulo siguiente sean relevantes; uno mal definido hace que la mejor sesión de ideación produzca soluciones a la pregunta equivocada.
El caso de la clínica dental continúa: el equipo llega con cinco temas sintetizados y debe decidir cuál es el problema que vale la pena atacar.
De observaciones a insights
Una observación es algo que viste o escuchaste. Un insight es una comprensión no obvia sobre por qué ocurre, que cambia la forma de ver el problema.
| Observación | Insight |
|---|---|
| Las pacientes con hijos faltan más a citas de la tarde | La cita se agenda según la disponibilidad de la clínica, no según la rutina del paciente; el conflicto de horario está decidido desde el día en que se agenda |
| Los pacientes que faltan no avisan | Avisar implica una llamada difícil y una posible penalización; el silencio es la opción con menor costo para el paciente |
| Las recepcionistas confirman por teléfono con poca respuesta | La confirmación llega por un canal que el paciente no atiende durante el horario laboral |
Un insight sólido cumple tres condiciones:
- Está respaldado por varias observaciones de distintos participantes.
- Explica una causa, no solo describe un síntoma.
- Sorprende a alguien del equipo o de la organización, es decir, no era obvio de antemano.
flowchart TD
O1[Observación 1] --> T[Tema de afinidad]
O2[Observación 2] --> T
O3[Observación 3] --> T
T --> Q{¿Por qué ocurre?}
Q --> I[Insight]
I --> POV[Point of View]
POV --> HMW[Preguntas How Might We]Personas
Una persona (en inglés persona) es un arquetipo de usuario construido a partir de la investigación, con nombre, contexto, objetivos, frustraciones y comportamientos. Sirve para que el equipo hable de “Carolina” en lugar de “el usuario” y para tomar decisiones con alguien concreto en mente.
Qué incluir
| Elemento | Ejemplo del caso |
|---|---|
| Nombre y foto o ilustración | Carolina, 38 años |
| Contexto relevante | Trabaja a tiempo completo, dos hijos en edad escolar, vive a 25 minutos de la clínica |
| Objetivo respecto al tema | Mantener su salud dental sin que interfiera con la logística familiar |
| Comportamientos observados | Agenda por teléfono en la pausa de almuerzo; acepta el primer horario que le ofrecen; usa WhatsApp para todo lo personal |
| Frustraciones | No puede llamar en horario de oficina; teme que le cobren por faltar |
| Cita textual | ”Si pudiera cambiar la hora desde el celular, nunca faltaría” |
Qué no incluir
- Datos demográficos que no influyen en el comportamiento (estado civil, ingresos) si la investigación no mostró que importan.
- Rasgos inventados para dar color (“le gusta el yoga”) que no vienen de la evidencia.
- Más de tres o cuatro personas por proyecto; más allá, dejan de orientar.
Buyer persona y user persona
En productos donde quien compra no es quien usa, se distinguen ambos perfiles. En la clínica, para ortodoncia infantil, la madre o el padre deciden y pagan (buyer) y el niño vive la experiencia (user). Las necesidades de ambos cuentan.
Point of View
El Point of View (POV) es un enunciado del problema con tres componentes: una persona, una necesidad y un insight.
[Persona] necesita [necesidad expresada como verbo] porque [insight].
Ejemplo del caso:
Carolina, paciente trabajadora con hijos, necesita poder mover su cita en menos de un minuto desde el celular y sin hablar con nadie, porque hoy avisar le cuesta más que faltar y la amenaza de cobro la lleva a guardar silencio.
Reglas para un POV útil:
| Regla | Por qué |
|---|---|
| La necesidad es un verbo, no un sustantivo ni una solución | ”Necesita un recordatorio” ya decidió la solución; “necesita recordar en el momento oportuno” deja abierto el cómo |
| El insight explica la necesidad | Sin insight, el POV es una queja |
| Es específico a una persona | ”Los pacientes necesitan…” diluye la tensión que hace útil el enunciado |
| Cabe en dos o tres líneas | Si no cabe, hay más de un problema mezclado |
El equipo escribe varios POV, uno por insight relevante, y luego elige.
Preguntas How Might We
La pregunta “¿Cómo podríamos…?” (How Might We, HMW) convierte un POV en una invitación a idear. El “cómo” supone que hay soluciones; el “podríamos” invita a explorar sin compromiso; el “nosotros” implica trabajo de equipo.
Del POV de Carolina pueden salir varias HMW:
- ¿Cómo podríamos hacer que mover una cita sea más fácil que faltar?
- ¿Cómo podríamos eliminar el miedo a la penalización sin perder los turnos?
- ¿Cómo podríamos ofrecer desde el inicio horarios que calcen con la rutina de Carolina?
Técnicas para abrir y cerrar
Una HMW demasiado amplia (“¿cómo podríamos mejorar la experiencia del paciente?”) no orienta. Una demasiado estrecha (“¿cómo podríamos añadir un botón de reprogramar en el SMS?”) ya es una solución.
| Técnica | Efecto | Ejemplo |
|---|---|---|
| Amplificar lo bueno | Abrir | ¿Cómo podríamos hacer que agendar sea tan fácil como reprogramar debería ser? |
| Eliminar lo malo | Cerrar | ¿Cómo podríamos quitar la llamada del proceso de reprogramación? |
| Explorar el opuesto | Abrir | ¿Cómo podríamos hacer que faltar sea más trabajoso que avisar? |
| Cuestionar un supuesto | Abrir | ¿Cómo podríamos operar sin citas de hora fija? |
| Cambiar el adjetivo | Reenfocar | ¿Cómo podríamos hacer que avisar sea tranquilizador en vez de incómodo? |
| Dividir en partes | Cerrar | ¿Cómo podríamos avisar a tiempo? ¿Cómo podríamos ofrecer alternativas? |
| Usar una analogía | Abrir | ¿Cómo podríamos hacer que reprogramar sea como cambiar un pedido de comida a domicilio? |
El equipo genera entre diez y veinte HMW por POV, las agrupa y elige dos o tres para la sesión de ideación.
flowchart LR
POV[Point of View] --> A[Amplificar lo bueno]
POV --> E[Eliminar lo malo]
POV --> S[Cuestionar supuestos]
POV --> D[Dividir en partes]
A --> HMW[Banco de HMW]
E --> HMW
S --> HMW
D --> HMW
HMW --> Sel[Seleccionar 2 o 3]Jobs To Be Done como alternativa
Jobs To Be Done (JTBD) es un marco complementario, asociado a Clayton Christensen y a Anthony Ulwick, que enuncia el problema como el “trabajo” que la persona quiere resolver, independiente del producto que use para hacerlo. La formulación habitual:
Cuando [situación], quiero [motivación], para [resultado esperado].
Ejemplo:
Cuando me surge un imprevisto el día antes de una cita, quiero moverla sin hablar con nadie, para no perder el turno ni sentir que estoy fallando.
Comparación con el POV:
| Aspecto | Point of View | Jobs To Be Done |
|---|---|---|
| Centro | Persona y su insight | Situación y resultado esperado |
| Lenguaje | Necesidad y causa | Trabajo funcional, emocional y social |
| Uso típico | Diseño de servicios y experiencias | Estrategia de producto, segmentación por trabajo |
| Fortaleza | Conecta con la investigación cualitativa | Independiza el problema de la solución actual |
Un equipo puede escribir ambos: el POV para mantener a la persona presente y el JTBD para asegurarse de que el problema no está atado al canal o producto actual.
Criterios para elegir el problema
Con varios POV sobre la mesa, hay que decidir. Criterios habituales:
| Criterio | Pregunta |
|---|---|
| Evidencia | ¿Cuántos participantes y observaciones lo respaldan? |
| Impacto | ¿Qué parte del fenómeno (inasistencias) explica? |
| Alcance | ¿Está dentro de lo que el equipo puede cambiar? |
| Riesgo | ¿Qué pasa si lo atacamos y nos equivocamos? |
| Novedad | ¿Lo ha intentado ya la organización? ¿Qué pasó? |
En el caso, el equipo descartó el POV sobre agendar horarios compatibles desde el inicio (requiere cambiar la planificación de los odontólogos, fuera del alcance inmediato) y eligió el de reprogramar sin fricción ni miedo, que explicaba la mayor parte de las inasistencias y estaba al alcance.
Antipatrones
El problema es una solución disfrazada
“Los pacientes necesitan un sistema de recordatorios por WhatsApp” no es un problema. Señales de alerta: el enunciado contiene un sustantivo de producto, una tecnología o una funcionalidad. Prueba: preguntar “¿para qué?” hasta llegar a una necesidad humana.
El problema es demasiado amplio
“Mejorar la experiencia del paciente” permite cualquier solución y por tanto ninguna. Prueba: ¿se puede saber si una idea responde o no al problema?
El problema ignora la evidencia
El equipo elige el problema que la gerencia quería desde el inicio aunque la investigación apunte a otro lado. Prueba: ¿cada parte del POV se puede rastrear a observaciones?
El problema es de la organización, no de la persona
“La clínica necesita reducir inasistencias” es un objetivo de negocio legítimo, pero no un POV. Las soluciones que salen de un problema organizacional tienden a presionar al usuario (cobros, llamadas insistentes) en vez de ayudarlo.
flowchart TD
E[Enunciado candidato] --> Q1{¿Contiene una solución?}
Q1 -->|sí| R1[Preguntar para qué y reescribir]
Q1 -->|no| Q2{¿Permite descartar ideas?}
Q2 -->|no| R2[Estrechar con un insight]
Q2 -->|sí| Q3{¿Cada parte tiene evidencia?}
Q3 -->|no| R3[Volver a la investigación]
Q3 -->|sí| Q4{¿Está centrado en una persona?}
Q4 -->|no| R4[Reformular desde la persona]
Q4 -->|sí| OK[POV listo para idear]Ejercicio práctico
- A partir de los temas sintetizados en el capítulo anterior, escribe tres insights que cumplan las tres condiciones (evidencia múltiple, causa, sorpresa).
- Construye una persona con los elementos de la tabla, sin añadir rasgos que no vengan de la investigación.
- Redacta un POV por insight. Pásalos por el diagrama de antipatrones y corrige los que fallen.
- Reescribe el POV elegido en formato Jobs To Be Done y anota qué cambia en la forma de ver el problema.
- Genera al menos doce preguntas How Might We usando al menos cuatro técnicas distintas de la tabla.
- Aplica los criterios de selección en una tabla y elige dos o tres HMW para la sesión de ideación del capítulo siguiente.
Autoevaluación
-
¿Cuál de los siguientes enunciados es un insight y no una observación?
- A. Las pacientes con hijos faltan más a las citas de la tarde
- B. Avisar que no se asistirá tiene para el paciente un costo mayor que faltar en silencio
- C. La recepcionista llama para confirmar citas cada mañana
- D. Tres de catorce entrevistados mencionaron el cobro por inasistencia
-
¿Qué componente del Point of View aporta la explicación de la necesidad?
- A. La persona
- B. La necesidad
- C. La cita textual
- D. El insight
-
¿Cuál de estas preguntas How Might We ya contiene una solución?
- A. ¿Cómo podríamos hacer que mover una cita sea más fácil que faltar?
- B. ¿Cómo podríamos eliminar el miedo a la penalización?
- C. ¿Cómo podríamos añadir un botón de reprogramar en el mensaje de confirmación?
- D. ¿Cómo podríamos hacer que avisar sea tranquilizador?
-
¿Cuál es la formulación habitual de un Job To Be Done?
- A. Cuando [situación], quiero [motivación], para [resultado]
- B. [Persona] necesita [necesidad] porque [insight]
- C. Como [rol], quiero [funcionalidad] para [beneficio]
- D. Si [condición], entonces [acción]
Respuestas
- B. Explica una causa no obvia; las otras tres describen hechos observados.
- D. El insight da la razón de la necesidad; sin él, el POV es una queja.
- C. “Botón de reprogramar en el mensaje” es una funcionalidad concreta, no un problema.
- A. La forma “cuando, quiero, para” es la de JTBD; la B es el POV y la C una historia de usuario ágil.
Checklist
- Distingo observaciones de insights y puedo justificar cada insight con evidencia múltiple.
- Construí al menos una persona basada solo en la investigación.
- Mi POV tiene persona, necesidad como verbo e insight, y no contiene una solución.
- Reescribí el problema en formato Jobs To Be Done.
- Tengo un banco de preguntas How Might We generadas con varias técnicas.
- Elegí el problema con criterios explícitos y documentados.