Discovery de producto antes de crear una aplicación
Cómo definir problema, personas usuarias, alcance, riesgos y criterios de aceptación antes de crear una aplicación, y qué documento debe cerrar discovery.

Discovery es la fase previa al desarrollo en la que se acuerdan problema, personas usuarias, efecto esperado, límites de alcance, riesgos y supuestos técnicos. El resultado debe ser un documento suficiente para comparar alternativas y preparar un presupuesto, con un alcance proporcional al tamaño del proyecto.
No garantiza un coste menor, pero reduce incertidumbre: revela expectativas contradictorias, ausencia de datos, integraciones difíciles o riesgo jurídico antes de que dependan de ellos muchas funciones terminadas.
Para qué sirve si ya sé qué quiero construir
Una descripción de idea puede entenderse de modo diferente por quien encarga, usa y desarrolla. Antes de la primera línea de código conviene comprobar tres desajustes:
- De alcance. «Panel de administración» puede significar tres pantallas o treinta. Sin acordar qué entra en presupuesto, el conflicto es cuestión de tiempo.
- De problema. Se quiere una aplicación para gestionar encargos, pero el problema real es que llegan por cinco canales y nadie los recoge. Una aplicación no resuelve un problema que no toca.
- De persona usuaria. Quien compra y quien usa suelen ser personas distintas, con necesidades distintas. Una aplicación diseñada para quien compra puede no ser utilizada por el equipo.
Qué ocurre durante discovery
1. Objetivos de negocio, no lista de funciones
La primera pregunta no es «qué debe hacer la aplicación», sino «qué debe cambiar en la empresa si funciona». La respuesta sirve luego para descartar funciones: si no contribuyen a ese cambio, salen de la primera versión. Las buenas respuestas se pueden medir: reducir tiempo de gestión, dejar de transcribir datos entre sistemas o permitir a la clientela consultar sin llamar a la oficina.
2. Personas usuarias y sus tareas
Quién la utilizará, con qué frecuencia, en qué dispositivo y qué intenta lograr. La pregunta más útil es: ¿cómo se hace hoy? Aunque la respuesta sea una hoja de cálculo y tres correos, describe el proceso que hay que atender.
3. Proceso actual y proceso deseado
Se mapea el recorrido actual, los lugares donde se pierde algo y el recorrido objetivo. En cada paso preguntamos: «¿qué haces cuando los datos no encajan?» Esas respuestas describen el proceso real y a menudo determinan el coste.
4. Modelo de datos
Definimos los conceptos principales del dominio y sus relaciones, no todas las tablas «por si acaso». Comprobamos que el alcance no depende de definiciones contradictorias: cambiar relaciones básicas después puede exigir migraciones y actualizar muchas funciones.
5. Restricciones e integraciones
Sistemas que conectar, requisitos legales, datos personales, plazos externos y presupuesto. Una restricción puede cambiar de forma importante el presupuesto: por ejemplo, si un sistema no expone la interfaz necesaria o un contrato prohíbe cierta forma de tratar datos.
6. Alcance de la primera versión
Separa «debe existir para que funcione» de «sería bueno tener», justificando cada elemento. Para un producto con un recorrido clave, un referente puede ser MVP en 4–6 semanas.
7. Riesgos explícitos
Una lista de cosas que pueden salir mal con su impacto. Un proyecto sin riesgos anotados no es más seguro: simplemente los descubrirá tarde y con mayor coste.
Qué debe resultar
Un documento concreto, no notas de conversación. En nuestro caso incluye:
- descripción del problema y objetivos medibles;
- personas usuarias y tareas;
- proceso objetivo;
- modelo de datos y arquitectura;
- alcance de primera versión y lista de elementos pospuestos conscientemente;
- calendario por etapas y presupuesto;
- riesgos con plan de respuesta.
El documento es tuyo y puedes ejecutarlo con nosotros o con otra empresa. Si encargas el desarrollo con nosotros, descontamos el importe de discovery del presupuesto del proyecto. Los pasos siguientes se describen en cómo crear una aplicación desde cero.
Cuánto cuesta y cuánto dura
Nuestras horquillas de agosto de 2026: taller discovery con documento de dirección 3.000–8.000 PLN netos; diseño y planificación completos con arquitectura, hoja de ruta y estimaciones 8.000–25.000 PLN netos. Depende de participantes, integraciones y materiales disponibles; normalmente va desde un taller hasta unas dos semanas.
Presupuestar un proyecto descrito en un párrafo contiene más supuestos y riesgo para ambos lados. Un alcance detallado permite señalar qué incluye el precio, qué datos debe aportar la clientela y qué provoca una nueva estimación. Discovery puede reducir el colchón de incertidumbre, pero también descubrir un requisito que eleve el precio honesto.
Cuándo no hace falta discovery
- Cuando el alcance es realmente pequeño e inequívoco: una integración, una pantalla, un flujo.
- Cuando ya tienes una buena especificación, especialmente si alguien técnico está de tu lado; entonces basta una revisión.
- Cuando el problema es validar la idea, no delimitarla. Primero comprueba, incluso manualmente, si alguien lo quiere. Discovery sirve cuando se sabe que el problema es real.
Cómo prepararte
- Reúne ejemplos reales: encargos, documentos, correos y hojas que utilizáis.
- Invita a quien realiza el trabajo, no solo a quien lo encarga.
- Anota qué no se puede hacer hoy aunque debería poderse.
- Decide quién toma las decisiones de alcance. La ausencia de una persona con autoridad provoca pausas y acuerdos contradictorios.
Preguntas frecuentes
¿Se puede hacer discovery en remoto?
Sí; es como solemos hacerlo: taller online de 2–3 horas, trabajo por nuestra parte y después una ronda de preguntas complementarias.
¿Tenemos que encargaros el desarrollo después?
No. El documento es tuyo y no obliga a nada. Si continuamos, descontamos el importe del proyecto según las condiciones de la oferta.
¿En qué se diferencia de una auditoría de IA?
La auditoría de IA responde «dónde compensa IA en nuestra empresa». Discovery responde «qué construir exactamente y cómo». A veces la auditoría precede al discovery.
Llevamos proyectos propios por la secuencia discovery → brief → plan → implantación; así dirigimos también la renovación de este sitio. Consulta diseño y planificación o cuéntanos tu idea.

Autor
Maciej Szukalski
Fundador de Condictor · arquitecto de sistemas · investigación y desarrollo
Diseña y desarrolla productos digitales desde 2014. Se especializa en arquitectura, investigación y aplicaciones con capas de automatización e inteligencia.
Conoce su experiencia y forma de trabajo¿Tienes un problema que resolver?
Veamos cuál es el mejor primer paso
Describe tu situación en unas frases. Volveremos con preguntas o una propuesta concreta para el siguiente paso.
