El manual del fundador IA — las 36 páginas de Anthropic, en español

Quiero validar esta idea de negocio: [describí tu idea en una frase].

Mi hipótesis del problema, como la tengo hoy, es: [escribí el problema que creés que existe].

Ayudame a afilarla hasta que sea una hipótesis testeable: que diga quién exactamente tiene el problema, cada cuánto lo sufre, qué tan grave es y qué hace hoy para resolverlo. Mostrame la diferencia entre una observación vaga y una hipótesis concreta. Ejemplo de lo que busco: en vez de "revisar contratos toma demasiado tiempo", algo como "los equipos legales de empresas medianas pasan más de 3 días por contrato porque los cambios se manejan en cadenas de email y no en un solo documento con control de versiones".

Devolveme mi hipótesis reescrita así de específica, y decime qué tendría que ver en el mundo real para confirmarla o para tumbarla.

Quiero que actúes como abogado del diablo de mi idea, no como animador. Mi idea es: [tu idea]. Mi hipótesis del problema es: [tu hipótesis afilada].

Tu trabajo es construir el caso más fuerte de por qué esto va a fracasar. Dame:
1. Las razones estructurales por las que este problema podría no valer la pena resolver.
2. Señales de mercado negativas: competidores que ya lo intentaron y fracasaron, y por qué.
3. Patrones de comportamiento de los clientes que jueguen en contra.
4. Mis supuestos más frágiles, los que si fallan tiran todo abajo.

No suavices nada para hacerme sentir bien. Si encontrás evidencia de que mi idea necesita cambiar, decímelo claro: esa es la señal para pivotar.

Ayudame a mapear el panorama competitivo de [tu idea / tu mercado] por niveles:
- Competidores directos.
- Competidores indirectos (otras formas en que la gente resuelve hoy el problema).
- Posibles compradores (empresas grandes que podrían entrar a este espacio).
- Jugadores adyacentes que podrían moverse hacia acá.

Para cada nivel, armá el argumento más fuerte de por qué ESE competidor podría ganarme, no la versión más fácil de descartar.

Después, sintetizá las quejas más repetidas de los clientes de esos competidores (de reseñas y comentarios públicos): qué es lo que las soluciones actuales todavía no resuelven. Si mi idea ataca una de esas quejas, es evidencia fuerte a favor; si no la ataca, también me sirve saberlo.

Ayudame a dimensionar el mercado de [tu idea] con un modelo TAM / SAM / SOM, y dejá a la vista los supuestos detrás de cada número. No me des solo la cifra que me haga ver fundable: cuestioná los supuestos.

Decime si este mercado está creciendo, consolidándose o ya maduro, y quién tiene el presupuesto y quién decide la compra (¿son la misma persona?).

Después, identificá tres tendencias externas —una regulatoria, una tecnológica y una demográfica— que puedan afectar este mercado en los próximos dos años. Para cada una, decime si es viento a favor o viento en contra para mi caso puntual.

Quiero entrevistar a clientes potenciales para validar [tu hipótesis]. Ayudame con tres cosas.

1. A quién: armá un perfil objetivo preciso (puesto, tipo de empresa, tamaño de equipo, antigüedad) de quién sufre este problema más fuerte, y dónde encuentro a esa gente (comunidades, eventos, grupos de LinkedIn, Slacks).

2. Qué preguntar: voy a escribir mis preguntas a mano y quiero que las audites. Marcá cualquier pregunta tendenciosa, que apunte al futuro hipotético ("¿usarías algo así?") en vez del pasado real ("contame la última vez que tuviste este problema"), o demasiado abierta. Sugerime una repregunta para los dos o tres momentos donde la persona probablemente se vaya por las ramas. Mis preguntas son: [pegá tus preguntas].

3. Organización: armá una lista de prospectos a partir del perfil, una secuencia de mensajes personalizados para contactarlos y una hoja de seguimiento con el estado de cada uno. (En Claude Cowork esto se puede conectar a tu correo y calendario para agendar solo.)

Acá están mis notas de las últimas entrevistas con clientes potenciales: [pegá tus notas].

Hacé dos listas claras y separadas:
1. La evidencia que APOYA mi hipótesis.
2. La evidencia que la CONTRADICE.

