Un producto mínimo viable (MVP) es una versión de un producto con las características justas para ser utilizable por los primeros clientes, quienes luego pueden proporcionar retroalimentación para el desarrollo futuro del producto.
\n\nHoy quiero enfocarme en cómo se ve esto para el lanzamiento de aplicaciones de IA. Para hacerlo, solo necesitamos entender 4 cosas.
\nEl principio de Pareto, también conocido como la regla 80/20, todavía aplica pero de una manera diferente a lo que podrías pensar.
\n\nUna analogía que a menudo uso para ayudar a entender este concepto es la siguiente: Necesitas algo que te ayude a ir del punto A al punto B. Quizás la visión es tener un automóvil. Sin embargo, el MVP no es un chasis sin ruedas o motor. En cambio, podría verse como una patineta. Lanzarás el producto y te darás cuenta de que necesita frenos o dirección. Entonces lanzas un scooter. Después, descubres que el scooter necesita más apalancamiento, así que agregas ruedas más grandes y terminas con una bicicleta. Limitado por la fuerza que puedes aplicar como ser humano, comienzas a pensar en motores y puedes ramificarte en ciclomotores, e-bikes y motocicletas. Entonces un día, lanzas el automóvil.
\n\nCuando hablamos de que algo está 80% hecho o 80% listo, generalmente es en un sentido de aprendizaje automático. En este contexto, cada componente es determinístico, lo que significa que 80% se traduce en 8 de 10 características completas. Una vez que las 2 características restantes estén listas, podemos lanzar el producto. Sin embargo, si queremos seguir la regla 80/20, podríamos ser capaces de lanzar el producto con el 80% de las características y luego agregar el 20% restante más tarde, como un automóvil sin radio o aire acondicionado. Sin embargo, el significado del 80% puede variar significativamente, y esta definición puede no aplicar a una aplicación impulsada por IA.
\n\n![\"Cuarteto](\"/assets/images/anscombes_quartet.png\")
\nLa imagen anterior es un ejemplo del cuarteto de Anscombe. Es un conjunto de cuatro conjuntos de datos que tienen estadísticas descriptivas simples casi idénticas pero distribuciones y apariencias muy diferentes. Esta es una explicación clásica de por qué las estadísticas resumidas pueden ser engañosas.
\n\nConsidera el siguiente ejemplo:
\n\n| Query_id | \nscore | \n
|---|---|
| 1 | \n0.9 | \n
| 2 | \n0.8 | \n
| 3 | \n0.9 | \n
| 4 | \n0.9 | \n
| 5 | \n0.0 | \n
| 6 | \n0.0 | \n
El puntaje promedio es 0.58. Sin embargo, si analizamos las consultas dentro de segmentos, ¡podríamos descubrir que estamos sirviendo a la mayoría de las consultas excepcionalmente bien!
\n\n\n\n\nAdmitir en qué eres malo
\nSer honesto con aquello en lo que eres malo es una excelente manera de construir confianza con tus usuarios. Si puedes identificar con precisión cuándo algo tendrá un mal desempeño y rechazarlo con confianza, entonces podrías estar listo para lanzar un gran producto mientras educas a tus usuarios sobre las limitaciones de tu aplicación.
\n
Es muy importante entender las limitaciones de tu sistema y poder comprender con confianza las características de tu sistema más allá de las estadísticas resumidas. Esto es porque no todos los sistemas son iguales. El comportamiento de un sistema probabilístico podría ser muy diferente del ejemplo anterior. Considera el siguiente conjunto de datos:
\n\n| Query_id | \nScore | \n
|---|---|
| 1 | \n.59 | \n
| 2 | \n.58 | \n
| 3 | \n.59 | \n
| 4 | \n.57 | \n
Un sistema como este también tiene el mismo puntaje promedio de 0.58, pero no es tan fácil rechazar ningún subconjunto de solicitudes...
\n\nConsidera una aplicación RAG donde una gran proporción de las consultas son sobre consultas de línea de tiempo. Si nuestros motores de búsqueda no soportan esta restricción de tiempo, probablemente no podremos desempeñarnos bien.
\n\n| Query_id | \nScore | \nQuery Type | \n
|---|---|---|
| 1 | \n0.9 | \ntext search | \n
| 2 | \n0.8 | \ntext search | \n
| 3 | \n0.9 | \nnews search | \n
| 4 | \n0.9 | \nnews search | \n
| 5 | \n0.0 | \ntimeline | \n
| 6 | \n0.0 | \ntimeline | \n
Si estamos en apuros para lanzar, simplemente podríamos construir un modelo de clasificación que detecte si estas preguntas son preguntas de línea de tiempo o no y lanzar una advertencia. En lugar de intentar constantemente empujar al algoritmo a hacerlo mejor, podemos educar al usuario cambiando la forma en que podríamos diseñar el producto.
\n\n\n\n\nDetectar segmentos
\nDetectar estos segmentos podría lograrse de varias maneras. Podríamos construir un clasificador o emplear un modelo de lenguaje para categorizarlos. Además, podemos utilizar algoritmos de clustering con los embeddings para identificar grupos comunes y potencialmente analizar los puntajes medios dentro de cada grupo. El único objetivo es identificar segmentos que puedan mejorar nuestra comprensión de las actividades dentro de subgrupos específicos.
\n
Una de las peores cosas que puedes hacer es pasar meses construyendo una característica que solo aumenta tu productividad un poco mientras ignoras algún segmento más importante de tu base de usuarios.
\n\nAl rediseñar nuestra aplicación y reconocer sus limitaciones, potencialmente podemos mejorar el rendimiento bajo ciertas condiciones al identificar los tipos de tareas que podemos rechazar. Si somos capaces de poner estos datos de segmentos en algún tipo de Observabilidad del Sistema, podemos monitorear de manera segura qué proporción de preguntas están siendo rechazadas y priorizar nuestro trabajo para maximizar la cobertura.
\n\nUna de las cosas peligrosas que he notado trabajando con startups es que a menudo pensamos que la IA funciona en absoluto... Como resultado, queremos ser capaces de servir una gran aplicación general sin mucho pensamiento sobre qué exactamente queremos lograr.
\n\nEn mi opinión, la mayoría de estas empresas deberían intentar enfocarse en una o dos áreas significativas e identificar un buen nicho al cual apuntar. Si tu aplicación es buena en una o dos tareas, no hay forma de que no puedas encontrar cien o doscientos usuarios para probar tu aplicación y obtener retroalimentación rápidamente. Mientras que, si tu aplicación no es buena en nada, va a ser difícil ser memorable y proporcionar algo que tenga uso repetido. Podrías obtener algo de viralidad, pero muy rápidamente, vas a perder la confianza de tus usuarios y te encontrarás en una posición donde estás tratando de reducir la deserción.
\n\nCuando estamos cargados al frente, la capacidad de usar GPT-4 para hacer predicciones, y el tiempo de retroalimentación es muy importante. Si podemos obtener retroalimentación rápidamente, podemos iterar rápidamente. Si podemos iterar rápidamente, podemos construir un mejor producto.
\n\nEl MVP para una aplicación de IA no es tan simple como lanzar un producto con el 80% de las características. En cambio, requiere una comprensión profunda de los segmentos de tus usuarios que puedes servir bien y la capacidad de educar a tus usuarios sobre los segmentos que no sirves bien. Al entender las limitaciones de tu sistema y especializarte en un nicho, puedes construir un producto que sea memorable y proporcione algo que tenga uso repetido. Esto te permitirá obtener retroalimentación rápidamente e iterar rápidamente, lo que en última instancia conducirá a un mejor producto, al identificar tus hazañas de fuerza.
", "source_hash": "sha256:628188f6afb27695d03e01274d59eb0b52134258149bbac07bab13c678413b93", "model": "claude-sonnet-4-5-20250929", "generated_at": "2026-01-15T20:06:50.899320+00:00" }