← Back to blog

Product Thinking

Personal Knowledge Management

Personal knowledge management is a set of filing rules for things you read. Here is what each method optimizes, and the one thing they all miss.

Updated August 23, 2026 Intriq Editorial 7 min read
Relationship MemoryProduct Thinkingmemoryrememberpeople
Abstract illustration for Personal Knowledge Management

Personal knowledge management is the practice of capturing what you learn, storing it somewhere durable, and getting it back when it is useful. Every method you have heard of, Zettelkasten, PARA, CODE, GTD, is a rule for the middle step: given a new piece of information, where does it go?

That framing is more useful than the app comparison, because the methods differ far less than their communities suggest. They all take material you read, break it into pieces, and file those pieces by subject or by project. Which means they all share the same blind spot, and it is a large one.

The methods, and what each one optimizes

MethodFiling ruleOptimizes forWhere it strains
ZettelkastenAtomic notes linked to related notes, no foldersProducing new writing from old readingNeeds steady linking work to stay useful
PARAProjects, Areas, Resources, Archives, by actionabilityFinding things while you are working on themEverything not attached to a project drifts into Areas
CODECapture, Organize, Distill, ExpressTurning reading into outputThe distill step is the one people skip
GTDNext actions separate from reference materialDeciding what to do nextReference is deliberately a dumping ground

Read those filing rules next to each other and the family resemblance is obvious. Luhmann’s slip-box files by conceptual relation. PARA files by whether you are currently doing something about it. CODE files by the stage of processing. All three assume the incoming material is an idea, an article, a book note, a research fragment, something you read and might write about later.

WHAT EACH METHOD FILES BYZettelkastenwhich idea it relates toPARAwhich project it servesCODEwhat stage it is atGTDwhether it needs an action
Four methods, four keys, one assumption: the note is about a subject. That holds for almost everything you read.

For that material the methods work. Pick any of them, apply it consistently, and a year later you can find what you read about supply-chain risk, pull the four notes that matter, and write something with them. This is a solved problem, and the arguments between the camps are mostly about taste.

Every method is a filing rule, and filing rules have edges

Here is the material that breaks all four at once.

Priya mentioned her co-founder makes the final call on anything above fifty thousand. Marcus is defending his viva in July and is anxious about it. The head of procurement at your biggest account asked for an introduction to a hardware person, four months ago, and you said yes.

ONE FACT, FOUR FILING SYSTEMSPriya's co-founder makes the final callZettelkastenno idea to link it toPARAlands in AreasCODEcaptured, never distilledGTDfiled as reference
The fact is worth more than most of what you saved this month. Every system files it somewhere it will never be looked at again.

Try to file any of those. They are not about a subject, so Zettelkasten has nothing to link them to. They are not a project and not a resource, so PARA puts them in Areas, which is where PARA users will tell you things go to die. CODE captures them happily and then the distill step never comes, because there is nothing to distill from one sentence. GTD is closest, since “make the introduction” is a real next action, but the context around it, why Priya’s co-founder matters and what Marcus is worried about, is filed as reference and reference is a drawer.

None of this is a flaw in the methods. It is a category they were not designed for. Personal knowledge management grew out of research note-taking, and researchers file by topic because their retrieval question is a topic.

The retrieval key is the whole problem

A filing rule is only half a system. The other half is how you get things back, and that is where the mismatch becomes visible.

PULL RETRIEVALYou remember to lookYou type a queryThe note appearsThe first step is the one that already failed.PUSH RETRIEVALA meeting startsWhat you know is already thereNo query, because nothing had to be remembered first.
Pull retrieval needs you to remember that there is something to remember. That is the exact thing that failed.

Every PKM method assumes pull retrieval. You have a question, you go and look, the system answers. That is a fair assumption for reading notes, because the question arrives while you are working and you know roughly what you saved.

It is a bad assumption for anything about a person. The moment you need what Priya told you is thirty seconds before Priya walks in, and at that moment you are not going to search, because the whole failure is that you have forgotten there was something to find. A record you have to remember to consult is not doing the remembering.

That is the structural difference. Topic material is retrieved by query. People material has to be retrieved by event, which means the trigger has to come from the calendar rather than from you.

Why elaborate systems collapse in month three

There is a second, better-known failure, and it compounds the first.

heavy schemaleast structure you can tolerateNOTES ACTUALLY RETRIEVEDMONTHS IN
Configuration feels like progress and produces none. The system that wins is usually the one that was boring enough to start using immediately.

Designing a schema is enjoyable and produces nothing. Worse, every layer of structure you add up front is a decision you then have to make at capture time, forever. The moments worth capturing are almost always inconvenient, and a system that asks you to pick a folder, a tag and a note type in a car park will lose to a plain text file every time.

The practical version of PKM is smaller than the literature suggests:

  • Capture in one place with no decisions. One inbox, any format. Filing happens later or never.
  • Only structure what you have actually retrieved twice. Structure earned by use, not planned in advance.
  • Delete on read. A note you re-read and do not need again is finished. Most systems fail from volume, not from loss.

That is enough to make the topic half work for most people.

The second store

The people half needs a different shape, not a better folder inside the same one. Three things have to change: the key is a name rather than a subject, the unit is a fragment rather than a document, and the trigger is an event rather than a query.

This is what Intriq is: a store for the second column. You capture the line worth keeping in the minute after a conversation, by voice or in a sentence, and it attaches to the person rather than to a date or a topic. Before you next see them, what you know about them is there without you having gone looking. Nothing is scraped or enriched, and you can export all of it.

Run it alongside whatever you use for reading notes. Obsidian, Notion and a slip-box are all good at the thing they were designed for, and none of them was designed for this. Two stores with two keys is not a failure of tidiness. It is what having two different retrieval questions actually looks like.

Key takeaway: Personal knowledge management is a filing rule plus a retrieval habit, and every popular method files by subject and retrieves by search. That covers what you read. It does not cover what people tell you, which needs a name as its key and your calendar as its trigger.

FAQ

What is personal knowledge management in simple terms?

It is a system for capturing what you learn, keeping it somewhere durable, and getting it back when it matters. The capturing and the storing are easy. The methods people argue about, Zettelkasten, PARA, CODE, are really different answers to one question: where does a new piece of information go so that you can find it later?

What is the difference between PARA and Zettelkasten?

PARA files by actionability into Projects, Areas, Resources and Archives, so it tracks what you are currently working on. Zettelkasten files by conceptual relation, with atomic notes linked to other notes and no folders, so it builds a web that generates new writing. PARA suits people managing work. Zettelkasten suits people producing ideas.

Do I need an app for personal knowledge management?

No, and starting with one is a common mistake. A single plain text file plus a habit of writing things down beats an elaborate setup you configure for a weekend and abandon in April. Add structure only for the things you have actually gone back and looked for more than once.

Does AI change personal knowledge management?

It transformed retrieval and left capture untouched. Asking questions of your own notes in plain language now genuinely works, which removes the argument for elaborate tagging. What did not change is that the system can only answer from what made it in, so the bottleneck moved entirely to the four seconds after you have a thought.

Where do notes about people belong in a PKM system?

Nowhere comfortable, which is the honest answer. They are not projects, resources or ideas, so they land in whatever catch-all folder your method provides and are never opened again. The material needs a different index: filed under the person, surfaced before you see them, rather than filed under a topic and retrieved by search.

How much time should personal knowledge management take?

Capture should be seconds and unstructured. Review should be a few minutes a week, mostly spent deleting. If you are spending an evening on the system itself, that time is coming out of the reading and thinking the system was supposed to support, and month three is when that becomes obvious.