Market Opportunity Intelligence Engine
Un motor de inteligencia de mercado para descubrir oportunidades de producto a partir de problemas reales, evidencia trazable y análisis de necesidades.
El problema
En comentarios, reseñas, foros y comunidades, las personas describen problemas, tareas que resuelven manualmente y limitaciones de los productos que utilizan.
Sin embargo, encontrar una queja no significa haber encontrado una oportunidad de negocio. El problema puede ser ocasional, estar resuelto por una herramienta gratuita o aparecer repetidamente porque todos responden a una misma publicación.
El reto es distinguir el ruido de los problemas que justifican una validación de producto.
La propuesta
Market Opportunity Intelligence Engine —MOI— es un proyecto para transformar evidencia no estructurada en oportunidades de producto concretas, trazables y priorizadas.
El motor buscará identificar:
- Qué problema expresa el usuario.
- Qué intenta conseguir y en qué situación.
- Cómo lo resuelve actualmente.
- Qué evidencia existe sobre frecuencia, urgencia o costo.
- Qué señales contradicen la oportunidad.
- Cuál sería el producto más pequeño capaz de entregar valor.
Si el análisis de miles de comentarios solamente permite defender tres oportunidades, ese será un resultado válido. También lo será concluir que no existe evidencia suficiente.
De la evidencia al producto
Cada oportunidad deberá conservar una cadena de trazabilidad:
Fuente → Evidencia original → Señales → Grupo de problemas → Job-to-be-Done → Oportunidad → Hipótesis de producto.
El Job-to-be-Done describe la necesidad mediante una estructura sencilla:
Cuando ocurre determinada situación, quiero realizar una tarea para obtener un resultado.
El producto se propondrá después de comprender y contrastar esa necesidad.
Cómo funcionará
La arquitectura combinará procesamiento determinístico, modelos semánticos y modelos de lenguaje, con responsabilidades separadas.
| Componente | Responsabilidad |
|---|---|
| Ingestión y normalización | Importar archivos y conservar su procedencia. |
| Limpieza y deduplicación | Identificar ruido y contenido repetido sin perder las referencias originales. |
| Extracción estructurada | Detectar problemas, tareas, soluciones actuales y señales económicas. |
| Embeddings y búsqueda híbrida | Recuperar evidencia relacionada aunque utilice palabras distintas. |
| Clustering semántico | Agrupar problemas similares y mantener los casos que no forman grupos coherentes. |
| Consolidación de JTBD | Relacionar problema, contexto, tarea y resultado esperado. |
| Evaluación escéptica | Buscar alternativas existentes, contradicciones y razones para descartar la oportunidad. |
| Scoring determinístico | Aplicar criterios explícitos y mostrar cómo se obtiene cada puntuación. |
La base tecnológica prevista es Python, PostgreSQL y pgvector, con interfaces independientes para proveedores de modelos.
La solución más pequeña que entregue valor
El motor favorecerá productos de alcance reducido: una mini-app, un producto digital, una extensión o una utilidad sencilla.
Una necesidad solamente justificará un producto más amplio cuando su complejidad lo requiera.
Entre los patrones que buscará están tareas como copiar datos entre aplicaciones, consolidar pedidos, comparar registros, verificar mensajes, convertir archivos o revisar información periódicamente.
Estos patrones serán pistas de investigación; su presencia no bastará para declarar una oportunidad.
Qué entregará
Cada ficha de oportunidad incluirá:
- Problema observado y Job-to-be-Done.
- Segmento, cuando exista evidencia para identificarlo.
- Situación que activa la necesidad.
- Solución o proceso utilizado actualmente.
- Evidencia favorable y contraria.
- Producto mínimo propuesto.
- Hipótesis de precio y distribución.
- Riesgos y preguntas pendientes.
- Experimento de validación.
- Criterios para descartar la idea.
La puntuación de oportunidad, la confianza en la evidencia y la adecuación para una mini-app serán dimensiones separadas.
Lo que el sistema no deberá inventar
El motor no presentará como hechos el tamaño de mercado, la disposición a pagar, la frecuencia de uso o las características del segmento si la evidencia no los respalda.
Cuando falte información, la respuesta será desconocido.
Las promesas de producto, los precios y los canales de adquisición se identificarán como hipótesis que todavía necesitan validación.
Primera versión
La construcción comenzará con una herramienta de línea de comandos y archivos importados manualmente.
- Crear los modelos de dominio, almacenamiento y trazabilidad.
- Importar, normalizar y deduplicar evidencia.
- Preparar un conjunto de evaluación etiquetado manualmente.
- Extraer señales mediante esquemas estrictos.
- Incorporar búsqueda semántica y agrupación de problemas.
- Construir JTBD e hipótesis de oportunidad.
- Aplicar evaluación escéptica y generar reportes.
Las primeras entregas se concentrarán en demostrar la calidad del análisis.
Cómo comprobaré que funciona
La primera prueba prevista utilizará entre 5,000 y 20,000 comentarios reales de un nicho.
Compararé el motor con un análisis directo realizado por un modelo de lenguaje. Un evaluador humano revisará los resultados sin conocer qué método produjo cada uno.
La comparación medirá trazabilidad, afirmaciones sin respaldo, calidad de los problemas identificados y utilidad de las oportunidades para diseñar experimentos de validación.
Cada componente deberá demostrar que aporta valor antes de justificar más complejidad.
Estado
Proyecto en fase de diseño y definición de arquitectura.
Las capacidades descritas son objetivos de desarrollo. Todavía no se presentan resultados de benchmarks ni oportunidades de mercado validadas.
El primer hito será construir la base del sistema y un flujo reproducible de ingestión de evidencia.
La meta
Encontrar pocas oportunidades defendibles y comprobar si merecen convertirse en productos.
Evidencia antes que interpretación. Necesidades antes que productos. Validación antes que afirmaciones de mercado.