Si la primera lista es mucho más larga que la segunda, decime con honestidad si esa diferencia refleja lo que de verdad dicen los datos, o si refleja lo que yo quería encontrar. Marcá cualquier punto donde mi lectura parezca estar acomodando las respuestas a lo que me conviene creer.

Ya hice el trabajo de validación: el problema es real y tengo un concepto de solución que la evidencia respalda. Dame una mano en dos pasos.

1. Estresá mi concepto: [describí tu solución]. Decime los tres supuestos de los que más depende este diseño, qué tendría que ser cierto para que cada uno se sostenga, y qué pasa si alguno falla. ¿Este diseño ataca el problema que reveló la validación, o el que asumí al arrancar?

2. Cuando el concepto aguante, ayudame a definir la ÚNICA interacción central de la que depende la solución. Construyamos solo eso con Claude Code —un prototipo liviano, no el producto real— para ponerlo frente a 5 personas de mi perfil objetivo. Lo que aprenda en esas 5 conversaciones decide si sigo o vuelvo al tablero.

Antes de abrir Claude Code, quiero definir la arquitectura de mi MVP. Te describo qué estoy construyendo: [el problema central que resuelve, quiénes son los usuarios, y la escala que espero de forma realista en los próximos seis meses].

Ayudame a definir:
- Los principios de arquitectura que deberían gobernar el build.
- Las dependencias que conviene evitar dado mi contexto.
- Los tradeoffs que estoy aceptando conscientemente en esta etapa, y por qué.

Dejá el resultado listo para guardar como un archivo CLAUDE.md: va a ser mi documento de contexto de arquitectura, el primer artefacto del proyecto y la base que Claude Code lee en cada sesión para no arrancar de cero.

Ayudame a escribir un documento de alcance para mi MVP, antes de construir una sola función. Mi producto es: [descripción].

El documento tiene que dejar claro:
- Qué hace el producto.
- Qué NO hace, deliberadamente.
- Qué evidencia concreta de usuarios reales justificaría agregar algo nuevo (no "sería lindo", sino "un grupo de usuarios nos dijo que sin esto no le sacan valor").

Cuando más adelante te traiga ideas de funciones nuevas, tu trabajo es presionarlas contra este documento: ¿es señal real de los usuarios, o es entusiasmo mío disfrazado de estrategia de producto?

Ayudame a armar una plantilla simple para mis sesiones de trabajo con Claude Code, de forma que cada sesión sea coherente. La plantilla debe incluir:
- Al arrancar: revisar el documento de alcance y cargar el contexto de mi CLAUDE.md.
- La tarea específica de esta sesión y las restricciones o patrones que tengo que respetar.
- Al cerrar: una entrada de bitácora corta que registre qué se construyó, qué decisiones se tomaron y qué supuestos nuevos se introdujeron.

Esos cinco minutos de documentación por sesión son mi seguro contra la deriva de arquitectura que termina en un código imposible de mantener.

Antes de poner mi MVP frente a cualquier usuario real, revisá el código principal de la aplicación con foco en seguridad. Revisá específicamente:
- Autenticación y manejo de sesiones.
- Exposición de datos en las respuestas de las APIs.
- Validación de entradas y riesgos de inyección.
- Dependencias con vulnerabilidades conocidas.

Para cada hallazgo, decime qué tan grave es y si requiere arreglo antes de salir. Marcá con prioridad alta todo lo que toque autenticación, secretos o manejo de datos: eso quiero revisarlo yo a mano, no dejarlo solo en tu palabra.

Quiero definir mi marco de medición antes de que llegue el primer usuario, para no terminar midiendo solo lo que me conviene. Mi producto es: [descripción].

Ayudame a fijar:
- Qué métricas importan de verdad para este producto y cuáles son sus benchmarks.
- Mis criterios de activación y mis metas de retención a Día 7 y Día 30.
- Qué sería un falso positivo en mi caso (por ejemplo: registros sin activación, ingresos sin retención, entusiasmo inicial sin uso repetido).

Sumá dos pruebas del manual para leer el PMF:
1. Test de Sean Ellis: preguntarles a los usuarios activos "¿cómo te sentirías si ya no pudieras usar esto?". Más del 40% que responde "muy decepcionado" es señal real de PMF.
2. Test del esfuerzo: antes del PMF, retener pide esfuerzo heroico constante (outreach, incentivos); después del PMF, el producto empieza a jalar solo.

