What a PM’s knowledge base is for

Oct 14, 2026

Zihan Wang

Every opportunity assessment starts with the same question: what do we already know? For most PMs, the answer is "I'd have to dig."

The bottleneck moved

A few years ago, the hard part was getting evidence at all. Interviews took weeks to set up, synthesis took even longer, and continuous discovery was a dream for most teams.

AI changed that. Today a PM without a research team can pull themes out of 300 support tickets before lunch, summarize every sales call, and run desk research on a competitor in an afternoon.

Research got cheap. Judgment didn't. Deciding what the evidence means and what to bet on is still your job, and it just got harder, because evidence now arrives faster than anyone can keep track of.

So the bottleneck moved. It used to be "we don't know enough." Now it's "we don't know what we already know." You can hear it in the questions that come up in every planning round:

  • Have we tested this before? What happened?

  • Which customers asked for it, and what exactly did they say?

  • Did we already decide against it? Why?

What IS a knowledge base, for a PM?

In my opinion, it's the list of questions a PM keeps needing answers to, with one page per question that the AI keeps current, organized by themes. Every claim on a page points to its source.

Questions like:

  • What's stopping our customers from renewing?

  • Where do new users get stuck in their first week?

  • What do small teams need that large accounts don't?

  • Which onboarding experiments have we run, and what did we learn?

  • What did we decide about the free plan, and what would change it?

You already carry this list in your head. A knowledge base writes it down and keeps the answers up to date, so you don't have to.

The good news is that you don't need a new tool for it. A knowledge base is three things:

  • Files you own: plain text in a folder, readable by whichever AI you use this year or next.

  • Rules you write. The most important one is what counts as knowledge. After that come what counts as a source, how a page is built, and when a claim is too old to keep.

  • Your call on what becomes knowledge. Nothing turns into a page unless you say so.

In other words, the AI does the upkeep and you keep the judgment.

The method: give the bookkeeping to the AI

We borrowed the method from Andrej Karpathy's LLM Wiki. His argument is that the hard part of a knowledge base was never the reading or the thinking. It's the bookkeeping: filing, cross-linking, updating, and noticing what changed. People give up on that within weeks, so he hands it to the AI.

The method has 3 layers:

  • Sources are the raw material: transcripts, tickets, research. You add them, and nobody edits them afterwards.

  • Pages are what the AI writes from the sources, and rewrites as new ones come in.

  • Rules are yours. They say how pages are written, linked and checked.

And the AI has 3 jobs:

  • Take in: when a new source arrives, it updates every page that source touches.

  • Answer: when you ask a question, it answers from the pages and cites its sources.

  • Check: it looks for contradictions, stale claims and gaps.

The method: you add sources and write the rules, the AI writes and checks the pages

What it gives you back

Here's the method at work on the example company from our workshops: a team-task app with small teams on one plan and larger accounts on another. The interviews were written for practice (the pack is public), but you'll recognize the customers.

The PM opens one topic with one question: what's stopping our customers from renewing?

After three interviews, the page said: fix notifications. After interview four, it said that the biggest customer disagrees. After interview eight, it said that four customers can't get their data out, and that this is the real problem.

So the answer changed twice in nine interviews, and the PM never had to go back and re-read a transcript. This is the page after nine interviews:

The page after nine interviews: what changed lately, the picture now, a contradiction, open questions, a source behind every line

Now ask it an opportunity question: "Should we build reporting for larger accounts?" Four things come back.

1. What you already know, with sources. You get the evidence for and against, and each line points at the conversation it came from. When someone asks where a belief came from, you can show them.

2. Where your evidence disagrees. Small teams don't trust notifications, while the largest account switched them off in the first month. A summary would have picked one of the two. The page keeps both and says so.

3. What you decided before, and why. If this came up last year, you see what the call was and what would have changed it, which saves you from debating it all over again.

4. What's missing, or too old to trust. No small team brought up reporting, but nobody asked them either. Now you know which research to run next, and since research is cheap, an agent can do the first pass.

And again, none of these is a decision. That’s still yours to make. 

Where it sits next to your company wiki

You probably already have a company wiki, and this doesn't replace it. The company wiki is big and shared, and it's written for everyone. Your knowledge base is small and curated, and it's written for one job: yours.

"Yours" means the part of the product you're responsible for, whether that's onboarding, payments or the AI features. It holds what you need to decide well in that area.

The two only meet at the edges:

  • In: when you rely on a doc, you save a dated copy as a source. If someone edits the original later, your thinking still stands on what you actually read.

  • Out: specs, updates and briefs get drafted from your pages and published back to the wiki.

Build yours

The knowledge base is an essential part of our AI OS. Join us on 22 October, when we're building one together. You’ll leave with a knowledge base that you can keep building on.

Back to Overview