Discovery de producto para founder no técnico: qué vale, qué no, y cómo hacerlo en cuatro semanas

Una founder que conocemos pagó US$ 18.000 por “discovery de producto” a finales de 2024. La entrega fue un Notion de 64 páginas con personas, mapas de jornada, hipótesis, mapas de empatía y tres workshops grabados. Bien hecho, dentro del estándar de los cursos de producto. Cuatro meses después seguía sin software, sin alcance, sin decisión. Tenía un informe.

Discovery de producto, en una línea, es el trabajo de convertir una intuición sobre una oportunidad en una decisión de construir, con alcance, costo y plazo defendibles. Para un equipo de producto maduro, esto es una práctica continua de investigación y validación. Para un founder no técnico que aún no ha construido nada, es otra cosa: es la diligencia mínima que separa un brief serio de un cheque firmado a oscuras. Los artículos que dominan esta búsqueda en Google enseñan la primera versión. La segunda, que es la tuya, no la escribe nadie.

Este texto trata de la versión que sirve para tu situación. Más corta, más estrecha, y que termina con una decisión, no con un documento.

Discovery no es investigación, es diligencia

La palabra “discovery” trae un problema de traducción cultural. En el léxico americano de producto viene del mundo de PMs senior en empresas grandes, donde el tiempo dedicado a explorar un problema se justifica por la escala de la decisión de roadmap que viene después. Cuando eres un founder no técnico y aún no has construido nada, tu decisión no es “qué feature priorizar en el Q3”. Tu decisión es “vale la pena construir algo, con qué alcance, y con qué presupuesto”. Eso es diligencia, no investigación.

La diligencia tiene criterios objetivos. La investigación tiene preguntas abiertas. Las dos se parecen en las primeras semanas. La diferencia aparece cuando intentas cerrar.

La versión que vamos a describir aquí es, de hecho, un subconjunto disciplinado de lo que enseñan los frameworks canónicos (Marty Cagan, Teresa Torres, Jeff Patton). Es la parte que paga el alquiler para tu etapa. El resto, en general, te va a costar tiempo que no tienes.

Dónde falla el discovery típico para founders

El modelo estándar asume tres cosas que el founder no técnico no tiene: un equipo multidisciplinar, un producto en marcha, y decenas de usuarios disponibles para entrevista continua. Quita esas tres premisas del framework e intenta aplicarlo igual, y eres como un cardiólogo tratando a un paciente sin ningún examen de imagen. Sigue dando buenos pálpitos, pero pierde la herramienta principal.

Tres fallos repetidos en muchos founders.

El primero es el discovery sin plazo. Sin deadline duro, el discovery se convierte en el mejor proyecto de tu vida. Siempre encuentras una entrevista más, una hipótesis más por validar, una pieza más de market research que parece útil. Un mes se vuelve tres, tres se vuelven seis. El capital se quema y el software no nace.

El segundo es el discovery académico. El founder, normalmente alguien con formación de consultoría o finanzas, ama los frameworks. Aprende sobre Jobs to Be Done, Double Diamond, Design Thinking, Lean UX y quiere aplicarlos todos. El resultado es un trabajo que parece una tesis de máster en producto y nunca responde a la pregunta básica: ¿se puede construir, con quién, por cuánto, en cuánto tiempo?

El tercero, y el más caro, es el discovery sin usuario real. Los founders se sienten tentados a hacer toda la “investigación” con colegas, mentores e inversores. Esa gente es generosa con la opinión y económica con la verdad. Lo que te dicen en una llamada de 30 minutos no es lo que un cliente real pagaría por resolver. El discovery de founder exige conversaciones con al menos cinco personas que encajen exactamente en tu ICP, fuera de tu círculo, que no te deban nada.

Las cinco preguntas que todo discovery de founder responde

En lugar de adoptar un framework de producto traducido, proponemos cinco preguntas. Son pequeñas, pero si no puedes responder cada una con una frase concreta, todavía no terminaste.

1. ¿Quién es la persona específica que va a pagar, y por qué paga hoy (aunque mal) por el problema? Si no puedes decir “ella paga US$ X por Y, hoy, con la solución Z”, todavía tienes una hipótesis de mercado, no un cliente. Vale para B2B y para B2C.

