Señales de que tu idea todavía no está lista para desarrollarse

La decisión de desarrollar un producto digital es probablemente una de las más caras que vas a tomar como founder o emprendedor. No solo por el costo del desarrollo en sí, sino por el costo de oportunidad: cada mes que invertís en construir algo que el mercado no necesita es un mes que no dedicaste a encontrar lo que sí necesita.

La buena noticia es que hay señales bastante concretas que indican cuándo una idea todavía no está lista. No son abstractas ni dependen de la experiencia previa de quien las evalúa. Son observables, medibles, y — si uno está dispuesto a escucharlas — ahorran mucho más dinero del que cuesta ignorarlas.

Señal 1: No podés nombrar a tres personas concretas que tengan el problema

Esta es la más reveladora y también la más resistida. Cuando preguntás "¿quién tiene este problema?", la respuesta suele ser "muchos comercios", "las pymes", "cualquier empresa que haga X". Pero cuando pedís nombres, teléfonos o direcciones de correo de personas reales que hoy están sufriendo ese problema, la conversación cambia.

Si no podés nombrar a tres personas concretas — con nombre y apellido, con un contexto, con un proceso actual que podrías observar — que tengan el problema que tu idea resuelve, hay una probabilidad alta de que el problema no sea tan intenso como pensás, o de que las personas que lo tienen no sean fáciles de alcanzar, o de que estés resolviendo algo que a vos te parece relevante pero que a tu mercado objetivo no le quita el sueño.

Tres personas no es un número mágico, pero es un umbral práctico: si ni siquiera tres personas que conocés o podés contactar tienen este problema, ¿cómo vas a encontrar trescientas, o tres mil? Y sin usuarios, no hay producto.

Señal 2: El problema cambia cada vez que lo explicás

Una idea está lista cuando cinco personas distintas del equipo pueden describir el problema en una oración y decir lo mismo. Si cada vez que alguien explica qué problema resuelve el producto la descripción cambia — aparecen matices nuevos, se agregan casos de uso, se amplía el alcance —, el problema no está definido.

Un problema bien definido tiene tres componentes que se pueden escribir sin ambigüedad: quién lo tiene, en qué situación aparece, y qué consecuencia concreta genera. Si alguno de esos tres componentes cambia según quién lo cuenta, la definición no está lista.

Esto no se arregla con más reuniones de equipo. Se arregla saliendo a hablar con las personas que supuestamente tienen el problema y dejando que sean ellas — no el equipo — quienes definan cómo se ve ese problema en su día a día. Si lo que ellas describen no coincide con lo que el equipo venía suponiendo, el problema no es de ellas: es de la definición.

Señal 3: No tenés una métrica de éxito que puedas medir sin el producto

Muchos equipos definen el éxito del producto en función de métricas que solo van a existir cuando el producto esté construido: cantidad de usuarios registrados, tasa de retención, ingresos recurrentes. Pero para saber si la idea está lista, necesitás una métrica que puedas medir hoy, antes de escribir una línea de código.

Una métrica de validación pre-producto responde a la pregunta: ¿cómo sé, hoy, que este problema es lo suficientemente grave como para justificar una solución? Puede ser el tiempo que alguien pierde por semana en un proceso manual, la cantidad de errores que genera ese proceso, el dinero que se deja de ganar por no tener una herramienta adecuada, o la cantidad de clientes que se pierden por un cuello de botella específico.

Si no podés ponerle un número a ninguna de estas cosas, no sabés si el problema vale lo que cuesta resolverlo. Y construir sin saber si el problema justifica la inversión es una apuesta, no una decisión de negocio.

Señal 4: No sabés qué haría el usuario el primer día que use el producto

Una idea lista para desarrollarse no solo tiene claro el problema: tiene claro el primer comportamiento concreto que se espera del usuario. No "que le guste", no "que lo recomiende", no "que vuelva". Algo observable: que cargue un dato, que complete un pedido, que genere un comprobante, que cierre una tarea.

Si no podés describir la secuencia exacta de acciones que un usuario haría en su primera sesión — paso por paso, desde que abre la herramienta hasta que obtiene un resultado —, lo que tenés es una visión, no un producto. Las visiones son necesarias, pero no están listas para desarrollo: necesitan traducirse a comportamientos concretos antes de que un equipo técnico pueda construir algo útil.

Esta señal se detecta fácil con un ejercicio simple: dibujá las pantallas que vería el usuario en su primera sesión. No necesitás diseño: papel y lápiz alcanza. Si no podés dibujar las primeras tres pantallas sin dudar sobre qué va en cada una, la idea no está lo suficientemente madura.

Señal 5: Estás construyendo para un problema que no tenés forma de observar

Hay una diferencia enorme entre suponer que un problema existe y haberlo visto existir. Si tu conocimiento del problema viene de artículos, reportes de industria o conversaciones informales, pero nunca observaste a alguien atravesarlo en tiempo real — viendo qué hace, qué decide, qué atajos improvisa, qué abandona —, estás diseñando a ciegas.

La observación directa revela cosas que ninguna entrevista revela: procesos que la persona ni siquiera menciona porque los da por sentados, pasos que saltea porque le parecen irrelevantes, frustraciones que no verbaliza porque asume que son inevitables. Sin esa observación, el producto va a estar diseñado para resolver el problema tal como el equipo lo imagina, no como el usuario lo vive.

Esto no significa que no puedas construir nada sin observación directa. Pero sí significa que el riesgo de equivocarse es mucho más alto, y que ese riesgo debería estar explícito en la conversación sobre si desarrollar o no.

Qué hacer cuando detectás estas señales

Detectar que una idea no está lista no es un fracaso. Es información que evita un fracaso más caro. Y hay cosas concretas que se pueden hacer para mover la idea de "no lista" a "lista" sin gastar en desarrollo:

• Si no tenés tres personas concretas, salí a hablar con gente de tu mercado objetivo. No a venderles nada: a entender cómo resuelven hoy el problema que creés que tienen.
• Si el problema cambia cada vez que lo explicás, escribí la definición en una oración y mostrásela a cinco personas ajenas al equipo. Si no entienden lo mismo, la definición no es clara.
• Si no tenés métrica de éxito, medí el proceso actual durante dos semanas. Aunque sea a mano, con un cronómetro y una planilla. Cualquier número es mejor que ninguna medición.
• Si no sabés qué haría el usuario en su primera sesión, construí un prototipo en papel o con herramientas de maquetado y ponelo frente a alguien. Observá qué hace, no qué dice.
• Si no podés observar el problema, encontrá la forma. Una videollamada donde alguien comparta pantalla mientras hace su proceso actual es mejor que diez entrevistas.

Cuándo sí conviene avanzar

Así como hay señales de que la idea no está lista, también las hay de que sí lo está. Si podés responder afirmativamente a estas tres preguntas, probablemente estés en un buen momento para arrancar:

• ¿Hay al menos tres personas que reconocen tener el problema y están dispuestas a probar una solución?
• ¿Podés describir el problema en una oración sin que nadie te pida aclaraciones?
• ¿Sabés exactamente qué haría un usuario en su primera sesión y qué resultado obtendría?

Si las tres respuestas son sí, avanzar tiene sentido. Si alguna es no, la inversión más rentable en este momento no es desarrollo: es investigación.

Para profundizar en el proceso de validación, revisá qué validar antes de desarrollar una aplicación. Si ya pasaste esta etapa y estás definiendo el alcance, te puede servir cómo definir el alcance de un MVP.