Imagina que entras a una ferretería y el dependiente, en vez de preguntarte qué quieres arreglar, te entrega un catálogo de 160 herramientas y te dice: "navega y encuentra la que necesitas". Eso es exactamente lo que hacen la mayoría de los productos digitales hoy.
El problema no es la falta de funcionalidades. Es que se construyen desde las herramientas, no desde los objetivos del usuario.
- Un producto organizado por capacidades obliga al usuario a hacer el trabajo de traducción entre "lo que necesito" y "lo que hay disponible".
- Un producto organizado por objetivos reduce esa fricción a cero: el usuario llega, declara su situación, y el producto responde.
Arquitectura: La tiranía del catálogo
Durante años, el modelo por defecto del producto digital ha sido el catálogo de funciones. Menús, pestañas, filtros, dashboards con decenas de widgets. Todo disponible, todo visible, todo accesible... y todo igual de irrelevante si el usuario no sabe qué necesita exactamente.
Este error tiene un origen claro: se diseña desde dentro hacia fuera. El equipo de producto conoce las capacidades del sistema y las expone fielmente. Pero el usuario no piensa en términos de funciones, piensa en términos de situaciones. "Tengo que cerrar este mes con las cuentas cuadradas." "Necesito que mi equipo deje de enviarme actualizaciones por email." "Quiero saber si este cliente va a renovar."
Nadie quiere navegar 160 herramientas. Quieren resolver su situación concreta. Si tu producto no habla ese idioma, el usuario se irá al que sí lo hable.
La irrupción de la IA ha amplificado este problema. Ahora es más fácil que nunca añadir capacidades: un modelo que resume, otro que clasifica, otro que predice. El resultado es productos que acumulan potencia bruta pero no resuelven nada específico mejor que antes. Acumular capacidades sin norte estratégico es la trampa más cara del producto moderno.
JTBD: Diseñar desde la situación, no desde la solución
Jobs-to-be-Done no es una metodología de moda. Es una pregunta brutal: ¿para qué contrata el usuario tu producto? No qué hace tu producto, sino qué trabajo le resuelve a alguien en una situación concreta.
Cuando respondes esa pregunta con honestidad, la arquitectura del producto cambia. Las funciones no desaparecen, pero se organizan alrededor de flujos con intención. El usuario no navega; avanza. No busca; es guiado.
Esto tiene implicaciones directas en cómo se priorizan las funcionalidades, cómo se diseñan los onboardings y cómo se mide el éxito del producto. Un buen proceso de validación temprana debería identificar estos trabajos antes de escribir una sola línea de código.
El test es sencillo: ¿puede tu usuario describir en una frase qué tarea concreta acaba de completar con tu producto? Si la respuesta es vaga o genérica, tienes un catálogo, no un producto.
En Room 714 trabajamos con equipos que ya tienen el producto construido y quieren entender por qué no retiene. La mayoría de las veces, el diagnóstico es este: demasiadas herramientas, demasiado pocos objetivos claros. Si reconoces ese síntoma, es el momento de hacer la pregunta correcta antes de añadir una función más.
