Un repo puede parecer un roadmap si lo resumes mal. Apunta un agente listo a un codebase, pregúntale “qué hace este producto”, y te devuelve una lista de features limpia y segura. Parece progreso. Rara vez te dice si algo de eso debería seguir ahí.
Claude Code es excelente leyendo un repo. Encuentra subsistemas, traza eventos y rutas, detecta gaps de instrumentación y responde con criterio. Para diagnóstico puntual, tíralo de ahí. Este no es un artículo sobre Claude Code siendo flojo.
Es sobre otra más difícil. Olvídate de qué hay en el repo. ¿Qué forma tiene el producto que has construido? Esa pregunta necesita algo que Claude Code tira entre chats: una memoria del producto como sistema.
Esa memoria es Brújula, la nueva vista de razonamiento de producto dentro de PaellaDoc. Lee tu repo y tus artefactos en un grafo, lo mantiene en tu máquina, y habla de producto, no de código. Todo lo de abajo es lo que eso te da.
¿Qué es un grafo de conocimiento de producto?
Un grafo de conocimiento de producto es el producto que has construido visto como sistema, no como lista. Lleva las zonas y cómo se conectan, de dónde ha salido cada pieza, a qué distancia está del core, y si algo lo ha probado de verdad. La versión obvia, un árbol limpio de PRD a épica a story a criterio, ayuda. No es ahí donde está el valor.
El valor es leer la forma. ¿Dónde está el centro real de lo construido, y qué queda lejos y cuesta caro de mantener? Hay zonas que son puentes entre dos mundos, otras son fontanería, otras son apuestas de growth que nadie ha probado. El grafo te enseña cuál es cuál.
Eso es topología, y convierte un producto en un mapa desde el que decidir. Una lista de features te dice qué existe. La forma te dice dónde mirar primero.
¿Qué te dice la forma de un producto, y qué no?
Una lectura topológica de un grafo de producto puede inferir:
- el centro real del producto construido
- las periferias caras
- las capacidades puente que conectan zonas
- las áreas duplicadas o fragmentadas
- la línea entre infraestructura y valor de usuario
- dónde se concentra el esfuerzo
- la distancia entre una zona y el core
- la deuda de validación: muy construido, poco probado
- las preguntas que deberían desbloquear una decisión
No puede inferir, solo por la forma:
- si los usuarios aman una feature
- si una zona genera revenue
- si una apuesta ha sido buena o mala
- si el roadmap original tenía razón
- si una zona lejana debe eliminarse
La forma no decide por ti. Te dice dónde decidir primero. Ese hueco, entre señalar y decidir, es la línea que Brújula tiene que mantener consigo misma.
¿Qué forma tiene la topología de producto en la práctica?
Coge una app de aprendizaje de idiomas, de las que cualquiera se imagina. Lee su grafo como un mapa y la forma aparece rápido:
- Core: el motor de aprendizaje. Lecciones, repetición espaciada, progreso, niveles, repaso.
- Infraestructura portante: el pipeline de contenido, el audio, el job diario, el login.
- Puentes: el onboarding hacia la primera lección, el loop de racha que tira de la gente de vuelta, un modo práctica que reutiliza el motor de lecciones.
- Periferia cara: ligas, leaderboards, clubes, un feed social, eventos de temporada, el backoffice competitivo de todo eso.
- Apuesta especulativa: una API pública y una plataforma para escuelas y equipos.
- El riesgo central: se ha construido una máquina competitiva grande encima de un motor de aprendizaje, sin prueba de que convierta en aprendices que de verdad sigan progresando.
Ahora la pregunta de producto no es “¿son buenas o malas las ligas?”. Es más afilada:
¿Las ligas son un canal de adquisición que produce aprendices retenidos y que progresan, o un segundo producto que se come el foco del primero?
Eso no lo contestas desde una lista de features. Empiezas a contestarlo desde la forma, más la única medición que falta y a la que la forma te apunta.
¿Brújula o Claude Code para decidir producto?
Usa Claude Code para diagnosticar el repo y Brújula para leer el producto. Esto no es una competición de quién es más listo en una pregunta. Son dos trabajos distintos.
| Claude Code, directo | Brújula |
|---|---|
| diagnóstico de repo rápido y afilado | convierte el repo en mapa de producto |
| encuentra evidencia concreta: servicios, eventos, rutas, commits | encuentra forma: core, periferia, puentes, densidad |
| gaps operativos muy accionables | separa infraestructura de valor de usuario de apuestas de growth |
| más barato y directo | preguntas de producto repetibles sin empezar de cero |
| reanaliza desde cero en cada pregunta | conserva memoria estructural entre preguntas |
| lee el repo | lee el producto como sistema, con provenance |
Los he corrido a los dos contra el mismo producto. En “qué está muy construido pero poco validado”, Claude Code ha sido fuerte encontrando gaps de instrumentación concretos. Brújula ha sido mejor estructurando la deuda: cuánto del grafo está inferido frente a respaldado por una fuente independiente, qué zonas están sobreconstruidas respecto a su distancia del core, dónde la construcción ha adelantado a la prueba.
En “mapea la topología: centro real, periferias caras, puentes, infraestructura frente a valor, sobreinversión sin outcome, preguntas urgentes de validación”, los dos leen distinto. Claude Code ha escrito como un auditor técnico: broker links, eventos, servicios, idiomas. Brújula ha escrito como un memo de producto: core, periferia, puentes, el supuesto arriesgado, la decisión.
Puntuado como lo puntuaría un CPO, ha ganado el memo de producto, pero no por paliza. Y esta es la parte que toca decir en claro: para llegar a un memo de CPO top, el mapa no basta. Necesita negocio real: revenue, CAC, LTV, cohortes, compromisos comerciales, estrategia de compañía. Brújula mapea el producto construido. No se inventa los números que no puede ver.
¿Cómo debería explicarse un grafo de conocimiento de producto?
Un grafo no es una herramienta. Un grafo traducido a una decisión, sí. La diferencia está en el lenguaje.
Esto no:
EPIC-09.1 tiene 45 artefactos reverse-intake, distance score 15, validation gap 100.
Esto:
Has construido una máquina competitiva grande encima de un motor de lecciones. Puede ser un canal de adquisición, pero todavía no hay prueba de que convierta en aprendices que sigan volviendo.
Esto no:
El grafo muestra puentes semánticos entre zonas.
Esto:
El onboarding y la racha son los puentes entre captar gente y uso real. Si esos puentes no miden progreso activo, no puedes saber si la periferia funciona.
Nada de esto va de una respuesta más bonita. Va de convertir la estructura del producto en una frase sobre la que un product owner pueda actuar.
¿Te puedes fiar de un grafo de producto sacado por reverse intake?
Si el grafo viene de reverse intake, Brújula tiene que decirlo, en claro, cada vez. Un grafo leído desde el producto construido puede decir “esto es lo que sugiere el producto que has shipeado”. No puede decir que esta era la estrategia del equipo, que lo han validado usuarios, ni que el mercado lo quiere.
Reconocer ese límite no es una debilidad. Es buena parte de lo que separa un mapa de producto de una alucinación con seguridad. Un grafo que pinta una historia limpia sobre código desordenado es peor que ningún grafo, porque se lee como verdad. Así que marcas qué está construido, qué está supuesto y qué está probado de verdad, y mantienes los tres aparte.
¿Por qué importa más la topología de producto en la era IA?
Antes, un product manager podía tapar la falta de memoria de producto con reuniones, docs, un roadmap y criterio personal. Funcionaba porque construir era lo bastante lento como para pensar entre releases.
Con agentes, el coste de construir baja tanto que el riesgo cambia. La pregunta deja de ser “¿podemos construirlo?”. Pasa a ser:
- ¿por qué seguimos construyendo esto?
- ¿qué parte del producto está creciendo sin evidencia detrás?
- ¿qué apuesta se ha convertido en inercia sin que nadie lo dijera?
- ¿qué hemos confundido con progreso porque hay mucho código?
El build trap siempre ha sido real. Los agentes lo aceleran, porque llega más código más rápido y parece impulso. Un mapa de producto hecho de zonas, provenance, distancia y deuda de validación es como le pones el freno: no construyendo menos por construir menos, sino decidiendo con la forma delante.
Entonces
Claude Code te dice qué hay en el repo. Brújula te dice qué forma tiene el producto que has construido. Y esa forma es lo que te deja decidir qué proteger, qué congelar, qué validar esta semana, y qué no construir todavía.
La ventaja nunca ha sido responder más bonito que un agente leyendo código. Es que el producto construido se vuelve una memoria por la que puedes caminar: cada zona lleva de dónde ha salido, a qué distancia está del core, y si algo ha probado que funciona. Esa es la capa donde las decisiones de producto dejan de empezar desde cero.
Esta es la mitad de arriba de mantener vivo el contrato de producto, y la misma apuesta que el product management en la era de la IA: cuando construir es barato, la ventaja es decidir con memoria, no con intuición.
Brújula viene dentro de PaellaDoc, local-first y gratis. Construye este grafo desde tu propio repo, sin nube y sin cuenta, y lo convierte en decisiones de producto sobre las que puedes actuar.
¿Qué parte de tu producto está creciendo con más código y menos prueba? Cuéntame en el foro.