Cuando lleguen los datos, hacé el caso adversarial: ¿qué diría un escéptico sobre estos números?

Dos pedidos sobre el feedback de mis usuarios de MVP.

1. Logística (para Claude Cowork): armá y mantené el ciclo de feedback —contactar a los usuarios, agendar sesiones, recibir reportes de bugs y pedidos de funciones, y escribir una síntesis semanal de lo que llegó. Yo reviso la síntesis; después vos analizás si se me escapó algún punto importante.

2. Diagnóstico de pivote: ya llevo [número] ciclos de iteración sin avanzar hacia mis metas de PMF. Antes de decidir qué hacer, tomá mis datos de retención, el feedback de usuarios y mi hipótesis original del problema, y respondé tres preguntas: ¿hay un segmento que responde distinto al resto? ¿la brecha entre el valor que diseñé y el valor que la gente experimenta es un problema de posicionamiento o de producto? ¿qué tendría que ser cierto para que este producto encuentre PMF, y es realista dado lo que estoy viendo? Que tus respuestas decidan si ajusto, pivoto o vuelvo a la etapa de Idea.

Dirigí a Claude Code para hacer una auditoría completa de arquitectura sobre el código de mi MVP. Producí una lista priorizada de:
- Debilidades estructurales (dónde está frágil el código).
- Huecos en la cobertura de tests.
- Candidatos a refactorización.

Después, tomá esa lista y secuenciá la remediación a lo largo de mis próximos sprints: qué hay que arreglar antes del próximo release, qué puede esperar un sprint, y qué es deuda aceptable para mantener por ahora.

Por último, ayudame a documentar en mi CLAUDE.md las decisiones de arquitectura que tomé durante el MVP y que viven solo en mi cabeza, así cada sesión futura arranca con un entendimiento compartido de por qué el sistema está hecho como está.

Quiero dejar de ser el cuello de botella de mi startup. Usá Claude Cowork para hacer una auditoría estructurada de mi carga operativa: cada tarea recurrente, cada decisión que cae en mi escritorio y cada flujo que solo pasa porque yo me acuerdo de hacerlo. Mi día a día, lo más completo que pueda describirlo, es: [describí tus tareas].

Clasificá cada cosa en tres baldes:
1. Se puede automatizar por completo.
2. Necesita un humano, pero no necesariamente a mí.
3. Requiere genuinamente criterio de fundador.

Para los candidatos a automatizar, diseñá la lógica del flujo: qué lo dispara, cuáles son las reglas de decisión, cómo se ve el resultado y a dónde va cuando termina.

Hacé una revisión de seguridad a nivel de código con Claude Code, orientada a los marcos que exige mi mercado objetivo: [SOC 2 / GDPR / HIPAA / el que aplique]. Surgí tanto las vulnerabilidades como los huecos de compliance.

Después, con esos hallazgos, producí dos cosas:
1. Una secuencia priorizada de remediación de seguridad.
2. La lista de documentación y controles —logging, gestión de accesos, auditoría— que un comprador enterprise va a pedir antes de firmar.

Tratá esto como un flujo continuo dentro de mi ciclo de desarrollo, no como un proyecto único. Y recordá: tu escaneo es una ayuda, no un reemplazo de una revisión de compliance hecha por un profesional.

Ayudame a diseñar un sistema operativo de gestión de producto liviano para la etapa de lanzamiento, que pueda correr sin que yo intervenga cada vez. Quiero:
- Una cadencia de sprint definida.
- Una plantilla mínima de spec: qué necesita estar definido antes de que Claude Code toque una función.
- Un árbol de decisión para el triage de bugs: cómo se clasifican y a dónde se rutean.
- Un brief de métricas semanal que tome los datos de mis fuentes reales.

Cuando el diseño esté, quiero que Claude Cowork implemente y corra los elementos recurrentes: agendar las ceremonias de sprint, rutear los reportes de bugs y compilar el brief de métricas, en fecha y sin mí.

Quiero soltar el día a día sin que se caiga nada. Primero, ayudame a hacer la lista de las cosas que SOLO yo debería estar haciendo en esta etapa (narrativa de producto, relaciones con el directorio, cierres enterprise, conversaciones fundador a fundador). Todo lo que no esté en esa lista es candidato a delegar o automatizar con Claude Cowork.

