Get AI summaries of any video or article — Sign up free
Master Notion: From Confused to Confident with Marie Poulin's Coaching thumbnail

Master Notion: From Confused to Confident with Marie Poulin's Coaching

Tiago Forte·
5 min read

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

TL;DR

Replace a single evolving “canonical” speaker-notes page with a database so updates don’t break reliability.

Briefing

A major source of Notion stress isn’t the app’s complexity—it’s the lack of a reliable structure for changing content without losing authority. In a coaching session with Marie Poulin, the focus lands on turning a constantly evolving “speaker notes” document into a system that stays trustworthy even as new cohorts, resources, recordings, and feedback keep arriving.

The workflow starts with a tension many teams recognize: one “canonical” document that must remain stable versus the reality that improvements keep demanding edits. The solution is to stop treating pages like static truth and instead build a database-backed template where changes are fast, reversible, and automatically organized. Rather than relying on folders where data lives in one place, the approach leans into Notion’s ability to access the same information in multiple contexts—so the same speaker notes can be filtered, embedded, and reused without duplicating chaos.

Poulin demonstrates this by creating a database on the “parent page” for “live session speaker notes,” then dragging existing pages into that database. Key properties are added to make the records usable over time: automated timestamps like created time and last edited time, a version/cohort tag (e.g., “V 15”), status phases (planning, preparation, delivery, finished), and practical links such as a URL for the keynote file or related assets. Person properties help assign ownership so team members can work without seeing everything.

From there, the dashboard becomes the control center. Resources and past-session material are organized into headings and pulled into a table of contents so staff can find what matters quickly. Filtering by cohort/version (for example, showing only items tagged with “v15”) keeps views clean and prevents accidental clutter. The system also anticipates operational needs: where recordings live (e.g., Panopto), where feedback is stored, and how responsibilities shift over time through “responsible person” assignments and filtered views.

A second database for “in-class resources” adds another layer of reuse. Resources can be stored once (as URLs, file properties, or attachments like worksheets), then linked to sessions through relations. Two-way relations let a resource page show every session where it was referenced, enabling consistent reuse of high-value materials without hunting through scattered Google Drive folders or video links.

Finally, the session turns these building blocks into templates. Instead of starting from scratch each time, the content for each course section (e.g., “Express” and “distill”) is copied into templates and converted into text blocks inside the template so new sessions inherit a proven starting point. The result is a repeatable “starting script” that reduces fluster and preserves consistency—while still allowing edits where they matter.

The coaching takeaway is as much behavioral as technical: build systems that match existing habits, then standardize them. The goal isn’t to impose rigid rules that make people feel worse—it’s to make the next session easier to run, easier to update, and easier for a team to maintain with confidence.

Cornell Notes

The coaching session reframes Notion from a place to store documents into a system for managing change. A “live session speaker notes” database replaces a single, fragile canonical page, using properties like cohort/version tags, status phases, timestamps, ownership, and URLs to keep records reliable over time. A dashboard then filters and presents only what’s relevant for the current cohort, while relations connect sessions to reusable “in-class resources.” Templates capture the repeatable parts of each session type (e.g., Express, distill) so new sessions start from a proven structure rather than from scratch. This matters because it reduces stress, prevents clutter, and helps teams maintain authoritative materials without freezing them in place.

How does a database-based approach reduce the “canonical document” problem in team workflows?

Instead of treating one page as permanent truth, the system turns speaker notes into database records. Existing pages get dragged into a “live session speaker notes” database, then organized with properties that support change: automated timestamps (created time, last edited time), a cohort/version tag (e.g., “V 15”), and a status workflow (planning → preparation → delivery → finished). Because updates happen at the record level and views can be filtered, the workspace stays authoritative without requiring everyone to keep editing the same static page.

Which Notion properties make speaker notes manageable as cohorts repeat?

Poulin adds properties that support both tracking and operations: created time and last edited time for auditability, a version/cohort tag so the current cohort can be filtered (e.g., show only items tagged “v15”), status to reflect where each session is in its lifecycle, and link fields like a URL for related files (e.g., keynote or other assets). A person property (renamed from the default “person” to “instructor” or “responsible”) supports ownership and future delegation.

How does the dashboard avoid clutter while still keeping access to past information?

The dashboard uses headings and a table of contents for navigation, then relies on filtering to show only the current cohort’s speaker notes. Past-session content can still be accessible via embedded areas (e.g., an embed for watching the prior session) and by maintaining “last cohort” sections. Filtering by cohort/version ensures the view stays tidy even as the underlying database grows.

What role do relations play between sessions and reusable resources?

Relations connect a session record to a resource record so the same resource can appear in multiple contexts. For example, an “in-class resources” database can store URLs and attachments (like worksheets), and a relation lets “live session speaker notes” filter by which resources were referenced. Two-way relations can show every session where a given blog post or resource was used, turning scattered references into a searchable network.

Why convert content into templates, and how is that done in this workflow?

Templates prevent starting from scratch each time and preserve a consistent starting point. After building the structured content for a session type (like Express or distill), the content is copied into a template page. Inside the template, blocks can be turned into text so the template reliably inserts the content. New sessions then inherit the same structure, reducing fluster and improving consistency across cohorts.

What’s the coaching principle behind the technical choices?

The system is designed to align with existing habits rather than replace them with rigid rules. Poulin emphasizes taking what’s already working—like how speaker notes are used—and standardizing it so the system doesn’t make people feel more confused. The mantra is to keep asking what the goal is and how data should interact, then build only the properties and connections that support that purpose.

Review Questions

  1. When would a cohort/version tag be more useful than relying on manual page naming, and how would you use it in a filtered view?
  2. How would you decide which properties to add to a speaker-notes database without turning it into excessive data entry?
  3. What are the practical benefits of using two-way relations between sessions and resources compared with storing only URLs inside each session page?

Key Points

  1. 1

    Replace a single evolving “canonical” speaker-notes page with a database so updates don’t break reliability.

  2. 2

    Use cohort/version tags (e.g., “V 15”) and filtered views to keep dashboards clean for the current session cycle.

  3. 3

    Add operational properties—status phases, timestamps, URLs, and ownership—to make maintenance and delegation straightforward.

  4. 4

    Build a dashboard that combines navigation (headings and table of contents) with embedded access to past recordings and resources.

  5. 5

    Create a separate “in-class resources” database and link it to sessions using relations so references are reusable and searchable.

  6. 6

    Turn repeatable session structures into templates so new cohorts start from a proven baseline instead of rebuilding from scratch.

  7. 7

    Standardize what already works, then add only the properties and connections that support the team’s real workflow goals.

Highlights

The “canonical document” dilemma is solved by shifting from one authoritative page to database records with filters, so change stays controlled rather than destabilizing.
Cohort/version filtering (like showing only “v15”) keeps the dashboard tidy while the database continues to grow.
Two-way relations let a single resource page reveal every session where it was referenced, turning scattered links into a usable knowledge graph.
Templates capture repeatable session sections (e.g., Express, distill) so new sessions inherit structure without extra setup.