Un problema útil es lo bastante grande o frecuente como para merecer atención

El panel luce espectacular en la demostración. En este ejemplo ilustrativo, detecta un error de formato en una exportación mensual. Corregirlo lleva dos minutos y ocurre dos veces al año. A todo el mundo le gusta la demostración; nadie vuelve a abrir el panel después de la prueba.

El problema se puede describir, pero quizá el coste de convivir con él sea menor que el de añadir otra herramienta. La elegancia por sí sola no crea urgencia.

Una conversación sobre productos propone una prueba útil con dos ejes: desconfía de un problema que sea a la vez pequeño y poco frecuente. Un problema grande puede merecer atención aunque aparezca de vez en cuando; uno pequeño y recurrente puede acumularse hasta convertirse en un hábito diario. La idea es examinar el trabajo que hay detrás de la presentación.

Cuenta por separado los casos y sus consecuencias

«¿A cuántas personas les ocurre este problema?» es una pregunta inicial demasiado amplia. Pregunta a un equipo concreto cuándo pasó por última vez y qué sucedió después. ¿Alguien dedicó unos minutos, perdió una venta, retrasó un pedido, expuso datos privados o simplemente detectó una molestia? Esas consecuencias no son equivalentes.

Después pregunta con qué frecuencia ocurre la misma clase de situación. Una corrección semanal de cinco minutos puede consumir bastante tiempo en un equipo grande. Un fallo anual puede seguir siendo importante si impide una transferencia crítica. Es más difícil vender un producto independiente para una molestia que ocurre dos veces al año y se resuelve en dos minutos.

Considera una elección ilustrativa que combina ambos ejes:

Estas categorías son preguntas que conviene investigar, no veredictos de mercado. Qué significa «alto» depende de a quién se le atribuya el coste. Un error que apenas afecta a una persona administradora puede crear un problema serio para un cliente. Un fallo que no apareció en una entrevista breve puede ser central durante los picos estacionales.

Un problema puede parecer pequeño en una demostración y grande en un sistema

El trabajo de integración deja clara la diferencia. Un valor de campo incorrecto parece un detalle en el registro de un contacto. Si el mismo mapa se aplica a miles de contactos, se convierte en una fuente recurrente de correcciones manuales. Al contrario, una alerta sofisticada para una discrepancia estética aislada puede añadir más trabajo administrativo del que ahorra.

La guía para integrar herramientas empresariales empieza por un flujo de trabajo y una fuente de verdad, porque el coste real está en cómo se mueven y utilizan los registros. Del mismo modo, un equipo que decida si debe pasar de herramientas gratuitas a un plan de pago debería contar las soluciones provisionales y las acciones que se pierden, en vez de limitarse a comparar listas de funciones.

Pregunta por los tres últimos casos reales. Para cada uno, registra quién lo detectó, quién lo corrigió, qué otro trabajo se interrumpió y qué habría pasado si nadie hubiera intervenido. Esta última pregunta distingue una molestia de un riesgo invisible. También evita que una persona fundadora o compradora convierta una hipótesis llamativa en un patrón medido.

Después pregunta cuánto cuesta la solución actual. Una hoja de cálculo y una comprobación de cinco minutos quizá sean suficientes. Un proceso manual que obliga a una persona especialista a conciliar registros cada mañana quizá no lo sea. La alternativa forma parte del valor del producto; no conviene ignorarla.

Comprueba también el coste de adopción

Incluso un problema importante puede no justificar una aplicación nueva. Alguien debe conectarla, aprender a usarla, revisar sus resultados y mantener los accesos. Si el producto exige más atención que la tarea, es razonable que quienes lo compran sigan con su método provisional.

La conversación de origen también advierte de que una configuración manual puede hacer que el interés inicial parezca mayor de lo que es. Puede parecer que un equipo compra software cuando en realidad depende de consultoría no facturada. Es especialmente difícil atender de forma sostenible un problema pequeño con un proceso de incorporación caro. Eso no prohíbe ofrecer servicios; significa que también hay que contabilizarlos.

Hay excepciones a este enfoque de dos ejes. Las obligaciones de cumplimiento pueden exigir actuar aunque los incidentes observados sean poco frecuentes. Un mercado nuevo puede tener poco historial que medir. Un grupo de nicho puede sufrir lo bastante como para justificar una solución, aunque la población general no tenga el mismo problema. En esos casos, las pruebas deberían proceder de obligaciones, vías de fallo creíbles o presupuestos comprometidos, no solo de una estimación de frecuencia.

Los ejes también ayudan a decidir si una necesidad merece un producto independiente o una pequeña función dentro de algo que la gente ya utiliza. Puede que un problema de formato, poco frecuente y menor, merezca un botón dentro del flujo de exportación, aunque nadie se suscriba a un servicio aparte para resolverlo. Un problema pequeño y frecuente quizá se solucione mejor cambiando una opción predeterminada que vendiendo otro panel. El alcance del producto debe corresponderse con la atención que ya exige la tarea. La pregunta no es si existe el problema, sino cuánto comportamiento nuevo puede pedir razonablemente la solución.

La pregunta de descubrimiento más útil no es «¿Lo usarías?», sino «Cuéntame la última vez que pasó, cuánto costó y qué hiciste en su lugar». Un producto merece existir cuando esa respuesta apunta a un trabajo que la gente ya intenta cambiar.