Un equipo puede estar de acuerdo con una idea de producto y, aun así, discrepar sobre por qué funcionará. Una persona da por hecho que los clientes ya perciben el problema. Otra supone que estarán dispuestos a pagar para resolverlo. Una tercera cree que será fácil conseguir los datos necesarios. Mientras esos supuestos no salgan a la luz, una hoja de ruta bien presentada puede ocultar tres apuestas distintas.
Un taller de mapeo de supuestos ayuda a decidir qué incertidumbre investigar primero. Identifica una afirmación capaz de cambiar la decisión de invertir y diseña una prueba que permita decidir si conviene seguir adelante.
Distingue la importancia de las evidencias
En un mapa de supuestos, la importancia indica cuánto depende la idea de que una afirmación sea cierta. Las evidencias reflejan lo que realmente sabes sobre esa afirmación. Son valoraciones distintas. Una opinión defendida con convicción no es una evidencia sólida, y un detalle fácil de comprobar no es necesariamente importante.
El método de mapeo de supuestos de Strategyzer cruza la importancia con las evidencias para identificar hipótesis críticas con poco respaldo. Utiliza esa distinción para organizar la conversación, no para atribuir precisión científica a la posición de las notas adhesivas.
Representa la importancia de menor a mayor en el eje vertical y las evidencias de débiles a sólidas en el horizontal. Etiqueta ambos extremos. Los primeros candidatos suelen estar en la zona de alta importancia y evidencias débiles. Puedes orientar los ejes de otra manera, siempre que todo el equipo los interprete igual.
Empieza por una decisión, no por una lluvia de ideas sin contexto
Escribe la decisión en la parte superior del tablero: «¿Deberíamos crear este trimestre un portal de informes para nuestros clientes?». Añade qué está en juego y cuándo hay que decidir. De lo contrario, las personas pueden enumerar incertidumbres interesantes que no afectan a la decisión que tienen delante.
Si el equipo ya ha elegido una función sin aclarar la necesidad del cliente, este ejemplo de árbol de oportunidades y soluciones ayuda a distinguir el resultado deseado, las necesidades no satisfechas, las posibles soluciones y las pruebas.
Reúne a quienes conocen el comportamiento de los clientes, las restricciones de ejecución y las consecuencias comerciales. Comparte una breve descripción de la idea y las evidencias disponibles. Si cuentas con un lienzo de modelo de negocio, utiliza sus bloques para plantear preguntas sobre clientes, canales, costes y socios. El lienzo sirve como punto de partida, no como prueba de que el modelo funciona.
Pide a los participantes que escriban por separado antes de debatir. Cada nota debe contener una sola afirmación y, debajo, el motivo por el que alguien la considera cierta. Así se distingue claramente entre una solicitud de soporte, una cita de una entrevista y la intuición de un directivo.
Convierte los supuestos vagos en afirmaciones comprobables
«Los clientes quieren mejores informes» es demasiado amplio para someterlo a prueba. Podría referirse a una carga más rápida, gráficos más claros, menos correos o datos que se puedan exportar. Una afirmación más útil sería: «Los responsables de cuentas de agencias pequeñas necesitan enviar a sus clientes un resumen semanal del estado del proyecto, y preparar ese resumen les exige trabajo manual de forma recurrente».
Strategyzer describe las hipótesis útiles como comprobables, precisas y centradas en una sola cuestión. En la práctica, especifica las personas, la situación y el comportamiento que esperas. Separa las afirmaciones que mezclan demanda, disposición a pagar y viabilidad de ejecución. Las evidencias sobre una de ellas no demuestran las demás.
Plantea también la pregunta contraria: ¿qué demostraría que esta afirmación es falsa? Si el único resultado aceptable es que todos estén de acuerdo, estás redactando un argumento de venta, no una hipótesis.
Ejemplo: ¿debería una agencia crear un portal para sus clientes?
Imagina una agencia pequeña que está valorando crear un portal de informes para sus clientes. En este ejemplo hipotético, el equipo dispone de algunas conversaciones con clientes y muestras de los informes actuales, pero todavía no tiene un portal en funcionamiento.
| Supuesto | Importancia | Evidencias disponibles | Siguiente pregunta |
|---|---|---|---|
| A los clientes les cuesta encontrar el estado más reciente del proyecto | Alta | Varios correos de soporte, pero ninguna observación de cómo trabajan los clientes | ¿Qué hacen los clientes cuando necesitan una actualización? |
| Los clientes iniciarán sesión regularmente en un portal independiente | Alta | Solo una preferencia interna | ¿Utilizarán los clientes una prueba piloto sin recibir recordatorios? |
| Los datos existentes del proyecto permiten elaborar resúmenes fiables | Alta | Una exportación de muestra con campos incompletos | ¿Qué campos hay que corregir manualmente? |
| Es necesario personalizar el aspecto del panel | Baja para una prueba piloto | Una solicitud de cambio de color | ¿El aspecto del panel impide que los clientes completen la tarea? |
| Los responsables de cuentas dejarán de enviar informes duplicados | Alta | No hay un acuerdo operativo al respecto | ¿Qué obligaciones siguen exigiendo un informe por correo? |
El supuesto sobre el inicio de sesión es un candidato evidente para una prueba, pero la fiabilidad de los datos también importa: el entusiasmo de los clientes no compensa unos informes incorrectos. El equipo elige una prueba piloto pequeña que permita observar el uso real y, al mismo tiempo, revisar los datos manualmente. Aplaza la conversación sobre el aspecto del panel porque esa decisión puede esperar sin comprometer al equipo con una opción costosa.
Valora la calidad de las evidencias sin darles una precisión que no tienen
Para cada nota, pregunta de dónde proceden las evidencias, a qué usuarios representan y qué otra explicación podría encajar. «Un cliente pidió un panel» podría significar que quiere menos reuniones de seguimiento, no otro sitio donde iniciar sesión. Cinco comentarios de una misma cuenta no equivalen a cinco cuentas independientes.
Deja los enlaces a las evidencias o breves extractos junto a la afirmación correspondiente. La guía para sintetizar comentarios de clientes (en inglés) puede ayudarte a organizar observaciones repetidas sin confundir la repetición con una prueba de demanda del mercado.
No resuelvas todos los desacuerdos promediando votos. Si soporte observa un problema recurrente y ventas nunca lo ha oído mencionar, averigua si atienden a grupos de clientes distintos. Coloca dos notas en el mapa cuando las afirmaciones se refieran a segmentos diferentes. Ese desacuerdo puede ser lo más útil que revele el taller.
Elige una prueba que pueda cambiar la decisión
Convierte el supuesto elegido en una ficha breve de prueba: afirmación, participantes o datos, actividad, observación, criterio de decisión y responsable. Define el criterio antes de ver el resultado. Eso no hace que un estudio pequeño sea concluyente, pero evita que el equipo cambie la definición de éxito para adaptarla a la respuesta que prefiere.
Para la prueba piloto de la agencia, invita a los clientes a través de su contacto habitual a un portal pequeño que requiera iniciar sesión y contenga una página de estado semanal ya revisada. Observa si vuelven sin recordatorios constantes y si siguen pidiendo la misma información por correo. Después, pregúntales por sus motivos. Una página de acceso público permitiría comprobar la utilidad de la información, pero dejaría sin resolver la disposición a iniciar sesión. Abrir un enlace una vez no equivale a adoptar el portal, y el silencio no implica satisfacción.
Realiza por separado una comprobación técnica de la integridad de los datos. Una prueba piloto preparada manualmente puede enseñar si la propuesta resulta útil, pero no demuestra que generar los informes de forma automática vaya a ser fiable o económico. Explicita esa incertidumbre pendiente en lugar de darla por resuelta dentro de un resultado positivo.
Utiliza el resultado para cambiar el plan
Conserva la afirmación original y añade debajo lo observado. Después, decide si seguir adelante, revisar la idea, buscar otras evidencias o detenerla. «No concluyente» es un resultado válido cuando la participación ha sido insuficiente o la prueba no ha reproducido la situación relevante.
Por ejemplo, si los clientes prefieren un correo breve y apenas regresan al portal, la agencia podría probar un mejor resumen por correo en vez de añadir funciones al portal. Si los clientes sí lo utilizan, pero el personal dedica demasiado tiempo a corregir datos, quizá la siguiente inversión deba centrarse en la calidad de esos datos. Son decisiones diferentes, aunque partan de la misma idea de producto.
Abre Boardmix y dibuja una matriz en la que la importancia aumente hacia arriba y las evidencias se refuercen hacia la derecha. En el ejemplo de la agencia, coloca «Los clientes vuelven sin recordatorios» cerca de la esquina de alta importancia y evidencias débiles. Mantén cerca, como afirmación independiente, «Los datos existentes permiten elaborar resúmenes fiables». Junto a la matriz, añade una ficha de la prueba piloto con la actividad, la observación, el criterio de decisión y el responsable. Registra los resultados debajo, en lugar de mover una nota a «evidencias sólidas» tras un único comentario positivo. Para una sesión más amplia, consulta la guía de talleres de descubrimiento de producto (en inglés).
