Product decisions come from scattered signals. I built a graph to connect them.

I started this wanting AI to help write PRDs and automate the build process. The better use case turned out to be making sure nobody walks into a customer meeting blind.

A PM doesn't make a decision from one document. They pull from customer calls, support tickets, product analytics, adoption data, sales blockers, NPS, Slack threads, prior launches, and gut instinct. Before automating any PM artifact, I asked three questions: where do PMs get the sources they use to decide, where do those decisions enter the build lifecycle, and what comes out the other side. That became the PM Brain.

I started with a real workflow that turned into a skill: writing a PRD. The PRD is the artifact people see. The real work happens before it, and it's mostly forensic: what pain is this solving, is the request one loud customer or a pattern across accounts, are deals blocked because of it, did something similar ship before, and what does the account team know that product hasn't heard yet.

The information exists. It's just scattered across systems and people, and each system only tells part of the story.

For example, take “UI complexity” as a popular customer ask. Customers say the UI is complex. Sales hears it as a deal blocker. Support hears it as repeated tickets. Product sees it as low funnel adoption. Calls have the quotes, feature requests have the asks, NPS comments have the frustration in plain English. Individually, each signal is easy to ignore. Together, they show you nuanced customer asks and where the product is leaking trust.

I forked Garry Tan's GBrain repo because the shape matched the problem better than a plain vector database. Most RAG setups embed documents, search chunks, and summarize what comes back. That works for lookup. PM brain is liker a relational graph: customers connect to pain points, pain points connect to features, features connect to release notes, and a six-month-old call can matter again the moment a new deal stalls. The value is in the connections, not the chunks.

GBrain's hybrid search runs three retrieval modes at once (vector for semantic lookup, keyword for exact names, graph for relationships), backs answers with citations, and flags what it doesn't know instead of guessing. It also auto-wires the graph on ingest with zero LLM calls, which keeps the whole thing cheap to run at scale.

A confident answer with no source is worse than no answer for PM work. You need to know which customer said it, which account it came from, and what the system still doesn't know.

If you want to see gbrain tutorials: GBrain shipped in April 2026 and picked up a fast following. MarkTechPost has a full install-to-MCP walkthrough with real terminal output, and Vectorize's review is a fair-minded look at where the project holds up and where it doesn't. Worth reading before you fork it.

I anchored on account (customer) data first, since accounts are the one object product, sales, CS, and leadership all share. From there I extracted pain-point themes from the qualitative data: accounts, pain points, customer asks, feature themes, product areas, and the evidence behind each one. Edges connect accounts to pain points, pain points to feature themes, and feature themes back to artifacts like PRDs and release notes.

That structure changes the question you can ask. Not "find notes that mention Feature X," but "which accounts feel this pain, what did they say, which deals are blocked, and have we solved something like this before." That's the actual PM question.

The end users simply use Claude to connect to MCP and start asking questions to the brain. What started out as a PM’s tooling quickly expanded to PMM and other teams.

The result of this brain became a vector-based graph database with 100k+ pages, 225k+ edges, and growing everyday.

I built this to write PRDs faster, and it does that. But the best use case turned out to be walking into a customer meeting already knowing the account's history. That surprised me, then made complete sense: go-to-market talks to customers every day, product hears a fraction of it, and someone always ends up asking a customer to repeat context they already gave.

The brain generates a prep note like:

Once the brain had accounts, pain points, and evidence, it stopped being a PM-only tool. Account teams used it before calls, partner marketing pulled pain-point themes, and it got pulled into exec-level account prep. So I turned it into an MCP server, since the goal is cross-functional context and people already use Claude. Now the questions run more like "what should I know before this meeting" or "which pain points show up in > $1M ARR customers" than "find me a document."

Meeting prep dossier isn't hand-assembled. Account briefs run through a deterministic HTML generator with agentic workflow for summarizing data, so the same account produces a byte-identical brief every time. A brief that changes on rerun isn't a brief you can trust in a live meeting.

The layer split is what makes this project scalable across org: the brain stays underneath as one graph, and a skill templatizes (I called it “account-brief” skill) the dashboard on top of it. If anyone wants to slice and dice the data differently with a different dashboard, Claude can do that backed by the same data. That separation means the graph doesn't care how you look at it. Account brief today, pain-point leaderboard tomorrow, whatever view the next question needs after that.

The next version combines unstructured and structured data. The PM Brain has qualitative signal. The data warehouse has structured signal: usage, adoption, retention, feature telemetry. The real product is both, which means a PM can finally ask whether the customers complaining about a workflow actually show the same pain in their usage data, or whether adoption moved after a feature shipped.

Release notes are next on the ingestion list, since they close the loop end to end. Slack and email are harder. The signal is real but the noise is brutal, and ingesting them blind is how you build a haunted attic with embeddings.

AI for product managers should start before the artifact: sources, lifecycle moments, outcomes, evidence, customer context, product judgment. The artifact gets better when the context gets better.

I set out to build a PRD assistant. I ended up building customer memory for product and go-to-market. That's the better brain.