En noviembre de 2024, un proyecto llamado Freysa puso un agente LLM a custodiar un wallet de Ethereum. La instrucción era clara: no transfieras los fondos bajo ninguna circunstancia. Los participantes pagaban cantidades crecientes por cada intento de convencerlo. Después de 481 intentos y $47.000 acumulados en el bote, alguien convenció al modelo de que la función de rechazar era en realidad la función de transferir.
Unas semanas después, Jane Street publicó un puzzle donde una red neuronal de 2.500 capas resultó ser una implementación de MD5. El ganador lo resolvió combinando visualización de matrices, reducción a SAT, reconocimiento de patrones criptográficos, y una consulta a ChatGPT.
Ambos proyectos generaron más atención que la mayoría de startups con millones en funding. La pregunta es obvia: ¿cómo se evalúa una idea así antes de construirla? ¿Cómo saber si tiene potencial viral real o es solo un ejercicio técnico interesante que nadie compartirá?
El problema: evaluación de MVPs en la era de la viralidad
La mayoría de frameworks para evaluar ideas de producto asumen un mercado racional. Business Model Canvas, Lean Canvas, Jobs To Be Done — todos son herramientas valiosas para productos con demanda predecible. Pero fallan con proyectos donde la distribución viral es el producto.
Freysa no tenía «customers» en el sentido tradicional. No resolvía un «job to be done». Era un mecanismo donde el propio acto de participar generaba atención que atraía más participantes. La economía era circular: más intentos generaban más bote, más bote generaba más cobertura mediática, más cobertura atraía más intentos.
Para evaluar este tipo de proyectos necesitas perspectivas que generen tensión, no consenso. Un analista de negocio te dirá que no hay modelo de ingresos sostenible. Un especialista en viralidad te dirá que la sostenibilidad es irrelevante si el k-factor es mayor que 1. Ambos tienen razón. Y la verdad está en algún punto entre ambos que solo emerge del conflicto.
La idea: un consejo adversarial de expertos simulados
He diseñado una herramienta que simula un consejo de cinco expertos, cada uno con un framework de decisión concreto y una jurisdicción definida. No son personalidades genéricas con nombre famoso. Cada uno aplica reglas de decisión específicas que filtran el ruido que un análisis genérico no filtraría.
El proceso tiene tres fases:
- Análisis independiente: cada experto evalúa la idea desde su lente, sin ver lo que dicen los demás. Esto previene el anclaje — si el experto de negocio habla primero y dice «esto es genial», el de legal suaviza sus objeciones.
- Debate adversarial: los expertos leen los análisis de los demás y se critican mutuamente. Con fundamento, no con diplomacia. Máximo 10 rondas hasta consenso o deadlock.
- Síntesis: un plan ejecutable con issues por área, timeline, y — lo más importante — kill criteria: las métricas concretas que, si no se cumplen, significan que hay que parar.
Los cinco elegidos (y por qué cada uno está ahí)
Paul Graham — Negocio y Estrategia
Su framework para evaluar startups en fase cero es el más riguroso que existe para proyectos sin datos. Su pregunta «¿estás haciendo algo que la gente quiere?» es brutal pero necesaria. No acepta «la gente» como mercado — exige nombre y apellido del primer usuario.
Lo que aporta al consejo: la disciplina de distinguir entre «idea interesante» y «negocio viable». Su concepto de «do things that don’t scale» es especialmente valioso para MVPs virales, donde la tentación es construir infraestructura para millones de usuarios que aún no existen.
Descartados para esta silla: Peter Thiel (demasiado contrarian — a veces rechaza buenos proyectos por no ser suficientemente «zero to one»), Alex Hormozi (su expertise está en negocios de servicios, no en productos tech virales).
Lawrence Lessig — Legal y Regulación
No es un abogado que dice «no se puede». Es un jurista que piensa en regulación como arquitectura. Su framework de «cuatro modalidades de regulación» (ley, normas sociales, mercado, y código/arquitectura) permite analizar cómo diseñar un sistema para que la regulación no sea un problema, en vez de intentar evadir la regulación.
Lo que aporta al consejo: la pregunta «¿qué pasa cuando el regulador se da cuenta de que existes?» Muchos proyectos crypto/AI son legalmente irrelevantes en pequeño y regulados en grande. Lessig identifica el umbral donde la regulación se activa.
Descartados para esta silla: un abogado corporativo genérico (diría «no» a todo y mataría el proyecto antes de nacer). La clave es que Lessig entiende que la regulación no es el único instrumento — la arquitectura del sistema puede hacer innecesaria la intervención legal.
Seth Godin — Marketing y Posicionamiento
Su pregunta central — «¿quién es tu smallest viable audience y por qué les importa?» — es la más importante para un lanzamiento viral. No piensa en «cómo llegar a millones» sino en «cómo llegar a los primeros 100 que realmente les importa».
Lo que aporta al consejo: el test de remarkability. ¿Tiene esto algo que hará que alguien lo comparta sin que se lo pidas? «Es útil» no se comparte. «Es notable» sí. Su concepto de «Tribes» encaja perfectamente con comunidades tech/crypto que ya tienen identidad de grupo.
Descartados para esta silla: Philip Kotler (demasiado corporativo — piensa en marketing de multinacionales, no de MVPs), April Dunford (su framework de positioning es excelente pero está diseñado para productos existentes que buscan reposicionarse, no para lanzamientos desde cero).
Balaji Srinivasan — Hype y Viralidad
Este es el consejero más agresivo del panel. Entiende los mecanismos de distribución crypto-nativos: FOMO, incentivos tokenizados, network effects, y la mecánica específica de cómo algo pasa de cero a trending en 48 horas.
Lo que aporta al consejo: la pregunta «¿qué hace que alguien haga un screenshot de esto y lo publique en Twitter en los próximos 5 minutos?» Es la unidad atómica de viralidad. Si tu producto no genera screenshots espontáneos, necesitas presupuesto de marketing.
Descartados para esta silla: GaryVee (entiende atención pero no la intersección crypto+AI, que es donde están los mecanismos virales más potentes hoy), Mr. Beast (su expertise es viralidad en contenido audiovisual, no en productos tech), Nir Eyal (su framework «Hooked» está diseñado para retención, no para viralidad de lanzamiento — son problemas distintos).
DHH (David Heinemeier Hansson) — Técnico
Su obsesión es «la cosa más simple que funciona». Para un MVP, el mayor riesgo técnico no es usar la tecnología equivocada. Es no lanzar nunca porque te pasaste tres meses eligiendo el stack.
Lo que aporta al consejo: la pregunta «¿puede una persona construir esto en 2 semanas?» Si la respuesta es no, o el alcance es demasiado grande o el stack es demasiado complejo. Su regla de «boring technology» (PostgreSQL, no CockroachDB; Redis, no Dragonfly) es el antídoto contra el síndrome de «usamos blockchain porque podemos».
Descartados para esta silla: Werner Vogels (piensa en escala desde el día 1, que es exactamente lo que no necesitas en un MVP), Kelsey Hightower (su expertise en Kubernetes sobreingeniaría cualquier MVP — es matar moscas a cañonazos).
Las tensiones productivas: donde emerge la verdad
Las tensiones entre consejeros no son un defecto del diseño. Son el diseño.
Balaji vs. Lessig: viralidad contra regulación
Esta es la tensión principal. Balaji querrá mecanismos de FOMO con dinero real (prize pools visibles, pay-to-play, tokens). Lessig señalará que en la UE, pay-to-play con bote acumulado se clasifica como juego de azar y necesita licencia de la DGOJ.
La resolución productiva no es que uno gane. Es que emerja un diseño que satisfaga ambos: por ejemplo, challenges gratuitos con sponsors que ponen el prize pool (legal en la mayoría de jurisdicciones) en vez de entry fees directas (gambling en muchas).
Godin vs. DHH: remarkable contra espartano
Godin querrá una experiencia memorable — un leaderboard público con animaciones, perfiles de participantes, badges de logro. DHH querrá una página estática con SQLite y un formulario.
La resolución: ¿puedes ser remarkable con tecnología aburrida? La respuesta casi siempre es sí. El contenido del challenge es lo remarkable, no la interfaz. Un leaderboard en una tabla HTML sin JavaScript puede ser más notable que un dashboard con Three.js si el contenido que muestra es genuinamente impresionante.
Paul Graham vs. Balaji: unit economics contra growth
PG querrá un modelo de ingresos claro desde el día 1. Balaji dirá que la distribución viral ES el modelo — primero audiencia, luego monetización.
Ambos tienen precedentes a su favor. Instagram no tenía modelo de ingresos cuando llegó a 100 millones de usuarios. Pero por cada Instagram hay 10.000 proyectos que crecieron sin modelo y murieron sin dinero.
La resolución suele ser temporal: validar la viralidad primero (da la razón a Balaji), pero con un timeline estricto para demostrar unit economics (da la razón a PG). Los kill criteria formalizan este acuerdo.
El output más valioso: kill criteria
La mayoría de side projects mueren lentamente. No hay un momento de fracaso claro. El fundador simplemente deja de dedicarle tiempo porque «surgieron otras cosas». Tres meses después, el dominio caduca y nadie se da cuenta.
Los kill criteria son lo contrario: umbrales concretos, con plazos concretos, que definen cuándo parar.
| Señal | Umbral | Plazo | Acción |
|---|---|---|---|
| Participantes en beta | <50 en 2 semanas | Semana 2 | Pivotar o cancelar |
| Shares del post de lanzamiento | <100 | Semana 4 | Revisar positioning |
| Usuarios recurrentes | <10% retención a 30 días | Semana 8 | Cancelar |
La regla: si 2 de 3 kill criteria se incumplen, el proyecto se para. Sin excepciones. Sin «un mes más». Sin «es que no hemos hecho suficiente marketing».
Esto es lo que distingue a un profesional de un aficionado. El aficionado se enamora de la idea. El profesional se enamora del resultado. Y si el resultado no llega en el plazo acordado, tiene la disciplina de parar y dedicar su energía a otra cosa.
Por qué simulaciones y no personas reales
La objeción obvia: ¿por qué no hablar con personas reales en vez de simular expertos con un LLM?
Tres razones.
Disponibilidad. Paul Graham no te va a dar 2 horas para analizar tu side project. La simulación sí. Y aunque la simulación no tenga la experiencia acumulada del original, aplica los frameworks publicados del original con una consistencia que una persona ocupada no te daría.
Adversarialidad honesta. Las personas reales suavizan sus críticas por cortesía social. Una simulación configurada para ser adversarial lo es de verdad. «Tu modelo de ingresos no existe» es una frase que un inversor piensa pero no dice en la primera reunión. La simulación la dice en la primera ronda.
Coste marginal cero. Puedes ejecutar el consejo 5 veces con variaciones de la misma idea y comparar resultados. Intentar eso con 5 personas reales requiere 25 horas de su tiempo.
Las simulaciones no reemplazan a asesores reales. Pero permiten llegar a la conversación con un asesor real habiendo eliminado ya los problemas obvios. Es la diferencia entre presentar un borrador limpio y presentar un primer impulso sin filtrar.
El meta-patrón: debate estructurado como herramienta de decisión
Este diseño no es exclusivo de MVPs. Ya lo uso para code review (tres expertos en simplicidad, diseño y rendimiento) y para design review (cuatro expertos en densidad informativa, usabilidad, producto e interacción).
El patrón es siempre el mismo:
- Expertos con jurisdicción definida: cada uno tiene un dominio sobre el que opina con autoridad. Fuera de su dominio, no tiene voto.
- Frameworks de decisión explícitos: no «qué piensas» sino «qué dice tu framework sobre esto».
- Tensiones diseñadas: los conflictos entre expertos están planificados. Son la fuente de información más valiosa del proceso.
- Convergencia forzada: máximo N rondas. Si no hay consenso, el moderador decide y documenta la disidencia como riesgo.
- Output accionable: no un ensayo, sino issues, timelines, y criterios de éxito/fracaso.
La diferencia entre «pedir a un LLM que analice tu idea» y «pedir a 5 LLMs especializados que debatan sobre tu idea» no es de grado. Es de naturaleza. El primero produce una opinión. El segundo produce un mapa de riesgos y un plan donde los puntos ciegos de cada perspectiva quedan expuestos por las demás.
La pregunta que deberías hacerte
Antes de escribir la primera línea de código de tu próximo proyecto, pregúntate: ¿quién te va a decir que es mala idea?
Si la respuesta es «nadie, porque no se lo he preguntado a nadie», ya tienes un problema. Y si la respuesta es «mis amigos, que me apoyan mucho», tienes un problema peor.
Lo que necesitas no es apoyo. Es escrutinio estructurado de gente (real o simulada) que tenga incentivos para encontrar los fallos, no para validar tus ilusiones. Cinco perspectivas que se contradicen entre sí producen más verdad que una que te da la razón.
El coste de evaluar una idea es una tarde. El coste de construir una idea mala es meses de tu vida que no recuperas. Las cuentas son claras.
Relacionado: Si te interesa cómo el pensamiento adversarial se aplica al debugging de sistemas opacos, Una red neuronal de 2.500 capas que resulta ser MD5. Y si quieres ver cómo funciona el mismo patrón de consejo aplicado a code review, Simplify: un consejo Jedi para code review con IA.
Read this article in English.
