El MVP es una pregunta, no un producto

Un MVP no es la primera versión de un producto. Es la pregunta más cara que puedes hacerle a la realidad, recortada hasta que el software pueda responderla. Si no puedes nombrarla en una frase, todavía no tienes un MVP. Tienes un backlog disfrazado de lanzamiento.

¿Qué pregunta responde un MVP?

La jerga trata el MVP como un objeto. Una versión. Un conjunto de pantallas. Un “mínimo” definido por lo que cabe en el sprint.

Eso invierte el orden. El código es el último paso. La claridad es el primero. La mayoría de los productos fallidos fueron construidos correctamente — para el problema equivocado.

Un MVP responde una sola pregunta. No tres. No “y también”. Si el lanzamiento tiene que demostrar el motor, el directorio, la pasarela, la app nativa y el panel de analytics, no estás preguntando nada. Estás construyendo el producto que imaginaste, con menos CSS.

La pregunta tiene que ser cara. Cara significa: si la respuesta es no, cambias el producto o lo paras. Si la respuesta no puede ser no, no es una pregunta. Es una justificación.

También tiene que ser observable. “¿La gente lo va a amar?” no se observa. “¿Un profesional independiente en Chile publica sitio y agenda en cinco minutos y deja de usar WhatsApp como calendario?” sí se observa. Alguien lo hace o no lo hace.

El alcance nace de esa pregunta, no al revés. Recortas hasta que se vuelva obvio qué entra y qué no. Lo que no entra no es deuda. Es una decisión.

Ese corte es el trabajo que llamo ingeniería de producto: nombrar el problema, ingeniar el sistema que lo sostiene, ponerlo en manos de alguien. No es un deck. No es un prototipo que muere en una carpeta.

¿Qué pregunta respondía cada producto al lanzar?

Lancé tres productos en 2026. Cada uno tenía una pregunta. Ninguno era “una plataforma”.

Agendamelo

Agendamelo no preguntaba si Chile necesita un SaaS de reservas. Eso no se responde con software. Se responde con una opinión.

La pregunta era más estrecha: ¿un profesional independiente deja WhatsApp como calendario si el sitio público existe después de nombre, servicios y horarios, y el cliente reserva sin que nadie conteste?

WhatsApp es un transporte, no un objeto público. No hay horario publicado. No hay precios que un buscador lea. No hay una URL que el cliente reenvíe sin copiar un chat.

Si la pregunta es esa, el onboarding de cinco minutos no es copy. Es el experimento. Galería, reseñas, equipo y FAQs pueden esperar. La comisión por reserva no entra: el cliente reserva en línea y paga en el local. La plataforma cobra el software, no el oficio.

Las sesiones recurrentes sí entran el día uno. Parecen “una feature más”. No lo son. El producto ya promete tratamientos semanales. Si el motor no modela una serie, la pregunta queda a medias. Reducir no es borrar todo. Es borrar lo que no responde, y dejar lo que sí.

El directorio de 19 rubros por 69 comunas —unas 1.400 URLs— no era la pregunta del primer Ship. Era una consecuencia de tener tenants públicos. Primero existe el objeto. Después se hace encontrable.

PGAS

PGAS no preguntaba si el SEO sigue funcionando. Preguntaba si un servicio de visibilidad se puede comprar como catálogo.

La gente le pregunta a ChatGPT, lee Perplexity y se queda en las AI Overviews. La oferta de agencia no se movió: keywords, un PDF mensual, el precio detrás de “consultar”. Alcance líquido. Método de reunión. El sitio de la agencia no demuestra las páginas que dice saber construir.

Eso es un fallo de producto, no de copy. El alcance líquido no puede cargar un número público. Un método que solo existe en una reunión no se versiona.

La pregunta al lanzar: ¿alguien compra un primer corte de SEO, AEO y GEO si el precio, la ventana de 48 horas y el entregable están publicados, sin una llamada de ventas?

Por eso Diagnóstico Express existe a $79.000 CLP, en 48 horas, con un PDF, una llamada de 30 minutos y las cinco oportunidades principales. No es un cupón. Es la pregunta hecha SKU.

Yo no quería otra agencia. Quería un servicio con catálogo, un pipeline que puedo correr, y un sitio que demuestra ese pipeline. El método VERA vive en el producto. Este dominio cuenta quién lo construyó.