2. ¿Qué fricción tolera porque no tiene alternativa? El software que vale construir resuelve fricción real. No la que ella menciona primero (que normalmente es el precio), sino la que aparece cuando preguntas “¿cómo lo haces hoy?” y oyes la descripción de un proceso manual que nadie debería estar haciendo en 2026.

3. ¿Cuál es el alcance mínimo que cambia un workflow manual por un workflow automatizado, de punta a punta, para un único caso de uso? Atención a “punta a punta”. La mitad del software que los founders compran resuelve sólo la parte bonita del problema y empuja el resto a una hoja de cálculo. Eso no es producto, es demo.

4. ¿Qué evidencia muestra que tu versión es lo bastante diferente como para que alguien pague? Diferente en qué: precio, integración, flujo, datos, contexto local. Si tu respuesta es “mejor diseño”, todavía estás buscando. Mejor diseño solo casi nunca es un wedge defendible.

5. ¿Qué es lo más grande que puede salir mal, y cómo sabrías en cuatro semanas que salió mal? Toda construcción es una apuesta. El discovery termina cuando tienes una hipótesis falsable rápidamente, y un plan explícito para probarla una vez que el código exista.

Si puedes contestar las cinco en una página, terminaste. Si las contestas en veinte páginas, hiciste el discovery equivocado.

El discovery de cuatro semanas: cronograma honesto

No conocemos un solo buen discovery de founder que haya durado más de cuatro semanas de tiempo dedicado. Conocemos varios que se estiraron en tiempo total porque el founder lo combinaba con otras cosas, pero el “tiempo de foco” rara vez pasa de un mes útil.

Este es el cronograma que recomendamos para un founder no técnico que todavía no ha construido nada:

Semana 1: Mapa del territorio. Dibujas el problema con el vocabulario de tus futuros clientes (no con tu vocabulario académico de founder). Listas explícitamente quién vive ese problema hoy. Haces de cinco a ocho conversaciones cortas (30 minutos), grabadas y transcritas, con personas que no conoces personalmente. Preguntas cómo lo resuelven hoy, cuánto pagarían, y qué alguna vez “intentaron y no funcionó”.

Semana 2: Un caso de uso punta a punta. Tomas un único caso real de una de las personas entrevistadas y dibujas su flujo completo, desde el momento en que se dispara el problema hasta el resultado deseado. En papel, en Miro, en Excel, da igual. El criterio: alguien que nunca oyó hablar de tu producto puede leer ese flujo y describir lo que haría el software. Eso ya te obliga a cortar el 40% de lo que imaginabas al inicio.

Semana 3: Un spec de una página. Traducción del flujo a una especificación corta que describa qué hace el software, qué decisiones automatiza, qué decisiones deja al usuario, y qué integraciones necesita para no romperse en el primer mes. Ese spec es la base del product requirements document que vas a entregar al desarrollador.

Semana 4: Diligencia comercial. Usas ese spec para conversar con dos o tres software houses, un freelancer senior, y (si tiene sentido) un candidato a primer dev interno. No para contratar. Para validar tres cosas: el alcance es lo bastante claro como para recibir un presupuesto serio, ese presupuesto encaja con tu matriz de costo, y el cronograma cabe dentro del runway que tienes antes de la próxima ventana comercial.

Cuatro semanas. Cinco preguntas respondidas. Un spec de una página. Tres cotizaciones comparables. No terminaste un Notion de 64 páginas, terminaste una decisión.

El entregable: una especificación que impide que la software house te juegue

La mayor virtud del discovery corto es lo que sale de él. No es una presentación. No es un informe. Es una página densa que describe, al nivel correcto de detalle, lo que va a hacer el software.

Este spec tiene cuatro bloques, y nada más.

El objetivo de negocio en dos líneas. Si gastas más que eso, todavía no convergiste.

El caso de uso primario como una jornada de cinco a ocho pasos, desde el disparo hasta el resultado. Puedes escribir este bloque como bullets de comportamiento (“el usuario pega el link”, “el sistema valida”, “el sistema pregunta”, “el sistema ejecuta”, “el sistema notifica”). Sin decoración, sin visualización.

