Un equipo le pregunta a Claude Code si su repo cubre de verdad un dolor real del usuario. La respuesta llega rápida, afilada y justa. Luego le preguntan lo mismo a Brújula y obtienen otra lectura, conectada al mapa de lo que el producto ya es. Las dos tienen razón en parte.
La pregunta interesante no es cuál IA “gana” ese intercambio. Es qué tipo de sistema necesita un equipo para seguir decidiendo bien, durante meses, no en un único chat.
¿Por qué decidir es ahora más difícil que construir?
Durante años, una parte grande del coste estaba en convertir una idea en código. Con agentes como Claude Code, Codex, Cursor o Kimi, construir es mucho más barato y rápido. Eso no hace menos importante el trabajo de producto. Lo hace más exigente.
Si cualquiera puede construir más rápido, la ventaja ya no está en producir features. Está en decidir mejor qué construir, con qué evidencia, bajo qué supuestos, y cómo aprender antes de acumular deuda de producto.
Construir barato trae una trampa dentro. Ahora puedes generar más pantallas, más épicas, más experimentos, más código. Y más deuda de producto. Si el equipo no mejora su sistema de decisión al mismo ritmo, toda esa velocidad solo acelera la dispersión.
Ese es el nuevo cuello de botella. No teclear. Decidir, y aprender.
¿El product management clásico está obsoleto con la IA?
Esta no es la parte donde alguien anuncia que los clásicos están obsoletos. No lo están.
Valor, viabilidad, usabilidad y factibilidad siguen siendo el trabajo. El descubrimiento continuo sigue ganándole a discutir una única solución que parece inevitable. Una métrica compartida que capture el valor real al usuario sigue evitando que el equipo hable cuatro idiomas distintos. El linaje de Cagan, Teresa Torres y la gente de la North Star no lo ha sustituido la IA. La era IA sube el listón sobre todo ello, porque acelerar el código y el diseño no garantiza mejores outcomes. El trabajo difícil, encontrar soluciones valiosas y viables, necesita más juicio, no menos.
Lo nuevo es dónde tiene que vivir ese juicio. No en un documento estático que envejece al día siguiente de escribirse.
En la era de la IA, el PRD deja de ser el documento que precede al producto. Pasa a ser un sistema vivo que evalúa, recuerda y corrige las decisiones del producto.
¿Qué cambia en el product management con la IA?
La forma del trabajo se mueve en seis frentes:
- de explorar una solución a explorar muchas rutas
- de un PRD a un prototipo evaluable
- de la opinión a los evals
- de la búsqueda documental a un grafo de relaciones
- de un roadmap estático a un decision ledger
- de “el PM escribe requisitos” a “el PM diseña el sistema que aprende”
Ninguno de estos quita al humano. Cambian de qué es responsable el humano. En un mundo de agentes, la persona de producto deja de ser quien escribe la spec y pasa a ser quien diseña el bucle de decisión.
¿Qué hace Brújula por el product management?
Brújula es la capa de razonamiento de producto dentro de PaellaDoc. Lee tu repo, tus artefactos, tus decisiones y tus conversaciones, y conecta cinco cosas:
- Mapa as-built: qué existe de verdad en el repo.
- Provenance: de dónde viene cada artefacto.
- Grafo semántico: cómo se relacionan capacidades, riesgos, decisiones y evidencia.
- Apuestas futuras: las direcciones candidatas que se derivan de todo ello.
- Evals de producto: cómo sabes si una recomendación ha sido buena.
Lo importante es lo que se niega a hacer. No te entrega una estrategia y la llama verdad.
Brújula no dice “esta es la estrategia”. Dice: esto es lo que se puede inferir, esto es lo que no se sabe, estas son las apuestas candidatas, y esta es la validación mínima antes de construir más.
¿Puede el reverse intake revelar la estrategia de producto?
Un reverse intake no es discovery. No habla con usuarios, no mide dolor y no reconstruye la intención original del equipo. Su valor es otro: muestra qué producto se ha construido de verdad. Ese mapa as-built, más provenance y relaciones, basta para detectar capacidades, huecos y deuda de decisión. A partir de ahí, el trabajo no es dictar una estrategia. Es formular apuestas candidatas y nombrar qué validar antes de construir más.
Lo que significa que no toda fuente permite el mismo tipo de afirmación. Esta es la parte que casi todos los grafos de producto hacen mal:
| Lo que quieres afirmar | Lo que necesita | Qué puede sostenerlo |
|---|---|---|
| ”El usuario siente este dolor” | usuarios reales, uso, validación | evidencia externa, validation runs |
| ”Lo decidimos a propósito” | docs y decisiones de humanos | fuentes naturales, escritas por personas |
| ”Esta capacidad existe” | el producto construido | reverse intake |
| ”Así está implementado” | el código | código en crudo |
La regla que mantiene a Brújula recta consigo misma: un nodo de reverse intake puede sostener esto existe. No puede sostener esto le importa al usuario. Un grafo bonito de nodos no es evidencia. La apuesta ordenada, puntuada por la evidencia que de verdad la respalda, sí.
¿Claude Code o Brújula para decidir producto?
Esto no es una batalla de modelos, y Brújula no es “la más lista”. Claude Code directo es excelente en lo suyo: leer código en crudo con precisión, detectar dispersión y deuda, contestar una pregunta técnica o local afilada, sin capa intermedia. Para diagnóstico puntual, tíralo de ahí.
Su límite es la continuidad. El contexto se reconstruye en cada chat. No hay provenance estructurada, ni historial de decisiones reutilizable, ni grafo de artefactos persistente, ni comparación entre versiones, ni evals de producto repetibles. La respuesta es buena y luego se evapora.
Brújula es la infraestructura de la parte que tiene que persistir:
| Claude Code directo | Brújula |
|---|---|
pregunta → escaneo del repo → buena respuesta → contexto perdido | pregunta → grafo + provenance + historial → respuesta → artefacto → eval → decision ledger → mejor respuesta siguiente |
La diferencia no es que Brújula piense mejor que Claude Code en una pregunta aislada. Es que Brújula convierte el razonamiento de producto en un sistema persistente, auditable y mejorable.
¿Qué son los evals de producto y por qué sustituyen al PRD estático?
En productos de IA, la calidad no se controla solo con tests deterministas. Hay que definir qué es una buena respuesta, qué fallos son inaceptables y qué evidencia puede sostener una recomendación. Por eso los evals empiezan a parecerse a PRDs vivos: no describen una feature una vez, evalúan continuamente si el producto se comporta como ha prometido.
Así que cada respuesta de Brújula que recomiende una dirección debería poder evaluarse a sí misma: si ha mantenido recta la provenance, si ha separado evidencia de hipótesis, si ha propuesto una validación siguiente concreta, si ha evitado certeza estratégica sin respaldo. Es la misma apuesta que el resto de lo que construyo, donde lo que hace fiable la salida es la spec, no la intuición del modelo. Lo he medido en el benchmark de verificación: en crudo, el modelo cuela errores; con el contrato escrito, no.
¿Cuál es la ventaja de producto en la era IA?
La nueva ventaja de producto no es una IA que responde una vez. Es un sistema que recuerda, conecta, cuestiona y evalúa cada decisión de producto a lo largo del tiempo.
El futuro del product management no es humanos contra agentes. Es diseñar un sistema donde los agentes construyen, el grafo recuerda, los evals corrigen y las personas siguen siendo responsables del juicio. El PM no desaparece. Se convierte en el diseñador del bucle de decisión.
He escrito sobre mantener vivo el contrato de producto mientras los agentes hacen la escritura, en el runtime eres tú. Esta es la otra mitad: generar el contrato correcto desde el principio, y ser claro sobre qué puedes y qué no puedes afirmar todavía. Brújula es esa capa para PaellaDoc. No una IA que pretende tener la verdad. Un sistema que te ayuda a encontrarla más rápido.
Brújula es la capa de razonamiento de producto dentro de PaellaDoc, local-first y gratis. Convierte tu repo, tus decisiones y tu evidencia en un mapa de producto que puedes interrogar.
Si construir ya es barato, ¿cuál es la decisión más lenta y más cara que tu equipo sigue rehaciendo desde cero? Cuéntame en el foro.
Preguntas frecuentes
¿La IA ha dejado obsoletos a los product managers?
No. La IA ha abaratado construir, lo que ha movido el cuello de botella de construir a decidir qué construir y con qué evidencia. El juicio del PM importa más, no menos. Pasa de escribir requisitos a diseñar el bucle de decisión: qué explorar, qué validar y qué evidencia tiene que respaldar una elección antes de que los agentes la conviertan en código publicado.
¿Cuál es el nuevo cuello de botella del product management?
Decidir y aprender. Cuando los agentes construyen en horas, la ventaja ya no es producir features más rápido, es decidir mejor qué construir y validarlo antes de acumular deuda de producto. Construir barato te deja generar más pantallas, más épicas, más experimentos, y más deuda. Si el sistema de decisión no mejora al mismo ritmo, esa velocidad solo acelera la dispersión.
¿Qué son los evals de producto?
Los evals definen qué es un buen comportamiento de producto, qué fallos son inaceptables y qué evidencia sostiene una recomendación. Funcionan como PRDs vivos: en vez de describir una feature una vez, comprueban continuamente si el producto se comporta como prometió. Cada recomendación se vuelve evaluable, si mantuvo recta la provenance, separó evidencia de hipótesis y propuso una validación siguiente concreta.
¿Brújula sustituye a Claude Code?
No. Claude Code es excelente para diagnóstico ad hoc del repo: leer código en crudo con precisión, detectar dispersión y deuda, contestar una pregunta local afilada. Su límite es la continuidad, el contexto se reconstruye en cada chat. Brújula es la capa que persiste: provenance, historial, un grafo de producto y evals de producto, para que el equipo no reanalice su producto desde cero cada vez.