WspWrapped

WspWrapped no preguntaba si la IA puede entender tus chats. Preguntaba algo más incómodo.

Todo chat esconde preguntas que la memoria no responde: quién escribe más, quién empieza, quién contesta a las 3am, quién se silencia, quién borra. Los datos están en el export. El archivo es ilegible como métrica.

La pregunta al lanzar: si nunca guardo un mensaje, ¿la gente igual sube un .txt o un .zip, obtiene más de 30 métricas y se lleva una tarjeta para Stories?

La privacidad no es una política. Es el modelo de datos. El parser corre en memoria. Solo persisten agregados. Si la pregunta incluye “y además un modelo lee el chat”, dejas de tener esa arquitectura. Tienes otro producto: un archivo de conversaciones ajenas.

El uso es episódico. Un chat, una vez, para publicar una historia. Una suscripción pelea contra esa forma. Los créditos no: un crédito, un reporte completo. Tres créditos a $2,99. Diez a $4,99. No vencen. Capa gratis con métricas básicas.

La tarjeta 9:16 también entra el día uno. Sin un frame que se pueda publicar, el reporte muere en una carpeta de capturas. Eso no es crecimiento. Es la pregunta: ¿el resultado sale de la pantalla?

¿Cómo cambia el alcance “reducir hasta que se vuelva obvio”?

Reducir no es recortar features al azar. Es separar síntoma, pedido, restricción, suposición y ruido hasta que quede el problema.

El síntoma de Agendamelo era “contesto WhatsApp todo el día”. El pedido era “una app de reservas”. La restricción era cinco minutos percibidos, pesos chilenos y la comuna como unidad. La suposición era que el profesional publicaría si empezar era barato. El ruido era pasarela, app nativa, marketplace, comisión.

Cuando recortas hasta que se vuelve obvio, el alcance deja de ser una lista. Se vuelve un esquema mínimo. Nombre, servicios con precios, horarios semanales. Con eso hay H1, lista de precios y calendario. Si falta uno, no se publica. El resto es aditivo.

En PGAS, reducir congeló entregables. Quince URLs on-page. Cuatro contenidos al mes. Diagnóstico en 48 horas. Un precio público es una promesa. No puedes publicarlo si el alcance se negocia en cada llamada. El trabajo a medida vive al pie del catálogo como excepción, no como default.

En WspWrapped, lo obvio era el archivo que el usuario ya tiene. No “añadir IA a los chats”. Exportar, soltar el archivo, ver números, compartir una tarjeta. Si el reporte no puede salir del dashboard como un frame, el producto no termina.

Reducir también cambia el stack. PGAS no tiene CMS ni base de datos detrás del sitio: el catálogo cabe en el repo. WspWrapped no tiene una tabla de mensajes. Agendamelo sí tiene tenancy en Postgres, porque la pregunta exige agendas aisladas. Las herramientas siguen a la pregunta. No al revés.

El mínimo que queda no se ve pequeño. Se ve inevitable. Si todavía tienes que explicar por qué existe cada pieza, no reduciste lo suficiente.

¿Qué decidí no construir?

Decidir qué no construir es la mitad del trabajo. La otra mitad es poder decir por qué. En los tres productos el “no” más visible protege la pregunta.

Agendamelo no cobra comisión por reserva. Una comisión habría obligado a una pasarela y a la seña remota. El producto habría respondido “¿cómo cobro yo?” en vez de “¿el cliente reserva solo?”. Reserva en línea, paga en el local. La suscripción cobra el software. El local cobra el oficio. Comisión: 0%.

Tampoco vende dominios el día uno, ni WhatsApp automático. El slug es el sitio. El correo lleva la fiabilidad; WhatsApp se manda desde el panel, un clic. Cinco minutos es la pregunta. El DNS y el SLA de Meta no.

PGAS no esconde el precio detrás de “consultar”. El H1 de /precios nombra SEO, AEO y GEO en pesos chilenos. Los planes mensuales no piden permanencia mínima. El trabajo custom es overflow. Si el default es una cotización, nadie puede comprar sin una reunión. La pregunta del catálogo nunca se responde.

Tampoco hay CMS en ese sitio, ni un blog de SEO en este dominio. pgas.online habla del método. jorgeco.tech habla de quién lo construyó. Duplicar posts canibaliza la agencia y ensucia la persona.

