Get AI summaries of any video or article — Sign up free
Build with me: Notion's project management starter kit thumbnail

Build with me: Notion's project management starter kit

Notion·
5 min read

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

TL;DR

Organize the workspace with top-level pages by team or function so subpages and linked content stay easy to find.

Briefing

A Notion project-management starter kit centers on one idea: build project tracking from connected databases—then use views, filters, and rollups to keep teams aligned without duplicating work. The system starts with a workspace organized by top-level pages (by team or function), then moves into a project roadmap database where each project is a database entry with structured properties like status, launch date, priority, team, and owner. Because each row becomes its own full Notion page, teams can attach specs, links, images, and ongoing discussion directly to the project record—turning “tracking” into a living workspace rather than a static spreadsheet.

The core mechanics come from Notion databases and their building blocks: properties and views. Properties define the data model—text, dates, URLs, and especially select tags for initiatives—while views reshape the same underlying data for different workflows. The kit demonstrates five view types (table, board/kanban, calendar, list, and gallery) and shows how a board view can group projects by initiative or status, with card counts that make it easy to see what’s next. Views can also be filtered down to a specific person’s workload (e.g., “me”) and saved for quick reuse. Even the card content is customizable, letting teams decide which properties matter at a glance.

Where the system becomes truly project-management-grade is the relationship between projects and tasks. Instead of listing tasks as plain text inside a project page, the kit recommends a master tasks database with task-specific properties (type, assignee, priority, status, due date). Tasks then connect to projects through a relation property, creating a two-way link: selecting a project on a task automatically surfaces the task under that project, and vice versa. This keeps data sane—project tracking stays in the project database, task tracking stays in the task database—while still making them codependent through the relation.

Once relations exist, rollups provide the next layer of automation-like visibility. The kit shows rolling up task statuses onto the project roadmap so a project can display how many related tasks are “next up,” “in progress,” or “completed,” without manually updating anything. It also demonstrates rolling up other fields such as project launch dates and estimated time in hours derived from task properties. The same pattern extends beyond projects and tasks into OKRs: objectives relate to key results, key result statuses and numeric progress roll up into objective dashboards, and formulas (based on JavaScript) can calculate progress toward targets.

Finally, the starter kit emphasizes collaboration features that make the system operational: Notion’s updates feed logs changes and who made them, and pages can be followed so notifications appear in the updates area. Setup is framed as incremental—build the property “skeleton” first, then add relations and rollups as teams discover what needs to connect. The result is a flexible project-management system that supports multiple perspectives (by team, owner, initiative, or status) while keeping the underlying data connected rather than duplicated.

Cornell Notes

The starter kit builds project management in Notion by structuring work around connected databases. A project roadmap database stores each project as a page with properties like status, launch date, priority, team, and owner, plus room for specs and discussion. Teams then create multiple views (table, board/kanban, calendar, list, gallery) to group and filter the same data for different workflows, including saved “my projects” views. The system’s power comes from relating a master tasks database to the projects database, creating a two-way sync. With relations in place, rollups surface task status, launch dates, and time estimates back onto project records, and the same pattern extends to OKRs via relations and rollups.

Why treat each project row as a full Notion page instead of just a spreadsheet entry?

Each row in the project roadmap table is also an individual database entry that opens into a full page. That page keeps the same properties (status, launch date, priority, team, owner) while also allowing rich content in the body—project descriptions, specs, links, images, and threaded comments. The result is centralized project context: tracking fields live in properties, while supporting documentation and collaboration live in the page body.

How do views change what teams see without changing the underlying data?

Views reorganize the same database data using different layouts and controls. Notion supports five major view types: table, board (kanban-style), calendar (date-based), list, and gallery. A board view can group cards by any property (initiative, priority, status, responsible engineer), and cards can display only the properties the team cares about. Filters can narrow results further (e.g., show only projects where the responsible engineer is “me”), and saved views preserve groupings and filters for quick navigation.

What’s the practical difference between listing tasks as text inside a project vs using a master tasks database?

Text-based tasks inside a project page are static and hard to classify, filter, assign, or audit. A master tasks database creates structured task records with properties like task type, assignee, status, priority, and due date. That structure enables accountability and historical filtering, and it makes relations possible—so tasks can connect to projects and update project-level visibility.

How do relations create a two-way connection between tasks and projects?

A relation property links two databases. In the tasks database, a relation called “project” lets each task select the related project from the project roadmap database. When tasks are related, the project record automatically shows which tasks are connected. The sync works both ways: changing or adding relations on one side updates the other side, while each database still maintains its own task-specific vs project-specific properties.

What do rollups add after relations are established?

Rollups pull specific information from related database entries into a summarized property on the other database. After relating tasks to projects, a rollup can display task statuses on the project page (e.g., show the original status values or counts). It can also roll up other fields like launch dates and estimated time in hours from task properties. This reduces manual updates and keeps project dashboards consistent with task progress.

How does the same database pattern support OKRs?

OKRs are modeled with relations and rollups. Objectives relate to key results, and key result statuses and numeric progress roll up into objective-level dashboards. A formula property (JavaScript-based) can calculate progress toward a target (e.g., current result out of a targeted result). The objective view then becomes a compact status board for multiple key results.

Review Questions

  1. What properties would you choose for a project roadmap database to support your team’s day-to-day decisions (status, owner, dates, priority, initiative, etc.)?
  2. How would you design views and filters so different roles (engineers, designers, PMs) see the same project data in different ways?
  3. What information would you roll up from tasks to projects, and why would those rollups reduce manual work or errors?

Key Points

  1. 1

    Organize the workspace with top-level pages by team or function so subpages and linked content stay easy to find.

  2. 2

    Model projects as a dedicated database where each entry is a full page with structured properties plus a body for specs and collaboration.

  3. 3

    Use database views (table, board/kanban, calendar, list, gallery) to group and filter the same project data for different workflows, and save the views you’ll reuse.

  4. 4

    Track work in a master tasks database with task-specific properties, then connect tasks to projects using a relation property for two-way synchronization.

  5. 5

    Use rollups to surface task-derived information (status, launch dates, estimated hours) back onto project records without manual updates.

  6. 6

    Extend the same relation + rollup pattern to OKRs by linking objectives to key results and rolling up status and numeric progress.

  7. 7

    Treat setup as incremental: build the property skeleton first, then add relations, rollups, and saved views as the system matures with team needs.

Highlights

A project roadmap database row is also a full Notion page, letting teams keep tracking fields and project documentation in one place.
Board views can group by any property (initiative, priority, status, owner) and cards can show only the most relevant properties for that workflow.
Relations between tasks and projects create a two-way sync, while rollups turn that connection into project-level dashboards.
Rollups can summarize task statuses, roll up launch dates, and even aggregate time estimates in hours.
OKRs can be built the same way: objectives relate to key results, rollups summarize status and progress, and formulas calculate current vs target results.

Topics

Mentioned