Get AI summaries of any video or article — Sign up free
Build a Second Brain PKM in Notion thumbnail

Build a Second Brain PKM in Notion

Irfan Bhanji·
5 min read

Based on Irfan Bhanji's video on YouTube. If you like this content, support the original creators by watching, liking and subscribing to their content.

TL;DR

Build a Notion second brain around a small set of properties—name, tags, media type, and last updated—to keep the system usable.

Briefing

A simple Notion database can function as a “second brain” without complex templates or heavy upfront note-writing—if the system is built around a small set of searchable fields, especially tags. The core idea is that most of the value in personal knowledge management comes from making information easy to retrieve later, not from spending time crafting elaborate summaries for every item collected.

The setup uses a lean database with only four properties: a name, tags, the type of media, and the last updated time. The philosophy is explicit: roughly 80% of an effective database comes from a couple of well-chosen properties. For this system, searchability is the priority, so tags do the heavy lifting. Relational features, multiple views, and advanced filters are treated as “fancy and fun,” but unnecessary for day-to-day retrieval.

A second pillar pushes against proactive, template-driven note-taking. Instead of writing book reports, chapter summaries, or pre-formatted fields for every source, the workflow stays reactive—capture only what future reference might require. For a fiction book like Project Hail Mary, the notes are intentionally bare bones: page numbers paired with a few lines of curiosity (for example, a page reference tied to “why microwaves don’t melt your face”). There’s no book template, no forced summary. For a YouTube video, the notes are similarly minimal: an embedded video, tags for people and topic, and most importantly a timestamp (like 8:41) so the viewer can jump back to the exact moment that mattered.

Tags are described as the “linchpin” because they represent what a future self would actually type when searching. The transcript emphasizes making tags descriptive and specific, and even adjusting note titles to match personal language. Retrieval in Notion is supported in two ways: filtering by tags and searching within the content of each page. Notion’s full-text search is highlighted as a practical advantage—if a note contains a term (like “evernote”) inside the body text, it can still be found even when there’s no tag or title match.

There’s also a limitation: Notion doesn’t allow searching across multiple tags in a single query, requiring the filter function instead. The creator notes a newer feature that allows searching different filters, but still wishes tag search were more flexible.

Finally, the system recommends keeping notes contained within three or four large databases—personal reminders, content creation, behavioral change and habits, and the personal knowledge management database. The rationale is that databases act like organizational “containers” that prevent notes from getting lost, while tags and internal search keep everything reachable. The minimal approach is also framed as a response to Notion’s potential to feel overwhelming; the goal is sustainability through low effort and consistent retrieval.

Cornell Notes

The transcript presents a minimal Notion “second brain” built for retrieval, not documentation. A personal knowledge management database uses only four properties—name, tags, media type, and last updated—because most value comes from a small number of well-designed fields. The system relies on descriptive, specific tags and on Notion’s ability to search inside the text of each note, so future searches can find content even without tag/title matches. Note-taking stays reactive: capture page numbers, timestamps, and brief prompts rather than writing book-report style summaries. Keeping all notes inside three or four main databases helps prevent fragmentation and keeps information searchable.

Why does the system avoid complex Notion database features like relationships and many views?

It treats searchability as the main job of the database and argues that most effectiveness comes from a couple of core properties. The database is intentionally limited to four fields—name, tags, media type, and last updated—because additional relational structures and fancy views add complexity without improving day-to-day retrieval enough to justify the effort.

What makes tags the “linchpin” of retrieval in this workflow?

Tags are designed to match what a future self would actually type. That means tags should be descriptive and specific, covering topic areas and subject matter in a way that supports later searching. The transcript also suggests aligning note titles with personal phrasing so searches and browsing feel natural.

How does the workflow handle different content types like books and YouTube videos?

It uses minimal, purpose-driven notes. For Project Hail Mary (fiction), the notes are just page numbers tied to curiosity (e.g., a page reference about “why microwaves don’t melt your face”). For a YouTube video, the note embeds the video and stores tags plus a timestamp (like 8:41) so the viewer can jump straight to the most relevant moment.

What’s the advantage of searching within page content in Notion?

Even if a term isn’t in the note’s title or tags, Notion can still find it if it appears in the body text. The transcript gives an example where “evernote” is found inside a saved paragraph method, despite there being no tag or title containing that term.

What limitation remains for tag-based searching, and how does the system work around it?

Notion doesn’t support searching for two different tags in a single query, so users must rely on the filter function. The transcript mentions a newer feature that lets users search across filters, but it still calls out the need for more advanced tag search behavior.

Why keep notes inside only three or four big databases?

Consolidation improves searchability and reduces the risk of notes getting scattered or lost. The transcript describes separate databases for personal reminders (like taxes and license plate), content creation, behavioral change and habits, and the personal knowledge management database—each acting as a container with tags and internal search.

Review Questions

  1. If you could only keep four properties in a Notion knowledge database, which would you choose and why?
  2. How would you design tags so they match your future search behavior rather than your current organization preferences?
  3. What kinds of notes would you treat as “reactive” (low-effort capture) versus “proactive” (template-heavy writing), and what triggers that decision?

Key Points

  1. 1

    Build a Notion second brain around a small set of properties—name, tags, media type, and last updated—to keep the system usable.

  2. 2

    Use descriptive, specific tags as the primary retrieval mechanism, matching what your future self would likely type.

  3. 3

    Prefer reactive note-taking (page numbers, timestamps, brief prompts) over template-driven summaries for every source.

  4. 4

    Rely on Notion’s full-text search to find terms inside note bodies even when they aren’t in tags or titles.

  5. 5

    Expect tag-search limitations in Notion (no simple multi-tag search) and use filters when needed.

  6. 6

    Keep all notes inside three or four main databases to prevent fragmentation and maintain consistent searchability.

  7. 7

    Treat minimalism as a sustainability strategy: reduce upfront effort to avoid Notion overload.

Highlights

The database stays intentionally bare: four properties, with tags doing most of the work for retrieval.
Reactive capture beats book-report templates—page numbers and timestamps can be enough.
Notion’s ability to search inside the text of each page can surface notes even without tag/title matches.
Keeping notes in a few large databases acts like a guardrail against losing information.
Tag search across multiple tags is limited, so filters become the practical workaround.

Topics