WspWrapped no es una suscripción. Un producto de curiosidad de un viernes noche entrena a la gente a cancelar, no a analizar. Créditos que no vencen bajan el arrepentimiento. El trade-off es no tener un ingreso mensual liso. Lo acepté.

Tampoco guardo el texto de los mensajes. Si persisto el chat, me vuelvo archivo de datos íntimos. Un producto que me niego a operar. Si el mes que viene invento una métrica nueva, el usuario vuelve a subir el archivo. Es más barato que un lago de mensajes. Lo que el landing llama “IA” tiene que correr sobre esos números, no sobre el transcript. Mandar el chat a un modelo anula la pregunta de privacidad.

Cada “no” protege una pregunta. Un MVP que dice que sí a todo no está preguntando. Está posponiendo el corte.

¿Cómo Think / Build / Ship convierte el MVP en un loop?

Think / Build / Ship no es un eslogan de tres columnas. Es el orden en que una pregunta se vuelve sistema y el sistema vuelve a ser pregunta. Think nombra el problema y decide qué no construir. Build ingeniera el sistema. Ship lo pone en manos de alguien, aprende, y vuelve a Think. No se traduce. Es el método.

El MVP no es el final de Ship. Es el primer paso del loop. La respuesta de la realidad alimenta el siguiente Think.

Agendamelo lo muestra. El trial de 7 días sin tarjeta responde “¿alguien publica?”. Después existe Perfil Gratis: la URL sigue; el motor de reservas se apaga. Indexar un tenant que ya no reserva es una decisión que solo aparece cuando el primer Ship toca realidad. El motivo para pagar es la agenda, no la existencia del sitio. Eso no estaba en el primer corte. Salió del loop.

PGAS lo muestra de otra forma. El diagnóstico se acredita entero si contratas implementación en 30 días. Baja el costo de entrar sin diluir el SKU. El tracking de menciones en modelos sigue, en parte, siendo un loop manual. El método lo dice. No vendí un dashboard que no existe. Esa deuda es el siguiente Think.

WspWrapped lo muestra en el parse. Un renglón que funciona en inglés en Android es otro renglón en iPhone, en español, con una marca Unicode antes del corchete. El fix de un parse malo es un parse mejor, no un modelo. Cada formato que sobrevive es un Ship que alimenta el siguiente corte.

Sin loop, el MVP se convierte en la versión 1.0 permanente. Con loop, el mínimo deja de ser un objeto. Vuelve a ser una pregunta: más cara, más estrecha, más honesta.

Eso es lo que vendo cuando alguien llega con un brief y una fecha. No un especialista por capa. El camino completo. El mismo que recorrieron los tres productos, y el que describo en ingeniería de producto.

Cómo lo aplico

1. 01/
   Nombro la pregunta en una frase. Si no cabe, no es una pregunta. Sigo recortando hasta que un extraño la pueda repetir.
2. 02/
   Escribo qué contaría como un no. Si el no no existe, estoy justificando un backlog. La pregunta cara es la que puedes perder.
3. 03/
   Listo lo que no voy a construir, con el porqué. Comisión, suscripción, cotización oculta: cada no protege la pregunta. Sin porqué, el no no aguanta la primera reunión.
4. 04/
   Bajo el umbral de publicación al esquema mínimo. Lo aditivo espera. El experimento no. Nombre, servicios y horarios publican Agendamelo. Un SKU de 48 horas publica PGAS. Un export y un reporte publican WspWrapped.
5. 05/
   Elijo el cobro que no pelea con el uso. Suscripción de software, no comisión. Créditos, no mensualidad. Catálogo público, no reunión obligatoria. El precio es parte del diseño.
6. 06/
   Lo pongo en una URL. Miro qué hace la gente. El siguiente Think parte de eso, no del deck original. Si la realidad no puede responder, todavía no lancé. Lancé un prototipo con dominio.

El mismo camino cabe en un producto de consumo, en un SaaS multi-tenant y en un servicio empaquetado como catálogo. La categoría cambia. El corte no.

El MVP es una pregunta, no un producto. El producto es lo que construyes para poder hacerla. Si la respuesta llega, recortas otra vez. Si la respuesta es no, paras. Lo demás es backlog.