De la idea al proyecto
Cómo evaluar y delimitar una idea tecnológica antes de construirla.
Casi ningún proyecto tecnológico fracasa por escribir mal el código. Fracasa antes: por resolver un problema que nadie tenía, para un usuario que nunca existió, con un alcance que jamás cupo en el tiempo disponible.
Cómo funciona esta guía
Puede cambiar mil veces. Sirve para que la ficha tenga con qué encabezarse.
¿Para qué sirve esta guía?
Tener una idea es un buen punto de partida, pero no es todavía un proyecto. Entre una cosa y la otra hay un trabajo que casi nadie disfruta y que casi todos se saltan: convertir el entusiasmo en algo que pueda discutirse, criticarse y, si hace falta, abandonarse a tiempo.
Cuando alguien propone desarrollar una aplicación, una plataforma web, un dispositivo con sensores, una herramienta educativa o un sistema con inteligencia artificial, la conversación arranca casi siempre por la parte más visible —y, hay que decirlo, la más divertida—: la solución.
«Quiero hacer una app para…»
«Quiero construir un dispositivo que…»
«Quiero usar inteligencia artificial para…»
El problema es que una solución puede ser técnicamente impecable y, aun así, estar mal delimitada, atender una dificultad menor, dirigirse a usuarios demasiado generales o exigir mucho más tiempo del que el equipo realmente tiene. Nada de eso se nota mientras se dibuja la interfaz. Se nota tres meses después.
Esta guía está pensada para detenerse antes de construir. Su propósito no es dictaminar si una idea “es buena” o “es mala” —esa pregunta rara vez tiene respuesta útil—, sino ayudar a convertirla en un proyecto que pueda explicarse en voz alta sin que se caiga a pedazos.
Un proyecto puede perseguir fines muy distintos. Puede buscar:
- Aprender una tecnología.
- Resolver un problema educativo.
- Generar impacto social.
- Apoyar una necesidad dentro de una institución.
- Convertirse en una tesis.
- Producir una herramienta útil para una comunidad.
- Explorar una oportunidad de negocio.
- Desarrollar una prueba de concepto.
- Servir como base para un proyecto de investigación.
Todos esos objetivos son legítimos y ninguno es más serio que otro. Lo que ninguno perdona es la vaguedad.
Primero: ¿qué tipo de proyecto quieres hacer?
Antes de discutir funciones, lenguajes, sensores, modelos o plataformas, conviene nombrar el resultado que esperas obtener. Suena obvio, pero es el paso que más se omite: dos personas pueden trabajar en la misma idea durante semanas creyendo que persiguen cosas distintas.
Ubica tu proyecto en una de estas categorías. No para encasillarlo, sino para saber contra qué vara vas a medirlo.
| Tipo de proyecto | Pregunta principal | Un resultado exitoso podría ser |
|---|---|---|
| Aprendizaje técnico | ¿Qué quiero aprender a construir? | Prototipo funcional que demuestre una habilidad |
| Proyecto académico o tesis | ¿Qué pregunta quiero responder o evaluar? | Evidencia, análisis y documento académico |
| Impacto educativo o social | ¿Qué situación quiero mejorar? | Cambio observable en una población o proceso |
| Producto para una institución | ¿Qué problema operativo quiero resolver? | Herramienta adoptada por usuarios reales |
| Emprendimiento | ¿Existe una oportunidad por la que alguien pagaría? | Usuarios, adopción, ventas o piloto |
| Investigación tecnológica | ¿Qué capacidad nueva quiero demostrar? | Método, prototipo, publicación o prueba de concepto |
La tercera pregunta es la más incómoda y, con diferencia, la más útil. Casi todo el crecimiento descontrolado de un proyecto empieza por demostrar cosas que nadie pidió.
El problema antes que la solución
Una idea tecnológica suele nacer ya vestida de solución. Escuchamos la propuesta y podemos imaginar la pantalla, el dispositivo, el flujo de trabajo. Lo que rara vez escuchamos es la dificultad que le dio origen.
«Una aplicación tipo Duolingo para aprender neurociencias.»
«Un sistema con visión artificial para…»
«Un wearable que mida…»
Todas esas frases describen qué se va a construir. Ninguna responde la pregunta que va antes:
¿Qué problema existe aunque tu solución todavía no exista?
Un problema bien definido describe una dificultad real que alguien experimenta, y no debería depender de la tecnología propuesta. La diferencia se ve mejor con un ejemplo:
Hace falta una app de neurociencias.
Personas interesadas en aprender fundamentos de neurociencias encuentran información dispersa, con niveles de profundidad inconsistentes y sin una ruta clara para avanzar.
La segunda formulación abre la puerta a muchas soluciones posibles. Quizá una aplicación sea la adecuada. Quizá lo sea un curso, una guía, una comunidad o simplemente un índice bien hecho. Esa incertidumbre no es un defecto: es la señal de que el problema está bien planteado.
Completa, si es posible: “Actualmente, ______ intenta ______, pero tiene dificultades porque ______.”
Describe una situación concreta, no una generalidad.
Pérdida de tiempo, errores, costos, frustración, abandono, mala calidad, riesgo, falta de acceso.
Un buen enunciado de problema sobrevive a su propia solución: si mañana cambias de tecnología, el problema sigue ahí, intacto, esperando.
¿Quién tiene realmente ese problema?
“Estudiantes”, “público general”, “médicos”, “personas interesadas en tecnología” o “usuarios de internet” no son usuarios: son categorías censales. Dentro de cualquiera de ellas caben personas con necesidades completamente incompatibles entre sí.
Un proyecto que funciona casi siempre empieza con un grupo mucho más pequeño y mucho más concreto de lo que resulta cómodo admitir.
Personas interesadas en neurociencias.
Estudiantes universitarios sin formación biomédica que quieren adquirir fundamentos de neurociencia de manera autodidacta.
La diferencia práctica es enorme. A la primera población no puedes buscarla. A la segunda puedes encontrarla el martes por la tarde, entrevistarla y observar qué hace cuando se atora.
Describe un grupo específico: dónde está, qué hace, en qué contexto aparece el problema.
Si no puedes encontrar a tus usuarios, eso ya es un resultado del estudio, no un obstáculo administrativo. Anótalo.
Evidencia: ¿cómo sabes que el problema existe?
Revisar artículos, estadísticas, reportes de mercado y tendencias es un ejercicio valioso, pero no sustituye conocer directamente a las personas que tienen el problema. La literatura te dice que algo ocurre en el mundo; los usuarios te dicen si ocurre aquí, ahora y a alguien concreto.
Conviene distinguir tres niveles. No se diferencian por lo convincente que suene el argumento, sino por lo que le costó a alguien producirlo.
- “Yo creo que esto sería útil.”
- “Mis amigos dijeron que les gustaría.”
- “El mercado de esta industria es enorme.”
- “Una aplicación parecida tiene millones de usuarios.”
- “Hay muchas publicaciones sobre este tema.”
- Encuestas y formularios de interés.
- Listas de espera.
- Personas que aceptan probar un prototipo.
- Usuarios que dejan su correo.
- Personas que completan una prueba.
- Las personas ya intentan resolver el problema por su cuenta.
- Invierten tiempo o dinero en resolverlo.
- Utilizan soluciones alternativas, aunque sean incómodas.
- Describen dificultades recurrentes, no anecdóticas.
- Regresan voluntariamente a utilizar tu solución.
- La recomiendan a otros.
- Una institución acepta probarla.
- Alguien está dispuesto a pagar.
Antes de construir, habla con usuarios
Hay una pregunta que conviene no hacer, porque su respuesta casi nunca sirve:
«¿Usarías una aplicación como ésta?»
La gente es amable. Dirá que sí. Preguntar por el futuro invita a la cortesía; preguntar por el pasado obliga a los hechos. Por eso funcionan mejor estas otras:
- ¿Cuándo fue la última vez que tuviste este problema?
- ¿Qué hiciste para resolverlo?
- ¿Qué herramientas utilizaste?
- ¿Qué fue lo más difícil?
- ¿Cuánto tiempo te tomó?
- ¿Abandonaste en algún momento?
- ¿Has pagado por alguna solución?
- ¿Qué haces actualmente cuando vuelve a ocurrir?
Sepáralas: evidencia de literatura, estadísticas o internet, frente a evidencia obtenida directamente de usuarios.
¿Cómo lo resuelven hoy?
Tus competidores no son únicamente otros productos parecidos al tuyo. La competencia real es cualquier alternativa que el usuario ya utiliza hoy, por rudimentaria que sea.
Puede ser otra aplicación, una hoja de cálculo, WhatsApp, YouTube, una libreta, un proceso manual, un profesor, un libro, ChatGPT, un servicio profesional… o simplemente no hacer nada, que suele ser la alternativa más popular de todas.
Muy pocas ideas tecnológicas pierden contra una empresa rival. Casi todas pierden contra una frase:
«La solución actual no es perfecta, pero es suficientemente buena.»
Enumera al menos tres alternativas reales, incluida la de no hacer nada.
Si la única respuesta a la pregunta 15 es “porque la mía tendrá más funciones”, todavía hace falta trabajo. Cambiar de herramienta siempre cuesta algo; la mejora tiene que ser mayor que ese costo.
¿Cuál es tu propuesta de valor?
Una propuesta de valor no es una lista de funciones. “Gamificación”, “IA”, “mapas”, “dashboard”, “notificaciones”, “repetición espaciada”, “sensores” o “blockchain” son características: describen lo que el producto tiene, no lo que la persona logra.
La pregunta que importa es otra:
¿Qué podrá hacer mejor el usuario gracias a tu solución?
Una forma sencilla de ponerlo por escrito:
Ayudamos a [usuario] a [lograr algo] mediante [enfoque], reduciendo o mejorando [problema o métrica].
Por ejemplo: Ayudamos a estudiantes sin formación biomédica a adquirir fundamentos de neurociencia mediante rutas breves y progresivas, reduciendo la dependencia de contenidos fragmentados y permitiendo verificar qué conceptos dominan.
Elige una. Sólo una.
Una prueba rápida: si tu frase podría aplicarse igual de bien a tres productos distintos, todavía no es una propuesta de valor.
Antes del MVP: diseña el experimento más pequeño
Un Producto Mínimo Viable no significa necesariamente construir una versión incompleta de la aplicación. Esa interpretación es la que lleva a equipos enteros a programar durante un semestre para descubrir al final lo que una tarde de conversaciones habría revelado.
Antes del MVP técnico casi siempre existe un experimento mucho más sencillo:
- Un prototipo en Figma.
- Una landing page.
- Una demostración en video.
- Una hoja de cálculo.
- Un formulario operado manualmente.
- Diez lecciones en una página web sencilla.
- Una simulación.
- Un servicio realizado a mano detrás de la interfaz.
- Un prototipo electrónico con funciones mínimas.
- Una prueba con cinco usuarios.
- Un pre-test y un post-test.
- Una demostración con datos históricos.
Fíjate en el cambio de pregunta. No se trata de encontrar la versión pequeña de tu producto, sino la prueba barata de tu hipótesis:
¿Qué versión pequeña puedo construir?
¿Qué experimento barato puedo realizar para comprobar la hipótesis más importante?
Por ejemplo: que las personas realmente tienen el problema; que usarían la solución; que la tecnología puede lograr la precisión necesaria; que existe acceso a los datos; que una institución permitiría desplegarla; que el método produce aprendizaje; que el dispositivo puede medir la señal.
Define la condición concreta antes de hacer la prueba, no después de ver los datos.
El objetivo del primer experimento no es impresionar a nadie: es permitirte cambiar de opinión rápido y barato.
Separa interés, uso y resultado
En muchos proyectos se mezclan tres preguntas que parecen la misma y no lo son. Confundirlas es la forma más común de creer que algo funciona cuando no funciona.
¿La gente dice o demuestra que quiere la solución?
- Personas entrevistadas.
- Registros.
- Lista de espera.
- Solicitudes de información.
- Aceptación de un piloto.
¿Las personas realmente utilizan la solución?
- Usuarios activos.
- Sesiones.
- Frecuencia de uso.
- Finalización.
- Retorno después de varios días.
- Tiempo de uso.
¿La solución mejora aquello que queríamos mejorar?
- Aprendizaje.
- Tiempo de procesamiento.
- Precisión.
- Reducción de errores.
- Ahorro.
- Satisfacción.
- Adherencia.
- Detección.
- Productividad.
Un producto puede generar mucho interés y no usarse nunca. Puede usarse mucho y no producir ningún resultado. Son fallas distintas, con causas distintas, y sólo se distinguen si desde el principio se miden por separado.
Factibilidad técnica
Ahora sí, la tecnología. Si llegaste hasta aquí con las respuestas anteriores razonablemente claras, esta sección es sorprendentemente rápida: ya sabes qué tiene que hacer el sistema y para quién.
Describe los componentes principales, no la lista completa de funciones.
Acceso a una base de datos, aprobación institucional, comité de ética, disponibilidad de pacientes, API de terceros, permisos, equipo especializado.
Las dependencias externas casi nunca detienen un proyecto al principio. Lo detienen a la mitad, cuando ya no hay tiempo para buscar alternativas. Conviene tocar esas puertas la primera semana, no la décima.
Ejecutabilidad: ¿puedes terminarlo?
Los proyectos universitarios fallan mucho más por exceso de alcance que por falta de capacidad técnica. Rara vez el obstáculo es que el equipo no supiera programar; casi siempre es que el proyecto era, desde el día uno, demasiado grande para el tiempo que existía.
Haz las cuentas con el tiempo real disponible —el que queda después de las otras materias, el trabajo, los exámenes y la vida— y no con el tiempo ideal.
Una buena delimitación se reconoce por un síntoma claro: incluye una lista escrita de las cosas que no se van a hacer.
Riesgo, ética y consecuencias del error
No todos los proyectos tienen el mismo nivel de riesgo, y tratarlos como si lo tuvieran es tan problemático como ignorarlo. La pregunta que ordena esta sección es simple:
¿Qué ocurre si el sistema se equivoca?
Hay que prestar atención especial cuando el proyecto toca salud, datos personales, menores de edad, decisiones sobre personas, seguridad, biometría, población vulnerable, información sensible o recomendaciones médicas, psicológicas o financieras.
La última pregunta suele ser la más subestimada. Un prototipo que sugiere un diagnóstico será leído como un diagnóstico, diga lo que diga la letra pequeña.
Decide antes de construir
Después de recorrer esta guía, tu proyecto debería caer con bastante claridad en uno de tres estados. Ninguno de los tres es un veredicto sobre ti; los tres son decisiones sobre cómo invertir las próximas semanas.
Existe suficiente evidencia para realizar un primer prototipo o un piloto acotado.
El problema parece relevante, pero el usuario, la solución, el alcance o el experimento necesitan cambiar.
La evidencia actual no justifica invertir más tiempo en esta versión de la idea.
Conviene decirlo con todas sus letras: detener una idea a tiempo no es fracasar. Descubrir en dos semanas que una hipótesis era incorrecta puede ahorrar meses de desarrollo, y esos meses valen exactamente lo mismo si se invierten en otra idea mejor.
Sea cual sea el estado en el que caíste, algo sigue. Éste es el último campo de la guía.
Tu ficha de proyecto
Nombre provisional del proyecto
Tipo de proyecto
Problema
Usuario principal
Evidencia
Soluciones actuales
Limitación de las soluciones actuales
Propuesta de valor
Solución propuesta
Hipótesis más importante
Primer experimento
Métrica de éxito
Factibilidad
Alcance de la primera versión
Fuera de alcance
Riesgos principales
Próximo paso
Un proyecto tecnológico no comienza cuando se escribe la primera línea de código. Comienza cuando se puede explicar con claridad:
quién tiene un problema, qué problema tiene, cómo sabemos que existe, cómo lo resuelve actualmente, qué queremos mejorar y cuál es el experimento más pequeño que nos permitirá decidir si vale la pena continuar.
La tecnología viene después.
Tus respuestas se guardan únicamente en este navegador, en tu propio equipo. No se envían a ningún servidor ni quedan registradas en este sitio. Si borras los datos de navegación o abres la guía en otro dispositivo, no aparecerán.
De la idea al proyecto
Cómo evaluar y delimitar una idea tecnológica antes de construirla.
Casi ningún proyecto tecnológico fracasa por escribir mal el código. Fracasa antes: por resolver un problema que nadie tenía, para un usuario que nunca existió, con un alcance que jamás cupo en el tiempo disponible.
Cómo funciona esta guía
Puede cambiar mil veces. Sirve para que la ficha tenga con qué encabezarse.
¿Para qué sirve esta guía?
Tener una idea es un buen punto de partida, pero no es todavía un proyecto. Entre una cosa y la otra hay un trabajo que casi nadie disfruta y que casi todos se saltan: convertir el entusiasmo en algo que pueda discutirse, criticarse y, si hace falta, abandonarse a tiempo.
Cuando alguien propone desarrollar una aplicación, una plataforma web, un dispositivo con sensores, una herramienta educativa o un sistema con inteligencia artificial, la conversación arranca casi siempre por la parte más visible —y, hay que decirlo, la más divertida—: la solución.
«Quiero hacer una app para…»
«Quiero construir un dispositivo que…»
«Quiero usar inteligencia artificial para…»
El problema es que una solución puede ser técnicamente impecable y, aun así, estar mal delimitada, atender una dificultad menor, dirigirse a usuarios demasiado generales o exigir mucho más tiempo del que el equipo realmente tiene. Nada de eso se nota mientras se dibuja la interfaz. Se nota tres meses después.
Esta guía está pensada para detenerse antes de construir. Su propósito no es dictaminar si una idea “es buena” o “es mala” —esa pregunta rara vez tiene respuesta útil—, sino ayudar a convertirla en un proyecto que pueda explicarse en voz alta sin que se caiga a pedazos.
Un proyecto puede perseguir fines muy distintos. Puede buscar:
- Aprender una tecnología.
- Resolver un problema educativo.
- Generar impacto social.
- Apoyar una necesidad dentro de una institución.
- Convertirse en una tesis.
- Producir una herramienta útil para una comunidad.
- Explorar una oportunidad de negocio.
- Desarrollar una prueba de concepto.
- Servir como base para un proyecto de investigación.
Todos esos objetivos son legítimos y ninguno es más serio que otro. Lo que ninguno perdona es la vaguedad.
Primero: ¿qué tipo de proyecto quieres hacer?
Antes de discutir funciones, lenguajes, sensores, modelos o plataformas, conviene nombrar el resultado que esperas obtener. Suena obvio, pero es el paso que más se omite: dos personas pueden trabajar en la misma idea durante semanas creyendo que persiguen cosas distintas.
Ubica tu proyecto en una de estas categorías. No para encasillarlo, sino para saber contra qué vara vas a medirlo.
| Tipo de proyecto | Pregunta principal | Un resultado exitoso podría ser |
|---|---|---|
| Aprendizaje técnico | ¿Qué quiero aprender a construir? | Prototipo funcional que demuestre una habilidad |
| Proyecto académico o tesis | ¿Qué pregunta quiero responder o evaluar? | Evidencia, análisis y documento académico |
| Impacto educativo o social | ¿Qué situación quiero mejorar? | Cambio observable en una población o proceso |
| Producto para una institución | ¿Qué problema operativo quiero resolver? | Herramienta adoptada por usuarios reales |
| Emprendimiento | ¿Existe una oportunidad por la que alguien pagaría? | Usuarios, adopción, ventas o piloto |
| Investigación tecnológica | ¿Qué capacidad nueva quiero demostrar? | Método, prototipo, publicación o prueba de concepto |
La tercera pregunta es la más incómoda y, con diferencia, la más útil. Casi todo el crecimiento descontrolado de un proyecto empieza por demostrar cosas que nadie pidió.
El problema antes que la solución
Una idea tecnológica suele nacer ya vestida de solución. Escuchamos la propuesta y podemos imaginar la pantalla, el dispositivo, el flujo de trabajo. Lo que rara vez escuchamos es la dificultad que le dio origen.
«Una aplicación tipo Duolingo para aprender neurociencias.»
«Un sistema con visión artificial para…»
«Un wearable que mida…»
Todas esas frases describen qué se va a construir. Ninguna responde la pregunta que va antes:
¿Qué problema existe aunque tu solución todavía no exista?
Un problema bien definido describe una dificultad real que alguien experimenta, y no debería depender de la tecnología propuesta. La diferencia se ve mejor con un ejemplo:
Hace falta una app de neurociencias.
Personas interesadas en aprender fundamentos de neurociencias encuentran información dispersa, con niveles de profundidad inconsistentes y sin una ruta clara para avanzar.
La segunda formulación abre la puerta a muchas soluciones posibles. Quizá una aplicación sea la adecuada. Quizá lo sea un curso, una guía, una comunidad o simplemente un índice bien hecho. Esa incertidumbre no es un defecto: es la señal de que el problema está bien planteado.
Completa, si es posible: “Actualmente, ______ intenta ______, pero tiene dificultades porque ______.”
Describe una situación concreta, no una generalidad.
Pérdida de tiempo, errores, costos, frustración, abandono, mala calidad, riesgo, falta de acceso.
Un buen enunciado de problema sobrevive a su propia solución: si mañana cambias de tecnología, el problema sigue ahí, intacto, esperando.
¿Quién tiene realmente ese problema?
“Estudiantes”, “público general”, “médicos”, “personas interesadas en tecnología” o “usuarios de internet” no son usuarios: son categorías censales. Dentro de cualquiera de ellas caben personas con necesidades completamente incompatibles entre sí.
Un proyecto que funciona casi siempre empieza con un grupo mucho más pequeño y mucho más concreto de lo que resulta cómodo admitir.
Personas interesadas en neurociencias.
Estudiantes universitarios sin formación biomédica que quieren adquirir fundamentos de neurociencia de manera autodidacta.
La diferencia práctica es enorme. A la primera población no puedes buscarla. A la segunda puedes encontrarla el martes por la tarde, entrevistarla y observar qué hace cuando se atora.
Describe un grupo específico: dónde está, qué hace, en qué contexto aparece el problema.
Si no puedes encontrar a tus usuarios, eso ya es un resultado del estudio, no un obstáculo administrativo. Anótalo.
Evidencia: ¿cómo sabes que el problema existe?
Revisar artículos, estadísticas, reportes de mercado y tendencias es un ejercicio valioso, pero no sustituye conocer directamente a las personas que tienen el problema. La literatura te dice que algo ocurre en el mundo; los usuarios te dicen si ocurre aquí, ahora y a alguien concreto.
Conviene distinguir tres niveles. No se diferencian por lo convincente que suene el argumento, sino por lo que le costó a alguien producirlo.
- “Yo creo que esto sería útil.”
- “Mis amigos dijeron que les gustaría.”
- “El mercado de esta industria es enorme.”
- “Una aplicación parecida tiene millones de usuarios.”
- “Hay muchas publicaciones sobre este tema.”
- Encuestas y formularios de interés.
- Listas de espera.
- Personas que aceptan probar un prototipo.
- Usuarios que dejan su correo.
- Personas que completan una prueba.
- Las personas ya intentan resolver el problema por su cuenta.
- Invierten tiempo o dinero en resolverlo.
- Utilizan soluciones alternativas, aunque sean incómodas.
- Describen dificultades recurrentes, no anecdóticas.
- Regresan voluntariamente a utilizar tu solución.
- La recomiendan a otros.
- Una institución acepta probarla.
- Alguien está dispuesto a pagar.
Antes de construir, habla con usuarios
Hay una pregunta que conviene no hacer, porque su respuesta casi nunca sirve:
«¿Usarías una aplicación como ésta?»
La gente es amable. Dirá que sí. Preguntar por el futuro invita a la cortesía; preguntar por el pasado obliga a los hechos. Por eso funcionan mejor estas otras:
- ¿Cuándo fue la última vez que tuviste este problema?
- ¿Qué hiciste para resolverlo?
- ¿Qué herramientas utilizaste?
- ¿Qué fue lo más difícil?
- ¿Cuánto tiempo te tomó?
- ¿Abandonaste en algún momento?
- ¿Has pagado por alguna solución?
- ¿Qué haces actualmente cuando vuelve a ocurrir?
Sepáralas: evidencia de literatura, estadísticas o internet, frente a evidencia obtenida directamente de usuarios.
¿Cómo lo resuelven hoy?
Tus competidores no son únicamente otros productos parecidos al tuyo. La competencia real es cualquier alternativa que el usuario ya utiliza hoy, por rudimentaria que sea.
Puede ser otra aplicación, una hoja de cálculo, WhatsApp, YouTube, una libreta, un proceso manual, un profesor, un libro, ChatGPT, un servicio profesional… o simplemente no hacer nada, que suele ser la alternativa más popular de todas.
Muy pocas ideas tecnológicas pierden contra una empresa rival. Casi todas pierden contra una frase:
«La solución actual no es perfecta, pero es suficientemente buena.»
Enumera al menos tres alternativas reales, incluida la de no hacer nada.
Si la única respuesta a la pregunta 15 es “porque la mía tendrá más funciones”, todavía hace falta trabajo. Cambiar de herramienta siempre cuesta algo; la mejora tiene que ser mayor que ese costo.
¿Cuál es tu propuesta de valor?
Una propuesta de valor no es una lista de funciones. “Gamificación”, “IA”, “mapas”, “dashboard”, “notificaciones”, “repetición espaciada”, “sensores” o “blockchain” son características: describen lo que el producto tiene, no lo que la persona logra.
La pregunta que importa es otra:
¿Qué podrá hacer mejor el usuario gracias a tu solución?
Una forma sencilla de ponerlo por escrito:
Ayudamos a [usuario] a [lograr algo] mediante [enfoque], reduciendo o mejorando [problema o métrica].
Por ejemplo: Ayudamos a estudiantes sin formación biomédica a adquirir fundamentos de neurociencia mediante rutas breves y progresivas, reduciendo la dependencia de contenidos fragmentados y permitiendo verificar qué conceptos dominan.
Elige una. Sólo una.
Una prueba rápida: si tu frase podría aplicarse igual de bien a tres productos distintos, todavía no es una propuesta de valor.
Antes del MVP: diseña el experimento más pequeño
Un Producto Mínimo Viable no significa necesariamente construir una versión incompleta de la aplicación. Esa interpretación es la que lleva a equipos enteros a programar durante un semestre para descubrir al final lo que una tarde de conversaciones habría revelado.
Antes del MVP técnico casi siempre existe un experimento mucho más sencillo:
- Un prototipo en Figma.
- Una landing page.
- Una demostración en video.
- Una hoja de cálculo.
- Un formulario operado manualmente.
- Diez lecciones en una página web sencilla.
- Una simulación.
- Un servicio realizado a mano detrás de la interfaz.
- Un prototipo electrónico con funciones mínimas.
- Una prueba con cinco usuarios.
- Un pre-test y un post-test.
- Una demostración con datos históricos.
Fíjate en el cambio de pregunta. No se trata de encontrar la versión pequeña de tu producto, sino la prueba barata de tu hipótesis:
¿Qué versión pequeña puedo construir?
¿Qué experimento barato puedo realizar para comprobar la hipótesis más importante?
Por ejemplo: que las personas realmente tienen el problema; que usarían la solución; que la tecnología puede lograr la precisión necesaria; que existe acceso a los datos; que una institución permitiría desplegarla; que el método produce aprendizaje; que el dispositivo puede medir la señal.
Define la condición concreta antes de hacer la prueba, no después de ver los datos.
El objetivo del primer experimento no es impresionar a nadie: es permitirte cambiar de opinión rápido y barato.
Separa interés, uso y resultado
En muchos proyectos se mezclan tres preguntas que parecen la misma y no lo son. Confundirlas es la forma más común de creer que algo funciona cuando no funciona.
¿La gente dice o demuestra que quiere la solución?
- Personas entrevistadas.
- Registros.
- Lista de espera.
- Solicitudes de información.
- Aceptación de un piloto.
¿Las personas realmente utilizan la solución?
- Usuarios activos.
- Sesiones.
- Frecuencia de uso.
- Finalización.
- Retorno después de varios días.
- Tiempo de uso.
¿La solución mejora aquello que queríamos mejorar?
- Aprendizaje.
- Tiempo de procesamiento.
- Precisión.
- Reducción de errores.
- Ahorro.
- Satisfacción.
- Adherencia.
- Detección.
- Productividad.
Un producto puede generar mucho interés y no usarse nunca. Puede usarse mucho y no producir ningún resultado. Son fallas distintas, con causas distintas, y sólo se distinguen si desde el principio se miden por separado.
Factibilidad técnica
Ahora sí, la tecnología. Si llegaste hasta aquí con las respuestas anteriores razonablemente claras, esta sección es sorprendentemente rápida: ya sabes qué tiene que hacer el sistema y para quién.
Describe los componentes principales, no la lista completa de funciones.
Acceso a una base de datos, aprobación institucional, comité de ética, disponibilidad de pacientes, API de terceros, permisos, equipo especializado.
Las dependencias externas casi nunca detienen un proyecto al principio. Lo detienen a la mitad, cuando ya no hay tiempo para buscar alternativas. Conviene tocar esas puertas la primera semana, no la décima.
Ejecutabilidad: ¿puedes terminarlo?
Los proyectos universitarios fallan mucho más por exceso de alcance que por falta de capacidad técnica. Rara vez el obstáculo es que el equipo no supiera programar; casi siempre es que el proyecto era, desde el día uno, demasiado grande para el tiempo que existía.
Haz las cuentas con el tiempo real disponible —el que queda después de las otras materias, el trabajo, los exámenes y la vida— y no con el tiempo ideal.
Una buena delimitación se reconoce por un síntoma claro: incluye una lista escrita de las cosas que no se van a hacer.
Riesgo, ética y consecuencias del error
No todos los proyectos tienen el mismo nivel de riesgo, y tratarlos como si lo tuvieran es tan problemático como ignorarlo. La pregunta que ordena esta sección es simple:
¿Qué ocurre si el sistema se equivoca?
Hay que prestar atención especial cuando el proyecto toca salud, datos personales, menores de edad, decisiones sobre personas, seguridad, biometría, población vulnerable, información sensible o recomendaciones médicas, psicológicas o financieras.
La última pregunta suele ser la más subestimada. Un prototipo que sugiere un diagnóstico será leído como un diagnóstico, diga lo que diga la letra pequeña.
Decide antes de construir
Después de recorrer esta guía, tu proyecto debería caer con bastante claridad en uno de tres estados. Ninguno de los tres es un veredicto sobre ti; los tres son decisiones sobre cómo invertir las próximas semanas.
Existe suficiente evidencia para realizar un primer prototipo o un piloto acotado.
El problema parece relevante, pero el usuario, la solución, el alcance o el experimento necesitan cambiar.
La evidencia actual no justifica invertir más tiempo en esta versión de la idea.
Conviene decirlo con todas sus letras: detener una idea a tiempo no es fracasar. Descubrir en dos semanas que una hipótesis era incorrecta puede ahorrar meses de desarrollo, y esos meses valen exactamente lo mismo si se invierten en otra idea mejor.
Sea cual sea el estado en el que caíste, algo sigue. Éste es el último campo de la guía.
Tu ficha de proyecto
Nombre provisional del proyecto
Tipo de proyecto
Problema
Usuario principal
Evidencia
Soluciones actuales
Limitación de las soluciones actuales
Propuesta de valor
Solución propuesta
Hipótesis más importante
Primer experimento
Métrica de éxito
Factibilidad
Alcance de la primera versión
Fuera de alcance
Riesgos principales
Próximo paso
Un proyecto tecnológico no comienza cuando se escribe la primera línea de código. Comienza cuando se puede explicar con claridad:
quién tiene un problema, qué problema tiene, cómo sabemos que existe, cómo lo resuelve actualmente, qué queremos mejorar y cuál es el experimento más pequeño que nos permitirá decidir si vale la pena continuar.
La tecnología viene después.
Tus respuestas se guardan únicamente en este navegador, en tu propio equipo. No se envían a ningún servidor ni quedan registradas en este sitio. Si borras los datos de navegación o abres la guía en otro dispositivo, no aparecerán.