Después, con Cowork, armá un mapa de cuellos de botella de mi capa operativa actual: cada flujo, decisión y aprobación que pasa por mí. Extrapolá qué le pasa a cada uno si yo no estoy disponible una semana entera. Los flujos que se traban son donde todavía soy indispensable: ahí hay que apretar los criterios de traspaso, las rutas de escalación y el manejo de excepciones. Analizá los puntos de falla y recomendá los arreglos.

Elegí mis tres prospectos más exigentes (o tres clientes ideales que me encantaría cerrar): [nómbralos o describilos]. Hacé un análisis de brechas: qué documentación, qué SLAs (acuerdos de nivel de servicio) y qué infraestructura de soporte esperaría el equipo de compras enterprise de cada uno antes de firmar un contrato de varios años, y dónde me quedo corto hoy.

Después, secuenciá el trabajo entre Claude Code y Claude Cowork:
- Claude Code: endurecer el código contra los estándares de confiabilidad y seguridad que piden los contratos enterprise, y construir la infraestructura de soporte técnico que nunca tuve (logging, monitoreo, respuesta a incidentes, observabilidad para que los SLAs sean exigibles).
- Claude Cowork: correr la capa operativa del soporte enterprise (ruteo de tickets, escalaciones, actualizaciones de documentación cuando cambia el producto, seguimiento de renovaciones, cadencias de reporte).

Ayudame a construir desde cero una función de salida al mercado (GTM) para mi startup en escala. Mi producto es: [descripción]. Mis audiencias ahora incluyen [usuarios nuevos / compradores enterprise / inversores / analistas].

Construí los recursos fundamentales: segmentación de mercado, arquitectura de mensajes, estrategia de relación con analistas, playbooks de ventas, y narrativas de métricas orientadas a inversores. Traducí mis propuestas de valor a un enfoque de marketing de producto relevante para cada segmento (cada audiencia tiene su propio vocabulario y me evalúa con su propia vara).

Después, que Claude Cowork sea la capa de ejecución táctica: pipelines de contenido, secuencias de outbound, logística de briefings con analistas, cadencias de prensa, higiene del CRM y reportes de pipeline.

Quiero meter mi expertise de dominio dentro del producto para que sea un foso que un competidor genérico no pueda copiar. Mi sector es [tu sector] y los detalles que yo conozco y otros no incluyen [jerga, reglas regulatorias, casos borde, frustraciones, razones por las que las respuestas obvias no funcionan].

Dos pasos:
1. Ayudame a capturar y organizar este conocimiento en un contexto estructurado y buscable, y a codificar mis flujos recurrentes (por ejemplo "cómo audito un contrato de alquiler comercial") como Skills reutilizables que Claude corra igual cada vez.
2. Identificá un caso borde que un competidor genérico resolvería mal en mi vertical. Con Claude Code, construyamos un test case dedicado para ese caso (basado en una situación real que yo haya visto). Cada vez que aparezca un caso borde parecido, lo sumamos: con el tiempo, mi suite de tests se vuelve el mapa de mi foso.

Quiero convertir lo que mis usuarios generan y construyen sobre mi producto en una ventaja que no se pueda replicar. Dos partes.

1. Datos: acá hay un resumen de los datos de interacción que vengo recolectando —qué recolecto, desde cuándo, y cómo cambia el uso con el tiempo: [resumen]. Identificá los tres patrones de comportamiento de mayor señal, y diseñá el ciclo (data flywheel) que convierte ese uso en mejora sistemática del producto. Después, redactá una narrativa de foso de una página: cómo funciona mi flywheel, hace cuánto está girando, y por qué un competidor con muchos recursos que arranca hoy no podría replicarlo en menos de dos años.

2. Integraciones: ayudame a auditar a mis 10 clientes más grandes por profundidad de integración —qué flujos construyeron sobre mi producto, de qué integraciones dependen, y cuál sería su costo de cambiarse. Identificá qué tipos de integración crean el lock-in más profundo y qué podría construir (integraciones nativas, APIs, webhooks, SDKs) para que los clientes que hoy están en la superficie se integren más hondo.