Las decisiones técnicas que toma el founder, y las que el founder delega. Hay tres o cuatro decisiones que afectan al presupuesto y que el founder necesita poder defender (multi-tenant o no, integración crítica X o Y, mobile-first o web-first, datos sensibles bajo regulación o no). El resto, lo delegas a quien va a construir.

Las tres cosas que quedan explícitamente fuera del alcance de la v1. El buen discovery va tanto sobre lo que entra como sobre lo que se queda fuera. Cuando nombras lo que estás cortando, cortas de verdad. Cuando no lo nombras, la software house reabre la conversación cuando el presupuesto empieza a apretar.

Este documento de una página es la diferencia entre un brief que una software house puede cotizar de forma cerrada y un brief que se vuelve un contrato T&M sin techo. Es el filtro contra el presupuesto inflado: cuando el alcance está claro, queda obvio cuándo el número es cobro honesto y cuándo es grasa.

Cuándo estás terminando discovery, y cuándo estás procrastinando

La línea entre “todavía no terminé” y “estoy usando el discovery para retrasar la decisión” es fina. Para la mayoría de founders no técnicos, pasa por aquí.

Si llevas más de cuatro semanas dedicado al discovery, ya no estás validando, estás postergando. El discovery no mejora con más tiempo a partir de un punto. Se vuelve más redundante. Cada nueva entrevista confirma lo que ya dijeron las tres anteriores, o contradice algo específico que se resuelve con una decisión pequeña, no con un mes más de investigación.

Si no puedes escribir tu spec de una página sin volver a “depende del feedback de los usuarios”, estás en un loop de validación que no va a terminar solo. El spec es el resultado de la síntesis, no de la investigación continua. En algún momento cierras el cuaderno y escribes.

Si todavía no conversaste con ninguna software house, freelancer o candidato a dev usando tu material, sólo hiciste la mitad del discovery. La diligencia técnica y comercial es lo que valida que tu spec sea construible dentro del presupuesto y del tiempo. Saltarse esa parte es como aprobar un plan de viaje sin verificar si hay vuelo al destino.

Volviendo a la primera PAA: ¿qué es entonces el discovery de producto?

En una frase: es el trabajo de convertir una intuición sobre una oportunidad en una decisión de construir, con alcance, costo y plazo defendibles. Para un founder no técnico, es un ejercicio de diligencia hecho en cuatro semanas, anclado en cinco preguntas, con un spec de una página como salida.

No es un workshop. No es hipótesis apilada sobre hipótesis. No es mapa de empatía. Esas herramientas existen, son útiles en otras situaciones, y pueden aparecer puntualmente dentro de tu discovery. No deberían ser el discovery.

¿Y las cuatro fases del producto?

La PAA pregunta esto porque el internet de producto en español repite mucho la frase “ciclo del producto”. Para el founder, las cuatro fases que importan son, en orden honesto: discovery (estás aquí), decisión de construir, primera versión real en producción, e iteración con clientes que pagan. La elección de herramientas y enfoques dentro de la tercera fase sólo tiene sentido cuando la fase 1 ya entregó una decisión.

La fase en la que la mayoría de founders no técnicos se atasca es entre 1 y 2. El discovery termina cuando tienes evidencia suficiente para tomar una decisión de construir. Si todavía estás recolectando evidencia, no saliste de la fase 1.

Cómo saber que terminaste: la prueba del sobre

Si un cliente potencial entrara en tu sala ahora mismo, y tuvieras que explicar en tres minutos qué vas a construir, para quién, con qué diferencia, en cuánto tiempo y por cuánto, ¿podrías? Sin slides, sin Notion, sin volver a “depende”.

Si sí, terminaste el discovery. Puedes dejar de investigar y empezar a construir.

Si no, todavía tienes trabajo. Pero el trabajo es cerrar una de las cinco preguntas, no empezar todas otra vez.

El discovery de founder no es la parte glamurosa del trabajo. Pero es la única parte en la que cinco horas de honestidad brutal valen más que cincuenta horas de framework. La diferencia entre los founders que construyen y los que se quedan en discovery durante nueve meses suele ser sólo esa: los primeros saben cerrar.